GNU Bashの環境変数処理の不備により任意のコードが実行される脆弱性(CVE-2014-6271,CVE-2014-7169)に関する検証レポート

0
Filed under exploit

【概要】
GNU Bash(以下、単にBash)にリモートより任意のコードが実行される脆弱性が発見されました。一連の脆弱性の愛称?は「Bashbug」または「Shellshock」のようです。

本脆弱性は、Bashの環境変数に関数を設定し同一の環境変数内に任意のコードを設定することで発生します。
攻撃者は、細工した環境変数を設定することにより、Bashを経由した環境で任意のコードが実行可能となります。

Bashを経由した環境での脆弱性の利用方法は、以下のような場合があります。
– ApacheなどWebサーバ上でCGIをBashから実行している場合にWebサーバの実行権限で任意のコードを実行
– DHCPサーバで環境変数に任意のコードを埋め込みDHCPクライアントに対してBashを経由して任意のコードを実行
– sshのForceCommand設定なでで使用可能なコマンドを制限している環境でログインユーザー権限で任意のコマンドを実行

このほかの例として、以下のURLでRedhat社の製品で影響を受ける環境の例が掲載されています。
Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

今回、この脆弱性(CVE-2014-6271,CVE-2014-7169)について検証を行いました。

【影響を受ける可能性があるシステム】
CVE-2014-7169
– Bash 4.3 Patch 25 およびそれ以前
– Bash 4.2 Patch 48 およびそれ以前
– Bash 4.1 Patch 12 およびそれ以前
– Bash 4.0 Patch 39 およびそれ以前
– Bash 3.2 Patch 52 およびそれ以前
– Bash 3.1 Patch 18 およびそれ以前
– Bash 3.0 Patch 17 およびそれ以前

CVE-2014-6271
– Bash 4.3 Patch 25 以前
– Bash 4.2 Patch 48 以前
– Bash 4.1 Patch 12 以前
– Bash 4.0 Patch 39 以前
– Bash 3.2 Patch 52 以前
– Bash 3.1 Patch 18 以前
– Bash 3.0 Patch 17 以前

なお、ディストリビュータごとに影響を受けるバージョンが異なります。詳細は各ディストリビュータの脆弱性情報を参照ください。また、LinuxなどのOSをベースとしたネットワーク機器を含めた専用機器においても関連する脆弱性情報が発表されています。使用されている各機器のセキュリティ情報を収集されることを推奨いたします。

すでに、CiscoやF5のような利用者が多いと考えられる機器について各ベンダーから情報が公開されています。
GNU Bash Environmental Variable Command Injection Vulnerability
SOL15629: GNU Bash vulnerabilities CVE-2014-6271 and CVE-2014-7169

【対策案】
CVE-2014-6271については以下のバージョンで修正されています。
– Bash 4.3 Patch 25
– Bash 4.2 Patch 48
– Bash 4.1 Patch 12
– Bash 4.0 Patch 39
– Bash 3.2 Patch 52
– Bash 3.1 Patch 18
– Bash 3.0 Patch 17

CVE-2014-7169については、本レポート作成時点(2014年9月26日)において修正されておりません。各ディストリビュータによって独自のパッチを提供しています。詳細は@piyokangoさんのブログがまとめてくださっておりますので参照いただくことを推奨いたします。

回避策については、【概要】で紹介したRedhat社のページのように
– mod_securityによる回避
– iptablesによる回避
などの方法が考えられます。

【参考サイト】
CVE-2014-6271
CVE-2014-7169
JPCERT/CC Alert 2014-09-25 GNU bash の脆弱性に関する注意喚起
bash の脆弱性対策について(CVE-2014-6271 等)
bashの脆弱性(CVE-2014-6271) #ShellShock の関連リンクをまとめてみた

【検証イメージ】
shellshock

【検証ターゲットシステム】
– Cent0S 7 + Apache 2.4.61 + GNU bash, バージョン 4.2.45(1)-release-(x86_64-redhat-linux-gnu)
– Ubuntu Server 14.04.1 LTS
– Bash 4.3-7ubuntu1
– Apache 2.4.7-1ubuntu4.1

【検証概要】
脆弱性の存在するターゲットシステムに、攻撃者が実行したいコードを含めたHTTPリクエストを送ります。ターゲットシステム上ではコードが実行され、攻撃者に応答を返します。
これにより、リモートからターゲットPCの操作が可能となります。

【検証結果】
下図は実際にCGIを経由してコードを実行した画面です。黄色で囲まれた部分はUser-Agentに実行コードを埋め込んていることを示しています。赤色で囲まれた部分は実行結果を示しています。これにより、ターゲット上で任意のコードを実行することに成功しました。
CVE-2014-6271

