カテゴリー
Vulnerability

Web-based DNS Randomness Test。

 「(緊急)キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について」について記事を書いたときに, Web-based DNS Randomness Test についてギャンギャン言って,ギャンギャンいうだけじゃあまりにも無責任なので,サイトのアドミンにメールしてみたのだが,その返事が今日来た。

Hello!

Thank you for your note. The problem as you show is with the main website, but this isn’t replicated across the various websites that we have, including the DNS Randomness test, since that uses another website server with different versions of software. But in any case, I do really want to replace the certificate at least, besides updating a very old system that supports www.dns-oarc.net. Again thank you, we are working on this.

ということなので,私が送ったテスト結果はメインのサーバに関してのものだが,「DNS Randomness test は別の Web サーバでかつ別のバージョンのソフトで動いているから大丈夫ですよ」という返事だ。さらに,少なくとも証明書は置き換え,メインの www.dns-oarc.net が乗っかっているシステムも新しくするつもりだと付け加えてある。

 ということだと, Web-based DNS Randomness Test は,一応,大丈夫ということになるのかなと思うのだが,この返事を読んで別のことが心配になってしまった。彼が書いてきたことが本当だとすると, Heartbleed testHeartBleed Bug が,どういうチェックの仕方をしてくれているのかということだ。

 私のドメインで動いている Web サーバはたった1台の PC だが,通常は複数であるほうが当たり前だ。だから,当然,そのドメインでつながっているサーバをすべて調べて,1台でも変なのがあれば,警告を出してくれてるんだと思いたい。まさか,てっぺんに立っている代表だけを調べてるわけじゃないよな。

カテゴリー
Vulnerability

(緊急)キャッシュポイズニング攻撃の危険性増加に伴う DNSサーバーの設定再確認について。

投稿アップデート情報  追記  追記2(4/16)  追記3(4/16)  追記4(4/19)

 JPRS 様のおっしゃるところによれば,「(緊急)キャッシュポイズニング攻撃の危険性増加に伴う DNS サーバーの設定再確認について」なんだそうで,ございまする。

 DNS サーバーの設定についてのナンチャラカンチャラは,去年もイッパイあったが,先日の CVE-2014-0160 と手に手を取って,パーティやるっち,考えるだに恐ろしい。

 Web-based DNS Randomness Test てのがあるみたいなんだが。何の脈絡もなく,フッと,そのサーバ www.dns-oarc.net を Heartbleed test でチェックしてみたんよ。ほしたら, VULNERABLE かつ Please take immediate action! になったよぉ。えーーーっ。

 この世は,どうなっとんじゃ。

追記:
 テスト結果が 100% 正しいと言えないのは,百も承知だが, heartbleed test でのテストでも, www.dns-oarc.net は Server is vulnerable to all attacks tested, please upgrade software ASAP. という結果になった。どうすんのー?

追記2(4/16):
 www.dns-oarc.net で, DNS Randomness チェックするときにさ,何にも入力するわけではない。だから,個人情報なんかを抜かれるとは思わないが,しかし,これだけ HeartBleed Bug について大騒ぎしてるのに,こういうたぐいのサイトのアドミンが今まで対処していないことに,ガックリ来て,信頼できなくなっちまうわけよ。カミンスキー祭りなんかあって,みーんなが www.dns-oarc.net でチェックしたりすると,このサイトの脆弱性が巡り巡ってどこに影響するかわからないのが,ネットの世界だからなぁ。
 このガックリは,先のスラドのリンク先で見た,「なぜ Theo de Raadt は IETF に激怒しているのか」の Theo de RaadtIETF への怒りにも通じるところがあるような気がする。
 こーんだけ, HeartBleed Bug で大騒ぎしている最中に,警告を出した JPRS がその警告ページに www.dns-oarc.net へのリンクを貼るなら,直接関係はないにしても, HeartBleed Bug の対応が済んでるかくらい,チェックしてから貼んなよということだ。

 しかし,この件はどこにコンタクトをとったらいいんだろう。 admin at dns-oarc.net にメールしてみるかな。

