Protezione da SQL injection e LFI

[mmleoni]

ciao,
  dato che bugSearch.net mi ha fatto venire l'angoscia ho scritto un plugin per proteggere il sito dai vari attacchi citati:

http://extensions.joomla.org/extensions/access-a-security/site-security/12731

questo plugin intercetta le richieste inviate a joomla e blocca i principali attacchi SQL injection e LFI (local file inclusion) impedendo che arrivino al componente vulnerabile.

Domande e spiegazioni in coda a questo post, non sul mio sito (tutto ciò che va al mio sito si presume a pagamento  )

ciao a tutti,
marco

[guido57]

Installato plugin!
Grazie mille.
Guido

[mmleoni]

Nota:
questo plugin intercetta i più comuni attacchi, non OGNI attacco.
deve essere pertanto inteso come un aiuto, non come una soluzione definitiva.

ps: è uscita la versione 0.98a con qualche minor fix...

ciao,
marco

[guido57]

Nota:
questo plugin intercetta i più comuni attacchi, non OGNI attacco.
deve essere pertanto inteso come un aiuto, non come una soluzione definitiva.

ps: è uscita la versione 0.98a con qualche minor fix...

ciao,
marco

Si certo, non c'è la pretesa di avere una soluzione definitiva. Certamente però tra tutte le "azioni difensive" apprese seguendo i post relativi alla sicurezza e con l'aiuto di lavori come il tuo ...
Aggiornamento fatto!
Guido

[makjla]

installato anch'io sicuramente è un aiuto in più, grazie!

[joored]

Grazie mmleoni,
io l'ho installato ma mi chiedo
come va configurato?
Io ho lasciato la configurazione di default ad eccezione di:

- Send Email Alert on injection/inclusion = SI
- Mail to notify attack = mia@mail.it

Per il resto è meglio lasciare tutto immutato?

[mmleoni]

sì, le impostazioni di base sono più che adeguate, se non comprendi bene il significato delle opzioni è meglio non toccorle.

ciao,
marco

ps: scusate la latitanza, ma mi hanno messo sotto con il lavoro 

[@kshym]

Ho instalato su tutti siti, Grazie
da un sito, che viene attacato ricevo questo messaggio
------------------------
** Local File Inclusion [GET:task] => ../../../../../../../../../../../../../../../proc/self/environ\0
** Local File Inclusion [REQUEST:task] => ../../../../../../../../../../../../../../../proc/self/environ\0

**PAGE / SERVER INFO


*REMOTE_ADDR :
203.94.243.59

*HTTP_USER_AGENT :
libwww-perl/5.805

*REQUEST_METHOD :
GET

*QUERY_STRING :
option=com_myblog&Itemid=43&task=../../../../../../../../../../../../../../../proc/self/environ%00



** SUPERGLOBALS DUMP (sanitized)


*$_GET DUMP
 -[option] => com_myblog
 -[Itemid] => 43
 -[task] => proc/self/environ\0


*$_POST DUMP


*$_COOKIE DUMP


*$_REQUEST DUMP
 -[option] => com_myblog
 -[Itemid] => 43
 -[task] => proc/self/environ\0
 -[tmpl] => component
---------------------------------------
cinceramente capisco poco cosa è
mi potete gentilmente ad aiutare come capire questo messaggio, e prima di tutto come capire da chi, o da dove viene attacato il sito
Grazie di nuovo

[mmleoni]

ciao,
 è un attacco automatizzato (USER_AGENT :libwww-perl/5.805) volto ad una vulnerabilità di com_myblog che non filtra correttamente la path delle librerie da includere. se il server è configurato correttamente gli attacchi di questo tipo (LFI) non hanno effetto.

rinuncia a capire chi è: tanto sarà il solito ragazzino imbecille.

ciao,
marco

[@kshym]

