In September 2004, security procedures at The Sumitomo Mitsui Banking Corporation failed it when one of its security guards let friends in to play cards. The hackers installed software that recorded pictures of information on computer screens, details of keystrokes and of users’ security details. They were caught when they tried to collect on the information they had harvested.

In 2007, a conman gained access to the safety deposit boxes at an ABN Amro bank in Antwerp’s diamond quarter, in what is thought to have been the biggest robbery ever committed by one person. The thief used no violence, just his charm, to gain entry and steal gems worth €21 million.

“He bought chocolates for the personnel, he was a nice guy, he charmed them, got the original of keys to make copies and got information on where the diamonds were,” said Philip Claes, spokesman for the Diamond High Council in Antwerp.

Many people who work in offices will know that passwords, key codes, and SecureID tokens can often be simply picked up off the desks around them. If a social engineer can gain access to an office, any of this information is potentially up for grabs. The data that can be accessed using these items is very likely to be critical to the company, otherwise why defend it?

So how do you defend your company against an attacker who uses his knowledge of your staff to simply walk into the building?

The patch for human weakness is simple: education. An informed workforce is safer than one left in the dark. Managers should try to create a corporate culture in which security is everybody’s business, not just that of the IT department or the security guard. An organisation’s technological security may identify some attacks, but if the staff and organisational culture are on your side as well, then your systems will be far more secure.

For example, employees should understand that if legitimate IT staff need access to a machine, they should not need the employee’s help, or username and password, to do so. But if the company’s employees treat technology as a feared and mysterious thing, it leaves a hole through which a social engineer can attack. The social engineer may be given access to critical systems, simply by posing as one of the IT staff. During social engineering engagements we have had instances where employees have logged in for the social engineering team, believing them to be IT staff, and left them in charge of critical systems.

Since we started testing how companies’ systems hold up against social engineering attacks, we have been surprised by how easy it is to operate in a crowded room. We have even worked in restricted access areas and never been challenged. Looking like you belong and are busy can make people leave you alone. Why does this work?

Most organisations’ security policies require that staff ask people who they do not recognise for company ID. But especially in Britain, asking for ID is seen as confrontational behaviour and those who do it may meet more outrage than praise for their understanding of the need to challenge strangers. You need more that just a policy to resolve this problem; you need to teach people that social engineering actually happens, and that they can make a difference.

In the UK we are lucky enough to have a TV show called the Real Hustle. This show purports to teach people about the way con men work and protect them from getting hustled. If it can work for keeping peoples money in their wallets, couldn’t staff education in a similar vain keep corporate data safe?

The event validation mechanism reduces the risk of unauthorized postback requests and callbacks. When the EnableEventValidation property is set to true, ASP.NET allows only the events that can be raised by the control during a postback request or callback.

– MSDN

From a security point of view, this sounds like a great feature. EventValidation actually does go a long way in protecting many non-editable application inputs (such as drop-down lists, etc) from parameter manipulation attacks.

Unfortunately there is very little documentation on how EventValidation works underneath the hood (you can find one attempt at an explanation here). One thing I have noticed is that there are some inconsistencies in how EventValidation gets enforced. Specifically, there are certain scenarios that seemingly *should* result in a validation exception but do not. Let’s look at a few…

The First Scenario

In the first scenario, we have an account maintenance page that allows users to view and potentially update their account information. Updates are submitted by pressing the “Update” image button on the account maintenance page. This button is a standard ASP.NET ImageButton control as shown by the code below:

<asp:ImageButton ID="ImageButton1" runat="server" OnClick="ImageButton1_Click" ImageUrl="/images/UpdateProfile.gif" />

As you can see, the image button triggers the ImageButton1_Click method within the codebehind when clicked, which will process the update. Based on application business rules, users within certain groups are not permitted to update their profile. As such, the developer took the following route to disable this feature:

if (HttpContext.Current.User.IsInRole("GUEST"))

{

  ImageButton1.Enabled = false;

  ImageButton1.ImageUrl = "/images/UpdateProfileDisabled.gif";

}

As you can see, if the user is in the “Guest” role, the button will be disabled and a grayed out image button will be displayed instead. For reference, the HTML generated by this code is shown below:

<input type="image" name="ImageButton1" id="Image1" disabled="disabled" src="/images/UpdateProfile.gif"/>

At this point, some of you are undoubtedly thinking about a possible attack here. The ImageButton control is disabled, but if the logic within the associated OnClick method (ImageButton1_Click) doesn’t perform the same role check, then the user can still submit a request to update their profile by forcing the request (even though the button has been disabled). Those of you familiar with how HTML works know that simply removing the disabled=”disabled” portion of the HTML INPUT tag shown above will enable the button within the browser. Once the enabled button is clicked, the ImageButton1_Click method will be invoked.

This is clearly bad coding on the part of the developer, however that is not the interesting part here. Based on the concept behind EventValidation, you would think that this scenario should throw an exception. In fact, if the control were a LinkButton instead of an ImageButton, a validation exception would be thrown. So why doesn’t EventValidation catch this? I’m not 100% certain but my guess is that it’s because a LinkButton controls use the EventTarget parameter to pass in the “clicked” control name whereas with an ImageButton, the actual control name is passed as the name of an input parameter (along with its .x and .y coordinates) and the EventTarget is left blank.

Another Scenario

Now let’s look at another scenario. This time the page uses the OnTextChanged event of a TextBox control to determine whether the value was modified and, if so, will update the database with the new value. As you can see from the excerpt below, the TBUserName_TextChanged method will be called when the TextBox value is changed.

<asp:TextBox ID="TBUserName" runat="server" OnTextChanged="TBUserName_TextChanged" />

Like the previous scenario, the developer uses a similar technique to prevent users outside of the “Administrators” role from updating their user name. If the user is not in the “Admins” role, the text box will be disabled within the browser so that the user will not be permitted to update the value.

if (!HttpContext.Current.User.IsInRole("ADMINS"))

{

  TBUserName.Enabled = false;

}

Once again, the method associated with the OnTextChanged event (TBUserName_TextChanged) needs to also perform the same role check to prevent a malicious user from bypassing the “disabled” HTML attribute. This is another scenario where EventValidation should seemingly prevent such an attack from working since the control is not enabled, however it doesn’t.

Other Notable Points

Both of the scenarios outlined here will not be exploitable if the controls have their respective .Visible attributes set to false. Forcing a request that uses a non-visible control (one where .Visible is explicitly set to “false”) will generally always trigger an EventValidation exception. However, as you can see from the above two examples this is not always the case when only the .Enabled attribute is set to false.

A few other points of interest that I noticed with respect to the above scenarios:

• EventValidation DOES prevent users from submitting a LinkButton button when .Enabled is set to “false”
• The OnTextChanged event will not be raised when the .ReadOnly attribute on a TextBox control is set to “false”

So to summarize, Event Validation is a great feature of ASP.NET that can potentially thwart exploits where the developer may be incidentally relying on client-side controls (like the Browser) to prevent users from performing certain actions. Unfortunately, however, there is some inconsistency on how controls are treated when they are “Disabled” rather than not “Visible”.

The funny part is that based on the terminology alone, when asked if it is generally more secure to “Disable” something versus make it “Not Visible”, almost all security folks would recommend disabling. Ironic isn’t it?

Those of you not familiar with various extensions that the IIS team has released over the past several months should check out IIS.NET. My two favorites are the URL Rewriter for IIS7 (think mod_rewrite for IIS) and Dynamic IP Restrictions Extension, an add-on that dynamically blocks IP addresses that violate connection threshold and timing limits (great for slowing down CGI and App Scans).

Overall, the conference was great…hats off to Stacy and the crew for a job well done. They will be posting videos of the talks on the Source Conference site over the next few weeks, so certainly worth keeping an eye out.

