Step 110. 프로젝트: “리눅스 권한 모델의 허점” 정리 문서 — 공격자의 눈으로 복습한다

Level 2 — 보안 입문과 공격 스킬 기초 | 난이도 ★★★☆☆ | 예상 소요 시간 3~4시간

전제: Step 23~25(권한·소유권·사용자), Step 99(Bandit의 setuid), Step 100(cron), Step 106(특수 권한 비트), Step 108(PATH 인젝션), Step 109(링크)를 마쳤다. 리눅스 터미널이 준비되어 있다.

• 준비물: 리눅스 터미널(발견 명령 검증용), 문서 작성 도구 하나(메모장·마크다운·개인 위키 무엇이든), 그리고 지금까지의 실험 노트.
• 주의: ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 이 챕터의 발견 명령 실측은 WSL 리눅스(Ubuntu 24.04)에서 수행했습니다.

지금까지 여러분은 리눅스 권한 모델의 허점을 하나씩 따로 배웠습니다. setuid, PATH 인젝션, 심볼릭 링크, cron — 각각은 개별 기법이지만, 실전의 공격자는 이것들을 하나의 점검 목록으로 봅니다. "이 서버에 올라탔다. 이제 뭘 확인하지?"라는 질문의 답이 바로 그 목록입니다. 오늘은 새로운 기술을 배우지 않습니다. 대신 흩어진 지식을 한 장의 참고 문서로 묶는 프로젝트를 합니다 — 이 문서는 Level 2 후반의 권한 상승 실전 내내 여러분의 옆에 놓일 것입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

• 리눅스 권한 우회 지점 4종을 "조건 / 발견 방법 / 악용 방법 / 방어법"의 4단 구조로 정리한다
• 각 우회 지점의 발견 명령어를 직접 실행해 보고 출력을 문서에 붙인다
• 워게임(Bandit 등)에서 실제로 쓴 기법과 문서의 항목을 연결한다
• 앞으로 새로운 우회 기법을 배울 때마다 같은 틀에 추가하는 "살아있는 문서" 습관을 만든다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

2-1. 권한 모델은 튼튼하다 — 허점은 설정에서 나온다

먼저 짚고 갈 사실이 있습니다. 리눅스의 권한 모델 자체 — 소유자/그룹/기타에 rwx를 붙이는 체계 — 는 수십 년간 검증된 단단한 설계입니다. 커널은 매 접근마다 이 규칙을 성실하게 검사합니다.

그런데 왜 권한 상승 공격이 성공할까요? 답은 "모델의 실패가 아니라 설정의 실패"입니다. 잘못 붙은 setuid 비트, 경로 없이 명령을 부르는 스크립트, 누구나 고칠 수 있는 cron 스크립트, 공용 디렉터리의 예측 가능한 파일 — 전부 "사람이 설정을 어긴" 지점입니다. 공격자는 시스템과 싸우는 게 아니라 관리자의 실수와 약속합니다.

2-2. 4단 정리 프레임 — 조건 / 발견 / 악용 / 방어

오늘 문서의 각 항목은 반드시 이 네 칸을 채웁니다:

이 틀의 힘은 대칭에 있습니다. 같은 문서가 공격자의 점검표이자 방어자의 점검표입니다 — 실무의 침투 테스트 보고서가 정확히 이 구조("취약 조건 / 확인 방법 / 영향 / 권고")로 쓰이는 이유입니다.

2-3. 발견이 먼저다

네 칸 중 초보가 가장 얕보는 칸이 "발견"이고, 실력을 가르는 칸도 "발견"입니다. 악용법은 문서에 다 적혀 있지만, 그 조건이 이 서버에 존재하는가를 찾아내는 것은 명령과 눈의 문제이기 때문입니다. 그래서 오늘 프로젝트의 규칙은 하나입니다 — 문서의 모든 발견 명령은 직접 실행해 보고, 출력을 붙여 넣는다. 읽기만 한 문서는 외워지지 않습니다.

3. 따라 하기

3-1. 문서 뼈대 만들기

