yeseul7 님의 블로그

리눅스 기반 시스템 탐색 및 데이터 분석(OverTheWire Bandit)

yeseul7 — Wed, 13 May 2026 15:27:48 +0900

본 실습은 MacBook의 macOS 환경에서 진행하였다.
macOS는 기본적으로 UNIX 기반 터미널 환경을 지원하므로, Windows 환경에서 사용하는 WSL 대신 기본 터미널(zsh)을 활용하여 Bandit 서버에 접속하고 실습을 수행하였다.

Level 0

목표: SSH를 사용하여 게임에 로그인하는 것

포트와, 연결할 호스트, 사용자의 이름, 비밀번호까지 다 주어졌다.

ssh -p 2220 bandit0@bandit.labs.overthewire.org

접속 완료

Level 0 → Level 1

목표: 홈 디렉토리에 있는 readme 파일에서 다음 레벨(bandit1)의 비밀번호를 찾는 것

ls #파일 보기
cat readme #파일의 목록 중 readme 읽기 (파일 읽기)

ls와 같은 명령어를 이용해서 readme 파일의 존재를 확인 후, cat readme를 통해 읽으면 다음 레벨의 password를 찾아볼 수 있게 된다.

문제에서 말했듯 일단 password (ZjLjTmM6FvvyRnrb2rfNWOZOTa6ip5If)를 복사해서 저장해둔다

exit 명령어를 통해 로그아웃 한 뒤 찾은 암호로 다시 접속한다.

Level 1 → Level 2

목표: 홈 디렉토리에 있는 -라는 이름의 파일을 읽어서 다음 레벨 비밀번호를 찾는 것

하지만, 리눅스에서는 -가 특수하게 쓰이기 때문에 cat -를 할 때, 이상하게 작용할 수 있음.

그러므로 ls를 통해 파일명을 확인 한 후, ./를 통해 파일명을 지정하며 알아내야함.

리눅스에서 ./파일명은 현재 폴더 안의 파일이라는 뜻이므로, ./를 이용하면 -도 파일명으로 선택 가능

ls
# - 가 들어있음

cat ./-

263JGJPfgU6LtdEvgfWU1XP5yac29mFx 다음 단계의 비밀번호를 저장해둔 후, 아까와 같이 exit -> 암호로 다시 접속

Level 2 → Level 3

목표: 홈 디렉토리에 있는 spaces in this filename 이라는 파일에서 다음 레벨의 비밀번호를 찾기

파일 이름 안에 공백이 들어가 있는 경우 리눅스에서는 공백을 명령어 인자 구분으로 인식하기 때문에, 공백으로 인해 파일명이 잘려버리는 이슈가 발생. 그러므로 전체를 하나로 묶어주기 위해 ""를 사용하여야만 한다.

ls
cat "./--spaces in this filename--"

실제 파일 이름은 --spaces in this filename-- 이기 때문에, 파일명이 -로 시작할 경우 옵션으로 인식될 수 있으므로, 이전 레벨과 마찬가지로 ./를 사용하여 현재 디렉토리의 파일임을 명확히 지정해주어야 한다.

비밀번호: MNk8KNH3Usiio41PRUEoDFPqfxLPlSmx

Level 3 → Level 4

목표: inhere 디렉토리 안에 있는 숨김 파일(hidden file)에서 다음 레벨의 비밀번호를 찾는 문제

리눅스에서는 . 으로 시작하는 파일을 숨김 파일로 취급하기 때문에, 일반 ls 명령어로는 보이지 않는다.

cd inhere
ls -a
cat ...Hiding-From-You

파일이 inhere 디렉토리 안에 있기 때문에 우선 디렉토리 이동을 할때 쓰는 cd를 통해 이동 후,

ls -a를 통해 숨김 파일까지 확인해야만 한다. -a를 붙이는 이유는, a가 all을 뜻하며, 숨김 파일까지 모두 보여주게 만드는 명령어이기 때문이다.

비밀번호: 2WmrDFRmJIq3IPxneAaMGhap0pFhF3NJ

Level 4 → Level 5

목표: inhere 디렉토리 안에 있는 여러 파일 중, 사람이 읽을 수 있는(human-readable) 파일 하나를 찾아 다음 레벨의 비밀번호를 획득

리눅스에는 텍스트 파일, 뱌이너리 파일, 이미지, 압축 파일 등 다양한 파일이 있지만, 사람이 읽을 수 있는 파일은 정상 문자로 보이는 텍스트로, 사람이 읽을 수 없는 바이너리 파일 같은 것은 깨져 보인다.

cd inhere
ls
file ./*

inhere 디렉토리 안에 있다고 했기 때문에, cd imhere을 통해 디렉토리로 이동, ls를 통해 파일이 무엇이 있는지 확인한 후,

file ./* 명령어를 통해 현재 디렉토리의 모든 파일의 종류를 분석한다.

여기서, file은 이 파일이 어떤 종류인지 분석해주는 명령어이고, *는 모든 파일이라는 뜻이라서, ./*를 해주면 현재 디렉토리의 모든 파일을 의미한다. 그래서 file ./*를 하면 현재 디렉토리의 모든 파일을 어떤 종류인지 분석을 해주게 된다.

-file07이 text 파일로 나타나있기 때문에 cat ./-file07을 해주면,

비밀번호: 4oQYVPkxZOOEOO5pTW81FB8j8lxXGUQw

가 나타나게 된다.

Level 5 → Level 6

목표: inhere 디렉토리 아래 어딘가에 있는 파일 중, 특정 조건을 모두 만족하는 파일을 찾아 다음 레벨의 비밀번호를 획득

특정 조건을 모두 만족하는 파일을 찾아야 하는 문제이다. 즉, 하나씩 찾기보다는 find를 쓰는 것이 출제 의도에 더욱 맞는 풀이이다.

find는 파일을 조건으로 검색하는 명령어이다. -size 등 옵션을 이용해 조건으로 검색을 할 수가 있다.

cd inhere
find . -size 1033c #문제에서 말한 조건, 크기가 정확히 1033 bytes인 파일을 찾기 위함

#size로 파일 크기 검색,
#리눅스에서 c는 bytes를 의미하며,
#.는 현재 디렉토리를 의미한다.

file ./maybehere07/.file2
#나온 ./maybehere07/.file2 파일의 종류를 확인

Level 6 → Level 7

목표: 서버 전체에서 특정 조건을 만족하는 파일을 찾아, 그 안에 저장된 다음 레벨의 비밀번호를 획득

조건은, 소유자가 bandit7 그룹이 bandit6, 파일 크기가 33 bytes여야 한다.

리눅스 파일에는 파일 이름, 크기, 소유자, 그룹, 권한 같은 정보가 있기 때문에 find 명령어를 통해 그중 owner, group, size 조건을 사용해야한다.

주요 옵션은 다음과 같다

-user	파일 소유자
-group	파일 그룹
-size	파일 크기

조건을 추가해본다면,

find / -user bandit7 -group bandit6 -size 33c

여기서 /는 리눅스 루트 디렉토리를 뜻한다. 그러므로 find /는 서버 전체 검색의 의미.

많이 나오는 것 중에 권한 없는 폴더 접근 실패 메시지인 Permission denied가 없는 bandit7.password 파일을 찾았다.

cat /var/lib/dpkg/info/bandit7.password 해서 열어주면

다음과 같은 비밀번호 morbNTDkSW6jIlUc0ymOdMaLnOlFVAaj를 찾을 수 있다.

Level 7 → Level 8

목표: data.txt 파일 안에서 millionth 라는 단어 옆에 있는 값을 찾아 다음 레벨의 비밀번호를 획득

millionth 라는 단어 옆에 있는 값을 찾아야 하기 때문에, 파일 안에서 특정 문자열을 검색하는 명령어인 grep이 필요하다.

grep millionth data.txt

이런 구조를 통해 특정 문자열을 검색할 수가 있게 되는데,

각각의 의미는 다음과 같다.

grep	문자열 검색
millionth	찾을 단어
data.txt	검색 대상 파일

바로 grep을 통해 찾아주면, 다음과 같은 글자가 뜬다. millionth라는 단어가 있는 줄을 찾은 것이고, 그 옆에 비밀번호 값이 있다고 했으니

비밀번호는 dfwvzFQi4mU0wfNbFOe9RoWskMLg7eEc가 된다.

Level 8 → Level 9

목표: data.txt 파일 안에서 단 한 번만 등장하는 줄을 찾아, 그 값을 다음 레벨의 비밀번호로 사용

한 번만 등장하는 줄을 찾아야 하기 때문에 여러 번 반복되는 줄은 제외하고 데이터를 찾아야만 한다.

잘 찾기 위해서 텍스트를 정렬하는 명령어인 sort과 중복 줄 처리 명령어인 uniq가 필요하다.

uniq만 쓰는게 아니라 sort도 함께 쓰는 이유는, uniq는 정렬이 필요하기 때문이다.

uniq는 바로 옆 줄이 같은 경우만 처리 가능하기 때문에 꼭 정렬을 해주어야 한다.

sort data.txt | uniq -u 

#uniq -u는 리눅스에서 한 번만 나온 줄만 출력이라는 의미를 가지고 있고,
#|(pipe)를 통해서 한 명령어 결과를 다음 명령어로 전달하게 된다

각각의 의미를 해석해보면 다음과 같다.

sort data.txt	파일 내용 정렬
\|	명령어 결과를 다음 명령어로 전달
uniq -u	한 번만 나온 줄 출력

비밀번호: 4CKMh1JI91bUIZZPXDqGanal4xvAg0JM

Level 9 → Level 10

목표: data.txt 파일 안의 사람이 읽을 수 있는 문자열 중, 여러 개의 = 문자 뒤에 있는 값을 찾아 다음 레벨의 비밀번호를 획득

사람이 읽을 수 있는 문자열만 추출하는 것이 목표이기 때문에, data.txt가 일반 txt 파일이 아니라 이상한 문자들이 섞인 바이너리 데이터가 있을 것이라고 추측 할 수가 있다.

이럴 때는 어떻게 해야할까? 파일 안에서 사람이 읽을 수 있는 문자열만 추출하는 명령어인 strings을 써보면 된다.

문제에서는 preceded by several '=' characters이라고 했기 때문에, ===== 같은 문자 뒤에 비밀번호가 있을 확률이 높다. 먼저 사람이 읽을 수 있는 문자열 추출하고, 그 뒤에 = 포함 줄을 찾아보는 것이 좋다.

strings data.txt

이 명령어만 사용해도

내리다 보면 비밀번호로 추측할 수 있는 줄이 나타나지만, 더 확실히 알기 위해서

strings data.txt | grep ==

을 통해서 특정 문자열을 검색해본다.

the password is FGUW5ilLVJrxX9kMYMmlN4MgbpfMiqey.

즉, 비밀번호는 FGUW5ilLVJrxX9kMYMmlN4MgbpfMiqey이다.

Level 10 → Level 11

목표: data.txt 파일 안에 Base64로 인코딩된 데이터가 들어 있으며, 이를 디코딩해서 다음 레벨의 비밀번호를 찾기

인코딩된 문자열을 원래 내용으로 되돌려야 하는데, 여기 나오는 Base64는 암호화가 아니라 인코딩이기 때문에, 데이터를 사람이 복사하거나 전송하기 쉬운 문자 형태로 바꿔둔 것이라고 생각하면 된다.

cat data.txt

cat을 통해 열어보면

다음과 같은 문자열이 있는데, 끝에 = 또는 ==가 붙어 있으면 Base64일 가능성이 높아진다.

base64 -d data.txt #Base64를 디코딩

-d 옵션을 통해 디코딩 해주면

비밀번호 dtR173fZKb0RRsDFSGsg2RWnpNVj3qRr가 된다.

Level 11 → Level 12

목표: data.txt 파일 안에 있는 문자는 알파벳이 13칸씩 밀려 있는 상태. 이를 원래대로 되돌려 다음 레벨의 비밀번호를 찾기

이 문제를 풀기 위해선 ROT13에 대해서 알아야한다.

ROT13은 알파벳을 13칸씩 밀어서 바꾸는 방식으로, 한 번 더 ROT13을 적용하면 원래 문자로 돌아온다는 특징이 있다.

lowercase(a-z)와 uppercase(A-Z)가 13 positions rotated라고 적혀있기 때문에, A-Z와 a-z를 둘 다 처리해야하고, 치환을 위해 특정 문자들을 다른 문자들로 바꿔주는 명령어인 tr이 쓰이게 된다.

cat data.txt | tr 'A-Za-z' 'N-ZA-Mn-za-m'

각각의 의미는 다음과 같다.

cat data.txt	data.txt 내용 출력
\|	명령어의 결과를 뒤로 넘김
tr	문자 치환
'A-Za-z'	대문자 A-Z, 소문자 a-z 전체
'N-ZA-Mn-za-m'	13칸 밀린 알파벳 순서

비밀번호: 7x16WNeHIi5YkIhWsfFIqoognUTyj9Q4

12 → Level 13

목표: data.txt 파일은 어떤 파일을 hexdump 형태로 바꿔놓은 것, 그 원본 파일은 여러 번 압축되어 있는데, 이 hexdump를 다시 원래 파일로 복구한 뒤, 압축을 여러 번 풀어서 다음 레벨의 비밀번호를 찾기

data.txt는 파일 내용을 16진수 형태로 보여주는 hexdump의 형태라고 한다. 실제 압축 파일이 아니라, 압축 파일을 사람이 볼 수 있는 16진수 텍스트로 바꿔둔 상태라는 뜻. hexdump를 원래 바이너리 파일로 되돌리는 것이 중요하다.

우선, 명령어를 통해 원래 바이너리 파일로 되돌리고 /tmp 아래에 작업용 디렉토리를 만들어서 거기서 작업하라고 안내하고 있기 때문에

mktemp -d

명령어를 통해 임시 디렉토리를 만든다. 여기서 임시 디렉토리를 만드는 이유는, 압축을 여러 번 풀게 되면 파일 이름도 바꾸고 새 파일도 생기기 때문에 Bandit 홈 디렉토리에서 마음대로 파일을 만들거나 수정하기 힘들 수도 있어서이다.

다음과 같은 임시 디렉토리가 만들어지면

cd /tmp/tmp.To4YfkYWCb

cd를 통해 그곳에 들어가고,

cp ~/data.txt .

#cp(copy) : cp 원본파일 복사할 위치 형식으로 쓰인다.
#~는 현재 로그인한 bandit12의 홈 디렉토리
#.은 현재 디렉토리

명령어를 통해 홈 디렉토리에 있는 data.txt를 현재 작업 폴더로 복사한다.

ls로 파일이 있는 것을 확인해준 뒤,

xxd -r data.txt data

#xxd는 파일을 hex dump 형태로 보여주거나, 반대로 hex dump를 원래 바이너리 파일로 되돌리는 명령어
#-r은 reverse, 되돌리기라는 뜻

다음과 같은 명령어를 통해서 hexdump을 복구한다. 이후 file data를 통해 어떤 압축을 풀어야 하는지 확인을 해보면,

gzip 압축 파일임을 확인할 수 있게 된다. 그 이후

mv data data.gz #.gz여야 풀기 편하기 때문에 mv를 통해 이름 변경
gzip -d data.gz #압축 해제
file data #어떤 종류의 파일인지 확인

file로 종류 확인하고, 맞는 압축 해제 명령어 사용 후 다시 file로 확인하는 과정을 반복하면 된다.

마지막 text 파일 확인 후 cat을 하면 드디어 비밀번호를 알 수가 있다.

비밀번호: FO5dwFsc0cbaIiH0h8J2eUks2vdTDwAn

Level 13 → Level 14

목표: 다음 레벨의 비밀번호는 /etc/bandit_pass/bandit14에 저장되어 있지만, 해당 파일은 bandit14 사용자만 읽을 수 있다. 이번 레벨에서는 비밀번호 대신 다음 레벨에 접속할 수 있는 SSH 개인키가 제공. SSH 개인키를 받기.

비밀번호 대신 SSH key를 이용해서 로그인해야 하기 때문에, 우선 key가 있는 파일을 찾아야한다.

ls를 통해 파일을 살펴보면 sshkey.private라는 파일을 찾을 수 있다.

현재 환경에서 시도해본 결과 Bandit 서버 내부에서 localhost로 다시 접속하는 방식이 차단되어 있었다. 따라서 sshkey.private 파일의 내용을 로컬 Mac 환경에 저장한 뒤, 해당 개인키를 사용하여 외부에서 bandit14 계정으로 접속하는 방식으로 진행하였다.

cat sshkey.private

보이는 key값을 복사해둔 뒤에 exit한 후, mac에서 키 파일을 만든다.

nano ~/bandit14.key #nano는 터미널에서 쓰는 간단한 텍스트 편집기이다.

nano	터미널에서 쓰는 간단한 텍스트 편집기
~	내 홈 디렉토리
/	경로 구분자
bandit14.key	만들거나 열 파일 이름

홈 디렉토리에 있는 bandit14.key 파일을 nano로 열고, 파일이 없으면 새로 만들어주는 명령어가 된다.

안으로 돌아가 키를 붙여넣어주고,

SSH 개인키 파일은 인증 정보이기 때문에 권한이 과도하게 열려 있으면 SSH에서 사용을 거부할 수 있다. chmod 600 ~/bandit14.key 명령어를 사용해서 개인키 파일의 권한을 소유자만 읽고 쓸 수 있는 상태로 제한해주었다.

chmod 600 ~/bandit14.key 
#chmod는 파일 권한을 변경하는 명령어
#600 소유자만 읽기/쓰기 가능, 다른 사용자는 접근 불가

ssh -i ~/bandit14.key -p 2220 bandit14@bandit.labs.overthewire.org

다음과 같이 개인키 파일을 이용해 접속을 시도하면

다음과 같이 비밀번호 입력 없이 드디어 bandit14 계정으로 접속할 수 있다.

Level 14 → Level 15

목표: 현재 레벨의 비밀번호를 localhost의 30000번 포트로 제출해 다음 레벨의 비밀번호를 획득.

우선 현재 레벨의 비밀번호에 대해 알아보았다.

이전 레벨의 설명에서 bandit14의 비밀번호가 `/etc/bandit_pass/bandit14`에 저장되어 있으며, bandit14 사용자만 읽을 수 있다고 안내되어 있었다. SSH 개인키를 이용해 bandit14 계정으로 접속한 뒤에는 해당 파일을 읽을 권한이 생기므로, 먼저 현재 레벨의 비밀번호를 확인하였다.

cat /etc/bandit_pass/bandit14

이번 문제를 풀기 위해선 특정 호스트와 포트에 연결해서 데이터를 주고받는 도구인 nc(netcat)에 대해서 알아야 했는데, localhost의 30000번 포트에 현재 레벨의 비밀번호를 보내야 하므로, 다음과 같이 명령어를 입력하였다.

nc localhost 30000

#localhost = 현재 접속 중인 Bandit 서버 자기 자신
#30000 = 비밀번호를 제출해야 하는 포트 번호

이 명령어를 사용하게 되면 다음과 같이 입력을 기다리는 상태가 되는데 그때 앞에서 확인한 현재 레벨의 비밀번호를 입력하면 서버가 이를 확인하고, 다음 레벨의 비밀번호를 응답으로 출력하게된다.

비밀번호: 8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo

Level 15 → Level 16

목표: 현재 레벨의 비밀번호를 localhost의 30001번 포트로 제출하되, SSL/TLS 암호화 연결을 사용하여 다음 레벨의 비밀번호를 획득

현재 비밀번호는 8xCjnmgoKbGLhHFAZlGE5Tmu4M2tKJQo로 이미 앞선 단계에서 얻어놨다.

이번 문제에서는 nc 대신 SSL/TLS가 적용된 서버에 접속해서 데이터를 주고받을 수 있게 해주는 명령어인 openssl s_client를 이용해야 하는데,

openssl s_client -connect localhost:30001

다음과 같은 명령어로 이용할 수가 있다.

각각의 의미를 해석해보면 다음과 같다.

openssl	SSL/TLS 관련 기능을 제공하는 명령어
s_client	SSL/TLS 서버에 클라이언트처럼 접속하는 기능
-connect	접속할 대상 서버와 포트를 지정
localhost:30001	현재 서버의 30001번 포트에 접속

앞선 문제와 같이, 입력 대기를 기다리는 상태에서 현재 비밀번호를 입력해주면 다음 문제의 비밀번호가 나오게 된다.

비밀번호: kSkvUpMQ7lBYyCM4GBPvCvT1BfWRy0Dx

Level 16 → Level 17

목표: 현재 레벨의 비밀번호를 localhost의 31000~32000 범위 안에 있는 포트 중 하나에 제출하여, 다음 레벨 접속 정보를 획득

이번 문제는 적혀있는 그대로, 31000~32000 포트 중 실제로 서버가 열려 있는 포트를 찾고, 그중 SSL/TLS 통신을 사용하는 포트를 찾은 후, 현재 비밀번호를 보냈을 때 다음 인증 정보를 돌려주는 포트를 찾아야 한다.

포트 범위를 알아내는 과정에서 nmap이라는 스캔 도구가 이용이 된다.

nmap은 특정 서버에서 어떤 포트가 열려 있는지 확인하는 포트 스캔 도구이다.

nmap -sV -p 31000-32000 localhost
#-sV: 열린 포트에서 동작하는 서비스의 종류/버전을 확인하는 옵션

이러한 구조로 이뤄지는데, 명령어를 해석하면 다음과 같다.

nmap	포트 스캔 도구
-sV	열린 포트의 서비스 정보를 확인
-p 31000-32000	31000번부터 32000번까지 검사
localhost	현재 접속 중인 Bandit 서버 자기 자신

결과를 확인해보면,

여기서 echo는 보낸 값을 그대로 다시 돌려주는 서비스이기 때문에, 문제에서 나머지는 보낸 값을 그대로 돌려준다고 했으니, echo들은 정답이 아니다. 31518은 ssl/echo라서 SSL은 쓰지만, 결국 echo 서비스라 정답이 아닐 가능성이 크고,

남은 것은 31790/tcp open ssl/unknown이 된다. SSL/TLS를 사용하지만 echo 서비스는 아닌 포트가 하나 뿐이기 때문.

openssl s_client -quiet -connect localhost:31790

#-quiet: 연결 과정에서 나오는 불필요한 출력이나 일부 안내 메시지를 줄이는 옵션
#-connect: 접속할 대상 서버와 포트를 지정하는 옵션

다음으로, 앞선 문제에서 배웠던 openssl s_client를 이용하여 서버에 접속하면 입력 대기가 뜨게 되고, 그곳에 현재 비밀번호를 입력한다.

Level 13 -> 14 때처럼 SSH 개인키가 나오기 때문에, 이전과 똑같은 방식으로 풀이를 진행.

exit
nano ~/bandit17.key #키 파일 생성
chmod 600 ~/bandit17.key
ssh -i ~/bandit17.key -p 2220 bandit17@bandit.labs.overthewire.org

Level 17 → Level 18

목표: 홈 디렉토리에 passwords.old와 passwords.new 두 파일이 있고, 두 파일 사이에서 변경된 유일한 줄이 다음 레벨의 비밀번호. 두 파일의 차이 비교.

ls를 통해 파일을 확인하면 두개의 파일이 보인다.

이때, diff라는 두 파일의 차이점을 비교해서 보여주는 명령어를 사용하면 되는데

diff passwords.old passwords.new

다음과 같이 사용하면 된다.

diff	두 파일의 차이점을 비교하는 명령어
passwords.old	비교 기준이 되는 이전 파일
passwords.new	변경된 내용이 들어 있는 새 파일

> 줄이 passwords.new의 변경된 줄을 의미하기 때문에, 비밀번호는 x2gLTTjFwMOhQ8oWNbMN362QKxfRqGlO이 된다.

Level 18 → Level 19

목표: 다음 레벨의 비밀번호는 홈 디렉토리의 readme 파일에 저장되어 있다. 하지만 .bashrc 파일이 수정되어 있어서 SSH로 로그인하면 바로 로그아웃되는 것을 우회해야 한다.

비밀번호를 치자마자 나가지는 것이 보인다. 정상 로그인해서 명령어를 입력하는 방식이 막혀 있으니, SSH 접속과 동시에 명령어를 실행하는 방법을 사용해야 한다.

SSH는 단순히 로그인만 하는 게 아니라, 접속하면서 원격 명령어를 바로 실행할 수가 있고, 문제에서 비밀번호가 readme 파일에 있다고 했으니까, 접속하면서 바로 cat readme를 실행하면 된다.

ssh -p 2220 bandit18@bandit.labs.overthewire.org cat readme

실행해보면 다음과 같이 password가 뜨는 것을 볼 수가 있다.

비밀번호: cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

Level 19 → Level 20

다음 레벨에 접근하기 위해 홈 디렉토리에 있는 setuid binary를 사용해야 한다.
이 파일을 인자 없이 실행하면 사용 방법을 알 수 있고, setuid binary를 사용한 뒤 /etc/bandit_pass에서 이번 레벨의 비밀번호를 확인할 수 있다.

ls -l

우선 ls-l 를 사용해 파일을 자세히 봐본다.

bandit20-do 실행 파일이 보이는데, 문제에서 인자 없이 실행해보라고 했으니

./bandit20-do

우선 실행을 해본다.

Example: ./bandit20-do id라며 사용법이 출력되게 되는데, 이 사용법을 토대로 실행할 명령어를 붙이면

./bandit20-do cat /etc/bandit_pass/bandit20

이런 명령어가 되고, 각각 해석해보면 다음과 같은 뜻을 가진다.

setuid	실행 파일을 파일 소유자의 권한으로 실행하게 하는 권한
ls -l	파일 권한과 소유자 정보를 자세히 확인
./파일명	현재 디렉토리의 실행 파일 실행
/etc/bandit_pass/bandit20	bandit20 비밀번호 파일 위치

setuid가 걸린 실행 파일을 이용해 bandit20 권한으로 명령을 실행하고, 다음 레벨 비밀번호 파일을 읽게 되는 것이다.

비밀번호는 0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO이 된다.

Level 20 → Level 21

목표: 홈 디렉토리에 있는 setuid binary는 사용자가 지정한 포트로 localhost에 연결한 뒤, 연결된 곳에서 한 줄의 텍스트를 읽고, 그것이 현재 레벨인 bandit20의 비밀번호와 일치하면 다음 레벨인 bandit21의 비밀번호를 전송.

문제를 요약해보면 먼저 서버 역할을 하는 포트를 열어두고, setuid binary가 그 포트로 접속하게 만들면 되는 것인데, 이전 문제들은 어떤 서버에 접속해서 비밀번호를 보내는 방식이었지만, 이번 문제는 반대로 네트워크 연결을 기다리는 쪽과 접속하는 쪽을 직접 구성해야한다.

우선 ls -l을 이용해서 파일을 보고 이번에는 nc를 서버처럼 사용하도록 명령어를 구성해야 한다.

echo "0qXahG8ZjOVMN9Ghs7iOWsCfZyXOUbYO" | nc -l -p 12345 &

#nc -l -p 12345는 해당 포트에서 연결을 기다리는 서버처럼 동작하게 됨

다음과 같은 명령어가 되는데, 각 부분의 의미는 다음과 같다


echo "비밀번호"	현재 비밀번호를 출력
nc -l -p 12345	12345번 포트에서 연결을 기다림
&	이 명령어를 백그라운드에서 실행

실행한 후 바로 ./suconnect 12345를 통해 실행을 해주면, suconnect가 localhost:12345로 접속해서 nc가 보내는 비밀번호를 읽고, 맞으면 bandit21 비밀번호를 출력하게 된다.

비밀번호: EeoULMCra2q0dSkYj561DX7s1CpBuOBt

Level 21 → Level 22

목표: cron이라는 시간 기반 작업 스케줄러에 의해 어떤 프로그램이 주기적으로 자동 실행되고 있다. /etc/cron.d/ 디렉토리에서 설정 파일을 확인하고, 어떤 명령어가 실행되는지 알아내기.

우선

ls /etc/cron.d/

명령어를 통해 파일을 확인해본다.

bandit22와 관련된 cron 설정 파일을 찾아야 하는데, 파일을 살펴보면 cronjob_bandit22이라는 파일이 보인다.

cat /etc/cron.d/cronjob_bandit22

다음과 같은 명령어를 통해 확인해보면

설정 파일을 볼 수 있는데, 여기서 * * * * *는 실행 주기를 의미하고, bandit22 /usr/bin/cronjob_bandit22.sh는 bandit22 사용자 권한으로 /usr/bin/cronjob_bandit22.sh 스크립트를 실행한다는 뜻이다.

스크립트 경로를 찾았기 때문에, cat을 통해 한번 더 읽어서 확인을 해본다.

cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv은

bandit22 비밀번호를 읽어서 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv에 저장한다는 뜻이기 때문에

cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv

cat을 통해 파일을 확인 해주면

다음과 같이 비밀번호 tRae0UfB9v0UzbCdn9cY0gQnds9GF58Q가 나온다.

Level 22 → Level 23

목표: 이번에도 cron에 의해 어떤 프로그램이 주기적으로 자동 실행되고 있다. /etc/cron.d/ 디렉토리에서 설정 파일을 확인하고, 실제로 어떤 명령어가 실행되는지 분석.

이번에는 한 단계 더 나아가서, 단순히 스크립트를 따라가는 것뿐만 아니라 스크립트가 어떤 파일 이름을 만들고, 어디에 비밀번호를 저장하는지 이해해야 하는 문제이다. 문제에서 다른 사람이 작성한 shell script를 읽는 것은 매우 유용한 능력이라고 하고 있기 때문에, 이번 문제의 핵심은 쉘 스크립트를 읽고 동작을 해석하기가 된다.

ls /etc/cron.d/

ls를 통해서 bandit23과 관련된 파일을 찾고

cronjob_bandit23파일을 확인 후

cat /etc/cron.d/cronjob_bandit23

이전 문제처럼 cat을 통해 실제로 실행되는 스크립트 경로를 확인한다.

이전 문제에서 말했듯 * * * * *는 실행 주기를 의미하기 때문에, 매분 bandit23 사용자 권한으로 /usr/bin/cronjob_bandit23.sh를 실행한다는 뜻이 된다.

cat /usr/bin/cronjob_bandit23.sh

스크립트 내용을 확인해보면

다음과 같은 내용이 들어있는데, 각각의 의미를 해석해보면 다음과 같다.

#!/bin/bash	이 파일이 bash 쉘로 실행되는 스크립트임을 의미한다.
myname=$(whoami)	현재 스크립트를 실행하는 사용자 이름을 myname 변수에 저장한다. cron 설정에서 이 스크립트는 bandit23 권한으로 실행되므로, myname에는 bandit23이 들어간다.
mytarget=$(echo I am user $myname \| md5sum \| cut -d ' ' -f 1)	I am user bandit23이라는 문자열을 만들고, 이를 MD5 해시값으로 변환한 뒤, 해시값 부분만 잘라 mytarget 변수에 저장한다.
echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget"	어떤 비밀번호 파일을 어디로 복사하는지 안내 메시지를 출력한다.
cat /etc/bandit_pass/$myname > /tmp/$mytarget	/etc/bandit_pass/bandit23 파일의 내용을 /tmp/해시값 파일로 저장한다. 즉, 이 파일 안에 다음 레벨 비밀번호가 들어 있다.

이어서 생각해보면, 이 스크립트는 실행 사용자의 이름을 기준으로 해시값을 생성하고, 해당 해시값을 파일명으로 사용하여 /tmp 디렉토리에 비밀번호 파일 내용을 저장한다. cron에 의해 bandit23 권한으로 실행되므로, 결과적으로 /etc/bandit_pass/bandit23의 내용이 /tmp/$mytarget에 저장된다는 뜻이다.

그 다음 스크립트에서 쓰는 해시값을 직접 계산해야 하는데

echo I am user bandit23 | md5sum | cut -d ' ' -f 1

다음과 같은 명령어를 통해 계산해볼 수가 있다.

각 부분은 다음과 같은 의미를 가진다

echo I am user bandit23	해시 계산에 사용할 문자열 출력
md5sum	입력 문자열의 MD5 해시값 계산
cut -d ' ' -f 1	공백 기준으로 첫 번째 값, 즉 해시값만 추출
/tmp/해시값	cron 스크립트가 비밀번호를 저장하는 파일 경로
cat /tmp/해시값	해당 파일 내용을 출력

계산으로 나온 해시값을 확인한 이후

cat /tmp/8ca319486bfbbc3663ea0fbe81326349

다음과 같은 명령어를 수행해주면

다음 레벨의 비밀번호인 0Zf11ioIjMVN551jX3CmStKLYqjk54Ga가 나오게 된다.

Level 23 → Level 24

이번에도 cron에 의해 어떤 프로그램이 주기적으로 자동 실행되고 있다.
/etc/cron.d/에서 cron 설정을 확인하고, 실제로 어떤 명령어가 실행되는지 분석해야 한다.
이번 레벨에서는 직접 shell script를 만들어야 하며, 실행된 스크립트는 삭제될 수 있으므로 복사본을 따로 보관하는 것이 좋다는 것이 문제의 설명이다.

ls /etc/cron.d/
cat /etc/cron.d/cronjob_bandit24

다음과 같은 명령어를 통해 cron이 실제로 어떤 스크립트를 실행하는지 살펴본다.

cat /usr/bin/cronjob_bandit24.sh

명령어를 통해서 cron이 실행하는 스크립트 확인해보면,

다음과 같은 스크립트가 실행중임을 알 수가 있고, 이 스크립트는 `/var/spool/bandit24/foo` 안에 있는 파일들을 자동으로 실행하고 삭제한다. 다만 아무 파일이나 실행하는 것이 아니라, 소유자가 `bandit23`인 일반 파일만 실행한다. 따라서 bandit23 사용자인 내가 만든 스크립트를 이 디렉토리에 넣으면 cron이 주기적으로 실행해줄 수 있다.

스크립트의 내용을 하나씩 뜯어보면 다음과 같다.

myname=$(whoami)	현재 스크립트를 실행하는 사용자 이름을 저장
cd /var/spool/"$myname"/foo	/var/spool/bandit24/foo 디렉토리로 이동
for i in * .*	디렉토리 안의 일반 파일과 숨김 파일을 순회
owner="$(stat --format "%U" ./$i)"	각 파일의 소유자 확인
[ "${owner}" = "bandit23" ] && [ -f "$i" ]	소유자가 bandit23이고 일반 파일인지 검사
timeout -s 9 60 "./$i"	조건을 만족하면 파일을 최대 60초 동안 실행
rm -rf "./$i"	실행 후 파일 삭제

bandit24 비밀번호를 직접 읽을 권한이 없는 상황이지만, cron은 bandit24 권한으로 실행될 가능성이 높기 때문에 직접 만든 스크립트 안에

cat /etc/bandit_pass/bandit24 > /tmp/내파일

처럼 적어두면, cron이 bandit24 권한으로 실행하면서 비밀번호를 /tmp/내파일에 저장해줄 수 있게 된다.

mktemp -d

명령어를 사용하게 되면 나의 작업 파일이 생기고,

cd /tmp/tmp.3h9KF69UC2

cd를 통해 나의 작업 파일으로 이동 후

touch result.txt #결과를 저장할 빈 파일 생성
chmod 666 result.txt #cron이 실행하는 bandit24 사용자도 이 파일에 쓸 수 있게 권한 설정

결과물을 받을 파일을 만든다.

nano script.sh
#nano를 통해 열어서

#!/bin/bash
cat /etc/bandit_pass/bandit24 > /tmp/tmp.3h9KF69UC2/result.txt

#다음과 같은 내용을 넣는다

이 때, 파일에 실행 권한을 부여하는 명령어인 chmod을 사용해야 한다. cron이 shell script를 실행하려면, 그 파일이 실행 가능한 상태여야 하기 때문이다.

chmod +x script.sh

다음 명령어를 통해 실행 권한을 준 뒤,

cp script.sh /var/spool/bandit24/foo/

cp를 통해 cron이 실행하는 폴더로 복사하면 된다.

그 이후 cat명령어를 사용해 봐보면 다음과 같은 비밀번호가 뜬다

비밀번호: gb8KRRCsshuZXI0tUuR6ypOFjiZbf3G8

Level 24 → Level 25

30002번 포트에서 데몬이 실행 중이며, bandit24 비밀번호와 4자리 숫자 PIN을 함께 보내면 bandit25 비밀번호를 얻을 수 있는 문제이다. PIN은 직접 알아낼 수 없고, 0000부터 9999까지 모든 조합을 시도하는 brute-forcing 방식으로 찾아야 한다.

4자리 PIN을 자동으로 전부 대입해보는 문제이지만, 직접 하나 하나 치면 너무너무 오래 걸리게 된다. 반복문을 사용한 스크립트를 만들어야 하는데, 문제에서 말한 brute-forcing은 가능한 모든 경우의 수를 하나씩 시도하는 방식이라

4자리 숫자 PIN은 0000부터 9999까지 총 10,000개 경우가 있다.

mktemp -d
cd /tmp/tmp.MFrtARLWW9

우선 출력이 많을 수 있으니까 /tmp에 작업 디렉토리를 만들고 이동.

브루트포싱 스크립트 생성해야 하기 때문에

nano bforce.sh

nano를 통해 생성한다.

#!/bin/bash

PASSWORD=$(cat /etc/bandit_pass/bandit24)

for pin in {0000..9999}
do
    echo "$PASSWORD $pin"
done | nc localhost 30002 > result.txt

스크립트의 내용은 다음과 같이 작성하였는데, 각각 명령어를 해석해보면 다음과 같다.

#!/bin/bash	이 파일을 bash 쉘로 실행하겠다는 의미이다.
PASSWORD=$(cat /etc/bandit_pass/bandit24)	현재 레벨인 bandit24의 비밀번호를 읽어 PASSWORD 변수에 저장한다.
for pin in {0000..9999}	0000부터 9999까지의 모든 4자리 PIN을 하나씩 대입하며 반복한다.
do ... done	반복문에서 실행할 명령어 범위를 나타낸다.
echo "$PASSWORD $pin"	bandit24비밀번호 PIN 형태의 문자열을 출력한다.
\| nc localhost 30002	반복문에서 만들어진 입력값들을 localhost의 30002번 포트로 전송한다.
> result.txt	서버에서 돌아오는 응답을 화면에 출력하지 않고 result.txt 파일에 저장한다.

문제에서 매번 새 연결을 만들 필요는 없다고 했기 때문에, nc 연결을 반복해서 10000번 만드는 대신, 반복문에서 생성한 입력값 전체를 한 번에 nc localhost 30002로 전달하였다.

chmod +x bforce.sh
./bforce.sh

chmod를 통해 권한을 부여하고, ./bforce.sh로 현재 디렉토리에 있는 bforce.sh 파일을 실행.

대부분의 잘못된 PIN에 대해서는 서버가 Wrong!과 같은 실패 메시지를 반환하기 때문에,

grep -v "Wrong" result.txt

grep -v "Wrong"을 사용하여 Wrong이 포함된 줄을 제외하고 출력해보면

다음과 같은 비밀번호 iCi86ttT4KSNe1armKiwbQNmB3YJP3q4가 나오는 것을 볼 수가 있다.

Git 기본 명령어 배우기

yeseul7 — Mon, 11 May 2026 06:39:16 +0900

1. Git commit

프로젝트의 스냅샷들. 매우 가볍고 커밋 사이의 전환도 매우 빠르다. Git 자체에서 가능한 한 커밋을 가볍게 유지하고자 하기때문에, 커밋할 때마다 디렉토리 전체를 복사하진 않음. 각 커밋은 저장소의 이전 버전과 다음 버전의 변경내역(delta)을 저장.

2. git branch

특정 커밋에 대한 참조, 하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역이다. 커밋을 가리키고 있는 이름표.

3. git checkout [브랜치명]

현재 작업 위치(브랜치나 커밋)를 다른 곳으로 이동하는 명령어이다. 변경분을 커밋하기 전에 새 브랜치로 이동하게 만들어준다.

git branch bugFix
git checkout bugFix

branch를 통해 새 브랜치를 생성하고, 이후 checkout로 bugFix 브랜치로 이동한 것이다.

4. git merge

git checkout main
git merge bugFix

별도의 브랜치를 합치는 방법 중 하나. 두 개의 부모를 가리키는 커밋을 만들게 됨. 두개의 부모가 있는 커밋이라는 것은 "한 부모의 모든 작업내역과 나머지 부모의 모든 작업, 그리고 그 두 부모의 모든 부모들의 작업내역을 포함한다"라는 의미가 있음. 현재 위치한 브랜치에 다른 브랜치의 커밋 내용을 가져와 병합함.

5. git rebase

git rebase main

한 브랜치의 커밋들을 다른 브랜치 뒤에 다시 이어붙이는 명령어. 기존 커밋을 그대로 합치는 merge와 달리, 커밋 기록을 새로 정리해 히스토리를 깔끔하게 만든다. 새로 시작 위치를 옮기는 것. 주로 브랜치를 최신 상태로 맞추거나, 불필요한 분기 없이 일직선 형태의 커밋 기록을 만들 때 사용함.

6. HEAD에 대하여

현재 작업 중인 커밋을 나타내는 것이다.
브랜치나 특정 커밋을 기준으로 현재 내가 어느 위치에서 작업하고 있는지를 보여준다.
또한 상대참조(~<num>, ^, ^^ 등)를 통해 이전 커밋으로 이동하거나 특정 시점의 커밋을 쉽게 참조할 수 있다.

git checout bugFix^ #bugFix 부모의 커밋으로 한칸 이동

# ~연산자. 올라가고 싶은 부모의 개수를 표시

git checkout HEAD~4 #4개 부모 커밋으로 이동
git branch -f main HEAD~3 #main 브랜치를 현재 HEAD 기준 3개의 부모 커밋 이전 위치로 강제 이동

branch를 강제로 옮길 때 가장 주의해야 하는 점은, -f(force)를 반드시 써야 한다는 것이다. 브랜치 자체가 강제로 이동되기 때문에 최신 커밋 연결이 끊기거나 기록을 잃어버릴 수도 있는 위험성이 존재하기 때문에, git에서 -f를 요구하게 된다.

즉, 구조가

git branch -f 브랜치이름 이동할위치

가 된다.

7. git reset

브랜치가 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌리는 명령어. 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것.

git reset HEAD~1 #예시

8. git revert

각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 리셋(reset)을 잘 쓸 수 있지만, 다른 사람이 작업하는 리모트 브랜치에는 쓸 수 없음.

(히스토리를 고쳐쓰기 때문)

리모트 브랜치에서 사용 가능한, 이루어진 작업을 반대로 수행하는 새 커밋을 만드는 방법

git revert HEAD

9. git cherry-pick

git cherry-pick <commit1> <commit2> <...>

현재 위치(HEAD) 아래에 있는 일련의 커밋들에 대한 복사본을 만드는 것.

개별 커밋을 골라서 HEAD위에 떨어뜨릴 수 있다. (단, 그 커밋이 현재 가리키고 있는 커밋이 아니어야함)

10. git rebase -i

git rebase -i HEAD~4

인터렉티브 리베이스(rebase 명령어를 사용할 때 -i 옵션 같이 사용) 옵션을 추가하면, 해시를 몰라도 사용 가능하게 해준다.

커밋 순서 바꾸기와, 빼기, squash(여러 커밋 합치기) 등을 할 수가 있다. 어떤 커밋을 취하거나 버릴지를 선택할 수 있고, 커밋의 순서를 바꿀 수도 있기 때문에 어떤 작업의 일부만 골라내기에 유용하다.

11. git commit --amend

git commit -m "helo" #오타
git commit --amend -m "hello" #수정

방금 한 커밋을 정정할 수 있게 만들어주는 명령어.

다음의 예시와 같이 커밋을 수정할 수가 있다.

12. git tag

git tag v1 C1

태그의 이름을 v1으로 짓고, 커밋 C1을 지정해서 참조했다고 해석하면 된다.

tag는 커밋들이 추가로 생성되어도 절대 움직이지 않고, 커밋 트리에서 특정 지점을 표시하기 위한 영구적인 이정표 같은 역할을 하게 된다.

13. git describe

git describe <ref>

가장 가까운 태그에 비해 상대적으로 어디에 위치해있는지 묘사(describe)해주는 명령어.

여기서, ref에는 commit을 의미하는 그 어떤 것이든 쓸 수 있다. 특정 지어주지 않다면 그냥 지금 체크 아웃된 곳(HEAD)을 사용한다.

<tag>-<numCommits>-g<hash>

출력은 다음과 같은 형식으로 이루어지며, tag는 가장 가까운 부모 태그를, numCommits은 그 태그가 몇 커밋 멀리있는지를, <hash>는 묘사하고있는 커밋의 해시를 나타낸다.

14. ^ 수식

git checkout main^2

병합이 된 커밋에서 참조 할 부모를 선택할 수 있는 수식. 보통 첫 부모를 따라가지만, ^수식을 숫자와 함께 사용하면 디폴트 동작이 아닌 선택한 동작대로 결과가 실행된다.

git checkout HEAD~^2~2

이런식으로 섞어서도 사용 가능하다.

원격 저장소

1. git clone

git clone <원격 저장소의 url>

원격 저장소의 복사본을 로컬에 생성할 때 사용하는 명령어.

2. git fetch

git fetch
git fetch origin foo #원격 저장소의 foo 브랜치로 가서 로컬에 없는 커밋들을 가져와 로컬의 o/foo 브랜치에 추가

git fetch <source>:<destination> 
#<source>에 받아올 커밋이 있는 원격에 있는 place
#<destination>에 그 커밋을 받아올 로컬의 place

git fetch origin :bugFix #리소스 인자를 없음으로 지정. 로컬에 새 브랜치를 만듦

원격 저장소(origin)의 최신 내용을 로컬로 가져오기만 하는 명령어.

fetch를 해야만 origin/main도 최신으로 갱신이 된다.

원격 저장소에 있지만 로컬에 없는 커밋을 다운로드 받고, 원격 브랜치가 가리키는 곳을 업데이트 하게 된다.

3. git pull

git pull

#git pull origin foo = git fetch origin foo; git merge o/foo
#git pull origin bar:bugFix = git fetch origin bar:bugFix; git merge bugFix

#커밋이 도착하는 곳을 신경 씀. fetch를 하며 지정된 destination인자의 위치로 merge가 수행).

원격 저장소의 변경을 fetch하고 그 이후 merge하는 작업의 과정을 한번에 하는 명령어.

본질적으로 git fetch 후에 내려받은 브랜치를 병합하는 과정을 단축하게 된다.

4. git push

git push #매개변수 없이 사용하는 디폴트 행동은 ush.default라 불리는 git의 설정에 따라 결정이 된다.
git push <remote> <place> #인자를 지정해서 어디서부터 커밋이 오고, 어디로 가야하는지 지정

#ex) git push origin main

git push origin <source>:<destination> #콜론 참조스펙. source는 git이 알아낼 수 있는 위치를 이름 붙여 말함
#source와 destination을 따로 지정

git push origin :side #리소스 인자를 없음으로 지정. 원격 저장소의 브랜치를 삭제

로컬 저장소에서 생성한 커밋을 원격 저장소(origin)로 업로드하는 명령어. 로컬 브랜치의 변경 사항을 원격 브랜치에 반영할 때 사용한다.
push가 완료되면 원격 저장소의 브랜치 위치도 최신 커밋으로 이동한다.

5. git pull --rebase

git pull --rebase

원격 저장소의 최신 변경 사항을 가져온 뒤(fetch), 현재 작업 내용을 그 위에 다시 적용(rebase)하는 명령어. 기존 merge 방식과 달리 불필요한 병합 커밋이 생성되지 않는다. 커밋 기록을 한 줄로 깔끔하게 유지할 수 있게 해준다.

6. 원격 추적

git checkout -b foo o/main

foo 라는 새 브랜치를 생성하고, o/main 브랜치를 추적 대상으로 설정

이후에 foo 브랜치에서 git pull 또는 git push 를 실행하면 자동으로 o/main 과 연결되어 동쟉한다.

이미 존재하는 브랜치에도 원격 추적 설정 추가하는 법

git branch -u o/main foo

foo 브랜치가 o/main 브랜치를 추적하도록 설정. 현재 작업 중인 브랜치라면 브랜치명을 생략할 수도 있다.

풀이 인증!

[포렌식 기초] 5주차 과제

yeseul7 — Wed, 18 Feb 2026 21:41:35 +0900

1. abcdefg - who

문제 파일을 열어보면

이렇게 되어있는데, 문제 서버 생성 후 터미널에 들어가 이대로 쳐본다.

그럼 이렇게 서버에 들어가게 되어있는데

안에 뭐가 있는지 보려면, ls를 쳐야하는데 비밀로 감춰둔 파일이 있어 안 보이기 때문에 ls -a를 통해 확인해야한다.

또, 리눅스 시스템에서는 시스템에 존재하는 사용자 정보를 /etc/passwd에 넣기 때문에 확인을 해본다.

이렇게 보면 많은 파일들이 보이는데, 그중 수상한 파일이 있다는 것을 알 수 있게 된다.

cat 명령어를 통해 passwd 파일을 확인해보면, 다양한 사용자 정보를 볼 수 있는데 무언가 이상한 파일이 있다는 것을 알 수 있게 된다.

바로, bash shell파일로 접근을 한다는 점이다. Bash shell은 사용자가 입력한 명령을 해석하여 운영체제에 전달하는 명령행 인터페이스인데 다 이곳으로 접근한다는 점이 조금 이상하다고 볼 수 있다.

이 파일을 열기 위해선 sudo 명령어를 통해 입력해야하는데, 이를 통해 패스워드를 입력하면 이렇게 뜬다.

엄청 많이 뜨는 화묜 속에서 플래그를 찾을 수 있었다

제출해보면 성공!

2. access-log

이 문제는 솔직히 좀 어려워서ㅜㅜ 함께 실습을 함 확인해봤다...

필터링을 해서 보았을 때 SQLI, 그러니까 SQL injection인 것을 알 수 있게 되는데 뒤에 아이디를 보면 좀 비정상적으로 길다는 사실을 알 수 있다.

TMNo=9067 AND 1=1
UNION ALL SELECT
  1,
  NULL,
  '<script>alert("XSS")</script>',
  table_name
FROM information_schema.tables
WHERE 2>1
--/**/;
EXEC xp_cmdshell('cat ../../../etc/passwd')#

