Cached Credentials, Authenticating Proxies and Spyware

Recently a client of mine and I had a long winded debate about the dangers of not protecting machines from spyware and other malware. The client swore up and down that since they had an authenticating proxy that required the windows cached credentials to access the internet that they were protected. They believed that the proxy prevented the spyware and other malware from being able to phone data home as the spyware would not have access to the cache credentials to access the internet.

We spent a lot of time searching for spyware or other malware that were known that could use windows cached credentials and could not find any. The results that we did come up with were articles on how using an authenticating proxy helps cuts down on spyware and other malware as they cannot phone home. Even though all the data was pointing to me being wrong I knew if it did not currently exist that as spyware evolved it would exist.

Even though I continued to argue my points and tried to provide relevant supporting data to back my concerns up they were still firm that spyware is not an issue. So I set forth to prove them wrong. I remembered back in the day when I use to write applications in Visual Basic that you could make a web browser in just a few minutes. Visual Basic allows you to do this through the web browser component, which uses the Internet Explorer engine. With this in mind I formulated my first theory. The theory was if it used Internet Explorer then it should use cached credentials to authenticate too without the need to steal them or anything else. To test this out I wrote a quick web browser using the web component in Visual Basic. Once I completed the code I disabled the proxy in Internet Explorer to make sure that without that checked I did not have internet access. Once I verified I did not have internet access I launched my web browser that I just coded and witnessed the same thing. With this tested I then re-enabled the proxy settings in Internet Explorer and repeated the test again. This time both Internet Explorer and the web browser I built connected to the internet. With the theory of my web browser using the cached credentials proven correct I moved on to actually sending data out through the proxy /firewall. To accomplish this I decided to use the “http post” command as it will allow me to submit data to a form over port 80 using the http protocol which is allowed through the proxy / firewall for authenticated users. To do this I found an old “shoutbox” script and used “live http headers” for Firefox to see how a post looked. Once I captured the posting header I broke it down in my application into 2 parts. Part one was the post string and part 2 was the data I recorded from user input. Once I clicked the execute button the data was posted to the shoutbox application and my theory was proven fact.

To double verify my theory I ran a second set of tests:

Test 2: Using Raw packet tools to test my theory.

Without firewall rule allowing me to bypass the proxy

C:>nc -vv xxxx.net 80

DNS fwd/rev mismatch: xxxx.net != lambda.xxxxxxx.com

xxxxx.net [xxx.xxx.xxx.xxx] 80 (http): TIMEDOUT

C:>nc -vv xxxxx.net 80

DNS fwd/rev mismatch: xxxx.net != lambda.xxxxxx.com

xxxxxx.net [xxx.xxx.xxx.xxx] 80 (http) open

As you can see with the rule allowed in the firewall to allow me to bypass the proxy and use the firewall the Netcat application can connect via http to xxxxx.net since it does not have to authenticate.

In the wild a malicious person could use a vulnerability in Internet explorer to download the application and execute it in the background or they could email it to a user and have them run it. The application does not require admin rights all it needs is the ability to use Internet Explorer.

I will upload the POC once I show the company my findings later this week. IP and URL's have been altered to protect them.

Original story: http://www.digitaloffensive.com