記録破りのDDoS攻撃!サイバー脅威の拡大と企業が取るべき対策とは?

Share

近年、DDoS攻撃の規模と頻度が急激に増加しており、企業や組織にとって無視できない脅威となっています。特に、2024年第4四半期には、過去最大規模となる5.6テラビット毎秒(Tbps)のDDoS攻撃が確認され、サイバー攻撃の新たな段階へと突入したことがわかりました。この攻撃は、わずか80秒間で1万3,000台以上のIoTデバイスを利用して実行され、Cloudflare社のDDoS防御システムによって自動的に検出・ブロックされました。

お問い合わせ

お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

DDos攻撃の事例として、SQAT.jpでは日本航空へのサイバー攻撃の実態についても解説しています。こちらもあわせてぜひご覧ください。
【徹底解説】 日本航空のDDoS攻撃被害の実態と復旧プロセス
Dos攻撃とは?DDos攻撃との違い、すぐにできる3つの基本的な対策

DDoS攻撃の増加と進化する手口

2024年第4四半期には、Cloudflare社が軽減したDDoS攻撃の件数が690万件にのぼり、前四半期比16%、前年比83%の増加を記録しました。さらに、1Tbpsを超える大規模攻撃の件数は前四半期比で1,885%も増加し、これまで以上に大規模な攻撃が常態化しつつあります。

HTTP DDoS攻撃では、既知のボットネットによる攻撃が全体の73%を占め、11%は正規のブラウザを装った攻撃、10%は疑わしいHTTPリクエストによる攻撃でした。ネットワーク層(L3/L4)攻撃では、SYNフラッド(38%)、DNSフラッド(16%)、UDPフラッド(14%)が主要な手法として確認されています。また、Miraiボットネットの亜種による攻撃が特に顕著であり、2024年第4四半期には、この攻撃手法の使用頻度が131%も増加しました。

企業が直面するDDoS攻撃のリスクとは?

DDoS攻撃がもたらす影響は多岐にわたります。最も直接的な被害は、システムのダウンによる業務停止であり、企業の信用低下や顧客離れにつながる可能性があります。また、近年増加している「ランサムDDoS攻撃(Ransom DDoS)」では、攻撃を受けた企業が身代金の支払いを要求されるケースが増えています。2024年第4四半期には、Cloudflare社の顧客でDDoS攻撃を受けた顧客のうち、12%が身代金の支払いを求められ、前年同期比で78%の増加を記録しました。

業界別にみると、通信業界が最も多くの攻撃を受け、次いでインターネット関連業界、マーケティング・広告業界が標的となっています。特に、金融業界は依然としてサイバー犯罪者にとって魅力的なターゲットとなっており、資金詐取を目的とした攻撃が増加しています。

DDoS攻撃から企業を守るための対策

DDoS攻撃の脅威が拡大するなか、企業は効果的な防御策を講じる必要があります。特に、以下のような対策が推奨されます。

  1. 常時オンのDDoS防御システムの導入
    DDoS攻撃の多くは短時間で発生するため、人間の対応では間に合わないケースが多いです。自動検知・防御機能を備えたDDoS対策ソリューションを導入することで、攻撃を迅速に無力化できます。
  1. ネットワーク層とアプリケーション層の両方を保護
    DDoS攻撃には、L3/L4(ネットワーク層)攻撃とL7(アプリケーション層)攻撃があります。両方の層に対する防御対策を講じ、ファイアウォールやWAF(Web Application Firewall)を活用することが重要です。
  1. ゼロトラストアーキテクチャの採用
    攻撃者の侵入を最小限に抑えるために、ゼロトラストモデルを導入することも有効です。認証・認可プロセスを強化し、アクセス制御を厳格化することで、不正なトラフィックを遮断できます。
  1. クラウドベースのDDoS対策の活用
    オンプレミスのDDoS対策はコストが高く、攻撃の規模が拡大するにつれて対応が難しくなります。クラウドベースのDDoS防御サービスを活用することで、スケーラブルなセキュリティ対策を実現できます。
  1. 定期的な脆弱性診断とインシデント対応計画の策定
    攻撃のリスクを最小限に抑えるために、定期的なセキュリティ監査を実施し、DDoS攻撃を想定したインシデント対応計画を策定することが不可欠です。特に、SLA(サービスレベルアグリーメント)を明確にし、攻撃発生時の対応フローを事前に決めておくことが重要です。

今後のDDoS攻撃トレンドと企業が取るべきアクション

DDoS攻撃は今後さらに巧妙化し、大規模化すると予想されています。特に、AIを活用したボットネット攻撃や、IoTデバイスを悪用した攻撃が増加する見込みです。さらに、特定の企業や業界を標的とした「高度な標的型攻撃(APT)」の手法がDDoS攻撃にも応用される可能性があります。

企業は、単に防御するだけでなく、プロアクティブなセキュリティ戦略を採用し、攻撃を未然に防ぐ体制を構築する必要があります。DDoS攻撃はもはや一部の企業だけの問題ではなく、あらゆる業界にとって喫緊の課題となっています。

常に最新の脅威情報を把握し、効果的な防御策を講じることで、企業のシステムとデータを守ることができます。DDoS攻撃のリスクを最小限に抑えるためには、今すぐ適切な対策を実施することが求められるでしょう。