이 URL을 디코딩 해보면, AND 1=1을 통해 항상 참인 것을 확인하는 SQL Injection 가능 여부 테스트용 코드를 넣었는데, 이것이 에러 안 나면 “취약하다”는 신호이기 때문에 취약성을 확인하는데 쓰이게 된다.

또,

Stored / Reflected XSS 공격
DB에 이 값이 저장되거나 출력되면
→ 웹페이지에서 자바스크립트 실행됨

즉:

SQLi로 XSS 페이로드를 DB에 주입하게 되는 코드가 있당.

이 공격의 특징을 보면 특정 환경을 정확히 아는 공격으로 취약한 곳이면 뭐든 털겠다는 무차별 공격이라고 볼 수 있다.

이 SQL 구문을 보면 공격자가 무엇을 공격하려 했는지 알 수 있는데, 대충 보았을 때의 구조가

SELECT ...
FROM dvwa.flag
ORDER BY id
LIMIT 0,1

이런 형식이고, 뒤에

IF(ASCII(SUBSTRING(flag,1,1))=68, SLEEP(5), 0)

이런 조건이 붙기 때문이다. flag의 첫 글자의 ASCII 값이 68이면 5초 멈춰라. 라는 뜻으로 해석할 수 있는데 응답 시간이 달라지는지를 이용해서 데이터를 한 글자씩 뽑아내는 공격으로 해석할 수 있는 방식으로, ASCII 65, 66, 67, 68… 이렇게 하나씩 바꿔가며 테스트하는 것이다. 따라서

