Gradle Plugin Portal：結合點擊劫持和CSRF漏洞實現帳戶接管

一、點擊劫持漏洞

1.1 關於點擊劫持

點擊劫持，也稱為「用戶界面糾正攻擊（UI Redress Attack）」，是指攻擊者使用多個透明或不透明層，誘使用戶在打算點擊頂層頁面時，點擊到其他頁面上的按鈕或鏈接。因此，攻擊者「劫持」針對其頁面的點擊，並將其跳轉到另一個頁面，而該頁面很可能是由另一個應用程序或域名所持有。

使用類似的技術，也同樣可以劫持擊鍵。通過精心設計的樣式表、iframe和文本框組合，用戶以為自己是在輸入電子郵件或銀行帳戶的密碼，但實際上可能是在鍵入由攻擊者控制的隱形框架。

1.2 漏洞發現

最近，我對於軟體安全CTF挑戰比較感興趣。在觀看YouTube時，我偶然發現了Mr. Robot CTF Hacking Walkthrough（https://youtu.be/0VJyfJzbPE4），並且了解到一個名為Nikto的有趣工具。Nikto是一個簡單的實用程序，可以用於掃描Web域以查找已知的安全漏洞。我之前在Gradle Plugin Portal中發現過一個安全漏洞，因此我決定嘗試丟Gradle Plugin Portal運行這一工具。

nikto -h https://plugins.gradle.org/

- Nikto v2.1.6

---------------------------------------------------------------------------

Target IP: 104.16.174.166

Target Hostname: plugins.gradle.org

Target Port: 443

---------------------------------------------------------------------------

SSL Info: Subject: /OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=ssl473435.cloudflaressl.com

Altnames: ssl473435.cloudflaressl.com, *.gradle.org, gradle.org

Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305

Issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2

Start Time: 2018-10-20 12:13:30 (GMT-4)

---------------------------------------------------------------------------

Server: cloudflare

Retrieved via header: 1.1 vegur

The anti-clickjacking X-Frame-Options header is not present.

The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS

Uncommon header "cf-ray" found, with contents: 46ccc5bf2d9f9a1c-EWR

Uncommon header "expect-ct" found, with contents: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"

The site uses SSL and the Strict-Transport-Security HTTP header is not defined.

The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type

Cookie __cfduid created without the secure flag

Uncommon header "cf-cache-status" found, with contents: MISS

No CGI Directories found (use "-C all" to force check all possible dirs)

Entry "/m2/" in robots.txt returned a non-forbidden or redirect HTTP code (200)

"robots.txt" contains 1 entry which should be manually viewed.

Server is using a wildcard certificate: *.gradle.org

The Content-Encoding header is set to "deflate" this may mean that the server is vulnerable to the BREACH attack.

Server banner has changed from "cloudflare" to "cloudflare-nginx" which may suggest a WAF, load balancer or proxy is in place

Uncommon header "x-amz-version-id" found, with contents: 4CuDbNLw3ZyTEYAmFHvtPU.P25twrUJH

Uncommon header "x-amz-error-code" found, with contents: NoSuchKey

Uncommon header "x-amz-error-message" found, with contents: The specified key does not exist.

Uncommon header "x-amz-request-id" found, with contents: 5C1075D723B3C9D2

Uncommon header "x-amz-error-detail-key" found, with contents: 11207779/head/cart32.exe

Uncommon header "x-amz-id-2" found, with contents: fbYSEo6uojolLGL8uQZaGT6pmtW/DW5 s/aUxy2rOzep8qV f8z1tBilEpZugMVKTUfuSJMPPIc=

OSVDB-3092: : This might be interesting... possibly a system shell found.

9123 requests: 0 error(s) and 20 item(s) reported on remote host

End Time: 2018-10-20 12:32:52 (GMT-4) (1162 seconds)

---------------------------------------------------------------------------

1 host(s) tested

最後的結果是這樣的：

反點擊劫持X-Frame-Options頭部不存在。

在大學時期，我就掌握了點擊劫持漏洞的相關知識，甚至我還在上一家公司實習期間發現了他們的一個漏洞。對於不熟悉X-Frame-Options頭部的讀者來說，其具體描述如下。

X-Frame-Options HTTP響應頭部可用於指示是否應該允許瀏覽器在、

1.3 概念證明（PoC）

這非常有趣，我很快就編寫出了一個PoC，演示一個可以針對Gradle Plugin Portal實現漏洞利用的點擊劫持攻擊。

