Anche se hai seguito vagamente gli eventi dei gruppi di hacker Anonymous e LulzSec, probabilmente hai sentito parlare di siti Web e servizi hackerati, come i famigerati hack di Sony. Ti sei mai chiesto come lo fanno?

Esistono numerosi strumenti e tecniche che questi gruppi usano e, anche se non stiamo cercando di darti un manuale per farlo tu stesso, è utile capire cosa sta succedendo. Due degli attacchi che si sentono costantemente su di loro utilizzando sono "(Distributed) Denial of Service" (DDoS) e "SQL Injections" (SQLI). Ecco come funzionano.

Immagine di xkcd

Attacco di tipo Denial of Service

Che cos'è?

Un "rifiuto di servizio" (talvolta chiamato "Denial of Service distribuito" o DDoS) L'attacco si verifica quando un sistema, in questo caso un server Web, riceve così tante richieste contemporaneamente che le risorse del server sono sovraccaricate, il sistema si blocca e si arresta. L'obiettivo e il risultato di un attacco DDoS di successo sono i siti Web sul server di destinazione non disponibili per richieste di traffico legittime.

Come funziona?

La logistica di un attacco DDoS può essere meglio spiegata con un esempio.

Immagina che un milione di persone (gli attaccanti) si uniscano con l'obiettivo di ostacolare gli affari della compagnia X abbattendo il loro call center. Gli aggressori si coordinano in modo che martedì alle 9:00 chiameranno tutti il ​​numero di telefono della compagnia X. Molto probabilmente, il sistema telefonico della compagnia X non sarà in grado di gestire un milione di chiamate contemporaneamente così tutte le linee in arrivo saranno bloccate dagli aggressori. Il risultato è che le chiamate telefoniche legittime (ad esempio quelle che non sono gli attaccanti) non arrivano perché il sistema telefonico è impegnato a gestire le chiamate degli aggressori. Quindi, in sostanza, l'Azienda X sta potenzialmente perdendo business a causa delle legittime richieste che non sono in grado di superare.

Un attacco DDoS su un server web funziona esattamente nello stesso modo. Poiché non esiste praticamente alcun modo per sapere quale traffico proviene da richieste legittime contro gli attaccanti fino a quando il server web sta elaborando la richiesta, questo tipo di attacco è in genere molto efficace.

Esecuzione dell'attacco

A causa del "bruto" forza "natura di un attacco DDoS, è necessario disporre di molti computer tutti coordinati per attaccare allo stesso tempo. Rivedendo il nostro esempio di call center, questo richiederebbe a tutti gli aggressori di sapere entrambi di chiamare alle 9:00 e di chiamare in quel momento. Sebbene questo principio funzioni sicuramente quando si tratta di attaccare un server web, diventa molto più semplice quando vengono utilizzati i computer zombi, invece dei computer effettivamente equipaggiati.

Come probabilmente saprai, ci sono molte varianti di malware e trojan che , una volta sul tuo sistema, giace dormiente e di tanto in tanto "telefona a casa" per le istruzioni. Una di queste istruzioni potrebbe, ad esempio, essere quella di inviare richieste ripetute al server Web di Company X alle 9 del mattino. Quindi con un singolo aggiornamento alla posizione home del rispettivo malware, un singolo utente malintenzionato può coordinare istantaneamente centinaia di migliaia di computer compromessi per eseguire un massiccio attacco DDoS.

La bellezza dell'utilizzo dei computer zombi non è solo nella sua efficacia, ma anche nel suo anonimato in quanto l'attaccante non deve utilizzare il proprio computer per eseguire l'attacco.

SQL Injection Attack

Che cos'è?

Un attacco "SQL injection" (SQLI) è un exploit che sfrutta le scarse tecniche di sviluppo web e, in genere combinato con la sicurezza del database difettosa. Il risultato di un attacco riuscito può variare dalla rappresentazione di un account utente a una completa compromissione del rispettivo database o server. A differenza di un attacco DDoS, un attacco SQLI è completamente e facilmente prevenibile se un'applicazione Web viene programmata in modo appropriato.

Esecuzione dell'attacco

Ogni volta che accedi a un sito web e inserisci il tuo nome utente e password, per testare il tuo credenziali l'applicazione web può eseguire una query come la seguente:

SELEZIONA ID utente DA utenti DOVE UserName = "myuser" AND Password = "mypass";

