LAC 株式会社ラック

セキュリティ2016/08/23

Cisco社製品におけるSNMPの脆弱性(CVE-2016-6366)について

8月17日(現地日付)に米Cisco社より公開されたCisco ASA(Firewall製品)のSNMP機能における任意のコードが実行可能な脆弱性(CVE-2016-6366)について注意して頂きたく、改めて概要をお伝えいたします。

  • ツイート
 

こんにちは。
JSOCのシニアセキュリティアナリストの品川です。

昨年末にJuniper社のFirewall製品における脆弱性について本ブログに書かせていただきましたが、今回もFirewall製品の脆弱性について検証を行いましたので、少しでも現在対応中の方などのお役に立てばと思い、書かせていただきます。
参考)昨年の記事

今回は、Cisco社のFirewall製品であるCisco ASAのSNMP機能における任意のコードが実行可能な脆弱性(CVE-2016-6366)についてです。本脆弱性は、Shadow Brokersと称するグループが、ハッカー集団「Equation Group」から得た情報の一部として公開したとされる、ファイルやツール群が攻撃対象とする脆弱性の一つであり、EXTRABACONと名称が付けられているようです。

Cisco社の公式発表によれば、影響範囲は全てのCisco ASA製品・バージョンで、修正版の公開されていない、いわゆる0dayの脆弱性(2016年8月21日現在)とのことですが、本脆弱性はCisco ASA上で稼働するSNMP機能に対して、細工したSNMPパケットが送られることにより任意のコードが実行可能となる脆弱性です。
そのため、「SNMP機能へのアクセスが許可されたIPアドレスからの接続」であり、「攻撃側がSNMPのコミュニティ名やアカウント情報を知っている」などアクセスに必要な情報を予め入手しておく必要があります。
このことから、被害を受ける環境は比較的限定的と言えますが、SNMPはUDPプロトコルであり攻撃者は容易に送信元IPアドレスを偽装可能であり、IPアドレスの制限では充分とは言えない点に留意する必要があります。上位の機器にて制御が可能な環境については、ネットワーク上で対象機器に対するSNMP通信が到達しないような制御を行うこともご検討ください。

さて、ここから検証結果ですが、実際に公開されたツールを用いてJSOCにて検証を行ったところ、試行する毎に挙動の違いが見られるものの、Cisco ASAに対して以下のいずれかの状況を引き起こすことが可能であることを確認しました。

  • Cisco ASAの停止(クラッシュ)と再起動
  • リモートログイン認証の無効化(SSH等で任意のID/パスワードを用いてログインおよび特権アクセスが可能)

※実行するタイミングにより、クラッシュして再起動するケースと認証の無効化ができるケースがありました。

以下は、攻撃成功後にCisco ASAに対するSSH接続の認証において、ユーザ名もパスワードもブランク(空白)で特権モード(Firewallのアクセスコントロールリストに編集なども可能なモード)にアクセスできた際の状況を示しています。なお、ユーザ名とパスワードは test/test でも test/123 など任意の文字列でログイン可能なようです。

20160822_01.jpg

2016年8月22日12時現在、JSOCの監視対象では攻撃や被害の検知はありません。しかしながら、今回公開されたツールは同じ脆弱性を用いて「正常な状態」(正規のアカウントによる認証が必要な状態)に戻す機能も有しています。
そのため、例えば任意の文字列による認証ができないことをもって「被害を受けていない」と断定することができないことに注意してください。

完全に攻撃者が機器を制御し得る脆弱性のため、事後の万全な確認項目を用意することは困難ですが、以下に挙げるような点を確認されることをお勧めいたします。

  • 存在しないはずのアカウント名によるログインなど、Syslogに不審なログイン記録がないか
  • 意図せず変更されている設定情報がないか(Configのバックアップとの差分がないか)
  • SNMP機能に対するアクセス制御が適切な設定となっているか
  • 第三者からSNMPを許可しているインターフェイスまで通信が到達しないよう経路制御が適切に行われているか

なお、特に昨年より様々なメーカの製品で類似の脆弱性が公表されるケースが続いておりますが、これらの多くは今回の脆弱性と同様に管理系のアクセス(SSH/TELNET/HTTPSなど)に対して、接続元を限定するなどの基本的な対策が行われていれば防止できるものがほとんどです。

