0day の盛衰: 2022 年に 0day が悪用された年の振り返り

これは、実際に悪用されたゼロデイ脆弱性に関する Google の 4 回目の年次レビュー [2021、2020、2019] であり、2022 年半ばのレビューに基づいています。このレポートの目的は、個々の脆弱性を詳細に説明することではなく、年間を通じて脆弱性を分析し、傾向、ギャップ、学んだ教訓、成功を探ることです。

まとめ

2022年には41件のワイルド・ゼロデイが検出・公表され、これは2014年半ばに追跡が開始されて以来2番目に多い記録となったが、2021年に検出された69件よりは減少した。 40% の減少は、安全性を向上させるために削減すべき明らかな数値のように思えるかもしれませんが、現実はより複雑です。 2022 年の重要なポイントは次のとおりです。

パッチ適用時間が長いため、Android では N 日は 0 日と同様に機能します。 Android エコシステム全体で、ユーザーがパッチを長期間利用できない状況が複数あります。攻撃者は 0day 脆弱性を必要としませんが、0day として機能する n 日を使用できます。

ゼロクリックエクスプロイトと新しいブラウザーの緩和策により、ブラウザーのゼロデイ脆弱性が軽減されます。多くの攻撃者は、ワンクリック攻撃ではなくゼロクリック攻撃に転じています。ゼロクリックは通常、ブラウザ以外のコンポーネントを対象とします。さらに、主要なブラウザはすべて、脆弱性の悪用をより困難にする新しい防御機能を実装しており、攻撃者が他の攻撃対象領域に移動する可能性があります。

40% 以降のゼロデイ脆弱性は、以前に報告された脆弱性の亜種です。 2022 年からの 41 件のワイルド 0days のうち 17 件は、以前に報告された脆弱性の亜種です。これは、2020 年のレビューレポートと 2022 年の中間レポートで以前に説明した不快な傾向を継続しています。 Over 20% は、2021 年と 2020 年以前のワイルド 0day のバリエーションです。

バグ競合が多発しています。 2022 年には、攻撃者が同じ脆弱性を互いに悪用しているという報告がより頻繁になり、セキュリティ研究者も、後に攻撃者によって使用されていることが判明した脆弱性を報告しました。世に出ているゼロデイ脆弱性が発見され、一般的な消費者向けプラットフォームに対してパッチが適用されると、他の攻撃者も脆弱性を侵害する可能性がますます高まります。

2022 年のゼロデイの分析に基づくと、業界は引き続き次の分野に注力すると予想されます。

  1. バリアントおよび n 日が 0 日として使用される問題を解決する、より包括的でタイムリーなパッチ。

  2. より多くのプラットフォームがブラウザーに続き、脆弱性のクラス全体の悪用可能性を低減するための広範な緩和策をリリースしています。

  3. 技術的な詳細を共有し、複数の製品にわたるエクスプロイト チェーンを共同で検出するために、ベンダーとセキュリティ保守担当者の間の透明性とコラボレーションが強化され続けています。

数値的な観点から見ると

2022 年に検出され公開された 41 件の脆弱性のうち、検出されたすべてのゼロデイ脆弱性の大きな割合を占めるものは見つかりませんでした。年間を通じて比較的均等に分布していることがわかります。前半は 20 件、後半は 21 件です。これら 2 つのデータ ポイントを組み合わせると、テストがより頻繁かつ定期的に行われることがわかります。また、実際に発見されているゼロデイを持っていると考えられる組織の数が依然として多いこともわかりました。 2021 年以降、69 件のゼロデイ脆弱性が検出され、20 の組織が認定されました。 2022 年には、18 の組織が 41 件のワイルド ゼロデイ イベントで表彰されました。この問題を解決するにはできるだけ多くの人員が必要であるため、ゼロデイ検出に取り組んでいる組織の数が引き続き多いことは有望です。

2022 年に検出および公表されたワイルド ゼロデイは 41 件で、2021 年の 69 件から減少しました。 2021年からは大きく下がったものの、2022年でも2位となっている。分析に使用するすべての 0days は、このスプレッドシートで追跡されます。

0day の盛衰: 2022 年に 0day が悪用された年の振り返り

 

0day の盛衰: 2022 年に 0day が悪用された年の振り返り

セキュリティ指標としての 0day 数量制限

