2011.12.24 13:49 System

[+]Introduction


아주 간만에 포스팅입니다.

1,2주 안하다보니 한달이 되고 두달이 되고..

 

<Fig0. 하라는 공부는 안하고!>

좀 더 심도있는 내용을 올리고 싶었는데 그게 또 핑계거리가 되서 블로그에 글을 안쓰고 있네요.

그래서 간단한 내용이라도 올리고자 합니다.

Global Hooking 을 거는 손쉬운 방법으로는 SetWindowHookEx가 있죠.

Windows 에서 자동으로 Injection을 시켜주기 떄문에 Process의 생성을 catch 해서 따로 Injection 해줄필요도 없구요.

이 부분에 관해서는 Reversecore님 Blog에 아주 자세히 설명되어있기 떄문에 참조하시길 바랍니다.

제가 이번에 쓸 내용은 SetWindowsHookEX를 이용해서 Hooking 을 걸고 UnHookWindowHookEx를 이용하여 해제했는데도 

박혀있는 DLL 을 강제로 Ejection 시키는 방법입니다.

[ 추후 UnHookWindowsHookEx를 이용하지 않고 Hooking을 해제하는 방법도 올리도록 하겠습니다 :D 

Windows7 에 올라와서 물리 메모리에 접근하는게 좀 까다로워져서 고생중이네요. Driver 없이 User 모드에서 가능한지를 살펴보고 있습니다

XP는 되는데 음.. ]



[+]Problem



UnHookWindowsEx만 호출한 경우 대부분의 Process에서는 DLL이 Ejection 되지 않습니다.

[ 물론 해제가 되는 Process도 있습니다. Process 내부에서 Message 처리를 열심히 하는 녀석들이죠.

대부분 UI 가 사용자에게 보여지고 있는 상태의 녀석들이구요. ]

보통 UnHook 후에 SendMessage 를 Broadcasting 하게 뿌려서 Process에 해제하게 되죠.

이 Message는 의미있는 Message 일 필요는 없습니다. 

Message가 오면 Hook Chain을 알아서 갱신하니까요.

아무튼 이렇게 Message 를 뿌려줘도 DLL이 빠지지 않는 Process가 존재하게 됩니다.

대표적으로 AdobeARM.exe Chrome의 Rundll32.exe가 있죠.

물론 항상 빠지지 않는건 아니고 간혹 빠지지 않는 현상을 보게 됩니다.

이런 Process들은 대부분 단일 Thread라는 점을 확인할 수 있는데요.

정리하자면

1. UnHook할 때는 Message를 뿌려서 받은 Process들은 해제가 된다.

2. UnHook 되지 않는 녀석들은 대부분 단일 Thread이다.

3. 위 Process 들도 항상 DLL이 Ejection 안되는건 아니다.

이 부분에서 문제점을 유추할 수 있습니다. 

Process에 외부에서 들어온 Message를 처리할 Thread가 없으면 DLL이 Ejection 되지 않는다.

라는 점입니다.



[+]Solution


그렇다면 위 문제는 어떻게 해결해야 할까요?

많은 분들이 FreeLibrary를 CreateRemoteThread를 이용해서 삽입하는 방법을 생각하셨을겁니다.

흠, 하지만 이 방법에는 문제점이 있는데

FreeLibrary시에 해당 DLL에 접근하고 있는 Thread가 있으면 그대로 프로그램이 뻗어버린다는 것이죠.

DLL Unload 뭐 이런 Error가 났던걸로 기억합니다.

결국 DLL이 자동으로 Ejection 되게 하려면 Message를 처리하도록 만들어야한다는거죠.

Message 처리 루틴 Thread를 Process에 삽입하고 다시 Message를 보내볼까요?

너무 번거롭습니다.

생각해보면 Process 자체에서 Ejection 해주는게 아님을 파악할 수 있습니다.

빈 Message를 받았을 때 Hook Chain에 없는 DLL을 빼주는게 Process 자체 역할을 아니니까요.

Process는 단순히 Message를 받는 것이고 이 때 발생한 특정 Event를 Windows에서 받고 Ejection 해준다고 판단 내릴 수 있겠군요.

그렇다면 직접 Message를 발생시키면 어떨까요?

Code Injection을 통해서 DLL이 빠지지 않는 Process에서 Message를 발생하도록 하는거죠.

아래 Code Inejction Code는 Reversecore님의 Code를 상당부분 인용했습니다.

http://www.reversecore.com/82 

먼저 사용할 함수를 정의합니다.




다음은 실행코드입니다.

함수 호출에 필요한 String을 먼저 삽입하고 그곳을 참조하는 방법입니다.



SendMessage를 쓰기 보다 SendMssageTimeOut을 썼고

Parameter 간소화를 위해 Broadcasting을 합니다.

위와 같은 방법을 이용하면 DLL이 정상적으로 잘 Ejection되는 것을 확인하실 수 있을겁니다.

어때요 참 쉽죠?


글이 올라온 날이 12월 24일이라는 건 신경안쓰셔도 됩니다








Posted by LinkC

2011.07.16 21:45 WarGame

[+] Introduction

 


 이번에 소개할 문제는 VM 관련 문제 입니다.

VM을 이용한 기술은 VCP [ Virtualized Code Protection ] 이 있으며 해당 기술은 Protector 에 많이 쓰이곤 합니다.

언뜻 봐도 " Code를 Virtualize 하여 Protect 한다 " 라는것을 의미한다는거라고 쉽게 추측 할 수 있죠.

상용 Packer 인 Themida에 실제로 쓰이고 있는 기술이기도 하구요.

물론 Themida에는 VCP 뿐만 아니라 여러가지 Anti Reversing 기술들이 들어가있습니다만..

 이 포스팅에서는 VM만을 다루도록 하겠습니다.

 * VM이 적용되면 Reversing 하는 입장에서는 상당히 귀찮아집니다.

뒤에서 설명하겠지만 Assembly Language 로 한줄씩 실행되기 떄문에 

전체적인 구조를 살펴보려면 Script를 짜거나 손으로 직접 모아야 하기 떄문이죠.

디버거로 열어봤는데...


<Fig 0. VM이 딱 ! >


 <Fig0-1. 5초후에 빡침이 딱!>



[+] Problem


<Fig1. Bin500을 실행 시켰을 때 >

 

먼저 Debugger로 문자열을 확인해보면

key File로 짐작되는 문자열 'codegate.key' 를 찾을 수 있습니다.

적당히 아무내용이나 집어넣어서 재실행 시켜보면

역시 유효하지 않은 파일이라고 하는군요.

<Fig2. 해당 파일이 올바르지 않을 때 메세지> 

이런 류의 문제라면 해당 Key 파일을 검사하는 부분을 우회해도 

암호가 나오지 않고 그 파일을 가지고 연산을 하기 떄문에

해당 파일의 내용을 정확히 복구를 해야 합니다.

 파일을 열어 Verify 하는 부분을 찾으려 해도 도통 보이지 않는군요.

이 문제의 핵심인 Verify 부분이 VM에 의해 실행되기 때문이죠.


[+] Analysis

 
그렇다면 Debugger로 확인을 해봅시다. 

<Fig3. VirtualAlloc을 통해 특정 메모리 영역을 할당받는 모습>

 해당 영역을 확인해보면 아시겠지만

애초에 VM 영역에서 시작하네요.

후에 VirtualAlloc 을 호출하고 특정 영역에  RWE 권한을 모두 줍니다.

계속 따라가보면 VirtualAlloc을 한번 더 호출하고 .. [ 같은 크기, 다른 위치에 RWE 권한을 줍니다 ] 

이 할당한 영역에 특정 명령어를 수행하는 것을 확인 할 수 있습니다.

<Fig4. VirtualAlloc에 할당된 영역에서 코드를 실행하고 있는 모습>
 
