Lvbug團隊接單滲透網站後台入侵等駭客服務，如果您正在尋求專業的駭客為您工作，您可以聯絡我們！

我如何在 7 分鐘內駭掉 40 個網站

去年夏天我開始學習資訊安全和駭客技術。在過去的一年裡，我玩了各種戰爭遊戲、奪旗和滲透測試模擬，不斷提高我的駭客技能並學習有關「如何使電腦偏離其預期行為」的新知識。

長話短說，我的經驗始終僅限於模擬環境，而且由於我認為自己是白帽黑客（又名好人之一），所以我從不插手別人的業務——毫不誇張地說。

到目前為止。這將詳細講述我如何侵入託管 40 個（這是一個確切數字）網站的伺服器以及我的發現。

註：需要具備一些必備的 CS 知識才能理解本文的技術部分。

一位朋友給我發訊息，說在他的網站中發現了XSS漏洞，並希望我進一步查看。這是一個重要的階段，因為我傾向於要求他正式表示我已獲得他的許可，可以在他的 Web 應用程式和託管該應用程式的伺服器上執行完整的測試。答案是肯定的。

在本文的其餘部分中，我將把我朋友的網站稱為 http://example.com

第一步始終是枚舉並找到盡可能多的有關敵人的信息，同時盡量少地驚動他們。

在此階段，我們觸發計時器並開始掃描。$ nmap –top-ports 1000 -T4 -sC http://example.com
example.com 的 Nmap 掃描報告 { redacted}
主機已啟動（0.077 秒延遲）。
{redacted} 的rDNS 記錄：{redacted}
未顯示: 972 個過濾埠
港口國服務
21/tcp open ftp
22/tcp open ssh< a i =9>| ssh-主機金鑰：| {已編輯}80/tcp 開啟 http| http-methods：|_ 潛在風險方法：TRACE|_http-title：受害者網站139/tcp open netbios -ssn443/tcp 開啟 https| http-methods：|_ 潛在風險方法：TRACE|_http-title：網站沒有標題 (text/html; charset= UTF-8)。< /span>5901/tcp 開啟vnc- 1445/tcp 開啟microsoft-ds|_{redacted}|協定版本：3.8|安全類型：|_ VNC 驗證(2)8080/tcp 開啟http-proxy|_http-title: 400錯誤請求8081/tcp open blackice-icecap

掃描大約在 2 分鐘內完成。

有很多開放連接埠！透過觀察 FTP（連接埠 21）和 SMB（連接埠 139/445）連接埠是否打開，我們可以猜測伺服器用於檔案託管，並且用於檔案共享，同時它也是一個網頁伺服器（連接埠80/443 和代理8080/8081）。

如果上述掃描的資訊不夠，則可以考慮進行 UDP 連接埠掃描並掃描前 1000 個以上的連接埠。允許我們互動的唯一連接埠（無需憑證）是連接埠 80/443。

我不會浪費任何時間，啟動 gobuster 來枚舉網絡伺服器上任何有趣的文件，同時我將手動挖掘資訊。$ gobuster -u http://example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 100/admin
/login

事實證明 /admin 路徑是一個“管理工具”，允許經過身份驗證的使用者修改網頁伺服器上的內容。它需要憑證，因為我們既沒有用戶名也沒有密碼，所以我們繼續。 （劇透：gobuster沒有發現任何有價值的東西）

到目前為止，我們已經進行了大約 3 分鐘。還沒有什麼有用的東西。

瀏覽網站，我們看到它要求我們登入。沒問題，我們使用虛擬電子郵件建立帳戶，點擊確認電子郵件並在幾秒鐘後登入。

網站歡迎我們並提示我們導航到我們的個人資料並更新我們的個人資料圖片。多麼體貼。

看到網站看起來是客製化的，我傾向於測試無限檔案上傳漏洞。在我的終端機上我執行：echo “

我嘗試上傳“圖像”，賓果遊戲！上傳者允許上傳exploit.php 檔案。當然它沒有縮圖，但這意味著我的文件已上傳到某個地方。

在這裡，我們期望上傳者對上傳的檔案進行某種處理，檢查其檔案副檔名並替換為可接受的檔案副檔名（如.jpeg、.jpg），以避免攻擊者上傳惡意程式碼（如您的程式碼）遠端執行程式碼真的。

畢竟人們關心安全。

正確的？正確的？ …正確的？「複製影像位址」會將以下網址複製到我們的剪貼簿：
http://www.example.com/admin/ftp/objects/XXXXXXXXXXXX.php< /span>

看來我們的 webshel​​l 已經準備好並且可以運行了：

看到網頁伺服器運行 perl 腳本（真的是perl嗎？），我們從我們最喜歡的<中取得一個perl反向shell a i=3>cheatsheet，設定 IP/端口，我們將獲得一個低權限的 shell – 抱歉，沒有螢幕截圖。

評估大約 5 分鐘，我們已經有了一個低權限的 shell。

令我驚訝的是，該伺服器不僅託管 1 個網站，而是40 個不同的網站。遺憾的是，我沒有保留每個細節的螢幕截圖，但輸出如下：$ ls /var/wwwaccess.log site1/ site2/ site3/ {…這樣的例子不勝枚舉}

你明白了。令人驚訝的是，對所有託管網站的讀取權限都可用，這意味著我可以讀取所有網站的後端程式碼。我將自己限制在 example.com 的程式碼中。

值得注意的是，在cgi-admin/pages 目錄內，所有perl 腳本都以root 身分連接到mysql 資料庫 。資料庫的憑證以明文形式存在。讓它們成為root:pwned42