追記3(4/16):
 「強烈なDNSキャッシュポイズニング手法が公開される」。
 「もうなんか,ついていけない」って,素人のつぶやき。上記のページやその中のリンクを見に行くと,どうすりゃいいんだという気になる。難しすぎてよくわからないところも多いが,一般の人も多大な影響を受けるということはよくわかる(出るのは溜息ばかり)。

追記4(4/19):
 上の追記2についてだが,今日,

Hello!

Thank you for your note. The problem as you show is with the main website, but this isn’t replicated across the various websites that we have, including the DNS Randomness test, since that uses another website server with different versions of software. But in any case, I do really want to replace the certificate at least, besides updating a very old system that supports www.dns-oarc.net. Again thank you, we are working on this.

という返事をもらった。私が送ったテスト結果は,「メインのサーバに関してのものだが, DNS Randomness test は別の Web サーバでかつ別のバージョンのソフトで動いているから大丈夫ですよ」という返事だ。さらに,少なくとも証明書は置き換え,メインの www.dns-oarc.net が乗っかっているシステムも新しくするつもりだと付け加えてある。

 ということなんだけどさ。だから, DNS Randomness test については,それなりに大丈夫ということになるのかな。

カテゴリー
everyday life

CVE-2014-0160関連で調べてみた。

投稿アップデート情報  追記(4/11)  追記2(4/16)  追記3(4/22)  追記4(5/13)

 通常取引のある https 関係を Heartbleed test で調べてみた。
  All good, yourCheck.domain seems fixed or unaffected!
と出れば,一応OKという扱いで。 100% の保証はないし,対処がいつだったかもわからないし,証明書関係を作り直しているかどうかもわからないし。と,いろいろ問題はあるが,本日,私が使った銀行,電話,ホスティング関係は,みんな「All good, yourCheck.domain seems fixed or unaffected!」が出た。とはいっても,いつから fixed or unaffected なのかはわからないから,心配は尽きない。 SSL のバージョンが古ければ逆に大丈夫なのだが,その辺は,一般人には調べようがない。

 それから, FFFTP についてなのだが,川本優さん(@s_kawamoto)のツイートで「脆弱性対応済みのFFFTP新バージョンを公開するにはまだしばらく時間がかかるため、可能であれば直ちにFileZilla(OpenSSLではなくGnuTLSによる実装)への移行をおすすめします」ということだったが,一応,暫定版は出ている。

 ものすごく,基本的なことがわかっていない自分に驚きなんだが, SSL 証明書の中には,もちろん, OpenSSL ベースじゃないものもあるわけで,どこの SSL 証明書が何を使っているかというのは,一般消費者側で確認可能なのだろうか。

追記(4/11):
 考えたら,証明書の期限は簡単に調べられるよね。現時点のわが取引先銀行,電話,ホスティング関係の期限をチェックしてみた。
  銀行  2013/06/04 – 2014/08/02
  電話  2013/11/12 – 2015/12/04
  ホスティング  2013/04/05 – 2016/06/04
 で,これは,どうなんだろう。正式の認証局が再発行する場合,新しくなっても期限は変わらないものですか。それとも,期限が上記の場合は,古いままだと思っていいんですかね。常識的に考えると,発行日は新しくなるべきだと思うんですが。もっとも,もともと OpenSSL での実装でない可能性も大きいわけだが……

 OpenSSLでメモリ内容を外部から読み取られる脆弱性が発見されるの皆の書き込みが,興味深い。クライアントの PC の ssleay32.dll も関係あるんだろうか。

追記2(4/16):
 脆弱性確認サイトのメッセージだけれども, heartbleed test のほうは,こんな感じ。
