今日も元気にXを徘徊していたところ、どこにも公開していないサイトなのにめちゃくちゃアクセスが来るというポストがあり、そういえばCT Logとかもウォッチされてるしな。とつぶやいたところ まとめがあるといいな、とのコメントをいただいたので簡単にまとめてみました。（なお当該のポストはCT Log経由の攻撃と断定されているものではありません。）あくまで私が思い出しただけの話ですが、普通に来ますからね。 httpsサイトを新規公開するとすぐに攻撃botがやってきます 大事なことなのでもう一度いいます ステージングでも仲間内だけのページでもやってきます 見出し記法の濫用すみません。今回は注意喚起の側面が強いので、まずは何が起こりうるかを知ってもらうために最初に書きました。 botはやってきて何をするのか？単純にめちゃくちゃアクセスしてきます。サイトによっては数万回、/.envとか/.gitignor

一連のインシデントは日本時間の3月31日の9時ごろから12時ごろに終了しました。悪性の「axios@1.14.1」の露出時間は約2時間53分、「axios@0.30.4」は約2時間15分と推定されます。 上記の期間中に以下の操作をした場合、バックドアによる侵害が行われた恐れがあります。 「npm install axios」を実行した場合 依存パッケージにaxiosが含まれており、バージョン固定されていない状態で「npm install」を実行した場合 パッケージの依存ツリーにaxiosが含まれている状態で「npm install」を実行した場合 また、CI/CDパイプラインなどでこの時間帯に「npm install」が行われていた場合にも、パイプラインの実行先サーバーが侵害されている恐れがあります。 現在はnpm上で悪性バージョンは削除済みであり、「plain-crypto-js」も無害

2026年3月19日、Aqua Security が提供するOSSセキュリティスキャナ Trivy のエコシステムが、3週間以内に2度目のサプライチェーン攻撃を受けました。攻撃者は aquasecurity/setup-trivy および aquasecurity/trivy-action の2つのGitHub Actionsに悪意あるコードを注入し、これらを利用するCI/CDパイプラインからクレデンシャルを大規模に窃取するペイロードを配布しました。 本記事では、GitHub Events APIおよびGitHub上に残存するcommitデータから取得したエビデンスをもとに、何が起こっているかを記録します。その上で、取りうる対応指針を示します。 免責 本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。ペイロードの動作は手法の理解に必要な範囲で要

Trivy サプライチェーン攻撃の概要と調査結果 2026年2月21日〜28日にかけて、OSS 脆弱性スキャナ Trivy の GitHub リポジトリが乗っ取られるサプライチェーン攻撃が発生した。 FutureVuls は Trivy をスキャンエンジンの一部として利用しており、ちょうど攻撃期間中の 2/24 にリリース作業を行っていた。そこで、配布中のバイナリが改ざんされていないかを検証し、今回の攻撃による改ざんを受けていないと判断した。 2026年2月21日〜28日に Trivy の GitHub リポジトリが乗っ取られ、FutureVuls が配布する Trivy バイナリへの影響が懸念された バイナリハッシュ比較・ビルドタイムスタンプ・Sigstore（Rekor / cosign）署名検証の3点から検証した FutureVuls で「2026年2月24日リリース」以降から配布し

A colleague of mine shared a story from Windows XP product support. A major computer manufacturer discovered that playing the music video for Janet Jackson’s “Rhythm Nation” would crash certain models of laptops. I would not have wanted to be in the laboratory that they must have set up to investigate this problem. Not an artistic judgement. One discovery during the investigation is that playing t

Shai Hulud Strikes Again (v2)Another wave of Shai-Hulud campaign has hit npm with more than 500 packages and 700+ versions affected. Update: November 26, 2025 PostHog has published a detailed post mortem describing how one of its GitHub Actions workflows was abused as an initial access vector for Shai Hulud v2. An attacker briefly opened a pull request that modified a script executed via pull_requ

