カテゴリー
Windows

マイクロソフト セキュリティ アドバイザリ (2718704)

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

 まぁ,参っちゃいますねぇ。Microsoft 自身が発行した証明書が悪用されたらしく,その対応としてマイクロソフト セキュリティ アドバイザリ (2718704)が出ました。世も末じゃ。

 自動更新にしていればもうパッチが当たっているはずですが,更新プログラムとして,KB2718704があるかどうか,一応確認してみましょうね。あったら,O.K. ない場合は,Microsoft Updateを利用しましょう。それでもうまくいかない場合は,Unauthorized digital certificates could allow spoofingに行って,自分のOSに対応するものをダウンロードしてインストールしましょう。英語のページですが,ダウンロードファイルそのものは,言語別になっているので,落とす前に,日本語にしてから落としましょう。

 関係あるのは,
     Microsoft Enforced Licensing Intermediate PCA (証明書 2 つ)
     Microsoft Enforced Licensing Registration Authority CA (SHA1)
ということらしいので,結構あちこち影響あるのじゃないでしょうか。マイッタマイッタ(爆)。

追記(6/9):
 こういう悪夢の元だってことだよねえ。今回は,対象がちょっと別次元だったので,一般人はなんとか最悪のシナリオをまぬかれたってことらしい。

カテゴリー
Windows

MS12-004 – 緊急

 ちょっと出遅れたけど,CVE-2012-0003の件です。MicroSoftのページでいうと,MS12-004 – 緊急

 WindowsUpdateの自動更新を有効にしている場合には,疾うにパッチが落ちていると思うが,自動更新にしていない場合は,早急にあてたほうがいいと思う。

 何しろ,Windows Media Playerに関係する脆弱性だから,痛い目を見る可能性もあるかもしれない。(爆)

カテゴリー
WordPress

本家のお世話-#23。(WordPress3.3.1へアップデート)

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

 1/4にWordPress 3.3.1 セキュリティおよびメンテナンスリリースが出て,ページを見に行ったら,その日は日本語版は今準備中ですのでしばらくお待ちください,とのことだった。

 で,1/7の今日になっても,ダッシュボードのアップデートのところに,日本語版の情報が表示されない。XSSの脆弱性の修正も入っているというアナウンスだったので,気になって上記のページを再度見に行ったら,WordPress 3.3.1 日本語版をダウンロードのリンクが追加されていた。いつ追加されたんだと,ファイルをダウンローダで引っ張ってみたら,ファイルそのものの日付は,1/4のようだ。ということは,珍しくもダッシュボードのアップデートには,情報が出ないということなのだろうか。

 まあ,たまには,手動もいいじゃないのというわけで,久しぶりに手動でアップデートをやってみた(爆)。

 まず,何はさておき,元ファイルとデータベースのバックアップをする。やらなかったときに限って青ざめるようなことが起こるので,絶対にサボってはいけない作業である(笑)。

 その後,落としてきたzipを展開してファイルの差し換え。無事完了。不具合なし。

 手動でやらなかったら気づかなかったこと。フィード関係の以下の6個がなくなっていた。
    wp-atom.php
    wp-commentsrss2.php
    wp-feed.php
    wp-rdf.php
    wp-rss.php
    wp-rss2.php

追記(2/1):
 XREAのフリースペース。で書いたように,XREAにWordPressをインストールしてシングルサイトを作った。今日気づいたのだが,こっちのサイトでは,ダッシュボードの「WordPressの更新」のところに WordPress3.3.1–ja の情報が出ている。本家との違いは本家はマルチサイトということだが,もう一つ違うのは,本家の親サイトの言語が英語になっているということだ。インストールしたファイルそのものはどちらも同じ日本語版なので,更新情報が親サイトの言語設定に引きずられて表示されているのではないかと思う。
 親サイトの言語設定を変えてみれば,検証はできると思うが,設定を変えて本家がおかしくなるのが怖いので未検証である(爆)。

カテゴリー
everyday life