Grazie Marco, mi può suggerire qualche cosa da leggere per approfondire?
Sinceramente ho trovato un sacco di materiale, ma non so da dove cominciare
Grazie di nuovo

[ErikaB]

visto che sto ancora risolvendo un problema con un virus, non l'ho ancora installato ma ti ringrazio anche io per il contributo, una precauzione in più non farà mai male

[mmleoni]

@@kshym 

mi spiace, ma non saprei indicare un testo specifico, posso però dire che qualcosa si trova su internet come spiegazione... per il resto per capire come funziona un attacco LFI e come prevenirlo è necessario essere dei sistemisti.

ciao,
marco

=== edited
ps: sul mio sito trovi un esempio spiegato e commentato di un attacco sqli andato a buon fine...

[@kshym]

Ciao, oggi, è stato attacato un altro sito, l'informazione che ho ricevuto è diversa da quali che erano prima, una di quali avevo postato qua.
---------------------------
** Local File Inclusion [GET:option] => ../../../../../proc/self/environ
** Local File Inclusion [REQUEST:option] => ../../../../../proc/self/environ

[**removed**]
------------------------
P.S. Grazie per il suggerimento cerco leggere il tuo sito, Grazie di nuovo

[mmleoni]

@all
non incollate il dump dell'output del plugin, del resto la cosa è stata già più che discussa.
in questa sezione del forum potete trovare molteplici discussioni che affrontano gli attacchi segnalati.

alla fin dei conti tenete presente che se arriva la mail di avviso l'attacco è stato neutralizzato e quindi non ci sono problemi veramente gravi ma:

1.
verificate che il componente oggetto dell'attacco sia realmente installato sul vostro sito (in massima parte si tratta di attacchi automatizzati, si spara nel mucchio sperando di colpire qualcuno). verificate la presenza di aggiornamenti.

2a. attacco LFI (Local File Inclusion):
se il server è ben configurato tipicamente non hanno effetto. comunque segnalate la cosa all'assistenza.

2b. attacco sqli (SQL injection):
aggiornate/correggete/rimuovete il componente/modulo incriminato.

qualsiasi altro intervento richiede competenze abbastanza elevate...

ciao,
marco

[mau_develop]

[REQUEST:option] => ../../../../../proc/self/environ
--------------------------------------------------------------------
... se questa funzionasse spengo il pc, prendo la macchina e vado a picchiare il sysadmin

M.

[bsaett]

Salve,

mi chiedevo se questo plugin svolge una funzione simile rispetto a sh404sef (versione non commerciale), visto che quell'estensione dichiara di proteggere da script iniecton, base iniection, variabili illegali e simili. Grazie per eventuali delucidazioni in merito. 

[mau_develop]

quell'estensione dichiara di proteggere da script iniecton, base iniection, variabili illegali e simili
---------------------------------------------------------------------------------------
Non so cosa faccia quell'extensions ma visto che serve per il sef sicuramente farà un parsing dell'uri per ricavare le info della request dall'url facilitato.
Stessa cosa fa il plugin di Marco e credo tutti gli altri.

Le soluzioni di sicurezza devono avere (pochi) predeterminati obbiettivi e soprattutto devono rallentare il processo il minor tempo possibile. E' un problema comune perchè non può essere lasciato al background ma deve per forza essere un passaggio obbligato prima della restituzione di qualsiasi codice. Comunque il tutto deve avvenire in un plugin di tipo system, non avrebbe senso farlo altrove.

Per cui direi, se hai già quell'extensions, visto che garantiscono, è superfluo far fare il lavoro doppio, altrimenti è un ottima efficace e leggera soluzione.

M.

[bsaett]

Grazie, sei stato chiarissimo!

[Estella]

Ciao Marco,
oggi mi è arrivata la mail che ti copio sotto (in realtà sono 4 mail tutte uguali).
Non capisco però in che modo volevano entrare.
Non è che mi spieghi meglio quello che è successo?
Grazie
Estella

