Hydra sang php

Geisha là 1 cỗ máy leo thang quyền trên Linux được thiết kế bởi SunCSR team, thông tin về cỗ máy các bạn có thể xem thêm tại đây

Sơ lược thì geisha là 1 phòng thí nghiệm khá cơ bản nên với bài Sumo lần trước mình làm thì bài này có thêm nhiều "lỗ thỏ" để lừa đảo và làm mình mất thời gian. Cũng như bài viết Sumo trước đó, bài viết này cũng sẽ được trình bày theo từng bước một, từ bước cơ bản nhất cho đến khi lên root

Sau khi tải file OVF về chúng ta chỉ cần giải nén ra, sau đó mở bằng VMware. Tệp > Mở. (Ctrl + O) để tiến hành cài đặt máy

Lưu ý. Geisha mặc định đang ở chế độ Bridge, trước khi chạy máy chúng ta cần chuyển sang chế độ NAT

Search information

Quét IP của máy

Đầu tiên mình cần kiểm tra ip của máy ảo Kali bằng lệnh.

-rw-r----- 1 root root 4 Dec 27 23:19 flag

IP của Kali là

-rw-r----- 1 root root 4 Dec 27 23:19 flag

-rw-r----- 1 root root 4 Dec 27 23:19 flag

-rw-r----- 1 root root 4 Dec 27 23:19 flag

Đã có ip của máy Geisha là

-rw-r----- 1 root root 4 Dec 27 23:19 flag

Quét các cổng và dịch vụ

Thường thì các bài lab, các máy có nhiều "lỗ thỏ" hoặc các bài ở mức độ khó vừa - cao sẽ mở rất nhiều cổng, chạy rất nhiều dịch vụ để làm nhiễu. Các máy này sẽ yêu cầu người làm phải nhạy bén, nhận biết sớm các đối tượng cần chú ý và chuyển sang hướng làm khác để không đi lạc quá sâu vào "treo thỏ"

Biết thế nào rồi, trước khi đến đấy chúng ta phải tìm ra cái "lỗ thỏ" thì mới biết đường mà tính được. Lần này mình sử dụng thêm 1 vài tham số với bài Sumo.

-rw-r----- 1 root root 4 Dec 27 23:19 flag

• -sS. quét bằng giao thức TCP SYN
• -sV. quét tìm phiên bản của các dịch vụ đang chạy trên cổng
• -ô. scan version OS
• -pn. tránh việc bị chặn khi gặp tường lửa
• -P-. quét tất cả các cổng

Như kết quả trả về, Geisha chạy dịch vụ web trên các cổng 80, 7080, 7125, 8088 và 9198,các cổng này khi truy cập đều hiển thị cái từng ảnh giống nhau.

Quét các thư mục của dịch vụ web

Do việc truy cập trực tiếp các dịch vụ web không thu nhỏ được thông tin gì, mình tiếp tục thực hiện quét các thư mục, đường dẫn của mỗi dịch vụ. Mình sử dụng công cụ dirsearch để quét, lệnh sử dụng là

-rw-r----- 1 root root 4 Dec 27 23:19 flag

• -r. tiếp tục quét sâu vào các thư mục được tìm thấy
• -u {ip}. {Hải cảng}. scan address
• -tôi 200-299,300-399. chỉ hiển thị các kết quả trả về mã 2xx (thành công) và 3xx (chuyển hướng)
• -e *. quét toàn bộ các phần mở rộng. php. html. aspx,

Kết quả quét cổng 80

Nhưng mà

Kết quả quét cổng 7080

Nhưng mà đều 404 hết, nên là

Kết quả quét cổng 7125

Trông có vẻ hay ho, nhưng cứ để tạm đó đã, lát mình sẽ quay lại sau

Kết quả quét cổng 8088

Có nhiều kết quả ở đây, mình đã thử truy cập hết. Kết quả thật bất ngờ. chẳng có gì cả -_-

