2009-05-15 9 views

risposta

27

La migliore soluzione tecnica sarebbe quella di fare qualcosa che fa sì che il codice del loader di non essere in grado di funzionare correttamente dopo il processo di inizializza. Un modo per farlo è prendere il blocco del caricatore NT, che impedirà in modo efficace qualsiasi azione del caricatore. Altre opzioni includono il patching del codice del caricatore direttamente in memoria per fare fallire le chiamate a LoadLibrary per l'aggressore (es. Inserire un breakpoint int3 e self-debug per gestire i casi attesi) ..

Ma parlando come un hacker (uno che ammette il sito a cui ti sei collegato, infatti, non impedirai mai alle persone di ottenere codice nel tuo processo, in un modo o nell'altro. LoadLibrary è una comoda scorciatoia, ma ci sono un sacco di modi diversi per caricare il codice manualmente che non potresti mai sperare di interrompere del tutto, a parte qualche codice ring0 estremamente coinvolto. E anche se vai a suonare0, gli hacker saranno proprio lì accanto a te.

Inoltre, ci sono molti usi legittimi per l'iniezione di DLL. Programmi a tema, strumenti di accessibilità e vari programmi che estendono le funzionalità del sistema operativo possono potenzialmente utilizzare l'iniezione DLL per aggiungere funzionalità a qualsiasi programma.

+0

Anche se è impossibile fermare TUTTI gli hacker, voglio solo fermare quelle tre tecniche elencate. Questi sono il più comando e la tecnica è quasi esclusivamente usata, ma la maggior parte di leechers e kiddies. Solo FYI, il codice è all'interno di una DLL iniettata, quindi tutto quello che voglio fare è assicurarmi che, una volta entrato, nessun altro possa entrare. –

+8

Attenzione, il Loader Lock è una risorsa globale e coglierla (è | dovrebbe essere) motivi per la chiusura immediata. – MSalters

+0

"tutti possono potenzialmente utilizzare l'iniezione DLL per aggiungere funzionalità a qualsiasi programma" - e, il più delle volte, per bloccarlo (con il programma-essere-iniettato-a, essere incolpato per l'incidente da utente ignaro). –

6

Il modo migliore sarebbe quello di garantire che nessun processo non affidabile ottenga l'accesso come amministratore o che venga eseguito come lo stesso account utente dell'applicazione. Senza questo accesso, l'inserimento del codice nella tua applicazione non è possibile; e una volta che un tale processo ottiene quell'accesso, può causare ogni tipo di danno senza bisogno di iniettarsi in un altro processo - l'iniezione rende solo più facile nascondersi.

+1

Sì ... non è utile. Come posso inserire il processo sotto un nuovo account utente all'interno del processo? –

1

Perché vuoi evitare questo? È un vero e proprio bisogno di "business" o sei interessato a un 'hack' per opporsi al 'hack'

Se i diritti utente lo consentono, è di progettazione - il sistema operativo fornisce a tutti gli utenti la funzionalità si, l'amministratore del sistema è stato assegnato agli account con cui vengono eseguiti.

Raymond Chen sarà il collegamento qui presto ...

+7

L'iniezione di DLL è una pratica comune nel gioco hacking. Sto solo giocando con modi per prevenirlo. E, a sua volta, i modi per aggirare quelli. Che ne dici di smettere di mettere in discussione la moralità della domanda e di rispondere invece? –

+2

Non mettere in discussione la moralità. Più informazioni sono disponibili su entrambi i lati dell'equazione, meglio è. Il mio punto era che la funzione è una funzionalità del sistema operativo volutamente fornita, e quindi non è in realtà qualcosa che "non dovrebbe accadere". In primo luogo, qualsiasi tentativo di prevenirlo è più un "trucco" che un "aggiramento". Ma il mio obiettivo principale era quello di confermare che si stava cercando di entrare in una corsa agli armamenti contro il pensare che questo è qualcosa che normalmente si regola a livello di app. Chiaramente lo sei, quindi è stato chiarito ... –

+0

Questo non fornisce una risposta alla domanda. Per criticare o richiedere chiarimenti da un autore, lascia un commento sotto il loro post. – Kcvin

0

Io non sono intimamente familiare con le API di Windows, ma posso darvi alcune indicazioni più generalizzate:

  1. vedere se è possibile utilizzare Windows Data Execution Prevention (DPE). Probabilmente non funzionerà per tutti (leggi: la maggior parte) situazioni, perché il processo delineato nel tuo link è un processo valido dal punto di vista del sistema operativo. Difesa in profondità se

  2. garantire che i vostri metodi di processo affermano autorizzazioni di protezione in tutta l'applicazione

  3. allocare staticamente il vostro spazio di memoria in modo che eventuali nuove discussioni generato in esso sarà o fallire o sovrascrivere lo spazio di memoria esistente; probabilmente avrai bisogno di un grosso pezzo di logica per rilevarlo e correggerlo.

  4. Fattore il codice in un driver di periferica o qualche altro processo di basso livello che è possibile ottenere coperto dall'ombrello Protezione file di Windows.

appena visto risposta (bel nome, btw!) Di Cthulon e ho paura che è probabilmente corretta: chi vuole eseguire l'iniezione di codice sulla vostra applicazione sarà trovare un modo per farlo. I passaggi sopra potrebbero semplicemente renderlo un po 'più difficile.

Spero che questo aiuti

1

Proprio brevi pensieri per la discussione :)

Utilizzando una grotta codice per iniettare un CRC verificare nel vostro codice sarà forse rallenta ad altri di utilizzare altre grotte di codice.

Il polling dell'elenco dei moduli di processo per le dll sconosciute in fase di caricamento potrebbe aiutare a rallentare le persone semplicemente iniettando qualsiasi cosa vecchia con collegamento thread e hook di messaggi.

+1

Rif .: "Polling dell'elenco dei moduli di processo per dll sconosciuta". Mi sento come se fossi nascosto tra i cespugli quando sei passato davanti. I codice si inietta ma non si inietta DLL in modo da non vedere nulla lì. – Joshua

2

Sei alla ricerca di una soluzione Ring3? In tal caso, si desidera creare funzionalità aggiuntive nel sistema che al momento non è (almeno a mia conoscenza) fornito immediatamente, quindi richiederà un po 'di lavoro. Inoltre, questo è possibile da un driver, infatti la maggior parte del tuo software AV svolge regolarmente questo tipo di attività.

Per quanto riguarda l'interruzione dei metodi precedenti dalla modalità utente, diventa un po 'più complicato dal momento che non è possibile registrarsi come richiamo alla creazione del processo o al caricamento della DLL. Tuttavia, se si presuppone che il processo sia iniziato prima del loro, agganciare CreateRemoteThread e funzioni simili a livello globale ed eseguire questo tipo di controllo.

Quindi, in effetti, dovresti controllare dove CreateRemoteThread vuole creare un thread e restituire un errore se non sei soddisfatto.

Questo annullerebbe i primi due metodi. Per il terzo metodo, se hai hash validi del programma originale su disco, puoi sempre controllare l'hash prima di caricarlo. Se non hai hash, potresti almeno controllare alcuni dei posti semplici che qualcuno aggiungerebbe quel tipo di codice e cercare le DLL che non ti aspetti di trovare lì (ad es. IAT, o eseguire stringhe).

Non è infallibile, ma sembra dare la funzionalità richiesta.

11

Come difendersi da quei 3 tecniche:

CreateRemoteThread

È possibile impedire la prima tecnica (CreateRemoteThread che chiama LoadLibrary) agganciando LoadLibrary. Nel tuo hook controlli su un elenco di nomi DLL che conosci parte del processo e che potrebbero essere caricati, oppure puoi controllare un elenco di DLL conosciute che non vuoi caricare.

Quando si trova una DLL, non si desidera caricare SetLastError (ERROR_ACCESS_DENIED), quindi restituire NULL. Ho impostato l'ultimo errore in modo che le persone che scrivono il codice alla ricerca di un codice di errore ottengano uno. Sembra funzionare, forse un codice diverso potrebbe essere più appropriato.

Ciò interromperà il caricamento della DLL.

SetWindowsHookEx

penso che la stessa tecnica per CreateRemoteThread blocco funzionerà per SetWindowsHookEx, ma solo se è possibile ottenere il vostro gancio installato prima che la tecnica SetWindowsHookEx ha iniziato il caricamento suo codice (che è in genere quando si crea la prima finestra in un'app - così presto nella sua vita).

Codice Cave

Bella tecnica. Non visto prima. Puoi difenderti da questo, ma dovrai agganciare il punto di ingresso LoadLibrary (non la tabella IAT) poiché Code Cave chiama direttamente LoadLibrary.

Come ha commentato l'autore dell'articolo: ci sono molti modi in cui puoi essere attaccato e probabilmente avrai difficoltà a sconfiggerli tutti. Ma spesso si vuole solo difendersi da determinati carichi DLL (come una particolare DLL di terze parti che è incompatibile con il proprio software perché la DLL di terze parti non è stata scritta correttamente per tenere conto del fatto che potrebbe essere presente anche un altro hook, quindi si blocca dal caricamento).

+1

Scrivo ganci usando CreateRemoteThread. L'aggancio di LoadLibrary non è una difesa poiché non chiamo LoadLibrary. Ho delle copie interne di FindLibrary e GetProcedure all'indirizzo nello stub dell'assembly. – Joshua

4

Dal momento che questo poster allude che sta investendo in un gioco anti-hacking, vorrei fare un po 'di luce su ciò che penso. Come ex imbroglione.

Solo un puntatore sul gioco anti-hacking.

Il modo migliore è quello di lasciare che il server esegua la logica di base del gioco. per esempio. In uno sparatutto in prima persona, monitora i movimenti che i client inviano al server. Non permettere che si spostino casualmente. Lascia che il server dica ai clienti dove ogni giocatore si basa sulla sua logica. Non inoltrare mai solo i comandi. Potrebbero essere falsi.

A chi importa se l'hacker ha hackerato il proprio client? basta rifiutarlo agli altri e tutto va bene. Per i maphack di Starcraft, la soluzione è semplice. Non dare gamestate per aree che dovrebbero essere sconosciute. Si risparmia anche la larghezza di banda.

Ero un grande imbroglione in Delta Force (è un vecchio gioco). Il trucco principale che ho usato era di deformare ovunque nel gioco modificando direttamente la memoria del processo. Nessuna DLL richiesta!

Problemi correlati