【2014/09/28 oda 追記】
なお、上記のUbuntu上で実行しているテスト用のCGIは「#!/bin/bash」としてbashを明示的にbashを呼び出して実行しています。Ubuntu上のCGIで「#!/bin/sh」としてshを呼び出している場合は、通常dashへlinkされているため本脆弱性の影響を受けません。

【2014/09/28 ntsuji 追記】
以下のようにhttp経由で細工を施したブラウザでアクセスすることでWebサーバの権限を奪取することに成功しました。
これによりリモートから特定の権限で任意のコマンドが実行可能な状態になったと言えます。
gotshell_http

また、細工したDHCPサーバを設置し、そのサーバにDHCPリクエストを行ってきたCentOSの制御を奪うことにも成功しました。奪取できる権限はDHCPリクエストを行った際の権限に依存します。
gotshell_dhcp_full_edited

reported by oda, ntsuji

「STOP!! パスワード使い回し!!」について考えました。

0
Filed under memo


JPCERT/CCとIPAが「STOP!! パスワード使い回し!!」というキャンペーンを開始しました。

JPCERT/CCのプレス
IPAのプレス

JPCERT/CCが
「STOP!パスワード使い回し!」キャンペーンにご賛同頂ける企業の募集
を出しているところを見るとJPCERT/CC主導のキャンペーンなのでしょうか。

複数のサイトでパスワードの使い回しがあり、その現状に狙いを定めてリスト型攻撃が多く発生し、不正ログインの被害に遭っている方が増えていることを考えるとこのようなキャンペーンを行うことはとてもいいことだと思います。しかし、一方でボクはこのキャンペーンに薄らと違和感を覚えていました。その違和感というのはこの不正ログインを防止する上でどのような対策を誰が行うのかということとこのキャンペーンを照らし合わせたときに不十分に感じたからです。

「不正ログインを防止する」ということをボクは交通安全を実現し人命を救うことに例えることがよくあります。
サービス提供側は車の製造メーカー。ユーザはドライバーです。
エアバッグや衝突被害軽減ブレーキなど安全に配慮した機能を実装するのは車の製造メーカーです。
その車を適正に利用し、危険な運転を行わないようにするのはドライバーです。
この両方が満たされることが交通安全、人命を救うことに繋がると考えています。つまり、どちらか一方が欠けてもいけないということです。この例えからすると、サービス提供側は、強固なパスワードを設定することが可能となる実装するなどといったユーザを最大限に保護する機能を提供し、ユーザは強固なパスワードを設定し、使い回しをしない。ということで「不正ログインを防止する」ということが実現できると考えています。もちろん、それぞれは義務ではありませんので強制することはできず、一定の自由があるとも考えています。いずれにせよ、「不正ログインを防止する」にはサービス提供側とそのユーザそれぞれが努力する必要があると思います。

今回のキャンペーンを見てみるとユーザにしか努力しようがない「パスワードの使い回し」にフォーカスされています。不正ログインに対抗するためには「パスワードの使い回し」だけではなく、推測可能な「弱いパスワード」もSTOPさせる必要があると考えています。今回のキャンペーン対してはいくつかの賛同企業があり、それによって多くの方に「パスワードの使い回し」をやめてもらうための情報発信をすることはとても価値のあることだと思いますが、不正ログインそのものに対抗するためには、その賛同企業にも努力の余地があるのではないだろうか。と考えました。そこで賛同企業の提供サービスの一部ではありますがどのようなユーザを保護する機能を実装しているのかということを調査してみました。調査の結果は以下の通りです。(ボク自身が登録していなかったサービスが多数あったため今回登録して調査をしてみたのですが誤りやお気づきの点があればこっそり教えていただければ幸いです。修正いたします。)

 社名   サービス名   長さ   文字種  二要素  ユーザ名  [passw0rd]を設定
 Gunho   ガンホーID   8~16 *1   半角英数   有   独自ID   可 
 Hoikuu   保育のひろば   WordPress *2   WordPress *2   無   WordPress *2  WordPress *2
 CyberAgent   アメーバID   6~12   半角英数 *3   無   独自ID   可 
 dowango   niconico   6~32   半角英数   無   メールアドレス
 電話番号 
 可 
 ナナロク  個人向けサービスなし?
 mixi   mixi   6~ *4   半角英数記号   無   メールアドレス   不可 
 Yahoo!JAPAN   Yahoo!JAPAN ID  6~32文字   半角英数記号   有   ユーザID *5   不可 
 楽天   楽天会員   6~ *6 *7   半角英数   無   メールアドレス   可 
 DeNA   DeNA ID   8~20   半角英数記号   無   メールアドレス   可 
 GMOグループ  GMOとくとくID   6~16   半角英数   無   メールアドレス   可 

