https://gomguk.tistory.com/m/116

 

[Fuzzing 101] 퍼징으로 1-day 취약점 분석하기(GIMP)

들어가며 GIMP라는 이미지에디터를 퍼징한다. GIMP 2.8.16에서 발생하는 CVE-2016-4994을 분석한다. 그리고 발견한 크래시에서 코드 커버리지를 분석한다. CVE-2017-9048은 Use-After-Free 취약점이다. 동적할당

gomguk.tistory.com

들어가며

GIMP라는 이미지에디터를 퍼징한다. GIMP 2.8.16에서 발생하는 CVE-2016-4994을 분석한다. 그리고 발견한 크래시에서 코드 커버리지를 분석한다.

CVE-2017-9048은 Use-After-Free 취약점이다. 동적할당된 heap을 free하고 다시 재사용할 때 취약점이 발생한다. GIMP에서는 조작된 XCF 파일에서 발생한다.

공격자는 유효한 데이터의 손상에서 임의 코드 실행까지 다양한 악의적인 행위를 할 수 있다.

준비

1-day 실습이므로 취약점이 발생했던 같은 환경을 준비한다. 또는 다음의 내용을 학습할 수 있다.

다음의 내용을 학습한다.

  • 퍼징 속도 향상을 위한 persist mode 사용
  • 상호작용바이너리 퍼징 / GUI 프로그램 퍼징

Persist mode

AFL 지속 모드(Persist mode)는 단일 프로세스를 사용하는 퍼저를 기반으로 한다. 퍼저는 하나의 타겟 프로세스에 코드를 주입하여 값을 변조하거나 삽입한다.

afl-fuzz는 프로세스 내 퍼징의 이점과 멀티 프로세스 도구인 지속 모드를 결합한 작업 방법을 지원한다.

지속 모드에서 AFL++는 각 퍼즈 단계 실행을 위한 새로운 프로세스를 생성하는 대신 단일 분기 프로세스에서 대상을 여러번 퍼즈한다. 이 모드는 퍼징 속도를 20배까지 향상시킬 수 있다.

기본 구조는 아래와 같다.

//Program initialization

  while (__AFL_LOOP(10000)) {

    /* Read input data. */
    /* Call library code to be fuzzed. */
    /* Reset state. */
  }
  
  //End of fuzzing

 

Download and Build

1. 대상 프로그램 다운 및 빌드

cd $HOME
mkdir Fuzzing_gimp && cd Fuzzing_gimp
sudo apt-get install build-essential libatk1.0-dev libfontconfig1-dev libcairo2-dev libgudev-1.0-0 libdbus-1-dev libdbus-glib-1-dev libexif-dev libxfixes-dev libgtk2.0-dev python2.7-dev libpango1.0-dev libglib2.0-dev zlib1g-dev intltool libbabl-dev

 

2. GEGL 0.2(Generic Graphics Library)의 설치가 필요하다.

wget https://download.gimp.org/pub/gegl/0.2/gegl-0.2.0.tar.bz2
tar xvf gegl-0.2.0.tar.bz2 && cd gegl-0.2.0
sed -i 's/CODEC_CAP_TRUNCATED/AV_CODEC_CAP_TRUNCATED/g' ./operations/external/ff-load.c
sed -i 's/CODEC_FLAG_TRUNCATED/AV_CODEC_FLAG_TRUNCATED/g' ./operations/external/ff-load.c

 

3. build

./configure --enable-debug --disable-glibtest  --without-vala --without-cairo --without-pango --without-pangocairo --without-gdk-pixbuf --without-lensfun --without-libjpeg --without-libpng --without-librsvg --without-openexr --without-sdl --without-libopenraw --without-jasper --without-graphviz --without-lua --without-libavformat --without-libv4l --without-libspiro --without-exiv2 --without-umfpack
make -j$(nproc)
sudo make install

 

4. GIMP 2.8.16 다운로드 및 압축 해제

cd ..
wget https://mirror.klaus-uwe.me/gimp/pub/gimp/v2.8/gimp-2.8.16.tar.bz2
tar xvf gimp-2.8.16.tar.bz2 && cd gimp-2.8.16/
CC=afl-clang-lto CXX=afl-clang-lto++ PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$HOME/Fuzzing_gimp/gegl-0.2.0/ CFLAGS="-fsanitize=address" CXXFLAGS="-fsanitize=address" LDFLAGS="-fsanitize=address" ./configure --disable-gtktest --disable-glibtest --disable-alsatest --disable-nls --without-libtiff --without-libjpeg --without-bzip2 --without-gs --without-libpng --without-libmng --without-libexif --without-aa --without-libxpm --without-webkit --without-librsvg --without-print --without-poppler --without-cairo-pdf --without-gvfs --without-libcurl --without-wmf --without-libjasper --without-alsa --without-gudev --disable-python --enable-gimp-console --without-mac-twain --without-script-fu --without-gudev --without-dbus --disable-mp --without-linux-input --without-xvfb-run --with-gif-compression=none --without-xmc --with-shm=none --enable-debug  --prefix="$HOME/Fuzzing_gimp/gimp-2.8.16/install"
make -j$(nproc)
make install

Persistent mode

두가지 방법이 있다.

  • app.c 파일을 수정하는 방법
  • AFL_LOOP 매크로를 for 반복 루프 내에 포함시킨다.
