• 本文作者: topsec_support
  • |
  • 2023年11月29日
  • |
  • 未分类
  • |

EvilParcel漏洞分析

引言

今年年初,国内独立研究机构DarkNavy发表文章,指出某知名购物APP中存在漏洞攻击行为。这引起了广泛的关注和讨论。值得注意的是,其中涉及到一个已被编号为CVE-2017-13315的Android系统漏洞,这个漏洞在我们的研究中引起了浓厚的兴趣。CVE-2017-13315是一个已知的Android系统漏洞,其利用了Parcelable对象的序列化和反序列化过程中的不一致性。这种不一致性可能导致任意代码执行的风险,从而绕过手机系统的保护机制,实现对用户设备的潜在攻击。该漏洞的危害性较高,攻击者可以利用它隐蔽地安装和卸载恶意应用程序,对用户的隐私和安全造成严重威胁。

早在2018年,国内就有安全工作者对这个漏洞进行了研究分析,我们在这基础上做了一些研究和补充。

EvilParcel 漏洞原理

1. 什么是EvilParcel漏洞

EvilParcel漏洞是指在Android IPC通信中,由于Parcelable对象的序列化和反序列化过程中的不一致性而导致解析错误的安全问题。它在近年来成为一个重要的安全问题,影响着Android设备的安全性。在Android中,Parcelable是一种用于在进程间通信(IPC)中传递数据的关键组件。它允许对象在不同的进程之间进行序列化和反序列化,以便进行跨进程的数据传输。当一个Parcelable对象在反序列化过程中使用in.readInt()来读取数据,而在序列化过程中却使用dest.writeLong()来写入数据时,就会导致两次操作的不一致性。这种不一致性会导致在序列化后的二进制表示中多出4个字节的0。由于这额外的4个字节,后续的解析过程会发生整体向后偏移4个字节的情况,从而导致解析异常。恶意攻击者可以利用这个漏洞通过精心构建的序列化数据来执行未授权的操作。这种错位的错误使得攻击者能够绕过安全检查,修改数据,执行未授权的代码,并可能导致权限提升。

2.深入剖析 EvilParcel 漏洞的细节

  • 正常的Parcel序列化

为了更清楚地理解漏洞的原因,我们可以通过一个Bundle对象的示例来说明序列化后的二进制格式。只有对序列化解析方式有足够的了解,才能更深入地理解该漏洞的原因。

 

Bundle序列化时,键值对以key-value形式存储,不同的value类型会使用Parcel内置的值来表示。

通过手动解析二进制文件来理解Parcel的序列化和反序列化过程。手动解析二进制文件可以帮助我们了解其中的细节和数据结构,从而更好地理解EvilParcel漏洞的产生原因。

序列化后的二进制格式通常包括以下内容:包大小、魔数、键值对数量、键大小、键/值、值类型、[值长度]、值。

在Parcel的序列化过程中,首先会将数据转换为二进制格式。二进制格式的结构通常如下:

1. 包大小(Package Size):用于表示整个包的大小,包括所有序列化的数据和元信息。

2. 魔数(Magic Number):一个特定的标识符,用于识别Parcel数据的有效性和版本。

3. 键值对数量(Number of Key-Value Pairs):表示序列化数据中包含的键值对的数量。

4. 键大小(Key Size):表示每个键的长度。

5. 键/值(Key/Value):包含键和对应的值。

6. 值类型(Value Type):用于标识值的数据类型,例如字符串、整数等。

7. [值长度](Value Length):根据值类型可能会有的长度信息。

8. 值(Value):根据值类型存储的具体值。

EvilParcel 漏洞原理

数组类型、 parcelable类型等会多出一个value长度。

Bundle序列化的特定功能:

在Bundle的序列化过程中,所有键值对都按顺序写入。在每个值之前,会指示该值的数据类型(例如,13表示字节数组,1表示整数,0表示字符串等)。对于可变长度的数据,会在数据之前指示其大小(例如,字符串的长度,数组的字节数)。此外,所有的值都会进行4字节对齐。Bundle的序列化过程如下:首先,写入一个整型的size,表示整个Bundle的大小。然后,按顺序依次写入每个键和值。在写入值时,会使用writeValue方法,该方法会根据对象的类型分别写入一个代表类型的整数以及具体的数据。

所支持的类型如下所示:

  • EvilParcel漏洞