*1 同じ文字が4文字以上連続、数字のみ、英字のみ不可
*2 WordPress利用と考えられるため不明
*3 数字のみIDに含まれる文字列は使用不可
*4 33文字でも設定できた
*5 シークレットID利用可
*6 33文字でも設定できた
*7 ユーザIDと同一は不可

記号が使えないサービスや設定できる文字数が長くないもの、辞書攻撃に耐性が弱そうなパスワードを設定可能なサービスが見受けられます。だから、ダメだとはならないと思うのですが、今回の「STOP!! パスワード使い回し!!」を継続しつつ。今後は「STOP!! 弱いパスワード!!」キャンペーンといったサービス提供側とそのユーザが一丸となって不正ログインに立ち向かうようなキャンペーンが実施されればいいな。と思いました。

度々、穴となる「秘密の質問」もSTOPしてくれると嬉しいですね。


Club NTT-Westをかたるフィッシングにひっかかってみました。

0
Filed under phishing



久しぶりにひっかかってみました。

ということで本物と偽物の比較。

【本物】
true

【偽物】
01

相変わらず見た目そっくりですね。
入力のエラーチェックまで同じ挙動。
02

スクロールした際にでてくるメッセージが出てくるというのも同じ。
part

ただ、本物と偽物ではWebサーバの構成が違うようでブラウザのプラグインの反応が以下のように異なりました。

【本物】
t

【偽物】
f

偽物はIISで以下がNot Foundの画面です。
error

実際に情報を適当なものを入力してページ下部にある「次へ進む」を押したところ以下のページにリダイレクトされました。
03

入力させて、何事もなかったのように別のページにリダイレクトするというのは割と常套手段なのですが今回が多くのフィッシングサイトと違うところはIDとパスワードを入力させて盗むタイプのものではないということでしょうか。
今回、盗もうとしている情報は

・ご契約回線名義
・設置場所の郵便番号
・回線ID

の3つです。
気になったので「club NTT-West」の会員ログインのページを確認したところ下図のように会員IDとパスワードに加えて「お客様ID」もしくは「回線ID」が必要だということが分かりました。
したがって、攻撃者が欲しい情報は「回線ID」なのではないかと思います。

もしかすると、攻撃者はすでに何かしらの形で攻撃を行うためのリスト(IDとパスワードがセットのもの)は持っているものの3つめに必要な「お客様ID」もしくは「回線ID」を持っていないため、このようなフィッシングサイトを設置したのかもしれませんね。

以上です。

【同日追記】
Twitterでフィッシングサイトにログインページも存在するということを教えていただきました。
auth


Wiresharkによる無線LAN通信の復号手順メモ

0
Filed under memo


本記事に掲載した行為を自身の管理下にないネットワーク・コンピュータに行った場合は、攻撃行為と判断される場合があり、最悪の場合、法的措置を取られる可能性もあります。このような調査を行う場合は、くれぐれも許可を取ったうえで、自身の管理下にあるネットワークやサーバに対してのみ行ってください。また、本記事を利用した行為による問題に関しましては、一切責任を負いかねます。ご了承ください。

ひょんなきっかけで接続されているパスワードが設定されており、暗号化された無線LANを流れる自分以外の通信を復号できるかどうかということの再確認を「Wireshark」を用いて行ったのでそちらの手順のメモです。前提条件として、その無線LANに接続しているユーザはWPA2 Personalで共通のパスワードで接続しているというものです。
また、今回、Wiresharkを動作させているコンピュータはMacOSです。

まず、「Wireshark」を起動してメニューバーの

[Capture]→[Options]

を選択し、[Capture Options]ウインドウを表示します。
01

表示されたウインドウ内に表示されている中からパケットを収集するネットワークカードを選択して、ダブルクリックをします。すると下図のように[Edit Interface Settings]ウインドウが表示されますので
02

[Capture packets in promiscuous mode]
[Capture packets in monitor mode]

のそれぞれにチェックをします。

[Edit InterfaceSettings]ウインドウを[OK]で閉じ、[Capture Options]ウインドウを[Close]で閉じます。

次にメニューバーから

「Edit」 → 「Preferences…」

を選択し、[Preferences]ウインドウを開き、左ペインの[Protocols]を開き[IEEE 802.11]を選択します。
そうすると右ペインの表示が変化するので
[Enable decryption]にチェックを付けて
[Decryption Keys:]の[Edit...]ボタンをクリックします。
03

すると[WEP and WPA Decryption Keys]ウインドウが開きます。
04-1

