DLL Injection 의 절대방어는 가능한가




몇년 전까지만 해도 DLL Injection 이 굉장한 해킹 기술 중의 하나였고, DLL Injection 을 구현해서
어떠한 해킹 행위를 하는 것은 존경받거나 추앙받을만한 일이었습니다. 그러나 기술의 발전과
정보의 공유로 요즘은 DLL Injection 이 평범한 대중적인 기술이 되었고, 기본중의 기본 아니 그냥
기초학문 정도로 전락한 것 같습니다. 뭐 한마디로 개나새나 다 하는 기법이 됐습니다.



(이상하게 Injection 이라는 단어는 좋지 않은 의미로 주로 쓰이는 것 같네요. 웹 해킹의
SQL Injection도 그렇고...)


그러나 분명한 건, 대중적인 기술이고 개나새나 초딩도 구현할 수 있는 기법이면서
아직도 그걸 막을 수 있는 획기적인 대책은 아직 나오지 않았다는 겁니다. 이 대목에서
"이사람! DLL Injection 을 방어하는 방법에 대해서 전혀 접해본 것도 없나?" 라고 생각하신
분들 혹시 BaseThreadStartThunk 나 LoadLibraryExW 같은것 말씀하시려는 모양이라면
네 벌써 써봤습니다. 그리고 시원~~하게 뚫려 봤습니다. 라고 하고 싶네요 ㅠㅠ

몇년간 DLL Injection 을 막으려고 오만가지 생각과 오만 짓들을 다 해봤습니다만
해커들은 항상 생각지도 못한 개구멍을 찾아내서 결국은 넣더군요...;; 요즘엔 사실
답이 없다 라는 생각만이 앞섭니다.

제가 겪은 난점은 이렇습니다.
무수히 많지만 공개가능한 수준에서 세가지 정도만 나열해 보겠습니다.


1. DLL Injection 을 방어하는 루틴이 아무리 빨리 등장해도, ( WinMain()의
   맨 윗줄이나 TLS CallBack 에도 넣어봤음) 해커들은 그 루틴이 등장하기 전에
   주입을 함.

2. 보호 루틴을 먼저 띄운후 대상을 로딩해도, 시스템 DLL 을 가장해서 삽입 ;;

3. 다른 DLL 의 Import Table 에 Hacker.dll 을 추가하여 인젝션.

사실 요거 세개의 조합으로만 움직여도 인젝션 그 자체를 차단하는 것은 불가능 합니다.
현업에서 해커들에게 많이 시달려본 분은 이미 아시는 사실일 수도 있겠지만
정말 인젝션 그 자체를 차단하는 것은 영원히 해결되지 않을 난제라고 해도 무리는
아닌 것 같습니다.

그래서 저는 DLL Injection 을 감지/차단 하는 방법은, 사실 논문이나 연구자료 정도
이상으로 써먹기는 힘들다고 생각합니다. 필드에서는 뭐 그걸로 "어느 정도" 의 효용성은
발휘할 지 몰라도 정말 맘먹고 뚫는 해커에겐 소용없는 짓이라는걸 너무 많이 느꼈습니다.

우리가 일반적으로 아는 상식으로는 클라이언트 단에서는 맘먹고 뚫으면 절대 막을 수
없다고 하지만, 실제로 클라이언트 단이라도 정말 맘먹고 막으면 차단이 가능한 영역도
분명히 있습니다. 다만 "DLL Injection 의 절대 방어"는 그 영역이 아니라고 하고 싶네요.


window31. 2009년 9월.


Posted by window31


트랙백 보낼 주소 : http://window31.com/trackback/313 관련글 쓰기

댓글을 달아주세요

  1. 2009/09/01 07:25
    댓글 주소 수정/삭제 댓글
    강본좌가 GG를 치다니. 좀더 힘을 내주게나
    • 2009/09/02 00:12
      댓글 주소 수정/삭제
      강본좌는 뭐지 ㅋㅋㅋ
  2. 2009/09/01 08:28
    댓글 주소 수정/삭제 댓글
    그러게요. 이 바닥에서 절대라는 말은 좀처럼
    찾기 힘든거 같습니다.^^
    그런데 강본좌님이셨습니까?? ㅎㅎ
    • 2009/09/02 00:12
      댓글 주소 수정/삭제
      윗분께서 멋대로 ㅋㅋㅋ
  3. 2009/09/01 17:45
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
    • 2009/09/02 00:13
      댓글 주소 수정/삭제
      하하하 시스템별로 호환 되도록 버전관리하면서 static 으로 넣을 수 있을까 모르겠네요 ㅎㅎ
      너무 잼있게 읽었습니다 ^^
  4. 2009/09/08 21:21
    댓글 주소 수정/삭제 댓글
    좋은글 잘 봤어요~
  5. jinn
    2009/09/09 02:30
    댓글 주소 수정/삭제 댓글
    본좌님께서 GG를 치시다니.. (2)

    저희는 어찌하라고.. ㅠㅠ
  6. 2009/10/13 13:05
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
    • 2009/10/17 01:14
      댓글 주소 수정/삭제
      소용 없습니다. CreateProcess() 이후에 exe 에 우리가 만든 코드가 실행되는 시점은 이미 kernel32.dll 이 로드되어있는 시점이고, 이미 해커들은 인젝션 해 놓은 상태입니다.
    • 2009/10/18 12:19
      댓글 주소 수정/삭제
      비밀댓글입니다
    • 2009/10/22 22:17
      댓글 주소 수정/삭제
      이것 역시 생각해본 방법입니다.
      플랫폼이라는 문제가 발생하므로 사용할 수 없습니다.
      미지의 윈도우 시스템을 사용하는 클라이언트는 상식 이상으로 많습니다.
      그리고 이런 시도를 하게 되면 그런 유저들이 울부짖게 됩니다.
      클라이언트는 너무 다양하네요 정말... 하는것만을 느끼게 했습니다.
    • 2009/10/23 09:02
      댓글 주소 수정/삭제
      그렇군요...
      역시 어려운 문제입니다. :)
      "100% 막을수는 없는 영역"이라는 말씀에는 공감합니다. 예전에 Buffer Overflow나 FormatString 등의 취약점은 100% 막는다는게 가능했지만 리버싱에 대해서는 차단 불가능한 부분이 많은 것 같아요. 그냥 "좀더 뚫기 어렵게 만든다"는 느낌...? ^^
  7. 2009/10/13 13:07
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
    • 2009/10/17 01:14
      댓글 주소 수정/삭제
      그거 예전에 써보고 뚫렸습니다 ㅎㅎㅎ 소용 없으실듯 :)
    • 2009/10/18 10:07
      댓글 주소 수정/삭제
      비밀댓글입니다
    • 2009/10/22 22:19
      댓글 주소 수정/삭제
      네 제가 말씀드리는 것도 후자인데요?
      SetWindowsHookEx 로 집어넣는 넘들 막아봤습니다. 그리고 뚫렸습니다.
  8. 2009/10/19 23:49
    댓글 주소 수정/삭제 댓글
    음... 시스템 DLL을 가장해서 삽입하는 경우는 Cerification 쪽을 검증하면 될 것 같은 느낌이 드네요;; 물론 해당 API가 후킹되어있으면 정말 난감하죠. 결국 DLL Injection 하나라도 제대로 막기 위해서는 모든 프로세스 보호 방법을 총동원해도 무리라는 결론이 나옵니다.
    (그나마 최선의 방어책은 LdrLoadDll을 후킹하고(후킹 설치 루틴은 TLS Callback에 삽입), 실시간으로 후킹 여부를 검증하고, 시스템 DLL이 아닌 것들을 추려내고 등등을 하면 완벽에 가까운 보호는 가능할지도 모르지만요.)

    철학적으로 접근해보면, 실행된다는 것은 해킹될 수 있음을 의미하는 것이니까요... ^^;; 이미 수학적으로 100% 완전이라는 것은 이 세상에 존재하지 않다는 것도 증명된 사실이고;;
    (그건 그렇고 정말 오랜만이네요~~ 요즘 수능 준비하느라 통 바빠서...)
    • 2009/10/22 22:20
      댓글 주소 수정/삭제
      수능준비 하시느라 고생하시는군요 남은 기간동안 홧팅!
  9. ks
    2009/11/15 23:27
    댓글 주소 수정/삭제 댓글
    흠... 할당된 메모리 영역을 모두 찾아내서 검증해보는 방법은 어떨까요?

BLOG main image
by window31

카테고리

분류 전체보기 (281)
Reverse Engineering (21)
C, C++ (20)
Kernel (8)
Guitar (19)
잡담 (77)
etc (8)
who am i (8)
보안 이야기 (88)
Tools (3)
월간 마이크로소프트웨어/그.. (28)

글 보관함