Intelligent Application Gateway Product Team Blog

How IAG 2007 Can Mitigate Against SQL Injection Attacks – Demo Scenario

1. Introduction

 

SQL Injection is a potential threat to any web application that has an SQL based database backend.  This is true not just for Microsoft SQL backend but any web application on any OS with an SQL database backend.  There are lots of applications and application developers that didn’t or still don’t follow guidelines designed to mitigate or avoid this type of vulnerability.  The questions that keep coming to the Forefront Edge Security Team about this is: can we mitigate this threat anyway at the edge before the injection reaches the SQL database? IAG 2007 can help you on that. With IAG 2007 administrations can specify the allowed parameters and return values from each field in the application that interacts with SQL and therefore mitigate possible SQL Injection attacks.

 

It is very important to realize that ideally this mitigation should be done in the source code of the web application, rather than by using a device on the edge, as this is more of a bandage than a fix.  This is because the application will still be vulnerable to attacks originating from the internal network and not passing the edge, as well as also not being protected against the possibility of administrators having missed some mitigation on the edge device which could have been done better in the application code.  The bottom line is don’t use the edge as your ultimate protection mechanism for this type of attack.

 

Before we move on to the sample implementation, it is recommended that you review the following articles that provide details about SQL Injections and the ways to mitigate the problem in applications:

 

 

2. Weak Application Code – Sample

 

For this example we are going to use Nazim’s (from IIS Team) SQL Injection Demo code that he wrote for his blog. Nazim provides a very interesting example of how you can easily create weak code and what can happen when you do this.

 

3. Configuring IAG to publish the Web Application and inspect the traffic

 

The first step is to publish the web application:

·         Follow Nazim’s blog to create the database and the asp code

·         Create a website in IIS (it works perfectly with IIS 6)

·         Add the two pages to the new website and put the web server behind IAG.

·         Create a portal trunk in IAG

·         Add a Generic Web Application to the newly created portal trunk

·         Set the Application Type to SQL

·         Follow the wizard to point the application to the web server & site you created with Nazim’s code

·         Configure the Portal Link to have something like the following URL:

 

 

Figure 1 – Portal Link URL for this example.

 

After completing the configuration of the Web Application in IAG, follow the steps below to configure the URL Set that will block the SQL Injection attempts:

 

1.       Select the Portal Trunk that you created the web application on.

2.       Click the configuration button next to Advanced Trunk Configuration.

3.       Click on the URL Set tab.

4.       Look for the rule name that starts with the Application Type of your application.  Look for this rule in the Name field (for this example the application type is SQL ) and click on it.

5.       Change the Parameters column from Ignore to Handle

6.       Make sure that the methods are set to be POST and GET.

7.       Change the Parameter List according to the Figure 2:

 

 

Figure 2 – URL Set configuration.

 

Here is the real deal of this implementation: you need to know the application that you are publishing and know exactly what the parameters are, in order to make this configuration. By parameters, we refer to  both query string parameters as well as to POST-ed form fields sent from the client as HTTP data. IAG collects both of these and then analyses them, one by one, against the specific rules configured. For this example the following fields were used:

 

Name	Name Type	Value	Length	Existence
Name of the parameter. This can be specified as the real parameter, as it appears in HTTP requests, or as a regular expression	The type of the parameter’s Name field. ·         String: The parameter name is the real parameter, as it appears in HTTP requests ·         Regular expression: this can be used in order to create one single definition that matches multiple parameters	The valid characters that can this parameter’s value can hold. Here you will type values using Regular Expression that can cover the valid strings that this field should accept.  You have the option to leave this field empty, in which case the Value requirement is not enforced by IAG, but still other requirements, like Length and Existence, are enforced.	Length of this parameter. This field accepts a range. For example: ·         4:10: means four to ten chars in length are allowed ·         4:4: means only exactly four chars in length are allowed	Possible values: ·         Mandatory: parameter must exist in the request ·         Optional: parameter may or may not exist ·         Reject: HTTP request will be rejected if this parameter appears in it

 

1.       After making the above changes, click OK.

2.       Click Activate to apply the changes.

 

Now that IAG is configured and ready, it’s time to test the examples from Nazim’s SQL Injection Demo blog post.

 

First example will be:

 

·         Test 1 - Bypassing login for a known user. Let's say we know user 'Yuri' exists and using the '--' for commenting out the rest of the conditions in the query:

o   Username: Yuri'--

o   Password: nothing

 

IAG will intercept the traffic and it will display an error.

 

 

Figure 3 – Error that the user receives when clicking on Submit.

 

Going to IAG 2007 Web Monitor we have the following event:

 

 

Figure 4 – Parameter that was flagged as invalid.

 

If we try example 4 from Nazim’s SQL Injection Demo blog post we will have:

 

·         Test 4 - Injecting a new user. Let's say I want to add a user 'Hijack' with password 'This'.:

o   Username: ';INSERT INTO Users VALUES (100,'Hijack','This')--

o   Password: nothing

 

When user tries to do that the following warning will appear in the IAG Web Monitor and the user will receive the same error as in Figure 5.

 

 

Figure 5 – Another attempt to exploit the application by inserting a new user.

 

4. Conclusion

 

This post gives you an overview on how IAG can be used to help mitigate SQL Injection attacks coming from external users against applications that are published through an IAG Portal. As explained above, while this is a good step, this is not the definitive answer for fixing SQL Injection problems in your environment.  This does go a long way in preventing a problem, but the root cause is unchanged and until it’s resolved and the application is written securely, the potential for problems will continue to exist.

 

 

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

 

Technical Reviewer
Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

 

Ran Dolev
Security Consultant – IAG Team
Microsoft – Israel

 

 

ISA 2006 SP1 and IAG 2007 Supportability Statement

Introduction

 

Occasionally you find the combination of two things that result in something better than the sum of the individual parts. Some combinations that come to mind are peanut butter and chocolate, steak and lobster, and ISA Server 2006 and IAG 2007. You can’t eat ISA and IAG but combined in the IAG 2007 product they create an awesome SSLVPN with rich features. Just like a good soup, IAG 2007 benefits from high quality ingredients. For more information on this “better together” approach review the articles below:

http://www.microsoft.com/forefront/edgesecurity/iag/en/us/secure-remote-access.aspx

http://www.microsoft.com/Forefront/edgesecurity/iag/en/us/faq.aspx

 

Real World Experience

 

Recently, I began seeing questions about the addition of ISA 2006 SP1 on customers IAG 2007 systems. After some research it turned out that Windows update was detecting the lack of ISA 2006 SP1 and prompting administrators to install the service pack on their IAG 2007 servers. If you are familiar with IAG 2007 predecessor eGap 3.6 you will remember that the internal server was protected by a SCSI interface that shuttled between the external and internal servers. In IAG 2007 the external server and SCSI interconnect have been removed and replaced by ISA 2006. In this configuration ISA 2006 protects the external interface of IAG 2007 amongst other things.

Since SP1 for ISA 2006 includes feature updates as well as security updates, just like any other windows application it is essential to make sure there is no security vulnerability that might affect the ISA application. Hence it is important to make sure the ISA server is also updated from time to time.

When you first initialize the IAG 2007 system you will notice that ISA server 2006 is installed as well. As applications are added to the portal trunk, rules are created in ISA 2006 to allow the specific traffic types that IAG 2007 will publish. If IAG 2007 is configured for automatic updates or you visit the Windows update site, SP1 for ISA 2006 will be queued for installation if it is not already installed. You can review the benefits of SP1 for ISA 2006 by following this link: http://blogs.technet.com/isablog/archive/2008/05/23/isa-server-2006-service-pack-1-features.aspx

As you can see from reading the list we fixed a few things in ISA 2006 with SP1. In addition, patch management is part of the Desktop, Device, and Server security process best practices that IT professionals should be following. Recently, while testing IAG 2007 SP2 our product group tested with ISA 2006 SP1 installed and found no issues related to this service pack. So go ahead and add ISA 2006 SP1 to your IAG 2007 system. I bet you will find it’s a great combination and is a high quality ingredient in your security soup.

 

Author

Dan Watson

Security Support Engineer –IAG Team

Microsoft – NC

 

 

Technical Reviewers
Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

 

Mohit Saxena

Security Technical Lead – ISA/IAG Team

Microsoft – Washington

 

Certificates on IAG 2007

1. Introduction

 

The use of Digital Certificates with IAG 2007 is essential for several IAG authentication and access scenarios as well as for providing encryption of sensitive data. There are two main scenarios when using certificates; it is common to have misunderstandings about which scenarios each type of certificates are used. The first article of this series will give you an overview of the different types and usages of each certificate when you are using IAG 2007.

 