このブログで取り上げさせていただいたJuniper社のNetScreenシリーズやCisco社のCisco ASAに限らず、セキュリティ対策製品であっても脆弱性とは無縁ではありません。同様に重大な脆弱性も生じ得るものとして、改めてお使いの製品の管理アクセスについて、設定状況の見直しを実施してみていただければ幸いです。

最後に、今回の脆弱性の検証時に気がついた点などを以下に挙げますので参考としてください。

脆弱性の概要

20160822_02.jpg

参考URL
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160817-asa-snmp
http://blogs.cisco.com/security/shadow-brokers

SSHによる不正ログイン時のSyslogについて

■Cisco ASAのGUI管理ツール(Cisco ASDM)でログイン中に攻撃が成功し、ユーザ名もパスワードも空白の不正なログインが行われると、以下のようなログが表示されました。本来ユーザ名が入る箇所が空白になっていることが分かります。(赤字)

20160822_03.jpg

■このことから、Syslogは通常通り出力されると考えられるため、機器上に存在しないユーザ名のログイン成功を示すログが発生していないか確認することで、被害の有無がある程度把握可能と考えられます。

■但し、攻撃者が利用したユーザ名と同じユーザ名が機器上に存在する場合も考えられますので、SSHの接続元IPアドレスにも注意が必要です。

攻撃成功時のGUI管理ツール(Cisco ASDM)の
挙動について

■Cisco ASAのGUI管理ツール(Cisco ASDM)でログイン中に攻撃を行い、成功した後に表示を更新すると、インターフェイス情報がダウン状態になり、Syslogの表示も非表示になりました。

20160822_04.jpg

■再度Cisco ASDMを起動してログインを試行した場合、認証は任意の文字列で成功するものの、ASDMの起動途中で停止する状態になっていたため、Cisco ASDMは正常にCisco ASA自体のステータス情報を取得できず、起動に失敗しているものと推測されます。

■但し、実際にはインターフェイス(NIC)は切断されていませんでした。CLI(コマンドライン)から制御するには特に異常がないことから、今回の攻撃ツールはCLIからのみの制御を前提としている可能性が考えられます。


正常な状態(正常な認証が行われる状態)への
切り戻し時の挙動について

■本文でも触れた通り、公開されたツールにはCisco ASAへのログイン認証を実質的に無効化する機能と、再度認証を有効化する機能の両方を有していました。

■攻撃者の視点では、脆弱性を悪用して攻撃が成功した後、標的側のユーザがCisco ASDMにアクセスしてしまうと、ログインすることができないために、攻撃を受けていることに気付かれる可能性が懸念されます。しかし、SSHでの侵入後に認証を有効化する攻撃を行うことにより、SSHのセッションを維持したまま、認証を正常化することが可能でした。

■これにより、攻撃者は侵入後にすぐに正常な状態へ戻すことで、標的に気付かれる可能性を最小限に抑えながら攻撃を行う可能性も想定されます。

■Cisco ASAの管理者は、Cisco ASAに対する不審な管理アクセスセッションが残っていないか併せて確認することが望ましいと考えられます。以下にSSHで接続中のセッションを確認するコマンド例を示します。

20160822_05.jpg

今回公表された攻撃ツールが対象としている環境について

■今回の脆弱性は、全てのCisco ASAが影響を受けるとされていますが、Cisco ASAのシステムソフトウェアを8.2(5)から8.4(4)1に変更したところ、攻撃ツール上で対応バージョンでは無いエラーを示すメッセージが表示され、攻撃に失敗しました。

■これは、攻撃ツール側が対応しているバージョンが限定されているためと考えられ、実際にツールのサブフォルダを参照すると、Cisco ASAのバージョン毎にファイルが用意されていました。

20160822_06.jpg

■ファイル名やスクリプトのコードから、以下のバージョンを対象としているように見受けられます。
8.0(2)  8.0(3)  8.0(3)6  8.0(4)  8.0(4)32  8.0(5)
8.2(1)  8.2(2)  8.2(3)    8.2(4)  8.2(5)
8.3(1)  8.3(2)
8.4(1)  8.4(2)  8.4(3)    8.4(4)


■また、攻撃ツールの実行時には、実際に最初にSNMPでCisco ASAのバージョンを取得していることを確認しています。

20160822_07.jpg


■あくまで公開されたツールでの対応状況であるため、このリスト内での有無で現在利用されている環境が安全か危険かを分けることはできませんが、少なくとも本リスト内にあるバージョンをご利用の場合には、特に注意してください。

  • ツイート