Luckily the folks at Microsoft recently developed a new sample application, .NET StockTrader, that fills this gap nicely. The best thing about .NET StockTrader is that it was not intentionally designed to be an insecure application. It is worth mentioning that the primary purpose of the .NET StockTrader application is to showcase the performance and interoperability of .NET Enterprise Application Server technologies like Windows Communication Foundation (WCF) and NOT a model for web application security. That being said, for Microsoft to publish a sample application of any kind that has such obvious security bugs is interesting and would seem to be an oversight.

For those interested in seeing a live demo of the application, you can find a live instance of .NET StockTrader on one of our GDS Demo Sites. The items below just scratch the surface of this application as they were all quickly identified within about 10 minutes of playing around with the application. While there are surely more issues to be found, here are some highlights:

Failure to Restrict Authenticated URLs

Not surprisingly, the .NET StockTrader application uses ASP.NET Forms Authentication for restricting access to protected pages. Unfortunately, only the pages directly linked from the main navigation bar have been defined as protected resources within the web.config. What does this mean? Well, pages such as /PortfolioBySymbol.aspx (used to display your portfolio holdings) can be directly browsed without providing proper authentication credentials. You’ll notice that a NullReferenceException gets thrown when accessing this page anonymously. This is not by design, but due to the fact that the page attempts to read the ASP.NET forms authentication cookie and it’s missing. Luckily the NullReferenceException saves the day here, but still a very sloppy configuration error (not to mention a code-level failure to anticipate and safely handle scenarios where the ASP.NET Forms Authentication cookie is empty).

Password Disclosure

This issue highlights two major problems with the application. As an authenticated user, try browsing to the Account Profile page. Aside from the normal account profile data one would expect to find here, something will probably jump out at you (at least if you are a security person). There are two form fields, appropriately marked “Password” and “Confirm Password”, which are pre-populated. The problem here is that the actual user’s password is rendered back within two form fields. Even though the browser masks the values from plain-sight, they can easily be revealed by viewing the HTML source (aka Right-Click -> View Source). As I hinted at before, there are actually two issues here. The second problem is that these passwords are actually stored in plain-text within the back-end database table used for storing profile data. As you can see, things are starting to get ugly.

Cross-Site Request Forgery

The next issue is a classic Cross-Site Request Forgery (aka a one-click attack). These attacks are certainly common, but this one is especially ugly as you will see in a moment. Keep in mind that the premise for this sample application is an on-line stock trading web application, like eTrade. Unfortunately, the page used to execute all BUY and SELL transactions passes all of its parameter via a single GET request similar to the following:

/Order.aspx?action=buy&symbol=s:0&quantity=122

The reason this is especially dangerous is that it can even be exploited through a malicious IMG or other HTML tag as shown below, so forcing a POST request is not necessary for exploit:

<IMG SRC="/Order.aspx?action=buy&symbol=s:0&quantity=122" HEIGHT="0" WIDTH="0" />

FormsAuthenticationToken Manipulation

Now this one is arguably the worst of the lot. As I mentioned towards the beginning of the post, the .NET StockTrader application uses ASP.NET forms authentication. What I didn’t mention was that the Authentication section of the web.config actually has cookie protection disabled (aka protection=”None”). As you can imagine, this makes it trivial for anyone to decode the ASP.NET Forms Authentication Token and manipulate its contents to impersonate any, yes any, user. Ironically this is one of those issues that does not immediately jump out at you if just viewing the cookie since the Forms Authentication Token is always HEX encoded irrespective of the protection setting . Let’s take a look at an example:

signinform=BC970F782904ECCF027500690064003A0039000000316F04304A80C90100318975484C80C90100002F000000

The one thing that does jump out is the unusually short length of the encoded string and the abundance of NULL (00) values. Run this string through a HEX decoder and you can quickly see the wheels come off (Hint: 75 69 64 3A 39 == U I D : 9)

Arbitrary URL Redirection

Last but not least, I’ll point out a less severe but equally interesting URL that caught my eye when browsing the application:

/StockTrade.aspx?action=sell&return=Portfolio.aspx&holdingid=5434