2. When does IAG use Certificates?

 

The diagram below shows the various scenarios where IAG uses certificates for authentication and/or data encryption:

 

Figure 1 – IAG SSL Communication

 

This diagram shows the two parts of the communication when IAG 2007 is used to allow external access to internal resources. The main purpose here is to define which type of certificates are involved when each communication happening, therefore let’s see the following table:

 

Communication Channel	Certificate Type	Certificate Usability	Where the Certificate is Installed
Client to Server	Client Authentication	·         Client authentication ·         Endpoint Detection	Client workstation
Server to Client	Server Authentication	·         Regular Publishing Scenarios ·         Network Connector ·         IAG Portal	IAG Server
Server to Server	Server Authentication	·         Encrypted connection to protocol transaction, such as LDAPs and HTTPs	Application Server (Web Server) or in the Authenticator (Domain Controller for instance)

 

3. Client Certificate Authentication with IAG

 

The previous table summarizes the scenarios where a certificate is used, but how really IAG authenticates the user when using client certificate?  IAG certificate authentication works in four main phases:

 

1)      Certificate is checked in IIS against CRL to make sure it is not revoked

2)      Certificate validity is checked to make sure it’s not expired (cert.asp)

3)      Two pieces of data are collected from the cert the “username” and the “email address” (cert.asp)

4)      The directory service choose in the authentication repository is queried using the “username” and then if a match is found is that user is queried for the “email” parameter ([repositoryname].inc.)  The email parameter retrieved from the directory is compared to the value retrieved from the certificate([trunkname]1validate.inc).  If any of the 4 checks or subset of the checks fail or do not match the user is not authenticated.

 

It is important to remember that the IAG certificate authentication mechanisms are provided as samples.  These samples are intended to be re-written or modified to match the requirements each particular customer has.  Customer PKI schema vary so significantly customer to customer that it’s not possible to have a default configuration that knows how to deal with even most cases. 

 

There were some cases where the DN used as the Certificate SubjectCN, in this case our sample would properly pick up that object and use it for authentication.  However there are other cases the certificate does not contain DN or UPN but contains some other collection of objects we can use to write a custom ADSI query to AD to look up the user’s DN.  The framework provided is very flexible and customizable and is designed to allow as many cases as possible.

 

4. What comes next?

 

This post gives you an overview of how IAG uses certificate and starts to introduce client certificate mechanism. The coming articles will cover:

·         Certificate Authentication with and without Kerberos

·         Implementing Client Certificate Authentication

·         Understanding IAG’s “Certified Endpoint” feature

·         Understanding Endpoint Detection of Client Certificates

 

Stay tuned.

 

 

Authors

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

 

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

 

 

Performance Degradation in eGap 3.6 after apply Windows Server 2003 SP2

1. Scenario

 

This post is based on a support call where customer was reporting a performance degradation issue that was noticed after applying Windows Server 2003 SP2 on  eGap 3.6 appliances. The server started to slow down until a point where it was no longer answering external requests.

 

2. Gathering Data

 

The initial step here was to get performance monitor data from the OS and IIS perspective to understand what was happening. Fortunately the issue was really clear when we looked at the object Process and the counter %Processor Time. We found that the process whlerrsrvd.exe was constantly growing in memory consumption and not releasing resources. At that point the workaround implemented to drop the memory utilization of this process was to restart the Whale Log Server Service (whlerrsrvd).

 

3. Resolution

 

To fix this problem we had to install eGap 3.6 SP1. This update introduced a number of changes which contain a fix for memory management in whlerrsrvd.

 

4. Additional Information

 

Besides this issue that can potentially happen when you install Windows Server 2003 SP2 in a eGap 3.6 that doesn’t have SP1, you need also to be aware of other issue and our official statement about eGap/IAG with Windows Server 2003 SP2. For more information access the article below:

 

You may experience network-related problems after you install Windows Server 2003 SP2 on a computer that has Whale Communications IAG 3.6 or IAG 2007 installed

http://support.microsoft.com/kb/955090/en-us

 

 

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – TX

 

Technical Reviewer

Dan Herzog

Security Support Engineer – IAG Team

Microsoft – WA

 

Anouncement: Two AES Ciphersuites (128/256 bits) are now supported

