Your daily source of Pwnage, Policy and Politics.

Episode 350 – Mutillidae, APT Discussion, SCADA & Comodo

ISDPodcast Episode 350 for March 24, 2011.  Tonight's podcast is hosted by Rick Hayes, Keith Pachulski, Adrian Crenshaw, Karthik Rangarajan and Varun Sharma.

Announcements:

Indiana Linux Fest

When: March 25-27, 2011
Where: Wynhdam Indianapolis West Hotel Indianapolis, IN

CarolinaCon
When: April 29th, 30th, and May 1st, 2011
Where: Holiday Inn – Glenwood Avenue in Raleigh, NC
http://www.carolinacon.org/

SANS Mentor:  Security 401: SANS Security Essentials Bootcamp Style (Matthew Romanek)
When: Thursday, May 5, 2011 – Thursday, July 7, 2011
Where: Federal Way, WA 
http://www.sans.org/mentor/details.php?nid=24569

SANS: SANS Security 504: Hacker Techniques, Exploits & Incident Handling (Dave Shackleford)
When:  Sunday, May 15, 2011 – Friday, May 20, 2011
Where: Baltimore, MD

My Hard Drive Died

Data Recovery Expert Certification
When: June 6-10, 2011
Where: Atlanta, GA
http://www.myharddrivedied.com/data-recovery-training



@DerbyCon

When: September 30th – October 2, 2011
Where: Louisville, KY
http://www.derbycon.com/

ISDpodcast Mailing List:  http://groups.google.com/group/isdpodcast

Information Security Leaders Survey:
https://www.surveymonkey.com/s/isl-2011-certsurvey



Hackers for Charity Cookbook:  http://www.hackersforcharity.org/hackers-for-charity/hackers-for-charity-cookbook/
Hackers for Charity Cookbook is asking the hacker community to contribute their best recipes to be included in a Hackers Cookbook. ALL PROCEEDS GO TO HACKERS FOR CHARITY!!! 100%.  Submit your best recipes to cookfu@304geeks.com for consideration. First round of submissions are due by 4/1/2011 

Developers Survey:
Chris John Riley needs your help!  He needs developers to complete a quick (10 question) online survey.  The results will be used in an upcoming presentation at BSidesLondon.   So please take the time and take the survey: http://www.surveymonkey.com/s/FH9PFY6 or http://svy.mk/eNJzNC