果然，伺服器正在執行 MariaDB，我必須求助於這個問題才能存取資料庫。之後我們執行：mysql -u root -p -h localhostvictimdbname
密碼：pwned42

我們在資料庫中具有 root 權限。

僅僅 7 分鐘後，我們就擁有了對內容的完全讀取/寫入存取權限35(!) 個資料庫

在這裡，我在道德上有義務停下來，並揭露我迄今為止的發現。潛在的損害已經是巨大的。

攻擊者可以做什麼：

1. 轉儲所有資料庫的內容，如此處所述，導致所有 35 家公司的資料在公共領域洩露.
2. 刪除所有資料庫，有效刪除35家公司的數據
3. 為apache 和cronjob 的持久訪問留下一個後門，如此處所述，以防他們想要回程。此處所述，以防他們想要回程。

我應該在這裡注意到 mysql 進程是以 root 身份運行的，所以我想我應該嘗試執行 \! whoami 希望獲得 root 權限。不幸的是我仍然是阿帕奇。

是時候休息一下了。停止計時器。

還會出現什麼問題？

在披露我的發現後，我獲得了進一步深入研究的許可。

在尋找將我的權限升級到 root 並能夠造成巨大潛在損害的方法之前，我正在研究我可以使用有限用戶讀取哪些其他有趣的檔案。

此時，我想起了開放的 SMB 連接埠。這意味著系統中應該有某個資料夾在使用者之間共用。經過一番枚舉，目錄中出現以下內容/home/samba/secured （請原諒大規模審查）：

在所有這些目錄中，都有託管公司的每個使用者的檔案。 其中包括各種敏感數據，其中包括：

• .psd/.ai 文件（設計師知道保持這些隱私有多重要，畢竟這是他們的工作和技術）
• Cookie sqlite 文件
• 發票
• 盜版電子書（看到這篇我笑了）
• WiFi SSIDS 的憑證

攻擊者可以做什麼：

1. 在公司辦公室外紮營，登入他們的內部網路並執行您可以在本地網路上執行的各種有趣的攻擊
2. 將上面列出的所有敏感資料轉儲到公共領域

我們花了一些時間檢查資料夾並意識到這個問題的嚴重性。再休息一下。

最後一擊

在以 apache 身份觀察了一會兒apache 後，我決定是時候去釣大魚了，可惜獲得了 root 訪問權限。我參考了一個流行的cheatsheet並開始枚舉系統中有趣的文件。

由於到目前為止我的挖掘，我已經完成了大部分技術，似乎無法找到可以增加我立足點的東西。

就在那時，我突然想到了。在我習慣玩的奪旗挑戰中，作業系統通常會打補丁，並且是一些故意錯誤配置的服務最終為您提供了廣受歡迎的 root 權限。然而，在現實世界中，人們不會修補。

我的意思是，看看 Equifax（無法抗拒）。

伺服器運行什麼類型的Linux？$ cat /etc/issue
CentOS Linux 版本 7.2.1511（核心）

核心是什麼版本？

這看起來像是舊的核心版本。

我發現了這篇博文，它指出我可以使用此處找到的腳本來測試內核是否容易受到攻擊。

其次是：

遊戲結束。

我立即寫了一封電子郵件，充分披露了上述每一步的細節和潛在影響，並結束了這個夜晚。呼。

攻擊者可以做什麼：

1. 讀取/修改伺服器上的所有文件
2. 留下持久的後門（就像 apache 所做的那樣）
3. 安裝並可能將惡意軟體傳播到伺服器的內部網路中
4. 安裝勒索軟體（劫持 35 家公司的資料庫和所有託管公司的資料可不是小事）
5. 使用伺服器作為加密貨幣礦工
6. 使用伺服器作為代理
7. 使用伺服器作為C2C伺服器
8. 使用伺服器作為殭屍網路的一部分
9. … （動用你的想像力）
10. rm -rf /（連開玩笑都沒有）

第二天，我的朋友（他與營運伺服器的公司取得了聯繫）聯繫了我，並告知我文件上傳器中的錯誤已修復。

太長了；博士

總結一下，我們發現：

1. 具有無限檔案上傳漏洞的 Web 應用程序，該漏洞會導致低權限 shell。
2. mysql 資料庫的憑證，導致對 35 個資料庫的讀取/寫入訪問
3. 許多可讀的敏感文件

最後，我們濫用了未打補丁的核心來取得 root 存取權限。

緩解措施－建議

讓我們從為我們提供最初立足點的上傳者開始。由於整個 Web 應用程式的後端是用 Perl 編寫的 – 而且我不會說 Perl – 我無法真正建議對此進行修復。

我建議的一個解決方案是在 2017 年不要使用 perl，但這只是我的觀點，請隨意證明我錯了。

關於檔案系統，我建議根據最小權限原則謹慎為使用者指派適當的檔案權限。這樣，即使像 apache 這樣的低權限使用者獲得存取權限，他們也無法讀取任何敏感檔案。

在同一台伺服器上運行所有網站是一個壞主意，我不確定 Docker 化的方法是否可以解決該問題。

對所有資料庫使用相同的憑證肯定是一個壞主意。

單點故障通常是不好的。

最後，修補所有內容。它實際上是 1 個命令：su -c 'yum update' （特定於 CentOS）

感謝您的閱讀對Lvbug的支持並堅持到這裡，對於這麼長的帖子表示歉意。我想徹底了解，這是一個嚴重的情況😄