Stage 1: Use a Windows OS vulnerability for wormable spread. This is the zero day .LNK file attack.
Stage 2: If the malware lands on a computer running Siemens WinCC software it uses an application vulnerability to access the database containing sensitive information and exfiltrates the data

Stage 1 is an OS vulnerability. This effects everyone running Windows. Stage 2 is an application vulnerability. This effects only those running Siemens WinCC which the attack is targeted for. Siemens software has a critical severity vulnerability that is also easy to exploit: a hard coded password. Once hard coded passwords are discovered it is trivial for the attacker to access systems using that password, in this case a database.

Hard Coded password (also known as CWE-798: Use of Hard-coded Credentials) is #11 on the CWE/SANS Top 25 Most Dangerous Software Errors, an industry standard list that Veracode contributed to. It is a very common problem and is found in a lot of software that has not undergone proper security testing before shipping to customers. Veracode commonly finds this vulnerability in the software we test for our customers.

This is what the CWE/SANS Top 25 Most Serious Software Errors has to say about hard coded passwords:

“Hard-coding a secret password or cryptograpic key into your program is bad manners, even though it makes it extremely convenient – for skilled reverse engineers. While it might shrink your testing and support budgets, it can reduce the security of your customers to dust. If the password is the same across all your software, then every customer becomes vulnerable if (rather, when) your password becomes known. Because it’s hard-coded, it’s usually a huge pain for sysadmins to fix. And you know how much they love inconvenience at 2 AM when their network’s being hacked – about as much as you’ll love responding to hordes of angry customers and reams of bad press if your little secret should get out. Most of the CWE Top 25 can be explained away as an honest mistake; for this issue, though, customers won’t see it that way. Another way that hard-coded credentials arise is through unencrypted or obfuscated storage in a configuration file, registry key, or other location that is only intended to be accessible to an administrator. While this is much more polite than burying it in a binary program where it can’t be modified, it becomes a Bad Idea to expose this file to outsiders through lax permissions or other means.”

Siemens has put their customers at risk with this egregious vulnerability in their software. Worse, in my book however, is all the customers who purchased the software not knowing of its risk. Software customers that are operating SCADA systems on critical infrastructure or their factories with the WinCC Software had a duty to their customers and shareholders to not purchase this software without proper security testing.

We should ask the question, “Why didn’t Siemens fix the hard coded password vulnerability when it was first publicly disclosed?” They waited 2+ years and started to fix it only after a worm exploited it. We should also ask the question, “Is it negligence when you don’t fix a critical known vulnerability and wait for your customers to get exploited?”

The way to solve the problem of vulnerable software in critical infrastructure is to have independent security tests for at least the vulnerabilities listed in the CWE/SANS Top 25 Most Dangerous Software Errors before the software is deployed. Otherwise, customers are just hoping that someone discovers that someone else’s systems are compromised, and alerts the media, and there is a patch deployed, before their systems are compromised. With the sophistication shown through this multi-stage USB attack, it is clear that hope is not a viable option.

The AT&T website vulnerability is part of a growing new trend for vulnerability disclosures. As software and services move from traditional installed software to SaaS and into the cloud, more vulnerabilities are only going to exist in code running on one organization’s web server. This makes the basis for website vulnerability disclosures as beneficial somewhat different from disclosures for software that is installed on many customer devices.

The first issue with vulnerabilities in code running on a website is, to do the research in the first place, the researcher needs to interact with computers that they don’t own. Traditional vulnerability research occurs on the researcher’s equipment or on equipment they have permission to use. Website research has a risk of crossing the line into unauthorized access or exceeding authorized access as defined by the CFAA (Computer Fraud and Abuse Act).

What constitutes exceeding access on a public website is a bit of a gray area. On one hand, sending a large buffer to a web application that causes it to crash and execute the code of your choosing seems like exceeding authorized access. No one would ever think the application was designed to do that and clearly executing your own program is very different than interacting with a web page. But what about a web site which was designed to display the email address associated with an ID when the user enters an ID? Is it exceeding authorized access to put in a random ID and get the email address associated with it back? The website is working as its designers intended.

The latter case is exactly the vulnerability (now fixed) in the AT&T website that affected iPad 3G users. Anyone who registered on the AT&T website entered their iPad’s ICC-ID and an email address. After they had registered they could return and enter just the ICC-ID and the web page would display their email address. Researchers from Goatse Security noticed this and tried entering random ICC-ID numbers into the website and discovered for valid ICC-IDs they would get the owner’s email in response.

At this point Goatse Security had enough to demonstrate the vulnerability and report it to AT&T. But as is often the case when a tiny organization with little track record is reporting an issue to a huge multinational company, they gathered enough information to make the story newsworthy and got a 3rd party organization to contact the company. In fact, they harvested 114,067 email addresses. So a wrinkle to this “gray area” of exceeding authorized access may how much information is gathered. If AT&T prosecutes, as they have stated they will, we will get to find out whether this behavior exceeded authorized access in the eyes of the court.

There is clearly a benefit to Goatse Security’s work. AT&T had the opportunity to fix their website before any information about the vulnerability was made public. A vulnerability that disclosed information that could have been used by criminals to target iPad owners, both over email and over the GSM network, has been remediated. Furthermore, the iPad owners have been notified and can take corrective action, such as being more vigilant to iPad targeted attacks over email or changing their ICC-ID with a new SIM card. It is hard to see any downside to their actions. They never disclosed the information they obtained to prove the vulnerability to a 3rd party and they say they have destroyed it.

We need a way for researchers that discover vulnerabilities in web applications and report them without being prosecuted. As long as the owners of the web site have the opportunity to make corrections to address the vulnerability before disclosure, this will benefit users in the long run.

The challenge is in determining what is an attack and what is research? When does research become exceeding unauthorized access under CFAA? These questions don’t exist for research into vulnerabilities in traditional software that is installed on a machine the researcher owns. As sensitive information moves from local machines and servers to databases and files on the internet, this information is mediated by potentially vulnerable web applications. If good faith and responsible research can’t continue to follow software as it moves from desktops and servers to the cloud then data security overall will suffer.

But we shouldn’t kid ourselves and think that research alone can make an application more secure. It can point out bugs here and there, but can never make an application secure. To do that, web app developers need to test their software for security vulnerabilities before they deploy the software to the internet. A vulnerability report from a researcher is a wake-up call that security testing was inadequate. Organizations need to demonstrate to their customers that they have conducted adequate testing before they deploy their applications and certainly before they attract the attention of researchers. That is the real solution for security on the web. Unfortunately we are still in a phase where researchers need to keep demonstrating the need for more security testing.

Hiring Practices

Firstly, and even before a prospective employee is brought in for interview, the organisation should understand what they are looking for. A comprehensive Job Description is essential. It should be used not only for long listing, but also as the basis for ongoing performance reviews.

Reference Checks should be used to determine the truthfulness of a candidate’s employment history, in addition to providing context on generic competencies like communication, management, teamwork, efficiency and innovation. Employment referees should be contacted in addition to personal, or character, referees. Given the difficult legal climate and the potential liability associated with supplying a negative reference, refusal to provide one should increasingly be interpreted as indicative of prior problems in the workplace.

Background Checks that go beyond reference checks should be completed. Depending on the legal framework in the country in question, these checks could include:

• financial
• criminal
• medical
• drug testing
• education.

These checks can be expensive and should be concentrated on those individuals through whom the organisation is exposed to most risk:

• Technology workers
• Financial workers
• Workers with access to proprietary information
• Client facing workers

The benefits of conducting such checks are numerous. Staff turnover is reduced, risk of insider threat is reduced and the company’s reputation, and bottom line, is protected.

Employee Controls

Job Rotation – regular rotation of staff reduces the risk of collusion between individuals. When the position is rotated, the organisation may uncover evidence of errors or fraudulent activity.

Separation of Duties – this control ensures that no one employee has the access necessary to carry out a particular operation on their own. It makes collusion a prerequisite for fraudulent activity. Typically duties will be split between multiple employees or, ideally, teams of employees, with each group serving as a check and balance on the other.

Least Privilege (Need to Know) – is the principle that just because an employee is cleared to access a particular file, or topic, doesn’t mean they should be able to. Employees are given just enough access to allow them to conduct their normal duties, and no more. If job rotation is in place in the organisation, administrators must be careful to ensure that employees do not carry their accesses with them to a new job, building up an ever increasing set. Role based access control, which assigns privileges by the job that a person does, rather than to them as an individual, is an effective way to achieve this.

Mandatory Vacations – some organisations require that their employees take a vacation once a year of a set length. This allows the audit team to monitor the system for irregularities when that employee’s work is redirected to a colleague. Some organisations remove all access during this period to ensure that workers are not connecting in remotely, or working in the evenings or weekends.

…the vulnerability density (average flaws per MB of code scanned) for .NET was 27.2 and for Java the overall density was 30.0.

The question of which platform helps create a more secure application has been debated vigorously for many years. Back in 2003, with Andy Jaquith and other consultants at @stake, I performed a comparison of the security of the .NET vs. J2EE platforms. Our overall results had .NET coming out slightly ahead of J2EE mostly due to better developer defaults and better security guidance for developers. This may be the reason .NET is coming out slightly ahead in this analysis of hundreds of real-world applications.