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.

Introduction

HeadInTheSand150.png

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

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 were 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

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 and 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 stems 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 work 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 it's 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?

History

7th. of August 2011 - Initial posting

关键字 security,it’s getting worse
推荐.NET配套的通用数据层ORM框架：CYQ.Data 通用数据层框架
新浪微博粉丝精灵，刷粉丝、刷评论、刷转发、企业商家微博营销必备工具"