Amazonのデジタル証明書の表示方法。

 一昨日書くつもりだった記事が,サイト移転に手間取ったせいで今日になってしまった。でも,書いておきたかった件なので,やはりアップしておこう。

 今回,DigiNotarの不正証明書発行による被害の話の関係で,仕事のときに個人情報保護のためにSSLで通信しようと私的デジタル証明書を作ったときのことを思い出した。

 私的というのは,公的機関の証明を受けていないということで,SSL通信の効果としては何も問題はない。もちろん,安全についての注意すべき点も,公的ものと同じだ。ただ,零細で斜陽の勤め先だったので,公的機関(例えば,VeriSignとか―こっちは今のところ問題は報告されていない―今回問題になったDigiNotarとか)で証明を受けるための予算を出してもらえなかった。使ってもらう相手先もだいたい決まっているので,使用開始の前にオフラインでお願いをすることにしていた。

 で,実際に相手先にお願いをする前に,同僚に使い勝手を試してもらったのだが,事前にかなり詳しく説明した(口頭でだった。これが問題だったかも。)にもかかわらず,明朝の報告で通信はできたが,私が言ったようなメッセージは出なかったといった人がひとりいた。実際に,仕事場で私が手順通りにやって見せ,警告画面ってこれのことだよと指摘すると,そういえばそんなのあったという話になった。

 私的証明書だと必ず警告が出るはずだが,それでも上記のように気づかない場合もある。しかもこんなのが出るよと口を酸っぱくして念押ししていてさえだ。無意識に,マウスで「はい」をクリックしていってしまうのだ。ブラウザによってメッセージの出方が違うのも問題だ。バージョン違いだけで様子が違うこともある。
 ましてや,WindowsUpdateなどで知らないうちにインストールされているルート証明書の場合だと,存在すら知らない人が結構多いだろう。
 今回,気をつけなさいと言われても何に気をつけるんだと困っている人も多いかもしれない。今どきだから,オンラインショッピングなどをすることは多いだろう。だから,実は,デジタル証明書のお世話になっているんだが,気づかずに使っているってことだ。

 というわけで,今日はデジタル証明書ってこんなものなんですよという話を,Amazon.co.jpを例にしようと思う。しかし,初めから問題があるんだ。さっき書いたようにブラウザごとに表示のしかたが違う。ブラウザ全種について説明するなんて不可能だから,「なんとかのツッパリ」にもならないかもしれない。まぁ,でもやらないよりはいいだろうという程度。他のブラウザの方は,頑張って自力でやってみてください。
 それから,ブラウザとしてはインターネット・エクスプローラの利用者が一番多いだろうからこれで行くが,我が家には,バージョン8しかないので,ご了承願う。

 前置きはこのくらいにして―相変わらず長いという突っ込みは無し!!―本題に入る。画像のアップの都合上横幅を狭くしているので,気をつけてほしい。

  1. http://www.amazon.co.jp/にアクセスすると,図1のようなページが表示される。(1)のところがhttp://になっていることを覚えておいてほしい。
  2. Amazonで買い物をするにはサインインをする必要がある。先に品物を選んで,後にサインインという人も多いだろうが,今回の場合は,すぐにサインインボタンを押してみよう。すでにAmazonのアカウントを持っている人は(2),初めての人は(3)をクリックする。実は,どちらをクリックしても現れるページは同じである。
  3. クリックすると,図2のように「セキュリティの警告」窓が現れる。過去のどこかの時点で,図2の赤丸の部分にチェックを入れてOKをクリックしたことがある人は,これが出ずに図3の画面になる。警告画面が出た人は,赤丸のところはチェックを入れないままにしておこう。そして,OKをクリックする。図3の画面になる。(4)のところがhttps://になり,(5)のところにカギマークが現れたことに注意。
  4. 次は,このカギマークをクリック。図4のように「Webサイトの認証」窓が現れる。ここでは,「VeriSign」という会社がwww.amazon.co.jpを認証している。(6)をクリックすると,Windows Internet Explolerのヘルプのページが現れ,ここにはサイトの信頼性を判断する方法が列記されていてとても大事なのだが,今回は信頼性のチェックではなく,証明書を表示してみるのが目的なので,(6)ではなく(7)をクリックする。
  5. パッと新しい窓が開く。これがデジタル証明。(図5)
  6. 「全般」「詳細」「証明のパス」とタブが3つある。各タブを押して内容をみてほしい。この証明書が通信を暗号化して安全を図り,そのおおもとの認証がVeriSignのものであることがわかる。
  7. これがあるからと言って絶対安全というわけではない。この記事の初めの方に書いたが,この種の証明書は私のような個人にも作れるのだ。ただ,その私的証明書の場合は,VeriSignのような会社の認証はついていない。親しい人とSSLを利用してより安全な通信をしたければそれでもかまわないが,Amazonのように不特定多数のお客様と取引したければ,どこか信用あるところに認証してもらう必要がある。それがこの場合,VeriSignなのだ。

 

 

 

 

 こう書けば,VeriSignと同種の会社であるDigiNotarが引き起こしたことが大変に困ったことで,しかもその規模がわからないということは,深刻な事態だということがわかる。各ブラウザのベンダーが,DigiNotarの証明書が使えないように,アップデートで素早く対応したことも納得できると思う。