そして、[New]ボタンをクリックし、復号したい通信が流れる無線LANアクセスポイントの暗号化方式[Key Type]とパスフレーズとSSIDを入力をします。今回は[WPA-PWD]の通信を復号するため[Key]の部分は

Passphrase:ssid

という形式で入力します。
04-03

上記ウインドウ、[WEP and WPA Decryption Keys]ウインドウ、[Preferences]ウインドウを[OK]で閉じます。

これで準備は整いました。後は通信をキャプチャするだけで、条件に合致した通信は復号されて読むことができるようになります。
05

下図は、復号を行った状態と行っていない状態での通信の内容を表示したものです。
復号後のものはアクセスしたサイトのアドレスが表示されています。

【復号前】
09

【復号後】
07


模倣サイトと呼ばれている「3s3s」について

0
Filed under memo



各所から「模倣サイト」に関する注意喚起が出されています。多くの注意喚起は
「コンピュータウィルスに感染するなどの恐れがあり」といったような文言を添えて注意喚起をしています。模倣サイトとされているサイトのドメインは伏せられていることが殆どですが一部の発表によると「3s3s.org」というドメインのようです。
このあたりについてはpiyokangoさんがまとめを作られているので参照いただければと思います。

さて、この「3s3s」は一体どのようなサイトなのか?ということなのですが、それについてはトップページに書かれています。

3s3s01

Your favorite site someone has blocked? You do not like censorship?
Enter the site address in the text box below and click “Unblock”.

「あなたのお気に入りのサイト誰が誰かにブロックされましたか?あなたは検閲を好みませんか?
以下のテキストボックスにサイトのアドレスを入力し、「ブロックを解除する」をクリックしてください。」
といったところでしょうか。

この言葉通りであれば、何かしらの理由でユーe="float:left;margin-right:10px;">



各所から「模倣サイト」に関する注意喚起が出されています。多くの注意喚起は
「コンピュータウィルスに感染するなどの恐れがあり」といったような文言を添えて注意喚起をしています。模倣サイトとされているサイトのドメインは伏せられていることが殆どですが一部の発表によると「3s3s.org」というドメインのようです。
このあたりについてはpiyokangoさんがまとめを作られているので参照いただければと思います。

さて、この「3s3s」は一体どのようなサイトなのか?ということなのですが、それについてはトップページに書かれています。

3s3s01

Your favorite site someone has blocked? You do not like censorship?
Enter the site address in the text box below and click “Unblock”.

「あなたのお気に入りのサイト誰が誰かにブロックされましたか?あなたは検閲を好みませんか?
以下のテキストボックスにサイトのアドレスを入力し、「ブロックを解除する」をクリックしてください。」
といったところでしょうか。

この言葉通りであれば、何かしらの理由でユーe="width:55px;height:22px;background:transparent url('http://n.pentest.ninja/wp-content/plugins/wp-tweet-button/tweetn.png') no-repeat 0 0;text-align:left;text-indent:-9999px;display:block;">Tweet



各所から「模倣サイト」に関する注意喚起が出されています。多くの注意喚起は
「コンピュータウィルスに感染するなどの恐れがあり」といったような文言を添えて注意喚起をしています。模倣サイトとされているサイトのドメインは伏せられていることが殆どですが一部の発表によると「3s3s.org」というドメインのようです。
このあたりについてはpiyokangoさんがまとめを作られているので参照いただければと思います。

さて、この「3s3s」は一体どのようなサイトなのか?ということなのですが、それについてはトップページに書かれています。

3s3s01

Your favorite site someone has blocked? You do not like censorship?
Enter the site address in the text box below and click “Unblock”.

「あなたのお気に入りのサイト誰が誰かにブロックされましたか?あなたは検閲を好みませんか?
以下のテキストボックスにサイトのアドレスを入力し、「ブロックを解除する」をクリックしてください。」
といったところでしょうか。

この言葉通りであれば、何かしらの理由でユーザが見たいサイトがブロックされている場合、この「3s3s」を経由することで目的のサイトを見られるようにするというものだと考えられます。
「http://n.pentest.ninja/」というアドレスがブロックされているとすると「3s3s」を経由することで「http://n.pentest.ninja.3s3s.org/」というアドレスになり、閲覧できるようものだということです。つまり、誰かが意図的に作成したサイトではなく、元のサイトのまま表示させているため注意喚起のようにコンピュータウイルスの感染は考えられないということになります。もし、「3s3s」のほうにコンピュータウイルスに感染する危険性があるのであれば、元のサイトにもコンピュータウイルスに感染する危険性があるということになりますので本末転倒です。

