서론 지금까지 단순히 ret address를 변조할 수 있는 경우에 대해 공부하였다. 만일 ret address 변조가 아닌 함수 pointer 주소만 변조할 수 있는 경우에는 어떨까. 예를 들면 *input() 과 같은 식으로 실행될 때이다. 이 경우 결국 주소로 jmp하는 것과 같기 때문에 페이로드의 흐름과 rop에 따른 흐름이 일치하지 않는다. 그러므로 이를 일치시켜주기 위한 stack pivoting이 필요하다. 문제 환경 pwnyable 기본 커널로 한다. 1. 환경설정 vmlinux 추출, 분석 및 취약점이 모두 앞과 동일하다. 2023.08.27 - [Kernel Exploit] - kernel - ret2usr kernel - ret2usr 서론 가장 기본적인 커널 익스 기법인 ret2us..

서론 cr4 overwrite 2차전이다. 문제 환경 첨부 환경을 기준으로 한다. 1. 환경설정 1.1. vmlinux 추출하기 앞과 동일하다. ┌[root🐲 Wyv3rn]-(~/kernel/cr4) └> extract-vmlinux bzImage > vmlinux ┌[root🐲 Wyv3rn]-(~/kernel/cr4) └> ls bzImage rootfs.cpio start.sh vmlinux 1.2. 문제 환경 설정 start.sh qemu-system-x86_64 \ -m 512M \ -kernel ./bzImage \ -initrd ./rootfs.cpio \ -append "root=/dev/ram rw console=ttyS0 oops=panic panic=1 quiet nokaslr" \ -..

서론 앞서 공부한 보호기법 설명에서와 같이 SMEP 보호기법은 결국 CR4 레지스터 값에 따라 결정된다. 만일 해당 값을 수정할 수 있다면 보호기법도 해제할 수 있지 않을까? 본론 SMEP은 유저 공간에서의 NX와 같이 실행 권한을 제한하는 방법이다. CR4 레지스터에 SMEP을 제어하는 비트가 있어 이를 0으로 만들거나, 유저 공간의 rop과 같이 krop이 가능하다. 본 글에서는 CR4 overwrite를 기준으로 한다. 1. 환경설정 1.1. vmlinux 추출하기 앞과 동일하다. 1.2. 문제 환경 설정 앞과 동일하다. init.d/S99pawnyable #!/bin/sh ## ## Setup ## mdev -s mount -t proc none /proc mkdir -p /dev/pts moun..

서론 이제 보호기법을 하나씩 추가해보자. 우선은 SMEP이다. 2023.08.20 - [Kernel Exploit] - Kernel 보호기법 및 우회법 Kernel 보호기법 및 우회법 서론 커널 공간도 유저 공간과 마찬가지로 보호기법이 있다. 다행이라면 유저 공간의 보호기법과 대동소이한다는 점. 아직 각 보호기법에 따른 공격법을 공부하지 않았기에 느낌적인 느낌으로 wyv3rn.tistory.com 본론 SMEP은 유저 공간에서의 NX와 같이 실행 권한을 제한하는 방법이다. CR4 레지스터에 SMEP을 제어하는 비트가 있어 이를 0으로 만들거나, 유저 공간의 rop과 같이 krop이 가능하다. 본 글에서는 krop을 기준으로 한다. 1. 환경설정 1.1. vmlinux 추출하기 익히 아는 것과 같이 rop..

서론 가장 기본적인 커널 익스 기법인 ret2usr에 대해서 알아보자. 간단히 먼저 설명하자면, ret2usr는 stack buffer overflow에서 return to shellcode와 같다고 보면 된다. 본론 우선 테스트는 유명한 커널 익스 사이트인 포냐블의 LK01 파일을 기본으로 한다. Holstein 모듈 분석 및 취약성 실행 | 전당포! (pawnyable.cafe) Holsteinモジュールの解析と脆弱性の発火 | PAWNYABLE! Holsteinモジュールの解析と脆弱性の発火 LK01(Holstein)の章ではKernel Exploitの基礎的な攻撃手法について学びます。導入の章でLK01をダウンロードしていない方は、まず練習問題LK01のファイルをダ pawnyable.cafe 압축을 풀어보면 2개의 폴..

