Tuesday, April 12, 2011

Reviewing RSA's Report

I recently read an article that was sent to me detailing some of the steps of the recent attack against RSA. RSA was the victim of an advanced persistent threat which are a long-term pattern of targeted sophisticated attacks again an entity.

This particular article is located on page 6 of the report located here.

Phine Phishing
The RSA SecurID breach was one that started with a phishing attack (whose goal usually is to obtain sensitive information or to have the user take a certain action, like opening an attachment). This attack is carried out by an attacker sending an email that portrays to be from a trustworthy source

Working As Planned - Good News and Bad News
In March of this year, phishing emails were sent to two small groups of "low-level" users with the subject line “2011 Recruitment Plan.” This email had an MS Excel attachment with the new Adobe Flash vulnerabilty embedded in it.

The good news is that an email filter or anti-spam program caught the attachment and sent it to the Junk Mail folder. The bad news is that the employee went into the folder, retrieved the message and opened the attachment.

Let's stop right there for a minute. A little employee awareness training would've proven invaluable at this point.

The attack then installed a Poison Ivy variant for remotely controlling the infected machine. The Poison Ivy trojan uses a reverse connection, masquerading as a web browser process to bypass security controls and avoiding detection by the user and firewalls.

The attack first harvested access credentials such as: user, domain admin, and service accounts.

According to the article, it then went into specific servers, removed data, and moved it to staging servers set up inside RSA, “where the data was aggregated, compressed and encrypted for extraction," 

Password-protected RAR files were transferred via FTP from the RSA file server to an external, compromised machine at a hosting provider.

The files were then pulled by the attacker and removed from the external host.

Lessons Learned
Lessons learned here include user education, incident response, and disclosure.

The report mentioned that the phishing scheme targeted "low-level" users. While these people weren't defined, there is definitely an opportunity for security education for the users. There was a very good reason that the message that was received was tagged as spam and isolated. Not too bad considering that this was a 0 day or close to it attack.

The machine from which the email was opened wasn't patched to handle the new Adobe vulnerability. Depending on other factors that are in play, such as the ability to mitigate this threat (see isolation in the above paragraph), this may not be too bad of an issue due to the timing of the release of the vulnerability details and patch.

The next part of this equation is a bit nebulous, since I am not aware of the account(s) used and the number of queries to the database servers during this time vs the baseline numbers for a comparable time, but it would seem curious as to why an alert of some sort wasn't configured to warn the admins or at least the help desk of a large number of queries or spike in activity , if that was the case.

Full disclosure of the attack to the customers is a right that they should have been given. Disclosure of this attack also provides the security community with the ability to see where potential holes exist in our own networks as well as provide an opportunity for user education, which looks to be the biggest issue here.

No comments:

Post a Comment