[Normaltic 웹해킹 입문] 6주차 CTF 문제풀이 - Login Bypass(4)

🤯 [웹 해킹 스터디] Login Bypass 4: 평문이 안 먹힐 때 (Hash 추측)

Login Bypass 4는 3번보다 훨씬 어려웠다.. 진짜 머리에 쥐가 날 뻔했다 🐭
앞선 Bypass 3과 똑같은 로직(식별/인증 분리)인 줄 알고 덤볐다가 큰코다친 과정을 기록한다.

목표: normaltic4 계정으로 로그인 성공하기

---

1. 1차 시도: Bypass 3 방식 (실패)

Login Bypass 3번과 구조가 같아 보였다. 당연히 "가짜 계정 생성" 기법인 UNION Injection을 시도했다.

Payload: abcd' union select 'normaltic4', '1234' #
PW Input: 1234

결과: 실패.
"어? 왜 안 되지?" Bypass 3번에서는 이렇게 하면 DB에서 normaltic4 / 1234를 뱉어주고, 내가 입력한 1234랑 비교해서 로그인이 됐었는데?

---

2. 2차 시도: 컬럼 순서가 반대인가? (가설 설정)

혹시 DB 테이블이 id, pw 순서가 아니라 pw, id 순서로 되어 있나? 하는 의심이 들었다.

Col 1 (pw?)	Col 2 (id?)
1234	normaltic4

만약 그렇다면 내가 순서를 뒤집어서 넣어줘야 한다. (이거 될 줄 알고 엄청 기대함...)

Payload: abcd' union select '1234', 'normaltic4' #
PW Input: 1234

결과: 응 아니야~~ (실패)
순서 문제도 아니었다. 그럼 도대체 뭐가 문제일까?

이쯤되면 200 OK가 로그인 실패한거라는건 바로 감이 온다

---

3. 3차 시도: 암호화(Hash) 함수 사용?

여기서 머리를 스친 생각. "비밀번호를 평문으로 저장 안 하고 해시(Hash) 처리했나?"

💡 해시(Hash)란?
비밀번호를 1234 그대로 DB에 저장하면 보안상 위험하다. 그래서 MD5, SHA-256 같은 함수를 거쳐 알아볼 수 없는 문자열로 바꿔 저장한다.
예: 1234 -> (MD5) -> 81dc9bdb52d04dc20036dbd8313ed055

만약 서버가 해시를 사용한다면 로직은 이렇다.

1. 사용자가 1234 입력 -> 서버는 이걸 해시로 변환 (81dc...)
2. DB에서 저장된 비밀번호를 가져옴
3. (서버 변환값) == (DB 저장값) 비교

내가 1차 시도에서 DB가 1234(평문)를 뱉게 만들었으니, 서버가 만든 81dc...(해시값)와 다르니까 로그인이 안 된 것이다!
그렇다면 DB가 뱉어내는 값도 해시 처리를 해서 줘야 한다.

MD5 함수 주입

가장 만만한 MD5부터 찍어본다. SQL에는 md5()라는 자체 함수가 있다.

Payload: abcd' union select 'normaltic4', md5('1234') #
PW Input: 1234

이렇게 보내면 DB는 1234를 MD5로 암호화한 값을 반환할 것이고, 내가 입력한 1234도 서버가 MD5로 변환해서 비교할 테니 일치할 것이다!

결과: 워후!! 정답!! 🎉
Login Bypass 4는 DB에 저장된 비밀번호가 해시(MD5) 처리되어 있다는 점을 간파해야 풀 수 있는 문제였다.

---

📝 해킹이 어려운 이유 (Black Box)

이번 문제를 풀면서 느낀 점은, 해킹은 "보이지 않는 상대와의 싸움"이라는 것이다.
소스코드가 보이지 않으니(Black Box), 힌트도 없고 확신도 없는 상태에서:

• "컬럼 순서가 다른가?"
• "MD5인가? SHA-1인가? SHA-256인가?"
• "혹시 Salt가 쳐져 있나?"

이 수많은 가능성을 하나씩 시도하고 검증해야 한다는 점이 어렵고도 매력적인 것 같다. 다음은 Login Bypass 5번이랑 SQLi 1~2 같이 풀어볼거임!! 가즈아! 🔥