WordPress 4.7 及び 4.7.1 への攻撃が増加中。

 いまだに増加中。大急ぎで WordPress をアップデートしよう,緊急事態ですよ。これ関係の記事はいっぱいだし,ネットオウルからもメールをもらったしで,これを書いてます。

 くりくりさんと Twitter で話したばっかりだったんだけどね。その件での初ツイートは 2/6 で徳丸さんの記事を見たからだ。“WordPress 4.7.1 の権限昇格脆弱性について検証した”

 昨日, Security Next が攻撃元の IP アドレスをいくつか載せてたので,夜,ログをチェックしてみたら, 2/6 に1 回だけあって, 500 エラーになっていた。そのときは,うちはもう WordPress 4.7.2 だったからだろう。
 ユーザエージェントが python-requests/2.11.1 で /wp-json/wp/v2/posts/ に来ていた。

 WordPress 4.7.2 のリリースは 1 週間以上前だし,オートアップデートがデフォルトだし,マニュアルアップデートでも超簡単なのに,この事態。残念至極。開発陣はもっと残念だろうなぁ。

権威DNSサーバーの設定不備による情報流出の危険性と設定の再確認について。

 表題の件,くりくりさんは早速確認されていたが,私は,自分とこに BIND とかが入っていないので関係ないじゃんとか思っていた。しかし,考えたら eNom のネームサーバを使っているわけだ。というわけで,それについて調べてみよう。大手どころだからと頭から信用してはいかんよね。 “権威DNSサーバーの設定不備による情報流出の危険性と設定の再確認について。” の続きを読む

またやらかしたの?

 なんか, Baidu がまたやらかしたみたいね。☞この件 (すぐ消えると思うから,PDF 版)。

 上記だけではあとで何の事だかわからなくなりそうだから,もう少し関連の記事を貼っておくが,

 しかし,こうたびたびとなると,確信犯としか思えなくなるよね。確信犯という言葉の使い方にも揺れがあるようだが,ここでの意味は,本来の意味ね。☞「道徳的・宗教的または政治的確信に基づいて行われる」
 Baidu は国営ではないから,国家的見地からの確信犯とまで言うと,言い過ぎ&勘ぐりすぎだろうか。それはさておき,私の語感から言うと確信犯という言葉は国家に対抗する意味合いを帯びることが多い気がするので,国家的見地からの確信犯というのは,矛盾をはらんだ用法かもしれない……(アセッ)。

 過去における, Google との争いとか著作権に関してのとかは,単なる市場に対する独占欲からと言ってもいいかもしれないが,今回のこととか, 2013 年の Simeji の件とかはなぁ。

 国家的見地からということになると,どこの国にもありうる話なので,セキュリティの話には敏感にならざるを得ない。と言って, Google や MS のような巨大企業のほうが信用できるという話には,絶対にならないが。

WordPress4.3 が来たよ。

 お盆,終わっちゃった。今年も,我が母方の親族では, 8/15 にパーティをやった。正にその日の朝, EX-V7 が壊れちゃった。 Grrr,ベリーバッドタイミング。そんなわけで,パーティの写真はあきらめた。どうやっても,「手ブレ補正ユニットが使用できません」というエラーメッセージが消えなかったのだが,このメッセージ, EX-V7 ではよくあるやつらしい。修理に出さなくてはいけない類の故障らしくて,高くつくらしいという情報をネットで得た。このデジカメを手に入れたのは, 2007.7.9 だから, 8 年前になる。どう思う?新しいのがいるって主張する絶好の機会じゃん。ネッ!(爆)
 んで,一昨日, DSC-WX220 を注文した。ほんでさっき,佐川さんが持ってきたよ~, ( ›◡ु‹ )。 “WordPress4.3 が来たよ。” の続きを読む

覚え書-#20。

投稿アップデート情報  追記(10/18)

 もう, “POODLE” 問題(つまり, CVE-2014-3566)には,対処した? OpenSSL のオフィシャルでも, OpenSSL Security Advisory [15 Oct 2014] が出てる。

 サーバ管理者としては下記のことをやった。
 今のところ, 1.0.1j でビルドされた Apache Lounge 版の Zip が手に入らないので, “SSL v3 goes to the dogs – POODLE kills off protocol” にあった回避策をやった。

 httpd-ssl.conf に SSLProtocol All -SSLv3 を書き加えて, httpd.exe をリスタートした。やる前は, SSL Server Test で “This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C” だったが,回避策後は, “This server is not vulnerable to the POODLE attack because it doesn’t support SSL 3” になった。実のところ,うちでは, Apache 2.4 と OpenSSL 1.0.1 を使っているので,うちの mod_ssl の場合, ‘SSLProtocol all’ は ‘SSLProtocol +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2’ ということになる。これは SSLProtocol Directive に記述がある。

 ユーザとしては,ブラウザで SSLv3 を停めた。
 やり方は,これも How to protect your browser にあった。英文だが,図もあってわかりやすい。日本語のサイトでは, IE, FireFox, Chrome の 3 つともの説明があるところを見つけられなかった。

