3. IoT 網路應用系統安全弱點

🦉OWASP Top 10 簡介

#

OWASP (Open Web Application Security Project) 是一個開放的社群非營利組織，致力於研究網際網路應用程式安全的標準、工具和技術，協助政府和企業理解並改善應用程式的安全性。

OWASP 最著名的是一份針對網路應用程式安全性的排名 - OWASP Top 10。它列出了目前最常見的十個網路應用程式安全風險，提供給開發人員、測試人員和資安人員作為指南以確保應用程式的安全防護。OWASP Top 10 大約每三年更新一次，以確保此份情資能夠跟上時代腳步。本課程將使用 OWASP Top 10 2021 來幫助學員了解弱點產生以及弱點防禦。

在 OWASP 中有許多領域的安全威脅排名，而最著名的排名是 OWASP Top 10。此排名中包含了各種由於管理疏忽或者是開發錯誤從而產生的弱點。OWASP IoT Top 10 則是在描述 IoT 設備常見的安全弱點。OWASP 也有針對 API、行動裝置、AI 等領域列出前十大資安威脅弱點。

以下是目前的 OWASP Top 10：

🦉A01 權限控制失效

#

權限控制失效 (Broken Access Control) 弱點發生的原因是由於使用者能夠訪問到本不應該訪問到的頁面或是功能，從而導致資訊洩漏或是越權控制的風險。此弱點發生的情況通常是當使用者訪問了一個需要身份驗證才能存取的頁面時，開發者沒有加入對使用者進行身份驗證的程式碼，從而導致使用者不需要經過身份驗證也能對其進行訪問與控制。

發生該弱點的程式碼通常具有以下幾點特徵：

• 沒有對 HTTP Request 進行身份驗證
• 沒有對敏感目錄進行權限控管
• 沒有對使用者的 session 進行驗證

請參考以下範例，以下為沒有完整驗證使用者身份的 php 程式碼：

// verify.php
<?php
session_start()

$secret_text = "secret_text";

if ($_SERVER["REQUEST_METHOD"] == "POST") {
    $user_input = $_POST["secret"];
    if ($user_input === $secret_text) {
        $_SESSION["authenticated"] = true;
        header("Location: admin.php");
        exit();
    } else {
        echo "Your input does not match the secret text.";
    }
}
?>

// admin.php
<?php
echo 'Welcome, administrator!';
?>

觀察 if() 部分的程式碼，跳轉至 admin.php 頁面的條件式為 $user_input === $secret_text，乍看之下進入該頁面的條件唯有 admin 能夠達成，但如果我們沒有在 admin.php 頁面驗證使用者的 session 是否有效，攻擊者能夠透過直接訪問 admin.php 從而導致權限控制失效的問題。

請參考以下範例，以下是修補過後有驗證使用者身份的 php 程式碼：

// admin.php
<?php
session_start();

if (!isset($_SESSION['is_admin']) || $_SESSION['is_admin'] === false) {
    header("Location: login.php");
    exit();
}

// 如果通過了上面的檢查，那麼使用者就可以訪問這個頁面的內容
echo 'Welcome, administrator!';
?>

在剛剛範例中的 admin.php 沒有對使用者進行身份驗證從而導致權限控制失效的問題。為了解決這個問題，可以在 admin.php 中加入對使用者進行身份驗證的程式碼，讓沒有經過身份驗證的使用者或是並非 admin 的使用者重新導向回登入頁面。

請參考以下範例，以下是一個不安全的 nginx 設定範例：

server {
    listen 80;
    server_name example.com;

    location /admin/ {
        root /var/www/html/admin/;
        index index.html;
    }

    location / {
        root /var/www/html/;
        index index.html;
    }
}

觀察 /admin/ 部分的設定，可以發現該目錄並沒有進行權限控管，導致任意使用者都能訪問在 /admin/ 路徑下的 index.html 以及其他檔案，可能導致敏感資訊的洩漏或未經授權的系統操作，造成權限控制失效的問題。

請參考以下範例，以下是修補過後經過存取控制的 nginx 設定範例：

server {
    listen 80;
    server_name example.com;

    location /admin/ {
        root /var/www/html/admin/;
        index index.html;

        # 基於 IP 位置的存取限制
        allow 192.168.0.0/24;
        deny all;
    }

    location / {
        root /var/www/html/;
        index index.html;
    }
}

