Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20602 > unrolled thread

Una cosa curiosa.

Back to article view | Back to it.comp.www.php

Contents

  Una cosa curiosa. Alex <tommaso5ita@yahoo.it> - 2016-04-04 11:16 +0200
    Re: Una cosa curiosa. Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-09 06:57 +0000
      Re: Una cosa curiosa. Alex <tommaso5ita@yahoo.it> - 2016-04-09 12:19 +0200
        Re: Una cosa curiosa. fmigliori <fmigliori@gmail.com> - 2016-04-09 06:40 -0700
          Re: Una cosa curiosa. Alex <tommaso5ita@yahoo.it> - 2016-04-10 11:15 +0200
            Re: Una cosa curiosa. Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-10 09:44 +0000
              Re: Una cosa curiosa. Alex <tommaso5ita@yahoo.it> - 2016-04-11 13:10 +0200
        Re: Una cosa curiosa. Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-09 21:53 +0000
          Re: Una cosa curiosa. Leonardo Serni <lserni@gmail.com> - 2016-04-10 00:36 +0200
      Re: Una cosa curiosa. g4b0 <email_sul_mio_sito@che_leggi_in.firma> - 2016-04-11 15:52 +0200

#20602 — Una cosa curiosa.

A volte si vedono chiamate http veramente strane.
Ad esempio questa dove al posto dell' IP c'è una cosa del genere:

}__test|O:21:"JDatabaseDriverMysqli":3:{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:" 
disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"feed_url";s:1348:"eval(chr(99).chr(111).chr(112).chr(121).c

Peraltro l'usanza di unviare IP irregolari non è ristretta ai piccoli 
operatori, anche i grandi a volte ne inviano 2 separati da una virgola. 
Senza tentativi di SQL injection ma non buoni lo stesso.

Ok, il php permette di filtrare l' IP in arrivo, però mi chiedo come 
accidenti fanno a fare chiamate http che hanno la stringa dell' IP così 
fasulla.

Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [next] | [standalone]

#20624

Il Mon, 04 Apr 2016 11:16:54 +0200, Alex ha scritto:

> A volte si vedono chiamate http veramente strane.
> Ad esempio questa dove al posto dell' IP c'è una cosa del genere:
> 
> }__test|O:21:"JDatabaseDriverMysqli":3:
{s:2:"fc";O:17:"JSimplepieFactory":0:{}s:21:"
> disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":5:
{s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}s:8:"feed_url";s:1348:"eval
(chr(99).chr(111).chr(112).chr(121).c

Mi hai incuriosito e ho trovato questo:

https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-
joomla.html
 
> Ok, il php permette di filtrare l' IP in arrivo, però mi chiedo come
> accidenti fanno a fare chiamate http che hanno la stringa dell' IP così
> fasulla.

Ma sei sicuro fosse nell'IP? Da quel sito sembra sia nella query string.

Bye.

[toc] | [prev] | [next] | [standalone]

#20625

Nel suo scritto precedente, Alessandro Pellizzari ha sostenuto :
>
> Mi hai incuriosito e ho trovato questo:
>
> https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-
> joomla.html
>  
Grazie per il ... coraggio di esaminare un argomento come questo !
Ho fatto gli aggiornamenti ai siti joomla, a suo tempo e, toccando 
ferro, dovrei essere ragionevolmente tranquillo. Però questi continui 
tentativi, che non si sono fermati, mi innervosiscono comunque.


>
> Ma sei sicuro fosse nell'IP? Da quel sito sembra sia nella query string.
>

Sicuro? Si, penso di si.
Le chiamate con sql injection sono numerose, alcune hanno la stringa
fet***e   nel campo $_SERVER['REQUEST_URI']
altre ce l' hanno in  $_SERVER['HTTP_USER_AGENT'])
Infine, alcune chiamate hanno la stringa incriminata in uno di questi 
campi: $_SERVER["HTTP_X_FORWARDED_FOR"] oppure $_SERVER["REMOTE_ADDR"] 
o ancora $_SERVER["HTTP_CLIENT_IP"] che sono le aree dell' IP 
chiamante.

Siccome, appunto, le chiamate farlocche sono tante e tutte in rapida 
successione, gli IP si possono desumere anche se non sono segnati e si 
tratta di IP cinesi, russi, ma anche del principale fornitore europeo 
di server a noleggio, un francese e tutti immaginano facilmente chi è.
Ultimamente in nostro francese ha fatto una modifica, ovvero mette la 
stringa di sql injection nel campo dell' user agent e come IP indica un 
IPv6.
Non so se gli IPv6 possano essere bannati da un file .htaccess, come 
gli IPv4,  ma certo saltano il Firewall (IPTable), il mio almeno, e la 
cosa è preoccupante perché se il nostro si mette anche a fare mail spam 
diventa quanto meno laborioso lasciarlo fuori.

Dunque, come fanno a falsificare l' IP? Bho. Non credo che basti aprire 
un socket, bisognerebbe anche 'personalizzare' il sottostante tcp/ip, 
penso. Una cosa da veri esperti e per cosa poi? Per essere considerati 
dei veri rompiscatole?

 Bye.

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20626

Il giorno sabato 9 aprile 2016 12:19:30 UTC+2, Alex ha scritto:
> Nel suo scritto precedente, Alessandro Pellizzari ha sostenuto :
> >
> > Mi hai incuriosito e ho trovato questo:
> >
> > https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-
> > joomla.html
> >  
> Grazie per il ... coraggio di esaminare un argomento come questo !
> Ho fatto gli aggiornamenti ai siti joomla, a suo tempo e, toccando 
> ferro, dovrei essere ragionevolmente tranquillo. Però questi continui 
> tentativi, che non si sono fermati, mi innervosiscono comunque.
> 
> 
> >
> > Ma sei sicuro fosse nell'IP? Da quel sito sembra sia nella query string.
> >
> 
> Sicuro? Si, penso di si.
> Le chiamate con sql injection sono numerose, alcune hanno la stringa
> fet***e   nel campo $_SERVER['REQUEST_URI']
> altre ce l' hanno in  $_SERVER['HTTP_USER_AGENT'])
> Infine, alcune chiamate hanno la stringa incriminata in uno di questi 
> campi: $_SERVER["HTTP_X_FORWARDED_FOR"] oppure $_SERVER["REMOTE_ADDR"] 
> o ancora $_SERVER["HTTP_CLIENT_IP"] che sono le aree dell' IP 
> chiamante.
> 
> Siccome, appunto, le chiamate farlocche sono tante e tutte in rapida 
> successione, gli IP si possono desumere anche se non sono segnati e si 
> tratta di IP cinesi, russi, ma anche del principale fornitore europeo 
> di server a noleggio, un francese e tutti immaginano facilmente chi è.
> Ultimamente in nostro francese ha fatto una modifica, ovvero mette la 
> stringa di sql injection nel campo dell' user agent e come IP indica un 
> IPv6.
> Non so se gli IPv6 possano essere bannati da un file .htaccess, come 
> gli IPv4,  ma certo saltano il Firewall (IPTable), il mio almeno, e la 
> cosa è preoccupante perché se il nostro si mette anche a fare mail spam 
> diventa quanto meno laborioso lasciarlo fuori.
> 
> Dunque, come fanno a falsificare l' IP? Bho. Non credo che basti aprire 
> un socket, bisognerebbe anche 'personalizzare' il sottostante tcp/ip, 
> penso. Una cosa da veri esperti e per cosa poi? Per essere considerati 
> dei veri rompiscatole?
> 
>  Bye.
> 
> -- 
> Alex
> 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---

REQUEST_URI è il più facile da modificare, lo puoi fare a mano 
e così anche l'HTTP_USER_AGENT,  i 
HTTP_X_FORWARDED_xxxxx sballati possono essere dovuti da 
una cattiva configurazione del proxy del cliente, ma non ho 
esperienza diretta, per gli ip bisogna capire come li ottiene 
php, ma di sicuro modificare il layer 3 significa 
incompatibilità totale con tutti i dispositivi di rete, sicuro che 
non ci sia confusione nei tuoi log?. Gli IPv6 non sono certo un 
sistema di hack, e iptable li gestisce, magari dovrai usare un 
pacchetto aggiornato e studiarti le differenze con l'attuale. 
Lo so è una palla, io avrei concepito l'IPv5 con 1 byte in più, 
ma con l'attuale tendenza di crescita dei nodi sarebbe 
stata un'idea miope.
Puoi segnalare gli ip incriminati del principale fornitore 
europeo di server a noleggio tramite https://www.ovh.it/abuse/.

[toc] | [prev] | [next] | [standalone]

#20634

fmigliori ha spiegato il 09/04/2016 :
>
> ma di sicuro modificare il layer 3 significa 
> incompatibilità totale con tutti i dispositivi di rete, sicuro che 
> non ci sia confusione nei tuoi log?. 
>
Siete tutti convinti e comincio a dubitarne anche io.

Comunque come sai meglio di me nelle stringhe user agent c'è spesso l' 
indirizzo di una pagina di cortesia del bot, se il vivitatore è un bot.
In una c'era scritto che, se non volevi il bot, ti bastava inserire un 
adeguato robot.txt.
Sconsigliava assolutamente di usare cose tipo .htaccess, perché non 
avrebbero funzianato in quanto lui aveva tantissimi ip.

Ora, facendo 2+2, significa anche che lui può cambiare l' IP con la 
massima facilità, e come lui possono farlo anche altri penso.

Bene, questo è un bot serissimo e con la migliore reputazione e non ho 
mai notato nulla nel suo comportamento di sbagliato, ma come fai ad 
essere sicuro che sono tutti così ?

Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20635

Il Sun, 10 Apr 2016 11:15:13 +0200, Alex ha scritto:

> Sconsigliava assolutamente di usare cose tipo .htaccess, perché non
> avrebbero funzianato in quanto lui aveva tantissimi ip.
> 
> Ora, facendo 2+2, significa anche che lui può cambiare l' IP con la
> massima facilità, e come lui possono farlo anche altri penso.

Quello dei bot è un "problema" diverso.
Per avere un bot che raccolga dati a una velocità decente non basta un 
singolo server, quindi in realtà i bot sono spalmati su decine o centinaia 
di server, ognuno col suo IP, in zone geografiche diverse, quindi molto 
probabilmente su classi di rete diverse.

Cercare di bloccarle tutte con una blacklist è un lavoro improbo, e il modo 
semplice, per i bot legali, è chiedere al bot di non tornare (o di non 
indicizzare certi contenuti) tramite robot.txt

La falsificazione dell'IP è un discorso diverso, ed è più complessa.

Per (cercare di) farla breve: nel pacchetto IP che il client invia al 
server ci devono essere l'IP sorgente, quello destinazione, la porta 
sorgente e destinazione e altre informazioni.

L'IP sorgente viene poi usato dal server per spedire la risposta (facendo 
un pacchetto "specchio" con sorgente e destinazione invertite).

Se metti un IP sorgente falso nella richiesta, non ti arriverà mai la 
risposta, perchè il server la manderà a qualcun'altro.

Questo può essere utile quando stai cercando di fare un attacco DoS (mandi 
pacchetti con un IP falso e lasci che il server mandi le risposte a 
qualcun altro, di fatto dimezzando il traffico sul server dell'attaccante, 
e quindi moltiplicando la potenza di fuoco).

Col protocollo TCP non credo si possa fare (ma non sono un cracker così 
esperto) per via del 3-way handshake. In pratica nel TCP:

1- il client richiede connessione
2- il server richiede conferma
3- il client manda conferma e manda richiesta

Se falsifichi l'IP non riceverai mai la conferma al passo 2, e se "forzi" 
il passo 3 il server scarta la richiesta perché non valida.

Per questo mi pareva difficile fosse un IP falsificato.

Tra l'altro nel pacchetto IP c'è posto solo per 4 byte in IPv4 e per 16 in 
IPv6, quindi è difficile infilarci una stinga serializzata di PHP. :)

