makoto_fujimotoのblog

株式会社進角
代表 藤本信のブログです
どうぞよろしくお願いします

カテゴリ : セキュリティ

他のサイトで流出したアカウント情報によって、自社サイトが不正ログイン攻撃を受けること(パスワードリスト攻撃)を予防するために、Apacheのmod_evasiveモジュールの導入がある程度有効だと思います。

mod_evasiveのDos防御機能は、同一アクセス元から単位時間あたりのページリクエスト回数に制限をかけることが可能で、閾値を超えた際に403(Forbidden)を返すことができます。したがって、ログインプログラムに対し短時間に多くのログインを試みるような攻撃を早々に撃退してくれることを期待できます。

ただし不正アクセス間隔が閾値に引っかからないようにのんびりとしている場合(10秒に一回とか)は攻撃とみなされず、全く役に立たないことも付け加えておきます。

ちなみにファイアウォール装置の基本機能として上記のような防御機能を持っているものもあるようです。

最近、国内外でサイバー攻撃事件が激増しているように感じます。
サイト運営者は気を付けましょう

3/15「JINSオンラインショップのお客様情報流出の可能性」
http://www.jins-jp.com/

3/17「CO2みえ~るツールサイトの改ざんについて」
http://mieeeru.go.jp/

3/19「Apacheの不正モジュールによるウェブ改ざんに注意、トレンドマイクロ」
http://internet.watch.impress.co.jp/docs/news/20130319_592299.html

3/20「素粒子原子核研究所・理論センターのウェブサイトが改ざん被害」
http://www.security-next.com/038379

3/21「国内Webサイトの改ざん相次ぐ、アクセスするとウイルス感染の恐れ」
http://itpro.nikkeibp.co.jp/article/NEWS/20130321/464622/?ST=security&P=2

3/22「一休.comが不正アクセスを検知」
http://www.ikyu.com/help/aboutpassword.aspx

3/23「韓国へのサイバー攻撃まとめ」
http://d.hatena.ne.jp/Kango/touch/20130323/1363986809

3/25「マイクロマガジン社サイトが改ざん、閲覧PCがウイルス感染の可能性も」
http://www.mdn.co.jp/di/newstopics/28859/?rm=1


ちなみにWebサイト防衛にファイアーウォールは常識ですが、以下のようなセキュリティ対策も検討したほうが良いですね。
・WAF導入
・IDS/ADS導入
・サーバにセキュリティソフト導入
・アクセス許可するIPアドレスを国内限定
・ネットワークセキュリティ診断&対策
・プログラムコードセキュリティ診断&対策
・マルウェア定期診断
・改ざん検知

「JINS ONLINE SHOP」個人情報流出の件

先週末3/14、JINSというメガネ屋さんのECサイトが不正アクセスに合っていたことが発覚し、12,036 件のクレジットカード情報が流出する事件あった模様です。セキュリティコードまで盗まれたことで注目を浴びています。
http://www.jins-jp.com/
http://www.jins-jp.com/info.pdf
http://www.jins-jp.com/info20130315-1600.pdf

当初は頻発しているSQLインジェクションを用いたデータベース流出が疑われ「そもそも何でセキュリティコードなんか記録する必要があるんだ?」という意見も飛び交いましたが、その後の調査で支払い方法入力画面のプログラムを改竄し、入力内容を第三者のサーバに送信されていたことが判明したようです。

つまり、何らかのミドルウェア層の脆弱性をつき、任意のコードを実行して決済部分のプログラムを書き換えられてしまった可能性があります。

現時点でここまで深刻な脆弱性を内包してるソリューションはJavaが真っ先に挙げられます。年明けくらいから相次いで未解決の脆弱性が指摘され、Oracle社は現在でも連日アップデートに追われている様子です。
http://jvn.jp/cert/JVNTA13-064A/

このJINSサイトがJavaソリューション(Tomcat/JRE/JDK等)を使用しているか否かについては、公開されている情報だけでは分からなかったのですが、ベンダー情報なども絡めると使用している可能性が高いと私は推測しています。

以下は私の想定シナリオです。

<潜在リスク>
1. 脆弱性のあるJavaを使用していた
2. サーバから外部へのデータ送信が可能になっていた(Firewallが未設定)

