TOPに戻る
▼Network
SNMPのセキュリティホール
┣ サービス拒否攻撃と
┃ バッファオーバーラン
┣ SNMPの必要性
┣ GetRequest/GetNext
┃ Request/SetRequest
┃ /Trap
┗ ASN.1/BERと
セキュリティホール
Copyright(C) 2001-2002.ugpop. All rights reserved.
■ ASN.1/BERとセキュリティホール ■
前回はSNMP(Simple Network Management Protocol)についての
動作説明を行ないました。
GetRequest/GetNextRequest/SetRequest/Trapと呼ばれるやり
取りをマネージャとエージェント間で行い、ネットワークの管
理が行なわれる事を説明しました。
また、このやり取りを行なう時の内容は数字を使って表され、
この数字の表現形式の事をASN.1(Abstract Syntax Notation
One)という事の説明も行いました。
今回はASN.1についてもっと詳しく説明します。
前回説明したように、GetRequest/GetNextRequest/SetRequest/
Trapのやり取りを行なう時は、実際には数字がやりとりされま
す。
ASN.1では、この数字の表現の仕方の種類をさまざまに規定し
ていて、以下の様な物があります。
┌───────────────────────────────┐
│BOOLEAN :真偽を表す(TRUE/FALSE) │
│INTEGER :整数型(符号付、可変長) │
│BIT STRING :ビット列型(ビット単位で可変長) │
│OCTET STRING :オクテットストリーム型 │
│NULL :ヌル型 │
│OBJECT IDENTIFIER :OID型 │
│ObjectDescripter :オブジェクト記述型 │
│EXTERNAL :外部型 │
│REAL :実数型 │
│ENUMERATED :整数列挙型 │
│UTF8String :UTF8(Unicode)文字列 │
│SEQUENCE/SEQUENCE OF:順序列型(格納順序に意味有り) │
│SET/SET OF :集合型(格納順序に意味無し)/単一集合型 │
│NumericString :数字列型 │
│PrintableString :文字列型 │
│TeletexString :TeletexString型 │
│VideotexString :VideotexString型 │
│IA5String :IA5String型 │
│UTC Time :UTC Time型 │
│GeneralizedTime :GeneralizedTime型 │
│GraphicString :GraphicString型 │
│VisibleString :VisibleString型 │
│GeneralString :GeneralString型 │
│CharacterString :CharacterString型 │
└───────────────────────────────┘
数値を表す表現方法、文字を表す表現方法、時刻を表す表現方
法、順序を表す表現方法、等々・・。
ASN.1で規定されている表現方法の種類にはたくさんの種類が
あります。
なんだか難しそうですがSNMPで使用するのはこの中でたった1
つだけです。
SNMPで使用するのは、「OBJECT IDENTIFIER」(OID)という物を
用います。
例えば、「ネットワークのエラーどれ位発生してる?」という
質問をASN.1で表すと「1.3.6.1.2.1.2.2.1.14.1」となります。
これを、OIDの表現方法に当てはめて見てみます。
最初の1番目には該当OIDを誰が規定しているのかの情報が載
ります。
1.3.6.1.2.1.2.2.1.14.1
 ̄
↑
├─┬────────────┐
│0│ITU−Tが規定 │
├─┼────────────┤
│1│ISOが規定 │
├─┼────────────┤
│2│ITU−TとISOが規定│
└─┴────────────┘
この例の場合、1なのでISOが規定しているOIDだという
事が分かります。
1番目がISOの場合、2番目の数字は、ISOの標準なのか、
登録機関なのか、加盟団体なのか、身元が明らかな組織なのか
を表します。
1.3.6.1.2.1.2.2.1.14.1
 ̄