また、この「3s3s」を経由すると「3s3s」が指定したサイトにアクセスを行ってきますので「3s3s.org」からのアクセスを「.htaccess」やファイアウォールなどでブロックすれば、各サイトで呼ばれているような「模倣サイト」の作成は防ぐことができるようになりますので、どうしても防ぎたいという場合は注意喚起をする前にそちらを実施すればいいのだと思います。
「.htaccess」によるブロックの方法は、Yuta Hayakawaさんがブログに書いてくださっています
さて、「模倣サイト」という言葉なのですが、こちらはこの言葉でいいのでしょうか。
ボクははじめ注意喚起していたことにTwitterで以下のようにつぶやきました。

これは「模倣サイト」という言葉に対して「コピー」という表現を使ったのですがこれに対してご指摘をいただきました。


※ また、北河拓士さんはTogetterにもこの件についてのまとめを作成してくださっています

おっしゃる通りで、このとき完全にコピーするよりも、プロクシのような仕組みのほうが「3s3s」自身の負荷も減らすこともできるのでこちらの可能性が高いかもしれないと思いました。

その後、piyokangoさんが「3s3s」の管理者に質問をしてくださったようでProxyであると明言されていますね。

何れにしてもこの「3s3s」は現在のところ仕組み上コンピュータウイルスに感染するようなものではないということが言えます。
もちろん、このサイトの管理者やこのサイトを乗っ取った攻撃者がある日「3s3s」を経由してのアクセスしたユーザに不正なスクリプトを埋め込むということをすれば、その瞬間からコンピュータウイルスに感染するというようなものに変更できなくはありませんが現在、各所で注意喚起されているものと
現在の「3s3s」の挙動は合致しない説明であると言えると思います。

ここまで書いてふと思い出したのですが過去にも似たようなことがありました。
昨年の4月11日にボクは以下のようなツイートをしています。

このつぶやきは、中国のドメインでフィッシングサイトらしきものが作成されているという注意喚起がされたときのものです。しかし、こちらも今回と似ているもので携帯電話でアクセスするためにサイトを携帯用に変換して表示してくれるサービスだったのでした。

また、このサイトを「3s3s」経由でアクセスしてみてソースコードを確認したのですが気になる表記がありました。下図の「blacklist.3s3s.org」の部分です。3s3s02

このアドレスにアクセスするといくつかのドメイン名とその管理者らしき方のメールアドレスが列挙されていました。試しにblacklistに記載されているドメインを入力してみたところ下図のようなポップアップが表示されました。
3s3s03

おそらく、「3s3s」にコンタクトを取りブラックリストに入れてもらうことでこのように対処してもらうことが可能なのでしょう。しかし、ポップアップにもある通り、OKを押すとすぐに「http://anonymouse.org/」にリダイレクトされました。
3s3s04

この「anonymous.org」も「3s3s」と似たサイトでここを経由して目的のサイトを閲覧するというものです。

だらだらと書いてきましたが簡単にいうと現在の「3s3s」は有害ではないと言えます。
どれくらい有害ではないかというと翻訳サイトで閲覧したいサイトのURLを打ち込むのと同様と考えていただければいいかもしれません。
参考までに下図はエキサイト翻訳のウェブページ翻訳で「http://n.pentest.ninja」を入力した結果です。
excitewebftans

日本に住んでいると検閲を受けてサイトをブロックされたりする機会はかなり少ないのであまりピンとくる方は多くはないのかもしれませんが、そのようなことが行われることが当たり前の国は世界中にあります。「3s3s」はそのような方のために作られたサービスなのかもしれません。
もちろん、普段から模倣サイトには気をつける必要があり、それと疑わしきものについては注意喚起すべきであるということにはボクも賛成ではありますが今回の件は「模倣サイトが作成されており、コンピュータウイルスに感染する恐れがある」といったような注意喚起そのものが不適切な表現であると言えます。とは言うものの「3s3s」側でも元のサイトと見た目に全く同じというわけではなく、元のサイトを表示するにはこちら。といったようなリンクなどをページ上部にでも表示してくれると親切設計で誤解を招きにくいのかもとも思いました。

今回の件で、正しく理解し、正しく伝え、正しく怖がるということの大切さを改めて考える事ができました。

ANAの「Webパスワード」導入で思ったこと。

2
Filed under memo


fly_01

全日本空輸(以下、ANA)から「Webパスワード」の導入に関する発表がありました。

これは、今まで数字4桁だったログインパスワード(と呼べる強度かどうかは別にして)から

任意の英文字(大小)と数字で構成する8桁以上16桁以下のパスワード

を設定できるようになるというものです。
実施開始予定は

2014年9月4日(木)午前 5:00(日本時間)より