그 후에 다시 0x40ABBD로 Return해서 특정 루틴을 반복합니다.


<Fig5. Code를 가져와 Decrypt하는 부분>

0x0040A94A를 호출함으로써 실행할 Code를 복호화 하는데

해당 함수를 살펴보면 다음과 같습니다.


<Fig6. Fig5의 Decrypt함수 내부>

 

사실 위 함수가 문제를 푸는데 큰 도움이 되는 건 아닙니다.

CPU가 해석 할 수 있는 일반 기계어로 복호화 하는 과정이지

Key 파일의 내용을 확인하는 과정이 아니기 떄문이죠.

하지만 VM의 동작 방식은 확인을 하고 갑시다.

대략적인 VM의 구현은 다음과 같습니다.

<Fig7. VM의 동작 방식>

실제 문제 파일을 Debugging 해보면 아시겠지만

text 영역과 VM 영역이 번갈아 가며 실행되는 것을 볼 수 있습니다.

Sensitive 한 곳은 VM 처리가 되어있는거죠.



즉 우리가 원하는 것은 ' Codegate.key 파일을 입력 받고 난 후 실패 메세지가 나오기 전까지의 연산 과정 ' 입니다.

이것은 1Byte 씩 검사하여 다르면 바로 실패로 return 하는 과정일수도 있고

전체 내용을 모두 검사한 후 최종적으로 실패를 판단할 수도 있습니다.

물론 전자가 훨씬 까다로워집니다. 실행중에 비교 값을 바꿔야하니까요.

ReadFile에 BP를 걸고 해당 파일을 읽어 온 후에 Buffer에 접근 하는 부분을 잡아보면

최종 Code가 실행되는 곳을 잡을 수 있습니다.

이곳을 보면 Fig4에서 할당한 곳과는 다른 공간임을 알 수 있습니다.

즉, 복호화된 Code가 실행 되는 부분은 2군데이며 

1. 일반 적인 Code가 실행되는 부분

2. Key 파일의 내용을 검사하는 부분


이 되겠습니다.

두 부분을 모두 BP 걸고 확인해보면 아시겠지만 Call , JMP 문을 찾아 볼 수 없다는걸 알 수 있습니다.

Call이나 JMP문이 가고자 하는 곳은 VM에서는 외부 , 즉 원본 프로그램의 text 영역입니다.

이 부분으로 가려면 해당 주소에 맞는 연산이 또 별도로 필요하죠.

문제 풀이엔 별로 중요한 내용이 아닙니다만,

'VM은 이런식으로 구현되고 있다' 라는 것은 염두해두시는게 좋습니다.



[+] Solution



이 다음부턴 딱히 설명 드릴게 없습니다.

Script를 짜거나 손으로 직접 코드를 바꾸시면서 진행을 하셔야 합니다.

운이 나쁘게도 앞서 설명드린 1Byte 씩 검사하고 아닐 경우 실패로 간주하는 타입이군요.

Script로 모으기 짜증 + 1  이 되었습니다.

아무튼 해당 Code를 모으면 다음과 같은 모습입니다.

Pydbg의 HardWare BP를 이용한건데 가변길이라 그런지 

다음 명령어까지 받아오더군요.. 쩝..


<Fig8. Xor, Cmp 부분 중 일부를 긁어온 모습>

이 부분을 예로 들자면

al 로 가져온 값을 xor 0x46 하고 이 값을 cmp 합니다.

xor  [ Data  ] , 0x46

cmp ( [ Data ] ^ 0x 46 )  , 0xf0

즉 Data 의 값은 0x46 과 Xor를 했을 때 0xF0 가 나오는 0xB6 이 되겠네요.

이런 식으로 Codegate.key 값을 하나씩 복원합니다.

Codegate key 값이 총 100 Byte 니 벼..별거 아니군요.

Xor 부분과 cmp 부분을 parsing 매 Byte마다 바꿔주면

다음과 같은 원본 데이터를 얻을 수 있습니다.

<Fig9. 원본 Key File >

이를 codegate.key 에 저장하면 


<Fig10. 해독된 Key File>

이게 정답은 아니겠죠?

100Byte의 16진수가 뭘 의미 할까요.

흠 분포도를 보면 문자를 의미하는건 아닌거 같습니다.

그리고 저 출력 방식도 의심해볼만 하죠

4 * 25 형식입니다.

또, 0x80 0x00 이 유독 눈에 많이 띄는걸 볼 수 있는데..

일단 이를 binary 값으로 바꿔보았습니다.


<Fig11. Binary 값으로 바꾼 모습>



<Fig11-1. !?>
왜 4 * 25 형식으로 출력했는지 알겠네요.

0x80이 binary 값으로 1000 0000 이니까

뒤의 0을 떼버리면 25 * 25 형식의 값이 완성됩니다.

여기에 모서리 부분을 보면 1과 0이 규칙적으로 나열되어있는데

전 이걸 QR 코드라고 판단했고 이를 만들어보면..



QR Code Reader로 읽어보니

I_am_in_C0d3gat3_2011!!

이라는 답이 나오는군요.















Posted by LinkC

2011.05.18 16:31 System

[+] Introduction


 Pydbg. 요즘들어 주목 받고 있는 Script 언어 중 하나인 Python의 Debugging Module 입니다.

Python 언어 자체가 심플하고 이해하기 쉽기 때문에 이를 이용하나 Pydbg도 상당히 접근하기 용이합니다.

물론 Python의 고질적인 문제인 속도는 안고 가야 할 문제입니다만..

이번 포스팅에서는 Pydbg의 Snapshot 기능이 가지고 있는 문제점에 대해서 써볼까 합니다.

Snapshot 기능에 대해 간단히 설명하자면 말그대로 특정 지점의 정보를 Snapshot 찍듯이 찍고

Restore를 통해 찍은 시점으로 돌아가는 거라고 보시면 되겠네요.

예를 들어서 금요일 저녁에 Snapshot을 찍어놓고 

일요일 저녁에 저장해뒀던 Snapshot으로 Restore 하는거죠.

...


<Fig0. 울지마라>

상당히 유용한 기능입니다.

특정 루틴을 반복하는데 좋겠죠? 

아무튼 해당 기능을 사용하는데 약간 문제가 있는데요,

첫번째는 Pydbg File 자체를 수정하지 않고 일어나는 문제점을 해결 하는 방법이고

두번째는 Pydbg File 자체를 수정하는 방법입니다.

간단하기로는 후자가 간단합니다. 단 두글자만 수정하면 끝나요.

포스팅은 전자에 중점을 두고 기술하도록 하겠습니다.




[+] Problem


snapshot의 사용방법은 간단합니다.

pydbg의 객체의 process_snapshot() method를 호출해주면 되죠

복구는 process_restore() 입니다.

그리고 해당 method를 호출해주기 전에

모든 thread를 멈추고 snapshot해야 한다고 pydbg의 제작자 pedram amini 가 명시하고 있습니다

그러니까 이런 식으로 해야겠죠.

SnapShot

dbg.suspend_all_threads()

dbg.process_snapshot()

dbg.resume_all_threads()


Restore 

dbg.suspend_all_threads()

dbg.process_restore()

dbg.resume_all_threads()



예제를 통해 문제를 살펴보죠.

간단한 문자열을 출력하는 다음과 같은 코드가 있습니다.

여기서는 puts를 이용하였으나, printf 문도 동일한 문제가 일어납니다.


*해당 문제는 VS2010의 msvcr100.dll 에서는 발생하지 않습니다만

Windows의 기본 C- Runtime Libary인 msvcrt.dll 을 썼을때는 해당 문제가 발생합니다.

확인해보면  msvcr100.dll에서는 별도의 예외처리가 들어갑니다. 

해당 예외 원인은 뒤에서 설명하도록 하죠.




<Fig1.  예제 프로그램>

