기본 콘텐츠로 건너뛰기

DLL Hijacking

DLL Hijacking

Windows의 높은 시장 점유율이 완벽한 보안으로 연결되지는 않는다. DLL Hijacking이 그 대표적인 예로 비즈니스 어플리케이션에 많은 영향을 미치고 있다.

Windows DLL

DLL(Dynamic-Link Libraries)는 데이터와 실행가능한 코드의 모음이다. 소프트웨어 개발 시 DLL을 이용함으로써 쉬운 소프트웨어 업데이트와 어플리케이션 간의 DLL 파일 코드 공유를 통한 메모리 사용률 감소를 기대할 수 있다.

Windows DLL Search Order

프로그래머들은 종종 절대경로를 지정하지 않고 DLL 파일을 사용하며, 이는 DLL Hijacking을 야기시키는 결과를 가져온다. 마이크로 소프트에서는 다음과 같은 과정을 거쳐 DLL 파일을 찾는다.

Created with Raphaël 2.1.2Directory of the ApplicationCurrent Directory16 bit System DirectoryWindows DirectoryDirectory in PATH value

Principles of DLL Hijacking

우리는 Windows가 DLL 파일을 찾는 방식을 통해서 DLL Hijacking을 이해할 수 있다. 예를 들어 어떤 어플리케이션에서 function.dll파일이 필요한 데 절대경로가 지정되어 있지 않다면, 악의적인 사용자가 function.dll파일이 위치한 경로보다 우선 순위가 높은 곳에 자신의 DLL 파일을 위치시켜 악의적인 코드를 실행시키게 할 수 있다.

Finding DLL Hijacking Vulnerabilities

DLL Hijacking을 찾는 좋은 방법은 Process Monitor를 활용하는 것이다. 프로그램을 실행 시 Process Monitor를 이용하여 절대경로를 지정하지 않고 불러오는 DLL 파일이 존재하는 지 확인한다.

  • Process Monitor 적용 필터
    • Operation is QueryOpen Include
    • Process Name is [검증 프로그램] Include
    • Path contains .dll Include

만약 검증 프로그램에서 DLL Hijacking 취약점이 존재한다면 다음과 같은 결과를 볼 수 있다.

Path Result
C:\Windows\System32\vuln.dll NAME NOT FOUND
C:\Windows\System\vuln.dll NAME NOT FOUND
C:\Windows\vuln.dll NAME NOT FOUND

Process Monitor에서 이러한 결과가 나타나는 경우 대부분이 DLL Hijacking 취약점이 존재한다.

Finding function names from a DLL

DLL Hijacking을 통하여 위조한 코드를 실행하기 위해서는 먼저 함수 명을 알아야한다. 이는 DUMPBIN 프로그램의 EXPORTS 옵션을 이용하면 할 수 있다. 다른 방법으로는 디버거를 이용하여 저장된 평문 문자열을 확인하는 것이다.

Writing DLL exploits

이제 DLL Hijacking을 활용해보자. DLL에서 코드를 읽을 때 수행하는 절차가 있다.

  • Load DLL
DLL_FILE = LoadLibrary("test.dll");
  • output_text 함수 실행
output_text = (DLLPROC)
GetProcAddress(DLL_FILE, "output_text");
  • DLL 코드
void output_text()
{
    cout << "ALL is going well!\n";
    return;
}

test.dll파일이 Windows 디렉터리에 위치한다고 가정하고 프로그램에서 test.dll의 절대경로를 지정하지 않고 불러와 output_text 함수를 사용한다면 다음과 같은 결과를 볼 수 있다.

All is going well!

이제 동일한 함수명을 가진 test.dll DLL 파일을 생성해보자.

void output_test()
{
    cout << "Something's not right here!\n";
    return;
}

만약 생성한 파일을 프로그램과 같은 위치에 저장하고 프로그램을 실행한다면 Windows 디렉터리에 저장된 test.dll파일 대신에 새로 생성한 DLL 파일을 불러와 실행하게 된다.

Attacking a victim remotely

많은 사람들이 원본 DLL 파일을 교체하여 공격하는 취약점으로 DLL Hijacking을 생각하기 쉽다. 하지만 목표하는 대상의 컴퓨터에 DLL 파일을 저장하는 것은 간단한 일이 아니다. 다음은 소셜 엔지니어링을 활용한 두 개의 공격 시나리오이다.

  • 공격자는 텍스트 뷰어 프로그램에서 취약점을 찾았다. 공격자는 아카이브 파일에 악의적인 DLL파일과 텍스트 파일을 넣는다. 희생자는 텍스트 파일을 열기 위해 아카이브 파일을 다운로드 받고 압축을 풀게 된다. 아카이브 프로그램은 취약한 텍스트 뷰어의 위치에 압축을 해제한다. 텍스트 뷰어는 공격자의 DLL에서 함수를 읽어 실행하게 된다.
  • 공격자는 전자우편 열람 프로그램에서 취약점을 찾았다. 위조한 DLL 파일과 몇 개의 무작위 파일, 전자우편 파일을 회사에서 사용하는 공유폴더에 업로드한다. 희생자가 전자우편을 열람할 때, 전자우편 열람 프로그램은 Windows 디렉터리에 저장된 원본 DLL 파일이 아닌 공격자의 DLL 파일을 불러와 위조된 코드를 실행하게 된다.

