Debugging e DLL-Injection

Dalla documentazione MSDN per OpenProcess

dwDesiredAccess [in]

The access to the process object. This access right is checked against 
the security descriptor for the process. This parameter can be
one or more of the process access rights.

If the caller has enabled the SeDebugPrivilege privilege, the 
requested access is granted regardless of the contents of the security
descriptor.

E poi se guardi l'accesso al processo diritti documentazione vedrai che uno dei diritti di accesso che puoi richiedere è PROCESS_VM_WRITE che è necessario per chiamare WriteProcessMemory .

Sempre dalla documentazione MSDN per CreateRemoteThread

A common use of this function is to inject a thread into a process that is being debugged to issue a break. However, this use is not recommended, because the extra thread is confusing to the person debugging the application and there are several side effects to using this technique:

It converts single-threaded applications into multithreaded applications.
It changes the timing and memory layout of the process.
It results in a call to the entry point of each DLL in the process.

Another common use of this function is to inject a thread into a process to query heap or other process information. This can cause the same side effects mentioned in the previous paragraph. Also, the application can deadlock if the thread attempts to obtain ownership of locks that another thread is using.

Anche se la documentazione raccomanda contro di essa. Ho visto più spesso CreateRemoteThread utilizzato nei debugger o in altri tipi di applicazioni di profiling / api logging.

Chiamare OpenProcess richiede che il processo corrente sia eseguito nel contesto di un utente che ha una voce nell'ACL del secondo processo. Quindi, se si avviano due processi nello stesso contesto utente, entrambi possono aprire gli handle l'uno con l'altro con autorizzazioni sufficienti per leggere e scrivere memoria. Tuttavia, se il processo che chiama OpenProcess è in esecuzione nel contesto di un utente amministrativo, tale processo potrebbe concedere a se stesso SeDebugPrivilege , che ignora tutti gli ACL del processo, in modo tale che possa accedere a tutti i processi per qualsiasi utente sul sistema. Un avvertimento è che CreateRemoteThread non funzionerà a meno che il processo di destinazione non venga eseguito nella stessa sessione del processo di chiamata.

Per quanto riguarda la logica alla base, la funzione CreateRemoteThread è stata originariamente utilizzata per scopi di debug ed è stata mantenuta per ragioni legacy. Da allora ha visto l'uso in una varietà di diverse operazioni:

• Un modo semplice per integrare funzionalità personalizzate in un prodotto di terze parti. Un sacco di software di gioco, come xfire, fa questo. Visualizzano la loro interfaccia utente su un gioco iniettando una DLL e agganciate le chiamate attuali di DirectX e OpenGL.
• Alcuni meccanismi RPC piuttosto rozzi utilizzano thread iniettati per richiamare funzioni in un processo di terze parti.
• I sistemi anti-malware spesso iniettano una DLL nei processi in esecuzione per evitare il successo in termini di prestazioni di funzioni come ReadProcessMemory , poiché possono semplicemente utilizzare le letture della memoria diretta.
• Diverse librerie anti-copia (DRM) utilizzano CreateRemoteThread per iniettarsi in una destinazione al fine di agganciare API che potrebbero essere utilizzate per leggere la memoria da un processo protetto.

Quindi, anche se in alcuni casi potrebbe costituire un problema di sicurezza minore, è improbabile che l'API scompaia a causa della sua versatilità.

Dipende dal sistema operativo, ma nella maggior parte dei sistemi operativi due processi separati devono essere tenuti in spazi di memoria separati dal sistema operativo quando si eseguono indipendentemente in modalità utente sulla maggior parte dei sistemi operativi. Ciò non significa necessariamente che non possano esistere exploit che potrebbero aggirare questa limitazione, ma a quel punto sarebbe un attacco molto più avanzato. Possono anche esserci varie API per consentire l'accesso ad altri spazi di indirizzi di processo a seconda di cosa è permesso dal sistema operativo, ma questo è tutto specifico del sistema operativo (e potenzialmente di configurazione).