Bye.

[toc] | [prev] | [next] | [standalone]

#20646

Alessandro Pellizzari ha detto questo domenica :

> Col protocollo TCP non credo si possa fare (ma non sono un cracker così 
> esperto) per via del 3-way handshake. In pratica nel TCP:
>
> 1- il client richiede connessione
> 2- il server richiede conferma
> 3- il client manda conferma e manda richiesta
>
Un sistema di saluti e di sincronizzazione.
Ho dato anche io una sbirciatine ed è veramente molto complesso, 
oltretutto non c'è solo tcp/ip ma anche udp che è più semplice ma meno 
affidabile.
Comunque hai ragione: mi sa che ho il log in disordine, forse con un 
po' di sporcizia.
Ciao e grazie.

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20632

Il Sat, 09 Apr 2016 12:19:28 +0200, Alex ha scritto:

> campi: $_SERVER["HTTP_X_FORWARDED_FOR"] oppure $_SERVER["REMOTE_ADDR"]
> o ancora $_SERVER["HTTP_CLIENT_IP"] che sono le aree dell' IP chiamante.

Tutti i campi HTTP_* sono facilmente modificabili.

L'unico modo che mi viene in mente è un possibile bug nel parser degli 
header di PHP. Per esempio, se un hacker aggiungesse un header tipo

