what you don't know can hurt you

Microsoft Visual C++ DLL Hijacking

Microsoft Visual C++ DLL Hijacking
Posted May 17, 2016
Authored by rugk

Microsoft Visual C++ 2010 Redistributable Package and Visual C++ Redistributable for Visual Studio 2015 suffer from multiple dll hijacking vulnerabilities.

tags | exploit, vulnerability
systems | windows
MD5 | e6906434cb499de8310b345ea39b21d5

Microsoft Visual C++ DLL Hijacking

Change Mirror Download
Dear Sir or Madam,
I found a DLL hijacking vulnerability in your Microsoft Visual C++ 2010 Redistributable Package and Visual C++ Redistributable for Visual Studio 2015.

Recently a lot of DLL hijacking issues in popular software was revealed. (https://packetstormsecurity.com/files/author/6137/) So I tested your Visual C++ 2010 Redistributable Packages from 2010 and the latest from 2015.
I downloaded vcredist_x86.exe from https://www.microsoft.com/en-us/download/details.aspx?id=5555. This is the version from 2010 and as you see it is still downloadable.
And vc_redist.x86.exe from https://www.microsoft.com/en-us/download/details.aspx?id=48145 (choosing the x86 version). This is the version from 2015.
All tests were done on Windows 7 x86.

The security vulnerability is well-documented and also described in docs by Microsoft. Here are a few sites:
* 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
* https://msdn.microsoft.com/en-us/library/ms682586.aspx
* http://seclists.org/fulldisclosure/2015/Nov/101

So when the user downloads these executables (with a web browser) they are usually saved in the "Downloads" directory. If there is a malicious DLL inside it (e.g. by tricking the user to download it via Social Engineering) this can be executed by your installers.
More information about the "download folder planting" here:
* 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
* http://seclists.org/fulldisclosure/2012/Aug/134>

So I tested your installers and these are the DLL files it loads and executed from the application directory (which is in most cases the Downloads directory as explained above):
vcredist_x86.exe:
* dwmapi.dll
* CRYPTBASE.dll
* cryptdll.dll
* CRYPTSP.dll
* feclient.dll

vc_redist.x86.exe:
* Cabinet.dll
* msi.dll
* version.DLL
* CRYPTBASE.dll
* feclient.dll
* WindowsCodecs.dll
* dwmapi.dll
* PROPSYS.dll
* ntmarta.dll
* CRYPTSP.dll
* RpcRtRemote.dll
* apphelp.dll
* Secur32.dll
* SSPICLI.DLL
* MPR.dll

~~ Proof of concept/Steps to reproduce ~~
I only use one DLL to show that it is exploitable.

1. visit http://home.arcor.de/skanthak/sentinel.html, download http://home.arcor.de/skanthak/download/SENTINEL.DLL and store it as dwmapi.dll in your "Downloads" directory;

2. download both installers (vcredist_x86.exe and vc_redist.x86.exe) and store them in your "Downloads" directory;

3. run the two installers from your "Downloads" directory;

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

I have created a video, which shows this:
* webm: https://mega.nz/#!aZYz0IIR!a_ycfhC10WGCfP-WArlRmEzLj-BVPr9-xDn8UfbtnrU
* gif: https://mega.nz/#!jMR1hKLJ!vcaw-PypYm-nh2EDGfFrbxZuoOGm_fYX01NGtGOYyyo

Due to the application manifest embedded in the installers which specifies "requireAdministrator" the executable installer is run with administrative privileges ("protected" administrators are prompted for consent, unprivileged standard users are prompted for an administrator password); execution of the DLLs therefore results in a privilege escalation!

Additionally I noticed that vc_redist.x86.exe is copied to the temporary directory. The path is like this:
> %temp%\<GUID>\.be\VC_redist.x86.exe
This should generally be avoided as %temp% is another unsafe directory, writeable by users without admin privileges. So when the file is placed there the same DLLs may be planted there or even the exe file itself may be replaced.
I did not verified whether this is possible and is another vulnerability, but it is at least bad practise.

All this information is treated as strictly confidential and no other person knows about the issues I discovered. I have not submitted this information to anyone.
Until the issue is resolved I will not tell anyone of this issue and keep it secret. However if you do not respond during 90 days or fix the error 90 after your first response I may make this information public. This helps to protects your users.
However I hope I do not have to do this and cooperation from your site would be very much appreciated.

Best regards,
<privat>

-----

Timeline:

* 2016-02-16: send
* 2016-02-16:
> We are aware of the reports of binary planting in the
> application directory (e.g. "Downloads" Folder). At this time, binary
> planting in the application directory does not meet the bar for
> security servicing by MSRC. For all other binary planting issues we
> still service them through MSRC security servicing.
>
> [links to docs included]

Based on the provided link [Definition of a Security Vulnerability](https://technet.microsoft.com/library/cc751383.aspx)] I explained why this is a vulnerability and asked what's the difference "between binary planting in the downloads folder compared to another folder?"

* 2016-02-16:
> This is a long standing and well known by Microsoft. Binary
> planting in the application directory does not meet the bar for
> security servicing as I mentioned previously.
>
> [links to docs included]

Again replied and asked "what folder does it have to be loaded to 'meet the bar for security servicing'?" Showed that the linked docs do not answer my question.

Me:
> Fact is in your applications you do not followed your own
> recommendations! That's why there are these issues...

* 2016-02-17:
> The difference is that the DLL would not be in the same folder
> as the program that is being ran. The "Current Working Directory-based
> Attack" would be an example of binary planting outside of the
> application directory. https://www.owasp.org/index.php/Binary_planting

Agreed and asked what to do now:
> 1. Will it be fixed?
> 2. Should I contact someone else about this issue?
> 3. Can I get some other "servicing" for this bug?

* 2016-02-17:
> Teams are well aware of this issue and working on solutions but there is no ETA on fixing there are many scenarios that must be accounted for. There is no further action that can be taken regarding this issue at this time.
* 2015-05-16: report published

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

March 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    15 Files
  • 2
    Mar 2nd
    5 Files
  • 3
    Mar 3rd
    3 Files
  • 4
    Mar 4th
    25 Files
  • 5
    Mar 5th
    20 Files
  • 6
    Mar 6th
    16 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    12 Files
  • 9
    Mar 9th
    3 Files
  • 10
    Mar 10th
    4 Files
  • 11
    Mar 11th
    23 Files
  • 12
    Mar 12th
    12 Files
  • 13
    Mar 13th
    12 Files
  • 14
    Mar 14th
    19 Files
  • 15
    Mar 15th
    12 Files
  • 16
    Mar 16th
    3 Files
  • 17
    Mar 17th
    1 Files
  • 18
    Mar 18th
    15 Files
  • 19
    Mar 19th
    22 Files
  • 20
    Mar 20th
    14 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    17 Files
  • 23
    Mar 23rd
    1 Files
  • 24
    Mar 24th
    1 Files
  • 25
    Mar 25th
    16 Files
  • 26
    Mar 26th
    0 Files
  • 27
    Mar 27th
    0 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2019 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close