Dragging Secrets Out of Chrome: NTLM Hash Leaks via File URLs
Table of contents
Capturing Hashes with DragonHash
Chromium-based browsers have an odd feature set that allows extensive drag-and-drop capabilities in the browser. This feature is not only useful for “typing” inputs during a clickjacking attack as shown in this blog, but also for making web applications feel like proper file handlers. You can drag files out of a web application and onto your desktop, for example.
A social engineer might find this feature useful for tricking users into copying a file onto the user’s computer, and that is certainly possible. You can have a web application prompt the user to, say, drag an image to the desktop, and when they release that image, you could, of course, copy that image file onto the desktop.
But that assumes you’re behaving yourself. It turns out you can write any file to the location the user releases the dragged element on. They may have dragged an image to the desktop, but when they release, you could write a binary file if you want. Sounds like a bad idea, but, okay, Chrome. Features.
Any hacker might start asking themselves, what happens if we start messing around with this for more than writing a file to disk? What if we start throwing in file URLs? Clearly, Chrome wouldn’t let that happen—right?
Because we know that if that hits Windows, Windows is going to do what it does—which is usually something terrible, like fling hashes around.
Let’s try out some JavaScript, shall we?
Assuming we have a web server hosting an image file, we can make a draggable image like so:
What we want is for the draggable element to set the data to be a DownloadURL, but instead of giving it the content of the file we want to write, we’ll point to Responder.
So, what happens when the user is tricked into dragging this image out of the web app and onto their Windows desktop?
Oh, good—nothing happened. But, there’s a funny thing about users.
When something doesn’t work, and it’s trivially easy to try again, users very often will just try again. And this is where Chrome lets Windows be its stupid self.
This does not actually copy the file to disk but does trigger our NTLM hash capture. We can add a bit more JavaScript to download a file so that, hopefully, the user doesn’t become too suspicious.
Now, this requires that Chrome (or whatever chromium-based browser the user has) has ‘automatically download to folder’ enabled. This does not appear to work when the browser is configured to ask the user every time where they want to download a file. And this file download will go to the configured download folder, not the desktop where the user dragged the image (or wherever they dragged the element).
You can skip this extra file download step if you think it’s less suspicious to not transfer a file at all; you’ll still get the NTLM hash.
You can try this out yourself with your own Responder server running from this online tool:
Code for this demo page can be found at: