If your engineers know nothing about basic security tenets, common security bug types, basic secure design, or security testing, there really is no reasonable chance that they will produce secure software.
From The Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software, Michael Howard, Steve Lipner
Introduction
10 years ago, most people thought of hackers as college kids pulling a prank. Those days are gone and the US Department of Defense decision to allow the U.S. to respond to cyber-attacks with physical force underscores this change. In the UK, they are revving up their cyber warfare plans, as they are developing a cyber-weapons programme that will give ministers an attacking capability to help counter growing threats to national security from cyberspace. According to Channel 4 News, China admits that it has an elite unit of cyber warriors in its army, and Germany is establishing two high-level government agencies devoted exclusively to cyber-war.
Investigators are usually unable to disclose information about investigations into cyber threats because of non-disclosure agreements, so it is likely that the problem is much greater than what we can be lead to believe based on the media coverage - and that's severe enough.
In March 2011, a security breach made it possible for criminals to enter into EMC Corp's RSA security division's security systems by creating duplicates to "SecurID" electronic keys. SecurIDs are widely used electronic keys designed to thwart hackers who might use key-logging viruses to capture passwords by constantly generating new passwords to enter the system. EMC has disclosed that the hackers had broken into their network and stolen some SecurID-related information that could be used to compromise the effectiveness of those devices in securing customer networks.
RSA is among the best at securing networks, and even they can't keep their most sensitive information out of the hands of hackers.
Who Else Was Hit by the RSA Attackers? Turns out that Abbott Labs, the Alabama Supercomputer Network, Charles Schwabb & Co., Cisco Systems, eBay, the European Space Agency, Facebook, Freddie Mac, Google, the General Services Administration, the Inter-American Development Bank, IBM, Intel Corp., the Internal Revenue Service (IRS), the Massachusetts Institute of Technology, Motorola Inc., Northrop Grumman, Novell, Perot Systems, PriceWaterhouseCoopers LLP, Research in Motion (RIM) Ltd., Seagate Technology, Thomson Financial, Unisys Corp., USAA, Verisign, VMWare, Wachovia Corp., and Wells Fargo & Co. were hit too.
More than 760 other organizations had networks that were compromised with some of the same resources used to hit RSA. Almost 20 percent of the current Fortune 100 companies are on this list.
In May 2011, hackers broke into the security networks of the world's biggest defense contractor Lockheed Martin Corp, and they are pretty savvy when it comes to defending their networks too. It's fairly obvious hackers have more resources at their disposal and that they are getting more sophisticated.
Change of Plan
Should confidential information about customers, finances or new products line fall into the hands of a competitor, such a breach of security could lead to lost business, law suits and even bankruptcy. Protecting information is a business requirement as well as an ethical, and sometimes legal, requirement too.
For individuals information security has an obvious impact on privacy.
Maybe it’s time to be serious about privacy and security. Can we assure our customers that we are creating 100% secure solutions? Unlikely, but we can at least stop repeating well known mistakes.
Authentication
Unless you are part of a top-notch development team, specializing in security, don’t ever attempt to implement authentication on your own – you will botch it, or you are a certifiable genius. Even integration with existing authentication mechanisms is sometimes a challenging task, and there are plenty of well documented examples where an actor claims to have a given identity and the software does not prove or insufficiently proves that the claim is correct.
Let’s look at a naïve example:
namespace BadAuthentication
{
public partial class Login : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
}
protected void loginButton_Click(object sender, EventArgs e)
{
if (AuthenticateUser(userNameTextBox.Text, passwordTextBox.Text))
{
Response.Cookies.Add(new HttpCookie("username", userNameTextBox.Text));
Response.Cookies.Add(new HttpCookie("password", passwordTextBox.Text));
Response.Cookies.Add(new HttpCookie("loggedin", "true"));
Response.Redirect("Default.aspx");
}
}
private bool AuthenticateUser(string username, string password)
{
return true;
}
}
}
As we can see, the user is “authenticated” by the login page, and the value “true” is assigned to the “loggedin” cookie.
namespace BadAuthentication
{
public partial class Default : System.Web.UI.Page
{
bool isAdministrator;
protected void Page_Load(object sender, EventArgs e)
{
if (Request.Cookies["loggedin"] == null || Request.Cookies["loggedin"].Value != "true")
{
Response.Redirect("Login.aspx");
}
else
{
if (Request.Cookies["username"].Value == "Administrator")
{
isAdministrator = true;
}
}
DataBind();
}
public override void DataBind()
{
base.DataBind();
if (isAdministrator)
{
userTypeLabel.Text = "Administrator";
}
else
{
userTypeLabel.Text = "Not Administrator";
}
}
}
}
If the user is not logged in, he is redirected to the login page; otherwise we test the "username" cookie to determine whether the user is an administrator.
Unfortunately, this code can easily be bypassed. The attacker just has to set the cookies independently so that the code does not check the username and password. The attacker could do this with an HTTP request containing headers along the lines of:
GET /Default.aspx HTTP/1.1
Host: www.example.org
Cookie: loggedin=true; username=Administrator
While this authentication scheme is pretty naïve, it’s not uncommon to see something similar in production use. By creating cookies for both the user name and the password, web applications can handle session timeouts. The cookies are usually not named “username” and “password” and the values are sometimes “encrypted” using a simple xor – not immediately human readable, but definitely “hackable”.
How Serious is This?
According to OWASP Top 10 Application Security Risks – 2010:
“Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities”
It’s worth noting that this issue ranks as the 3rd on the “Top 10” list.
Even the mechanisms we have relied on for several years can be broken. Rizzo and Duong has shown that the 'Padding Oracle' crypto attack affects ASP.NET, JavaServer Faces and other web frameworks.
Before going public with their findings – Rizzo and Duong provided Microsoft with the information required to fix the vulnerability. According to Microsoft Security Bulletin MS10-070 Microsoft has taken several actions to fix this vulnerability, and provides a script that will help to detect vulnerable ASP.NET applications at this location: Understanding the ASP.NET Vulnerability.
The Black Hat and DefCon computer security conferences of 2013 presented a lot of scary facts about the state of the industry: If something can connect to a network, it can be hacked. Computers and phones are still popular targets, but increasingly so are cars, home security systems, TVs and even oil refineries.[^], proving that the interconnectedness of all things leads to new security challenges and risks that needs to be addressed properly - and that is going to take time.
Credentials Management
Vulnerabilities in this area include:
- Weak Cryptography for Passwords: When we store the password in plain text in an application's configuration file, we introduce a vulnerability that can be exploited, if we attempt to remedy this password management problem by obscuring the password with an encoding function, such as base 64 encoding, this does not adequately protect the password.
- Not Using Password Aging or Password Aging with Long Expiration: As passwords age, the probability that they are compromised grows - It's also not unusual to see active accounts for previous employees and other people that should no longer have access to the system.
- Weak Password Requirements: The authentication mechanism is only as strong as its credentials. So it is important to require users to have strong passwords. Lack of password complexity makes brute-force attacks easier.
- Insufficiently Protected Credentials: Passwords are often sent as clear text across the network and this exposes the user credentials during transmission to the server making the credentials susceptible to eavesdropping.
Storing a username and password in a configuration file, typically as part of a connection string is far too common, so is sending the password unencrypted over the network. Web developers should always use Transport level security (TLS), preferably version 1.2 (SSL 3.3), for login pages, even if the rest of the site does not use TLS. This helps to prevent phishing attacks as TLS allows the client to verify the identity of the server it is connecting to.
Concluding Thoughts
While it has been shown that authentication schemes created by experts in the field can be broken, rolling your own is likely to make your software much more vulnerable to attack – dangerously so. When vulnerabilities are detected in something like ASP.NET, Microsoft has shown that they have the will to take this seriously. They also have the mechanisms in place to roll out a fix, not only across the enterprise, but effectively across the world.
In short, if you build software, and your software can be accessed by potentially malicious users inside or outside the firewall, the application will come under attack.
Many authentication vulnerabilities stem from inadequate understanding of the technologies involved. The .NET platform and Windows provides mechanisms that allow us to implement software that handles authentication properly – learn to use them, even if it does take time.
The “Best Practices” documentation doesn’t mean a thing unless you are familiar with the technologies involved, it will only lead to a false sense of security.
Over the last 12 years, I've been working on Integrated Operations for the Oil & Energy sector. When you mix mission critical infrastructure for automation and your intranet - you make the assumption that the security of your intranet has not been compromised. Based on available information, that seems to be a risky assumption. By further assuming that the major vendors of automation systems is on top of the situation, you ignore that major security conscious enterprises and organizations, with far more experience in this area, still have their security breached on a regular basis.
When it comes to preventing malicious attacks "Best Practices" for IT often balances the cost of security measures against the cost of restoring lost data from a backup. If an attacker can get into the automaton infrastructure, reprogram PLCs' and SCADA systems, the possible damage can be of an entirely different order of magnitude. Considering how Stuxnet worked its way into PLCs', it's reasonable to consider that even the most farfetched of schemes may be worth guarding against.
Further Reading
To get started on authentication visit:
Michael Howard is spearheading Security Development Lifecycle (SDL) at Microsoft - and it's working.
The Comodo Fraud Incident is well worth thinking about, what if they had been able to pull it off without being noticed? How many would believe that something like stuxnet would work - before it actually did?
Mark Russinovich, Microsoft Sysinternals, 3 part blog about stuxnet:
- Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1
- Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 2
- Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 3
The US Predator and Reaper Drones have been infiltrated by a computer virus that records every movement of the people operating the drones. Wired - Danger Room: Computer Virus Hits U.S. Drone Fleet
On 18th of October 2011, the New York Times did an article on Duqu, the heir to stuxnet: New Malicious Program by Creators of Stuxnet Is Suspected - the Duqu program was found in Europe in a narrowly limited group of organizations, “including those involved in the manufacturing of industrial control systems."
Duqu is looking for information such as design documents that could help mounting a future attack on an industrial control facilities.
It may, or may not have been China that was behind hacking of U.S. satellites, but hacked they certainly were. At least two U.S. environment-monitoring satellites were interfered with four or more times in 2007 and 2008. Reuters: China denies it is behind hacking of U.S. satellites.
Here is an example of what I fear exist in a number of places: Decade-old espionage malware found targeting government computers[^]
Imagine how something like this can be used to get hold of inside information which can be used to buy or sell stocks and options. Since the 'malware' doesn't do anything malicious to the computer system it's running on, it's pretty hard to detect using the common algorithms applied by anti virus software.
Experts hack power grid in no time[^] - Ira Winkler, a penetration-testing consultant, says he and a team of other experts took a day to set up attack tools they needed then launched their attack, which paired social engineering with corrupting browsers on a power company's desktops. By the end of a full day of the attack, they had taken over several machines, giving the team the ability to hack into the control network overseeing power production and distribution.
People working on automation and process control systems rely heavily on the systems being closed to the outside world, as in closed networks.
Wikipedia defines oxymoron as a figure of speech that combines contradictory terms. I'm afraid "Closed networks" is an excellent example of an oxymoron.
The Internet of Things
Please, please don't connect stuff like SCADA systems for nuclear plants, oil rigs, the power grid, etc. to the internet - vendors still have a very long way to go before they're able to close the gap between what they think they are selling and what they are capable of delivering. Here are just a few of the latest tidbits:
This vulnerability could be exploited remotely.
History
- 7th of August 2011 - Initial posting
- 24th of August 2011 - Added references to Mark Russinovich blog
- 8th of October 2011 - Added reference to Computer Virus Hits U.S. Drone Fleet
- 26th of October 2011 - Added reference to Duqu
- 28th of October 2011 - Added new information on the RSA Attack
- 1st of November 2011 - Added reference to hacked satellites
- 23rd of March 2013 - Added reference to TeamSpy
- 5th of February 2015 - things are, obviously, still getting worse.
