—————————————————————————————————————————————-
1. Summary

The Client Access Server (CAS) that services Autodiscover and Outlook Web App (OWA) has been found to be vulnerable to time-based authentication attacks. It has been discovered that when sending authentication requests to the CAS, behavior in the timing of the responses can be used to verify Active Directory (AD) realms and usernames within those realms. Authentication timing issues have been found in specific IIS file paths and OWA form-based authentication. This issue can allow an attacker to confirm the existence of a specific username in the directory, and will make other attacks such as password guessing or social engineering attacks more successful.

—————————————————————————————————————————————-
2. Description

When analyzing the response times of authentication requests, there is a noticeable time delay between realms and usernames that exist or don’t exist. It is believed that the underlying issues exists in Windows Kerberos. When the CAS sends authentication requests to the domain controller (KDC) the pre-authentication process is staged in such a way that noticeable time delays exist. OWA form-based authentication and IIS file paths were found vulnerable to this timing delay. The services and authentication paths that have been found vulnerable can be seen below in Table 1.

TABLE 1—VULNERABLE SERVICES

During the testing of the IIS file paths, HTTP NTLM authentication requests were being used. Typically, the realm name, username, and password is required for authentication. There is a case where the CAS can be configured so that the realm name isn’t required and authentication can be accomplished with just a username and password. In this case, the realm name doesn’t need to be known and usernames can be enumerated. Table 2 below details the Windows Kerberos process and approximate response times seen when sending requests to vulnerable services. It should be noted that system resources and network configurations can play a role in response time variations seen. During authentication, when the realm exists but the username doesn’t exist, these times can vary from system to system but the resulting time response is the same average time. For example, it has been seen on a OWA/Forefront TMG 2010 setup that when sending authentication requests to the EWS path, every authentication request will take approximately 60 seconds to respond. When sending form-based authentication requests to OWA 2013, every authentication request can take approximately 15 seconds to respond but another system running the same configuration with more system resources could take approximately 5 seconds to respond. As seen above, the response times in different environments may have different response times but the pattern in the timing response behavior patterns still exist.

TABLE 2—WINDOWS KERBEROS REVIEW

• Non-existing realm – It has been seen that when a non-existing realm names are being tested, that the first request takes 2-3 seconds, and then all requests thereafter take less than one second. What is believed to be happening here is that the first request is searching for the realm and fails but the search response is cached on the CAS for 30 seconds. Thus, the 2-3 second response is seen every 30 seconds.

• Realm exists but username doesn’t exist – A pre-authentication ticket is created to verify the username exists in the realm. The average time of the request can vary depending on resources but the resulting time response is consistent. This could be either approximately 5 seconds or higher. The highest response time seen is approximately 60 seconds.

• Realm and username exists – A pre-authentication ticket is created to verify the password. The time in seconds has been seen to take less then 2 seconds but in most cases this response time is under one second.

Table 3 below details an example of the timing attack analysis. This test was completed against a fully patched Exchange 2013 environment running Windows 2008 R2 server. The OWA 2013 form-based authentication response times were being monitored. The domain CORP is a valid realm and the usernames user_exist_1, user_exist_2, and user_exist_3 are valid account names.

TABLE 3—TIMING ATTACK ANALYSIS

The results are described below.
• Non-existing realm – This can be seen in response # 1 and 2.
• Realm exists but username doesn’t exist – This can be seen in response # 3, 6, and 7.
• Realm and username exists – This can be seen in response # 4, 5, and 8.

—————————————————————————————————————————————-
3. Impact

The issues detailed allow an attacker to enumerate AD realms and usernames which could lead to further compromise. There are many ways to identify realms and username formats, such as searching public databases, stripping metadata from published documents, by reviewing SMTP mail headers and services, or even by obtaining wordlists of the top most popular first and last names and creating a list of correctly formatted usernames to try with a brute force attack. The impact should be categorized as an information disclosure vulnerability.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2010/Forefront TMG 2010
Microsoft Exchange CAS 2007

—————————————————————————————————————————————-
5. Time Line

02/14/2014 Reported Vulnerability to the Vendor
03/10/2014 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
6. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