—– NG の場合 —————————————————————————————-
Looking for TLS extensions on https://YourCheckSite

ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check. Actively checking if CVE-2014-0160 works: Server is vulnerable to all attacks tested, please upgrade software ASAP. ----- Heartbeat の有効/無効の確認後, CVE-2014-0160 に対する脆弱性の判定,警告。----- ----- OK の場合 1 -------------------------------------------------------------------------------------- Looking for TLS extensions on https://YourCheckSite TLS extension 15 (heartbeat) seems disabled, so your server is probably unaffected. ----- Heartbeat の機能が無効なので,多分,大丈夫だろうという判定。--------------------- ----- OK の場合 2 -------------------------------------------------------------------------------------- Looking for TLS extensions on https://YourCheckSite ext 00015 (heartbeat, length=1) <-- Your server supports heartbeat. Bug is possible when linking against OpenSSL 1.0.1f or older. Let me check. Actively checking if CVE-2014-0160 works: Your server appears to be patched against this bug. Checking your certificate Certificate has been reissued since the 0day. Good. <-- Have you changed the passwords? ----- Heartbeat は有効だが,パッチ済の判定。証明書も再発行済,パスワードは変えた?の確認。---- でもって, Heartbleed test のほうは,こんな感じ。
—– NG の場合—————————————————————————————–
YourCheckSite IS VULNERABLE.

Here is some data we pulled from the server memory:
(we put YELLOW SUBMARINE there, and it should not have come back)

([]uint8) {
00000000 02 00 51 68 65 61 72 74 62 6C 65 65 64 2E 66 69 |..Qheartbleed.fi|
00000010 6C 69 70 70 6F 2E 69 6F 20 59 45 4C 4C 4F 57 20 |lippo.io YELLOW |
00000020 53 55 42 4D 41 52 49 4E 45 20 59 6F 75 72 43 68 |SUBMARINE YourCh|
00000030 65 63 6B 53 69 74 65 3A 34 34 33 F7 96 BF F3 35 |eckSite:443....5|
00000040 87 38 54 6A 02 66 02 4E AF 02 B5 1A 32 A6 61 08 |.8Tj.f.N....2.a.|
00000050 2C CF 2E 0C 4C F3 B7 92 C0 86 E7 86 B0 94 88 A7 |,...L...........|
00000060 0A |.|
}

Please take immediate action!
—– 脆弱性あり。当該サーバメモリから filippo.io が置いたデータを引き出し可能。これは,まずい。—–

—– OK の場合 ————————————————————————————–
All good, YourCheckSite fixed or unaffected!
—– チェック結果は全部 OK だったので,多分,大丈夫だろうという判定。——————————————–

追記3(4/22):
 昨日付で,「国内でもOpenSSL「心臓出血」が悪用、三菱UFJニコスから894人の情報流出か」が出てた。三菱UFJニコス自体のニュースとしては,12日18日の発表である。私のカードも関連があるので気になったのだが,今のところは,大丈夫そう。

今回問題になっているheartbeat機能によるやり取りは、通常、Webサーバーのログには残らない。このため、悪用した攻撃を受けているかどうかが分からないことが、今回の脆弱性の特徴の一つ。三菱UFJニコスでは、今回の攻撃は「心臓出血」脆弱性を悪用したものであることを特定したとしているが、特定した方法についてはコメントできないとしている。

 ITpro の記事内に上記の引用の表現があるのだが,特定の手段があるなら,教えてほしいもんだよな。公表しても,一般ピーポーにはつかえない特別なシステムがいるのだろうか。または,知られたらすぐに対策されちまうレベルの方法とか???

追記4(5/13):
 まだまだ,後を引きそうだねぇ。セキュリティホールmemoさんも,昨日スマホに関しての追記を書かれていた。

 The list of Android phones vulnerable to Heartbleed bug というのもあったんだが,日本語サイトでは,あまり一覧というのがない気がする。 GALAXY のサイトなんかでも,更新ファイルはあるがその辺の情報にはそれほど触れていない。更新開始日が,4/17とかになってるから間違いなく, HeartBleed 関連だと思うんだけどな。もっとも,スマホ利用の一般ユーザにとっては,スマホ本体にどれだけはっきり,この手の要アップデート情報が届くかのほうが,大事だろう。自分がいまだにスマホを使っていないので,その辺がどうなっているのか不明。身近の Amdroid 使いはあまり何も言っていないけどな。実際のとこ,どうなんだろう。

 Google App としては,だいぶ前から, Heartbleed Detector があるが,本人が調べる気になるかどうかが問題だからなぁ。

 再度, PC でのチェックサイトを掲載しておく。
     Heartbleed test
     heartbleed test
     Trend Micro Heartbleed Detector (無くなっちゃったみたいだ)

