Android第二个绕过签名认证漏洞原理

一、漏洞描述


该漏洞最早由国内“安卓安全小分队”(http://blog.sina.com.cn/u/3194858670)发现并提交给Google,Google迅速修复了该漏洞,对应编号为bug 9695860。该漏洞是即Bluebox Security提报Android 绕过应用签名认证漏洞后又一成功绕过Android签名认证漏洞。该漏洞原理与Bluebox Security漏洞略有不同。

二、影响设备
理论上会影响漏洞修复前所有设备。

三、漏洞原理


了解该漏洞需要对ZIP格式有些许了解(http://www.pkware.com/documents/casestudies/APPNOTE.TXT)。

在每个Zip文件中都有一个Central directory,Central directory中的每一项是一个File header。这个File header的结构对应到Android代码的类就是ZipEntry。File header结构中有一个偏移量指向local file header,local file header后面就紧跟着file data。接下来我们详细看一下local file header的结构:
local file header signature 4 bytes (0x04034b50)
version needed to extract 2 bytes
general purpose bit flag 2 bytes
compression method 2 bytes
last mod file time 2 bytes
last mod file date 2 bytes
crc-32 4 bytes
compressed size 4 bytes
uncompressed size 4 bytes
file name length 2 bytes
extra field length 2 bytes
file name (variable size)
extra field (variable size)


可以看到,除最后2个域以外,local file header的其他域都是定长的。而这两个变长域的长度是由file name length和extra field length所确定。再次说明,紧跟在extra field后面的就是文件的数据file data了。

Android是如何进行apk校验的呢?
Android在进行apk文件校验时,会调到ZipFile的public InputStream getInputStream(ZipEntry entry)函数。这函数中,有这么一段:


RAFStream rafstrm = new RAFStream(raf, entry.mLocalHeaderRelOffset + 28);
DataInputStream is = new DataInputStream(rafstrm);
int localExtraLenOrWhatever = Short.reverseBytes(is.readShort());
is.close();

// Skip the name and this "extra" data or whatever it is:
rafstrm.skip(entry.nameLength + localExtraLenOrWhatever);
rafstrm.mLength = rafstrm.mOffset + entry.compressedSize;
if (entry.compressionMethod == ZipEntry.DEFLATED) {
int bufSize = Math.max(1024, (int)Math.min(entry.getSize(), 65535L));
return new ZipInflaterInputStream(rafstrm, new Inflater(true), bufSize, entry);
} else {
return rafstrm;
}

注意:上述代码中红色部分。localExtraLenOrWhatever就是local file header结构中的extra field length。如果这里的extra filed length的大小是大于2^15,会怎么样?
没错,localExtraLenOrWhatever将会是负值。因此接下来,rafstrm.skip(entry.nameLength + localExtraLenOrWhatever); 这句将无法真正跳过变长域file name (variable size) 和extra field (variable size)。反而有可能呢会跳到file name (variable size)中,甚至file name (variable size)之前。当然为了攻击方便,我们还是期望它跳到file name (variable size)中。

漏洞攻击方式:
要改变一个apk的行为,显然攻击的目标就是apk里的classes.dex文件。对于classes.dex文件在apk文件中的local file header结构,其file name (variable size)域的内容肯定就是“classes.dex”了。注意,这里的后缀名dex,正好和dex文件开头的三个字节完全相同(不理解的,参见dex文件格式)。


a) 利用这一点,从file name (variable size)域“classex.dex”的“.”之后开始我们可以写入一个完整的dex文件。这个dex文件必须是原apk里的classes.dex文件。只有这样才能绕过签名验证。
b) 修改extra field length,使之为0xFFFD。因为这个值刚好为-3。根据漏洞,rafstrm.skip(entry.nameLength + localExtraLenOrWhatever); 这句就会跳到file name (variable size)域中的“.”之后。也就是一个dex文件的开始,这里必须是原dex文件内容。
c) 修改local file header之后的file data数据。在这里写入带有攻击代码的classes.dex内容。
d) 以上的修改会带来apk文件一些结构上的调整,比如扩充extra field域,调整file data大小等。


具体攻击模型,如下图。

Android第二个绕过签名认证漏洞原理_第1张图片


总的来说该攻击手段,首先利用了Android在签名验证过程中,对Zip文件相应16位域的读取时,没有考虑到大于2^15的情况。(因为java的int , short, long都是有符号数,而不像C/C++里有无符号数)。
其次利用了Zip文件中的local file header结构的extra field域来存放原classes.dex。但这个域的大小最多只能是2^16-1,因此被攻击的Apk里的classes.dex大小必须在64K以内。否则,就无法对其进行攻击。这算是这种攻击方式的一个限制。
最后还有一个问题补充说明:之所以这种攻击方式能成功,还在于在运行时,系统抽取的是hacked classes.dex,而在签名校验时,验证的是extra域里的classes.dex。前者是在libdex.so中实现,后者在Java层实现。是由Java层跟Native层不一致导致。


四、相关链接

http://www.androidpolice.com/2013/07/11/second-all-access-apk-exploit-is-revealed-just-two-days-after-master-key-goes-public-already-patched-by-google/

你可能感兴趣的:(Android第二个绕过签名认证漏洞原理)