追記(10/18):
 PHP 5.6.1 —>> PHP 5.6.2 ChangeLog.
 phpMyAdmin 4.2.9.1 —>> phpMyAdmin 4.2.10 ChangeLog.

ShellShock,ショーーーーーック!

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

 ヒェーッ!!
 もう対処しました? ShellShock 。うちのサーバ OS は Windows なので,直接の影響はなさそうですがね。まぁ,とんでもない脆弱性ですよ, NVD のスコアは満点の 10 だし。 VMWare 上に CentOS 6.5 があるので,その bash は,一応 bash-4.1.2-15.el6_5.2.i686 にアップデートしました。

 アップデートが済んだ後に env x='() { :;}; echo vulnerable' bash -c "echo this is a test" で,以下のメッセージが出るようだと,初期のパッチしか当たっていないので,もう一度アップデートが必要です。
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for 'x'
this is a test

 この情報は Red Hat Customer Portal 上の Masanari Iida さんのコメントで発見したものです。

 関連リンクをちょっとだけ。もちろんネット上にはすごい量の記事がありまっさ:

 ところで,うちの Apache エラーログには,昨日までに 6 回のアタックが残っていて,それについては昨日ブロックするようにしたんですが,本日現時点までで,また新しいところから 2 回のアタックがあってました。どれに対しても, HTTP エラーが返ってるんですがね。

追記(9/30):
 ”Bash bug: apply Florian’s patch now” に, “I very strongly recommend manually deploying Florian’s patch unless your distro is already shipping it.” という記述があり,そのパッチが当たっているのかどうかの確認方法も書いてある。

 Bash 自身で foo='() { echo not patched; }' bash -c foo をやったときに, “コマンドが見つかりません” が返ってくればパッチ済, “not patched” なら未パッチ。

 コメントで, vdp が “These ‘toughen the feature’ patches still feel quite scary.” と書き,あまり使わない機能なので,デフォルトでは使えないようにして,必要な場合はセキュリティに気を付けて有効にするようにしたらどうかと提案しているが,そのほうがいいんじゃないだろうか。

追記2(10/6):
 セキュリティホール memo さんのところのに 10/6 づけで追記が出ていた。

 ウォオオ。
 foo='() { echo not patched; }' bash -c foo
だけではいけないようですな。ただし, CVE-2014-6271 や CVE-2014-7169 と比べれば,危険度はグッと下がっているらしいです。