<犯行手口>
1. まず踏み台となるサーバを乗っ取り
2. 盗んだ個人情報を送るデータベースサーバを乗っ取り
3. 踏み台サーバからECサイトにjavaの脆弱性をつくハッキングを行いプログラムを改竄
4. 購入者が入力したカード情報を改竄プログラムでデータベースサーバに送信
5. データベースサーバから個人情報を奪取
6. 証拠隠滅

今回の流出事件がこれまで無かった手法を用いていたようですので、同類の潜在リスクがあるサイトは早急に点検をお勧めします。


次に

3/15、日本国内285件のウェブサイトが「Darkleech Apache Module」マルウェアに感染の件
日本国内の285件ウェブサイトが「Darkleech Apache Module」マルウェアに感染し、もし感染されたサイトをInternet ExplorerブラウザでアクセスしたらBlackholeの感染サイトに転送されてしまいます。転送されたらパソコンにあるPDF/Java/Flash古いバーションの脆弱性を使われて、パソコンがBlackholeで提供されているマルウェアに感染されます、との恐ろしい状況が現状日本に発見いたしました。
http://unixfreaxjp.blogspot.jp/2013/03/ocjp-098-285blackhole-exploit-kit.html

こちらの「Darkleech Apache Module」とJavaの脆弱性について関連性は確かではありませんが、ファイルの改竄によってマルウェアが埋め込まれたことを鑑みると、JINSサイトと同様の脆弱性をつかれた可能性があります。

WebサイトのソリューションにJava(Tomcat/JRE/JDK等)が使用されている場合は念のためご確認ください。


対象となる製品とバージョンは以下の通りです。
- Java SE JDK および JRE 7 Update 15 およびそれ以前
- Java SE JDK および JRE 6 Update 41 およびそれ以前

セキュアなWebサイトを運用する際にはSSL(サーバ証明書)を用いることが常識となっていますが、どのページからSSL化(https)するべきかは少し誤認があると思います。

いわゆるWebサイトをSSL対応する意義は、通信の暗号化とサーバ証明の二つの目的を果たすことにあります。前者の暗号化では入力したログイン情報や個人情報などを万が一途中の経路で読み取られても解読できなくします。後者のサーバ証明は、第三者証明機関によって発行された、このサイトが間違いなくオフィシャルなものであることを示す電子証明書をブラウザに送って安全性を担保する役割があります。

こちらはTwitterのサーバ証明書情報(サブジェクト)の例
CN = twitter.com
OU = Twitter Security
O = Twitter, Inc.
STREET = 795 Folsom St, Suite 600
L = San Francisco
S = California
PostalCode = 94107
C = US


したがって、例えばプレゼント応募や会員登録を行う際、利用規約等(個人情報保護方針)のユーザが承諾するページをはさむ場合、SSL対応するページは入力フォームや入力情報を受け取るCGIからではなく、利用規約ページから適用したほうが事前にサーバ証明書を確認できるので望ましいと私は考えています。

他にも重要な情報をユーザに伝える必要があるページはSSL化してサーバ証明書を確認できるようにしておいた方が良いのではないかと思います。


ちなみに通信の暗号化だけが目的であれば高価なサーバ証明書を取得する必要は無く、Webサーバの設定によってはURLをhttpsとするだけで使用できる場合があります。ブラウザから証明書が確認できない旨の警報が出ますが、サーバ管理やコンテンツ管理画面など、管理者やネットワークアクセスが限定されている場合などにリーズナブルにセキュリティを高められます。

まもなくネット選挙が解禁となり、メールでの選挙活動も盛んになると思いますが、要注意なのが候補者や政党に成りすましたメールです。万が一、本人ではない人や偽りの組織から送られて来たメールの内容によって、有権者の世論が左右され、国政に影響が及ぶ事になれば民主主義の根幹を揺るがす事態です。

Eメールというのはインターネットの古き良き時代の仕様をいまだに引きずっており、容易に偽装することが可能です。ですから、個人的には選挙活動におけるメール送信には電子署名(証明書)の付与が欠かせないと思っています。

現在、メールにおける電子署名の利用は金融機関など一部のメールに限られ、まだ一般化しているとは言えませんが、今後はネット選挙を期に普及が進むと思われますので少し調べてみました。

