[News] Il numero di cellulare è il nuovo obiettivo degli hacker: a rischio soldi e privacy

È boom di attacchi che prendono di mira i numeri di cellulari, sempre più spesso porta di accesso ai nostri dati: foto, account Facebook, conti correnti.

È boom di attacchi che prendono di mira i numeri di cellulari, sempre più spesso porta di accesso ai nostri dati: foto, account Facebook, conti correnti. L’esperto: ecco come avvengono i furti.

repubblica.it

[Articolo] La guida definitiva per verificare se un server Linux è stato violato e metterlo in sicurezza

Sospettiamo che il nostro server Linux sia stato violato? Abbiamo notato processi o attività strane? Vediamo in questo primo articolo come identificare un server Linux che è stato compromesso, e come cercare di ripristinare la situazione e chiudere fuori gli intrusi.

Difficoltà articolo (0->10): 8

Requisiti: conoscenza intermedia della shell di Linux, e hardening di un sistema.

Sospettiamo che il nostro server Linux sia stato violato? Abbiamo notato processi o attività strane? Vediamo in questo primo articolo come identificare un server Linux che è stato compromesso, e come cercare di ripristinare la situazione e chiudere fuori gli intrusi.

Partiamo dal presupposto che ad essere esposti a questo problema sono soprattutto i server che pubblicano servizi e applicazioni all’esterno (server web, ftp, …), e ancora più presi di mira sono i server messi a disposizioni dai principali provider del settore (Aruba, Register, OVH, …). I server di questi provider sono infatti presi di mira in modo massivo, e quotidianamente sono soggetti a tentativi di attacco su tutti i servizi e porte standard (ssh, http, …). Il motivo è semplice: ogni provider ha a disposizione determinati range di IP, dunque per un attaccante, chiunque esso sia (persona fisica o bot) è sufficiente eseguire degli scan e attacchi su questi range selezionati. Ad esempio, questi sono alcuni range che appartengono al noto OVH:

  • 142.4.192.0/19
  • 149.56.0.0/16
  • 158.69.0.0/16

Inoltre, preciso che buona norma per un server compromesso, sarebbe quello di radere tutto al suolo, reinstallato da zero sistema operativo e servizi. Questa pratica non è tuttavia sempre praticabile, poiché spesso sul server sono eseguiti applicativi fondamentali aziendali o per clienti, e la prima soluzione è invece quella di cercare di ripristinare il sistema ad uno stato consistente e sicuro.

Dunque, veniamo in dettaglio ai controlli da effettuare su un server che ipotizziamo essere stato compromesso.


1. Servizi in ascolto e porte aperte

Controlliamo i servizi attivi e le porte sui quali sono in ascolto:

# netstat -tulpn
# ss -nap

Devono indurre sospetto servizi in ascolto su porte non standard e soprattutto porte alte, tipicamente dalla 40000 in su, ad esempio:

# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
[...]
tcp 0 0 100.100.100.100:51553 0.0.0.0:* LISTEN 410/theerhd
[...]

Per controllare che non ci siano eventuali servizi nascosti usare poi il seguente tool:

# unhide-tcp
Unhide-tcp 20121229
Copyright © 2012 Yago Jesus & Patrick Gouin
License GPLv3+ : GNU GPL version 3 or later
http://www.unhide-forensics.info
Used options: use_fuser
[*]Starting TCP checking
[*]Starting UDP checking

Nel caso sopra, l’output è normale, nel senso che non sono stati rilevati servizi nascosti in ascolto, quindi possiamo stare tranquilli.


2. Processi attivi

Controlliamo tutti i processi in esecuzione:

# ps -ef

e l’albero dei processi attivi con relativi pid:

# pstree -pa

Il comando seguente, come nel punto precedente, può rilevare eventuali processi malevoli nascosti:

# unhide proc
# unhide sys
# unhide brute

Devono indurre sospetto eventuali processi con nomi strani (thweih43, lpevntw, 6oetheq, …), processi di cui non riconosciamo l’origine, o processi nascosti, come:

# unhide sys
[...]
Found HIDDEN PID: 256 Wchan: "[34ljyjil]"

3. Scansioni alla ricerca di malware

Installiamo il software rkhunter, per trovare eventuali trojan o malware in esecuzione.

Possiamo trovare una guida completa e ben fatta a questo link, perché la spiegazione di utilizzo del tool richiederebbe un intero articolo…


4. Ultimi accessi al sistema e utenti collegati

Facciamo un controllo sugli ultimi utenti che si sono collegati al sistema:

# last

e quali sono gli utenti attualmente collegati:

# who

Ovviamente, in questo caso dovrebbero far pensare eventuali connessioni di utenti non riconosciuti, oppure connessioni che sappiamo per certo non essere state fatte da noi.


5. Utenti attivi nel sistema

Controlliamo tutti gli utenti definiti all’interno del sistema:

# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
admin:x:1000:1000:,,,:/home/admin/:/bin/bash
[...]

Indice di sospetto dovrebbe essere la presenza di utenti nuovi non noti, o con nomi sospetti (come ad esempio l’utente admin nell’output precedente). Facciamo attenzione però, perché l’output del comando precedente può essere più o meno lungo, e può contenere anche molti utenti che potrebbero destare sospetti ma che in realtà sono utenti di sistema! Tipicamente, gli ultimi utenti ad essere stati creati sono aggiunti alla fine del file, quindi dobbiamo concentrarci su quelli.


6. Ultimi reboot del sistema

Controlliamo da quanto tempo è in esecuzione il server:

# uptime
 15:47:02 up 143 days, 12:07, 1 user, load average: 0,00, 0,00, 0,00

quando è stato fatto l’ultimo reboot:

# who -b
 system boot 2016-12-15 02:40

e il momento esatto di tutti gli ultimi reboot:

# last reboot
reboot system boot 2.6.15.4 Sun Apr 30 15:08 - 16:22 (01:13)
[...]

7. File modificati recentemente

Verifichiamo quali file sono stati modificati negli ultimi giorni (7-10 giorni):

find / -mtime -7

Facciamo attenzione che l’output del comando seguente potrebbe essere lungo e potrebbe impiegare tempo a essere visualizzato interamente. Eventualmente possiamo diminuire il numero di giorni, se si sospetta che l’attacco sia stato fatto da pochi giorni.


8. Analisi dei file di log

Esaminiamo i principali file di log (come sempre importantissimi), e in particolare i messaggi del kernel:

# dmesg

e gli ultimi log di sistema:

# cat /var/log/syslog

Controlliamo gli accessi falliti su SSH, soprattutto nel caso in cui il server sia esposto direttamente su Internet, verificando il file /var/log/auth.log in Debian e derivate, e /var/log/secure in Red Hat e derivate.

(Debian e derivate)
# cat /var/log/auth.log

(Red Hat e derivate)
# cat /var/log/secure

Potrebbe essere importante esaminare anche i log di eventuali servizi in ascolto, qualora presenti, tipo quelli dei server web (/var/log/apache/error.log e /var/log/apache/access.log per Apache, …).


9. Tool di auditing

Lanciamo un tool completo di auditing, come sysdig, seguendo le istruzioni di una delle seguenti guide:


10. Dump della memoria e analisi approfondita del sistema

Qualora nei punti precedenti avessimo rilevato la presenza reale di una minaccia, o di qualche intrusione, è bene approfondire l’analisi con tool specifici, come ad esempio volatility.

Possiamo trovare una guida ben fatta al seguente link:


11. Controllare cron e crontab

E’ importante controllare che non siano presenti script o comandi non noti schedulati all’interno del sistema tramite il servizio crond. Pertanto, è necessario verificare sia il file crontab, per tutti gli utenti di sistema, non solo per root, con il seguente comando:

# crontab -l

Il comando mostrerà eventuali comandi o script schedulati a giorni oppure ore particolari. Prestare dunque attenzione alla presenza di tutto ciò che non abbiamo apertamente configurato.

Analogamente, sarà necessario controllare all’interno di tutti gli altri percorsi usati dal demone crond, tra cui:

  • /etc/cron.d
  • /etc/cron.daily
  • /etc/cron.weekly
  • /etc/cron.monthly
  • /etc/cron.hourly

roghan

[aggiornamento 16/09/2020]

Facciamo qualche esercizio di pen testing su www.hackthissite.org – parte 1

Difficoltà articolo (0->10): 4

