This is simple. Very simple. But, hey, it was nice to see something other than SSL/TLS, RC4, and certificate RSA1024/SHA1 failures for once while doing PCI audit remediation.
IIS as used by OWA leaks a server's LAN IP address in HTTP headers in response to a crafted GET request if the authentication realm has not been properly set (vanilla OWA settings). From the smattering of servers I have run this against, I have to say that a good majority of them are not set properly. It is up to you to decide how useful knowing the LAN IP of a server even from behind a NAT device is, but for my part I could definitely see it coming in handy (file rigged with exploits e-mailed to someone inside the network with the server's LAN IP hardcoded into it, anyone?).
I really just pieced this together from 2 posts that I found online when remediating this issue:
I then just took the time to write a batch file that will ask for a domain and a port and, voila, it will connect via OpenSSL (the binaries are included in the archive). You then just paste the echoed HTTP requests into the console and allow it to get the headers. If the server is running IIS for OWA and is not configured properly, you will get the LAN IP of the server via the "WWW-Authenticate: Basic realm=" field.
The test utility in action.
So, how do we fix this? Well, I added another script into the archive in the "Fix" folder that will utilize "adsutil.vbs" to change the web services authentication realm to a string of the user's choice. If you have access to the affected server, just copy the "Fix" folder to it and run the batch script. It will stop and start web services for you and prompt you for your desired authentication realm (choose something that does not leak anything overly sensitive, such as "ACME Widget Corp." or "PRIVATE"). Once the fix has been applied, run the testing utility again and check what realm is returned in the headers. If everything went as planned, you should no longer be leaking your server's LAN IP.
Applying the fix.
Like I said, simple test and simple fix, but I wanted to create something that would make it easy for anybody to test for and remediate this issue. Plus, it was fun to do something other than disable protocols/ciphers or upgrade certificates.
DISCLAIMER: Run these tools at your own risk. I will not assume any responsibility for any issues, legal or technical, that arise from the use of these tools.HTTPLANLeakTester32.zip