Più di 7500 router MikroTik compromessi inoltrano traffico verso gli attaccanti

La società di sicurezza Qihoo 360 Netlab ha scoperto che 7500 router MikroTik sono stati attaccati attraverso gli strumenti carpiti alla Central Intelligence Agency nel corso del Vault7 dump, nello specifico tramite CIA Vault7 Chimay Red, un tool che consente di sfruttare due vulnerabilità note, una su Winbox (CVE-2018-14847) e una su Webfig legata all’esecuzione di codice in modalità remota. Sia Winbox che Webfig sono componenti di gestione RouterOS, il sistema operativo proprietario della MikroTik, una società lettone fondata nel 1996 e che oggi vende in tutto il mondo hardware e software per la gestione della connettività Internet.
 
I ricercatori Qihoo 360 Netlab, sapendo che i due tools di gestione, Winbox (applicazione GUI di Windows) e Webfig (applicazione web based) utilizzano le porte TCP 8291, 80 e 8080, sono riusciti ad analizzare il fenomeno già da metà luglio attraverso l’uso di Honeypot. Dall’analisi sono risultate alcune attività malevoli, come l’iniezione di codice mining di CoinHive. Inoltre è stato osservato un numero enorme di vittime con il proxy Socks4 abilitato. 
MikroTik_distribution
L’attacco prevede tre scenari
  • Scenario 1: Iniezione di codice Mining CoinHive
Una volta abilitato il proxy HTTP di Mikrotik RouterOS, gli hacker riescono a reindirizzare tutte le richieste del proxy HTTP a una pagina locale di errore HTTP 403 e a iniettare in essa un collegamento contenente il codice di web mining di Coinhive. In questo modo, l’utente malintenzionato prova ad eseguire il mining web sui dispositivi degli utenti attraverso il traffico che passa dal proxy. Purtroppo per l’hacker, l’attacco non funziona in quanto tutte le risorse web esterne, incluse quelle di coinhive.com, sono bloccate dagli ACL dei proxy impostati dagli stessi attaccati.
  • Scenario 2: Abilitazione maliziosa di Sock4 Proxy
Attualmente 239K dispositivi presentano la porta Socks4 (TCP/4153) abilitata maliziosamente e dalla configurazione del proxy consente l’accesso solo dalla seguente classe di Ip: 95.154.216.128/25. Affinché l’attaccante possa ottenere il controllo anche dopo il riavvio del dispositivo, il router viene configurato per eseguire un’attività pianificata che segnala periodicamente il suo ultimo indirizzo IP accedendo alla URL di un utente malevolo. L’attaccante sfrutta questo proxy Socks4 compromesso anche per eseguire la scansione di altri dispositivi MikroTik RouterOS. Tutti i 239K IPs potrebbero quindi fornire l’accesso a 95.154.216.128/25 e soprattutto a 95.154.216.167.
  • Scenario 3: Intercettazioni 
Il dispositivo MikroTik RouterOS consente agli utenti di acquisire pacchetti sul router e inoltrare il traffico di rete catturato ad un server Stream specificato. Attualmente i 7500 IP associati ai dispositivi MikroTik RouterOS sono stati compromessi dall’attaccante e il loro traffico viene dirottato ad alcuni indirizzi IP malevoli (uno di questi è il 37.1.207.114). Le porte interessate dagli attacchi sono  le 20, 21, 25, 110 e 143, corrispondenti al traffico dati FTP, FTP, SMTP, POP3 e IMAP. Inoltre sono coinvolte anche le porte SNMP 161 e 162. Non è ancora chiaro perché l’attaccante presti attenzione anche al protocollo di gestione della rete, visto che è usato pochissimo dagli utenti standard.
Raccomando a tutti gli utenti Mikrotik di aggiornare quanto prima la versione del RouterOS tramite la funzione di aggiornamento che trovate in Winbox e di seguire le linee guida per mettere in sicurezza i dispositivi disponibili a questa pagina Manual:Securing Your Router.
Articolo tratto da: CERT-PA

Google Chrome 69 e la nuova interfaccia grafica

In informatica gli aggiornamenti dei programmi portano con se sempre novità e funzioni interessanti ma purtroppo troppo spesso l’interfaccia grafica va nella direzione inversa, a volte sembra che le nuove versioni siano più vecchie di quelle precedenti!!!

Anche Google con la versione 69 di Chrome non fa eccezione, se cercate un pò su internet vi accorgerete che sono molte le lamentele alla nuova interfaccia grafica un pò troppo fumettosa e con problemi di aliasing dei font.

Oltretutto lo spazio tra le icone nell toolbar è aumentato ancora rispetto alla v68 che già era stato aumentato rispetto alla versione precedente.

Questa è la nuova interfaccia di Chrome:

Chrome v69

Personalmente preferivo la vecchia e fortunatamente tramite la modifica di un flag è possibile riaverla, basta visualizzare la pagina dei flag scrivendo nella barra degli indirizzi

chrome://flags/

e cercare il flag

UI Layout for the browser’s top chrome

che dovrebbe essere settato sul valore Default, modificatelo in Normal e riavviate Chrome, dovreste riavere la “vecchia” interfaccia:

Chrome v68

Configurare un Mikrotik come un server OpenVPN

Da qualche tempo ho convertito tutte le VPN che usavo per la gestione dei clienti in OpenVPN, diventato oramai uno standard, al posto delle vecchie PPTP oramai non più sufficientemente sicure e così avendo quasi sempre un Mikrotik presso i clienti ho deciso di riassumere i passaggi per la configurazione in questo post.

Tutta la configurazione viene fatta direttamente nel Mikrotik, compresa la generazione dei certificati, quindi dopo esserci collegati con il Winbox possiamo iniziare.

Mi raccomando di sostituire gli indirizzi IP, gli utenti e le password con i vostri dati.

Per prima cosa creiamo una CA, firmiamo il relativo certificato ed esportiamolo:

/certificate
add name=CA common-name=CA key-usage=key-cert-sign,crl-sign days-valid=3600
sign CA ca-crl-host=192.168.0.1 name=CA
export-certificate CA

In questo modo all’interno della sezione File ci ritroveremo con il file cert_export_CA.crt.

Ora che abbiamo generato la CA possiamo generare il certificato per il nostro Mikrotik, quindi scriviamo:

/certificate
add name=Mikrotik common-name=mikrotik days-valid=3600
sign Mikrotik ca=CA name=mikrotik

A questo punto se tutto è andato a buon fine dovremmo ritrovarci con i due certificati appena generati:

Certificates

Ora dobbiamo creare un pool per l’assegnazione degli indirizzi IP ai client:

/ip pool add name=ovpn-pool range=192.168.131.10-192.168.131.200

Qui la scelta della classe è arbitraria, l’importante è che non sia una classe esistente in LAN.

Creaiamo poi il profilo per la connessione, definendo il nome, l’ip da usare per il mikrotik e il relativo pool di indirizzi:

/ppp profile add name=ovpn local-address=192.168.131.1 remote-address=ovpn-pool

Ora creiamo un utente abilitato a connettersi in OpenVPN:

/ppp secret add name=vpn_user password=qystQMf9TxhlVrq9vE00 profile=ovpn service=ovpn

E infine attiviamo il server OpenVPN:

/interface ovpn-server server set enabled=yes certificate=mikrotik auth=sha1 cipher=aes256 port=1194 netmask=24 require-client-certificate=no mode=ip default-profile=ovpn

A questo punto la configurazione lato Mikrotik è terminata, non ci rimane altro da fare che creare i due file di configurazione da usare sul client.

Lato client abbiamo bisogno di due file:

  • Nome_connessione.ovpn
  • auth.cfg

Nel file auth.cfg dobbiamo inserire due due righe diverse l’utente e la password che abbiamo impostato nel Mikrotik, quindi nel nostro caso conterrà queste due linee:

vpn_user
qystQMf9TxhlVrq9vE00

Il file Nome_connessione.ovpn invece conterrà questo:

proto tcp-client
remote <nome_o_indirizzo_pubblico_del_Mikrotik> 1194
dev tun
script-security 2

nobind
persist-key

tls-client
verb 1

cipher AES-256-CBC
auth SHA1
pull

auth-user-pass auth.cfg
route 192.168.0.0 255.255.255.0
dhcp-option DOMAIN dominio.local
dhcp-option DNS 192.168.0.20

<ca>
..
</ca>

Nel file dovrete mettere i vostri dati:

  • Nome o indirizzo pubblico del Mikrotik
  • La classe di IP che usate internamente per creare automaticamente una rotta
  • Il nome del dominio locale e l’IP del server DNS interno se volete risolvere i nomi
  • Nella sezione <ca></ca> dovrete incollare il contenuto del file cert_export_CA.crt che abbiamo esportato nelle fasi iniziali

Una volta effettuati queste modifiche potrete stabilire una connessione OpenVPN verso il vostro Mikrotik senza nessun problema.

Se il Mikrotik non ha un IP pubblico ma si trova dietro un NAT non dovrete far altro che nattare sul router a monte la porta TCP 1194.

 

Windows Search: Problema indicizzazione

Recentemente mi è capitato che in un File Server basato su Windows Server 2012 R12 l’indicizzazione non funzionasse più correttamente, l’indicizzazione veniva riportata come completa senza errore ma in realtà una buona parte dei file non era indicizzata.

Indexing Options

Cercando nella documentazione Microsoft ho trovato la risposta al problema, come riportato in questa pagina:

Windows Search doesn’t support Data Deduplication. Data Deduplication uses reparse points, which Windows Search can’t index, so Windows Search skips all deduplicated files, excluding them from the index. As a result, search results might be incomplete for deduplicated volumes.

In pratica succede che tutti i file oggetto di deduplica non possono essere indicizzati!!! Quidi delle due l’una o si usa la deduplica o si usa l’indicizzazione.

Nel mio caso ho dovuto disabilitare la deduplica nel volume interessato e dopo aver eseguito un rebuild da zero dell’indice tutto è tornato a funzionare correttamente.

 

Questa è la storia di quattro persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno.

C’era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto.

Ciascuno avrebbe potuto farlo, ma Nessuno lo fece.

Qualcuno si arrabbiò perché era un lavoro di Ognuno.

Ognuno pensò che Ciascuno poteva farlo, ma Nessuno capì che Ognuno non l’avrebbe fatto.

Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.