実際に検出され公開されたゼロデイの数からは、セキュリティ体制についてはあまりわかりません。代わりに、多くの指標の 1 つとして使用します。 2022 年までに、セキュリティの改善と回帰の組み合わせにより、2021 年から 2022 年にかけて検出および公開されたゼロデイの数が約 40% 減少し、引き続き平均を上回るゼロデイの数が発生すると考えられます。 2022年に。

プラスの変化とマイナスの変化の両方が、野生での 0 日の数の増減に影響します。したがって、この数値だけを使用して、ユーザーの安全を守るための取り組みが進歩しているかどうかを示すことはできません。代わりに、その数値を使用して、どの要因がこの結果に寄与した可能性があるかを分析し、それらの要因が成功領域なのか、それとも取り組む必要がある領域なのかを検討します。

ゼロデイの検出数と公開数の増加につながる要因の例:

セキュリティの向上 - 攻撃者が同じ機能を維持するにはさらに多くのゼロデイが必要

  • 0日以内に発見して修正する

  • 既知のゼロデイ脆弱性を公表する企業が増加

  • プラットフォームにセキュリティ境界を追加する

安全な回帰 - 0days は発見と悪用が容易です

  • 報告された脆弱性に対してバリアント分析は実行されませんでした

  • エクスプロイト手法は軽減されない

  • 悪用可能な脆弱性が修正されるよりも多くコードに追加される

 

インザワイルドゼロデイの検出数と公開数の減少に寄与した要因の例:

セキュリティの向上 - ゼロデイでは、開発と使用に多くの時間、資金、専門知識が必要です

  • 悪用可能なゼロデイ脆弱性の減少

  • 新しいゼロデイが発生するたびに、新しいエクスプロイト手法の作成が必要になります

  • 新しい脆弱性には、新しい攻撃対象領域の調査が必要です

セキュリティの回帰 - 攻撃者が同じ機能を維持するために必要なゼロデイが少なくなる

  • 野生環境でのゼロデイの検出には時間がかかるため、バグのライフサイクルが長くなります。

  • ユーザーがパッチをインストールする時間を延長する

  • それほど洗練されていない攻撃方法: フィッシング、マルウェア、n-day 攻撃で十分

 

数値の増減を引き起こす可能性のあるさまざまな要因をブレインストーミングすることで、数値の背後で何が起こっているのかを理解し、そこから結論を導き出すことができます。 2022 年のオーガニック ゼロデイ数が平均を上回る 2 つの重要な要因は、ベンダーの透明性とバリアントです。検出と透明性に対するベンダーの継続的な取り組みは明らかに勝利ですが、ゼロデイ亜種が蔓延する割合が高いのは素晴らしいことではありません。これらのバリエーションについては、「既視感」セクションでさらに詳しく説明します。

同様に、2021 年から 2022 年にかけて自然ゼロデイ数の減少に寄与する可能性のある主要な要因のいくつかを評価します。プラスの要因としては、悪用可能なバグの減少が挙げられ、その結果、多くの攻撃者が互いに異なる手法を使用するようになり、悪影響が生じます。あまり洗練されていない攻撃方法で、有効性はゼロデイ脆弱性と同じですが、ゼロデイ脆弱性の検出には時間がかかります。野生でのゼロ日の数だけでは、野生での利用状況についてはあまりわかりませんが、この数字に影響を与えるさまざまな要因が本当の教訓となります。次のセクションでこれらについて詳しく説明します。

Android に 0day は必要ですか?

2022 年、Android エコシステム全体で、上流のメーカーがこの問題に対するパッチをリリースしたものの、下流のメーカーがパッチを受け入れず、ユーザーが適用できる修正をリリースするという一連のケースが見られました。 Project Zero は、2022 年 11 月のブログ投稿「Mind the Gap」でこれらの事例の 1 つを紹介しました。

上流ベンダーと下流メーカーとの間にこうしたギャップがあるため、ユーザーはすぐに入手できるパッチがなく、デバイスの使用を中止することが唯一の防御手段であるため、n-day (既知の脆弱性) が 0-day として機能する可能性があります。これらのギャップはほとんどの上流と下流の関係に存在しますが、Android ではより一般的であり、より長く続きます。

