NTLM Proxies

When working in a corporate environment, you’ll often find yourself behind a proxy server. This proxy server acts as a gateway between you and the internet (or other external networks). Any requests for remote resources outside the corporate intranet will have to go through this gateway. A user will be made aware of this when trying to access a website (say Google for example) and their browser prompts them for a username and password (the browser must be configured with the correct proxy hostname/IP and port number first). Upon entering the valid credentials, the user is presented with the requested resource (the Google webpage in this case).

HTTP Basic and HTTP Digest Authentication: There are two main standards for proxy authentication: HTTP Basic Authentication and Digest Authentication. Both work on a simple challenge-response principle, i.e:
  • User A requests Resource B through proxy server;
  • Proxy server challenges User A to identify himself;
  • User A enters Username and Password in browser popup box;
  • Proxy server receives login credentials and verifies against some repository;
  • If credentials are valid and the user is authorized to access Resource B then the resource is returned;
  • Otherwise the proxy server replies with an invalid authentication response.
As the name implies, the HTTP Basic protocol is a very simple implementation of this algorithm and through this simplicity comes a complete lack of security. The username and password are sent from the client to the proxy encoded by a weak obfuscation algorithm (Base64). This means anyone sniffing the traffic between the user and the proxy will be able to log and easily decode the login credentials for future malicious use.

This is where the HTTP Digest Authentication algorithm comes. With Digest, the username and password are secured using strong encryption standards similar to SSL (what banking sites use to secure online banking). This means a malicious sniffer will not be able to decode the username/password exchange between the client and proxy server. However, even though Basic Authentication is inherently insecure, it is by far the most commonly used standard. Digest is rarely used in corporate intranets but is gaining in popularity slowly.

NOTE: Whereas SSL (Secure Socket Layer) encryption is used to secure the transport for an entire client-server session, HTTP digest only secures the proxy password exchange. Digest could also be used to secure your online banking login, whilst the rest of the session would continue to be transferred in plain-text (although disclosing how much money you have in your accounts and your entire transaction history would not be wise).

Microsoft NTLM Authentication: Microsoft on the other hand, for whatever reason, decided to ignore both international standards and implement their own proprietary HTTP authentication algorithm know as NTLM (NT Lan Manager). NTLM has some added security benefits when compared to Basic authentication, but the encryption algorithms used are known to be relatively weak and should not be relied upon in critical environments (would not use this to secure a banking login). NTLM has gained some popularity in Windows based internal corporate networks as an easy to implement mechanism for securing internal credentials (an intranet is often considered a trusted environment).

NTLM Problems: The downside of the NTLM algorithm (besides its security weaknesses) is that it is not a published standard. This means that 3rd party software vendors who wish to make their products proxy friendly do not have proper documentation on how to implement the authentication mechanism. This is the reason why in some corporate environments you may have Internet Explorer and MSN Messenger working fine with your proxy, whereas some other 3rd party tools like Eclipse Software Update or 3rd party IM clients refuse to work even when you enter correct proxy details.

NTLM Proxy Tunel: Some clever individuals in the open-source community have managed to reverse-engineer the NTLM protocol. FireFox, for example, is now able to authenticate freely to NTLM proxy servers. However, a large number of clients are still unable to connect and are unlikely to ever implement this algorithm. This is where NTLM Authorization Proxy Server comes in. NTLM-APS is an open-source python tool that acts as an intermediary between all your application clients and the NTLM Proxy server on your corporate network. It works as follows:
  • Edit the NTLM-APS server config file with your environment details (real proxy host and port, fake proxy port - xxx, Basic authentication translation, etc);
  • Start the NTLM-APS server (requires Python to run). This will open a listening port on your local machine (port xxx defined above);
  • Configure all your non-NTLM clients proxy settings to point to 127.0.0.1:xxx rather than your real proxy server;
  • If using Basic authentication translation, configure your clients with a valid username and password, else enter the username and password in the server config file;
  • Done! All your clients should now be able to freely connect and retrieve any remote resources that Internet Explorer can!
Read the following section for a working example of configuring NTLM on Fedora 8 to work with the Yum RPM package updater.