EvilParcel漏洞的产生是由于Parcelable对象在序列化和反序列化过程中的不一致性所导致的。举个例子,考虑以下的MyParcelable对象,当它进行反序列化时使用了in.readInt()来读取数据,而在序列化过程中却使用了dest.writeLong()来写入数据。这两次操作的不一致性会导致MyParcelable对象在序列化后的二进制表示中多出4个字节的0。由于这额外的4个字节,后续的解析过程会发生整体向后偏移4个字节的情况,进而导致解析异常。然而,通过巧妙构造的序列化数据,利用这种偏移错误,可以执行未经授权的操作,这就是EvilParcel漏洞产生的根本原因。

使用Parcel进行序列化时,我们可以创建三个键值对。其中,第一个键值对使用com.topsec.test2.MyParcelable作为值的类型,第二个键值对创建一个带有有效负载的字节数组(bytearray)作为值,第三个键值对可以填充任意值。

序列化后的示意图:

 EvilParcel漏洞

在key[1]的value中添加隐藏的键值对数据,当进行反序列化和再序列化之后,这个隐藏的键值对就会被解析出来。

EvilParcel 漏洞原理

第一次序列化后的二进制文件如下内容:

第二次序列化Bundle,然后再次对其进行反序列化查看解析的key。

 

 EvilParcel 漏洞原理

二进制文件:

在进行两次序列化后,出现了一个名为”hidden”的键。原本该键的值是一个字节数组(bytearray),但现在它被错误地解析成了一个键。这种不一致性可能是由于序列化和反序列化过程中的错误操作或数据结构问题导致的。在第一次序列化时,”hidden”键的值被错误地处理,导致在第二次序列化和反序列化后,它被错误地解释为一个键,而不是之前的字节数组值。

通过手工分析两次序列化的二进制内容,比较第一次序列化和第二次序列化的解析不同。

手工分析第一次序列化:

手工解析出三组key-value值,此时payload还存在于key[1]的value中没有被解析出来。

第二次序列化时解析:

在进行调试时可以观察到原本位于key[1]的数据已成功解析,并且通过调试还可以确认key[2]的键名为”hidden”。由于序列化包头部指定了三对key-value,因此原本位于key[3]的键值对被丢弃了。(当前是序列化的文件解析,反序列化时key[1]的解析会报错但是会被捕获不会造成崩溃。)

[1] key的大小为0还是会读出key的值,如下函数:

在第二次序列化之后多出 0000 0000 导致之后所有的解析都偏移0×4字节。示意图如下:

EvilParcel 漏洞原理

由于在第一次反序列化时,隐藏的key没有显示出来,这是因为在反序列化过程中使用的是in.readInt()方法,它只会读取4个字节的数据。而在序列化过程中,由于错误的写入操作使用了dest.writeLong()方法,它会写入8个字节的数据。这就导致了在第一次反序列化时,只读取了4个字节的数据,而隐藏的key并没有被完整解析和显示出来。然而,在序列化后再进行反序列化时,由于之前的序列化错误导致了额外的4个字节(即多写了4字节的0)。这些额外的字节会在反序列化过程中被解析,并被误认为是隐藏的key的一部分。因此,在第二次反序列化时,隐藏的key被正确解析并显示出来。这种不匹配的读写操作导致了整体的偏移,从而导致隐藏的key在第一次反序列化时未能正确显示。而在第二次反序列化时,由于解析过程中的偏移修复,隐藏的key才能被完整解析并恢复。

案例分析

1. CVE-2017-13315 反序列化漏洞分析

CVE-2017-13315是一个典型的 EvilParcel 漏洞案例,它对Android操作系统中的Binder组件产生了影响。具体表现为在Parcelable对象的写入和读取过程中存在不一致,导致后续的key-value解析错位。这个漏洞于2017年被安全研究人员发现并报告。成功利用CVE-2017-13315漏洞的攻击者可以实现对目标应用程序的完全控制。攻击者可以利用该漏洞读取、修改或删除敏感数据,执行任意系统命令,甚至在用户不知情的情况下安装恶意应用程序。该漏洞的根本原因在于Binder组件在处理Parcelable对象时的错误解析和解构过程,导致数据错位和不一致。攻击者可以通过构造特定的恶意Parcelable对象,利用这种不一致性来欺骗目标应用程序,从而实现任意代码执行和攻击目标。

2. 漏洞产生原因和利用方式

2018年5月份修复的CVE-2017-13315在DcParmObject类中。

https://android.googlesource.com/platform/frameworks/base/+/35bb911d4493ea94d4896cc42690cab0d4dbb78f

原因是DcParamObject对象中的writeToParcel和readFromParcel方法不匹配。writeToParcel方法在序列化过程中多写入了一个额外的”0000″数据。这种写入方式导致序列化和反序列化的数据不一致,进而影响了第二次反序列化时的解析过程。由于解析错位,隐藏的key-value数据得以出现,从而绕过了第一次反序列化时的安全检测。

