Akamai Diversity
Home > Akamai Japan > 『モノ』が攻撃を始めるとき【Part1】

『モノ』が攻撃を始めるとき【Part1】

 Akamaiの研究チームは、「IoT(モノのインターネット)」デバイスを悪用した攻撃の増大についてモニタリングを行っています。これらの攻撃は、乗っ取られた様々な種類のデバイスから行われます。Akamaiは、お客様とユーザー様をこれらの攻撃から守るために日夜取り組んでいます。

その他の(汎用的なコンピュータなどの)IoTタイプではないデバイスの場合、デバイスの所有者はシステムをパッチで修正するか再設定するなどを行って、脆弱性をなくすことができます。対して IoT の所有者は ボットネットのメンバーリストから自分のデバイスを取り除く手段が、ベンダーのアップデートだけが頼りであることが少なくありません。場合によってはIoTデバイスのパッチ修正が自体ができず、デバイスを取り除く以外に手段がないこともあります。

このシリーズ記事では、Akamaiの脅威リサーチ(Threat Research)チームとセキュリティ・インテリジェンス・レスポンス(Security Intelligence Response)チームがこれらの課題についての認識を高めるための情報を提供し、IoTデバイスにとってのインターネットの安全性を高めるためにデバイスの所有者とベンダーが行えるアクションについてのご提案をします。

※ この記事は、Akamai Technologies InfoSec DirectorであるEric Kobrinの記事の翻訳を元にしています。

Part1:  Proxy

 攻撃の中には、悪意あるユーザーが攻撃用ソフトウェアをIoTデバイスにインストールしてそれらを使って直接攻撃を行うものがあります。SSHowDowN Proxy攻撃は、IoTデバイスを使って、リモートからProxy 攻撃トラフィックを生成するものです。これには、OpenSSHに12年前から存在する脆弱性を利用します。

この攻撃に関する詳細分析については、https://www.akamai.com/us/en/our-thinking/threat-advisories/で、SSHowDowN Proxy攻撃の詳細をご覧ください。

デバイスの種類

AkamaiがSSHowDowN Proxy攻撃を観測したデバイスの種類は、以下の通りですが、他のデバイスでも同様の脆弱性が存在すると考えられます。

  • CCTV、NVR、DVR デバイス(監視ビデオカメラ)
  • 衛星アンテナ機器
  • ネットワーク用デバイス(例: ルーター、ホットスポット、WiMAX、ケーブルモデム、ADSLモデム、など)
  • インターネットに接続されたNASデバイス

 

エンドユーザーへのガイダンス

 デバイス上のSSHパスワードやキーの設定にアクセスができる場合は、ベンダーデフォルト値から異なるパスワードやキーに変更してください。ただし、ここで注意したいのは、現時点で比較的多数の IoT 機器においてこの変更が適用出来ない点です。

 もしご自分のデバイスでSSHサービスの設定にアクセスできる場合は、以下の手順のうち1つまたは両方を行ってください。

  1. 「 AllowTcpForwarding No 」と「X11Forwarding No 」を、 sshd 設定ファイルに追加します。これらは通常、 /etc/sshd_config または、/etc/ssh/sshd_config で見つけることが出来ます。
  2. 全てのユーザー向けに、「 no-port-forwarding  」と「no-X11-forwarding 」を、 「 ~/.ssh/authorized_ keys 」ファイルに追加します。

 もし上記のどちらも行うことが出来ない場合は、お持ちのデバイスの管理者用コンソールから、SSH 全体を無効にしてください。SSHが必要なタスクの間は再度有効化することが出来ます。ただし、そのタスクが完了後は再び必ず無効にしてください。

もしデバイスがファイアウォールの背後にある場合、以下のうちの1つまたは複数の実施をご検討ください。

  1. お持ちのIoT デバイス全てのTCP Port 22に対する、自社ネットワーク外部からのインバウンド接続を無効にする。
  2. 運用に必要な最小限のPort およびIPアドレスのセットを除いて、お持ちのIoTデバイスからのアウトバウンド接続を無効にする。

 

ベンダーへのガイダンス

SSH デーモンを使用するIoTを販売されている場合は、以下のオプションをご検討ください。

  1. 全てのSSHアカウントについて、デバイスごとに別のパスワードやキーを使用する。可能な限りパスワード認証を無効にする。
  2. エンドユーザーが、ファームウェアリリースを待たずにsshd 機能を無効に出来るようにする。
  3. 使用されるSSH デーモンを堅牢化するため、デバイスにとって明確に必要ではない全ての機能を無効にする。これらにはX11、ポート転送、エージェント転送、SCPなども含まれます。
  4. 明確なインバウンドおよびアウトバウンドのパケットフィルタリングを含める。

 

技術概要

 私達が攻撃を観測したIoTデバイスは、これらのデバイス内のSSHサーバーの悪用を阻止するためのいくつかの手順を行っていたのですが、 CVE-2004-1653に対する防御のための手順は行っていませんでした。「/usr/sbin/nologin 」または、「/bin/false/ 」に対して管理者ユーザーシェルを設定することにより、シンプルなログインはたしかにブロックしていました。これは  有用ではありますが、制御としては不完全です

一度ユーザーアカウントの認証情報を与えられると、IoTの展開後は変更されないか、変更不可となることが多く、攻撃者は -D や -L フラグを ssh に使って、踏み台とするマシンをProxyにすることが出来てしまいます。 (下図参照)。 -N フラグは無効化されたシェルのローンチを回避するために追加することができます。

Orys Image-thumb-600xauto-5265.png

1)  /> ssh -D 8080 -N cctv_admin@iot.vuln ("デフォルト" アカウント認証情報が必要)

2)  /> curl --proxy socks5h://localhost:8080 http://target.site/

 

これらはIoT デバイスを利用した攻撃のため、  2004年以降のイニシャルディスクロージャーで提案された緩和策 は適用できないことがあります。

これらの攻撃の踏み台となったデバイスの分析を含む、技術詳細の全てについては、近い将来、詳細な技術レポートの中でお知らせする予定です。

Leave a comment