여기서 68 72 123 97 110 65 49 121 122 49 110 71 86 101 51 121 66 49 57 76 48 103 125 이 값들을 반환해보면 플래그를 추출할 수 있다고 한다.

플래그를 입력하면

성공한 것을 볼 수가 있다.

[포렌식 기초] 3주차 과제

yeseul7 — Wed, 4 Feb 2026 13:33:16 +0900

시작~!

1. Find the USB

윈도우 레지스트리 분석을 통해 usb 사용 흔적을 파악하는 문제이다!

기기연결 흔적은 포렌식에서 가장 중요한 데이터중 하나이기 때문에 함 봐보작!

일단 당연히 FTK imager에서 문제 파일을 열어주고

해당 경로를 찾아 삼만리를 한다.

마지막 system까지 추출을 끝냈으면 다음 단계는

이렇게 처리를 하는 것이다. 찾아보니 dirty 상태를 clean 상태로 만드는 것이라고 한다. 이렇게 해주는 이유는 전에 했던 분석과 파일이 섞일 수 있어서이다.

clean을 완료하고

기기 연결 흔적을 찾기 위해서 Registry Explorer를 열어 파일을 열어본 뒤 해당 경로를 찾는다.

USBSTOR는 “저장장치로 실제 사용된 USB”만 기록되는 곳이기 때문에