Kết quả quét cổng 9198

Continue is

Kiểm tra cổng 7125

Xem lại kết quả quét thì có 3 đường dẫn cần kiểm tra là /index. php, /chỉ mục. php/đăng nhập và /passwd

Hai đường dẫn đầu thì không có gì đặc biệt, nhưng khi truy cập đường dẫn /passwd sẽ tải được 1 file 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:/var/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-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:110::/nonexistent:/usr/sbin/nologin
sshd:x:105:65534::/run/sshd:/usr/sbin/nologin
geisha:x:1000:1000:geisha,,,:/home/geisha:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
lsadm:x:998:1001::/:/sbin/nologin

SSH vũ phu

Khi máy chủ bật dịch vụ SSH, mình có thể thử Brute Force SSH để truy cập vào máy chủ. Tuy nhiên, công việc Brute yêu cầu cần có danh sách từ lớn và mạnh mẽ mới thực sự hiệu quả

Ở máy này tác giả cho mình Chắc file /etc/passwd nên có thể thử Brute Force SSH được. Phân tích file passwd có thể thấy ngay user geisha có uid=1000. Thường thì khi cài đặt Linux, đầu tiên người dùng do chúng ta tạo sẽ có uid=1000, những người dùng được tạo sau đó sẽ có uid tăng dần từ 1000. Như vậy có thể thử mật khẩu Brute Force SSH của người dùng geisha

Nếu như có ai thắc mắc liệu người dùng có thể vũ phu được không thì đây là câu trả lời

• Số lượng người dùng trong tệp /etc/passwd là người dùng được tạo ra khi cài đặt hệ thống điều hành, hoặc được tạo ra trong quá trình cài đặt 1 số dịch vụ. Người dùng này chỉ được điều hành hệ thống sử dụng để chạy các dịch vụ và không thể đăng nhập vào được. Chú ý phần cuối cùng của mỗi dòng trong tệp /etc/passwd, phần này chỉ hiển thị shell mặc định của mỗi người dùng được sử dụng sau khi đăng nhập. With the user has shell only is /usr/sbin/nologin, /usr/bin/true, /usr/bin/false,. will not be login to be. Đọc thêm thông tin tại đây
• Ngoài user đặc biệt kia thì user root cũng không nên thử khi SSH Brute Force. Lý do là mặc định dịch vụ SSH sẽ không cho phép sử dụng mật khẩu khi SSH vào bằng user root, chưa nói đến độ khó thì việc Brute password của user root cũng không có tác dụng gì nhiều

Search qua qua thì mình tìm được hướng dẫn Brute Force SSH khá đơn giản trên hacknos. Tất cả công việc mình cần làm là chạy lệnh

-rw-r----- 1 root root 4 Dec 27 23:19 flag

OK, đã có user name là geisha và password là letmein, giờ thì SSH vào thôi

Tìm đường lên gốc

 Khai thác hạt nhân

Sau khi kiểm tra thấy máy đang chạy kernel bản 4. 19 mình search ngay xem có cách nào khai thác được không. Mình có thể dễ dàng tìm thấy PoC của CVE-2019-13272 cho phép cấp quyền root

Xin lỗi là mình chưa thử xem mã trên có hoạt động với kernel bản này hay không. Do máy không cài đặt gcc, user geisha thì không có quyền sudo, và file /etc/sudoers cũng không được chỉnh sửa luôn. Do đó là đường Kernel khai thác cụt

Leo quyền nhờ SUID

Lý thuyết

Leo quyền qua SUID là một trong những hướng dễ tiếp cận. Ý tưởng cơ bản là tìm các tệp điều kiện đối xứng 2

• Tập tin thuộc quyền sở hữu của người dùng root
• Tệp đã được gắn SUID
• Mình được cấp quyền thi file đó