—————————————————————————————————————————————-
1. Summary

The Microsoft Exchange Client Access Server (CAS) that services Autodiscover has been found vulnerable to an information disclosure. It has been discovered that a standard domain user without Exchange permissions can enumerate Autodiscover configuration files of Exchange users by an XML SOAP parameter injection. This issue can allow an attacker to confirm the existence of a specific email addresses. The type of information that is disclosed are things such as, legacy accounts and their username formats. The end user’s full name is also revealed which could aid in locating a user’s account. Exchange services, permissions, and the location of the domain controller that handles authentication are revealed as well.

—————————————————————————————————————————————-
2. Description

Autodiscover is a CAS service that is used to configure remote or internal mail clients for use with Exchange systems. Using a compatible mail client, the user can configure their client by providing an email address and password. The mail client goes through a discovery process to locate the remote CAS server hosting the Autodiscover configuration file. The configuration file is hosted on an IIS web server. By default the configuration file path is “/Autodiscover/Autodiscover.xml”. To access the Autodiscover.xml configuration file, an XML SOAP request is sent to the server using an HTTP POST method. Server side application controls require the User-Agent header of the request must represent that of an Outlook client, such as “Microsoft Office/12.0”. The body of the SOAP request can be seen in Figure 1.

FIGURE 1—XML SOAP REQUEST BODY

By examining the body of the SOAP request made, it was found that modifying the “EmailAddress” parameter to utilize another existing email address, the user’s configuration data can be enumerated. Using a single set of valid credentials, it is possible to inject the “EmailAddress” parameter to discover valid email addresses and gather data about the users and the environment. It was also found that even though valid Active Directory credentials are required to access the Autodiscover.xml file, it is not required to be a valid Exchange account with mailbox permissions. There are many ways to build an email address list that can be used when injecting the “EmailAddress” parameter, such as searching public databases, stripping metadata from published documents, by reviewing SMTP mail headers and services, or even by obtaining wordlists of the top most popular first and last names and creating a list of correctly formatted email addresses to try with this enumeration attack.

—————————————————————————————————————————————-
3. Impact

Allows an attacker to enumerate Exchange user and environment information which could lead to further compromise such as password guessing attacks, social engineering, and learning about internal systems. The impact should be categorized as an information disclosure vulnerability.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2007

—————————————————————————————————————————————-
5. Time Line

05/27/2014 Reported Vulnerability to the Vendor
06/26/2014 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
6. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

—————————————————————————————————————————————-
1. Summary

Multiple issues have been discovered that make it possible to disclose internal IP addresses of remote Microsoft Exchange environments. This includes internal addresses of the Client Access Server (CAS) which hosts services such as Outlook Web App (OWA) and Autodiscover. This also includes internal addresses of the proxy or gateways processing requests for the OWA.

—————————————————————————————————————————————-
2. Description

Attack #1 – OWA / Autodiscover

When sending a crafted GET requests to the web server with empty host header and using the HTTP protocol version 1.0(HTTP/1.0), the internal IP addresses of the under lying system is revealed in the header response. This flaw is believed to be an IIS issue and has been found in Microsoft Exchange systems such as Outlook Web App (OWA) and the Client Access Server (CAS). The flaw has been seen in Basic Authentication response headers on a 401 web server status and the Location headers on a 302 web server status. It’s possible this flaw exists in other products that run on IIS. An example of normal behavior can be seen when performing a HTTP/1.1 request to a protected page such as:

“https://autodiscover.example.com/Autodiscover/Autodiscover.xml”

The Basic Authentication HTTP header response normally reveals a public facing IP address or hostname of:

WWW-Authenticate: Basic realm=”autodiscover.example.com”

A proof of concept example can be seen below in Figure 1. All the vulnerable IIS paths discovered and there affected product versions can be seen in Table 1. Note that some of the file paths disclosed are vulnerable if default settings have not been changed. Some of the paths have been found vulnerable based on system administrator changes.

TABLE 1—VULNERABLE PATHS

FIGURE 1—BASIC AUTH HEADER REVEALS INTERNAL IP ADDRESS