為了使這個特定的PoC起作用，插件作者必須登錄到他們的插件門戶帳戶。但是，精心設計的惡意軟體可能會額外利用點擊劫持，讓插件作者在不知情的情況下登錄到他們的帳戶（如果插件作者尚未登錄）。

下面是針對已經登錄的插件作者，模擬一個「真實」網站的樣子。

當不透明度設置為0.5時，如下所示：

當不透明度設置為0時，如下所示：

1.4 披露和修復

針對這個漏洞，我們及時向Gradle團隊進行了披露。他們使用已經棄用但仍然安全的headerX-Frame-Options，修復了這一漏洞。

在晚上，我發現了第一個漏洞，並與Gradle團隊討論這一漏洞攻擊的安全隱患。Gradle團隊向我提到，插件門戶目前並不依賴於JavaScript。此時，我實際上還沒有查看過網站上的任何代碼，但這一條情報立刻促使我開始查看網站上表單提交框的HTML代碼。

於是，我立刻發現了第二個，也是更加糟糕的安全漏洞。

二、跨站請求偽造（CSRF）漏洞

2.1 關於跨站請求偽造漏洞

跨站請求偽造（CSRF）是一種攻擊方式，能夠強制最終用戶在當前對其進行身份驗證的Web應用程序上，執行原本不需要的操作。CSRF攻擊專門針對狀態更改請求，而不會竊取數據，因為攻擊者無法查看對偽造請求的響應。藉助社會工程學的一些幫助（例如：通過電子郵件或聊天工具發送鏈接），攻擊者可以欺騙Web應用程序的用戶執行攻擊者選擇的操作。如果受害者是普通用戶，那麼一次成功的CSRF攻擊可以強制用戶執行狀態更改請求，例如轉移資金、更改其電子郵件地址等。如果受害者是管理員用戶，那麼成功的CSRF可能會危及整個Web應用程序。

CSRF是一種欺騙受害者提交惡意請求的攻擊。在成功執行後，攻擊者就繼承了受害者的身份和特權，並能夠取代受害者的身份執行特定操作。對於大多數站點來說，瀏覽器請求中就自動包括了與站點相關的所有憑據，例如用戶的會話Cookie、IP地址、Windows域憑據等。因此，如果用戶當前已經對站點進行了身份驗證，那麼該站點將無法區分受害者發送的偽造請求和受害者發送的合法請求。

2.2 漏洞發現

如果我們載入Gradle Plugin Portal用戶管理頁面，那麼就會出現一個表單，我們可以通過該表單更改用戶名、電子郵件和密碼。打開Chrome開發者工具，我們可以看到這是一個HTML的表單元素。我們注意到，此表單中不包含作為表單HTTP POST請求的一部分發送的任何類型的身份驗證令牌（Token）。這意味著，伺服器完全依賴於瀏覽器的會話Cookie，來為此請求提供身份驗證。這是一個非常好的跡象，表明此頁面容易受到CSRF的攻擊。

2.3 概念證明（PoC）

為了測試CSRF，我將整個表單元素從Gradle Plugin Portal源代碼複製到了我自己的HTML文檔中。在清理格式和樣式元素後，我留下了一個只包含表單的HTML文檔。使用瀏覽器，在我的計算機上打開此HTML文檔，我設置了不同的用戶名以及一個新的密碼，然後點擊「Update Profile（更新個人資料）」按鈕。

我的PoC可以用於在惡意網站上更改用戶的密碼錶單：

當我點擊「Update Profile（更新個人資料）」按鈕時，進入到了我的Gradle Plugin Portal測試帳戶的個人資料頁面。我退出帳戶，並嘗試使用剛剛設置的密碼重新登錄。事實證明，我能夠使用這個新密碼登錄。於是，我剛剛從一個原本沒有許可權的網站上，更改了我的插件門戶網站的帳戶密碼。

Password

Password Again

在這裡，實際發生的是，瀏覽器理解表單標籤上的action="https://plugins.gradle.org/user" method="POST"。當我們按下按鈕時，瀏覽器會將HTML表單中的Payload以POST方法發送到https://plugins.gradle.org/user。在這裡，存在一個問題，就是瀏覽器使用登錄用戶的會話Cookie發送了這一Payload。這意味著，伺服器認為這是經過了身份驗證的請求，並且還更新了帳戶。除了通過一個簡單的文檔添加訪問惡意站點之外，這種攻擊方法完全可以自動化實現，而無需用戶交互。

2.4 啟發

