[TryHackMe] OWASP Top 10: 2021 - EP.2 (Task 5~8)

출처: https://tryhackme.com/room/owasptop102021

OWASP Top 10 - 2021

 
EP.2 에서는 OWASP Top 10의 10가지 취약점 중,
두 번째인 Cryptographic Failures에 대해 배워봅시다!
 

[5]  2. Cryptograhic Failures

 Cryptograhic Failures는 암호 알고리즘의 잘못된 사용 또는 부재로 인해 발생하는 취약점입니다.
 
Web Application Bascis 룸에서 배웠던, URL, HTTP Request나 HTTP Response를 통해 정보를 전달하는 과정에서,
ID나 password 같이 민감한 정보들은 남에게 노출되면 안됩니다.
그래서 민감한 정보들은 원본 그대로를 보내는 것이 아닌, 암호 알고리즘을 통해 사람들이 알아볼 수 없는 암호문으로 만들어 전송합니다.
(원본 = plaintext = 평문 / 암호문 = ciphertext 라고 부릅니다)
 
또한, 보통 서버 내부의 데이터베이스 (DB)에는 비밀번호를 그대로 저장하지 않고,
복원할 수 없는 hash (해시) 형태로 변환해 저장합니다.
(이를 통해, DB가 유출되도 비밀번호의 평문이 바로 노출되는 것을 막을 수 있습니다)
 
이런 식으로, Web Application은 사용자 정보를 보호하기 위해 다양한 수준의 암호화를 사용해야 합니다.
(암호화는 영어로 encryption! 알아두세요)
 
암호화시키는 데이터에는 크게 2가지 종류로 나눌 수 있습니다.

- 전송 중 데이터 암호화 (Data in Transit)

 = HTTPS, URL 같이 Client (사용자)와 서버 사이를 오가는 네트워크 트래픽의 암호화

- 저장 중 데이터 암호화 (Data at Rest)

 = DB, 파일 같이 저장되어 있는 데이터들의 암호화
(쉽게 보면, 위에서 먼저 설명한게 전송 중 데이터 암호화 / 나중에 설명한게 저장 중 데이터 암호화)
 
이러한 암호화를 실패하게 되면 Web App에서 이름, 생년월일, 계좌 정보, 비밀번호 등과 같은 민감한 정보가 노출될 수 있으며,
이를 이용해 공격자가 Man-in-the-Middle Attack, 줄여서 MTIM 공격 등을 통해 데이터를 가로채 정보를 훔칠 수 있습니다.

(Web Application 너무 길어서 Web App으로 줄여 쓸게요..)

 
또한, 약한 암호화나 잘못된 설정으로 서버에 저장된다면, 공격자가 직접 서버에 저장된 민감한 데이터를 찾아낼 수도 있습니다.
 
 
 

[6]  Cryptograhic Failures (Supporting Material 1)

 SQLite 데이터 베이스 (DB) 파일을 다루는 방법에 대해 가볍게 알아봅시다.
 
Web App은 보통 데이터를 저장하기 위해서 여러 데이터베이스 (DB)를 사용합니다.
데이터베이스는 여러 사용자들이 쉽게 접근 가능한 형식으로 대량의 데이터를 저장할 수 있어서 많은 사용자들이 언제든지 웹 사이트를 사용할 수 있게끔 해줍니다.
 
일반적으로는 MySQL, MariaDB 같은 서버 기반의 데이터베이스 (DB)를 사용하지만,
단일 파일로 존재하는 SQLite 같은 Flat-file 형식의 데이터베이스 (DB)도 존재합니다.
 
이러한 ".db", ".sqlite" 같은 DB 파일들이 웹 서버 폴더 (Web root)에 저장 및 노출되어 있다면, 공격자가 다운로드하여 내부 데이터를 그대로 볼 수 있습니다.
이것이 잘못된 설정으로 인해 발생한 데이터 노출 (Data Exposure) 취약점, 즉, Crypotgrahic Failures 취약점 입니다.
 
 

[6-1] Flat-file 데이터베이스 (DB) 파일 정보 확인하기

 "Flat-file" 형식에 대해 좀더 알아봅시다.
이 형식은 서버의 디스크 (서버 파일시스템)에 단일 파일로 저장되는 형식입니다.
즉, 데이터베이스 파일을 사용자 컴퓨터가 아닌 서버에 저장되어 서버 프로세스만 접근한다는 소리입니다. (제가 예전에 헷갈린 부분)
 
