它是 酒仙桥六号军队 的第 132 一篇文章。

全篇总共304一个字，预估阅读文章时间9分钟。

原因

渗入工作能力的反映不只是贮备0day的是多少，很多网站可否被提升，对自身基本系统漏洞的娴熟的相互配合利用也是一场磨练，小故事恰好是因纯属偶然取得shell的一次纪录小结。

从信息收集到进到后台管理

顾客给出的详细地址开启以后就只有一个登陆页面，留有沒有账户的我还在风中凌乱。

一直怼一个登陆框也不是事情啊，没法，只有先将端口号，文件目录和弱口令先检测起來。

端口号基础都开过觉得有点儿难题，ping 过以后发现有cdn。

很悲剧，弱口令没爆出去，文件目录端口号都没有过多的发现，重中之重便是必须一个账户进到系统软件。可是账户信息该从哪里收集？？？

这些，新项目逐渐顾客是出示了邮件地址做为汇报的递交详细地址的，首字母大写 名@xxx的文件格式，和很多公司的命名规范一样。

一边先把孩子的名字典结构起來，一边根据google英语的语法去检索有关电子邮箱，有关公司名字，运势非常好，从许许多多几十个论坛社区上边发现七八个企业邮箱，和好多个qq邮箱。

随后根据一些不为人知的的方式查取到在其中一些qq的绑定手机，及其历史时间登陆密码信息。

再度结构有关词典，果真大家都喜爱用相近的登陆密码，拖库取得成功。

进到后台管理后，逐个检测了一遍作用点都没能发现getshell的，提交也没能绕开后缀名限定。

都说沒有getshell的网站渗透测试不是及时的，只发现一些低中危系统漏洞可无法达到。

简易的权限验证绕开

由于沒有过多的获得，因此逐个浏览以前dirbuster跑出去的文件目录，在其中一个访问页面以后会出现一道阴影一闪而过，随后自动跳转到登陆页面，猜想干了权限认证，随后强制性自动跳转了。

检测中有很多情况下都很有可能碰到无权限浏览的状况

在我们碰到浏览403，401，302，或者弹窗提醒无权限能够尝试一下下列的方法。

GET /xxx HTTP/1.1 à403

GET /xxx HTTP/1.1 à403

302跳转：阻拦并drop自动跳转的数据文件，使其滞留在当今网页页面。

前面认证：只必须删除相匹配的挡住控制模块，或是是认证控制模块的前端代码。

这儿应用burp阻拦一下，丢掉后边的自动跳转，见到以下页面，弹出窗口還是提醒无法浏览，权限不足，可是和以前的浏览403不一样了，难道说就是我应用了一般账号登录的原因？？？

娴熟的开启F12开发者模式。删除前端代码看是不是能应用他的作用。

删完权限认证控制模块的前端代码后，运势非常好，也有一部分作用能够应用。

ssrf-通往shell的锁匙

在顾客系统软件后台管理转了大半天，最终在一个查询作用处发现了切入点

抓包软件发现post主要参数仿佛有点儿意思，尝试更换默认图片的详细地址，改成dnslog详细地址，回到提醒途径有误。

猜想是干了后缀名的限定，应当只有post png,jpg等后缀名的详细地址，先试一下载入一下虚拟服务器上的照片，取得成功回到，果真有物品。

一个规范的ssrf，，由于无法更改后缀名，应该是不可以载入passwd这类的文档了，還是先用一波dnslog，纪录一下真正ip详细地址。

可是ssrf并不仅仅读个文档这么简单，ssrf一般能够用于打内部网运用，根据它来打个redis或是mysql岂不美哉。

先依靠ssrf检测一下对外开放的端口号，22，80，443，6379。

看一下进攻redis一般能够利用的dict和gopher二种协议书，应用gopher协议书得话必须留意一些利用限定。

gopher协议书标准非常复杂，历经搜索，找到一款专用工具，应用其转化成的payload很精确，且可自定。

必须的小伙伴们能够自提。

必须将內容再开展一次url编号传入web的主要参数中才会一切正常运作。

Dict协议书敲指令比较立即。

1.载入內容；

2.设定储存途径；

3.设定储存文件夹名称；

4.储存。

大家一般对redis普遍的拒绝服务攻击有：

写webshell；

写密匙；

计划任务反跳。

第一种必须web途径，后二种方式很有可能必须一定的权限。

进攻的构思拥有，可是大家根据dict协议书浏览后并沒有发生回显，不清楚是不是存有未受权的redis服务项目，盲打一顿很有可能消耗珍贵的時间，灵光乍现，能够先写一个图片文件到tmp文件目录里，再根据file协议书开展载入，发生內容就说明redis是可以利用的。

发生回显，表明文档取得成功载入了，尽管有错码，可是危害并不大。

为了更好地取得shell，自然是先试一下用gopher协议书写密匙，该设备转化成密匙:ssh-keygen -t rsa。再应用专用工具将下列指令转化成gopher协议书适用的方式。

载入后尝试联接一下网页页面啥也没回到，尝试联接一下Wfk，忽然想到nmap結果仿佛ssh没扩大开放，效益性出错。

尝试反跳任务计划，可是等了大半天也没见shell弹回去，猜想可能是权限不足，没可以取得成功载入，遗憾早期检测中并沒有发现信息泄漏显现出web文件目录的途径，要不然能写个webshell也是很好的。

没法，这一只有先闲置一边，条条大路同罗马帝国，即然这一网站域名不好，看一下是否有关联的别的网站域名在这个ip上。

施工技术交底信息泄漏getshell

根据以前纪录的dnslog上的ip详细地址开展查取，发现了该ip详细地址下关联了别的网站域名。

浏览后改正url自变量后的默认设置主要参数，开启出错，取得成功曝出了相对路径，小小出错，却出示了极大的使用价值。

由于是施工技术交底，如今获得到B站的网址途径，假如能根据A站的ssrf把webshell提到B站的web途径里也是乐滋滋了，敢想敢干。

浏览shell，并敲入whoami指令查询权限，发现是个低权www客户。

提权

弹个互动的shell出去便捷开展提权，可是虚拟服务器一直无法一切正常接到shell。

转换一下端口号，网络工程师很有可能干了一定的限定，尝试根据443，53等常常对外开放的端口号弹出来shell。

取得成功取得shell，获得到低权限SHELL后一般会看一下内核版本，检验当今客户权限，再例举Suid文档，假如都没发现很有可能会依靠一些自动化技术脚本制作来查验很有可能存有的提权方法。

根据find / -perm -u=s -type f 2>/dev/null看一下有s属性文档。

Python好像是能够根据suid提权的，翻了翻自身的小手记，payload一发入魂。

这儿另附centos下suid提权比较全方位的小结：

到此检测完毕。

小结

全部检测全过程碰到许多艰难，很多地区看起来简易，实际上是不断尝试以后才成功通关。

检测中实际上仍未应用多么的厉害的进攻方式，简易整理全部步骤：各大网站信息收集发现管理员账户à拖库取得一部分登陆密码à前面认证绕开发现新作用点àssrf检测信息à施工技术交底获得web相对路径跨网址载入shellà取得shell后根据suid提权。