“Proactive PAM Defenses against LightBasin (UNC1945) & other Advanced Attackers“November 10, 2021 by Robert Auch より
2021年10月19日にCrowdStrike社はテレコム企業に影響を及ぼしたLightBasin（UNC1945とも呼ばれる）グループによるサイバー攻撃の詳細についての分析レポートをリリースしました。LightBasin攻撃はこの業界特有のプロトコールの悪用や標準のUnix/Linux攻撃を合わせた手法で実行され、複数のシステムを乗っ取りました。この特定の脅威犯罪集団は2019年以降、少なくとも13のテレコム企業への侵害を成功させました。
CrowdStrikeは、LightBasin攻撃対する防衛で7点から成るサイバーセキュリティ戦略を挙げて詳細説明しています。このCrowdStrike社による攻撃分析と照らし合わせて、私自身はここで言及されていない防衛でさらに3点の追加のLightBasin攻撃戦略が存在すると認識しています。
このブログでは以下の内容をカバーします：
- CrowdStrikeの対LightBasinの7点の推奨する保護をSANS CIS制御と紐づけ
- 上記の推奨でカバーされていない3つの追加サイバーセキュリティ制御を見極めて紐づけ
- BeyondTrust製品、PasswordSafeとPrivilege Management for Unix & Linuxがどのようにこの3つのLightBasin攻撃戦略にたいする保護を提供しセキュリティギャップを埋めるかについての説明
CrowdStrikeの7点の対LightBasinサイバー防御の推奨事項をCIS制御に紐づけする
この分析ではCrowdStrikeは以下の7つの推奨項目を特定のLightBasin攻撃に対する放映策としてあげています：
- イングレスとイグレスの進化したファイヤーウォールを利用し利用されるべきプロトコールだけが使用されていることを確認すること（特に協力関係下のパートナ間）
- 侵害があったと疑われる際にはインシデント対応捜査をすぐに開始すること
- MSP(Managed Service Provider)のセキュリティコントロールについて評価、テストを実行すること
- システム監視とSIME（エンドポイントからやエンドポイント防御ツールからのイベント転送）管理が実施され正しく実行されていることを確実にすること
- エンドポイント検知と対応（EDR）ツール（例えばCrowdStrikeのFalcon Sensor）を利用すること
- 最新の評価済の対応計画を確実にすること
- 驚異インテリジェンスのリソース（人的やその他）を利用し保持すること
これらCrowdStrikeの推奨項目を一般のセキュリティ制御フレームワークに紐づけすることで企業は推奨項目でまだ何がカバーされていないかを確認し、追加の防御で何が必要かを判断できます。今回はSANS Institute CIS Control v8に紐づけます：
- ネットワーク監視と防御: 13
- インシデント対応と管理：17
- サービスプロバイダ管理：15
- 監査ログ管理：8
- 継続的な脆弱管理：7
- インシデント対応と管理：17
- セキュリティ意識とスキルトレーニング：14
上記は現在の18種のCIS制御の7種をカバーします。
対LightBasinへの追加のサイバー防御手法を見極め紐づけする
彼らの分析内ではセキュリティ推奨が提示されなかったものの、さらに3つの攻撃戦略があると気が付きました。次にこれらの攻撃戦略を3つのCIS制御に紐づけしてみます。（上記の推奨項目とは異なることを示すため、項番はABCで示します。）
以下がその3つの攻撃戦略です：
A. 「発見された証跡から非常に弱い、またはサードベンダ関連のパスワード（huaweiなど）を利用したパスワードスプレー攻撃が示されている」
B. 「修正されたSysVintスクリプト/etc/rc.d/init.d/sshd経由からの常駐が確立されている」
C. 「攻撃者は正規のiptablesバイナリをトロイの木馬版に置き換えた」
CIS制御との紐づけをすると以下のようになります：
A. アカウント管理：5
B. アクセス制御管理：6
C. データ保護：3
では、この3つの攻撃層に有効などのような保護策があるか検討してみましょう。
この攻撃はテレコムネットワークを利用して横展開を実行する手法と説明はされていますが、金融（SWIFT）やその他健康医療企業などもパートナとの後方のピアリング(peering)システムで同じような環境を持っています。またさらにその他の多くの企業でも合意したVPNのピアリングがありCrowdStrikeがテレコム企業はGPRSやeDNSトラフィックに注意するように、と記述しているのと同じ注意を払う必要があります。
攻撃A. パスワードスプレーへの保護
CrowdStrikeの説明によると最初の企業ネットワークへの侵入は良く知られたアカウントの十分保保護されていないデフォルトパスワードか、共有パスワード経由であると分かります。
BeyondTrustのPasswordSafeは実証されたエンタープライズクラスの特権クレデンシャル管理ソリューションでアカウントインスタンス（各サーバ上の各アカウント）ごとにユニークなパスワードを設定する機能や、これらパスワードを定期的に、または利用の都度、変更する機能、そしてその他、上級のパスワードセキュリティプラクティスの執行を支援する機能で知られています。
暗号的に安全なCSPRNG（擬似乱数生成機構）で作成されたパスワードを安全に設定し（対してハッシュやレインボーテーブル、クラックテーブル内で見受けられるようなパスワード）パスワードスプレー攻撃を、アカウントが一般に知られているパスワードの利用やその漏洩を排除することで防御します。
各々のエンドポイント上の各アカウントごとにユニークな値を付与することは横展開を防ぎます。これは例え攻撃者がパスワードサーバからの/etc/shadowファイルを解読できたとしてもです。さらにPassword Safeはrotate SSH keysを設定また変更できるのでこのような手法から横展開を試みる動きも制御あるいは防御できます。
パスワードスプレーに対するその他の潜在的な保護には、これらの既知のアカウントをロックし、信頼できるジャンプホストからBeyondTrust Privilege Management for Unix and Linux（以前はPowerBrokerと呼ばれていたエンドポイント特権管理ソリューション）を使用して、pbrun -h <hostname> -u <account>を介してのみそれらにアクセスし、ActiveDirectoryなどの一元化されたディレクトリを介してアクセスおよび認証されます。
これらの最後の2つの方法では、ユーザーが同じパスワードスプレー攻撃を受けないようにすることはできませんが、それらには、攻撃者を制約されたジャンプホスト上の監査されているアクセスメソッド（Privilege Management for Unix and Linuxのセッションロギング機能を使用)の範囲内に収めます。
攻撃B．アクセス制御管理防衛
CrowdStrikeは2つ目のLightBasin攻撃手法として/etc/init.d/sshd初期化スクリプトが攻撃者によって編集され常駐したリスナーとして挿入するために悪用されたと記述しています。このような修正が可能だったことから攻撃者はrootアクセスを所持していたことが明らかですが、ではどのようにそれを入手したのでしょうか？
パスワードスプレー攻撃は単に「root」のみに対して行われたのではないでしょうから、対象アカウントが何らかのsudoアクセスを保持していたと推測できます。ここでは議論上完全なrootアクセスが合わせて入手できたと想定します、そのもとで防御策を話しましょう。
まず、あるツールに対してsudo権限を所有しているユーザがその権限を昇格させる技術手法は多く知れ渡っています。良く知られたGTFOBinsレポジトリ内でも文書化されています。
これらのツールの一つに対してのユーザのsudo権限を付与する際、逃げ道を制限するのはほぼ不可能です。しかしPrivilege Management for Unix & Linux製品ではpbksh, pbvi,およびpblessなどのツールを利用することが可能でACA（Advanced Control and Audit）を利用してGTFOBinsからの文書化されたバックドアがないツールに対してのみ権限昇格を許可したり0エスケープ後のファイルアクセスを制限したりすることが可能です。
以下のアニメーションしたGIFではPrivilege Management for Unix & Linux pbvi ユーティリティが昇格のさい利用されていることが分かります、同時にviに良く利用されるエスケープの「run scripts」は許可されていません。
Privilege Management for Unix & Linux’s のpbvi ユーティリティは”run scripts”エスケープを予防します。
（クリックするとBeyondTrust社ブログ原文のデモ動画にジャンプします)
また以下の例のようにviからpbviへの変更要求もPMULポリシーで実現できます。
procedure SafeFileEdits() {
editorlist={ ‘vi’, ‘vim’, ‘vim-tiny’, ‘emacs’, ‘nano’, ‘ed’, ‘edlin’};
if (basename(runcommand) in editorlist) {
runcommand=”pbvi”;
}
morelist={ ‘more’, ‘less’};
if (basename(runcommand) in morelist) {
runcommand=”pbless”;
}
unset(“editorlist”);
unset(“morelist”);
}
このポリシーを使う際はアクセプト前に単にSafeFileEdits();をコールしてください。この単純なポリシーを適用することで攻撃者が可能な昇格からのエスケープを阻止することができますが、SSHDファイルの修正を「直接的に」ブロックすることはできません。この部分に関してはユーザが渡した引数を見直す必要があります。この場合のベストな解決策は既知のファイルのみ修正が許可されるようにポリシーを書くことです。どのような場合でもsysv initスクリプトやsystemctl コントロールファイルを手動で編集する必要はありません。
多くの攻撃がPMUL昇格システムを通過しない可能性があることは言及に値します。root のシェルをpbkshまたはpbshに強制すると、これらのインスタンスを減らすのに役立つ場合がありますが、すべての攻撃を排除することはできません。
CrowdStrikeチームはFIM（File Integrity Monitoring）展開を推奨しています。これはPrivilege Management for Unix&Linuxが提供できる機能のひとつです。この話題内の攻撃に関しては、FIMポリシーは攻撃の早期段階での検知を大幅に改善できます、そしてその内容を直接Privilege Management for Unix & Linuxの文書に書き込みます：
{
“dev”:{“risk”:10,”mode”:true,”uid”:true,”gid”:true},
“exec”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true},
“other”:{“risk”:6,”mode”:true,”ino”:true,”pmask”:”002″,”gid”:true,”uid”:true,”ctime”:true,”size”:true,”mtime”:true},
“script”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true}
},
“bin”:
{
“all”:{“ino”:true,”hash”:true,”risk”:10,”mode”:true,”uid”:true,”ctime”:true,”pmask”:”022″,”gid”:true,”size”:true,”mtime”:true,”own”:”root”}
},
},
“include”:[
{“bin”:true,”path”:”/bin/*”,”chk”:”bin”,”recurse”:true},
{“bin”:true,”path”:”/usr/bin/*”,”chk”:”bin”,”recurse”:true},
{“bin”:true,”path”:”/lib/*”,”chk”:”bin”,”recurse”:true},
{“bin”:true,”path”:”/sbin/*”,”chk”:”bin”,”recurse”:true},
{“bin”:true,”path”:”/usr/sbin/*”,”chk”:”bin”,”recurse”:true},
{“bin”:true,”path”:”/usr/lib/*”,”chk”:”bin”,”recurse”:true},
{“sysconf”:true,”path”:”/etc/*”,”chk”:”sysconf”,”recurse”:true},
{“sysconf”:true,”path”:”/boot/*”,”chk”:”sysconf”,”recurse”:true}
],
}
このような構成は攻撃者をブロックはしませんが、防御側のエンジニアが予期していない構成を検知しすぐに対応を取ることを可能にします。
攻撃C: データ保護
システム管理者がフルのシェルを必要とする際、それをviやpbviで置き換えることは出来ません。第3の攻撃戦略に関しては攻撃者はシステムファイルをそのまま置き換えています。この場合viをpbviであるいはlessをpblessで置き換えることでは十分対処できません。これがPrivilege Management for Unix and Linux のACA機能が提供される理由です。
BeyondTrustの展開サービスチームはお客様に提供するポリシー内で「Block Backdoors」手法を良く利用します。現行のバージョンでは2つの部分があります、ひとつはユーザがユーザアカウントまたはグループメンバーシップを追加したり編集することを妨げることでユーザ作成のバックドアを防ぎます。そしてもうひとつはtools/commands/filesへのアクセスを妨げシステムダウンタイムを（CIAトリアド内のアベイラビリティを攻撃し）起こす可能性を予防します：
softwarecommands={‘yum’, ‘rpm’, ‘dpkg’, ‘apt’, ‘aptitude’};
if (!(basename(runcommand) in softwarecommands)) {
aca(“file”, “/etc/passwd”, “!all:log=2|read:log=1”, “BACKDOOR”);
aca(“file”, “/etc/shadow”, “!all:log=2|read:log=1”, “BACKDOOR”);
aca(“file”, “/etc/group”, “!all:log=2|read:log=1”, “BACKDOOR”);
}
if (basename(runcommand) == “ln”) { if (runargv[1] != “-s”) { reject(“Cannot hardlink files.”); } }
unset(“softwarecommands”);
}procedure BlockSystemDamage() {
damagecommands={‘/usr/bin/rm’, ‘/usr/bin/mv’, ‘/usr/sbin/halt’, ‘/usr/sbin/shutdown’, ‘/usr/sbin/reboot’, ‘/usr/sbin/init’, ‘/usr/bin/systemctl’, ‘/bin/rm’, ‘/bin/mv’, ‘/sbin/halt’, ‘/sbin/shutdown’, ‘/sbin/reboot’, ‘/sbin/init’};
for dmgcomm in damagecommands {
aca(“file”, dmgcomm, “all:log=1|!exec:log=2”, “SYSTEMDAMAGE”);
if ((runcommand == dmgcomm) || (basename(runcommand)==basename(dmgcomm))){
reject(“This command is blocked from executing to prevent system availability issues.”);
}
}
unset(“damagecommands”);
softwarecommands={‘yum’, ‘rpm’, ‘dpkg’, ‘apt’, ‘aptitude’};
if (!(basename(runcommand) in softwarecommands)) {
aca(“file”, “/etc/”, “!all:log=2|read:log=0|exec:log=0”, “SYSTEMDAMAGE ETC”);
aca(“file”, “/usr/”, “!all:log=2|read:log=0|exec:log=0”, “SYSTEMDAMAGE USR”);
}
unset(“softwarecommands”);
}
最初のプロシージャブロックはどのような昇格要求からも（フルシェルであっても）そのユーザがパッケージをインストールしていない限り全てpasswd/shadow/groupファイルへの読みこみ、書き込みをブロックします。
2番目の手順は、rm、mv、halt、shutdown、rebootなどの一般的なコマンドの実行をブロックします。また、パッケージ管理ツールが昇格された要求でない限り、/etc/および/usr/内のファイルへのread（）およびexec（）を除くすべてのアクセスをブロックします。これは、ファイルを不変にする、または/usrや/etcを読み取り専用でマウントするのと同じように機能しますが、ローカルシステム管理者が元に戻すことはできず、パッチ適用を妨げずに機能させることができます。link() 呼び出しを許可していないため、ユーザーは、保護されたパスの外部にある保護されたファイルをソフトリンクまたはハードリンクすることによって、それを回避することさえできません。
Privilege Management for Unix &Linux ポリシーは編集をブロック
（クリックするとBeyondTrust社ブログ原文のデモ動画にジャンプします)
LightBasinやその他の脅威への防御策の次のステップ：
このような紐づけの工程からLightBasinチームの利用した3つの攻撃手法を見極めました ― これはCrowdStrikeが推奨項目でカバーしていません ― そしてこのギャップをどう埋められるかBeyondTrustユーザーが適用できる手法について説明しました。
しつこい攻撃者は様々な手法であなたのシステムを侵害しようと試みます。防御側としてはまず、セキュリティが標準の制御フレームワークに基づいて構築されていることを確実にする必要があります。この中には各制御ポイントがビジネス要素にわたって防衛されているか継続した評価をすることが含まれます。
攻撃者による戦略を見直す際、この場合はLightBasin、この中で実行され記述されている「全て」の攻撃に対して防衛策が企業環境のセキュリティ層でカバーされていることを評価することは重要です。
Whitepapers : Malware Threat Report 2021
Whitepapers : CIS Controls 7.1 – Use the Top 20 to Identify and Mitigate IT Risk
Videos : Universal Privilege Management: The Journey to Securing Every Privilege, Every Time
Robert Auch, 上級実装アーキテクト
Robert Auchは、10年以上にわたりBeyondTrustのユーザー企業にセキュリティ設計とインストールを支援してきたプロフェッショナルサービスのセキュリティアーキテクトです。 彼の最近の焦点は、グローバルな金融機関向けのマルチプラットフォーム・ソリューション・セキュリティです。 ロバートは5つの大陸のみ？訪れたことがあります。
参考 Privilege Management for Unix & Linux Servers(PMUL)についてはこちらもご参照ください。