Fedora 8, YUM and NTLM Proxy: Yum is Fedora’s main software update tool. Yum typically connects to a number of online repositories to check for security updates and new applications. It can be configured to use a HTTP Basic Authentication proxy but is not NTLM compatible. This means that even though you may have FireFox able to connect to the internet through your corporate proxy, Yum will fail with authentication errors. NTLM-APS can be used as a work around for this limitation to access the needed software repositories as follows:

  • Firstly, download and install the latest version of FireFox on your Fedora box and make sure it can connect to the internet through your NTLM proxy;
  • Once you have verified that your internet is working (FireFox is NTLM enabled), download NTLM-APS and extract to a local directory;
  • Once extracted, open up the server.cfg file and edit as follows (leave other settings as default):
    • LISTEN_PORT:5865 (or whatever port is free on your machine and you want to use);
    • PARENT_PROXY: [your-ntlm-corporate-proxy.com] (copy-paste this from FireFox to be sure you’ve got it right);
    • PARENT_PROXY_PORT:8080 (or whatever the proxy server above is listening on, again copy this from FireFox);
    • ALLOW_EXTERNAL_CLIENTS:0 (could use this to set up a single NTLM-APS proxy tunnel for everyone in the office to share);
    • NT_HOSTNAME: [leave blank] (may need to change this depending on how strict your NTLM proxy is configured);
    • NT_DOMAIN: [the windows domain you use to login to your corporate machines]
    • USER: [comment out] (we’ll use HTTP Basic translation and prompt the client for proxy username);
    • PASSWORD: [comment out] (we’ll use HTTP Basic translation and prompt the client for proxy password);
  • Save and exit the server.cfg file;
  • From your NTLM-APS extract directory, open a console and type ‘./main.py &’;
  • If python is installed and configured correctly, this should launch the NTLM-APS server as a background task;
  • You should see something like ‘Now listening at [hostname] on port 5865′;
  • To test this, open up FireFox and change the proxy settings to point to 127.0.0.1, port 5865;
  • If you’re still able to access Google in FireFox with these new settings, proceed to configure yum, otherwise try the various debug settings in server.cfg;
  • To configure yum to use your new proxy, switch to root and edit /etc/yum.conf;
  • Add the following to the end of the file:
    • proxy=http://127.0.0.1:5865/
    • proxy_username= [your proxy username, will be forwarded by NTLM-ASP]
    • proxy_password= [your proxy password, will be forwarded by NTLM-ASP]
  • Start the Software Updater and hope for the best!
  • NOTE: it may be possible to configure these proxy settings as environment variables as part of your local profile instead, avoiding the need for root access or hard-coding the password in yum.conf;
Other Examples: Using the above method, it should be possible to configure virtually any client to work with your NTLM proxy. It is worth configuring this even on Windows machines where certain programs can’t seem to get stable internet connections. You may want to check with your supervisors first before setting this up in a corporate environment though to avoid violation of any security policies that may apply.

Comments

  1. Microsoft has fully documented the protocol since 2007.


    All Windows Communication Protocols (NTLM being one of them) are documented here:

    http://msdn.microsoft.com/en-us/library/cc216513(PROT.10).aspx


    The specifications relating to NTLM are:

    MS-NLMP: Main document describing NTLM v1, NTLM v2. etc.
    http://msdn.microsoft.com/en-us/library/cc236621(PROT.10).aspx

    MS-NTHT: NTLM over HTTP protocol
    http://msdn.microsoft.com/en-us/library/cc237488(PROT.10).aspx

    MS-NNTP: Specifies the use of NTLM authentication by NNTP (Network News Transfer Protocol)
    http://msdn.microsoft.com/en-us/library/cc236774(PROT.10).aspx

    MS-POP3: NTML for use with POP3
    http://msdn.microsoft.com/en-us/library/cc239183(PROT.10).aspx

    MS-SMTP: NTML for use with SMTP
    http://msdn.microsoft.com/en-us/library/cc246807(PROT.10).aspx

    ReplyDelete
  2. Bottom line: I don't understand all this talk about 'reverse engineering', e.g. for Firefox, unless we are talking about software from BEFORE 2007.

    ReplyDelete
  3. Thanks for pointing that out and providing these links. Yes, this article was written a few years back and later migrated to this blog. I guess things are a little different now.

    ReplyDelete

Post a Comment

Popular posts from this blog

Wkhtmltopdf font and sizing issues

Import Google Contacts to Nokia PC Suite

Can't delete last blank page from Word