Security Report TOPに戻る
TOP-更新情報に戻る

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

  • 2025年2月19日(水)14:00~15:00
    Web担当者に求められる役割とは?Webサイトのガバナンス強化とセキュリティ対策を解説
  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 2025年3月5日(水)13:00~14:00
    ランサムウェア対策の要!ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年3月12日(水)14:00~15:00
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    北朝鮮によるソーシャルエンジニアリング攻撃ソーシャルエンジニアリング攻撃とは?手口と脅威を解説

    Share

    2024年12月24日、警察庁および金融庁は、同年5月に発生した国内の暗号資産(仮想通貨)取引所から約482億円が窃取された事案に関連して注意喚起*1を発表しました。本記事では、北朝鮮によるソーシャルエンジニアリング攻撃の事例と手法を解説し、企業が取るべき対策例をご紹介します。

    ソーシャルエンジニアリング攻撃の概要

    北朝鮮のサイバー攻撃グループ「TraderTraitor(トレイダートレイター)」は暗号資産・NFTの窃取を目的とした不正アクセスやソーシャルエンジニアリングを駆使した攻撃を行っています。CISA(米サイバーセキュリティ・インフラセキュリティ庁)によると、暗号資産事業者に加えて暗号通貨に投資するベンチャーキャピタルや暗号通貨・NFTの個人保有者など、ブロックチェーン技術や暗号通貨業界の様々な組織が標的とされていることが確認されています*2

    ソーシャルエンジニアリングとは
    ソーシャルエンジニアリングは、人の心理を巧みに操り、重要な情報を引き出す手法です。この手法を使った攻撃がソーシャルエンジニアリング攻撃で、攻撃者は情報収集やシステムへの不正アクセスなどを目的に、人を心理的に操作して、攻撃者にとって都合のいい行動を起こさせます。

    関連記事:「ソーシャルエンジニアリングとは?その手法と対策

    ソーシャルエンジニアリングの手法

    「TraderTraitor」はまず、ビジネスパーソン向けの交流サイト「LinkedIn」上で採用希望者になりすまし、ターゲットとなる企業の従業員に接触しています。これにより、従業員の信頼を得たうえで企業の内部システムに侵入し、暗号通貨の正規取引を改ざんしたとされています。

    SNSを悪用した手法は近年の北朝鮮の攻撃キャンペーンに多く使われる手法です。偽のアカウント・ペルソナを構築し、ターゲット企業や個人にアプローチします。ディープフェイク技術を用いて履歴書やSNSに掲載する画像やビデオ通話の偽装を行うこともあります。このアプローチは、ターゲット企業内の資産を窃取する、従業員として入り込んで国連決議に基づく経済制裁をかいくぐって外貨を獲得する、ターゲット企業にマルウェアを展開するといった侵害を目的としています。

    参考:金融庁/警察庁/内閣サイバーセキュリティセンター
    北朝鮮当局の下部組織とされるラザルスと呼称されるサイバー攻撃グループによる 暗号資産関連事業者等を標的としたサイバー攻撃について(注意喚起)

    ソーシャルエンジニアリング攻撃の代表的な手法

    手法
    フィッシングターゲットをだますことで情報を引き出す(認証情報や個人情報)、マルウェアやマルウェアのダウンローダーなどの実行リンクや添付ファイルを送信する。従来はメールやSMSを使う手法が主流だったが、近年はSNSや音声を使う手法も増えている
    スピアフィッシングフィッシングの一形態
    特定の個人や企業を狙ったフィッシング攻撃を指す
    ビジネスメール詐欺取引先などになりすまし、入金を促す詐欺
    ベイティングマルウェアを仕込んだUSBメモリを廊下に落とす、無料の音楽や映画のダウンロードを提供し認証情報を盗むなど、「餌」を使って被害者をおびき寄せる攻撃
    プリテキスティング権威のある人物(銀行員、警察、ITサポートなど)になりすまし、個人情報を聞き出す
    テールゲーティング正規従業員の同僚や配達員、修理業者などを装って物理的なセキュリティを突破し、機密情報にアクセスする

    ソーシャルエンジニアリング攻撃の事例

    近年の代表的なソーシャルエンジニアリング攻撃2例をご紹介します。

    • XZ Utilsへのソーシャルエンジニアリング攻撃
      Linuxのオープンソース圧縮ファイルアプリケーションXZ Utilsに悪意のあるコードが埋め込まれたことが発見されたことから2024年3月に発覚した事件*3です。その後、偽のペルソナを騙る攻撃者が約2年間、プロジェクトの貢献者として活動し、悪意のあるコードを埋め込んでいたことが判明した事件です。オープンソースプロジェクトのエコシステムの在り方も同時に問われたのでご存じの方も多いのではないでしょうか。
    • ディープフェイク技術を悪用した詐欺
      在香港の多国籍企業の財務担当者がディープフェイクを用いたビデオ通話会議を通じて騙され、2億香港ドル(日本円で約40億円)を詐欺師に送金してしまった事件*4です。財務担当者は当初CFOを名乗る人物から送られたメールには疑念を抱いたものの、ビデオ通話会議に実在の同僚やCFOが出席しているものと思い込んだことが原因とされています。

    ソーシャルエンジニアリング攻撃の対策方法

    今回の北朝鮮によるソーシャルエンジニアリング攻撃を受け、FBIは注意喚起*5を行い、企業や個人に対して警戒を促しました。また、日本の警察庁も企業に対し、セキュリティ対策の強化を求めています。企業側では、「システム管理者」「従業員」「人事担当者」の3方向からの対策例を考え、組織一丸となってセキュリティ対策を実行することが重要です。技術的な面では、マルウェア検出システムの導入や定期的な更新も重要となります。これにより、自組織がソーシャルエンジニアリング攻撃で踏み台にされていた場合でも被害を最小限に抑えることが可能になります。

    ディープフェイクを用いたSNS上の偽アカウント・ペルソナは、過去の研究で多くの人が簡単に見抜けないことが明らかになっています。企業や個人は最新の攻撃手法を把握し、適切なセキュリティ対策を講じることが不可欠です。継続的な教育、技術的防御、国際協力を通じて、安全なデジタル環境を維持することが求められます。

    関連情報:
    Mink, J., Luo, L., Barbosa, N. M., Figueira, O., Wang, Y., & Wang, G. (Year), University of Illinois at Urbana-Champaign & Santa Clara University., DeepPhish: Understanding User Trust Towards Artificially Generated Profiles in Online Social Networks.

    まとめ

    • ソーシャルエンジニアリングとは、人の心理を巧みに操り、重要情報等を聞き出したりすること
    • 従業員教育×技術対策×物理セキュリティの3つを組み合わせて対策を強化
    • 最新の攻撃手法を把握し、適切なセキュリティ対策を講じることが重要

    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2025年2月19日(水)14:00~15:00
    Web担当者に求められる役割とは?Webサイトのガバナンス強化とセキュリティ対策を解説
  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    【徹底解説】
    日本航空のDDoS攻撃被害の実態と復旧プロセス

    Share

    概要

    2024年12月26日、日本航空(JAL)はDDoS攻撃を受け、国内外のフライトで大規模な遅延が発生。国内線60便、国際線24便で30分以上の遅延が生じ、最大4時間2分の遅延が報告されました。攻撃はネットワーク機器への大量データ送信による過負荷が原因で、飛行計画や貨物重量計算システムが通信不能となりました。

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

    DDos攻撃について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてぜひご覧ください。
    記録破りのDDoS攻撃!サイバー脅威の拡大と企業が取るべき対策とは?
    Dos攻撃とは?DDos攻撃との違い、すぐにできる3つの基本的な対策

    DDoS攻撃とは?

    DDoS攻撃とは、攻撃者が複数のコンピューターを利用し、標的のシステムに大量のデータを送りつけることでサービスを妨害する手法です。特に航空業界では、この攻撃が深刻な影響を及ぼすことがあります。日本航空(JAL)に対する攻撃もその一例であり、システムに過負荷をかけ、正常な運用を妨げました。

    攻撃の詳細

    このDDoS攻撃は、2024年12月26日午前7時24分に発生しました。この時間帯は多くのフライトが運航するピーク時であり、影響は甚大でした。日本航空(JAL)は、攻撃発生時に多くの乗客が移動中であったため、システムの混乱がさらに深刻化したと報告しています。DDoS攻撃の結果、JALの一部システムが一時的に停止し、フライトの遅延が発生しました。具体的には、国内線24便が30分以上遅延し、多くの乗客に影響を与えました。

    システム復旧の過程

    日本航空(JAL)は、発生したDDoS攻撃により、システムの不具合や航空券販売の停止、フライトの遅延などの影響を受けました。年末の繁忙期に多くの乗客が影響を受ける中、専門のサイバーセキュリティチームが迅速に対応し、ネットワークの一時遮断と復旧作業を実施。数時間でシステムは正常化し、フライトの安全性にも影響はありませんでした。復旧後、JALはセキュリティ対策を強化し、最新の防御技術を導入するとともに、従業員のサイバーセキュリティ教育を推進。今後の攻撃リスクを軽減し、乗客の安全確保を目指しています。

    DDoS攻撃に対する今後の予防策

    1. 多要素認証の導入
      システムへのアクセス制限を強化し、不正アクセスを防止する
    2. 定期的なネットワークのストレステスト
      脆弱性を早期に発見し、攻撃時の影響を最小限に抑える
    3. サイバーセキュリティ意識の向上
      スタッフへの定期的なトレーニングや演習を実施し、攻撃の兆候を早期に察知できる体制を整備する
    4. インシデント対応計画の見直しと更新
      攻撃発生時の役割分担や連絡体制を明確化し、シミュレーションを通じて計画の実効性を確認する
    5. 過去の攻撃事例の分析と対策の最適化
      これまでの攻撃事例を検証し、より効果的な防御策を導入することで業務の継続性を確保する

    これらの対策を実施することで、DDoS攻撃のリスクを軽減し、システムの安全性を高めることができます。

    まとめ

    今回の事件は、日本のサイバーセキュリティの脆弱性を浮き彫りにし、航空業界全体における防御強化の必要性を示しました。今後、日本は国際的な協力を強化し、より強固なサイバーセキュリティ対策を講じることが求められます。今回の事件を教訓に、防御策の強化が急がれています。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2025年2月12日(水)14:00~15:00
    ランサムウェア攻撃の脅威~感染リスクを可視化する防御策の実践を紹介~
  • 2025年2月19日(水)14:00~15:00
    Web担当者に求められる役割とは?Webサイトのガバナンス強化とセキュリティ対策を解説
  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Windows10のサポート終了-その影響とリスクを考える-

    Share

    2025年10月14日、Windows10のサポートが終了します。これにより、マイクロソフトによるセキュリティ更新プログラムの配信と技術サポートが完全に停止されます。現在、多くの企業や個人ユーザーがWindows10を利用していますが、サポート終了を見据え、システムの移行やアップデート計画を早急に検討する必要が出てきています。

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

    サポート終了後に直面するリスク

    サポートが終了したソフトウェアの継続利用は、重大なセキュリティリスクを伴います。Windows10の場合、セキュリティ更新が行われなくなることで、新たに発見される脆弱性に対して無防備な状態となってしまいます。日々進化するサイバー攻撃において、攻撃者はこうしたサポート終了後のソフトウェアを格好の標的としています。主なリスクとして、以下が挙げられます。

    1. 脆弱性を突かれるリスク

    サポート終了後に発見された脆弱性は、修正されないまま放置されることになります。攻撃者はこの未修正の脆弱性を悪用し、システムへの不正アクセスやデータの窃取を試みる可能性が高まります。特に企業のネットワーク環境では、1台の更新されていないPCが、システム全体にとっての弱点となりかねません。

    2. コンプライアンス上の問題

    近年、多くの業界で求められる各種規制やコンプライアンス要件では、最新のセキュリティ対策の実施が必須となっています。サポート終了したWindows10の使用は、これらの基準に抵触する恐れがあり、企業の信用失墜や法的制裁につながる可能性があります。

    3. ソフトウェアの互換性における課題

    最新のアプリケーションやハードウェアは、サポートの終了したOSでの動作保証を行いません。Windows10のサポート終了後は、新しいソフトウェアやデバイスが正常に機能しなくなる可能性が高く、業務効率の低下が懸念されます。

    Windows11への移行がもたらすメリット

    これらのリスクを回避するためには、最新のOSへの移行が不可欠です。現時点では、Windows11への移行が最も現実的な選択肢となっています。Window11では、セキュリティ機能の強化に加え、パフォーマンスの向上や最新テクノロジーへの対応が図られています。主なメリットは以下の通りです。

    • 最新のセキュリティ更新が継続的に提供され、新たな脅威からシステムを保護
    • ハイブリッドワークやAI活用に最適化された機能により、業務効率が向上
    • 各種セキュリティ要件への準拠により、コンプライアンスリスクを軽減

    計画的な移行の重要性

    Windows10のサポート終了に向けて、綿密な移行計画の策定が求められます。まずは現行のPCやシステムがWindows11の動作要件を満たしているか確認し、必要に応じて機器の更新計画を立てましょう。また、重要なデータのバックアップや、新システムに関する従業員向けトレーニングの実施も欠かせません。企業はIT部門と緊密に連携しながら、段階的な移行スケジュールを組むことで、業務への影響を最小限に抑えることができます。

    おわりに

    Windows10のサポート終了は、企業・個人を問わず、重要な転換点となります。セキュリティリスクや業務効率の観点から、サポート終了後のソフトウェア使用は避けるべきでしょう。早期から移行計画を策定することで、潜在的なリスクを回避しつつ、最新技術を活用できる環境を整えます。この機会に、Windows11への移行について具体的な検討を始めてみてはいかがでしょうか。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン

    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2025年1月22日(水)14:00~15:00
    ランサムウェア対策の要!ペネトレーションテストとは? -ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年1月29日(水)13:00~14:00
    サイバー攻撃から企業を守る!ソースコード診断が実現する“安全な開発”
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    AWSを狙うランサムウェアCodefingerの脅威と
    企業が取るべきセキュリティ対策

    Share

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。

    はじめに

    近年、クラウドサービスの利用が拡大する中で、新たなサイバー攻撃が注目を集めています。その中でもCodefingerというランサムウェアグループが、Amazon Web Services(AWS)のS3バケットを標的にした攻撃を展開していることが報告されています。この攻撃は、データの暗号化を通じて企業に多大な被害をもたらし、対策の重要性が浮き彫りになっています。

    ■関連記事
    https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c

    Codefingerによる攻撃の手口

    Codefingerの攻撃は、AWSの認証情報を不正に入手するところから始まります。主にフィッシング攻撃や既知の脆弱性を利用して認証情報を取得した攻撃者は、その情報を使い、AWSの「Server-Side Encryption with Customer Provided Keys(SSE-C)」機能を悪用します。この機能は、ユーザーが独自の暗号鍵を用いてデータを暗号化するものですが、攻撃者はこれを逆手に取り、データを勝手に暗号化してしまいます。

    さらに、攻撃者はS3 Object Lifecycle Management APIを使用し、データを自動的に削除するポリシーを設定します。この結果、被害を受けた企業は重要なデータにアクセスできなくなるばかりか、高額な身代金を要求される事態に陥ります。

    攻撃の影響とリスク

    この攻撃がもたらす影響は非常に深刻です。暗号化されたデータはAWS側にも復号化ができない仕組みになっており、攻撃者以外によるデータの復旧がほぼ不可能です。そのため、多くの場合、被害者は身代金を支払うか、データを諦める選択を迫られます。このような状況は、企業の業務停止や信頼失墜を引き起こし、さらには経済的損失にもつながります。また、Codefingerの攻撃手法は他のサイバー犯罪グループによって模倣される可能性があり、攻撃の拡大が懸念されています。クラウドサービスを利用する企業にとって、こうしたリスクは今後さらに高まるでしょう。

    企業が取るべき防御策

    このような攻撃に対抗するには、以下のような多層的な対策を講じることが重要です。

    • AWS環境での認証情報の管理の徹底
      AWSのセキュリティ設定を強化することも効果的です。例えば、SSE-Cの利用を制限するポリシーを設定することで、攻撃者による悪用を防ぐことができます。また、必要最低限の権限のみを付与する「権限の最小化」を徹底することで、万が一認証情報が漏洩しても被害を最小限に抑えることが可能です。
    • AWSセキュリティ設定の強化
      Codefingerによる攻撃は、AWSだけでなく、他のクラウドサービスプロバイダーにとっても警鐘となる事例です。業界全体で防御策を進化させる必要があり、クラウドサービスプロバイダーも不正なアクティビティを迅速に検出し、対応できる体制を構築する必要があります。さらに、顧客への迅速な通知体制を整えることも重要です。認証情報の漏洩が確認された場合、速やかに顧客に通知し、被害拡大を防ぐための具体的な対応策を提示することが求められます。

    業界全体でのセキュリティ強化の必要性

    Codefingerによる攻撃は、AWSだけでなく、他のクラウドサービスプロバイダーにとっても警鐘となる事例です。業界全体で防御策を進化させる必要があり、クラウドサービスプロバイダーも不正なアクティビティを迅速に検出し、対応できる体制を構築する必要があります。さらに、顧客への迅速な通知体制を整えることも重要です。認証情報の漏洩が確認された場合、速やかに顧客に通知し、被害拡大を防ぐための具体的な対応策を提示することが求められます。

    まとめ

    Codefingerの攻撃は、AWS環境におけるセキュリティリスクを浮き彫りにしました。このような脅威に対処するためには、認証情報の管理、多要素認証の導入、セキュリティ設定の強化など、企業が積極的に防御策を講じる必要があります。また、クラウドサービスプロバイダーも、不正アクセスを迅速に検出し、対応できる仕組みを強化することで、顧客の信頼を守ることが求められます。今回の事例を契機に、セキュリティ対策の見直しを検討してみてはいかがでしょうか。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン

    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2025年1月22日(水)14:00~15:00
    ランサムウェア対策の要!ペネトレーションテストとは? -ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年1月29日(水)13:00~14:00
    サイバー攻撃から企業を守る!ソースコード診断が実現する“安全な開発”
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    2024年のサイバーセキュリティ振り返り
    -KEVカタログが示す脆弱性の実態-

    Share

    米サイバーセキュリティ・社会基盤安全保障庁(Cybersecurity and Infrastructure Security Agency、以下CISA)が2021年から公開しているKEVカタログ(Known Exploited Vulnerabilities Catalog)は、悪用が確認された既知の脆弱性情報をリスト化した、サイバーセキュリティの防御に重要なデータベースです。本記事ではこのKEVカタログをもとに、2024年に注目された脆弱性情報と悪用事例を振り返ります。

    ※本記事で扱うKEVカタログの情報は2024年12月10日(アメリカ現地時間付け)のものです。2024年12月10日までにKEVカタログに登録されたCVEは175件になります。(参考:2023年1月~12月…187件)

    KEVカタログに登録された脆弱性の概要

    KEVカタログに登録された脆弱性のうち、CVSSv3.0/3.1で算出された注 1)ベーススコアの平均値は8.37注 2)、中央値は8.6でした。CVSSv3.0/3.1のスコアレンジあたりのCVE数は以下の通りです。

    表1 CVSSの深刻度に対するKEVカタログに登録されたCVEの件数

    米国以外での悪用実態の反映

    2024年はJPCERT/CCから以前注意喚起が行われた、日本を主要ターゲットとする脆弱性の悪用実態がKEVカタログに反映されています。直近で登録された脆弱性は以下の2件です。

    • CVE-2023-28461:Array Networks AGおよびvxAG ArrayOSに認証なしでSSL VPNゲートウェイ上のファイルシステムを閲覧可能にする脆弱性
      KEVカタログ登録日:2024年11月25日
      JPCERT/CC注意喚起(2023年9月22日発行):https://www.jpcert.or.jp/at/2023/at230020.html

    SQAT.jpでは以下の記事でも紹介しています。こちらもあわせてご覧ください。「緊急セキュリティ警告:ArrayOS AG における深刻な脆弱性 CVE-2023-28461

    • CVE-2023-45727:North Grid ProselfのXML外部エンティティ(XEE)参照の不適切な制限の脆弱性
      KEVカタログ登録日:2024年12月3日
      JPCERT/CC注意喚起(2023年10月26日発行):https://www.jpcert.or.jp/at/2023/at230022.html

    2024年11月にトレンドマイクロが公開したブログ*6では上記2件についてはAPT10の関連組織による悪用とされており、メインターゲットは日本、そのほかに台湾とインドとされています。ヨーロッパのみで悪用されているケースについても比較的早い時期に掲載されるようになっています。最近のものでは以下が該当します。

    なお、KEVカタログを提供するCISAはアメリカの政府機関となるため、アメリカ国内向けの情報が優先されます。一方でKEVカタログはCSV形式やjson形式でデータを公開しており、自動的な情報収集の一環に組み込みやすいという利点があります。JPCERT/CCや独BSIはそれぞれの国や地域の脅威情報をタイムリーに公開しており、KEVカタログと同時に利用することで情報の補完が図れるという利点があります。両者はHTMLファイルやPDFファイルなど、主に人が目で見ることを優先したデータの提供を各国言語で行っています。

    ベンダ別登録数

    2024年も、例年通りMicrosoftの登録数が圧倒的に多くなっています。

    図1 KEVカタログ ベンダ別登録数(一部)

    図1KEVカタログベンダ別登録数(一部)
    ※KEVカタログの2024年1月1日~12月10日および2023年1月1日~12月31日の登録情報をベンダごとに集計。2024年の当該期間の登録数上位10位(同率10位が2件)までを表示

    なぜMicrosoftの登録数が多いのか

    Microsoftの登録数が多い理由は、デスクトップ向けOSの大半をWindowsが占めているためです。直近の2024年11月の調査*2では全世界でのデスクトップ向けOSの市場占有率は72.94%となっています。企業向けのOSとしてWindows OSを選択するケースも多数に上ります。

    企業では社内リソースへのアクセス制御のためにアイデンティティ管理が必要になりますが、Windows PCが主流の社内ネットワークでアイデンティティ管理といえばActive Directoryが不可欠になります。MicrosoftのKEVカタログへの登録数が多いのはActive Directory侵害が攻撃側にとって大きなマイルストーンとなるからです。Active Directoryを侵害することによって攻撃者は特権昇格やユーザー資格の奪取、アクセス権限の制御などを行い、マルウェア(ランサムウェア含む)を配置し、自身の目的(金銭や情報の窃取など)を達成することができます。

    一方でActive Directoryは外部に公開されるものではなく、社内向けの閉じたサービスとして存在するものです。このため攻撃者は別の手段を用いて社内のネットワークに侵入し、Active Directory環境内に入り込み、横展開をしながらActive Directory本体の侵害を目指して侵害活動を行います。この横展開における侵害活動で用いられるのがWindows OSの各種機能の脆弱性(主にゼロデイ)となります。

    Active Directoryについて、過去のセキュリティトピックス解説動画では以下の内容で動画を公開中です。ぜひご覧ください。
    Active Directoryを侵害から守るためのガイド

    Windows OSの脆弱性:古いテクノロジーの残存

    Windows OSは最新版でも互換性の問題からWindows 95やNT時代の古いドライバや機能を維持しています。Internet Explorerへの互換性やKerberos認証でのRC4、NTLM、PPTPなどが該当するのではないでしょうか。この中でも2023年6月にInternet Explorerはデスクトップアプリとしての使命を終えていますが、Internet Explorerを構成していたドライバは互換性(EdgeにおけるIEモードのサポート)の維持の目的で最新のOSでも残存しています。

    事例:CVE-2024-43573:Windows MSHTMLの脆弱性

    MSHTMLはInternet Explorerのレンダリングエンジンで、互換性の維持を目的にWindows 10/11でも現存しているドライバです。この脆弱性はユーザーには存在しないはずのInternet Explorerの機能を呼び出し、Internet Explorerの脆弱な保護機能を悪用してマルウェアをダウンロードさせることを目的とした攻撃に悪用されました。悪用の概要は下図の通りです。

    図2 CVE-2024-43573:Windows MSHTMLの脆弱性

    その他登録数上位のベンダ

    2024年、特に増加が際立つのはIvanti、Android、D-Link、Palo Alto Networks、VMwareの5社になります。各ベンダについては以下をご参照ください。

    ベンダ名 説明
    Ivanti 旧LANDESKを中心とするインフラストラクチャ管理製品を提供する米国企業
    Android Android OSなどを提供する米国Google社内のAndroid Open Source Project
    D-Link 台湾のネットワーク機器メーカー。家庭用や中小企業向けの市場で強みをもつ。
    Palo Alto Networks ファイアウォールやVPN機器などの企業向けセキュリティネットワーク機器や関連製品を提供する米国企業。
    VMware ハイパーバイザなどの仮想化製品とその管理ツールを提供する米国Broadcom社傘下の企業。

    製品タイプ別登録数

    2024年にKEVカタログに登録されたCVEを製品タイプ別に分類したグラフでみると、Microsoftの登録数が多いことから、当然、OS/カーネルの登録が多くなっています(40件、23%)。また攻撃の初期アクセスに悪用されることが多いネットワーク機器も3位となっています(15件、9%)。そしてインフラストラクチャ管理製品が全体の10%(2位、18件)、エンドポイント管理製品が6%(4位、11件)を占めています。

    図3 製品タイプ別KEVカタログ登録数

    図3製品タイプ別KEVカタログ登録数
    弊社でKEVカタログに登録されたCVEを調査し、製品タイプ別に分けたものとなります。製品が複数の機能を含む場合は1.脆弱性が大きく影響を及ぼす機能、2.製品の主要な機能の順に振り分けを行っています。

    インフラストラクチャ管理製品の悪用

    インフラストラクチャ管理製品と大雑把にまとめましたが、ネットワーク機器の管理ツール、インベントリ管理ツールからサーバアセット管理ツールまで幅広いことから、以下の2タイプの脆弱性に絞って悪用実態をご紹介します。

    ネットワーク機器の管理インターフェース/管理機能の脆弱性悪用

    対象製品 CVE CWE 自動化
    FortiManager CVE-2024-47575*3 CWE-306
    重要な機能の使用に対する認証の欠如
    不可
    PAN-OSの管理インターフェース CVE-2024-0012*4 CWE-306
    重要な機能の使用に対する認証の欠如
    CVE-2024-9474*5 CWE-77
    OSコマンドインジェクション
    不可

    製品 製品概要 攻撃の概要注 3) 攻撃者
    FortiManager Fortinet製品の統合管理用のアプライアンス ・管理対象アプライアンスの詳細な設定情報、ユーザー・パスワードの取得
    ・脅威アクターのデバイスをFortiManagerに登録
    不明

    備考

    IOCなどはこちらを参照。
    https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575?hl=en

    PAN-OSの管理
    インターフェース
    PAN-OSが搭載されている機器の管理インターフェース。今回はWebインターフェースが対象。 ・WebShell(難読化)を使用して管理者権限を奪取
    ・管理アクションの実行や設定改ざん、特権昇格など
    不明

    備考

    IOCなどはこちらを参照。
    https://unit42.paloaltonetworks.com/cve-2024-0012-cve-2024-9474/

    ITアセット統合管理ツールの脆弱性悪用

    対象製品 CVE CWE 自動化
    CyberPersons Cyber Panel CVE-2024-51378*6 CWE-276
    不適切なデフォルトパーミッション
    VMware vCenter Server CVE-2024-38812 CWE-122
    バッファオーバーフロー
    CVE-2024-38813 CWE-250
    不要な特権による実行
    不可
    CWE-273
    削除された特権に対する不適切なチェック
    不可

    製品 製品概要 攻撃の概要 攻撃者
    CyberPersons Cyber Panel オープンソースのWebホスティング管理ツール。バックアップやWordPressの管理がWebブラウザで実行できる ミドルウェアによる入力値の検証の欠如による管理者権限へのアクセス権獲得・機微情報の取得注 4)および任意のコマンド実行*7 Helldownランサムウェア*8
    VMware vCenter Server vSphereシリーズの大規模仮想化環境の運用管理支援ツール vCenter Server v7.0で導入されたPlatform Services Controller(PSC)によりバックエンドプロセスがDCERPCプロトコルに依存する形態となっているところに、認証ワークフローまたはSOAP APIのエンドポイントに対して細工されたリクエストを送ることで初期アクセスを達成し、その後特権昇格と永続化を行っていると予想されている*9 不明

    EOL製品への対応

    ここでEnd-of-Life(サポート終了期限)と脆弱性への対応についても触れておきます。以下は2024年にKEVカタログに登録されたD-Link製品の脆弱性に関する推奨対策の一覧です。登録された脆弱性6件中5件がEOL(End-of-Life、製品サポート終了)を迎えている製品の脆弱性でした。これらのEOLを迎えている製品についてD-Linkからは新たなパッチを提供せず、買い替えを推奨しています。

    表2 2024年にKEVカタログに登録されたD-Link製品と推奨対策

    対象製品 CVE KEVカタログ登録日 推奨対策
    DIR-820 CVE-2023-25280 2024年9月30日 買い替え
    DIR-600 CVE-2014-100005 2024年5月16日 買い替え
    DIR-605 CVE-2021-40655 2024年5月16日 買い替え
    複数のNAS製品注 5) CVE-2024-3272 2024年4月11日 買い替え
    CVE-2024-3273 2024年4月11日 買い替え
    DSL-2750B CVE-2016-20017 2024年1月8日 製品型番を確認の上、必要に応じてパッチ適用

    CWE別登録数

    2024年のCWE別登録数のトップ10は以下の通りです。

    表3 CWE別KEVカタログ登録件数

    ランク CWE 概要 件数 CWE top 25ランク 2023年登録数 2023年登録数
    ランク
    1位 CWE-502 信頼できないデータのデシリアライゼーション 11 16 8 7
    1位 CWE-78 OSコマンドインジェクション 11 7 11 3
    3位 CWE-416 開放済みメモリの使用 10 8 16 2
    4位 なし CWEに該当する項目がないもの 9 22 1
    5位 CWE-22 パストラバーサル 8 5 4 15
    6位 CWE-287注 6) 不適切な認証 8 14 5 12
    7位 CWE-787 境界外書き込み 7 2 9 5
    8位 CWE-843 型の取り違え 6 ランク外 4 15
    8位 CWE-94 コードインジェクション 6 11 9 5
    10位 CWE-284注 7) 不適切なアクセス制御 5 ランク外 6 8

    ※登録件数は同一CVEで複数のCWEに該当する場合、それぞれ1件としてカウントしています。

    2024年のCWE別登録数の傾向

    C言語起因の脆弱性の減少

    代表的なC言語に起因する脆弱性、メモリハンドリング関連の脆弱性は2023年の52個(全体の約28%)から2024年は33個(全体の約19%)へ減少しました。一因は2023年に本カテゴリでKEVに登録された多数の脆弱性のうち、スマートフォンやタブレット端末のベンダとしておなじみのAppleとSamsungの登録件数が減少していることにあります。

    • Apple登録件数…2023年21件→2024年7件
    • Samsung登録件数…2023年8件→2024年0件

    表4 C言語が関連するKEVに登録されたCVE一覧(2023年~2024年)

    C言語が主要な原因となるCWE 2024年にKEVに登録されたCVE 2023年にKEVに登録されたCVE
    CWE-119: バッファオーバーフロー CVE-2017-1000253, CVE-2023-6549 CVE-2017-6742, CVE-2022-22706, CVE-2023-4966
    CWE-120: クラシックバッファオーバーフロー CVE-2023-33009, CVE-2023-33010, CVE-2023-41064
    CWE-122: ヒープベースのバッファオーバーフロー CVE-2024-38812, CVE-2024-49138, CVE-2024-30051 CVE-2023-23376, CVE-2023-27997, CVE-2023-28252, CVE-2023-36036, CVE-2023-4911
    CWE-125: 範囲外メモリの読み取り CVE-2021-25487, CVE-2023-28204, CVE-2023-42916
    CWE-134: 制御されていないフォーマット文字列 CVE-2024-23113
    CWE-190: 整数オーバーフロー/アンダーフロー CVE-2022-0185, CVE-2024-38080 CVE-2023-2136, CVE-2023-21823, CVE-2023-32434, CVE-2023-33107, CVE-2023-6345
    CWE-401: メモリリーク CVE-2023-26083
    CWE-416:解放後使用(Use After Free) CVE-2024-9680, CVE-2024-4671, CVE-2012-4792, CVE-2024-43047, CVE-2024-38107, CVE-2024-38193, CVE-2024-36971, CVE-2024-1086, CVE-2024-4610, CVE-2022-2586 CVE-2016-9079, CVE-2019-8526, CVE-2021-25394, CVE-2021-29256, CVE-2022-22071, CVE-2022-3038, CVE-2022-38181, CVE-2023-0266, CVE-2023-21608, CVE-2023-21674, CVE-2023-28205, CVE-2023-29336, CVE-2023-32373, CVE-2023-33063, CVE-2023-36802, CVE-2023-4211
    CWE-787: 範囲外への書き込み CVE-2023-34048, CVE-2024-21762, CVE-2024-0519, CVE-2023-7024, CVE-2024-23225, CVE-2024-23296, CVE-2024-4761 CVE-2021-25372, CVE-2023-20109, CVE-2023-26369, CVE-2023-28206, CVE-2023-32435, CVE-2023-42917, CVE-2023-4863, CVE-2023-5217
    CWE-823: メモリ位置外へのポインタ参照 CVE-2021-25372

    これらの脆弱性は汎用OSやスマートフォンOS、ネットワーク機器やチップセットのファームウェアなどの脆弱性が中心です。KEVカタログに掲載される脆弱性は攻撃者にとって都合の良いOSやネットワーク機器の脆弱性が多いため、各ベンダのC言語系統での開発比重の変動にともない、逓減ていげんしていくと予想されます。

    登録件数上位のCWEと代表的な脆弱性

    表5 登録件数上位のCWEと代表的な2024年の脆弱性

    CWE CVE ベンダ・
    製品名
    脆弱性概要 攻撃者の情報 自動化
    CWE-78 CVE-2024-40711 Veeam Backup & Replication 非認証ユーザーによる任意コードの実行につながるデシリアライゼーションの脆弱性*10 ランサムウェア(Akira, Fog, Frag)*11
    CWE-78 CVE-2024-1212 Progress Kemp LoadMaster 非認証ユーザーによるOSコマンドインジェクション*12 不明
    CWE-22 CVE-2024-8963 Ivanti Cloud Services Appliance (CSA) 管理ユーザー認証の回避と任意のコマンドの実行につながるパストラバーサル。CVE-2024-8190のコマンドインジェクションの悪用につなげる目的で使用されたと推測される。 不明

    備考

    ただしIOCや悪用の詳細についてはFortinet社から公開されている。
    https://www.fortinet.com/blog/threat-research/burning-zero-days-suspected-nation-state-adversary-targets-ivanti-csa

    脆弱性悪用の自動化の可否

    2024年5月から米CISAはVulnrichmentという脆弱性情報の充実プログラムを公開し始めました。これはStakeholder-Specific Vulnerability Categorization(ステークホルダー固有の脆弱性の分類、略称SSVC)に必要な付加情報の提供などを目的に公開されているもので、SSVCによる脆弱性のトリアージに利用できる有効な情報源が加わったことで、脆弱性管理がしやすくなるというものです。SSVCのトリアージのうち、デプロイヤーモデル(アプリケーションや機器を実環境で使っている人が対象のモデル)では脆弱性に対するAutomatable(自動化の可否)の評価が必要となりますが、Vulnrichmentではこの評価も併せて公開されています。攻撃者にとっては脆弱性悪用をツール化することで流通させることが可能となる点や、ツールの利用で技術力が特に問われずに利用できる点などから、自動化の可否は悪用されやすさの一つの指標として注目すべきものがあります。

    SSVC(Stakeholder-Specific Vulnerability Categorization)について、SQAT.jpでは以下の記事でも紹介しています。こちらもあわせてご覧ください。
    脆弱性診断は受けたけれど~脆弱性管理入門

    表6 2024年にKEVカタログに掲載された脆弱性の自動化可否

    自動化可否 件数
    可能 75
    不可 86
    データなし 14
    出典:https://github.com/cisagov/vulnrichmentよりデータを取得

    ランサムウェアグループの悪用が判明しているもの

    2024年もランサムウェアによる被害が後を絶たない一年となりました。KEVカタログではランサムウェアグループの悪用が特定されたかどうかについても情報が掲載されていますので、ぜひこの機会にご参考にされてみてはいかがでしょうか。

    表7 ランサムウェアグループによる悪用の判明

    ランサムウェアグループの悪用 件数
    判明している 22
    不明 153

    注:
    1) CVSS3.0及び3.1はベーススコア算出用のメトリクスに相違がないため、同一のスコアとして比較対象としています。なお、CVSS4.0はベーススコア算出用のメトリクスが異なるため、比較対象としていません。
    2) CVSSスコアはCISA Vulnrichmentから取得できたものを優先し、CISA Vulnrichmentに登録がないものはNVD検索を行っています。なお2024年12月12日時点でCISA Vulnrichmentに登録がない、2024年にKEVカタログに登録されたCVEは19件となっています。
    3) https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575?hl=en
    およびhttps://unit42.paloaltonetworks.com/cve-2024-0012-cve-2024-9474/(2024年12月13日参照)
    4) PoCの詳細となるhttps://attacke.rs/posts/cyberpanel-command-injection-vulnerability/を参照
    5) 対象製品は次のリンク先を参照。https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10383
    6) CWE-287は現実世界での脆弱性へのマッピングが非推奨となっているCWEです。詳細はMITREによるCWE-287の詳細ページのVulnerability Mapping Notesをご覧ください。なお、詳細ページでは代わりにCWE-1390またはCWE-309を使用するよう推奨されています。
    7) CWE-284は現実世界での脆弱性へのマッピングが非推奨となっているCWEです。詳細はMITREによるCWE-284の詳細ページのVulnerability Mapping Notesをご覧ください。詳細ページでは代わりにCWE-862、CWE-863、CWE-732、CWE-306、CWE-1390、CWE-923を使用するよう推奨されています。

    ウェビナー開催のお知らせ

  • 2025年1月15日(水)13:00~14:00
    スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 2025年1月22日(水)14:00~15:00
    ランサムウェア対策の要!ペネトレーションテストとは? -ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年1月29日(水)13:00~14:00
    サイバー攻撃から企業を守る!ソースコード診断が実現する“安全な開発”
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    【CWE TOP 25 2024年版】にみる新たなセキュリティ脅威と指針

    Share

    最も危険なソフトウェアエラー 「CWE TOP 25」2024年版発表

    2024年11月22日、米MITREが運営するHSSEDIと米サイバーセキュリティ・インフラセキュリティ庁(CISA)は、「2024 CWE TOP 25 Most Dangerous Software Weaknesses(最も危険なソフトウェアエラーTOP25 2024年版)」を発表しました。

    CWE TOP 25は過去1年間に報告された3万件を超える脆弱性データを分析し、深刻度や影響範囲が大きい脆弱性タイプをランク付けしたものです。セキュリティ対策の優先順位を定め、効率的にリスクを軽減するための重要な指針として注目されています。

    順位 脆弱性名 昨年順位
    1 クロスサイトスクリプティング(CWE-79) 2
    2 範囲外の書き込み(CWE-787) 1
    3 SQLインジェクション(CWE-89) 3
    4 クロスサイトリクエストフォージェリ(CWE-352) 9
    5 パストラバーサル(CWE-22) 8
    6 範囲外の読み取り(CWE-125) 7
    7 OSコマンドインジェクション(CWE-78) 5
    8 解放したメモリの使用(CWE-416) 4
    9 認可の欠如(CWE-862) 11
    10 危険なタイプのファイルのアップロード許可(CWE-434) 10
    11 コードインジェクション(CWE-94) 23
    12 不適切な入力検証(CWE-20) 6
    13 コマンドインジェクション(CWE-77) 16
    14 不適切な認証(CWE-287) 13
    15 権限管理の不備(CWE-269) 22
    16 不適切なデータ逆シリアル化(CWE-502) 15
    17 権限を持たないユーザへの機密情報の漏洩(CWE-200) 30
    18 不適切な認可(CWE-863) 24
    19 サーバーサイドリクエストフォージェリ(CWE-918) 19
    20 メモリバッファ境界内での不適切な処理制限(CWE-119) 17
    21 NULLポインター逆参照(CWE-476) 12
    22 ハードコードされた資格情報の使用(CWE-798) 18
    23 整数のオーバーフローまたはラップアラウンド(CWE-190) 4
    24 制御されていないリソース消費(CWE-400) 37
    25 重要な機能の使用に対する認証の欠如(CWE-306) 20

    出典:https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.htmlより弊社翻訳

    CWEとは

    CWE(Common Weakness Enumeration)は、ソフトウェアにおける共通脆弱性分類です。脆弱性項目ごとに一意のIDが決められ、そのタイプごとに体系化されています。ソフトウェアやシステムに存在する脆弱性を体系的に分類・整理したデータベースであり、開発者やセキュリティ専門家が脆弱性の回避や修正を行うための知識を提供します。

    このデータベースを基に作成されたCWE TOP 25は、影響の深刻度や頻度を基準に順位付けされています。前年度と比較して順位を上げている項目については、特に脅威が高まっていると言えます。自組織のセキュリティの弱点と関係しているかといった分析や優先的に対策すべき項目の検討などに役立つ情報です。

    2024年度の全体的な傾向

    2024年版のTOP25では、クロスサイトスクリプティング(XSS)が最も危険な脆弱性として1位に返り咲きました。昨年は2位だったXSSが再びトップとなったことで、この脆弱性が依然として攻撃者にとって非常に有用であり、深刻なリスクをもたらしていることが浮き彫りとなっています。さらに、範囲外メモリへの書き込みやSQLインジェクションも上位にランクインしており、依然として攻撃手段に活用されている実態が明らかになりました。これらの脆弱性はシステムへの不正アクセスやデータ漏洩を引き起こす可能性があり、引き続き厳重な警戒と対策が求められます。

    まとめ

    CWE TOP 25は、ソフトウェアセキュリティにおける脆弱性を特定し、効果的な対策を講じるための指針として機能します。開発者にとっては、脆弱性を事前に予測し、修正作業を効率化するための実用的なツールであり、セキュリティ専門家にとっては、リスク評価や診断の基準を提供します。さらに企業にとっては、このリストを活用することで、セキュリティ戦略を再構築し、組織やシステムのセキュリティ体制を強化するための基盤となります。

    CWE TOP 25が提供する洞察は、企業や組織が脆弱性を未然に防ぎ、安全なソフトウェアやシステムを構築するための重要なステップとなります。特に、攻撃の高度化が進む現代では、このリストを活用してリスクの排除や対策の強化を図ることが、企業の存続と顧客信頼の維持に直結します。CWE TOP 25をもとに、最新のセキュリティ対策を実施することが今後さらに重要になるでしょう。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2025年1月15日(水)13:00~14:00
    スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 2025年1月22日(水)14:00~15:00
    ランサムウェア対策の要!ペネトレーションテストとは? -ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年1月29日(水)13:00~14:00
    サイバー攻撃から企業を守る!ソースコード診断が実現する“安全な開発”
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    2038年問題とは?-2000年問題の再来?2038年問題の影響と解決方法-

    Share

    本記事では最近話題の「2038年問題」について解説します。2038年問題は狭義のサイバーセキュリティと関連するものではありませんが、そのまま放置してしまうとサイバーインシデントを引き起こす可能性がある問題となります。対応に準備に時間を要する問題であることから、読者の皆さまに早い段階から関心を持っていただければと考えています。

    2000年問題を振り返る

    初期のプログラミング言語(FORTRANやCOBOL注 1) など)はデータ型に日付型がなかったため、文字列を割り当てて日付として処理をしていました。

    この時、日付を文字列で処理する際、1960年代~80年代の人類は自分が作ったプログラムがその後長く使われるなどと思わず、「とりあえずYY-MM-DDで表示すればデータ量削減にもなるし、いいだろう」と考え、慣例として西暦年を下2桁で処理していました。

    図1:2000年問題の原因となった表示方法

    何しろ今とは異なりCPUもメモリも、貧弱でも超高価な時代です。資源の節約は必要な限り実行しなければならない課題だったといえます。しかし、1990年代に入ったところで人類はふと気づきます。「これはもしや、西暦年の下2桁だけだと2000年になった時、処理上1900年に戻ってしまうのでは?」と。

    図2:2000年問題

    そうして、1990年代半ばからプログラムの書き換えが行われ、それまで下2桁だった西暦年を4桁に変更し、万が一の時のために1999年12月31日から2000年1月2日までの間、一部のIT業界の人たちが正月返上で出勤して不測の事態に備えたのが2000年問題です。

    2000年問題では実際、2000年1月1日当日、特に何かが起こることはありませんでした。その背景は以下の通りです。

    2000年問題が2000年1月1日に何も問題とならなかった背景

    • COBOLやFORTRANなどのレガシー言語で古くに書かれたアプリケーションやマイコンなど対象が限定されていたこと
      (※C言語などの比較的新しい言語は日付型をデータ型に持っていたため関係がなかった。)
    • 発生日が明確だったこと
    • 対策が西暦年の2桁を4桁表示に変更するという方法に集約されていたこと
    • 数年間にわたって事前の対策がとられていたこと

    限定的な対象に対し、事前に入念な準備を行ったことが功を奏し、インシデントが発生しなかったことが2000年問題の結果です。

    計算機とデータ型:2038年問題の技術的背景

    さて2024年現在、コンピューター・タブレット端末・スマートフォンなど、見た目などから計算機であることがわかりづらいようになっていますが、やはりコンピューターは計算機です。実際アプリケーションを動かすにしてもプログラムがされていて、プログラムの実行には必ず計算が伴います。そして、プログラム上でデータを処理するためにはデータの種類を定めるデータ型というものがあります。

    データ型の例

    データ型
    文字列(str) 今ご覧になっているいわゆる文字列のこと
    整数型(int) 1, 2, 50, 1065, -5などの整数(負の数も含む)
    浮動小数点型(float) 3.14, -0.001, 356.25などの小数点を含む数(負の数も含む)
    ブーリアン型(bool) 真(True)か偽(False)のいずれかで表わされる
    日付型(date) 世界標準時(UTC)を基準として、1970年1月1日からの経過秒数を表すタイムスタンプデータ。整数型データで表わされる

    2000年問題のときはFORTRANやCOBOLに日付型が存在せず、文字型で処理していたこと、また限られた資源を節約するために下2桁で年を表していたことが原因でした。一方、2038年問題は日付型のタイムスタンプデータを格納する整数型のデータ長(ビット幅)の実装が原因となるものです。

    SQAT.jpでは以下の記事で2024年版のプログラミング言語をめぐる状況と、ちょっとした脆弱性対策に関する情報をご紹介しています。こちらもあわせてご覧ください。
    【続】プログラミング言語の脆弱性対策を考える:2024

    2038年問題の技術的課題

    符号付32ビット整数型から符号付64ビット整数型への移行の壁

    前述したデータ型の例の表にもあるように日付型は絶対的な日付を表すものではなく、1970年1月1日午前0時0分を基準日時(エポックタイム)としてそこからの経過秒数をタイムスタンプデータとしてあらわすものです。C言語ではtime_tと呼ばれるこのデータでは、タイムスタンプデータを格納するのは符号付32bitの整数型となっています。符号付整数型は最初の1bitを正負符号のために使用します。符号の1ビットがあるため、実際に日付データ用に利用できるのは正負を表す最初の1ビットを除く31ビットで、利用できるビット長は(231-1)=2,147,483,647秒となります。よって基準日時からおよそ68年を上限として演算・表示ができるものとなります。

    図3:符号付32bitであらわした2038年1月19日3時14分7秒

    図3は1970年1月1日午前0時0分から2,147,483,647秒が経過した、2038年1月19日3時14分7秒(※うるう秒は考慮しておりません)の符号付32bit整数型でのtime_tの状態です。一番左側の符号0は正の値を表しており、1970年1月1日午前0時0分から2,147,483,647秒、正の方向に経過したことを示します。

    さて、二進法の常で右側の31bitがすべて1になった場合、通常一番左側の1ビット目が1になります(二進法の繰り上がり)。

    図4:符号付32bitのままで2038年1月19日3時14分8秒になった場合

    1970年1月1日午前0時0分から2,147,483,648秒経過すると図4のようになります。符号付の場合、一番左側の符号1は負の値を表すため、1970年1月1日午前0時0分から2,147,483,647秒、負の方向に遡った1901年12月13日20時45分52秒を示します。つまり放置しておくと日付データが大きく誤ることとなります。この問題が最も深刻になるのは符号付32bitのtime_tを何らかの形で参照し、それを正しいものという前提で処理しているプログラムが、2038年1月19日の時点(または2038年1月19日以降の日付を参照する時点)で未改修のまま残ってしまうことで影響を及ぼしてしまうことなのです。

    ウェビナー開催のお知らせ

  • 2024年12月18日(水)14:00~15:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 最新情報はこちら


    2038年問題を回避する3つの対応策

    対策として考えられる方法はいくつかありますが、根本的な対策は以下の3つになります。

    1. time_tを符号付64bit整数型に変更する
    2. time_tを符号なし32bit整数型に変更する
    3. time_tの基準日時を1970年1月1日午前0時0分から別の日時に移動する

    主要OS・アプリケーションの2038年問題対応状況

    2038年問題の影響が一番大きく出ると当初予想されていたのが各種OSです。以下に各OSの対応状況を記載します。

    各OSの対応状況

    OS
    Linux 64bitアーキテクチャ向けには当初より64bitのtime_tを提供。
    32bitアーキテクチャについてはLinux Kernel 5.6で64bit化対応済み。5.4/5.5についてもバックポートで対応済み。*13
    FreeBSD 原則として64bit対応済みだが、i386アーキテクチャの32bitアーキテクチャのみ非対応。I386アーキテクチャについては符号なしの32bit整数型 time_tを提供*2
    Windows 64bitで1601年1月1日0時からの100n sec単位の差分計算をしていることから2038年問題は対象外といわれている*3
    macOS macOS10.0(Cheetah)で基準時を2001年1月1日0時に変更しており、2038年問題は対象外。また、32bitアプリケーションはmacOS 10.15(Catalina)以降では使用できない*4

    表にもある通り、最新のOSであればほぼ問題なく2038年問題をクリアできることがわかります。問題はOSの機能を補完する各種ドライバやライブラリ群、また、そのうえで動くアプリケーションでしょう。それぞれ確認は必要となりますが、代表的なものの対応状況は以下の通りです。

    ライブラリ/アプリケーション名 対応状況
    GNU C Library (glibc) バージョン2.34でx86アーキテクチャ上での64bit整数型time-tに対応。ただしx86アーキテクチャ上のglibcのtime_t自体は32bitのままで、_TIME_BITSプリプロセッサマクロが64に設定されていて、かつLFSが有効な場合にのみ利用可能などの制限あり*5
    NFS NFSv4(RFC7530)秒単位のデータは符号付64bitであることが定義されている*6(※2.2.1 nfstime4の項を参照)
    XFS Linux 5.10でオプションとしてナノ秒単位を64bitで計算・表示する「big timestamps」を追加し、2486年まで対応できるように修正。ただしデフォルトで追加が反映されるものではなく有効に設定する必要がある*7
    MySQL 8.0.28でFROM_UNIXTIME(), UNIX_TIMESTAMP(), CONVERT_TZ() の64bit対応。ただしOS側が64bit対応である必要あり(いずれの関数もOSの日付型データを参照するため)*8
    MariaDB 11.5.1でタイムスタンプを2106年02月07日6時28分15秒まで拡張*9
    Visual C++ 32bitであえて指定されていない限りは64bitがデフォルト値*10

    上記はごく一部の対応状況ですが、仮に対応していても制限事項がつくものが存在する点に注意が必要です。ここまで記載した内容で何となくお気づきの方もいらっしゃるかもしれませんが、2038年問題は発生する可能性がある箇所が2020年問題に対して格段に多いため、時間がかかることが予想されます。

    2000年問題と2038年問題の違い

    • 対象がOS/ライブラリからアプリケーション、機器類まで非常に幅が広い
    • 2000年当時に比べて格段にデジタル化が進んでいる
    • 対策方法が一様ではないものや、現在動いているシステムに対して即時変更をかけられないものがある

    企業が取るべき2038年問題対策:自社システムの診断方法

    自社のプログラムの調査は?

    さて、「PCやサーバなんかを買ってきたものの、自社で作ったものはどうすればいいの?」というケースもあるでしょう。自社で作ったものは…そうです。自分たちで調べるしかないのです。実際に調査をして対応をした事例がまとめられた論文が公開されています。

    組込み機器開発における2038年問題への対応事例

    https://www.ipsj.or.jp/dp/contents/publication/39/S1003-1809.html

    この事例では製品のライフサイクルがもともと20年前後を想定していることから、まずは2038年を最低限クリアすることを要件として調査を開始しています。このケースは組み込み機器になりますが、その単体の機器でもOS部分を含む総行数330万行のコードから符号付32bit整数型のtime_tを明示的に使用する箇所およそ3500か所が発見されています。

    この事例でとられたステップを簡単にまとめます。

    この事例では3500か所に対して5.8人月で実行された修正作業もさることながら、そのレベルの工数で抑制するために事前の洗い出しや対策案の立案、修正作業の手順策定といったところの重要さが感じられます。特に対策案を選定するにあたって要件が明確だったことが対策案の選定を容易にしたことがわかることから、作業開始前(せめて対策案の選定前)に要件を明確にしておくことの重要さを実感させられます。

    さて、2038年問題に該当するコードを検出するためのツールは日本の研究者も含め、いくつかのGitHubレポジトリからリリースされています。最近では立命館大学のサイバーセキュリティ研究室によるY2k38チェッカーがリリースされています。

    Y2k38チェッカーチェッカー作者によるプレゼン資料

    https://speakerdeck.com/ran350/unixyo2038nian-woyue-eteyuke

    こういったチェッカーは自社開発のプログラム資産のざっとしたチェックに使えるでしょう。また、チェッカー以前の問題として、まずは自社のプログラム資産が2038年問題の影響を受けないか、そろそろ確認を行い、準備を始める期間に入ってきたといえるかもしれません。

    組み込み機器とは?:2038年問題の最大の影響

    実はここまでにあまり触れていない、最大の2038年問題があります。それは、先ほどの論文の事例にもある組み込み機器の問題です。

    組み込み機器といわれてもピンとこない方もいらっしゃるかもしれません。身近な例でいうと家電製品を制御するために組み込まれているコンピューターになります。一番パソコンに近いものであれば最近のハードディスク内蔵か外付け対応のテレビが挙げられます。このほかにも例えば電車に乗るときの自動改札機、切符販売機、水道や電気ガスなどのメーター類や街中で見かけるデジタルサイネージなども組み込み機器です。ほかにも工場のセンサー類やオートメーション用の機器類、配電設備や浄水・配水設備などのインフラ設備、病院の検査機器などにも組み込み機器が用いられています。

    先ほどの事例のようにライフサイクルが決まっていて、そのライフサイクルの間のみ使用するというのが利用者(消費者)側に正しく認識されていれば問題ないのですが、実際のところ、組み込み機器こそライフサイクルを超えて、転売などをされて使い続けられるケースが多く、販売業者も製造業者もすべての出荷品の現状をトレースできないケースがあるといわれています。特に償却期間が5年を超えるような固定資産については入れ替えの検討なども含めて対応する必要が出てくることから、そろそろ取りまとめを始めなければならないでしょう。また、個人向けのIoT機器や家電のように、長期間の利用は想定されていない(売り切りに近い)製品については直前になって買い替えが必要といったアナウンスが出てくる可能性もあるでしょう。

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    まとめ

    2038年問題は日付データが誤ることで社会的に大きな影響を与える可能性があります。本記事公開日(2024年12月)時点ではまだまだ先の問題と思っている方が多いと思いますが、そろそろロードマップを書き始めないと対策に取る時間が足りなくなる可能性があります。これを念頭に置き、早めの対策方法を考えておく必要があるでしょう。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    注:
    1)FORTRAN
    ・数学分析用を目的としたプログラミング言語
    ・データ型は整数、実数、複素数、文字、論理の5種類
     COBOL
    ・1950年代終わりに開発されたプログラミング言語
    ・データ型は文字、数字、数字編集の3種類


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    パスワード要件が変わる!- NIST SP800-63B-4の第2次公開草案の重要ポイントと実装への影響-

    Share

    2024年8月、NIST(米国国立標準技術研究所)が「NIST SP 800-63B-4」の第2次公開草案を発表しました。このガイドラインでは、パスワードの長さを15文字以上推奨とし、複雑性要件や定期的な変更義務を廃止するなど、認証に関する新たな基準が示されています。本記事では、企業の情報セキュリティ担当者が注目すべきポイントや、今後の認証ベストプラクティスについて解説します。

    NISTの新ガイドラインのドラフト版が公開

    2024年8月に、NISTより、NIST SP800-63B-4の第2次公開草案(2nd Public Draft)が公開されました。NIST SP 800-63は、日本では「電子認証に関するガイドライン」という名前でIPAからも日本語訳が公開されているガイドラインで、世界的に強い影響力を持つガイドラインの一つです。2023年3月には、このガイドラインの第4版となるNIST SP800-63-4のドラフト版が公開されています。今回はその第2次公開草案となりますが、そのうちの「認証とライフサイクル管理」に関する63Bについて取り上げます。

    NIST SP800-63の構成

    NIST SP800-63A 登録と身元確認
    NIST SP800-63B 認証とライフサイクル管理
    NIST SP800-63C フェデレーションとアサーション

    NIST SP800-63B-4第2次公開草案では、パスワード関連において、初期公開版からいくつかの変更点があります。パスワードの長さについては、最小8文字という基準を維持しつつ、15文字以上を推奨するようになりました。最大長は少なくとも64文字に設定する必要があります。複雑性要件に関しては、特定の文字タイプの混合を要求するなどの合成規則を課すことを明確に禁止しています。代わりに、Unicode文字の使用を推奨し、パスワードの選択肢を広げています。ブロックリストの使用については、過度に大きなリストは不要であるとの見解を示しています。オンライン攻撃はすでにスロットリング要件によって制限されているためです。新たにパスワードにはフィッシング耐性がないことを明記されており、この脆弱性に対する認識を高めています。パスワード管理ツールの使用については、引き続き許可すべきとしていますが、関連する参考文献が追加されました。定期的なパスワード変更要求については、2017年の第3版から引き続き、セキュリティ侵害の証拠がない限り不要としています。

    NIST SP800-63B-4第2次公開草案から読み解くポイント

    初期公開版との差は先に述べた通りですが、最新の第2次公開草案のポイントであると考えられるのは、以下の4点です。

    • パスワード文字数は15文字以上が推奨され、最大長は少なくとも64文字
    • パスワードの複雑性要求(複数の文字タイプの要求)の廃止
    • 定期的な強制変更の廃止
    • 秘密の質問の廃止

    特にパスワード文字数に関する問題は、弊社の脆弱性診断においても頻繁に検出されております。下表に2024年上半期に実施したWebアプリケーション脆弱性診断結果の中で順位が高い項目をまとめました。

    弊社「SQAT® Security Report」2024-2025年秋冬号 p.18より

    この中で3位となる「脆弱なパスワードの許容」は、パスワードの長さが8文字未満の場合に弊社では「高」リスクと判定し、指摘しているものとなります。最近、米国のセキュリティ企業が発表したAIを用いたパスワードの解析にかかる時間の調査結果では、8文字未満のパスワードは、例え大文字・小文字のアルファベット、数字、記号がすべて含まれていたとしても6分以内に解析できることが分かりました。(ちなみに、14文字ではパスワードがすべて小文字のアルファベットで構成されていたとしても、解析に49年かかる結果が出ています)このことからも、世の多くのシステムが大きな危険に晒されているというのが分かるかと思います。パスワードの長さについては、これまでにもMicrosoftやFBIからガイダンスが出ていますので、気になる方はあわせてご確認ください。

    ■Microsoft
    https://support.microsoft.com/en-us/windows/create-and-use-strong-passwords-c5cebb49-8c53-4f5e-2bc4-fe357ca048eb
    ■FBI
    https://www.fbi.gov/contact-us/field-offices/portland/news/press-releases/oregon-fbi-tech-tuesday-building-a-digital-defense-with-passwords

    パスワード認証の限界

    今回の改定で強く打ち出されているのは、複雑で人間にとって記憶不可能なランダム文字列よりも、長大なパスワードであることの方が推奨されるということです。また、定期的な変更をするよりも、複数システムで同じパスワードを使い回さないということが重要である、ということも同様です。

    パスワード認証は長年にわたり広く使用されてきましたが、ユーザは多数のアカウントを管理する必要があり、長大なパスワードを使い回しせずに、すべてを記憶することは現実的に考えて困難です。仮にパスフレーズやパスワード管理ソフトを用いて解決を図ったとしても、フィッシング攻撃やデータ漏洩により、パスワードが容易に盗まれる危険性や、将来の処理能力の向上によるブルートフォース攻撃のリスクというものは健在です。結果、パスワード認証の限界を見据えたときに、代替として考えられるのが、多要素認証や生体認証です。

    主な認証技術

    まず、そもそも認証にはどのような要素があるかを振り返りましょう。認証の要素になり得るのは、その本人だけに属するモノ・コトです。それらとしては、下図のとおり、「知識」「所持」「生体」の3種類の要素が挙げられます。

    Webサービスやスマホアプリにおいて使用されている認証方式には、前述した3要素のうち1つだけを用いる単要素認証(パスワードのみの認証など)、2つ以上の要素を組み合わせる多要素認証(パスワード+スマホで受信した認証コードなど)、また、認証を二段階で行うが、認証要素自体は同じ場合もある二段階認証(パスワード+秘密の質問など)があり、いずれの方式も、次のような認証技術を組み合わせて行われます。

    認証機構のベストプラクティス

    現在、認証機構のベストプラクティスと考えられるのが、多要素認証です。なかでも普及が進む「FIDO2」は、有望な選択肢と言えるでしょう。FIDO2はユーザ視点ではスマートフォンなどでの生体認証を行うというステップで認証が完了するように見えることから、利便性が高いと考えられます。他方、システム側から見た場合、公開鍵認証と生体認証などの多要素による認証がセットになっていることから、ユーザの設定による認証強度の低下に影響されにくい方式であることは、サービスを提供する側からみて大きな利点といえます。

    多要素認証「FIDO2」

    まずは現状の認証が安全か確認することから

    安全な認証機構を実現するための第一歩として、現在実装している認証機構や情報漏洩対策が安全かどうか確認することが推奨されます。確認には定期的なセキュリティ診断の実施が有効です。様々なセキュリティサービスベンダより各種メニューが提供されているため、対象システムにあわせて実施するとよいでしょう。

    セキュリティ診断によりセキュリティ状態が可視化された後は、対策の実施レベルや時期を検討しましょう。対策にあたっては、リスクに応じて優先度を定めた上で行うことが有効です。システム特性ごとに必要十分なセキュリティを保持した認証を実現するためには、認証に関してどのような技術があるのか、どのようなセキュリティリスクに対応できる仕組みなのか把握しておくことが大切です。

    【参考】ガイドライン
    NISC「インターネットの安全・安心ハンドブック
    https://security-portal.nisc.go.jp/guidance/handbook.html

    BBSecでは

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    SQAT脆弱性診断サービス

    Webアプリケーション脆弱性診断-SQAT® for Web-

    Webサイトを攻撃するハッカーの手法を用いて、外部から動的に脆弱性を診断することで、攻撃の入口となる可能性のある箇所を検出します。診断は最新のセキュリティ情報に基づき実施されますので、開発時やリリース前ばかりでなく、既存システムに対する定期的な実施といった、現状の脆弱性対策の有効性を確認するために活用することをおすすめしています。
    以下より、サービス内容が記載されている資料のダウンロードもいただけます。

    Webアプリケーション脆弱性診断バナー

    ウェビナー開催のお知らせ

  • 2024年12月4日(水)13:00~14:00
    インシデント発生の事前準備・事後対応-拡大するサイバー攻撃への対策方法とは-
  • 2024年12月11日(水)14:00~15:00
    ランサムウェア攻撃の実態と対策:2024~脅威に備える最新の対策法を解説~
  • 2024年12月18日(水)14:00~15:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 最新情報はこちら


    Security Report TOPに戻る
    TOP-更新情報に戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    緊急セキュリティ警告:ArrayOS AG における深刻な脆弱性 CVE-2023-28461

    Share

    Array Networks社のArrayOS AGに存在する重大な脆弱性について、企業が知るべき最新情報をお伝えします。ネットワークセキュリティについて情報収集されている方は必読です!

    脆弱性の概要と深刻度

    CVE-2023-28461は、ArrayOS AGのセキュリティ基盤を揺るがす深刻な認証脆弱性です。CVSSスコア9.8という極めて高い危険度は、即時の対応を求めています。

    脆弱性の特徴

    • 影響バージョン:ArrayOS AG 9.4.0.481以前
    • 攻撃難易度:非常に低い
    • 潜在的リスク:システム不正アクセス、情報漏洩、サービス運用妨害

    攻撃の実態と脅威

    2023年3月15日に公表されたこの脆弱性は、すでに複数の攻撃キャンペーンで悪用されています。特に注目すべきは、Earth Kashaという脅威アクターによる組織的な攻撃です。

    攻撃の特徴

    • 2023年4-5月:リモートコード実行が疑われる攻撃
    • 標的:日本および世界各国のテクノロジー企業、政府機関

    企業が取るべき対策

    この脆弱性から組織を守るために、以下の対策が不可欠です。

    修正プログラムの適用

    Array Networks社から提供されている修正プログラムを速やかに適用することが最も重要です。特に、バージョン9.4.0.481およびそれ以前のバージョンを使用している場合は、最新のアップデートを適用してください。

    アクセスログの監視

    不審なアクセスや異常な動作を早期に発見するために、アクセスログを定期的に監視し、異常がないか確認します。特に、VPN接続や外部からのアクセスが多い環境では注意が必要です。

    セキュリティ機器の強化

    インターネット境界に設置されているセキュリティ機器(ルータやファイアウォールなど)の設定を見直し、不必要なポートやサービスを閉じることで攻撃面を減少させます*11

    脆弱性管理の実施

    使用しているシステムやアプリケーションの脆弱性情報を定期的に確認し、ゼロデイ脆弱性や既知のエクスプロイトに対する対策を講じます。特に、Array AGシリーズのような外部からアクセスされる機器は優先的に管理します*2

    多要素認証の導入

    認証機構自体の強度を高めるため、多要素認証(MFA)を導入し、パスワードだけでなく他の認証手段も組み合わせて使用します。

    リスク軽減のための具体的なステップ

    システム管理者向け緊急対応

    • ArrayOS AGのバージョンを速やかに確認
    • 公式パッチの即時適用
    • 不審なアクセスログの分析
    • 外部セキュリティ専門家への相談検討

    最後に

    この脆弱性は単なる技術的な問題ではなく、組織の存続に関わる重大なセキュリティリスクです。迅速かつ包括的な対応が求められます。セキュリティは待ったなし。今すぐ行動を起こしてください。


    Security Report TOPに戻る
    TOP-更新情報に戻る

    サイバーインシデント緊急対応

    サイバーセキュリティ緊急対応電話受付ボタン
    SQAT緊急対応バナー

    ウェビナー開催のお知らせ

  • 2024年12月4日(水)13:00~14:00
    インシデント発生の事前準備・事後対応-拡大するサイバー攻撃への対策方法とは-
  • 2024年12月11日(水)14:00~15:00
    ランサムウェア攻撃の実態と対策:2024~脅威に備える最新の対策法を解説~
  • 2024年12月18日(水)14:00~15:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像