Johnson & Johnsonのウェブアプリの脆弱性を悪用する

Johnson & Johnsonのウェブアプリの脆弱性を悪用する Eaton • 2026年6月24日 リンクをコピー 共有 本日、私が2つの全く異なるJohnson & Johnsonのウェブアプリで見つけた脆弱性を公開します。1つは、約1,000人の学生の詳細を公開した大学のキャンパス採用システムにおける脆弱性で、もう1つは、20社で使用されている内部監査システムの管理者権限奪取に関するものです。詳しく見ていきましょう！ #1: キャンパス採用 大学のキャンパスで行われるキャリアフェアや採用イベントをご存知でしょうか？JnJは、これらのイベントに参加して新しい人材を発掘しています。彼らはこれらのイベントを管理するために、「キャンパス採用」ウェブサイトを構築しました。 学生にはイベントキーが与えられ、それを使用して自分の情報を提出します。 特に目新しいものはありません…ウェブサイトの基盤となるコードを見るまでは。そこには、興味深いプライベートな採用担当者ルートが見つかります！ 「/recruiter」にアクセスすると、Microsoft SSOログインページにリダイレクトされ、このサイトのこの部分がJnJ従業員に制限されていることが確認されます。 認証設定は非常にシンプルです。Microsoft Authentication Library（MSAL）がフロントエンドに統合されており、従業員がログインしていることを確認する役割を担っています。 私が安全でないウェブアプリを暴くのに役立つクライアントサイドのトリックの1つは、MSALをハッキングして常に誰かがログインしていると思わせることです。もし、トークンを正しく使用していないAPIが下層にある場合、このような問題を迅速に発見するのに役立ちます。このケースでは、MSALコードを修正して、常に「ログイン済み」の1アカウントの詳細を返すようにするだけで済みました。 これが完了すると、プライベートな採用担当者ルートにアクセスできるようになりました。イベントの管理、新しいイベントの作成、およびすべての学生情報の表示が可能です。採用担当者ダッシュボードでは、面接した特定の学生に与えられた評価やメモも確認できます。 何が悪かったのか：MSALトークンは実際にはどこでも使用されていませんでした。代わりに、ハードコードされたAPIキーがAWS APIへの認証に使用されていました。 約1,000人の学生が影響を受けました。キャンパス採用サイトはその後更新され、APIキー認証がBearerトークン（MSAL）認証に置き換えられました。 #2 監査追跡管理システム 監査追跡管理システム（ATMS）は、JnJとその関連会社全体の監査を管理するための内部ウェブアプリです。 LifeScan Ethicon, Inc Biosense Webster ITS Depuy Ethicon-Endo Janssen Vistakon Acclarent JDx Sterilmed CLS JJSV Cerenovus EQ Janssen UK & Ireland RAD Abiomed Inc. CQ MedTech V-Wave このシステムは、キャンパス採用と比較して、アクセスするのにもう少し手間がかかりました。サイトにアクセスするとすぐに、Microsoft SSOログインページにリダイレクトされます。これが起こる前に、ReactJSアプリがダウンロードされ、多くの興味深いAPIが見つかりました。 私は何が起こるかを確認するために「getAllUsers」APIにアクセスすることにしました。それは13.6k人のJnJ従業員のリストを返しました。 これは非常に大きな発見でした。なぜなら、すべてのAPIが認証されていないことを示しており、クライアントサイドのコードをハッキングするだけで全てにフルアクセスできることを意味していたからです。これが認証コードの様子です。キャンパス採用と同様に、Microsoft SSOを使用してユーザーを認証するためにMSALを使用し、その後いくつかの値をローカルストレージに設定しています。Bearerトークンを使用している兆候はありませんでした。これは私たちにとって好都合です！ ユーザーのなりすましを正しく機能させるためには、このシステムを使用している有効なJnJ従業員のユーザー名とWWIDを見つける必要がありました。できれば多くの権限を持つ人です。私はヘルプページに遭遇し、そこにはシステム管理者の詳細が書かれていました。 「getAllUsers」APIでその名前を検索すると、必要な情報が明らかになり、パッチが考案されました。 これにより、ログインリダイレクトが停止され、有効なログインが行われたかのようにハードコードされた値がローカルストレージに設定されます。これにより、新しいものが表示されました。 「OK」をクリックしても解決しませんでした。コードに戻りましょう… それはセッションを作成するコードです。セッションGUIDを返し、有効期限を計算するためにタイムスタンプを設定するAPIへの単なるGETリクエストです。そのAPIにアクセスすると、有効なセッションIDが返されました。 次に、有効なタイムスタンプと一緒に手動でそれを挿入しました… 更新すると、私はログインできました！ ドロップダウンを使用して会社を切り替えることができます。 管理者として、私は特別なメニューにアクセスできました。 そして、私が探索したのはその程度です。このシステムには、おそらく機密情報やトランスクリプトが満載されています。はるかロシアからでも。様々な機密保持に関する警告があるため、ここでは内部会議の議事録やトランスクリプトは表示しないことにしました。 ボーナス：彼らはいくつかの秘密の値を隠すために、かなりお粗末なクライアントサイドの暗号化スキームを使用していました。皮肉なことに、このようなコードが公開されていることを考えると、この監査システム自体は一度も監査を受けていないようです。 タイムライン 私がJnJにセキュリティ脆弱性を報告したのは2024年のことでした。当時の経験は素晴らしく、彼らは即座に対応し、一緒に仕事をするのが本当に楽しいものでした。しかし、これら2つの脆弱性を報告した際の経験は、それほどポジティブではありませんでした。両方の脆弱性は2025年10月に彼らに報告されました。月末までに、彼らはキャンパス採用の脆弱性を解決しました。しかし、ATMSの脆弱性は何ヶ月も対処されませんでした。私は2026年4月まで数ヶ月間フォローアップを続け、その時にジャーナリストの友人に協力を依頼しました。予想通り、彼らのJnJのメディアリレーションへのメールが、ついに彼らを修正に動かしました。深刻な内部データ漏洩が起こりうると思っていたものを解決するために、報道機関の介入が必要だったことは少し困惑しました。 完全なタイムライン： 2025年10月6日：JnJの脆弱性報告プログラムに報告。 2025年10月16日：応答も対応もないためフォローアップ。 2025年10月17日：JnJから最初の応答があり、調査すると確認。 2025年10月31日：キャンパス採用の脆弱性が修正される。ATMSについて問い合わせ。 2025年11月17日：ATMSに関する応答も対応もないためフォローアップ。 2025年12月22日：ATMSに関する応答も対応もないためフォローアップ。 2026年1月22日：ATMSに関する応答も対応もないためフォローアップ。 2026年4月8日：ジャーナリストに連絡。 2026年4月21日：ATMSの脆弱性がついに修正される。 2026年6月24日：公開 JnJの対応は最善とは言えませんでした。2024年に比べて2025年は脆弱性の処理がはるかに非効率だったようです。このプロセスで何が壊れたのかを修正し、2024年に経験した素晴らしい報告体験に戻れることを願っています。