カテゴリー
Vulnerability

CVE-2014-0160って?

投稿アップデート情報  追記3(4/16)

 CVE-2014-0160 ってことで,対処としては, secadv_20140407.txt ということらしいんだが, ApacheLounge 版の場合,もとが IPv6 Crypto apr-1.5.0 apr-util-1.5.3 apr-iconv-1.2.1 openssl-1.0.1f zlib-1.2.8 pcre-8.34 libxml2-2.9.1 lua-5.1.5 expat-2.1.0 になってるんでどうすりゃいいんだと思って, News & Hangout にお願いを書こうと思っていったら,もうあった。
     Critical Security Vulnerabilty: Upgrade to OpenSSL 1.0.1g

 すぐに,出るかな? openssl-1.0.1g のやつ。 The Heartbleed Bug を見ると,かなりヤバそうなんだが。パッチが出るまでの対処方法がわからないよぉ。

 チェットサイトが作られてた。 Heartbleed test
 同じくテストサイト。 heartbleed test

 当面,ポートを閉じておくことにした。うちの場合は,ユーザは私だけだから,私が不自由に耐えれば,無問題(爆)。@19:00

追記:
 「本家のお世話-#99。(CVE-2014-0160 に対処のため Apache のアップデート)」をやりやした(爆)。当然,ポートも元に戻したヨ。
 うちは,これでいいとして,「母さん、私達のあの証明書、どうするんでせうね?ええ、ずっと前からから世界中にばらまかれている、 SSL のあの証明書ですよ。」ナンチャッテ。とっても,心配。

 証明書自体は大丈夫なのかな?いまんとこ,情報は錯綜しているようだが……

追記2:
  The Heartbleed Bug を読み直してみた。やはり,証明書は作り直しておこう。

追記3(4/16):
 SSL Server Test というのもある。 CVE-2014-0160 だけではなく,証明書の全体的レベルを調べてくれる。このサイトは Heartbleed Bug への対応はできている。ただし,証明書の 0day 後の再発行はされていないようだ。

カテゴリー
WordPress

「シンボリックリンク攻撃のデモ」だってサ。

 「シンボリックリンク攻撃のデモ」をやるかもしれないってさ。徳丸さんとこの「マイナビのセミナーにて講演します」に書いてあった話。まぁ,ご自分の講演の告知だから,宣伝ちゃ宣伝だけど,近くだったら聞いてみたいよなぁ。

 申し込みのページには,「※競合企業や同業他社の方は参加をご遠慮いただく場合がございますのであらかじめご了承ください。」という注意書きがあるから,競合企業や同業他社の方で行きたい方は気をつけてねー。何の注意をしとるんじゃ(笑)。

 「シンボリックリンク攻撃のデモ」って,元ネタは絶対に,これ,でしょ。しかし,こういうことって対岸の火事じゃないからね。参考になりそうなことは聞いてみたいよなぁ。

 まあ,距離的に,聞きに行くってのは無理だよなー。

カテゴリー
everyday life

笑っちゃいけないけど……

投稿アップデート情報  追記(2/6)

 笑っちゃいけないし,笑いごとじゃないけど,やっぱり笑っちゃった件。以下,順不同に羅列。

 最後の記事については,さすがに追記がついているのだが,どうなるのかなぁ。 ANA については,我が家もマイレージを使っているけど,そっちも変わりますかー⤴。

 しかし,セキュリティの話って,いくら口を酸っぱくして説明し,口角泡を飛ばしても,聞いてるほうにその気がなければ,屁の突っ張りにもならないという明白な証左だね。その辺は,私ごとき辺境の住人でも,いつも「困ったもんだ」って件なんだけどサ。

追記(2/6):
 この件関連で,徳丸さんのところに,架空インタビュー仕立ての記事が載った。GitHubに関する話なども再引用されてて,なかなか,ためになる。JALの不正ログイン事件について徳丸さんに聞いてみた

カテゴリー
everyday life

