お知らせ
開催概要 セミナー名 2022年のセキュリティ予測 日時 2022年2月17日（木） 14:00～14:30 アジェンダ 2022年が始まりましたが、皆さんいかがお過ごしでしょうか。新型コロナウイルスもそろそろ落ち着いて欲しいですね。 さて、今回のオンラインセミナーは、2022年のセキュリティ予測と題して、昨年のセキュリティインシデントの振り返りと、今年どのような脅威が想定されるのか、 どのような分野が特に注意すべきなのか、持つべきスキルとは？といった、2022年の展望をご紹介します。 ぜひ、ご参加・お申込みください。 お申し込み 下記のフォームからお申し込みください。 お申込者にはセミナー開催日前日の 17:00 にオンラインセミナー用URLをお送りいたします。 お申込期限 2022年2月17日 14:00 セミナー資料 セミナー資料のダウンロードはこちら アーカイブ セミナー動画の視聴はこちら
トピック：Attacks and Threat Actors 2021年12月22日、Jonathan Tanner インジェクション攻撃は、OWASPの「Webアプリケーションの脆弱性トップ10」に恒常的にランクインしています。SQLインジェクション、コマンドインジェクション、クロスサイトスクリプティング（XSS）攻撃は、一般的に最初に思い浮かぶインジェクション攻撃の形態ですが、ログインジェクションにもリスクがあり、見過ごされている場合があります。 ログインジェクションとは、ユーザが操作した入力内容が無害化されずに記録された場合に発生するもので、リモートコード実行（RCE）など、さまざまな影響を及ぼす可能性があります。これは、最近公開されたCVE-2021-44228（別名「log4shell」）log4jに対する攻撃のように、2.15.0より前のバージョンのlog4jや、2.16.0以上で機能が完全に削除される前の2.15.xバージョンでデフォルトのformatMsgNoLookupsプロパティを無視した攻撃がそうでした。 脅威のハイライト Log4j ログインジェクション RCE – 攻撃者がログインジェクション攻撃に成功したと仮定すると、JNDIを使ってLDAP検索を行う特別に細工された文字列置換を使って、攻撃者が制御するリモートLDAPサーバから読み込まれたコードを実行することができます。Javaアプリケーションにおけるlog4jの人気の高さと、任意のコードを実行できる能力を考慮して、Apacheはこの脆弱性が公開された際に可能な限り高い深刻度の評価を与えました。この脆弱性により、多くの著名な企業が影響を受けました。 詳細 開発者やシステム管理者は、ソフトウェアが正常に動作しているかどうかを確認したり、動作していない場合にはより具体的な内容を特定するために、ログの記録はほとんどのアプリケーションやシステムにとって重要な要素です。しかし、ログインジェクションは、アプリケーションやシステム自体のリスクだけではありません。なぜなら、ログが他のソフトウェアによって処理されることはよくあることで、そのソフトウェアもログインジェクションの試みに対して脆弱である可能性があるからです。基本的に、ログファイルに書き込んだり、ログファイルから読み取ったりするものはすべて、ログインジェクション攻撃の標的になる可能性があります。また、ログを読んでいる人も、ログインジェクション攻撃の標的になる可能性があります。ログインジェクション攻撃としては、ログの偽造、サービス拒否、悪意のある文字列のインジェクションなどが考えられますが、これらの攻撃自体にもいくつかの可能性があります。 ログの偽造とは、ログに記録されるペイロードを細工して、見た目は正当だが偽のログ行を追加することです。これは、ログ分析システムや、手動でログを読む人（またはイベントシステムを通じてログを読む人）を騙して、実際には起こっていないイベントが起こったと思わせたり、特定のイベントの発生頻度の分析を歪めたりするために使用されます。サービス拒否攻撃では、攻撃者が大量のデータでログファイルを圧倒します。これにより、メモリの枯渇、ディスクスペースの肥大化、あるいは、サイズに基づいてロールバックされ、ファイルのサブセットのみが保持されるログの場合には、ログシステムによってログエントリが早期に削除されることになります。これらのログインジェクション攻撃は、特定のプログラミング言語やテンプレートエンジンを利用する必要はありません。 悪意のある文字列インジェクションは、最近公開されたlog4jの脆弱性の場合、リモートコード実行を含め、様々な形態やペイロードを取ることができます。これらの悪意のある文字列は、ロガーやログを読み取るソフトウェアの組み込み機能を悪用することができます。log4shellの場合、文字列置換の側面が悪用されます。具体的には、log4jの式言語を使用して変数を検索し、ログ出力に置換することができる機能です。ログを表示または処理するソフトウェアでテンプレートエンジンが使用されている場合、使用されているテンプレートエンジンの構文を使用してテンプレートインジェクションが可能な場合があります。ログがWebブラウザに表示される場合、テンプレートインジェクションに加えて、Webサービスで使用されているプログラミング言語でコードを注入することが可能な場合があります。例えば、ログが必ずしも攻撃者でなくてもよいユーザに表示されるときに実行されるPHPコードをログに注入することができます。また、ログにJavaScriptを書き込んで、ユーザがWebアプリケーションを介してログエントリを閲覧したときにレンダリングされて実行されるようにする、つまりストアドクロスサイトスクリプティング攻撃も可能です。 インジェクション攻撃では、情報漏えいなど様々な結果やリスクが考えられますが、リモートコード実行（RCE）は、脆弱性のより深刻な結果の一つです。RCEは、攻撃者がアプリケーション内のコードを、あたかもアプリケーションの一部であるかのように実行し、アプリケーション自身が利用可能なあらゆるアクセス権や特権を得ることを可能にします。これにより、アプリケーションが利用可能なファイルや、アプリケーションが通信するデータベースへのアクセス、さらにはリバースシェルを介したホストシステム自体へのアクセスが可能になります。ファイルやデータベースへのアクセスは情報漏えいの原因となりますが、シェルは、攻撃者がネットワークにさらに侵入し、アプリケーションがアクセスできる範囲外のシステムやリソースを侵害するための出発点となります。このように、log4shell攻撃が悪用された場合、データとネットワークの両方のセキュリティに深刻な影響を与える可能性があります。 ロギングソフトウェアを構築・保守しているグループにとっては、今回の脆弱性により、データサニタイズ機能を組み込む必要性と、セキュリティリスクを考慮してどの程度の機能が有用であるかを検討する必要性が浮き彫りになりました。ほとんどのデータベースクライアントライブラリは、SQLライブラリの「プリペアドステートメント」のようなインジェクション攻撃から保護するために、データサニタイズ機能を提供しています。独自の式言語やテンプレートを持つロギングライブラリの場合、安全ではない可能性のある文字列をロギングする際、ライブラリのユーザに同様の機能を提供することは大変役立ちます。log4shellのような深刻な脆弱性につながる可能性のある機能を数多く利用している場合、保守管理者が検討すべき課題かもしれません。このRCEを可能にする機能が2.16.0で削除されたことを考えると、log4jの保守管理者はすでにこの点に気づいているかもしれません。 log4shellからの保護方法 log4shellから保護するための最善の方法は、少なくともlog4jのバージョン 2.15.0、理想的には2.16.0以上にアップグレードして、この特定のRCEを軽減することです。log4jは直接の依存関係の外でアプリケーションに含まれているかもしれないので、ビルドシステムを使用して依存関係ツリーを入手し、間接的な依存関係としてのlog4jの脆弱なバージョンを確認することができます。「Maven」と「Gradle」は、プロジェクトの依存関係ツリーを印刷するコマンドラインツールを含んでいます。log4jのバージョンが2.10.0以上、2.15.0未満の場合、2.15.0でデフォルトで無効化された機能は、javaコマンドを使用してアプリケーションを実行する際「-Dlog4j2.formatMsgNoLookups=true」フラグを追加することで手動で無効化できます。バージョン2.15.xを使用している場合は、アプリケーションやコマンドのどこかでこのフラグがfalseに上書きされていないかどうかを確認する必要があります。 ファイアウォール（ネットワーク、Webアプリケーションを問わず）は、アップグレードの計画と実行に時間がかかる場合の暫定的な対策として、LDAPトラフィックの送信をブロックできる可能性があります。しかし、これらの対策は、この特定の脅威を保護するだけで、ログインジェクション全般を保護するものではありません。Barracuda Web Application FirewallとWAF-as-a-Serviceは、log4shellに関連するものを含むログインジェクションの試みを保護します。 ログを使用するすべてのアプリケーションは、たとえそれがlog4jやJavaを使用していなくても、外部からユーザが提供した入力がログに記録されるときに、ログインジェクション攻撃の可能性と、ログの特定の用途に関連する適切なデータサニタイズの実践を確認すべきです。これにより、ログインジェクションに関連して存在する可能性のある他のまたは将来の脆弱性を軽減することができます。サニタイズは、アプリケーションやログシステムの機能を考慮するだけではなく、ログから読み取るものがさらに別の可能性のある脆弱性を引き起こす可能性があるため、単純ではありません。同様に、そもそも何がログに記録されているかということも考慮しなければなりません。例えば、ユーザ名やメールは、インジェクション攻撃を可能にするような特殊文字を許可するケースとしてはリクエストヘッダに比べて妥当性が低いと言えますが、これらの文字を必要とするケースもあります。 ログが実際にどのようなシステムで処理されているのか、そのシステムにはどのような脆弱性が存在するのかを考慮することで、ログがもたらすリスクを適切に評価することができます。これは、ログインジェクション攻撃が発生する場所をすべて把握しなくても、その潜在的な影響を理解するのに役立ちます。ログインジェクションは、ログを読み取るすべてのシステムに影響を与える可能性があるため、ログを読み取ったり処理したりしているシステムを追跡することは、ログの記録に関連する特定のリスクを理解するのに役立ちます。また、セキュリティチームや開発チームにとっては、攻撃者がコントロールできるログの内容に関して、どのようなプログラミング、テンプレート、式言語を考慮する必要があるのか絞り込むことができます。 レポート：2021年のアプリケーションセキュリティの状況 原文はこちら： Threat Spotlight: Log injection attacks December 22, 2021 Jonathan Tanner https://blog.barracuda.com/2021/12/22/threat-spotlight-log-injection-attacks/
開催概要 セミナー名 今のバックアップシステムの弱点は克服されていますか？ ～バックアップソリューションに必要な５つの機能をご紹介～ 日時 2022年1月20日（木） 14:00～14:30 アジェンダ ランサムウェアの脅威により、私たちはバックアップについて新たな考え方を迫られています。 攻撃者は、バックアップストレージ自体も標的にし、プライマリバックアップサーバと、保持しているセカンダリディザスタリカバリのバックアップコピーを削除しようとします。そしてバックアップシステムから復旧できないようにしてから、身代金を要求することにより、企業が身代金を支払う確率を上げるのです。 このため、データのバックアップを、従来の3-2-1バックアップ戦略だけでは考えることはできなくなりました。 本ウェビナーでは、ランサムウェアによるリスクを軽減するバックアップソリューションに必要な５つの機能をご紹介します。 お申し込み 下記のフォームからお申し込みください。 お申込者にはセミナー開催日前日の 17:00 にオンラインセミナー用URLをお送りいたします。 お申込期限 2022年1月20日 14:00 セミナー資料 セミナー資料のダウンロードはこちら アーカイブ セミナー動画の視聴はこちら