정상적으로는, 서버 내부에서만 접근하기 때문에, 웹 자체에서는 문제가 되지 않습니다.
하지만, 웹 사이트의 루트 (사용자가 접근 가능한 폴더)에 놓이면 외부 사용자가 다운로드해서 자신의 컴퓨터로 가져갈 수 있게됩니다.
 
 
이제 Linux 상에서의 SQLite 데이터베이스를 예시들을 통해 알아봅시다!
 
먼저 데이터베이스의 파일 정보를 찾아봅시다.

( 입력 : ls -l )
anby@linux$ ls -l
-rw-r--r-- 1 anby rabbit 10240 Mar 10 14:55 hacking.db

 'ls -l' 명령어를 통해 파일의 권한, 소유자, 그룹, 파일 크기, 수정 날짜, 파일명을 출력했습니다.
 
우선, "-rw-r--r--" 부분의 글자들은 순서대로 분석해, 어떤 권한을 가지는지 확인해보면,
- 맨 앞의 "-" 은 일반 파일임을 나타냅니다.
- 그 뒤의 "rw-" 는 소유자가 읽기 (r)와 쓰기 (w) 권한을 가짐을,
- 그 뒤의 "r--" 는 그룹이 읽기 (r) 권한만을 가짐을,
- 맨 뒤의 "r--" 는 다른 사용자들도 읽기 (r) 권한만을 가짐을 나타냅니다.
 
권한 부분 뒤쪽의 숫자 "1" 은 하드 링크의 개수를 나타냅니다.
즉, 하드 링크의 개수가 1개임을 나타내고, 일반적인 파일은 1개의 하드 링크를 가집니다.
하드 링크를 통해서 하나의 파일에 여러 개의 파일 이름을 부여할 수 있습니다.
(하드 링크 2개 = 같은 파일 데이터를 가리키는 파일 이름이 2개 존재)
 
"anby" 는 소유자의 이름 / "rabbit" 은 그룹 이름 / "10240" 은 파일의 크기를 byte 단위로 표시한 것입니다.
"Mar 10 14:55" 은 파일의 마지막 수정 날짜가 3월 10일 14:55 임을 나타내고,

"hacking.db" 는 이 파일의 이름입니다.
 

( 입력 : file [파일 이름] )
anby@linux$ file hacking.db
hacking.db: SQLite 3.x database, last written using SQLite version 3041000, 
            file counter 3, database pages 5, cookie 0x2, schema 3

'file hacking.db' 명령어.
즉, file 명령어를 통해 "hacking.db" 의 파일 유형을 출력했습니다.
 
중요한 부분은 앞 부분인 "SQLite 3.x database" 입니다.
이 부분을 통해 "hacking.db" 가 SQLite 3.x 형식의 데이터베이스 파일임을 알 수 있습니다.
 
중요하진 않지만, 뒷 부분을 알아보자면.
마지막 기록된 SQLite의 버전이 3041000 (3.41.0) 이고,
파일 변경 횟수 (file counter)가 3번이며,
이 파일은 5개의 페이지로 구성되어 있고,
데이터베이스의 내부 식별자인 cookie 값이 0x2 이며,
스키마 버전이 3 입니다.
 
 

[6-2] SQLite로 데이터베이스 (DB) 파일 내용 확인하기

이제 "hacking.db" 데이터베이스에 접속하겠습니다.
현재 이 파일이 SQLite3 버전을 사용한다는 것을 확인했기 때문에,
sqlite3 명령어를 통해서 "hacking.db" 데이터베이스에 접속합니다.

( 입력 : sqlite3 [파일 이름] )
anby@linux$ sqlite3 hacking.db
SQLite version 3.41.0 2025
Enter ".help" for usage hints.
sqlite>

'sqlite3 hacking.db' 명령어를 입력해, "hacking.db" 데이터베이스 접속에 성공하면,
프롬프트가 "sqlite>" 로 바뀝니다.
이제 "sqlite>" 뒤에 명령어를 넣어가며 데이터베이스의 테이블 구조와 저장된 데이터를 확인하면 됩니다.
(테이블 (table) = 하나의 sheet (액셀 sheet 생각하면 됩니다))
 
우선, '.tables' 명령어를 입력해서 어떤 테이블들이 존재하는지 확인합니다.

( 입력 : .tables )
sqlite> .tables
hackers

"hacking.db" 에는 "hackers"라는 테이블만이 존재함을 알 수 있습니다.
 
이제 "hackers" 테이블의 정보를 좀더 알아봅시다.
"PRAGMA table_info(hackers);" 명령어를 사용하여, hackers 테이블의 스키마를 확인할 수 있습니다.
(스키마 (schema) = 시트에 어떤 열이 있고, 각 열에는 어떤 타입의 데이터가 들어오는지 지정한 설명서)