攻击者可以构造一个恶意的Android应用程序,通过发送恶意的Bundle到Settings应用中,从而利用EvilParcel漏洞控制Settings执行系统权限的操作。在构造Bundle时,Android应用程序会创建三个键值对。第一个键值对是正常的、合法的数据,用于掩盖恶意操作。第二个键值对的值会被精心构造,其中包含恶意的payload,即攻击者想要在Settings应用中执行的系统权限操作。这个恶意的payload可能包括修改系统设置、获取敏感信息等恶意行为。而第三个键值对只是用来占位的,其键和值可以随意填写,没有实际作用。当这个恶意的Bundle被发送到Settings应用时,Settings应用会进行序列化操作,并将其存储在内存中。然后,在反序列化时,由于EvilParcel漏洞的存在,读取操作与写入操作不匹配,多出的4个字节的0导致解析偏移。这样,恶意的payload会被解析为Settings应用的操作指令,从而执行系统权限的操作。

示意图:

EvilParcel 漏洞原理

App发送的Bundle首先会到system_server中进行反序列化检查。这个反序列化检查是为了防止潜在的安全漏洞和恶意行为。在这里,与2013年相关的错误7699048打了一个补丁,也被称为Launch AnyWhere。该补丁的目的是防止第三方应用程序通过系统用户越权调用。system_server会对应用的数字签名进行验证,以确保其合法性和可信性。如果验证成功,system_server会将Bundle传输到IAccountManagerResponse.onResult()方法,并通过IPC机制调用onResult()。在这个过程中,系统会对Bundle进行二次序列化,以便在不同进程间传递数据。这种两次序列化的过程是为了增强安全性。第一次序列化和反序列化发生在系统边界内,由system_server负责处理,可以对数据进行验证和过滤,以确保只有合法的、经过授权的应用程序能够访问和操作数据。第二次序列化发生在IPC通信过程中,确保数据的安全传输和完整性。通过这种机制,系统能够有效地控制和管理应用程序之间的数据传输,防止恶意应用程序利用Bundle的序列化和反序列化过程进行攻击或滥用系统权限。

在调用onResult()函数时,由于二次序列化的过程,隐藏在key[1]中的value中的恶意payload将被显示出来。这意味着KEY_INTENT的值存在,并且可以被访问和利用。由于当前进程是系统用户,因此成功启动任意Activity成为可能。这相当于从用户权限提升至系统权限。通过利用这个漏洞,可以结合其他组件和功能来实现系统权限的写入和读取操作。例如,通过启动任意Activity,可以访问系统设置、修改系统配置、获取敏感信息等。此外,还可以利用系统权限执行恶意代码、篡改系统文件、获得持久性访问权限等。

二次序列化示意图:

EvilParcel 漏洞原理

如下是网上开源的poc代码,该代码成功执行后会调用隐藏的重置PIN密码界面,而在这个界面输入新的PIN密码将能够覆盖旧的PIN码,而无需进行验证。这是因为普通的App应用程序通常没有权限来调用该界面。在正常情况下,即使在用户界面上手动点击打开PIN重置密码选项,也需要先验证原始PIN密码后才能输入新的PIN密码。这种漏洞的存在使得攻击者能够绕过正常的安全措施,直接修改设备的PIN密码而无需进行必要的验证流程。这可能导致个人隐私的泄露、设备数据的访问和篡改,甚至可能导致设备被完全控制和滥用。

成功执行后,该poc代码将启动settings中隐藏的ChooseLockPassword界面。这个界面是Android系统中的一个重要设置界面,用于选择和设置设备的锁屏密码。正常情况下,只有经过授权的用户或具有相应权限的应用程序才能访问和修改此界面。然而,由于漏洞的存在,攻击者可以利用该poc代码来绕过正常的权限限制,直接启动隐藏的ChooseLockPassword界面。在这个界面上,攻击者可以输入新的PIN密码,而无需进行原始密码的验证。这使得攻击者能够修改设备的锁屏密码,从而获得对设备的控制权。

EvilParcel 漏洞原理

参考:

1、Bundle风水——Android序列化与反序列化不匹配漏洞详解 https://xz.aliyun.com/t/2364?page=1

2、EvilParcel vulnerabilities analysis https://habr.com/en/companies/drweb/articles/457610/#:~:text=CVE%2D2017%2D13315%20belongs%20to,between%20apps%20and%20the%20system.

 

 

 

 

Written by topsec_support