06BWAPP通关指北——敏感信息泄漏篇

夺旗攻略 2019-01-14

作者:古月蓝旻

Base64 Encoding (Secret)--full

让我们去解密cookie,先说下cookie加密的重要性吧,由于HTTP是无状态协议,服务端仅能通过cookie来识别客户端身份,那么cookie如果是明文或者弱加密的状态,恶意攻击者可推测处其它用户甚至管理员的cookie从而实现越权

先看low级别下的,显然base64

直接解即可

然后medium/high级别下,40位16进制数,很可能是SHA-1

前往https://www.somd5.com/进行解密

看源码可知真相

所以cookie的加密方式可以严苛点,来点username+password字符一起进行加密也是业内比较常见的做法

BEAST/CRIME/BREACH Attacks--low

老版本TLS 1.1的几类经典漏洞,墙外有一篇文章说的非常nice,强烈建议下载pdf通读

Attacks on SSL

SSL ATTACK

这里的漏洞主要是针对TLS/SSL老版本加密算法存在的一些缺陷,配合中间人,已知明文攻击等方式去还原加密数据包

网页提示提供了OWASP提供的O-SAFT,这个其实主要可以用于检测站点HTTPS加密算法的安全性,基于perl语言,网站直接给的包并不能使用,可以去官网和git上下载

github-OSAFT

O-Saft

里面最坑的就是要去自己安装perl的相关模块

Clear Text HTTP (Credentials)--low

明文登录凭据传输,这个没什么好说的,burp也告诉你了

medium和high级别都是告诉你走https

Heartbleed Vulnerability

心脏滴血漏洞,经典中的经典,之前还做过分享CVE-2014-0160,利用老版本openssl的缺陷,一次可从服务端内存dump共计64KB数据!

网站非常良心提供了脚本,用法写的很清楚

为了能抓到帐号密码信息,我先去

https://192.168.248.130:8443

注销又登录了一次,此时使用py攻击

帐号密码毕露无遗

Host Header Attack (Reset Poisoning)--low

涨姿势的一道题,常见于PHP类型站点的密码找回处,可以先看看以下几篇文章和案例学习一下

What is a Host Header Attack?

Email link poisoning / Host header attack

https://www.owasp.org/index.php/Cache_Poisoning

实战Web缓存中毒

回归到本题,这道题的逻辑是这样的:输入一个注册用户的邮箱,服务器会给该邮箱发送一个重置secret的邮件,里面有一个重置secret的链接。

这个套路我们在重置密码邮件里其实挺常见的,但是那里主要想的攻击点在于破解链接里token的算法实现重置任意用户密码

好了,现在这道题给了我们另外一个重置密码的思路,就是改“HOST”

好了,有人说,改HOST?改完你邮件都发不出去,服务端根本没收到请求,都不会生成重置密码链接的好伐?

是的,这里的HOST我们不改

那么我们先想一想,对于重置密码邮件而言,什么最重要?

自然是生成的重置密码连接,比如

http://www.a.com/resetpass.php?token=aaabbbcccddd

常规想法是破token啊,能自己算的话岂不美哉?

但是事与愿违,很多时候token的算法没有那么不堪一击那怎么办?

好的,如果我们能直接拿到token或者能拿到resetpass.php?token=aaabbbcccddd这一部分,其实就可以重置密码了

那么怎么拿呢?如果这个时候重置链接长这样

http://www.attacker.com/resetpass.php?token=aaabbbcccddd

我们又是attacker.com的主人,看一下自己站点access.log就能拿到resetpass.php?token=aaabbbcccddd了

有人说,可能吗,重置密码连接怎么可能使用其它域名

有可能的,只要你的代码是本题这么写

$server = $_SERVER["HTTP_HOST"];

$content.= "Click the link to reset and change your secret: http://" . $server . "/bWAPP/secret_change.php?email=" . $email_enc . "&reset_code=" . $reset_code . "nn";

重置密码链接由多部分拼接而来,其中服务端取HOST头

有人说,HOST头你怎么改?明显不存在的嘛

NO,在某些配置中,使用X-Forwarded-Host头是可以改写Host头的

所以我们只要在重置密码的请求里添加X-Forwarded-Host头,然后里面写成我们自己的恶意服务器,就可以生成假的重置密码链接

好了我们实践一下

由于服务器发不了邮件,我们该下源码,把重置链接输出出来

正常重置

增加头

然并卵,返回链接还是没有变,为什么呢?因为缓存我们没改掉,所以没有投毒成功,但是真的没办法了么?其实也不是,误打误撞摸索出一种方法

首行改为绝对路径,HOST改成我们自己的服务器地址,由于源码中从HOST取值,所以请求既发出去了,恶意链接也生成了

效果如下

后来和小伙伴试验了一下,不改成绝对路径,只改HOST也可以生成恶意链接