그래서 Find the USB 문제에서는 무조건 USBSTOR부터 봐야한다.

다음 사진에서 문제에서 요구한 2024년 4월의 시리얼 넘버를 살펴보면 03A49E66

USB에 들어가 같은 시리얼 넘버의 2024년 4월 흔적을 살펴보면 VID가 058F, PID가 6387인 것을 볼 수 있다.

그러므로 답 형식에 맞추면 답은

DH{058F_6387_03A49E66}

2. Autoruns

같은 파일을 쓴당

문제 이름도 그렇고, 컴퓨터가 재부팅 될때마다 실행된다고 했으니 다음과 같은 경로를 확인해본다

사용자 레지스트리 하이브인 NTUSER.DAT로 들어가야한다.

휴 찾앗다 눈 빠질뻔 했다 다음엔 글자 크기 키우고 봐야지...

"C:\Users\victim\malware.exe"라는 데이터를 찾을 수 있다. 이건 victim 계정이 로그인할 때마다 malware.exe가 자동 실행되도록 등록돼 있다는 뜻이기 때문에

이걸 FTK imager로 찾아보면 뜬다!

추출해서 열어보면 ㄹㅇ 계산기 파일이다...

해시값 자주 추출하기랠 그냥 추출하는 프로그램을 깔고 추출해주면

302021d31f2d0bce01d7afc26bfe2ba2가 MD5해시값임을 알 수 있다.

해결 완~!

3. boot_time

가작...

이번엔 이벤트로그 분석 문제이다.

FTK imager에 들어가 log파일 전체를 export 해주고

이벤트 뷰어 연다.

ppt에 적힌대로 일단 security먼저 들어가서

마지막 부팅이니까 EventID 4608으로 찾아본다

이렇게 필터로 찾는거라고 한다.

마지막 부팅이랬으니 답은 2024.04.07일에 있던게 맞는 것 같다.

답 치던 중 한번 틀렸는데... 이유가 오전 12시이기 때문에 12가 아니라 00가 답이었다.. 한참 헤메었다ㅜㅜㅜ

4. nikonikoni

왜 자구 이런 해킹을 당하는 건지 모를 일이다ㅜㅜ

아까 boot 한거랑 똑같은 파일을 쓰기 때문에 중략하고

어디를 살펴봐야 할지 몰라서 GPT에게 물어보니

문제 상황을 포렌식 관점으로 풀면

사건 요약

배경화면이 애니메이션 캐릭터로 변경됨
사용자는 직접 바꾼 적 ❌
⇒ 스크립트가 실행됐다는 뜻

그럼 “어떤 방식”이 제일 흔하냐?

✅ 1순위: PowerShell

왜냐하면:

파일 다운로드
이미지 변경
레지스트리 수정
자동 실행 등록
이걸 전부 PowerShell 한 줄로 가능

실제 공격자 입장에서:

powershell -ExecutionPolicy Bypass -File script.ps1

이게 제일 흔함.

이라고 한다. 그러므로 powershell을 함 열어본다....

뭔가 내려받는 파일이 있어서 https링크 복붙해 들어가보니

이런 파일이 있다. 보기만해도 어지러워 지피티한테 물어보니 읽어야 하는 핵심 코드 10줄 정도를 해석해 알려주었고,

코드의 흐름을 보았을 때 ||로 인해 앞에 있던 명령어의 출력이 뒤에 있는 것의 입력으로 가며

jpg 파일이 다운로드 되어 창에 띄워지는 그런 악성 코드의 흐름을 가지고 있다.

악성 스크립트 실행 시간을 unix로 바꿔야된댄다 . 왜냐하면, 문제에서 시켯기 때문. 2024-04-07 오전 12시 26분 45초였으니 또 속지말고 00으로 꼭 해서 돌려보면

DH{merong_ani_1712417205}가 답이 된다. 넘 어려운문제였는데... 이해를 위해서 한번 더 봐야할듯 ㅜ

5. Track_the_file

드림이가 자꾸 해킹에 당해온다.

드림이: 나도 힘들다.

ppt에 적힌대로 추출을 하고

NTFS log Tracker로 각자 자리에 잘 넣어준다.

추출 후 DB browser for SQLite에서 열어주면

많은 것이 뜬다. 우리의 목표는 파일이 복사된것을 확인하는 것이다.

UsnJrnl 로그 분석 결과, malware.exe에 대해 동일 시각에 다수의 기록이 확인되었으며, 이는 파일이 복사 및 생성되는 과정에서 발생한 이벤트로 해석할 수 있다!!

NTFS UsnJrnl 특성상 파일 복사 시 여러 이벤트가 연속적으로 기록된다고 한다. malware.exe 역시 해당 시점에 생성/쓰기 이벤트가 확인된다.

플래그 양식인

FLAG = DH{yyyy_MM_dd_hh_mm_ss}대로 쓰면

DH{2024_04_04_21_10_46}가 정답이 된다.

[Devops 3.5기] 2주차 과제

yeseul7 — Wed, 28 Jan 2026 11:33:26 +0900

1. dockerhub에 올렸는데 이걸 이제 pull로 가져와서 wsl에서 실행시켜보기

해봅시당~

근데 이제 나는 맥북이기 때문에 알아보니 wsl는 신경 쓸 필요가 없다구 햇당

WSL = 윈도우 안에서 리눅스를 쓰게 해주는 것

인데 나는 리눅스가 바탕이기 때문이다.

드디어 맥북을 쓰는 이점이 생겼다.

끼끼.

일단 vs 코드에서 새로운 터미널을 열고,

uname -a 로 지금 이 터미널이 맥 터미널이 맞는지 확인해본다.

Daewin이 뜨면 맞다고 한다!

docker --version 로 docker 버전을 출력해서, 설치와 실행이 되는 것을 확인 후

pull 해보려니 안되었다... 물어보니 login이 안되어서 그렇다고..

토큰 부분은 이미 해보았기 때문에 스킵 후 스무스하게 토큰을 비번으로 해 로그인 해주고

pull 해주면 된다.

실행이 되엇당.

과제 2번~!

2. 다음 실습 때 GCP에서 자동 배포할 예정이니 카드 등록해오기(무료임!)

카드 등록 완!

과제 3번!

3. CI/CD 배웠던 파이프라인 구조 뭔지 알아보기, nginx가 뭐였는지 알아보기

CI는 지속적 통합, Continuous Integration의 줄임말이라고 한다! 개발자가 작업한 코드를 주기적으로 Main Repository에 병합(merge)하여 변경하게 된다.

우리가 실습에서 했던 것은 .github/workflows/flask_ci.yml 파일을 통해 Pull Request 생성 시 CI가 작동하도록 설정했다!

CD는 지속적 배포/구축을 뜻하고 Continuous Delivery/Deployment의 줄임말이라고 한다.

빌드된 결과물을 Docker 이미지로 만들어 Docker Hub에 자동으로 push해서 올린다.

Main 브랜치에 PR(Pull Request)이 머지되면 자동으로 배포 프로세스가 진행된다고 한다. 실습 과정에서는 GitHub의 Secrets 기능을 이용해 Docker Hub 토큰 등을 저장하고, 머지 성공 시 Docker Hub에 이미지가 푸시되도록 구축하는 작업이 적혀있다.(ppt 내용 참고)

nginx는 서비스의 앞단에서 요청을 받아 전달해 주는 역할으로, 쓰인 말로는 리버스 프록시(Reverse Proxy)라는 기능을 통해 클라이언트의 요청을 받아서 실제 애플리케이션(예: 8080 포트)으로 전달해 주는 역할을 수행하게된다.

조금 쉬운 설명으로 이해하고자 한다면, 안내원으로 생각하여 용자가 "저 여기 서비스 좀 쓸게요!" 하고 들어오면, Nginx가 "아, 이쪽으로 가세요~" 하고 내부 서버(예: 8080 포트)로 길을 안내해 준다고 한다. 장점으로는 두개가 있다.

보호: 서버를 직접 노출 안 시켜서 보안에 좋다.
교통정리: 손님이 너무 많으면 여러 서버로 나누어 보내주기도 한다.

CI/CD 파이프라인도 쉽게 표현하면, 코드를 넣으면 서비스가 짠! 하고 나오는 자동화 공장이라고 생각하면 된다고 한다.

코드 작성 (GitHub): 네가 코드를 고치고 GitHub에 올린다.(Push/PR).
검사 단계 (CI): 샌드위치 재료가 신선한지 검사하듯, GitHub Actions가 네 코드를 자동으로 빌드하고 테스트 (문제가 있으면 여기서 딱 걸리게 됨)
박스 포장 (Docker): 검사가 끝난 코드를 어느 컴퓨터에서나 잘 돌아가게 'Docker'라는 박스에 예쁘게 담는다.
배송 및 진열 (CD): 박스(Docker 이미지)를 Docker Hub에 보내고, 우리 서버(AWS 등)에서 새 버전으로 교체한다.

다음과 같은 단계가 이어진다고 생각하면 된다!

우리가 실습으로 구축하는 파이프 라인은

