About these ads


Posts Tagged ‘Night Dragon’

Five Years of Hacking (Updated)

August 3, 2011 8 comments

Strange Days for Information Security, you may watch my July 2011 Attacks Chart for noticing how troubled July has been. August promises to be even worse, but this is not the point…

The point is that in an Interview to Vanity Fair, which is not tipically an Information Security Magazine, Dmitri Alperovitch, Vice President of threat research at McAfee reported that, for at least five years, a high-level hacking campaign, dubbed Operation Shady RAT (like Remote Access Tool), has infiltrated the computer systems of national governments, global corporations, nonprofits, and other organizations. This infiltration has made more than 70 victims in 14 countries for what has been defined “Biggest-ever series of cyber attacks uncovered”, an attack so big that, according to Alperovitch: “It’s been really hard to watch the news of this Anonymous and LulzSec stuff, because most of what they do, defacing Web sites and running denial-of-service attacks, is not serious. It’s really just nuisance.”

Victims included government agencies in the United States, Taiwan, South Korea, Vietnam, and Canada, the Olympic committees in three countries, and the International Olympic Committee. Rounding out the list of countries where Shady rat hacked into computer networks: Japan, Switzerland, the United Kingdom, Indonesia, Denmark, Singapore, Hong Kong, Germany, and India. The vast majority of victims—49—were U.S.-based companies, government agencies, and nonprofits. The category most heavily targeted was defense contractors—13 in all.

Courtesy Of McAfee

In addition to the International Olympic Committee, the only other victims that McAfee has publicly named are the World Anti-doping Agency, the United Nations, and ASEAN, the Association of Southeast Asian Nations (whose members are Indonesia, Malaysia, the Philippines, Singapore, Thailand, Brunei, Burma, Cambodia, Laos, and Vietnam).

All the signs of the attack point to China. If confirmed this would be the third attack discovered by McAfee originating from China, after Operation Aurora and the Night Dragon.

One thing is clear: if Vanity Fair is dealing with Information Security, there is really something strange. At least let us hope this is not the sign Information Security is simply becoming a matter of fasion.

Meanwhile, after the Vanity Fair preview, McAfee has released its report on Shady RAT. McAfee was able to gain access to one specific Command & Control server used by the intruders, collecting logs that reveal the full extent of the victim population since mid-2006 when the log collection began. The results are described inside the documents and Curiously China, which was reported by the press as the alleged author of the attack, is never expressely quoted.

Courtesy Of McAfee

Interesting to say, this report raised several doubts on McAfee Competitors. As an example, Sophos, on a dedicated post, considers that there’s nothing particularly surprising in McAfee’s report since companies get often targeted by hackers, who install malware to gain remote access to their computers and data, sometimes driven by motivations for hacking which extend beyond purely financial (for instance, IP theft, economic, political, etc motivations).

Moreover, Sophos wonders why McAfee did not disclose what kind of information was stolen from the targeted organisations, and how many computers at each business were affected.

In any case I noticed with pleasure that, like I did, Sophos was also surprised from the fact the preview was first released on Vanity Fair…

About these ads

What do RSA, Epsilon and Sony breaches have in common?

You need to give people information and transparency so that they can understand security. It’s essential to make them a part of the security process and ensure they are aware of the company security policy.

These words were told yesterday, may, the 4th 2011 on Barcelona during the Check Point Experience, by Gil Shwed, the founder and Chairman of the Information Security Vendor, for unleashing the 3D Security model of the company, a model which focuses on policy people and enforcement.

No better moment could be found for emphasizing the role of the user inside the information security process!

The dramatic events of RSA, Epsilon and Sony Data Breach are redefining the information (in)security landscape and consequently rising many questions and concerns among the security professionals for the true extent of the events. RSA tokens, whose seeds were allegedly compromised during the breach are used in more than 25.000 corporations all over the Globe. The Epsilon Data Breach involved 2% of customers: for a company which sends out over 40 billion e-mails a year on behalf of over 2,500 clients, this means millions of individuals at risk and needing to be on alert from scams and phishing for years. Last but not least Sony, for which a total of more than 100 million records were stolen during two separate waves of attack on its PlayStation Network and Qriocity Service.

Now the question is: what do Mr. Shwed’s words deal with the latter events?

Well, (too) many words have been spent so far: recalling the security concerns for cloud based services (mostly in case of Epsilon and Sony) and the role of Advanced Persistent Threats which are becoming an harmful attack vectors for Enterprises, using spear-phishing mail to overwhelm the first line of defence made by the employees. Apparently old school techniques under renewed dresses. Nevertheless there is a point which, in my opinion, has not been adequately emphasized so far, and the point is just the answer to the previous question.

Simply said the uncovered point is the role of the people in the (in)security process which led to the breach. Hopefully this is not exactly the kind of role wished by Mr. Swhed, anyway if we reverse the paradigm, the result is exactly the same: on one hand, if it is true that the individual made aware of the policy enforces the first level of security and is the core of the security process itself, it is also tue that the unaware individual is the core of the breach. This is exactly what happened in the affair of RSA and Epsilon where the people, the first line of defense of any organization, was the first line to be breached, well before the systems, and the breach in the people was the trigger for the breach in the systems as well.

RSA clearly explained this occurrence in a blog post, and the appealing subject “2011 Recruitment Plan” of the phishing e-mail, hiding a zero-day Adobe Flash vulnerability (CVE-2011-0609) embedded into an excel spreadsheet, went into the annals of Information Security. Clearly the poisoned spreadsheet injected a RAT (Remote Access Tool) used to gain privileges and move freely into the network up to the final target.

Things were not so different for Epsilon, in which individual company employees were initially targeted for email scams and used to gain access to the internal database as happened.

So far there is not evidence of a similar occurrence for Sony, however  today’s Sony’s Response to the U.S. House of Representatives, written by Kazuo Hirai, Chairman of the Board of Directors of Sony Computer Entertainment America, in response to questions posed by the subcommittee members of the House Commerce Committee, in some steps closely resembles original RSA announcement.

Sony has been the victim of a very carefully planned, very professional, highly sophisticated criminal cyber attack.

And in case of RSA:

Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA.

(Not too much) curiosly the two steps are very similar, and likely the adjective sophisticated was used to emphasize an external origin of the attack aimed to exclude an internal fault and the presumable consequent fall of shares), nevertheless I could not help joining the two sentences and, presumably the two events, even if so far Sony did not show the same transparency of RSA and only few details are known.

Ultimately these events (to which I should add the Night Dragon malware), show that the new cyber-attacks are targeting users, and employees inside the Organization. Not only they targeted users to achieve the attack, but also the aftermaths will keep on targeting users for years: as a matter of facts, even if the full consequences of the RSA breach are not completely clear so far, PSN and epsilon users will presumably be the targets of a new wave of spear-phishing and spam emails (so far no news have been reported of a fraudulent use of Credit Cards Number stolen, which, according to Sony, were encrypted).

In all the cases, quoting Mr. Shwed’s words, we deduce the need for the user to be the core of the security process. The security process must shift to a level which involves policy definition, people awareness and, policy enforcement, at the device level, through an appropriate configuration, and most of all at the user level, through an appropriate education.

