微软Exchange似乎易受权限提升攻击影响,任何用户,只要有邮箱,就能变身为Domain Admin

荷兰Fox-IT公司研究员Dirk-jan Mollema在博客上发布了PoC,并详细解释了攻击细节。Mollema认为,主要的问题在于,Exchange默认在活动目录域名具有高权限。

他在博客文章中指出,“ExchangeWindowsPermissions组在活动目录的 Domain 对象上具有WriteDacl访问权限,使得该组成员均可修改域名权限,其中的一个权限是执行DCSync操作。”

这就导致攻击者能够通过Domain Controller操作同步活动目录用户的哈希密码。攻击者可通过访问这些哈希密码假冒用户并在使用NTLM(微软的认证协议)或该域名内的Kerberos认证的服务进行认证。

目前,Mollema尚未回应相关问题。他发布的博客文章题目是《滥用Exchange:你距离成为Domain Admin仅差一个API调用》。全文如下:

在多数使用活动目录和Exchange的组织机构中,Exchange服务器都具有一种高权限:成为Exchange服务器上的Administer就足以提升至Domain Admin。最近我在ZDI上偶然发现了一篇博客文章(见文末链接),他们详细说明了如何使用NTLM经由HTTP让Exchange进行认证。结合使用NTLM中继攻击,任何人只要拥有一个邮箱就能提升至Domain Admin权限,在我所知道的大概90%的使用Exchange组织机构中都是可行的。这种攻击可能是默认的,目前尚未有任何补丁,不过可以使用一些缓解措施来阻止此类权限提升问题。本文详细说明了这种攻击,而且PoC已发布,名为“PrivExchange”。

结合利用已知漏洞的新方法

这篇文章讲的是如何结合利用一些新漏洞以及已知的协议弱点,发动新攻击。结合使用3个组件,拥有邮箱的任何用户就能提升至Domain Admin访问权限:

Exchange Servers默认的权限太高

NTLM认证易受中继攻击

Exchange的某个功能使其能够认证到具有Exchange服务器计算机账户的攻击者

 Exchange和高权限

这里说的主要漏洞是,Exchange在活动目录域名中具有高权限。Exchange Windows Permissions组在活动目录的Domain对象中具有WriteDacl访问权限,导致该组的任何成员都能修改域名权限,其中一种权限是执行DCSync操作。任何具有这种权限的用户或计算机都能执行同步操作,而这种操作正常情况下是供Domain Controllers进行复制,这就导致攻击者能够同步活动目录中的所有用户的哈希密码。多名研究人员曾对此进行过阐述(见文末参考部分),而且我和同事Rindert也在去年写过。在那篇文章中我也发布了ntlmrelayx的更新,增加了在NTLM中继过程中执行这些访问控制清单(ACL)攻击的可能性。

NTLM 中继机器账户

NTLM中继已经存在有段时间了。之前,它的主要关注点是经由SMB中继NTLM,以便在其它主机上执行代码。虽然到目前为止,仍然很可能在很多未启用SMB签名进行安全加固的公司中实施这种攻击,但其它协议也易受中继攻击。我认为其中最有意思的协议就是LDAP,它可用于读取并修改活动目录中的对象。简单说一下NTLM中继,就是除非已经应用了缓解措施,否则在连接至攻击者机器上之后和网络中的其它机器进行连接时,很可能会绕过Windows自动执行的认证,如下图所示:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

当认证被中继到LDAP时,目录中的对象可被修改,给予攻击者权限,包括DCSync操作所需要的权限。因此,如果我们能够使Exchange通过NTLM认证和我们进行认证,那么我们就能执行ACL攻击。值得注意的是,只有在受害者通过HTTP而非SMB和我们进行认证时,中继到LDAP才奏效。

使 Exchange 进行认证

目前为止,唯一一个缺失的组件是使Exchange认证到我们的一种简单方法。ZDI的一名未透露姓名的研究员发现,使 Exchange 经由 Exchange PushSubscription功能通过 HTTP 向任意 URL 认证是很可能实现的。他们使用这个漏洞将NTLM认证中继回Exchange(即反射型攻击)并假冒其他用户。如果我们再结合Exchange默认具有的高权限并执行中继攻击而非反射型攻击,那么我们就能使用这些权限获得DCSync权限。这个推送通知服务允许用户在即使未发生任何事件的情况下每隔X分钟(X值由攻击者设定)发送一次信息。这就能确保Exchange即使在收件箱中没有任何活动的情况下和我们连接。

执行权限提升攻击

实施攻击,实现权限提升的流程如下图所示:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们需要使用两款工具执行该攻击:privexchange.pyntlmrelayx。这两款工具可从GitHub的PrivExchange和impacket库中获取。以中继模式启动ntlmrelayx,以Domain Controller上的LDAP作为目标,并通过如下代码使受攻击者控制的用户提升权限(这个案例中是ntu用户):

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们开始运行privexchange.py脚本:

1000.jpg

如果是以没有邮箱的用户运行的话,就会得到如上出错消息。再尝试一下通过具有关联邮箱的用户运行一下:

1001.jpg

一分钟之后(推送通知提供的值),我们可以看到连接进入ntlmrelayx,用户获得DCSync权限:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

我们确认DCSynx权限位于secretsdump位置:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

凭借所有活动目录用户的哈希密码,攻击者就相当于持有一张金卡,能够假冒任何用户或使用任何用户密码哈希认证到任何接受NTLM或Kerberos域名认证的服务。

技术细节:中继到 LDAP 并签名

上文提到从SMB中继到LDAP不起作用,这也是为何说这种攻击无法通过使用最近发布的SpoolService RPC滥用等实施(它通过SMB认证)的原因。由于关于这部分的问题很多,现在统一说一下。如果你不打算详细了解NTLM认证部分,可以跳过这部分。

在SMB和HTTP中的NTLM认证的不同之处在于默认协商的标记(flag)。有问题的部分是NTLMSSP_NEGOTIATE_SIGN标记(0x00000010),如MS-NLMP第2.2.2.5节所示。通过HTTP的NTLM认证并不会默认设置该标记,但如果是通过SMB认证,则会默认设置:

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

当我们将它中继到LDAP时,认证成功,但LDAP的预期是所有通过衍生自密码的会话密钥签名的信息(中继攻击中不具备)。因此它会忽视任何不具备签名的信息,从而导致攻击失败。有人可能会想,是否可以在传输过程中修改这些标记,这样就不用协商签名了。由于Windows现代版本都默认包含一个MIC(信息完整性代码)即基于所有3 NTLM信息的签名,因此对其中任何信息的修改都会导致其不合法。

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

那我们能删除MIC吗?可以是可以,毕竟它并非受NTLM信息保护的部分,但问题是NTLM认证(NTLMv2)中的最后一道防护措施阻止这样做:在 NTLMv2 响应的底部(该响应本身以受害者密码签名)存在一个AV_PAIR 结构MsAvFlags。当该字段的值为0x0002 时,表明客户端发送了一个具有type 3信息的MIC。

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

修改NTLMv2响应将导致认证失效,因此我们不能删除这个flags字段。该字段说明MIC被计算且包含,将使目标服务器验证MIC,从而验证所有的3信息都不会在传输过程中遭修改,因此我们无法删除签名标记。

我认为,这种情况仅对微软对NTLM的实现有效。实现NTLM的自定义工具很可能并不受影响,只有添加MIC和AV_PAIR标记时,导致它们易受标记修改攻击,从而导致SMB -> LDAP中继成为可能。其中一个例子就是NTLM的Java实现,它可在传输过程中遭修改绕过安全措施。

攻击无需任何凭证

上一节中,我们使用受攻陷凭证执行了攻击的第一步。如果攻击者只是位于执行网络攻击的位置,但并不具备任何凭证,那么仍然很可能触发Exchange进行认证。如果我们执行SMB到HTTP(或HTTP到HTTP)中继攻击(使用LLMNR/NBNS/mitm6欺骗),那么我们就能将位于同样网络片段中的用户认证中继到Exchange EWS并使用他们的凭证触发回调。我给出了一小段修改后的httpattack.py,你可以结合ntlmrelayx从网络角度实施攻击,而无需任何凭证(你只需要修改攻击者主机即可,因为它在文件中是硬编码的):

