黑盒漏洞挖掘(WEB篇)

在安全测试中,我们常常会遇到一些重复性工作。而鄙人记性不佳,有时候并不能高效的进行工作。因此,自己萌生了撰写工作总结的想法,将以往的工作列清单,做一个总结,以作查阅之用。

当然,这个系列也希望会持续更新。人,总是要有进步不是。

克敌机先

在测试某个网站时,我们常常需要先探测该网站的基本信息:

  • 是否存在WAF,像创宇盾这种检测到攻击会马上暂时性封IP,阿里云盾偷偷摸摸检测到攻击行为后,会直接无前兆地封禁你IP,至于安全狗、D盾、云锁、百度云安全这种就不一一例举了,暂时不细说。
  • 路径扫描,如果存在WAF或者目标较为脆弱,可以直接调整为非常低的线程数,比如一个线程,然后对目标进行文件/目录低速探测。如果没有太多限制,那就使劲儿造作。
  • 如果需要测试的网站比较大且比较耐操,且没有WAF/IDS,建议配置好去重和线程,使用大型扫描器对网站进行探测。这样做的好处是不会漏掉一些常用的漏洞,而且可以获取网站的结构。但缺点是需要等待比较长的时间,也容易被管理发现。
  • 部分网站的后台,可能存在于域名的其他端口上。如果服务器不存在CDN,这时候可以借助类nmap的扫描器来探测端口开放情况,比如使用命令: ``` nmap -sS -sV -p- –script=”http-title,banner” 192.168.2.10

```

  • 插件检测server类型,是否为tomcat/jboss/glassfish之类,探测是否存在可访问webserver console。
  • 检测网站是否为公开的CMS,探测CMS类型,漏洞库是否存在相关漏洞。
  • 查看有无列目录的权限。
  • 查看是否提供附件下载,如果是参数传递的URL,这类链接通常比较敏感。如果可以明显给出了文件的相对/绝对路径/可预测的类文件名id,我们可以优先进行任意文件下载测试,其次再进行常规漏洞测试。如果仅仅是给出了普通的id值,那可以直接进行常规漏洞测试。
  • 查看网站是否有明显的配置漏洞,比如提供了allow *的crossdomain.xml;没有进行过滤的robots.txt;容易猜测名字的源码压缩包;泄露敏感信息的配置文件、JS文件甚至普通html文件;.git/.svn文件供下载等。

权限,权限!

在遇到某个网站时,窃以为应该先寻找能够获取更大权限的地方,而登录后的权限无疑会更大。

这时,我们可以尝试进行注册,或者夺取原有的账户权限。

此时有一点需要注意,在登录的入口处和搜索处,可能存在一定的脆弱性,建议同其他前台产生的敏感数据包一同进行fuzz检测。

自给自足

在本身无权限时,我们可以去寻找注册的地方,间接获取更高的权限。 同时在此过程中,我们有几个点需要注意:

  • 研究找回密码功能,查看是否有无逻辑漏洞可以跳过,可否预测和爆破验证码。
  • 可能存在上传,查看能否直接获取webshell
  • 可能存在XSS,如果在注册能直接通过时,需要等待注册完毕,去用户中心再继续测试。如若需要等待审核,可以尝试植入XSS平台代码,等待机器上线。
  • 如若存在手机和邮箱验证,可尝试有无邮箱炸弹漏洞。
鸠占鹊巢

有时候管理或者开发不够细心,我们可以通过各种手段去获取原有普通用户或者管理用户的权限。在我们能够比较容易的获取后台登陆口,或者在无法注册用户时,我们可以如此操作:

  • 通过手工猜测密码/识别简单验证码/验证码绕过/直接爆破,猜测密码,来获取原有用户的权限。
  • 查看用户名是否存在,尝试能否预测/枚举用户,可能有机会猜测管理账号。
  • 搜寻文档,后台页面可能存在一些敏感说明文档提供下载,里面有可能会记录测试账号等敏感内容,对测试会比较有帮助。
  • 万能密码绕过,这种情况一般asp和php类型的网站会存在的稍微多些,不过新一点的网站这样的问题越来越少了。
  • 禁用JS,直接卡入后台管理页面。这种情况一般需要预先爆破或者在JS源码里找寻后台路径,然后再使用该方法。
  • 工具/插件修改cookie,直接进入管理后台。这种方法比较古老了,现在成功的几率是比较小的。
  • 善用类Google/类Github/类shodan引擎,搜寻泄露的后台账号密码/带认证的链接等等。
  • 设法找寻网站管理和开发者的相关信息,查找社工库组合相关密码。如果是针对企业和组织进行渗透,可设法查询社工库里相关的邮箱密码,再借助可登入的邮箱翻看敏感内容,从而达到进入后台的目的。

用户中心

