注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

K8拉登哥哥's Blog

K8搞基大队[K8team] 信息安全 网络安全 0day漏洞 渗透测试 黑客

 
 
 

日志

 
 

[提权]Microsoft Visual C++ DLL Hijacking  

2016-05-20 11:04:33|  分类: 提权工具 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
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>.beVC_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
  评论这张
 
阅读(1220)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2016