Nota: i valori stringa in una query SQL devono essere racchiusi tra virgolette singole, motivo per cui appaiono intorno ai valori inseriti dall'utente.

Quindi la combinazione del nome utente inserito (myuser) e della password (bypass) deve corrispondere a una voce nel Tabella utenti per la restituzione di un ID utente. Se non vi è alcuna corrispondenza, nessun ID utente viene restituito in modo che le credenziali di accesso non siano valide. Sebbene una particolare implementazione possa differire, la meccanica è piuttosto standard.

Dunque ora diamo un'occhiata a una query di autenticazione del modello che possiamo sostituire i valori che l'utente inserisce nel modulo web:

SELEZIONA ID utente Dagli utenti WHERE UserName = " [utente] "AND Password =" [pass] "

A prima vista, questo può sembrare un passaggio semplice e logico per convalidare facilmente gli utenti, tuttavia se una semplice sostituzione dei valori immessi dall'utente viene eseguita su questo modello, è suscettibile a un attacco SQLI.

Ad esempio, supponiamo che "myuser "-" sia inserito nel campo del nome utente e "password errata" sia inserita nella password. Usando la semplice sostituzione nella nostra query modello, otterremmo questo:

SELEZIONA ID utente Dagli utenti DOVE UserName = "myuser" - 'AND Password = "errato"

Una chiave per questa affermazione è l'inclusione dei due trattini(-). Questo è il token di commento iniziale per le istruzioni SQL, quindi tutto ciò che appare dopo i due trattini (incluso) verrà ignorato. In sostanza, la query precedente viene eseguita dal database come:

SELEZIONA ID utente Dagli utenti DOVE UserName = "myuser"

L'omissione evidente qui è la mancanza del controllo della password. Includendo i due trattini come parte del campo utente, abbiamo completamente aggirato la condizione di controllo della password e siamo stati in grado di accedere come "myuser" senza conoscere la rispettiva password. Questo atto di manipolare la query per produrre risultati indesiderati è un attacco di SQL injection.

Quale danno può essere fatto?

Un attacco di SQL injection è causato da codifica dell'applicazione negligente e irresponsabile ed è completamente prevenibile (che tratteremo in un momento), tuttavia l'entità del danno che può essere causato dipende dalla configurazione del database. Affinché un'applicazione Web possa comunicare con il database di back-end, l'applicazione deve fornire un accesso al database (nota, questo è diverso da un accesso utente al sito Web stesso). A seconda delle autorizzazioni richieste dall'applicazione Web, questo rispettivo account di database può richiedere qualsiasi autorizzazione di lettura / scrittura nelle tabelle esistenti solo per l'accesso completo al database. Se questo non è chiaro ora, alcuni esempi dovrebbero aiutare a fornire una certa chiarezza.

In base all'esempio sopra, puoi vedere che inserendo, ad esempio,"youruser" - "," admin'- - "o qualsiasi altro nome utente, possiamo accedere istantaneamente al sito come tale utente senza conoscere la password. Una volta che siamo nel sistema non sappiamo che non siamo in realtà quell'utente, quindi abbiamo pieno accesso al rispettivo account. Le autorizzazioni del database non forniranno una rete di sicurezza per questo perché, tipicamente, un sito web deve avere almeno l'accesso in lettura / scrittura al rispettivo database.

Ora assumiamo che il sito abbia il pieno controllo del rispettivo database che dà la possibilità per cancellare i record, aggiungere / rimuovere tabelle, aggiungere nuovi account di sicurezza, ecc. È importante notare che alcune applicazioni web potrebbero aver bisogno di questo tipo di autorizzazione, quindi non è automaticamente una cosa negativa che viene garantito il pieno controllo.

Quindi illustrare il danno che può essere fatto in questa situazione, useremo l'esempio fornito nel fumetto qui sopra inserendo quanto segue nel campo del nome utente:"Robert"; DROP TABLE Users; - ".After sostituzione semplice la query di autenticazione diventa:

SELEZIONA ID utente Dagli utenti WHERE UserName = "Robert"; DROP TABLE Users: - 'AND Password = "wrongpass"

Nota: il punto e virgola in una query SQL viene utilizzato per indicare la fine di una particolare istruzione e l'inizio di una nuova istruzione.

Che viene eseguito da il database come:

SELECT UserID FROM Users WHERE UserName = "Robert"

