這是用戶在 2024-11-27 13:50 為 https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/ 保存的雙語快照頁面，由 沉浸式翻譯 提供雙語支持。了解如何保存？
By — Benjamin Harris — Aliz Hammond   —  
由 — BENJAMIN HARRIS — ALIZ HAMMOND — 2024 年 9 月 11 日

We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI
我們花費 20 美元實現了 RCE，意外成為了.mobi 的網站管理員

We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI

Welcome back to another watchTowr Labs blog. Brace yourselves, this is one of our most astounding discoveries.
歡迎回來參觀另一篇 watchTowr Labs 博客。請大家準備好，這是我們最驚人的發現之一。

Summary 摘要

What started out as a bit of fun between colleagues while avoiding the Vegas heat and $20 bottles of water in our Black Hat hotel rooms - has now seemingly become a major incident.
所謂的開始於同事間避開維加斯炎熱和黑帽酒店房間裡的 20 美元一瓶水的一點樂趣，現在看來已經變成了一樁重大事件。

We recently performed research that started off "well-intentioned" (or as well-intentioned as we ever are) - to make vulnerabilities in WHOIS clients and how they parse responses from WHOIS servers exploitable in the real world (i.e. without needing to MITM etc).
我們最近進行了研究，起點是「善意的」（或者是我們所能做到的最善意）——讓 WHOIS 客戶端中的漏洞以及它們如何解析 WHOIS 伺服器的回應在現實世界中可被利用（即不需要進行 MITM 等）。

As part of our research, we discovered that a few years ago the WHOIS server for the .MOBI TLD migrated from whois.dotmobiregistry.net to whois.nic.mobi – and the dotmobiregistry.net domain had been left to expire seemingly in December 2023.
作為我們的研究的一部分，我們發現幾年前，.MOBI TLD 的 WHOIS 伺服器從 whois.dotmobiregistry.net 迁移到 whois.nic.mobi – 而 dotmobiregistry.net 域名似乎已在 2023 年 12 月到期。

Putting thoughts aside, and actions first, we punched credit card details as quickly as possible into our domain registrar to acquire dotmobiregistry.net - representing much better value than the similarly priced bottle of water that sat next to us.
放棄思緒，以行動為先，我們盡快將信用卡詳細資訊輸入我們的域名註冊商以取得 dotmobiregistry.net - 這比我們旁邊那瓶價格相似的水有著更好的價值。

Our view was that as a legacy WHOIS server domain, it was likely only used by old WHOIS tools (such as phpWHOIS, which conveniently has an Remote Code Execution (RCE) CVE from 2015 for the parsing of WHOIS server responses – thus fitting our aim quite nicely).
我們的觀點是，作為傳統的 WHOIS 伺服器域名，它很可能是僅被舊的 WHOIS 工具（如方便的 phpWHOIS，該工具於 2015 年有一個遠端代碼執行（RCE）CVE，用於解析 WHOIS 伺服器回應——因此非常符合我們的目標）。

Throwing caution into the wind and following what we internally affectionately refer to as our 'ill-advised sense of adventure' - on Friday 30th August 2024 we deployed a WHOIS server behind the whois.dotmobiregistry.net hostname, just to see if anything would actually speak to it actively.
拋開謹慎，追隨我們內部親切地稱之為「不明智的冒險感」的事，我們於 2024 年 8 月 30 日星期五在 whois.dotmobiregistry.net 主機名後部署了一個 WHOIS 伺服器，只是想看看是否真的有什麼會主動與之對話。

The results have been fairly stunning since - we have identified 135000+ unique systems speaking to us, and as of 4th September 2024 we had 2.5 million queries. A brief analysis of the results showed queries from (but certainly not limited to):
自那以來，結果相當驚人 - 我們已經識別了超過 135000 個獨特的系統與我們溝通，截至 2024 年 9 月 4 日，我們已經有 250 萬個查詢。對結果的簡要分析顯示，查詢來自（但絕不限於）：

  • Various mail servers for .GOV and .MIL entities using this WHOIS server to presumably query for domains they are receiving email from,
    各種.gov 和.mil 實體使用的這個 WHOIS 伺服器，可能用於查詢他們接收電子郵件的域名，
  • Various cyber security tools and companies still using this WHOIS server as authoritative (VirusTotal, URLSCAN, Group-IB as examples)
    各種網絡安全工具和公司仍使用此 WHOIS 伺服器作為權威（以 VirusTotal、URLSCAN、Group-IB 為例）

However, significant concern appeared on 1st September 2024 when we realised that numerous Certificate Authorities responsible for issuing TLS/SSL certificates for domains like 'google.mobi' and 'microsoft.mobi', via the 'Domain Email Validation' mechanism for verifying ownership of a domain, were using our WHOIS server to determine the owners of a domain and where verification details should be sent.
然而，在 2024 年 9 月 1 日，我們意識到許多負責為像'google.mobi'和'microsoft.mobi'這樣的域名發行 TLS/SSL 證書的證書機構，通過用於驗證域名所有權的'域名電子郵件驗證'機制，正在使用我們的 WHOIS 伺服器來確定域名的所有者以及應將驗證詳情發送至何處時，出現了重大的關注。

We PoC'd this with GlobalSign and were able to demonstrate that for 'microsoft.mobi', GlobalSign would parse responses provided by our WHOIS server and present 'whois@watchtowr.com' as an authoritative email address.
我們與 GlobalSign 進行了 PoC 測試，並能證明對於'microsoft.mobi'，GlobalSign 會解析我們 WHOIS 伺服器提供的回應，並將'whois@watchtowr.com'呈現為一個權威的電子郵件地址。

Effectively, we had inadvertently undermined the CA process for the entire .mobi TLD.
實際上，我們不經意中破壞了整個 .mobi TLD 的 CA 流程。

As is common knowledge, this is an incredibly important process that underscores the security and integrity of communications that a significant amount of the Internet relies upon. This process has been targeted numerous times before by well-resourced nation-states:
如人皆知，這是一個非常重要的過程，強調了許多互聯網依賴的通訊的保安性和完整性。這個過程在過去多次被資源豐富的國家所針對：

While this has been interesting to document and research, we are a little exasperated. Something-something-hopefully-an-LLM-will-solve-all-of-these-problems-something-something.
當這些內容被紀錄和研究的時候，我們感到有些煩躁。某個某個希望某個LLM能解決所有這些問題某個某個。

As always, we remind everyone - if we could do this, anyone can.
如常，我們提醒所有人——如果我能夠做到這一點，任何人都可以。

Onto the full story...
進入完整故事...

Setting The Scene 設定場景

We're sure you’re familiar with the old adage, ‘it never rains but it pours’. That was definitely the case here, where we set out with the intention of just getting some RCE’s to fling around, and ended up watching the foundation of secure Internet communication crumble before our eyes.
我們確信您對那句古老的格言「不雨則已，雨則倾盆」一定不陌生。這裡的情況確實如此，我們原本只是打算找一些 RCE 來玩玩，結果卻眼睜睜看著安全互聯網通訊的基礎在我們面前崩潰。

Before we get ahead of ourselves, though, let’s start at the beginning, in which we decided to take a quick look at a WHOIS client. The protocol being some 50+ years old, we expected WHOIS clients to be constructed with the same brand of string as an enterprise-grade SSL VPN appliance, and so we took a naive shot and served up some A’s.
在我們不先自滿之前，讓我們從頭開始，我們決定快速檢查一個 WHOIS 客戶端。該協議已有 50 年以上歷史，我們預期 WHOIS 客戶端將使用與企業級 SSL VPN 設備相同的品牌字串構建，因此我們冒了一個天真的嘗試，並提供了一些 A 的服務。

# python3 -c "printf( 'Domain Name: ' + 'A' * 3000)" | nc -w1 -l whois

Haha, we were right. Funny.
哈哈，我們對了。好笑。

This, at first glance, looks like an easily-exploitable crash. We were keen to find more bugs, and keenly started examining some other client implementations - but we were soon interrupted by some vocal killjoys naysayers.
這，乍看之下，像是一個容易利用的當機。我們渴望找到更多錯誤，並熱切地開始檢查其他客戶端實現 - 但我們很快就被一些愛唱反調的否定者打斷了。

They were quick to remind us that, to get to this state in our lab environment, we’d impersonated a WHOIS server, redirecting traffic from the usual server to our test server via iptables.
他們迅速提醒我們，要在我們的實驗室環境中達到這個狀態，我們偽裝了一個 WHOIS 伺服器，將流量從通常的伺服器經由 iptables 轉向我們的測試伺服器。

How realistic was this attack scenario, the naysayers asked?
這個攻擊情況有多現實主義，反對者詢問？

We tried to silence the killjoy's naysayers and convince them our attack was plausible - we could find a registrar that allows us to set a Referral WHOIS value, or buy an IP range and control the range ourselves - but they suggested we spend more time doing, and less time playing academia.
我們試圖平息那些反對者的否定聲音，並說服他們我們的攻擊是可行的——我們可以找到一個註冊商，允許我們設定參考 WHOIS 值，或者購買一個 IP 範圍並自行控制範圍——但他們建議我們花更多時間做事，而不是玩學術遊戲。

The reality was that in order for an attacker to carry out an attack against a WHOIS client, they’d need one of the following:
現實是，為了對 WHOIS 客戶端進行攻擊，攻擊者需要以下其中之一：

  • A Man-In-The-Middle (MiTM) attack, which requires the ability to hijack WHOIS traffic at the network layer - out of reach for all but the most advanced of APTs,
    一個中間人攻擊（MiTM），需要能夠在網路層級搶奪 WHOIS 流量——只有最先進的 APT 才能達到，對於其他人來說都無法觸及，
  • Access to the WHOIS servers themselves, which is plausible but unlikely, or
    存取 WHOIS 伺服器本身，這是可能的但不太可能，或
  • A WHOIS referral to a server they control.
    一個 WHOIS 參考至他們控制的伺服器。

These are effectively the preconditions of a nation-state or someone who is very comfortable compromising global TLD WHOIS servers in pursuit of exploiting clients.
這些實際上是國家或那些在追求利用客戶時，非常舒適於妥協全球 TLD WHOIS 伺服器的人的先決條件。

You would, at this point, be forgiven for thinking that this class of attack - controlling WHOIS server responses to exploit parsing implementations within WHOIS clients - isn’t a tangible threat in the real world.
您在此階段會原諒自己認為這類攻擊——控制 WHOIS 伺服器回應以利用 WHOIS 客戶端內部的解析實現——在現實世界中並不是一個具體的威脅。

We were left unsatisfied. We had located some shoddy code, but declaring it out of reach sounded like something you might bill a day rate for.
我們感到不滿足。我們找到了一些粗製濫造的代碼，但宣稱它無法達成聽起來像是你可能會按日計價的事情。

Perhaps there was another avenue for attack?
或許還有另一個攻擊途徑？

Collateral Damage In Pursuit Of RCE
損害賠償追求 RCE

The key to turning this theoretical RCE into a tangible reality is rooted in the tangled mess of the WHOIS system.
關於將這個理論上的遠端程式執行（RCE）轉變為具體現實的關鍵，其根源在於 WHOIS 系統的複雜混亂之中。

One of the biggest ‘kludges’ in the WHOIS system is the means of locating the authoritative WHOIS server for a given TLD in the first place.
其中 WHOIS 系統最大的「修補」之一，就是首先找到特定 TLD 的授權 WHOIS 伺服器的辦法。

Each TLD (the bit at the end of the domain), you see, has a separate WHOIS server, and there’s no real standard to locating them - the only ‘real’ method being examining a textual list published by IANA. This list denotes the hostname of a server for each TLD, which is where WHOIS queries should be directed.
每個 TLD（位於域名末尾的部分），您可以看到，都有獨立的 WHOIS 伺服器，並沒有實際的標準來定位它們——唯一「真實」的方法是檢查由 IANA 發布的文本列表。此列表表示每個 TLD 伺服器的主機名稱，這是 WHOIS 查詢應該指向的位置。

As you can imagine, maintainers of WHOIS tooling are reluctant to scrape such a textual list at runtime, and so it has become the norm to simply hardcode server addresses, populating them at development time by referring to IANA’s list manually. Since the WHOIS server addresses change so infrequently, this is usually an acceptable solution.
想像之下，WHOIS 工具的維護者不願在運行時抓取這樣的文本列表，因此將伺服器地址硬編碼成為常規，在開發時通過參考 IANA 的清單手工填充。由於 WHOIS 伺服器地址變化非常少，這通常是一個可接受的解決方案。

However, it falls down in an ungraceful manner when server addresses change. With a little bit of legwork, we found that the WHOIS server for a particular TLD - .mobi - had been changed some years ago from the old domain whois.dotmobiregistry.net to a new server, at whois.nic.mobi.
然而，當伺服器地址變更時，它會以不雅的方式崩潰。經過一點點努力，我們發現某個 TLD 的 WHOIS 伺服器 - .mobi - 已經在幾年前從舊域名 whois.dotmobiregistry.net 更換到新的伺服器，即 whois.nic.mobi 。

Of course though, because the Internet is joined together by literal string and hopes/wishes at this stage, somebody had neglected to renew the old domain at dotmobiregistry.net meaning it was up for grabs by anyone with $20 and an ill-advised sense of exploration.
當然，因為目前互聯網是由文字和希望/願望連接在一起，所以有人疏忽了更新舊域名在 dotmobiregistry.net ，意味著任何人只要花 20 美元和一個不明智的探索感就可以搶購。