Windows 2008 Server and Windows Vista were both released with support for SSL/TLS ciphersuites which use the AES symmetric encryption. Windows 2003 Server was released without these ciphersuites, and so IAG 2007 did not support them either. Recently Microsoft has released a hotfix for Windows 2003 Server which adds two TLS AES ciphersuites, one for 128-bit encryption and one for 256-bit encryption. Installing this hotfix on an IAG 2007 appliance will add support for the TLS AES ciphersuites. More information about the hotfix is available at http://support.microsoft.com/kb/948963/en-us

Publishing Microsoft ActiveSync through IAG 2007 – Part 2 of 2

1. Introduction

 

We published the first part of this article, which had step by step details of how to configure Microsoft ActiveSync through IAG 2007. In this second part, we will cover troubleshooting the most common issues that we’ve encountered while publishing ActiveSync through IAG 2007.

 

2. Gathering Data

 

One of the most important areas that you need to be aware of in troubleshooting ActiveSync, is what data you need to collect.  As a rule of thumb the following logs should be enabled for this scenario:

 

2.1. IAG Trace logs

 

Follow the steps below to enable this log:

 

1. Browse to C:\Whale-Com\e-Gap\von\InternalSite\inc\trace.inc

2. Modify trace_on = false to trace_on = true and save the file

3. Browse to C:\Whale-Com\e-Gap\common\conf\trace.ini

4. Go to the last line of the file and add the following lines:

[Trace\WhlFilter]

*=xheavy

[Trace\UserMgrCom]

*=xheavy

 

5. Save the file

 

Tracing will now start for both WhlFilter and UserMgrCom,. These logs will be located in \whale-com\e-gap\logs and should be named *.usermgrcom*.log and *.whlfilter.*.log

 

2.2. Filter log

 

Follow the steps below to enable this log:

 

1. Run regedit

2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\von\UrlFilter

3. Locate the LogFlag DWORD

4. Modify the value from HEX 0 to HEX 4

 

In about 30 seconds logging will start and the log will be located in \whale-com\e-gap\von\conf\websites\[TrunkName]\Logs\*WhlFilter.log

 

 

3. Troubleshooting Scenarios

 

The environment used for this troubleshooting guide is the following one:

 

Figure 1 – Basic diagram.

 

3.1. After completing the IAG configuration by following part 1, I’m getting an error when I try to synchronize my mobile device. I enabled the logs but there is nothing in there.

 

If this is the first attempt to synchronize after enabling the ActiveSync Trunk and the logs are empty, most likely you are running into a certificate issue. If you enable Netmon trace on the external NIC of the IAG server you will notice the following:

 

TCP Handshake on port 443

192.168.0.185     192.168.0.181     TCP   TCP:Flags=......S., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337408, Ack=0, Win=32768 (scale factor 0) = 32768

 

192.168.0.181     192.168.0.185     TCP   TCP:Flags=...A..S., SrcPort=HTTPS(443), DstPort=1032, PayloadLen=0, Seq=2541104422, Ack=337409, Win=16384 (scale factor 0) = 16384

 

192.168.0.185     192.168.0.181     TCP   TCP:Flags=...A...., SrcPort=1032, DstPort=HTTPS(443), PayloadLen=0, Seq=337409, Ack=2541104423, Win=33580 (scale factor 0) = 33580

 

SSL Handshake

192.168.0.185     192.168.0.181     SSL   SSL:  Client Hello.

 

192.168.0.181     192.168.0.185     SSL   SSL:  Server Hello. Certificate. Server Hello Done.v

- Ssl:   Server Hello. Certificate. Server Hello Done.

  - TlsRecordLayer:

     ContentType: HandShake

   - Version: TLS 1.0

      Major: 3 (0x3)

      Minor: 1 (0x1)

     Length: 1426 (0x592)

   - SSLHandshake: SSL HandShake TLS 1.0 Server Hello Done(0x0E)

      HandShakeType: ServerHello(0x02)

      Length: 70 (0x46)

    + ServerHello: 0x1

      HandShakeType: Certificate(0x0B)

      Length: 1344 (0x540)

    - Cert: 0x1

       CertOffset: 1341 (0x53D)

     - Certificates:

        CertificateLength: 1338 (0x53A)

      - X509Cert: Issuer: Denver CA,contoso,com, Subject: *.contoso.com

       + SequenceHeader: