When you configure Exchange 2003 for Outlook Web Access, you open yourself up to a particular kind of attack called a URL attack. In this article, Brien Posey explains what a URL attack is and what you can do to prevent it.
Although I read my fair share of articles and books on Exchange Server security, I have to admit there is one thing that has always bothered me. When the majority of these texts (including many of the ones that I have written) discuss Outlook Web Access (OWA), they tend to discuss things like front end / back end configurations, IP filtering, firewalls, and that sort of thing. You really don't see many Exchange related articles that talk about protecting an OWA server against a URL attack, even though URL attacks are one of the most common hacking techniques used against Web Servers. In this article, I will explain what a URL attack is and why it is so dangerous.
Before I begin
Before I get started, I want to point out that the security technique that I'm going to be showing you isn't going to help everybody. As you probably know, Exchange Server 2003 can be run on Windows 2000 Server or on Windows Server 2003. If you are running Exchange Server 2003 on a Windows 2000 Server, then this is definitely a technique that you want to pay attention to.
If, on the other hand, you are running Exchange Server 2003 on Windows Server 2003, then I'm sorry to say that this technique isn't going to help you. Microsoft has designed IIS 6.0 (which comes with Windows Server 2003) so that it does not need the URLScan add-on. Even so, Microsoft has recently released URLScan version 2.5 which isn't really necessary for IIS 6.0 Servers, but is supported by Microsoft for IIS 6.0 implementations.
Even if you are running Exchange Server 2003 on a Windows Server 2003 box, feel free to keep reading if you want to learn more about URL attacks or if you are interested in securing non OWA Web servers.
What is a URL attack?
Before I show you how to deploy URLScan, I want to talk a little bit about URL attacks. That way, you can really appreciate what I am going to show you later on. The idea behind a URL attack is that the hacker uses the Internet Explorer address bar as a mechanism for hacking the site, based on what the hacker already knows about the site and about Windows based Web servers in general.
If a hacker wants to attack a Web Server using a URL attack, the first thing that they need to do is to determine whether or not the server is a Windows box, and what language the site is coded in. This is a whole lot easier than you might think.
There are techniques that Web Administrators can use to make it more difficult to determine the server's operating system, and there are more sophisticated methods for determining an underlying operating system, but in most cases the Administrator does not use cloaking techniques, so advanced reconnaissance techniques are unnecessary. If a hacker is attacking an OWA front end server, the reconnaissance efforts are especially unnecessary because OWA will only run under Windows.
If you want to confirm that a Web site is running on a Windows box, look at the extension used for the page being served. If the file extension is .ASP or .ASPX, then you can be pretty certain that the Web site is running on a Windows Server because only Windows Servers host ASP (Active Server Pages) code. For example, take a look at the following URL from my own Web site:
Notice that the first part of the string consists of the HTTP header, the path to the page, and the page name (in this case display_forum_topics.asp). The fact that the page has an ASP extension is a pretty clear indication that the Web site is running on a Windows Server.
The next thing that I want you to pay attention to in the URL listed above is the last part, beginning with the question mark. The reason for the question mark is because ASP pages are compiled at the Web server. If you choose the Source command from Internet Explorer's View menu, the source code that you are seeing is not the actual source code for the page. The real source code is usually much longer and more sophisticated than what you see. An ASP page's job is to take the input that it has been handed and then create an HTML page based on the way that the ASP page has processed that input.
I know that this probably sounds confusing to those of you who aren't programmers, so I will try to make it a little easier to understand. If you visit the URL that we have been talking about, you will see that the page is the Networking portion of the site's Question and Answer forum. Take a look at the URL though. The name of the page is Display_Forum_Topics, not Display_Network_Forum Topics. The Web site has lots of different forums, but there is not a separate Web page for each forum. Instead, the Display_Forum_Topics.asp page contains a set of rules that control which forum will be displayed, based on the input that the page receives.
Any time that you see a question mark in an ASP URL, the portion of the URL following the question mark is a variable name used by the hidden ASP code, an equals sign, and a value that is being assigned to that variable. Go ahead and visit the URL listed above, but change the ?ForumID=10 portion of the URL to ?ForumID=9.
When you do, the site displays the Pocket PC forum instead of the Networking forum. You haven't gone to a different URL. You have simply manipulated the value of a variable, and in doing so ended up with a completely different screen being displayed. This is lesson number one for URL hacking. You can control a site's behavior by manipulating variables.
OK, I realize that switching forums by changing a ten to a nine is nothing spectacular, but it's the principle that matters. The Web page that I showed you is fairly simple compared to some. It is not uncommon for ASP pages to have many different input variables, all of which can be manipulated.
A lot of times hackers will even spend a lot of time going over a site with a fine tooth comb just so that they can take notes on what they can learn about a site prior to performing an actual attack. By surfing around an ASP site, visiting every page, trying every option, you can discover the names of many of the internal variables that are being used, and the paths to different pages within the site. I know that this sounds crazy, but I have personally used these and other techniques to break into unauthorized areas of Web sites (but only for legal, penetration testing purposes).
Before I go on talking about other hacking techniques, let's stop for a minute and talk about how URLScan could be used to prevent this type of exploit. So far I have talked about how a hacker can study an ASP Web site and figure out things like variable names and file paths and then use that information to control a Web site's behavior. Assuming that the hacker is feeding the Web site valid variable values, there really isn't a way to block this type of hack. After all, the Web application is simply responding to what it considers to be normal input.
The trick to stopping this type of hack is to make your Web server understand the difference between normal input and abnormal input. For example, earlier I showed you how changing a ten to nine altered the contents of a Web page. That particular action is harmless because nine is perfectly valid input and the Web site is responding to that input just as it is supposed to.
What would happen though if a hacker replaced the number ten with some weird, non ASCII character? Your guess is as good as mine. However, hackers do things like that. The idea is that if you give a Web site unintended input then you might be able to get the Web site to produce a buffer overflow error or you might be able to gain an unauthorized level of access to the site or crash a database, or anything like that.
URLScan's job is to filter out potentially malicious URLs. There are lots of different types of URLs that can be filtered, but one of the things that URLScan can look for is long bit (non ASCII) characters. Think about this in the context of an OWA front end server. There is no legitimate reason for anybody to be sending non ASCII characters to your OWA server. This means that if such requests do get sent to the server they are probably malicious in nature and need to be blocked.
SQL insertion attacks
So far I have only talked about very basic URL hacking techniques, but there is one other common exploit that I want to discuss. It's a variation of a URL attack called a SQL insertion attack. To understand how a SQL insertion attack works, you need to know a little bit about how ASP programming works.
If you look below, you will see a very simple ASP application that I wrote to read a list of last names from an Access database and then display those last names in alphabetical order. Let's take a look at some ways that this simple block of code could be exploited through a SQL insertion attack.
To understand how a SQL insertion attack works, imagine that you've got a very simple application that asks you to enter your name. Your name is then written to a database and then read from the database and displayed on the screen for verification. The program sounds innocent enough, but what would happen if instead of typing in my name, I entered some ASP source code instead?
Depending on how the application is setup, the source code could be written to the database in place of a name. When the application goes to read my name from the database, it would actually be reading a block of code that I inserted instead. Depending on what method the application uses to write my name to the screen, it could actually end up executing the code. This is how one type of SQL insertion attacks work.
So what does this have to do with URL hacks? Keep in mind that an ASP application's job is to produce HTML code based on the input that it is given. If an application is asking me to enter my name, then the ASP code has already executed. It created the HTML page that is asking for my name. Simply entering my name alone doesn't do anything because the page has finished executing.
If you wanted an ASP application to take the name that has been entered and write it to a database, then you would have to reload the page, using the user's input as data. The most common method for doing so is to use the HTML form action command to pass the user's input back to the ASP page as a parameter embedded in the URL. That way, the page will be reloaded and will be able to process the user's input. The point is, though, that the user's input is usually passed as a parameter within the URL (http://www.domain.com/path/filename.asp?variable=input)
What I am trying to show you is that whether input is entered from within an HTML form or entered directly into the URL string, a legitimate variable can be substituted with malicious code (usually laced with SQL commands, hence the name SQL insertion attack).
Whether you are protecting your own Web application or an OWA server, there are several ways that URLScan can protect you from this type of attack. One thing that USLScan can do is to limit the length of the URL string. Think about it for a moment. If a hacker is including code within the URL, the URL is going to end up being really long in most cases. Why not limit the length of the URL so that IIS will ignore any URLs that are longer than what is necessary for legitimate usage? Another reason why you should limit URL lengths is because excessively long URLs have been used in buffer overflow exploits.
There are many other ways that URLScan can protect your server by filtering out various types of malicious URLs. Hopefully though, I have given you an understanding of why URL filtering is important. If you want to download URLScan, you can find it Microsoft's Web site.