Khi 1 file đáp ứng các điều kiện trên thì bất kỳ user nào chạy file này đều sẽ tương thích với user root chạy file. Nói đơn giản thì coi như chúng ta có quyền root (với cái file đó thôi. v)

Ví dụ khi kiểm tra cờ tập tin bằng lệnh ls -la được xuất ra sau

-rw-r----- 1 root root 4 Dec 27 23:19 flag

Khi đó chỉ user root mới có quyền đọc file flag. Nếu lúc này kiểm tra tệp /usr/bin/nl bằng lệnh ls -la đã được kết quả

Thì người dùng thường sẽ chạy lệnh nl với quyền root và có thể đọc cờ tệp

Áp dụng vào máy Geisha

Đầu tiên, ta thực hiện tìm kiếm các tập tin được chạy với quyền root bằng lệnh

-rw-r----- 1 root root 4 Dec 27 23:19 flag

Các tập tin trong /usr/bin/ là các lệnh được chạy với quyền root

• mount and umount is command working with disk disk
• newgrp và gpasswd là lệnh làm việc với nhóm. Mình đã nghĩ đến việc sử dụng lệnh newgrp để chuyển người dùng geisha sang nhóm root, tuy nhiên không thành công. Do newgrp chỉ được chuyển dễ dàng khi 1 người dùng đã có sẵn trong nhiều nhóm, lúc này có thể chuyển giữa các nhóm với nhau.
  Lệnh newgrp cũng có thể thêm người dùng vào nhóm, nhưng nếu nhóm đó đã là quản trị viên nhóm đặt mật khẩu bằng lệnh gpasswd thì phải cung cấp mật khẩu mới có thể thêm vào nhóm đó.

• sudo, su và passwd thì quá quen thuộc rồi, 3 lệnh này không giúp mình root được
• chsh và chfn lần như lệnh thay đổi shell đăng nhập và thông tin người dùng, không làm được gì ở đây
• base32 có thể mã hóa tệp hoặc đầu vào từ stdin, cũng có thể giải mã base32

Khi tìm kiếm trên gtfobins cũng có thể sử dụng lệnh base32 để tiến hành leo quyền. Trong trường hợp /usr/bin/base32 có gắn suid thì có thể vượt quyền, đọc các tệp không được cấp quyền truy cập

Chi tiết xem tại base32. GTFOBin

Đọc khóa riêng SSH

Với SUID được gắn cho lệnh base32 thì mình có thể đọc được rất nhiều file, tuy nhiên để đọc được luôn cờ thì mình phải biết cờ lưu ở đâu. Cách này thì hơi hên xui, dựa vào kinh nghiệm mà đoán thì mình cũng may mắn đoán được 1 trong 4 cái tên

• /gốc/gốc
• /gốc/gốc. txt
• /root/cờ
• /root/cờ. txt

Tuy nhiên cách này không chắc lắm, nên mình muốn tìm 1 cách khác chính thống hơn. Nghĩ về việc đọc được các file quan trọng trên Server Linux thì mình có 2 ý tưởng

• Đọc /etc/shadow và crack password của user root => su root
• Đã đọc SSH private key của user root => ssh -i {private-key-file} root@{ip}

Sau khi đọc /etc/shadow thì mình cứ tắt luôn ý tưởng đi tiếp

-rw-r----- 1 root root 4 Dec 27 23:19 flag

Thấy trường mật khẩu của người dùng root bắt đầu với $6$ là mình thấy hướng này không tương lai rồi. Bởi vì đó là dấu hiệu cho thấy mật khẩu được băm với SHA-512 cơ. Nếu là $1$ - MD5 thì có khả năng crack được, SHA-512 thì chịu thôi

Như vậy thì chỉ còn 1 hướng đó là đọc SSH private key thôi. Khóa cá nhân của người dùng root nằm tại /root/. ssh/id_rsa. Theo hướng dẫn trên GTFOBins, thì có thể đọc được bằng lệnh

-rw-r----- 1 root root 4 Dec 27 23:19 flag