微软 Exchange 爆出 0day 漏洞,来看 POC 和技术细节

缓解措施

攻击依靠多种组件才能实施。在此前的博客文章中我已经强调过多种针对NTLM中继攻击和中继到LDAP的防御措施。

适用于该攻击的最重要的缓解措施包括:

删除Exchange在Domain对象上的不必要的高权限。

启用LDAP签名以及LDAP信道绑定,分别阻止中继到LDAP和LDAPS。

阻止Exchange服务器和任意端口上的工作站进行连接。

启用IIS中Exchange端点上(并非Exchange Back End,否则会导致Exchange崩溃)的Extended Protection for Authnticaiton。它将验证NTLM认证中的信道绑定参数,它将NTLM认证关联到TLS连接中并阻止向Exchange web服务进行中继。

删除注册表项(registry key),从而能够中继回Exchange服务器,如微软对CVE-2018-8518缓解措施的讨论。

在Exchange服务器上执行SMB签名(偏好域名中的所有其它服务器和工作站)以阻止针对SMB的跨协议中继攻击。

如果不使用EWS的push/pull订阅服务,则可以通过使用限制策略将EWSMaxSubscriptions设置为0的方式禁用。这是@gentikiwi提供的方法,我还没有测试过合法应用程序使用它们的频率,因此推荐在小范围内进行测试。

工具以及受影响版本

PoC请参见 https://github.com/dirkjanm/PrivExchange,且已在如下Exchange/Windows版本上进行了测试:

将Server2012R2 上的Exchange 2013 (CU21)中继到Server 2016 DC(都是完全修复版本)

将Server 2016上的Exchange 2016 (CU11)中继到Server 2019 DC(都是完全修复版本)

将Server 2019上的Exchange 2019中继到Server 2019 DC(感谢@gentilkiwi进行测试)

如上的Exchange服务器都是使用共享权限模式安装的(默认),但有writeup指出,RBAC拆分权限部署也很容易受到攻击(我并未亲自测试过)。

Exchange 2010 SP3似乎并未受影响。在我的实验室中,这个版本按类似于以上提及的SMB协商签名,从而打破了这种中继攻击。版本14.3.435.0以及14.3.123.4均展现出这种行为。

资源/参考

可参见如下博客文章、白皮书和研究论文了解关于此类攻击的更多信息:

1. 缓解资源

https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1 

https://www.blackhat.com/docs/webcast/04262018-Webcast-Toxic-Waste-Removal-by-Andy-Robbins.pdf 

ACL权限提升研究

https://www.blackhat.com/docs/us-17/wednesday/us-17-Robbins-An-ACE-Up-The-Sleeve-Designing-Active-Directory-DACL-Backdoors-wp.pdf

2. NTLM中继/签名讨论

NTLM反射型攻击回顾https://github.com/SecureAuthCorp/impacket/issues/451

NTLM SMB-> LDAP中继https://github.com/SecureAuthCorp/impacket/pull/500

中继凭证林总

https://www.secureauth.com/blog/playing-relayed-credentials

3.其它参考

MS-NLMP

https://msdn.microsoft.com/en-us/library/cc236621.aspx

讨论Exchange API的ZDI文章

https://www.zerodayinitiative.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange

通过meterpreter进行NTLM远程中继,讨论如何远程通过枢纽主机进行中继

https://diablohorn.com/2018/08/25/remote-ntlm-relaying-through-meterpreter-on-windows-port-445/

ACL攻击相关

https://www.slideshare.net/DirkjanMollema/aclpwn-active-directory-acl-exploitation-with-bloodhound

原文链接

https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/

*本文作者:360代码卫士;转载请注明来自FreeBuf.COM

近期,研究人员发现了一种能够读取加密数据的新型侧信道攻击技术,这种攻击技术针对的是操作系统,而不是芯片,而且这种技术将有可能成为网络犯罪分子获取目标公司加密技术的关键。

研究人员发现了一种读取加密数据的新型侧信道攻击

这种新型的侧信道攻击主要针对的是操作系统,它能够绕过特定硬件的芯片,主要利用现代操作系统的基础功能来访问开发人员和用户想要尝试隐藏的那些数据。

研究人员在这份标题为《页面缓存攻击》的论文中提到:“这种技术主要针对的是Windows和Linux操作系统,但也有可能适用于其他操作系统。除此之外,它不需要对硬件中那些乱七八糟的指令进行分析,它主要依赖的是低权限用户通过操作系统就能够获取到的简单系统调用。”

Alex Lonescu不仅是该研究团队中的一员,而且他还是CrowdStrike的高层。他专门解释了攻击成功所需的几个要素:“首先,如果你有办法向目标设备的缓存中注入数据的话,那么你需要确保这些数据已经成功注入到缓存里了,接下来当你尝试导出这些数据时,你就会得到一些有意思的东西。”更重要的是,研究人员还发现不仅只有硬件有缓存这种东西,现在几乎任何东西都有缓存。

这种新漏洞的强大之处就在于,它可以检测并提取整个缓存页表上的数据,甚至是那些只存在了几毫秒的数据它都能获取到。由于攻击本身只需要花几毫秒的时间,因此攻击者有足够多的时间来做他们想做的事情,比如说读取用户的键盘击键数据和那些涉及到加密密钥查询的明文响应数据。

研究人员发现了一种读取加密数据的新型侧信道攻击

Tripwire的VERT团队在对该漏洞的潜在影响进行分析之后,给DrakReading写了一封电子邮件。他们在邮件中写到:“研究人员已经演示了如何利用现代操作系统架构中的漏洞来在孤立的进程之间创建隐蔽的数据传输信道,而且攻击者设置还可以存储键盘记录,并监视随机数生成器。更重要的是,攻击者可以利用低权限进程来实现数据的窃取。”

这种攻击技术基于的是目标操作系统中合法的系统调用,研究人员表示:“之所以会存在这种问题,是因为原本的操作系统设计得过于宽松,给非特权进程的权限过多,导致它们可以访问某些与缓存相关的系统调用。”

研究人员还举了个例子,比如说PHP框架中就使用了PHP函数microtime()来作为伪随机数种子,并用来进行密码操作。由于攻击者可以捕捉到返回的微时间以及调用密码生成器的请求,所以他们就能够了解加密的基本信息,从而使解密的过程变得更加简单。

研究人员发现了一种读取加密数据的新型侧信道攻击

虽然这种攻击是可以有办法防御的,但这需要操作系统厂商和应用程序开发者的共同努力,然后通过修改代码来修复这个漏洞。

* 参考来源:darkreading,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

不传谣不信谣,题目说了疑似,所以不管怎么着,改密码吧

image.png

2019年1月30日,一位名叫"Andrew"的未知黑客通过Pastebin网络服务发布了一份在线声明,据称宣布了其拥有属于LinkedIn的1.59亿客户数据库。

为了证明真假,黑客已经发布了一份包含100个客户的样本列表及其帐户登录凭据,作为泄露数据的证明。

image.png

目前,黑客拒绝公开分享整个泄露的数据库,而是愿意以99美元的价格向愿意购买的人出售完整的清单。

image.png

此外,对于不想直接购买整个数据库的人,黑客也提出以一小笔费用0.012比特币(41美元)的价格来破解你想要的任何人的个人账户。

Yes, this means that for .012BTC  you can hack ANY linkedin user, and if they use the same password on other sites you can hack into there too. Their iCloud with all their personal photos, their email accounts, facebook and instagram are all vulnerable to being hacked once you have this database.

Enjoy and please help keep this leak private by not sharing it after you've purchased. 

google翻译:

是的,这意味着对于.012BTC,您可以破解任何linkedin用户,如果他们在其他网站上使用相同的密码,您也可以入侵。 他们的iCloud及其所有个人照片,他们的电子邮件帐户,Facebook和Instagram都很容易被拥有此数据库后被黑客入侵。

在购买之后,请不要分享,请尽量帮助保密。

image.png

这群黑客看起来也试图在网上出售其他200个网站的黑客数据库– 每件20 至150美元 一件,包括各种著名的和非著名的网站。

emm。。好像看见了某些著名网站。。

image.png

具体参考链接。。拉到文末

当然以前领英也是出过类似的数据泄露大事件的,像2016年的大事件:

1.17亿LinkedIn领英数据正在暗网地下黑市热卖

https://www.freebuf.com/news/104895.html

image.png

反正,不管数据来源真假,大家勤劳改密码才是真道理。(改完随便转发一下嘛!)

如果数据属实,这恐怕是2019年开年以来最大的一起数据泄露事件了。

参考链接:

[1]https://roguemedialabs.com/2019/01/30/hacker-selling-database-of-159-million-clients-leaked-from-linkedin-online/

[2]https://rocketr.net/buy/bfd77635ea0a

[3]https://pastebin.com/x9ECRdis

[4]https://pastebin.com/sXPPyFYk

Kaspersky研究人员在2018年发现一个在受害者计算机中安装恶意浏览器扩展或感染已安装的扩展的恶意软件。恶意软件可以关闭已安装的扩展的完整性检查,并为目标浏览器自动更新。Kaspersky安全产品检测到该恶意软件为Razy,通过恶意广告拦截模块进行传播,并伪装成合法软件在免费文件主机服务上进行分发。

Razy的目的有很多,主要是与窃取加密货币相关。其主要工具是main.js脚本,可以:

· 搜索网站上的加密货币钱包的地址,并将其替换为攻击者的钱包地址;

· 伪造指向钱包的二维码图片;

· 修改加密货币交易页面;

· 欺骗Google和Yandex搜索结构。

感染

Razy木马工作在Google Chrome, Mozilla Firefox和Yandex浏览器上,对不同的浏览器有不同的感染场景。

Mozilla Firefox

对Firefox,Razy会安装一个名为Firefox Protection的扩展,ID为{ab10d63e-3096-4492-ab0e-5edcf4baf988} (文件夹路径为:

“%APPDATA%\Mozilla\Firefox\Profiles\.default\Extensions\{ab10d63e-3096-4492-ab0e-5edcf4baf988}”)。

恶意扩展开始工作后, Razy会编辑以下文件:

·  “%APPDATA%\Mozilla\Firefox\Profiles\.default\prefs.js”,

· “%APPDATA%\Mozilla\Firefox\Profiles\.default\extensions.json”,

· “%PROGRAMFILES%\Mozilla Firefox\omni.js”.

Yandex 浏览器

木马会编辑%APPDATA%\Yandex\YandexBrowser\Application\\browser.dll来关闭扩展的完整性检查。然后重命名原始文件为browser.dll_,然后将其放在同一文件夹内。

木马会创建注册表‘HKEY_LOCAL_MACHINE\SOFTWARE\Policies\YandexBrowser\UpdateAllowed” = 0 (REG_DWORD)来关闭浏览器更新。

然后,安装扩展Yandex Protect到文件夹%APPDATA%\Yandex\YandexBrowser\User Data\Default\Extensions\acgimceffoceigocablmjdpebeodphgc\6.1.6_0。ID acgimceffoceigocablmjdpebeodphgc对应的合法扩展为Cloudy Calculator, 版本号为6.1.6_0。如果Yandex浏览器已经安装了该扩展,就会被替换为恶意的Yandex Protect。

Google Chrome

Razy会编辑文件%PROGRAMFILES%\Google\Chrome\Application\\chrome.dll来关闭扩展的完整性检查。然后将原来的chrome.dll文件重命名为chrome.dll_。

然后创建以下注册表来关闭浏览器更新:

“HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes” = 0 (REG_DWORD)
“HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\DisableAutoUpdateChecksCheckboxValue” = 1 (REG_DWORD)
“HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\InstallDefault” = 0 (REG_DWORD)
“HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\UpdateDefault” = 0 (REG_DWORD)

研究人员遇到很多种不同的Chrome扩展被感染的情况。其中一个是Chrome Media Router,Chrome Media Router是基于Chromium的浏览器的服务的组件。在所有的Chrome浏览器中都安装了,但是在已安装扩展中没有显示。在感染过程中,Razy会修改Chrome Media Router扩展所在的文件夹的内容:

‘%userprofile%\AppData\Local\Google\Chrome\User Data\Default\Extensions\pkedcjkdefgpdelpbcmbmeomcjbeemfm’.

使用的脚本

无论是哪种目标浏览器类型,Razy会添加下面的脚本到含有恶意脚本的文件夹中:bgs.js, extab.js, firebase-app.js, firebase-messaging.js和firebase-messaging-sw.js。在同一文件夹中创建或覆写文件manifest.json来确保这些脚本得到调用。

 

原始Chrome Media Router扩展(左)和修改后的Chrome Media Router扩展(右)

脚本firebase-app.js, firebase-messaging.js和firebase-messaging-sw.js都是合法文件。属于Firebase平台,用来发送统计数据到恶意攻击者的Firebase账号。

脚本bgs.js和extab.js都是恶意文件,使用工具obfuscator.io进行了混淆。第一个脚本会发送统计数据到Firebase账号,第二个脚本会在脚本 i.js的调用中加入参数

tag=&did=&v_tag=&k_tag=。

脚本 i.js会修改HTML页面,插入广告和视频片段,以及Google的搜索结果。

i.js 在YouTube页面加入的广告

感染主要是通过main.js完成的,对脚本的调用会加入到用户访问的每个页面中。

 

插入脚本main.js到web页面的i.js代码片段

Main.js脚本通过以下地址进行传播:

· Nolkbacteria[.]info/js/main.js?_=

· 2searea0[.]info/js/main.js?_=

· touristsila1[.]info/js/main.js?_=

· solkoptions[.]host/js/main.js?_=

脚本main.js是不混淆的,其功能可以从函数名中看出:

 

上图是函数findAndReplaceWalletAddresses的代码,可以看出其功能是搜索Bitcoin和Ethereum钱包,并用攻击者的钱包地址进行替换。该函数在除了Google和yandex域名外的其他几乎所有页面都可以工作,甚至包括 instagram.com和ok.ru。

指向钱包地址的二维码也可能会被替换。当用户访问web页gdax.com, pro.coinbase.com, exmo.*, binance.* 或页面中含有src=’/res/exchangebox/qrcode/’元素时,就会发生替换。

除了上面描述的函数外,main.js会修改加密货币交易所EXMO和YoBit的web页面。调用以下脚本加入到页面的二维码中:

· /js/exmo-futures.js?_= – when exmo.*/ru/* pages are visited

· /js/yobit-futures.js?_= – when yobit.*/ru/* pages are visited

当域名是nolkbacteria[.]info, 2searea0[.]info, touristsila1[.]info, archivepoisk-zone[.]info时。

这些脚本会展示给用户关于对应的交易所的新特征,并提供以市场利率出售加密货币的服务。换句话说,用户会被说服将钱转入攻击者的钱包里。

 

EXMO交易网站上的垃圾消息示例

Main.js还会欺骗Google和Yandex的搜索结果。如果搜索请求其连接到加密货币或者加密货币交易网站,页面中就会显示伪造的搜索结果:

· /(?:^|\s)(gram|телеграм|токен|ton|ico|telegram|btc|биткойн|bitcoin|coinbase|крипта|криптовалюта|,bnrjqy|биржа|бираж)(?:\s|$)/g;

· /(скачать.*музык|музык.*скачать)/g;

· /тор?рент/g;

这就是为什么受感染的用户会访问受感染的网站或合法的加密货币主题的网站:

 

Google搜索结果被感染的扩展修改

当用户访问Wikipedia时,main.js也会加入含有支持该网站的广告框。而原来的donation请求会被删除。 

要求支持Wikipedia的伪造广告栏

当用户访问telegram.org官网时,也会看到以极低的价格购买Telegram tokens的信息:

 

受感染的扩展从钓鱼web资源ton-ico[.]network加载telegram.org站点内容

 

telegram.org上的恶意广告

当用户访问俄罗斯社交网络Vkontakte (VK)时,木马也会加入广告栏。如果用户点击,就会被重定向到位于域名ooo-ooo[.]info的钓鱼资源,之后会弹出让用户支付少量钱来获取大量贷款的信息。

 

vk.com站点上的虚假广告

我们在Google Play上发现了几款美容相机应用(检测为AndroidOS_BadCamera.HRX),可以访问用于恶意目的的远程广告配置服务器。其中一些已经被下载了数百万次,考虑到这些类型的应用程序的流行,这并不奇怪。大量的下载来自亚洲,尤其集中在印度。

图1. Google Play上恶意美容相机应用的屏幕截图

技术分析

下载应用程序的用户不会立即怀疑其有任何不妥之处,直到他们决定删除该应用程序。以com.beauty.camera.project.cloud包为例,它将在启动后创建一个快捷方式。但是,它会将其图标从应用程序列表中隐藏,这使得用户更难以卸载该应用程序,因为他们无法拖动和删除。此外,相机应用程序使用加壳程序来防止它们被分析。

图2.显示恶意应用程序如何从应用程序列表中隐藏自身的代码段

当用户解锁设备时,该应用会推送几个全屏广告,包括将通过用户的浏览器弹出的恶意广告(如欺诈性内容和色情内容)。在分析过程中,我们发现了一个付费的在线色情播放器(检测为AndroidOS_PornPlayer.UHRXA),在点击弹出窗口时下载了该播放器。但请注意,即使在用户付费并启动播放器之后,也不会播放任何内容。

没有任何迹象表明这些应用程序的背后是广告,因此用户会很难发现它们的来源。其中一些应用程序重定向到网络钓鱼网站,要求用户提供个人信息,例如地址和电话号码。例如,在下图中,单击中间屏幕截图中的“确定”按钮将用户重定向到新页面,这将为用户提供三次尝试以赢得奖品。第三次尝试将始终允许用户获胜,之后将出现一个表单,询问用户详细信息。

图3.弹出广告的屏幕截图(中间截图中的中文文本是用户赢得iPhone X的公告,在弹出窗口上单击确定将显示钓鱼网站)

该应用程序将从以下远程服务器和外部URL下载广告配置,它们将分析目标设备以确定广告的行为:

· hxxps://d3pukqxlxhielm.cloudfront.net/congfig[.]json

· hxxps://dgld3i8oh1hf6.cloudfront.net/congfig[.]json

然后安排后台服务解析配置并调用设备的浏览器。

图4和5.网络流量和代码段显示浏览器弹出不需要的广告

另一批恶意相机应用程序

进一步深入调查后,发现了另一批与照片过滤器相关的应用程序,它们在Google Play上具有相似的行为。这些应用程序允许用户通过将他们的图片上传到指定的服务器来“美化”。但是,用户不会获得最终已编辑的照片,取而代之的是使用九种不同语言的假冒更新提示获取图片。作者可以收集在应用程序中上传的照片,并可能将其用于恶意目的 – 例如,在社交媒体中伪造的个人资料照片。

图6:ART照片编辑器(中间:“编辑过程”,右:虚假更新)

这些应用程序使用的远程服务器在代码中使用BASE64编码了两次。此外,其中一些应用程序也可以通过上面提到的相同隐藏技术隐藏自己。

在撰写本文时,谷歌已经删除了这些应用程序。

图7:从Google Play下载的恶意相机过滤应用

建议

鉴于许多恶意应用程序看起来都很合法,用户应该始终调查应用程序的合法性。一个好方法是检查来自其他用户的评论。如果评论提到任何类型的可疑行为,那么就不要下载应用程序。

图8.来自其中一个应用程序的评论(大多数分数是五星级或一星级,呈“U”形曲线,这可能表明合法评论者给出的评分较低,而假冒评分则给出尽可能高的评分)

 

IoCs

1.png

一、概述

在最近的内部渗透测试中,我遇到了一个EDR产品(在本文中将不会提及产品名称)。该产品极大程度的阻碍了我访问lsass内存的过程,并且使我们无法使用自定义的Mimikatz工具来转储明文的凭据。

1.png

二、错误的道路

所以现在,假设我是一位恶意软件作者,我其实可以编写特定的驱动程序来对抗检测和阻止。我的第一个想法是Obregistercallback,这是许多反病毒产品常用的方法。由于许多反病毒产品都会非常粗略的重新组装恶意软件Rookit的WinAPI挂钩,因此微软实施了这一回调。但是,在MSDN的最下面,我们能看到一行文字:“该回调从Windows Vista Server Pack 1(SP1)和Windows Server 2008开始可用”。为了提供一些缺少的上下文,我此刻正在Windows Server 2003上进行操作。因此,该系统缺少用于阻止反病毒产品检测的所需功能。

在进行了几个小时的尝试之后,我试图利用csrss.exe,并尝试通过csrss.exe来继承lsass.exe的句柄。最终,成功获得了一个带有PROCESS_ALL_ACCESS到lsass.exe的句柄。我们通过滥用csrss生成子进程,然后继承已存在的lsass句柄,最终实现了这一方法。

2.png

然而,当我即将沉浸在喜悦之中时,得到了令人失望的结果。EDR还是阻止了ShellCode注入csrss,同时也阻止了通过RtlCreateUserThread创建线程。由于某种原因,代码未能作为子进程生成,并且没有继承句柄,但我们仍然能以某种方式获得lsass.exe的PROCESS_ALL_ACCESS句柄。

接下来,我们试着打开一个lsass.exe的句柄,代码只有这一行:

HANDLE hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, lsasspid);

现在,我居然获得了一个完全控制lsass.exe的句柄。EDR没有对此进行模糊测试。在这时,我意识到,我走向了错误的道路,因为EDR从来没有关注我们是否获得句柄访问权限,而是我们接下来要进行的操作会受到严格检查。

三、回到正轨

我们已经获得lsass.exe的完整控制句柄,现在可以继续前进,解决下一个关键的突破口。我们立即尝试使用句柄调用MiniDumpWriteDump(),但结果是失败的。

3.png

我们来进一步分析这个警告内容:“Violation: LsassRead”(违规:lsass读取)。实际上,我们并没有做任何读取操作,只想对进程进行转储。然而,要转储远程进程,必须在MiniDumpWriteDump()中调用某种类型的WinAPI,例如ReadProcessMemory(RPM)。我们来看看ReactOS上的MiniDumpWriteDump的源代码。

4.png

正如大家所看到的,函数(2) dump_exception_info()以及许多其他函数都依赖于(3) RPM来执行其功能。这些函数由MiniDumpWriteDump (1)引用,这可能就是问题的根源所在。现在,我们有一些经验可以发挥作用。我们必须了解Windows系统内部工作原理,以及如何处理WinAPI的过程。以ReadProcessMemory为例,其工作方式如下。

ReadProcessMemory只是一个包装器,它会进行一系列健全性检查,例如nullptr检查。实际上,这就是RPM所做的一切。但除此之外,RPM还调用函数NtReadVirtualMemory,该函数在执行系统调用指令之前设置寄存器。系统调用指令会通知CPU进入内核模式,然后调用另一个名为NtReadVirtualMemory的函数,它执行ReadProcessMemory应该执行的操作的实际逻辑。

— — — — — -Userland — — — —- — — — | — — — Kernel Land — — — —
 
RPM — > NtReadVirtualMemory --> SYSCALL->NtReadVirtualMemory
 
Kernel32 — — -ntdll — — — — — — — — — - — — — — — ntoskrnl

在有了上述知识后,我们现在必须确定EDR产品如何检测并阻止RPM/NtReadVirtualMemory调用。答案其实非常简单,就是“挂钩”(Hook)。有关挂钩的更多信息,可以参考我之前发表的文章。简而言之,该操作使得我们可以将代码放置在任意函数的中间,并获得对参数和返回变量的访问权限。我非常确定,EDR是通过我提到的一种或多种技术,使用了某种挂钩技术。

但是,读者应该清楚,大多数EDR产品都在使用服务,特别是内核模式下运行的驱动程序。通过访问内核模式,驱动程序可以在RPM的callstack中的任何级别执行挂钩。但是,如果任何驱动程序挂起任何级别的函数都是微不足道的,这会在Windows环境中产生一个巨大的安全漏洞。因此,必须要提出一种解决方案来防止这种性质的改变,这种解决方案就是核心补丁保护(又称为KPP或Patch Guard)。KPP几乎在每个级别都进行内核扫描,如果检测到修改,将会触发BSOD。这包括ntoskrnl部分,其中包含WinAPI内核级别的逻辑。在掌握这些背景知识后,我们可以确信,EDR不会挂钩调用栈中的任何内核级别函数,我们就可以使用用户空间的RPM和NtReadVirtualMemory调用。

四、挂钩

要查看函数在应用程序内存中的位置,与具有%p格式字符串的printf和函数名称作为参数一样简单,如下所示。

5.png

但是,与RPM不同,NtReadVirtualMemory不是ntdll中的导出函数,因此我们不能像正常情况下一样引用该函数。我们必须指定函数的签名,并将ntdll.lib链接到项目中,才能执行该操作。

6.png

一切就绪,让我们尝试运行。

7.png

现在,我们得到了RPM和NtReadVirtualMemory的地址。接下来,我将使用我最喜欢的逆向工具Cheat Engine来读取内存并分析其结构。

ReadProcessMemory:

8.png

NtReadVirtualMemory:

9.png

对于RPM函数,它看起来一切正常。它会执行一些栈和寄存器的设置,然后在Kernelbase内调用ReadProcessMemory。最终将导致我们进入到ntdll的NtReadVirtualMemory。但是,如果我们查看NtReadVirtualMemory并了解基本的钩子是什么样的,我们就能发现其中的异常之处。函数的前5个字节被修改,其余字节则保持原样。我们可以通过查看周围的其他类似函数来判断这一点。所有其他函数都遵循非常相似的格式:

0x4C, 0x8B, 0xD1, // mov r10, rcx; NtReadVirtualMemory
 
0xB8, 0x3c, 0x00, 0x00, 0x00, // eax, 3ch — aka syscall id
 
0x0F, 0x05, // syscall
 
0xC3 // retn

其中的一个区别就是系统调用ID(它标识了内核域中调用的WinAPI函数)。但是,对于NtReadVirtualMemory,第一条指令实际上是对内存中其他地址的JMP指令。我们来具体看一下。

CyMemDef64.dll:

10.png

好吧,所以我们并不是在ntdll的模块中,而是在CyMemDef64.dll的模块中。啊,现在我明白了。

EDR放置了原始NtReadVirtualMemory函数中应该存在的跳转指令,将代码流重定向到他们自己的模块中,然后检查所有类型的恶意活动。如果检查失败,那么Nt*函数将返回错误代码,不会进入内和空间,并执行开始的部分。

五、绕过方法

现在,我们已经掌握了EDR如何检测并阻止我们WinAPI调用的方式,这是非常明显的。但是,我们如何解决这一问题呢?有两种解决方案。

5.1 重新修补补丁

既然我们知道NtReadVirtualMemory函数应该是什么样子,那么我们就可以使用正确的指令轻松覆盖JMP指令。这将阻止我们的调用被CyMemDef64.dll拦截,并会进入到他们无法控制的内核之中。

5.2 Ntdll IAT Hook

我们也可以创建自己的函数,类似于在5.1中所进行的操作,但不是覆盖挂钩函数,而是在其他地方重新创建它。然后,我们进入到Ntdll的导入地址表,交换NtReadVirtualMemory的指针,并将其指向我们新的fixed_NtReadVirtualMemory。这种方法的优点在于,如果EDR检查了它们的挂钩,看起来就像没有经过修改一样。它永远不会被调用,而ntdll IAT指向其他地方。

六、结果

最终,我选择了第一种方法,该方法更为简单。然而,第二种方法也并不复杂,我打算在之后的几天再尝试一下这种方法。

11.png

七、总结

这种方式适用于这个特定的EDR,但是逆向类似的EDR产品并创建通用的绕过方法也是非常简单的。该方法也同样适用于64位所有版本的Windows,但我没有在32位上进行过测试。源代码请参见:https://github.com/hoangprod/AndrewSpecial/tree/master

感谢大家阅读本篇文章,如果大家发现存在任何问题,还请指教。

近两年,着实成了数据泄露的大年,尽管GDPR颁布,但数据泄露事件却有愈演愈烈的趋势。

1月30日上午,一位名叫“Andrev”的黑客通过Pastebin发布了一则消息,声称其攻击了LinkedIn服务器,并窃取了约1.59亿的用户信息。为证实其行为,他发布了一个包含100个用户的信息名单,名单中包括帐户信息、登陆密码等。据称,泄露的用户中包含一些国际知名企业CEO。

目前,该黑客拒绝公布泄露数据的内容,并且打算将整个数据库信息打包出售,标价99美元。另外,对于无购买意向的人,黑客也表示可以收费提供个体攻击服务(任何想要攻击的人,你出钱,我办事),费用为0.012比特币(约41美元)。

已有媒体根据黑客放出的数据,对其中的部分用户邮箱尝试取得联系,但目前尚未得到任何回应。无论如何,所有LinkedIn的用户请尽快修改密码,以避免不必要的损失。

针对此次泄漏事件,该黑客发布声明称:

“没错,仅仅需要0.012个比特币,你就可以入侵任意一个LinkedIn帐户,获得他们的全部信息。如果你运气好,他们在其他网站也使用相同的密码,那么你还会有额外的收获。一旦你拥有了这个数据库,那么这些人的个人信息、iCloud、Facebook、Instagram等帐户都会被你掌握在手中。”

PS:尊重原创,购买后请勿分享。

附黑客放出的数据截图:

微信图片_20190131104520.png微信图片_20190131104547.png

*参考来源:roguemedialabs,Karunesh91编译整理,转载请注明来自FreeBuf.COM

前两篇文章(第一篇第二篇),我们详细的对解析用户空间进程堆的方法进行了阐述,不过理论还需实践的检验,本篇文章,我们就接着将前面所讲的方法和理论进行评估,并将它们用于实际案例中就行检测。

结果评估

本节描述了HeapAnalysis类及其插件的评估。

结果验证

结果验证是对上述所讲的方法和技术可靠性的重要验证进程,所有测试均可以在以下环境中进行,且验证进程支持不同的Glibc版本:

1.Arch Linux 32位,×86,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

2.Arch Linux 64位,×64,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

HeapAnalysis类实现了多个函数,这些函数会将当前检测的数据与我们在处理内存时对每个块的期望进行比较:

1.测试正确的标志,例如,线程arena中的块的NON_MAIN_ARENA;

2.块的地址是否一致;

3.大小检测(例如是否一致);

4.分配状态测试:是否可能是任何bin或fastbin分配的一部分? 

5.对于MMAPPED块,还要进行一些额外的测试(有关更多详细信息,请参见MMAPPED区域);

对于MMAPPED块,还有另一个涉及malloc_par结构的验证步骤。 glibc一方面使用此结构的构建来控制某些全局设置,另一方面用于计算MMAPPED块的总大小和数量。这是通过该结构的唯一实例(名为mp_)完成的,它位于映射的Glibc库中。如果提供了mp_的偏移量,则HeapAnalysis类将使用该结构来验证所有已识别的MMAPPED块的数量和大小。如果存在任何差异,它会尝试识别隐藏的MMAPPED块,如果识别不出来,则会发出警告。此外,malloc_par结构会将所有块和堆相关结构的大小分别与相应的vm_area结构的大小和所有arena的大小进行比较。

完整性验证

虽然这项工作目前还无法完成全部的Glibc堆实现,但这并不妨碍开始尝试用各种步骤来识别与内存取证相关的所有相关信息和方案。我们试着开发了一套测试程序,该程序涵盖了我们所知道的所有特殊情况,以提供最完整的检测,最终,我们将使用这些测试用例自动验证我们实现的输出的完整性。为简明起见,此文我们不会对这套测试程序进行详细讲解,不过你可以在完整技术报告中看到整个细节

真实应用案例分析

本章节将演示我们的插件在真实世界示例中的应用,演示过程中,请注意两个方面,一方面注意插件是否是通过描述分析进程本身来实现,另一方面注意是使用的插件还是在整个堆中进行原始搜索的特点来实现的。在下面的小节中执行的分析是使用“黑盒测试方法”完成的,这意味着,如果没有另外指定,那么没有必要预先收集来自源代码的与进程相关的细节,比如结构定义。

zsh示例

之前描述的Rekall和Volatility的bash插件在整个堆空间中先会搜索以标签为前缀的时间戳字符串,然后再会搜索指向时间戳的历史结构,以便识别发出的命令字符串。插件的输出是命令条目列表,每个命令条目都是由发出的命令和相应的时间戳组成。我们的目标是为zsh识别相同的信息。本节中的相应分析已在结果验证部分中列出的相同环境中完成。

当使用history命令检测历史记录时,要分析的zsh进程在其历史记录中包含142个已执行的命令:第一个是ps aux,最后一个是#[email protected] &*()。分析进程的第一部分是以“黑盒测试方法”完成的,这意味着没有关于zsh如何存储命令或时间信息的内部信息是预先以任何方式收集的。这种方法的唯一信息是关于bash命令分析的现有信息,第一次检测尝试是查找以标签为前缀的时间戳字符串。然而,Zsh似乎没有以与bash相同的方式存储时间戳。于是下一步是使用heapsearch插件在块中的某处搜索已发布的命令。列表1显示了使用heapsearch搜索字符串#[email protected]%&*()的结果,其中显示了地址0x09BCF830处所包含的感兴趣的命令块。

5.jpg

列表1

使用heapsearch搜索包含已发布的zsh命令的块,虽然此命令有时可以在多个块中进行识别,但每个命令似乎至少会在分配的块中识别一次,该块仅包含命令和末尾保留的一些尾随字节。列表2显示了包含已发布的zsh命令块的hexdump。

6.jpg

列表2

包含已发布的zsh命令的块的Hexdump,由于这些块没有提供任何元信息(例如,在何时发出命令),所以下一步是再次使用heapsearch插件找到指向这些块的指针,但这次提供了包含发出命令的块的地址。你可以在单独分配的块中找到每个测试命令的一个指针,其大小为56字节(针对×86环境)。

在检测多个块(使用heapdump插件的转储内容)之后,可以得到以下信息:

1.字节5-8包含指向已发出命令的指针

2.字节25-32是2个时间戳,存储为4字节整数,其中前四个字节是发出命令的开始时间,后四个字节是命令结束的时间。

3.字节41-44包含命令计数器;

当使用heaprefs插件检测这些块以获取引用时(参见列表3,输出已经被删除和修改),它显示字节1-4,5-8(命令指针),13-16,17 -20和33-36指向其他块。这些块的起始地址列在“注释(Comment)”列中,而包含指针的字节在“数据(Data)”列中用方括号进行了标记。

7.jpg

列表3,使用heapref分析引用的块

通过将这些信息与zsh的源代码相结合,你就会在相关的历史条目结构histent中发现两个指针:fields down(向上的字段)(字节17-20)和fields up (向下的字段)(字节13-16)。由于这些字段会用来引用上一个或下一个histent条目,因此允许可靠地遍历histent实例。由于内容条目的链接列表是循环的,所以按着一个方向遍历,就足以获得所有histent条目,其他指针对于当前的检测并不重要。

现在,我们的最后一项任务是构建一个插件,以方便自动提取这些命令信息。为了能够遍历该histent列表,第一步是可靠地识别一个histent条目。由于命令可以包含在各种大小不同的块中,并且不提供任何可搜索的模式,所以这种方法是查找包含histent结构的块。对于×86而言,包含块的大小为56字节,对于×64架构,包含块的大小为96字节。因为还存在具有相同大小的非相关块,所以需要区分它们。由于每个histent条目都应该有一个指向包含命令的块的指针和指向下一个和上一个histent条目的指针,因此测试会包括检测这些指针是否引用已知的块。如果测试结果为正,最后一个检测则是遍历向上和向下指向下一个和上一个histent结构的指针,并测试它们的向下或向上构建是否指向当前块。如果是这种情况,则将当前块视为一个histent 结构,并使用向下构建遍历命令历史记录。

列表4显示了zsh插件的示例输出 (输出已经删除)。

8.jpg

列表4,zsh插件的示例输出

虽然因为时间戳字符串,可以使用原始搜索重建bash历史记录,但这种方法对zsh不起作用,因为时间戳不是以带有附加标签的字符串形式保存的,而是作为一个4字节整数保存的。此外,由于在分析进程中无法识别其他可搜索的模式,因此原始搜索很可能不适用于上述分析过程,此时使用堆分析插件的优势就显示出来了。

KeePassX示例

检测的第二个工具是密码管理器KeePassX(版本0.4.3),我们已在以下环境中进行了测试:

1.Ubuntu 15.10 32位,×86,内核版本4.2.0–16-generic,Glibc2.21版本;

2.Ubuntu 15.10 64位,×64,内核版本4.2.0-16-generic,Glibc2.21版本;

以下分析的设置由KeePassX数据库组成,该数据库包含多个密码条目,这些密码条目已被分为两个文件夹。每个密码条目都有标题、用户名、URL和注释的值。打开数据库进行分析时,只打开第一个文件夹,同时保持第二个文件夹完全不变。

我们的第一次尝试是在进程空间的某处找到未加密的主密码(master password )和条目密码,但找不到它们。但是,在5个带有不同密码管理器条目的测试中,我们已在3个已分配的块中成功观察到当前打开的密码条目的未隐藏密码。只要密码条目显示未隐藏的密码,这三个块就会一直存在。如果密码再次隐藏,三个块中的两个将被释放,保留其中一个进行分配。只有当输入窗口关闭时,包含密码的所有块才被释放。根据释放的块的大小,密码将在几毫秒(几分钟,甚至几个小时也有可能)内被重写。虽然释放的块(包含长度在1到40之间的密码)通常在几秒钟或几分钟内重新分配,但在某些情况下,包含同样大小密码的释放块会被合并到更大的释放块中。由于这些更大的块由于太大(例如在几百字节的范围内)不经常分配,密码可能在该块中可能保持几个小时,但也更难被找到(因为它被其他数据包围)。此外,在块数据部分的前18个字节中从未观察到实际密码,这意味着即使在释放的块被合并到大型bin中,密码也不会通过×86架构上的任何bin指针被覆盖。

在寻找到密码字段之后,下一步是寻找更多感兴趣的字段,这个分析过程中选择的字段是标题、用户名、URL和注释。 KeePassX在数据库被打开后,会立即将完整的字段内容存储在已分配的块中。这不仅适用于标题、URL和注释等字段,还适用于用户名字段,由于在KeePassX的示例中,该字段仅在概述中以星号显示,因此不应在堆内进行再加密。综上所述,如果密码数据库被打开而未被锁定,则可以从堆中提取所有文件夹中所有密码管理器条目的概述(密码字段除外)中的所有字段。为了分析和比较来自不同块(包含字段字符串)的数据,我们已使用heapdump插件将它们转储到单独的文件中。列表5显示了一个转储数据块的十六进制转储输出,该数据块包含一个用户名(在本例中是yyyyyyyy_yyy_user5_aaaaaaaab):

9.jpg

列表5,包含KeePassX用户名字段的块数据部分的十六进制转储

在比较包含来自相同类型的字符串(例如用户名)和来自其他类型的字符串的不同块之后,可以导出以下属性(对于未隐藏的密码也是如此):

1.字符串总是由16位的endian编码;

2.字符串并不是从块的数据部分的开头开始的,而是在18字节之后,这很可能是因为字符串是结构或对象的一部分;

3.字节5-8和9-12分别与字符串的大小相关,而字节9-12表示正确的大小(大小是由编码的字节序列表示的字符数,而不是字节数),这两者都可能是四字节无符号整数的实例。字节4-8中的值恰好比字节9-12中的值大1倍(请参见列表5:0x19与0x18);

4.字节13-16指向字符串的开头;

5.该字符串后会紧跟4个空字节;

6.根据字符串的大小,最后有一些额外的字节(某种填充字节),在大多数情况下从0到6个字节不等。然而,很少有这种情况,即这个额外的字节会达到14个字节(6加上直到下一个更大的块大小的字节数);

字节1-4没有改变,而字节13-18和字符串结束后的字节不但变化很大,它们也没有显示出任何与某个类型或密码管理器条目的可靠一致性。

于是,下一步我们就是使用heapsearch插件搜索任何指向字段字符串的指针。虽然搜索字符串的起始地址没有显示任何引用(包含在同一块中的引用除外),但搜索这个块的数据部分的开头处会显示出另一个块中至少有一个指针。使用heaprefs插件分析这个块时,它会显示指向其他块的12个指针,其中四个指针指向包含标题、用户名、URL和注释字符串的块。在我们分析了大量的密码条目之后,就可以合理假设出每个密码条目,其中存在着大小为96字节(在×86环境中)的块,这个块至少引用了这四个字段。这意味着,通过搜索大小相同的块并检测给定偏移量的指针,就可以收集到相同密码条目的标题、用户名、URL和注释字符串,这个信息被用来创建一个概念验证插件,具体方法就是使用HeapAnalysis类,它会自动为所有密码条目提取这四个字段。列表6显示了该插件的示例输出(输出已被删除)。

10.jpg

列表6,KeePassX插件的示例输出

此时,你应该注意,如果没有来自有关块上下文的起始地址的信息,查找字段字符串的引用将会更加困难,而在最坏的情况下,各种字符串关联到一个密码条目的可能性也会降低。

总结

本文重点介绍了如何在Linux进程的上下文中分析堆,其研究目的是支持研究者分析用户空间进程堆中包含的数据。首先,要对Glibc的堆实现有了深入的了解,这在Glibc分析部分中有详细的介绍。该分析侧重于从内存取证角度分析堆相关数据的存储方式和存储位置。其次,这些知识已被用于构建内存取证框架Rekall插件,该框架用于分析Linux用户空间进程的堆并提供对已识别块的访问。细节在插件实现部分中有详细说明,其中特别描述了一种识别隐藏MMAPPED块的算法。由于产生可靠的结果是计算机取证的关键要求,因此部分评估涵盖了能够验证收集到的结果的信息。为了说明研究的实用性,在真实的应用程序示例中中,我们使用了zsh和KeePassX的例子描述了用户空间应用程序的黑盒分析进程。

本文研究结果的一些局限性

由于交换空间在某些情况下是用户空间进程分析进程中的关键资源,到目前为止我们的研究中还未涉及到这一点。当本次研究中引入的插件用于包含堆相关数据的交换页面的进程时,它们很可能无法可靠地分析堆并提取所有块。

本次研究的目标之一是为存储在内存中的数据提供一个类似进程的视图,不过从上述研究的结果来看,虽然我们已经搞清楚了堆在进程中所包含的详细信息(特定信息的位置及其大小),但目前还是无法提取有关数据类型的信息,根本原因是堆不存储任何数据类型信息。在已经知道数据类型和数据本身大小的情况下,仍然有一种方法可以将特定块与特定类型关联起来,通过搜索特定大小的数据块,取证人员可能能够收集特定类型的数据。然而,这种方法需要对这些块进行进一步的测试(如zsh部分所示),因为可能会有更多大小相同的块包含不同的数据。

如上所述,对特定堆的解析要依赖特定的操作系统。在对不同的堆进行解析时,已经成功测试的方法和插件很可能都不适用。到目前为止,我们所探索的HeapAnalysis类和插件仅支持在上述架构和Glibc版本上分析Linux进程。但是,在详细的技术报告中,我们提供的信息可用于增加对更多体系结构或操作系统的支持。

虽然可以在不提供调试信息的情况下分析用户空间进程的堆,但这种方法并不可靠。比如当任何相关结构发生变化(malloc_chunk、malloc_state或heap_info)时,插件在分析堆时肯定会失败,如果缺少指向全局变量mp_的指针,结果可能仍然不完整。如果没有mp_,则无法确定是否已发现所有MMAPPED块,另外由于在本例中,我们没有启动对隐藏MMAPPED块的搜索,因此输出中可能至少缺少一个MMAPPED块。

除了隐藏的MMAPPED块之外,还有一种不确定性情况,就是HeapAnalysis类可能会丢失块,如果分析进程错误地将包含整个arena的vm_area_struct丢失了,虽然测试结果似乎仍然是正确的,但是却丢失了arena的块。以上所说的这种不确定性情况,可能发生的场景是这样的:解析过程中,没有提供关于main_arena位置的调试信息,并且main_arena搜索进程无法找到它,这也意味着此进程无法找到任何线程arena。由于在该场景中没有可用于任何arena的有效指针,因此可能存在未检测到的arena,这就是说有arena未被注意到。虽然这种情况在理论上是存在的,但是在我们的评估中,丢失arena的情况却未被检测到。

未来的研究方向

由于最重要的限制是缺少对交换空间的支持,为了全面分析进程的堆,必须确保对包含堆相关数据的所有页面的访问。因此,将交换空间集成到内存取证进程中,就是进一步分析用户空间进程的关键一步。

为了增加HeapAnalysis类的支持,我们计划更多系统架构上测试插件,并在需要时进行适当调整。此外,对诸如jemalloc之类的进一步堆实现的分析允许分析来自诸如Firefox之类的应用程序的进程的堆分配。此外,对诸如jemalloc等其他堆实现的分析,还允许来自Firefox等应用程序的进程的堆分配。

总而言之,本文中介绍的插件简化了分析进程,并使用模式匹配方法识别内存中无法轻易找到的信息。这些插件和内存中有关堆对象的详细信息,也可用于支持内存取证的进一步研究。此外,本文还演示了用户空间进程的分析,同时说明了在分析进程中如何获取堆的细节信息。

大家好,今天我想给大家展示的是如何使用Frida工具来攻击安卓应用程序。我可是花了好几个小时的时间才把这个Frida工具安装好的,最后发现,其实并不是很难,我只是没有找到一个对于像我这样的移动安全初学者的良好教程。所以我才决定做这个教程,给移动安全初学者提供一个参考,如果你知道Frida是什么,你可以直接跳到step0:开始安装Frida。

Frida是什么?

Frida官网上是这么说的:

它是针对本地APP的类似油猴插件的东西,用更专业的术语来说,它是一个动态代码检测toolkit。它可以让你注入JavaScript代码片段或者你自己的库到Windows中的APP中,也可以注入到macOS,GNU/Linux,iOS,Android和QNX的APP中。Frida还提供了一些构建在Frida之上的简单工具。这些工具你可以直接使用,也可以根据自己的需求来调整,或者是作为如何使用API的示例。

简而言之,Frida就是一个让你可以注入脚本到本地APP(此案例我们将注入到安卓APP中)中的工具,从而修改APP的行为(在这里例子中,我们可以绕过ssl pinning并执行中间人攻击,即使APP使用的是HTTPS/SSL连接),并且实时的进行动态测试。

声明:此方法不适用于使用HSTS协议的APP,比如Facebook,Instagram,Twitter,PayPal和银行APP,不过不用担心,现在绝大多数APP还没有使用这个HSTS协议。

step0—环境配置

电脑端

· Python2.7

· Python pip

· adb工具

· 本地代理(Burpsuite)

Android端

· root过的安卓手机(我的是一加手机 Android8.1)

· 安卓模拟器,Android4.4.4到8.1

step1—电脑安装Frida

# installing frida via terminal, sometimes you need to run this command as sudo
pip install frida-tools

step2—设备上安装frida-server

由于安卓设备有很多种不同的架构,所以我们需要搞清楚我们的设备是什么处理器,我们需要把手机跟电脑连接(要先激活USB调试选项),然后运行下列命令:

# getting the processor arquitecture in this case is ARM, there are also x86, x86_64, etc ...
adb shell getprop ro.product.cpu.abi
ouput: armeabi-v7a

OK,知道架构之后,我们就可以下载对应的Frida服务器版本了,下载的GitHub链接在这里https://github.com/frida/frida/releases,由于最新的版本不好用,这里我建议大家下载frida-server-12.0.5-android-arm.xz,下载好之后,我们需要解压这个frida server,然后将它复制到设备中。

# extracting frida-server binary from the xz file
# for linux distributions
tar -xJf frida-server-12.0.5-android-arm.xz
# for macOS or BSD based
unxz frida-server-12.0.5-android-arm.xz
 
# then we need to copy the frida-server binary to the device with adb
adb push ./frida-server-12.0.5-android-arm /data/local/tmp/

step3—frida中的hello进程

一旦我们在电脑端安装好了frida,在安卓端安装好了frida-server,我们就可以使用下面的命令与frida进行交互了:

# first we need to start frida-server with this adb command
# the last '&' is to run the command in background
# disable SELinux is very important I was looking about 4 hours trying to see what happened and SELinux was preventing the success frida-server execution, also frida-server must run as root
adb shell 'su -c setenforce 0'
adb shell 'su -c /data/local/tmp/frida-server-12.0.5-android-arm &'
 
# then if everything works you can see frida's hello world with
# frida-ps is for list the devices process and -U flag is for usb devices
frida-ps -U

1.png

step4—配置Burpsuite

在我们的设备之间建立连接的最快的方式就是将安卓设备和电脑连接到同一个WiFi中,所以我们需要在安卓设备中把WiFi连接修改为手动配置代理,然后设置Burpsuite代理为本机IP,具体配置如下图:

2.png 

当然,我们还需要安装Burpsuite证书。只要安卓设备的代理设置好了,我们就可以在浏览器中访问https://burp这个链接,然后点击CA证书按钮下载证书(注意:你需要将证书后缀der改成cer)如图:

3.png

最后一步—绕过SSL Pinning

现在,我们已经安装好了frida,Frida-server,Burpsuite也配置好了。下一步就是运行“通用安卓SSL Pinning Bypass No.2”脚本来开始嗅探应用程序的连接了,我们先要下载这个脚本并保存在本地。这里有一篇博文是讲解该脚本的(你可以从这个repo里添加多个脚本到frida里,也可以自定义脚本)

/*
   Universal Android SSL Pinning Bypass
   by Mattia Vinci and Maurizio Agazzini
 
   $ frida -U -f org.package.name -l universal-ssl-check-bypass.js --no-pause
 
    https://techblog.mediaservice.net/2018/11/universal-android-ssl-check-bypass-2/
*/
 
Java.perform(function() {
 
    var array_list = Java.use("java.util.ArrayList");
    var ApiClient = Java.use('com.android.org.conscrypt.TrustManagerImpl');
 
    ApiClient.checkTrustedRecursive.implementation = function(a1, a2, a3, a4, a5, a6) {
        // console.log('Bypassing SSL Pinning');
        var k = array_list.$new();
        return k;
    }
 
}, 0);

现在我们唯一要做的就是保存脚本,这里我们保存为“Frida-ssl-2.js”,然后运行下列命令:

# the -l flag is to run custom script, in this case ssl pinning 2 script
# the -f flag is for the apk package name, --no-paus option to not interrupt
# the app startup at all and still leave the spawning of the process to Frida.
 
frida -U -l frida-ssl-2.js --no-paus -f com.example.application

然后程序就开始运行了,我们可以在Burpsuite中看到结果,如图:

4.png

到这一步,我们可以看到已经使用frida成功绕过了ssl pinning,你可以对安卓应用程序进行抓包分析和实施进一步攻击了。

参考文献:

http://asvid.github.io/android-frida-hackinghttps://koz.io/using-frida-on-android-without-root/

https://www.codemetrix.net/hacking-android-apps-with-frida-1/

https://www.notsosecure.com/pentesting-android-apps-using-frida/