互聯網上的任何網站都可以在他們的站點上嵌入此表單，從而導致任何Gradle插件作者在登錄到他們的Gradle插件門戶帳戶時（即使他們早已離開插件門戶的頁面），都可能會使自己的帳戶被篡改。這是因為GRADLE_PORTAL_SESSION_ID被設置為永遠不會過期。但是，如果插件作者此時還沒有登陸，那麼惡意網站可能會利用點擊劫持，讓作者在不知不覺中點擊「登錄」按鈕。

2.5 披露和修復

在發現這一問題後，我立即向Gradle團隊報告了這一漏洞的重要性、嚴重性和潛在影響。此外，我還提供了資源鏈接，討論如何正確修復此漏洞。如果大家現在查看Gradle插件門戶的源代碼，會發現其中添加了一個新的隱藏表單元素。

現在，當此表單被發送到Gradle Plugin Portal伺服器時，還會檢查相應的令牌（Token），以確保它是有效的令牌。惡意站點無法生成這一csrfToken，因為它無法訪問從中派生出的Cookie。

三、總結

Gradle團隊很快就成功修復了這兩個漏洞。但是，這兩個漏洞的披露，表明了開發人員在平時所使用的資源也很可能存在著一定的風險。

3.1 插件門戶對攻擊者的價值

對於攻擊者來說，Gradle插件門戶是一個非常有價值的目標。如果攻擊者想要破壞全球範圍內的數百個軟體，或者想要破壞每一個新開發的Android應用程序，那麼一個不錯的起點就是攻擊Gradle Plugin Portal、Maven Central或JFrog。如果惡意攻擊者可以在受信任的插件作者的插件門戶上安裝惡意插件，那麼他們就可以輕鬆在世界各地許多開發人員的計算機和持續集成（CI）伺服器上執行他們的惡意代碼。該攻擊的簡化版本是惡意攻擊者在發布新插件的7天內攻陷Gradle插件作者的帳戶，刪除現有插件，並上傳他們自定義的插件。然而，插件作者不知道他們的插件已經被替換為惡意插件，並且不斷會有新用戶下載惡意插件。於是，攻擊者的代碼就開始在軟體開發棧的關鍵位置執行。更糟糕的是，由於此類惡意代碼在接近編譯組件的位置執行，惡意插件可能會將惡意位元組碼注入生成的組件中，從而威脅全球的Web應用程序和Android應用程序。

對CCleaner構建及發布過程的成功攻擊已經表明了上述理論的可行性。在Cisco Talos的文章中，CCleaner Hack被公開披露，Cisco團隊寫道：「外部攻擊者可能會破壞其部分開發或編譯環境，並利用這一訪問許可權，將惡意軟體插入到官方已發布版本的CCleaner中」。這類攻擊的後果可能會非常嚴重。就CCleaner而言，他們自稱「截至2016年11月，全球下載量超過20億」。據報道，他們每周會增加500萬個新用戶。

3.2 面向未來的安全建議

我強烈敦促Gradle團隊儘快聘請專業的滲透測試團隊，以尋找插件門戶和編譯搜索門戶中可能存在的其他安全漏洞。此外，我向該團隊提供如下建議：

1、當電子郵件地址、用戶名、密碼發生更改時，自動向插件作者發送電子郵件。此外，當上傳他們擁有的新插件時，也應發送確認電子郵件，從而使插件作者清楚地知道他們的身份驗證令牌（Token）是否已經被泄露。

2、在插件門戶帳戶上，添加對雙因素身份驗證的支持，並在登錄帳戶和更改帳戶的電子郵件或密碼時，驗證第二個身份驗證因素。

3、在允許設置新密碼之前，需要首先輸入插件帳戶的當前密碼，並進行驗證。

4、考慮開展漏洞賞金計劃。對於一些未被披露的安全漏洞，存在一個有利可圖的灰色市場。一些公司（例如Zerodium）和政府非常願意購買安全漏洞，以便他們可以實現自己的目的。這些漏洞通常不會向受影響的公司報告，而是會轉發給需要進行利用漏洞的個人。事實證明，漏洞賞金計劃是安全研究人員探索公司產品安全漏洞的一個有效動力。此外，它還為「負責任的安全漏洞披露方式」提供了一種途徑。

5、聘請專業的滲透測試團隊。之所以要重複提及，就是因為這一點的重要性。專業的滲透測試團隊可以發現自動化工具永遠無法發現的安全漏洞。Gradle插件門戶是Gradle團隊維護的非常重要的資產，因此需要進行全面的安全檢查。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！