[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AU携帯電話サービス 迷惑メール防止機能の迂回



【概要】

AUの迷惑メール対策システムにおいて、フィルタリングを迂回して迷惑メールを送信可能な脆弱性が確認
された。問題が修正されたため、ここに詳細を報告する。

【対象となる機能】

AU携帯電話サービス 迷惑メール対策システム
 「なりすましメール拒否機能」
 「未承諾広告※メール拒否機能」

【脆弱性の種類】

迷惑メールフィルタリングの迂回

【背景】

1)「なりすましメール拒否機能」

AUの迷惑メール対策において、「なりすましメール」とは、携帯電話のアドレスを送信元としているもの
の、実際には携帯端末以外の機器から送信されたメールのことを指す。パソコンからインターネット経由
で送信したメールで、差出人欄(From: ヘッダ)に「@xxxxxxxxxxx」を含むものなどがこれに該当する。

「なりすましメール拒否機能」は、「なりすましメール」を受信拒否する機能である。差出人欄(From: 
ヘッダ)に基づいて、携帯電話から送られたかのように見えるメール(@xxxxxxxxxxxなど)をフィルタリ
ングする。

2)「未承諾広告※メール拒否機能」

「未承諾広告※メール拒否機能」は、件名に「未承諾広告※」を含むメールを受信拒否する機能である。
件名欄(Subject: ヘッダ)に基づいて、未承諾広告※を含むメールをフィルタリングする。

上記の2つの迷惑メール防止機能を、不正なエンコードにより迂回できることが確認された。

【詳細説明】

メールのヘッダに日本語を指定する場合には、[RFC 2047 Message Header Extensions] に従い、以下の
2つのエンコード方式を用いることができる。

B encoding
Q encoding

このうち Q encodingでは、アルファベットなどを除く文字は=に続く16進数 2桁で表現する。例えば
「@」は「=40」、「_」は「=5F」となる。この時、16進数に用いるアルファベットは大文字にすることと
されている。

対象システムにおいて、エンコード方式に Q encode を採用し、かつ、16進数の表記に小文字のアルファ
ベットを用いることにより、本来のフィルタリングを迂回することが可能であった。

1)「なりすましメール拒否機能」の迂回

通常、「なりすましメール拒否機能」が有効であれば、以下のような携帯電話のアドレスを差出人として
パソコンからメールを送信すると、エラーメールが戻される。

From: hoge-fuga@xxxxxxxxxxx
From: <hoge-fuga@xxxxxxxxxxx>
From: "hoge-fuga@xxxxxxxxxxx"

しかし、これらのデータを Q encode し、かつ、16進数の表記に小文字のアルファベットを用いることに
より、携帯端末にメールが配信される。

From: =?ISO-2022-JP?Q?hoge=2dfuga=40ezweb=2ene=2ejp?=
From: <=?ISO-2022-JP?Q?hoge=2dfuga=40ezweb=2ene=2ejp?=>
From: "=?ISO-2022-JP?Q?hoge=2dfuga=40ezweb=2ene=2ejp?="

これらのメールを受信すると、携帯端末側では差出人が以下のように表示される。

hoge-fuga@xxxxxxxxxxx

2)「未承諾広告※メール拒否機能」の迂回

「未承諾広告※メール拒否機能」が有効にされている場合、件名に「未承諾広告※」を含むメールは携帯
端末側に届けられない。

(通常は以下のように B encode が行われる)
Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoGyhC?=
(以下のように Q encode しても、メールは拒否される)
Subject: =?ISO-2022-JP?Q?=1B=24BL=24=3E5Bz9=2D9p=22=28=1B=28B?=

しかし、このデータを Q encode し、かつ、16進数の表記に小文字のアルファベットを用いることによ
り、携帯端末にメールが配信される。

Subject: =?ISO-2022-JP?Q?=1b=24BL=24=3e5Bz9=2d9p=22=28=1b=28B?=

この場合、携帯端末側では件名が以下のように表示される。

未承諾広告※

いずれの現象においても、本来大文字でエンコードすべき部分が小文字でエンコードされていることで、
文字列検索が有効に機能しなくなるものと思われる。そもそも不正なデータであるので、「正しく」デ
コードできないことは仕様上正当な動作かもしれないが、受信した携帯端末では文字化けが起こることな
く表示されるため、結果的にフィルタリングを回避することができる。

【影響範囲】

携帯端末で受信結果が正常に(文字化けせずに)表示されることは、端末 A1101S において確認済み。そ
れ以外の機種については検証していないが、同様の現象が発現した可能性はある。

【脅威】

1)「なりすましメール拒否機能」の迂回

なりすましメールを拒否しているユーザに対しても、携帯端末から送られたかのように見えるメールをパ
ソコンなどから送信することが可能となる。

差出人として受信者のアドレスを指定することで、受取人が自分に向けて送信したかのような形を取るこ
とも可能である。

2)「未承諾広告※メール拒否機能」の迂回

未承諾広告※メールを拒否しているユーザに対しても未承諾広告※メールを配信することができる。

【再現手順】

1) 「なりすましメール拒否機能」の迂回

以下のようなアドレスを差出人(From: ヘッダ)に指定する:
差出人を「hoge-fuga@xxxxxxxxxxx」と表示させる場合

hoge-fugaの「-」を不正にエンコード("=2D" -> "=2d")
=?ISO-2022-JP?Q?hoge=2dfuga=40ezweb=2Ene=2Ejp?=

ドメイン名の「.」を不正にエンコード("=2E" -> "=2e")
=?ISO-2022-JP?Q?hoge=2Dfuga=40ezweb=2ene=2ejp?=

小文字混じりの不正なエンコードが1つでもあれば、
以下のようなエンコードでも可("." がエンコードされていない)
=?ISO-2022-JP?Q?hoge=2dfuga=40ezweb.ne.jp?=

(参考)正規のエンコード
=?ISO-2022-JP?Q?hoge=2Dfuga=40ezweb=2Ene=2Ejp?=


2)「未承諾広告※メール拒否機能」の迂回

件名を以下のように設定する:
「未承諾広告※」を不正にエンコード
=?ISO-2022-JP?Q?=1b=24BL=24=3e5Bz9=2d9p=22=28=1b=28B?=

(参考)正規のエンコード
=?ISO-2022-JP?Q?=1B=24BL=24=3E5Bz9=2D9p=22=28=1B=28B?=

【回避策】

この問題は既に修正されている。


--ScriptKitty