$ openssl s_client -host autodiscover.example.com -port 443

—SNIP—
GET /Autodiscover/Autodiscover.xml HTTP/1.0
HTTP/1.1 401 Unauthorized
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-SOAP-Enabled: True
X-WSSecurity-Enabled: True
X-WSSecurity-For: None
X-AspNet-Version: 2.0.50727
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm=”10.1.1.10″
X-Powered-By: ASP.NET
—SNIP—

Attack #2 – Reverse Proxy / Gateway

It has been shown in OWA 2007 and 2010, that it’s possible to reveal the internal IP address of the reverse proxy or gateway processing requests for OWA. Such proxies or gateways include Forefront TMG 2010. This attack can be performed using a web browser. When attempting to trigger ASP.NET debug and making a GET request to the OWA path “/owa/auth/trace.axd”. The OWA throws a server side exception with a web server status of 403. The verbose error reveals the internal IP address of the proxy or gateway. Example output can be seen below in Figure 2.

FIGURE 2—REVERSE PROXY/GATEWAY INTERNAL IP DISCLOSED

An error occurred and your request couldn’t be completed. If the problem continues, contact your helpdesk with this HTTP Status code: 403.

Request
Url: https://mail.example.com/owa/auth/trace.axd
User host address: 10.1.1.1
OWA version: 14.2.318.3

—————————————————————————————————————————————-
3. Impact

Allow an attacker to gather information about the internal network.

—————————————————————————————————————————————-
4. Affected Products

Microsoft Exchange CAS 2013
Microsoft Exchange CAS 2010
Microsoft Exchange CAS 2010/Forefront TMG 2010
Microsoft Exchange CAS 2007
Microsoft Exchange OWA 2003

—————————————————————————————————————————————-
5. Solution

Only attack two is fixed in current versions. Apply the latest supplied vendor patches.

—————————————————————————————————————————————-
6. Time Line

12/17/2012 Reported Vulnerability to the Vendor
01/03/2013 Vendor Confirmed the Vulnerability
08/01/2014 Publicly Disclosed

—————————————————————————————————————————————-
7. Credits

Discovered by Nate Power

—————————————————————————————————————————————-

Multi-Tech Systems “MultiModem iSMS” appliance is affected by multiple XSS (cross-site scripting) vulnerabilities, which potientally leads to the comprimise of the device.

For the latest advisory Click Here

Attack #2 is more interesting because it can be remotely exploited via a SMS message.

When reporting this issue it did come into question the 160 character limitation of SMS technology and if this would to limit the attacker.  In the proof of concept video, you can see exploitation was successful with 158 characters using the Browser Exploitation Framework BeEF!

please visit www.securitypentest.com for the original advisory.

Trustwave’s WebDefend console software is prone to static MySQL database passwords in the binary files, which leads to a comprimise of sensitive information.

For the latest advisory Click Here

Below are the steps that led up to the discovery of this low hanging fruit:

• I first started by using tcpdump to capture traffic between the appliance and a workstation running the console software.
• When using the console software to login, I noticed the authentication was done over port 5000.  After I logged in, the console software started to load data over MySQL port 3306. What I found interesting was all the sql traffic was getting initated by the workstation. At this point I wanted to know how the workstation was able to login to the MySQL server on the appliance.
• By using several sysinternal tools on the workstation, I was able to determine which binary files the console software was using when the sql connection got initiated.
• I then used a combination of strings and IDA Pro to search through the binaries for the sql login and bingo found it!

please visit www.securitypentest.com for more WebDefend advisories

This is a very interesting flaw that I came across in Symantec Antivirus Corporate edition in July 2009 while trying to recreate the XFR.EXE design flaw (CVE-2009-1431). At first I thought this was the same flaw, but while running a serious of test against multiple versions of SAVCE. I realized I had tested it against the latest patched 10.1.8 version of the product and the vulnerability was still there. Upon further investigation I discovered this flaw went against the Intel Alert Handler Service (hndlrsvc.exe) over TCP port 38292.

POC: http://www.foofus.net/~spider/code/ams-cmd.cpp.txt

For the latest advisory Click Here