去年夏天我开始学习信息安全与黑客技术。在过去的一年中,我通过参加各种战争游戏、夺旗以及渗透测试模拟,不断提高我的黑客技术,还学习了很多关于“如何让计算机偏离其预期行为”的新技术。 长话短说,我的经验总是局限于模拟环境,而且我认为自己是个有道德的白帽黑客,所以我从未入侵过别人的业务,一次都没有。 直到现在。本文讲述了我入侵一台托管了40个网站(确切的数字)的服务器的故事,以及在此过程中我的发现。
一位朋友告诉我,他的网站中发现了一个XSS漏洞,他希望我能进一步了解一下。这是个很重要的阶段,因为我会要求他授权我对他的web应用程序进行全面的测试,并赋予我访问托管服务器的全部权限。结果他答应了。
第一步是收集尽可能多的敌方信息,并注意不要打草惊蛇。 在这个阶段,我启动计时器并开始扫描。 $ nmap --top-ports 1000 -T4 -sC http://Nmap scan report for {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
这台服务器上有很多开放的端口!通过观察,我发现FTP(端口21)和SMB(端口139/445)端口是开放的,我猜服务器用这些端口托管文件和共享文件,还发现这是一个web服务器(端口80/443,代理在端口8080/8081)。 如果上述扫描信息不够,我还会考虑做一次UDP端口扫描,扫描最常用的1000多个端口。现在我可以在无需认证的情况下访问的唯一端口是80/443。 抓紧时间,我启动了gobuster,罗列出了Web服务器上所有有趣的文件,同时我将手动挖掘信息。 $ gobuster -u http:// -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100/admin/login 原来/admin路径是一个“管理工具”目录,通过身份验证的用户可以利用这些工具修改web服务器上的内容。它需要身份验证,但是我既没有用户名,也没有密码,所以只能找别的方法。(剧透:gobuster没有发现任何有价值的东西。)
在浏览网站的时候,它要求我登录。这没关系,我用虚拟电子邮件创建了一个账户,然后在几秒钟后点击确认电子邮件并成功登录。 网站显示了欢迎信息,并弹出对话框带我进入个人资料页面,要求更新我的个人资料图片。做的很贴心啊。 看来该网站是定制的,所以我决定测试一下无限制上传文件的漏洞。我在终端上运行了如下命令: echo '' > exploit.php 我试着上传该“图片”,哈哈!该网站接受了上传exploit.php。当然这个文件没有缩略图,但是这意味着我的文件肯定上传到服务器的某个地方了。 获取exploit的位置 这里,我原本以为网站会对上传文件做一些处理,检查扩展名,并替换为可接受的文件扩展名,比如.jpeg,.jpg,以避免攻击者上传恶意的远程操控代码,希望各位看官的网站都做到了。 毕竟大家都很关心安全问题。 是吧?是吧?……没错吧? 接下来“复制图片的路径”,其实就是复制如下路径:
看来我的网页木马程序已经做好准备且开始工作了: 我发现web服务器运行的是perl脚本(真的,perl?),于是我从常用的cheatsheet(http:///cheat-sheet/shells/reverse-shell-cheat-sheet)中拿了一个perl语言的反向shell,设置好IP /端口,然后我得到一个低特权shell(对不起,没有截图)。
令我惊讶的是,该服务托管的不止1个网站,总共有40个不同的网站。很遗憾我没有保存每个细节的截图,只有如下的输出结果: $ ls /var/wwwaccess.log site1/ site2/ site3/ {... 等等} 我想你也看出来了。让人惊愕的是,我可以读取所有托管网站,这意味着我可以访问所有网站的后台代码。我原以为我只能访问的代码。 值得注意的是,在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(!)个数据库的全部权限。 到了这里,从道德上讲我必须停止此次黑客行动,并揭露迄今为止的发现。这些潜在的危害已经十分惊人了。 攻击者将如何处置这些数据:
我应该注意到,在这里mysql进程是以root身份运行的,所以如果我尝试运行\! whoami,也许可以获得root的身份。不幸的是我仍然是apache。
还有什么更大的问题? 在揭露了我的发现后,我获得了更多权限,可以进行更进一步的挖掘。 在寻找方法可以将我的权限升级到root以制造巨大危害的可能性之前,我一直在研究我受限的用户还可以查阅些哪些其他有趣的文件。 就在那时,我想起了开放的SMB端口。这意味着某个地方的某个文件夹应该是对系统用户共享的。经过一番筛查后,下面的目录出现在了/ home / samba / secured目录中(请原谅我的批量审查): 这些目录保存了托管公司每个用户的文件。其中包括一些敏感数据,比如:
攻击者将如何处置这些数据:
最后一击 通过apache四处寻找了一会儿后,我决定去钓大鱼——拿到root用户。我喜欢利用cheatsheet(https://blog./2011/08/basic-linux-privilege-escalation/),搜寻有趣的文件系统。 到目前为止我的搜寻已经用完了大部分的技术,但是却似乎无法找到突破点。 就在此时,我突然想到,在以前玩“夺旗”的挑战中,操作系统通常会做一些改动,故意制造一些错误的配置服务,最终为你提供所需的root权限。然而在现实世界中,人们可不会这么做。
服务器运行的是哪个Linux? $ cat /etc/issueCentOS Linux release 7.2.1511 (Core) Kernel是什么版本? 这个看似是个旧版的Kernel。 看到此图你能想起什么?(提示:这个问题非常非常严重) 如果没有,请点击这里: https://www./technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years 我在这篇博文中找到了我所需要的测试Kernel是否脆弱的脚本: http:///easily-test-dirty-cow-cve-2016-5195-vulnerability/ 然后运行: 游戏结束! 我马上写了一封邮件,充分披露了上述每一步的细节以及潜在影响,一晚上的工作结束了,可以松口气了。 攻击者可以做什么:
第二天,我的朋友(他与运营服务器的公司取得了联系)告诉我,文件上传中的bug已得到修复。 总结一下我们的发现:
最后,攻击者可以滥用未打补丁的内核来获取root访问权限。 改良措施 首先文件上传的bug给了我们下手的机会。由于整个Web应用程序的后端都是用perl编写的(而我不会perl),所以我无法真正提出修复方案。 但是我可以建议一点:不要是使用2017版的perl,但这只是我的看法,大家可以随时证明我错了。 关于文件系统,我建议参考最小权限原则,谨慎地为用户分配恰当的文件权限。这样一来,即使像apache这样低特权用户可以访问,他们也无法读取任何敏感文件。 在同一台服务器上运行所有网站不是明智之举,我不确定docker化的方案是否可以解决这个问题。 所有数据库拥有相同的身份认证肯定是个很糟的主意。 单点故障通常不好。 最后,打补丁!实际上只需运行一个命令:su -c'yum update'(特定于CentOS)。
|
|
来自: 昵称11935121 > 《未命名》