Girovagando in rete si possono trovare numerosi siti che permettono di mettere alla prova le proprie capacità e intuito di hacker. Alcuni esempi dei più famosi siti che possiamo trovare sono questi:

Ognuno contiene un certo numero di esercizi pratici di penetration testing, ma non solo, ci sono anche casi simil-reali, articoli, forum, curiosità… Nello specifico, ho scelto uno dei siti sopra elencati per studiarlo più a fondo, e in questo e nei prossimi articoli mostrerò come risolvere alcuni esercizi e casi di pen testing.

hacking

Il sito da me scelto è www.hackthissite.org, ma lo definirei più un portale che un sito web, perché al suo interno è possibile accedere ad una grande quantità di informazioni nonché è possibile parlare sul forum con appassionati dell’argomento.

Solo dopo essersi registrati (fornendo una password di accesso sufficientemente robusta, mi raccomando!!!) ed essersi autenticati, possiamo accedere al portale e a tutte le sue sezioni. Molte sono interessanti, ma non lasciamoci distrarre e concentriamo la nostra attenzione sulla sezione “Challanges”, e quindi “Basic missions”. Queste “missioni” sono semplici casi costruiti ad hoc in cui siamo messi difronte ad una pagina web con un form e contenente una o più vulnerabilità da trovare. Solo dopo aver trovato la vulnerabilità e la password nascosta, è possibile sbloccare il livello successivo.

Esaminiamo insieme i primi 5 livelli e le loro vulnerabilità. ATTENZIONE: di seguito mostrerò come risolvere ogni singolo caso, e dove/come trovare indizi e password per il livello successivo ma non indicherò mai le singole password (se proprio non riuscite ad accedere al livello successivo neanche ora scrivetemi pure in privato ;-)).

 

Livello 1

Descrizione: This level is what we call “The Idiot Test”, if you can’t complete it, don’t give up on learning all you can, but, don’t go begging to someone else for the answer, thats one way to get you hated/made fun of. Enter the password and you can continue.

Requisiti: HTML.

Questo è il livello base, e come indicato tra i requisiti è sufficiente avere una conoscenze davvero minima di HTML. Dunque basta visualizzare i sorgenti della pagina spostandosi al form di richiesta password, et voilà, il commento in verde conterrà la password in chiaro:

Level

Inseriamo perciò la password nel form reale della pagina e proseguiamo al secondo livello.

 

Livello 2

Descrizione: Network Security Sam set up a password protection script. He made it load the real password from an unencrypted text file and compare it to the password the user enters. However, he neglected to upload the password file…

Requisiti: buon senso.

Questo livello direi che è banale, e forse addirittura più semplice del precedente. Leggendo attentamente la descrizione è facile intuire quale sia la password, vedendo che il responsabile Sam si è dimenticato di inserire il file, con la password reale, utilizzato per fare il confronto. Se lo script della pagina dunque effettua il confronto con un file vuoto, la password sarà?!

 

Livello 3

Descrizione: This time Network Security Sam remembered to upload the password file, but there were deeper problems than that.

Requisiti: conoscenze base di HTML.

Ancora un livello molto facile, infatti basta leggere la descrizione per capire che anche questa volta la password è racchiusa in un file che viene utilizzato per fare il confronto nel form. Dunque, analizziamo il codice sorgente della pagina:

level3

Intuitivamente possiamo notare un campo input nascosto del form, che punta ad un file chiamato “password.php”. Puntiamo subito al file, per ottenere ciò che vogliamo e proseguire al livello dopo.

 

Livello 4

Descrizione: This time Sam hardcoded the password into the script. However, the password is long and complex, and Sam is often forgetful. So he wrote a script that would email his password to him automatically in case he forgot.

Requisiti: conoscenze di HTML e un indirizzo mail.

Siamo ancora nella fascia entry level per la difficoltà. Leggendo la descrizione, capiamo che ancora una volta la password è scritta all’interno dello script del sito, ma questa volta è codificata con qualche tipo di algoritmo. Quello che ci interessa è che la dichiarazione ci dice che esiste anche uno script che invia una mail all’amministratore Sam con la password, probabilmente in chiaro, e lo script viene richiamato dal pulsante analogo.

level4.1

Passando al codice sorgente:

level4

