Flawed Authentication System Implementation

balaji
By balaji

April 14, 2011

There are various motivations and factors that drive the implementation of an authentication system in an organization... If authentication systems are implemented without putting thought to resultant side effects, then they may introduce security vulnerabilities. We will discuss two cases of such flawed implementations in this article.

There are various motivations and factors that drive the implementation of an authentication system in an organization. These may include:

  • Integration with an already existent user credential store
  • Single sign-on
  • Reuse of already existing infrastructure components like reverse proxies or load balancers
  • Use of infrastructure components that provide multiple functionalities, one of them being authentication

If authentication systems are implemented without putting thought to resultant side effects, then they may introduce security vulnerabilities. We will discuss two cases of such flawed implementations in this article.

Case I

The organization implements intranet domain-based authentication for an internet-based HR web application

This organization had outsourced their HR to a third party vendor. The organization's requirements were as follows:

  1. They did not want their employees to access the HR application from outside the organization's intranet.
  2. They wanted to utilize the domain login to sign in to the HR application. They did not want a separate authentication process.
  3. The user credentials should be automatically generated and not in the control of the end user.

The HR application was a web application on the internet. The user had to perform the following steps to obtain access to the HR application:

flawed-auth-case1.png
  • Step 1: Log in to the intranet domain. User authentication was performed against the Active Directory.
  • Step 2: Click on a desktop icon to access the HR application. On clicking the icon, the SOAP request was sent to a server hosting a web service in the intranet. One of the parameters in the SOAP request was the login name of the domain user.
flawed-auth-soap-request.png
  • Step 3: The web service performs a lookup corresponding to the login name. In response, the web service sends back the URL of the HR application. The username and password hash are sent as part of the query string in the URL.
flawed-auth-soap-response.png
  • Step 4: On receiving the response, the web service client on the user machine starts up an instance of the browser and sends a request to the URL received in response to the web service call.
flawed-auth-home-page.png

This authentication model suffered from the following vulnerabilities:

  1. Once the web service receives the first request, there is no way for it to ensure the non-repudiation of the login name that it received as a parameter in the request. An adversary can change the login name parameter to any other valid domain username and log in to the HR application as that user.
  2. In response, the web service sends back a URL containing the user ID and credential hash in the query string. Using a proxy/sniffer, an adversary can get hold of this URL. This URL can be used outside the office intranet to access the HR application, thus bypassing the company's restriction.

Case II

Proprietary closed source authentication/reverse proxy server

The following case will explain how customers often find themselves in tricky and often insecure situations if all the possible factors are not considered while acquiring security products.

flawed-auth-case2.png

The above diagram depicts the relevant components of the network:

  1. The organization decided to acquire an authentication server that can act as a reverse proxy and load balancer as well. This authentication server/reverse proxy is located in the DMZ.
  2. The authentication server performs a lookup against the LDAP server for authentication.
  3. Once the user is authenticated, the authentication server sets a session cookie and forwards the request to one of the multiple application servers.
  4. For the remaining user sessions, the authentication server acts as a reverse proxy, and forwards the user requests to the same application server where the first request for post-authentication was forwarded.
  5. The application servers are located in the internal segment.

An important point to note here is that the authentication server implementation is a closed source. The vendor only exposes certain configurable parameters via an interface.

After the vulnerability assessment, it was discovered that there were multiple threats that might be realized:

  1. Although the entire application was hosted over SSL, a local adversary could still perform a man-in-the-middle attack using tools like Surfjack. The Secure attribute could not be set for cookies.
  2. To prevent a brute force attack, the authentication server provided "number of login attempts" as a parameter that could be configured via an interface. However, via another vulnerability, a valid application username can be enumerated. This may allow an attacker to launch a denial-of-service attack against the authentication server.

The authentication logic could not be modified to include controls like CAPTCHA to prevent such brute force attack, or setting the Secure attribute of session cookies to prevent MITM attacks, as the authentication server software is proprietary and a closed source.


Tags: Features

About

balaji