( 입력 : PRAGMA table_info([테이블 이름]); )
sqlite> PRAGMA table_info(hackers);
0|hackID|TEXT|1|NULL|1
1|hackGroup|TEXT|1|NULL|0
2|age|INT|0|NULL|0
3|password|TEXT|1|NULL|0

PRAGMA table_info 명령어를 통해 column index, column 이름, 데이터 타입, NOT NULL 여부, 기본값, 기본 키 여부를 출력했습니다.
 
출력된 내용을 분석해봅시다.
- 우선 맨 앞 숫자는 column index로 각 column의 순서를 나타냅니다.
- 두 번째는 coulmn 이름으로 말 그대로 해당 column의 이름입니다.
- 세 번째는 데이터 타입으로, 해당 column의 데이터가 정수형(INT)인지, 문자열(TEXT)인지 등을 알려줍니다.
- 네 번째는 NOT NULL 여부로, '0' 이면 NULL 값을 데이터로 가질 수 있다는 뜻이고, '1' 이면 NULL 값을 데이터로 가질 수 없기에 무조건 어떤 데이터를 품고 있어야 합니다.
- 다섯 번째는 기본값으로, 'NULL' 이면 기본값이 없는 것입니다.
- 마지막은 기본 키 여부로, '1' 이면 기본 키를 가지고, '0' 이면 가지지 않습니다.
 
즉, PRGAM table_info 명령어는 원하는 테이블의 스키마를 확인할 수 있는 명령어이고,
지금 출력된 내용들이 해당 테이블의 데이터 구조임을 알 수 있습니다.
(쉽게 말해, 스키마 = 테이블의 데이터 구조)
 
 
이제 스키마 (데이터 구조)를 파악했으니, 본격적으로 데이터들을 확인합시다!
'SELECT * FROM hackers;' 명령어를 사용하여, hackers 테이블 안에 있는 데이터들을 출력합니다.

( 입력 : SELECT [원하는 컬럼] FROM [테이블 이름]; )
sqlite> SELECT * FROM hakers;
0|Ivy|Cytus|600|949a14829b9d2e76507b2b5d0b1b5bc0
1|Kururu|Keroro|6000|b55ea8572786c4e981d7121464d08
2|SilverWolf|Stellaron|25|ab1087fb6126aecd6d802a13c9b4575c
3|Mr.Robot|FSociety|31|60909f3b178c770ef8fdc2b4a4c85630

SELECT 명령어를 통해 원하는 column들을 지정하고, 조회할 수 있습니다.
( * 은 모든 것을 선택한다는 의미를 가지고 있습니다)
FROM 명령어는 내가 데이터를 조회할 테이블을 선택합니다. (어떤 테이블에서 데이터를 가져올 것인가!)
 
즉, 'SELECT * FROM hackers;' 는 hackers 테이블에서 모든 column들을 조회하겠다는 의미입니다.
 
자료의 순서는 위에서 확인한 스키마대로 구성됩니다.
맨 앞의 순서 index를 제외한다면, hackID, hackGroup, age, password 의 순서로 각 column에 해당되는 데이터들이 출력됩니다.
첫 줄을 예시로 살펴보면, " hackID = Ivy, hackGroup = Cytus, age = 600, password = 영어로 긴거" 입니다.
 
 
 

[7]  Cryptograhic Failures (Supporting Material 2)

 위에서 데이터베이스에 대해 살펴보았습니다. 방금의 예시를 통해 확인했듯이 비밀번호 같은 중요 정보들은 대부분 Hash 값으로 변환해둡니다. (이상하게 생긴 긴거)
Hash 값은 복호화를 할 수 없기 때문에 보안이 강화되고, 또한, 데이터의 무결성(integrity) 검증에도 활용됩니다.
(복호화 = 암호화된 데이터를 원본으로 되돌리기 / 무결성(integrity) = 데이터가 변조되지 않고 원본 상태 그대로 유지되었는가)
 
 
설령 우리가 데이터베이스를 성공적으로 해킹했다고 해도, Hash 값만으로는 저 정보가 무엇인지 정확하게 알 수 없기에 해킹 성공이라 보기 힘듭니다.
이 Hash 값을 부수고 비밀번호의 원본을 알아내기 위해 한 가지 사이트를 활용해보겠습니다!
 
CrackStation 사이트는 간단한 수준의 Hash 값들을 자동으로 cracking(크래킹) 해줍니다.
CrackStation 주소: https://crackstation.net/

https://crackstation.net/

왼쪽 네모 상자에 Hash 값을 넣어주고 '로봇이 아닙니다' 체크 후, "crask Hashes" 버튼을 눌러준다면,

이런 식으로 Hash 값의 원본을 알아낼 수 있습니다.
 
 
 

