nirvanaon/own-defenderProgetto di ricerca che esegue il reverse engineering delle interfacce COM di Windows Security Center per tracciare la registrazione degli antivirus tramite ATL, vtable, WSCAPI e RPC, con verifica in fase di esecuzione via WMI.
OWN-Defender è un progetto di ricerca sulla sicurezza di Windows incentrato sulla comprensione di come il Centro Sicurezza di Windows (WSC) rappresenta e gestisce i prodotti antivirus attraverso le sue interfacce COM.
Il progetto è nato come indagine sul comportamento dimostrato da DefendNot, ma anziché trattare l'implementazione esistente come una scatola nera, l'ho usata come punto di partenza per un reverse engineering indipendente e una verifica autonoma.
L'obiettivo di questo progetto è comprendere l'intero percorso di esecuzione:
COM
↓
CLSID / IID
↓
CoCreateInstance
↓
QueryInterface
↓
ATL Interface Map
↓
vtable
↓
IWscAVStatus4
↓
CWscIsv
↓
WSCAPI.dll
↓
RPC
↓
Centro Sicurezza di Windows
Il progetto è stato sviluppato e testato in un ambiente di ricerca Windows controllato.
Solo per uso di Ricerca / Educativo
Questo progetto è destinato alla ricerca sugli internals di Windows, al reverse engineering, all'educazione sulla sicurezza e ai test di sicurezza autorizzati. Non utilizzarlo per interferire con software di sicurezza su sistemi che non possiedi o per i quali non hai esplicito permesso di test.
La domanda iniziale era semplice:
Come fa il Centro Sicurezza di Windows a sapere che esiste un prodotto antivirus?
Invece di fermarmi alla documentazione pubblica dell'API, volevo capire cosa accade sotto l'API.
Questo ha portato a diverse domande:
QueryInterface() l'interfaccia?__int64 a1 per un metodo?Register() è effettivamente la funzione di registrazione AV?Il primo passo è stato identificare la classe COM del Centro Sicurezza di Windows.
Il progetto utilizza la classe COM WSC:
CLSID_WscIsv
F2102C37-90C3-450C-B3F6-92BE1693BDF2
L'implementazione contiene anche una logica per individuare dinamicamente il CLSID dal registro di Windows invece di affidarsi esclusivamente a un valore hardcoded.
Concettualmente:
HKLM
└── SOFTWARE
└── Classes
└── CLSID
└── {CLSID}
└── API ISV del Centro Sicurezza di Windows
Questo ha fornito la prima relazione importante:
Registro
↓
CLSID
↓
API ISV del Centro Sicurezza di Windows
La sfida successiva è stata determinare quale interfaccia COM dovesse essere richiesta.
Il progetto utilizza:
IWscAVStatus4
con:
4DCBAFAC-29BA-46B1-80FC-B8BDE3C0AE4D
Una delle lezioni importanti emerse dalla ricerca è stata:
Un nome GUID da solo non è una prova sufficiente.
Ho verificato la relazione attraverso il reverse engineering anziché assumere che il nome dell'interfaccia e il GUID fossero corretti.
L'indagine ha incluso:
QueryInterface_ATL_INTMAP_ENTRYQueryInterfaceUno dei passaggi di reversing più utili è stato seguire l'implementazione di:
CComAggObject<CWscIsv>::QueryInterface()
che alla fine raggiunge:
ATL::CComObjectRootBase::InternalQueryInterface()
La mappa delle interfacce ATL viene utilizzata per confrontare l'IID richiesto con le voci di interfaccia registrate.
Concettualmente:
IID richiesto
↓
QueryInterface()
↓
InternalQueryInterface()
↓
Mappa interfacce ATL
↓
Confronto GUID
↓
Interfaccia corrispondente
↓
Puntatore all'interfaccia
Questo ha fornito una prova indipendente che il GUID oggetto di indagine corrispondeva effettivamente all'interfaccia COM prevista.
Register()Una delle maggiori sfide del reversing è stata capire perché IDA/Ghidra non sempre mostravano la firma del metodo che mi aspettavo.
L'interfaccia ricostruita contiene:
virtual HRESULT __stdcall Register(
BSTR path,
BSTR name,
unsigned int,
unsigned int
) = 0;
Tuttavia, il decompilatore poteva mostrare un'implementazione come:
_IWscAVStatus4<CWscIsv>::Register(__int64 a1)
All'inizio questo sembrava incoerente.
Ulteriori indagini hanno mostrato che la rappresentazione del decompilatore descriveva un wrapper/thunk e la chiamata vtable indiretta sottostante, piuttosto che presentare la firma logica completa dell'interfaccia.
Questa è diventata una lezione importante:
L'output del decompilatore è un'interpretazione del codice macchina, non la verità originale a livello di sorgente.
Per risolvere queste discrepanze, ho confrontato:
Definizione interfaccia COM
↓
Layout vtable
↓
Assembly
↓
Wrapper/thunk
↓
Convenzione di chiamata
↓
Funzione target effettiva
Register()Un'altra fonte di confusione era la presenza di più funzioni con nomi come:
IWscAVStatus2::Register
IWscAVStatus4::Register
IWscFWStatus2::Register
RegisterAV
La realizzazione importante è stata che nomi simili non significano interfacce identiche.
Per esempio:
AV
↓
IWscAVStatus4
↓
Registrazione AV
mentre:
Firewall
↓
IWscFWStatus2
↓
Registrazione firewall
Il numero dell'interfaccia e l'implementazione circostante dovevano essere verificati invece di selezionare una funzione semplicemente perché il suo nome conteneva Register.
Questa è stata una delle parti più utili della ricerca perché mi ha costretto a correlare:
Interfaccia
+
IID
+
vtable
+
implementazione
+
layout dei parametri
+
target della chiamata
Dopo aver identificato l'interfaccia corretta, ho tracciato l'operazione di registrazione più in profondità nel binario.
Il percorso osservato era approssimativamente:
IWscAVStatus4::Register()
↓
CWscIsv
↓
RegisterSecurityProductFunction
↓
wscRegisterSecurityProduct()
↓
WSCAPI.dll
↓
s_wscRegisterSecurityProduct()
↓
NdrClientCall3()
↓
RPC
↓
Centro Sicurezza di Windows
Questo è stato particolarmente importante perché il metodo COM stesso non era l'operazione finale.
La chiamata alla fine attraversava un confine RPC.
Questo ha cambiato il modo in cui vedevo l'architettura:
COM
≠
implementazione finale
Invece:
COM
↓
implementazione locale
↓
API WSC
↓
client RPC
↓
componente Windows
WSCAPI.dllIl livello successivo era WSCAPI.dll.
Il percorso ricostruito tramite reverse engineering raggiungeva:
wscRegisterSecurityProduct()
che alla fine invocava:
s_wscRegisterSecurityProduct()
e poi:
NdrClientCall3()
Questo era il punto in cui l'indagine passava da una normale chiamata COM all'infrastruttura RPC di Windows.
Comprendere questo livello ha aiutato a spiegare perché il comportamento non poteva essere completamente compreso guardando solo la DLL COM originale.
L'analisi statica era solo una parte della ricerca.
Dopo aver ricostruito l'interfaccia e il percorso di chiamata rilevanti, ho creato la mia implementazione controllata e ho confrontato il comportamento risultante con il Centro Sicurezza di Windows.
Ho utilizzato informazioni del Centro Sicurezza di Windows / WMI come:
ROOT\SecurityCenter2
AntiVirusProduct
per osservare indipendentemente le informazioni sul prodotto registrato.
Il processo di verifica era:
Reverse engineering
↓
Ricostruzione interfaccia
↓
Implementazione propria
↓
Esecuzione a runtime
↓
Centro Sicurezza di Windows
↓
Osservazione WMI
↓
Confronto risultati
Questo mi ha permesso di verificare che le conclusioni dell'analisi statica corrispondessero al comportamento osservabile di Windows.
Questo progetto mi ha insegnato molto più di come interagire con una singola interfaccia COM.
CoCreateInstanceQueryInterfaceWSCAPI.dllNdrClientCall3Soprattutto, ho imparato a evitare di affidarmi a una singola prova.
Invece:
Simbolo
↓
Decompilatore
↓
Assembly
↓
GUID
↓
Mappa interfacce
↓
vtable
↓
Grafo delle chiamate
↓
RPC
↓
Verifica a runtime
Ogni livello aumenta la fiducia nella conclusione.
L'implementazione della ricerca è composta da due componenti principali.
OWN-Defender
│
├── OWN-Defender.cpp
│ ├── interazione COM WSC
│ ├── individuazione CLSID
│ ├── inizializzazione COM
│ ├── interazione IWscAVStatus4
│ ├── registrazione
│ ├── aggiornamento stato
│ └── pulizia
│
└── dllmain.cpp
├── punto di ingresso DLL
├── loader di ricerca
├── esecuzione controllata
└── gestione pulizia/arresto
Il repository è volutamente piccolo affinché la relazione tra il comportamento ricostruito tramite reverse engineering e l'implementazione rimanga facile da seguire.
Questo progetto è stato costruito attorno a domande piuttosto che alla semplice riproduzione di funzionalità:
Come identifica WSC la classe COM?
Come viene mappato l'IID all'interfaccia?
Come individua QueryInterface l'interfaccia?
Perché IDA mostra firme di funzioni diverse?
Dove si trova la vtable effettiva?
Quale Register() è l'implementazione AV?
Cosa accade dopo il metodo COM?
Dove entra WSCAPI.dll nella catena di chiamate?
Dove inizia RPC?
Come si può verificare indipendentemente il risultato?
Queste domande si sono rivelate alla fine più preziose dell'implementazione finale stessa.
Il progetto fornisce anche un utile punto di partenza per studiare il confine di sicurezza tra:
Applicazione
↓
COM
↓
Centro Sicurezza di Windows
↓
Informazioni sul Provider di Sicurezza
Una distinzione importante è che registrare informazioni sul prodotto di sicurezza non equivale automaticamente a disabilitare il motore Defender o a bypassare i suoi meccanismi di protezione.
Pertanto, questo progetto dovrebbe essere visto principalmente come:
Ricerca di reverse engineering su Centro Sicurezza di Windows / COM
piuttosto che come un'affermazione che la sola registrazione WSC costituisca una vulnerabilità di Defender.
Qualsiasi impatto sulla sicurezza richiede un'indagine e una validazione separate.
Questa ricerca è stata ispirata in parte dal lavoro dimostrato in DefendNot di es3n1n.
Un ringraziamento speciale all'autore per aver fornito un utile punto di partenza per comprendere il meccanismo WSC.
Progetto originale: https://github.com/es3n1n/defendnot
Lo scopo di questo repository non è rivendicare la ricerca originale come propria, ma documentare il mio processo di reverse engineering, l'implementazione indipendente e la verifica del comportamento sottostante di Windows.
Questo repository è fornito per:
Utilizza questo progetto solo su sistemi che possiedi o per i quali sei esplicitamente autorizzato a eseguire test.
L'autore non è responsabile per uso improprio, danni, perdita di dati, interferenza con i controlli di sicurezza o distribuzione non autorizzata.
Questo progetto è concesso in licenza secondo la GNU General Public License v3.0.
Vedere LICENSE per i dettagli.
L'obiettivo principale di OWN-Defender non è semplicemente riprodurre una tecnica di registrazione AV.
È dimostrare una metodologia di reverse engineering ripetibile:
Trova
↓
Mappa
↓
Ribalta
↓
Ricostruisci
↓
Traccia
↓
Implementa
↓
Verifica
Ciò che è iniziato con una domanda sul Centro Sicurezza di Windows è diventato un'esplorazione più profonda di COM, ATL, mapping GUID/IID, vtable, codice generato dal compilatore, WSCAPI, RPC e architettura di sicurezza di Windows.
L'implementazione è il risultato. Il processo di reverse engineering è il vero progetto.