Possiamo vedere chiaramente che lo script utilizza un campo del form per l’invio della mail, e difatti il campo value contiene l’indirizzo di Sam a cui viene inviata la password. A questo punto per ottenere la password è sufficiente scaricare la pagina in locale, modificare il campo value con quello della propria mail, ricaricare la pagina locale, e richiedere l’invio della password con il pulsante ;-).

Riceveremo presto la mail con la password per proseguire di livello…

 

Livello 5

Descrizione: Sam has gotten wise to all the people who wrote their own forms to get the password. Rather than actually learn the password, he decided to make his email program a little more secure.

Requisiti: conoscenze di HTML, Javascript, e un indirizzo mail.

Da ora inizia a salire leggermente la difficoltà, perché Sam ha inserito nel proprio codice un controllo ulteriore per il form di richiesta password, similmente al caso precedente.

level5

Il codice sorgente della pagina è questo:

level5.1

In particolare non è sufficiente, come nel livello 4, la modifica dell’indirizzo mail manualmente ma bisogna ricorrere allo scripting lato client, cioè  Javascript. La tecnica che permette questo è chiamata Javascript Injection con la quale è possibile iniettare codice arbitrario lato client in una pagina in modo tale da indurre la pagina stessa a fare quello che desideriamo senza impattare direttamente il codice del server. L’inserimento di codice in una pagina può essere fatto istantaneamente dall’URL del browser.

In questo caso, poiché non possiamo appunto modificare l’indirizzo mail “a mano”, facciamo uso di JS Injection con questo comando:

javascript:void(document.forms[0].to.value="mail_address");

A ritroso, il comando permette di modificare il campo value, del form zero (il primo, appunto zero, è quello che ci interessa), del documento attuale. Dopo aver quindi dato il comando, premiamo il pulsante per la richiesta della password via mail… e abbiamo terminato anche questo livello e la prima parte della guida :-)!

Matteo

Pericolo hacker: è davvero così?

Alcuni giorni fa è stato trasmesso da Le Iene un video in cui veniva intervistato un giovane hacker, anzi nemmeno tanto giovane ;-). Anche se vi siete persi la puntata non preoccupatevi, su youtube si trova sempre tutto, eccolo. Nell’intervista l’hacker dice, e poi dimostra, quanto sia facile entrare nel pc di una qualunque persona, e dunque quanto sia facile poter rubare dati sensibili o altro ad ignari utenti. Il tipo afferma che non ha mai usato le password e i dati che ha recuperato per nessun motivo, ma sarà davvero così? Personalmente non gli credo, perché dice anche che impiega giorni se non mesi per pianificare un attacco! Quindi trascorre dei mesi a pensare ad un possibile attacco solo per puro divertimento?? Mah! Comunque, tornando allo scopo dell’articolo, il pericolo di essere attaccati è davvero così elevato come vogliono farci credere nel video? Nella realtà non è proprio così…
Per quanto riguarda i cracker, ossia gli hacker “cattivi” (che attaccano i pc e i sistemi non per divertimento o passione ma solo per scopo di lucro o peggio), si possono categorizzare in due tipologie:

* quelli che non vogliono attaccare una persona in particolare, e l’obiettivo è semplicemente attaccare qualcuno, come nel caso dei virus/worm/trojan trasmessi ad utenti sconosciuti tramite i software p2p
* quelli che invece prendono di mira una persona specifica (o un’azienda ad esempio), che conoscono, o comunque possono essere a conoscenza che questa persona ha dei dati che a loro potrebbe interessare. […]

Alcuni giorni fa è stato trasmesso da Le Iene un video in cui veniva intervistato un giovane hacker, anzi nemmeno tanto giovane ;-). Anche se vi siete persi la puntata non preoccupatevi, su youtube si trova sempre tutto, eccolo. Nell’intervista l’hacker dice, e poi dimostra, quanto sia facile entrare nel pc di una qualunque persona, e dunque quanto sia facile poter rubare dati sensibili o altro ad ignari utenti. Il tipo afferma che non ha mai usato le password e i dati che ha recuperato per nessun motivo, ma sarà davvero così? Personalmente non gli credo, perché dice anche che impiega giorni se non mesi per pianificare un attacco! Quindi trascorre dei mesi a pensare ad un possibile attacco solo per puro divertimento?? Mah! Comunque, tornando allo scopo dell’articolo, il pericolo di essere attaccati è davvero così elevato come vogliono farci credere nel video? Nella realtà non è proprio così…