Some Random Thoughts On RSA Breach

April 10, 2011 15 comments
Security tokens from RSA Security designed as ...

Image via Wikipedia

June 7 Update: RSA admits some stolen seeds were used to attack Lockeed Martin and will replace SecurID tokens for customers with concentrated user bases typically focused on protecting intellectual property and corporate networks.

May 31 Update: Wired reports that L-3, a Second Defense Contractor, has been targeted by an attack using information stolen during the RSA Breach

May 28 Update: Other Random Thoughts after Several Sources reported that Lockeed Martin the “largest U. S. Defense contractor” was presumably hit by an alleged attack led by mean of compromised seeds.

Some days have passed since the RSA breach, but the echo has not yet gone. Maybe RSA did not contribute efficiently to suppress rumors as, in the meantime, has continued to issue ambiguous advices to its customers, and, more in general to the infosec community. Only few days ago a post from the Company has explained some more details about the breach. According to the above mentioned post written by Uri Rivner, RSA Head of New Technologies, the breach was due to an APT (Advanced Persistent Threat) exploiting a zero-day Adobe Flash vulnerability (CVE-2011-0609) embedded into an excel spreadsheet attached to an email from an appealing subject “2011 Recruitment Plan”. The poisoned file injected a RAT (Remote Access Tool) used by the attackers to gain privileges and move freely into the network up to the final target.

Curiously, the subject was so appealing to convince some users to recover it from the quarantine folder: to lure victims through pecuniary topics is a consolidated method of cyber scam at all levels, and RSA has not made exception in this circumstance.

This attack deserves much attention from the infosec community as we are used to think to multi-layer protection technologies but too often forget that the individuals are the first (and weakest) layer of defense, hence also the best technology, even that from a primary manufacturer as RSA is, risks to be very little useful, or even useless, if not supported by an adequate education of users. Phishing is considered an old attack method, mainly used in the past to lure individuals. Today its combination with 0-day vulnerabilities is proving to be a devastating weapon for Cybercrime targeting enterprises. (It is not a combination that also the Night Dragon Attack, maybe amplified by McAfee Marketing in response to the attention gained by its eternal competitor Symantec for the role played in the identification of Stuxnet, was initiated by a some phishing emails). Is this the reason why, on April the 1st, RSA decided to acquire NetWitness, a company whose technology, as stated in the press release:

provide precise and pervasive network visibility, enabling security teams to detect and remediate advanced threats while automating the incident investigation process.

Without invoking philosophical considerations, the main question is: are secureID users really safe or do they need to worry about their level of security after the breach?

My opinion is that the RSA breach was conceived as the final stage of a large scale attack to a wide organization making use of RSA tokens, since in most cases (we should hope in all cases), the alleged stolen information, alone, is not enough to perpetrate a successful attack unless the RSA breach was not preceded by other attacks perpetrated by the same author(s) aimed to steal the missing piece of the puzzle.

Taking a step back, on March, the 17th when the breach was announced, the open letter on the RSA web site, stated that:

Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

Of course the “potentially be used to reduce the effectiveness” sounds a little bit ambiguous. Anyway a subsequent bulletin for RSA customers was released on March, the 21th 2010, stating that:

RSA SecurID technology continues to be a very effective authentication solution. Whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers.

Said in few words according to the Company, the stolen information, alone, may not be used to perform a successful attack. Even if the RSA algorithm (in its post-2003 implementation using AES hash with 128 bit ECB blocks) is not public, RSA statements sound true since some quantities used in the hash are neither related to the 128 bit random seed nor to the 64 bit standard ISO representation of Current Time: they are a 32-bit token-specific salt (supposedly the serial number of the token, which may have been subtracted in the breach, and a 32 bits padding). Today this quantities are not used for security purposes, but simply to shape the blocks to 128 bits as requested by AES hash (enjoy the math of AES hash algorithm at this link).

Courtesy of Wikipedia

Of course, together with the PIN known only by the user, there is, in theory, enough stuff to make an attack unsuccessful in case a (organized) gang of cybercrooks come in possess of the database mapping a SecurID token with its seed. But unfortunately, as often happens, reality is much worse than theory, so one discovers that someone reversed the RSA algorithm and developed Cain & Abel, which, by mean of an RSA SecurID Token Calculator is able to retrieve the One Time Password from an RSA token, provided the malicious user owns the file contained in the RSA Authentication Server (mapping the token serial number with the seed) and knows the User PIN. Small “negligible” detail: from version 4.9.10 (released in 2007), Cain & Abel supports AES-128 of post-2003 securID implementation.

So at the end, supposed the information stolen from RSA is comparable, or could be brought in some manner to be comparable (in form and content) with that contained in each RSA Authentication Server (and it should be since each RSA token must be synchronized with its own authentication server), Cain & Abel (or a similar tool) could be applied to successfully obtain the password for each token whose seed was stolen, provided the attacker come somehow in possess of the only missing information: the user PIN.

There are several ways to steal a user PIN, from Social Engineering to sniffing. Often social engineering leverages the shallowness of the user or the lack of policies of the organization (yes… In my life I have also seen some SecurID tokens with attached a post-it containing the PIN). Of course when I mention sniffing I do not mean network sniffing since both in case of an organization adopting SecurID tokens either in native ACE mode or RADIUS mode, the PIN is never transmitted in clear, anyway we have not to forget that many organizations adopt software tokens (also in mobile devices), so one might not exclude a priori that a large scale attack had deserved the development and the deployment  of a Trojan tailored to steal PIN from RSA software tokens.

This is the reason why I expect that the target of the attackers was not RSA but an important organization making use of RSA securID authenticators. As a consequence I would not be surprised if a malicious tool to sniff PINs from RSA Software authenticators were discovered.

Seeds on the Black Market?

If I fly with my imagination I do not feel to completely exclude that the stolen information one day could be available in the black market to target other major organizations besides the presumed original victim: in fact do not forget that Banks worldwide are among the bigger customers of RSA). This is the reason why, RSA users should take in serious consideration the recommendations provided by the Company the day after the breach.

Personal Note 1

The Italian Security Professional group on Linkedin dedicated an interesting post to the RSA affaire (in Italian) which is continuously updated as new information is released. Today the last controversial advice: it looks like RSA will provide hack data in exchange of customer secrecy (thanks to Andrea Zapparoli Manzoni for reporting this information). This advise comes in the same day in which I discovered a further controversial article (actually dating back to a couple of weeks ago) reporting a possible (unconfirmed) backdoor in the SecurID tokens requested by the NSA in exchange of the authorization to export the technology…  Very strange the temporal proximity with the breach, as much strange the fact that this information is passed nearly unnoticed…

Personal Note 2

I must confess I was really intrigued on better understanding how the SecureID algorithm works for understanding which is the missing part “to make the successful attack complete” (to use the same words in the RSA bulletin).

Since, as already mentioned, the RSA algorithm is not public (even if the first version pre-2003 was reversed in 2000) I only may perform some kind of speculations. In these days I searched all the possible documentation and probably in this link I found a scenario which might be quite close to reality. Please notice that what follows is a mere speculation.

