Newsgroup: it.comp.www.php
Titolo: Hackeraggio sito... da dove sono passati?

Un amico ha trovato il suo dominio hackerato.
In una certa dir si č trovato dei file lol.php .
Ora stiamo cercando di capire come abbiano fatto a salvarli nel suo spazio 
web.
Il suo dominio ospita diversa roba ma l'attenzione cade sotto un sito che 
contiene diversi form che usa per dialogare con un db mysql.
La domanda č:
Non voglio sapere come si fa (altrimenti qualcuno fraintenderebbe questo 
post) ma, secondo voi, č possibile salvare dei file su uno spazio web 
tramite SQL injection o simili?

tramite SQL injection o simili?
Sì.
Comunque, è più probabile che tu abbia assistito alla lotta fra un
pacchetto precotto (butto la' un nome... PHP-BB3) ed uno script di
attacco altrettanto precotto.
Questi casi li puoi individuare piuttosto bene, cercando su Google
cose come "MySoftware MyVersion vulnerability".
Per es. "wordpress 3.2 vulnerability".
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!


Ti ringrazio, ma non sembra questo il caso.
C'erano solo script "fatti-in-casa" (probabilmente in malo modo).
L'arduo è capire "dove" sono passati... 

 tramite SQL injection o simili?
Tramite sql injection e` difficile (a meno che i tuoi script non eseguano 
codice PHP preso dal DB, tramite eval(), ma l'uso di eval() e` male, 
quindi non va fatto :).
E` piu` facile che siano riusciti ad uploadare un file tramite un form, e 
che quel file fosse un .php e abbiano scoperto dove va salvato, e 
l'abbiano richiamato direttamente. A quel punto puoi fare quello che vuoi.
Il moto piu` veloce per proteggersi in questi casi e` di impedire il 
salvataggio di file con estensione .php (o .phtml, o qualsiasi altra cosa 
il webserver interpreti come script, non solo php, ma anche perl, python, 
ecc.)
Ci sono anche altri modi, ma questo e` il piu` comune e il piu` facile da 
sfruttare quando non vengono usati pacchetti precotti.
Bye.

 L'arduo è capire "dove" sono passati... 
Leggi i log del server web, controlla i POST prima della prima richiesta 
agli script iniettati.

 tramite SQL injection o simili?
la SQL injection in genere permette di fare altre cose. Più probabile
un get hack targettato ad una "include" messa lì alla leggera.
Tradotto: da qualche parte c'era una url che conteneva un nomefile (di
una library o altro componente), che è stato sostituito con una URL
esterna contenente codice php malevolo. Come hanno già suggerito,
dovresti trovarne evidenza nei log di apache.
bye!

ecc.)
O meglio ancora, visto che l'utente mette come "nome file" cose che levano
di sentimento ("Quel ramo del lago di Como che volge a mezzogiorno fra due
catene non interrotte di monti...doc", "Quant'è bella questa nota!.txt", e
via folleggiando), salvare il file in due pezzi (uno, eventualmente dentro
al database):
	<$unique>.inf
	<$unique>.dat
Dentro al primo file ci va il serialize() dei metadati e dentro il .dat il
contenuto del file. Quando poi l'oggetto viene risbattuto in output, viene
creato uno header "filename: \"....\"" appropriato.
Due altri vantaggi sono il bilanciamento di grossi archivi di file - visto
che si puo' ricorrere al trucchetto di usare il primo, secondo, ... byte a
mo' di path e 58ee09937d51f3886dcd0c0ea91c053e.dat viene archiviato dentro
a ${UPLOAD}/58/ee/58ee09937d51f3886dcd0c0ea91c053e.dat - e il fatto che se
viene inviato due volte un file con lo stesso nome, è possibile evitare la
sovrascrittura.
(Non so se ho raccontato la catastrofe avvenuta ${SOMEWHERE} quando non so
piu' quanti studenti uploadarono TUTTI un file "tesi.doc" [1].
Ufficialmente, il disco fu smontato ed inviato a Langley per una analisi a
raggi Y, unico modo - se pur costosissimo - per recuperare i dati perduti,
sovrascritti ormai piu' e piu' volte. Fortunatamente ho amici nell'NSA[2])
Leonardo
[1] si salvo' uno che aveva mandato la tesi in .ps... e si senti' dire che
    "il file è illeggibile con Word".
[2] e ancor piu' fortunatamente lo scimpanze' autore del "sito uèbb" aveva
    "reimplementato ed ottimizzato" la gestione dei file temporanei, cosi'
    che tutti i file mai uploadati erano ancora in /tmp/sarcazzi e bastava
    aprirli tutti per leggerne il nome dell'autore.


Punto anche i miei 2 cents su un form con un file upload che non
filtrava i .php e spostava i file in una directory facilmente
raggiungibile.
Puoi risolvere in primis bloccando i file con certe estensioni, poi
spostare i file caricati in una cartella al di fuori dal web server
(in modo che non sia raggiungibile direttamente dall'esterno), e
rinominare i file.

 ciao, f.
Bhè quello del file upload è successo anche a me, al primo sito che ho
fatto ;)
Quello dell'include-a-cazzo può essere, mi sembra postnuke aveva una
vulnerabilità simile

Ah, giusto per non avere alcun dubbio: il file creato
dall'"hacker" (lol.php mi pare di aver capito) con che permesso/utente
è?
Magari ti hanno bucato l'ftp e il codice del sito è perfetto (dubito)

 ha scritto nel messaggio 
news:7925be5f-1340-4431-b50b-<fddc8d...@p16g2000vbi.googlegroups.com...
<Ah, giusto per non avere alcun dubbio: il file creato
<dall'"hacker" (lol.php mi pare di aver capito) con che permesso/utente
<č?
Non riesco a verificarlo, non accesso all'ftp ho solo copia del file 
inviatami via mail.
<Magari ti hanno bucato l'ftp e il codice del sito č perfetto (dubito)
Non credo, credo piů sia colpa del codice... sto lavorando su tutti gli 
spunti che avete dato.
Grazie