給一個廠商測試時 burp 發現了在 Host 點上的 External service interaction (DNS) 外部服務交互 漏洞，廠商使用的是 Akamai 的 CDN 服務，跳板請求的 IP 歸屬也是 Akamai。
和 Akamai 郵件溝通後，瞭解到這是他們充分考慮後的故意設計，所以對他們來說不算漏洞。但雖然他們規避了大部分威脅，這個漏洞也確實仍然存在跳板訪問的問題，暫且記錄在此吧。Akamai 沒有漏洞賞金計劃。
Akamai 給我的回覆，說明了他們的考量：
Akamai edge servers indeed perform DNS resolution on the Host headers they process. This is a well-understood, thoroughly reviewed, and entirely intentional behavior of our platform. Akamai relies on this behavior to support some of its routing and mapping mechanisms; we do not store an internal, fixed hostname-to-origin server mapping. The DNS resolution we perform is just a typical query against any publicly exposed DNS server.
Here are common concerns with such DNS queries in the context of potential external interaction or SSRF vulnerabilities, and why those do not apply to Akamai.
-
An attacker may use DNS resolution artifacts to leak information about internal backend networks.
Akamai’s case: There is no backend network to speak of in our architecture, meaning that there is no internal resources to resolve, or leak information about, via SSRF. The IP address observed in the DNS server logs corresponds to one of our publicly exposed reverse proxies.
-
An attacker may utilize this to redirect HTTP traffic to vulnerable internal services instead of its intended destination.
Akamai’s case: Similarly to the above, there is no backend network that exposes web services, and no internal/proprietary HTTP interaction that follows the name resolution.
-
An attacker may utilize the impacted resolver as an amplification factor and launch DNS-based DoS attacks.
Akamai’s case: Akamai edge servers perform a single, properly-crafted DNS query against a publicly exposed DNS server. There is no DNS amplification involved.