ハーーァ。

 レベルは違うけど,いろいろ「ハーーァ」な話を順不同で列挙。列挙というと辣韭と書きたくなっちまうなぁ。 —> 我ながら,アホだね(汗)。

 正月でバタバタした後,寝込んだせいでいろいろセキュリティネタを書く元気がないので,あちこちチラチラ見ながら「ハーーァ」と溜息をついている始末。ハーーーーーーーァ。

カテゴリー
Vulnerability

CVE-2012-1823

The same article in English

 「さくらのVPSに来る悪い人を観察する その2」と「SSH ハニーポットでの悪い人の観察」を見て大笑いした。徳丸さんところで見つけて,彼が「抱腹絶倒のスライド資料」と書いてあったので,確認のために見に行ったのだが,なるほどだった。

 CVE-2012-1823 関連のスライドショーである。実際のとこ,スライドナンバー 36 で示されているアタックは,どこにでもやってくる。脆弱性があるかないかなんてお構いなしだ。そんなわけで,うちも例外ではない。現サーバ構成には, SSH は含まれていないし, PHP も当該脆弱性とは関係なく CGI 版でもないから,大きな被害は免れているだけだ。しかし,攻撃数が多いときに,管理者(私)が頭に来るという被害は常にある(爆)。

 Ozuma5119 さんなんかは,真の white hacker といえるね。興味があったら,リンク先を訪問してみてください。

カテゴリー
everyday life

こんなことがあっていいのか。

The same article in English

 今月20日に, Reuters が “Exclusive: Secret contract tied NSA and security industry pioneer” というすっぱ抜きをやった。 23 日には,ミッコ・ヒッポネン が “EMCおよびRSAのトップ達への公開書簡” を書いた。

 こんな話を信じたくはないが,ミッコがこんなものを書くということは,あらかた真実なんだろうと思わざるを得ない。 NSA にとっては,ある意味正規の仕事をやったにすぎないと言えないこともないが, RSA のほうからいうと恥を知ないにもほどがあるということになる。もちろん,片方の側の記事を読むだけでなく,反対側の記事,例えば NSAとの関係に関するメディアの主張に対するRSAの対応 (魚拓です)なんかも読まなければいけない。

 しかし,一番悲しいことは, RSA への信頼が損なわれたということである。

カテゴリー
WordPress

WordPress に BulletProof Security を入れてみた。

The same article in English
投稿アップデート情報  追記(12/2)~~追記4(2014/7/14)  追記5(7/16)

 WordPress のセキュリティ強化のために「BulletProof Security」というプラグインを入れてみた。インストールは簡単だが,有効化するについては,いくつか気を付けたほうがいいところがある。

  1. Network / Multisite 上で使用可能なプラグインだが,「ネットワークで有効」にしてはいけない。「ネットワークで無効」のまま,親サイトでだけ有効にする。
  2. BulletProof Security は .htaccess を使うので,当然ながら,サイトの .htaccess が書き換えられてしまう。前もって, WordPress ルートと wp-admin 内の .htaccess をバックアップしておこう。
  3. .htaccess を利用するので, BulletProof Security が自分の WordPress で使えるかどうかは,サーバのコンフィグ次第ということだ。うちの場合だと,途中でエラーが出たので, Apache のログを見て, httpd.conf の <Directory> にある AllowOverride ディレクティブOptions=Indexes を付け加えた。

 ところで, BulletProof Security のページで, Sucuri SiteCheck Scanner を見つけたので,スキャンしてみた。怖いものは見つからなかった。まあ,「Sucuri SiteCheck は無料のリモートスキャナです。できる限り正確な情報をお届けできるように努めていますが,スキャン結果に間違いがないことを保証するものではありません。」てスキャンのサイトに書いてあったけど,それは当たり前のことだから。

