In che modo gli aggressori raccolgono feedback remoti per identificare e sfruttare i buffer overflow?

Question

In che modo gli aggressori raccolgono feedback remoti per identificare e sfruttare i buffer overflow?

#1 da (3 voti)

5

I buffer overflow locali sono relativamente facili da capire: lanciare qualche input su un'interfaccia e vedere se il processo fallisce con un core dump o simile. Tuttavia, a mio avviso, questo tipo di exploit funziona bene solo quando l'utente malintenzionato ha avuto accesso illimitato per testare le interfacce e vedere come il loro input influenza il processo.

Tuttavia, per cose come appliance bloccate (firewall, proxy, ecc.), server di fascia commerciale di fascia alta o software specializzato in cui un utente malintenzionato non può facilmente acquistarlo per giocare, come si raccoglie con successo il feedback necessario per montare un attacco riuscito?

^{(Capisco che se la risorsa ha un valore sufficiente, un aggressore motivato acquisterà un dispositivo così specializzato, ma mi piacerebbe sapere - in teoria - come potrebbe essere fatto senza accesso locale.)}

Modifica : presumo anche che l'autore dell'attacco non abbia accesso a una shell remota generica.

penetration-test exploit buffer-overflow

posta logicalscope 19.02.2012 - 19:58

fonte

1 risposta

Leggi altre domande sui tag penetration-test exploit buffer-overflow

Conserva in modo sicuro le credenziali per i servizi di applicazioni Web in Apache Quali problemi potrebbero esistere con l'emulazione TLS-OBC dei certificati del browser?

score 3 · Accepted Answer

Hai menzionato la risposta più comune nella tua domanda - per cose come firewall, proxy, server di fascia alta ecc., gli hacker li acquisteranno. Possono quindi affittare i gusci per la pratica. Il mercato in questo aspetto è incredibilmente professionale e ben organizzato, con intere piattaforme di trading create per gestire livelli di ricercatori e sfruttatori.

Il percorso in cui un utente malintenzionato non ha accesso è una prova ed un errore istruiti - ad esempio l'utente malintenzionato potrebbe sapere che un'appliance è basata su un particolare sistema operativo, quindi fa alcune ipotesi plausibili sulle dimensioni dello stack ecc. per costruire un exploit shell remoto e la slitta NOP di una dimensione che può funzionare e basta provarla e vedere se il loro codice di exploit restituisce una shell.

Se all'inizio non succede nulla, riprova.
Se il server non risponde, potrebbero essere vicini ma causare un problema, riprovare
Se la shell è stata creata - profit!