Per quanto riguarda i cracker, ossia gli hacker “cattivi” (che attaccano i pc e i sistemi non per divertimento o passione ma solo per scopo di lucro o peggio), si possono categorizzare in due tipologie:

  • quelli che non vogliono attaccare una persona in particolare, e l’obiettivo è semplicemente attaccare qualcuno, come nel caso dei virus/worm/trojan trasmessi ad utenti sconosciuti tramite i software p2p
  • quelli che invece prendono di mira una persona specifica (o un’azienda ad esempio), che conoscono, o comunque possono essere a conoscenza che questa persona ha dei dati che a loro potrebbe interessare.

Rientrano nella prima categoria quasi unicamente gli attacchi definiti phishing, quando il cracker X invia una mail all’utente contenente un link ad un sito fasullo, o quando la mail contiene un allegato che in realtà è un virus o un trojan. Questo tipo di cracker non conosce solitamente molte informazioni sulla vittima, e quindi la pericolosità dell’attacco sta tutta nella mail! Per quanto riguarda invece il secondo gruppo di cracker, la situazione è ben diversa. In questo caso l’attaccante ha più informazioni sulla vittima, o si trova fisicamente vicino (ad esempio un vicino di casa che vuole crakkare il router wireless, o in luoghi pubblici con un accesso wifi libero), e il metodo di attacco può anche essere diverso dal semplice phishing, anzi quasi sicuramente.

Dopo questa breve spiegazione sui possibili hacker “cattivi”, vediamo se e quando bisogna preoccuparci e come possiamo proteggerci! Tornando ancora al primo gruppo di cracker, possiamo proteggerci da essi con un minimo di accortezza:

  1. installare un firewall sul proprio pc (a meno che non abbiate un router ADSL, che generalmente incorpora e ha attivo un firewall)
  2. avere un antivirus aggiornato (non importa avere una suite super costosa, ma è sufficiente anche un antivirus freeware)
  3. aggiornare costantemente il proprio sistema operativo (che sia Windows, Linux, Mac, o altro)
  4. fare attenzione alle mail ricevute. Disabilitare sempre la visualizzazione delle mail in formato HTML, e visualizzare in semplice modalità testuale in modo da evitare il caricamento di eventuali script nascosti. Non dobbiamo mai rispondere a mail sospette, e soprattutto non aprirne gli allegati!
  5. non dobbiamo visitare siti potenzialmente dannosi, come ad esempio siti warez/crack, contenenti codici seriali o materiale pirata in generale, o a volte anche fasulli siti di gruppi hacker
  6. attenzione anche a ciò che si scarica tramite software p2p.

Seguendo questi accorgimenti le possibilità di subire un attacco sono prossime allo zero. Diversa è la situazione nel caso in cui un utente sia preso di mira da un cracker, che è fisicamente vicino alla vittima nel caso di connessioni wireless, oppure quando conosce ad esempio il suo indirizzo IP. In questo caso non esiste difesa sicura, e dipende tutto dal livello di abilità dell’attaccante nel portare a termine un attacco diretto! Firewall e antivirus non servono a molto purtroppo :-(… Per un maggiore approfondimento su ciò, consiglio di leggere l’intervista a Joanna Rutkowska, esperta di sicurezza informatica, al seguente link:

Contro i veri hacker non c’è firewall che tenga

Concludendo, il numero di attacchi maggiormente diffusi viene effettuato da cracker appartenenti al primo gruppo (a volte semplici ragazzini, in gergo definiti script-kiddies), mentre sono molto rari quelli relativi al secondo gruppo, diciamo 10 a 1. Dunque possiamo tutti dormire sonni tranquilli e non c’è da preoccuparsi per quello che hanno detto a Le Iene se seguiamo gli accorgimenti scritti su, e ricordiamo… La miglior difesa siamo sempre e solo noi stessi!

Vi consiglio anche di leggere la guida che ho scritto:

Come proteggere la privacy in Rete

roghan

%d blogger hanno fatto clic su Mi Piace per questo: