先週、ちょっとしたトラブルから、私個人が会社のシステムが使えなくなってしまい、1.5日間、全く仕事ができないという事態に。。

普段、PCを起動していない時でも、うちの会社は携帯電話からteamsやメールが見られるので、休日とかもちょこちょこ携帯は見ていたりしました。

今回のトラブルはPCだけじゃなく、携帯からのシステムアクセスもできなくなったので、携帯で話す以外、会社との接触が断たれた状態に。。

いつアクセスできるようになるかも分からない状態で、すごく不安な気持ちになりました。

普通の人だったら、休んじゃうのでしょうけど、私は気が気じゃなくて、その1.5日、大げさかもしれないですが、社会から隔離されたような気分で沈み込んでました。。

1.5日後、復旧してシステムにアクセスできた時、嬉しかったこと(笑)

病気になって健康のありがたさに気づく感じと同じですねw

私は基本的には仕事が好きですが、やっぱり時にはしんどいなー、だるいなーと思うことも正直あります。

ただ、今回のことを通じて、改めて私は仕事が無いと生きてけないんだなって思いましたね^^;

みなさまも、時には心が折れそうになったり、やり場のない怒りを感じることがあるかもしれないですが、

コロナで職を失ったり収入が減る人がたくさんいる中で、今までと変わらず働けるって素晴らしいと思います。

忙しいとなんで自分ばっかり。。と思うこともあるかもしれないですが、その人ができるから仕事が集まってくるのであって、

忙しいってポジティブに捉えると素敵なことだと思います。

仕事で心が疲れたら、読み返してみてください。

Golden SAML part2

gamzatti
Vote 0 Votes

ここしばらく、研究仲間と以前のブログで書いたGolden SAML attackの検証をしてました。

攻撃の手順は細かく書いてくれているので、きちんと読んで手順を飛ばさずやれば再現できるのですが、理解に結構時間がかかりました。

前提条件として、攻撃者がADFSのローカル管理者権限を得ている前提で、ざっくり以下の流れになります。

1)SAMLトークンに署名、暗号化している暗号鍵と証明書を窃取
2)1)で窃取した情報を用いてドメイン管理者のSAMLトークンを生成(これがGolden SAML)
3)2)で生成したSAMLトークンを用いてGraph API(AzureやM365を操作するためのAPI)用のアクセストークンを入手
4)3)で入手したGraph API用のアクセストークンを用いて、アプリケーションに対して、メールの読み書きのパーミッションを追加。
5)Graph APIの実行に必要な認証情報(シークレット)を登録
6)SAMLトークンおよび5)で取得したシークレットを用いて メールを読む APIを実行するためのアクセストークンを取得
7)5)と6)を用いて、メールを読むGraph APIを実行し、ユーザのメールボックスにアクセス

攻撃の一連の流れを理解しようとすると、SAML、Graph API、OAuth、APIのアクセス許可など色んなことを勉強する必要がありそうです。

詳しくは書かないですが、簡単に言うと、Golden TicketのTGTと同様に、一度SAMLトークンが発行されると、有効期限内は信頼されたものとして扱われて、それを元にGraph APIのアクセス権限が得られてしまうところがポイントかなと思います。
Azure ADはポータルが他要素認証なので、Golden Ticketよりも更に数多くの手順を踏む必要がありますし、
Golden Ticket程何でもできるわけではなく、ある程度できることに制限はありそうですが。。

要するに、ドメコンに加えて、ADFSサーバもちゃんと守ることが大切ということですね。

Azure ADはまだまだ私も勉強中なので、今後アップデートしていきたいと思います。
大人になっても、日々勉強ですね..(汗)

アンチエイジングだと思って頑張ります笑

久しぶりにJava関連の脆弱性を調査する機会がありました。
WebLogicのRCEの脆弱性です。動作するPoCも出ています。
Commons Collectionの脆弱性のような、デシリアライズに起因するオブジェクトインジェクションの脆弱性になります。
攻撃はweblogicの7001ポート宛に行われますので、7001ポートがインターネットに空いていないかは要チェックです。