문서 파일을 만듭니다. 개인 위키가 있다면 거기에, 없다면 마크다운 파일로 시작하세요.

입력

mkdir -p ~/security-notes && cd ~/security-notes
nano privesc-linux-v1.md

아래 목차 템플릿으로 시작합니다. 문서에서는 각 항목을 h2 제목(샵 두 개 + 제목)으로 만들면 됩니다 — 이 챕터 파일의 표기 규칙상 여기서는 목록으로만 보여 드립니다:

섹션 1~4의 각 항목 아래에는 4단 프레임의 소제목(조건 / 발견 / 악용 / 방어)을 미리 만들어 두세요. 빈칸을 채우는 것이 오늘의 작업입니다.

3-2. 발견 명령 1 — setuid 전수 조사

첫 번째 항목의 "발견" 칸을 채울 명령을 직접 돌려 봅니다.

입력

find / -perm -4000 -type f 2>/dev/null

출력 (2026-09-09 실측, WSL Ubuntu 24.04 — 전체 조회에 시간이 걸려 주요 디렉터리 기준으로 요약):

/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/bin/umount
/usr/bin/su
/usr/bin/sudo
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/passwd
/usr/bin/mount
/usr/bin/gpasswd

읽는 법: -perm -4000은 setuid 비트가 붙은 파일을 찾는 조건이고, 2>/dev/null은 권한 없는 디렉터리의 에러를 숨깁니다. 목록 속 passwd, sudo, su는 정상적으로 setuid가 필요한 명령들입니다. 여기서 공격자가 찾는 것은 "이상한 것" — 예를 들어 find, vim, python처럼 setuid가 필요 없는 프로그램에 비트가 붙어 있는 경우입니다(Step 106의 GTFOBins 복습).

왜: 이 명령 한 줄이 권한 상승 정찰의 첫 페이지입니다. 여러분 문서의 "1. setuid" 항목 → ### 발견 칸에 이 명령과 출력 일부를 지금 붙여 넣으세요.

3-3. 발견 명령 2 — cron과 쓰기 가능 파일

입력

ls -la /etc/cron.d/
find /tmp -writable -type f 2>/dev/null | head -8

출력 (2026-09-09 실측):

total 16
drwxr-xr-x   2 root root 4096 Feb 10  2026 .
drwxr-xr-x 100 root root 4096 Sep  9 15:12 ..
-rw-r--r--   1 root root  102 Mar 31  2024 .placeholder
-rw-r--r--   1 root root  201 Apr  8  2024 e2scrub_all

/tmp/websrv2/backup/notes.txt
/tmp/websrv2/admin/index.html
/tmp/websrv2/secret.txt
/tmp/websrv2/index.html
...

읽는 법: /etc/cron.d/에는 시스템 예약 작업이 파일로 들어 있습니다. 공격자의 관심은 ① 누가 이 파일들을 고칠 수 있는가(권한 열 확인), ② cron이 실행하는 스크립트가 누구나 쓸 수 있는 곳에 있지는 않은가, 입니다. -writable 검색은 "내가 고칠 수 있는 파일"의 목록 — 여기에 root가 실행하는 스크립트가 섞여 있다면 그것이 문입니다.

왜: Step 100의 Bandit cron 문제가 정확히 이 구조였습니다. 명령을 문서의 "4. cron 악용" → ### 발견 칸에 붙이세요.

3-4. 발견 명령 3 — PATH와 링크

입력

echo $PATH
find /tmp -xtype l 2>/dev/null

출력 (2026-09-09 실측, 일부):

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:...

/tmp/linklab/sym.txt

읽는 법: $PATH는 쉘이 명령을 찾는 순서입니다(Step 108). 앞쪽에 누구나 쓸 수 있는 디렉터리가 있으면 위험 신호입니다. -xtype l은 깨진 심볼릭 링크를 찾습니다(Step 109) — 누가 흘려둔 링크, 그리고 "내가 쓸 수 있는 경로에 고권한 프로그램이 만질 이름"을 미리 점치는 재료가 됩니다.