証明書は、Webサイトのセキュリティ対策で使用されるSSLサーバ証明書などが有名ですが、メール用の証明書も各社から提供されています。

「ベリサイン セキュアメールID」
https://www.verisign.co.jp/securemail/
1年有効 185,850円(税込) 1メールアドレスにつき 1セキュアメールID

う、高い。。

「グローバルサイン クライアント証明書」
https://jp.globalsign.com/service/clientcert/
組織(部署)向け
 電子署名(S/MIME)用証明書 1年 54,600円
組織に属する個人向け
 マネージドPKI Lite 10ライセンス105,000円

これらの証明書を取得し、一般的なメールソフトであればインストールして使用できるようです。

大量の宛先に同報配信する場合や組織として日常的に証明書付のメールを送りたい場合は、ゲートウェイ型のメール配信ソリューションがあるようです。
http://www.hde.co.jp/hsm/
http://www.ditgroup.jp/service/product/apmg/
http://www.spis-box.net/sign/index.html


なお、ネット選挙用のWebサイトを運用するにあたって必要と思われるサーバ等のインフラ環境については、以前書いたこちらの記事を参考にしてください。
「ネット選挙用サーバ構築のガイドライン」 http://blog.shinkaku.co.jp/archives/23337019.html

Webサイトがハッカーによって不正アクセスされ、サービス妨害や改ざんや情報漏洩する事件が毎日のように発生しています。ソフトウェアに脆弱性が見つかると比較的にすぐに対策版が公開されますが、IT業者に運用を委託していても、なかなか能動的にソフトウェアのアップデートを行ってくれず(契約にもよりますが)、脆弱性が放置され、結果的に一般的に知られた攻撃手法でサービス被害を受けることあります。

ソフトウェア開発を委託してそのまま運用に移行した場合や、レンタルサーバの契約をした場合、依頼者側の心理としては、セキュリティ対策を「やってくれているんじゃないの?」「これだけ不正アクセスが多いんだからやってくれて当然でしょ?」と期待してしまうようです。

しかし、リアルの世界で考えると、例えばマンションの鍵や防犯設備について、管理会社がピッキングを始めとする最新のセキュリティ対策を適宜採ってくれて、万が一の際には保障してくれる、などと期待することはまずありませんよね?もし防犯や防災を強化したければ専門の業者に自己負担で依頼し、万が一の損害を担保するのは保険会社の領域という社会的コンセンサスがあります。

したがって、ITソリューションに対してだけセキュリティ対策を「やってくれている」と期待するのは早計だと思います(契約にもよりますが)。また「注意喚起くらいしてくれてもいいじゃないか」と期待したいところですが、個々の企業のホスピタリティのレベルであって前提とするには危険です。

セキュリティ対策については契約書や約款に謳われている場合も多いのですが、基本的に不確定要素の多いセキュリティやハードウェア故障に伴う損害については、逆にありとあらゆる可能性が免責事項として記載されています。セキュリティに関しては、いかなる大手IT業者でもテロ攻撃や暴動などと同様に、無限のリスクがある責任を保証することは不可能なので、具体的に明示されていない場合すらあります。

ここまで主に依頼者側の意識の整理をしましたが、次にIT業者がソフトウェアのアップデートを積極的にワークできないと思われる理由を挙げてみます。

  1. セキュリティ対策の責任とコストについて顧客と業者間でコンセンサスが取れていない。
  2. サーバソフトウェアのバージョンアップを行うとWebサービスに不具合が生じる可能性がある。
  3. サーバソフトウェアのバージョンアップに伴う作業が非常にデリケートでサービス停止のリスクがある。
  4. サーバ運用を担当している業者とWebサービスを開発している業者が異なり責任を負えない。
  5. サーバソフトウェアのバージョンアップを実施する前にWebサービスの十分な動作検証が必要。
  6. そもそも脆弱性の発端は不正アクセス手法を考え出した犯罪者なので、そのコスト負担に疑問がある。
  7. 常時告知されるセキュリティ喚起情報を収集し、脆弱性がWebサービスに及ぼす影響を調査するコストが高い。
  8. "敵"の概念が希薄で性善説を前提とする民族的な習性がハッキング行為をイメージできない。

