15年超IT系記者のプライドがポッキリ折れた話
「固定観念を捨てろ、既成事実や常識を疑え」。記者が新社会人としてこの仕事を始めた16年前、先輩記者から言われたのがこのセリフである。取材記事を書く際に、勝手な思い込みや事実誤認、重要事項の見落としなどがあってはならない。「とにかくあらゆることをまず疑ってかかれ。相手の言うことをうのみにするな。一次ソースに当たり、裏を取れ」。こう叩き込まれながらこれまでやってきた。 「そんなに片っ端から疑ってかかったら、人間不信にならないか？」。こんな質問を受けることもあるが、記者からすればむしろ逆である。どんな人でも勘違いをすることはある。取材時に主張したいことをうまく伝えられず、誤解することを口走ってしまうケースもあるだろう。根拠とするデータがそもそも間違っている可能性だってある。そうした諸々の可能性を先回りして考え、フォローする。そして最終的には信じる。そこに人間不信など入る余地はない。 実際に、この
OpenSSL脆弱性の再発防止へ、業界大手が重要オープンソースプロジェクトを支援
GoogleやMicrosoft、富士通などの大手が参加して、インターネットのインフラを担うオープンソースプロジェクトを資金面でバックアップする。 オープンソースのSSL／TLS暗号化ライブラリ「OpenSSL」に致命的な脆弱性が見つかったことを受け、GoogleやMicrosoft、IBMなどの業界大手が参加して、インターネットのインフラを担うオープンソースプロジェクトを資金面でバックアップする「Core Infrastructure Initiative」を発足させた。Linux Foundationが4月24日に発表した。 Core Infrastructure InitiativeにはAmazon Web Services（AWS）、Cisco、Dell、Facebook、富士通、Google、IBM、Intel、Microsoft、NetApp、Rackspace、VMwareな
三菱UFJニコスがOpenSSLの脆弱性を突かれて不正アクセスを受けた件をまとめてみた - piyolog
三菱UFJニコスのWebサイトが不正アクセスを受け、会員情報が不正に閲覧されたと発表しました。ここでは関連する情報をまとめます。 概要 2014年4月11日に三菱UFJニコスが自社Webサイトで不正なアクセスを検知し、Webサイトを停止。その後詳細な調査結果として、4月18日に第3報を公開し、そこでOpenSSLの脆弱性(恐らくCVE-2014-0160)を悪用した不正アクセスであったことを報告。 三菱UFJニコスの不正アクセスに関連した発表 2014/4/11 弊社Webサイトへの不正アクセスについて(PDF) 2014/4/12 不正アクセスに伴い停止させていただいた弊社Webサービス再開のお知らせと会員様へのお願い(PDF) 2014/4/18 弊社会員専用WEBサービスへの不正アクセスにより一部のお客さま情報が不正閲覧された件(PDF) (1) 被害状況 不正閲覧会員数 894名(
暗号化ソフト狙った攻撃で情報流出か NHKニュース
インターネットで広く利用されている暗号化ソフトに重大な欠陥が見つかった問題で、大手カード会社「三菱ＵＦＪニコス」のホームページがこの欠陥を狙った不正アクセスを受け、のべ８９４人分の個人情報が外部に流出した可能性のあることが分かりました。 ソフトの欠陥が確認されてから国内で被害が明らかになるのは今回が初めてです。 三菱ＵＦＪニコスによりますと、今月９日から１１日にかけて、ホームページに不正な通信が繰り返されたため調べたところ、「ＯｐｅｎＳＳＬ」と呼ばれる無料の暗号化ソフトの欠陥を狙った不正アクセスが確認されたということです。 この不正アクセスで、クレジットカードを所有する会員のべ８９４人分のカード番号の一部や、氏名、住所それに電話番号などが不正に閲覧され、外部に流出した可能性があるということです。 これまでのところカードが不正に使われたケースは確認されていないということですが、三菱ＵＦＪニコ
Heartbleed bug による秘密鍵漏洩の現実性について – IIJ Security Diary
本稿では HeartBleed bug による秘密鍵漏洩の可能性を考察します。 OpenSSL で利用される RSA 秘密鍵のフォーマットは PKCS#1[1]Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 http://tools.ietf.org/html/rfc3447#section-3.2 で定められています。暗号化された暗号文の復号、もしくはデジタル署名を行う際に RSA の秘密鍵による操作が行われます。SSL/TLS サーバに https でアクセスした場合には、その両方の用途で秘密鍵が用いられます。そのため HSM などの仕組みが無い場合には秘密鍵がメモリ上に展開されている可能性が高いと言えます。実際 Cloudflare Challenge[2
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO
heartbleedをiptablesで止めることについて - yasulib memo
前書き OpenSSLの脆弱性（CVE-2014-0160）が公開されました。 詳細はpiyokangoさんの素晴らしいまとめを参照してください。 OpenSSLの脆弱性（CVE-2014-0160）関連の情報をまとめてみた - piyolog エフセキュアブログにて、トーマツの岩井さんが書いた興味深い記事がありました。 エフセキュアブログ : Openssl Heartbleed 攻撃の検知について ＃根本的な対策ではなく、あくまで攻撃検知という意味で。 iptables log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" iptables block rules i
OpenSSLの脆弱性（CVE-2014-0160）関連の情報をまとめてみた - piyolog
HeartBleed(CVE-2014-0160)関係のリンク集、自分のメモ用なので不正確です。 HeartBleedの影響対象となるOpenSSLバージョン 以下のバージョンが影響を受けます。但し、システムによっては原因となっているheartbeat機能が無効化されている場合もあるため、バージョンが一致しただけで当該脆弱性の影響を受けるかは確定しません。 (1) OpenSSL 1.0.1系 バージョン名 リリース時期 CVE-2014-0160 OpenSSL 1.0.1 2012/03/14 脆弱性あり OpenSSL 1.0.1a 2012/04/19 脆弱性あり OpenSSL 1.0.1b 2012/04/26 脆弱性あり OpenSSL 1.0.1c 2012/05/10 脆弱性あり OpenSSL 1.0.1d 2013/02/05 脆弱性あり OpenSSL 1.0.1e
OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
暗号化ソフト欠陥、ＮＳＡは２年前から認識－情報収集に利用 - Bloomberg