登入网站用户中心后,我们一般可以做如下测试。

  • 抓包测试,查看在数据包中修改参数,能否越权枚举和修改用户的基本信息/订单/地址等内容。
  • 在用户互发私信功能处,可能存在存储型XSS。
  • 如若在注册时,并未测试存储XSS、邮箱/手机/私信炸弹、越权修改密码,可在此测试。
  • 查看是否存在附件上传/头像上传,文件命名规律也可稍作检查,最后查看能否直接获取webshell。
  • 查看搜索功能是否有别于前台,能否间接枚举用户或者手机号。
  • 在用户中心进行SQL注入和XSS的fuzz测试,成功几率大抵会高于前台。
  • 对于邀请注册/登出系统/登录跳转/注册验证的链接,都可能存在任意URL跳转的漏洞。
  • 如果用户中心未启用token验证,在修改密码/修改用户名和昵称/修改地址/修改邮箱和手机号等地方,很可能存在CSRF漏洞。
  • 上传后的地址可能存在列目录漏洞。

管理后台

  • 管理后台可能存在上传的地方,可以尝试能否获取webshell。
  • 上传处,如若能上传文本类型文档,查看是否有预览功能,进而考虑能否写入存储型XSS。
  • 上传处,如果能够上传XML文档,或者只是提交XML内容,可以尝试XXE攻击。
  • 上传处,如果过滤了大多数动态文件,但并不是使用的白名单,可以考虑上传shtml,同样可能执行命令。
  • 配置处可能存在未过滤的地方,可以直接写入存储型XSS。
  • php类的网站,有的可以通过转义和截断,往配置文件里写入webshell。
  • asp类的网站,可以通过写配置,然后数据库备份得到webshell,这里不细说。
  • 后台大多验证不严,可以尝试SQL注入和XSS的fuzz测试。
  • 后台可能存在执行命令的地方,可进行fuzz,获取敏感配置或者直接反弹shell。
  • 如若后台存在通讯录,在不违反合规条款的情况下,可尝试自行处理。
  • 部分后台如果存在管理用户表,在不违反合规条款的情况下,可尝试自行处理。
  • 管理后台大概率不会验证token的,所以很多网站后台也因此存在CSRF。
  • 如果非管理用户,也可以尝试越权修改其他用户的密码。
  • 后台有时会存在读取文件内容,或者探测内网存活的功能,抑或是上传特殊文件进行解析,可以尝试是否存在SSRF。

权宜之计

如果我们无法登陆后台,也无法注册怎么办?我们可以尝试以下几种做法:

  • 评论处可能存在上传和存储型XSS,也可能存在没有验证重复提交的CSRF。
  • 提交个人建议等供审核的内容时,有可能后台没有做XSS过滤,这时候就可以进行盲打。
  • 某些用户的个人页面可以通过枚举id获得,里面可能存在一些敏感信息。
  • 在前台或者用户中心,可能存在星号隐藏一些敏感信息,比如说手机号。这些信息在某些时候,可能在源码里直接或者间接能看到。
  • 前台可能存在一些伪静态页面,建议随手尝试注入,虽然现在这样的案例已经比较少了。
  • 在尝试列目录漏洞时,可以在目录后面加上XSS字符尝试是否有反馈,也可以尝试不存在的文件名(hacksb.php)或者错误的文件名(~list.aspx、error.jspx)进行报错。

端口入侵

  • 某些端口存在服务认证,如果有弱口令/默认口令,可以爆破进入。
  • 某些WebServer在特定端口,同样存在单独的WEB登陆口,如果突破进入后台,可以部署包拿webshell,也可能执行命令反弹shell。
  • 代理端口,这类服务比较少,如果找到可以尝试连接,设法将其作为跳板,切入内网。
  • 特定端口开启的服务,可能存在RCE,结合MSF可以反弹shell。

细节思考

  • 测试敏感点注入时,最好多尝试几遍,加上risk、level、random-ua以及tamper,不要过于依赖扫描器或者fuzz工具。
  • 测试XSS的时候,最好先用字符试水查看过滤情况,有时候不能直接使用payload的时候,可以尝试绕过。
  • 上传时可能存在黑/白名单时,每次手动改包会很麻烦。最好是通过字典批量发包进行fuzz。另外,%00不管用时,可以替换成类似的空白字符段(以后补上细节)。
  • 绕过逻辑改包,无论是上传还是找回密码,记得每步截图,也许有时候只有一次机会。
  • 修改状态码时,也许能够通过辅助插件,自动化fuzz判断。
  • 调用callback内容时,其内容也许可控,我们可以尝试往里面注入污染语句。最后,再尝试寻找调用callback的地方。
  • 找后台一般有几种情况,可以是子目录,也可以是同域名下其他端口,甚至是其他子域名。比如统一SSO登录的情况下,一套网站总会有一个唯一入口。但由于历史的原因,总会遗漏和不统一的地方,那就是我们的突破口。
  • 待续。