Google Chrome Cleanup Tool DLL Hijacking

Google's software_removal_tool.exe alias Chrome Cleanup Tool loads
and executes several DLLs from its "application directory" during
runtime:

* Windows XP:
  SetupAPI.dll, NTMarta.dll, ClbCatQ.dll, SRClient.dll, UXTheme.dll,
  RASAPI32.dll, HNetCfg.dll, IPHlpAPI.dll, RASAdHlp.dll, XPSP2Res.dll,
  RichEd20.dll, SENSAPI.dll

* Windows 7:
  NTMarta.dll, SRClient.dll, DWMAPI.dll, UXTheme.dll, IPHlpAPI.dll,
  DNSAPI.dll

Additionally the following DLLs are loaded from its "application
directory" during load-time:

WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll,
ProfAPI.dll, Secur32.dll, Version.dll


For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for
"prior art" about this well-known and well-documented vulnerability.


If an attacker places the DLLs named above in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.


See <http://seclists.org/fulldisclosure/2015/Nov/101>
and <http://seclists.org/fulldisclosure/2015/Dec/86>
plus <http://seclists.org/fulldisclosure/2015/Dec/121>


Proof of concept (verified on Windows XP and Windows 7 using
version 2.46 and 6.44.3.0 of software_removal_tool.exe):

1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
   <http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save
   it as UXTheme.dll in your "Downloads" directory, then copy it
   as RichEd20.dll, ClbCatQ.dll, SetupAPI.dll, DWMAPI.dll etc.;

2. download software_removal_tool.exe and save it in your
   "Downloads" directory;

3. run software_removal_tool.exe from the "Downloads" directory;

4. notice the message boxes displayed from the DLLs placed in
   step 1.

PWNED!

5. create empty files WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll,
   WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll in your
   "Downloads" directory;

6. run software_removal_tool.exe from the "Downloads" directory.

DOSSED!


This denial of service can easily turned into arbitrary code
execution too: just create a DLL with all the entries referenced
from software_removal_tool.exe.


For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>:

| To ensure secure loading of libraries
| * Use proper DLL search order.
| * Always specify the fully qualified path when the library location
    ~~~~~~
|   is constant.


Additionally software_removal_tool.exe uses an UNSAFE temporary
directory %TEMP%scoped_dir<pid>_<random> to extract and run
%TEMP%scoped_dir<pid>_<random>ChromeRecovery.exe

For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> plus
<https://cwe.mitre.org/data/definitions/426.html> and
<https://cwe.mitre.org/data/definitions/427.html>


stay tuned
Stefan Kanthak


Timeline:
~~~~~~~~~

2016-01-28    sent vulnerability report to <security@google.com>

              NO reply

2016-02-05    resent vulnerability report to <security@google.com>

2016-02-10    reply from Google security team:
              "Chrome is not in scope for the Google VRP program, and has
               a separate bug reporting process."

2016-02-10    resent vulnerability report to <security@chromium.org>

              NO reply, not even an acknowledgement of receipt

2016-02-24    resent vulnerability report to <security@chromium.org>
              and <security@google.com>

2016-02-24    reply from Google security team:
              "This is working as intended."

Google want's to have your Windows pwned!

2016-02-24    completely clueless reply from Chromium telling that they
              didn't read <http://seclists.org/fulldisclosure/2015/Nov/101>
              and <http://seclists.org/fulldisclosure/2015/Dec/86>
              plus <http://seclists.org/fulldisclosure/2015/Dec/121>:

              "I'm also unsure what defenses you intended to propose here,
               because the loader definitely pulls in many (all?) of those
               imports prior to any application code running -- so things
               like SetDefaultDllDirectories simply aren't a viable defense."

2016-02-24    OUCH!
              The DLLs loaded during runtime (see steps 1 to 4) don't have
              any exports, there is no import which can (or need to) be
              pulled by the loader.

2016-02-26    another nonsense reply from Chromium

2016-02-26    report published
              obviously neither Google nor Chromium seem to be interested
              in fixing their vulnerable cleanup tool.

STAY AWAY FROM SUCH CRAPWARE!

Share on Google Plus

About Vo Uu

Tác Giả là người chuyên nghiên cứu về các kỹ thuật hacking, security, marketing, là người có góc nhìn lạ và đi sâu vấn đề cũng như là một con người thẳng thắn góp ý. Nếu sử dụng bài trên blog mong các bạn dẫn lại nguồn tác giả!!! Tác Giả rất mong có sự đóng góp hội ý từ cộng đồng để cho an toàn an ninh mạng việt nam ngày càng được an toàn hơn!!