它是 酒仙桥六号军队 的第 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提权。