December 2021 Archives

今年一年は、ひとことで言うと、超マルチタスクな一年でした。。
働き方改革の流れもあって、昔より残業時間は減りましたが、忙しさの質が変わった感じです。
昔はひたすら１つの事に突き進んでれば良かったのですが、今は同時に平均５案件くらいをさばかないといけない。
やりたいこと、やらないといけないことは無数にあるのに、身体は１つしかないからついていかない。。
このご時世、仕事に恵まれるのは素晴らしいことですが、そんな息苦しさも感じた１年でした。
自分のクローンを作りたいくらいです（笑）

求められる立場も技術からビジネスの創出やマネジメントにシフトしてきました。
ただ、私自身は何歳になっても技術を追い続けることは大切だと思っているので、オフの時間を使って
何とか技術にも触れることができたと思っています。

この１年を振り返ると。。

1月、いきなり年明け早々、Salesforceの設定不備に起因する情報漏洩が話題になりました。私の参加していたプロジェクトもSalesforceを使っていたので、それなりに深く調査したのですが、非公開のWeb APIエンドポイントが悪用されるということで、APIセキュリティについて考える良い機会になりました。

３月は、日米制御システムサイバー演習を初のリモートで開催しました。制御システムという実機がキーになる演習をリモートで、
しかも初対面の各国からの参加者が集う中、無事成功できたのは、素晴らしい関係者が協業した賜物だと思います。

4月は、名工大ドクターとしての初の国際学会"Efficient Industrial Control Systems risk assessment using the attack path to the critical device" を発表。国際学会も現地に行けなくなってしまって、とても残念です。。

7月、2016年頃からずっと温めていたActive Directoryのセキュリティログ調査ノウハウを"NEC Active Directoryセキュリティリスク診断サービス"として、ついにリリース。
当初、一緒に調査をしていた方といつかサービスとして世に出せるといいですね、という話をしていたので、実現して感慨深いです。
研究発表やカンファレンスでの発表も大きな達成感がありますが、商用として世に出すのはまた違った達成感がありますね。

8月、私がセカンドオーサーの論文"Cyber Security Risks of Technical Components in Industry 4.0" を発表。
Industry 4.0ネタも、調査、実験共に苦労したので、セカンドでありながら、こちらも嬉しかったです。
やっぱり、あまり世に情報がないものをネタにすると、手探り状態なので、楽しい反面、苦労も多いです＾＾：

また、8月は卒業者向け講義もあり、Azure ADセキュリティをネタとしました。
今までオンプレのADしかやってこなかったので、良い勉強になりました。
それにしてもGolden SAML Attackの再現には同僚と共に苦戦しました。。（苦笑）
ちなみに、Golden SAML AttackもAzureのWeb APIが悪用されるのですが、APIのセキュリティって難しいですね。
ゼロトラでは必須の要素ではあると思いますが、APIの目的がそもそも自動化なので、多要素認証などの
セキュリティを組み込むと、どうしてもトレードオフになってしまいます。
ゼロトラスト がバズっているものの、この辺りはまだ深く議論されていない気がするので、新しい研究やサービスの
ネタにならないかなーと思っているところです。

脅威度が高い話題になった脆弱性系も多かったですね。
PrintNightmare(CVE-2021-34527)、Log4j(CVE-2021-44228/CVE-2021-45046/CVE-2021-45105/CVE-2021-44832)、Kerberos 権限昇格(CVE-2021-42287/CVE-2021-42278)など。
これ以外にWebLogicのRCEの脆弱性(CVE-2021-2394)などもあり、久しぶりにJava系の脆弱性検証をたくさんやった年でした。

また、業務以外では、名工大ドクター２年目として、今は名工大のDCS模擬プラントでペンテストをしています。
DCSは、従来のSCADAとは構成が少し異なっていて、AD環境＋全て二重化されているため、プラントに影響を与えるレベルの攻撃が
容易ではなさそうです。
ただし、アカウントが全部ADで一元管理されているので、ドメイン管理者権限を取ると、全てのマシンにログインすることができます。
二重化されているのでプラントに直接影響を及ぼす悪さは難しいものの、システムの一部に影響を与える監視の妨害などはできそうなことが分かってきました。

振り返るとあまりプライベートがなく、仕事と研究に費やした１年でしたが（笑）、とても中身が濃くて、有意義な１年だったと思います。
同僚が言っていた、"休日に本当に休んでいると、周りに置いていかれる"という言葉が印象に残っているのですが、周りを見ると、やはり"この人はすごい！！"と思う人は、（良い意味で）仕事とプライベートの区別なく、自分を磨かれている気がします。
私はそこまでにはまだ遠いですが、（外見ではなく）、中身が劣化しないように、自分を磨いていきたいと思います。

2.17.0でRCE可能との記事も出ていますが、結論から言うと、そんな簡単に攻撃できる方法ではないので、脅威度は高くないと思います。

当初の様にログを出力する延長の処理ではなく、JDBCAppenderと呼ばれるデータベースにログを保存するための機能を悪用して攻撃者サーバに接続させるというやり方なのですが、

攻撃者がlog4jの設定ファイルを改ざんできる必要があるので、その条件になっている時点でもうアウトな気がします。。。＾＾；

このように、情報が錯綜する中では、正しく脅威度を判別できる力が必要だなぁと今回改めて思いました。

結局今回も、複数回脆弱性が出て、パッチが出て、バイパス方法が出て。。。のオンパレードでしたが、個人的に本当に深刻なのは2.14.1を使っている場合のみで、

2.15.0より後では攻撃成立に条件があるので、そこまでシビアではないと思います。

何はともあれ、今回の一連の検証を通じて、RMI, JNDI, log4jの機能等、色々勉強になりました。

脆弱性検証をすると、その製品の知識だけでなく、付加的に得られる知識が多いのが良いなと思います。

この裏で発生していたKerberosのPAC検証の脆弱性(CVE-2021-42287/CVE-2021-42278)の検証が手付かずなので（汗）正月にやろうかと思います（笑）

どんどんアップデートが出るLog4shellですが、2.15.0では当初DoSが可能と言われていましたが、今はRCEをする方法がこちらのブログに上がっています。

ただし、ターゲット上で①log4jのlookup機能を明示的に有効していること、②クラスパス上にデシアライズ時に任意のコード実行に繋がる脆弱性を持つクラスが存在すること(古いバージョンのCommons Collectionなど)の条件が必要なので、そこまで脅威度は高くないと思います。

①②の条件に該当する場合は、allowedLdapHostsで接続先のサーバを絞っていても、バイパスする方法があるので、注意が必要です。

Commons Collectionの脆弱性は、約６年前に解説記事を書くために深く分析したのですが、その後、他のJavaの脆弱性で悪用されるとは思ってませんでした。。

冬休みの初日は、こちらの検証でした笑

今まで忙しかったので、冬休みはゆっくりしようと思いつつ、目の前にあるとやってしまいます＾＾：

12/19 update

何回アップデートするのだろうと思いながら。。＾＾：

昨日、V2.16.0に対しても悪用可能なCVE-2021-45105が公開されました。

org.apache.logging.log4j.ThreadContextを使って外部から受け取ったデータを変数にセットし、

Log4jのカスタムレイアウトパターンで、その変数を使っている場合に、影響を受けます(詳細は12/18のUpdate参照)。

攻撃者が不正な入力をすると、無限ループが起きて、StackOverflowErrorでアプリケーションが停止します（動作する実証コードが公開されている）。

条件に該当する場合は2.17.0にアップデートすることをお勧めします。

実機での検証結果などを簡単にまとめたものを以下に置いています。

Log4Shell.pdf

-------------

12/18 Update

また新たな迂回方法が出ました。結論から言うと2.16.0にアップデートするのが望ましいと思われます。

org.apache.logging.log4j.ThreadContextで外部から受け取ったデータを変数にputしていて、

Log4jのカスタムレイアウトパターンで、その変数を使っている場合に、formatMsgNoLookupsを回避できます。

脆弱なコードの例：

----------

Log4jのパターンレイアウト設定の例

<PatternLayout pattern="${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n"/>

コードの例

ThreadContext.put("apiversion", request.getParameter("name"));

LOGGER.warn("test");

----------

log4j v2.15.0では、上記迂回を悪用する影響が軽減された（任意のコード実行はできなくなった）ものの、修正に不備があり、

CVE-2021-45046（Dosの脆弱性）として報告され、2.16.0で解消されているそうです。

有効なPoCは今時点では公開されていないそうですが、今後公開される可能性もあるため、根本的に解消されている2.16.0にアップデートすることが推奨されています。

2.16.0では、lookup機能が完全に削除されているようです。

参考：

https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/

--------

12/17 Update

JVMオプション
-Dlog4j2.formatMsgNoLookups=true
を指定する回避策について、org.apache.logging.log4j.LOGGER.printfメソッドを使用してログ出力をしている場合は、回避策を迂回して攻撃可能との情報があり、
実際に攻撃可能なことも確認しました。
参考：
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html

下記でお伝えした通り、新しいJavaの使用も根本的な解決策ではないため、上記も踏まえるとlog4jのアップデートが最も安全と考えられます。

-------

12/14 Update

Javaのそれぞれのバージョン 6u211, 7u201, 8u191, 11.0.1 以降でLDAPを用いたリモートクラスのロードが禁止されていますが、

tomcatでは、その制限を迂回する方法があり、新しいバージョンのjavaでも攻撃可能なことを確認しました。
tomcatを使っている方はJavaのバージョンに関わらず早急な対処をお勧めします。

------------------------------

金曜の夜、自社の仕事に追われていたら、同僚から出てると教えてもらい、遅ればせながら今日検証スタート。

log4jを使っており、外部から受け取ったデータをログに出力しているプログラムが影響を受け、Webアプリなどで

使われている場合はRCEが可能です。実際に動作する攻撃コードが公開されています。

この脆弱性を悪用する攻撃は、JNDIによって外部サーバから不正なjavaクラスをロードさせるというやり方ですが、

特定のJavaバージョン以降（例えば、Java8系の場合、1.8.191）では、外部からのクラスロードがデフォルトでは禁止されています（詳しくはこちら）。

そのため、明示的にJVMのプロパティcom.sun.jndi.ldap.object.trustURLCodebaseをtrueにしていない限りは

少なくても現在公開されているPoCでの攻撃は難しいのではと思います。

ただ、その制限を迂回するようなやり方もあるようなので、完全に大丈夫とは言い切れないです。

脆弱性の解説はこちらのサイトが詳しいです。Java系は、中国語のサイトが多いですね。

ちなみに攻撃コードを検証したい人向け情報ですが、上記で書いた通り、javaのバージョンとJVMプロパティに注意するのと、

デフォルトではerror以上のレベルしか有効になっていないので、errorかfatalで出さないと刺さらないです。

log4j2.xmlでdebug, Info, warnを有効にすると、それらのレベルでも攻撃可能です。

有効になっていないログレベルで出力しても、脆弱性が存在するルートを通らないようです。

何か追加情報があれば、アップデートしたいと思います。取り急ぎ、分かっていることまで。