DROP TABLE Users

Così, abbiamo usato un attacco SQLI per cancellare l'intera tabella Users.

Naturalmente, si può fare molto peggio perché, a seconda delle autorizzazioni SQL consentite, l'utente malintenzionato può modificare i valori, eseguire il dump delle tabelle (o l'intero database stesso) in un file di testo, creare nuovi account di accesso o addirittura dirottare l'intera installazione del database.

Prevenzione di un attacco di SQL injection

Come accennato più volte in precedenza, un attacco di SQL injection è facilmente prevenibile. Una delle regole cardine dello sviluppo web è che non ci si fida mai ciecamente dell'input dell'utente come abbiamo fatto quando eseguivamo una semplice sostituzione nella nostra query modello di cui sopra.

Un attacco SQLI è facilmente vanificato da ciò che viene chiamato sanitizzare (o fuggire) i propri input. Il processo di sanitizzazione è in realtà piuttosto banale dato che essenzialmente non gestisce in modo appropriato alcun carattere inline single quote (') tale da non poter essere utilizzato per terminare prematuramente una stringa all'interno di un'istruzione SQL.

Ad esempio, se si desidera cercare "O'neil" in un database, non è possibile utilizzare la semplice sostituzione poiché la virgoletta singola dopo O causerebbe la fine prematura della stringa. Invece si sanifica usando il carattere di escape del rispettivo database. Supponiamo che il carattere di escape per una singola virgoletta in linea sia la pre-introduzione di ogni citazione con un simbolo . Quindi "O'neal" sarebbe stato sanificato come "O 'neil".

Questo semplice atto di risanamento previene praticamente un attacco SQLI. Per illustrare, rivisitiamo i nostri esempi precedenti e vediamo le query risultanti quando l'input dell'utente è sterilizzato.

myuser '- / errato :

SELEZIONA ID utente DA utenti WHERE UserName = " myuser "- 'AND Password =" wrongpass "

Poiché la virgoletta singola dopo che myuser è stato sfuggito (ovvero è considerato parte del valore di destinazione), il database cercherà letteralmente lo UserName di" myuser " - ".Inoltre, poiché i trattini sono inclusi all'interno del valore stringa e non dell'istruzione SQL stessa, verranno considerati parte del valore obiettivo anziché essere interpretati come commento SQL.

Robert '; DROP TABLE Users; - / wrongpass :

SELECT UserID FROM Users WHERE UserName = "Robert "; DROP TABLE Users - 'AND Password = "wrongpass"

Eseguendo semplicemente l'escape della virgoletta singola dopo Robert, sia il punto e virgola che i trattini sono contenuti nella stringa di ricerca UserName, quindi il database cercherà letteralmente"Robert" ; DROP TABLE Users; - "invece di eseguire l'eliminazione della tabella.

In Summary

Mentre gli attacchi web si evolvono e diventano più sofisticati o si concentrano su un diverso punto di ingresso, è importante ricordare di proteggere contro attacchi provati e veri che sono stati l'ispirazione di diversi "strumenti hacker" liberamente disponibili progettati per sfruttarli.

Alcuni tipi di attacchi, come DDoS, non possono essere facilmente evitati mentre altri, come SQLI, possono. Tuttavia, il danno che può essere causato da questi tipi di attacchi può variare da qualsiasi inconveniente a catastrofico a seconda delle precauzioni prese.

How-To Geek è alla ricerca di uno scrittore di sicurezza

Pensi di avere la combinazione perfetta di conoscenza geek e abilità di scrittura? Stiamo cercando uno scrittore esperto e orientato alla sicurezza che si unisca al nostro team. Cosa stiamo cercando Cerchiamo uno scrittore esperto e un esperto di sicurezza che copra guide pratiche e spiegatori nel regno di infosec dal punto di vista del consumatore.

(how-to)

Esportare i contatti da Outlook, Outlook Express e Windows Live Mail

Hai bisogno di esportare i tuoi contatti fuori da Outlook? Lavoravo in un ufficio in cui sono installate più versioni di Office sui computer dei dipendenti, tra cui Office 2003, Office 2007, Office 2010 e Office 2013! Quando qualcuno cambia computer, di solito finisco per dover esportare le loro e-mail e i loro contatti su un altro computer, che più spesso aveva una versione diversa di Office installata.S

(How-to)