追記(9/11): 次記事に書き足りないと感じたことを書きました。

カテゴリー
Vulnerability

PHPやらApacheやら。

投稿アップデート情報  追記(8/28) 追記2(8/29) 追記3(8/31) 追記4(9/16)

 Apache Killerの件のパッチはいつになったら,出るんだろう。Apache HTTPD Security ADVISORYの記事の最初の時刻は,8/24 16:16:39 GMT(日本時間8/25 00:16:39 だっけ。イギリスはまだ夏時間だよね。)になっていて,48時間でパッチを出したいと書いているのだが,8/26 10:35:31 GMT(日本時間8/26 18:35:31)の記事では,あと1日みたいなことを書いてある。もうすぐ経過するよね。今度は出るだろうか。

 こういうことって,素人に毛の生えたようなサーバ管理者(もちろん自分のこと!! こんなところで威張ってどうするんだ―爆)には,頭痛の種。どうすればいいかよくわからん。Bug 51714からDoS Exploit for mentioned vulnerabilityを落として試してみようとしたら,バスター君の異議で落とせなかった。ブラウザで見るだけでなく,ダウンロード自体ができない。この辺を弄るのも面倒なので,やめることにした。

 Apache LoungeのWarning Security issue :: DoS attack with range requests !のSteffenの書き込みにしたがって,手当てをしておくべきだろうか。うちのような零細なところに故意に攻撃してくるとは思えないけど,「下手な鉄砲も数撃ちゃ当たる」でバカなことをやる頭の悪いハッカーがいたら,流れ弾に当たらないとも限らない。どうせ今まで,おどおどしながら手をこまねいていたんだから,パッチが出るのを待っていようかな。modsecurity_crs_20_protocol_violations.confを利用するのなら,あんまりよくわからなくても手当てだけはできそうだから,やっぱりやっておこうかな。

 しかし,この間のPHP ver.5.3.7のとんでもないバグといいい,こういうことがあるときには続くものですね。

追記(8/28):
 結局,24時間以上たっても,正規のパッチは出ていないもよう。
 ということで昨日,やっぱりやっておいた方がいいかなと思ったことについてだけど,徳丸さんが,
     訂正:mod_securityのCore Rule Set 2.2.2に含まれるApache Killerルールは
     とても効果があるけど、Rangeヘッダのみの対応で、Request-Rangeヘッダには
     対応していないので、他の回避策をとった方が良さそうですね
とつぶやいておられたので,どうしたらいいかなと思いつつ寝た。朝,Twitterを見に行ったら,日記を書いたとつぶやいておられたので,早速見に行った。さすがに徳丸さんで,詳しい検証付きで「Apache killerは危険~Apache killerを評価する上での注意~」を書いておられた。

 徳丸さんは,Apache2.2系を使っておられるとのことなので,この記事を参考に,httpd.confを手直しした。いつも,お世話になります(拝)。あまりにも常識なので,徳丸さんが書いていないことの備忘(汗)。
     LoadModule headers_module modules/mod_headers.so のアンコメント。
     Apacheの再起動。
