hblf 发布的文章

透过F5获取服务器真实内网IP

前言

渗透测试过程中,经常会遇到目标服务器使用F5 LTM做负载均衡。

如果能获取到目标服务器的真实IP地址,会给后续渗透带来一定便利。

本文既是最近渗透遇到的一点点经验分享。

F5修改cookie机制

F5 LTM做负载均衡时,有多种机制实现会话保持。

其中用到很多的一种是通过修改cookie来实现的。

具体说来,F5在获取到客户端第一次请求时,会使用set cookie头,给客户端埋入一个特定的cookie。

比如:

Set-Cookie: BIGipServerpool_8.29_8030=487098378.24095.0000

后续再接到客户端请求时,F5会查看cookie里面的字段,判断应该交给后续哪台服务器。

作为传统大厂,F5当然不会傻到直接把服务器IP address写入到cookie里面。

F5很巧妙的把server的真实IP address做了两次编码,然后再插入cookie。

所以,只要依据解码流畅,解开487098378.24095.0000的内容,就拿到了server的真实IP address。

解码思路

  • 首先,把第一小节的十进制数取出来,也即,487098378
  • 第二,将其转为十六进制数1d08880a
  • 第三,从后至前,以此取四位数出来,也即,0a88081d
  • 第四,依次把他们转为十进制数:10136829
  • 最后,得到真实内网IP:10.136.8.29

总结

严格意义上说,只有内网的私有IP,对正面突破目标防线的帮助并不明显。但是,当需要做内网渗透和漫游的时候,这一点信息还是有价值的。再不济,写report的时候,如果实在没的可写的时候,还可以拿这点作为一个issue作为丰富report的素材。

互联网企业安全高级指南读书笔记

前言

春节前花了几天时间,终于把这本书完整读完了。受益匪浅!

这是市面上第一本从总览的视角陈述甲方企业安全建设思路与框架,描绘企业内部信息安全全貌的书。

除了“战略”层面的全局观,这本书还难能可贵的深入了一些技术细节,在“战术”层面也不乏很多干货。

为了帮助记忆和理解,我基本上每章都用思维导图的方式整理了笔记。

这些笔记并非对全书的完整总结,亦非斗胆点评,仅作为个人理解和梳理思路的笔记之用。

第三章 甲方安全建设方法论

第三章.png

第四章 业界的模糊地带

第四章.png

第五章 防御架构原则

第五章.png

第六章 基础设施安全

第六章.png

第七章 网络安全

第七章.png

第八章 入侵感知体系

第八章.png

第九章 漏洞扫描

第九章.png

总结

总得来说,互联网企业和传统行业企业在安全建设的思路上,殊途同归。

不同点

  • 扩展性

互联网企业的业态具有大流量、高实时性、海量用户、海量数据的显著特征。由于流量太大,所以“两个海量”的特征与传统企业非常不一样。同时,互联网企业的线上业务就是钱,这样就决定了高实时性是必保的点。传统企业的线上业务即便是挂了,在一定时间内也不会直接影响生产力。

为了应对一大一高两个海量,传统安全企业的解决方案存在先天不足:无法无缝横向扩展。这就导致了互联网企业更多的选择自研防护手段。

互联网企业对安全防护手段的要求是,低维护成本+高扩展性。而传统企业呢,更看重的是易配置+防护全面。

  • 自研能力

这一点非常容易理解。互联网企业拥有足够的薪资吸引高端人才,所以才能支撑自研的需求。而传统企业除了保护线上业务外,还需要应对合规、内部防泄密等安全外延业务诉求。自身也不具备自研的能力。

相同点

  • 分层防御+威胁感知

无论是线上业务防攻击,还是内部治理防泄密,都必须依赖分层设计的多重防御措施交互实现立体化、深层次的防御能力。应对瞬息万变的攻击特征,必须具备第一时间感知威胁发生的能力。所以,无论是威胁情报,还是大数据分析,这些技术在不同业态的甲方企业内都会有持续的生命力和价值点。综上,虽然业态不同,但核心思想还是相通的。

另外,作者赵老师在书中提到,传统企业迫于提高生产力、提高效率的压力,业态向互联网转化的速度会越来越快。所以,互联网企业在线上业务安全防御方面的经验,领先传统企业十年,此言不虚。安全的本质始终没有变,就看在不同环境下怎么玩的踏实,怎么玩出精彩。

与君共勉。

从甲方的角度谈谈WAF测试方法--part2

