제목 : Apache Shiro 인증 우회 취약성 재발 (CVE-2016-6802)

[KoreanHackerTeam]

0x00 漏洞详情​

Shiro가 경로를 제어 할 때 들어오는 URL 인코딩을 해독하지 못해 공격자가 필터를 우회하고 필터링 된 경로에 액세스 할 수있었습니다.

0x01 漏洞影响​

Shrio 1.3.2

0x02 环境搭建​

이 버전에는 Shiro-Spring-Boot-Starter가 없으므로 아직 GitHub에서 https://github.com/godzeo/shiro_1.2.4_sample/archive/master.zip로 프로젝트를 얻을 수 있습니다. 다음으로 샘플/웹/pom.xml 파일에서 JSTL 버전을 1.2로 지정해야합니다.

아이디어 편집기를 통해 전쟁 패키지로 컴파일 한 다음 Tomcat의 WebApps 디렉토리에 넣어 실행하십시오. 컴파일 된 전쟁 패키지 : https://github.com/backlion/demo/blob/mas 따라서 계정 경로는 필터링 된 경로에 속한다고 결정할 수 있습니다. 현재 BURP를 사용하여 자르기 한 다음 인증 권한을 우회하는 경로에 액세스하기 전에/임의의 디렉토리 이름 /./추가/추가하십시오. 1. 먼저 백엔드 홈페이지에 직접 액세스 한 다음 직접 점프 302

2. 액세스 경로 전에/임의의 디렉토리 이름 /./추가하는 경우, 고가의

3에 액세스 할 수 있습니다. 여기에서 배경 홈페이지 소스 코드와 우회 후 액세스 한 페이지의 내용을 볼 수 있습니다.

0x03 漏洞复现​

이 취약점에 대해서는 온라인으로 게시 된 정보가 거의 없습니다. 찾을 수있는 유일한 유용한 것은 Github에 대한 커밋 레코드와 CVE의 설명 정보입니다.
github 커밋 정보 : https://github.com/apache/shiro/commit/b15ab927709ca18a4a02538be01919a19ab65afcve 설명 : https://cve.mitre.org/cgi-bin/cvename.cvename.cgi?name=CVE-2016-680-2016-6802. webutils.java의 getContextPath 메소드에서.

CVE는 다음과 같이 설명됩니다.
1.3.2 이전의 Apache Shiro를 사용하면 공격자가 의도 된 서블릿 필터를 우회하고 뿌리가 아닌 서블릿 컨텍스트 경로의 사용을 활용하여 액세스 할 수 있습니다.
이 CVE 설명과 커밋 정보를 바탕으로, 우리는 뿌리가 아닌 컨텍스트 경로가 발생할 때 컨텍스트 경로를 얻을 때 취약성이 발생한다는 것을 알 수 있지만 자세한 정보는 여전히 알려져 있지 않습니다.
ContextPath와 관련이 있으므로 샘플 프로젝트를 배포 할 때는 ContextPath에서 배포해야하며 루트를 사용할 수 없습니다. 먼저 GetContextPath 함수의 입구에서 247 행에서 중단 점을 설정하고 액세스하려면 로그인이 필요한 일반 요청을 보내고 근처 코드의 처리 로직을보십시오.
CURL -V 'http://192.168.1.9:8080/샘플 -web-1.2.4/account/index.jsp'

후두 후 컨텍스트 경로이며 특별한 작동이 없음을 알 수 있습니다. 우리는 반환을 따르고 계속 추적합니다. ContextPath를 모른다면 먼저 Google을 직접 권장합니다.

org.apache.shiro.web.util.webutils#getPathWithInApplication 함수를 따르십시오. 방금 얻은 컨텍스트 경로는 실제로 requesturi를 계산하는 것이며, 선 그리기 코드의 두 줄을 참조하십시오.

org.apache.shiro.web.filter.mgt.pathmatchingfilterchainresolver#getchain 함수를 계속 따랐습니다. 요청 루리가 실제로 얻어 졌다는 것을 알 수 있습니다. 여기에서 조금씩 따라 가십시오. 103 줄 근처의 루프가 일치하는 프로세스에 대한 요청 루리를 얻고 일치하는 상황에서 해당 작업을 수행하는 데 사용된다는 것을 찾는 것은 어렵지 않습니다.
여기서 요청한 것은/account/** 모드와 일치하는 Account/Index.jsp입니다. 구성 파일 (shiro.ini)에서 /계정 /** 디렉토리는 로그인 한 후 사용자가 액세스해야합니다. 여기에서 후속 작업은 현재 사용자가 로그인되었는지 여부를 확인하는 것입니다.

여기서 F9는 직접 출시되며 302가 실제로 로그인 페이지로 리디렉션된다는 것을 알 수 있습니다. 이런 식으로 아이디어는 분명합니다. 문제는 ContextPath이며, 요청 러리를 생성하는 데 사용되는 ContextPath이며, requesturi는이 요청에 인증이 필요한지 여부를 결정합니다. 따라서 우리는 변형 된 컨텍스트 경로를 구축하기 만하면 변형 된 requesturi를 생성하기 만하면 Apacheshiro의 인증 메커니즘을 우회 할 수 있습니다.
그렇다면 어떻게 건설되어야합니까? 커밋 패치 코드에 따르면 디코딩 및 정규화 작업이 수행되는 것을 알 수 있습니다. 비정규 경로로 인해 발생해야합니다. 잘못된 맥락 경로를 얻으려면 /x/./와 같은 경로 만 구성하면됩니다.
다시 분류 한 후에는 ContextPath의 값이 /x/./sample_web_war가되었음을 알 수 있습니다. 계산 된 requesturi가 무엇인지 확인하려면 그것을 따라 가십시오. 정규화 및 디코딩 후, requesturi의 값은 /sample_web_war/account/index.jsp입니다.

내가 방금 본 부분을 계속 따릅니다. 나타나는 requesturi가 더 이상 /계정 /** 모드와 정상적으로 일치 할 수 없으며 로그인이 로그인되었는지 확인하는 단계에 들어 가지 않을 것임을 알기가 어렵지 않습니다.이 요청이 정상인지 확인하기 위해이 요청을 해제합니다.
curl -path-as-is -v 'http://192.168.1.9:8080/x /./샘플 web-1.2.4/account/index.jsp'

을 확인하기 전에 로그인 해야하는 페이지 컨텐츠를 성공적으로 반환했습니다. 이는 주로 ContextPath 및 requesturi의 일관되지 않은 처리 때문입니다.

0x04 漏洞分析​

https://blog.csdn.net/qq_41832837/article/details/109064636#%E8%BF%9C%E7%A8B%8B%E5%AE%89%E5%8 5%A8%E9%99%90%E5%88%B6%E7%BB%95%E8%BF%87%E6%BC%8F%E6%B4%9E%EF%BC%88CVE-2016-6802%EF%BC%89
http://ll29.cn/apache%20Shiro/apache%20Shiro%E8%BF%9C%E7%A8%8B%E5%AE%89%E5%85% A8%E9%99%90%E5%88%B6%E7%BB%95%E8%BF%87%E6%BC%8F%E6%B4%9E [CVE-2016-6802] .html

新晋毒瘤ApacheShiro？ - lightless blog

0. 背景准备对最近频发的 ApacheShiro 做个简单的分析和总结，从 1.2.4 开始统计，之前的古老版本就不看了。1. Deserialization1.1 shiro-550 AKA...

lightless.me

GitHub - godzeo/shiro_1.2.4_sample: shiro_1.2.4_sample shiro 550 原版样例

shiro_1.2.4_sample shiro 550 原版样例 . Contribute to godzeo/shiro_1.2.4_sample development by creating an account on GitHub.

github.com