由于Target里面的Host已经被固定为192.168.248.130,看来又是一种新思路,host在请求时也不是那么重要,如果服务器刚好取了server_host作为重置链接的一部分,那么host攻击者可以任意改

这里没有用到缓存投毒的思路,还是略有遗憾

防御的思路自然是吧server地址写成定值

HTML5 Web Storage (Secret)--low

嗯,又到了补充知识的环节

HTML5拥有很多新特性,除了新增很多标签外,同时增加本地存储用户浏览数据的功能(web storage),主要是解决cookie本身的限制,同时减少服务端存储的内容。

web storage分为sessionstorage和localstorage

sessionStorage将数据保存在session中,浏览器关闭也就没了;而localStorage则一直将数据保存在客户端本地;

这里给两个资料参考一下

HTML5 Web存储(Web Storage)技术以及用法

HTML5 WebStorage

好了,回归本题,我们先在控制台里看看

存储-本地存储里面确实有login和secret

那么这个值怎么拿到呢?题目提示用XSS,但是看过源码可以知道,这道题本身没有输入和输出点,自然谈不上XSS

当然思路还是很好的,我们可以用console尝试alert一下,如果可以出来那么以后遇到有XSS的地方就可以用了

好了,根据上面的教程,我们构造一下

alert(localStorage.getItem('secret'))

当然也可以

alert(localStorage.getItem('login'))

嗯,控制台自己弹不过瘾,我去一个有XSS的页面试一下

XSS - Reflected (GET)--xss_get.php

直接来一波

<script>alert(localStorage.getItem('secret'))</script>
<script>alert(localStorage.getItem('login'))</script>

所以这里启发了一个新思路,如果某站点把重要信息存在了本地又存在xss,可以通过localstorage把东西取出来

POODLE Vulnerability--low

嗯,POODLE 漏洞,这个是针对SSL 3.0协议的漏洞,攻击者可以利用该漏洞发动中间人攻击拦截用户浏览器和HTTPS站点的流量,然后窃取用户的敏感信息,如用户认证的cookies信息、账号信息等。

SSL 3.0诞生于1996年,迄今已二十多年了,后来的TLS 1.0/1.1/1.2其实为SSL 3.1/3.2/3.3

我们知道SSL协议是为了解决HTTP明文传输的问题,那么这么历史悠久的协议在历史上也数次爆发过重大漏洞,有些是基于协议本身,有些是基于加密算法,而此次的POODLE漏洞,利用场景上看,更多被用于中间人获取HTTPS包中的cookie,利用前提在于攻击者处于中间人的位置,同时能控制客户端发送ajax数据包,通过控制客户端不断发送特殊明文包,经过SSL 3.0通过CBC模式进行加密,由于该模式的缺陷,从而算出cookie信息等。

详细分析过程见:

POODLE漏洞分析

POODLE漏洞东山再起,影响TLS安全传输协议

漏洞分析---SSLv3降级加密协议Padding Oracle攻击

本题并未提供实操环境,而且受限于客户端本身在SSL协商是否时同意使用SSL 3.0协议(目前浏览器几乎不可能),同时服务端SSL协商时也不一定使用该版本。漏洞复现较为困难建议了解即可。

SSL 2.0 Deprecated Protocol--low

嗯,这个不是说SSL 2.0是漏洞,而是协议里包含结构性漏洞

根据RFC6176的描述 SSL 2.0存在以下缺陷

1. 消息认证使用MD5,MD5算法很早就被证明不安全;
2. 握手包不受保护,中间人可以欺骗客户端选择比较弱的加密套件;
3. 消息完整性和消息加密使用相同密码,如果客户端和服务端协商使用若加密算法将会很危险;
4. 会话可以轻易被终止,中间人可以非常简单插入一个FIN包去关闭会话,而接收端都无法确认是否是会话正常终止;

所以这是一个缺陷协议,根据页面提示,还是使用OWASP的O-Saft进行检测,不过还是和上面一样,对perl不熟悉导致检测报错,当然AWVS也能检测这个漏洞

这里多给一些SSL/TLS缺陷方面的资料

felipe-tribaldos-ssl

Why is the deprecated SSL 2.0 protocol considered insecure and how can it be exploited?

Text Files (Accounts)--low

嗯,这个是安全配置的问题,有两个问题,首先任意输入内容,在low级别下,会创建一个文件,链接为

http://192.168.248.130/bWAPP/passwords/accounts.txt

点开以后发现是明文,造成了信息泄漏

其次就是这个地址,讲道理没有登录的用户甚至没有权限的用户根本访问不了,而我们测试发现,即使是注销状态访问上面的链接,都是可以直接进行查看,所以如果攻击者利用扫描器进行目录爆破,很有可能找到这个文件

好了,敏感信息泄漏篇完结,这一篇有些题目还是很有意思的


本文由 古月蓝旻 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

还不快抢沙发

添加新评论