Friday nigth에 snapshot 을 찍고

Sunday night 에 restore를 해보면

정상적으로 작동하지 않는걸 확인해볼 수 있습니다.

<Fig2. 정상적으로 출력되지 않고 종료된 모습>
 
나머지도 출력이 되지 않는걸로 봐선 Handling 되지 않는 예외가 발생하여 프로그램이

죽었다고 보면 되겠죠.

발생하는 예외의 Call Stack을 확인해보면

EnterCriticalSection 이후에 발생하는 것을 볼 수 있습니다.

예외가 나는 경우를 확인해보면 항상 같은 곳에서 발생하지는 않습니다만

EnterCriticalSection 함수에 진입하고 나서 발생하는것은 변함이 없습니다.

EnterCriticalSection?

동기화를 위해 사용되는 방법중 임계영역[  Critical Section ] 을 이용하는데 사용되는 함수입니다.

단일 Thread 프로그램인데 무슨 동기화냐 하시는분이 계실지도 모르겠는데

기본적인 Console 출력 함수들은 모두 동기화 작업을 거칩니다. 



왜 이런 문제가 발생할까요?


[+] Analysis


예외 원인을 보면 Access Violation이 주로 일어납니다.

일단 Snapshot method가 호출되었을 때 저장되는 내용을 한번 살펴보겠습니다.


<Fig3. 각 Thread의 Context를 get_thread_context를 통해 저장한 모습>

Context에는 어떤 내용이 저장되는고 하니

<Fig4. WinNT.h에 있는 CONTEXT Structure의 구조>
 

해당 함수에서는 CPU Register를 저장합니다. 

이후 메모리를 돌며 쓰기가 불가능한 곳과 실행파일 이미지를 제외한 영역을 저장합니다.


 <Fig5. 쓰기 가능한 메모리 영역을 저장하는 부분>

 바로 이곳이 문제입니다.

 stack 값이나 Register 영역 값은 모두 정상적으로 복구되는데 실행 파일 이미지에 저장되는 변수는 그대로 남아있는 것입니다.

 즉, data 영역에 저장되는 전역변수가 문제가 될 수 있다는 거죠.

Critical Section의 구조를 살펴봅시다.

<Fig6. Critical Section 구조체의 모습>

첫번째 member를 보면  _RTL_CRITICAL_SECTION_DEBUG 이라는 Linked List 형태의 구조체를 가리키고 있는

포인터 임을 확인 할 수 있습니다.

자 그렇다면 정리해봅시다.

전역변수로 지정된 Critical Section 구조체는 Restore 되어도 변하지 않습니다.

그대로 남아있다는 소리죠.

그런데 해당 구조체가 가리키고 있는 _RTL_CRITICAL_SECTION_DEBUG 구조체는 

Restore 되면 Snapshot 될 때의 상태로 돌아가게 됩니다.

즉 , InitializeCriticalSection이 호출되기 전 상태로 돌아간다는 말입니다.

여기서 문제가 일어납니다.

전역 변수를 참조해보았을때 , 이미 Initialize 된 Critical Section 이 있는 것을 확인됩니다.

이를 사용했더니 실제로는 Initialize 되지 않는 Critical Section 이라는 거죠.

그 포인터가 가리키는 쓰레기 값을 가지고 연산을 했으니 Error가 나는게 당연했겠죠?

여기서 프로그램마다 메모리 값이 다르니 예외가 발생하는 곳도 달랐을 겁니다.

정리하자면, 해당 변수는 정상적으로 Restore 되지 않았는데 가리키는 영역은 Restore 되었다는 거죠.

물론 EnterCritialSection 안에서 나는건 공통적입니다만..

위 사항은 Console 출력 함수에서 적용되는 문제입니다.

Image 영역에 있는 메모리에 있는 변수에 접근하는 모든 것이 문제가 될 수 있습니다.

예를 들면 File Pointer 연산이 있겠죠




 [+] Solution  

 
1.  Snapshot을 찍을때 Image 영역까지 합니다.
 
가장 심플하고 간단하죠.

모든 전역변수도 정상적으로 변경이 되구요

Pedram Amini가 왜 Image 영역을 막아뒀는지는 모르겠습니다만

pydbg를 보면 필요하면 해제하라고 명시되어있습니다.

흠.. 다른 문제가 생길 수 있을지는 좀 더 봐야 할거 같네요.


2. 해당 변수의 snapshot 상태로 직접 돌려준다.

Console 출력 함수들의 경우 해당 Critical Section 영역을 0으로 덮어버리면 알아서 다시 할당하기 때문에

문제가 일어나지 않습니다.

File Pointer의 경우 현재 위치를 가리키고 있는 포인터를 원하는 위치로 돌려주는 식으로 우회가 가능하겠습니다.

좀 번거롭죠. 사용하는 함수마다 이렇게 해 줘야 하는 불편함이 있구요.



3. Image 영역에 쓰는 변수에 접근하지 않는다.

.... 

네 피하면 되는겁니다.

핵심적인 부분만 Snapshot , Restore 합니다. 

지역변수 연산만 한다면 이 방법이 먹히겠죠.

어떠한 수정도 없지만 그만큼 한계가 있는 방식입니다.



<Fig7. 이게 꿈이라고 말하지 말아주세요>

 


Posted by LinkC

2011.05.11 18:34 System

[+] Beginning



약 1년 전에 Google Chrome에서 웹페이지가 로딩 되지 않는 것에 대한 포스팅을 했습니다.

http://linkc.tistory.com/entry/Google-Chrome-Loading-Problem

sandbox 옵션을 사용하지 않으면 해결되는 문제였죠.

그 땐 그런가 보다 하고 넘어갔는데, 최근 다시 그런 문제가 생겨

왜 이런 문제가 일어나는지 , 해당 옵션을 사용하지 않으면 정상적으로 동작하는지

한 번 살펴보기로 했습니다.


[+] Problem



앞서 설명했던 대로입니다.

Chrome을 실행 하면 웹 페이지가 로딩 되지 않습니다.

또 가끔 페이지가 로딩 되더라도 다음과 같은 메세지를 뱉으며 죽어버리기 일수죠.

<Fig1. 크롬이 오류를 내며 죽는 경우>

개발자들의 센스가 보이는 문구네요. 귀엽죠?

<Fig1-2. 귀여워>


크롬을 실행 할 때는 물론, 실행 중에도 간혹 페이지가 뜨지 않는 현상이 발생합니다.


[+] Analysis


 

1. Session 및 Desktop의 생성

크롬은 Sandbox 기능을 사용하고 있습니다.

다음은 실제 크롬을 막 실행 시킨 직후의 모습입니다.


  <Fig2.  메인 크롬 Process의 WindowsStation>



크롬은 각 탭 하나마다 새로운 자식 프로세스를 생성하며, 탭 이외에도 Plug in 이나 확장프로그램을 사용하면 하나씩 늘어납니다.

<Fig2>를 찍을 땐 , 모든 확장 프로그램을 작동 중지한 상태에서 찍어서 2개만 떴지만, 실제 사용하는 확장 프로그램을 모두

사용하면 6~7개 정도의 크롬이 등장합니다.

아무튼 <Fig2>를 보면 아시겠지만 크롬의 WindowStation이 WinSta0 이외에도 하나 더 생성되어 있는 것을 확인할 수 있습니다.

WindowStation?

Session의 하위 개념입니다.

Session > Station > Desktop > Process 순으로 보시면 되겠네요.

자세한 사항은 다음 블로그에 상당히 정리가 잘 되어있으니 참고하시면 도움이 될겁니다 :D

http://www.benjaminlog.com/tag/%EC%9C%88%EB%8F%84%EC%9A%B0%20%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%85%98



메인 프로세스는 이렇게 2개가 혼재하고 일반 탭의 자식 프로세스는 가장 하단의 WindowStation인 Service 어쩌구 하는

Station 만 존재합니다.

<Fig3. CreateWindowStation을 호출하여 Station을 만드는 모습 >

이후에 GetUserObjectInformation 을 이용하여

만든 Station의 이름을 가져옵니다.

<Fig4. GetUserObjectInformation을 호출하여 이름을 얻어온 모습. Service ~ >

확인해보면 <Fig2>와 같은 형식을 지닌 것을 알 수 있죠.

이후 호출하는 함수를 따라가보면 다음 함수를 호출합니다.

<Fig5. CreateDesktop을 호출하여 Fig3에서 생성한 Station 내부에 Desktop을 생성한 모습>

sbox . Sand Box 를 의미하는 것이겠죠?

0xD64 는 해당 메인 Process 의 PID 입니다.



2. Process 생성

<Fig6. CreateProcessAsUsesr를 호출하여 Process를 생성하는 모습>

해당 함수를 MSDN에서 살펴보면

<Fig7. MSDN에서 살펴본 CreateProcessAsUser>


CreateProcess 와 다른 점은 첫번째 인자가 추가되었다는 점 하나 뿐입니다.

이 hToken 값은 생성될 User의 Handle값이 되겠죠.

그리고  STARTUPINFO  구조체의 lpDesktop 변수에 앞서 생성해준 Station 과 Desktop 정보가 들어갑니다.

또한 , 바로 실행하지 않고 Suspend 상태로 Process를 생성하구요.

흠. 보통 일반적인 Process를 생성하는 방법과는 약간 차이가 있네요.

이후에 CreateJobObejct 를 통해 미리 생성해둔 Job에

AssignProcessToJobOjbect 를 통해 Fig6에서 생성이 완료된 Process를 Job에 추가시킵니다.

Job은 일련의 속한 Process에게 공통적인 정책을 적용하기 위해 사용한다고만 알아두시면 될 것 같네요.



3. Check Integrity

이 후 메모리의 무결성을 검사합니다.

이 무결성을 통과하지 못하고 문제가 발생한 경우는 제가 확인했을 때 IAT Hooking 이 이루어질 때 였습니다.

[ 다른 경우가 있다면 알려주세요! ]

해당 Hooking을 거는 프로그램이라고 하면 보안 프로그램이나 악성 프로그램정도가 되겠죠.

Sandbox 내에서 생성된 탭은 일반적인 방법으로는 Hooking 이 되지 않기 때문에

[ 물론 외부 Process와 통신이 필요한 tab은 Sandbox로 생성하지 않습니다. 그런 tab은 Hooking 이 걸리게 되죠. ]

부모, 자기 자신의 Process만 검사하는 것으로 보입니다.

체크후에는 VirtualAllocEx를 통해 Sandbox에 생성한 Process의 메모리에 접근합니다.

제가 확인한 경우는 2가지 입니다.

첫번째는 VirtualAllocEx에서 해당 Process로 접근 하는 메모리에 권한을 주지 않는 방법으로 차단하는 경우,

두번째는 특정 함수를 선택하고  ReadProcessMemory 를 이용하여 Hooking이 되었는지 여부를 확인하고 차단 하는 경우


입니다.

2가지 프로그램 밖에 테스트 해보지 않았지만 다른 것도 비슷할 것으로 보입니다.




4. Terminate Process Or Resume Process

3번의 Integrity 를 통과하지 못하면 Process를 Terminate 합니다.

Terminate Process가 실패하면 GetExitCodeProcess을 통해서 Process를 종료하구요.

뭐 통과를 하게 되면 생성해둔 Process를 다시 동작시킵니다.



5. Conclusion

<Fig2>를 보면 아시겠지만 크롬은 최소 Process가 2개 입니다

하나는 부모 Process , 하나는 탭에 할당된 Process죠.

부모는 다른 Station에서 실행되고 있는 Process를 Control 하는 역할을 하게 되고

실제 페이지를 뿌려주는건 자식 Process 입니다.

만약, 3번 Check를 통과하지 못했다면 결과적으로 남는 것은 부모 Process 하나 뿐입니다.

이렇게 되면 페이지를 탐색할 자식 Process가 없는 꼴이 되니 정상적으로 실행 될 수 없다는 겁니다.

이해 되시나요?

물론 Plug in 이나 확장 프로그램도 모두 실행이 안되더군요.





[+] Solution



정리하자면

1. IAT Hooking을 거는 특정 프로그램을 종료시킨다.

2. [ 위 Hooking을 거는 Process가 사용자 권한일 경우에 한함 ] 크롬을 관리자 권한으로 실행시켜 Hooking을 못 걸게 한다.

3. 크롬에 --no-sandbox 옵션을 줘서 실행한다.



정도가 되겠습니다.

해당 문제 때문에 크롬을 못쓰는 분들이 해결 하시고 잘 사용하실 수 있길 기원합니다 :D


Posted by LinkC

2011.05.03 11:04 Music/Else

아주 간만에 음악 포스팅이군요!

이 영광을 거머쥔 그룹은 인디 밴드 내에서도 상당한 인기몰이중인 국카스텐입니다.

그만큼 실력도 대단한 그룹이죠.

올해 지산 록 페스티벌에도 온다고 하니 기대되네요 :D

1집에 이어 발매한 Tagtraume에 실린 붉은 밭으로 시작할게요

Original과 Acoustic 모두 매력이 있겠지만

저는 Acoustic 버전이 이 곡에 어울리지 않나 싶네요!







 
기쁨을 마셔버린 붉은 천사야

마지막 불꽃으로 떨어져 보자
니가 베어문 농염한 비명속에

벗어버린 허물을 잡고

태양을 만지러 가네
뜨거워진 우리 몸은 조금씩 갈라지고

Come down-
말라가는 나의 뼈는 기억을 잃어가고

Come down-
마지막 불꽃에

망가진 감각에

새가 된 천사에

내 안의 저주의 땅
뜨거워진 우리 몸은 조금씩 갈라지고

Come down-
말라가는 나의 뼈는 기억을 잃어가고

Come down-




다음은 Original 버전입니다

어느 게 더 맘에 드시나요? :D


Posted by LinkC

2011.02.27 15:14 WarGame

Padocon 문제를 기웃거리다 재밌는 문제를 발견했습니다.

Bot은 많이 들어보셨죠?

출동이다 Autobots!



아 이게 아닌가?

아무튼 위의 예시에서도 보셨다 시피

bot은 로봇의 준말입니다.

얼마 전 , 아니 요즘까지도 화제가 되는 있는 좀비 PC의 감염 원인이 되고 있는 녀석들이죠

일단 설치가 되고 나면 Command & Control Server에 접속해서 공격자의 명령에 따르는 착실한 종이 됩니다.

보통 IRC를 이용하여 공격자의 명령을 하달하곤 했는데 

요즘은 Twitter를 이용한 악성 Twit Bot 이 등장했습니다.

이번 문제에서 이용한 것도 Twit Bot 이구요.


[+] Dynamic Analysis


파일을 실행시켜 보면 먼저 hint.jpg 라는 파일이 생깁니다.



<그림1. Hint.jpg>


흠. 기존의 Bot의 구조도와 다르지 않습니다만 명령을 전달하는 것이 Twitter가 된다는 점이 흥미롭군요.

아무튼 이 hint에 직접적인 답은 없는 거 같고, 현재 Bot이 이런 원리로 돌아가고 있다는 것을 알려주기 위해서 생성된 거 같군요

Bot 이면 분명 명령을 하달하는 어느 Site에 접속을 할 것이고, 이 경우 특정 Twitter에 접속하겠죠.

나가는 Packet을 잡아서 확인해봅시다.


<그림2. Wire Shark 로 Capture 한 Packet>

확인해보면 fuck1224 라는 Twitter 계정으로 접근 하고 있는 것을 확인 할 수 있습니다.

