导语:基于本文的分析,将来攻击者可能会更深入地研究这种独特语言所提供的功能,得益于Objective C和强大的Cocoa框架,各种执行方法,以及现在优秀的、免费使用的IDE的可用性,AppleScript正在成为一个强大的、多用途的、易于开发的工具。
当我们考虑macOS的安全性和攻击者使用的工具时,无论这些攻击者是野外攻击还是渗透测试的真实工具,我们都会想到诸如python脚本、shell脚本、恶意文档、可疑扩展之类的东西,当然,还有伪造、篡改或恶意注入程序包。尽管AppleScript内置的macOS技术已经存在了很长时间,并且比macOS 10本身早了8到9年,但在安全领域,人们对它的关注却少得多。
正如我将在以下文章中介绍的那样,AppleScript已经被攻击者广泛使用。这包括它在广告软件中的使用,它在诸如持久性、反分析、浏览器劫持、欺骗等任务中的使用。令人担忧的是,考虑到安全研究领域对AppleScript缺乏关注,所有这些甚至都没有利用AppleScript的一些最强大或独特的功能,其中一些我们将在下面介绍。
为什么AppleScript会被一般开发者和安全检测的人员忽略?
AppleScript与Bash和其他shell语言不同,也与Python不同(Python是一种跨平台的、初学者友好的脚本语言,得到了广泛的采用和赞扬),它是macOS特有的一种特有语言。你不仅不能在Windows和Linux等其他台式机操作系统上使用它,甚至不能在苹果的其他操作系统如iOS和iPadOS上使用它。
作为一种语言,AppleScript以其古怪、缓慢和难以开发简单脚本而闻名。它的古怪之处在于,它试图使用“自然语言”,但其语法完全是人为的,常常前后矛盾,也非常冗长。比较用于计算/ usr / bin目录中项目数的简单任务的代码,shell脚本将永远是最简洁的:
ls -l /usr/bin | wc -l
Python有点冗长,但仍然相当干净和熟悉:
#!/usr/bin/python import os path, dirs, files = next(os.walk("/usr/bin")) print len(files)
但是,AppleScript版本的性质则完全不同。
tell application "System Events" set theFiles to name of every file of folder "bin" of folder "usr" of startup disk count of theFiles end tell
AppleScript的执行速度也很慢,因为底层技术包括通过一个称为Apple Event Manager的古老接口构造和发送Apple事件,该接口是为Apple System 7操作系统编写的(1991年发布),即使在当时也没有对性能进行优化。
从历史上看,使用AppleScript开发脚本非常困难,因为大多数访问它的人会尝试使用免费的、内置的但以简洁著称的(Apple)Script Editor.app。该脚本几乎缺少开发人员通常期望和需要的所有功能,没有调试器,没有自省变量,没有代码片段或有效的代码完成功能。以下就是列举的一些缺少的功能:
直到最近,Script Editor的唯一第三方替代产品的价格为200美元,并有一个时间限制,20天的演示期。
简而言之,在时间、精力和金钱上的投入使得开发出的产品只能在macOS的桌面上使用,对于大多数人来说,选择一种有用的或高效的编程语言时,AppleScript是最不需要考虑的。因此,尽管AppleScript已经存在了近30年,但大多数Mac管理员、Mac开发人员或Mac终端用户很少使用它。实际上,AppleScript可能是有史以来最不受欢迎、最不讨人喜欢的编程语言。
那么,为什么攻击者喜欢使用AppleScript?
AppleScript是为自动化和应用程序间通信而设计的,其目标是允许普通用户将重复的任务链接在一起并在没有进一步用户交互的情况下执行它们。例如,你可以让Mail.app在收到来自特定发件人的电子邮件时或在主题行或内容中带有特定关键字的邮件时自动触发脚本,从电子邮件中提取所需的详细信息,然后在其中填充数据库。具有所需信息的Excel或Numbers,随数据输入即时进行格式化和排序。一旦脚本建立,用户就无需参与其中。
事实证明,自动化应用程序间通信和回避用户交互对恶意软件作者来说是天赐之物。还有什么比将流行的应用程序(如电子邮件客户端、web浏览器和Microsoft Office套件)按照你的意愿进行执行而不需要用户参与更有用的呢?
因此,尽管对于脚本或编程语言来说,它在几乎所有可能的受众中都缺乏吸引力,但仍有一部分人确实在广泛使用AppleScript,他们就是攻击者。
macOS恶意软件中,攻击者使用AppleScript的最新示例
最近针对Safari的浏览器劫持者安装了一个隐藏的LaunchAgent,它通过shell脚本加载、编译和执行AppleScript。
它从一个封装在DMG中的外壳安装程序脚本开始,该脚本应该包含一个名为“PDFConverter4u”的应用程序。但是在磁盘映像的一个隐藏的.assets文件夹中有一个第一阶段的shell脚本:
5f198e82c0cf9a9f7d7a8d01273a6ad75a17a95960d8996dcdd028922b3d97bc
这将解压并执行第二阶段的shell脚本:
55529224e9f70f5cab007e2ca98f6aec5cf31eb923fdfc09f60c01cc45c80666
最终生成隐藏的启动代理,该启动代理执行另一个包含通过osascript启动的AppleScript代码的shell脚本:
cdaa2121d79031cf39159198dfe64d3695a9c99ff7c3478a0b8953ade9052ecc
AppleScript的目的是用攻击者的Shell脚本提供的用户名代替流行的搜索引擎google,bing和yahoo上的用户搜索查询,这是攻击者通过点击赚钱的一种快速简便的方法,这种攻击会对降低受害者设备的运行速度。
尽管此特定示例被封装在单独的文件中,但许多其他示例都以纯文本字符串或混淆的base64或类似编码将其AppleScript直接写入MachO二进制文件。
从Bundlore安装程序中提取的以下字符串表明,该代码试图强制在Google Chrome浏览器中启用JavaScript执行,然后使用AppleScript在浏览器前窗口的活动标签中执行该代码。
来自41e0d31d52cb93f6a5020a278e8f360a6e134e6cc7092b4a5e575ac8b96a8d74的字符串
下一个示例是一个Pirrit恶意软件的变体:
21331ccee215801ca682f1764f3e37ff806e7510ded5576c0fb4d514b4cf2b7c
开发者同时使用纯文本AppleScript和base64编码的AppleScript,目标是Safari、Chrome和Firefox浏览器。
以下是一些针对Firefox的经过解码的base64,并尝试执行自动击键以将当前URL复制到用户剪贴板,然后将URL替换为攻击者选择的URL:
在没有Apple事件的情况下使用AppleScript
说到base64,下面的例子说明了许多普通用户和开发人员忽略的关于AppleScript的一些功能:你可以使用AppleScript来执行任何其他类型的脚本,包括python脚本,就像这个去掉了Empire exploit工具包的脚本,对攻击者来说,这些功能特别合胃口。
对于AppleScript和Python,AppleScript和Perl,AppleScript和Bash,甚至是AppleScript以及所有命令行工具的功能,你可以全部调用它们,并将其功能引入AppleScript并将其与其他实用程序结合。
上面的示例都使用了我们称之为“vanilla AppleScript”的代码,也就是说,从平台早期开始就存在的本地AppleScript语言。但是从Yosemite 10.10开始,一直到macOS的最新版本,AppleScript通过访问Cocoa框架获得了越来越强大的功能,这为创建成熟的、功能强大的程序和应用程序提供了可能性,除了AppleScript本身之外,不需要其他任何东西。通过AppleScript执行的Objective C在速度上或多或少与在MachO二进制文件中执行的Objective C相当。
有趣的是,尽管到目前为止我们还没有看到攻击者利用这些强大的功能,但至少有两个原因使我们将来可以这样做:首先是避免检测,其次是因为易于获得良好的开发环境。
使用AppleScript可以避免被检测到
避免在执行过程中被检测到,是所有恶意软件(甚至是勒索软件)的主要目标。 AppleScript为进攻者提供了多种执行方式,除了简单地执行.scrpt文件之外,你还可以从邮件规则,shell脚本,内存中,命令行,MachO中,纯文本,未编译文件,Automator工作流程,文件夹操作,Finder服务或日历事件运行AppleScript。
因为AppleScript能够在不需要编译的二进制代码的情况下执行Objective C代码,这就为许多有趣的攻击提供了可能性。基于macOS Catalina 10.15中引入的kextless安全框架,它也有可能绕过检测工具。
在一篇由Cedric Owens撰写的文章——《快速调整macOS终端安全框架》中,Owens开始测试使用三种最新开发的第三方安全工具来检测哪些是可以检测到的,哪些是不可以检测到的,这三种工具利用了新的苹果终端安全框架(Apple Endpoint Security framework)。终端安全性是一种C API,用于监视系统事件是否存在潜在的恶意活动。 您可以使用支持本机呼叫的任何语言编写客户端,并向Endpoint Security注册以授权未决事件或接收已发生事件的通知。 这些事件包括进程执行,挂载文件系统,派生进程和引发信号。使用Endpoint Security开发系统扩展,并将其打包在使用SystemExtensions框架的应用中,以在用户的Mac上安装和升级扩展。
Owens发现的一件有趣的事情是,如果你试图通过osascript和vanilla AppleScript获取用户的剪贴板,这个活动会很容易被他测试的所有工具获取。
osascript -e 'the clipboard'
但是,当使用本地Cocoa API NSPasteboard时,Owens测试的所有Endpoint Security框架支持的工具似乎都无法捕获该活动。但是现在,我们当然也可以从AppleScript本地执行NSPasteboard!
请注意,我们的一行简单但可检测的osascript已经变成了大约14行复杂的AppleScript-ObjC。很少有人愿意尝试在脚本编辑器中构造这种代码,当然我也不例外。
但是,开发复杂的AppleScripts的问题现在或多或少已经成为过去,这篇文章前面提到的第三方替代产品现在具有免费试用版,并且零售价仅为旧价格的一半。更重要的是,它还允许你将大量的样本代码拖放到脚本中,例如上面脚本中使用的样本代码。它提供了开发人员友好的功能,例如代码完成和API查找,这些功能确实减轻了开发AppleScript代码的麻烦。
让我们来看另一个例子,很多攻击行动都是为了避开运行特定软件的目标。Little Snitch就是一个很好的例子,各种VM软件又是另一个例子。我们可以很容易地通过名称获得运行中的应用程序的列表,然后通过NSWorkspace直接调用Cocoa API来对其进行测试。
如果我们只想对特定应用程序的存在进行正确或错误测试,则可以将应用程序名称放在列表中,并在第一次检测到时返回true。
换句话说,通过将AppleScript的钩子利用到Cocoa框架中,我们可以执行本地代码,而无需构建MachO二进制文件或MachO应用程序(尽管你也可以使用AppleScript实现这两种功能!)。我们可以无文件地执行此操作,这样就不会被新的“kextless”工具(比如Owens测试过的那些工具)捕获,而且我们可以以比macOS上任何其他可用代码都多得多的方式执行此代码,无论是shell脚本、Python脚本还是macOS包。
总结
由于AppleScript语言本身的复杂性和不友好的操作性,一般人不常用它。但AppleScript的功能又十分特殊,所以攻击者非常偏爱用AppleScript。基于本文的分析,将来攻击者可能会更深入地研究这种独特语言所提供的功能,得益于Objective C和强大的Cocoa框架,各种执行方法,以及现在优秀的、免费使用的IDE的可用性,AppleScript正在成为一个强大的、多用途的、易于开发的工具。
攻击者总是会试图利用防御者忽略的东西,AppleScript已被安全领域忽略了好多年了,是时候引起他们的重视了。我曾经将AppleScript描述为“macOS的PowerShell”。
本文翻译自:https://www.sentinelone.com/blog/how-offensive-actors-use-applescript-for-attacking-macos/如若转载,请注明原文地址: