甲骨文公司對導致Oracle TNS Listener毒藥攻擊的零日漏洞處理方式，讓很多管理員感到困惑，他們不知道該對數據庫采取什么安全措施。在本文中，我們將研究TNS Listener漏洞的運作原理，分析Oracle的回應以及企業是否應該調整其網絡防御系統以更好地保護其數據庫。

TNS Listener漏洞

這個特殊的漏洞很容易被利用，并允許攻擊者執行中間人攻擊以獲取對數據庫服務器的完全控制：它的嚴重程度取決于對它的攻擊深度。該漏洞暴露了TNS Listener服務，此服務將來自客戶端的連接請求路由到所有版本的Oracle數據庫的服務器中。安全研究人員Joxean Loret在2008年發現了這個漏洞，并向Oracle報告了此漏洞。四年后，他發布了該漏洞的細節信息，因為他以為Oracle已經解決了這個問題。

然而，Oracle最近才針對漏洞CVE-2012-1675發布了一個帶外安全警告。并且，這只是一個解決方法，而不是一個補丁，它提供了保護TNS Listener和抵御利用該漏洞發起的攻擊的指導信息。2012年4月Oracle關鍵補丁更新也沒有包含針對該漏洞的補丁。Oracle對于發布解決方案而不是補丁，給出了以下原因：

這個補丁很復雜，這將嚴重影響“向后移植（backport）”或傳統安裝。

這個補丁是存在回歸問題的代碼的關鍵部分。

客戶要求Oracle不要涵蓋安全補丁，因為該補丁將會增加回歸到CPU的機會，而這可能危及數據庫的穩定性。

Oracle TNS Listener毒藥攻擊漏洞可能多年來都存在于所有版本的Oracle數據庫平臺中，但這個漏洞只有在下一個主要版本推出時才可能會被修復。在那之前，管理員必須采用Oracle提供的解決方法，沒有使用該解決方法的Oracle客戶很容易受到遠程未授權攻擊者的攻擊。

如果在這個解決方法發布之前可能已經發生了攻擊呢？不幸的事實是，惡意攻擊者也許已經獨立地發現這個Oracle TNS Listener毒藥攻擊漏洞，并可能多年來都利用它來攻擊企業數據庫，而管理員可能從來都沒有發現。

在過去，企業將不得不進行取證調查以及分析歸檔日志文件，看看是否可以檢測到異常命令或者網絡流量來證明有人成功利用了這個漏洞。原漏洞通知時間和Oracle采取的并非完全令人信服的行動時間這么久，也讓一些安全專家質疑Oracle還知道哪些其他漏洞而選擇不修復。

這種情況也闡明了為什么計算機安全專家在美國參議院軍事委員會新興威脅和功能小組委員會，告訴成員要假設美國軍方計算機網絡已經被滲透的原因，基于這個前提，安全工作應更專注于保護敏感數據，而不是控制訪問權限。這些意見不是這個漏洞的結果，而是基于大型企業發生的數據泄露事故數量，它們的系統已經被感染幾個月甚至幾年。

使用網絡外圍作為數據庫防御

盡管如此，管理員仍然不應該放棄其外圍防御。相反地，在這些防御的基礎上，還應該采用謹慎的網絡分段，并為數據庫連接強制使用SSL和傳輸層安全加密。預防永遠好過補救，穩妥的企業安全團隊應該假定：在網絡某處存在被感染的系統，惡意軟件正試圖通過該系統收集和滲出重要數據到遠程命令控制中心。

為了反映這一現實，安全團隊必須重新調整其優先次序、資源和時間。他們應該確保分配足夠的時間和技術（例如數據丟失防護）來尋找可疑內部流量，并在當出現不符合安全政策的請求時，防止數據離開網絡。

開源工具Hone可用于追蹤企業內可疑惡意活動的來源。Hone由美國能源部下屬太平洋西北國家實驗室發布，它是一個網絡活動可視化工具，通過跟蹤流量到產生流量的應用，Hone能夠幫助網絡經理更好地識別和理解攻擊，并幫助管理員更快地識別感染來源。

隨著軟件代碼變得越來越復雜，供應商不能快速提供漏洞補丁的請擴將會越來越多。Oracle對TNS Listener毒藥攻擊的處理方式充分說明：在供應商發布下一個修復補丁之前，企業不能坐以待斃。基于這個前提，企業必須重新調整安全防御措施，監控和控制傳入和傳出流量，以彌補關鍵業務企業應用的不足。