とのことで

2014年12月3日まで

は案内、移行期間として

2014年12月4日以降

はこのポリシーの「Webパスワード」のみの利用に切り替わる予定だそうです。

設定できるパスワードと認証方法に関してはまだまだ万全というわけではなく

・使用できる文字種に「記号」を使えるようにする。
・設定可能な文字数を長くする。
・二要素(段階)認証を設定可能にする

など個人的には、改善の余地のあるものだと思います。

しかし、元々が数字4桁のみと脆弱極まりないと言えるものだったということもあるにはあるのですが
今回の「Webパスワードの導入」は大きな進歩だとも言えると思います。

ANAは、2014年3月11日、「ANAマイレージクラブ」のWebサイトに不正ログインがあり、
顧客9人のマイレージ・112万マイル(現金に換算すると、最大で65万円分)が「iTunesギフトコード」に不正に交換されていたこと発表しています。

この事実から以下のように考えることもできるのではないでしょうか。

65万円分の補填を行うことと、今まで数字4桁で構築してきたシステムを「Webパスワード」を設定できるように変更するコストを天秤にかけた場合、補填したほうが安い。(金銭的な)費用対効果を考えれば、決して誠意ある対応とは言えませんが、システムの変更を行わず、都度、補填を行うという選択をするという可能性も大いにあったのではないかと思います。

その中で改善点はまだまだあるものの
今回の選択をしたということは評価すべきことなのではないかと思います。

昨今、色々なところでセキュリティ事故が発生しています。
Web改ざん、不正ログイン、情報漏洩、サービス停止などなど。

もちろん、事故が起こるということは何かしらの不備があるからです。
それは、マイナスの評価をされて然るべきことだと思うのですが
その事故に対してどのような対応を取ったのかということは、事故を起こした事と別に評価すべきものではないかと思っています。

不正ログイン事故が発生した場合も可能な限りユーザに情報開示を行ったサービスと
そうではないサービスとでは違った評価がされるべきだと思っています。
前者は、きちんとプラスの評価をユーザもすべきだと思います。
その評価(マイナスだけではなくプラスの評価も)をTwitterなどでつぶやいてみることもいいと思います。地道かもしれませんが、そうした個々人のアクションがサービス提供側に伝わっていききちんと対応すれば、きちんと評価されるんだという空気が広がって良いサイクルが生まれていけばいいなって思います。

人は、誰でも誉められることは悪い気はせず嬉しいものだと思います。
そうすると「これでいいんだ。よかった。もっと頑張ろう」って思えるものだと思うんですよね。

今回のANAの対応を見て、ボクは「よくやってくれた!」と思いました。
今後、更なるレベルの向上も行ってくれることも期待したいと思います。

そして、今回のANAの対応を受けて
他のサービス提供サイトのセキュリティレベルの向上があると嬉しいと思います。

WordPressのPHPのXML処理の不備によりサービス妨害(DoS)攻撃が実行される脆弱性に関する検証レポート

0
Filed under exploit

【概要】
WordPressに、リモートよりサービス妨害(DoS)攻撃が可能な脆弱性が発見されました。

この脆弱性は、WordPress内のPHPがXMLを処理する際の処理に不備が存在するため、リモートよりサービス妨害(DoS)攻撃を受ける問題が起こります。
これにより、攻撃者はリモートからサービス妨害(DoS)攻撃を行うことが可能になります。それにより、利用者がWebサービスに接続し難くすることが可能です。
今回、この脆弱性の再現性について検証を行いました。

【影響を受ける可能性があるシステム】
■WordPress
– WordPress 3.5から3.9.2未満のバージョン

【対策案】
WordPress.orgより、この脆弱性を修正するプログラムがリリースされています。
当該脆弱性の修正を含む最新のバージョンを適用していただくことを推奨いたします。
WordPress > 日本語

【参考サイト】
JPCERT コーディネーションセンター Weekly Report
WordPress › 日本語 « WordPress 3.9.2 セキュリティリリース
WordPress >WordPress › WordPress 3.9.2 Security Release

【検証イメージ】
image_140813_01

 

 

 

 
【検証ターゲットシステム】
Windows Server 2012 + XAMPP for Windows 1.8.3 / PHP 5.5.11 + WordPress 3.9.1日本語版

【検証概要】
攻撃者が作成した細工されたリクエストをサーバに送ることで脆弱性を利用した攻撃を行い、対象サービスを遅延させ、結果、通常の利用者からのアクセスを妨害するというものです。
これにより、サービス妨害(DoS)攻撃が可能となります。