Any time you see a URL or file name being passed to the application there is usually something fishy going on. As it turns out, the “return” query string value on this page is directly assigned to the .PostBackUrl property of a LinkButton control on the page. The result is an arbitrary URL redirection exploit when the user clicks the link button. Ironically this bug is also dangerously close to being a Cross-Site Scripting (XSS) bug, however there appears to be some built-in escaping taking place thanks to the .NET framework (although I am sure with some further testing this could be turned into an exploitable XSS bug).

So What?

I think we all would agree that the insecure code examples and sloppy configuration settings highlighted above are pretty common and easily fixed, however that’s no excuse for Microsoft publishing a sample application riddled with flaws (even if it isn’t intended to be a showcase for application security). As many of us know, developers often rely on sample code and reference applications like the ones published on MSDN when writing code, so mistakes like these could easily make their way into a real-world scenario. Pretty scary.

Ironically, ALL of these issues can be mitigated with Secure Parameter Filter (SPF) for IIS, which can be seen live in action protecting the same sample application at http://trade-spf.gdsdemo.com. Also, for those interested in continuing the bug hunt, the .NET StockTrader sample application can be downloaded for free from MSDN.

Non-editable inputs are those that end-users do not need to modify directly ‘ hidden form fields, URIs and QueryString parameters, cookies, etc. Traditional approaches to protecting this data ‘ black list and/or white list validation ‘ are insufficient as they cannot normally prevent authorization flaws within the context of a user’s session.

Our talk demonstrated two freely available solutions that provide this type of protection for existing web applications without the need to modify the underlying application source code. In general, they both operate on the theory that the application should only permit users to perform those actions that the UI has rendered to them. The idea is to leverage HTTP responses at run-time to identify all legitimate requests (forms and links), collect the state of each possible request, and then validate subsequent requests against the stored state information. Specifically, we cover HDIV (HTTP Data Integrity Validator) for J2EE web applications and SPF (Secure Parameter Filter) for .NET web applications. The implementation details of each are discussed as well as related pros and cons.

You can download the presentation slides here.

We also released version 1.0.1 of SPF earlier this week and have a public SPF demo site running .NET PetShop v4 from MSDN. More information on SPF can be found on its official page.

• The OWASP Top Ten Web Application Vulnerabilities
• .NET and Java Secure Coding Practices
• The Secure Development Lifecycle
• Tools for Hacking web applications

There are also a couple of hacking demos that target vulnerabilities in a sample banking web application. Check it out here. Enjoy!

Microsoft has pitched UrlScan v3 as a band-aid solution to protect against SQL injection worm attacks on classic ASP and ASP.NET applications. The reality is that UrlScan’s capabilities to protect applications-level attacks are quite limited. Specifically, UrlScan is not able analyze POST data and lacks support for regular expressions. This combined with the inability to include or exclude specific URLs leaves many users unable to adequately protect their vulnerable applications. Unfortunately with UrlScan it’s an all or nothing approach.

SPF overcomes both of these shortcomings. Unlike UrlScan, SPF is specifically designed to thwart application-level attacks. UrlScan is not. UrlScan was originally designed to protect IIS web servers from the onslaught of web server attacks that surfaced shortly after the turn of the millennium (i.e. Code Red, Nimda, etc). UrlScan is very effective as a server-level protection mechanism; however the reality is that it simply was not designed to be an application-level protection mechanism.

Last week, an updated beta of SPF was released which has been significantly optimized for performance in Black-List only configuration mode. I have come up with the following sample configuration which can be used to protect IIS6 applications from SQL injection attacks (applications hosted on IIS7 can also use this configuration). Keep in mind that these patterns are designed to prevent false positive hits while still allowing most sites to function; using blanket deny rules against strings like “exec”, for example, won’t work in most real-world situations (strings like this occur way too often in most free-text submissions). I experienced this first-hand when attempting to implement UrlScan on a customer website using the sample SQL Injection rules published on the IIS.NET Security Blog.

The Black-List only sample configuration for SPF is shown below:

<spfConfig logDirectory="c:\\temp\\logs" protectForm="false" protectUri="false"
protectQueryString="false" protectCookie="false" protectMode="Active"
defaultUrl="/default.asp">

        <protectedFileExtensions>
                       <add extension=".asp" />
                       <add extension=".aspx" />
                   </protectedFileExtensions>

        <blackListPatterns>
                       <add patternRegex="(select|grant|delete|insert|drop|alter|replace|
                       truncate|update|create|rename|describe)\\s+.*\\s+(from|into|table|
                       database|index|view|set)" applyTo="all" />
                       <add patternRegex="'?\\s+OR\\s.+=" applyTo="all" />
                       <add patternRegex="(--|;|*|@@|0x|DECLARE|..|.dbo.)" applyTo="all" />
                       <add patternRegex="(CAST|EXEC|CHAR)(%|()" applyTo="all" />
                       <add patternRegex="(s|x)p_" applyTo="all" />
                   </blackListPatterns>

</spfConfig>

If anyone has any additional ideas on good SQL attack patterns to look for, feel free to share your thoughts. Keep in mind SPF BlackListPatterns are not case sensitive and are applied to decoded request data. As always, this is not intended to be permanent solution for SQL injection (as opposed to fixing your code); however it certainly raises the bar for bad guys and will buy you some time to implement the optimal fix.

Those of you who attended the “Protecting Vulnerable Applications with IIS7” talk which I presented at Black Hat earlier this month will recognize SPF as the module which I demonstrated. The version we released today works with both IIS6 and IIS7 and is written in managed .NET code.

So what exactly does SPF do? SPF provides two primary protection mechanisms which are each explained in more detail below.

Tamper Protection

The tamper protection capabilities of SPF are primarily designed to thwart authorization attacks. Tamper protection works at the following levels:

• URI Protection - Protected URI’s require a cryptographic token to access. The only way to obtain a valid URI token is for the application to present you with a link to the URI. This is primarily designed to thwart direct browsing attacks where users can forcefully request pages for which they are not entitled.

• Query String Protection - Protected query string values are validated using a cryptographic token which ensures they were not tampered with. This protection is designed to secure embedded query string values from manipulation.

• Form Field Protection - Protected form fields that contain embedded values (i.e. Hidden Fields and Select Lists) are encrypted to prevent un-authorized viewing or modification by malicious users.

• HTTP Cookie Protection - Protected cookies are encrypted to prevent un-authorized viewing or modification by malicious users.

SPF tokens can also be bound to the calling user and set to expire, resulting in the ability to protect against Cross-Site Request Forgery and thwart certain types of hijacking, replay and cross-site scripting attacks.

Malicious Input Filtering

Malicious input filtering (referred to as Black List Protection) is designed to identify parameters that include known attack patterns. SPF supports Black List pattern matching against Query Strings, Post data, and Cookie values.

In some ways, this functionality can be compared to existing server filters like Microsoft’s URL Scan, but SPF provides much more flexible capabilities. Black List Protection was originally not within the scope of SPF’s protection mechanisms, however with the recent wave of SQL Injection worms it became apparent that URLScan (specifically the recently released 3.0 Beta version) is not sufficient for protecting web applications from attack.

URLScan is a good server-level protection mechanism that has been adapted to provide basic web application protection whereas SPF is designed specifically to defend web applications and therefore can provide more comprehensive protection against harmful input. SPF’s Black List Protection provides the following:

• Regular Expression Support - Provide a powerful mechanism for defining malicious input patterns
• Flexible Request Entity Coverage ‘ Black List patterns can be applied to any combination of Query Strings, Post data or Cookie values. This level of HTTP request coverage is especially critical as SQL Injection worms become more advanced and move beyond exploiting Query String parameters. Specific URLs can also be excluded from Black List coverage for greater flexibility.

