Sunnyday's Free talk

네트워크 회사에 있다보니 CAP 파일이 굉장히 중요하다.

근데 CAP 파일 분석툴이 없다.

좀 더 정확히 이야기 하면 "CAP 파일 내부의 어떤 코드가 취약하고 어떤 악성코드가 심어졌고.." 라는 것을 의미한다.

"그걸 분석해서 뭐하려고?" 라고 이야기 할지는 모르겠지만

EXE 분석툴, SWF 분석툴.. 등 다양한 포멧을 분석할 수 있는 툴들이 많다.

하지만 왜 CAP 파일 분석툴은 없을까.. 라고 고민하게되었고 설계하고자 한다.

일단 CAP 파일을 분석하려면 아래와 같은 조건이 선행되어야 한다고 생각한다.

1. 세션별 트래픽 분류

2. 데이터 값에 대한 File format 확인 (파일종류 확인)

3. 다양한 취약점에 대한 이해

4. 결과값들의 연관관계

사실 정확히 이야기 하면 CAP 파일 분석툴은 필요가 없다.

해당 컴퓨터 내부에서 프로그램으로 동작하면 되는것이 아닌가..

하지만.. 내 실력이 미천하여.. CAP 파일을 생성한 이후, 그 CAP 파일을 분석하는 형태로 구성을 계획중이다.

해당 툴이 완성되면 아래와 같은 Flow로 분석을 진행할 예정이다.

ex) "취약점분석시스템"이란 제작할 툴을 이용하여 만들 시스템으로 웹서버로 URL을 받아들여 분석하는 시스템이다.

1. 보안관제 혹은 보안에 관심있는 사람들이 "취약점분석시스템"에 접근하여 URL을 입력한다.

2. 입력된 URL은 내부에 있는 가상머신을 통해 접근하게되며, 접근할 때 네트워크 트래픽을 덤프한다. (CAP)

3. 약 20초간 딜레이 -> CAP 파일 백업 -> Snapshot 복원

4. 생성된 CAP 파일을 분석툴을 이용하여 분석한다.

5. 분석툴은 내부적으로 알려진 취약점 및 악성코드, 경유지, 유포지 등을 수집/분석한다.

6. 수집/분석 된 결과를 "취약점분석시스템"에 보여준다.

이로 인해 예상되는 이익은 아래와 같다.

1. 분석시스템의 자동화로 인해 업무효율 상승

2. 신종 공격 발견 시간 단축

3. 악성파일 및 악성스크립트 수집

4. 알려진 공격과 알려지지 않은 신종공격에 대해 실시간으로 구별가능.

5. 샘플에 대한 처리률 상승

만들고는 있는데.. 언제쯤 완성될런지는..

일단 담주 금요일까지 완성을 목표로.~

GetPC (get Program Counter, also known as GetEIP on x86) code is code that determines its own location in a process' address space. It is commonly used in code that needs to reference itself, for instance in self-decoding and self-modifying code.

CALL GetPC

The easiest way to implement GetPC code on x86 is using the CALL instruction, like so:

$+0:    E8 00000000 CALL    $+5         ; PUSH $+5 onto the stack
$+5:    59          POP     ECX         ; ECX = $+5
$+6:    ...shellcode...

Because the argument to the CALL instruction is the offset of the code to call, in this case 0, this code contains null bytes. Unfortunately, it is often not possible or practical to inject null bytes into a target process during exploitation. A common trick to get around this is to make the CALL point to a lower address address, making the offset negative, like so:

$+0     EB XX       JMP     SHORT $+N   ; Jump to the call instruction
$+5:    59          POP     ECX         ; ECX = $+N+5
$+6:    ...shellcode...
$+N:    E8 FFFFFFXX CALL    $+5         ; PUSH $+N+5 onto the stack and jump back to $+5

As you can see, this code is null free but this code has two drawbacks:

1. It is 2 bytes larger than the first example.
2. The shellcode between the POP and CALL instruction can only be 126 bytes, if you need more room, you will have to jump over the call and put the remainder after it.

There is a second trick to get around these two problems:

$+0     EB FFFFFFFF CALL    $+4         ; PUSH $+5 onto the stack and jump to $+4
$+5:    C8 59XX XX  ENTER   XX59,XX     ; Does not get executed like this; see below.

When this code executes, the CALL will jump to the last byte of its own instruction. The code executed after the CALL will therefore be:

$+4:    FFC8        DEC     ECX         ; Does nothing useful; can be considered a NOP.
$+6:    59          POP     ECX         ; ECX = $+5
$+7:    ...shellcode...

The above code is only 1 byte larger than the first GetPC and puts no constraints of the shellcode following it.

FSTENV GetPC

A way to retrieve the value of EIP on x86 systems is to use the x87 FSTENV instruction to store the state of the x87 floating point chip after issuing a FLDZ instruction. The structure store in memory by FSTENV will then contain the address of the FLDZ instruction at offset 0x0C of the structure:

$+0     D9EE          FLDZ                   ; Floating point stores $+0 in its environment
$+2     D974E4 F4     FSTENV SS:[ESP-0xC]    ; Save environment at ESP-0xC; now [ESP] = $+0
$+6     59            POP ECX                ; ECX = $+0

This method is also null free and uses the same amount of bytes as the last CALL example.

SEH GetPC

A third way to write GetPC code is to use the Windows specific Structure Exception Handler (SEH). When an exception happens in a process on Windows, a structured exception is created by the operating system and passed to the first SEH handler to see if it can handle it. If not, the second SEH handler is asked, etc... if no SEH handler handles the exception, the program is terminated because of an unhandled exception. Whenever a structure exception handler is called, it is passed (pointers to) information about the exception on the stack. This information includes the address in memory of the instruction that caused the exception.

It is relatively simple to register a structured exception handler with the OS. If a shellcode can generate a small structured exception handler at a known location in memory and register it before causing an exception, this small structured exception handler would get executed. It could determine the address of the instruction that caused the exception and jump back to the next instruction (the one immediately following it). The code would then continue as normal, only now knowing exactly where it is.^{[todo:Write an example]}

Because the SEH was abused heavily by exploits for various purposes, Microsoft has introduced additional checks on the SEH as mitigation against this abuse with each service pack of Windows XP. These have made writing working SEH GetPC increasingly harder. On Windows Vista, it seems these mitigation make it impractical of not impossible to write working SEH GetPC code. However, it is still possible to write SEH GetPC code on Windows XP sp3. It's even possible to do so using only alphanumeric instructions, which is used in ALPHA3 to create alphanumeric SEH GetPC code.