[Hacking] 시스템 해킹 (1)

kw0n笑 — Mon, 18 May 2026 15:09:03 +0900

시스템 해킹 (Pwnable) 이해하기

해킹이란?
- 권한이 없는 행위를 하는 것
시스템 장악 (shell 실행)
- 시스템: os를 기반으로 하드웨어를 통제할 수 있는 소프트웨어적 환경
- 쉘: 실행하고 싶은 프로그램을 실행시켜주는 프로그램 (cmd, bash, Zsh)
- 쉘 실행 => 시스템 해킹, pwnable의 목표
- 시스템 장악: 외부에 포트가 열린 프로그램에 접근하여 쉘을 실행시킨다는 것이다
  - 목표: 권한없이 넘어가서 하고 싶은 거 하기
  - 구체화: 프로그램의 취약점을 찾아 공격해 쉘을 실행하는 것이 pwnable의 목표

Pwnable의 문제상황 이해하기

인터넷 어딘가에 위차한 외부, remote 환경에서 내부 환경으로 침투하여 들어가는 것아 ctf pwnable에서 출제되는 문제 상황

Pwnable 문제 예시

hacktheworld.xyz의 pwn 카테고리 문제 확인

시스템 해킹 문제를 푸는데 원격 접속(nc, netcat)이 왜 필요한가?

nc hacktheworld_cca.xyz 3000

도메인 이름: 인터넷에 연결된 컴퓨터의 이름
포트: 실행중인 프로그램에 접근하기 위한 번호
nc (도메인) (포트)로 접속 정보를 나타냄 e.g. nc 101.79.9.58 10001

악의적인 실행흐름 만드는 법

컴퓨터 구조 이해하기
- CPU와 CPU 속의 레지스터, 거기 pc를 저장하고, memory가 존재하는 구조
프로그램 실행과정
- CPU는 PC에 쓰인 주소에 있는 프로그램 코드를 가져와서 검증없이 실행 => 이용해보자
악의적인 실행과정 만들기
- 0xFFFFF라는 임의의 주소에 password가 뭔지 알아내는 코드 삽입하고 pc 값을 0xFFFFF로 바꿔주기

사진 출처: 해킹대회 (CTF) 출전을 위한 시스템킹(Pwnable) 입문 - juntheworld [인프런]

[CS] 더블 인코딩

kw0n笑 — Sat, 2 May 2026 01:17:30 +0900

XSS filtering 취약점 공격 방어 시나리오:

client → WAF → 어플리케이션 환경에서 WAF가 요청 검증해서 XSS 공격 코드 차단

※ WAF: Web Application Firewall, 웹 방화벽

1. 시나리오

APP은 WAF를 통과한 데이터를 받아 작업 수행한다.

⇒ WAF는 전달 받은 데이터를 다시 디코딩해서는 안 됨, 그러면 오히려 공격자가 더블 인코딩으로 웹 방화벽의 검증을 쉽게 우회함

<script>(내용)</script>

// %253Csript%253E (내용을 더블 인코딩 한 값)
// 웹 방화벽이 해당 데이터를 디코딩 후 검증 -> %3Csript%3E(내용을 한 번 인코딩)-> 음 안전하네
// app에서 해당 데이터를 다시 디코딩해서 <script> %3Csript%3E을 게시판 DB에 저장, 검증 후 디코딩 발생
// 희생자가 해당 게시글 읽으면 XSS가 발생하여 악성 자바스크립트 코드 실행

검사가 미흡한 php 예시

<?php

$query = $_GET["query"]; // PHP는 GET, POST하고 자동으로 디코딩함

if (stripos($query, "<script>") !== FALSE) {
    header("HTTP/1.1 403 Forbidden");
    die("XSS attempt detected: " . htmlspecialchars($query, ENT_QUOTES|ENT_HTML5, "UTF-8"));
}

...

$searchQuery = urldecode($_GET["query"]); // 한 번 더 디코딩(urldecodes)

?>

<h1>Search results for: <?php echo $searchQuery; ?></h1>

아래의 php 코드를 보면 디코딩이 두 번 이루어짐을 알 수 있다.

POST /search?query=%3Cscript%3Ealert(document.cookie)%3C/script%3E HTTP/1.1

if (stripos($query, "<script>") !== FALSE)

...
-----
HTTP/1.1 403 Forbidden
XSS attempt detected: &lt;script&gt;alert(document.cookie)&lt;/script&gt;]

// 공격 실패

POST /search?query=%253Cscript%253Ealert(document.cookie)%253C/script%253E HTTP/1.1
...
-----
HTTP/1.1 200 OK
<h1>Search results for: <script>alert(document.cookie)</script></h1>

// 공격 성공

위의 경우엔 (내용)을 한번만 인코딩하였으므로 두 번째 디코딩에서 필터링된다. 그러나 아래의 경우에서는 (내용)을 두번 디코딩하게 되어 결과적으로 페이로드를 실행하게 되어 공격이 성공한다.

2. 방어 방법

HTML entity encoding(출력 시 인코딩)은 HTML 정규화의 반대 과정으로 브라우저가 정규화를 통해 코드를 실행하지 못하도록, 의도적으로 문자를 뭉개서 단순 텍스트로 보이게 만드는 방어 과정이다. 서버에 어떤 값이 저장되어 있든 브라우저에 뿌려줄 때 <를 <로 바꿔서 출력하면 브라우저는 이를 코드로 실행하지 않고 단순한 문자로 인식한다.

브라우저는 HTML 문서를 읽을 때 두 가지 모드로 작동합니다.

실행 모드 (Parsing Tags): <script>를 만나면 자바스크립트 코드로서 실행
출력 모드 (Rendering Text): <script>를 만나면 화면에 <script>라고 출력하라는 의미구나 생각

해결법: $searchQuery를 출력할 때 htmlspecialchars()를 사용한다.

만약 공격자가 <script>alert(1)</script>라는 값을 입력햇을 때, 서버가 htmlspecialchars()를 써서 보내준다면 서버(php)는 공격자가 보낸 데이터를 받자마자 바로 화면에 뿌리지 않고, htmlspecialchars()에 집어 넣는다.

구분	서버가 브라우저에 보내는 코드 (Source)	브라우저가 사용자에게 보여주는 화면 (View)	스크립트 실행 여부
인코딩 안 함	<h1><script>alert(1)</script></h1>	(알림창이 뜸)	실행됨 (위험)
인코딩 함	<h1><script>alert(1)</script></h1>	<script>alert(1)</script>	실행 안 됨 (안전)

kw0n笑 님의 블로그