この脆弱性の興味深いところは、Commons Collectionの脆弱性のように、デシリアライズ時にRCEするのではなく、
オブジェクトインジェクションをした後に、RCEをするための別の不正なオブジェクトを攻撃者のサーバからロードするというところです。
詳しくは書かないですが、脆弱性があって悪用されるプログラムの作り上、デシリアライズ時にRCEまで実行することが難しいので、
オブジェクトの生成時に外部リソースにアクセスしに行くようなクラスを悪用して、RCE用のプログラムをロードさせるイメージです。
ちなみに外部リソースからオブジェクトをロードさせる方法はJNDIインジェクションという手法が取られています。
この脆弱性に限らず、数年前からblack hatなどでも講演されている手法になります。

今回も、またデシリアライズ、リフレクション(動的にメソッドなどを実行すること)、RMI(リモートホスト上のJavaプログラム実行)などが

組み合わせて悪用されていますが、まぁ危なそうな機能ではありますよね。。

脆弱性を調査していると毎回思いますが、発見してPoCまで作る人って(ハッカーを含めて)天才ですね。。
よくこんなこと思いつくなぁ。。と感心してしまいます^^;
脆弱性の詳細が知りたい方はこちらの記事を読んでみてください

中国語ですが、最近のWeb翻訳はすごいですね。日本語に訳すとちょっと読みづらかったので、英語に訳した方が読みやすいかもしれません。

HiveNightmare

gamzatti
Vote 0 Votes

また出ました。CVE-2021-36934特権昇格の脆弱性について。

ローカルの特権昇格なので、PrintNightmare程の脅威度はないと思いますが、

非特権ユーザ権限を得た攻撃者が、特権でクレデンシャルのダンプをできるようになります。

動作する攻撃コードも出ているので注意が必要です。

1809以降のwindows10で、1つ以上の有効なシャドウコピーが作成されている時に影響を受けます。

ただ、他にも攻撃が成立する条件があるかもしれなくて、今調査中です。

まだ試せてないのですが、2019も影響を受けるようです。

解説記事はこちらが詳しいです。

回避策などの検証はまだできていないので、後ほど。

今までずっと温めてきたActive Directoryのセキュリティサービスをやっとリリースすることができました!

NEC Active Directory セキュリティリスク診断サービス

このサービスは、色んな方のノウハウや協力があってこそ、実現できたと思います。ご協力いただいた皆様に感謝します。

関連して、ADセキュリティに関するコラムも公開しましたので、ご興味ある方はご一読ください。

つい最近、PrintNightmare が公開されたばかりで、これからもADを狙う攻撃は継続的に出てくると思います。

本サービス含め、Active Directoryセキュリティの向上に貢献できれば嬉しいです。

今後は、Azure ADのセキュリティも勉強していきたいと思います。

PrintNightmare

gamzatti
Vote 0 Votes

最近、管理業務に忙殺され、技術に全くキャッチアップできていなかったのですが、
先日、研究仲間からヤバイの出てるよと教えてもらい、久しぶりに検証しました^^;
あまり時間がなかったので、先にexploitを成功させていた研究仲間に教えてもらった手順通りに試しましたが、
以下の前提のもとで確かにリモートコード実行できます。

・攻撃者が対象サーバとネットワーク的に疎通できる環境に侵入していること
 (攻撃パケットはSMBで対象サーバの445ポート宛に行われる)

・攻撃者がターゲットコンピュータの一般ユーザ(ADサーバの場合はドメインユーザ)のID/Passを窃取していること

ADサーバだけでなく、クライアントPCなども攻撃可能なのでご注意ください。

以下の回避策が有効であることも確認しました。

・Print Spoolerサービスの停止
・グループポリシーで「印刷スプーラーがクライアント接続を受け入れるのを許可する」を無効化(ADサーバのみ確認)

zerologonと言い、なんか最近やばいwindowsの脆弱性が多いように思います。。

Golden SAML

gamzatti
Vote 0 Votes

ずっとオンプレのAD/Windowsに関する攻撃や検知について調べてきましたが、そろそろADFSやAzureについても勉強が必要だと思い、遅ればせながらAzureについて学び始めました。
オンプレADに対しては、"Golden Ticket"でしたが、ADFSやAzureに対しては"Golden SAML"という攻撃があるそうで、ホワイトペーパーが公開されているので、読んでみました。
ADFSは、Office 365などのクラウドサービスなどに対してシングルサインオンを実現するためのADのサービスです。このシングルサインオンの際は、SAMLと呼ばれる規格が使われます。SAMLでは、ユーザが対象サービスにアクセスするとADFSにリダイレクトされ、ADFSがSAMLレスポンスと共にトークンを払い出して、以後ユーザはトークンを使って(id/passを入れることなしに)対象サービスにアクセスできるという仕組みです。

