一下来自小火的自述，篇幅略长：
去年夏天我开始学习信息安全和黑客。在过去的一年中，我参加过各种各样的战争游戏，夺取了旗帜和渗透测试模拟，不断提高我的黑客技巧，并学习了“如何使计算机偏离预期行为”的新事物。
长话短说，我的经验总是局限于模拟环境，而且由于我认为自己是一个白帽黑客（又名好人之一），我从来没有把我的鼻子插入其他人的业务 - 从字面上来说。
这将是一个详细的故事，关于我如何发现并入侵一个托管40个（这是一个确切的数字）网站的服务器的过程。
注意：需要 一些先决条件的cs知识来贯彻本文的技术部分。
一个朋友给我发来了他的网站上发现的一个xss漏洞，他希望我进一步看看。
这是一个重要的阶段，因为我倾向于要求他正式表达我有他的许可，对他的web应用程序和托管它的服务器进行全面测试。
答案是 肯定的。
1、行动开始
在这篇文章的其余部分，我将把我的朋友的网站称为 http://example。
第一步就是尽可能地尽可能多地提示并尽可能多地发现你的敌人。
在这个阶段，我们触发我们的计时器并开始扫描。
$ nmap --top-ports 1000 -t4 -sc http://examplenmap扫描报告example 主机启动（延迟0.077s）。的rdns记录：未显示：972个已过滤的端口港口国服务21 / tcp open ftp22 / tcp打开ssh| ssh-hostkey：| {}节录80 / tcp打开http| http的方法：| _有潜在风险的方法：trace| _http标题：受害者网站139 / tcp open netbios-ssn443 / tcp打开https| http的方法：| _有潜在风险的方法：trace| _http-title：网站没有标题（text / html; charset = utf-8）。| _ {}删节445 / tcp打开microsoft-ds5901 / tcp打开vnc-1| vnc的信息：| 协议版本：3.8| 安全类型：| _ vnc认证（2）8080 / tcp打开http-proxy| _http-title：400错误的请求8081 / tcp打开blackice-icecap
扫描在大约两分钟内完成。
这是很多开放的端口！通过观察ftp（端口21）和smb（端口139/445）端口是否打开，我们可以猜测服务器用于文件托管和文件共享，以及它是一个网络服务器（端口80/443分别代理在8081/8080 ）。
2、从战争的艺术来看，枚举是关键。
如果上面的扫描信息不够，则要考虑进行udp端口扫描和超过1000个端口的扫描。我们被允许与之交互的唯一端口（不带凭据）是端口80/443。
在不浪费任何时间的情况下，我将启动程序枚举web服务器上的任何有趣的文件，同时我将手动挖掘信息。
gobuster
$ gobuster -u http://example -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100/管理员/登录
原来，/ admin路径是一个“管理工具”，允许经过身份验证的用户修改web服务器上的东西。它需要凭据，因为我们没有用户名和密码，我们继续前进。（剧透：gobuster没有发现任何有价值的东西）
到目前为止，我们大概有三分钟的时间是什么也获取不到的。
浏览到网站，我们看到它要求我们登录。没问题，我们创建一个虚拟电子邮件帐户，点击确认电子邮件，几秒钟后登录。
该网站欢迎我们，并提示我们导航到我们的个人资料，并更新我们的个人资料图片，多么体贴。
3、无限制上传文件
看到该网站看起来是定制的，我倾向于测试一个无限制的文件上传漏洞。
所以我在终端上执行：
echo“”> exploit.php
我尝试上传“图像”，宾果！上传器允许exploit.php文件上传。当然，它没有缩略图，但这意味着我的文件上传到某个地方。
4、获取漏洞的位置
在这里，我们希望上传者对上传的文件进行某种处理，检查其文件扩展名，并替换为接受的文件扩展名，例如.jpeg，.jpg，以避免攻击者上传恶意代码的远程代码，像你的真正做到。
毕竟人们关心安全。
对？对？…对？
`复制图像地址`导致下面的url被复制到我们的剪贴板：http://example/admin/ftp/objects/xxxxxxxxxxxx.php
所以看来我们的webshell已经准备就绪，并且正在运行：
5、获取shell权限
看到网络服务器运行 perl 脚本（真的，perl？），我们从我们最喜欢的cheatsheet获取一个perl反向shell ，设置ip /端口，我们得到一个低特权的shell - 抱歉，没有截图。
在评估中约五分钟，我们已经有了一个低特权的shell。
令我惊讶的是，服务器并没有托管一个网站，而是有 40个不同的网站。可悲的是，我没有保存每一个细节的截图，但输出结果如下：
$ ls / var / www
access.log site1 / site2 / site3 / {...名单继续}
你明白了。令人惊讶的是，阅读 所有 托管的网站是可允许的的，这意味着我可以阅读所有网站的后端代码。我限制自己的example的代码。
值得注意的是，在目录中，所有的perl脚本都以root身份连接到mysql数据库。数据库的凭证以明文形式存在。让这些根源：pwned42
cgi-admin/pages
6、入侵数据库
果然，服务器运行mariadb，我不得不诉诸这个问题 才能够访问数据库。之后，执行：
mysql -u root -p -h localhost victimdbname密码：pwned42
我们在数据库中拥有root权限。
“使用数据库名称”允许我们访问35个数据库中的任何一个，并查看和修改其内容
仅仅七分钟后，我们就可以对 35（！）数据库的内容进行完整的读/写访问。
在这里，我在道义上有义务停止和透露我的调查结果。潜在的危害已经很大。
7、攻击者可以做什么
转储所有数据库中的内容，如所描述这里，从而在公共领域被泄露所有35家公司的数据。
删除所有的数据库，有效地删除了35个机器的数据
留下后门持久访问作为apache与cronjob，如这里所述，以防他们想要回程。
我应该在这里注意到，mysql进程是以root身份运行的，所以我想我会尝试执行，希望获得root权限。不幸的是，我仍然是apache。
\! whoami
时间休息一下。停止计时器。
8、有什么可以进一步出错？
在透露我的研究结果后，我进一步获得更深入的了解。
在寻找将我的权限升级到root并能够造成巨大潜在损失的方法之前，我正在研究可以使用有限用户阅读的其他有趣文件。
那时候，我想起了开放的smb端口。这意味着应该在系统中的用户之间共享某个文件夹。
经过一番列举，下面出现在目录中（请原谅我的质量审查）：
/home/samba/secured
在所有这些目录中， 托管公司的每个用户都有文件。 这包括各种敏感数据，其中包括：
.psd / .ai文件（设计师知道保持私密性是多么重要，毕竟是他们的工作和技术）
cookie的sqlite文件
发票
盗版电子书（当我看到这一点时感到轻笑）
证件到他们的wifi ssids
攻击者可以做什么
在公司办公室外面营地，登录到他们的内部网络，执行各种在本地网络上可以做的有趣的攻击
将上面列出的所有敏感数据转储到公共领域
花了一些时间去浏览文件夹，并认识到这个问题有多严重。
再来一次休息。
9、最后一击
经过四处寻找apache后，得到root权限。我指的是一个流行的cheatsheet，并开始枚举有趣的文件系统。
由于我挖掘到目前为止，我已经经历了大部分这些技术，似乎没有能够找到可以增加我的立足点的东西。
那是什么时候打到我的 在我习惯的“捕捉旗帜”挑战中，操作系统通常会打补丁，这是一些故意错误配置的服务，最终会为您提供所需的root权限。然而在现实世界中， 人们并不打补丁。
我的意思是，看看equifax （无法抗拒）。
服务器运行什么样的linux？
$ cat / etc / issuecentos linux版本7.2.1511（核心）
内核是什么版本？
这看起来像一个旧的内核版本。
这是否提醒你什么？如果没有，请在这里阅读 （提示：这是非常严重的）
我发现这个博文指出我测试内核是否容易受到在这里找到的脚本。
时间戳和firefox恢复了编辑的网站
其次是：
游戏结束
我立刻写了一封电子邮件，充分披露了上述每一步的细节和潜在影响。
攻击者可以做什么
读取/修改服务器上的所有文件
留下一个持久的后门（就像apache一样）
安装并可能将恶意软件传播到服务器的内部网
安装勒索软件（以35家公司的数据库为例，所有托管公司的数据都是人为的）
使用服务器作为加密货币矿工
使用服务器作为代理
使用服务器作为c2c服务器
将服务器用作僵尸网络的一部分
… （动用你的想象力）
rm -rf / （甚至不是开玩笑）
第二天，我的朋友（与操作服务器的公司联系）接到通知，并通知了文件上传器中的错误是固定的。
tl;博士
10、总结一下，我们发现：
具有无限制文件上传漏洞的web应用程序，导致低权限shell。
mysql数据库的凭据，导致读/写访问35个数据库
许多可读的敏感文件
最后，我们滥用未打补丁的内核来获取root访问权限。
建议
让我们从给我们最初立足点的上传者开始吧。由于整个web应用程序的后端是用perl编写的，而且我也不会说perl，所以我不能真正提出修复的建议。
我建议的一个修复将不会在2017年使用perl，但这只是我的意见，随意来证明我错了。
关于文件系统，我建议根据最小权限原则，为用户分配适当的文件权限。这样，即使像apache这样的低权限用户可以访问，他们也无法读取任何敏感文件。
在同一台服务器上运行所有网站是一个坏主意，我不确定是否采用码头化方法可以解决问题。
对所有数据库拥有相同的证书肯定是一个坏主意。
单点故障通常是不好的。
最后，补丁一切。这实际上是一个命令:( 特定于centos）
su -c 'yum update'