We registered the domain, working on the theory that, while most client tooling would be updated to use whois.nic.mobi, most of the Internet population is still surprised when their 2011 SAP deployment gets popped, and thus WHOIS applications in production had a fairly decent chance of still referencing whois.dotmobiregistry.net.
我們註冊了域名，基於這個理論，即儘管大多數客戶工具將更新以使用 whois.nic.mobi ，但當大多數網絡用戶發現他們 2011 年的 SAP 部署被攻擊時，仍然會感到驚訝，因此生產中的 WHOIS 申請還有相當高的機會仍然參考 whois.dotmobiregistry.net 。

Of course, this being the Internet, we got a little more than we bargained for.
當然，由於這是互聯網，我們得到的超出了我們的預期。

So What? It's Old 所謂？已經很舊了

We soon realized the threat model for this attack had just changed.
我們很快意識到這次攻擊的威脅模型已經改變了。

Now that we control a WHOIS server, we were in the position to ‘respond’ to traffic sent by anyone who hadn’t updated their client to use the new address (auto updates are bad, turn them off).
現在，我們控制了一個 WHOIS 伺服器，我們處於可以「回應」由任何未更新客戶端以使用新地址的人發送的流量（自動更新很糟糕，關閉它們）。

No longer do we require a Man-In-The-Middle attack, or some exotic WHOIS referral, to exploit a WHOIS client vulnerability - all we need to do is wait for queries to come in, and theoretically respond with whatever we want.
不再需要進行中間人攻擊，或某些外來的 WHOIS 參考，來利用 WHOIS 客戶端漏洞——我們所需要做的就是等待查詢來到，並理論上以我們想要的任何內容來回應。

The pre-requisites for real-world exploitation now sat within what we deemed ‘rough reality’.
實際應用的先決條件現在位於我們所謂的「粗糙現實」之中。

Things were beginning to escalate.
事態開始升級。

We had set out to find some simple bugs in WHOIS client tooling, file for some CVEs, get them fixed.. but then we realised that once again we’d probably chewed off more than we intended and things were about to become worse - much worse.
我們原本打算在 WHOIS 客戶端工具中找出一些簡單的錯誤，為某些 CVE 提交報告，並修復它們。但後來我們意識到，我們可能又超出了預期的範圍，情況即將變得更加惡化——非常惡化。

Never Update, Auto-Updates And Change Are Bad
從不更新、自動更新和變更都是不好的

Unfortunately, there is a lot of Internet infrastructure which depends on the antiquated WHOIS protocol.
很不幸，有許多互聯網基礎設施依賴於過時的 WHOIS 協議。

Starting off slow, we’re now in a position to attack the many websites that run a WHOIS client and echo the results back to the user, injecting XSS or PHP eval payloads. Ethical (and legal) concerns prevent us from doing so, however - and we did not spend $20 to get an XSS.
開始時速度較慢，我們現在處於能夠攻擊許多運行 WHOIS 客戶端並將結果回應給用戶的狀態，注入 XSS 或 PHP eval 有效載荷。然而，道德（以及法律）上的關注阻止了我們這麼做——我們並沒有花 20 美元來獲得一個 XSS。

Of course, our original goal was to find and exploit some 0day in WHOIS clients, or some other system that embeds a WHOIS client (such as a spam filter), similar to the trivial memory corruption we found earlier.
當然，我們的原始目標是尋找並利用某些 WHOIS 客戶端的 0day 漏洞，或者嵌入 WHOIS 客戶端的其他系統（例如垃圾郵件過濾器），與我們之前發現的簡單記憶體洩漏相似。

Our biggest hurdle here - as alluded to above - was the simplicity of the WHOIS protocol itself, which is a simple text-based TCP data stream. With so little complexity, there seemed very little room for developers to make errors.
我們在這裡最大的障礙——如上所述——是 WHOIS 協議本身的簡單性，它是一個簡單的基於文字的 TCP 數據流。由於複雜性如此之低，似乎沒有太多空間讓開發者犯錯誤。

Ha. 哈。

Prior Art 先有技術

To fully understand and look to leverage our new capability and adjusted threat model, we decided to examine the area’s ‘prior art’ in exploitation, looking at historic attacks on WHOIS clients.
為了全面了解並善用我們的新功能及調整後的威脅模型，我們決定檢視該領域的「先有技術」在洩漏方面的應用，檢視對 WHOIS 客戶的歷史攻擊。

We were somewhat surprised that a search for relevant CVE data yielded relatively few results, which we attributed to the area being under-researched - the search return 26 CVE records.
我們有些驚訝地發現，搜索相關 CVE 數據的結果相對較少，我們將這歸因於該領域研究不足 - 搜索返回了 26 條 CVE 記錄。

Once we discount the irrelevant results, we are left with only three bugs that are triggered by malformed WHOIS responses.
一旦我們排除無關結果，我們只剩下三個由格式錯誤的 WHOIS 回應觸發的錯誤。

This small number - three bugs since 1999 - makes it obvious to us that very little research has been done - likely due to the perception that any real-world exploitation comes with difficult prerequisites, such as control of a TLD WHOIS server.
這個小數字——自 1999 年以來有三個錯誤——對我們來說顯而易見，進行的研討非常有限——可能是由於認為任何實際應用都需要困難的先決條件，例如控制 TLD WHOIS 伺服器。

But, there have been some interesting cases - just to give you a taste of where this is going.
但，已經有一些有趣的案例——只為了讓你一瞥這將走向何方。

phpWHOIS (CVE-2015-5243)

The first bug that our retrospective found was CVE-2015-5243. This is a monster of a bug, in which the prolific phpWhois library simply executes data obtained from the WHOIS server via the PHP ‘eval’ function, allowing instant RCE from any malicious WHOIS server.
第一次我們回顧發現的錯誤是 CVE-2015-5243。這是一個怪物般的錯誤，其中多產的 phpWhois 函式庫簡單地執行從 WHOIS 伺服器通過 PHP 的 'eval' 函數獲取的數據，允許從任何惡意 WHOIS 伺服器立即實現 RCE（遠端執行）。

The vulnerable code snippet:

foreach ($items as $match => $field) {
    $pos = strpos($val, $match);

    if ($pos !== false) {
        if ($field != '') {
            $var = '$r' . getvarname($field);
            $itm = trim(substr($val, $pos + strlen($match)));

            if ($itm != '')
                eval($var . '="' . str_replace('"', '\\\\"', $itm) . '";');
        }

        if (!$scanall)
            break;
    }
}

What’s going on here?
發生了什麼事？

The important item is the juicy eval statement in the middle of the snippet, which is fed data returned from the WHOIS server.
重要項目是中間的 juicy eval 語句，該語句從 WHOIS 伺服器返回的數據中獲取。

While it attempts to escape this data before it evaluates it, it does so imperfectly, only replacing " with the escaped form, \\\\" . Because of this, we can sneak in our own PHP code, which is then executed for us.
當它試圖在評估之前逃逸這些數據時，它做得很不完美，只將 " 替換為逃逸形式， \\\\" 。因此，我們可以偷偷加入我們自己的 PHP 代碼，然後它會為我們執行。

Netitude’s blogpost lays out all the details, and even provides us with exploitation code - ”;phpinfo();// - is enough to spawn a phpinfo page.
Netitude 的博客文章詳細列出所有細節，甚至提供給我們利用程式碼 - ”;phpinfo();// - 只需 phpinfo 頁面即可啟動。

We tried this out on an application that uses phpWhois, purely to demonstrate, and it worked swimmingly:
我們在一個使用 phpWhois 的應用程序上試了這個，純粹為了展示，結果非常出色：

Clearly this is a powerful bug - the best part being that phpWhois hardcodes our newly found whois.dotmobiregistry.net in vulnerable versions (it's old, but at a cursory glance no-one appears to have ever updated phpWhois).
這顯然是一個強大的錯誤——最好的部分在於 phpWhois 在易受攻擊的版本中硬編碼了我們新發現的 whois.dotmobiregistry.net （它很舊，但粗略一看似乎沒有人更新過 phpWhois）。

What other historic artefacts could we find, though?
我們還能發現哪些歷史遺物呢？

Fail2Ban (CVE-2021-32749)
失敗禁止 (CVE-2021-32749)

As we continued to examine historic client-side bugs, we came across CVE-2021-32749. This one is again a pretty nasty bug, this time in the ever-popular fail2ban package. It’s a command injection vulnerability, a vulnerability class keenly sought by attackers due to its power and ease of exploitation.
我們在繼續檢查歷史客戶端錯誤時，遇到了 CVE-2021-32749。這一次又是一個相當惡劣的錯誤，這次是在永遠受歡迎的 fail2ban 套件中。它是一個命令注入漏洞，由於其強大和易於利用，這是一種攻擊者極為關注的漏洞類別。

As you may know, if you have administered a fail2ban server, the purpose of fail2ban is to monitor failed login attempts, and prevent bruteforce or password-guessing attacks by blocking hosts which repeatedly fail to log in.
如你所知，如果你管理過 fail2ban 伺服器， fail2ban 的目的是監控失敗的登錄嘗試，並通過阻止反覆失敗登錄的主機來防止暴力破解或密碼試猜攻擊。

Being the polished package it is, it also includes the ability to email an administrator when an IP address is banned, and - very helpfully - when it does so, it will enrich the email with information about who owns the banned IP address.
作為一個光鮮亮麗的套件，它還包括當 IP 地址被封鎖時向管理員發送電子郵件的功能，而且非常實用——當它這麼做時，它會將有關被封鎖 IP 地址所有者的信息豐富到電子郵件中。

This information is gleaned from - yeah, you guessed it! - our friend WHOIS.
此資訊來自於 - 哎，你猜對了！ - 我們的朋友 WHOIS。

Unfortunately, for some time, the output of the WHOIS client wasn’t correctly sanitized before being passed to the mail tool, and so a command injection bug was possible.
很抱歉，一段時間內，WHOIS 客戶端的輸出在傳遞給 mail 工具之前並未正確消毒，因此可能存在命令注入錯誤。

Fortunately - or unfortunately, if you’re an attacker - because fail2ban runs a WHOIS query on the IP address rather than, for example, a domain name specified in the PTR record of an IP address of blocked hosts - this attack is not within reach still based on our newly found capability.
幸運的是——或者不幸的是，如果你是一個攻擊者——因為 fail2ban 對 IP 地址進行 WHOIS 查詢，而不是例如在阻斷主機的 IP 地址的 PTR 記錄中指定的域名——這種攻擊仍然超出了我們新發現的能力範圍。

For those that control a WHOIS server that is queried for IP addresses, though, exploitation is simple - simply attempt to unsuccessfully authenticate to a server via SSH a few times to trigger a ban, and once fail2ban queries the WHOIS server for information on your IP address - serve a payload wrapped in backticks.
對於那些控制被查詢 IP 地址的 WHOIS 伺服器的人來說，利用則非常簡單——只需嘗試無法通過 SSH 驗證伺服器幾次以觸發封鎖，然後當 fail2ban 查詢 WHOIS 伺服器以獲取您 IP 地址的資訊時——提供一個被反引號包裝的 payload。

Reality check 現實檢視

So, the burning question on our minds - can we actually exploit these bugs, right now?
所以，我們心中燃燒的問題——我們現在真的能夠利用這些錯誤，對吧？

Well, at this stage, our view was fairly pessimistic in terms of achieving real-world impact. We saw the following pre-requisites:
好吧，在這個階段，我們對實現實際影響的看法相當悲觀。我們看到了以下預設條件：

  • The WHOIS client must be querying an old authoritative .MOBI WHOIS server and thus by definition, has not been working for quite a while
    WHOIS 客戶必須正在查詢舊的認證 .MOBI WHOIS 伺服器，因此按照定義，已經有一段時間沒有正常工作了
  • To achieve client-side code execution (i.e. compromise) via a WHOIS client vuln - the only public option available to us was disclosed in 2015 and appears to have been rectified in 2018 - likely due to the perceived lack of real-world exploitation mechanisms.
    為了通過 WHOIS 客戶端漏洞實現客戶端代碼執行（即攻擊）- 我們唯一可用的公共選項在 2015 年被揭露，並看起來在 2018 年已經得到修正 - 這可能是由於認為缺乏現實世界實際利用機制的感知。

Meh. Our gut feeling remained that most of the Internet and those in the sane world would logically be querying the new .mobi authoritative WHOIS server whois.nic.mobi, rather than the decommissioned dotmobiregistry.net (which we now controlled).
Meh. 我們的直覺仍然認為，大多數的互聯網和那些理智的世界中的人會邏輯性地查詢新的 .mobi 权威 WHOIS 伺服器 whois.nic.mobi ，而不是已經退役的 dotmobiregistry.net （我們現在控制著）。

“Surely no large organisations would still reference the old domain”, we thought to ourselves.
當然沒有大型組織還會參考舊網域名，我們這麼想。

Kill WHOIS With Fire 燃燒 WHOIS

Without skipping a beat and really not considering the consequences, we set up a WHOIS server beneath our new domain at whois.dotmobiregistry.net, and logged incoming requests. We specifically focused on two things:
不顧一切地跳過每一步，並真正沒有考慮後果，我們在我們新的域名 whois.dotmobiregistry.net 下設置了一個 WHOIS 伺服器，並記錄了來自的請求。我們特別關注兩件事：

  • Source IPs (so we can perhaps begin to work out who exactly was querying an outdated server), and,
    來源 IP（我們可以開始分析究竟誰正在查詢過時的伺服器），以及，
  • The queried domain (because again, this may give off some clues).
    查詢的域名（因為再次，這可能會提供一些線索）。

We threw together the lglass server to respond to WHOIS requests that found their way to our WHOIS server, and returned:
我們迅速搭建了 lglass 伺服器以回應尋找到我們 WHOIS 伺服器的 WHOIS 請求，並返回：

  • ASCII art (we were relatively refrained here, but it was a priority)
    ASCII 藝術（我們這裡相對克制，但這是優先事項）
  • Fake WHOIS details indicating watchTowr as the owner for every queried entity.
    偽裝的 WHOIS 詳細資訊，將 watchTowr 標示為每個查詢實體的所有者。

As this was our private server, we included a request for queries to cease (after all, they were unauthorised).
這是我們的私人伺服器，所以我們要求停止查詢請求（畢竟，它們是不被授權的）。

A quick test directly to our new WHOIS server showed that all was working as expected, with the following response provided for a query about google.mobi:
快速測試直接到我們新的 WHOIS 伺服器，顯示所有功能都按預期運作，以下為關於 google.mobi 的查詢提供的回應：

Nice. 不錯。

Uh….. ,……

Well, it’s 2024 - absolutely no one has the ability to exercise patience, including ourselves.
啊，現在是 2024 年 - 沒有人有耐心，包括我們自己。

So, we began just looking around the Internet for obvious locations that could be sending queries our way. Surely, we thought - surely! - the broken clients using an outdated server address wouldn’t be in anything major, that we use every day?
所以，我們只是開始在互聯網上尋找顯而易見的可能向我們發送查詢的地點。當然，我們想——當然！——使用過時伺服器地址的損壞客戶不會在每天我們都使用的任何重大事物中？

etc (you get the idea)
等等（你明白意思）

A screenshot of each WHOIS tool would become repetitive, but you get the idea.
一個 WHOIS 工具的截圖將會變得重複，但你能夠理解這個概念。

  • urlscan.io - “A sandbox for the web” - used our WHOIS server for .mobi, too. You can see the results by browsing to a page representing any .mobi domain (like this one).
    urlscan.io - “網際網路的沙盒” - 也使用了我們的 WHOIS 伺服器來處理.mobi，您可以通过瀏覽代表任何.mobi 域名的頁面（就像這個一樣）來查看結果。
  • VirusTotal, the popular malware-analysis site, was querying us! A tool dedicated to the analysis of hostile code seemed like an opportunity for enjoyment.
    病毒總量，這個受歡迎的惡意軟體分析網站，正在向我們查詢！一個專門用於分析敵對代碼的工具，看起來像是享受的機會。

Sadly, VirusTotal doesn't render our ASCII art properly, but as you can see - VirusTotal is querying our makeshift WHOIS server for this global .TLD and presenting back the results. We were also pleased to see that VirusTotal updated their records of who owns bbc.mobi:
可惜，VirusTotal 沒有正確呈現我們的 ASCII 藝術，但正如您所見 - VirusTotal 正在查詢我們的臨時 WHOIS 伺服器以取得這個全球 .TLD 的資訊，並呈現回結果。我們也很高興看到 VirusTotal 更新了關於 bbc.mobi 的所有者記錄：

For anyone that has ever worked in offensive security, you occasionally get a sinking feeling where you realize something may be a little larger than expected, and you begin to wonder.. “what have we broken?”.
對於任何曾經在攻擊安全領域工作過的人來說，你偶爾會有一種沉澱的感覺，當你意識到某件事可能比預期的要大一些，你開始疑惑…“我們打破了什麼？”

(Editors note: Technically, this should be ‘what was broken’, because people were querying our WHOIS server without authorisation and we’re very upset - get off our lawn!).
(編輯者註：從技術上來說，這應該是‘出了什麼問題’，因為有人未經授權查詢我們的 WHOIS 伺服器，我們非常不滿——請離開我們的草坪！）。

Well, with our WHOIS server clearly working - we figured we’d come back in a few days and see if anything at all reached out to us - giving us a good excuse to stare at a separate PSIRT response indicating a 2 year lead time to resolve a vulnerability.
嗯，我們的 WHOIS 伺服器顯然正在運作 - 我們想過幾天再回來看看是否有任何東西聯繫我們 - 這成為我們專注於另一個 PSIRT 回應的好藉口，該回應指出解決漏洞需要 2 年的預先時間。

Being insatiable and generally finding it hard to focus on anything longer than a TikTok video of a dog in a hat, we took a look to see how many unique IPs had queried our new WHOIS server after a few hours:
不斷求新且通常難以專注於超過一個戴帽子的狗的 TikTok 影片的時間，我們查看幾個小時後有多少獨特的 IP 已經查詢我們的新 WHOIS 伺服器：

$ sqlite3 whois-log-copy.db "select source from queries"|sort|uniq|wc -l
76085

Uh. Yes, that’s correct - this is 76,000+ unique source IP addresses that have sent queries to our WHOIS server in just a couple of hours.
嗯。對的，這是 76,000 多個獨特的源 IP 位址，在短短幾個小時內向我們的 WHOIS 伺服器發送了查詢。

We were somewhat dismayed when, after leaving our server running for around two days, the poor little SQLite DB containing the logs ballooned to some 1.3 million queries! Clearly, we’d stumbled into something more major than we’d anticipated.
我們在將伺服器運行約兩天後，發現那個包含日誌的瘦小 SQLite DB 突然膨脹到約 1.3 百萬次查詢，這讓我們有些失望。顯然，我們遇到了比預期更重大的問題。

We threw the list of IPs at ZDNS and just sat back, as a relatively feeble way of doing attribution:
我們將 IP 清單丟給 ZDNS，然後就坐回來，這是一種相對薄弱的進行歸因的方法：

$ cat whois-src.txt|./zdns PTR > ptr.txt

Anyway, the results were curious.
無論如何，結果很奇特。

$ grep gov ptr.txt |{magic}|sort|uniq
.gov-east-1.compute.amazonaws.com."
.gov.ar."
.gov.bd."
.gov.br."
.gov.il."
.gov.in."
.gov.ph."
.gov"

Great. We’d inadvertently done a thing.
很棒。我們不經意地做了一件事。

Some other highlights of source hosts (not exhaustive, but just to give you some idea of just how bad this trash fire appeared to be):
某些來源主機的其他亮點（不全面，只是為了讓你了解這場慘烈的火災看起來有多糟糕）:

  • Mail servers! Lots and lots of mail servers.
    郵件伺服器！無數無數的郵件伺服器。

    Spam filters will often do WHOIS lookups on sender domains. We saw a bunch of these, ranging from the aptly-named cheapsender.email through to mail.bdcustoms.gov.bd - which appears to be part of the Bangladeshi government's infrastructure. Yikes! Theoretically, we could cause mayhem by serving responses indicating that the sending domain was a known spammer - and even more mayhem-worthy to start fuzzing the WHOIS parsing code to pop RCE on the mail servers themselves. 

    (We didn’t) (我們沒有）
  • Leading on from that thought, what other .gov apparatus have we been queried by?
    從那個想法出發，我們還被詢問過哪些.gov 設備？
    Well, we found Brazil in our logs multiple times - for example, antispam.ap.gov.br and master.aneel.gov.br , and Brazil was not alone. We also found .gov addresses belonging to (but again not limited to):
    好吧，我們在日誌中多次找到巴西 - 例如， antispam.ap.gov.br 和 master.aneel.gov.br ，而巴西並不獨一無二。我們還找到了屬於（但又不僅限於） .gov 地址：
    • Argentina, 阿根廷，
    • Pakistan, 巴基斯坦，
    • India, 印度，
    • Bangladesh, 孟加拉國，
    • Indonesia, 印尼
    • Bhutan, 不丹
    • Philippines, 菲律賓，
    • Israel, 以色列
    • Ethiopia, 衣索比亞
    • Ukraine, 烏克蘭
    • USA. 美國。

Neat. 整齊。

  • Militaries (.mil) 軍事 (.mil)
    • Swedish Armed Forces, for example
      瑞典國防軍，例如
  • Universities (.edu) 大學 (.edu)
    • All of them 所有這些
  • We even saw cyber security companies - hey Group-IB, Detectify! - query our WHOIS server (presumably doing threat intel things for .mobi domains).
    我們甚至看到了網絡安全公司——嘿，Group-IB，Detectify！——查詢我們的 WHOIS 伺服器（可能是在為.mobi 域名進行威脅情報事務）。
    • We saw Censys query us for ‘google.com’ and wondered if we’d get an APT number and a threat intel report shout-out if we’d been actively delivering payloads. Maybe we did? Check your boxen. (We didn't. Or did we?) 

We’re still trying to determine what software solutions are in play here/configured to query this WHOIS server for .mobi - let us know if you have any ideas.
我們仍在試圖確定這裡使用哪些軟體解決方案/配置以查詢這個.mobi 的 WHOIS 伺服器 - 如果你有任何想法，請告訴我們。

Those who are nefariously minded likely realised what we saw as well - with .gov and other mail servers querying us each time they received an email from a .mobi domain - we could begin to passively determine who may be in communication.
那些心懷邪念的人可能已經意識到我們所看到的——當他們從.mobi 域名收到電子郵件時，每次.gov 和其他郵件伺服器都會向我們查詢——我們可以開始被動地判斷誰可能正在進行通訊。

This is not ideal. How do we fix this? Well, hold that thought - IT GETS WORSE.
這不是理想狀況。我們該如何解決這個問題？好吧，先別急著想——情況會變得更糟。

Tales of TLS 故事 of TLS

TLS/SSL. Everyone knows it - it’s that friendly little padlock icon in the address bar that assures you that your connection is secure. It’s powered by the concept of certificates - sometimes used for HTTPS, sometimes used for signing your malware.
TLS/SSL。大家都知道它——那就是位於地址欄的那個親切的 小鎖頭圖標，它確保你的連接是安全的。它由證書的概念驅動——有時用於 HTTPS，有時用於簽署你的惡意軟體。

For example, say you’re the owner of watchTowr.mobi. You want to secure communications to your web server by speaking TLS/SSL , so you go off to your favourite Certificate Authority and request a certificate (let’s also pretend you haven’t heard of LetsEncrypt).
例如，假設你是 watchTowr.mobi 的擁有者。你想要透過 TLS/SSL 來確保與你的網站伺服器的通訊安全，所以你前往你最喜歡的證書授權機構並請求一個證書（讓我們也假裝你還沒聽說過 Let's Encrypt）。

The Certificate Authority will verify that you own the domain in question - watchTowr.mobi - and will then sign a private certificate, attesting to your identity as the owner of that domain. This is then used by the browser to ensure your communications are secure.
證書機構將確認您擁有相關的域名 - watchTowr.mobi - 並將簽署一份私有證書，證明您是該域名的擁有者。此後，瀏覽器將使用這個證書來確保您的通訊是安全的。

Speaking of LetsEncrypt, this thread is interesting - https://community.letsencrypt.org/t/why-doesnt-lets-encrypt-use-whois-information-for-domain-validation/46287). In this thread, forum posters detail why LetsEncrypt doesn’t validate domains via WHOIS. Seems paranoid.
關於 Let's Encrypt，這個討論串很有趣 - https://community.letsencrypt.org/t/why-doesnt-lets-encrypt-use-whois-information-for-domain-validation/46287)。在這個討論串中，論壇發帖者詳細解釋了為什麼 Let's Encrypt 不透過 WHOIS 進行域名驗證。看起來有些過於謹慎。

Anyway, what does this have to do with WHOIS, and what does it have to do with us?!
任何，這與 WHOIS 有何關係，與我們有何關係？！

Well, it turns out that a number of TLS/SSL authorities will verify ownership of a domain by parsing WHOIS data for your domain - say watchTowr.mobi- and pulling out email addresses defined as the ‘administrative contact’.
好吧，結果顯示，許多 TLS/SSL 機構會通過解析您的域名（例如 watchTowr.mobi ）的 WHOIS 數據，並提取被定義為「管理聯繫人」的電子郵件地址來驗證域名的所有權。

The process is to then send that email address a verification link - once clicked, the Certificate Authority is convinced that you control the domain that you are requesting a TLS/SSL cert for and they will happily mint you a certificate.
流程是然後將驗證鏈接發送到該電子郵件地址 - 一旦點擊，證書授權機構將相信您控制您所請求 TLS/SSL 證書的域名，他們將高興地為您簽發證書。

For example: 例如：

Perhaps you can see where we’re going with this? sobs
或許你可以看出我們這個方向？嘆息

If a TLS/SSL certificate authority is using our WHOIS server for .mobi domains, we can likely provide our own email address for this “Email Domain Control Validation” method.
如果 TLS/SSL 憑證機構正在使用我們的 WHOIS 伺服器為 .mobi 域名，我們可能能提供我們自己的電子郵件地址以供此“電子郵件域名控制驗證”方法使用。

Uh-oh. Is this a fringe feature supported only by two-bit, poor-quality certificate authorities?
啊唷。這是只有兩毛五分的低質量證書機構支持的邊緣功能嗎？

No! Here’s a sample of large TLS/SSL Certificate Authorities/resellers that support WHOIS-based ownership verification:
不！以下是支持基於 WHOIS 的所有權驗證的大型 TLS/SSL 證書機構/經銷商的範例：

  • Trustico 信貿科
  • Comodo 康多
  • SSLS
  • GoGetSSL
  • GlobalSign 全球簽證
  • DigiSign 數位簽名
  • Sectigo 設領通

Going through the normal order flow, we began cautiously - by generating a CSR (Certificate Signing Request) for the fictitious domain watchTowr.mobi - the logic being that as long as our WHOIS server was queried, whether or not the domain was real was irrelevant because we respond positively to absolutely every request including domains that don’t actually exist.
通過正常的訂單流程，我們開始謹慎地進行 - 通過為虛構的域名 watchTowr.mobi 生成 CSR（證書簽名請求）- 這個邏輯是只要我們的 WHOIS 伺服器被查詢，無論域名是否為真實的都無關緊要，因為我們對絕對每個請求都給予積極的回應，包括那些實際上不存在的域名。

# sudo openssl req -new -key custom.key -out csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:SG
State or Province Name (full name) [Some-State]:Singapore
Locality Name (eg, city) []:Singapore
Organization Name (eg, company) [Internet Widgits Pty Ltd]:watchTowr 
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:watchtowr.mobi
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

We’re not going to walk through each provider - for the purposes of illustration, we’ll use GoGetSSL.
我們不會逐一介紹每個供應商 - 為了說明之用，我們將使用 GoGetSSL。

Once we upload our watchTowr.mobi CSR to GoGetSSL, it is parsed, and we continue. The indication of these placeholder email addresses indicates that WHOIS was not successful - instead of the email address that our WHOIS server is configured to respond with (whois@watchtowr.com), we’re presented with only @watchtowr.mobi domains.
getting our watchTowr.mobi CSR 上傳到 GoGetSSL 之後，將會被解析，我們繼續進行。這些占位符電子郵件地址的指示表示 WHOIS 沒有成功 - 我們沒有收到我們 WHOIS 伺服器配置以回應的電子郵件地址（ whois@watchtowr.com ），而是只顯示 @watchtowr.mobi 域名。

That’s something of a relief.
這是某種程度的舒緩。

The Certificate Authority has correctly determined that the domain watchTowr.mobi does not exist and thus if WHOIS is working as expected, no email addresses will be returned. We concluded that our newly set up WHOIS server was not being queried by the provider.
證書機構已正確判斷域名 watchTowr.mobi 不存在，因此如果 WHOIS 依預期運作，則不會返回任何電子郵件地址。我們得出結論，我們新設置的 WHOIS 伺服器未被供應商查詢。

At least the world isn’t ending. Right? (spoiler: it actually was)
至少世界還沒有結束。對吧？（洩漏：其實已經結束了）

We carried on trying a few other providers until a thought occurred.
我們繼續嘗試其他幾個供應商，直到一個想法浮現。

The WHOIS protocol is extremely simple. Essentially it is a string blob returned in various formats depending on the TLD serving it. Each provider implements parsing in their own way. Perhaps, before we write off our theory, we should make sure this verification mechanism is actually working as it is supposed to.
WHOIS 協議非常簡單。實質上，它是一個以各種格式返回的字符串 blob，這取決於服務它的 TLD。每個提供者都以他們自己的方式實現解析。或者，在我們放棄我們的理論之前，我們應該確保這個驗證機制正在按預期的方式運作。

So, we began again - choosing microsoft.mobi as a .mobi domain that appeared to follow a fairly typical WHOIS format (when using the current .mobi WHOIS server).
所以，我們再次開始 - 選擇 microsoft.mobi 作為一個 .mobi 域名，該域名看起來遵循一個相當典型的 WHOIS 格式（當使用當前的 .mobi WHOIS 伺服器時）。

The screenshot below shows that the legitimate WHOIS record for microsoft.mobi was correctly parsed at Entrust, as the only email addresses available for validation were at the microsoft.com domain:
以下截圖顯示， microsoft.mobi 的合法 WHOIS 記錄已在 Entrust 正確解析，因為可供驗證的電子郵件地址僅在 microsoft.com 域名下：

While the WHOIS record for watchTowr.mobi was not being parsed at all (indicating that Entrust was using the correct WHOIS server, and not ours):
當 watchTowr.mobi 的 WHOIS 紀錄根本沒有被解析（這表示 Entrust 正在使用正確的 WHOIS 伺服器，而不是我們的）：

Looks good you think? 看起來還不錯，你這麼認為嗎？

WRONG. 錯誤。

We skipped and hopped over to the next provider, GlobalSign. GlobalSign reported that they were unable to parse the WHOIS record of microsoft.mobi:
我們跳過並跳到下一個供應商，GlobalSign。GlobalSign 回報他們無法解析 microsoft.mobi 的 WHOIS 記錄：

At this point, something clicked in our minds. Perhaps GlobalSign WAS querying our new WHOIS server - but the string returned by our WHOIS server was incompatible with GlobalSign’s parsing?
在這個時刻，我們的腦海中突然有了啟發。可能 GlobalSign 正在查詢我們的新 WHOIS 伺服器——但由我們的 WHOIS 伺服器返回的字符串與 GlobalSign 的解析不兼容？

We copied the microsoft.mobi output from the legitimate WHOIS server, made it our own, and loaded it into our own WHOIS server - updated to look like the following:
我們複製了來自合法 WHOIS 伺服器的 microsoft.mobi 輸出，使其成為我們自己的，並將其載入我們自己的 WHOIS 伺服器 - 更新後如下所示：

Holding our breath, we then re-triggered GlobalSign with a CSR for microsoft.mobi…
我們屏住呼吸，然後使用 CSR 重新觸發 GlobalSign 於 microsoft.mobi …

We want to be explicitly clear that we stopped at this point and did not issue any rogue TLS/SSL certificates to ourselves. This would undoubtedly create an incident, and require significant amounts of work by many parties to revoke and roll back this action.
我們想明確表示，我們在這個點停止，並未向我們自己發行任何惡意 TLS/SSL 證書。這無疑會造成事件，並需要許多當事人投入大量工作來撤銷和回滚此行動。

Success! 成功！

The GlobalSign TLS/SSL certificate WHOIS domain verification system had queried our WHOIS server, parsed whois@watchTowr.com from the result, and presented it as a valid email address to send a verification email to, allowing us to complete verification and obtain a valid TLS/SSL certificate.
全球 Sign TLS/SSL 憑證 WHOIS 域名驗證系統已查詢我們的 WHOIS 伺服器，從結果中解析出 whois@watchTowr.com ，並將其呈現為有效的電子郵件地址，以發送驗證郵件，使我們能夠完成驗證並獲得有效的 TLS/SSL 憑證。

This is then blindingly simple:
這其實非常簡單：

  • Set up a rogue WHOIS server on our previously authoritative hostname, responding with our own email address as an ‘administrative contact’
    設置我們先前具有權威性的主機名上的惡意 WHOIS 伺服器，以我們自己的電子郵件地址作為「管理聯繫人」回應
  • Attempt to purchase a TLS/SSL certificate for a .mobi domain we want to target (say, microsoft.mobi)
    嘗試購買一個我們想要目標的 TLS/SSL 國家/地區代碼 ( .mobi ) 的憑證（例如， microsoft.mobi ）
  • A Certificate Authority will then perform a WHOIS lookup, and email us instead of the real domain owners [theory]
    一個證書機構將進行 WHOIS 查詢，並將電子郵件發送給我們，而不是真正的域名所有者 [理論]
  • We click the link, and.. [theory]
    我們點擊連結，然後... [理論]
  • … receive an TLS/SSL cert for the target domain! [theory]
    … 接收目標域的 TLS/SSL 證書！ [理論]

Now that we have the ability to issue a TLS/SSL cert for a .mobi domain, we can, in theory, do all sorts of horrible things - ranging from intercepting traffic to impersonating the target server. It’s game over for all sorts of threat models at this point.
現在，我們有能為 .mobi 域發行 TLS/SSL 證書的能力，理論上我們可以執行各種可怕的事情——從攔截流量到偽裝目標伺服器。對於各種威脅模型來說，這時遊戲已經結束了。

While we are sure some may say we didn’t ‘prove’ we could obtain the certificate, we feel this would’ve been a step too far — so whatever.
當我們確信有些人可能會說我們沒有「證明」我們能夠獲得證書，我們認為這將會是一個過於冒進的步驟——所以無所謂。

One Last Thing 最後一件事

Please stop emailing us..
請停止給我們發郵件。

Here We Go Again.. 再來一次...

We hope you’ve enjoyed (and/or been terrified by) today’s post, in which we took control of a chunk of the Internet’s infrastructure, opened up a big slab of juicy attack surface, and found a neat way of undermining TLS/SSL - the fundamental protocol that allows for secure communication on the web.
我們希望您已經享受（以及/或被驚嚇）了今天的貼文，在其中我們掌握了互聯網基礎設施的一部分，開啟了一塊大塊美味的攻擊面，並找到了一個巧妙的方法來破壞 TLS/SSL——這是允許網絡上安全通訊的基本協議。

We want to thank the UK's NCSC and the ShadowServer Foundation for rapidly working with us ahead of the release of this research to ensure that the 'dotmobiregistry.net' domain is suitably handled going forwards, and that a process is put in place to notify affected parties.
我們想感謝英國的 NCSC 和 ShadowServer Foundation 在我們發布這項研究之前迅速與我們合作，確保'dotmobiregistry.net'域名將得到適當處理，並設立一個流程來通知受影響的當事人。

The dotmobiregistry.net domain, and whois.dotmobiregisry.net hostname, has been pointed to sinkhole systems provided by ShadowServer that now proxy the legitimate WHOIS response for .mobi domains.
The dotmobiregistry.net 域，以及 whois.dotmobiregisry.net 主機名，已指向由 ShadowServer 提供的陷阱系統，該系統現已代理 .mobi 域名的合法 WHOIS 回應。

We released this blog post to initially share our process around making the unexploitable exploitable and highlight the state of legacy infrastructure and increasing problems associated with abandoned domains - but inadvertently, we have shone a spotlight on the continuing trivial loopholes in one of the Internet’s most vital encryption processes and structures - TLS/SSL Certificate Authorities. Our research has demonstrated that trust placed in this process by governments and authorities worldwide should be considered misplaced at this stage, in our opinion.
我們發布了這篇博客文章，最初是為了分享我們將無法利用的內容變得可利用的過程，並強調傳統基礎設施的狀況以及與棄用域名相關的日益增加的問題——但無意中我們將聚光燈投向了互聯網最關鍵的加密過程和結構之一——TLS/SSL 證書機構的持續簡單漏洞。我們的研究表明，在這個階段，全球政府和機構對此過程所寄予的信任應該被認為是錯置的，我們的看法是如此。

We continue to hold concern around the basic reality - we found this on a whim in a hotel room while escaping the Vegas heat surrounding Black Hat, while well-resourced and focused nation-states look for loopholes like this every day. In our opinion, we are not likely to be the last to find inexcusable flaws in such a crucial process. 
我們繼續關注基本事實——我們在逃避黑帽大會周圍的維加斯熱浪時，隨意在一間酒店房間裡發現了這個問題，而資源充足且專注的國家每天都在尋找這樣的漏洞。在我們看來，我們不太可能是最後一個在這樣關鍵過程中發現不可原諒缺點的人。

Although subverting the CA verification process was by far the most devastating of impacts that we uncovered, it was by no means the limit of the opportunity available to us as we also found everything from memory corruptions to command injections. Our ‘honeypot’ WHOIS server gave us some interesting statistics, revealing just how serious the issue is, and a large amount of Internet infrastructure continues to query us instead of the legitimate WHOIS servers.
不過，我們發現的最具破壞性的影響莫過於干擾 CA 驗證流程，但絕非我們能夠利用的機會的極限，因為我們還發現了從記憶體損壞到命令注入的各種問題。我們的「釣魚罐」WHOIS 伺服器提供了一些有趣的統計數據，揭示了這個問題的嚴重性，以及大量的互聯網基礎設施繼續向我們查詢，而不是尋找合法的 WHOIS 伺服器。

We do not intend to call out any specific organization or maintainer here - the prevalence of this issue and the statistics on hand show that this is not a pure-negligence or competence related issue - but a fundamental flaw in how these processes work together.
我們並無意指名道姓任何特定組織或維護者——這個問題的普遍性和手頭的統計數據顯示，這不是純粹疏忽或能力相關的問題——而是這些流程如何相互運作的根本缺陷。

It’s worth noting that all the above attacks that we were able to orchestrate given our takeover are also possible by any entity that is able to carry out MITM attacks - such as entities that control or can influence transit backbones. It would be very easy for an attacker with such access to fake WHOIS data for any domain, and thus obtain valid TLS/SSL certificates. Of course, there has been an insurmountable level of effort by major players to add transparency to this process over the years, and thus, 'pulling off' a heist of this scale has its operational hurdles.
值 得 注意 的 是，我們在佔領的情況下能夠策劃的所有上述攻擊，任何能夠執行 MITM 攻擊的實體也都可能進行 - 例如控制或能夠影響轉運骨幹的實體。對於擁有這樣訪問權的攻擊者來說，偽造任何域名的 WHOIS 資料都非常容易，從而獲得有效的 TLS/SSL 證書。當然，隨著時間的推移，主要玩家已經付出了無法逾越的努力來增加此過程的透明度，因此，執行如此規模的盜竊行為有其運作障礙。

At watchTowr, we passionately believe that continuous security testing is the future and that rapid reaction to emerging threats single-handedly prevents inevitable breaches.
在 watchTowr，我們熱情地相信持續的安全測試是未來，並且對新興威脅的快速反應單獨防止不可避免的洩漏。

With the watchTowr Platform, we deliver this capability to our clients every single day - it is our job to understand how emerging threats, vulnerabilities, and TTPs could impact their organizations, with precision.
使用 watchTowr 平台，我們每天都將這項能力提供給我們的客戶 - 我們的職責是精準了解新興威脅、弱點和 TTPs 可能對他們的組織產生的影響。

If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch.
如果您想了解更多關於 watchTowr 平台，我們的攻擊面管理與持續自動化紅隊測試解決方案，請聯繫我們。