서론 gef가 익숙하고 편해서 사용하고 있었으나, 무슨 이유인지 모르겠지만 kernel debuging 시 register, stack, code 모든 영역의 값이 제대로 나오지 않는 문제가 발생했다. 지원은 하긴 할텐데 정확히 이유를 알 수 없어 어쩔 수 없이 pwndbg를 설치하였다. 설치 방법 아래를 차례로 실행하면 끝. git clone https://github.com/pwndbg/pwndbg cd pwndbg ./setup.sh kernel debuging 기본 셋팅 아래 스크립트를 기준으로 실행하면 된다. #! /bin/sh gdb \ -ex "add-auto-load-safe-path $(pwd)" \ -ex "file vmlinux" \ -ex 'set arch i386:x86-64' \..

아무래도 반복적으로 파일 압축 / 해제를 해야할 것 같아서 간단히 shell script를 만들어 보았다. 일부 명령어가 룻 권한으로 실행되어야하기에 미리 root으로 권한을 유저를 변경한 뒤 실행하자. rootfs.cpio 파일과 추가할 파일이 같은 폴더에 있을 때 ./cpio.sh 파일1 파일2 파일3 ... 과 같은 방식으로 사용하면 된다. #! /bin/bash if [ $# -eq 0 ] ; then echo "useage : cpio.sh file1 file2 ..." exit 0 else for var in "$@" do if [ ! -e $var ] ; then echo $var : "file not exist" exit 0 fi done mkdir unzip cp ./rootfs.cpio..

서론커널 공간도 유저 공간과 마찬가지로 보호기법이 있다.다행이라면 유저 공간의 보호기법과 대동소이한다는 점.아직 각 보호기법에 따른 공격법을 공부하지 않았기에 느낌적인 느낌으로 써내려가본다. 보호기법 확인 방법checksec 먹힌다./proc/cpuinfo와 /etc/default/grub 파일을 확인qemu script에 보통 설정되어있음. 제일 좋은건 두번째, 세번째 방법이고cat /proc/cpuinfo | grep flags로 smep, smap/etc/default/grub에서 kaslr을 확인하거나 qemu script에-append nokaslr-cpu smep, smap와 같이 확인 가능하다. 또는 커널 내에서 아래와 같이 확인 가능하다.~ $ cat /proc/cmdlineroot=/de..

앞서 생성한 것과 같이 bzImage는 kernel, rootfs.cpio는 기본적인 파일 시스템의 구조만 가지고 있으며, qemu로 실행 시 rootfs.cpio의 파일들만 나타날 것이다. 그러므로 익스코드 작성 후 해당 익스 바이너리를 rootfs.cpio 파일 내에 넣어줘야한다. cpio 파일 압축 해제 명령어는 아래와 같고 cpio -idv rootfs.cpio 더불어 바이너리는 커널과 파일 시스템 내에 링커가 없기 때문에 -static 옵션을 주고 컴파일해야한다. 또는 base64로 인코딩..

vmlinux 앞선 kernel image build 시에도 언급한 것과 같이 vmlinux는 커널 디버깅에 사용할 여러 주소들과 값들을 가지고 있으며, 보통 CTF에서는 제공되지 않는 경우가 많다. (용량이 커서?!) 그러므로 아래와 같이 추출 가능하다. extract-vmlinux bzImage 파일에서 vmlinux를 추출할 수 있는데, 다음과 같은 명령어로 추출할 수 있다. /usr/src/linux-headers-$(uname -r)/scripts/extract-vmlinux bzImage > vmlinux 다만 추출된 파일에서는 심볼들이 삭제된 상태이지만, objdump, ROPgadget 등으로 ROP을 위한 gadget의 주소는 구할 수 있다.