【検証結果】
下図は、攻撃後の誘導先のコンピュータ(Windows Server 2012)のタスクマネージャです。黄線で囲まれている部分は、攻撃を実行する前のプロセスの状態です。
bf_attack

 

 

 

 

 
 


赤線で囲まれている部分が、リモートから攻撃者が、サービス妨害(DoS)攻撃をを実行した直後の状態が表示されています。
af_attack01

 

 

 

 

 

 
 


Webサービスの遅延が発生し、ページの参照が待機状態になりました。
af_attack02

※ 今回の検証にはWindows OSを使用していますが、Linuxなどの環境でも同様の現象を再現することが可能です。

 

 

 

 

 

 

 

 

 

reported by y.izumita, nao323, ntsuji

OnionShare を使ってみました。

0
Filed under tool



先日、参加した「江戸前セキュリティ勉強会(2014/07)」のLTで@kitagawa_takuji さん が「OnionShare」というツールの紹介をしていましたのでボクも使ってみました。

「OnionShare」は、Tor Hidden Serviceを使ってファイルを共有する為のツールで、Torネットワークに接続した状態で共有したファイルを指定すると一時的なURLが生成されそのファイルが共有状態になります。そのURLを受け取る側に安全な方法で伝え、受け取る側はTorネットワークに接続した状態でブラウザを使ってそのURLを指定しダウンロードするという単純な仕組みです。

公式サイトはこちら
現在の対応OSは以下の通りです。
OS_version

/
【OnionShare起動】
予めTorネットワークに接続しておく必要があります。
(一番簡単な方法はTor Browser Bundleをダウンロードして、Tor Browserを起動することです。)
接続していない状態で「OnionShare」を起動すると以下のようなエラーメッセージが表示されます。
01

Torネットワークに接続した状態で起動すると下図のように共有するファイルの選択画面が表示されます。
02
ここでファイルを選択をしたら共有完了でURLが生成されます。



【共有とダウンロード】
下図が共有が行われている状態です。
03

ここで「Copy URL」ボタンをクリックするとクリップボードに生成されたURLがコピーされます。
また、「Close automatically」にチェックを入れていると接続してきた最初のユーザのみがダウンロードできるようです。
チェックを外している状態ですと自動でクローズされず、任意にクローズされるまではダウンロードし続けられるようでした。

コピーしたURLをTor Browserを利用して接続を行なうと下図のような画面が表示されます。
04
ここでファイル名のボタンをクリックすることでダウンロードが開始されます。

アクセスがあった際の「OnionShare」の画面はこちらです。
05
先程の画面から「Download page loaded」という通知が追加されていますね。
「Close automatically」にチェックが入っている状態だと、このあとウインドウが閉じられることになります。
そして、再度ブラウザでアクセスしても接続できないようになります。(終了しているので当然ですが)
06

また、チェックが入っていない場合は下図のように開きっぱなしとなり開いている以上、URLを知る人はダウンロード可能となります。
07

Torネットワークを使っているので速度的には若干のストレスはあるかもしれませんがルータの設定などを変更することなく手軽にファイルを共有できますし、ダウンロードされたことを知ることもできるので「◯◯に共有したのでダウンロードしたら消すから教えてね。」的なやり取りも必要ないためちょっとしたファイルを共有する際には便利かもしれませんね。肝としてはURLの受け渡しを安全に行う必要があるということでしょうか。

以上です。

SMBCダイレクト をかたるフィッシングサイトにひっかかってみました。

0
Filed under phishing



ということで今回も引っかかってみました。
まずは本物とニセモノ比較。

【本物】
00_trust_smbc

【ニセモノ】
00_smbc

いつものように見た目全く同じですね。
ただ、ソフトウェアキーボードを使おうとすると違いが見られました。

【本物】
sk_trust

【ニセモノ】
sk_fake

それでは適当な情報を入力して先に進んでみます。
ログインボタンから進むと乱数表の入力を求められます。
綺麗に横一列すべてですね。
02_smbc
この後、他の部分もすべて入力が求められました。
以前に書いた三菱東京UFJ銀行のフィッシングサイトと同じパターンですね。

ちなみにログインのところやこの乱数表入力のところどこかで入力せずに進もうとするとこんなページが表示されます。
nop

そして、乱数表の入力ラッシュが完了すると最後にここにリダイレクトされました。
lastpage
インターネットバンキングのトップページじゃなくてなぜか生命保険のトップページに… どうして?

今回のものはメールで以下のようはHTMLで来るそうです。
phi_ref
「本人認証サービス」と書かれたところをクリックすると一旦、HTMLファイルを経由して
当該フィッシングサイトにリダイレクトされるようになっていました。
その一旦経由するファイルのソースコードを見てみると