^H^H^H^H^HREMOTE_ADDR: blablabla

(dove ^H è il control-code per "backspace")

e PHP lo trasformasse in 

$_SERVER['HTTP_^H^H^H^H^HREMOTE_ADDR'] = 'blablabla'

dopo che ha messo REMOTE_ADDR in quell'array, e interpretasse la stringa 
risultante, potrebbe sovrascrivere il valore vero.

È l'unico modo che mi viene in mente, e sono un po' terrorizzato al 
pensiero che possa essere vero. :D

Bye.

[toc] | [prev] | [next] | [standalone]

#20633

On 9 Apr 2016 21:53:49 GMT, Alessandro Pellizzari <shuriken@amiran.it> wrote:

>È l'unico modo che mi viene in mente, e sono un po' terrorizzato al 
>pensiero che possa essere vero. :D

A quanto pare, PHP butta via direttamente tutto lo header se ci provi:

# echo -e -n "GET /hdr.php HTTP/1.0\r\nX-SERVER-ADDR: 192.168.666.666\r\n\r\n" | netcat 192.168.2.200 80 | grep 168
HTTP_X_SERVER_ADDR = 192.168.666.666
SERVER_ADDR = 192.168.2.200
REMOTE_ADDR = 192.168.2.200

# echo -e -n "GET /hdr.php HTTP/1.0\r\nX-^?SERVER-ADDR: 192.168.666.666\r\n\r\n" | netcat 192.168.2.200 80 | grep 168
SERVER_ADDR = 192.168.2.200
REMOTE_ADDR = 192.168.2.200

