BUG Area Riservata di website 9 accesso a pagine riservate - (risolto)

[serzio]

Come dal titolo, per avvisare TUTTI gli utenti di website x5 8 e 9 che le loro aree riservate, se usate, possono essere facilmente bucate con due righe .... facciamo tre ..... di codice.

Per evo8: <QUI>

Per evo9: <QUI>  -- link rimosso, il problema è stato risolto a partire dalla build 1918 --

PS. Per ovvi motivi, lo script è abilitato a funzionare solo sugli esempi autorizzati dal sottoscritto e comunque previa registrazione dell'indirizzo IP del visitatore.

[serzio]

Naturalmente qualcuno ha incoscientemente deciso di non rendere visibile nel consueto elenco cronologico il topic sull'answers ... http://answers.websitex5.com/post/32657 ... oltre ad avergli snaturato il nome del topic rendendolo un post insignificante a fronte del rischio enorme per gli utenti. Mi aspettavo un comportamento maggiormente responsabile.

Sono talmente arrabbiato che ho deciso, per ora, di liberalizzare lo script per testare se il proprio sito web è affetto dal problema, tenendo ben presente che:

• esiste un log di utilizzo con IP, data, ora e sito web testato

• chi lo utilizza, lo fa sotto la propria responsabilità ed accetta la raccolta dei dati al punto precedente
  

La sintassi da utilizzare, con la parte in rosso da personalizzare, è:

www.serzio.it/x5test.php?url=www.miosito.xx/paginaprotetta.php

Seguirà la spiegazione sul come ottenere questo risultato .... che è comunque già ottenibile con il solo studio di un po' di php ed un pizzico di intuito.

[edit] Ho corretto il link a cui mancava il .php dopo il nome dello script, scusate.

[calfasoft]

Mah, non ho ben capito però se l'effrazione avviene sulla pagina di login (nota) oppure su una delle pagine interne, che potrebbero quindi non essere note.
In ogni caso sarei curioso di testarlo su uno dei miei siti, tanto non c'è poi mica nulla di così segreto :-) quindi vediamo un po' se funziona : [size=78%]http://www.alfas.it/lab/imlogin.php[/size] (evo9)

[boschetti.mirko]

Pazzesco...non trovando più il Post di Serzio, ho provato a metterne uno io, con la domanda di come mai fosse cambiato il titolo, e fosse nascosto dalla lista, ma ora non appare neanche il mio....Blacklist per il nome Serzio???

[boschetti.mirko]

Trovato... lo hanno messo privato di colpo qui:    http://answers.websitex5.com/post/32678   

[calfasoft]

Post PrivatoI motivi per cui questa discussione è stata impostata come privata possono essere i seguenti:L'autore ha deciso, in un secondo momento, di renderla privata.La discussione contiene informazioni riservate e Incomedia ha ritenuto opportuna renderla privata.Il messaggio ha ricevuto una segnalazione di Abuso (off-topic, contenuto, ecc.)[/font][/i]

[boschetti.mirko]

Oppure l'autore sà troppo... 

[serzio]

Mah, non ho ben capito però se l'effrazione avviene sulla pagina di login (nota) oppure su una delle pagine interne, che potrebbero quindi non essere note.
In ogni caso sarei curioso di testarlo su uno dei miei siti, tanto non c'è poi mica nulla di così segreto :-) quindi vediamo un po' se funziona : [size=78%]http://www.alfas.it/lab/imlogin.php[/size] (evo9)

Il problema si verifica sulle pagine protette, non su quella di login. Viene semplicemente aggirata la procedura di login e quindi, conoscendo il nome della pagina protetta, vi si accede senza passare dalla validazione. Non escludo ulteriori sviluppi, appena ho tempo, cerco di fare qualche test in più.

Ho liberato dalle restrizioni lo script che ora è utilizzabile da chiunque, anche se con le stesse premesse.

[lemonsong]

Non so in quanti la usino ancora ma lo script buca anche le aree riservate della versione 7

[calfasoft]