Android 版 Kindle の SSL サーバ証明書検証不備脆弱性。

 表題の件,我々一般人には,一見関係なさそうに見えるが,怪しいアプリをうかつに使わないとか,メールアカウントやパスワードの管理をしっかりするとかいうことでは,同じなんじゃないかと思う。

 そういえば,昨日,「ネット競売、消せぬ情報 大手3社、履歴・カード番号保存 利用者「流出が心配」」というのもあったな。えって,思うかもしれないけど,結構そういうとこ多い。だって,登録させる側からいえば,データの不正使用をする気はなくても,ユーザ側の無料版の反復利用を防ぐためだけでも,元情報は必要なわけだから,良心的であっても,罰則がないなら,データを保持するほうが妥当だと思う。どのくらい保持するとかで口を拭ってる様子は感じられるが……。知識の欠如から対応がいい加減なところもあるにはあるけどね。

 登録データの削除については,簡単/困難/不能をまとめたこんなサイトがある。 justdelete.me
 このサイトは, bitly.com (有名どころだが,日本語対応がないみたいなので, twitter そのものの短縮リンクが向上してからは,使うのをやめようとしたのだ) のアカウントを削除しようと四苦八苦しているときに発見した。
 まぁ, justdelete.me の一覧を見ると,サイトの性質から考えても, HARD あるいは impossible で当然だなと思うところもたくさんあるけど……。 justdelete.me ,日本語でも似たものがあるのかな。

 やっと,本題。
 29 日に JVN から Android 版アプリ Kindle における SSL サーバ証明書の検証不備の脆弱性というのが出ていて,セキュリティホール memo さんが「そのうち徳丸さんから解説が出るだろう」と書いておられた解説が出た。「Android版KindleにおけるSSLサーバ証明書の検証不備の脆弱性CVE-2014-3908」。読んでみたけど,難しくて,よくわからん。

 証明書を作るときに「コモンネームをちゃんとやってねー」というのはよく聞く。一致してない場合は,アクセスさせてくれないからだと,理解していた。これは,自前証明局の話ね。

 でも,奥さんの記事「SSL/TLSライブラリの正しい使い方(もしくは、コモンネームの検証について)」を読むと,多数の人がアクセスするアプリの場合,コモンネームの検証の実装はそれほど単純なものではないみたいだ。うちの自宅サーバレベルは蚊帳の外みたい(爆)。

 徳丸さんの解説は難しくて 100% 理解しているとはいいがたいのだが,それでも「コモンネームの検証が漏れてる場合があるって,超ヤバいじゃん」ということくらいは十分わかる。

 8月初めには,「App Storeのアプリが盗まれた」って話もあったし,スマホが一気に普及して,それ関係の悪事も花盛りだな。

 徳丸さんの記事の件は,実際に悪用されてるかどうかは現時点で不明なようだが,持っている方は,既に対応バージョンが出ているようだし, 「Kindle – Google Play の Android アプリ」でアップデートしておこう。

 「App Storeのアプリが盗まれた」の件については,セキュリティホール memo さんによると,いたのくまんぼうさんとこが,有用みたい。「注意喚起:アプリ乗っ取り犯の手口判明。ITCアカウントの入力を求めるアプリには注意!

マイクロソフト セキュリティ アドバイザリ 2915720 ???

 6月になっちゃいましたねぇ。
 2013年12月11日に,マイクロソフト セキュリティ アドバイザリ 2915720 が出たとき,「Windows Authenticode 署名形式で署名したバイナリの署名の検証方法を変更」っていう話があった。でもって,変更そのものは,セキュリティ情報 MS13-098 で既に配布されているが,2014年6月11日までは有効化されないよということだった。

 例のごとく「推奨するアクション」があったので,やってみた。”EnableCertPaddingCheck”=”1″ を試したのは, CF-J10(Win7 HP Sp1 64bit), NJ2100(Win8 Pro 32bit), xw4200(Win7 HP Sp1 32bit), KeyPaso(Vista Business SP2 32bit) の4台。いずれにおいても特にトラブルはなかった。どんな状況で問題が発生するのが,経験済みの方は,お教えいただければ幸いである。

 もっとも,マイクロソフト セキュリティ アドバイザリ 2915720 は 2014年5月22日に更新されてて,変更が有効になるのが, 8月12日に延期されたようだ。

「.do が時節柄気になる~」にふいちゃった。

 くりくりさんのコメントに,「おなかいっぱいです」と書きつつも, Gigazine の「IEに重大な脆弱性、サポート終了のWindows XPは修正パッチの予定なし」内の「IEのFlashプラグインを無効にすることが有効な対策」という表現にふいちゃった件も書き添えたが,も1個,セキュリティネタでふいた件を書いておこう。

 例によって,徳丸さんとこを見に行ったら,「三井住友VISAカードのフィッシングサイト」って話で,よくあるフィッシングメールの検証をやってくれていた。

 まっ,ためになる話ではあるんだがよくある話だし,私としては,検証結果より,彼が使っている検証環境が,どんなものかのほうを教わりたいなと思う,今日この頃,ナンチャッテ。「中身を見てやろうと検証環境を起動しました。閲覧しただけでマルウェアに感染するかもしれませんので…」と書かれてあるもんで,ハハハ。

 で,最後の一文でふいちゃった。
   「拡張子の .do が時節柄気になるところではありますね。」
だってさ。だよねー。もしかして,これが書きたいばっかりに,このネタで記事を書いたのではないかと,勘ぐったりして(爆)。

関係ないと思っていたんだが, Apache Struts の脆弱性。