と思ったら,再起動については,Twitterでつぶやいておられた(爆)。

追記2(8/29):
 パッチはまだ出ていない。Apache Killer (CVE-2011-3192)には,「はっきりと攻撃元のログが残ってしまうので、むやみに撃つのはやめたほうがいいかなと思います。」と書いてある。(笑)

追記3(8/31):対応のApache 2.2.20が出ました。

追記4(9/16):
 アパッチ本家で2.2.21(released 2011-09-13)が出ました。2011-09-14 06:06リリースのCVE-2011-3192.txtがこの件のADVISORYの最終版のよう。
 Loungeでも,Apache 2.2.21 releasedということらしいです。9/8にサイトをXREA+に移したため,サーバのセキュリティアップデートが喫緊の課題でなくなったため,書き込みが遅くなってしまいました。「対岸の火事」と思うと対応がいい加減になるという典型です。お粗末。

カテゴリー
WordPress

WordPressのテーマでゼロデイだって?!

 なんか,TwitterでScottが「WordPressのテーマでゼロデイだって」とつぶやいていた。時差はあるとはいえ,日付は2日になっているのに,Twitterをほとんど見ないので,今気づいたという体たらくなんだけど,チェックしてみたら自鯖のWordPressについては,問題なかった。

 XREAのほうの「ネットワークの作成」で使っているテーマを調べたら,「delicate」がthumb.phpという名で問題のtimthumb.phpを使っていたので,脆弱性を回避するための方法として書かれていたように,
    $allowedSites = array (
     ‘flickr.com’,
     ‘picasa.com’,
     ‘blogger.com’,
     ‘wordpress.com’,
     ‘img.youtube.com’,
    );
のところを$allowedSites = array ();に直した。/delicate/cacheにも,/tmpにも,幸いにして怪しいファイルはなかった。もし,ハックされてるかどうかは,WordPressのインストールディレクトリで,base64_decodeのあるファイルを確認する。base64_decode関数の括弧内にエンコード・ストリングの長いのが見つかったら,多分ハックされてるって。

追記:
 「セキュリティホール memo」さんでも報告があっていた。

追記2:
 A secure rewrite of timthumb.php as WordThumb (魚拓です) を読んでて気になったので,縦書き集のcURL関数に, curl_setopt ($curl, CURLOPT_TIMEOUT_MS,5000); を追加。PHP5.2.3未満,cURL7.16.2未満だと,CURLOPT_TIMEOUTじゃないと使えないだろう。value の適切な設定値が分からないので一応5秒に設定。

追記3(8/6):
 今回の脆弱性の修正が施されたTimThumb 2.0がリリースされた。
http://timthumb.googlecode.com/svn/trunk/timthumb.php ☜ Google Code のサービスの終了とともにリンク先も消えたので,今掲載しているのは,魚拓である。新しい TimThumb のリポジトリは GitHub にあるようだが……。(2016.5.13 追記)
で配布されている。私は,まだ未検証。帰宅後,試すつもりです。

追記4(8/6):
 帰宅後,試すつもりと書いたのだが,帰ってきてXREAのWordPress3.2にアクセスしたら,早くも,Delicateのバージョン: 3.4.4の通知が来ていた。早速アップデート。したのち,確認したら,thumb.php,custom-thumb.php,cacheがきれいさっぱりなくなっている。えーっ,それはないよ。timthumb.php ver.2.0が試せないじゃん。テストサイトだから,そんなとこまでローカル・バックアップ取っていないし。アップデート前に試してみるべきだった。アチャーッ。

カテゴリー
everyday life

Passwords Resetの話。