Ok, in effetti vedo che fornendo il nome della pagina protetta bypassa la protezione.
Da una rapida analisi del file di lock mi pare di capire che non fai altro che passargli delle variabili di sessione caricate ad hoc, infatti Evo controlla se sono già caricate e quindi lo inganni, giusto ?
Cmq, come sul mio sito, le pagine protette sono invisibili nel menù, quindi qualche difficoltà in più indubbiamente la si può anche trovare :-)
Ritengo in ogni caso molto utile questo tuo spunto di pseudo hakeraggio, in quanto se non si conoscono i buchi, non si sa nemmeno di dover mettere delle toppe !!
Buon lavoro e buona giornata (qui si soffoca!)
ciao

[lemonsong]

Cmq, come sul mio sito, le pagine protette sono invisibili nel menù, quindi qualche difficoltà in più indubbiamente la si può anche trovare :-)

Questo: www.alfas.it/lab/

Se sì, metti una toppa perché se vai sul menu Area Utenti vedi il nome della pagina protetta.
Inoltre chi conosce il programma da http://www.alfas.it/lab/imsitemap.html riesce a trovarla (suppongo se non nascosta).

Se no... come non detto (una toppa però la metterei lo stesso a quel sito).

[serzio]

Non ho avuto il tempo per studiare a fondo il problema, purtroppo in questo periodo ho degli orari massacranti e soltanto qualche ora libera nel fine settimana. Come dicevo, si è trattato solo di una intuizione mentre "spiavo" la funzione imcheckaccess nel file x5engine.php.
Vediamo se riesco a spiegare "a grandi linee" il concetto principale che ha permesso questo mezzo hacking ... giocattolo ... tre righe di codice in tutto.
Mi sono accorto che la verifica dei dati di login funziona così: se dati mancanti manda su imlogin (il redirect viene fatto con l'header), se dati errati visualizza errore e manda su login (ancora header), altrimenti prosegui nella visualizzazione della pagina riservata.
Il problema è che anche dopo l'header location, l'esecuzione di uno script prosegue, se non viene bloccato in qualche modo e continua ad inviare output, mentre il comando header viene inviato in output al browser e causa il redirect.
Se in qualche modo, qualsiasi cosa io inserisca come nome e password, riesco ad intercettare il comando header e bloccarlo, l'esecuzione del webserver intanto è proseguita ma la finestra del browser non esegue il redirect e quindi riceve ancora i dati sul canale aperto, dati che rappresentano la pagina protetta.
Come posso fare a bloccare l'header location? Beh, il curl me lo permette e quindi il gioco è fatto. Rimarrebbe qualche altro dettaglio, ma è già sufficiente così.

La soluzione ... beh, è stata promessa a breve anche per la versione 8 e quindi non rimane che aspettare ..... oppure vedere se stesil vuole fornirne una sua in anteprima.

[serzio]

Per chi volesse cimentarsi per proprio conto, è sufficiente editare la pagina riservata ed inserire in if-then che interroghi le variabili di sessione inizializzate dalla funzione imcheckaccess() e dia esplicitamente un exit() nel caso in cui la validazione non ci sia stata (piuttosto che lasciare l'esecuzione a se stessa, come adesso).

[calfasoft]

Beh, direi che la cura ha funzionato.
Ovviamente ringrazio chi si è sbattuto x scoprire il bug e x averne divulgato la soluzione.
In effetti è una stupidata, ma bisognava arrivarci ! 
complimenti vivissimi, e spero che incomedia vi dica almeno grazie
fabio

[serzio]

Beh, direi che la cura ha funzionato.
Ovviamente ringrazio chi si è sbattuto x scoprire il bug e x averne divulgato la soluzione.
In effetti è una stupidata, ma bisognava arrivarci ! 
complimenti vivissimi, e spero che incomedia vi dica almeno grazie
fabio

Nessun ringraziamento, a parte quelli di qualche nostro utente. Mi sono inoltre guadagnato sul campo una discreta collezione di post censurati (di cui ho gli screenshot) e l'inserimento in una specie di "limbo" in cui vanno a finire tutti i miei topic di nuova apertura e che non ne permette la visualizzazione a tutti gli utenti. Unica ben magra soddisfazione, la risposta ad un ticket su aruba in cui c'e' anche un LINK al nostro lavoro.  ... ma va bene così ...