This article reveals a bit of our research and provides an advance notification of a largely unknown remote exploit technique on Windows. More importantly, it provides instructions for protecting your computers from this technique while waiting for the affected software to correct its behavior.
Two weeks from now I'll be holding a presentation at RSA Conference US called "Advanced (Persistent) Binary Planting" (Thursday, March 1, 9:30 AM Room 104). The presentation will include demonstrations of "two-step" binary planting exploits where in the first step the attacker silently deploys a malicious executable to user's computer, and the second step gets this executable launched. For those familiar with our past research on binary planting, this removes the need for remote shared folders as well as the need to get the user to double-click on a document in Windows Explorer.
Obviously, the idea is not new: If the attacker manages to somehow get her executable onto user's computer, getting it executed may be just a step away. But in order to deploy the file without heavy-duty social engineering (which invariably works in practice but is frowned upon among security folks) or physical access (which may include an overseas round trip), what is she left with? One ally she may find is the web browser - which lets the user download all sorts of files from all sorts of web sites. Directly to the Downloads folder.
What's In Your Downloads Folder, Anyway?
If you have ever downloaded anything from the Internet, you know that you can always find it in the browser's "Downloads" or "Downloaded files" window. This window also provides a way to delete any downloaded file, or all of them, with just a few clicks. Or so one would think.
Actually, browsers don't delete files from the Downloads folder: they only delete them from the browser's list so that they're no longer visible to the user. In fact, between the latest versions of top web browsers (Chrome, Firefox, Internet Explorer, Safari and Opera), only Internet Explorer 9 (not 8) and Opera provide a way to actually delete a downloaded file from the Downloads folder through their user interface, and even then you have to do it through a right-click menu - in Opera even a sub-menu. Only Opera allows you to delete all files at once.
As a result, your average Downloads folder is a growing repository of files, new, old and borderline ancient. If anything malicious sneaks by your browsers' warnings or your mental safeguards, it is bound to stay there for a long time. Waiting for someone or something to launch it.
Do You Really Want To Download This?
But, you may say, all major web browsers will warn the user if he tries to download an executable file, and the user will have to confirm the download. Right?
Not entirely. One major web browser will, under certain conditions (to be explained at the presentation), download an executable to the Downloads folder without asking or notifying the user. For sure, it will then not execute this file, but the file will remain in the Downloads folder. Possibly until the user re-installs Windows. Furthermore, the same web browser allows a malicious web page to trick the user into confirming a download attempt using clickjacking (an old trick), which is another way to get the executable to the Downloads folder.
And finally - applying to all web browsers -, if some extremely (perhaps even obscenely) interesting web site persistently tries to initiate a download of an executable, how many attempts will it take before an average web user tells it to shut up already and accepts the download, knowing that it will not be automatically executed?
Downloaded But Not Executed? Give It Time.
So the Downloads folder tends to host various not-so-friendly executables. Big deal; it's not like the user is going to double-click those EXEs and have them executed. No, not the user directly, but other executables that he downloads and executes - for instance, installers.
We found that a significant percentage of installers we looked at (especially those created by one leading installer framework) make a call to CreateProcess("msiexec.exe") [simplified for illustration] without specifying the full path to msiexec.exe. This results in the installer first trying to find msiexec.exe in the directory where it itself resides - i.e., in the Downloads folder (unless it was saved elsewhere) - and launching it if it finds it there.
And this is just one single executable. If you launch Process Monitor and observe activities in the Downloads folder when any installer is launched, you will find a long series of attempts to load various DLLs. Not surprising: this is how library loading works (first trying to find DLLs in the same folder as EXE), and in most cases it would not be a security problem as most folders hosting your EXEs are not attacker-writable. However, the Downloads folder is - to some extent, anyway.
So what do we have here? An ability to get malicious EXEs and DLLs to the Downloads folder, where they will in all likelihood remain for a very long time, and at least occasional activities on user's computer that load EXEs and DLLs from the Downloads folder. This can't be good.
But that's it for now. My presentation will also feature data files (non-installers) launching executables from the Downloads folder in a "classic" binary planting manner, instructions for finding binary planting bugs, recommendations for administrators, developers and pentesters, and more.
What You Should Do Right Now
For those of you who think we might be the first people in the world to have thought of this - we sincerely appreciate your compliments! The rest of you should do the following:
- Open your browser's Downloads folder in Windows Explorer or any other file manager.
- Look for the presence of msiexec.exe. If you find it there and you don't think you intentionally downloaded it at some point in the past, send it to your favorite malware research (anti-virus) company and delete it from your Downloads folder.
- Look for the presence of any *.dll files in the Downloads folder and do the same as in the previous step.
- Delete all files from the Downloads folder.
- Locate msiexec.exe in your %SystemRoot%\System32 folder and copy it to the Downloads folder. (Note: this will prevent Windows to update the msiexec.exe that will be used when installing files from the Downloads folder, but won't affect installers launched from other locations. On the upside, it will also block installer-based attacks described above.)
Hope to see you at RSA Conference,
@mkolsek
@acrossecurity
Posts
