Semplici strumenti per la ricerca della memoria di processo per stringhe di connessione MSSQL

3

Sto lavorando con un software che gestisce tutte le autorizzazioni in un binario del client Windows sul computer dell'utente. Il software si collega a un database di back-end utilizzando l'account sa . La password sa viene archiviata crittografata in un file di configurazione sul client, ma il client deve ovviamente decrittografarlo prima di autenticarsi con il database.

Sono stato in grado di recuperare la password sa in vari modi, incluso l'utilizzo di un debugger, la ricerca di un dump della memoria e la ricerca diretta della memoria con WinHex . Sono curioso di sapere se esistono strumenti o malware che renderebbero questa vulnerabilità ancora più facilmente sfruttabile. La password viene memorizzata come stringa di connessione MSSQL per tutto il tempo in cui il processo client è attivo.

Esistono malware noti per cercare nella memoria le stringhe di connessione al fine di sfruttare questo tipo di vulnerabilità? Ci sono strumenti che un utente può scaricare che lo farebbe automaticamente, o c'è una discreta quantità di conoscenze tecniche necessarie per sfruttarlo?

    
posta jncraton 30.11.2015 - 15:35
fonte

4 risposte

1

Il malware per sniffare la memoria è comunemente utilizzato dagli aggressori per rimuovere i numeri di account dai sistemi POS. La maggior parte degli scraper RAM è gestita da un'espressione regolare, in cui gli autori degli attacchi cercano la memoria di un altro processo per il modello di un numero di account.

Il modello cercato è completamente configurabile dall'attaccante. Non ci sarebbe nulla che impedisca a tale software di essere riconfigurato per cercare nella memoria di un'altra applicazione stringhe come "Provider=", "UID=", "PWD=" o altri dati che potrebbero essere presenti in una stringa di configurazione del database.

Indipendentemente dal fatto che qualche attaccante lo abbia fatto nella vita reale è una domanda per gli investigatori forensi (o per gli aggressori).

    
risposta data 30.11.2015 - 22:49
fonte
3

Hai dimostrato uno dei lati negativi dell'utilizzo dell'autenticazione di SQL Server rispetto all'autenticazione di Windows. Questo è il motivo per cui Microsoft consiglia di utilizzare l'autenticazione di Windows a meno che non si abbia una buona ragione per non farlo. Qui è una descrizione dei pro e dei contro di ciascuno. In particolare:

The encrypted SQL Server Authentication login password, must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.

Qui è un altro articolo di Microsoft che parla di come proteggere la connessione di SQL Server stringhe per Entity Framework, ma le stesse regole si applicano anche se non si utilizza EF. Questa dichiarazione ribadisce il motivo per cui raccomandano sempre l'utilizzo dell'autenticazione di Windows:

Be aware that logon information and passwords may be visible in a memory dump.

When data source logon and password information is supplied in the connection string, this information is maintained in memory until garbage collection reclaims the resources. This makes it impossible to determine when a password string is no longer in memory. If an application crashes, a memory dump file may contain sensitive security information, and the user running the application and any user with administrative access to the computer can view the memory dump file. Use Windows Authentication for connections to Microsoft SQL Server.

Per quanto riguarda l'eventuale utilizzo di applicazioni malware esistenti? Certamente sappiamo che può esistere, e tu lo hai dimostrato tu stesso. Tutto ciò che serve è che un'applicazione venga eseguita con autorizzazioni sufficienti per visualizzare la memoria di un'altra applicazione che memorizza le password in memoria. La parte difficile è che è probabile che tu abbia bisogno di sapere come è strutturata la memoria per trarne vantaggio. In altre parole, probabilmente avresti bisogno di sapere come funziona l'applicazione e poi costruisci lo sniffer di memoria attorno ad esso. Forse ci sono parole chiave generali che puoi cercare, ma ciò richiederebbe un bel po 'di fortuna. Un po 'come cercare sul fondo oceanico le navi perse che potrebbero ancora avere dei tesori in esse; a un certo punto il costo / la ricompensa non ne vale la pena.

Detto questo, se sapessi che una particolare (popolare) applicazione ha questo tipo di falla nella sicurezza, puoi tentare di progettare un malware che sia su misura per quell'applicazione, e quindi indirizzare gli utenti dell'applicazione per cercare di convincerli per installare il tuo malware sullo stesso computer.

    
risposta data 30.11.2015 - 21:39
fonte
1

Le risposte fornite erano tutte utili, ma nessuno in realtà mi ha indirizzato verso uno strumento che funzioni in modo rapido e automatico. Ne ho scritto uno anch'io che analizza rapidamente la memoria di un processo di Windows utilizzando le impostazioni configurabili. Ecco il progetto su Github se è utile a chiunque altro:

memvulnscan

    
risposta data 10.12.2015 - 17:22
fonte
0

Penso che il percorso più probabile per un utente malintenzionato sia semplicemente quello di annusare il filo per la password. Se un utente malintenzionato ha un accesso sufficientemente limitato alla memoria sniff, dovrebbe anche avere accesso sufficiente per eseguire uno sniffer di pacchetti e cercare le stringhe di connessione di SQL Server sul cavo non crittografato. (SQL Server generalmente ha una connessione non crittografata).

Avresti quindi il vantaggio di poter annusare qualsiasi altra connessione non crittografata, che per le applicazioni aziendali sono molte. Con la giusta architettura dello sniffer, sarebbe banale poter aggiungere cose nuove e interessanti da sniffare, incluse le connessioni di SQL Server.

Se questo malware esiste non lo so, ma lo scopo è molto più generale di qualcosa che mira specificamente all'autenticazione di SQL Server.

    
risposta data 30.11.2015 - 21:57
fonte

Leggi altre domande sui tag