投稿アップデート情報  追記(2017/1/24)

 事の発端は,Wordpress file monitor plus1.2である。
 21日に,Scottから,「Wordpress file monitor plus1.2をリリースしたよ」というメールをもらったので,早速,ダッシュボードからアップデートしてみたら,約束通り,日本語ファイルを同梱してくれていた。もちろん,アップデート直後のファイル名は,wordpress-file-monitor-plus-ja_JP.moになっているから,FTPでアクセスしてwordpress-file-monitor-plus-ja.moに名前を変えないと有効にはならない。
 Forumsを見に行ったら,この間問い合わせたことを踏まえて,「デフォルトではWordPressの時間設定に従うけれど,各自で好きなようにいじれる」と書いてあったので,「どっからいじればいいの?」と問い合わせたら,「この次のバージョンにはテーマのfunctions.phpから設定できるようなフィルタを設置する」という返事が来た。その投稿に例として載せてくれていたコードをfunctions.phpに書き込んだときに,うまく使えなかったので,もう一度問い合わせをしようとしたのだが,WORDPRESS.ORGにログインしようとしたら,図1が表示された。ところで,うまく使えなかったのは,すごーく初歩的なことを忘れていたせいだった(恥)。
 ログインに関しては,(1)の[Recover Password]のボタンをポチッと押して,パスワードを再発行してもらった。しかし,当然ながら何で全部のパスワードをリセットしなくてはいけなかったのかは気になるわけで,書き込みが終わってから(2)の[we reset all passwords]のリンクを押して何を書いてあるか見に行った。読み終わってから,ふと気づいたんだけど,使っていたパスワードはWORDPRESS|日本語でもらったもんだから,それを再発行してもらわなければいけないということは,当然,WORDPRESS|日本語にも記事はあるはず。ということで,そちらを見に行ったら,やっぱり,あった。パスワードリセット(図2)。
 こういう訳なんだ。どこにでも,こういう危険はあるので,サーバの管理はしっかりやらないといけないなぁと,改めて思うわけ。今回のことがWordpress file monitor plusの件がらみで起こったことに,因縁を感じるなぁ。だって,WPFMPはサーバ上のファイルの改変を教えてくれるプラグインだからねえ。

追記(2017/1/24):
 WordPress File Monitor Plus は開発終了の模様。 Fork として WordPress File Monitor があるのでそちらを使うといいと思う。

カテゴリー
WordPress

WordPress 3.1.1 日本語版にアップデート。

 2.28(月)にWordPress ver.3.1ラインハルトの日本語版にしたばかりなんだが,昨日,マイナーバージョンアップがあって,3.1.1になった。本家版は4.5(火)に出た。スパンが短いのは
=================================================================================
このメンテンナンスおよびセキュリティリリースでは、バージョン 3.1 にあった30件弱のバグを修正しています。以下で一部をご紹介します。

* メディアアップロードに関するセキュリティ強化
* パフォーマンス向上
* IIS6 対応のための修正
* タクソノミーおよび PATHINFO (/index.php/) パーマリンク修正
* クエリおよびタクソノミーとプラグイン互換性に関する各種エッジケース (まれに起こる問題) 向けの修正

バージョン 3.1.1 ではさらに、WordPress コア開発者でありセキュリティチームに属するジョン・ケーヴとピーター・ウエストウッドが発見したセキュリティ問題3点にも対処しています。一つ目は、メディアアップローダーでの CSRF 阻止の強化。二つ目は、一部の環境において、非常に悪意を込めて作成されたリンクがコメントに含まれていた場合の PHP クラッシュの防止。三つ目は、XSS 問題の修正です。
=================================================================================
ということらしい。所帯が大きくなり,ユーザが多くなると,対処も迅速が求められるんだろうから,大変だよね。皆様,ご苦労様です。
 早速更新した。

カテゴリー
WordPress

偽セキュリティソフト「Security Tool」について

投稿アップデート情報  追記・追記2(10/12)  追記3(2013/8/15)