if ( filenames ){
gint i;

for(i=0;filenames[i] != NULL; i++){
	if (run_loop){
		#ifdef __AFL_COMPILER
			while(__AFL_LOOP(1000)){
				file_open_from_command_line (gimp, filenames[i], as_new);
			}
			exit(0);

		#else
			file_open_from_command_line (gimp, filenames[i], as_new);
		#endif
		}
  • AFL_LOOP를 xcf_load_invoker 함수 내에 포함시킨다.
--- ../xcf.c	2014-08-20 08:27:58.000000000 -0700
+++ ./app/xcf/xcf.c	2021-10-11 13:02:42.800831192 -0700
@@ -277,6 +277,10 @@
 
   filename = g_value_get_string (&args->values[1]);
 
+#ifdef __AFL_COMPILER
+  while(__AFL_LOOP(10000)){
+#endif
+
   info.fp = g_fopen (filename, "rb");
 
   if (info.fp)
@@ -366,6 +370,12 @@
   if (success)
     gimp_value_set_image (&return_vals->values[1], image);
 
+#ifdef __AFL_COMPILER
+  }
+#endif
+
+  exit(0);
+
   gimp_unset_busy (gimp);
 
   return return_vals;

첫 번째 방법은 다른 입력 형식도 타겟으로 할 수 있지만 두 번째 방법은 xcf만 대상으로 하므로 더 빠르게 버그를 찾을 수 있다.

Seed corpus creation

샘플 xcf 파일을 구해서 AFL input 폴더에 넣는다.

Fuzzing

GIMP 바이너리를 대상으로 한 퍼징이므로 불필요한 플러그인을 제거한다.

rm ./install/lib/gimp/2.0/plug-ins/*

 

Fuzzing!

ASAN_OPTIONS=detect_leaks=0,abort_on_error=1,symbolize=0 afl-fuzz -i './afl_in' -o './afl_out' -D -t 100 -- ./install/bin/gimp-console-2.8 --verbose -d -f @@
  • gimp-console-2.8은 GIMP의 CLI 버전이다.
  • 결정론적 변이 옵션을 허용했다. (-D)
  • 코드에 무한 루프 버그가 있으므로 시간 제한(-t 1000)을 설정해야 한다. 시스템 성능에 따라 다를 수 있기 때문에 적절히 조절한다.

Triage

ASan 트레이스를 지원하므로 크래시가 발생한 파일을 매개변수로 전달하여 실행하면 된다.

'시스템' 카테고리의 다른 글

AFL fuzzer & Exploit  (0) 2022.10.22
AFL Fuzzer  (0) 2022.10.22
Exploiting Null Byte Buffer Overflow for a $40,000 Bounty  (0) 2019.12.26
Pwning VMWare, Part 1: RWCTF 2018 Station-Escape  (0) 2019.12.24
x64 Stack 개요  (0) 2019.12.11
블로그 이미지

wtdsoul

,

 

IOS에서 Application에서 탈옥을 탐지하기 위해서 사용하는 코드의 예시들을 살펴보겠다.

 

크게 2가지로 나눌 수 있다.

1. 탈옥시 생기는 경로가 존재하는지 확인해 탐지하는 방법.
2. 탈옥시 생기는 Root 권한으로만 접근할 수 있는 곳에 접근해 탐지하는 방법.

이외에 추가적인 방법이 존재하긴한다. 밑에서 소개하도록 한다.

 

 

1. 탈옥시 생기는 경로의 존재여부 검사.

(여러 앱을 분석하면서 검사하는 경로를 추가할 예정이다.)

 

(fileExistsAtPath: 함수를 통해서 경로의 존재여부를 판단한다.)

 

(NSArray에 경로들을 쭈욱 넣고 아래와 같은 루틴으로 일치하는게 존재하는지확인한다.)

 

이와 같이 fopen 함수를 통해서도 판단할 수 있다.

 

 

(최신) - *표시한게 현재 내 환경에서 탐지된 경로이다.

/usr/sbin/frida-server 

/etc/apt/sources.list.d/cydia.list  

/etc/apt/sources.list.d/electra.list

/etc/apt/sources.list.d/sileo.sources

/.bootstrapped_electra

/usr/lib/libjailbreak.dylib

/jb/lzma

/.cydia_no_stash 

/.installed_unc0ver 

/jb/offsets.plists

/usr/share/jailbreak/injectme.plist

/etc/apt/undecimus/undecimus.list

/var/lib/dpkg/info/mobilesubstrate.dylib

/Library/MobileSubstrate/MobileSubstrate.dylib

/Library/MobileSubstrate/DynamicLibraries/* 

/jb/jailbreakd.plist

/jb/amfid_payload.dylib

/jb/libjailbreak.dylib

/usr/libexec/cydia/firmware.sh 

/var/lib/cydia/ 

/etc/apt/ 

 

/private/var/lib/apt/ 

/private/var/Users/

/var/log/apt/ 

/Applications/Cydia.app 

/private/var/stash

/private/var/lib/cydia 

/private/var/cache/apt/ 

/private/var/log/syslog/

/private/var/tmp/cydia.log

/private/var/tmp/frida-*.dylib 

/Applications/Icy.app/

/Applications/MxTube.app/

/Applications/RockApp.app/

/Applications/blackra1n.app/

/Applications/SBSettings.app/

/Applications/FakeCarrier.app/

/Applications/WinterBoard.app/

/Applications/IntelliScreen.app/

/Applications/crackerxi.app/ 

/private/var/mobile/Library/SBSettings/Themes

/Library/MobileSubstrate/CydiaSubstrate.dylib

/System/Library/LaunchDaemons/com.ikey.bbot.plist

/System/Library/LaunchDaemons/com.saurik.Cydia.Startup.plist

/var/mobile/Library/Caches/com.saurik.Cydia/sources.list 

 

/usr/sbin/sshd 

/usr/bin/sshd

/bin/bash 

/usr/libexec/ssh-keysign 

/usr/libexec/sshd-keygen-wrapper 

/bin/sh 

/etc/alternatives/sh 

/etc/ssh/sshd_confing 

/usr/libexec/sftp-server 

/usr/bin/ssh 


Root 권한으로만 읽기/쓰기를 할 수 있는 곳

(여러 앱을 분석하면서 검사하는 경로를 추가할 예정이다.)

 

 

/private/

/root/

/

 

 


기타 방법

1. URL을 접속해 에러가 발생하는지 여부를 확인해 탐지하는 방법.

   ( cydia:// 로 시작하는 URL은 탈옥된 디바이스에서만 접속이 된다. )

 

 

 

2. /etc/fstab 의 Size를 통해 탐지하는 방법.

 

음........ stat로 불러온 객체 +0x60 지점에 뭐가있나..? 80이랑 비교하는데.. 확인해봐야겠다.

 

 

 

3. system(0)을 호출한 결과를 통해 탐지하는 방법.

   ( root권한이 있어야 호출이 가능한 것 같다. )

   이외에도 fork(), vm_protect(), _dyld_image_count() 함수들을 호출함으로써 탐지할 수 있다.

  가 아니라 탈옥기기와 순정기기와의 실행결과가 서로 다르다는 점을 이용해 탈옥여불르 탐지한다.

 

 

4. "/Applications"를 lstat의 인자로 전달해 반환 값을 확인한다.

    ( 심볼릭 링크인지 아닌지 확인하는 과정을 거친다.. 무슨...? )

 

   이외에 확인할 수 있는 경로 목록

    - /Library/Ringtones

    - /Library/Wallpaper

    - /user/arm-apple-darwin9

    - /usr/include

    - /usr/libexec

    - /usr/share

 

    - /var/lib/undecimus/aat 

 

기존의 시스템 파티션에 위치하는 몇 개의 디렉토리는 탈옥 과정 파이션이 Overwrite 됨에 따라서 데이터를 더 큰 데이터 파티션에 이전해야 한다. 이전 파일 위치는 유효해야 하므로 심볼 링크를 통해 이를 해결하게된다.

 

 

5. 동작중인 프로세스를 점검해 탈옥을 탐지한다.

 

 

 

6. OpenSSH 서비스에 접근함으로써 탐지하는 방법.

 

'모바일' 카테고리의 다른 글

iOS 디버깅 우회  (0) 2022.05.14
chimera jailbreak download plist  (0) 2022.05.11
[apk-mitm] APK 파일 SSL/TLS pinning 우회 및 기능 없애는 방법 (펌)  (0) 2022.04.28
libil2cpp-Patcher  (0) 2022.04.27
android jadx tool  (0) 2021.12.11
블로그 이미지

wtdsoul

,

안티 리버싱

리버싱 2022. 10. 19. 09:39

앞서 안티 디버깅에 대한 간단한 예제를 살펴보았다.

2020/08/04 - [SECURITY/REVERSING] - 안티 리버싱 :: 03 - 안티 디버깅 예제

 

 

이제는 안티 디버깅에 대한 이론적인 것들을 간단하게 개념적으로 정리해볼 것이다.

 

대다수 안티 디버깅 기법은 FS:[0x30] 에 접근해 윈도우 API 를 이용하거나, 

디버깅하면 그냥 실행했을 때보다 실행 시간이 길어짐을 이용하여 시간을 검사하는 기법을 자주 사용한다.

 

 

 

 

------------------- 목차 -------------------

 

1. Windows API 

1.1 IsDebuggerPresent
1.2 CheckRemoteDebuggerPresent

1.3 NTQueryInformationProcess

1.4 OutputDebugString

1.5 FindWindow

 

2. structure (구조체) 를 수동으로 검사

2.1 BeingDebugged 플래그

 

3. 디버거로 실행할 때 프로세스에 미치는 변화를 감지

3.1 INT

3.2 Checksums

3.3 시간 체크

 

4. TLS Callback

 

-------------------------------------------- 

 

 

 

 

1. Windows API 

 

 

1.1 IsDebuggerPresent

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-isdebuggerpresent

 

앞선 예제에서 살펴본, 가장 간단한 디버거 탐지 윈도우 API 함수이다.

이 함수는 PEB 구조에서 IsDebugged 필드를 찾아 디버그가 동작 중인지 판단하여 동작 중이 아니라면 0을, 동작 중이라면 0이 아닌 값을 반환한다.

 

** PEB 는 FS 레지스터를 통해 접근 가능. TEB 의 0x30 이 PEB 를 가리킴

  --> FS:[0x30] 이라 되어있으면 PEB 를 가리키는 것

** TEB, PEB 란?

더보기
접기

* TEB (Therad Environment Block)

: win32 의 자료 구조로서, 현재 실행 중인 스레드에 대한 정보를 저장하고 있다.

다양한 윈도우 DLL 에 대한 컨텍스트 정보를 담고 있다.

이 요소들이 유저 모드에서 구동되므로 유저 모드에서 쓰기가 가능한 구조체가 필요했다.

그래서 이 구조체는 커널 모드에서만 쓰기가 가능한 시스템 주소 공간이 아닌 프로세스 주소 공간에 위치한다. 

 

* PEB (Process Environment Block)

 

: 윈도우 NT 에서의 데이터 구조체.

운영체제 내부에서 사용하는 구조체로, 이미지 로더, 힘 관리자, 윈도우 시스템 DLL 등 유저 모드 상에서 접근할 필요가 있는 정보를 가지고 있다.

 

(NT ZW ?? -> https://blog.naver.com/stgavriel/80044878343)

 

 

+ FS 레지스터

: 커널 모드에서는 KPCR(Kernel's Processor Control Region) 구조체를,

유저 모드에서는 TEB 구조체를 가리키고 있다.

 

따라서

FS:[0] 은 TEB 의 시작 위치, 

FS:[0x30] 은 PEB 의 시작 위치를 의미

 

실제로 함수 실행에 들어가보면 FS:[30] 으로 PEB 구조체에서 +2 를 하여 BeingDebugged 를 확인하는 것을 볼 수 있다.

 

 

 

1.2 CheckRemoteDebuggerPresent

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-checkremotedebuggerpresent

 

PEB 구조의 IsDebugged 필드를 확인하며 IsDebuggerPresent 와 거의 동일한 기능을 한다. 

다만 자신이나 로컬 컴퓨터의 프로세스에 대해서만 검사할 수 있다.

 

파라미터로 프로세스 헨들을 받아 프로세스가 디버거 환경에서 실행 중인지를 판단한다.

 

Use the IsDebuggerPresent function to detect whether the calling process is running under the debugger.

 

 

1.3 NTQueryInformationProcess

https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntqueryinformationprocess

 

첫 번쨰 파라미터로 프로세스 헨들을, 두 번째 파라미터로 얻고자 하는 프로세스 정보의 타입을 요구한다.

두 번째 파라미터인 ProcessInformationClass  ProcessDebugPort(0x7) 을 준다면 해당 프로세스가 디버깅 중인지에 대한 여부를 반환한다.

 

디버깅 중이라면 0, 아니면 디버거 포트 번호를 반환한다.

 

(NT ZW ?? -> https://blog.naver.com/stgavriel/80044878343)

 

 

1.4 OutputDebugString

https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-outputdebugstringw

 

디버거에 출력할 문자열을 전달하는 데 사용되는 함수이므로 디버거의 존재를 탐지하는 데 사용할 수 있다.

 

이 함수를 실행했는데 오류가 발생하지 않는다면 디버거로 실행중이라는 의미이다.

 

 

1.5 FindWindow

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa

 

특정 프로그램(디버그)가 실행되고 있는지 검색할 수 있다.

첫번째 파라미터로 검색할 프로그램(디버그) 이름을 주고, 만일 해당 프로그램이 실행 중이라면 그 헨들을, 실행하고 있지 않다면 NULL 값을 반환한다.

 

ex. FindWindow("OllyDbg", NULL)

 

 

 

2. Structure (구조체) 를 수동으로 검사

 

PEB 구조체에서 디버거가 존재하는지에 대한 정보를 제공한다.

 

운영 체제는 실행 중인 각 프로세스에 대해 윈도우 PEB 구조체를 관리한다.

환경 변수 값, 로드된 모듈 목록, 메모리 주소, 디버거 상태 등의 프로세스 환경 데이터를 포함한다.

 

프로세스 실행 중에 FS:[0x30] 으로 PEB 를 접근할 수 있다.

https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb

 

2.1 BeingDebugged 플래그

 

이 플래그는 PEB 구조체의 오프셋 2에 있다. (0x2) (향후 윈도우 버전에 따라 변경 가능)

이 플래그 값이 0 이면 디버거가 동작하고 있지 않다는 것이고, 1 이면 디버거가 동작하고 있다는 뜻이다.

 

 

그리고 다른 플래그들이 존재하지만, 향후 윈도우 버전에 의해 구조가 달라질 수 있으므로 해당 문서를 참조하길 바란다.

 

 

3. 디버거로 실행할 때 프로세스에 미치는 변화를 감지

 

3.1 INT 3

 

INT 3 는 소프트웨어 BP 를 설정하는 기본 메커니즘이다.

 

INT 3 의 OPCODE 는 0xCC 로, 이 OPCODE 를 검색하여 본래의 코드가 INT 3 로 변경되었는지 프로세스를 스캔한다.

0xCC 가 발견되면 디버거가 존재한다는 뜻이다.

 

혹은 코드에 INT 3 구문이 있을 때, 디버거로 실행하면 오류가 나지 않지만 그냥 실행하면 해당 구문은 오류를 뱉는다. 오류를 뱉는지에 대한 여부로도 디버그의 존재 여부를 파악할 수 있다.

 

 

이를 우회하기 위해서는 소프트웨어 BP 대신 하드웨어 BP 를 설정하면 된다.

 

 

 

 

3.2 Checksums

 

특정 코드 영역의 CheckSum 값을 구하고, 원본 CheckSum 과 비교하여 BP 설정 혹은 각종 코드 패치 여부를 검사할 수 있다. 

 

그 중 Hash Checking 기법은 함수 코드들의 Hash 값을 미리 구해 둔 다음, 그 값과 실행 중간에 호가인한 Hash 값이 같은지 확인하여 패치 여부를 탐지하는 것이다.

 

 

 

3.3 시간 체크

 

디버거로 프로세스를 실행하면 그냥 프로세스를 실행했을 때보다 속도가 현저히 느려진다.

이런 시간 차이를 탐지하는 몇 가지 기술이 존재한다.

 

 

3.3.1 타임 스탬프

 

특정 동작 수행 전후에 타임 스탬프를 기록하고 비교한다.

 

혹은 예외 발생 전후의 타임 스탬프를 가져와서 비교한다. 디버거가 예외를 처리하는 경우 상당한 지연이 발생하기 때문에 구분할 수 있다. (예외를 무시하거나 지나치게 하는 기능을 제공하는 디버거들도 있지만, 그럼에도 차이가 발생한다.)

 

 

3.3.2 rdtsc (OPCODE 0x0F31)

 

가장 일반적인 시간 검사 방법이다.

 

가장 최근에 시스템이 리부팅한 이후 흐른 시간 값을 저장한 64비트를 반환한다.

이 명령어를 실행한 후 두 값의 차가 특정한 정도를 넘으면 디버거가 실행 중임으로 판단할 수 있다.

 

 

3.3.3 QueryPerformanceCounter & GetTickCount

https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount

 

 

rdtsc 와 같이 시간차를 분석할 수 있는 윈도우 API 함수이다.

 

 

4. TLS Callback

 

일반적으로 대다수 디버거는 PE 헤더에서 정의한 프로그램 지입점에서 시작한다.

그런데 TLS(Thread Local Storage) Callback 은 진입점 전에 실행되는 코드로, 디버거 몰래 실행할 수 있다.

 

즉, TLS Callback 에 악성 코드 기능을 삽입한다면 디버거로는 감지하지 못한다.

 

일반적인 프로그램은 .tls 섹션을 사용하지 않기 때문에 .tls 섹션이 있는 경우 가장 먼저 안티 디버깅을 의심해야 한다.

 

출처: https://kali-km.tistory.com/entry/Anti-Debugging?category=490391

관련 내용을 더 알고 싶다면 - https://flack3r.tistory.com/entry/TLS-%EC%BD%9C%EB%B0%B1-%EC%95%88%ED%8B%B0%EB%94%94%EB%B2%84%EA%B9%85

 

 

참고 사이트들

https://blog.naver.com/sol9501/70128619541

https://kali-km.tistory.com/entry/Anti-Debugging?category=490391

'리버싱' 카테고리의 다른 글

Lab05-01.dll  (0) 2022.05.02
IAT & EAT 정리  (0) 2022.04.27
RVA to RWA 쉽게 계산하기 [펌]  (0) 2022.04.27
EAT IAT 계산  (0) 2022.04.25
C#은 SecureSting 클래스  (0) 2021.07.09
블로그 이미지

wtdsoul

,

DNS Cache Poisoning 공격 : 네이버 블로그 (naver.com)

 

DNS Cache Poisoning 공격

● DNS Cache Poisoning DNS Cache Poisoning 공격은 DNS 통신상의 인증 취약으로 인하여 발...

blog.naver.com

 DNS Cache Poisoning
DNS Cache Poisoning 공격은 DNS 통신상의 인증 취약으로 인하여 발생한다. 공격자가 DNS 응답 패킷을 위조하여 취약 DNS 서버에 전송할 경우, DNS 서버가 해당 응답을 Authoritative DNS 서버로부터 발송된 정상적인 응답으로 받아들인다는데 문제점이 있다. 위조된 응답이 받아들여질 경우, 취약 DNS 서버의 Cache 테이블에 공격자에 의하여 위조된 정보가 저장되게 되며, 이후에는 DNS 서버는 일반 이용자들에게 Cache 테이블에 저장된 위조된 DNS 정보를 제공하게 된다.


● DNS 서버 인증 취약점
DNS 서버는 TXID(Transaction ID)와 Source Port 를 이용하여 DNS 패킷을 인증하는데, TXID 와 Source Port 추측이 가능하다는데 문제점이 있다. 특히, DNS Source Port 의 경우 질의 시 일정한 번호로 고정되게 되어 추측이 용이하다.

취약한 Recursive DNS 서버에서의 질의 패킷에 대한 Source Port 확인 예(일정한 번호로 고정)

TXID 또한 변화 범위가 넓지 않아, 공격자가 TXID 번호에 대한 무작위 대입 또는 순차 대입 공격 등을 통하여, 위조 응답 패킷이 인증이 되도록 할 수 있다.

DNS 패킷의 TXID 필드 Length 예

위와 같이 TXID 필드는 16Bit 이므로, 한 번의 무작위 대입 공격으로는 1/65536 확률을 가지게 된다. 그러나, 단시간 내에 무작위로 대입된 대량의 패킷을 발송하는 방식으로 공격 성공 확률을 크게 높일 수 있다.

TXID 번호에 대한 무작위 대입 또는 순차 대입 공격



● DNS Cache Poisoning 공격 분석
DNS 인증 취약점 공격이 성공하여 위조된 DNS 패킷이 취약한 DNS 서버에서 Accept 될 경우, 공격자가 의도한 특정 도메인에 대한 악성 IP 주소 값이 취약한 DNS의 Cache 테이블에 저장되게 되며, 이후에는 해당 취약 DNS 서버는 DNS 질의를 하는 모든 이용자들에게 변조된 IP 주소로 응답하게 된다. 정상적인 DNS 요청 및 서비스 과정과 공격자에 의한 공격 과정을 비교하여 살펴보면 다음과 같다.

▶ 정상적인 DNS 요청 과정

정상적인 DNS 요청 절차 예
 

인터넷 사용자가 DNS 도메인 서비스를 정상적으로 받을 경우의 과정은 위의 그림과 같다. 사용자 PC 가 Recursive DNS 서버에 특정 도메인네임에 대한 주소 요청을 하게 되면, Recursive DNS 서버는 해당 도메인을 가지고 있는 Authoritative DNS 서버로 찾아가서, 해당 도메인에 대한 주소를 응답받아, 최초 질의한 사용자 PC 에 해당 주소를 알려준다.

▶ DNS 응답 조작 통한 Cache Poisoning 공격 과정 예
정상적인 응답 과정과는 다르게, 공격자가 DNS 응답 패킷을 임의로 제작하여, DNS 서버에 발송하여 DNS Cache 테이블에 공격자가 원하는 정보가 입력되도록 한다. 이 공격을 성공하기 위하여는 우선 DNS 인증 취약점 공격이 성공하여야 한다.

DNS Cache Poisoning 공격 예

① 공격자는 AAA 도메인을 공격 대상 DNS 서버에 요청한다.
② Authoritative DNS 서버로부터 응답 패킷이 온 것처럼 소스 IP 를 Auth DNS IP 로 스푸핑하여
위조된 응답 패킷을 공격 대상 DNS 서버에 보낸다. 공격자는 위조된 패킷이 실제 정상적인 Auth DNS 응답보다 먼저 수신 되도록 빠른 속도로 발송한다.
③ 공격 대상 DNS 서버는 위조된 응답 패킷을 받아들여, 위조된 주소를 Cache에 저장한다. 위조된 응답 패킷을 받아들이기 위해서는 우선 DNS 인증 취약점 공격이 성공하여야 한다.
④ 공격 대상 DNS 서버를 사용하는 일반 사용자가 AAA 에 대한 DNS 질의를 할 경우 위조된 주소로 응답받게 된다.


● DNS Cache Poisoning 모의 공격 과정
▶ DNS 인증 취약점 공격
① 공격자는 공격자가 구성한 Authoritative DNS 서버를 활용, 공격자 도메인으로 쿼리 패킷을 발송 및 분석하는 방법 등을 통하여, 취약 DNS 가 질의 시 사용하는 Source 포트를 파악한다.
② 취약 DNS 서버에 Poisoning 을 원하는 도메인의 다수 하위 도메인으로 질의를 발생시킨 후, TXID 필드 값을 순차적으로 증가시켜가며 빠른 속도로 위조된 응답 패킷을 발송한다. 위조 패킷 발송 시 UDP Destination 포트는 취약 DNS 서버가 사용하는 것으로 확인된 Source 포트 번호로 설정한다. 일단 Authoritative DNS 서버로부터 정상적인 응답을 받을 경우, DNS Cache 에 정상적인 도메인 주소 정보가 저장되게 되어, 이후에는 질의가 발생하지 않게 되며, 위조된 응답 패킷을 수신하지 않아 공격이 불가능해진다. 따라서, 새로운 하위 도메인으로 주기적으로 질의를 한다.

공격을 위한 위조된 응답 패킷 예 (짧은 시간 내에 TXID를 순차적으로 변경해 가며 응답 패킷 발송)

③ 취약 DNS 는 공격자가 발송한 대량의 위조된 패킷 중 TXID 가 일치하는 패킷이 수신되면 해당 응답을 정상적인 패킷으로 받아들인다.

▶ DNS Cache Poisoning을 통한 특정 도메인에 대한 IP 주소 위조
DNS 인증 취약점 공격이 성공하게 되면, 취약 DNS 서버는 위조된 DNS 응답 패킷을 받아들여 DNS Payload 에 있는 위조된 정보를 DNS Cache 테이블에 저장한다. www.pr[생략]ng.net 도메인을 대상으로 실제 공격하는 과정과 결과를 살펴보면 다음과 같다.

DNS Cache Poisoning 공격 과정

① 취약 DNS 서버에 pr[생략]ng.net 도메인에 대한 위조된 응답 패킷을 발송한다. (Cache Poisoning을 하고자 하는 도메인인 www.pr[생략]ng.net 와 Resolving IP 199.199.199.199 는 Additional RR 필드 부분에 삽입)

위조된 DNS 응답 패킷 내용 예

② 공격이 성공한 후, 취약 DNS 서버를 사용하는 사용자가 www.pr[생략]ng.net 도메인에 대한 질의를 할 경우, 위조된 199.199.199.199 로 응답받게 된다.

공격 성공 전 - 10.50.100.6 으로 응답
공격 성공 후 - 변조된 199.199.199.199 으로 응답



● 대응 방안
▶ 사전 예방 방안 : 캐시/리졸빙 DNS 서버로 사용되는 시스템을 운영 중이라면, 해당 보안 취약점 공격에 대비하기 위하여 각 벤더사의 DNS 를 최신 버전으로 업그레이드한다.

취약점 점검 방법 : 점검하고자 하는 도메인이 "aaa.bbb.ccc.ddd" 인 경우
$ dig @aaa.bbb.ccc.ddd +short porttest.dns-oarc.net TXT
취약점이 존재하는 경우
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "aaa.bbb.ccc.ddd is POOR: 26 queries in 4.0 seconds from 1 ports with std dev 0.00"
DNS가 취약점에 노출되지 않은 경우
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net. "aaa.bbb.ccc.ddd is GOOD: 26 queries in 2.0 seconds from 26 ports with std dev 17685.51"


▶ 신뢰할 수 있는 호스트에 대해서만 recursive query 서비스가 가능하도록 설정한다. recursive query를 제한하더라도, DNS 가 패치가 안되어 있을 경우는, 내부의 호스트를 이용한 공격에는 노출되게 되므로 주의해야 한다.
- 신뢰된 호스트에서만 Recursion 서비스를 제공하는 방법 (BIND 8.2.1와 이후 버전)

① 신뢰 네트워크 대역에 대한 ACL 설정
acl internal { 192.168.1.0/24; };
② internal 로 정의된 대역으로부터 발생하는 요청만 받아들이도록 설정
options {
...
allow-recursion { internal; };
...
};

- Bind9 에서는 "view" 설정을 통하여 IP 대역 별로 Recursion 서비스 여부를 조정할 수 있다.

Recursion 기능을 활성화
view "internalview" {
match-clients { internal; };
recursion yes;
};
Recursion 기능을 비활성화
view "externalview" {
match-clients { any; };
recursion no;
};



● 공격 발생 시의 탐지 방안
DNS 인증 취약점을 공격하기 위해서는, 공격자는 Authoritative DNS IP 로 가장하여 위조된 DNS 응답 패킷을 발송하여야 한다. TXID 필드는 16bit 로써 임의의 값으로 저장된 하나의 응답 패킷을 발송할 경우, 1/65536의 성공 확률을 가지게 된다. 따라서, 공격자는 성공 확률을 높이기 위하여 TXID 를 순차적으로 증가 또는, 무작위로 대입된 응답 패킷들을 대량으로 발생시키는 방식으로 공격을 수행할 소지가 매우 높다. Authoritative DNS 서버로부터 정상적인 응답 패킷이 도착하기 전에, 공격을 성공시켜야 하므로, 한 번의 질의 시 공격을 위한 짧은 시간이 주어진다. 따라서, 공격자는 주기적으로 Poisoning 을 원하는 도메인에 대한 임의의 서브 도메인 이름으로 재질의를 하며 공격을 수행하게 된다. 또한, 위조된 DNS 응답 패킷의 Additional 필드(또는 추가 answer 필드)에는 Poisoning 을 원하는 도메인 정보와 주소가 삽입되게 된다.
공격이 발생하게 되면, 공격 대상 Recursive DNS 서버에서는 단일 IP 로부터 응답 패킷들이 대량으로 유입되는 현상이 관찰될 것으로 보인다. 또한, 해당 응답 패킷의 "Question" 및 "Answer" DNS 필드에는 최하위 서브 도메인명이 랜덤 형식인 비정상적인 형태의 도메인이 포함되어 있을 가능성이 높다.
Recursive DNS 서버 운영자는 단일 IP 에서 매우 짧은 시간 내에 DNS 응답 패킷이 대량으로 유입되는 로그 및 현상이 관찰될 경우, 유입되는 DNS 응답 패킷들의 "Question" 및 "Answer" DNS 필드의 페이로드를 확인하여, 최하위 서브 도메인명이 랜덤 형식이거나 계속적으로 변경되는 비정상적인 형태의 실제로는 존재하지 않는 도메인이 포함되어 있는지를 확인해 보도록 한다. 짧은 시간 내에 이러한 유형의
패킷이 다수 확인될 경우 공격 발생을 의심해볼 필요가 있다.

공격 패킷의 "Question" 및 "Answer" 필드 내에 포함되어 있는 비정상적인 도메인 예

'경로 및 정보' 카테고리의 다른 글

[Windows - Tip] 무료 대용량 텍스트 파일 읽기 프로그램  (0) 2022.10.27
QEME로 MIPS 구동 환경 셋팅(펌)  (0) 2022.10.23
chromium-browser  (0) 2022.10.12
Cycript 도구  (0) 2022.10.11
Docker 2375/2376  (0) 2022.10.07
블로그 이미지

wtdsoul

,

chromium-browser

경로 및 정보 2022. 10. 12. 13:28

https://commondatastorage.googleapis.com/chromium-browser-asan/index.html

 

https://commondatastorage.googleapis.com/chromium-browser-asan/index.html

 

commondatastorage.googleapis.com

 

Chrome Build File

'경로 및 정보' 카테고리의 다른 글

QEME로 MIPS 구동 환경 셋팅(펌)  (0) 2022.10.23
DNS Cache Poisoning 공격  (0) 2022.10.14
Cycript 도구  (0) 2022.10.11
Docker 2375/2376  (0) 2022.10.07
jenkins RCE  (0) 2022.10.07
블로그 이미지

wtdsoul

,

Cycript 도구

경로 및 정보 2022. 10. 11. 23:55

https://iphonedevwiki.net/index.php/Cycript_Tricks

 

Cycript Tricks - iPhone Development Wiki

Getting objects Objective-C objects using choose() The function choose(), introduced in version 0.9.502[citation needed] and documented here, allows us to get an array of existing objects of a certain class. Objective-C objects from addresses Use #0xdeadba

iphonedevwiki.net

https://bachs.tistory.com/entry/iOS-Hooking3Cycript

 

iOS Hooking#3(Cycript)

1. Cycript Cycript는 iOS에서 실행되고 있는 애플리케이션을 동적으로 수정하고 분석을 할 수 있게 해주는 SDK이다. 문법은 기본적으로 Objective-C / JavaScript를 혼합하여 사용 가능하다. 2. Cycript Hooking..

bachs.tistory.com

https://hackcatml.tistory.com/52

 

Cycript(iOS 12.4)

cyrun을 이용하면 ios 12에서도 cycript 사용이 가능. - Cycript 및 Cyrun 설치 및 구동 wget http://apt.saurik.com/debs/cycript_0.9.594_iphoneos-arm.deb wget http://www.tateu.net/repo/files/net.tateu.cyc..

hackcatml.tistory.com

 

 

1. Cycript

Cycript는 iOS에서 실행되고 있는 애플리케이션을 동적으로 수정하고 분석을 할 수 있게 해주는 SDK이다.문법은 기본적으로 Objective-C / JavaScript를 혼합하여 사용 가능하다. 

2. Cycript Hooking

 

2-1) view계층 확인하기

ex) UIApp.keyWindow.recursiveDescription()

 

view의 계층을 출력하여준다. NSLog로 출력하여 큰 화면으로 보면 아래와 같이 이쁘게 보인다.

 

 

2-2) subviews()

ex) UIApp.keyWindow.subviews()[index]

 

window는 하나 이상의 view를 가지며, view 역시 하나 이상의 view의 집합이다. 각 하위 view들의 접근은 subviews()[index]의 형태로 접근 가능하고, 2-1에서 확인한 계층을 참조하여 각 요소들을 찾을 수 있다.

 

 

2-3) _viewDelegate()

ex) UIApp.keyWindow.subviews()[2].subviews()[0]._viewDelegate()

 

_viewDelegate를 이용하여 해당 view의 controller에 접근 가능하다.

 

2-4) replacing existing objective-C methods

ex) Game2ViewController.prototype['recognizeAnswer'] 

= function() { NSLog(@"[JSACH]HOOKED"); return 1;}

 
target ViewController를 찾아 prototype배열에 후킹할 method에 접근하여 위와 같이 재정의해줌으로써 replacing가능함

 

 

참고) Cycript에서 사용하는 API나 문법, Trick들이 정리되어있는 링크

 

 - iOS Tricks

     http://iphonedevwiki.net/index.php/Cycript_Tricks

 

 - Cycript공식 홈페이지

http://www.cycript.org/

 

참고로 이 글은 Cycript 0.9.594버전을 기준으로 작성을 하였다.

 

 

3. 결과

 

3-1) 메서드 재정의

 

1
Game2ViewController.prototype['recognizeAnswer'= function() { NSLog(@"[JSBACH]HOOKED"); NSLog(@"[JSBACH] return SUCCESSED"); return 1;}
 

 

 

 

3-2) 메서드 후킹 로그

 

3-3) 후킹 성공 결과

 

 

------------------

 

cyrun을 이용하면 ios 12에서도 cycript 사용이 가능.

 

- Cycript 및 Cyrun 설치 및 구동

wget http://apt.saurik.com/debs/cycript_0.9.594_iphoneos-arm.deb

wget http://www.tateu.net/repo/files/net.tateu.cycriptlistenertweak_1.0.0_iphoneos-arm.deb

wget http://www.tateu.net/repo/files/net.tateu.cyrun_1.0.5_iphoneos-arm.deb

dpkg -i cycript_0.9.594_iphoneos-arm.deb

dpkg -i net.tateu.cycriptlistenertweak_1.0.0_iphoneos-arm.deb net.tateu.cyrun_1.0.5_iphoneos-arm.deb

 

cyrun -n <AppName on home icon> -e -d 또는

cyrun -b <AppBundleID> -e -d

 

- Bundle ID, Bundle DisplayName, Bundle ExecutableName 확인

NSBundle.mainBundle.infoDictionary.allKeys()

NSBundle.mainBundle.infoDictionary.CFBundleName

NSBundle.mainBundle.infoDictionary.CFBundleIdentifier

NSBundle.mainBundle.infoDictionary.CFBundleDisplayName

 

 

- View 계층 확인

UIApp.keyWindow.rootViewController    // root view controller 확인

UIApp.keyWindow.rootViewController._printHierachy().toString()

UIApp.keyWindow.recursiveDescription().toString()

UIApp.keyWindow._autolayoutTrace.toString()    // simplified recursiveDescription

 

 

- subviews 확인

UIApp.keyWindow.subviews()    // keyWindow의 subviews 확인. 아래 예시는 #으로 구분되는 2개의 subviews를 가지고 있음

#주소.subviews()    // 특정 주소값을 가지는 view의 subviews 확인. 아래 예시는 #으로 구분되는 1개의 subview를 가지고 있음

UIApp.keyWindow.subvies()[index]._viewDelegate()    // 해당 뷰를 담당하는 controller 출력. 아래 예시는 keyWindow의 첫번째 subview를 담당하는 controller가 UIApplicationRotationFollowingController 임을 나타냄.

 

 

- 상태표시줄 숨기기 / 표시하기(안되는 경우가 많음)

[[UIApplication SharedApplication] setStatusBarHidden:YES]

[[UIApplication SharedApplication] setStatusBarHidden:NO]

 

 

- 아이콘 badge number 조작(안되는 경우가 많음)

var a = [UIApplication sharedApplication]

[a setApplicationIconBadgeNumber:100];

 

 

- Print Methods

(1) printMethods 함수 만들어서 수행

// Usage:
// for InstanceMethods: printMethods('className')
// for ClassMethods: printMethods('className', true)
function printMethods(className, isa) {
  var count = new new Type("I");
  var classObj = (isa != undefined) ? objc_getClass(className)->isa :
  objc_getClass(className);
  var methods = class_copyMethodList(classObj, count);
  var methodsArray = [];
  for(var i = 0; i < *count; i++) {
  var method = methods[i];
  methodsArray.push({selector:method_getName(method),
  implementation:method_getImplementation(method)});
  }
  free(methods);
  return methodsArray;
}

==> 실행결과(DVIA-v2 앱에 대해서 test)

출력된 결과는 보기 힘드니, Online Javascript Beautifier를 활용(ex.  https://beautifier.io/).

 

(2) _methodDescription() 메서드 활용

UIApp.keyWindow.rootViewController._printHierachy() 명령어로 뷰 계층 확인 후 관심 클래스의 주소값에 대하여 다음 명령어 수행

#<주소값>._methodDescription().toString()    // 이 방법의 경우 알고자 하는 클래스의 method 뿐만 아니라 다른 클래스의 메서드들도 출력해주다보니 쓸모없는 정보들이 너무 많이 출력됨

 

 

- Print Current ViewController

function currentVC() {
  var app = [UIApplication sharedApplication]
  var keyWindow = app.keyWindow
  var rootController = keyWindow.rootViewController
  var visibleController = rootController.visibleViewController
  if (!visibleController){
  return rootController
  }
  return visibleController.childViewControllers[0]
}

==> 실행결과

 

※ 출처

https://bachs.tistory.com/entry/iOS-Hooking3Cycript

https://sevencho.github.io/archives/c12f47b1.html

https://gist.github.com/laprasdrum/667213ab364ef2536a30f3bdb79c77bb

http://nullgirl.com/blog/2018/03/20/iOS%E9%80%86%E5%90%91%E4%B8%8E%E5%AE%89%E5%85%A8-Cycript%E8%84%9A%E6%9C%AC%E4%BD%BF%E7%94%A8/

https://ileeyj.tistory.com/257

 

 

'경로 및 정보' 카테고리의 다른 글

DNS Cache Poisoning 공격  (0) 2022.10.14
chromium-browser  (0) 2022.10.12
Docker 2375/2376  (0) 2022.10.07
jenkins RCE  (0) 2022.10.07
Cisco Smart Install Client 취약점  (0) 2022.10.06
블로그 이미지

wtdsoul

,

Docker 2375/2376

경로 및 정보 2022. 10. 7. 14:20

해커, 도커도 뚫었다 – ㈜소프트이천 (soft2000.com)

 

해커, 도커도 뚫었다

지난 월간안 4월호 ‘클라우드 환경을 노리는 7가지 위협’를 통해 취약한 도커 환경을 노리는 공격이 증가하고 있음을 설명한 바 있다. 그리고 클라우드 도입과 함께 도커 활용이 계속 늘어남

www.soft2000.com

 

최근 클라우드 도입이 증가하면서 많은 시스템들이 가상화 기술을 사용하고 있다. 일반적으로 잘 알려진 가상화 기술 ‘하이퍼바이저(Hypervisor)’는 애플리케이션과 라이브러리를 격리시킬 수 있다. 하지만, 운영체제(OS) 뿐만 아니라 하드웨어 스택 부분도 가상화 시키기 때문에 메모리, CPU 등 자원을 많이 소모한다. 반면 ‘도커(Docker)’는 애플리케이션과 라이브러리를 패키지(컨테이너)로 묶어 리눅스 컨테이너(LinuX Containers: LXC)’로 리소스가 적게 드는 격리 환경을 만들 수 있다.

 

또한 도커는 애플리케이션을 쉽게 빌드(Build), 테스트(Test), 및 배포(Deploy) 할 수 있어 ‘데브옵스(Devops)’에 최적화되어 있는 오픈 소스 도구라 할 수 있다. 이에, 많은 기업들이 도커를 활용해 데브옵스 환경을 구축하고 있다.

 

도커를 타겟으로 한 악성코드

최근, 많은 서버들이 도커로 구성되면서 이를 타겟으로 한 공격도 증가하고 있다. 특히, 여러 공격 중에서도 ‘Docker REST API’를 이용한 공격이 급증하고 있다. 실제로 도커 관련 서버들의 침해 사례들을 보면 공격자들이 ‘Docker REST API’를 이용해 악성코드를 배포하고 있다. 그리고, 배포된 악성코드에는 취약한 Docker REST API 설정의 서버를 대상으로 측면 이동(Lateral Movement) 기능이 포함되어 기존 SSH 봇넷 악성코드처럼 공격이 확산되고 있다.

 

 

 

본 문서에서 언급하는 ‘취약한 Docker REST API 설정을 가진 서버’는 인증 및 접근 제한없이 원격 환경에서 ‘도커 이미지(Docker Image)’와 ‘도커 컨테이너(Docker Container)’를 관리하는 REST API를 사용할 수 있는 서버를 말한다.

 

취약한 Docker REST API 서버는 HTTP Request(Port:2375/2376)에 대한 HTTP Response({"message":"page not found"})를 통해 Docker REST API 서버를 탐지할 수 있다. 따라서, 격자는 [그림 2]와 같이 무작위 스캐닝을 수행해 취약한 Docker REST API 서버를 탐지한다.

 

 

 

공격자는 취약한 Docker REST API 서버를 알아낸 다음 Docker REST API를 통해 기존 도커 컨테이너에 악성코드를 실행시키거나 새로운 악성 도커 이미지를 다운로드 받아 실행시킨다.

 

 

 

특히, 공격자는 직접 포트 스캔을 하지 않고도 ‘쇼단(SHODAN)’과 같은 오신트(OSINT: 오픈소스 인텔리전스의 줄임말)를 이용해 Docker REST API 설정이 취약한 서버를 쉽게 찾을 수 있다. 이러한 방식으로 배포되는 악성코드는 대표적으로 6가지 종류가 있으며, 그 히스토리는 아래와 같다.

 

 

이번 글에서는 위 악성코드 6개 중 ‘Kinsing’, ‘Xanthe’, ‘KaijiDDoS’에 대해 소개한다.

 

'경로 및 정보' 카테고리의 다른 글

chromium-browser  (0) 2022.10.12
Cycript 도구  (0) 2022.10.11
jenkins RCE  (0) 2022.10.07
Cisco Smart Install Client 취약점  (0) 2022.10.06
SSTI  (0) 2022.09.28
블로그 이미지

wtdsoul

,

jenkins RCE

경로 및 정보 2022. 10. 7. 13:18

Remote Code Execution | A Story of Simple RCE on Jenkins Instance. | by Awez Kagdi | Medium

 

Remote Code Execution | A Story of Simple RCE on Jenkins Instance.

Vulnerability Category: A1- Code Injection

medium.com

Abusing Jenkins Groovy Script Console to get Shell | by Nishant Sharma | Pentester Academy Blog

 

Abusing Jenkins Groovy Script Console to get Shell

Jenkins is a leading open source automation server for deploying and automating any project.

blog.pentesteracademy.com

 

Here I have used censys.io tool to identify the vulnerability. In below POC you can seen in search query I have searched Jenkins dashboard. In result you will receive an IP’s and technologies platform used.

 

Now you have to open the IP in the browser tab to check the Jenkins Dashboard access. As you can see we have the dashboard access without any authentication and authorization.

 

Now you have to check if you have any other privilege's to exploit this vulnerability. How to check???

  1. IP/asynchPeople
  2. IP/configure
  3. IP/configureSecurity
  4. IP/script

Description: found a Jenkins instance publicly accessible. An attacker can execute an arbitrary code .

I opened it and it was publicly accessible and the worst part was it didn’t have any authentication set over it. Jenkins likes to view all the people having access to Jenkins Instance /asynchPeople provides that,

/configureSecurity- for global configuration setting.

/configure- configuration mode

/Script- To execute the script/commands.

As you can see we have access to script console to execute commands.

 

You can execute the followings commands and many more if you want.

  1. “ls /”.execute().text
  2. string contentRead = new File(‘/etc/passwd’).getText(‘UTF-8’)
 
 

You can also open terminal, This allows you to execute commands directly and depending on the user privilege.

 

 

'경로 및 정보' 카테고리의 다른 글

Cycript 도구  (0) 2022.10.11
Docker 2375/2376  (0) 2022.10.07
Cisco Smart Install Client 취약점  (0) 2022.10.06
SSTI  (0) 2022.09.28
jinja2-ssti-filter-bypasses  (0) 2022.09.27
블로그 이미지

wtdsoul

,

Cisco Smart Install Client 취약점 (tistory.com)

 

Cisco Smart Install Client 취약점

2017년초 Cisco Smart Install Client 취약점을 통하여 공격이 들어와서 시스템이 재부팅 되는 증상이 발견되었다. 내용은 아래와 같다 l 원인 : Cisco Smart Install Client(CVE-2018-017) 취약점을 이용한 원격..

kang1216.tistory.com

2017년초 Cisco Smart Install Client 취약점을 통하여 공격이 들어와서 시스템이 재부팅 되는 증상이 발견되었다. 내용은 아래와 같다
 
l  원인 : Cisco Smart Install Client(CVE-2018-017) 취약점을 이용한 원격 시스템 재부팅(참조URL1)
l  대상 펌웨어 : 아래 URL에서 확인 가능(참조URL2)
l  증상 : 시스템 리부팅, DOS공격, 무한루프 발생
l  공격형태
-       침입자는 Cisco Smart Install Client 장치에서 사용되는 Smart Install 메시를 TCP4786 포트를 통하여 보내어
시스템에 악영향을 끼칠수 있는 오버플로우 생성, 원격 명령어(Reload), 무한루프등을 발생
l  조치 방법
1.     펌웨어 업그레이드
2.  Vstak Disable(임시조치)
1) 스위치에서 Smart Install Client 기능 관련 서비스 활성화 여부 확인
test# show vstack config
 Role: Client (SmartInstall enabled)   // enable일경우 사용중임
Vstack Director IP address: 0.0.0.0
 
*** Following configurations will be effective only on director ***
Vstack default management vlan: 1
Vstack start-up management vlan: 1
Vstack management Vlans: none
Join Window Details:
         Window: Open (default)
         Operation Mode: auto (default)
Vstack Backup Details:
         Mode: On (default)
         Repository:
 
2) 스위치에서 관련포트 활성화 여부 확인
** 외부에서 접근시에만 나오는 경우도 있음
test# show tcp brief all
04A20C38  1.1.1.1.4786     *.*   LISTEN
 
3) 외부에서 관련포트 접근 확인
 
C:\Users\kang>telnet 1.1.1.1 4786
 
4) 스위치에서 Smart Install Client 기능 비활성화
test# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
test(config)# no vstack
test(config)# do sh vstack config
Role: Client (SmartInstall disabled)   // disable일 경우
Vstack Director IP address: 0.0.0.0
 
*** Following configurations will be effective only on director ***
Vstack default management vlan: 1
Vstack start-up management vlan: 1
Vstack management Vlans: none
Join Window Details:
         Window: Open (default)
         Operation Mode: auto (default)
Vstack Backup Details:
         Mode: On (default)
         Repository:
 
5) 스위치 관련 포트 활성화 여부 확인(외부에서 접근 테스트 진행)

 
참조URL1 : https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=27106
참조URL2 : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-smi2

'경로 및 정보' 카테고리의 다른 글

Docker 2375/2376  (0) 2022.10.07
jenkins RCE  (0) 2022.10.07
SSTI  (0) 2022.09.28
jinja2-ssti-filter-bypasses  (0) 2022.09.27
[ IIS ] http header 에 server 정보  (0) 2022.09.21
블로그 이미지

wtdsoul

,

https://velog.io/@dogfootbirdfoot/%EB%B8%94%EB%A1%9D%EC%B2%B4%EC%9D%B8-%EC%8A%A4%ED%84%B0%EB%94%94-12%EC%A3%BC%EC%B0%A8

 

블록체인 스터디 [12주차]

이번주는 cryptozombies lesson5를 학습했다. lesson5의 주제는 ERC721이다.이더리움 상에서의 토큰이란 기본적으로 몇몇 공통 규약을 따르는 스마트 컨트랙트이다. 즉, 다른 모든 토큰 컨트랙트가 사용하

velog.io

이번주는 cryptozombies lesson5를 학습했다. lesson5의 주제는 ERC721이다.

이더리움 상에서의 토큰이란 기본적으로 몇몇 공통 규약을 따르는 스마트 컨트랙트이다. 즉, 다른 모든 토큰 컨트랙트가 사용하는 표준 함수 집합을 구현하는 것이다. 예를 들면, ERC20 토큰을 따라서 애플리케이션을 만든다면면 이 앱이 다른 어떤 ERC20 토큰과도 상호작용이 가능한 것이다.

ERC 스탠다드의 종류는 9가지이며 ERC20은 표준 토큰이다. 여기서는 화폐처럼 사용하기 적절한 ERC20 대신 ERC721 토큰을 사용했다. 좀비는 화폐처럼 분할할 수 없고 각각의 좀비가 서로 다르기 때문이다. ERC721은 대체 불가능하고 각각의 토큰이 유일하고 분할이 불가하기 때문에 이 방법이 좀비를 거래하기에는 가장 적절하다.

토큰 컨트랙트를 구현하기 위해 인터페이스를 솔리디티 파일로 따로 복사하여 저장하고 import했다. ERC721 토큰의 함수들과 이름이 겹치는 함수나 modifer들은 다른 이름으로 바꾸는 리팩토링을 하고 전송 로직을 사용하여 한 사람이 다른 사람에게 소유권을 넘기는 것을 구현했다.

일단은 하라는대로 따라서 구현하긴 했는데 사실 전송 로직을 완전히 이해하지는 못했다. 토큰을 보내는 사람이 함수를 호출하는 transfer방식과 토큰을 받는 사람이 함수를 호출하는 takeOwnership방식을 학습했는데 아마 다시 보면서 복습을 해야할 것 같다.

학습한 내용 :

https://velog.io

 

'스터디' 카테고리의 다른 글

solidity 2022/10/02 cryptozombies  (0) 2022.10.02
solidity 2022/10/02  (0) 2022.10.02
Smartcontract Openzeppelin 22.09.18  (0) 2022.09.18
solidity 2022.09.04  (0) 2022.09.04
Solidity 2022.09.03  (0) 2022.09.03
블로그 이미지

wtdsoul

,