これは攻撃者にとって好都合なケースです。攻撃者は既知の n デイ脆弱性を悪用する可能性がありますが、影響を受けるすべてのデバイスに適用されるため、それを 0 デイ脆弱性として実行する可能性があります。 2022 年に Android で発生するこの例としては、ARM Mali GPU の脆弱性である CVE-2022-38181 があります。この脆弱性は、2022 年 7 月に Github Security Labs のセキュリティ研究者である Man Yue Mo 氏によって Android セキュリティ チームに最初に報告されました。その後、Android セキュリティ チームは、この問題は「デバイス固有」であるため「修正不可能」であると判断しました。ただし、Android セキュリティ部門はこの問題を ARM に報告しました。 2022 年 10 月に、ARM は脆弱性を修正した新しいドライバー バージョンをリリースしました。 2022 年 11 月に、TAG はこの脆弱性が実際に使用されていることを発見しました。 ARM は 2022 年 10 月に修正ドライバー バージョンをリリースしましたが、この脆弱性は ARM が最初にリリースされてから 6 か月後、Man Yue Mo によって最初に報告されてから 9 か月後の 2023 年 4 月まで Android によって修正されませんでした。数か月。

  • 2022 年 7 月: Android セキュリティ チームに報告

  • 2022 年 8 月: Android のセキュリティが「修正不可能」とマークされ、ARM に送られる

  • 2022 年 10 月: ARM がバグを修正

  • 2022 年 11 月: 脆弱性が実際に発見される

  • 2023 年 4 月: Android セキュリティ情報に掲載

2022 年 12 月、TAG は、Samsung Internet Browser の最新バージョンをターゲットとした別のエクスプロイト チェーンを発見しました。当時、Samsung のインターネット ブラウザの最新バージョンは、7 か月前の 2022 年 5 月にリリースされた Chromium 102 上で動作していました。この連鎖の一環として、攻撃者は、0 デイとして実行可能な 2 つの n デイ脆弱性、CVE-2022-3038 (2022 年 6 月に Chrome 105 でパッチ適用) と ARM Mali GPU カーネル ドライバ CVE-2022-22706 を悪用することができました。 ARM は 2022 年 1 月に CVE-2022-22706 のパッチをリリースし、実際にエクスプロイトとしてフラグが立てられましたが、攻撃者は 11 か月後でもそれをゼロデイとして使用できました。この脆弱性は 2022 年 1 月に広く悪用されましたが、Android のセキュリティ情報には 2023 年 6 月まで掲載されませんでした。

0 日として機能するこれらの n 日は、0 日として追跡されるかどうかのグレーゾーンに該当します。以前は、CVE-2019-2215 および CVE-2021-1048 を 0 日としてカウントすることがありました。これら 2 つの脆弱性の場合、上流の Linux カーネルでバグは修正されていますが、Linux 標準に従って CVE が割り当てられていません。これらは、広く発見される前に Android でパッチを適用する必要があるセキュリティ問題として特定されなかったため、これらを含めました。 CVE-2022-38181 の場合、このバグは当初 Android に報告され、ARM はこの問題に対してセキュリティ勧告を発行し、ダウンストリーム ユーザーがパッチを適用する必要があることを示しました。私たちは引き続きこのエラーの「グレーゾーン」を解読する試みを続けますが、エラーを追跡する方法についての意見を歓迎します。

2021 年のブラウザはどうなるのか

全体の数字と同様に、実際にブラウザをターゲットとして検出されたゼロデイの数は、2021 年から 2022 年にかけて 26 件から 15 件へと 42% 減少しました。これは、攻撃をより困難にするためのブラウザーの取り組みを反映していると当社は評価しており、全体として、攻撃者の行動はブラウザーから、デバイス上の他のコンポーネントをターゲットとしたゼロクリック攻撃へと移行しています。

 

0day の盛衰: 2022 年に 0day が悪用された年の振り返り

 

上位のブラウザ防御の進歩は、エクスプロイト チェーンの初期ベクトルとして他のコンポーネントのプッシュに影響を与える可能性があります。 2022 年を通じて、より多くのブラウザーがリリースされ、エクスプロイトに対する追加の防御機能が強化されることが予想されます。 Chrome の場合、これは MiraclePtr、v8 サンドボックス、および libc++ の機能強化です。 Safari ではロックダウン モードが導入され、Firefox ではより詳細なサンドボックスが導入されました。攻撃的セキュリティ ベンダーである Dataflow Security の脆弱性研究者兼脆弱性開発者である Ki Chan Ahn 氏は、2023 年 4 月の Zer0Con 基調講演で、この種の緩和策によってブラウザーの悪用がどのように困難になり、人々が他の攻撃面に目を向けるようになるかについてコメントしました。

 