Piu' precisamente se lo header contiene qualcosa che non sia alfanumerico bòno.

Si può fare questo, ma è una illusione:

echo -e -n "GET /hdr.php HTTP/1.0\r\nX-SERVER-ADDR: \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bSERVER_ADDR =
192.168.666.666\r\n\r\n" | netcat 192.168.2.200 80 | grep 168
SERVER_ADDR = 192.168.666.666
SERVER_ADDR = 192.168.2.200
REMOTE_ADDR = 192.168.2.200

Infatti la variabile si chiama sempre HTTP_X_SERVER_ADDR:

...| grep 168 | tr "\b" "."
HTTP_X_SERVER_ADDR = .....................SERVER_ADDR = 192.168.666.666
SERVER_ADDR = 192.168.2.200
REMOTE_ADDR = 192.168.2.200

To cut a long story short, anche trucchi con ASCIIZ, UTF-8, UTF-8 incompleto, ritorni carrello e caratteri
di controllo messi a spregio (anche codificati, anche travestiti da UTF-8) non hanno funzionato. Se c'è un
modo, è al di là della mia non insignificante fantasia perversa :-D

Leonardo che quindi non escluderebbe che ci sia
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#20650

On 09/04/2016 08:57, Alessandro Pellizzari wrote:
> Mi hai incuriosito e ho trovato questo:
> 
> https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-
> joomla.html

Strano, non si vedono spesso zero-day su Joomla :D

-- 
g4b0, linux user n. 369000
http://brosulo.net

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web