继Part1之后,停了将近半个月才动笔写第二部分,不是因为懒,实在是最近几个项目事情多。顺手还准备了几个面试,耽搁到了现在。

今天把这篇给自己的总结写完吧。

0X05 Webshell防御

webshell拦截

文件上传防御难免百密一疏,普通的webshell上传后,攻击者必然要通过与webshell通信,开展后续渗透。WAF必须有能力识别通信内容,并及时阻断。很多webshell的通信内容是经过base64编码的,WAF必须具备解码后准确分析的能力。

测试方法很简单,在服务器上放好测试的webshell,客户端通过WAF后访问webshell,执行重要的操作,如:dir、ls、net user等系统命令;连接操作数据库;上传下载文件等。

这项测试需要收集大量常用webshell,用于覆盖常见webshell的识别。Github上有一个项目收集了各种格式的webshell,妈妈再也不担心我找不到shell啦。

Github webshell collect

一句话拦截

如果服务器安装有杀毒软件,常见webshell是可以被查杀的。大马能拦住,小马当然也不能放过。一句话木马可是杀软无力识别的。

防御一句话,其实防御的是菜刀以及各种版本的菜刀与一句话的通信。

这里要重点说两款工具:

  • cknife:项目地址,这把刀可以自定义各种通信方式和php执行函数用于绕过waf检测。实际测试下来,的确很多家waf的默认策略对自定义模式拦截无力。
  • antSword:项目地址,修改版的菜刀,也很好用。

0X06 暴力破解及其他杂项

暴力破解

WAF必须具备识别工具自动爆破密码的能力,其实判断的原理不难,分析请求某个文件的某几个参数的频率即可。用BurpSuite测一测就知道。在WAF上需要手工配置防爆破的策略,指明请求的URI、用户需要输入的参数名、访问阈值条件。

F5 ASM在判断暴力破解行为时,会判断会话有效性,造成这里有个bug,使用burpsuite爆密码时ASM根本拦不住。开了售前ticket查了半天,联系研发才闹明白是判断机制设计所致,自然也就无法修改了。

机器访问

为了防止薅羊毛,WAF必须具备能力,根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件,拦截超出正常频率的机器访问行为。

这项测试非常考验设备的自定义程度,而Imperva在自定义策略的灵活性上,遥遥领先其他友商,无愧于Gartner第一象限的位置。自定义程度越高,策略越灵活,防御效果越好,对甲方工程师的技术要求也就越高。很多传统行业的甲方工程师由于不熟悉攻防,对HTTP没研究那么深,自定义策略反而成了工作的负担。在和Imperva工程师交流时多次看到其他同行发来的邮件,询问某某场景下实现某功能,应该如何配置。我觉得如果不懂HTTP,WAF干脆就不要玩了,纯粹是给自己找负担。从白帽子的角度来说,目标网站有WAF不可怕,渗透还是要坚持的,万一对方不懂HTTP呢。

指定参数拦截

在post表单中,安全基线要求代码必须判断用户输入内容是否合理。比如,手机号一项,必须提交13/15/17/18开头的11位纯数字。如果编码时实现该需求,一行正则匹配就搞定。但是你不能保证每个程序猿都是勤奋的。所以,用WAF帮助站点实现该需求是必备功能要求。

WAF必须具备识别制定URI的指定参数,提交的数据格式。这一项也是将各厂家区分开的重要指标。

命令注入

WAF还必须具备识别命令注入攻击的能力,这一项DVWA是提供了测试功能的。之所以重点拿出来说,是因为Imperva、F5 ASM在这里都存在明显的疏漏。常见系统命令,这两家的WAF都不能在默认策略下准确识别。这一点我很奇怪,明明特征库里是有这一类特征的,可为何检出率如此低?

0X07 设备自身安全

WAF除了要保护目标网站的安全性之外,自身的安全性也不可或缺。别不信,FortiWeb的5.5.3版本就存在CSRF漏洞。国产主流的漏洞扫描产品,除了绿盟也都存在CSRF漏洞。

另外,要使用NMAP等各种工具扫描设备开放的端口,看看有没有什么服务存在已知漏洞。

第三,设备登录入口必须支持连续登录失败X次后拦截登录请求的功能,防止被爆破。

第四,设备web端会使用类似jQuery等库,而第三方库是有各种已知漏洞的,查到CVE后逐个验证下漏洞是否存在。

第四,开个WVS扫一扫页面吧,看看有没有什么明显的漏洞。

0X08 自学习

商业WAF相比自研WAF,最大的优势在于自学习功能。商业WAF拥有多项专利技术,可以根据web应用的访问行为和流量,自动学习用户正常访问行为特征,据此建立防御策略。Imperva在这方面技术领先很多,专利也最多。如果用好了自学习功能,WAF的漏过能够很大程度上的改善。

但是,凡事没有绝对。WAF的自学习功能最大的困扰是误报。Web应用的功能非常复杂,请求方式千奇百怪,机器学习算法再精妙,也不可能百分百还原所有用户正常行为。一旦误判,大量的误报拦截会让管理员叫苦不迭。

实际测试下来,个人感觉自学习功能更多时候是厂商拿来做宣传的噱头和控标的一个指标项,但是实际在生产环境中使用它,最好还是慎之又慎,就连厂商工程师都不建议使用,你敢给领导打保票背这个雷吗?

但是自学习功能并非是聋子的耳朵–摆设。自学习最大的用处其实是分析用户行为的工具。用这个功能连续监控一个月之后,哪个URL被访问次数最多,用户的请求方法与行为是什么,可以通过自动报告一览无余。有了这个报告,后续在做Web应用调优、访客行为分析、判断误报等方面还是很有用的。

0X09 第三方测试工具

除了上述各种手工测试项目,还可以使用第三方开源工具测试WAF的拦截能力。这里推荐两个工具。

第一:碳基体的测试工具:项目地址

这款工具是用perl写的,在t文件夹下已经写好了很多测试脚本,这些脚本可以把攻击payload放在http协议的各个字段提交,用于测试WAF在不同http参数的识别能力。具体用法不多说了,碳基体写的非常清楚。

这里想说两点:

  1. X-Forwared-For是很多WAF会漏过的点。
  2. 没有哪家WAF可以百分百拦截所有测试脚本。换句话说,测出来漏过的地方,需要WAF上手工配置策略,白帽子们也可以在渗透时自由发挥了。

第二:Ironbee项目:项目地址

Ironbee是一款开源waf,这个项目是测试拦截率的攻击,也是用perl写的。同样的,baseline-detection目录下的脚本,也不是默认策略可以百分百识别的。

0X10 管理与维护

WAF除了要满足低误报低漏报,还必须人性化易管理。下面的几个功能点,是从管理员角度出发测试的内容。

  • 设备操作日志:WAF的所有管理员操作必须留存日志备查。
  • 管理员权限分割:管理员必须不能删除和操作设备日志,管理与审计权限必须分立。
  • 误报后的快速例外:WAF会出现超过50%的误报,出现误报后,设备必须支持快速且简便的例外策略生成。
  • 日志包含完整http的request和response,高亮显示违规内容。
  • 日志可导出:WAF的日志必须支持以标准syslog格式导出,既可以与SIEM联动,也可以让管理员手工分析。
  • 多种形式的报表展现:包括但不限于自定义源地址、目的地址、攻击手法、规则、日期时间等条件的自由组合生成报表。
  • 流量可视化展现:统计每个站点流量、统计指定源的流量、统计点击次数,可视化展现。

0X11 写在最后

写这篇文章的初衷,绝非为某个品牌站台,或者贬损某个品牌。我在写作的过程中尽量避免带有个人感情色彩,尽量保持对品牌的中立性。任何WAF都是众多开发人员的辛苦结晶,每家都有自己独到的地方,也难免存在疏漏。希望通过甲方安全人员的和厂商研发人员的共同努力,把WAF完善的更好更易用。

受限于自己技术能力,测试方法和测试内容难免有遗漏或错误,希望读者反馈指正。

全文首发于安全客,地址请戳 很感谢360团队对我的认可。

从甲方的角度谈谈WAF测试方法--part1

网络上很多同行都发文讨论过各种绕WAF的技巧,也有很多文章分享自研WAF的思路。

作为传统行业的甲方安全工程师,我试着写一写自己在WAF选型测试时的大体思路。

一方面,是对自己完成一个项目的总结,另一方面,也算是提供一个不同的视角看看WAF,希望对乙方朋友今后设计、优化WAF产品有一点点帮助。

0X01 测试思路

环境搭建

  • 服务器:使用DVWA搭建一套包含各类漏洞的网站,并开启access日志以供分析。DVWA搭建过程不细说。
  • WAF:反向代理部署,将DVWA服务器做反向代理后映射出VS IP。测试时所有payload发送至VS
    IP,经WAF处理后交给DVWA服务器。
  • 测试方法:客户端构造payload提交给VS IP,服务器查看access日志。如被有效识别并过滤,access日志应没有相关内容。

0X02 OWASP TOP10 常规防御

SQLi

  • get型注入:http://10.44.100.18/dvwa/vulnerabilities/sqli/?id=22&Submit=Submit#
    的参数id可以注入,构造payload提交即可。
  • post型注入:DVWA登录过程用burpsuite抓包,即可构造post型注入。

XSS

  • 反射型XSS和存储型XSS在DVWA中都有,构造payload即可。

CSRF、command injection、Brute Foce、File upload等等方式,DVWA都有了,不细说。

漏掉的是SSRF、反序列化、structs、心脏滴血,这些攻击在当前版本的DVWA中是没有设计的,需要单独考虑。

0X03 绕过技术的防御

除了最常见攻击手法的防御以外,WAF还应该具备识别变形的Payload的能力。

目前国内外商业WAF可以识别99%以上的常规攻击手段,区别主要就体现在对各类编码后的变形Payload的分析能力上。

这里面又区分成了两大类思路。

思路一:

WAF抓取到HTTP包后,做多重解码,将每重解码的结果提取正则,与特征库进行匹配。各家能解码的层数会有区别。F5的ASM可以支持最多5层并且允许用户手工设定层数。其他家虽不可指定解码层数,但都具备相应能力。

思路二:

考虑到正则匹配容易误报漏报,有厂家放弃了这种分析模式,转而做语义分析。长亭科技的SqlChop就是如此,详情可阅读:SQLChop - 一个新型 SQL 注入检测引擎

在测试中,需要手工对payload做编码变形。详细说来:

SQLi变形

  • urlencode编码:别小看这种常见的绕过方法,有厂家的WAF还真检测不出来。
  • unicode编码
  • 关键字大小写替换:这个比较常规了,基本是没有检测不到的。
  • 关键字转为十六进制
  • 关键字用反引号引起来
  • 关键字用/#! #/注释引起来
  • 关键字用/##/注释截断:select转为sel/**/ect
  • 关键字用%00截断
  • 提交的HTTP包中,将x-originating-IP 改为127.0.0.1
  • 提交的HTTP包中,将X-remote-addr 改为127.0.0.1
  • SQLMAP的各类TAMPER,挨个试一试吧

XSS变形

XSS变形最多,WAF漏报也是最严重的。谁让HTML可利用的标签那么多呢。

这一块的测试,有赖于测试者平时收集各类XSS payload 的量。我仅列出一部分常见的以供参考:

<embed/src=//goo.gl/nlX0P>
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
<a onmouseover="javascript:window.onerror=alert;throw 1>
<svg><script>varmyvar="YourInput";</script></svg>
<s%00c%00r%00%00ip%00t>confirm(0);</s%00c%00r%00%00ip%00t>
<script>//@cc_on!alert(1)/*@cc_on~alert(2)@*/</script>
<marquee/onstart=confirm(2)>/
<a/onmouseover[\x0b]=location=&#039;\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3A\x61\x6C\x65\x72\x74\x28\x30\x29\x3B&#039;>XSS

文件包含绕过

data:text/plain;base64,ZGF0YTp0ZXh0L3BsYWluLDw/cGhwIHN5c3RlbSgnY2F0IC92YXIvd3d3L0ZpbGVJbmNsdWRlLnBocCcpPz4=

文件上传绕过

文件上传绕过主要考虑几个方面:

  • 123.php.123
  • 123.asp;.gif
  • as.php%00.gif
  • 文件开头添加GIF89a
  • burpsuite抓包修改Content-Type: image/jpeg

0X04 扫描器防御能力

WAF应具备根据数据包特征识别扫描器的能力,并加以阻止。常见的扫描器,如WVS、SQLMAP、Netsparker、havij、Appscan都应该拿来实际测试WAF的反应。

需要说明的一点是,WAF不仅要拦截扫描器发来的数据包,还应在日志中注明,攻击者使用何种扫描器。这对运维人员分析日志很有帮助。

例如,实际测试中,Imperva对SQLMAP和Netsparker都可以准确识别。而F5的ASM则可以准确识别WVS和SQLMAP。FortiWeb则不具备这个能力。

剩下几个章节,将讨论以下内容:

  • Webshell通信拦截测试