觀察 /admin/ 部分的設定，可以發現我們新增了兩行設定，限制 /admin/ 路徑僅能從 192.168.0.0/24 網段才可被訪問。當然，也能使用身份驗證機制來確保只有授權的使用者可以訪問 /admin/。

以上兩個範例展示了權限控制失效問題產生的原因與防禦方式，要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 在每個 Request 中都對使用者進行身份驗證
• 對敏感目錄進行權限控管
• 對使用者的 session 進行限制

🦉A02 加密機制失效

#

加密機制失效 (Cryptographic Failures) 弱點發生的原因主要是由於開發者使用不適當的方式保護使用者的敏感資訊，從而導致攻擊者能竊取到敏感資訊。例如：登入憑證、身分證字號、信用卡號等。

發生該弱點的程式碼通常會具有以下幾點特徵：

• 敏感資訊以明碼傳輸，例如：HTTP、SMTP、FTP 等協定
• 使用老舊或已知存在安全風險的加密演算法，例如：DES
• 使用預設的 Encrypt Key 或是弱密碼
• 沒有將敏感資訊加密儲存

請參考以下範例，以下是一個使用 HTTP 傳輸的封包被攔截的範例，受害者使用了 HTTP 協定來傳輸敏感資料，使得攻擊者能夠完整的讀取受害者傳輸的封包內容。

請參考以下範例，以下是一個使用 HTTPS 傳輸的封包被攔截的範例，相對於 HTTP 協定，可以發現受害者的封包經過加密後，攻擊者無法得知傳輸的封包內容。

請參考以下範例，以下是一個儲存使用者資料的 SQL table ，但儲存時沒有將密碼使用 Hash 儲存而是使用明文儲存。若攻擊者成功進入系統或是訪問資料庫將造成帳號資料外洩的風險，攻擊者將能輕易獲取明文密碼。

以上兩個範例展示了加密機制失效問題產生的原因與防禦方式，要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 除非必要，否則不向使用者索取敏感資訊
• 使用安全的加密演算法來加密儲存資訊
• 使用 Hash 來保護使用者的密碼
• 使用加密協定，例如：HTTPS

🦉A03 注入式攻擊

#

注入式攻擊 (Injection) 是一種常見的漏洞，允許攻擊者將惡意輸入注入到程式碼或指令中，使其成為程式碼或指令的一部分。這種攻擊通常是因為在接收輸入資料時未對輸入進行適當的驗證和過濾而導致。

常見的注入攻擊有以下幾種：

• 指令注入攻擊 (Command Injection，Cmdi)：
  • 攻擊者利用漏洞將惡意指令注入到指令拼接間，使其在目標系統上執行預期外的指令。可能導致攻擊者透過遠端程式碼執行取得 Shell。
• SQL 語句注入攻擊 (SQL Injection，SQLi)：
  • 攻擊者將惡意 SQL 語句注入到應用程式的原始 SQL 語句中以控制查詢語句。可能導致資料庫洩漏、任意讀取檔案、透過遠端程式碼執行取得 Shell。
• 跨網站指令碼注入攻擊 (Cross-Site Scripting，XSS)：
  • 攻擊者在網頁中注入惡意 JavaScript 腳本，控制瀏覽器執行危險程式碼。可能導致資訊洩漏、偽造用戶、透過遠端程式碼執行取得 Shell。
• 伺服器模板注入攻擊 (Server-Side Template Injection ，SSTi)：
  • 攻擊者將惡意的模板引擎程式碼注入到模板內，控制伺服器端模板引擎。可能導致任意讀取檔案、透過遠端程式碼執行取得 Shell。

請參考以下範例，以下是一個 Command Injection 的 PHP 程式碼範例：

<?php system("ping  -c 4 " + $IP);?>

假設使用者的輸入不經過任何驗證完整地傳入變數 $IP。在正常情況下，輸入如果為 127.0.0.1，程式會將使用者的輸入完整放入指令中，如下所示：

ping -c 4 127.0.0.1

如果該指令正常運作，將會產生以下輸出：

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1： icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from 127.0.0.1： icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from 127.0.0.1： icmp_seq=3 ttl=64 time=0.036 ms
64 bytes from 127.0.0.1： icmp_seq=4 ttl=64 time=0.031 ms

--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3061ms
rtt min/avg/max/mdev = 0.029/0.033/0.038/0.003 ms

在 Linux 中，分號 ; 代表結束當前指令，並且執行後續指令。因此，如果在輸入中加入分號，將使得單行輸入可以執行兩個及以上的指令。如果攻擊者輸入 127.0.0.1 ; id，此時指令將變成：

ping -c 4 127.0.0.1 ; id

如果該指令正常運作，將會產生以下輸出：

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1： icmp_seq=1 ttl=64 time=0.029 ms
64 bytes from 127.0.0.1： icmp_seq=2 ttl=64 time=0.032 ms
64 bytes from 127.0.0.1： icmp_seq=3 ttl=64 time=0.034 ms
64 bytes from 127.0.0.1： icmp_seq=4 ttl=64 time=0.038 ms

--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3069ms
rtt min/avg/max/mdev = 0.029/0.033/0.038/0.003 ms
uid=33(www-data) gid=33(www-data) groups=33(www-data)

在輸出的最後一行，可以看到 id 指令被成功執行。同時也代表攻擊者可以在此處執行任意命令，達到遠端執行任意程式碼 (Remote Code Execution，RCE) 的目的。

由於 Injection 攻擊通常能讓攻擊者取得 RCE，因此此類攻擊通常會是攻擊者優先瞄準的目標。要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 過濾使用者輸入的特殊符號
• 將實際運作的指令與使用者的輸入分離
• 對使用者的輸入進行二次驗證

🦉A04 不安全設計

#

不安全設計 (Insecure Design) 是一種定義廣泛的概述，涵蓋了在設計階段未能充分考慮並解決的安全問題。這類問題可能源於多種原因，例如：未妥善處理使用者的輸入輸出、未正確實施安全措施、無效的身份驗證等。儘管不安全設計的概念有點抽象，但我們可以藉由觀察幾個範例來了解不安全的設計包含的情況。

1. 密碼重置問題： 在使用者忘記密碼時，有些網站會藉由讓使用者回答【你所就讀的小學】或【你父母的名字】這類問題來重置密碼。這種情況下，攻擊者可能可以透過在社交媒體、網路搜索等公開資源來獲得答案，使得這種恢復密碼的方式具有風險。在社群媒體上常常會有人將自己的資料公開，我們可以利用此特點來嘗試找到這些題目的解答，或者是使用社交工程來嘗試套出目標的資訊等。

2. 爆破攻擊與洪水式攻擊： 若未設置有效防止機器人的保護機制，可能會導致惡意攻擊者用自動化工具對網站進行攻擊。攻擊者可以透過不斷嘗試不同的用戶名和密碼組合，直到找到正確的組合或猜中密碼，稱為爆破攻擊 (Brute Force Attack)。攻擊者也能透過向目標系統發送大量的流量或請求，以超出其處理能力限制，使得真正的使用者無法正常使用系統，稱為洪水式攻擊 (Flood Attack)。

請參考以下範例，以下範例是一個洪水式攻擊的例子，攻擊者透過發送大量的 HTTP Requests 來連接至目標，並嘗試消耗其處理能量來導致伺服器癱瘓的問題。

請參考以下範例，以下範例是暴力破解的例子，當網站沒有限制 IP 對其登入或者任意路徑進行大量請求時，攻擊者可以利用此點來進行掃描路徑、暴力破解等攻擊行為。

為了防禦不安全設計的弱點，我們需要在設計階段就將安全因素納入考量，並將其視為設計目標的重要部分。在開發過程中我們可以採用安全軟體開發生命週期 (Secure Software Development Life Cycle，SSDLC) 的模型，嚴格遵守相關原則，以大幅降低弱點出現的可能性。回顧剛剛提到會發生弱點的地方，我們能夠從開發階段提出幾個解決辦法。

1. 密碼重置問題：
   • 由於用於密碼重置的問題答案通常不只有使用者一個人知道，攻擊者能利用公開來源情報 (Open Source INTelligence，OSINT) 來獲得答案，因此此類設計應該被移除或是使用更安全的設計，例如：雙重認證 (Two-factor authentication，2FA) 等機制來替代。
2. 爆破攻擊與洪水式攻擊：
   • 由於爆破攻擊與洪水式攻擊會產生大量異常的流量，因此我們可以透過流量過濾的方式來檢測和過濾異常的流量。此外，也能使用人機驗證 (Captcha) 來檢測使用者是否為自動化腳本。

🦉A05 安全設定缺陷

#