<meta http-equiv=”Content-Language” content=”zh-CN”>
<meta HTTP-EQUIV=”Content-Type” CONTENT=”text/html; charset=gb2312″>

とありました。
「gb2312」は、簡体中国語の文字コードセットですね。

ちなみに今回のサイトなのですがホストアドレスをIPアドレスに正引きしたものを再度逆引きしてみると日本のプロバイダのものになっていました。
踏み台にされていたりするのでしょうか。
dig

ちなみにこのサーバ上には「三菱東京UFJ銀行」「そな銀行」…じゃなくて、「りそな銀行」のフィッシングサイトもホストされていました。

以上です。

ウェブマネー をかたるフィッシングサイトにひっかかってみました。

0
Filed under phishing

ということで今回もひっかかってみました。

またまた、今回も自分のアカウントを持っていないサービスです。
というわけで早速、フィッシングサイトと本物のページを見比べてみましょう。

【本物】
trustpage_webmoney

【ニセモノ】
00_webmoney

ボクのアクセスしたタイミングのせいなのかもしれませんが【ニセモノ】はソフトウェアキーボードの画像がリンク切れを起こしていますね。
ちなみにリンク切れしている画像のURLにアクセスしてみた結果は下図です。
02_webmoney
IISのデフォルトエラーページですね。
このソフトウェアキーボードの画像が置かれていたと思われるサーバは「smarteraASP.NET」というホスティングサービスの会社でした。
ここだけ対処されたということなのでしょうか?

さて、ウォレットIDとパスワード、セキュアパスワードにあり得ない文字列を入力してログインボタンを押してみました。
01_webmoney
すると、【本物】のウェブマネーのトップページにリダイレクトされました。
以前にひっかかってみた銀行のフィッシングサイトとは違ってとてもシンプルなものですね。
意外とあり得ないほど乱数表を入力させるよりはこれくらいシンプルなほうが引っかかり易いとも考えられますね。
また、情報を盗んでからリダイレクトするなら見た目が同じの【本物】のログインページにしたほうが
ユーザは「入力ミスしたのかな?」と騙せるような気もしなくもないのですが
このフィッシングサイトは、どうして、わざわざ【本物】のトップページにリダイレクトしているのでしょうね。

ということで以下は今回のフィッシングに利用されたメールの本文です。

お客様
株式会社营团社サービスシステムをご利用いただき、ありがとうございます。
システムはお客様のアカウントが異常にログインされたことを感知しました。
下記のログイン時間を照らし合せてご本人様によるログインであるかどうかご確認お願い
します。

https://member.webmoney.ne.jp/

もし、ご本人によるログインでしたら、お手数ですが本メールの破棄をお願いいたします。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ウェブマネー ウォレット

■ウェブマネー ウォレットに関するお問い合わせ
サポートセンター(平日 10:00〜18:00 土日祝祭日を除く)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

(記載されているリンクは本物のURLですがクリックするとフィッシングサイトにアクセスするように細工されています。)

ここで気になったのは「株式会社营团社サービスシステム」という社名です。
この名前で検索すると過去に「スクウェア・エニックス」や「ハンゲーム」のフィッシングメールが送信されていたようです。
ちなみに「营团社」というのは日本語表記にすると「営団社」となります。
そして、エニックスの母体となった社名は「株式会社営団社募集サービスセンター」だそうです。

ボクも調べて初めて
感知しました!

以上です。

【2014/06/26追記 その1】
上記、フィッシングサイトを調べていたら同じサーバ上に
別のフィッシングサイトの設置を見つけてしまいました。
こちらはハンゲームのサイトです。

【本物】
00_hangame

【ニセモノ】
01_hangame
比べるまでもなくそっくりであります。
サイトの挙動も上記の「ウェブマネー」のものと同じでした。
また、faviconを比べてみたのですが「ウェブマネー」のときと同じfaviconですね。

【ウェブマネーのニセモノと本物のサイトのfavicon】
favi01

【ハンゲームのニセモノと本物のサイトのfavicon】
favi02

【2014/06/26追記 その2】
@NaomiSuzuki_さんに別の人(組織?)が運営していると思われる「ウェブマネー」のフィッシングサイトを教えていただきました。
こちらは先に紹介したものと違いソフトウェアキーボードの画像のリンク切れはありませんでした。
webmoney_comp

さらに、faviconもオリジナルサイトと同じものでした。
favicon03

また、認証情報を入力し、ログインボタンを押した時の挙動も前のものと異なっており
オリジナルサイトのトップページにリダイレクトするのではなく、オリジナルサイトのログイン画面にリダイレクトするようになっていました。
(つまり、見た目には同じページが再度表示されるということです。)