GitHub: 코드를 커밋하고 Pull Request(PR)를 날린다.
GitHub Actions(yml...): PR이 올라오면 자동으로 CI(빌드/테스트)를 돌린다,
Docker Hub: CI가 성공하면 소스코드를 Docker 이미지로 구워서 Docker Hub라는 창고에 저장한다.
ㄴ 이 과정에서 왜 굳이 Docker를 쓰는가?에 대해선 이미 수업 시간에 들었던 바로, 환경 일관성. 즉, 어떤 컴퓨터 환경에서도 동일하게 내 프로그램을 실행하기 위해서라고 생각해면 된다)
Server (Nginx): 최종적으로 우리 서버에 배포되면, Nginx가 딱 버티고 서서 들어오는 요청을 처리해 주는 구조.

이런 방식으로,

'GitHub Actions가 코드를 검사해서 Docker 박스에 담아 창고(Docker Hub)에 넣으면, Nginx라는 문지기가 있는 서버에서 서비스가 돌아가는 것' 이라고 이해하면 편하다.

[Devops 3.5기] 1주차 과제

yeseul7 — Wed, 28 Jan 2026 02:35:21 +0900

밀렷다. 벼락치기가 아닌 벼락맞기... 1주차 과제 시작~!

일단, 깃 브랜치 배우기에 접속한다!

요래 다양한 명령어를 배울 수 있는 것 같다.

우리의 과제는 1단계(git 기본)의 문제 4까지 해보는 것 같다!

먼저 깃 커밋에 대한 설명이 적혀있다.

문제에선 이런 창이 나온다. 목표는 커밋을 두번 해보는 것!

두번 해보니 끝낫다. 아직까진 쉽지만 방심하지. 않을. 것.입니다.

다음은 브랜치에 대한 설명이다.

해결을 했다. 사실 한번 중간에 틀렸는데, 이건 인자를 2개까지만 받기 때문에 같이 써서 그렇다고 한다.

이쯤에서 잠깐 헷갈려서 소중한 친구 지피티한테 물어봤는데 커밋은 사진 찍는 것, 브랜치(main)은 지금 최신 사진이 어디있는지 알려주는 화살표 같은 거라고 했다. 여기서 main은 사진이 아니라 화살표라서 움직일 수 있다고 했다.

왜 commit 하면 main이 움직이냐고 물었는데, main 위에 서서(commit 위치에서) 사진을 찍고 있었기 때문이라고 한다.

checkout = 내가 잡을 화살표 고르기

이기 때문에

그래서, 브랜치 bugFix를 만들어서 참조(화살표) 하나 추가했고,

checkout bugFix를 해서 bugFix 화살표를 내가 잡은 것이라고 이해하면 된다고 한다.

드간다.

풀어보았는데 모범답안이 아니엇나보다... 그래서 한번 모범답안이 뭐일지 물어보았다

git checkout -b bugFix

이 한 줄이 두 개를 동시에 해줌

git branch bugFix (브랜치 만들기)
git checkout bugFix (그 브랜치 잡기)

라고 한다. 몰랐던 부분이니 한번 짚어 보고 넘어가기로!

상당히 헷갈리는 것이 나왔다. 무슨 설명인지 모르겠으니 일단 설명을 한번 보고 오겠다.44

문제 설명 중 작은 깨달음... 위로 올려놓는다는게 화살표로 자식으로 표현되는구나... 나는 부모가 되는줄 알앗다.

리베이스에 대한 개념은 일부러 다 캡쳐해서 남겨두었다! 다시 돌아봤을 때 더 쉽게 이해하기 위해서!

문제 시작~!

이번에는 모범 답안으로 성공했다!! 새 브랜치를 만들어 선택하는 부분ㅎ에서 아까 알아보았던 모범답안인

git checkout -b bugFix를 써서 그런 것 같당ㅎㅎ

짠! 끝낫당~~ 3번이 완벽하게 못 푼게 아숩지만 배운 후 4번에서 썼으니 만족하기로(?) 하였다!

과제 끝!

[포렌식 기초] 2주차 과제!

yeseul7 — Sat, 24 Jan 2026 04:02:49 +0900

문제 1. VBR

다음 문제는 플래그 값을 계산을 해야하는 문제이다. 파일 시스템을 알기 위해선

다음과 같이 FAT32는 0x52나, NTFS는 0x03에서 확인해야 한다.

이 파일은 0x52부터 FAT32라는 것이 나타나있기 때문에 A = 1이다.

다음은, 볼륨의 크기에 대해 알아야 하는데

Total Sectors × Bytes Per Sector

이 표에 의하면, total sector 32는 0x20 ~ 0x23에 있고,

00 80 3E 00에 FAT32이니까 리틀 에디안 방식이기 때문에 바꾸면 00 3E 80 00 = 0x3E800

Bytes Per Sector은 0x0B~0x0C에서부터 시작해 00 02 리틀 에디안 방식을 바꿔버리면 02 00 = 512B/sector = 0x200

둘이 계산하면

0x3E800 * 0x200 = 0x7D000000 이다

볼륨 시리얼 번호는

Volume ID, 그르니까

0x43 ~ 0x46에 있다. 그러므로 8A EE A8 0E. 리틀 에디안 방식이기 때문에 큰 자리면서 표기로 바꾸면 0E A8 EE 8A이다.

이제 대충 답을 구할 수 있을 것이다. FLAG = DH{(A + B + C)}

A: 파일시스템이 FAT32면 1, NTFS면 2
B: 해당 볼륨의 크기
C: 볼륨 시리얼 번호

답을 하나 하나 더해 넣어 10진수로 바꿔주면, 2343104139이라는 수가 나온다

성공!!

문제 2. Corrupted Disk Image

우선 FTK imager에서 파일을 열어보면, 파일이 깨져있는 것을 발견할 수 있다.

Raw로 바꾸고 텍스트 파일이 아닌 걸 선택해야 한다

이럴 때는 헥스 에디터로 열어서 디스크 파일의 원본 바이트를 그대로 보는 과정이 필요한데, 그 이유는 우리가 원본으로 보게 되면 깨져있어도 파일을 볼 수 있게 해주기 때문이다.

NTFS VBR 복사본= VBR위치 + NTFS의 전체 섹터 크기 - 1

검색을 통해 확인해보면 NTFS 파일이라는 것을 알 수 있고, 공식에 따르면 끝 주소 = 0x0D8FFE00 + 0x200 - 1
= 0x0D8FFFFF 그만큼을 긁어서 맨 처음 부분에 복붙 하면

이렇ㄱ게 된당! 여기서 이메저를 열고 들어가면 뭔가... 읽지 않고는 못 배길 것 같은 그런 파일을 찾을 수 있는데 그걸 열어보면 이런 얼탱이 없는 그림판 문구가 뜬다.

근데 이건 keyFile를 Hashcalc라는 해시 계산 소프트웨어를 사용해서 파일의 해시값을 계산하는 그런 보기보다 복잡한 문구였다고 한다............

해시 함수 계산기를 통해 계산해서 가져다 붙이면

해결된다ㅜㅜ

문제 3. FFFAAATTT!

일단 FTK imager로 열면 이렇게 옆에 계속 FIX라는 문구가 뜬다!!

파일 시스템 확인! 파일 시스템은 FTA32이다.

짱짱! 중요한 수업 자료에 따르면, FAT 32는 사본은 6번째 섹터에 저장해둔다는 것을 알 수가 있다!!!

섹터는 한 섹터에 512바이트니까, 단순계산으로 6번 섹터 시작 = 6 × 512 = 3072바이트 = 0x0C00라고 알 수가 있다.

섹터 크키는 512 = 0x200니까

0x0C00 + 0x200 - 1 = 0x0DFF까지 잡아주면 된당

자 이제 저장하고! 한번 살펴보다보면....

플래그 파일을 만날 수 있어 신났는데 암호가 걸려있다... 이걸 알아내야 끝이,,,

살펴보던 중 gg.png 파일이 안 열려 이걸 헥스 에디어로 다시 돌려보니 키를 발견할 수 있게 되었다 ㅜㅠ DHDHFIX.

그걸 암호로 하나 하나 다 열어보니, FINISH_FIX 메모에서 플래그를 확인할 수 있었다!!

성공!!

4. structure-based carving

문제 파일은 zip이라고 했으니, zip 헥스 에디터를 열어 zip 헤더인 50 4B 03 04를 검색해본다.

완전 얼탱이. 1009개나 나온다... 으쩌지 생각하던 중에

참고 자료 설명? 해석?을 해보면 압축 방식을 보니 08이 일반적인 압축 방식이라고 설명을 했고

version은 GPT에게 물어보니 14일 확률이 높다고 하는데, 이 이유는 보통 최근 버전인 14로 되어있다고 한다.

flag는 00일 확률이 당근 높다고 생각되는 파일이기에 00으로 해서 한번 더 검색해보면,

이렇게 검색했는데 아무래도 내가 찾지 못하는 건지 안 뜬다ㅜㅜ 지윤언니가 알려준 방식대로 생각했을 때, 08은 비밀번호가 걸려있지 않은 파일, 09는 암호화 되지 않은 파일이라고 했는데 우리의 문제에선 {압축 패스워드는 zip 파일 어딘가에...}라고 쓰여있었으므로 패스워드가 필요만 암호화 된 zip 파일이다. 그러므로 09로 검색하는 것이 맞다!

딱 하나 나오는 걸 찾아브럿다.

해당 부분 복사해서 붙이고 zip으로 만드니

비번이 필요하댄ㄷ.

그래서 다시 문제를 살펴보니

라고 해서 다시 들어가서 함 살펴보니

비번을 찾을 수가 있었당.

압축 풀면 플래그 뜬다! 요걸 고대로 입력하면~!

끝!!!!

해초 : 김예슬 7주차 과제(File Vulnerability)

yeseul7 — Thu, 27 Nov 2025 16:29:10 +0900

유종의 미를 거두기 위해! 시시시작~!

1. image-storage

php로 작성된 파일 저장 서비스입니다. 라고 문제 설명에 적혀있지만,,, php 파일을 몬만들까봐 잔뜩 긴장하며 풀어본다....

일단 문제에 처음 들어가면 이런 화면이 뜬다.

이미지를 업로드 해야 할 것만 같다.

업로드에 한번 들어가보면, 이런 업로드 창이 뜨는데

대충 소스 코드를 읽어봐도 다 찾아봐도 업로드의 기능은 있지만 파일을 읽는 기능은 없기 때문에, 우리가 직접 웹쉘 파일을 올려서 cat 명령어로 파일을 읽게 해야한다. 서버에 파일 읽는 기능이 없기 때문이다!