Intro/Outro Music provided by JimmyZ (http://soundcloud.com/jimmyz)

 

Stories

Source: http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10

Mutillidae: A Deliberately Vulnerable Set Of PHP Scripts That Implement The OWASP Top 10.  Version 2.0 beta has just been released.

http://www.irongeek.com/downloads/mutillidae2.0.1beta.zip

 

Source:  http://blogs.computerworlduk.com/jericho-forum/2011/03/after-the-breach—how-secure-is-rsas-securid/

Source:  http://www.computerworlduk.com/news/security/3265825/rsa-warns-securid-customers-about-hack/

Source:  http://www.csoonline.com/article/678070/rsa-breach-puts-apt-back-in-the-spotlight

Source:  http://news.cnet.com/8301-27080_3-20044775-245.html

Source:  http://news.cnet.com/8301-27080_3-20044455-245.html

Source:  http://www.readwriteweb.com/enterprise/2011/03/rsa-breach-an-attack-that-used.php

Source:  http://www.net-security.org/secworld.php?id=10765

 

I was asked by Kevin, a guy that used to work with me a long time ago to comment on the whole RSA breach.  To be honest, we talked about it last Friday so I was a little reluctant at first, that was until yesterday.  Reactions to the RSA breach have been as varied as the security community itself.  They've ranged from the "it's not a big deal" to "OMG!".  We wanted to take a few moments and discuss the breach, what we know about it, what it means and what does (wait for it) APT really mean to us.  

 

So what do we know?  Well, on March 17th RSA, the security division of EMC, suffered a breach and data loss following an "extremely sophisticated cyber attack."  Their investigation revealed that the information extracted from the company systems was related to its SecurID two-factor authentication products. 

 

What does it mean?  RSA SecurID is a hardware token that are identical internally except for the unique printed serial number on the outside of each one.  Each token is initialized with a secret ‘seed’ value, and a cryptographically protected copy of that seed value is sent to the token purchaser to install into their authentication server.  The algorithm, which is based on AES, uses that seed value combined with the internal clock to generate the numbers displayed.  Normally customers buy a large batch of tokens at one time, and receive a file containing that batch of seed values. 

 

Software tokens are similar, except that one copy of the secret seed is installed into the software token, and another into the authentication server. The main difference from the hardware tokens is that the cryptography makes it very difficult for the customer to generate their own seeds, protecting RSA's revenue. 

 

In both cases, once installed on the authentication server, most of the cryptographic protection of the seed values could be removed by anyone with sufficient time and effort to reverse engineer the code, and in fact the previous secret 64-bit algorithm was revealed about 10 years ago through such reverse engineering.

 

Now this means that, in principle, RSA has a copy of all the seed values linked to the token serial numbers. That means they could choose to offer a service to re-send seed values. It also means that anyone in the supply chain potentially has a chance to take a copy of those seed values. Naturally RSA has implemented a very secure handling process to protect those secrets, from the generation of the secret seed values to the transmission and storage of them.

If RSA's attackers were somehow able to obtain the seed records then things are much worse then it would seem at first blush.  Again, the reason is because these seed records are used to generate the unique, one-time passwords that SecureID generates every 30 seconds or so in order to authenticate the user.  If the attackers have access to the seed they could potentially can calculate the number that is shown on the token during authentication.
 

What's the impact?  We don't know now.  I doubt that anyone outside of EMC/RSA knows for certain.  Obviously, RSA competitors know and are trying to leverage this to increase their market share.  

 

This is where we now get into APT (Advanced Persistent Threats).  I know I'll catch hell for saying it, but APT is the new buzz word or marketing term for something that has been happening for years and years and years. Since the advent of someone wanting what someone else has, be it wine, women or land. I participated in a panel discussion on the topic yesterday that was moderatored by David Dumas. David started out by defining what APT is which is helpful. I paraphrasing here, but essentially it is a human being or organization that is performing operations with the end goal being theft of something; intellectual property, money, something that someone else values. It’s not all about IP or money. States are involved – economic power, intelligence, reconnaissance or weakening in the event of a strike capability. Sometimes it can be as simple as gathering information of people (think Chinese Dissidents).  David compiled a list of questions that we had intended to use as part of the panel, but like most things we tended let the audience's questions lead us.  Below are the questions that David provided.  I wanted to share them with you to get your take on the subject:

 

  • Is APT something that everyone should be worrying about and planning for (is APT pervasive or just hype)?
  • Explain how APT works (reconnaissance, phishing, infection, exfiltration)?
  • What industries are targeted the most with APT?
  • What data is most often taken (this goes to adding more protections around the most valuable data)?
  • What are the most common Trojans used with APT?
  • How can you tell you've been infected by APT?
  • What can be used for detection (system logs, AV logs, IDS logs, Netflows, DNS, VPN logs, Full packet capture, File system analysis)?
  • What can be done (logs, correlation of data across the enterprise, combine response efforts into a central location, keep data longer)?
  • How long should you maintain this network data (3 months, 6 months, 9 months, a year)?
  • What can be used for Mitigation (DNS/IP Sink Hole, system remediation and reimage)?
  • What can your security vendor company do to mitigate the risks of APT (asked to the panelists)?
  • Do you notify law enforcement when you find APT (or the company that you saw was infected by this malware)?
  • Do you recommend security awareness to all employees and if so, do you have any examples/suggestions?
  • Are you seeing APT being used by certain countries or is it equally used across the globe?
  • What is missing from a technology, training, resources, policy perspective that needs to be addressed?
  • Do we have all the tools to combat APT?
  • Should vendors cryptographically sign all the code, including JavaScript, that they produce so that users can verify that they are really running the code they think they’re running?

I personally think there is a good bit of hype with APT as with anything. STUXNet was so overhyped that you have probably gotten to the point where people cringe when they hear that name.  However, the reality is that APT is real and it is pervasive, but it is nothing new.  That being said, it does highlight the need for every company to gain insight into why someone would target them and what are the "crown jewels" to a business, thus what they need to protect.   The Penetration Execution Standard (http://www.pentest-standard.org) does a great job of highlighting OSINT (OpenSource Intelligence) that should be gather as part of a penetration test.  But unfortunately, we as pentesters aren't doing it and companies aren't either.  Therefore, it stands to reason that most companies wouldn't know who is/would be targeting then and what they would be after.
 

Mitigating APT is usually a matter of knowing what someone wants and protecting it.  While that sounds simple, it's really not.  In reality, a penetration test can identify weaknesses that can be exploited, however it would not mitigate the threat from a well funded, patient and skilled attacker.  Think SE attacks, or simple smash and grab.  The idea that APT can be prevented is simple ridiculous.   The real focus should be on plugging the obvious and yes, not so obvious holes and then focusing on your ability to track what is/has taken place.  That means log management and that means either a SIEM or personnel to do the monitoring.  This leads into the next focus, Incident response (IR).  An IR plan is something that must be in place and it must be practiced.  Having been an Incident Response Coordinator, I can tell you from experience that during an actual incident is not the time to "figuring out" what to do.  
 
Finally, what does all this mean to us?  It means we have the opportunity to learn from others mistakes and grow.  Does it mean you should move away from RSA?  We don't know enough to say "yes" or "no", and as we stated earlier, no one else does either.  I had a boss one time that always used to get asked "are we secure."  He would respond with information about our current efforts or attacks that we were seeing.  One time I told him that all he was really doing was confusing them cause they really didn't understand what being secure meant.  He agreed and the next time he was asked he replied with "Do you feel secure?"  They answered "yes", they felt secure.  That's the real question.  Do you still feel secure using SecureID?  

The security of software used to control hardware at nuclear plants, gas refineries and other industrial settings is coming under renewed scrutiny as researchers released attack code exploiting dozens of serious vulnerabilities in widely used programs.

The flaws, which reside in programs sold by Siemens, Iconics, 7-Technologies, Datac, and Control Microsystems, in many cases make it possible for attackers to remotely execute code when the so-called supervisory control and data acquisition software is installed on machines connected to the internet. Attack code was released by researchers from two separate security camps over the past week.
“SCADA is a critical field but nobody really cares about it,” Luigi Auriemma, one of the researchers, wrote in an email sent to The Register. “That's also the reason why I have preferred to release these vulnerabilities under the full-disclosure philosophy.”

The vulnerability dump includes proof-of-concept code for at least 34 vulnerabilities in widely used SCADA programs sold by four different vendors. Auriemma said the majority of the bugs allow code execution, while others allow attackers to access sensitive data stored in configuration files and one makes it possible to disrupt equipment that uses the software. He included a complete rundown of the vulnerabilities and their corresponding PoC code in a post published on Monday to the Bugtraq mail list.

It came six days after a Moscow-based security firm called Gleg announced the availability of Agora SCADA+, which attempts to collect virtually all known SCADA vulnerabilities into a single exploit pack. The 22 modules include exploits for 11 zero-day vulnerabilities, said the company's Yuriy Gurkin in an email. It's not clear how much the package costs.

Gurkin said Gleg's website has come under sustained web attacks shortly after releasing the SCADA exploit pack.

“We have tried to switch to ddoshostingsolutions.com provider but in just 3 days were out of 500 GB traffic limit,” he said. “Currently trying to solve this.”

The vulnerability of SCADA systems had long been theorized, but it wasn't until last year that the world got an object lesson on just how susceptible they could be to attack. In July, researchers reported the discovery of a computer worm that attacked SCADA software sold by Siemens. Research later showed that the underlying Stuxnet exploit amounted to a “search-and-destroy weapon” built to take out Iran's Bushehr nuclear reactor.

A breach involving an affiliate Comodo RA (registration authority). The RA is an entity trusted to register other entities or to authenticate those who are being issued a certificate. Comodo is reporting that root keys, intermediate CAs (certificate authorities) and secure hardware were not affected in this breach. The fraudulent certificates were issued by the UTN-USERFirst-Hardware certificate authority.

These certificates may be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against all web browser users, including users of Internet Explorer.  Credentials for a Comodo Account in Southern Europe were compromised and used to issue nine fraudulent certificates for seven Internet domains:

Affected Domain

Serial

mail.google.com

047ECBE9FCA55F7BD09EAE36E10CAE1E

www.google.com

00F5C86AF36162F13A64F54F6DC9587C06

login.yahoo.com

00D7558FDAF5F1105BB213282B707729A3

login.yahoo.com

392A434F0E07DF1F8AA305DE34E0C229

login.yahoo.com

3E75CED46B693021218830AE86A82A71

login.skype.com

00E9028B9578E415DC1A710A2B88154447

addons.mozilla.org

009239D5348F40D1695A745470E1F23F43

login.live.com

00B0B7133ED096F9B56FAE91C874BD3AC0

global trustee

00D8F35F4EB7872B2DAB0692E315382FB0

Comodo has stated that these certificates were immediately revoked and the compromise account disabled. IP addresses associated with this attack originate in Iran. Comodo has made the observation that "…domains targeted would be of greatest use to a government attempting surveillance of Internet use by dissident groups." For this reason, Comodo believes that the attack was likely sponsored by a nation-state adversary. They also note that the Iranian government have made previous attempts at attacking other methods of encrypted communications.

According to reports, only one of the nine fraudulent certificates has been observed in use on the Internet (login.yahoo.com). Major web browser vendors are blacklisting these certificates by hardcoding the fingerprints in the web browser. Microsoft has issued Security Advisory 2524375, which provides a software update that customers should install as soon as possible to protect Windows systems. The CTU research team is in the process of developing countermeasures to detect the use of the fraudulent certificates.