ブラウザの悪用はますます困難になってきており、悪用の配信は過去数年間で進化し続けており、これが 2022 年のブラウザのバグ数の減少を説明しています。 2019 年と 2020 年に、野生で検出されたゼロデイの大部分は水飲み場攻撃によるものでした。水飲み場攻撃とは、攻撃者が Web サイトにアクセスすると思われるグループを標的にすることです。サイトにアクセスした人は誰でも悪用され、最終的なペイロード (通常はスパイウェア) が配信されます。 2021 年には、ワンクリック リンクが最初の攻撃ベクトルになることがよく見られます。水飲み場攻撃とワンクリック リンクはどちらも、デバイス上の初期ベクトルとしてブラウザを使用します。 2022 年には、より多くの攻撃者がゼロクリック エクスプロイト (ユーザーの介入なしでトリガーできるエクスプロイト) に目を向けるようになります。ゼロクリックは、ブラウザ以外のデバイスのコンポーネントをターゲットにする傾向があります。

 

2021 年後半、Citizen Lab は、NSO が Pegasus スパイウェアで使用していた iMessage を標的としたゼロクリック脆弱性 (CVE-2023-30860) を捕捉しました。 Project Zero では、この 2 部構成のブログ投稿シリーズで脆弱性について詳しく説明しています。 2022 年にワイルド 0 ヒットが公的に検出および開示されたことはありませんが、使用量が不足しているという意味ではありません。私たちは、複数の攻撃者が 0-click エクスプロイト チェーンを使用し、現在も使用していることを認識しています。

ゼロ クリックは次の理由から検出が困難です。

  • 彼らの寿命は短い

  • 通常、それらの存在を示す明らかな兆候はありません

  • 多くの異なるコンポーネントが対象となる可能性があり、ベンダーはリモートからアクセス可能なすべてのコンポーネントを常に認識しているわけではありません。

  • 水飲み場攻撃のように広く利用できるのではなく、ターゲットに直接配信します。

  • 通常、ナビゲート可能な Web サイトまたはサーバーではホストされません

 

ワンクリックエクスプロイトの場合、ターゲットはエクスプロイトを配信するために表示されているリンクをクリックする必要があります。これは、ターゲットまたはセキュリティ ツールがリンクを検出する可能性があることを意味します。このリンクは、ナビゲート可能なサーバー上で脆弱性をホストするために使用されます。

一方、ゼロクリックは、通常、着信通話またはメッセージを処理するコードをターゲットとします。つまり、着信メッセージまたは通話のインジケーターが表示される前に実行できることがよくあります。これにより、それらの寿命が大幅に短縮され、「生きている」と検出できる期間も大幅に短縮されます。攻撃者は今後もゼロクリック エクスプロイトを利用する可能性が高いため、防御者としては、これらのエクスプロイトを検出してユーザーを保護する方法に焦点を当てる必要があります。

Deja Vu: 完全なパッチ適用は依然として最大のチャンスの 1 つ

2022 年に実際に発見された 41 件の 0days のうち 17 件は、以前に公開された脆弱性の亜種でした。私たちは、2020 年のレビュー レポート「Deja vu-lnerability」で初めて関連コンテンツを公開し、2020 年以降 0 日間に出現した 25% は以前に公開されたバグの亜種であると指摘しました。この数は増加し続けていますが、その原因としては次のようなことが考えられます。

  • ディフェンダーはバリアントを識別する能力が向上しており、

  • Defender は、実際のゼロデイ亜種の検出を改善します。

  • 攻撃者はさらに多くの亜種を利用している、または

  • 脆弱性の修正は十分に包括的ではないため、さらに多くの亜種が存在します。

答えはおそらく上記すべての組み合わせですが、ユーザーが悪用できるゼロデイ亜種の数は減少していないことがわかっています。悪用可能な亜種の数を減らすことは、テクノロジー業界およびセキュリティ業界における最大のチャンス分野の 1 つであり、攻撃者はゼロデイ脆弱性を悪用するためにより一層の努力を強いられています。