서버가 파일을 단순히 보여주는 것이 아니라, '프로그램'처럼 실행해서 그 결과물만 보여주기 때문!

서버 코드가 php로 이루어져 있기 때문에 php 파일을 하나 맹글어준다.

다음과 같은 코드를 작성하면 되는데, php 기본 구조를 유지한 상태로

system() 함수를 통해 시스템 명령어를 넣어주어야 하기 때문에 system("cat /falg.txt");

이번에 문제 풀면서 알게 된 사실인데, ""하는 이유가 system 함수 자체가 문자를 읽어 명령어로 변환하라는 뜻이란다... 그래서 문자열을

넣어야 하기 때문에 ""라고,,,, 큰 깨달음...

아무튼 만들어서 업로드 해주면?

업로드 되었다.

이제 메인에 들어가면 내가 만든 파일이 뜨고 들어가면

플래그가 뜬다!

2. file-download-1

비기너 문제이다. 못 풀면 안되기 때문에... 해보자!!!

우선 들어가면 이런 페이지가 뜬다. memo 를 업로드 해달라고 하기 때문에 돌아볼 것도 없이 upload my memo로 들어가본다~!

파일 이름을 지정하고 내용을 넣은 뒤 업로드 할 수 있는 창인 것 같다.

이때, 소스 코드를 보면 우리가 배운 ..(더 상위의 디렉토리로 접근 할 수 있는 것)을

제한하고 있다는(bed characters...라고 뜨게 해둠)것을 알 수 있다.

거두절미하고 memo를 한번 올려보자

텍스트를 넣고 업로드를 누르면

우리가 넣은 memo가 뜬다.

들어가보면 우리가 만든 메모가 적혀있는 것을 알 수 있는데, 우리의 문제 설명에 flag.py를 다운로드 받으면 플래그를 획득할 수 있습니다. 라고 적혀있기 때고, 다시 한번 소스 코드를 확인하면

이런 형식이기 때문에 read?______로 읽어서 다운로드 받을 수 있는 것을 알 수 있당.

그래서, url을 통해 read?name= ../flag.py로 변경해주면? 다음과 같은 플래그가 뜬다!

해초 : 김예슬 6주차 과제(commed Injection)

yeseul7 — Wed, 26 Nov 2025 19:13:24 +0900

1. command-injection-1

문제에 들어가 확인해본다.

host에 무언가 적는 칸이 있는 것을 보아, 여기에 값을 넣으면 flag가 나오는 구조로 추측을 해볼 수 있다.

받은 소스코드 파일을 살펴보면, flag.py에는 flag가 있는 것을 알 수 있고

app.py에는 우리가 답을 추측해볼 수 있는 소스가 적혀있는데,

이때 cmd = f'ping -c 3"{host}"'라는 구절에서 우리가 form으로 host 값을 주게 되면 cmd에 저장되는 것을 알 수 있고,

이것은 subprocess.check 부분에서 실행되게 되는데, 성공시 render_template('ping_result.html', data=output.decode('utf-8'))을 통해서 결과 페이지를 랜더링 해주고, subprocess.CalledProcessError: 에서 보면 실패시 만들어진 cmd과 an error occurred while executing the commed. 라는 에러 메시지를 보여주게 된다.

그러므로 정답 코드를 작성해보면

8.8.8.8" ; cat flag.py #이 되는데

이유는

8.8.8.8"을 통해 값을 넣어주고 닫은 뒤,

;라는 에러이든 아니든 뒤에 것도 실행해주는 쉘 메타문자를 써준 뒤

cat(읽어서 출력해주는 기능을함)을 통해 flag.py를 출력, #을 통해 뒤를 주석처리하여 뒤 구문을 무력화시키는 것이다!

하지만, 이렇게 넣을 시 이런 문장이 뜨게 되는데 이때 최종적으로 개발자 도구를 켜

이 pattern 부분을 지우고 다시 실행해보면

이렇게 플래그가 나오는 것을 볼 수 있다 끝!!

2. old-44

문제를 들어가본다! 먼가 name에 뭘 넣어야만 하는 것 같다...

이것만으로는 감을 전혀 잡을 수 없으므로(당연히)

view-source에 들어가본다.

echo를 통해 id 값을 우리가 출력하는 것 같은데, You just need to execute ls라고 적혀있으니 우리는 쿨하게 '를 통해 닫아줄것이다. 그리구 ;라는 아까도 봤던 오류이든 아니든 실행하게 만드는 쉘 메타문자를 넣어준 뒤 뒤에 ls를 넣고 주석처리 넣어보고싶지만 5글자까지의 한계가 있기 때문에 '로 닫은 뒤 고대로 넣어준당

그럼 이렇게 flag_29라는 파일과 index.php라는 파일이 뜨는데

요게 끝이라고 생각해선. 안된다. 왜냐면 이건 단지 파일명이기 때문에 그 다음에 URL 파라미터에 그 파일명을 넣어서
서버의 파일 읽기 기능을 이용해 내용을 읽어야 하기 때문이다.

이렇게 flag 파일을 그대로 붙여 파라미터로 값을 전달하면

찐 플래그 값이 뜬다!

3. Command Injection Advanced

일단 파일은 연다.

받은 악성 코드 파일도 한번 열어주고, 그 링크를 복사한다!

소스 코드를 gpt한테 해설 맡겼을 때,

$cache_file = './cache/'.md5($url);
이 한 줄으로 인하여 우리는 cache 폴더가 있다는 것을 알 수 있다고 알려주엇당...

./ → 현재 디렉토리
cache/ → cache 폴더가 있다
md5($url) → 파일 이름은 URL 값의 MD5 해시

“이 프로그램은 ./cache 폴더에
URL을 해시한 이름으로 파일을 저장하는구나."

로 이해해야 한다고 하였다.

그러므로,

url에 다음과 같은 복사한 파일 링크를 붙여넣고! 출력 파일 이름을 hello.php로 cache에 저장하는 그런 구문을 지정한다.

사이트 주소(host) 뒤에 우리가 만든 파일의 링크를붙여넣고, ls로 확인한 뒤 /flag 해준다!!

해초 : 김예슬 5주차 과제(SQL)

yeseul7 — Sun, 16 Nov 2025 21:29:16 +0900

결국 과제가 밀려버렸기 때문에!!

빠르게 라업 작성 들어갑니당.

1. simple_sqli

이 문제야말로 정말 쉽다! 난이도 1임을 인정할 수 있는 유일한 문제. 입니다.

곧바로 로그인 창으로 들어가줍니다!

주어진 소스 코드를 확인해보면,

userid = admin 이어야 하고, 비밀번호는 저희가 모르는 상태로 되어있지만

로그인을 하게 된다면 플래그를 띄워준다는 것을 알 수 있습니다.

여기에서 우리는 userid = admin을 알고, password를 모르기 때문에 조건 중 하나인 패스워드를 주석처리해서 지워버리면 된다.

sql에서 주석처리는 --

그러니 로그인 창에서 admin"을 해주고({userid} 자리에 넣어주는 것) 그 뒤에 --를 달아주면 뒤 내용을 자연스럽게 주석처리 하면서

우리는 조건을 충족해 사이트로 접속할 수 있게 된다. 이때 주의할 점은 "를 꼭 해주어야 올바른 문장이 된다는 것!!

비밀번호는 대충 아무거나 해주고(주석처리 되기 때문) 로그인을 누르면,

이렇게 플래그가 나온다~!~!~!!

2.simple_sqli_chatgpt

요 문제도 아까 문제랑 비슷한 문제이다! 쫄지말고(?) 접근할것. (스스로에게 하는 말입니다...)

로그인 창으로 먼저 들어가고,

확인해보면 아까랑은 조금 달리 userlevel이라는 것이 뜬다는 걸 볼 수 있다.

소스 파일을 확인해보면 아까랑은 비슷한데 조금 다른 코드가 뜬다.

주의 깊게 봐야 할 부분은 if userid 부분인데,

userid == admin, userlevel == 0을 꼭 조건으로 만족해야한다는 것.

그렇기 때문에, userlevel부분에 맞춰

0 and userid = 'admin가 답 코드가 된다.

왜냐하면 '{userlevel}'"이니까

userlevel ='{0 and userid = 'admin}'")

이런 식으로 기존에 있던 '를 고려해 채워야한다는 것!

요렇게 로그인 창에 답을 넣으면?

플래그가 뜬다!!

3. blind sql injection advanced

일단 심호흡을 하고 풀어봐야 하는 문제가 나왔다. 정말 쉽지 않타.... 다행히 vs코드 다른 버전 깔았드니 돌아가더랍니다...

다행.......이죠?...ㅎㅎ

우선 문제에서 준 파일들을 읽어줍니다. 요 파일에선 user테이블에 3개의 행, 그 안에 'admin', 'guest', 'test'에 대한 각각의 데이터가 들어가있다는 것과, admin의 upw가 곧 우리가 찾아야하는 flag라는 것을 알 수 있다.

우선, 플래그의 글자 길이부터 알아야하기 때문에

코랩에 들어가서 주소를 변수로 지정하고

password_length라는 변수를 만든 뒤 값을 0으로 초기화해둔다.

그 이후 while문을 통해 password_length의 길이를 구하게 되는데,

password_length에 돌아갈 수록 하나씩 더해주는 것을 짠 뒤에

exists가 뜨면(같다는 것이 참이 뜨면) break를 하고 빠져나와 password_length 값을 출력해주는 프로그램을 만든다.

그 다음 각 문자별 비트 길이를 찾기 위한 코드를 작성해야 하기 때문에, 패스워드 길이만큼 돌아가는 for문을 작성해주어야 한다.

substr(upw, {i}, 1)
→ 비밀번호의 i번째 글자 하나를 잘라서 가져온다.
ord( … )
→ 가져온 글자를 ASCII 숫자값으로 바꾼다.
bin( … )
→ 그 ASCII 숫자를 이진수 문자열로 바꾼다.
length( … )
→ 이진수 문자열의 길이를 센다.
length(...) = {bit_length}
→ 이진수 길이가 공격자가 넣은 {bit_length}와 같은지 비교한다.
-- -
→ 뒤에 오는 SQL 코드를 주석 처리해서 무효화한다.

가 다음 length(bin(ord(substr(upw,{i},1)))) = {bit_length}-- -라는 줄 안에서 각각 함수들의 역할이다.

비트 수를 알아냈다면, 0과 1으로 검사를 해보고 각각 결과를 넣어 완성하는 코드를 돌리면 된다!