追記(12/2):
 なんか ‘Broken Link Checker’ プラグインが下記のメールをくれましてん。自ブログの存在するファイルのことなので,ビックリ。

   Broken Link Checkerは、あなたのサイトに新しいリンク1がリンクエラーと検出されました。
   リンクエラーの一覧 :
   リンク テキスト: Asus ,HCL X51C (T12C) Motherboard schematic
   リンクのURL : /blog-j/files/Asus_HCL_X51C_(T12C).pdf
   ソース : ノートをWin8 Proにアップグレード。
   すべてのリンクエラーを見ることができます: http://ダッシュボードのツールの URL

 何で,どうして??? 10/16 にアップロードしてから全然変えてないし,とか思って,ブラウザからアクセスしたら,別のエラーが出た。こんなの:
   o6asan.com 403 Forbidden Error Page
   If you arrived here due to a search or clicking on a link click your Browser’s back button
   to return to the previous page. Thank you.

 調べたてみたら, ‘BulletProof Security’ プラグインが吐くものだった。さらに調べて ‘BulletProof Security’ は,ファイル名に ( ) があると拒否する設定になっていることがわかった。何かセキュリティ上でまずいことでもあるのかな。

 安直に, Asus_HCL_X51C_(T12C).pdf を Asus_HCL_X51C-T12C.pdf に変えて解決 (^_^;)。

追記2(12/3):
 早速,Version:.49.7 へのアップデートがあり,使えないと書いたばかりの「ネットワークで有効」ができるようになった。もちろん,前のままの方式でも使える。
 追記(12/2)の補足だが,ファイル名に半角空白が入っているのもダメなようだ。

追記3(12/4):
 なんか毎日ここに追記書いてるよー(苦笑)。 ‘BulletProof Security’ 君,今度は,わがサイトの Flash Movie をブロックしてやんの。お蔭さんで,高住神社のなんかで,「ムービーが未ロード」とか出た。ご本尊の Adobe Flash Player がらみでもよくある話なんで,疑っちゃったじゃないの,今回は無実なのに-ハハ。
 解決方法は, Flash swf 403 error – Flash slideshow blocked で,どんぴしゃり。 Root の .htaccess に我が家の swf を足してやった。こんな感じ。太字のイタリックですね。
   RewriteRule .* index.php [F,L]
   RewriteCond %{REQUEST_URI} (flvplayer.swf|timthumb.php|~~|thumbs.php) [NC]

追記4(2014/7/14):
 最近気づいたんだが,サーバのログにかなりな数の 500 Internal Server Error が出ていた。しょっぱなの見た目では, font-face の IE 用ハックのせいに見えた。しかし,最終的にわかったのは, BPS の .htaccess の フィルターから来ているということだった。 URI の最後に ? があるとまずいようだった。それで, WordPress 日本語フォーラムと BulletProof Security Free フォーラムに相談に行った。おかげで,無事,解決。パチパチ!!

 より詳しい話は,相談先の下記2サイトをご覧ください。
   IE11(Win8.1),IE10(Win7)で,アクセスしたとき,font.eotについてエラーがでる。
   font-face 500 Internal Server Errors

追記5(7/16):
 我が家の http_error_log.txt には,うちのサイト関連の 403 Forbidden Error がズラッと並んできた。 Broken Link Checker が HEAD メソッドを使うせいである。 Broken Link Checker が HEAD メソッドを使うんだということは 2012.12.29 の TODOS の話題で知っていたが,両プラグインとも使い続けたかったので,あきらめて事態を受け入れていた。どうすりゃいいのか,わかんなかったし(爆)。

 ところが,今回 500 Internal Server Error の件で, .htaccess を覗いていて,下記の文言を発見。ワォッ!!
# REQUEST METHODS FILTERED
# This filter is for blocking junk bots and spam bots from making a HEAD request, but may also
# block some HEAD request from bots that you want to allow in certain cases. This is not a
# security filter and is just a nuisance filter. This filter will not block any important bots
# like the google bot. If you want to allow all bots to make a HEAD request then remove HEAD
# from the Request Method filter.
# The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against
# your website.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F,L]

 これって,こっから, HEAD を消しちゃっていいってことだよね?早速,ルートの .htaccess から HEAD を消した。 wp-admin のほうは,そのまま。 Broken Link Checker はここで HEAD をやる必要ないからネ。

 思惑通り,ことは進んでいる (*´▽`*)。