Lab Overview
實驗環境下載：https://seedsecuritylabs.org/Labs_16.04/Networking/DNS_Rebinding/
在這個實驗中模擬的物聯網設備是一個恆溫器，用於控制室內溫度。要成功設置溫度，客戶端需要能夠與物聯網服務器交互。由於物聯網設備在防火牆後面，外部機器不能與物聯網設備交互，因此不能控制恆溫器。為了擊敗防火牆保護，攻擊代碼必須首先進入內部網絡。這並不難，當來自內部網絡的用戶訪問攻擊者的網站時，攻擊者的代碼(JavaScript代碼)實際上是從用戶的瀏覽器中運行的，因此在受保護的內部網絡中運行。然而，由於瀏覽器實現的沙箱保護，攻擊者的代碼仍然不能與物聯網設備交互，即使它現在在內部網絡中。
這個實驗的目標是使用DNS重綁定攻擊來繞過沙箱保護，這樣攻擊者的javascript代碼就可以成功地從設備獲得必要的信息，並使用這些信息來獲得溫度測量的一個非常高的值。
本實驗涵蓋以下主題:
• DNS server setup
• DNS rebinding attack
• Attacks on IoT devices
• Same Origin Policy
我們的攻擊目標是防火牆後面的一個物聯網設備。我們不能從外部直接訪問這個物聯網設備。我們的目標是讓內部用戶運行我們的JavaScript代碼，這樣我們就可以使用DNS重新綁定攻擊與物聯網設備交互。
許多物聯網設備都有一個簡單的內置web服務器，因此用戶可以通過web api與這些設備交互。通常，這些物聯網設備由防火牆保護，它們不能從外部直接訪問。由於這種類型的保護，許多物聯網設備沒有實現強大的身份驗證機制。如果攻擊者能夠找到與它們交互的方法，就很容易危及其安全性。
我們使用一個簡單的webserver來模擬這種易受攻擊的物聯網設備，該服務器提供兩個api:密碼和溫度。物聯網設備可以設置室溫。為此，我們需要向服務器的溫度API發送一個HTTP請求;請求應該包括兩部分數據:目標溫度值和密碼。密碼是定期更改的秘密，但可以使用密碼API獲取。因此，要成功設置溫度，用戶首先需要獲得密碼，然後將密碼附加到溫度API中。密碼不是用於身份驗證的;它用於抵抗跨站請求偽造(CSRF)攻擊。沒有這種保護，一個簡單的CSRF攻擊就足夠了;沒有必要使用更複雜的DNS重新綁定攻擊。為了簡單起見，我們硬編碼了密碼;在實際系統中，密碼將定期重新生成。
LabEnvironment
在這個實驗室中，我們將使用三台機器，分別稱為用戶VM、本地DNS服務器和攻擊者VM。為了簡單起見，我們使用VirtualBox中的NAT網絡適配器將這些虛擬機放在同一個網絡上。在現實世界中，它們不在同一個網絡上。我們還假設運行在用戶VM上的設備在防火牆後面，因此攻擊者VM不能直接訪問物聯網設備。這個實驗室的設置相當複雜，因為我們需要配置三個VM並在它們上運行多個服務器，包括一個IoT web服務器(在用戶VM上)、一個web服務器和一個DNS服務器(在攻擊者VM上)以及一個DNS服務器(在本地DNS服務器上)
LabTasks
Task1: Configure the User VM
Step1. 減少Firefox的DNS緩存時間。為了減少DNS服務器的負載並加快響應時間，Firefox瀏覽器緩存DNS結果。默認情況下，緩存的過期時間為60秒。這意味着我們的DNS重新綁定攻擊需要等待至少60秒。為了讓我們的實驗更輕鬆，我們把時間減少到10秒或更少。在URL字段中輸入about:config。單擊警告頁面后，我們將看到首選項名稱及其值的列表。搜索dnsCache，找到以下條目並將其值更改為10:
更改后，應該退出Firefox瀏覽器，並重新啟動;否則，更改將不會生效。
Step 2. 改變/etc/hosts.我們需要將以下條目添加到/etc/hosts文件中。我們將使用www.seedIoT32.com作為物聯網web服務器的名稱。此服務器可以運行在不同的VM上，但為了簡單起見，我們在用戶VM上運行物聯網服務器(其IP地址為192.168.43.175):
Step3. Local DNS Server 。我們需要配置用戶VM以使用特定的本地DNS服務器。這是通過將本地DNS服務器設置為解析器配置文件(/etc/resolv.conf)中的第一個名稱服務器條目來實現的。一個挑戰是所提供的VM使用動態主機配置協議(DHCP)來獲取網絡配置參數，如IP地址、本地DNS服務器等。DHCP客戶機將用DHCP服務器提供的信息覆蓋/etc/resolv.conf文件。
要將信息導入/etc/resolv.conf而不用擔心DHCP，一種方法是將以下條目添加到/etc/resolvconf/resolv.conf.d/head文件(192.168.43.78為本地DNS服務器的IP地址):
頭文件的內容將預先寫入動態生成的解析器配置文件。通常，這隻是一個註釋行(/etc/resolv.conf中的註釋來自這個頭文件)。在進行更改之後，我們需要運行以下命令使更改生效:
Step 4. Testing 。配置用戶VM之後，使用dig命令從您選擇的主機名獲取IP地址。從這個響應中，請提供證據證明這個響應確實來自你們的服務器。如果找不到證據，說明配置不成功。
Task2: Start the IoT server on the User VM
在此任務中，我們將在用戶VM上啟動物聯網服務器。通過web服務器，用戶可以與物聯網設備通信。
Step 1. 安裝 Flask. 我們使用Flask web框架來開發物聯網服務器 sudo pip3 install Flask==1.1.1
Step 2. Start the IoT server. 物聯網服務器代碼包含在user_vm.zip，可以從實驗室的網站上下載。解壓縮文件后，進入user_vmf文件夾，通過運行準備好的腳本start IoT .sh或直接運行“flask run”啟動物聯網服務器。需要注意的是，我們使用端口8080作為物聯網服務器(該端口號在實驗室設置中是硬編碼的;將其更改為不同的数字將破壞實驗室設置)。
Step 3. Testing the IoT server 。要測試物聯網服務器，請將瀏覽器指向用戶VM上的以下URL。如果一切都設置正確，我們應該能夠看到一個恆溫器。我們也可以通過拖動滑動條來改變溫度設置。
Task3: Start the attack web server on the Attacker VM
在本實驗室中，只能從防火牆后訪問物聯網設備，即，僅來自實驗設置中的用戶VM。將惡意代碼發送到用戶虛擬機上的一種典型方式是讓用戶訪問我們的網站，這樣放置在web頁面上的JavaScript代碼就可以進入用戶虛擬機上。在這個任務中，我們將啟動一個web服務器來託管這些web頁面。
Step 1. 安裝 Flask。 我們的惡意web服務器也是基於Flask web框架開發的。
Step 2. Start the attacker’s web server 。攻擊者的服務器代碼包含在attacker_vm.zip，可以從實驗室的網站上下載。解壓縮文件后，進入attacker_vm文件夾，通過運行準備好的腳本start_webserver.sh或直接運行“flask run”來啟動web服務器。
Step3. Testing the Attacker’s web server.
Task4: Configure the DNS server on the Attacker VM
攻擊者VM也充當了attacker32.com域名的命名服務器。BIND9服務器已經在攻擊者VM上運行，我們需要為它準備一個區域文件。一個示例區域文件包含在attackr_vm文件夾中。我們應該相應地更改區域文件，並將其複製到/etc/bind文件夾中。
將以下區域條目添加到/etc/bind/name .因此上面的區域文件將由BIND9服務器使用。
如果一切都設置正確，我們可以嘗試以下dig命令，看看我們得到的響應是否與我們放在區域文件中的響應相同
Task5: Configure the Local DNS Server
在本地DNSserver上，我們設置attacker32.com域的轉發記錄，因此每當本地 DNS 服務器收到此域內主機的 DNS 查詢時，它只需將 DNS 查詢發送到指定轉發記錄的 IPaddress，而不是前往 root server 和the .com server，以找出attacker32.com域的名稱服務器的位置。
要將此類記錄添加到本地 DNS 服務器，我們需要將以下行添加到 /etc/bind/named.conf
在用戶機上測試，dig成功：
Task6. Understanding the Same-Origin Policy Protection
同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能。瀏覽器的同源策略，限制了來自不同源的“document”或腳本，對當前“document”讀取或設置某些屬性。影響“源”的因素有：host（域名或IP地址，如果是IP地址則看做是一個根域名）、子域名、端口、協議。在瀏覽器中，<script>、<img>、<iframe>、<link>等標籤都可以跨域加載資源，而不受同源策略的限制，但是瀏覽器限制了JavaScript的權限，使其不能讀、寫返回的內容。
attacker_vm的change界面
單擊click之後，user_vm的溫度並不會改變
user_vm的change界面
單擊click之後，user_vm的溫度變為99℃
Task7. Defeat the Same-Origin Policy Protection
擊敗同源的主要想法保護來自這樣一個事實:策略執行基於主機名,而不是IP地址,所以只要我們使用www.attacker32.com的URL,我們遵守SOP的政策,但這並不意味着我們是限制與www.attacker32.com web服務器進行通信。
在用戶的瀏覽器向www.attacker32.com發送請求之前，它首先需要知道www.attacker32.com的IP地址。一個DNS請求將從用戶的機器發出。如果IP地址沒有緩存在本地DNS服務器上，一個DNS請求最終會被發送到attacker32.com的nameserver，它運行在攻擊者的VM上。因此，攻擊者可以決定在響應中放入什麼。
Step 1: Modify the JavaScript code. 在攻擊者虛擬機中，在www.attacker32.com:8080/change中運行的JavaScript代碼存儲在以下文件中:attacker_vm/rebind_malware/templates/js/change.js。由於該頁面來自www.attacker32.com服務器，根據同源策略，只能與同一服務器交互。因此，我們需要將代碼的第一行從http://www.seediot32.com:8080更改為以下內容:
Step2: Conduct the DNS rebinding 。我們的JavaScript代碼發送請求到www.attacker32.com，請求將返回到攻擊者VM。這不是我們想要的，我們希望將請求發送到iot服務器。這可以通過DNS重新綁定技術實現。我們首先映射 www. attacker32.com 為攻擊者VM的IP地址，這樣用戶可以從http: //www.attacker32.com/change獲得實際頁面。在我們點擊網頁上的按鈕之前，我們重新映射www.attacker32.com主機名到iot服務器的IP地址，按鈕觸發的請求將到達iot服務器。這正是我們想要的。
修改好相應文件進行刷新：
同源策略是瀏覽器的一個安全功能，不同源的客戶端腳本在沒有明確授權的情況下，不能讀寫對方資源。所以xyz.com下的js腳本採用ajax讀取abc.com裏面的文件數據是會被拒絕的。同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。不受同源策略限制的1. 頁面中的鏈接，重定向以及表單提交是不會受到同源策略限制的。2. 跨域資源的引入是可以的。但是js不能讀寫加載的內容。如嵌入到頁面中的<script src=”…”></script>，<img>，<link>，<iframe>等
Task8. Launch the Attack
使用用戶機訪問下列url：
每當10秒倒計時為0，溫度將會被設定為88度：
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※南投搬家公司費用需注意的眉眉角角，別等搬了再說!
※教你寫出一流的銷售文案?