Archivi Tag: firewall


Purtroppo, dopo lo scherzetto che ci ha combinato la Fortinet qualche mese fa (FortiGuard Update – Failed Reboot Condition – get_backdoor_timeout) radendo al suolo migliaia di apparati rilasciando un pacchetto di firme IPS, oggi da ancora prova di accuratezza e precisione nella definizione delle sue firme IPS e di grande capacità e coordinamento del suo supporto.

Circa un mese fa abbiamo aperto una chiamata al supporto Fortinet dedicato ai partner perche’ le firme che definiscono gli attacchi “POP3.Login.Failed” e “POP3.Brute.Force.Login” non rispondevano come ci saremmo aspettati.

Attivando il logging dei pacchetti ci siamo accorti che la firma “POP3.Login.Failed” intercetta anche tutta un’altra serie di stringhe che nulla hanno a che fare con un tentativo di accesso non riuscito. La firma in questione infatti intercetta a priori qualsiasi risposta proveniente dal server POP3 che contenga la stringa “-ERR“, stringa che pero’ viene restituita anche in altri casi, non solo in quelli di accesso non riuscito.

Questo e’ uno dei log rilevati sul nostro apparato:

itime=1324656057 dtime=1324659657 dstname=213.205.33.10 device_id=FGT80C3909642149 log_id=16384 subtype=signature type=ips timestamp=1324656057 pri=alert policyid=17 serial=11837806 attack_id=109248518 severity=info carrier_ep=N/A profile=N/A sensor=IPS_WINDOWS_+ src=172.16.31.32 dst=213.205.33.10 src_port=54387 dst_port=110 src_int=internal2 dst_int=wan2 status=detected proto=6 service=pop3 user=ospite group=WIFI_GUEST_local ref=http://www.fortinet.com/ids/VID109248518 count=1 incident_serialno=433376215 msg=”pop3_decoder: POP3.Login.Failed” vd=root identidx=0 profiletype=N/A profilegroup=N/A attack_name=N/A

Andando a guardare i pacchetti che sono passati ci siamo accorti pero’ che non era affatto un tentativo di login fallito ma un generico messaggio di errore rilasciato dal server:

-ERR [SYS/TEMP] mailbox locked by other server

Cosi’ come in altre occasioni e’ stata intercettata e catalogata come  “POP3.Login.Failed” la stringa “-ERR Command is  not valid in this state” o “-ERR Unknown command.“.

E’ indubbio che ogni tanto vengano intercettati anche dei tentativi di login falliti la cui risposta del server tipicamente e’: “ERR Logon failure: unknown user name or bad password“, oppure “-ERR Authentication Failure.“, oppure “-ERR Authentication failed.“, oppure “-ERR Logon Unknown.“.

Sono proprio tutti questi “oppure” che creano un bel problema in effetti perche’ a seconda del sistema verso il quale si tenta l’autenticazione POP3, la risposta potrebbe essere diversa. In effetti l’unico pattern comune tra tutte le risposte sembra essere la stringa “-ERR”, ma basare la firma su questa stringa genera una quantità di falsi positivi da renderla del tutto inutile.

Da alcune risposte fornite dal supporto tecnico e’ probabile infatti che la firma per il “POP3.Login.Failed” sia qualcosa di molto simile a questo:

F-SBID( –name “POP3.Login.Failed”; –protocol tcp; –src_port 110; –flow from_server,reversed; –seq <,200,relative; –pattern “|2D|ERR “; –within 5,packet;)

 

Un ulteriore problema che abbiamo riscontrato e’ proprio sulla firma “POP3.Brute.Force.Login“.
L’idea che avevamo avuto era quella di proteggere i sistemi facendo in modo che il Fortigate riconoscesse i cosi’ detti “attacchi a forza bruta” perpetrati sui protocolli tipicamente piu’ esposti quali POP3, IMAP, SMTP ed FTP.
Nel set standard di firme IPS Fortinet risultano presenti infatti anche le firme per gli attacchi:

Riconoscere degli attacchi che si sostanziano in ripetuti tentativi di login con username e password predefiniti puo’ mettere parzialmente a riparo da problemi legati alle password deboli o eccessivamente ovvie ed evitare che qualcuno posso scoprire delle credenziali di accesso in maniera relativamente semplice. Il motore IPS dei Fortigate permette inoltre, una volta intercettato un attacco, di mettere in “quarantena” l’ip dal quale proviene per evitare ulteriori tentativi ed altre tipologie di connessioni.

Attivate le firme “Brute.Force.Login”, la sorpresa l’abbiamo avuta quando nei log abbiamo riscontrato migliaia di tentativi di accesso sul protocollo POP3 passati indisturbati attraverso il Fortigate senza che si accorgesse di nulla e facesse scattare le azioni legate alla firma “POP3.Brute.Force.Login” (“block” e “quarantine”). Di questo abbiamo chiesto spiegazione al supporto tecnico e la prima risposta che abbiamo ricevuto e’ stata:

