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度：