トークンは、ADFS上で生成される秘密鍵によって署名、暗号化されるのですが、この鍵を盗むことで攻撃者がSAMLレスポンスを生成し、任意のユーザ、サービスへのアクセス権を手に入れるという攻撃が"Golden SAML"です。
攻撃者が作ったSAMLレスポンスであるものの、正規の鍵で署名、暗号化されているという点では、Golden Ticketと似ていますね。。
更に、Golden Ticketと同様に、有効期限などもコントロールできるようです。
なお、秘密鍵を入手するためには、Domain Adminを取る必要はなく、ADFSのサービスアカウントまたはADFSサーバの管理者アカウントを得られれば良いそうです。ドメコンに加えて、ADFSサービスがインストールされているサーバを守るのも大切そうですね。。

上記ホワイトペーパはSolarWinds攻撃全体について書かれていて、SolarWinds攻撃では、Golden SAMLを作った後に、Azure ADにドメインを追加したり、Office 365 にアクセスするためのバックドアを作ったり、色々やっているみたいです。

やはり正規の鍵や証明書を悪用する攻撃なだけに、検知は難しいそうですが、ADFSやドメインコントローラのイベントログ、Azure ADの監査ログなどがモニタリング対象として挙げられていました。冒頭で紹介したホワイトペーパや本URLにモニタリングの詳細が書かれています。

ちなみに、Golden SAMLは、ADと他のサービスをフェデレーションさせている場合に影響を受けるので、オンプレAD単体で動かしている場合は問題なしです。

まだ、PoCなどは動かせていないのですが、読んでいるだけだと分からない点も多いので、早めに動かしてみたいところです。

Golden SAML以外にも、このホワイトペーパはADFSやフェデレーションの仕組みを知るためにとても勉強になりました。もしお時間があれば、ぜひ読んでみてください。

***** update2*****

1点訂正があります。
以前CVE-2021-24085も組み合わせて使われると書いていたのですが、
CVE-2021-24085のパッチを適用後もCVE-2021-27065によるバックドア設置が可能であることを確認したため、
msExchEcpCanaryはCVE-2021-26855(SSRFの脆弱性)によって取得していると思われます。
PoCコードからも、そのように読み取れますね。
失礼しました。。

***** update*****

Exchange Serverのsystem権限を取れるRCEの攻撃コードが見つかったようです。

(各Exchangeで使われている)有効なメールアドレスの情報が1つあれば、exploit可能なようです。

Metasploitにモジュールが組み込まれたとの情報もあるため、特にインターネットからExchangeのHTTPSサーバがアクセス可能な場合は、注意が必要な状況かと思います。

また追加情報があれば、アップデートします

********************

具体的には、以下の脆弱性を組み合わせて悪用することで、Exchange Serverにバックドアを置いてリモート制御することが可能になるとのこと。

CVE-2021-26855(SSRFの脆弱性),

CVE-2021-27065(任意のファイル書き込みの脆弱性)

これらの攻撃は全て、Webメールなどを提供しているexchange server443ポート宛に行われます。

CVE-2021-26855は、それらの脆弱性単体で何かサーバに影響を与えるというよりは、CVE-2021-26855のファイル書き込みに必要なトークンやcookieなどを入手するために使われるものと思われます。

攻撃手法についてこちらの記事が詳しいので、興味がある方は読んでみるといいと思います。

検知の観点では、これらに記載の通り、攻撃を受けると特徴的なパスやクエリを使ったリクエストが送られ、公開ディレクトリにwebshellが置かれます。

また、VirtualDirectoryの設定(InternalUrl ExternalUrl )不正に書き換えられるため、設定が正しいかを確認することが手掛かりとなりそうです。

まずは、自組織のExchange Serverの443ポートがインターネットからアクセス可能な状態になっていないか確認するのが良さそうです。

外に開いていなくとも、組織内での侵害(横展開)に悪用される可能性はあると思います。

ちなみに、SSRFって少し分かりづらいと思うのですが、超概要についてはこちらを読んでみてください。

CVE-2021-26855のSSRFは、exchangeHTTPサーバがKerberosを介してIISなどのバックエンドサーバーに対して認証を行う処理を悪用して、攻撃者がexchangeサーバになりすますことができるという内容だそうです。

自粛で動きづらいこともあり、今週末はお家にこもってカタカタしてました。

普段、休みの日に作業する時はダラダラしてしまうのですが、珍しく集中しましたね(笑)

そんな中、分かったことの備忘録諸々。全然違う話題が集まっていますが、気にしないでくださいw

・CVE-2020-25684(DNSpooq)

DnsmasqというDNSソフトウエアの脆弱性のホワイトペーパーが出ていることを同僚から教えてもらいました。

ちなみに、Dnsmasqってそんなに使われていないと思いますし、脅威度の高いものではないと思うのですが、内容が興味深かったので書いているだけです。

理論的には(RFCに基づいた実装をしている場合)、攻撃者がキャッシュポイズニングをするためには、TXID(クエリ紐づくユニークなID)とソースポートのランダム化の組み合わせを推測する必要がある。

しかし、Dnsmasqは、上位DNSサーバからの応答を受け入れる際にTXIDとソースポートの組み合わせを検証しないので、攻撃者はキャッシュポイズニングをするための試行回数が減ってハードルが下がってしまうという内容です。これはDnsmasqが転送に使用されるソケットは64個に制限し、1つのポート上で複数のTXIDを多重処理していることが原因だそう。

逆にいうと、ポートに関しては、(64/全ポート数)の確率で当たってしまうということですね。

上記ホワイトペーパーにランダムさのエントロピーの式が書いてあって、私は最初なぜそんな式になるのかが全然理解できず、数学に強い同僚に、エントロピーは確率の逆数になるからだと説明してもらい、やっと腑に落ちました。

○十年振りに、順列と組み合わせとかを真面目に考えました(結果的にはそんな複雑なこと考えなくても良かったんですけどねw)

・Splunkのフィールドエイリアス

最近、仕事の関連で今更ながらSplunkを勉強し始めました。

Splunkにはログ項目から抽出したフィールドに別名(エイリアス)を付ける機能があります。

エイリアスを使うと、異なる機器から収集したログがバラバラのフィールド名でも、統一したエイリアスをつけてあげることで、

フィールド名の違いを意識せずに統一的に検索できるようになります。

エイリアスの設定は、何故かSplunk画面からの設定ではうまくいかず、prop.confという設定ファイルを編集する方法ならうまくいきました。

ちょっとハマったので、ご参考になれば幸いです。

・pythonのrequestsモジュールで複雑なjsonデータをPOSTしたい時

シンプルなjsonデータなら、変数にjsonデータを文字列として入れて、requests.post()のdataパラメータとして渡すだけで十分なのですが、

入れ子になったような複雑なjsonデータを送りたい時は、プログラムに直接記載する方法ではうまくいかないことがあります

(特殊文字のエスケープやエンコードをちゃんとやればいけるのかもしれないですが。。)

そんな時は、jsonデータを別ファイルとして保存して、json.load()で保存したjsonをロード後、エンコードするとうまくいくかもしれません(以下のような感じ)。

json_open = open('message.json', 'r')
data = json.load(json_open)
param=json.dumps(data).encode("utf-8")


今週は残タスクがたくさんあって、今日は土曜日ですが数時間働きました。

PCを触らない休日はあまりないのですが(笑)、会社に申請を出して正式に休日に働いたのは久しぶりですね。

とはいえ、今日は短時間で集中できてとても良い日でした。

出航復帰し、最近は実ログを眺めることが増えたのですが、今日はプロキシサーバ製品であるiFilterを触っていました。

プロキシサーバのアクセスログに通信元端末のIPアドレスが記録されることは言うまでもないと思いますが、iFilterでは通信元端末のホスト名も残すことができるんですね。

デフォルトでは記録されなくて、以下の設定が必要でした。

・iFilterの"DNS逆引き"機能をONにすること

・iFilterがインストールされているサーバからクライアント端末のホスト名を逆引きできること

 (私の検証環境では、iFilterがインストールされているサーバのDNSリゾルバの設定に端末の名前解決ができるDNSサーバを追加)

小さなことの様ですが、DHCPでIPが頻繁に変わってしまうような環境でもプロキシのログだけで通信元端末を特定できるので、実は便利だなぁと思います。