소개
여기에 공개 익스플로잇(Public Exploit) 분석 또는 제 1day 익스플로잇 중 일부를 게시할 예정입니다.
[ 공개 익스플로잇 분석 ]
- 개인적으로 공개 익스플로잇을 배우는 가장 좋은 방법은 익스플로잇을 완전히 이해할 때까지 한 줄씩 이해하는 것이라고 생각합니다. 다른 사람들도 이를 통해 배울 수 있기를 바라며, 커뮤니티에 기여하기 위한 목적으로 이러한 (과하게 주석이 달린 ;) ) 익스플로잇 중 일부를 게시할 것입니다. 또한 문서화 목적도 있습니다. 시간이 지나면 이런 것들이 머릿속에서 희미해지기 때문입니다.
CVE-2016-8655
- 이것은 rebel의 익스플로잇에 대한 상세 분석입니다.
- 멋진 익스플로잇을 만들어 준 rebel에게 감사합니다! :D
CVE-2016-5342
mp3 버전
tty 버전
- 이것은 freener의 Android LPE 익스플로잇에 주석을 단 버전입니다.
- arm32
- 힙 오버플로우
- 이 익스플로잇은 다른 객체의 객체 포인터를 덮어씁니다. ret2dir 공격을 사용하여 손상된 포인터가 익스플로잇 페이로드를 보유한 커널의 예측 가능한 고정 주소를 가리키도록 만듭니다. 이 익스플로잇 기법은 PXN과 PAN을 우회합니다.
CVE-2016-2434
- 이것은 Jianqiang Zhao의 Android LPE 익스플로잇에 주석을 단 버전입니다.
- arm64
- 임의 주소의 16바이트를 0으로 만듭니다.
- 이 익스플로잇은 커널의 고정 주소에 위치한 유용한 전역 객체의 16바이트를 지워버립니다.
- 전역 객체 내부의 손상된 객체 포인터는 유저랜드(userland)의 익스플로잇 페이로드를 참조합니다. 이러한 종류의 공격은 PAN(또는 PAN 에뮬레이션)이 있는 기기/커널에서는 작동하지 않습니다.
- extra_recipe 탈옥을 이해하려는 제 시도
- 저는 특히 kpp 우회 부분에 관심이 많았습니다. 우회에 대한 막연한 이미지를 얻을 수 있는 몇 개의 슬라이드가 있었지만, 코드 내부에서 실제로 무슨 일이 일어나고 있는지 세부적인 부분을 파고들고 싶었습니다.
- 또한 탈옥의 마지막 요소(Cydia 설치 등)를 이해하고 싶었습니다.
yalu102 (ViewController.m)
- 실제 버그와 관련된 부분과 그것이 어떻게 익스플로잇되었는지에 주석을 달았습니다.
- 원본 익스플로잇 대신 yalu102를 살펴본 이유는 port-feng-shui 기법이 더 깔끔하고 이해하기 쉬워 보였기 때문입니다.
- 분석은 kpp 우회 직전에 멈춥니다.
- 다양한 숫자 오프셋에 대한 정보가 조금 더 있기 때문에 여기로 이동합니다.
- 또한 객체 파일만 존재하는 yalu102와 달리 patchfinder.c가 온전하게 있습니다.
- cydia 부분이 다소 불완전해서 kpp 이후에 cydia 브랜치로 이동합니다.
- tfp0 및 사후 익스플로잇(post-exploitation) 이후 탈옥의 요소를 이해하려고 시도합니다.
empty_list (sploit.c)
- Ian Beer의 empty_list 커널 익스플로잇에 대한 상세 분석입니다.
- 매우 약한 프리미티브에서 시작하여 더 강력한 AAR을 구축하고, 마침내 완전한 기능을 갖춘 task port를 구축하는 놀라운 기법들을 사용합니다. 익스플로잇 코드 뒤에 숨겨진 port 매직은 믿기 어려울 정도입니다. 이 모든 것이 8개의 NULL 바이트 힙 오버플로우로 이루어집니다. 정말 충격적입니다.
- 안정성을 개선하기 위한 몇 가지 단순한 아이디어를 끄적여 두었습니다. 누군가가 미래에 더 안정적인 버전의 익스플로잇을 공개하기를 바랍니다. :)
- 놀라운 익스플로잇을 만들어 준 Ian Beer에게 감사합니다!
CVE-2018-4233
- 이것은 @niklas_b의 iOS Webkit 익스플로잇에 주석을 단 버전입니다.
- 매우 명확하고 간결하며 철저하게 주석이 달린 라이트업을 작성해 준 kudima(@begger_dd)에게 큰 감사를 드립니다! :)
- 해당 라이트업은 JIT 타입 혼동(type confusion) 버그, boxing/unboxing 변환의 일부 제한 사항(불안정성을 초래할 수 있음), 그리고 초기/후기 AAR/AAW 프리미티브가 어떻게 구성되는지에 대한 상세한 설명을 제공합니다. 또한 최근 완화 조치(인덱스 마스킹, ArrayBuffer 백킹 스토어 포이즈닝, W^X JIT 메커니즘의 일부 변경, JSObject 구조의 변경 등) 이후 익스플로잇 기법의 변화에 대한 통찰력도 제공합니다.
jsc_ConcatMemcpy_infoleak
- 이것은 kudima의 WebKit 정보 유출(infoleak) 익스플로잇(2018.8.27에 수정됨)에 주석을 단 버전입니다.
- 이것은 lokihardt가 보고한 버그 중 하나의 불완전한 수정에서 비롯되었습니다. lokihardt의 보고서에 따른 패치는 Double -> Object 타입 혼동 프리미티브를 수정했지만, 반대 방향인 Object -> Double은 수정하지 않았습니다.
- 단일 객체와 마커를 포함하는 butterfly로 웹킷 힙을 스프레이한 후, concat 버그를 트리거하여 여러 double 배열의 많은 부분을 초기화되지 않은 힙 데이터로 채웁니다. 초기화되지 않은 버그 있는 concat으로 생성된 double 배열들을 반복하여 이전에 스프레이한 객체의 주소를 찾아낸 다음 이를 유출합니다.
- 훌륭한 익스플로잇과 라이트업을 제공해 준 kudima(@begger_dd)에게 다시 한번 감사드립니다! :)
jsc_prop_enum_uaf
- 이것은 kudima의 또 다른 기여입니다. kudima의 WebKit 원격 코드 실행 익스플로잇(이 커밋에서 수정됨)에 주석을 단 버전입니다. iOS 12.1에서 수정되었으며, iOS 12.0.1까지 작동합니다.
- 문제는 baseline-jitted forin 루프에서 코드를 실행하는 동안 JSOBject를 뒷받침하는 StructureID 객체를 해제하고 가비지 컬렉터를 트리거하는 코드를 도입할 수 있지만, 가비지 컬렉터가 "JSPropertyNameEnumerator->m_cachedStructureID" 멤버를 마킹하지 않아 "JSPropertyNameEnumerator->m_cachedStructureID"가 가리키는 StructureID 객체가 스윕(sweep) 단계에서 해제되어 댕글링 포인터가 된다는 것입니다.
- StructureID 객체가 GC로 해제된 후, 이전에 해제된 "StructureID object" 슬롯을 차지하는 새 StructureID 객체를 생성하는 코드를 도입할 수 있습니다.
- 객체 A의 StructureID를 해제한 후 객체 B가 그 자리를 차지하는 새 StructureID를 생성하도록 만들면 타입 혼동 상황을 만들 수 있습니다. "JSPropertyNameEnumerator->m_cachedInlineCapacity"가 객체 A의 인라인 프로퍼티 크기로 설정되는 반면, "JSPropertyNameEnumerator->m_cachedStructureID"는 객체 B를 나타내는 새 Structure ID 객체를 가리키기 때문입니다. 이로 인해 'op_get_direct_pname'의 검사가 통과되고 객체 B가 경계를 벗어난 인라인 프로퍼티에 접근할 수 있게 됩니다.
- 이것은 AAR/AAW와 같은 더 강력한 프리미티브를 구축하는 데 악용될 수 있으며, 더 나아가 임의 코드를 실행하는 데 사용될 수 있습니다.
- 멋진 익스플로잇과 매우 상세한 라이트업을 제공해 준 kudima(@begger_dd)에게 감사합니다! :)
[ 1Day ]
CVE-2017-2547
- 어느 날 Zer0con 2018에서 발표된 후 singi의 익스플로잇을 살펴보고 이를 개선하기로 결정했습니다.
- 이것은 pwnjs에 통합하기 전의 독립 실행형 버전의 익스플로잇입니다.
- 개선 사항은 다음과 같습니다.
- 향상된 안정성(오염된 메모리로 광범위한 브라우징 세션 후에도 완벽하게 작동)
- 다양한 브라우저 버전과 호환되도록 모든 하드코딩된 오프셋 제거
- 다른 익스플로잇 기법 사용(표준 misalign 기법)
- webkit 프로토타입을 생성하여 최종적으로 pwnjs 프레임워크에 통합
- 코드를 훨씬 더 읽기 쉽게 만들고 많은 주석 추가
- 특별 감사
- 놀라운 phrack 기사와 공개 익스플로잇을 제공한 qwertyoruiop & Samuel Grob
- 훌륭한 pwnjs 프레임워크를 만든 Brian Pak & Andrew Wesie