** Local File Inclusion [GET:page] => ../../../../../../../../../../../../../../../../../../../proc/self/environ\0
** Local File Inclusion [REQUEST:page] => ../../../../../../../../../../../../../../../../../../../proc/self/environ\0

[** rimosso dal moderatore **]

[mau_develop]

...la stessa cosa dei post precedenti... nulla se non un tentativo a casaccio di un 'iniection di codice arbitrario.
se leggi dall'inizio capisci.

M.

[Estella]

Grazie per la risposta.
Ancora una domanda che spero non sia troppo stupida....
Se io mi costruisco un modulo che gestisce dati (che sono salvati in tabelle da me create), seguendo gli standard riportati nelle guide di joomla, nessuno sa dell'esistenza di questo modulo e quindi nessuno sa come è scritto il codice. Quindi dovrebbe essere difficile fare attacchi attraverso questi moduli.
I moduli invece pubblici, possono essere analizzati da tutti e quindi gli hacker possono scoprire le falle e sfruttarle.
E' giusto questo ragionamento?

[mau_develop]

si, in linea di massima direi di si, però diciamo che

---------------------
Se io mi costruisco un modulo che gestisce dati (che sono salvati in tabelle da me create), seguendo gli standard riportati nelle guide di joomla,
---------------------

non hai egualmente problemi di vulnerabilità, ogni extensions è quello che tu hai descritto di voler fare.
In linea di massima ti direi anche che se controlli sempre che tutto ciò che non è generato runtime es:

$pippo=0;
for($pippo=0; bla bla

non è necessario fare un casting, la variabile nasce e muore nel punto in cui viene eseguita.

ma tutto ciò che viene dall'esterno va controllato, ti aspetti una cosa e quella deve essere.... un numero un numero, di tot cifre, positivo o negativo, una stringa  -> solo caratteri, max tot, no formattazione o parole riservate etc.

adesso poi dico una cosa che non dovrei dire, ma in fondo è abbastanza vera; tranne castronate micidiali.... col plugin di mmleoni sei anche abbastanza protetta da errorini, poichè molti pattern di iniezione vengono comunque verificati a monte... certo che se mi spari un post o un get diretto nella query o in un include ... hai voglia a fare plugin

M.

[mmleoni]

non inserite tutto il codice di segnalazione: di che si tratta è scritto nella prima riga.
si tratta di un tentativo di richiamare la shell dei comandi per farle eseguire codice passato nella richiesta http.

@mau
tu hai idea di quanti (pseudo)sysadmin dovresti picchiare?

ciao,
marco

[Naomi]

In 24 ore ho ricevuto le email di avviso di 5 attacchi
4 sono LFI che non riporto come richiesto dal moderatore.
Il 5°, però, è diverso. Ovviamente per me è incomprensibile ma spero che possa essere utile a qualcuno che ne capisce...

Codice: [Seleziona]

** Union Select [GET:firstCode] => 1 and 0 union select 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Table name in url [GET:firstCode] => 1 and 0 -- 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Union Select [REQUEST:firstCode] => 1 and 0 union select 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--
** Table name in url [REQUEST:firstCode] => 1 and 0 -- 1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7 from jos_users limit 20--

[... deleted by mod ...]

*REQUEST_METHOD :
GET

*QUERY_STRING :
option=com_ezautos&Itemid=49&id=1&task=helpers&firstCode=1+and+0+union+select+1,2,concat(0x26,0x24,0x24,0x25,username,0x21,password,0x25,0x24,0x24,0x26),4,5,6,7+from+jos_users+limit+20--

[... deleted by mod ...]



[mmleoni]

questo invece è un tentativo di recuperare la password degli utenti amministrativi tramite SQL injection. vi è però da dire che solo le versioni di joomla pre 1.5.16 sono vulnerabili a questo specifico attacco.

ciao,
marco

ps: bastano le prime righe!!!