바로 접속해보죠.


<그림3. Fuck1224 계정의 time line>

흠 문제가 쉽게 풀리는거 같군요.

분명 저기있는 알수 없는 문자들 중 하나가 답일 겁니다.

Base64로 Encoding 되어 있는거 같네요. 이걸 Decoding 해보면 답이 쨘!

어때요 참 쉽죠?

[ONL[Y|Dfzce}}D#}`/hfi.o|gg#~~t.abje+n

4J :ZZHIxoe {jecyoom4mstN+_un

}}S#PA|Dfi.ofzce0#

rj: M.KE$U0dph49Vaer}zTw"j7c,?t]#1c

으..으읭?

머리속엔 풰이크다, 이 볍진아 라는 플짤이 반복 재생되고 있습니다.

뭐 이렇게 쉽게 풀릴리가 없겠죠.

아무래도 문제 Binary의 정적 분석이 필요할 것 같습니다.



[+] Static Analysis


이것 , 저것 다 떼고 핵심 함수만 살펴보죠.

해당 Twitter에서 문자열을 받아 이를 Command 로 해석하는 부분을 봐야합니다.

String 을 뽑아내니 어딜 봐야 할지 답이 나오네요.

DOWNLOAD, DDOS, STOP ...

저 함수가 분명 할겁니다.

<그림4. IDA 로 뽑아낸 Binary의 String>

해당 함수를 살펴보면 인자로 Twitter Time line 에 나왔던 문자열을 받는 것을 볼 수 있습니다.

Decoding 하는 함수를 분석 해서 할 수도 있겠습니다만

그냥 인자를 넘겨줄때 저희가 원하는 문자열을 넣으면 되겠죠.

아마 가장 첫번째 문자열일거라고 생각합니다.

해당 문자열을 넣어보면.. 

cmo6IE0uS0UkVTBkcGg0OVZhZXJ9elR3Imo3Yyw/dF0jMWM=



<그림5. 원하는 문자열을 넣고 Decoding 완료 시에 BP로 잡아낸 모습>

저게 답이 겠죠?



[+] Etc



이런식으로 Twitter를 이용해 악성 Bot에게 명령을 내리게 되면

이를 추적하기가 상당히 난해해집니다.

서울에서 Bot에게 명령을 내리든, 부산에서 내리든, 해외에서 내리든 

Bot은 정상적으로 동작하기 때문에 공격자의 위치를 특정하기가 굉장히 어렵다고 하는군요.

Social Network가 한창 인기를 얻어 부상함에 따라 Bot도 유행을 따라 Twitter에 탑승하는군요.

각 AV사에서도 지금 알려진 Twit bot들에 대한 엔진 업데이트를 마친 상태입니다.

보안은 영원한 창과 방패의 대결이랄까요. 



아무튼 요즘 문제시 되는 상황에 맞는 재미있는 문제였다고 생각합니다 :D

출제자 분들에게 박수를! 




Posted by LinkC

2011.02.27 13:36 Web

정말 간만이네요

그동안 정말 바쁘.. 진 않았습니다. 

훈련소 갔다와서 정신 차릴줄 알았는데 잉여력이 더욱 업그레이드 되었습니다.

새 컴퓨터 맞춘다고 이것 저것 알아보다 보니 타임 리프를 경험했네요 

가벼운 주제로라도 포스팅을 하자는 마음에 적습니다. 

네, 제가 잉여력 잠식을 위해 꺼내든 카드는 

함정 카드! 



가 아니라 토르 입니다.



Q. 다음 중 토르를 올바르게 설명한 것을 고르시오

1. 북 유럽 신화에 나오는 천둥의 신으로 올해 영화화가 된 마블의 히어로 중 하나 .

2. 마비노기 영웅전 Episode 7 에서 등장하는 레이드 보스.

3. 스타크래프트2에서 등장하는 테란의 거대로봇.

4. The Onion Routing network 의 약자로 말 그대로 양파형 라우팅 네트워크의 구현.

네, 놀랍게도 정답은 3번..

죽어라 토르!



이 아니라 4번입니다.



[+] How Tor Works?



본론으로 들어가자면, Tor (토르)는 프록시의 업그레이드 판이라고 보시면 됩니다.

Onion Routing Network에서도 짐작 할 수 있지만, 양파처럼 까도 까도 또 Routing 되는 네트워크 시스템이라고 이해하시면 쉽겠죠.

대표적인 Tor 다음은 Tor Project의 사이트입니다

https://www.torproject.org

먼저 Tor의 동작 방식을 살펴보도록 하죠


How Tor works
<그림1. Client가 Directory Server로부터 Node list를 받아오는 모습>

Tor circuit step two
<그림2. Client 가 데이터를 전송 하는 모습1 >


Tor circuit step three
<그림3. Client가 데이터를 전송하는 모습 3>


먼저 Client 가 Directory Server로 부터 Node list 를 받아옵니다.

그리고 해당 List 에서 Node를 랜덤으로 뽑아 데이터를 보내는 거죠.

이 때 일정 시간이 지나면 Data Path는 또 달라지게 됩니다.


[+] Why We use Tor?


지금까지 Tor가 동작하는 방식을 보았습니다.

Tor를 사용함으로서 얻을 수 있는 이점은 뭐가 있을 까요?

1. Anonymity

<그림4. https://check.torproject.org 를 통해 Tor 사용여부를 체크한 모습. 실제와 다른 IP가 찍힌 것을 볼 수 있음.>

Tor를 사용하는 가장 큰 이유중 하나인 익명성입니다.

언제든지 원할때 마다 New Identity를 이용해 IP를 변경할 수 있죠




2. Encryption

위 그림3을 참조하시면 각 Node간에는 암호화가 적용 되어 있는 것을 확인할 수 있습니다.

중간에 Data를 가로채더라도 평문으로 드러날 일은 없다는 것이죠.

하지만 Tor의 이 안정성엔 다소 문제시 되고 있는 점이 있는데요. 그림을 잘 보셨다면 금방 눈치채셨을 겁니다.

이 건은 뒤에서 다루도록 하겠습니다.


3. Hidden Service

다소 부가적인 기능입니다.

Tor 사용자만 이용할 수 있는 말그대로 Hidden Service죠.

Tor hidden service step six
<그림5. Tor가 제공하는 Hidden Service의 동작 원리>


이를 이용하면 해당 Service를 제공하는 Server의 IP는 알 수 없게 됩니다.

즉,  DDOS 등의 공격에도 노출되지 않는 이점을 가지게  되는 거죠.

문제는 Tor 사용자만 이용할 수 있으며 DB Server가 뚫리면 그대로 노출된다는 점이겠죠.

아래의 링크에 접속을 시도해 봅시다.


일반적인 브라우저는 해당 링크에 대한 정보가 없으므로 접속 할 수 없습니다만

Tor Plugin 을 사용하고 있는 전용 브라우저라면 다음과 같이 정상적으로 페이지를 로딩하게 됩니다.



<그림6. Tor Plug in 을 사용한 Fire Fox로 해당 Hidden Service를 이용한 모습>



4. Just Free!

네 , 공짭니다.

무슨 말이 필요한가요.

게다가 자신이 원한다면 자발적으로 Tor의 전송 Node가 되는 것이 가능합니다.

이용자가 늘어날 수록 잠재력은 높아지는거죠. 물론 그냥 쓰는 사람이 배는 많겠습니다만..


5. ETC

요즘 스마트폰 사용자가 급증하면서 무선 인터넷의 취약성이 수면위로 떠올랐고

좀 더 안전하게 이용할 수 있는 방법이 제시되었습니다.

[##_http://linkc.tistory.com/script/powerEditor/pages/1C%7Ccfile9.uf@19604F3F4D69BAF313BB81.PNG%7Cwidth=%22589%22%20height=%22351%22%20alt=%22%22%20filename=%22%EC%BA%A1%EC%B2%98.PNG%22%20filemime=%22image/jpeg%22%7C_##]
<그림7. Tor의 Android App Version. Orbot >



그 중 하나가 Tor고 이런 저런 이유 덕으로 요즘 인기 몰이 중입니다.


<그림8. 꾸준히 유저가 증가하고 있는 Tor>



[+] Weakness of Tor


Tor가 인기를 얻고 있긴 합니다만 다른 사람이 쓴다고 해서 무작정 쓰는 일은 없어야겠죠.

Tor가 가진 문제점을 알아봅시다.

1. Untrustworthy Tor Operator

앞서 말씀 드렸다시피 Tor에서는 자신이 원하면 Tor Network 의 한 Node가 될 수 있습니다.

Node가 되어 전송하다보면 자신이 마지막 Exit Node가 될 수 있죠.

Exit Node에서 최종 목표까지 가는 바로 그 Link는 암호화 되지 않았다는 걸 기억하시나요?

만약 악의를 가진 해커가 이를 가로챈다면 Packet의 Data는 그대로 노출되고 말죠.


<그림 9. Tor Network의 가장 큰 문제점으로 지적되는 것>


결국 위와 같은 상황을 방지하려면 별도로 암호화가 되어 있어야 되는데 이는 Tor의 목적성을 하나 잃어버리는 것이나 마찬가지입니다.



2. Speed 

전세계에 뻗친 여러개의 Node, 그것도 일반 사용자를 거치다 보니 

속도가 제대로 나올 턱이 없죠.

이를 높이려는 노력은 하고 있지만 글쎄요, 아직은 그 효과를 못보고 있는거 같군요.



3. Tor Block Lists

몇몇 웹 사이트와 Service 에서는 Tor를 사용하는 유저들을 제한하고 있는 모양입니다.

Tor를 사용하는 사람들이 일반적으로 악의적인 목적을 가지고 이용하기 때문일까요?

뭐 이는 Proxy, VPN 등에서도 직면하고 있는 문제점으로 보입니다.






[+] 마치며



지금까지 Tor에 대해 살펴보았습니다.

Tor는 기존에 있던 VPN과 서로 간의 장단점 때문에 말이 많은데요.

속도, 신뢰성 면에서는 VPN에게 밀리고 있는 모습을 보여주는 데다가

Free 로 이용할 수 있다는 점도 다른 무료 VPN 덕분에 그렇게 내세울 만한 점은 되지 못하는거 같습니다.

[ 물론 대부분의 무료 VPN은 1일/30일이 데이터 사용량에 제한등을 두고 있습니다. ]

하지만  굉장히 자유로운 IP의 유동성 ,사용자가 직접 Tor Network에 참여할 수 있는 확장성 , 그리고 앞으로의 잠재성 등을 생각해본다면

쉽게 무시할 만한 기술은 아니라고 보여지네요.




P.S 다음 링크에서는 무료 익명 서비스들을 소개, 비교하고 있으니

한번 들어가셔서 자신에 맞는 서비스를 찾아보시는것도 좋겠습니다 :D





'Web' 카테고리의 다른 글

Why grid of webhard is so bad?  (3) 2012.09.21
What is Tor?  (2) 2011.02.27
ASP.NET Padding Oracle Attack!  (2) 2010.10.13
I`m on a Chrome!  (0) 2010.09.13
웹브라우저의 춘추전국시대?  (0) 2010.09.13
Catching temporary I.E Files -IE 임시 파일 가로 채기  (5) 2010.08.24
Posted by LinkC

2010.12.14 01:01 Etc../잡담

네 , 논산 훈련소에 다녀왔습니다

그렇게 힘들지도 않고 재밌게 한달간 지내다왔..

다고 하면 거짓말 같겠죠?

뭐 다 할만했는데 한달간 외부랑 완전히 차단된다는게 

좀 힘들었던 것 같습니다



아, 12월 넘어가니까 무진장 추워졌던 점도 추가하고 싶네요 

아침에 하는 알통구보는 빅추위 으엌ㅋㅋ 

뭐 중간에 연평도 사건도 터지고 이런 저런 일 있었던 것 같네요

글도 정말 간만에 씁니다

나와서 처음 컴퓨터 앉았을 때 잡는 마우스는 뭐 이리 어색했던지 ㅋㅋ

아무튼 나와서 컴퓨터에 앉은지 1시간만에 완벽 적응하고 한달 전으로 다시 돌아온 느낌입니다

한달이 통째로 사라진 느낌?

네, 머리와 함께 말이죠

크흐흨흐흨흨ㅎ ㅠ,.ㅠ


뭐 훈련소 갈 때 챙겨가야 할 건.. 다른 곳에도 많이 나와있겠습니다만

제가 느끼기로는

샴푸, 스킨, 로션 이정도에

깔창 [ 저 같은 경우 전투화에 이미 깔창이 있어서 산 깔창은 한번도 안쓰고 가져왔습니다 =,.= ]

시계 [ 사긴 했는데 쓸데가 없더군요. 불침번 할 때 어느 정도 필요하긴 합니다만.. ]

핸드크림총기나 그런것들을 많이 만져서 그런지 손이 많이 건조해집니다. 챙겨가시는게 좋아요 ]

밴드 및 연고 [ 잔 상처가 나기 쉬운데 가져가면 분대원들에게 사랑 받으실 수 있습니다 ]

변비약 [ 많은 사람들이 변비에 시달리더군요. 사실 거기 가서 달라고 하면 얻을 수 있습니다 ]

사탕 [ 정말 단 거 많이 먹고 싶습니다 ㅋㅋ 사실 들어가기 전에 소지품 검사를 하긴 하는데, 자세히는 하지 않거든요. 챙겨가면 좋습니다 ]



밴드 및 연고, 변비약, 사탕등은 뭐 가져가면 좋아요 

뭐 이밖에 팔꿈치 보호대, 물집 방지 하는 것들  등등 많이들 가져갑니다만

위에 것들에 비해 좀 필요성이 많이 떨어집니다

물론 있어서 나쁠건 없습니다만 후에 처리하기가 귀찮죠..




그리고 가서 읽을 책! 

주말이나 틈틈히 읽으실 책을 들고 가시면 매우 좋습니다 

물론 훈련소에서도 읽을 책은 있지만

여유시간이 의외로 많습니다

위의 물품들 빼곤 모조리 가방을 책으로 채우고 싶을 정도로 말이죠

왜 주위에서 책 챙기란 말을 안했는지 모르겠네요 -.-

아무튼 제가 다녀온 곳은 한 주에 2-3권 읽을 시간 정도는 충분했던  것 같습니다

물론 청소라던가 이것저것 시키기 시작하면 정말 한페이지 읽을 시간도 없긴 합니다만 ㅋㅋ

아무튼 몇 권 챙겨가시면 후회하시는 일은 없을 겁니다


핸드폰 같은 경우는 한달간 방치하니까 배터리를 풀로 충전해서 가시던가, 

여분의 배터리를 하나 챙기시는걸 추천합니다


뭐 이정도면 될 것 같네요

훈련소 생활은 그렇게 어렵지 않을 겁니다

서로 계급이 같은데다가 같은 상황인지라 서로 사람 대하기가 참 쉽거든요

정말 다양한 사람들이 있고 .. 재밌습니다.

지루하진 않을 거에요 ㅋㅋ


그밖에 훈련소 질문 사항이 있으시면 언제나 문의하셔도 됩니다 :D





어.. 그리고 

요즘 참 지르고 싶은 물건들이 많이 보이네요

스마트폰이라던가.. SSD 라던가...

저의 지름신은 

먹을 거라던가 옷보다는 전자기기를 사랑하나 봅니다

문제는 이것들 가격이 정말 만만치 않다는 점인지라 지름신도 섣불리 덤벼들지 못하는 상태랄까 -.-

한달 평균 3만원도 안내는 핸드폰 약정 까지 끊고 [ 아직 1년 가까이 남았는뎅.. ]

5-6만원씩 내면서 스마트폰 사긴 좀 그래서 말이죠~

요즘은 2년 약정에 3.5면 그럭저럭 괜찮은 스마트폰을 구입할 수 있는 것 같던데

유심히 잘 살펴봐야겠어요

그런데 윈도우7 폰도 한번 만져보고 싶고~

고스펙 폰도 써보고 싶고~

이래저래 고민이 많습니다


SSD는 아래 동영상을 봤을 때가 참 쇼크였죠



이게 벌써 1년도 더됐습니다

그 때 당시 가격도 쇼크였습니다만..

요즘은 가격 많이 내렸더군요

64기가가 현재 15만원 정도 할겁니다

120기가가 28만원 정도 하구요

흠.. 기본 OS에 여러 프로그램을 깐다고 했을 때

동영상이나 음악 파일들은 일반 하드에 넣는다고 가정을 해고

64기가는 좀 작아보이고..

120기가는 또 커보이고..

게다가 가격도 만만치 않고.. 이거

80 - 120 기가가 좀 더 싸지면 그 때 구입을 해야 겠어요



아무튼 이정도로 글을 마치겠습니다

복귀도 했겠다 , 다시 글 열심히 포스팅 해야겠습니다!






Posted by LinkC

2010.10.13 14:05 Web

매우 많이 참조 , 및 그림 출처 : 



위 두 사이트들은 Padding Oracle Attack에 대해 상당히 자세히 , 깔끔하게 설명해주고 있습니다. 

현 포스팅은 제가 위 사이트에서 이해한 방식을 정리한 것임을 밝혀둡니다.



몇 주 전, ASP.NET의 취약점이 알려지면서 전세계 사람들의 이목을 모았습니다 [ 저는 몰랐다는게 에러 =,.= ]

beist님의 글을 보고 비로소 알았죠


<그림1. beist 님이 뽑은 올해 최고의 버그>

ASP.NET이 얼마나 많이 쓰이고 있는지 알고 계시다면 beist 님의 말이 와닿을 겁니다.

웹 상에 떠돌아다니는 수 많은 페이지가 바로 맛있는 먹잇감으로 변하는 순간이니까요.

골라 먹는 재미가 있을 정도로 많다 그말입니다.


<그림2. 취약 사이트를 골라드실 수 있어요 :D>

보안 뉴스에도 뜨고 이제 어느 정도 알만한 사람들은 다 아는 그런 상태가 되었습니다.

MS에서도 부랴부랴 보안 패치를 내놓았고, 현재 대형 사이트 정도는 패치가 된 상태입니다.

자세한 MS 보안 공지 사항은 아래를 참조하세요.


현재 상황을 알아보았으니, 이제는 어떻게 이런 취약점이 공격에 성공하는지 알아볼 차례입니다.

사실 이번 공격은 02년도에 이미 알려진 기법을 응용한거라고 하더군요.

아무튼 이번 공격명부터 살펴보겠습니다.

ASP.NET Oracle Padding Attack 

사실 처음 들었을 때 , ASP.NET과 오라클 [ DB ] 간의 상호 연동 중 취약점이 발견된 것인줄 알았습니다.

사실 그렇게 되면 타겟팅 범위가 상당히 줄어들어버리기 때문에 

왜 다들 그렇게 큰일이라고 하는지 몰랐죠.

하지만 여기서 오라클은 DB 관리 시스템이 아니라

<그림3. 많은 이들의 사랑을 받고 있는 DB 관리 시스템 중 하나. oracle >

이 분입니다.


<그림4. oracle 의 정체는 이렇..?>

.......

매트릭스에서 오라클이 맡은 역할을 생각해보면 전혀 상관 없는건 아닙니다.

아니, 애초에 워쇼스키 형제는 이때문에 오라클이라는 이름을 가져온거겠죠.

바로 이겁니다.



신탁 기계 [ oracle machine ] . 판정 문제를 연구하는데 사용하는 추상 기계로... 


ASP.NET oracle Padding Attack 란

Padding 이 올바르게 되었는지를 Oracle 을 통해 판단하여 ASP.NET을 공격하는 그런 방법인겁니다

앞으로 나올 내용까지 생각해서 말씀드리자면 여기서 신탁이라는 건 그냥 응답입니다. 네 별거 없죠.

ASP.NET 시스템에서는 Padding 이 올바르게 되었는지 여부에 따라 응답이 다르게 오게 됩니다.

이것으로 판단을 해서 공격을 성공시키는거죠.

어때요. 참 쉽죠?

사실 이 공격을 구체화시켜보면 밥 아저씨가 그림 그리듯이 마냥 쉬운건 아닙니다


<그림5. 어때요. 참 쉽죠?>



[+]Padding Oracle Attack의 공격 원리


서두가 너무 길어졌네요.

공격 방법에 대해 알아봅시다.

제가 앞서 언급했다 시피, 이 공격의 핵심은 Padding과 서버에서 오는 응답에 있습니다.

ASP.NET의 경우 암,복호화 Block 암호화 기술을 사용하게 되고 , 이 Block 암호화 기술들은

Block 단위로 연산이 이루어지기 때문에, Size가 부족하면 그 만큼 채워넣으며 이를 Padding 이라 합니다.

우리가 앞으로 살펴보고자 하는 예제는 3DES 암호화를 이용하고 있습니다

자세한 설명은 생략... 이 아니라 다음을 참조하세요



보시면 Block Size 는 64bit , 즉 8 byte 입니다.

이 점 유의하면서 계속 보도록 하죠.

1 Block의 내용이 부족하다면 이를 채워 넣고 , 이 채워넣는 과정을 Padding 이라고 한다고 했습니다.

PKCS#5 에는 이와 같은 Padding 규약이 언급 되어있는데요.

바로 남은 N byte 를 N 으로 채운다는 것입니다.

다음 그림을 보면 이해가 쉽겠네요.



<그림6. PKCS#5에 명시된 Padding 규칙>

공격도 이 규칙을 따라 진행됩니다.

String의 길이는 저장이 되지 않기 때문에 이는 가변적으로 변할 수 있습니다.

N이 N개만큼만 있으면 OK 라 이거죠.

여기서 확인하는게 서버로부터의 응답입니다..

Padding이 올바르면 200 ,



 올바르지 않다면 500 을 리턴합니다.



Padding Oracle Attack의 의미가 이제 와닿나요?

Padding 값을 Brute Forcing 하면서 200 응답을 내는 지점을 찾으면 됩니다.





[+]Padding Oracle Attack의 목적정의



예제 평문과 암호화된 값, 암호화 방식은 다음을 참고하세요.

<그림7. CBC 모드의 3 DES 암호화 모습>

그러니까 전체 암호화된 값은 다음과 같은 형태로 우리들에게 제공 됩니다.


http://sampleapp/home.jsp?UID=7B216A6951170FF851D6CC68FC9537858795A28ED4AAC6

우리에게 주어지는건 3Block 짜리 24Byte 뿐입니다. 

그림7에서 나타난 것과 달리 평문도 , Intermediary Value 값도 알지 못합니다. 

이 공격에서 우리가 목적으로 하는 것은 무엇이죠?

바로 원하는 값을 암호화 시키거나 평문을 구하는 것입니다.

이러한 목적을 위해서 Intermediary Value 값을 구하는 것은 필수 불가결 합니다.

고로 Intermediary Value 값을 구하는게 우리에게 가장 선행되는 일이라는 거죠.

이 값을 구해야 우리가 원하는 값으로 암호화 하는게 가능하겠구요.





[+]Padding Oracle Attack을 통해 
 Intermediary Value 구하기



 여기서 조금 전에 설명드렸던 Padding 의 성질을 이용하면 다음과 같은 IV 값을 얻을 수 있습니다. 

<그림8. Padding 된 1Byte 값을 통해 Intermediary Value 1 Byte 를 알아낸 모습>

길이가 7Byte인 Block은 0x01으로 1Byte 만큼 Padding 됩니다.

우리는 IV 값을 모르지만 Brute Forcing 을 통해 HTTP 응답코드가 200이 나올 때 까지 집어 넣어 확인 할 수 있죠.

이렇게 확인한 값이 0x3c라 이겁니다.

위 그림에서는 Intermediary Value 값이 나와있지만, 사실 우리는 Triple DES 의 Key 값을 모르는 상태이기 때문에 

Intermediary Value 값을 구할 수 없었고, Padding Oracle Attack 을 통해서 비로소 구할 수 있었던 거죠.

서버에서는 평문의 길이를 기억하고 있지 않으며, 오직 Padding 값이 규칙에 따라 채워넣어져 있는 것인지 만을 체크합니다.

그래서 다음과 같이 8byte 모두 Padding 되어 있는 경우를 가정하여 Intermediary Value 8 byte 값을 모두 구할 수 있는 겁니다.

<그림 8. 8byte 가 Padding 되어 있다고 가정하여 Intermediary Value 8 byte를 모두 구한 모습>





[+] 
 Intermediary Value 로 원하는 문자열 암호화 하기 


앞서 말씀드렸다 시피 우리는 Key 값을 모르기 때문에 3 DES 를 통해 원하는 문자열을 통해 암호화 할 수 없습니다.

하지만 이미 암호화된 문자열을 IV로 조작함으로써, 원하는 대로 복호화 되도록 설정 할 수 있죠.



<그림9. IV 값을 조작하여 원하는 값을 암호화 한 모습>

여기서 유의할 점은 Block 암호화 방식을 사용하기 때문에, N-1 Block 이 N번째 Block에 영향을 준다는 점입니다.


<그림 10. CBC 모드의 복호화 방법>


그러니까 원하는 문자열을 암호화 하기 위해서는 가장 마지막 Block 부터 조작을 해나가야 한다는 겁니다.






[+] 
 
Padding Oracle Attack 예제 영상 




첫번째 영상은 암호화 되어 있는 ScriptResource 인자 값에 Web.config를 암호화 시킨 값을 집어 넣어 Web.config 파일을 

받아 볼 수 있는 장면을 담았습니다.



다음은 좀 더 실질적인 공격 모습을 담고 있는 영상입니다.

특정 사이트의 쿠키 구조를 파악한 뒤에 관리자 권한을 나타내는 문자열을 암호화 시켜 인증을 통과한 후, webshell을 올려 

시스템 권한을 얻어 낸 모습입니다.

정말 흥미롭군요!


[+] 
 
Padding Oracle Attack 방어 방법  

공격 방식을 생각해보면 방어방법이 아주 까다로운건 아니라는걸 알고 계실겁니다.
말그대로 판단을 못내리도록 하면 되죠. 잘못된 신탁 [ oracle ]을 내려주면 되는 겁니다.
이 방법으로 제시된 것이 
ResponseRedirect 기능을 사용하여 custom error페이지로 Redirect 하는 방법과
응답 시간에 랜덤한 시간 텀을 두고 응답하는 겁니다.
응답 시간에 랜덤한 시간 텀을 두는게 어딜 봐서 Padding 공격을 막느냐 하는 의문을 가지실 수 있는데
제가 언급한 전자의 방법을 쓰더라도, 응답 시간을 체크하면 이를 구분 할 수 있기 때문에
후자의 방법도 함께 써야 한다는 겁니다. 

이렇게 응답시간을 체크하여 구분 짓는 것은 Side channel attack 에서 Timming attack 에 속합니다.
brute forcing 하거나 알고리즘의 이론적인 취약점이 아닌
응답에 걸리는 시간, 파워 소비량 등을 계산하여 취약한 점을 발견해 내는 것을 side channel attack 이라 하며
이에 대한 자세한 설명은 다음을 참고하시길 바랍니다.
실제로 Troy hunt 가 이에 대한 실험을 했고, 결과는 다음과 같습니다.

<그림11. 응답 코드에 따른 반응 시간>
빨간색이 올바르지 않은 Padding 을 했을때, 파란색이 올바른 Padding 을 했을 때의 응답을 나타냅니다.
또한, 각 응답마다 랜덤한 시간만큼을 추가하는 조치가 취해지면 결과는 다음과 같이 변합니다.

<그림12. 랜덤한 텀을 준 후의 응답 시간>
자세한 결과는  Troyhunt의 포스팅을 참조하시길 바랍니다. 좋은 자료들이 많네요

[+] 
 마치며 


이런 분이 많을 거 같아 3줄 요약 하자면
1. Padding 이 올바른지 여부를 HTTP 응답 코드로 알 수 있음.
2. 응답 코드를 통해 맞을 때 까지 brute force , 알아낸 
 Intermediary Value 로 원하는 문자열 암호화
3. 응답 코드를 Redirect 하고 응답 시간을 조절함으로써 방어 가능.



혹시 자신이 관리하는 페이지가 취약한지 알고 싶으신분은

다음 사이트를 이용해서 확인하시길 바랍니다.

http://paddingoracletest.com/



참조 , 및 그림 출처 : 





'Web' 카테고리의 다른 글

Why grid of webhard is so bad?  (3) 2012.09.21
What is Tor?  (2) 2011.02.27
ASP.NET Padding Oracle Attack!  (2) 2010.10.13
I`m on a Chrome!  (0) 2010.09.13
웹브라우저의 춘추전국시대?  (0) 2010.09.13
Catching temporary I.E Files -IE 임시 파일 가로 채기  (5) 2010.08.24
Posted by LinkC

2010.10.09 17:46 Music/Linkin Park


이번에 MV 발표된 곡입니다

정말 상당한 연출력이네요

Joe Hahn은 그룹의 멤버면서 이런 연출까지 담당하고 있다는게 정말 대단하네요!

한국인 3세라서  그런지 2분 13초에는 하회탈도 등장합니다 :D






This is not the end, this is not the beginning
Just a voice like a riot rocking every revision
But you listen through the tone and the violent rhythm and
Though the words sound steady, something empty's within 'em
We say yeah / with fists flying up in the air
Like we're holding onto something that's invisible there
'Cause we're living at the mercy of the pain and fear
Until we dead it / forget it / let it all disappear

Waiting for the end to come / wishing I had strength to stand
This was not what I had planned
It's out of my control
Flying at the speed of light / thoughts were spinning in my head
So many things were left unsaid
It's hard to let you go

I know what it takes to move on
I know how it feels to lie
All I want to do is trade this life for something new
Holding on to what I haven't got

Sitting in an empty room / Trying to forget the past
This was never meant to last
I wish it wasn't so

What was left when that fire was gone
I thought it felt right but that right was wrong
All caught up in the eye of the storm
And trying to figure out what it's like moving on
And I don't even know what kind of things I said
My mouth kept moving and my mind went dead so
Picking up the pieces now where to begin
The hardest part of ending is starting again

'Music > Linkin Park' 카테고리의 다른 글

[Linkin Park] Waiting for the end  (0) 2010.10.09
[ Linkin Park ] Faint  (0) 2010.03.25
[ Linkin Park ] In the end  (0) 2010.03.25
[Linkin Park] New Divide  (0) 2009.12.09
Posted by LinkC

블로그 이미지
LinkC

태그목록

Tistory Cumulus Flash tag cloud by BLUEnLIVE requires Flash Player 9 or better.

공지사항

Yesterday42
Today29
Total328,590

달력

 « |  » 2019.5
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

최근에 받은 트랙백

글 보관함


. .