安全設定缺陷 (Security Misconfiguration) 弱點產生的原因主要是因為正在運行的系統、軟體，由於安全設定的不正確，從而導致暴露了過多的資訊以及攻擊面。舉例來說，如果我們對於一個 IoT 設備服務只需要提供網頁介面，那麼對於使用者端要開放的也僅有網頁的服務，而不應該額外開放如：SSH、FTP 等服務。

該弱點通常具有以下幾點特徵：

• 啟用不必要的功能
• 使用預設的密碼或是登入憑證
• 程式執行未正確判斷例外，導致錯誤訊息透漏服務背後的技術與版本
• 系統設定導致可能存在安全風險的功能被開啟

請參考以下範例，以下是一個開啟不必要服務的範例，在這台設備上可以看出目標的定位應是提供使用者網頁服務，但卻開啟了 MySQL 的 3306 埠，MySQL 是一個並不需要對外的服務，會讓設備增加可能會被駭客入侵的攻擊面。若想維持系統正常運作並同時減少攻擊面，可以將 8080 埠改為 80 埠並設定連線規則只允許 80 埠對外。若有遠端管理需求，可以將 SSH 對外同時設定 /etc/ssh/sshd_config 只允許從內網進行連線，便能在服務穩定運作的同時減少攻擊面。

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 關閉非必要的埠、服務、網頁頁面和帳號特權等
• 修改預設密碼，並遵循密碼複雜度原則
• 關閉錯誤訊息以防止針對性的攻擊

🦉A06 危險或過舊的元件

#

使用危險或過舊的元件 (Vulnerable and Outdated Components) 弱點產生的原因是由於開發時使用了具有漏洞的元件進行開發。攻擊者往往會尋找並利用已知的漏洞來對這些老舊的服務進行攻擊。這樣的攻擊手法範疇廣泛，可以針對的目標從作業系統、網頁伺服器、到具體的軟體套件或插件。

許多過時或有已知漏洞的軟體和服務常用於 IoT 設備上，例如：vsftpd 2.3.4 存在不須經過身分驗證的 RCE 漏洞。同樣地，Dropbear SSH 0.34 也存在 RCE 漏洞。下圖是 vsftpd 2.3.4 的 CVE 編號，其 CVSS 分數高達 10.0 分。

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 以自動化的方式檢查系統是否存在已知的安全漏洞
• 更新以確保系統元件或服務保持在最新的版本
• 更新套件時，從軟體開發者的官方網站下載

🦉A07 認證及驗證機制失效

#

認證及驗證機制失效 (Identification and Authentication Failures) 弱點產生的原因是沒有正確對驗證機制所需的資訊做處理。它可能讓未經授權的人獲得進入系統的權限，並取得敏感資訊。該弱點出現的主要原因主要是由於程式或是網站在驗證使用者時存在缺陷，從而導致攻擊者能夠偽裝其他使用者來取得其他使用者的控制權限。

該弱點通常具有以下幾點特徵：

• 沒有針對暴力破解或其他自動化攻擊的防護措施
• 使用預設密碼
• 允許使用者使用弱密碼
• 沒有正確的刪除 session

請參考以下範例，登入頁面設定了使用者的 session，但是在登出時，使用者的 session 並沒有被刪除，若攻擊者在使用者登出後取得使用者曾經使用過的 session，那麼該 session 依然有效的情況下就能訪問到該使用者所擁有的權限。

<?php
session_start();
session_unset();

header('Location: login.php');
exit();
?>

請參考以下範例，僅需記得將 session 正確銷毀，避免攻擊者使用了使用者之前使用過的 session 訪問需經過身分驗證的頁面。

<?php
session_start();
session_unset();
session_destroy();

header('Location: login.php');
exit();
?>

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 使用隨機生成密碼作為初始密碼
• 增加登入限制，如登入次數、IP 等
• 在登出後刪除使用者的 session
• 使用最小特權原則開發

最小特權原則 (PoLP) 是開發上一個非常重要的觀念，意味著每個使用者或系統應該只有完成其任務所必需的權限。遵循該原則開發的系統，可以降低認證或驗證機制失敗的風險，減少攻擊者可能取得的權限。

🦉A08 軟體及資料完整性失效

#

軟體及資料完整性失效 (Software and Data Integrity Failures) 產生的原因是軟體被未經授權的第三方改動造成軟體及資料完整性受到損害，從而導致軟體本身自帶後門或是惡意程式碼等問題。此弱點的判定方式主要可以根據資安核心三要素 (CIA) 的完整性 (Integrity) 來判斷是否產生。