Since the beginning of 2003, SecurID performs an AES hash operation, in standard ECB mode, to hash

  • a 128-bit token-specific true-random seed;
  • a 64-bit standard ISO representation of Current Time in the following format: year/month/day/hour/min/second;
  • a 32-bit token-specific salt (the serial number of the token);
  • another 32 bits of padding, which can be adapted for new functions or additional defensive layers in the future.

The latter two are not a specific security feature but are needed since the AES-Hash operation needs 128 bit multiples. The 64 bit standard ISO representation is derived from a 32-bit representation of the current time (GMT) in seconds since midnight on 01/01/86, from which, only 22 bits are used from the original value, leaving 222 or 4,194,304 total possible time values. These inputs, conflated and hashed by the AES, generate the series of 6-8 digit (or alphanumeric) token-codes that are continuously displayed on the SecurID’s LCD as a “one-time password.” Rolled over every 30 or 60 seconds. In order to implement a pure two factor authentication, the user must insert a known PIN in order to complete the authentication process (but this is configured by the administrator).

Will Energy Facilities Be The Next Targets Of Cyber-War?

April 3, 2011 6 comments

I spent some time in reading the declarations of Comodo Hacker, the alleged author of the fake Certificates issued by mean of the compromising of a couple of (sigh!) Italian Comodo Partners, and I found some very interesting points far beyond the single event.

Actually, it had been clear from the beginning that the attack had been performed from an Iranian ISP, feeding the hypothesis of an Iranian Cyber Army action aimed to intercept emails from dissidents in a quite troubled moment from the Middle East after the winds of change blowing from the Maghreb.

Anyway Comodo Hacker was anxious to quickly put the record straight, declaring he was the only author of the attack, and, if one just wanted to involve an army on the event, had to consider that he was the only army, being able to rely on his own experience of 1000 programmers, 1000 project managers, 1000 hackers:

Now, even if the political connotation of the message still makes me think that behind this act there might be a real cyber army (but this is my personal opinion), this is not the real point. The real point is that this attack occurred as a kind of revenge against Stuxnet, and more in general the fact, supported by Comodo Hacker, that the U.S. and Israel where behind it.

Fight fire with fire, fight code with code…

The attack to Comodo Certificates has left a wide impact in the INFOSEC world and probably things will not be the same anymore since in few days  all the strongholds, the identity security model relied on, have been miserably compromised (I took the liberty to add the RSA affaire to this event even if there is no evidence so far of a political matrix behind it). But there is another interesting point, and it is the third law of motion (you will not probably know I was a physic in my previous life) which, with not too much imagination, could be applied to infosec as well, if one considers the events that are happening: “the mutual forces of action and reaction between two bodies are equal, opposite and collinear”, which, in few and simple words should sound as: “to every cber-action corresponds an equal and opposite cyber-reaction”. If this is true, this means to me, as an infosec professional, that we will have to get used to similar cyber actions. Also from this point of view things will not be the same anymore…

Armed with this awareness, my mind runs inevitably among the dunes of the Libyan desert, where a civil war is being fought, now sadly familiar to all. Let me fly (but not too much) with my imagination and think that the Civil War will end up with the exile of Mr. Muammar Gaddafi. In this case it is likely to expect that he will find his revenge, not only with real terrorists act, but also with (cyber)terrorist acts, in the wake of the Comodo affaire, which, even if related to Iran, is the first known example of a cyber-terrorist act strictly related not only to the Stuxnet attack, but also to the movements flooding from Maghreb to Middle East, what I called the Mobile Warfare due to the primary role played by the mobile technologies inside these events.

We don’t have privacy in internet, we don’t have security in digital world, just wait and see… These lines can be considered as a kind of Declaration of Cyber-war against everything…

Targets of Cyberwar

Nowadays everything has a stream of bit inside and as a matter of fact is vulnerable to malware. What is happening in Libya (and the consequences on our energy bills), together with the risk of nuclear meltdown in Fukushima is pushing the so called Western world to reconsider its energy policy and accelerate the development of Smart Grids in order to promote a better, wiser use of energy. In these circumstances compromising an energy facility would have a huge practical and symbolic impact (do you remember the Night Dragon APT, tailored specifically for Oil Facilities?), that is the reason why, in my opinion, the first targets of this Cyber-terrorism reaction will be energy utilities. Few weeks ago I wrote an article (in Italian) concerning vulnerabilities and security of Smart Grids, which can be considered the “world of unknown” from a security perspective since they adopt an Internet open model to interconnect old legacy SCADA systems and, to make matters worse, the structures that govern the IT world and the SCADA world have a silo-ed approach being often mutually suspicious against each other. As a dark omen, few days later, a list of 34 0-day SCADA vulnerabilities was released by Luigi Auriemma, an Italian Researcher.

Think about it: compromising a smart grid with a SCADA malware could have potentially devastating consequences and should sound as a kind of dark revenge: imagine an Iranian SCADA malware sabotaging the energy facilities of U.S., and more in general the facilities the Western World is building to cut the umbilical cord that ties him strictly to the Middle East countries (that often are also the hottest as far as the political temperature is concerned).

Moreover, the development of electric vehicles will further complicate the scenario since they will be able to interconnect Directly to Home Area Networks (the borderline of Smart Grids), offering an unexpected (and probably not so complicated) ingress point for Cyber-Terrorists to Smart Grids, if it is true that nowadays a small car owns 30-50 ECU (Electronic Control Units) interconnected by a bidirectional Synchronous bus and governed by something like 100 millions of lines of codes. My dear friend and colleague, ICT Security expert and Aviation Guru, David Cenciotti will be glad to know that an F-22 Raptor owns about one tenth of lines of codes (“only” 1.7 millions), the F-35 Joint Strike Fighter about 5.7 millions and Boeing 787 Dreamliner about 6.5 millions used to manage avionics and on-board systems. Of course one may not exclude a priori that these systems may be target as well of specific tailored malware (do you remember the intrepid Jeff Goldbum injecting on the mother ship of Aliens on Independence Day?)

Prepare ourselves for a Smart Grid Stuxnet? I think there is enough to be worried about for the next years…

Violati i Server RSA

Stamattina mi sono svegliato con una di quelle notizie la cui eco rimbomberà per un bel pezzo nell’arena Infosec. Il blog di Sophos riporta difatti che la nota azienda di sicurezza RSA, specializzata in sistemi di autenticazione forte (in pratica da lei inventati) è stata vittima di un attacco informatico che ha portato alla sottrazione di alcune importanti informazioni.

La notizia è stata comunicata da RSA stessa mediante uno stringato comunicato sul proprio sito. Sebbene l’Azienda sia riuscita a rilevare l’attacco e abbia da subito rafforzato le misure di sicurezza, purtroppo non ha potuto impedire la sottrazione di preziose informazioni dai propri server tra cui alcune relative al sistema di autenticazione forte OTP a due fattori, RSA Secure-ID, che da anni costituisce la soluzione ammiraglia della Casa (che di fatto ha inventato l’omonimo algoritmo di crittografia asimmetrica). Chi di noi non ha mai utilizzato almeno una volta il piccolo quadrante con i numerini magici che cambiano ogni 10 secondi?

