JOCにサイバー攻撃、全PC交換 金銭要求「ない」：朝日新聞デジタル
","naka5":"<!-- BFF501 PC記事下（中⑤企画）パーツ＝1541 -->","naka6":"<!-- BFF486 PC記事下（中⑥デジ編）パーツ＝8826 --><!-- /news/esi/ichikiji/c6/default.htm -->","naka6Sp":"<!-- BFF3053 SP記事下（中⑥デジ編）パーツ＝8826 -->","adcreative72":"<!-- BFF920 広告枠）ADCREATIVE-72 こんな特集も -->\n<!-- Ad BGN -->\n<!-- dfptag ＰＣ誘導枠５行 ★ここから -->\n<div class=\"p_infeed_list_wrapper\" id=\"p_infeed_list1\">\n <div class=\"p_infeed_list\">\n <div class=\"
Neverbleed - RSAの秘密鍵演算を別プロセスに分離する話
機能毎にプロセスを分割し、それらを別個の権限のもとで実行することで、脆弱性があった場合の影響を抑え込むというのは、一定以上の規模をもつプログラムでは、しばしば見られるデザインパターンです。 qmailは、そのような設計がなされたメール配送デーモンとして名高いですし、OpenSSHもまた、認証プロセスと通信プロセスを分離することで、外部との通信を担当するコードにバグがあったとしても、ルート権限が奪われないように設計されています（参照: Privilege Separated OpenSSH）。 一方で、OpenSSLにはそのような権限分離は実装されていません。Heartbleedの際にサーバの秘密鍵が漏洩したのも、秘密鍵の取り扱いと、その他の通信の取り扱いを同一のメモリ空間の中で行っていたからだと考えることができます。 ないのなら、自分で作ればいいじゃない…ということで作りました。それが、N
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
5分でわかる正しい Web サイト常時 SSL 化のための基礎知識
Web サイトを常時 SSL 化する場合に、最低限知っておかなければならない知識や、注意点、実際の設定方法まで、ひと通りまとめてみました。メリットやデメリット、証明書の種別からリダイレクト設定などについても解説しています。 HTTPS をランキングシグナルに使用しますと Google が公式に発表したあたりから、Web サイトの SSL 対応、特に Google が推奨している Web サイトをすべて HTTPS で配信する、所謂 「常時 SSL 化」 についての話を聞いたり、実際にお客様から相談されたりするケースが増えてきました。 そこで、いい機会だしその辺に関する情報をまとめておこうかな～ と思って書いてみた、恒例の （？） 5分でわかるシリーズ。書き終わって見たところ絶対に 5分じゃ無理っていう文章量になっててどうしようかなぁとも思ったんですが、気にせず公開してみます。 常時 SSL
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば
RHEL, CentOS, Amazon Linux (6以前) /etc/localtime を /usr/share/zoneinfo 以下から上書きしたりシンボリックリンク張ったりという手法が横行していますが、 /etc/localtime は glibc パッケージに含まれるためパッケージを更新すると上書きされてESTとかに戻ってしまうわけです。 当然ながら、ディストリビューションとして正しい設定方法が用意されているので、こちらを使います。 /etc/sysconfig/clock にタイムゾーンを書きます。*1sudo sed -i -e "s/^ZONE/#ZONE/g" -e "1i ZONE=\"Asia/Tokyo\"" /etc/sysconfig/clock tzdata-update を実行します。sudo /usr/sbin/tzdata-update これだけで
GitHubユーザーのSSH鍵6万個を調べてみた - hnwの日記
（2015/1/30 追記）時期は不明ですが、現時点のgithub.comはEd25519鍵にも対応しています。 （2016/5/31 追記）「GitHubにバグ報告して賞金$500を頂いた話」で紹介した通り、既に弱い鍵はGitHubから削除され、新規登録もできなくなっています。 GitHub APIを利用して、GitHubの31661アカウントに登録されているSSH公開鍵64404個を取得してみました。抽出方法*1が適当すぎて偏りがあるような気もしますが、面白い結果が得られたと思うのでまとめてみます。 SSH鍵の種類 鍵の種類 個数 割合 RSA鍵 61749 (95.88%) DSA鍵 2647 (4.11%) ECDSA鍵 8 (0.01%) 約6万個の鍵のうち、8個だけECDSA（楕円DSA）鍵が見つかりました！常用しているのか試しに登録してみただけなのかはわかりませんが、何にせよ
DDoS攻撃されたらそこで試合終了!? レンサバから利用停止を宣告される前にできる8つの対策 - Qiita
もしも運用しているサーバにDDoS攻撃をされて、大量のトラフィックを理由にホスティング業者から、そのサーバの利用停止を唐突に宣告されたらどうしますか? なにか対策を考えていますか? by woodleywonderworks. CC BY 2.0 「ファイアウォールでそういった攻撃を防いでいるから大丈夫」「まさか契約上そんな一方的なことができるはずない」と思うかもしれません。私もそのような認識でした。しかし、実際にDDoS攻撃を受けてみると業者の対応は次のようでした。 ホスティング業者は味方をしてくれない ホスティング業者は技術的に的はずれな対策を講じる ホスティング業者は利用規約を拡大解釈し、サービス停止を迫ってくる この3点を信じられない方のために、「付録:DDoS攻撃を受けた時のGMOクラウドPublicと私のやりとり」をこの記事の最後に書いたので、現実のホスティング業者の対応が実際
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
YDN「広告配信先レポート」が「firestorage.jp」のダウンロードリンク晒して炎上案件か？
これらの「配信先URL」にアクセスしてみると。 ああこれはダメなやつだ。 firestorageユーザーがアップロードしたファイルの「ダウンロードリンク」が、YDNの「広告配信先レポート」でモロバレです。 ダウンロードURLは40桁の英数字にて暗号化されていますので、アップロードされた方が他の方にお知らせしない限り、URLが知られることはありません。 いや漏れてるから。 ダウンロードページにリスティング広告を掲載するfirestorage側の注意不足でもあり、情報漏洩に直結しそうなURL情報をレポートで公開するヤフー側の不手際でもあり、さらにはオンラインストレージをパスワード設定無しで利用するユーザー側のセキュリティ意識の欠如でもあり。 ダウンロードファイル名から判断する限りではありますが、明らかに社外秘だろ的なものがいくつも含まれており、関係各位の今後の身の処し方が他人事ながら大変心配で
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 解決まで一ヶ月以上という相当な
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
オープンリゾルバ確認サイト公開のお知らせ
各位 <<< オープンリゾルバ確認サイト公開のお知らせ >>> JPCERT/CC 2013-10-31 I. 概要 JPCERT/CCは、お手元の PC からオープンリゾルバの確認ができるサイトを公開いたしました。 オープンリゾルバ確認サイト http://www.openresolver.jp/ オープンリゾルバとは、外部の不特定の IP アドレスからの再帰的な問い合わせを許可している DNS サーバのことです。オープンリゾルバは国内外に多数存在し、大規模な DDoS 攻撃の踏み台として悪用されているとの報告があります。 JPCERT/CC Alert 2013-04-18 JPCERT-AT-2013-0022 DNS の再帰的な問い合わせを使った DDoS 攻撃に関する注意喚起 https://www.jpcert.or.jp/at/2013/at130022.html また、DN
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
偶然にも500万個のSSH公開鍵を手に入れた俺たちは - slideshare
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
Androidで、全アプリをトロイの木馬に改変可能な脆弱性発見 ～Android端末の99％に存在と米セキュリティーベンチャーが警告