服務對外但需要登入，能有什麼風險嗎？
在開發產品的時候，常常需要搭配各種工具作為輔助，例如說用 GitHub 管理程式碼，或者是用自己架的 GitLab。在專案管理的部分，也有些人會選擇用自己架的 JIRA 或是 Redmine，這些都很常見。
雖然這些服務通常都會有 cloud hosting 的方案，但比較常看到的是自己把服務架起來。畢竟有些是開源的專案，自己架起來省了不少成本，而有些公司的考量則是希望資料掌握在自己這邊，而不是別人的雲上面。
在最理想的情況之下，這些服務應該是不會對外的。意思就是，只有公司內網的 IP 可以連結到這些服務，如果不在公司內，就是透過 VPN 才能存取到，確保外面的人看不見這些服務。
但實際的狀況卻是，有些公司並沒有把這些服務隔離在內網（或搞不好根本沒想到要這樣做？或可能是有什麼實作上的困難），因此在外網就可以直接看見這些服務。
這樣會有什麼問題嗎？
最糟的狀況就是權限管理沒有做好，讓這些服務甚至不需要登入就可以存取，如此一來，公司內部的資訊就直接暴露在外。如果暴露的服務是 GitLab，程式碼就會跟著曝光，或有些敏感資訊例如說帳號密碼也有可能跟著曝光。
看到這邊你可能會想說：
不可能吧，有公司會這麼不小心連權限都不鎖嗎？
HITCON ZeroDay 是一個台灣的漏洞回報平台，在上面回報的漏洞會給廠商足夠的時間修補，接著過一陣子以後就會對外公開，上面可以直接搜尋有人回報過的漏洞，這是搜尋 GitLab 的結果：
這只是其中一部分的搜尋結果，如果好奇全部的搜尋結果，可以自己去網站上面試試看，看看有哪些公司有過類似的問題。
GitLab 存取控制缺陷，就代表不需要登入也可以看到裡面的 project，無論是程式碼還是各種相關文件，全部都會被人看光光。
這些服務是怎麼被找到的？
看了上面的截圖，你會好奇的第一個問題可能就是這個。
他們是怎麼找到這些服務的？難道是這些公司的員工自己來回報嗎？不然照理來說應該不會發現這些服務才對？
不不不，答案或許比你想得更簡單。
GitLab 的登入頁面預設的標題是「Sign in · GitLab」，所以只要運用一點 Google 的搜尋技巧，就可以找到網址有 tw 的 GitLab 登入頁面：「intitle:Sign in · GitLab inurl:tw」
這只是其中一種方法而已，是最方便快速的方法，但能找到的資料有限。另外一種方法則是利用其他一些網站——專門在搜集資訊的網站。
有些網站會去掃描每一個 IP 或是新註冊的網域，去掃他們的每一個 port，然後根據 response 來決定它可能是哪個服務，這些資訊可能存在於 response header 或是 body 的任何地方。有了這些資料以後，就可以做跟剛剛類似的事情，直接去搜尋資料庫裡面有哪些 IP 有 GitLab 這個服務，有些更精準的甚至可以指定版本。
例如說 Shodan 就是這樣的一個網站：
如果需要的話，還可以指定更精準的條件，例如說「在台灣的 GitLab 服務」之類的，就會跑出一長串清單，但這類型的網站靠的是查詢來賺錢，所以想看更多資料的話就必須付錢。
想了解更多這種服務的話，可以參考我同事寫的：駭客起手式 : Shodan & Fofa。
總之呢，只要你的服務暴露在外網，就很有可能被探測到，被收錄進去某人的資料庫裡面。所以千萬不要想著「我又沒有特別宣傳這網站，怎麼會被發現」，光是有 public IP 這一點，網站就已經被發現了。
可是我的服務需要自家信箱才能登入，這樣就沒問題了吧？
前面提過最糟的狀況就是權限沒有控管好，開放訪客註冊或是根本不需要註冊，而最好的情況當然就是服務不對外，隔離在內網裡面。而在這兩者之間的狀況就是標題所提到的：「服務對外，但需要登入」。
因為需要登入，而駭客不知道帳號密碼，既然無法登入就看不到東西，也無法達成任何攻擊，造成任何損害。
真的是這樣嗎？
通常是這樣沒錯，除非你用的這個服務本身就有漏洞，而且這個漏洞不需要登入就可以觸發，這類型的漏洞通常被稱為 Pre-Auth 的漏洞，儘管沒有登入，但只要能存取到這個服務，就能利用這個漏洞。
應該有不少人都有用過 Jira 吧？Jira 在 2019 年 7 月時有過一個編號是 CVE-2019–11581 的漏洞，是 Pre-Auth RCE，Pre-Auth 指的是不需要登入，RCE 指的是 Remote Code Execution，意思就是這個漏洞能夠讓攻擊者在系統上執行任意指令，是很嚴重的漏洞。這個漏洞只要有開 contact administrator 的功能就會中招。
另外呢，Jira 背後的公司 Atlassian 推出的另外一個服務 Confluence，在今年八月也爆出了一個 Pre-Auth RCE，編號為 CVE-2021–26084，這次不需要特別開什麼設置就會中招。
換句話說，上面這兩個漏洞基本上就是只要你服務對外，就有遭受到攻擊的風險，無論你有沒有鎖登入功能都一樣。
這就是服務對外的風險，只要這個服務本身存在著 Pre-Auth 的漏洞，攻擊者就可以在未登入的狀況下進行攻擊。
接著許多人的下一個問題可能是：
我們公司又不有名，應該不會有人來打吧？
這就不一定了，因為搞不好「打你的人也不知道自己在打的是誰」，還記得我前面說過的 shodan 搜尋引擎嗎？
假設今天我是一個攻擊者，而且想讓效益最大化，我一定是先去上面搜尋符合條件的主機，然後把清單撈下來以後直接把攻擊自動化，先寫好一個腳本，利用這個漏洞讓遠端的主機跑挖礦程式什麼的，接下來只要啟動腳本，就會自動去攻擊每一台主機。
因此，我根本不會知道那些主機是誰的，因為我也不需要知道。
來簡單總結一下：
- 只要你的主機有著 public IP，就能夠被找到
- 承上，如果架的服務有 Pre-Auth 的漏洞，就很容易遭受到攻擊
最根本的解決方法就是把這台主機隔離在內網，讓外界存取不到，或者是防火牆設定好，只允許特定的 IP（通常是來自公司的 IP）存取 。除此之外，也還是要頻繁更新版本，避免使用到有漏洞的版本，讓攻擊者無機可趁。
如果真的因為一些原因要對外，至少在前面擋個 WAF（Web application firewall），有些 WAF 的反應速度很快，可以站在最前線把一些惡意的 payload 擋掉，例如說 Cloudflare：How Cloudflare helped mitigate the Atlassian Confluence OGNL vulnerability before the PoC was released
最後，若是你對這類型的資安主題有興趣，除了追蹤這個 Medium 帳號以外，也可以追蹤 Cymetrics Tech Blog，我跟幾個同事們都會在那上面寫資安相關的文章。
文章版权归原作者所有。
