Securityに関するstereocatのブックマーク (219)

  • オンライサービスや製品のHeartBleed(CVE-2014-0160)の影響についてまとめてみた - piyolog

    HeartBleedの影響についての情報のまとめです。(OpenSSL情報集約のページに書いていましたが量が増えてメンテナンスが大変になってきたため別記事としました。) 「影響あり」は特に記載無い限り、修正版の公開、または対応が済んでいます。随時更新・修正しています。piyokangoが勝手にまとめているだけですので、リスト掲載の情報だけを鵜呑みにせずリンク先の情報を確認してください。また掲載されていない情報があれば、@piyokangoまで教えて頂けると嬉しいです。 1. OS 対象名 CVE-2014-0160の影響 対象製品・バージョン Windows 影響なし − OSX 影響なし − Android ●影響あり(修正版提供時期不明) 4.1.1 iOS 影響なし − BlackBerry(smartphone) 影響なし − RHEL ●影響あり(日語) 6.5,7 Beta

    オンライサービスや製品のHeartBleed(CVE-2014-0160)の影響についてまとめてみた - piyolog
  • Heart Bleedを読んだ - The first cry of Atom

    int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ heartbeatという機能の詳しいことは調べられていないけれどどうやらクライアントーサーバ型の機能を提供するものらしい。 つまり何らかのリクエストを受け取ってレスポンスを返すようなサービスを提供するものらしい。dtls1_process_heartbeatで大事なのは ポインタpだ。これはリクエストデータを受け取って格納している。このリクエストデータは構造体になっていて、以下のように記述されている。 typedef struct

  • WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる

    OpenSSLの脆弱性「Heartbleed」が世間を賑わせていますが、色々と乗り遅れてしまった感があるので、ゆるゆると落ち穂拾いをしようかと思います。 Heartbleedで秘密鍵を手に入れたらSSL通信の中身全部見えちゃうじゃん!! という事態になっていますが、なんとなく理論的にそうだろうなと分かるもののイマイチ具体的な手順が分からない。 というわけで今回のテーマとして、手元にサーバの秘密鍵と、SSL通信をパケットキャプチャしたpcapファイルがあるときに、Wiresharkでどんな感じでSSL通信を「ほどく」のか……という具体的な手順を、ハマり所を含めてまとめておこうかと思います。 というか、私自身がハマったので自分用メモですな。なおこの文書では"SSL"とだけ記述し、TLSは無視しています。 前提条件 とりあえず以下のような感じの検証環境で試しました。 IPアドレス 説明 ホストO

    WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まつてゐる
  • OpenSSLの重大バグ「Heartbleed」発覚に伴い、あなたが今すぐパスワードを変更するべきサービス一覧 | ゴリミー

    先日、OpenSSLの重大バグ「Heartbleed」が発覚し、ネット上で大騒ぎとなっていた。非常に深刻な脆弱性となっているため、ネット上の様々なサービスが被害を被っている。 詳しくはTechCrunch Japanに書いてあるが、これは従来「安全」とされていたセキュリティにおける重大な欠陥であり、決して他人事では済まされない話だ。 セキュリティー研究者らが “Heartbleed“と呼ぶそのバグを悪用すると、過去2年以内のあらゆるバージョンのOpenSSLが走るシステムで、システムメモリー上にある大量のデータを暴露することが可能だ。 これがどういうことかと言うと、パスワード入力時に「*」などの文字で他人に読み取れないように置き換えられていたはずのパスワードが第三者に読み取れる可能性がある、ということだ。つまり、パスワードを盗み見できてしまうのだ。ハッキリ言ってこれは極めて危険。 あなたが

    OpenSSLの重大バグ「Heartbleed」発覚に伴い、あなたが今すぐパスワードを変更するべきサービス一覧 | ゴリミー
  • OpenSSLのHeartbleed脆弱性(CVE-2014-0160)

    TOP > タイガーチームセキュリティレポート > OpenSSLのHeartbleed脆弱性(CVE-2014-0160) タイガーチームセキュリティレポート OpenSSLのHeartbleed脆弱性(CVE-2014-0160) 先日明らかにされたOpenSSLのHeartbleed脆弱性が話題になってたようなので検証しました。これはOpenSSLのHearbeat実装(HTTPでいうところのkeep-alive)におけるread overrunの脆弱性で、誰でも簡単にexploit可能で攻撃の痕跡がほとんど残らないという特徴があります。対象となるのは1.0.1f以前の1.0.1系OpenSSLです。今回は1.0.1fで検証しました。 -影響- Heartbleed脆弱性を利用すると、heap上の任意のデータが漏洩する可能性があります。heap上のデータにはSSL/TLSの秘密鍵や、

  • 「個人を特定する情報が個人情報である」と信じているすべての方へ―第1回プライバシーフリーク・カフェ(前編)

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    「個人を特定する情報が個人情報である」と信じているすべての方へ―第1回プライバシーフリーク・カフェ(前編)
  • CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば

    必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして

    CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
  • OpenSSLの脆弱性で想定されるリスク - めもおきば

    JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者(一般ユーザ)の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ

    OpenSSLの脆弱性で想定されるリスク - めもおきば
  • なぜTheo de RaadtはIETFに激怒しているのか

    の虫: OpenBSD、怒りのコミットで、OpenBSDのTheo de RaadtがIETFに対して激怒している。 src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 なぜTheo de Raadtは、OpenSSLではなく、IETFに対して激怒しているのか。IETFというのは、インターネット上の規格制定の団体である。今回、世上を騒がせているHeartbeat問題は

  • JALの不正ログイン事件について徳丸さんに聞いてみた

    高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、JALの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。日航空のホームページに不正アクセスがあり、JALマイレージバンク(JMB)のマイルが、Amazonのギフト券に勝手に交換される被害がありました。日航空の発表では、1月31日から2月2日にかけて、身に覚えがないマイル交換がされているという問い合わせが複数ありました。調査の結果、40人の利用者のマイルがアマゾンのギフト券、数百万円相当と交換されていたというものです。 徳丸: ここで問題となるのは、パスワードは数字6桁ということなんですよね。 高橋: やはりそこですか。パスワードが数字6桁だとどのような攻撃ができるのでしょうか? ブルートフォース攻撃 徳丸: まず、ブルートフ

    JALの不正ログイン事件について徳丸さんに聞いてみた
  • 50,000 ドルの価値がある Twitter アカウントが盗まれたその経緯 : にぽたん研究所

    ひろしまさん (廣島さん) は、これまでたった 1 文字の Twitter アカウント @N を持っていました。 何故「持っていました」と、過去形なのかというと、どうやら先日、巧妙な罠に、人ではなく 2 社の有名 IT 関連企業がハメられたことによって、ひろしまさんの稀少なそのアカウントが第三者によって盗まれてしまったそうなのです。 2014/02/26 追記: 記事掲載時点では「持っていました」と過去形で表現していますが、ひろしまさん人によるツイートで、2014/02/25 の昼過ぎ (日時間 2014/02/26 の早朝) に、この事件によって盗まれてしまったアカウント @N がようやく取り戻されたことがわかりました。 Order has been restored. — Naoki Hiroshima (@N) February 25, 2014 解決まで一ヶ月以上という相当な

    50,000 ドルの価値がある Twitter アカウントが盗まれたその経緯 : にぽたん研究所
  • https://jp.techcrunch.com/2013/12/19/20131218google-location-history/

    https://jp.techcrunch.com/2013/12/19/20131218google-location-history/
  • dotless domainとccTLDの話:Geekなぺーじ

    昨年12月に、Informational RFCとして、RFC 7085「Top-Level Domains That Are Already Dotless」が発行されました。 そこでは、TLD(Top-Level Domain)そのものにAレコード、AAAAレコード、MXレコードが登録されている、いわゆる「ドット無しドメイン」の一覧が紹介されていますが、一部界隈では「晒し上げRFC」と揶揄されています。 なお、このRFCで「晒し上げられている」TLDはすべてccTLDで、gTLDは一つもありません(その理由を、今回の記事で紹介します)。 要は、「ここで晒されているccTLDは、運用を見直せば?」という圧力の意味合いもあるようです。 ここでポイントなのは、「直せ」と直接的に言っているのではなく、「ドット無しは有害です」「これがドット無しのTLDの一覧です」ということがたんたんと記載されて

  • ネットワークアクセス制御システム「PacketFence 4.1」リリース | OSDN Magazine

    カナダInverseのPacketFenceプロジェクトは12月11日、オープンソースのネットワークアクセス制御(NAC)ツールの「PacketFence 4.1.0」をリリースした。新機能の追加や既存機能の強化が加わっている。 PacketFenceは、オープンソースの侵入検知システム「Snort」や脆弱性スキャナ「Nessus」を統合し、異常なネットワーク活動の検出、脆弱性スキャン、問題のあるデバイスの隔離といった機能を持つネットワークアクセス制御(NAC)システム。FreeRADIUSモジュールによるIEEE802.1xのサポートや無線と有線の一元管理、役割ベースのアクセス制御、ゲストアクセス機能、マルウェア対策、WiFiオフロード、私用情報端末の業務利用(BYOD)管理などさまざまな機能を備える。ライセンスはGPLv2。ダウンロードは30万件を上回っているという。 バージョン4.1

    ネットワークアクセス制御システム「PacketFence 4.1」リリース | OSDN Magazine
  • 高木浩光先生からドコモ個人情報問題の濃厚解説ツイートが来たる(山本一郎) - 個人 - Yahoo!ニュース

  • Googleグループに残る「非公開のつもり」のメーリングリスト 公開範囲設定に注意を

    Googleグループの開設画面。アクセス権限は「基的な権限」メニューで設定できるが、「ネット上で誰でも閲覧できる状態」を、「トピックを表示 ユーザーのグループを選択 すべてのユーザー」というメニューで表すなど、分かりづらい表現になっている Googleが提供する掲示板/メーリングリストサービス「Googleグループ」で、環境省が機密情報を誰でも見られる状態で共有していたことが分かり、省内の規定違反に当たるとして問題になった。Googleグループはデフォルトで投稿内容がネット全体に公開される仕様になっており、現在も公開を意図していないとみられる情報が散見される状態だ。企業などが情報流出などのリスクを負う恐れもあるとして、セキュリティ専門企業が注意を呼び掛けている。 Googleグループは、テーマに応じた掲示板を作り、情報共有できるサービス。掲示板への書き込みはメールかWebから可能で、更新

    Googleグループに残る「非公開のつもり」のメーリングリスト 公開範囲設定に注意を
  • ふたひねりきかせたOpenFlowの利用事例 | さくらのナレッジ

    ということでOpenFlow、なんですが、仮想化・抽象化されたネットワークにおけるサービスの提供といった、いわゆるSDNの手法として導入されるケースが一般的かと思います。 しかし稿でご紹介するのはそうした事例とは全く異なるもので、OpenFlowならではのクリーンなAPIとハードウェアスイッチの処理能力を生かした、効果的なDDoSアタック防御の手法です。 以下の内容は、ネットワークエンジニア向け情報サイト、Packet Pushersのコミュニティブログに寄稿した3の記事をさくらのナレッジ向けに書き直したものです。 お題目 大規模DDoSアタックが発生すると、さくらインターネットのネットワーク網(以下:当社ネットワーク)への複数の入口から攻撃パケットが一気に流入してきます。 こうした大量のパケット流入によるネットワーク帯域輻輳を防ぐために、以前から当社ではd/RTBHという手法で対応し

    ふたひねりきかせたOpenFlowの利用事例 | さくらのナレッジ
  • 広告を消してくれるブラウザ拡張機能「Adblock Plus」の秘密

    6月21日にページ中に表示される広告を非表示にする「Adblock Plus」のInternet Explorer対応版がリリースされ、主要ブラウザであればどれでも「Adblock Plus」が使えるようになりました。 ブラウジングの際に広告バナーをブロックしてくれるということで重宝している人も多いと思いますが、その裏で、Adblock Plus製作者の背後には“戦略的パートナー”の存在があり、製作者の関連企業やお金を出した企業の広告はブロックせずに配信しているということが明らかになっています。 Adblock Plus Undercover – Einblicke in ein mafioeses Werbenetzwerk | Mobilegeeks.de | Allgemein http://www.mobilegeeks.de/adblock-plus-undercover-ein

    広告を消してくれるブラウザ拡張機能「Adblock Plus」の秘密
  • 「きょう誕生日の人RT」「#ペットの名前」に反応してはいけない理由

    著者紹介:宮田健(みやた・たけし) 元@ITの編集者としてセキュリティ分野を担当。現在はフリーライターとして、ITやエンターテインメント情報を追いかけている。アイティメディアのONETOPIでは「ディズニー」や「博物館/美術館」などのキュレーターをこなしつつ、自分の生活を変える新しいデジタルガジェットを求め日々試行錯誤中。 先日、「はてな匿名ダイアリー」に掲載されたエントリーが話題になりました(参照リンク)。予備校が広告として電車内に張り出している「大学合格体験記」を見て、そこに登場している女性の「名」をソーシャルネットワークサービス(SNS)で検索。出身地や出身校とあわせて人を特定し、たくみに近づいたというものでした。匿名の書き込みですし、どこまで当のことかは不明ですが、実現可能性は高そうです。 出したつもりがなくてもオープンになってしまう個人情報 この一件、興味深いのは、SNS

    「きょう誕生日の人RT」「#ペットの名前」に反応してはいけない理由
  • BLOGOS サービス終了のお知らせ

    平素は株式会社ライブドアのサービスを ご利用いただきありがとうございます。 提言型ニュースサイト「BLOGOS」は、 2022年5月31日をもちまして、 サービスの提供を終了いたしました。 一部のオリジナル記事につきましては、 livedoorニュース内の 「BLOGOSの記事一覧」からご覧いただけます。 長らくご利用いただき、ありがとうございました。 サービス終了に関するお問い合わせは、 下記までお願いいたします。 お問い合わせ

    BLOGOS サービス終了のお知らせ