投稿アップデート情報  追記(4/28) ~ 追記8(2017/9/6)

 関係ないと思っていたんだが,大いに関係あるらしいワ, Apache Struts の脆弱性!! 発端は,「Struts 2」でって話だったんだが,「Struts 1」にも同様の脆弱性があるらしいという話になった。

 そんでもって,なんと,[「e-Taxソフト(WEB版)」、「確定申告書等作成コーナー」、「NISA(日本版ISA)コーナー」 サービス停止のお知らせ(重要)平成26年4月25日(4月30日,復旧のお知らせがリリースされ,サービス停止のお知らせは消えた。アーカイブ版として,うちに保存していた分にリンクを貼っておく。こんなのだった。)]は,「Struts 1」を使っていたせいなんだと。私も利用させてもらってるよと,「確定申告,済みました?」に書いた「確定申告書等作成コーナー」もしっかり含まれている。使っていた当時は,問題なかったのでありましょうか?そう思いたい。提出のため国税庁に送信,ってことをしなければ,大丈夫なんだろか。どっかにわが経済事情が飛んでってないよね,もしもし,国税庁様っ!!

 まあ,「Struts」の今回の脆弱性は,「Struts 2」にもあるから,どうしようもないが,天下の国家機関がいつまでもサポートが終わってるもんを使うなよなぁ。せめて,こういう事態が発生したら,すぐに「Struts 2」に切り替えられる地点には達しておいてほしいよなぁ。とはいえ,前記のごとく,今回は「Struts 2」にしても問題は全く解決しない。

 「Struts」の件,本当にどうなるのかネ。「Struts」って,種類としては,Webアプリケーションフレームワークってことらしいが,外部からではインストールされているかどうかの診断は,なかなか難しいらしいことを読んだ。デフォルトでのインストールの場合,strutsって名前のディレクトリなりファイルなりができるようだから,サーバ内をローカルで調べてみるといいらしいよ。でもって,見つかった場合は,どうするかっていうと,こんなところ

 出来るもんなら,関連サービス停止してアンインストしてしまったほうがいいんだろうが……。

追記(4/28):
 出ましたよ。 S2-021Struts 2.3.16.2 へ,緊急にアップグレードしてくれになっている。といいつつ,同ページに,一応,それができない場合の回避策も,書かれているけど。

 しかしなあ,今度は大丈夫かね。前回も, S2-020 の直後に, exploit が出回ったみたいだからなあ。

 それと,「Struts 1」についてはどうなるんだろ。きっちりしたサポートのあるメーカーのミドルウェアとして使っている場合以外,自分で exploit に対応できる実力がないなら,サクッと使用をあきらめたほうがいいかもよ。

追記2(5/7):
 えっと,さらに S2-022 が出た。もぐらたたき状態になってるように感じるが……

追記3(2016/4/28):
 アクセス数は正直だねぇ。 Apache Struts 2 の脆弱性 (S2-032) に関する注意喚起が出たら,ピンと跳ね上がりましてん。でも, DMI(Dynamic Method Invocation) って,今どき,デフォでオフでないの?って思ったけど,本記事を書いたときも,古いの使っているところが多くて驚いたからなぁ。今回もいっぱいあるんだろ。ありがたくないワァ!!

追記4(2017/3/14):

 昨年末より,さぼり気味の我がブログ。この件もうっちゃらかしにしてたんだが,アクセスログを見ると,この古い記事に結構あちらこちらから訪問者がいらっしゃる。で,本日重い腰を上げてこの追記。まぁ, twitter ではつぶやきもしたんですがね。こんなの☟。

 今回の脆弱性は, CVE-2017-5638 というやつで, Apache Struts 2 の Jakarta マルチパートパーサーに元があるらしい。したがってマルチパートパーサーとして Jakarta は無効になってて,別のを使っているよということなら,回避できてることになる。
 あるいはすでに Fix 済みの新バージョンが出ているので,それにアップデートする。 2.3 系なら 2.3.32 に, 2.5 系なら 2.5.10.1 に更新すればよいということらしい。

 最近は,新しいのが出たら早いとこ更新したほうが身のためですよ。例の WordPress 4.7.2 の件もあったし。

追記5(3/17):
 「JakartaStreamMultiPartRequest についても、本脆弱性の影響を受け、攻撃が 実行可能な場合があるとの情報を受け取りました。」だそうです。
情報 URL: Apache Struts 2 の脆弱性 (S2-045) に関する注意喚起

追記6(3/21):
 S2-046PoC が GitHub に出てます。

追記7(3/24):
 Apache Struts 2 Exploit Analysis の記事を見たので,それも含めて,ツイートをリンク。

追記8(9/6):
 また出てましたね。「Apache Struts 2」に深刻な脆弱性の話。主として S2-052 の話で CVE-2017-9805 の関連ですね。