セキュリティツール 感染はしなかったが,この間TODOSで書いたばかりのこれらしきものに遭遇した。

 実は,SimilarPostsの日本語化があのままになっているので痺れを切らせて,日本語化したものをアップしてしまおうと思って,しかし,Robに無断はまずいだろうと彼のサイト(http://rmarsh.com/plugins/similar-posts/)に出かけたら,右のようなサイトにリダイレクトされて脅された。脅されたというのは比喩だが,ギクッとしたもんね。

 すぐに,ネットを切ってPC内をスキャンしたが,私が分かっているClamAV関係のウィルス以外は見つからなかったし,「Security Tool」に感染している痕跡もなかった。

投稿アップデート情報  追記・追記2(10/12)  追記3(2013/8/15)

 しかし,Robのところからというのが怖いです。昨今はまともなサイトでも安心はできないということを身をもって体験したわけで。ブラウザのJava Scriptと画像の表示を切ってアクセスしたら大丈夫だった。けど,Robのところに行くときにそんなことして行かないもんなぁ。

 「Wait a minute! This is important – we check your device」というメッセージが出るんだが,ググっても日本語ページは見つからなかった。あちらではもうとっくによく流行っているのか,ここなどいくつかが見つかった。まぁ,Robのところもあちらですからね。

追記:
 昨日,アップしたばかりの記事なんだけど早速検索ワードでここに来る方がいらっしゃいます。
 で,あの後ちょっとググッて見たけど,結構流行っているみたいですね。ウイルスバスターはすり抜けますという報告も多いようですが,うちはバスターです。もっとも,SpyBotS&DとSpywareBlasterも入ってます。Winのパッチもすべてあたっています。サーバ関係もいろいろ。いずれも最新です。
 まぁ,Winのパッチは数が多いので,いろいろバッティングして不具合の起こることもあり当てるときは注意を重ねていますが,それでも時々アチャッと言うことがあります。(月例)分は2010年10月13日のセキュリティリリース予定らしいけど,結構いろいろありますし緊急が4個もありまっせ。
 MSの緊急,重要,警告,注意 (https://technet.microsoft.com/ja-jp/security/gg309177.aspx#EBB) の使い分けはご存知ですか?知らないという場合は,リンクを見てください。


追記2:
 今朝(12日),Robから返事が来た。簡単なやつ。
「ありがとう!どうやら,サイトは復旧できたと思う。」
 で,折り返しどんな状況だったのか聞いてみたら,ここ(魚拓です)を読んでくれと返事が来た。<<----- リンク切れが起きていたので,貼り直し。元記事と少し変わっているような気がする。(2011.Dec.8)
 ずーっと読んでいくと,案の定サーバのセキュリティレベルでハッキングされるかされないかが決まるので,各自ができることはあまりないと書いてある。ただ,ファイルが書き換えられたときには知らせてくれるプラグインがあるので,それをインストールして監視するといいそうだ。
 私の場合は,AntiVirusを入れてあるのでこれがいいのかも知れない。

追記3(2013/8/15):
 「Similar Posts」のサポートが止まって長いので, Yet Another Related Posts Plugin を使うことにした。こちらには,はじめから日本語化ファイル(プラグイン作者自作)が付いている。どうも日系の方みたい。

カテゴリー
WordPress

アクセス制限。

先日,梅の実(今日の落下分)で書いたように,ブログページへのbotがあまりに激しいので,共通するユーザーエージェントで制限して見ようと思って,.htaccessに以下を追加して見た。

SetEnvIf User-Agent “libwww-perl” ng_ua
Order allow,deny
Allow from all
Deny from env=ng_ua

効果あるだろか。

追記:
先日,Casper_Cell Parijatah sronoをググッたときはあまり情報がなかったんだけど,今日.htaccessを変更してから,libwww-perlで調べたら,かなり前から報告のあるphpライブラリの悪用方法のようですね。「変更前に調べろよ」と,突っ込まれそうですが,サーバ初心者なので……(苦笑)
http://gigazine.net/index.php?/news/comments/20070410_libwww/
http://www.hazama.nu/t2o2/archives/002711.shtml
本当は,マルスクリプト内の用語で弾くべきなんだろうけど,それはもう少し勉強してからにします。今のところ,ユーザーエージェントで’libwww-perl’を名乗ってるのはスパムばかりなので,前記の.htaccessで大丈夫そうです。