https://android.jlelse.eu/hacking-android-app-with-frida-a85516f4f8b7

https://www.securitynewspaper.com/2017/07/25/universal-android-ssl-pinning-bypass-frida/m

在2019年1月观察到的恶意JavaScript电子邮件附件数量增加之中,ESET研究人员发现大量针对俄罗斯用户的传播勒索软件的垃圾邮件。

2019年1月,恶意JavaScript电子邮件附件的检测率急剧上升,这是一种在2018年大多数时间处于休眠状态的攻击媒介。在依赖此向量的恶意垃圾邮件活动的“新年版”中,我们发现了一波新的俄语垃圾邮件,分发名为Shade或Troldesh的勒索软件,ESET检测为Win32/Filecoder.Shade。

该攻击行动是2018年10月开始分发Shade勒索软件的恶意垃圾邮件活动的后续。

一、2019年1月行动

我们的遥测显示2018年10月的攻击活动一直持续到2018年12月下旬,在圣诞节期间休息,然后在2019年1月中旬恢复且规模翻番,如图1所示。图中的下降点与周末一致,这表明攻击者热衷于欢公司的电子邮件地址。

图1  – 自2018年10月以来检测传播Win32/Filecoder.Shade的恶意JavaScript附件

如前所述,此行动是我们从2019年初开始观察到的一个更大趋势的一部分 – 恶意JavaScript附件作为一种广泛使用的攻击媒介的回归。图2显示了我们遥测中看到的发展趋势。

