First, a little bit about Google Web Toolkit (GWT). GWT is a Java framework that is used to create AJAX applications.  Rather than having to write complex JavaScript code, GWT makes it easy to build AJAX enable Java web applications by allowing developers to build the components in Java and then compiling that code into optimized JavaScript for browsers to run.  One of the added bonuses that GWT provides is the ability to reuse code.  GWT-RPC provides the ability to send native and custom Java objects from the client-side Javascript code over to the Java server-side backend.  GWT-RPC sends a serialized stream containing the Class name, Method name, Parameters through the wire whenever an AJAX call is made. This serialized stream is what we need to dissect in order to understand which fields can be fuzzed without invalidating the request.

The serialized steam is in plaintext and delimited by pipes.  The calls are sent through the browser as a typical HTTP POST Request with the serialized method call in the body of the request. Here is an example of a very simple GWT RPC request to a method called greetServer that takes in two strings as parameters.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

The stream can be split into three different parts (keep in mind that I am using Google’s naming convention for these parts as seen through the code that implements the serialization).

Header

1. Contains the SERIALIZATION_STREAM_VERSION value which at present will always be set to 5.  If this value is changed, it will cause an error on the server side. Therefore, this value is not fuzzable.
2. The next value is a flag value. I have yet to seen somewhere where this value is set to anything other than 0. Modifying this value does not break a request.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

String Table

1. The first value is an integer that tells you how many pipe delimited values to read in to fill the String Table.  In this example, the next seven values will be the String Table contents. Consider this data structure to be similar to that of an array in that each value has an index that corresponds to the values in the Payload (discussed next).

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

Payload

1. Consists of numeric values used to reconstruct the method call and parameters in the String Table. For example, 1 refers to the second element (http://localhost:8080/testproject), 2 refers to the third element (29F…), etc.
2. These values for the most part should not be fuzzed. Since the payload values are used to reconstruct the method call on the server changing them to anything that will create an invalid call which will result in a request error.
3. There are a few caveats which I’ll get into more detail as we progress.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

The first four values of the payload can be expected to appear in every GWT RPC request. The first two values consist of the directory containing all the Javascript that was generated during the GWT compiliation and what looks to be an identifier for the Service. Regardless of their meanings, their contents should not be fuzzed as the values are not taken into consideration by the server. The next values “com.test.client.GreetingServer” and “greetServer” corresponds to the server side service name and method name that will be called. Altering these values to an incorrect class or method will cause an exception to be thrown and returned in the response if the exception is not properly handled by the server.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

This is where the Payload gets a little more interesting … The fifth payload value (2) actually tells you how many method parameters are being sent. In this example the user is sending two parameters; since two parameters are being sent, there are two subsequent payload values (5|5 in this case) that refer to the indices of the String Table containing the data types of the parameters.  In this example, The Java data type of both method parameters is java.lang.String.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

The final two values refer to the indices of the String Table containing the actual string values that are being passed in the method. These are the primary subjects for application-level fuzzing. It’s worth noting that integer values that are sent as parameters will be appended to the payload rather than being stored in the String Table. Integer values can be modified, however since Java will be expecting an integer value you will be limited to only numeric values.

5|0|7|http://localhost:8080/testproject/
|29F4EA1240F157649C12466F01F46F60|
com.test.client.GreetingService|greetServer|java.lang.String|
myInput1|myInput2|1|2|3|4|2|5|5|6|7|

Keep in mind that this was a walkthrough of a request with primitive data types. In reality, developers can be sending custom objects or more complex common Java objects such as Vectors, Linked Lists, etc. These data types will follow a different protocol for reading values from the String Table and Payload. To properly de-serialize these types, I found it easiest to capture sample requests and script the de-serialization.  I am planning to share this research and my script for automating the fuzzing of GWT RPC applications in an upcoming blog post.

Overview

Adobe Flex is a software development kit released by Adobe Systems for the development and deployment of cross-platform rich Internet applications based on the Adobe Flash platform. An instance of a DOM-based Cross Site Scripting (XSS) vulnerability was found in the default index.template.html file of the SDK which is a template used by FlexBuilder to generate the wrapper html for all application files in your project. The XSS vulnerability appears to affect all user’s that download and utilize this html wrapper. For more information on DOM-based XSS visit OWASP’s site.

Technical Details

File: index.template.html

1) Data enters via URL parameters through the window.location javascript object, is then stored into MMredirectURL variable, and passed to the AC_FL_RunContent() function.

Line 59:
..snip..
var MMredirectURL = window.location;
..snip..

Line 63:
AC_FL_RunContent(
..snip..
"FlashVars", "MMredirectURL=" MMredirectURL '&MMplayerType=' MMPlayerType '&MMdoctitle=' MMdoctitle "",
..snip..

2) The MMredirectURL variable with user-controllable input is passed to AC_GetArgs and ultimately to AC_Generateobj, which performs a document.write. Writing the un-validated data to HTML creates the XSS exposure.

File: AC_OETags.js

Line 200:
function AC_FL_RunContent(){
var ret =
AC_GetArgs
( arguments, ".swf", "movie", "clsid:d27cdb6e-ae6d-11cf-96b8-444553540000"
, "application/x-shockwave-flash"
);
AC_Generateobj(ret.objAttrs, ret.params, ret.embedAttrs);
}

Line 178:
function AC_Generateobj(objAttrs, params, embedAttrs)
{
var str = '';
if (isIE && isWin && !isOpera)
{
str = '<object ';
for (var i in objAttrs)
str = i '="' objAttrs[i] '" ';
str = '>';
for (var i in params)
str = '<param name="' i '" value="' params[i] '" /> ';
str = '</object>';
} else {
str = '<embed ';
for (var i in embedAttrs)
str = i '="' embedAttrs[i] '" ';
str = '> </embed>';
}
document.write(str);
}

NOTE: For the exploit to work, the end user must have installed an older version of Adobe Flash than the value that is set in the Globals variable “requiredMajorVersion” (Line 36).

Proof-of-Concept Exploit

This vulnerability can be exploited against any Flex based application that uses the index.template.html wrapper page containing the code above. In order to exploit this issue, the end user must have Adobe Flash installed, but it must be an older version than the required one set by the application owner (set in Globals variable “requiredMajorVersion”).

Reproduction Request:

http://FlexApp/Flex/index.template.html?”/></object><XSS attack string goes here>

Recommendation

Update to Flex 3.4 SDK or view Adobe’s TechNotes on how to manually fix the issue.

So how can SQL Injection, which is an application level problem, be used as a vector for attacking an organization? In a number of ways. SQL Injection gives an attacker the ability to interact with the database, and therefore if something is possible on the database server it may well be possible through SQL Injection. Modern database systems such as Oracle, SQL Server and others provide a rich variety of functionality for their users – all too often though, some of this functionality can be abused by malicious individuals.

Making some assumptions, its likely that something like the following occurred:

1. It was possible to interact with the underlying operating system in some way using SQL Injection. This could have been through the ability to execute operating system commands (such as through the well known xp cmdshell stored procedure on Microsoft SQL Server), or through the ability to stage content to the database server (or filesystem) and then have it compiled to executable content.
2. With the ability to execute content at the operating system layer, access was consolidated by providing some form of alternative control channel or remote access to the database server.
3. With consolidated access to the database server, the attacker uses the database server as a foothold to go further into the organization.

These types of hybrid attacks where one type of attack is dovetailed or launched over another are becoming increasingly common. Another SQL Injection hybrid attack of recent note was the SQL Injection mass attacks that started in early 2008. These used SQL Injection in another way – to inject links to JavaScript malware into thousands of unsuspecting vulnerable sites. It just goes to prove that even if a vulnerability is over 10 years old, it still has some new tricks to be seen.

The decision to open-source SPF was an easy one.  The biggest factor preventing several companies from implementing SPF in their production environment was the fact that it was neither commercially supported nor open source.  By moving SPF to an open source licensing model, more companies will have the option to experiment and hopefully use SPF to protect their web applications. 

The CodePlex platform also provides public issue tracking and a discussion forum that will hopefully benefit the SPF user base going forward.  Enjoy!

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.