Defending against DLL Hijacking

DLL Hijacking 취약점은 라이브러리 사용 시 전체경로를 기입하는 것만으로도 방지할 수 있다. 대안으로 DLL 파일이 위치한 경로를 우선적으로 탐색하는 방법이 있지만 대응방안으로 충분하지 않다. 또 다른 대안으로는 DLL 파일의 체크썸 해시 값 일치 여부를 검증하는 방법이 있다. 추가적으로 사용자 자신이 직접 보호하는 방법이 있다. 예를 들어 사진을 다운받았을 때, DLL 파일이 함께 있다면 DLL 파일을 제거 후 그림 파일을 열람하는 것이다. 그리고 레지스트리 키를 변경하는 방법이 있다.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\CWDIllegalInDllSearch
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\binaryname.exe\CWDIllegalInDllSearch

이 블로그의 인기 게시물

X-Frame-Options-Test

X-Frame-Options 테스트하기 X-Frame-Options 페이지 구성 시 삽입된 프레임의 출처를 검증하여 허용하지 않는 페이지 URL일 경우 해당 프레임을 포함하지 않는 확장 응답 헤더이다. 보안 목적으로 사용되는 확장 헤더로 아직 적용되지 않은 사이트들이 많지만 앞으로 점차 적용될 것으로 보인다. X-Frame OptionsDENY, SAMEORIGIN, ALLOW-FROM 옵션을 이용하여 세부 정책을 설정한다. 옵션 설명 DENY Frame 비허용 SAMEORIGIN 동일한 ORIGIN에 해당하는 Frame만 허용 ALLOW-FROM 지정된 ORIGIN에 해당하는 Frame만 허용 크롬 4.1 , IE 8 , 오페라 10.5 , 사파리 4.0 , 파이어폭스 3.6.9 이상에서는 DENY , SAMEORIGIN 이 적용되며, ALLOW-FROM 은 각 브라우저 마다 지원 현황이 다르다. https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/X-Frame-Options 해당 확장헤더는 브라우저에서 처리하는 응답 헤더이므로 미지원 브라우저 사용 시 설정과 무관하게 페이지 내 포함된 모든 Frame을 출력한다. (검증 테스트: Opera 5.0.0) 테스트 코드 DENY <!DOCTYPE html> < html lang = "en" > < head > < meta http-equiv = "X-Frame-Options" content = "deny" /> < title > Deny option Test </ title > </ head > < bod

C-lang-vulnerabilities

C 언어 공통 취약점 해당 글은 CERN Computer Security의 Common vulnerabilities guide for C programmers 글을 참고하여 작성하였습니다. C언어에서 발생하는 대부분의 취약점은 버퍼 오버플로우와 문자열 처리 미흡과 관련되어 있다. 이는 segmentation fault를 유발하고 입력 값을 조작할 경우 임의 코드 실행으로 이어질 수 있다. 이에 대부분의 에러와 조치 방안을 살펴보자고 한다. gets stdio gets() 함수는 버퍼 길이를 검증하지 않아 사용 시 항상 취약성을 야기한다. Vulnerable Code #include<stdio.h> int main() { char username[ 8 ]; int allow = 0 ; printf ( "Enter your username, please: " ); gets(username); //악의적인 값 삽입 if (grantAccess(username)) { allow = 1 ; } if (allow != 0 ) { //username을 오버플로우하여 덮어씀 privilegeAction(); } return 0 ; } Mitigation fgets() 함수 사용 및 동적 메모리 할당 #include <stdio.h> #include <stdlib.h> #define LENGTH 8 int main () { char * username, *nlptr; int allow = 0 ; username = malloc (LENGTH * sizeof (*username)); if (!username) return EXIT_FAILURE; printf ( "Enter your username, please:

HTML/CSS를 활용하여 카카오톡 클론 만들기

시간을 내어 HTML과 CSS를 공부한 것은 대학생 때가 마지막이었던 것으로 기억한다. 그 동안 사이드 프로젝트로 진행했던 여러 아이디어들을 결국 서비스하지 못했던 결정적인 이유는 프론트 엔드 기술 부족이었다고 생각하고 우선 HTML과 CSS 학습을 진행하였다. 프론트 엔드 기술은 많은 발전을 거듭하여 예전에 비해 큰 복잡성을 가지게 되었다. 빠른 시간 안에 숙지하지 못한 기법들에 대해서 알아보고 구현하고자 하는 아이디어에 활용할 수 있을 정도로 진행해보고자 한다. 또한 보안적 관점에서 발생할 수 있는 프론트 엔드 위협에 대해 파악할 수 있는 좋은 밑거름이 되길 기대해본다. 우선적으로 진행한 카카오 톡 디자인 클론은 노마드 아카데미의 강의를 수강하며 진행하였고 결과는 아래의 링크에서 확인할 수 있다. 소스코드 저장소 구현된 웹 페이지