图2  – 在过去的一年中检测到通过电子邮件附件分发的恶意JavaScript,所有这些都被检测为JS/Danger.ScriptAttachment

特别值得注意的是,2019年1月传播Shade勒索软件的活动在俄罗斯最为活跃,占这些恶意JavaScript附件总数的52%。其他受影响的国家是乌克兰、法国、德国和日本,如图3所示。

图3  –  2019年1月1日到2019年1月24日期间传播Win32 / Filecoder.Shade的恶意JavaScript附件的分布(ESET检测)

根据我们的分析,2019年1月行动中的典型攻击始于发送一封用俄语写的电子邮件,附件是一份名为“info.zip”或“inf.zip”的ZIP包。

这些恶意电子邮件为订单更新,看起来是来自合法的俄罗斯组织。我们看到的电子邮件冒充俄罗斯银行B&N Bank(注:最近与Otkritie Bank合并)和零售连锁店Magnit。在ESET系统检测到的其中一封电子邮件中,翻译为:

主题:订单详情

你好!

我正在向您发送订单的详细信息。文件见附件。

Denis Kudrashev,经理

图4  –  2019年1月攻击中使用的垃圾邮件示例

ZIP存档包含名为“Информация.js”的JavaScript文件(即“信息”)。一旦提取并启动,JavaScript文件就会下载恶意加载程序,ESET产品检测为Win32/Injector。恶意加载程序解密并启动最终的有效载荷—Shade勒索软件。

恶意加载器从被感染的合法WordPress站点下载伪装成图像文件。为感染WordPress页面,攻击者使用自动机器人进行的大规模密码暴力攻击。我们的遥测数据显示了数百个这样的URL,所有这些URL都以字符串“ssj.jpg”结尾,托管恶意加载器。

加载程序使用声称由Comodo发布的无效数字证书进行签名,如图5所示。“签名者信息”中的名称和时间戳对于每个样本都是唯一的。

图5  – 恶意加载器使用的假数字签名

除此之外,加载器试图通过伪装成合法的系统进程Client Server Runtime Process(csrss.exe)来进一步伪装自己。它将自身复制到C:\ProgramData\Windows\csrss.exe,其中“Windows”是由恶意软件创建的隐藏文件夹,通常不在ProgramData中。

图6  – 恶意软件冒充系统进程并使用从合法Windows Server 2012 R2二进制文件复制的版本详细信息

二、Shade勒索软件

此恶意行动的最终载荷是加密勒索软件,称为Shade或Troldesh。 2014年末首次出现,但经常重新改进,勒索软件加密本地驱动器上的多种文件类型。在最近的行动中,勒索软件将扩展名.crypted000007附加到加密文件中。

赎金说明以TXT文件(俄语和英语)呈现给受害者,该文件被释放到受影响计算机上的所有驱动器。赎金票据的措辞与先前报道的2018年10月攻击活动的措辞相同。

图7  –  2019年1月的Shade勒索软件赎金条

三、如何保持安全

为避免成为恶意垃圾邮件的受害者,请在打开任何附件或点击链接之前始终验证电子邮件的真实性。如有必要,请与使用其官方网站上提供的联系方式发送电子邮件的机构联系。

对于Gmail用户,了解Gmail近两年来一直在阻止接收和发送的电子邮件中的JavaScript附件可能会很有用。

其他电子邮件服务的用户(包括公司邮件服务器)必须依赖他们的意识 – 除非他们使用一些能够检测和阻止恶意JavaScript文件的安全解决方案。

ESET安全产品中的几个不同模块可独立检测和阻止恶意JavaScript文件。

为避免WordPress网站遭到入侵,请使用强密码和双因素身份验证,并确保定期更新WordPress本身以及WordPress插件和主题。

IoCs

恶意ZIP附件的示例哈希值

ESET 检测名: JS/Danger.ScriptAttachment

1.png

JavaScript下载程序的示例哈希

ESET检测名: Win32/Injector

2.png

Shade勒索软件的示例哈希值

ESET检测名: Win32/Filecoder.Shade

3.png

托管Shade勒索软件的URL中的特定字符串

4.png