.NET Numeric Overflow
When programming with Microsoft .Net, there is not as much concern for overflow vulnerabilities. With the managed runtime, buffer overflows are handled for the most part. However, there is still the possibility for numeric overflows. A numeric overflow exists when arithmetic is performed on two values causing the result to roll past the max or min of the specified data type giving an unexpected result.
For example, say that you are adding two “Short†values together. A short is an unsigned value ranging from (–32767) – 32767. Lets look at the following operations:
32767 + 5 = 32772
This simple math operation creates what appears to be a valid, expected result. However, a “short†cannot contain a value that high. So what really happens when we try to add these values together as 2 “shorts†being stored in a “short�
32767 + 5 = -32764
Notice how the result is now at the opposite spectrum from what was expected. This happens because the most significant bit is saved for the sign. When we add these numbers together using binary form (which the computer uses) the carry over changes the sign and the overall value.
This could cause a big problem in an ecommerce type of site where price and tax are added together as one example. The user modifies the price so that when the tax is added, the total rolls over (like a odometer in our car) and now the customer has a credit in stead of a debit.
The following code snippet shows a few different ways that .Net handles numeric overflows. “Shorts†are used but this applies to other numeric types as well. I will discuss each of these techniques below.
1: short x = short.MaxValue; // 327672: short y = 5;3: short z;4:5: z = x + y; // Design Time Error!!6:7: z = (short)(x + y); // -327648:9: z = checked((short)(x + y)); // OverFlowException10:11: checked12: {13: z = (short)(x + y); // OverFlowException14: }15:16: unchecked17: {18: z = (short)(x + y); // -3276419: }20:21: y += x; // -32764Line 5 – This code will cause a design time error so it will be caught before you can successfully build your application. The reason this causes an error is that the (+) operator for two shorts is overridden to return an “intâ€. This would make sense that the two values could be greater than the max value of a “short†and to protect itself, the framework upgrades to an “intâ€. If z had been declared as an “int†this would not cause a problem.
Line 7 – To remediate the design time error, this example casts the result to a “shortâ€. However, as shown in the comment, the value overflows and the result is not what is expected by the developer.
Line 9 – This example builds upon the last example, but wraps the operation in the “checked†method. The “checked†method will check to see if the operation overflows the result and if so, throws an OverflowException.
Lines 11-14 – This is the same concept as the last example, but uses a “checked†block instead of the method. This is useful if there are multiple operations that need to be performed near each other. It will also throw the OverflowException.
Lines 16-19 – Here we are going to tell the runtime we do not want to check the values. This will not throw an exception and the result could be different that what is expected.
Line 21 – Finally, this example shows how the different operations have different results. We saw in the first example in Line 5 that the + operator returned an “int†datatype. When using the “+=†combination, the return value is of the original type. So in this instance, it will return a short. Notice this will not throw a design time error or the runtime error. It is susceptible to overflow and could lead to an unexpected return value.
These are very simple examples to demonstrate what numeric overflows are in .Net, how they can present themselves, and what methods .Net provides to help protect against them. These are just examples and are not meant to be used for production environments. Use this information at your own risk.
Bypassing ValidateRequest
Back in August 2009 (https://jardinesoftware.net/2009/08/27/validaterequest-property-xss/) I wrote about the Validate Request functionality and how it doesn’t do a good job of protecting against Cross Site Scripting in an attribute context. In this post, I am going to explain another technique that can be used to bypass the Validate Request filter in an html element context. This technique uses a different character encoding to bypass the blacklist checks that are done.
To recap, the Validate Request returns false when the following conditions are met:
- <a-z - A < character followed by an alpha character.
- <!, </, <?
- &#
As you can see, the main goal is to trigger an error when the less than (<) character is passed followed by a specific set of characters. Since it blocks the start character for an HTML element, it makes it difficult to just add new elements to the page. So how do we get around this? Using Unicode-Wide characters, we can pass in a character that looks like the < character, but it really isn’t. That character is represented at the value %uff1c. If this value is passed to a varchar field in a SQL database, it will get converted to the real < character. I have not seen this work on a nvarchar field. If this value is than returned to the browser without proper encoding, cross site scripting is possible. Lets take a look at how this works from an example.
- Create an XSS payload for a susceptible field (<script>alert(9);</script>).
- Change the opening and closing signs to use unicode-wide representation (%uff1cscript%uff1ealert(9);%uff1c/script%uff1e)
- Submit the data to the server.
- The data is stored in a varchar field.
- Retrieve the data without any encoding.
- Cross Site Scripting ensues with an alert box with the value of 9.
I have only seen persistent cross site scripting work for this. I have not seen this work in a reflective manor.
This example shows how important output encoding is for remediating cross site scripting vulnerabilities. Input validation important, but not completely bullet proof. The only way to make sure the code is safe is during the output routine.
ASP.Net 4: Change the Default Encoder
Filed under: Development, Security
In ASP.Net 4.0, Microsoft added the ability to override the default encoder. This is specifically focused on the HTMLEncode, HTMLAttributeEncode, and URLEncode functionality. These functions are used, in the eyes of security, to help mitigate cross-site scripting (XSS). The problem with the built in .Net routines is that they are built on a black-list methodology, rather than a white-list methodology. The built in routines use a very small list of characters that get encoded. For example, the .Net version of HTMLEncode encodes the following characters: <,>,â€,&. The Microsoft Web Protection Library (previously known as the Anti-XSS Library) instead determines all characters that don’t need encoding, a-z0-9 for example, and then encodes all the rest. This is a much safer approach to encoding.
In this post, I will show you how to use the Web Protection Library as the default encoder for an ASP.Net 4.0 application. The first step is to download the Web Protection Library. In this example, I use version 4.0 which can be found at: http://wpl.codeplex.com/.
Next, you will need to have an application to implement this. You can use an existing application, or create a new one. Add a reference to the AntiXSSLibrary.dll found in†Program Files\Microsoft Information Security\AntiXSS Library v4.0â€.
To use the library, it is time to create a new class. You can see the code in my class in Figure 1. I named the class “MyEncoder†and this is just a sample. (THIS IS NOT PRODUCTION CODE) There are two important factors to this class:
1. The class must inherit from System.Web.Util.HttpEncoder.
2. You must override each Encode Method you want to change.
If you only wanted to update the HTMLEncode and leave the other methods alone, just leave them out of the class.
Figure 1
using System;using System.Web;public class MyEncoder : System.Web.Util.HttpEncoder{public MyEncoder(){}protected override void HtmlEncode(string value, System.IO.TextWriter output){if (null == value)return;output.Write(Microsoft.Security.Application.Encoder.HtmlEncode(value));}protected override void HtmlAttributeEncode(string value, System.IO.TextWriter output){if (null == value)return;output.Write(Microsoft.Security.Application.Encoder.HtmlAttributeEncode(value));}}The final step to implementing this custom encoding is to update the web.config file. To do this, modify your httpRuntime element to have the “encoderType†attribute set, as seen in Figure 2. Change “MyEncoder†to the name of the class you created. If you do not have the httpRuntime element, just add it in.
Figure 2
<system.web><compilation debug="true" targetFramework="4.0"/><httpRuntime encoderType="MyEncoder"/>.....Although it would be really nice if the .Net Framework would just start using the Web Protection Library, they are just not ready for that yet. It is important that plenty of testing is always done when working with output encoding. Different encoders produce different outputs and may cause display defects. It is also important to note that this only effects items that get auto-encoded by the framework. For example, a text property of a textbox.
This is just a small example of modifying the default encoding type of your application. There is much more that you could potentially do with this. This is just a sample and this code is NOT FOR PRODUCTION USE.
Cyber Security Competitions for Students (Fall 2011)
June 16, 2011 by James Jardine · Comments Off on Cyber Security Competitions for Students (Fall 2011)
Filed under: SecurityAs the school hear is wrapping up, it is time for individuals and teams to start preparing for some upcoming cyber security challenges. What does every student want to think about over the summer break? More work, right? The good news: this can be fun and challenging. I am talking about Cyber Patriot IV and Cyber Challenge. Both competitions will be taking place in the fall of 2011.
Are you interested in Cyber Security? Do you like working with computers and want to be challenged? Are you thinking about going into the Information Technology field in the future? If you answer YES to any of these questions then these competitions are for you. Even if you didn’t answer yes, you may find out that you actually like this world.
Read the news on any given day and you can probably find a breach happening at a major company. Recently we have seen Phone companies, banks, and others suffer from cyber incidents. These companies need strong candidates to help protect their assets and company from cyber criminals. Don’t forget the country as well. Many acts of war are committed online and the defense of our country will move more to cyber activities.
There are a few challenges that are available to students. Each one has its own requirements and/or fees that are available on their web sites. Some require small teams where others are completed by individuals. So lets talk about a few of them.
Cyber Patriot IV
http://www.uscyberpatriot.org
There are two divisions of the competition, an all service division which is ROTC type, and then an open division which is for high schools.The primary goal is to have students work to protect a virtual machine. It consists of multiple rounds of competition. The organization will supply each team with an identical Virtual Image, for example Windows Server 2008. It will have pre-determined vulnerabilities (virus, malware, bad users, poor password policies, no logging, etc) and the students will get 6 hrs to secure the system. During the six hours, the virtual machine is connected to a scoring engine online that is looking for 10-20 items that need fixing. There may be more than that, but only these (which are not specified) count. Students can check their scores during the competition to see how they are doing. This really helps build up their ability to properly secure a computer.
The final rounds are held in Orlando and Washington DC (at least last year they were). If the team is successful enough to make it to DC, there is actually a red team (hackers) actively attacking the machines that the students are defending.
This is a really fun competition for students of high school age. It gives them hands on experience working with different types of computers. During the competition, the images can be Windows or Linux based.
Cyber Challenge
http://workforce.cisecurity.org/
The cyber challenge is quite different from Cyber Patriot in the fact that it consists of online videos and training materials that the students study. At pre-determined times, an online quiz is available for them to test their knowledge. It is not as hands on as Cyber Patriot, but helps build knowledge that is needed for Cyber Patriot. The main focus is on Networking fundamentals and Operating Systems. The training material is provided by SANS under the title Cyber Foundations(https://www.sans.org/cyber-foundations/).There are other challenges as well that you can see at the Cyber Challenge Site. One of those is DC3 which is more geared to digital forensics.
Get Involved
There are many schools that are not aware of these competitions. If you have any contacts with any high schools help spread the word about these different competitions. Lets help these students get the opportunities that can help them grow and learn.ASP.Net Value Shadowing
Value shadowing occurs when the developer does not specify the specific collection to pull a value from when multiple collections exist in the same context. The Request object is a great example of this. The Request object contains Querystring, Form, Cookies, and ServerVariable collections. Normally, if a developer wanted to access a value from a form variable, they would use something similiar to the following code snippet:
1: string str = Request.Form["myValue"].ToString();The above code snippet accesses a specific collection within the Request object. They could also access that value using the below two lines of code:
1: string str = Request["myValue"].ToString();2: string str2 = Request.Params["myValue"].ToString();The above code snippet is susceptible to value shadowing because it does not specify the specific collection. ASP.Net will loop through each collection until it finds the key name specified and take the first value. The loop starts with the QueryString collection, then goes to Forms, Cookies and finally Server Variables.
UPDATE: ASP.Net Server Controls do not use the Request.Params collection as previously stated. The framework determines if it is a POST or a GET and passes the correct collection to be parsed. However, the following information still stands true.
It doesn’t matter if the form is set to GET or POST, it will still be able to populate the control properly. This feature is great for ease of use and having some nice generic code, but what about security? Lets look at how this can cause a security problem if not properly handled.
Cross Site Request Forgery (CSRF)
This article assumes you already understand what CSRF is and how it works. If you don’t, do a quick Google search and it will clear it up. CSRF can be done using POST or GET, but GET is much easier to implement. By default, ASP.Net forms and other functionality work via the POST method. If we could submit a GET instead of a POST it would open up the attack surface a great deal. No longer do we need someone to visit a page with a form on it, but we could actually embed the GET request (a link) in emails or other medium.
Fortunately for the attacker, unfortunately for the developer, .Net uses Value Shadowing for its controls. This means all server side controls, ie. Viewstate, EventValidation, EventCommand, EventArguments, etc.. It is possible to take the values that would be submitted as part of the form and just add them to the Querystring instead. Now there is a GET request that is comparable to the POST request. ASP.Net Webforms does not check whether a post back comes from GET or POST. The one thing to keep in mind is that the URL in a GET is limited in size. If the form is large and the viewstate is very large, this could block this technique from working. This depends on the way the application is configured (more later).
Login Via GET
When working with a login page, it is important that you protect the user and their credentials. There are many reasons why this is important, for example, compliance, privacy, etc.. Logins should be done only via a POST request. One reason for this is because a GET request is logged in log files (IIS). Even if the url was https, a login via GET would log the username and password in the logs. This is a big no-no. As I have just shown, it is possible to login via GET if you wanted to in most ASP.Net webform applications. Most developers will not check to actually see if the request is a POST and enforce it. If the dev did enforce this, you could still submit the values, but it would be worthless unless you could gain something from it.
One way the developer could block logging in via the GET is by checking the HTTPMethod of the Request object like this:
1: if (Request.HttpMethod == "POST")2: {3: //Do Login4: }What It Means
The two above scenarios show the base techniques to create other attacks. The key is that the Page.IsPostBack property doesn’t look to see if the form is a POST, it is looking that specific variables are present in the Request (ie. Viewstate, EventValidation, EventArguments, etc). It is important for developers to understand this so they can properly protect against it.
Protection Mechanisms
There are a few different ways to help protect against these issues.
One way is to check the HttpMethod as in the previous code sample.
Another way is to actually check to make sure the values come in the collection you expect them to. If you expect POST variables, make sure they exist in that collection.
MAKE SURE EventValidation is enabled. This is important because when EventValidation is enabled, it will validate the ViewState data. If EventValidation is disabled then you can cause a valid Postback by just sending an empty __ViewState value in your querystring. ViewState can be very large so by requiring it, it can block using the querystring because of its length.
MAKE SURE you use the ViewStateMAC. This helps stop the ViewState from being tampered with.
MAKE SURE you set the ViewStateUserKey to a user unique value. This is VERY IMPORTANT!. When this is properly set, most of the above methods to attack will not be successful. Lets take just a moment to talk about this.
When you use the ViewStateUserKey, it adds a special value to each user’s ViewState. To perform CSRF, the attacker needs to preset the attack vectors with values they have obtained. When they create the page, the ViewState they submit (which should be required if you are enabling EventValidation) would be different than the ViewState you would get. This would block this attack from working. In the case of the Login Via Get, the ViewState would change for each session (roughly each time you log in) and would decrease the reasons for doing this.
Summary
The benefits of how ASP.Net handles these collections to create their objects are huge. However, they must be handled with caution. Make sure you are properly following Security Best Practices and you are testing your functionality to make sure it is secure. I do not try to cover every possible example or attack vector. Instead, I try to get the idea across so developers can have a better understanding and produce more secure code.
Microsoft’s SDL Process Guidance 5.1 Released
April 20, 2011 by James Jardine · Comments Off on Microsoft’s SDL Process Guidance 5.1 Released
Filed under: Development, SecurityApril 14th, Microsoft released their annual update to the SDL Process Guidance. The updated document can be downloaded from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=e5ff2f9d-7e72-485a-9ec0-5d6d076a8807&displaylang=en. Microsoft has done a good job of updating their SDL documentation to help cover the most important items. Here are some of the changes made in this release (Not all updates are included here).
Design Phase
Mitigating against Cross-Site Scripting (XSS). XSS has topped the OWASP Top Ten for a long time. In the most recent version it is ranked as #2 on the list. The document provides some tools to help protect against this. One recommendation is to use the Microsoft Anti-XSS Library to encode untrusted output.Apply no-open header to user-supplied downloadable files. More details are in the document, but this specifically applies to the X-Download-Options HTTP Header.
Implementation Phase
Use Secure Methods to access databases. This is related to SQL Injection vulnerabilities. Use Parameterized queries or stored procedures rather than dynamic sql. Use least privilege.Don’t use Visual Basic 6 to build products. This is a push to get away from VB6 and entirely into .Net.
Ensure that regular expressions must not execute in exponential time. Recently, it was brought up that an improperly formed regular expression could cause a denial of service with specially crafted input. Use the RegExFuzzer to test all regular expressions.
Use Secure Cookie over HTTPS. Make sure that authentication cookies and other secure cookies have the “Secure” flag set to only allow transmission over SSL.
Mitigate against Cross-Site Request Forgery (CSRF). See the document for more details.
Sample Code should be SDL compliant. I think this is something that should have been required all along. There are a few reasons for this. First, often sample code turns into production code. Developers learn from sample code, so if the sample is insecure, chances are good that the new code will also be insecure.
Verification Phase
File fuzzing when input to a file parser crosses a trust boundary. Fuzzing is the newest trend in effectively testing file parsers. If data is going to a file parser, fuzzing is a must.Classic ASP (Data Type Issues)
March 29, 2011 by James Jardine · Comments Off on Classic ASP (Data Type Issues)
Filed under: SecurityIt has been a long time since I have spent any time working with some classic ASP code. After spending so many years focusing more on Microsoft’s .Net platform, I see why people make the switch. My task was to update some old inline SQL calls (yeah, I know) to stored procedures or parameterized queries. The list of calls was fairly small, since most of the calls were already stored procedures. Things should have been nice and simple. Create the stored procedures, add some command objects with parameters and we are good to go. Unfortunately, there were a few hiccups, mostly around data types.
I ran into two issues that really through me for a loop. The first was while trying to pass a bit parameter. I set my parameter type to adBoolean, which I thought was right, but every time I would test the call it would not update my table. Before narrowing this down to the bit field, I tried transactions, GO statements, anything I could think of with no success. I then removed this parameter and was successful. I tried many different settings to get the adBoolean to work correctly, and it never did. The worst part was that it didn’t even give me an error, it just acted like everything was ok. I ended up using two different stored procedures around the bit field. Not an ideal solution, but it works on this type of application.
Next, I ran into an issue with the Money datatype. Setting my parameter to adCurrency gave me the exact same results as the previous parameter. No error, and no update. For this small query, I actually just did a parameterized query instead of the stored procedure.
If anyone has any ideas on why this wasn’t working, please post them in the comments. The stored procedures are straight forward with inputs like @myMoney Money or @myBit bit.
It is not often I deal with classic ASP, and I think I know why now. In most cases it would not have been that bad, but in this case, the ability to debug and test were very limited, adding to the complexity of the problem. The good news is that the changes are done and the code is a bit safer now.
Cyber Foundations 2011
If you are just hearing about the Cyber Foundations 2011 National Competition, you can start preparing for next year. The deadline to enter into this competition was February 25th, 2011. So what is this competition? It is a talent search for high school students with foundational skills in cyber security. The website (https://www.sans.org/cyber-foundations/?utm_source=web-sans&utm_medium=text-ad&utm_content=Featured_Links_Homepage_CyberFoundations_Home&utm_campaign=CyberFoundations_Home_Page&ref=64688) has many great resources and training videos to get the students started.
The competition covers three different modules, each containing a test at the end. Anyone can sign up to preview the first module to get a better understanding of the information covered. For students to compete the registration fee is $75 per student. The information is well put together and captivating.
As the Competition progresses, I hope to provide more information about it here. This is the first year that this has been available so I can’t wait to see how it goes.
Reflector Goes Commercial
Today appears to be the last day to download Red-Gate’s .Net Reflector tool for free. The Reflector tool disassembles .Net assemblies back to .Net code (sort of). This is very useful to be able to grab an assembly, and not only look at the methods it contains, but also to view exactly what that method does. For those of you that have read some of my previous posts about ValidateRequest, or XSS, much of the information is found by using reflector to see how the methods are working.
Red-Gate has realized that maintaing the tool is not possible when it is free. This move has definitely stirred up the message boards, upsetting a lot of users. Starting at $35, it is worth the price. Reflector comes in very handy when doing security assessments on applications where you have access to the assembly, but no source code.
Lets hope that Red-Gate’s decision to commercialize all versions of this tool doesn’t have too much of a negative effect.
DropBox Job Description – A Step in the Right Direction
February 17, 2011 by James Jardine · Comments Off on DropBox Job Description – A Step in the Right Direction
Filed under: SecurityI recently logged into my DropBox account and noticed that the landing screen had a notice about current job openings. I thought I would take a look at what they had available. I clicked on the Web Engineer position (http://www.dropbox.com/position?jvi=orflVfwG,Job) and was impressed to see one of their requirements: “You’ve seen CSRF and XSS in action and know how to prevent it from happening.†Now I look at a lot of job openings and it is rare to see this type of security topic included in them. I am confused at why they did not also mention SQL Injection, as it is the worst of the worst, but this is a step in the right direction. This is the type of requirements we need to start seeing on job requests to help join the cultures of development and security.
Follow Us
