About these ads

Archive

Posts Tagged ‘NetWitness’

Advanced Persistent Threats and Security Information Management

October 13, 2011 3 comments

Advanced Persistent Threats are probably the most remarkable events for Information Security in 2011 since they are redefining the infosec landscape from both technology and market perspective.

I consider the recent shopping in the SIEM arena made by IBM and McAfee a sign of the times and a demonstration of this trend. This is not a coincidence: as a matter of fact the only way to stop an APT before it reaches its goal (the Organization data), is an accurate analysis and correlation of data collected by security devices. An APT attack deploys different stages with different tactics, different techniques and different timeframes, which moreover affect different portion of the infrastructure. As a consequence an holistic view and an holistic information management are needed in order to correlate pieces of information spread in different pieces of the networks and collected by different, somewhat heterogeneous and apparently unrelated, security devices.

Consider for instance the typical cycle of an attack carried on by an APT:

Of course the picture does not take into consideration the user, which is the greatest vulnerability (but unfortunately an user does not generate logs except in a verbal format not so easy to analyze for a SIEM). Moreover the model should be multiplied for the numbers of victims since it is “unlikely” that such a similar attack could be performed on a single user at a time.

At the end, however, it is clear that an APT affects different components of the information security infrastructure at different times with different threat vectors:

  • Usually stage 1 of an APT attack involves a spear phishing E-mail containing appealing subject and argument, and a malicious payload in form of an attachment or a link. In both cases the Email AV or Antispam are impacted in the ingress stream (and should be supposed to detect the attack, am I naive if I suggest that a DNS lookup could have avoided attacks like this?). The impacted security device produce some logs (even if they are not straightforward to detect if the malicious E-mail has not been detected as a possible threat or also has been detected with a low confidence threshold). In this stage of the attack the time interval between the receipt of the e-mail and its reading can take from few minutes up to several hours.
  • The following stage involves user interaction. Unfortunately there is no human firewall so far (it is something we are working on) but user education (a very rare gift). As a consequence the victim is lured to follow the malicious link or click on the malicious attachment. In the first scenario the user is directed to a compromised (or crafted) web site where he downloads and installs a malware (or also insert some credentials which are used to steal his identity for instance for a remote access login). In the second scenario the user clicks on the attached file that exploits a 0-day vulnerability to install a Remote Administration Tool. The interval between reading the malicious email and installing the RAT takes likely several seconds. In any case Endpoint Security Tools may help to avoid surfing to malicious site or, if leveraging behavioral analysis, to detect anomalous pattern from an application (a 0-day is always a 0-day and often they are released after making reasonably sure not to be detected by traditional AV). Hopefully In both cases some suspicious logs are generated by the endpoint.
  • RAT Control is the following stage: after installation the malware uses the HTTP protocol to fetch commands from a remote C&C Server. Of course the malicious traffic is forged so that it may be hidden inside legitimate traffic. In any case the traffic pass through Firewalls and NIDS at the perimeter (matching allowed rules on the traffic). In this case both kind of devices should be supposed to produce related logs;
  • Once in full control of the Attacker, the compromised machine is used as a hop for the attacker to reach other hosts (now he is inside) or also to sweep the internal network looking for the target data. In this case a NIDS/anomaly detector should be able to detect the attack, monitoring, for instance, the number of attempted authentications or wrong logins: that is the way in which Lockheed Martin prevented an attack perpetrated by mean of compromised RSA seeds, and also, during the infamous breach, RSA detected the attack using a technology of anomaly detection Netwitness, acquired by EMC, its parent company immediately after the event.

At this point should be clear that this lethal blend of threats is pushing the security firms to redefine their product strategies, since they face the double crucial challenge to dramatically improve not only their 0-day detection ability, but also to dramatically improve the capability to manage and correlate the data collected from their security solutions.

As far as 0-day detection ability is concerned, next-gen technologies will include processor assisted endpoint security or also a new class of network devices such as DNS Firewalls (thanks to @nientenomi for reporting the article).

As far data management and correlation are concerned, yes of course a SIEM is beautiful concept… until one needs to face the issue of correlation, which definitively mean that often SIEM projects become useless because of correlation patterns, which are too complex and not straightforward. This is the reason why the leading vendors are rushing to include an integrated SIEM technology in their product portfolio in order to  provide an out-of-the-box correlation engine optimized for their products. The price to pay will probably be a segmentation and verticalization of SIEM Market in which lead vendors will have their own solution (not so optimized for competitor technologies) at the expense of generalist SIEM vendors.

On the other hand APT are alive and kicking, keep on targeting US Defense contractors (Raytheon is the latest) and are also learning to fly though the clouds. Moreover they are also well hidden considered that, according to the Security Intelligence Report Volume 11 issued by Microsoft, less than one per cent of exploits in the first half of 2011 were against zero-day vulnerabilities. The 1% makes the difference! And it is a big difference!

About these ads

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).

Follow

Get every new post delivered to your Inbox.

Join 2,994 other followers