SPF is currently available for free download and use from the GDS Tools page. The current Beta of SPF provides full protection for any application running on IIS7 and for ASP.NET applications running on IIS6. Non-ASP.NET applications on IIS6 will be limited to only the Malicious Input Filtering (Black-List) capabilities of SPF. A detailed administration guide is included with the download.

I began my presentation by discussing the mass SQL Injection attacks that started earlier this year (see Internet Storm Center coverage from the start of the year), originally out of China, but now out of Eastern Europe as well. The profit motivation for these attacks is fairly obvious - inject JavaScript malware into a site’s HTML. The attacks exploit SQL Injection vulnerabilities to insert JavaScript into the database that is then rendered back into web pages. Botnets are often used to randomly attack website pages on the Internet (chosen using Google, for example) with a generic SQL Injection attack. The attacks have one shot at success - it either works or it doesn’t. The major upside of using a botnet is that even a low success rate can be devastating as they can still compromise hundreds of thousands of pages. Even worse, the indiscriminate nature of botnet attacks make it so potential victims no longer have to wander off to the deep dark corners of the Internet to face the possibility of some malicious content being installed on their machines, because any site could potentially be infected.

There are some other profit motivations that to date we haven’t seen exploited. Namely, unlike the more common botnet attacks that seem to largely target home users for their personal information and details, the mass SQL Injection attacks have a different target - websites developed by organizations and businesses, large and small. Some of which may have some very interesting information, such as customer data and (regardless of whether it is supposed to be there according to the PCI DSS) credit card information. Another target are websites that are on DMZ’s behind outer perimeter controls (e.g. firewalls), and therefore may provide a useful pathway into an organization’s network, and all of the interesting information and data residing there.

Building on these attack scenarios, I then speculated on aspects of the current mass SQL Injection attacks that could lead to more serious exploitation. What I came up with was a self replicating SQL Injection worm, and this is what was demonstrated on stage at Black Hat.

How does the Proof of Concept SQL Injection Worm Work?

For the moment it is Microsoft SQL Server specific, largely because the functionality leveraging the underlying operating system is straight forward to access in SQL Server. The worm looks at the IP address it is on, and if it is an RFC 1918 private IP range it will scan the subnet looking for other web servers on port 80. When it finds a website, it does a fairly simple crawl of the entire site, and then parses through the HTML code to identify query strings with parameters, as well as forms in the HTML. The worm then tests each parameter in succession for trivially identified SQL Injection vulnerabilities. If a parameter is vulnerable, the worm will then run through the following tests:

• is the back end Microsoft SQL Server?
• are stored procedures executable?
• is the xp_cmdshell extended stored procedure executable?

If those tests succeed, the worm uses the xp_cmdshell functionality to upload a copy of itself (i.e. the payload) onto the database server. It does this by encoding the payload as a text file, echoing it up line by line, and unpacking it on the destination server using the debugger that ships with every Windows installation by default - debug.exe. Then, presuming it all worked, the reassembled worm is executed, and the spread continues. And that is all this proof of concept worm does - spread. All of this worked quite well live on stage, with the exploit to upload process taking about 2-3 minutes for my test network, enabling me to show a number of the worms executing in memory (as the worm doesn’t have any facility to detect whether a machine is already infected).

Yes, this particular worm does rely on an insecure configuration being present - namely that xp_cmdshell is executable. By default this is not available on SQL Server 2005, and won’t be executable unless the website has been explicitly granted privileged access to the database server, so not all vulnerable sites will be exploited by the worm. However, there are plenty of sites that are configured insecurely, running previous versions of SQL Server (that are much easier to misconfigure), and let’s not forget xp_cmdshell is also available and potentially exploitable on sites running a Sybase backend. After all, even if only one in ten sites are in this configuration, we will still have tens of thousands of vulnerable sites.

To wrap it all up, my Black Hat presentation demonstrated one particular way that things could get much worse with SQL Injection worms. Leveraging operating system access (if present) is only one potential way to wreak havoc on the Internet. There are lots of others - I for one will be very interested to see where those clever folks in China and Eastern Europe take the mass SQL Injection attacks in the near future.