はじめに 本記事では中間証明書が正しく設定されていないWebサーバーへのリクエスト時に、各アプリケーションがどのような動作をするかについて調査した結果をまとめます。最初に前提知識や調査に至った理由を書き、その後に調査結果を述べます。 前提知識 本記事を読むにあたって簡単なSSL/TLSの基本的な知識が必要です。 サーバー証明書／中間CA証明書／ルート証明書の違いとは？ サーバー側ですべき設定 WebサイトをSSL化するためには、サーバー側がサーバー証明書と中間証明書を設定する必要があります。しかし、Webサーバーで中間証明書を設定する場合、Webサーバーソフトによっては中間証明書を設定する項目がない場合があります。例えば"Nginx"には中間証明書を直接指定するディレクティブが用意されていないため、サーバ証明書と中間証明書を結合したものを"ssl_certificate"で指定します。"A

Intro 前回は、Nx の事例をベースに「パッケージを公開する側」の対策について解説した。 今回は、「パッケージを使う側」、もっと言えば「OSS を使う上で開発者が考えるべきこと」について考察する。 OSS の危険性 npm 起因のサプライチェーン攻撃が確認されたことで「npm は危険だ」という話になると、「npm を禁止すべき」といった極端な話になったりする。 前回のブログで紹介したような対策を行うなら、多少は良くなるかもしれない。しかし、それらは全てパッケージ公開者に委ねられる。自分が公開者として実施するなら、自分が原因で攻撃が発生することは防げるだろう。 一方、攻撃に必要な突破口は 1 つあれば良い。npm にある全てのパッケージが対策されない限り、npm を主語とした安全が担保される日は来ない。 この広大な依存関係の中には、闇落ちした開発者が、それまでの善良なコードを、自分の意志

Passkeys are designed to revolutionize the sign-in experience, offering a simpler, faster, and more secure alternative to passwords. This checklist will guide you through the key aspects of implementing passkeys to achieve optimal user experience (UX) outcomes. How to use this checklist This checklist is intended for developers and product teams implementing passkeys in their authentication flows.

Intro Apple が突如発表した Passkey。 実態は「WebAuthn の秘密鍵を iCloud で共有」するサービスだった。 そして、業界は本格的な Password-Less に向けて進んでいく。 Passkey と FIDO Passkey は Apple のサービスとして始まったが、単なるいちベンダのサービスでは終わらなかった。 もともと生体認証を牽引していた FIDO を中心にこの方式についての議論が行われ、最終的には業界全体が Passkey を用いて Password-Less を目指す方向で概ね合意することになる。 Apple 以外のパスワードマネージャも Passkey に対応(つまり、秘密鍵を登録しそれを共有する)ようになり、様々な場所で Passkey への移行が啓蒙されるようになった。 ちょうどコロナ禍と重なるくらいの時期だ。 ちなみに、ここまで Web

パスキーによる認証を開発したとき、パスキーの安全性をどう評価するのが妥当なのか検討していた。もちろんフィッシング耐性が高いというような特性については把握していて、サービス利用者にとって便益の多い認証であることはわかっている。ただそれが、例えばパスワードとTOTPを組み合わせた多要素認証に対して、どちらがより安全と言えるのか。これを一言に表すのはあまり簡単ではない。 パスキーは多要素認証なのか 多要素認証というのは、something you know、something you have、something you are の3種類の要素のうち複数を組み合わせる認証を言う語だ。 多要素認証は単一種類の要素による認証と較べて飛躍的に安全である。例えば、物理的な鍵は something you have であるが、それが盗まれてしまえば安全ではない。鍵が複数あっても、一度に盗まれてしまうかもし

XSSこわい 若頭: おいお前ら、なにかおもしろい遊びをしねえか。こんなにみんなで集まる機会もそうねえだろう エンジニア佐藤: そうですねえ、こんなのはどうでしょうか。人間誰しも怖いものが1つはありますから、それをみんなで教えあってみましょうよ 若頭: そりゃあおもしれえな。そうだなあ、おれはヘビが怖いね。ありゃ気味が悪くてしょうがねえ エンジニア山田: 自分はカエルを見ると縮み上がってしまいます、テカテカしていてどうにも苦手で。佐藤さんは何が怖いんですか エンジニア佐藤: 私は、XSSがこわいです エンジニア八島: あはは！何言ってんですか佐藤さん。XSSなんてこわいことないですよ エンジニア佐藤: ひいい、名前を聞くのも怖いです エンジニア山田: XSSなんて、フレームワークさえ使っていればきょうび起こらないですからねえ。佐藤さんは臆病だなあ その晩、エンジニア佐藤を目の敵にしている町

はじめに こんにちは、GMO Flatt Security株式会社 セキュリティエンジニアの小武です。 近年、WebAuthn、特にPasskeyはパスワードレス認証への関心の高まりや利便性の高さから、普及が進んでいます。 WebAuthnによるPasskey認証は強固な認証手段ですが、複雑な認証基盤の実装に不備があると、依然としてアカウント乗っ取りを含む従来のセキュリティリスクを払拭できません。 本記事では、W3CのWorking Draft(2025年5月現在)である Web Authentication: An API for accessing Public Key Credentials Level 3 を読み解き、Relying Party(RP)としてPasskey認証を導入する際に実装で注意すべき点を説明いたします。 はじめに Passkey認証でも生まれ得るセキュリティリ

Web会議はリモートワークの必須ツールとなり、自宅から職場との遠隔での通話を可能にしている。しかし、自宅環境からビデオを送信することは、背景に映り込む物品や写真を通じてプライバシー情報が漏えいするリスクをもたらす。この問題に対処するため、多くのWeb会議サービスはバーチャル背景機能を実装し、背後の実環境を隠せるようになった。 しかし、このバーチャル背景機能は実際には完全ではない。通話中に前景（人物）と背景の境界付近で実環境のピクセルが短時間だが可視化されるからだ。さらに人物が動けば動くほど、境界部分から実背景の一部がどんどん見え蓄積することで多くの情報が露呈する。 問題点は低解像度でのセグメンテーションにある。元の映像を256×144ピクセルに縮小してからセグメンテーションを行うが、この縮小した低解像度の1ピクセルは元の映像では5×5ピクセルの領域に相当する。そのため、前景と背景の境界が5

The majority of the traffic on the web is from bots. For the most part, these bots are used to discover new content. These are RSS Feed readers, search engines crawling your content, or nowadays AI bots crawling content to power LLMs. But then there are the malicious bots. These are from spammers, content scrapers or hackers. At my old employer, a bot discovered a wordpress vulnerability and inser

外国人向け格安通話SIM「VoiceLite」、日本の電話番号を月額990円で提供開始 携帯、モバイル関連 訪日・在日外国人向けの通信サービス「Mobal（モバル）」は、2025年4月25日より通話対応SIM/eSIMサービス「VoiceLite」の提供を開始しました。月額990円（税込）で日本の電話番号を保有し、通話・SMSが利用可能。申込みは英語で簡単に完了し、在留カードや銀行口座は不要です。全国20か所以上で当日受け取りが可能で、利用を通じてマラウイなどの支援地域への寄付にも貢献できます。 この度、訪日・在日外国人向けの通信サービス「Mobal（モバル）」を運営するモベルコミュニケーションズ（本社：イギリス Winding House 州, 代表取締役社長 Anthony J.Smith、以下「モベル」）は、音声通話サービスSIM/eSIM「VoiceLite（ボイスライト）」の提供

フィッシングやマルウェアのURLを共有する時、リンク化されないように hxxp://example[.]comのように記載する事があると思います。 その変換形式を定義する、『A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators』という提案仕様がIETFに提出されています。 用語 難読化(Obfuscating): 誤ってクリックされないようにする変換のこと 難読化解除(De-obfuscating): 難読化されたものをもとに戻す変換のこと IOC: indicators of compromise。悪意あるURL、メールアドレスのこと もともとは、『無害化(defanging)』『もとに戻す(refanging)』の用語を使ってはいたがObfuscating, De-obfuscatingに