CIA 是機密性 (Confidentiality)、完整性 (Integrity)、可用性 (Availability) 的首字母縮寫，是評估資安策略的三個基本要素。完整性，指的是保護資訊和系統免受未經授權或不正確的修改。對於資訊，完整性確保了資訊的正確性以及來源可信。對於系統，完整性確保了系統如預期運行，並且沒有被未經授權的攻擊者惡意修改。

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦。

• 使用數位簽章或 Hash 檢查套件或軟體的完整性

🦉A09 資安記錄及監控失效

#

資安記錄及監控失效 (Security Logging and Monitoring Failures) 弱點發生的原因是由於資安監控失效所引起的。資安監控有助於及時發現和應對安全威脅。從勒索病毒到釣魚攻擊，從 DDoS 到資訊洩漏，都對 IoT 設備的整體安全構成威脅。因此，有效的資訊安全監控策略是防範這些威脅的重要工具。

入侵檢測系統和入侵防護系統是資訊安全監控中的重要元素，入侵檢測系統 (Intrusion Detection System，IDS) 是一種實體設備或是軟體，用於監控網路或系統的活動以檢測可能的惡意行為。IDS 可以基於網路 (NIDS)，也可以基於主機 (HIDS)。當 IDS 檢測到可疑活動時，便會生成資安事件告警並通知 SOC 人員。入侵防護系統 (Intrusion Prevention System, IPS) 不僅可以檢測到攻擊者的入侵行為，還能阻止其發生。IPS 可以識別對系統發出的潛在的惡意流量，並攔截並阻止。

以下是兩個資安記錄及監控失效從而導致資安事件產生的現實案例。

1. 某間醫院由於缺乏監控和紀錄因此無法偵測入侵威脅，導致攻擊者入侵時無法正確的監控和防禦事件發生，並且在恢復階段時由於沒有日誌參考，因此也無法得知系統的弱點。
2. 某間購物商場由於缺乏監控和紀錄設備，因此攻擊者在入侵後潛伏了數年之久，並且於發現入侵後因缺乏日誌參考，因此也無法追蹤攻擊者。

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦：

• 確保日誌記錄重要事件
• 確保日誌格式符合能輕易讀懂、且格式化的形式
• 確保日誌不會受到污染攻擊
• 安裝 IDS / IPS 等安全防護系統已保證資安監控完善

🦉A10 伺服端請求偽造

#

伺服器端請求偽造 (Server Side Request Forgery，SSRF) 弱點發生的原因是當目標系統發起的請求被攻擊者控制。由於發起請求者是目標伺服器，因此可以訪問到攻擊者原本無法訪問的檔案，例如：僅限於本地的服務、內網資訊等。要深入研究 SSRF，我們可以先研究 URL。

以下是一個 URL 的範例：

http://localhost:8787/meow.php?id=1

我們可以將 URL 的結構拆解並分析：

{attack surface}://{domain}:{port}/{path}?{parameter}={value}

{attack surface} 決定可以掌握到的 SSRF 攻擊面。

{domain} 決定攻擊的影響的範圍。

此漏洞發生的位置通常是在使用者能夠輸入網址的位置，在後端處理時通常會將使用者所輸入的網址解析成發送位置，就是攻擊者可以影響到的區域。而 SSRF 能夠讓攻擊者取得僅能從內網訪問的資源或者是本地任意檔案等，我們將在此介紹三個不同協定的攻擊面可造成的影響以及其範圍。

在 http:// 的攻擊面上，能夠嘗試訪問可能存在於本地的 HTTP 服務。例如：localhost 的 8080 埠或 8443 埠都是有可能未公開於外網的埠，若能妥善運用，便能直接取得內網的立足點。在 file:// 的攻擊面上，攻擊者能夠讀取本地存在的任意檔案，通常會被利用來讀取本地配置檔 (如 /etc/passwd) 或是網站的原始碼，從而導致資料洩漏的風險。而 gopher:// 的攻擊面上，可以利用構造任意封包的特性來構造任意封包，攻擊者可以利用 gopher 的特性來構造 HTTP 協定的 POST 封包，或是構造成其他服務接收的任何封包，因此攻擊者可能利用此技術獲取內網資訊或者達到 RCE。

要防禦此弱點，我們可以檢查是否已經針對以下項目做好防禦：

• 設定 Domain 白名單
• 預設協定，不讓攻擊者指定