ush.it - a beautiful place

Truffa ai sondaggi di mambo

October 5, 2005 at 11:43 pm - Filed under Hacks, Language IT - 684 words, reading time ~2 minutes - Permalink - Comments

A dimostrazione della teoria "se puoi farlo col browser lo puo' fare anche un bot o un grabber" dimostriamo come sia semplice truccare i sondaggi di Mambo CMS, che, almeno in teoria, essendo un cms per comunita', dovrebbe limitare questo tipo di "spamming" (inteso in senso lato tutto cio' che puo' turbare il tranquillo e naturale vivere della comunita').

Il tutto si puo' realizzare comodamente tramite le curl, e in quest'esempio su un target https, che richiede piccoli accorgimenti rispetto alla semplice query http. I requisito e' disporre di curl compilate col supporto ssl.

curl -k "https://www.verona.linux.it/index.php?option=com_poll&Itemid=1" -d "voteid=25&task_button=Vota&id=16&task=vote" -b "sessioncookie=d7183c24ead150aeafd2caf4aae6d765"

Dove sessioncookie e' ottenuto navigando sulla homepage del sito che elargira' set-cookie: o direttamente dall'azione equivalente con le curl.

curl -k "https://www.verona.linux.it/" -i 2>&1 | grep "sessioncookie="

Come evitare questo genere di cose? Le metodologie sono molteplici ma un flood limit che scaturisca in un ip ban e' la piu' sicura e semplice.

Traduzione: al pari di quanto fanno molti scan detector si imposta sia un intervallo minimo di tempo che deve intercorrere tra le richieste HTTP POST, sia un limite numerico (un "tetto") di voti provenienti da un determinato ip nell'arco di un giorno.

Soluzione numero due potrebbe essere quella di bannare in maniera istantanea richieste provenienti da proxy conosciuti, con referer improbabili o nulli, con user agent tipici (es: wget, curl, etc.).

Soluzione numero tre e' quella di utilizzare un'immagine contenente un codice al momento dell'invio dei dati, questo, pur rimenendo l'unico sistema per evitare al 99,9% lo spam, e' intrusivo e non tiene conto degli utenti con problemi di accessibilita'.

Spam Karma 2 rappresenta uno dei migliori e piu' complessi plugin antispam disponibili e molte techiche utilizzate sono valide anche in questo caso.

Spam Karma 2 (SK2) is an anti-spam plugin for the WordPress blogging platform. It is meant to stop all forms of automated Blog spam effortlessly, while remaining as unobtrusive as possible to regular commenters.

In realta' non esiste un modo per evitare che una query venga effettuata se non tramite l'uso di elementi esterni non ottenibili tramite richieste o regexpr, si fa affidamento nella laggior parte delle volte all'iterazione umana nel leggere immagini, inserire password (non ottenibili da registrazioni sul sito ovviamente :P), rispondere ad email, fornire chiavi e quant'altro.

In ultima esiste un metodo di crittografia presentata da alcune banche, la traslazione delle lettere: viene generata un'immagine con sopra il normale alfabeto e sotto un suo corrispettivo traslato. Anche questo workround risulta in alcuni casi vulnerabile alla scansione OCR. Altre volte l'alfabeto traslato o la scacchiera vengono forniti su supporti fisici quali tessere o fogli. Rimane comunque vero che (a meno che non si sia utilizzata la crittografia asimmetrica) sul server esiste una controparte dei dati sufficente per rigenerare o validare la prima.

Con l'avvento delle rainbow tables bisogna perstare attenzione anche all'hashing, l'utilizzo di chiavi statiche di default e semplici append o prepend di stringhe al dato stesso non garantisce sicurezza (al massimo by obscurity). Per neutralizzare, nel peggiore dei casi temporaneamente, l'efficacia delle ranibow tables si utilizza una chiave differente per ogni sito, utente, giorno, etc.. La chiave verra pero' memorizzata da qualche parte (a meno che non sia l'utente stesso ad inserirlo, sperando che il traffico non sia loggato, il pc dell'utente ownato e con uno screenshoot taker o un keylogger) e se per qualche sfortunato motivo questa dovesse essere rubata bastera' ricalcolare la rainbow table. Avere chiavi diverse e' un disincentivo per la mole di cpu time necessaria.

Non volendo discostarmi oltre dal topic originario la storia ci dimostra (come nel caso Autistici e Inventati) che anche la crittografia asimmetrica e' vulnerabile se le chiavi sono accessibili.

Francesco 'ascii' Ongaro

THP USH Wisec DigitalBullets