↑
┌─┼──────────────────────┐
│0│標準(standard) │
├─┼──────────────────────┤
│1│登録機関(registration-authority) │
├─┼──────────────────────┤
│2│加盟団体(member-body) │
├─┼──────────────────────┤
│3│身元が明らかな組織(identified-organization) │
└─┴──────────────────────┘
この例の場合、「身元が明らかな組織」を表します。
SNMP(Simple Network Management Protocol)のOID(Object ID-
entifier)はRFC(Request For Comment)で管理される事になっ
ているので、この時の身元が明らかな組織とは、RFCの事です。
3番目以降は、RFCにより管理され、さまざまなSNMPに関する
やりとりが階層構造のようにして取り決められています。
ここでは膨大な量がある為、紹介しきれません。
興味のある方はこちらを見てみてください。
Alvestrand DataのObject IDentifierのページ(英語)
>>> http://www.alvestrand.no/objectid/top.html
または
ASN.1 Information siteのOBJECT IDENTIFIER一覧のページ(英語)
>>> http://asn1.elibel.tm.fr/cgi-bin/oid/display/
さらにこのASN.1で表された数字(OID等)を実際にビットデータ
として送信する場合に、BER(Basic Encoding Rule)という変換
が行なわれます。
BERについて概要だけ説明します。
BERは3つのフィールドで表されます。
┌───────┬─────────┬──────┐
│タグフィールド│値の長さフィールド│値フィールド│
└───────┴─────────┴──────┘
↑
ここにASN.1で
表現された数字(OID等)が入る
「1.3.6.1.2.1.2.2.1.14.1」等
「値フィールド」にはASN.1で表現された数字列が入ります。
「値の長さフィールド」には値フィールドの長さが入ります。
「タグフィールド」には1番上の表で示した中で、どの表現形
式を用いるかを示す為の値が入ります。
またタグフィールドには値フィールドのデータが構造化してい
るか、また使用目的等の情報が入ります。
ところでこのOIDですが、数字の長さもさまざまなものがあり
ます。
「ネットワークのエラーどれ位発生してる?」というRequest
に関しては数字が11個あります。
1.3.6.1.2.1.2.2.1.14.1
│ │
└──────────────────────┘
11個
これを例えば12個以上の数字をマネージャからエージェント
に送ってみた場合、どうなるでしょうか?
SNMPでは「マネージャ」と「エージェント」という言葉で表さ
れていますが、実体は単なるプログラムです。
不正なOIDを送った場合にプログラムは正常に対応できるので
しょうか?
そういう疑問を持って実際に試してみた学生達がいました。
フィンランドのOULUという大学の学生達です。
そしてその結果、「正常に動作しない」という事が判明したの
です。
この不具合は複数のベンダーのほぼ全てのネットワーク機器で
発生する事が分かりました。
ルータやスイッチ、ネットワークプリンタ、等々。
ネットワーク機器のほぼ全てのSNMPの機能に不具合が存在する
のです。
また、BER(Basic Encoding Rule)変換を行なった時の、「タグ
フィールド」「値の長さフィールド」「値フィールド」の3つ
のフィールドですが、いずれもBERやASN.1の仕様により長さが
可変です。
┌───────┬─────────┬──────┐
│タグフィールド│値の長さフィールド│値フィールド│
└───────┴─────────┴──────┘
│ │ │ │
└───────┴─────────┴──────┘
↑ ↑ ↑
│ │ ┌───┴─────┐
│ │ │ASN.1の仕様により │
│ │ │OID等の長さは可変 │
│ │ └─────────┘
│ ┌────┴──────┐
│ │値フィールドが1個の │
│ │場合と値フィールドが │
│ │1000個の場合とで │
│ │「値の長さフィールド」│
│ │の長さ(桁数)は異な │
│ │ります。 │
│ └───────────┘
┌──┴───┐
│1バイトでも│
│大丈夫なのだ│
│が将来の予約│
│の為に可変長│
│となっている│
└──────┘
値の長さフィールドに関しては少し難しいかもしれませんが、
例えば「値フィールド」が1個の場合は「値の長さフィールド」
には「1」という数字を1個だけ入れれば良いのですが、「値
フィールド」が1000個あった場合は「値の長さフィールド」
には「1」「0」「0」「0」と、4つの数字を入れる必要が
ありますよね?(本当はもう少し複雑ですが・・・。)
このBERのそれぞれのフィールド長が可変である事にもフィン
ランドの学生達は疑いを持ち、仕様と異なる様なデータを送っ
てみてみました。
その結果、これらについても「正常に動作しない」事が判明し
てしまったのです。
この脆弱性を発見した学生達はすぐさまCERT(Computer Emerg-
ency Response Team)に報告しました。
そして、通常であれば各ベンダーに報告され、パッチなど対策
が完了した段階でその脆弱性が公表され、同時にパッチが公開
されるのですが、今回の場合、ベンダーの対策が完了する以前
にクラッカーがこの脆弱性に気が付いてしまいました。
SNMPの脆弱性を攻撃するツールを作成し、公開してしまったの
です。
皆さんの中にもUDPポート161/162に対して攻撃を受けた方がい
らっしゃるかもしれません。
(ファイアウォールなどを入れていない方は攻撃されている事
自体に気づく事も出来ないのですが・・・。)
SNMPはポート161/162を使用するのです。
(ポートという言葉について、分からない方はサービスの種類
を表すものだと思ってください。ポートについては別の機会に
説明したいと思います。)
クラッカーによりツールが作成され、公開されてしまった事に
よりCERTはこの脆弱性をベンダーの対策が完了していない段階
で公表し、注意を促したというわけです。
この脆弱性は近年稀に見る影響範囲の広い脆弱性となってしま
いました。
その為、この講座でも早めに取り上げる事にしたのですが急い
で書いた為に分かりにくい部分も多々あったかと思います。
詳しくは参考文献の方に載っていますのでそちらの方をご参照
ください。
また、この講座を読んでお分かりいただけたかと思いますが、
これはSNMPのセキュリティホールというよりは、ASN.1/BERの
セキュリティホールと言っても良いものです。
クラッカーがこの脆弱性に気づいているという事は、SNMPだけ
でなく、今後ASN.1/BERを利用した他のプロトコルについて攻
撃が行われるかもしれないのです。
現在も着々と攻撃の準備が進められているのかもしれません・・。
参考文献:
CERTのSNMPの脆弱性についての勧告(日本語)
>>> http://www.lac.co.jp/security/intelligence/CERT/CA-2002_03.html
フィンランドのOULU大学の報告(英語)
SNMPの脆弱性をテストする為のツールも置いてある
>>> http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/snmpv1/index.html
SNMPについてもっと知りたい方
ZDNET Help Desk(日本語)
>>> http://www.zdnet.co.jp/help/howto/linux/0007master/06/
ASN.1/BERについてもっと知りたい方(日本語)
>>> http://www.geocities.co.jp/SiliconValley-SanJose/3377/
OIDの詳細についてもっと知りたい方
Alvestrand DataのObject IDentifierのページ(英語)
>>> http://www.alvestrand.no/objectid/top.html
ASN.1 Information siteのOBJECT IDENTIFIER一覧のページ(英語)
>>> http://asn1.elibel.tm.fr/cgi-bin/oid/display/
←前へ戻る ▲このページの上へ