サーバ運用担当者は常日頃からサービスの永続性の確保について大変なプレッシャーの中で仕事をしています。したがって、安定稼働しているシステムに手を加えることを嫌がりますし、そのように教育を受けている場合もあります。良く言えばお客様のサービスが停止することを懸念して積極的なアップデートを推奨しません。悪く言えばリスクにコミットするのが面倒ということでしょうか。

ちなみに最大手のG社においてもセキュリティ情報の喚起は行いますが、アップデートを「やってくれる」ということは無いようです。

もしかしたら、依頼者様の立場からすると「そんなのお前らプロの責任だろ!」「契約をちゃんと守れ!」の一言で片付けられていまう事かもしれませんが、過去にサーバ運用ビジネスをしていたことがある私の経験から、身勝手ながらこの様な心理状況があることがある、ということを包括的なITリスク管理を担当する方などに参考程度にしていただければ幸いです。

会員認証機能を持つサイトの多くは、ログインIDとしてメールアドレスまたは任意で決められるユーザIDが使用されています。しかし、昨今発生している膨大な個人情報漏えい事件の多さを鑑みると、既にかなりの割合のインターネットユーザのログイン情報がブラックマーケットに流通していると考えるべきでしょう。
参考:「パスワードリスト攻撃について

ログインIDを覚えやすいメールアドレスや任意のIDにすることで利便性は向上しますが、サイトを利用し始めたとたん、ブラックマーケットでログイン情報を入手したハッカーによってアカウントを乗っ取られる可能性があります。

したがって、今後、会員認証機能をもつセキュアなサイトを構築や改修する場合には、メールアドレス+パスワードあるいは任意のID+パスワードといった認証仕様は避けるべきだと思います。

具体的には会員登録時、ログインIDとして有無を言わさずサイト独自に生成したIDをユーザに配布する設計にすることです。これだけでブラックマーケットに流通している可能性のあるログイン情報とのマッチングを避けることが出来ますので、セキュリティ対策の第一歩として有効だと思います。

なお、この様なログインIDの形態は、クレジットカード会社等のWebサービス認証仕様として既にオーソドックスなものとなっています。

<加筆 2013.5.18>
さらに、私の経験上ログインIDとパスワードを同一にしている方が少なからずいる様です。その為にメールの認証がスルーされてメールサーバが不正にスパムメール配信に利用されてしまったケースがありました。

個人情報が流出する事件が後を絶ちませんが、どうやら不正に入手されたIDやパスワードが大量にブラックマーケットに出回っている兆候が否定できません。そのリストを用いて他のサイトで成りすましてログインに使用する行為をパスワードリスト攻撃あるいはリスト型アカウントハッキングと呼ばれています。

参考「使い回しIDが標的に…流出情報で不正アクセス」
http://www.yomiuri.co.jp/net/security/ryusyutsu/20130204-OYT8T00248.htm?from=tw


会員制サイトを運用していると防御ばかり気になりますが、最悪漏洩したことを想定したリスク設計を行うこと自体がタブーになっている場合があると思われます。なぜならSIerは、開発を担う立場上、漏洩を想定すること自体が提供サービスの質に問題があることを示すことになり、自ら信用を低下させかねないことには触れたがりません。

例えば会員登録性のポータルサイトで会員データが漏えいした場合、パスワードが暗号化されていなかったら、そのID&パスワードを使用して他のサイトで不正が行われるかもしれません。その場合、漏洩元が信用の棄損や損害賠償の責を負わないとは言えません。

このような二次被害を防止するために、パスワードが平文(非暗号化)で保存される仕様の会員サイトがありましたら、せめてパスワードだけでも暗号化する改修を行うことを推奨いたします。

こちらは以前書いたエントリーですが、改修のプロセスを大雑把に記述してありますので、参考にしていただければと思います。
http://blog.shinkaku.co.jp/archives/19808826.html

ネット選挙とは選挙活動をインターネットを中心として行う行為で、わが国でも2月か3月にも改正案が国会に提出され、今年の夏の参院選挙で本格導入の見込みです。

先の衆院選でもソーシャルメディアを中心として、実質的にネット選挙活動に近いものが行われ、法的にグレー状態のサイトや発信行為もあったようですが、結果的にお咎めは無かった様ですね。