I dettagli dell’attacco non sono noti: RSA ha dichiarato di essere stata vittima di un extremely sophisticated cyber attack, ma sembra che alla base ci sia comunque un Advanced Persistent Threat, un attacco quindi estremamente sofisticato, portato su molti livelli e, probabilmente, avente l’utente come punto di ingresso (a questo link una ottima definizione della tipologia di attacco).

Come accennato in precedenza, il lato peggiore della vicenda risiede nel fatto che sembra siano state rubate anche alcune informazioni relative alla soluzione di autenticazione a due fattori. Allo stato attuale non ci sono notizie di possibili attacchi ai danni dei clienti (RSA produce la maggioranza dei token OTP presenti sul mercato utilizzati per gli usi più variegati: dalle transazioni bancarie all’accesso remoto di operatori), tuttavia:

this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack.

Ovvero i dati sottratti potrebbero essere utilizzati per mitigare l’efficacia dell’attuale sistema di autenticazione a due fattori all’interno di un attacco di più ampio respiro.

RSA fornirà presto ai propri clienti alcune raccomandazioni per rendere più sicura la propria infrastruttura di autenticazione a due fattori, nel frattempo, in collaborazione con la U.S. Securities and Exchange Commission ha pubblicato le seguenti raccomandazioni:

  • Aumentare il livello di sicurezza relativamente alle applicazioni di social media e all’utilizzo delle stesse (e di eventuali altri siti web) a chiunque abbia accesso a porzioni di reti critiche;
  • Utilizzare password complesse, corredate da PIN;
  • Utilizzare la regola del least privilege nell’assegnare ruoli e responsabilità agli amministratori di sicurezza (qualsiasi amministratore deve accedere al livello minimo di informazione indispensabile per effettuare la propria attività);
  • Educare gli utenti all’importanza di evitare mail sospette e ricordare loro di non fornire nomi utente o altre credenziali a nessuno senza averne prima verificato identità e autorità. Non fornire mai credenziali in seguito a richieste effettuate tramite mail o telefono e denunciare subito questi comportamenti;
  • Porre attenzione alla protezione dei repository Active Directory, utilizzando tecnologie SIEM (Security Information & Event Management) e autenticazione a due fattori per l’accesso agli stessi repository;
  • Monitorare attentamente i cambiamenti dei privilegi utente e relativi diritti di accesso utilizzando tecnologie di monitoraggio (ad esempio il già citato SIEM) e considerando l’aggiunta di livelli di approvazione manuale per questi cambiamenti;
  • Effettuare l’hardening, il monitoraggio attivo, e contestualmente limitare l’accesso fisico alle infrastrutture che ospitano informazioni critiche;
  • Esaminare le procedure dell’help desk alla ricerca di eventuali brecce di informazioni che possano implicitamente aiutare un attaccante ad effettuare un attacco di tipo social engineering;
  • Aggiornare sempre tutta l’infrastruttura di sicurezza ed i sistemi operativi con le ultime patch di sicurezza.

Ancora una volta nel corso del 2011 l’equazione APT=furto di informazioni si rivela tristemente vincente ed efficace. Non sono ancora trapelati dettagli sull’attacco ma, dall’analisi delle raccomandazioni fornite, si delineano alcuni tratti comuni: la “compromissione” dell’utente come punto di ingresso per la compromissione dell’infrastruttura. D’altronde se si analizzano le raccomandazioni fornite e le si confrontano con la morfologia dell’attacco Night Dragon, non trovate che siano perfettamente coincidenti con le vulnerabilità umane e tecnologiche sfruttate in quel contesto?

Parigi val bene una messa (In Sicurezza)

A conferma delle previsioni dei produttori di sicurezza sembra proprio che dovremo abituarci, nel corso di questo 2011, ad attacchi informatici con matrice politica. Ultima vittima illustre in ordine di tempo il Ministero Del Tesoro Francese  vittima, a Dicembre 2010, di un attacco che ha portato alla sottrazione di documenti economici e finanziari inerenti la presidenza francese di turno del G20 ed altre questioni economiche.

Nel periodo in questione, secondo il quotidiano d’Oltralpe Paris Match che ha rivelato la vicenda, più di 150 computer appartenenti al Ministero dell’Economia Francese sono stati vittima di intrusioni malevole che hanno portato alla sottrazione illecita di numerosi documenti.

Le indagini condotte successivamente hanno rivelato che i file rubati sono stati inviati verso alcuni server cinesi. Già di per sé la questione sembrerebbe alquanto sospetta considerando il fatto che tra i temi discussi durante la presidenza francese del G20 c’era anche l’annosa questione dei rapporti economici tra la Cina e il resto del mondo.

Indipendentemente dalla cautela riguardo la presunta origine dell’attacco, ci sono due aspetti che mi hanno particolarmente colpito in questa vicenda: il primo è la presunta matrice politica dell’attacco. Il secondo, ancora più curioso, e per certi versi sconcertante, è il fatto che in questo attacco ho trovato molti aspetti in comune con il caso di Night Dragon, il malware con velleità energetiche concepito con lo scopo di sottrarre piani di progetto ed economici, relativi a raffinerie e centrali energetiche oil & gas. Questi aspetti prefigurano il modello di attacco di cui sentiremo parlare molto nel 2011 e sono relativi al fatto che il malware è riuscito a far breccia nella linea Maginot delle difese informatiche francesi, nel modo più ingenuo possibile, ovvero mediante un Trojan inviato via mail. Una volta eseguito, il malware è stato in grado di creare una porta di servizio backdoor, mediante la quale i gli attaccanti sono entrati all’interno dei computer vittima e presumibilmente nei server che ospitavano le informazioni sensibili.

Il punto nodale della questione risiede proprio in questo secondo aspetto. In questo attacco, come nel caso di Night Dragon, gli attaccanti hanno utilizzato come punto di ingresso un metodo piuttosto tradizionale, ovvero un trojan ricevuto via mail, strumento questo principalmente utilizzato, nella precedente era informatica, più per scopi personali (ad esempio rubare le credenziali di acesso al conto bancario), che politici. In effetti, le previsioni di sicurezza per il 2011 prevedevano il furto delle informazioni come uno dei principali refrain di questo 2011 cyber-informatico, eventualmente mediante l’utilizzo di quello che è stato definito lo Spyware 2.0, ovvero spyware rimodulato per scopi ben più ampi del semplice furto di informazioni personali.

Il DLP è sicuramente una tecnologia che può esesere a supporto per la prevenzione di eventi analoghi. Ad ogni modo, e non mi stancherò mai di dirlo, l’utente rimane al centro del processo di sicurezza, pertanto non dovrebbe mai dimenticare le conseguenze, a volte non immediate e inimmaginabili, di un comportamento superficiale, soprattutto in concomitanza di eventi simili.

Report Cisco 4Q 2010: Il Malware Web ha fatto il Bot(net)

February 20, 2011 Leave a comment

Dopo i turni di McAfee e Symantec è la volta di Cisco: il gigante dei router e della sicurezza perimetrale ha da poco pubblicato il proprio Cisco 4Q10 Global Threat Report che riflette i trend della sicurezza su scala globale da ottobre a dicembre 2010.