3-5. 항목 채우기 — 4단 프레임으로

이제 지금까지의 챕터를 복습하며 문서를 채웁니다. 각 항목에 들어갈 재료의 출처입니다:

각 항목의 4칸을 채울 때 주의할 것 — 악용 칸에는 "내 랩에서" 실제로 해 본 것만 구체적으로 적으세요. 해 보지 않은 것은 "개념"이라고 표시하는 정직함이 이 문서의 신뢰도입니다.

3-6. 워게임 연결 기록

문서의 ## 6 칸에, 여러분이 워게임에서 이 기법을 실제로 쓴 문제를 연결합니다. 예시:

- cron 악용 → Bandit 24: root의 cron이 /var/spool 내 스크립트를 실행.
  누구나 쓸 수 있는 디렉터리에 스크립트를 놓아 다음 레벨 비밀번호를 읽었다.

"이 추상적 기법이 실제 문제에서 이렇게 쓰였다"는 기록이 문서를 암기장이 아니라 경험의 지도로 만듭니다. 아직 풀지 않은 기법은 칸을 비워 두고, 나중에 풀 때마다 추가하세요.

4. 미션과 연습문제

미션 — "리눅스 권한 우회 v1" 문서 완성

3-1의 목차 템플릿으로 시작해 다음 조건을 만족하는 문서를 완성하세요:

1. 우회 지점 4종(setuid/sudo, PATH, 심볼릭 링크, cron)이 각각 조건/발견/악용/방어 4단 구조로 채워져 있다.
2. ### 발견 칸의 명령어는 전부 직접 실행해 봤고, 출력의 일부가 붙어 있다.
3. ## 5. 발견 명령어 모음에 명령이 5개 이상 모여 있다.
4. ## 6. 워게임 연결 기록에 최소 1개의 실제 풀이 경험이 연결되어 있다(없다면 Bandit에서 도전할 문제를 "예정"으로 적는다).
5. 문서 맨 앞 ## 0. 전제에 합법 범위 고지가 있다.

스스로 검증하는 법: 문서만 보고 낯선 리눅스 랩에 접속했을 때 "첫 10분에 무슨 명령을 칠지" 바로 답이 나오면 완성입니다.

연습문제

문제 1. "리눅스 권한 모델은 튼튼한데 권한 상승이 성공한다"는 문장이 모순이 아닌 이유를 설명해 보세요.

문제 2. 4단 프레임(조건/발견/악용/방어) 중에서 실력을 가르는 칸은 어느 것이며, 왜 그런가요?

문제 3. find / -perm -4000 -type f 2>/dev/null의 각 부분(-perm -4000, -type f, 2>/dev/null)이 하는 일을 설명해 보세요.

문제 4. 오늘 만든 문서가 방어자(시스템 관리자)에게도 유용한 이유를, 4단 프레임의 구조와 연결해 설명해 보세요.

[섹션 2] PATH 인젝션

[조건]
- 고권한(sudo/setuid)으로 실행되는 스크립트가 명령을 절대경로 없이 호출
- 내가 쓸 수 있는 디렉터리가 PATH의 앞쪽에 있음

[발견]
- echo $PATH  → 검색 순서 확인 (앞쪽에 /tmp, ~ 등이 있으면 위험)
- 스크립트를 cat으로 읽고 경로 없는 호출(`ls`, `tar` 등)을 찾는다
- sudo -l 로 내가 sudo로 실행 가능한 스크립트 목록 확인

[악용] (내 랩에서 실험함)
- mkdir /tmp/fake && echo 'echo 속았지' > /tmp/fake/ls && chmod +x /tmp/fake/ls
- export PATH=/tmp/fake:$PATH 후 ls → 가짜가 실행됨 (Step 108 실측)

[방어]
- 스크립트에서는 항상 절대경로(/bin/ls)로 호출
- 스크립트 첫줄에 PATH를 고정값으로 초기화
- sudo는 secure_path로 PATH를 초기화함 — 그래서 주 표적은 setuid 스크립트

6. 흔한 실수와 해결

벽 1. find를 돌렸더니 에러가 화면을 덮어요

증상: Permission denied가 수백 줄 쏟아져서 결과를 못 찾겠습니다.
원인: 일반 사용자로는 읽을 수 없는 디렉터리가 많기 때문입니다.
해결: 명령 끝의 2>/dev/null이 바로 그 처리 장치입니다. 빠뜨리지 마세요. 또 전수 조사(find /)는 환경에 따라 수십 초 이상 걸릴 수 있습니다 — 2026-09-09 실측에서도 시간 제한에 걸려 /usr /bin /sbin 범위로 나눠 실행했습니다. 기다리거나 범위를 나누세요.

벽 2. 어디까지가 "정상 setuid"인지 모르겠어요

증상: find -perm -4000 결과에 passwd, sudo가 나와서 "이것도 취약점인가?" 헷갈립니다.
원인: setuid가 원래 필요한 명령이 있습니다. passwd는 내 비밀번호 변경을 위해 시스템 파일을 고쳐야 하므로 setuid가 설계상 필요합니다.
해결: 의심 기준은 "이 프로그램이 왜 root 권한이 필요하지?"입니다. find, vim, python, cp 같은 범용 도구에 붙어 있으면 붉은 깃발입니다. 판단이 서지 않으면 Step 106의 GTFOBins 목록과 대조하세요.

벽 3. 문서를 쓰는데 "악용" 칸을 채울 수가 없어요

증상: 개념은 아는데 직접 해 본 적이 없어 쓸 말이 없습니다.
원인: 정상적인 상태입니다 — 그리고 그것이 이 프로젝트의 메시지입니다.
해결: 두 가지 선택지가 있습니다. 지금 랩이나 Bandit에서 실제로 해 보거나, 못 하겠으면 그 칸에 "개념만 이해, 미실험"이라고 정직하게 표시하세요. 날조된 경험으로 채운 문서는 실전에서 여러분을 배신합니다.

벽 4. 정리가 "남의 치트시트 베끼기"가 돼요

증상: 인터넷의 권한 상승 치트시트를 통째로 복사하고 있습니다.
원인: 빨리 완성하고 싶은 마음은 이해하지만, 그 문서는 남의 경험의 지도입니다.
해결: 규칙을 다시 확인하세요 — 직접 실행한 명령과 출력만 들어갑니다. 분량이 적어도 됩니다. 명령 10개를 직접 쳐 본 문서가 명령 100개를 베낀 문서보다 낯선 서버 앞에서 강합니다.

벽 5. /tmp에서 -writable 검색을 하니 내 파일만 잔뜩 나와요

증상 (2026-09-09 실측): /tmp 아래는 대부분 내가 만든 파일이라 -writable이 전부 검색됩니다.
원인: 당연한 결과입니다 — /tmp는 누구에게나 쓰기가 열린 공간이라 "쓸 수 있는 파일을 찾는" 조건의 의미가 퇴색됩니다.
해결: 실전에서 이 명령의 주 무대는 /etc, /usr/local, cron이 참조하는 스크립트 경로처럼 원래 내가 쓰면 안 되는 곳입니다. "쓸 수 있으면 안 되는 위치에서 쓸 수 있는 파일"을 찾는 눈이 핵심입니다.

7. 정리

오늘의 개념

오늘의 명령어

명령어보다 중요한 감각

오늘 만든 것은 문서이면서 동시에 사고방식입니다. 낯선 리눅스에 올라탔을 때 "여기서 뭘 하지?"가 아니라 "조건이 있는지 확인하자"로 바뀌는 것 — 그것이 취미와 실력의 갈림길입니다.

그리고 이 문서는 완성품이 아닙니다. 파일명의 v1이 약속입니다. 새로운 우회 기법을 배울 때마다, 워게임에서 새 유형을 풀 때마다 같은 틀에 추가하세요. 반년 뒤의 이 문서가 여러분의 실력을 가장 정직하게 보여 주는 이력서가 될 것입니다.

전부 체크되면 Step 110 완료입니다.