[8]  Cryptograhic Failures (Challenge)

 Task 8 상단부를 보시면, 실습환경을 열수 있는 링크가 있습니다. (갈색 네모로 가린 부분)

아마 "http://[IP 주소]:81" 형태

실습 환경을 실행해보면,

이런 식으로 웹사이트 하나가 나오게 됩니다.
 
우리의 미션은, 숨겨진 페이지에 저장되어있는 데이터베이스를 탈취해내는 것입니다.
힌트를 확인해보면, 개발자가 민감한 데이터가 들어있는 특정 디렉토리를 메모로 남겨둔 것같습니다.
 
개발자가 남긴 메모를 확인을 위해, 현재 웹페이지의 HTML 코드를 찾아봐야 될 것 같습니다.
"ctrl + U" 를 누르면, 브라우저가 현재 페이지의 HTML 코드를 원본 그대로 보여줍니다. (개발자가 남긴 주석까지!)
 
한편 현재 페이지에서 ctrl 키와 U 키를 동시에 눌러보면,

메인 페이지의 HTML 원본 코드

이런 식으로 메인 페이지의 HTML 원본 코드를 확인해볼 수 있습니다.
 
여기선, 딱히 유용한 정보가 보이지 않습니다.
하지만, 우리가 확인해볼 수 있는 페이지가 하나 더있습니다.
바로, 로그인 페이지입니다.
 
Login 버튼을 눌러 로그인 페이지로 이동한 후,

로그인 페이지

로그인 페이지의 HTML 원본 코드를 확인해보면,
개발자가 남겨놓은 민감한 데이터가 담긴 숨겨진 페이지를 찾아낼 수 있지 않을까요?
한 번 찾아보세요.. (글의 맨 마지막 부분에 숨겨진 페이지가 있는 부분을 알려드리겠습니다. 해결 못하시면 참고하세요)
 
 
이제 찾은 숨겨놓은 페이지로 이동을 합니다.
현재 우리가 이동할 수 있는 페이지는 메인 페이지와 로그인 페이지 2가지 이고,
각각의 url 뒤에 "/[찾은 페이지]" 형식으로 이동해보세요.. 
 
 
이런, ".db" 형식의 데이터베이스 파일이 있는 페이지로 이동하시면, 성공입니다.

숨겨진 페이지

이제 이 데이터베이스 파일을 다운로드 받으시면 됩니다.
(여러분이 Start AttackBox를 통해서 TryHackMe 사이트 상의 가상 머신을 활용한다면, 데이터베이스 파일이 성공적으로 다운로드 되고, Task 6에서 배운 내용으로 데이터를 확인해보실 수 있습니다.)
(하지만, 자신의 인터넷의 새 탭으로 실습을 했을 경우, 데이터베이스 파일을 열 방법이 없습니다! = AI 활용하세요)
 
원래라면, 우리는 Task 6에서 배운 방법대로, 터미널을 연 뒤, sqlite3 명령어를 사용해서 데이터를 확인해야 합니다.
하지만, AI를 활용하면, 손쉽게 데이터베이스 파일의 내용을 확인해볼 수 있습니다. (저희같은 무료 사용자들도요!)
 
다운받은 .db 파일을 ChatGPT, Gemini 같은 AI에게 넣어 내용을 확인해달라고 요청하면 해결할 수 있습니다!
(하지만, 실무에서는 절대 하시면 안됩니다!! 오류로 인해 편법을 사용한 것이니 실전에서는 써먹지 마세요)

 
 
어쨋든, 데이터베이스 파일에서 성공적으로 관리자 계정의 비밀번호를 Hash 값으로 획득했다면,
Task 7 에서 사용한 CrackStation 사이트를 통해서 본래의 비밀번호를 얻어냅시다!
(보통 모든 서버의 관리자 계정은 admin 으로 저장됩니다)

 
이제 우리는 admin 계정의 비밀번호도 얻었으니 로그인을 해보면,

 
성공적으로 관리자 계정으로 들어올 수 있게되면서, 해킹에 성공하게 됩니다.

로그인 성공!

 
이렇게 성공적으로 Cryptograhic Failures 취약점을 실습해보았습니다!
결과적으로 EP.2 에서는 OWASP Top 10에 해당되는 취약점 중 하나인 Cryptograhic Failures에 대해 학습했습니다.
 
 
 

[TryHackMe] OWASP Top 10: 2021 - EP.2 (Task 5~8). END.

 
 
[TryHackMe] OWASP Top 10: 2021 - EP.3 (Task 9~10). Continue...

(EP.3 에서는 Injection 취약점을 학습합니다!)