Il report Cisco si differenzia leggermente dai documenti precedentemente citati poiché proviene da un produttore di sicurezza focalizzato su soluzioni di rete, e si basa inoltre su dati di traffico raccolti dalla propria rete di sensori di Intrusion Prevention (IPS), di dispositivi di sicurezza IronPort per la posta e per il traffico Web, dai propri servizi di gestione remota Remote Management Services (RMS), ed infine dai porpri servizi di sicurezza basati sul Cloud ScanSafe.

Picco di Malware in Ottobre

Gli utenti Enterprise in media hanno registrato, nel periodo in esame, 135 impatti di nuovo malware al mese, con un picco di 250 eventi al mese in ottobre, mese che ha visto anche il più elevato numero di host intercettati ospitanti web malware  che si è attestato a 16.905. In totale nel periodo sono stati rilevati 38.811 eventi web risultanti, in totale, a 127.622 URL.

Il traffico correlato ai motori di ricerca si è attestato a circa l’8% del web malware con la maggior percentuale, pari al 3.84%, proeveniente da Google, in notevole calo rispetto al 7% della stessaa tipologia di traffico rilevata nel terzo quarto. Il traffico di tipo webmail si è invece attestato all’1%.

Il malware Gumblar (caratterizzato del redirigere le ricerche) ha compromesso in media il 2% delle ricerche nel periodo Q4 2010,  anche in questo caso in netto calo rispetto al picco del 17% raggiunto a maggio 2010.

Per quanto concerne gli exploit applicativi, Java l’ha fatta da padrone: la creatura di SUN Oracle ha sbaragliato la concorrenza, posizionandosi al 6.5%, una percentuale quasi quattro volte maggiore rispetto alle vulnerabilità inerenti i file PDF.

I settori verticali più a rischio sono risultati essere il Farmaceutico, Il Chimico, e il settore dell’energia (gas and oil), probabilmente per quest’ultimo ha contribuito anche il malware Night Dragon.

Attività delle BotNET

Le analisi rese possibili dai dati raccolti mediante i sensori IPS e i servizi gestiti hanno consentito di tracciare le attività delle botnet nel periodo preso in esame. I dati hanno evidenziato un leggero aumento del traffico generato dalle Botnet, soprattutto per quanto riguarda Rustock, la rete di macchine compromesse più diffusa, che ha avuto un picco notevole al termine dell’anno.

Per quanto riguarda le signature di attacco maggiormente rilevate, al primo posto spiccano le “Iniezioni SQL” (Generic SQL Injection), a conferma del fatto, indicato da molti produttori, che nel 2011 le vulnerabilità tradizionali verrano utilizzate in modo più strutturato per scopi più ampi (furto di informazioni, hactivisim, etc.).

Interessante notare che ancora nel 2011 sono stati rilevati residuati virali quali Conficker, MyDoom e Slammer. Per contro, a detta del produttore di San Francisco, i virus di tipo più vecchio quali infezioni dei settori di boot e file DOS, sarebbero in via di estinzione (ironia della sorte era appena uscito il report ed è stata rilevata una nuova infezione informatica diretta al Master Boot Record che ha sollevato una certa attenzione nell’ambiente).

Interessante anche l’impatto degli eventi mondiali sulla qualità e quantità del traffico: la rete di sensori Cisco ha difatti rilevato un picco di traffico peer-to-peer (in particolare BitTorrent) nell’ultima parte dell’anno coincidente, temporalmente, con la rivelazione dei “segreti” di Wikilieaks che ha portato gli utenti, viste le misure di arginamento tentate dalle autorità statunitensi, a ricercare vie parallele per avere mano ai documenti.

Meno Spam per tutti!

I produttori di sicurezza raramente vanno d’accordo tra loro, tuttavia, nel caso dello Spam, le indicazioni del gigante di San Jose sono in sostanziale accordo con quelle di McAfee. Il quarto trimestre del 2010 ha registrato un calo considerevole delle mail indesiderate, verosimilmente imputabile alle operazioni di pulizia su vasta scala compiute all’inizio dell’anno passato nei confronti delle grndi botnet: Lethic, Waledac, Mariposa e Zeus; e più avanti nel corso del medesimo anno nei confronti di Pushdo, Bredolab e Koobface.

Report Symantec Q4 2010: Fate Presto… Prima che la sicurezza SCADA!

February 16, 2011 1 comment

Symantec è particolarmente attiva in questo scorcio del 2011, così, dopo la pubblicazione del Dossier Stuxnet aggiornato, ha appena rivelato alla comunità di sicurezza il Symantec Intelligence Quarterly Report: October – December, 2010 che è interessante analizzare, notando, come questo si discosti notevolmente dall’analogo report recentemente pubblicato dalla livrea rossa di McAfee, principale concorrente del produttore di sicurezza di Cupertino.

Il titolo del report è tutto un programma: “Targeted Attacks on Critical Infrastructures” e riassume quelle che sono state le caratteristiche, dal punto di vista della sicurezza, di questo fine 2010: i cybercriminali si sono concentrati sulla creazione di malware targeted (ovvero ritagliato su misura) per danneggiare infrastrutture critiche.

Gli attacchi cosiddetti targeted sono perpetrati verso una specifica organizzazione o una specifica categoria di utenti e per questo sono notevolmente pericolosi ed efficaci, anche se usano tecniche tradizionali come phishing o link malevoli, essendo ritagliati su misura per l’infrastruttura obiettivo o anche per le abitudini o caratteristiche comportamentali degli utenti.

Attacchi di questo tipo, definiti anche Advanced Persistent Threat, trovano purtroppo una vasta gamma di applicazioni che spaziano dal furto di dati confidenziali finalizzato al profitto (ad esempo la sottrazione di credenziali bancarie), sino all’interferenza con le operazioni , se non in un vero e proprio sabotaggio dell’infrastruttura obiettivo. In molti casi, come ci ha dimostrato il 2011 (ed in particolare il mai troppo abusato Stuxnet) per ottenere lo scopo è sufficiente infettare un solo host (il famigerato paziente 0) per poi utilizzarlo come ponte involontario e catalizzatore per l’ondata di attacchi successiva.

E quindi cosa è accaduto nel 2010? La risposta è relativamente semplice, come dimostrato dal Trojan Hydraq (aka Operation Aurora secondo la nomenclatura adottata dal concorrente McAfee): una volta scoperte le potenzialità dei targeted attack i Cyber-criminali ne hanno utilizzato l’energia distruttiva verso le Infrastrutture Critiche.

A sostegno di questa tesi, il documento cita appunto i casi di Hydraq e Stuxnet. Il primo è inizialmente nato come un targeted attack facente leva su una Vulnerabilità del browser di casa Microsoft (advisory number 979352) con lo scopo finale di sottrarre informazioni alla vittima ed inviarle ad un server di comando e controllo. Questo attacco, che ha caratterizzato l’inizio del 2010 si è da subito tinto di giallo, non tanto per il mistero, quanto per i sospetti che sia stata proprio la Cina ad utilizzarlo con lo scopo di rubare credenziali di dissidenti dagli Account di Google.

Del secondo sappiamo tutto, addirittura Stuxnet era talmente targeted e così interconnesso con l’infrastruttura vittima, a tal punto che, secondo i ricercatori Symantec, sono passate solo 12 ore dalla prima compilazione alla prima infezione.

Curiosamente (ma fino a un certo punto) il report Symantec non cita Night Dragon, il malware scoperto dal concorrente McAfee che a mio avviso incarna meglio di chiunque altro, nel corso dell’ultimo trimestre 2010, il concetto del targeted attack rivolto a specifiche facility (questa volta un malware con il vizio del petrolchimico) e soprattutto facente uso di metodi tradizionali (SQL Injection e soprattutto download di malware tramite tecniche di Spearphishing) al fine di penetrare le barriere iniziali di protezione ed addentrarsi intimanente all’interno della rete verso le casseforti virtuali dove sono custoditi i segreti tecnici ed economici dell’organizzazione.

Gli attacchi di tipo targeted si fanno particolarmente pericolosi quando, come nel caso di Stuxnet. incrociano il mondo SCADA (Supervisory Control and Data Acquisition), ovvero quei processi e tecnologie che sottendono al monitoraggio e controllo delle Infrastrutture Critiche e dell’Industria, e che proprio per questo motivo, soprattutto in un momento turbolento come quello che stiamo vivendo, potrebbero essere al centro dell’attenzione di paesi nemici o singoli individui guidati da motivazioni ideologiche e politiche.

La pericolosità di SCADA non è nuova (si legga ad esempio questo articolo della stessa Symantec risalente al 2006), tuttavia nel 2010, è assurta alla ribalta grazie a Stuxnet e agli eventi successivi. Solo nell’ultimo trimestre dell’anno passato Symantec ha documentato 10 vulnerabilità pubbliche di SCADA, sulle 15 totali scoperte nel corso dell’anno. Ma non facciamoci troppe illusioni… Anche se numericamente esigue a causa della natura elitaria delle ricerche di sicurezza su questa tecnologia,  l’impatto di queste vulnerabilità è immane e un malintenzionato che volesse sfruttarle saprebbe bene come rendere il proprio attacco targeted per i punti deboli di SCADA, tra i quali Symantec ha annoverato nel 2010:

  • Tre vulnerabilità nell’interfaccia Web CGI dei prodotti Intellicom Netbiter webSCADA WS100 e WS200. Le vulnerabilità rilevate non sono di poco conto poiché consentono di caricare ed eseguire codice arbitrario ed accedere di conseguenza ad informazioni potenzialmente sensibili;
  • Una vulnerabilità di tipo SQL-injection all’interno della pagina di login del sistema SCADA Industrial Technology System (ITS). La vulnerabilità in oggetto consente di compromettere l’applicazione modificando la struttura del database sottostante;
  • Tre vulnerabilità di tipo buffer-overflow per il server DATAC RealWin SCADA. Grazie a questo insperato aiuto un attaccante è in grado di eseguire codice sul server;
  • Ulteriori tre vulnerabilità sono state scoperte nel prodotto Ecava IntegraXor, di cui due di tipo remote code-execution e una terza di tipo directory-traversal. “Ambetre” le vulnerabilità di questo prodotto possono essere utilizzate da un malintenzionato per eseguire codice arbitrario o accedere a informazioni sensibili ivi contenute.

Purtroppo la situazione è ulteriormente complicata dal fatto che una architettura SCADA non deve fare i conti con le sole proprie vulnerabilità intrinseche ma è costretta a portarsi dietro anche il pesante fardello delle vulnerabilità ereditate dai sistemi operativi ospitanti (sovente Microsoft) o dal middleware e database utilizzato per l’applicazione SCADA.

L’applicazione pratica di una vulnerabilità SCADA in una infrastrutture critica è presto detta, ed il caso di Stuxnet ne è emblematico: i sistemi di controllo industriale (di cui SCADA costituisce un esempio) sono utilizzati all’interno delle infrastrutture critiche per controllare i processi operativi quotidiani. In particolare sono essenziali per controllare e processare le informazioni inviate dai sensori ed attuare di conseguenza le necessarie azioni e comandi di risposta. A questo compito si aggiungono il monitoraggio degli ambienti operativi per verificare che le attività vengono sempre effettuate all’interno dei parametri di sicurezza (sono quindi in grado di prevenire condizioni pericolose per l’uomo quali: surriscaldamento, aumento dei livelli di tossicità, incendi o potenziali sovraccarichi).

Un sistema di controllo compromesso da un malware potrebbe non essere in grado di riconoscere le condizioni di pericolosità o anche di non contrastarle efficacemente, se non addirittura di sabotare deliberatamente e in maniera subdola l’infrastruttura come nel caso di Stuxnet. Le conseguenze potrebbero essere disastrose e portare ad eventi come quello (involontario) della città di Lake Havasu rimasta a secco per un guasto nel sistema di monitoraggio delle pompe d’acqua (Luglio 2010).

E quindi?

E quindi Symantec suggerisce di limitare l’esposizione delle reti che ospitano sistemi SCADA, possibilmente  isolandole dal resto del Globo. Nel caso in cui ciò non fosse possibile, il traffico verso il mondo esterno andrebbe limitato ai soli protocolli richiesti non disdegnando di proteggere ulteriormente gli accessi individuali mediante VPN IPSec autenticate ed eventualmente integrando la difesa con tecnologie di protezione di tipo endpoint sui sistemi operativi ospitanti (che comunque andrebbero sempre aggiornate) e con sistemi di Intrusion Detection & Prevention per le minacce di rete.

Dal punto di vista infrastrutturale la sicurezza di una infrastruttura SCADA è ulteriormente minata dal fatto che spesso, a causa della complessità, non è possibile creare un ambiente di test. Inoltre le interruzioni di servizio andrebbero limitate al minimo indispensabile poiché spesso sono costose se non addirittura distruttive. Suggeriti invece i test che possono essere fatti in linea, senza interrompere l’operatività quali passive asset discovery e vulnerability scanning, mentre tutte le operazioni di aggiornamento (Antivirus e pezze patch di sistema operativo) dovrebbero essere effettuate con la massima cura e con il massimo supporto dei produttori dei sistemi di controllo per minimizzare rischi e tempi di down.

Last But Not Least, non trascurare le attività di audit e policy compliance…

I Cinque Domini Dell’Apocalisse

February 15, 2011 2 comments

Quando la sicurezza Informatica incontra (involontariamente) l’arte…

Zoom Del Grafico Infezione al Dominio E (Aprile 2010 - Dati Symantec)

Symantec ha da poco pubblicato un aggiornamento relativo al proprio documento di analisi del malware Stuxnet. In questa versione del documento, che rappresenta forse il lavoro più esaustivo dedicato al malware delle centrali nucleari, il produttore di sicurezza di Cupertino ha aggregato i dati raccolti relativi al traffico effettuato dal malware verso i server di controllo remoto, con lo scopo di tracciare la linea spazio-temporale che ha caratterizzato l’infezione.

Come molti ricorderanno Stuxnet è stato da subito caratterizzato da una notevole complessità tecnica sancita, oltre che dall’uso massiccio di vulnerabilità 0-day, anche da molteplici meccanismi di infezione. A partire dall’infezione di una qualsiasi macchina Windows connessa in rete (il paziente zero), il malware è stato in grado di propagarsi con virulenza inaudita [e con l' (in)sperato supporto delle Vulnerabilità 0-day di Microsoft] all’interno della LAN. Come ultimo livello di infezione, grazie alla possibilità di propagarsi tramite drive USB, il malware ha raggiunto il vero (presumibile) obiettivo finale costituito dai nodi di programmazione PLC (definiti field PG) dei miscelatori delle Centrali Nucleari (soprattutto quelle Iraniane), nodi che tipicamente non sono connessi in rete.

Oltre a molteplici meccanismi di infezione, il team di sviluppo di Stuxnet (perché di un team deve essersi trattato considerata la complessità dell’architettura) ha dotato il malware della possibilità di aggiornarsi (per contrastare l’aggiornamento dei sistemi operativi e dei software di protezione anti-malware) e di essere controllato da remoto. In effetti il virus delle centrali nucleari non si è fatto mancare nulla ed i suoi creatori hanno previsto, seguendo la tendenza attuale del malware evoluto, un efficiente meccanismo peer-to-peer per controllare il malware da remoto ed eventualmente aggiornarlo grazie alla possibilità di connettersi ad un Server remoto di Comando e Controllo (C&C).

Sfrtuttando questo “vizietto” del malware, a partire dal 20 luglio 2010, Symantec ha messo in opera il monitoraggio del traffico dagli host compromessi connessi in rete verso i server di comando e controllo di Stuxnet. L’analisi dei campioni di virus analizzati ha consentito difatti di rilevare che i server di comando e controllo puntavano in realtà (tramite l’usuale http 80) a due domini:


facenti riferimento a server ubicati in Malesia e Danimarca. Una volta smascherati i finti domini il traffico è stato rediretto in lidi più sicuri. Contestualmente è stato possibile monitorare e analizzare il flusso di dati, impedendo ulteriormente il controllo delle macchine compromesse, e provvedendo nello stesso tempo ad avvisare le organizzazioni infette. I dati raccolti, appartenenti unicamente ai nodi compromessi connessi in rete, si sono rivelati estremamente preziosi per comprendere l’evoluzione dell’infezione. Ogni connessione verso i server di comando e controllo difatti, contiene dati quali: indirizzi IP interni ed esterni, nome del Computer, versione del Sistema Operativo, ed inoltre un indicatore che consente di capire se la macchina infetta ospita (e fa girare) il software di controllo industriale SIMATIC Step 7.

Grazie all’analisi di questi dati è stato possibile rilevare che alla  data del 29 settembre 2010 vi erano nel mondo 100.000 host infetti dei quali oltre il 60% localizzati in Iran. Dove peò i dati cominciano a farsi interessanti, è nel modo in cui è nata l’infezione: Symantec sostiene infatti che l’infezione sia nata da 5 punti ben precisi, ovvero tutto farebbe pensare che l’operazione sia stata concepita a tavolino per far partire il suo attacco mortale da cinque domini (il produttore giallo non rivela quali), da cui poi si è diffusa in tutto il globo.

A queste conclusioni si è giunti raccogliendo 3280 campioni del virus, “in rappresentanza” delle tre varianti del malware. Dal momento che il virus, ogni volta che infetta una nuova macchina, registra un timestamp oltre ad altre informazioni del sistema infetto; ogni campione racconta la storia del computer infetto, inclusa la prima infezione, il cosiddetto Paziente 0. Ovviamente con questi dati a disposizione è stato possibile ricostruire l’evoluzione del virus e determinare le caratteristiche di questa Apocalisse informatica:

  • Il nome di dominio registrato ha rivelato che Stuxnet è stato un attacco rivolto esplicitamente a cinque organizzazioni diverse;
  • Le cinque organizzazioni hanno subito 12.000 infezioni;
  • Tre organizzazioni sono state attaccate una sola volta, una è stata attaccata due volte, ed una ulteriore addirittura tre volte;
  • Il Dominio A è stato attaccato due volte (Giugno 2009 e Aprile 2010);
  • In ambedue i casi il paziente 0 (ovvero il computer origine dell’infezione) è stato sempre lo stesso;
  • Il Dominio B è stato attaccato tre volte (Giugno 2009, Marzo 2010 e Maggio 2010);
  • Il Dominio C è stato attaccato una sola volta (Luglio 2009);
  • Il Dominio D è stato attaccato una sola volta (Luglio 2009);
  • Il Dominio E sembra essere stato attaccato una sola volta (Maggio 2010), ma con tre infezioni iniziali (ovvero la stessa chiavetta USB galeotta è stata inserita dentro tre computer differenti);
  • Da queste 10 infezioni iniziali hanno avuto origine 12000 infezioni;
  • Sono stati registrati 1800 nomi di dominio diversi;
  • Tutte le date di infezione sono riconducibili a Giugno 2009, Luglio 2009, Marzo 2010, Aprile 2010 e Maggio 2010;
  • Tutte le organizzazioni infette hanno presenza in Iran;

Il grafici seguenti mostrano le lugubri figure geometriche derivanti dalla ricostruzione dell’infezione:

Infezioni per i domini A e B a Giugno 2009 (Dati Symantec)

Dominio B: Infezione Marzo 2010 (Symantec)

Sono stati riscontrati 10 cluster di infezione, il più virulento dei quali è stato quello che ha visto protagonista il Dominio B nel marzo 2010. Gli attacchi del 2009 hanno registrato il minore impatto, forse un artefatto causato dal numero ridotto di campioni raccolti per quell’anno. Inoltre, i grafici di infezione hanno principalmente rami lineari come se una singola infezione potesse influenzare un solo computer. Questo sarebbe solo parzialmente dovuto alle caratteristiche di autolimitazione del codice, mentre, probabilmente, potrebbe essere un artifatto introdotto dal numero ridotto di campioni raccolti.

Infezioni Aprile 2010 (Dati Symantec)

I dati evidenziano inoltre un non trascurabile effetto collaterale: il fatto che dagli iniziali 5 domini ne siano stati colpiti 1800 con 12000 indezioni, dimostra che Stuxnet è riuscito a sfuggire dai confini dei domini inizialmente colpiti, probabilmente per la collaborazione involontaria di partner e fornitori che, mediante una chiavetta USB galeotta, hanno propagato l’infezione oltre il perimetro virtuale del dominio obiettivo iniziale.

Il documento Symantec è estremamente curato e dettagliato, e questo ultimo aggiornamento è ulteriormente interessante e suggestivo (i grafi di evoluzione del virus sembrano opere arte ed hanno a mio avviso un contenuto artistico molto maggiore rispetto a certe opere che ho visto al MAXXI). Curiosamente, però, non ho potuto fare a meno di osservare che il documento Symantec è stato pubblicato subito dopo il report McAfee relativo al virus Night Dragon (che attacca facility differenti, appare meno raffinato del suo predecessore Stuxnet, ed ha inoltre sollevato reazioni controverse tra altri vendor di sicurezza). Questo sembrerebbe delineare una nuova tendenza dei produttori: ieri mettevano alla prova la bontà della propria tecnologia e dei propri laboratori di ricerca sfidandosi reciprocamente nella corsa dei tempi di rilascio delle signature per le nuove infezioni; oggi la sfida risiede nello sradicare per primi le minacce di nuova generazione (i cosiddetti Advanced Persistent Threat), soprattutto quando queste, anche utilizzando metodi di infezione “tradizionali”, effettuano il salto di qualità e minano alla base le infrastrutture critiche che presiedono all’Ordine Mondiale (almeno così come lo consociamo).

Dalla Cina Con Furore Arriva Il Dragone Della Notte

February 10, 2011 6 comments

Non sto parlando del titolo di un film di Bruce Lee in versione notturna, ma dell’ultimo arrivato nella poco ambita Hall Of Fame dei malware aventi come obiettivo le infrastrutture critiche.

Non si è ancora spenta l’eco del Virus Delle Centrali Nucleari che dalla Terra Dei Mandarini arriva un nuovo malware avente come obiettivo gli impianti di Olio, Gas e Petrolchimici. Secondo McAfee, che ha scoperto e battezzato il malware dagli occhi a mandorla con il nome di Night Dragon (che richiama suggestive e mitologiche immagini d’oriente), da novembre 2009, alcuni impianti di raffinazione in diversi paesi sono stati vittime di numerosi eventi malevoli, caratterizzata da un presunto focolaio cinese, e che hanno coinvolto numerose tecniche: dal social engineering, allo spearphishing, passando, tanto per cambiare, attraverso le immancabili vulnerabilità di Windows, la compromissione di Active Directory ed infine l’utilizzo di strumenti di amministrazione remota. Il tutto con l’obiettivo di raccogliere informazioni classificate appartenenti alla sfera tecnologica (quindi decisive nei confronti della concorrenza) e alla sfera finanziaria (ad esempio finanziamenti di progetti o gara d’appalto). Informazioni comunque contraddistinte dal minimo comune denominatore di appartenenza a tecnologie di produzione di impianti olio, gas e petrolchimico.


Dettagli Dell’Attacco

L’attacco del Dragone ha metaforicamente applicato il suo alito di fuoco verso le infrastrutture vittima mediante diversi fattori eterogenei di attacco in grado di penetrare progressivamente l’infrastruttura vittima. Le spire hanno avvolto gli obiettivi mediante:

  1. Compromissione dei web server della Extranet vittima tramite tecniche di attacco di tipo SQL Injection che hanno consentito l’esecuzione remota di comandi;
  2. Nei server compromessi sono stati caricati strumenti di controllo remoto utilizzati per trasformare i server compromessi in ponti di att(r)acco per accedere dall’esterno alla intranet e di conseguenza alle informazioni sensibili ivi contenute  e memorizzate nei desktop e server interni.
  3. Ulteriore accesso nell’intimità della intranet violata è stato ottenuto mediante la presa con la forza bruta (o meglio con la brute force) di ulteriori nome utente e password;
  4. Utilizzando i server Web Compromessi come server di comando e controllo (C&C), gli attaccanti, nella realtà, si sono resi conto che la sola disabilitazione delle impostazioni del proxy dal browser Microsoft Internet Explorer (IE) si è rivelata sufficiente per ottenere una connessione remota diretta alle risorse interne.
  5. Mediante malware di Controllo Remoto innestato (RAT Remote Access Tool), gli attaccanti sono stati in grado di connettersi ad altre macchine arrivando infine ai desktop papaveriali (ovvero le postazioni degli alti dirigenti) in cui hanno provveduto alla ovvia e sistematica razzia di archivi di posta elettronica ed altri documenti sensibili.

Gli attacchi hanno avuto origine all’interno della Grande Muraglia [ci sarebbe voluto un Great (Fire)wall] ed hanno utilizzato alcuni server acquisiti da servizi di hosting degli Stati Uniti per compromettere alcuni server in Olanda, e sferrare da questi ultimi virulenti attacchi contro corporation del settore Oil, Gas e Petrolchemical in Kazakistan, Taiwan, Grecia e Stati Uniti per rubare le informazioni.

E’ interessante notare il fatto che, per distribuire nelle macchine  remoto gli strumenti di controllo remoto (alcuni fatti in casa, altri “standard”), gli attaccanti abbiano utilizzato non solo tecniche di SQL Injection, ma anche ben più ingenue mail di phishing dirette verso le postazioni dei dipendenti, dipendenti che con un semplice click su un link compromesso hanno letteralmente aperto le porte (TCP) al malware che, una volta installato, ha provveduto alla sistematica raccolta di credenziali di dominio utilizzate poi per installarsi su ulteriori vittime e di conseguenza propagarsi ulteriormente nella intranet.

Una volta compromessi i sistemi interni, gli attaccanti hanno ottenuto le account di amministrazione interne e di Active Directory e le hanno utilizzate per aprire le porte sul retro (backdoor) dei sistemi ed impiantare cavalli di troia per bypassare le mura di protezione costituite dalla difesa perimetrale e dalle policy di sicurezza, arrivando, in alcuni casi a disabilitare i moduli anti-virus e anti-spyware a bordo dei desktop.

Tra gli strumenti di controllo remoto più utilizzati per questo attacco, McAfee ha rilavato il cavallo di troia zwShell, di cui gli attaccanti hanno sviluppato dozzine di varianti utilizzate per compromettere ed esportare (dumpare in termine tecnico) il database delle password di Windows (il famigerato SAM). Lo Zio SAM  è stato successivamente crackato con uno strumento standard dalle cupe bibliche reminescenze: Cain & Abel.

Una volta terminata l’operazione di recupero password è iniziata la razzia di file relativi a contratti e progetti (in acluni casi addirittura dati dai sistemi SCADA).



Leggendo in sequenza i vari documenti sino ad ora pubblicati, il mio morboso entusiasmo da professionista della sicurezza si è progressivamente smorzato. Speravo Pensavo di essere davanti ad un novello Stuxnet, ed invece mi sono ritrovato di fronte ad un “semplice” Cyber-attacco, pur sempre perpetrato in maniera massiva verso infrastrutture critiche, ma comunque facente uso di una combinazione, per quanto complessa e ben congegnata, di tecniche “tradizionali”.

Sorprende semmai il fatto che una operazione di cosi vasta portata sia stata avviata utilizzando come appiglio iniziale per l’attaccante due tipologie di attacco tutto sommato relativamente conisciute (ma non per questo semplici da contrastare): il classico SQL Injection e l’altrettanto noto phishing. E proprio in questo punto giace il paradosso: il termine Cyberattack evoca chissà quali misure in grande per contrastare minacce planetarie alle infrastrutture critiche e poi si scopre che le nostri fonti di energia possono essere compromesse da una tipologia di attacco (l’iniezione SQL) mitigabile da una normale sana attività fisica (oops di patching!), ed una tipologia di attacco, il phishing, arcinota e che non può essere contrastata pienamente da nessuna contromisura tecnologica, ma soltanto da una educazione responsabile dell’utente per l’uso del mezzo internet. Proprio in questo punto giace la difficoltà: per l’SQL Injection esistono i firewall applicativi e le patch… Per il cervello umano ancora no…


Get every new post delivered to your Inbox.

Join 2,944 other followers