2020 年のワイルド 0 デイの亜種が 40% を超えているだけでなく、20% を超えるバグはすべて以前のワイルド 0 デイの亜種であり、2021 年は 7 件、2020 年は 1 件です。 0dayは野生で捕獲され、贈り物です。攻撃者は、自分たちがどのような脆弱性を抱えているのか、またどのような悪用手法を使用しているのかを私たちに知られることを望んでいません。防御者はこの恩恵をできる限り活用し、攻撃者がゼロデイ脆弱性を再度悪用することを可能な限り困難にする必要があります。これには以下が含まれます。

  • エラーを分析して、この状況で攻撃者が選択した悪用方法だけでなく、真の根本原因を見つけます。

  • 同じエラーが存在する可能性がある他の場所を探します

  • バグの悪用に使用される可能性のある他のパスを評価します。

  • パッチを真の根本原因と比較し、回避策があるかどうかを判断します。

パッチが正しく、包括的である場合にのみ、パッチが完了したとみなされます。正しいパッチとは、バグを完全に正確に修正するものであり、脆弱性が悪用されなくなることを意味します。包括的なパッチは、修正を適用する必要があるすべての場所に適用され、すべての亜種をカバーします。単一の脆弱性またはバグが悪用される場合、多くの場合、その脆弱性を引き起こす複数の方法、または脆弱性にアクセスするための複数のパスが存在します。ベンダーが脆弱性全体を修正するのではなく、概念実証やエクスプロイトの例で示されたパスのみをブロックすることがよくあります。同様に、セキュリティ研究者は、パッチがどのように機能するかを追跡せず、関連する攻撃を調査せずにバグを報告することがよくあります。

不完全なパッチによって攻撃者がゼロデイを悪用しやすくなるという考えは人々を不快にさせるかもしれませんが、この結論の裏返しは私たちに希望を与える可能性があります。私たちはゼロデイをより困難にするための明確な道筋を持っています。より多くの脆弱性が正確かつ包括的にパッチされれば、攻撃者がゼロデイを悪用することはより困難になります。

以下の表に、特定されたすべての脆弱性の亜種をリストしました。 In-the-wild 0-day がどのようにバリアントであるかを詳しく知りたい場合は、FIRST カンファレンスのプレゼンテーション [ビデオ、スライド]、Zer0Con のスライド、OffectiveCon のプレゼンテーション [ビデオ、スライド] CVE-2022-41073 をご覧ください。 、および CVE-2022-22620 に関するこのブログ投稿。

製品

2022 ITW CVE

変異体

Windows win32k

CVE-2022-21882

CVE-2021-1732 (2021 itw)

iOS IOMobileFrameBuffer

CVE-2022-22587

CVE-2021-30983 (2021 itw)

ウェブキット「ゾンビ」

CVE-2022-22620

バグは 2013 年に修正され、2016 年にパッチがリグレッションされました。

Firefox WebGPU IPC

CVE-2022-26485

ファジングクラッシュは 2021 年に修正されました

ARM Mali GPU の Android

CVE-2021-39793 CVE-2022-22706

CVE-2021-28664 (2021 itw)

ソフォス ファイアウォール

CVE-2022-1040

CVE-2020-12271 (2020 itw)

クロムv8

CVE-2022-1096

CVE-2021-30551 (2021 itw)

クロム

CVE-2022-1364

CVE-2021-21195

Windows「プチポタム」

CVE-2022-26925

CVE-2021-36942 – パッチがリグレッションしました

ウィンドウズ「フォリーナ」

CVE-2022-30190

CVE-2021-40444

(2021itw)

アトラシアン Confluence

CVE-2022-26134

CVE-2021-26084 (2021 itw)

クロムインテント

CVE-2022-2856

CVE-2021-38000 (2021 itw)

Exchange SSRF「ProxyNotShell」

CVE-2022-41040

CVE-2021-34473「プロキシシェル」

Exchange RCE「ProxyNotShell」

CVE-2022-41082

CVE-2023-21529「プロキシシェル」

Internet Explorer JScript9

CVE-2022-41128

CVE-2021-34480

Windowsの「プリントスプーラー」

CVE-2022-41073

CVE-2022-37987

ウェブキット JSC

CVE-2022-42856

テスト失敗により2016年のバグが発見

エクスプロイトは著作権で保護されない

世の中の多くの商品とは異なり、0day 自体には制限がありません。ある人がゼロデイ脆弱性の存在を発見し、それをエクスプロイトとして開発したからといって、他の人が独自にゼロデイ脆弱性を発見し、それをエクスプロイトに使用することを妨げるものではありません。独自の脆弱性調査やエクスプロイト開発を行うほとんどの攻撃者は、他の人が同じことをすることを望んでいません。そうすることで脆弱性の価値が低下し、すぐに検出され修正される可能性が高くなるからです。

ここ数年、複数の研究者が同じ脆弱性を発見するという、大規模なバグ競合の傾向に気づいています。これは、ベンダーにバグを報告する攻撃者とセキュリティ研究者の間で発生します。バグの競合は常に発生しており、その発生率を正確に測定することはできませんが、セキュリティ アドバイザリで同じ脆弱性として個別に特定されたさまざまなエンティティの数、2 つの異なる脆弱性で見つかった同じ 0day、さらには会話の数を測定することはできません。の研究者らも、これがより頻繁に起こっていることを示唆しています。

誤った競合の数が増加することは、攻撃者が全体的に使用するゼロデイが少なくなることを意味するため、防御側にとっては有利です。攻撃対象領域を制限し、悪用可能なバグの種類を減らすことは、研究者が同じバグを発見するのに確かに役立ちますが、より多くのセキュリティ研究者が研究結果を発表することも貢献する可能性があります。人々は同じ研究を読んで次のプロジェクトのアイデアを思いつきますが、それは多くの人々にも同様のアイデアを引き起こします。プラットフォームと攻撃対象領域もますます複雑化しており、新しいコンポーネントやターゲットに関する専門知識を構築するには多大な時間の投資が必要です。

セキュリティ研究者とその脆弱性レポートは、特定の 0day が実際に検出されていない場合でも、攻撃者が使用しているのと同じ 0day を修正するのに役立ち、それによって攻撃者の脆弱性が侵害されます。ユーザーを標的にする可能性のある同じ脆弱性の修正に役立つため、ベンダーが引き続き研究者をサポートし、バグ報奨金プログラムに投資することを願っています。また、セキュリティ研究者が既知の自然なバグや脆弱性に徹底的にパッチを適用することがなぜ重要なのかも強調しています。

何をするべきだろう?

2022 年を振り返ると、私たちの全体的な結論としては、業界として私たちは正しい道を歩んでいますが、多くのチャンスがある分野があり、そのうちの最大のものは報告された脆弱性に対する業界の対応です。

  • ユーザーが自分自身を守れるように、修正と緩和策を迅速に提供する必要があります。
  • 脆弱性の根本原因を確実に解決するには、詳細な分析を実行する必要があります。
  • できるだけ多くの技術的な詳細を共有する必要があります。
  • 報告された脆弱性を利用して、可能な限り学習し、修正する必要があります。

これはどれも簡単なことではありませんが、この分野で働くセキュリティ チームにとっては驚くべきことではありません。ユーザーの迅速な保護と包括性の確保とのバランスをとるパッチ適用プロセスの投資、優先順位付け、開発が必要ですが、これは時としてストレスになる場合があります。必要な投資はそれぞれの固有の状況によって異なりますが、人員/リソース、インセンティブ構造、プロセスの成熟度、自動化/テスト、リリース頻度、パートナーシップなどに共通のテーマがいくつか見られます。

この投稿では、根本原因、パッチ、亜種、悪用手法の分析など、バグが適切かつ包括的に修正されることを保証するための取り組みについて詳しく説明します。私たちは引き続きこれらの分析の実施を支援していきますが、プラットフォーム セキュリティ チームやその他の独立したセキュリティ研究者も同様にこれらの取り組みに投資することを期待し、奨励しています。

最終的な考察: TAG の新しいエクスプロイト チーム

2023 年下半期に向けて、私たちは今後何が起こるか楽しみにしています。以前のレポートが Plan Zero ブログに投稿されていることにお気付きかと思います。当社の 0day in the wild プログラムは、脆弱性分析、検出、脅威アクター追跡の専門知識を 1 つのチームに統合し、追加リソースの恩恵を受け、最終的に次のことを達成するために、プログラム ゼロから TAG に移行しました。 TAG の脆弱性!今後はさらに多くのことが行われますが、これがユーザーをゼロデイ攻撃から保護し、ゼロデイ攻撃を困難にする上で何を意味するのか、私たちは非常に楽しみにしています。

出典: https://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html

原文、著者:xbear、転載する場合は出典を明記してください:https://cncso.com/jp/the-ups-and-downs-of-0-days-year-in.html

のように (0)
前の 2023年8月1日午前7時
2023年8月3日午前12時

関連する提案