After researching and the help of the IPS analyst team, it appears that the POP3.Brute.Force.Login is rate limited with 200 requests per 10 seconds. By counting the traffic logs from the fortianalyzer, it appears that the attackers rate was 120 pop3 sessions requests per 10 seconds and 138 POP3.Login.Failed attempts. It is expected the POP3.Brute.Force.Login was not triggered this time.

Sostanzialmente l’attacco non aveva avuto una magnitudo tale da allertare il Fortigate. Un attacco del tipo “POP3.Brute.Force.Login” deve avere almeno 200 richieste in 10 secondi (alias 20 richieste al secondo o 1.200 al minuto) per essere “notato”.  Personalmente lo ritengo un valore interessante perche’ se ipotizziamo un attacco che faccia anche “solo” 10 richieste al secondo (alias 600 al minuto) ma che perduri per 8 ore fanno quasi 300.000 tentativi senza che il motore IPS del Fortigate se ne accorga e quindi metta in quarantena l’IP da cui proviene l’attacco.  300.000 tentativi possono ritenersi un attacco a forza bruta? Credo di si…

Abbiamo chiesto a questo punto al supporto come poter abbassare il “rate” dei tentativi per il “POP3.Brute.Force.Login” e la risposta che ci hanno dato, e che in effetti ci aspettavamo, e’ stata quella di creare una firma personalizzata sui nostri parametri e ci hanno inviato in un primo momento questa:

F-SBID(–name POP3.BruteForce; –protocol tcp; –service POP3; –flow from_server; –pattern “USER”; –rate 50, 60; –track src_ip; )

poi, dopo qualche minuto, questa:

F-SBID(–service POP3; –flow from_server,reversed; –pattern “|2D|ERR “; –context header; –within 100,context; –track dst_ip; –rate 50,60; –description “Failed login to POP3 server 50 times in 60 seconds”; )

perche’ ovviamente il pattern “USER” avrebbe generato molti falsi positivi. Inutile dire che anche il pattern “-ERR“, come per la firma “POP3.Login.failed“, genera molti falsi positivi.

Successivamente ci siamo accorti che, anche attraverso la firma inviata dal supporto Fortinet, l’attacco “brute-force” non veniva comunque riconosciuto e l’ip attaccante non veniva messo in quarantena. A seguito di questa segnalazione il supporto Fortinet ci ha mandato un’altra firma:

 F-SBID( –name “POP3.Brute.Force.Login.Port110”; –protocol tcp; –src_port 110; –flow from_server,reversed; –seq <,200,relative; –pattern “|2D|ERR “; –within 5,packet; –track dst_ip; –rate 50,60; –description “Failed login to POP3 server 50 times in 60 seconds”; )

ma anche in questo caso, testando la firma con Brutus, l’ip attaccante non veniva messo in quarantena. Fatto di nuovo presente al supporto il problema ci hanno consigliato di abbassare il “rate” a 10,60 ovvero a 10 tentativi falliti per ogni 60 secondi. In questo caso pero’ gli utenti regolarmente loggati venivano messi in quarantena perche’ veniva intercettata piu’ volte durante la sessione POP3 la stringa “-ERR Unknown command.” (pare succeda di frequente con i server di posta di Aruba.it con Thunderbird come client di posta). Inutile dire che gli utenti validi venivano fermati ma Brutus continuava tranquillamente a poter portare avanti indisturbato un attacco.
Ricontattato il supporto Fortinet, ci mandano l’ennesima firma in cui il pattern risulta piu’ specifico per il server che deve essere protetto. Questa firma comunque non e’ valida in termini assoluti per tutti i server perche’ a seconda del server POP3 utilizzato, in caso di login errato, si puo’ ottenere una risposta diversa:

F-SBID( –name “POP3.Brute.Force.Login.Port110”; –protocol tcp; –src_port 110; –flow from_server,reversed; –seq <,200,relative; –pattern “|2D|ERR Logon failure“; –no_case; –within 20,packet; –track dst_ip; –rate 10,60; )

In ogni caso, niente anche questa volta, l’attacco viene fermato e l’ip attaccante messo in quarantena sono dopo alcuni minuti che l’attacco e’ in corso e solo dopo migliaia di tentativi portati a segno, non certo solo dopo i 10 previsti dal “rate” della firma.

Il problema sembra essere che il Fortigate riconosce l’attacco ma non esegue in drop di tutte le connessioni attive ma banalmente si limita a non consentirne l’apertura di nuove da parte dell’ip attaccante. Questo vuol dire che se il server attaccato non chiude la connessione dopo un certo numero di tentativi di autenticazione falliti  l’attaccante puo’ continuare a fare tutti i tentativi di accesso che vuole senza che il Fortigate intervenga. Nuove sessioni non potranno essere instaurate ma su quelle gia’ aperte l’attacco continua indisturbato.

Dear Customer,

I agree with you that it is reasonable to drop all old sessions from an banned IP. I will contact associate departments to find a possible solution. But I don’t think it will be available in a short time. As i suggested, please change more action to reset so ideally all identified attack sessions will be closed. Thanks for your patient.

Regards

Fortinet IPS

Fortinet “custom” POP3.Brute.Force.Attack – IPS Sensor Configuration

Ultimo suggerimento del supporto e’ stato quindi di impostare l’azione di default della firma da “block” a “reset” per arrivare quindi a questa configurazione del “Custom override” dell’ “IPS Sensor” applicato al protocollo POP3.

Sembrerebbe che dopo quasi un mese di mail con il supporto Fortinet forse siamo arrivati ad una conclusione della vicenda se non fosse per il fatto che durante un attacco “Brute.Force.Login” l’IPS Engine del Fortigate usa il 100% della CPU rendendo praticamente impossibili le comunicazioni attraverso il firewall. Come a dire: se non riesco a portare a termine con successo un attacco “brute-force”, almeno riesco a crearti un DoS perche’ l’apparato non regge il suo stesso motore IPS.

Ometto la quantità di problemi similari, e non, rilevati sulle altre firme “Brute.Force.Login”. In ogni modo questa sembra essere la configurazione piu’ stabile ed efficace per gli attacchi a forza bruta da utilizzare sugli apparati Fortigate.

 A questo punto non resta che rimanere in attesa di un miglioramento degli apparati e dei tempi e delle modalità di risposta del supporto tecnico.

Auguri!

 

Quelli della Fortinet ce ne hanno combinata un’altra. Hanno rilasciato delle firme per l’IPS che, di fatto, rendono inutilizzabili i Fortigate corrompendo la memoria interna al punto tale che e’ necessario riformattarla e ripristinare sia il firmware, sia la configurazione.

Negli ultimi tre giorni ci sono saltati tre apparati differenti, su tre clienti differenti, e abbiamo perso non meno di tre giorni di lavoro per ripristinare tutto, giorni di cui manderemo presto il conto a Fortinet. Pur essendo partner Fortinet, di sicuro ci penseremo bene la prossima prima di comprare degli altri apparati perché non e’ la prima volta che ci troviamo in condizioni di emergenza per problemi simili dovuti a bug del firmware o a signatures con problemi e dati i margini economici nei quali ci si muove, in particolare nel mercato small & medium business, il gioco non vale la candela se gli apparati (e servizi) hanno un elevato (sufficiente) indice di difettosità.

In ogni modo, di seguito l’output della console di uno degli apparati affetti dal problema, più sotto il bollettino rilasciato dal supporto tecnico (volendo anche l’originale in PDF ) ed in ultimo la nota tecnica inviataci “Loading FortiGate firmware image using TFTP


 

FGT50B-DEAD_DEVICE #

Please stand by while rebootig

FGT50B (14:15-10.01.2008)

Ver:04000010
Serial number:FGT50B3G09123456
RAM activation
Total RAM: 256MB
Enabling cache...Done.
Scanning PCI bus...Done.
Allocating PCI resources...Done.
Enabling PCI resources...Done.
Zeroing IRQ settings...Done.
Verifying PIRQ tables...Done.
Enabling Interrupts...Done.
Boot up, boot device capacity: 64MB.
Press any key to display configuration menu...
......

Reading boot image 1319595 bytes.
Initializing firewall...
System is started.
pid-28 lock_mlog()-504 shmget()failed: No such file or directory
pid-28 lock_mlog()-504 shmget()failed: No such file or directory
pid-28 lock_mlog()-504 shmget()failed: No such file or directory

__get_backdoor_timeout: Couldn't get shm
__set_backdoor_timeout: Couldn't get shm

FGT50B-DEAD_DEVICE login: pid-28 lock_mlog()-504 shmget()failed: No such file or directory
pid-28 lock_mlog()-504 shmget()failed: No such file or directory
pid-28 lock_mlog()-504 shmget()failed: No such file or directory
pid-28 lock_mlog()-504 shmget()failed: No such file or directory

FGT50B-DEAD_DEVICE login:

FGT50B-DEAD_DEVICE login: pid-28 lock_mlog()-504 shmget()failed: No such file or directory
FGT50B-DEAD_DEVICE login: pid-28 lock_mlog()-504 shmget()failed: No such file or directory

FGT50B-DEAD_DEVICE login: admin
Password: ********
__admindb_get_copy: Couldn't get admindb
__admindb_get_copy: Couldn't get admindb
Welcome !

FGT50B-DEAD_DEVICE # pid-28 lock_mlog()-504 shmget()failed: No such file or directory

 


Number: CSB-110610-1
Released: 10 June 2011
Modified: N/A
Subject: FortiGuard Update – Failed Reboot Condition
Product: FortiGate
Description:

 

A FortiGate may fail to restart correctly after a power cycle or a software reboot if a FortiGuard update of either the IPS engine and its signatures or the AV engine and its signatures has been performed. After the update has successfully completed and a subsequent reboot is carried out, the FortiGate device may hang and traffic may not traverse through it, the following output may be seen on the console port:

__get_backdoor_timeout: Couldn’t get shm
__set_backdoor_timeout: Couldn’t get shm
__admindb_get_copy: Couldn’t get admindb

 

Affected Products:

FortiGate devices running FortiOS v4.0 MR1 Patch Release 1 through to Patch Release 9, inclusive.
Check if the version of IPS engine and signature that is loaded on the FortiGate:

 

FortiGate# get sys fortiguard-service status

 

NAME VERSION LAST UPDATE METHOD EXPIRE

 

AV Engine 3.013 13/08/2009 15.44 manual 03/01/2012 0.00
Virus Definitions 13.309 10/06/2011 4.31 manual 03/01/2012 0.00
Extended set 0.000 01/01/2003 0.00 manual 03/01/2012 0.00
Attack Definitions 3.012 10/06/2011 4.31 manual 03/01/2012 0.00
IPS Attack Engine 1.230 10/06/2011 4.33 manual 03/01/2012 0.00

If FortiGate is running one of the affected firmware versions listed above, the IPS engine is version 1.230 AND the attack definitions are version 3.012 the device may be susceptible to this issue

Resolution:

To prevent the issue , update the IPS attack definition to version 3.013. This can be retrieved from the FortiGuard network by performing an update on the IPS definitions.

Using the GUI interface : System > Maintenance > FortiGuard > IPS definitions – Update

Then verify the attack definition file has been updated to 3.013:

 

FortiGate# get sys fortiguard-service status

 

NAME VERSION LAST UPDATE METHOD EXPIRE

 

AV Engine 3.013 13/08/2009 15.44 manual 03/01/2012 0.00
Virus Definitions 13.309 10/06/2011 4.31 manual 03/01/2012 0.00
Extended set 0.000 01/01/2003 0.00 manual 03/01/2012 0.00
Attack Definitions 3.013 10/06/2011 4.35 manual 03/01/2012 0.00
IPS Attack Engine 1.230 10/06/2011 4.33 manual 03/01/2012 0.00

Patch Release 10, v4.0, MR1 is scheduled for release on June 16th, 2011 to correct the FortiOS corruption of shared memory issue.

If the FortiGate has been rebooted and is already in the hung state, recovery can be achieved by reloading the firmware image via a TFTP reload.

For an emergency fix, customers are required to contact Fortinet Customer Support to request an interim build of firmware with the correction applie.

 

 

LogMeIn Rescue addresses common security concerns as follows:

  • There is no need to open any extra ports on your corporate or personal firewall, as all communications between the technician and the customer’s computer make use of the standard web protocol (HTTP).
  • An encrypted connection is established between technician and customer using established Internet protocols (256-bit SSL).
  • Support sessions are initiated by the customer: a technician cannot examine a customer’s computer without being invited to do so by the customer.
  • Once the support session has ended, all access rights to access the customer’s computer are removed.
  • Sessions can be recorded to provide a trail of a technician’s actions.
  • Nothing is permanently installed on the customer’s computer. A small Applet is downloaded when the session starts and is removed when the session ends. The only exception to this is if the Calling Card Applet is installed onto the customer’s computer. In this case, the Applet remains on the machine, but it is the customer who initiates support sessions by launching the Calling Card

LogMeIn Rescue and other LogMeIn products (LogMeIn free, LogMeIn Pro) use the following IP ranges over SSL:

  • 74.201.74.1 – 74.201.75.254 (74.201.74.0/23)
  • 216.52.233.1 – 216.52.233.254 (216.52.233.0/24)
  • 69.25.20.1 – 69.25.21.254 (69.25.20.1/23)
  • 64.94.18.1 – 64.94.18.254 (64.94.18.1/24)
  • 77.242.192.1 – 77.242.193.254 (77.242.192.1/23)
  • 212.118.234.0 – 212.118.234.254 (212.118.234.0/24)
  • 64.74.103.0 – 64.74.103.254 (64.74.103.0/24)
  • 64.94.46.0 – 64.94.47.254 (64.94.46.0/23)

Note:
These ranges are for all LogMeIn products. Also, they are subject to change without notice.

 

Powered by WordPress &Web Design Company - Modified by Lorenz