[HACKING] Analyzing BurpLoader.jar in Burp Suite Pro Crack(Larry Lau version) Part2
지난번 포스팅에 이이서 BurpLoader.jar에 대한 분석 내용으로 이어갑니다.
Analysis BurpLoader.jar Part 1
### http://www.hahwul.com/2017/06/hacking-analyzing-burploaderjar-in-burp.html
Analysis BurpLoader.jar Part 2
### http://www.hahwul.com/2017/06/hacking-analyzing-burploaderjar-in-burp_20.html
Analysis BurpLoader.jar Part 3
### http://www.hahwul.com/2017/12/hacking-analyzing-burploaderjar-in-burp.html
Decrypt with JMD Deobfuscator
일단 zkm을 풀기위해 JMD를 이용했습니다. JMD는 여러가지 Java 관련 난독화를 풀어주는 툴이죠. (https://github.com/contra/JMD)
#> JMD BurpLoader.jar zkm true
Java Multi-Purpose Deobfuscator
Please Visit RECoders.org for updates and info
Version 1.6
Created by Contra. Please read LICENSE.txt
Tons of code from skoalman, super_, ollie, popcorn89, the prophecy, and saevion
[ZKMTransformer][DEBUG]Classes loaded from JAR
[ZKMTransformer]ZKM Deobfuscator
[ZKMTransformer]Starting Unconditional Branch Remover…
[ZKMTransformer]Starting Exit Flow Corrector…
[ZKMTransformer][DEBUG]corrected exit flow in larry.lau.BurpLoader.
JMD로 확인 시 어느정도 풀려서 보이네요. zkm
Analysis string
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> LNimbus
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> larry.lau.javax.swing.plaf.nimbus.NimbusLookAndFeel
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> 1af427b18de46c38410b46fb5a3f8080
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> burp.StartBurp
먼저 LNimbus와 아래 larry.lau.javax.swing.plaf.nimbus.NimbusLookAndFeel는 JAVA Swing의 Look&Feel을 의미하는 것 같습니다. Look&Feel은 JAVA Swing의 GUI 중 하나이고, 아마 BurpLoader.jar 즉 Burp Suite Pro 실행 전 디자인을 동일하게 가져가려는 생각으로 적용한 부분인 것 같네요. (https://docs.oracle.com/javase/8/docs/technotes/guides/swing/nimbus_laf.html)
그 아래 hash는 뭔지 궁금한 부분이고… 이어서 burp.StartBurp로 Burp suite를 실행하는 것 같습니다.
아! hash에 대한 추측이 있었는데, 작성중에 찾았습니다. hash 발생 부분이 burp.StartBurp이였고, DirtyJOE로 봤을 때 아래와 같은 순서로 호출이 존재합니다.
밑에 burpsuite_pro_v1.7.17.jar was corrupted!는 실행 경로에 burp가 없거나 잘못된 jar 파일이 호출되었을 때 발생하는 메시지입니다. 아마도.. md5 hash를 통해 정상적인 burp인지 비교하고 실행하는 것으로 보이고 예상대로 1af42~~ 값은 pro 버전의 hash였습니다.
#> md5sum burpsuite_pro_v1.7.17.jar 1af427b18de46c38410b46fb5a3f8080 burpsuite_pro_v1.7.17.jar
이제 윗줄은 맘편히 건너띌 수 있겠네요. 다시 이어서…
엄청난 길이의 바이너리 데이터를 만났습니다. 아마 ldc의 존재이겠지요. 풀 엄두가 나질 않는군요. (다만 이전에 Runtime Analysis 내용과 약간 이어서 생각해보면.. 레지스트리 값에 쓰인 여러가지 Extender Data와 관련있을 수 있겠네요)
넘어가고 아래부분을 보면 license1 이라는 문자와 Bash64로 인코딩된 값을 만날 수 있습니다. 형태를 보아 토큰같이 큰 길이의 암호화값을 Bash64로 바꾼 것 같고, 이는 웹에서 토큰 사용시 많이 쓰는 부분이라.. 한가지 생각이 들었습니다.
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> license1
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> Haq5Ce+UbnSxL5wePtogCg==
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> KN3pXQj7IgB4oph/ti7SdybjoUB9IWHt0BGBVS1kycSvYAn2zh0uJq9gCfbOHS4mrpBSDMCrw+Aw6t2wCDaKXPL9/xlWZPZnlnj81ae76L6rYIW/23B+vIAMzTM6+SsBJTep+u797+Cg/yaUeEryGxpkbasDpH5d70FrMkQZoMslDr6l+eYulgBhofjcyNJ5vqPj5bNfba0odRAdtHCLW9rtRNWAx/6Te8l9+NUHxBaSV6wFtSwGCNSEmnlqBGfuVN65ZJyM7zq3dKuCUC48F2IcCewpKi2E5we8a9+PCeGY1Rs3XHSbEpqt50Grbw2bAkZAxxkjlSDyXSbhQkcnDQ==
[ZKMTransformer][DEBUG]larry.lau.BurpLoader -> 6Oxo0eZXXJNgBSjf5x9U7DC4g2qx0boj8IwmY/rlifScDnW+3zrEAJk23UYYdxEpQ6Oh05x8QeIjEZys6bvlyLN70lJi5wqkoXe+BtrTnpT5ZiDEaQCi52lPmP85uk2X+XVkwLdf+sC6W/2IbrpN8JCFUt00EDq7a8Y0++7KDV26+DO1llwjoBiX6nXAtwIJo/c1qOVEHEed37oxlw70u+uUIOf9X5aScbgIx2EmGBFH6HzjsGEim1PrJNzSO1Lu2q7aIlX75p4EX32tqRvc6qm5v1L835h29xdVfk88EB7uX7FsneuOiu/y7t4cmlBCIHK6T1R3+6i6HpcYOzlbG/E2o38ymfaqLP1ntQ+a+HGz4ia+F77zdE46gjcGhE4iKj7TI2c+6IC8S/xnvRbtHA==
바로 정기적으로 통신하던 서버와 license 관련하여 주고받는 데이터가 아닐까? 라는 생각이였지요. 지난번 분석에서 봤던 요청은 기존 Burp에서도 나가던 요청이기 때문에 Larry의 개인서버로 거짓 인증하는 것이 아닌 실제 서버와 통신으로 인증하는 것 같고, 이는 https(ssl) 통신이기 때문에 바이너리 값을 웹에서 사용 가능한 형태로 인코딩한 것으로 생각됩니다. 물론 엄청난 길이를 고려했을 땐 base64가 적합했겠죠. (그냥 url encode 시 엄청난 길이..)
Final
Part 1 보단 조금 더 상세한 정리가 가능할 것 같습니다.
-
어떤 취약점을 사용했는지? A: 개인적인 경험 상 인증 요청에 대한 위조를 통해 bypass 하는 것으로 추측됩니다. 확실하진 않지만, 현재까지 분석 내용을 봤을땐 이쪽이 가장 가깝네요.
-
프록시에 쌓인 데이터, 또는 취약점 데이터를 다른 서버로 전송하지 않는지? A: 실행 및 동작중에 원격지와 통신하는 기록이 있긴합니다. 다만 portswigger 소유의 사이트로 보이고 일반적인 burp도 동일하게 동작하기 때문에 라이센스나 업데이트 관련해서 주기적으로 체크하는 로직이 아닐까 합니다.
-
Exploit 코드로 추가적인 프로그램이나 명령행을 다운로드 하는지? A: 풀지못한 ldc값이 가장 문제이긴합니다. 다만 Extender 정보의 데이터 양을 고려했을 때 여러가지 플랫폼에 대한 Exploit을 집어넣기는 어려울 것 같습니다. 뭔가 추가적으로 데이터를 가져오는 부분도 없구요.
ldc값에 대해 풀지못한게 너무 아쉽습니다. 이 부분에 정말 핵심적인 데이터가 있다고 믿지만, 아직은 어떻게 풀어나가야할지 막막하네요. 혹시라도 좋은 아이디어가 있으시다면 공유 부탁드려요.
Refernece
https://docs.oracle.com/javase/8/docs/technotes/guides/swing/nimbus_laf.html https://github.com/contra/JMD