しかし、政党などが特設サイトを公開し、有権者へのアンケート結果を即時公開する様なサイトがいくつかありましたが、サーバやドメインの名義そして不正アクセス防止策に不備があって、政党の主義主張や民意を公平にコミュニケートするには問題があったサーバシステムもありました。

特に、アンケート結果が即時ページ反映されるような仕様のサイトが"炎上状態"となり、"魚拓"が取られ、運営側の訂正対応とイタチごっこになっている様を目撃し、支持率低下への逆効果になったのではと心配になりました。

そこで、今後ネット選挙活動が主流になることを鑑みて、インフラソリューションを提供する弊社の立場として、国政選挙におけるネット選挙用サーバに求められる要件を勝手ながら考えてみました。

(1) .jpあるいは*.jpドメインを使用する
日本国の国政選挙ですから。ネットビジネスに良く利用される.comドメインなどはふさわしくないと思います。

(2) ドメイン名義を政党や立候補者の代表として公開情報とする
ドメインのwhois情報を確認すると名義が匿名になっていたり、広告代理店やシステム会社になっていることがありますが、情報発信の主体となるドメイン名義は責任ある為政者の長になっているべきだと思います。

(3) SSLサーバ証明書の名義は政党や立候補者とする
SSLは通信暗号化の他に、サーバ証明書が「このサーバは公的証明機関の証明によって、間違いなく登録名義の組織が運営している」ということを示す証となりますので、ドメイン同様に代行業者や第三者を代理名義にすることは本末転倒だと思います。

(4) 情報・コンテンツの通信はすべて暗号化(HTTPS)方式とする
ユーザが非暗号化のHTTPでアクセスした場合でも、サーバ側で自動的にHTTPSにプロトコルを変更することができます。送受信の通信すべてを暗号化することで組織の情報管理の信頼性が向上します。

(5) メールを配信する場合は証明書付とする
インターネットメールは簡単に成りすましが可能で、フィッシングサイトへ誘導される危険性もあるので、証明書(デジタル署名)を付与して送信したほうがよいでしょう。

(6) サーバは国内法人のサービスを使用し、データセンターも国内立地を条件とする
昨今の国政選挙における主義主張の中心となるのは国内経済が第一に挙げられると思います。したがってインフラにも国内IT企業を積極的に使用して経済に貢献している方がつじつまが合うのではないでしょうか。また情報保全の点でも日本国の法律が適用される国内データセンターを利用すべきだと思います。

(7) アクセス可能なIPアドレスは日本国限定とする
ハッキング行為の9割以上は海外のIPアドレスからもたらされる現状と、情報内容と対象者が日本国籍を持つものに限られるので、思い切って国内IPアドレスからのアクセスに限定しても良いと思います。なお在海外邦人向けには登録制のプロキシサーバを提供することで対応できます。

(8) ユーザからアンケートや意見を受ける場合はIPアドレスによる重複制限を行う仕様とする
インターネットで不正な操作を行い重複投票などを行う行為がよく問題になります。しかしそれを防ぐことが技術に難しく、ユーザ側の手間を必要とする場合もあるので、IPアドレスによる重複排除を行っても支障はないのではないでしょうか。複数名でIPアドレスを共有する会社などからは一人しか意見を発信できなくなりますが、家庭のPCからは概ね個人個人の意見を発信できると思います。
参考「炎上しないネット投票システム


まとめますと、ポイントになるのは「誰が」「どんな情報を」「どれくらい」といった情報の正確性をより担保・証明できるようなサーバシステムが求められるのではないでしょうか。

なお一般的なインターネットセキュリティ対策が取られていることは前提となりますので今回は割愛させていただきました。

また気が付いたことがあったら加筆します。

乗っ取られたと思われるTwiterアカウントを削除しても何度も復活してしまう現象があるようです。

これはハッキングを行っている側のcookieに、ログインセッションが保持されたままとなっており、そこに記録されている内部IDを元にアカウント復元が出来たという理屈かもしれません。

そしてそのセッション情報はパスワードを変更しない限り、リセットされない仕様になっているとか?

いずれにしても、ネットでは頻繁に数十万、数百万単位の個人情報漏洩が起こっているので、自分のメアド+パスワードあるいはユーザID+パスワードの組み合わせは、既にブラックマーケットで流通していると考えたほうがよさそうです。

このページのトップヘ