サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
まことにもっともな疑問だと思います。公開鍵暗号には、狭義の公開鍵暗号と、広義の公開鍵暗号があります。パスキーで使われているのは、広義の公開鍵暗号です。 狭義・広義だと紛らわしいので、狭義の方をPublic Key Encryption(PKE)、広義の方をPublic KeyCryptography(PKC)と表記する場合があります。光成さんのブログ記事がわかりやすいです。 https://blog.cybozu.io/entry/2021/12/28/080000 あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ初めに サイボウズ・ラボの光成です。 いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。 ビットコ
JPCERT/CCでは、インシデント対応に関する相談やインシデントに関する情報提供を受け付けております。 ご相談は、被害組織からだけではなく、調査を支援するセキュリティベンダー、システム運用会社などからも受け付けています（被害組織を秘匿した上での相談方法などは、経済産業省から公表されている「攻撃技術情報の取り扱い・活用手引き」[1]をご参考ください）。サイバー攻撃の高度化やランサムウェア攻撃の広がりにより、断片的な情報でインシデント対応の判断をしなければならない事案が増えており、被害組織やファーストレスポンダー（運用保守会社等）だけの知見では対応が困難なケースが増えています。JPCERT/CCでは、このような事案におけるインシデント初動対応支援やセカンドオピニオンも行っていますので、ぜひご相談ください。 情報提供につきましては、必要に応じて注意喚起やインシデント対応などインターネットの安全
自分がとあるイベントあわせでやったこと。 トリガは以下の記事の公開および、記事の内容に関連する各種レポート。IT系コミュニティをタダ飯狙いの不審者からどう守るべきか。あるイベントで発生した深刻な事案と提言 － Publickey (publickey1.jp) 若手が相当おそれて課題提起してくれたこともあり、大きいところは自分のほうで巻き取って対応。過去に別のところでやってるし、（手慣れてるとは言わないけど）うごくせきぞう状態の自分がやったほうが良いと判断して対応。 以下、対応の流れをおおまかに。 運営関係者間で対応を協議の上、大きな方針をまとめる課題提起を受けて、イベントの運営側で協議を行い、大きな方針をまとめる。この方針の中で、会場および管轄の警察署との連携を強化することを確定。そしてこの中で、主担当者（今回の場合はオレ）をあらためて決定。 今回立てた方針は、以下の2つ。 不審なのが
連日さまざまなサイバーセキュリティ犯罪のニュースが報じられる中、いまだに日本のセキュリティレベルは高いとは言えない状況にあります。一方で、企業がサイバーセキュリティ対策を進める上では、人材不足や経営層の意識・関心、コスト、導入による利便性の低下など、さまざまな壁が立ちはだかっています。 そこで今回は、株式会社網屋が主催する「SecurityBLAZE2023」より、サイバーセキュリティのエキスパートによる講演をお届けします。本記事では、米金融大手で1億人以上の個人情報が漏えいした事件の背景をひもときながら、問題点とセキュリティ対策のポイントを解説します。 Webセキュリティの第一人者が語る、個人情報流出事件の裏側 徳丸浩氏：ただいまご紹介いただきました、EGセキュアソリューションズの徳丸でございます。本日は「米国金融機関を襲った個人情報大規模流出事件の真相」というテーマでお話をさせてい
Metabase Qは2月1日(米国時間)、「ImageMagick: The hidden vulnerability behind your online images」において、同社のセキュリティチームが発見した画像処理ソフトウェア「ImageMagick」の2件のゼロデイ脆弱性について報告した。これらの脆弱性を悪用されると、攻撃者によって標的のシステム上でサービス拒否（DoS）や情報漏洩などの攻撃を受ける可能性がある。 ImageMagick: The hidden vulnerability behind your online images - Metabase Q ImageMagickは画像の表示や操作、フォーマット変換などを行うことができるオープンソースのソフトウェアスイート。非常に多くの画像フォーマットに対応していることから、画像を扱う世界中のWebサイトで広く利用され
2022年11月30日03:24（東京）に、AdGuardDNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuardDNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日
meety_vuln.md Meety脆弱性2022-11 文責 mala 経緯: Meety退会しようと思ったがアカウントがなかったので、退会するためにアカウントを作ることにした。 免責: 気になった範囲ですぐに見つかったもののうち、悪用可能なものを記載しています。 好ましくないが仕様だろうというものは書いていません。 他の脆弱性が無いことを保証するものではないです。 これはsecretgistです 11/24 時点で未修正の脆弱性情報が含まれています。修正されたらpublicに変更する予定です。 近しい人向けの注意喚起と、開発元への報告を兼ねて書いています。 悪用を教唆したり、悪用しそうな人に情報を共有することは避けてください。 自分の所有していないアカウントの情報を書き換えると法に触れるので、そのような行為は絶対にやめてください。 11/25 Publicにしました 以下 1-4
はじめにTwitterはBug Bountyプログラム(脆弱性報奨金制度とも呼ばれる)を実施しており、脆弱性診断を行うことが認められています。本記事は、そのプログラムを通して報告された脆弱性についてを解説したものであり、インターネット上のサービスに無差別に攻撃する事を推奨するものではありません。 また、Twitter上で脆弱性を発見した場合は無闇に公開せず、TwitterのBug Bountyプログラムより報告してください。 要約不適切なアクセス制御とレートリミットの欠如、タイミング攻撃を組み合わせることによりTwitterの非公開リストの中身を閲覧できた。 不適切なアクセス制御TwitterのGraphQLエンドポイントに対して以下のようなリクエストを送信すると、リストが非公開であったとしてもリストのメンバーリストを取得することが出来た。 GET /graphql/iUmNRKLdkK
とのことなので、有名サイトでもこの脆弱性を抱えていることになります。 この記事に出てくる攻撃方法は 5つ あり、文章だとピンと来なかったのでシーケンス図に書き出してみました。 乗っ取りはすごい怖いですね... RDSの本番DBをtruncateしていくよりも下手したら損害が出る可能性もあるのでは？と思ってしまいます。 さて、本記事はこんなことかな？とふんわり書いているので、間違っていたら指摘していただけると嬉しいです Classic-Federated Merge Attack 攻撃者が被害者のメールアドレスを使い、先回りしてサービスのアカウントを作成しておく。被害者が「Googleでログイン」などでそのサービスにログインした場合にアドレスが統合されるため乗っ取りが成功する。攻撃者が設定したパスワードでログインできる。 UnexpiredSession Identifier Attack
最初に断っておくと今回は万人向けの記事ではないです。面白かったので自分が忘れないようにまとめているだけです。本記事の位置付け はじめに 発見経緯 CRCのエラー HTTPアクセスログ 壊れたgzipのtrailerを見てみる 壊れたファイルの法則性 月次ログファイルの生成Linuxカーネルのバグの可能性 バグ混入の歴史 ログ破損の原因 8バイトの謎 PoCの制約 まとめ本記事の位置付け Dirty Pipe（CVE-2022-0847）三部作の最後です。ダークナイト三部作で言うとダークナイト ライジングにあたります。ダーティとダークって似てませんか。 spliceを使って高速・省メモリでGzipからZIPを作る 20分で分かるDirty Pipe（CVE-2022-0847） Dirty Pipe（CVE-2022-0847）の発見経緯が面白かった（本記事） 上の1, 2を前提知識と
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
2021年12月10日、Javaベースのログ出力ライブラリ「ApacheLog4j」の2.x系バージョン（以降はLog4j2と記載）で確認された深刻な脆弱性を修正したバージョンが公開されました。セキュリティ関係組織では過去話題になったHeartbleedやShellshockと同レベルの脆弱性とも評価しています。ここでは関連する情報をまとめます。 １．何が起きたの？Javaベースのログ出力ライブラリLog4j2で深刻な脆弱性（CVE-2021-44228）を修正したバージョンが公開された。その後も修正が不完全であったことなどを理由に2件の脆弱性が修正された。 広く利用されているライブラリであるため影響を受ける対象が多く存在するとみられ、攻撃が容易であることから2014年のHeartbleed、Shellshock以来の危険性があるとみる向きもあり、The Apache Software
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[神アップデート]GuardDutyがEC2やECSのマルウェア検知時のスキャンに対応したので実際にスキャンさせてみた #reinforce | DevelopersIO](/image.pl?url=https%3a%2f%2fcdn-ak-scissors.b.st-hatena.com%2fimage%2fsquare%2f15ee2fd3d857b7a8f5946b7ced0b54d5a76e6b81%2fheight%3d288%3bversion%3d1%3bwidth%3d512%2fhttps%253A%252F%252Fdevio2023-media.developers.io%252Fwp-content%252Fuploads%252F2022%252F07%252F000_guardduty_malware_protection.jpg&f=jpg&w=240)
