Android应用中的常见漏洞总结(下)

Android应用中的常见漏洞总结下期来啦,和小编一起看看吧~

Zip包下载

UnZip解压文件漏洞

描述:

Zip
slip漏洞其实也是目录遍历的一种,通过应用程序解压恶意的压缩文件进行攻击。恶意攻击者通过构造一个压缩文件条目中带有…/的压缩文件,上传后交给应用程序进行解压。由于程序解压时没有对文件名进行合法性的校验,而是直接将文件名拼接在待解压目录后面,导致可以将文件解压到正常解压缩路径之外并覆盖可执行文件,从而等待系统或用户调用他们实现代码执行(也可能是覆盖配置文件或其他敏感文件)。

背景知识:

在Linux/Unix系统中“…/”代表的是向上级目录跳转,有些程序在当前工作目录中处理到诸如用“…/…/…/…/…/…/…/…/…/…/…/etc/hosts”表示的文件,会跳转出当前工作目录,跳转到到其他目录中。

Java代码在解压ZIP文件时,会使用到ZipEntry类的getName()方法,如果ZIP文件中包含“…/”的字符串,该方法返回值里面原样返回,如果没有过滤掉getName()返回值中的“…/”字符串,继续解压缩操作,就会在其他目录中创建解压的文件。

产生原理 :

因为ZIP压缩包文件中允许存在"…/"的字符串,攻击者可以利用多个“…/”在解压时改变ZIP包中某个文件6存放位置,覆盖掉应用原有的文件。如果被覆盖掉的文件是动态链接so、dex或者odex文件,轻则产生本地拒绝服务漏洞,影响应用的可用性,重则可能造成任意代码执行漏洞,危害用户的设备安全和信息安全.。

Android签名类

描述:

Android具有签名机制。正常情况下,开发者发布了一个应用,该应用一定需要开发者使用他的私钥对其进行签名。恶意攻击者如果尝试修改了这个应用中的任何一个文件(包括代码和资源等),那么他就必须对APK进行重新签名,否则修改过的应用是无法安装到任何Android设备上的。但如果恶意攻击者用另一把私钥对APK签了名,并将这个修改过的APK对用户手机里的已有应用升级时,就会出现签名不一致的情况。因此,在正常情况下,Android的签名机制起到了防篡改的作用。但如果恶意攻击者利用漏洞,那么恶意攻击者就可以任意地修改一个APK中的代码(包括系统的内置应用),同时却不需要对APK进行重新签名。换句话说,用这种方式修改过的APK,Android系统会认为它的签名和官方的签名是一致的,但在这个APK运行时,执行的却是恶意攻击者的代码。恶意攻击者利用这个修改过的APK,就可以用来覆盖安装原官方应用(包括系统的内置应用)。

“MasterKey”漏洞

背景知识:

Android签名的Signature Version V1 Android7.0之前的签名方式,使用jar
Signature方式对APK进行签名打包,jar Signature来自JDK。APK进行签名时会生成一个META-
INF文件夹,里面有三个文件:MANIFEST.MF,CERT.RSA,CERT.SF,是用来记录签名信息的。

MANIFEST.MF:

逐一遍历所有条目,如果是目录就跳过,如果是一个文件,就用SHA1(或者SHA256)消息摘要算法提取出该文件的摘要然后进行BASE64编码后,作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性,其值就是该文件在apk包中的路径。

CERT.SF:

1.计算这个MANIFEST.MF文件的整体SHA1值,再经过BASE64编码后,记录在CERT.SF主属性块(在文件头上)的“SHA1-Digest-
Manifest”属性值值下。

2.逐条计算MANIFEST.MF文件中每块的SHA1,并经过BASE64编码后,记录在CERT.SF中的同名块中,属性的名字是“SHA1-Digest”。

CERT.RSA是一个满足PKCS7格式的文件:它会把之前生成的 CERT.SF文件,用私钥计算出签名,
然后将签名以及包含公钥信息的数字证书一同写入CERT.RSA中保存。

漏洞利用:

1.向原始的App APK的前部添加一个攻击的classes.dex文件(A);

2.安卓系统在校验时计算了A文件的hash值,并以”classes.dex”字符串做为key保存;

3.然后安卓计算原始的classes.dex文件(B),并再次以”classes.dex”字符串做为key保存,这次保存会覆盖掉A文件的hash值,导致Android系统认为APK没有被修改,完成安装;

4.APK程序运行时,系统优先以先找到的A文件执行,忽略了B,导致漏洞的产生。

“9695860”漏洞

背景知识:

在每个Zip文件中都有一个Central directory,Central directory中的每一项是一个File header。这个File
header的结构对应到Android代码的类就是ZipEntry。File header结构中有一个偏移量指向local file
header,local file header后面就紧跟着file data。

local file header signature     4 bytes  
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)

//android 进行apk校验
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;
}

漏洞原理:

Java代码在读取“Central directory file header”结构的“Extra field
length”字段(java代码视为有符号short,C代码视为无符号short)时,如果大小超过0x7FFF则认为是负数,代码逻辑将负数一律按零处理。

1. 向原有的APK中的classes.dex文件B替换为攻击文件A,并添加一个大小为0xFFFD的extrafield;

2. 将原始dex文件B去除头3个字节写入extrafield;

3. Android系统在校验签名时使用的是Java代码的short,将0xFFFD以16位带符号整形的方式解析得到-3,
并解析出原始的文件B,Android认为程序APK没有修改,正常安装;

4. 系统在执行时使用C代码的uint16,将0xFFFD以16位无符号整形方式,得到攻击文件B。

按照正常逻辑,android读取local file header的file name length 和 extra field
length,跳转到file data
对classws.dex校验,hack后按照以下模型,java校验读原来的,没什么问题,但c读取classes.dex是读去我们的fake dex。

“9950697”漏洞

Signature Version V1的第3个洞,适用于android4.4以下的版本

漏洞原理:

Android在校验签名时,解析Apk包用的是java代码(ZipFile.java和ZipEntry.java),而在安装apk时,包括解压、dexopt等,用的是c代码(ZipArchive.cpp),这两份代码在解析ZipEntry时的步骤都是先从索引段读取ZipEntry的信息,然后定位到数据段。

数据段中的ZipEntry的Data[]字段是用来存放真正的压缩数据的。Java和c定位到Data[]字段的方法都是根据Data[]字段之前的字段的长度计算偏移:

Data[]的偏移 = ZipEntry的偏移 + 固定header的长度 + extraFieldLength + fileNameLength

Java使用的fileNameLength是从索引段的ZipEntry获得的,而C则是从数据段的ZipEntry获得的,所以就这里造成了不一致性,导致java和c定位到的data[]不一致。因此可以在数据段的ZipEntry中构造一个不一样的fileNameLength,进而让java校验签名时读取的是合法的文件,而c在安装是读取的是恶意的文件,绕过签名验证。

“janus”漏洞(CVE-2017-13156)

背景知识:

Android在4.4引入ART虚拟机,相比较于Dalvik虚拟机仅能运行包装于apk中的dex文件,ART还允许直接运行优化后的dex文件。具体操作是通过读取文件头部的magic字段进行判断,区别执行apk或者dex。

ZIP文件的读取方式是读取文件末尾定位的central directory, 然后通过里面的索引定位到各个zip
entry,每个entry解压之后都对应一个文件。ParseZipArchive()函数在进行以上处理时候并没有判断文件头部的magic字段是否为504B0304,即Zip。

漏洞原理:

攻击者可以通过将恶意dex文件置于apk文件的头部(如下图所示)。在系统安装apk文件时,系统安装器解压zip时并没有先判断apk文件的头部magic字段,默认是apk(zip)文件,从而直接从文件尾部进行读取解压,此时签名没有任何变化,因此可欺骗系统,从而进行安装。

攻击关键点是当用户点击运行apk时,系统ART虚拟机会去判断文件头部的magic字段,从而使用不同的策略执行文件,由于该apk文件头部被修改为恶意dex,因此art虚拟机直接执行恶意dex文件。

攻击模型:

最后

分享一个快速学习【网络安全】的方法,「也许是」最全面的学习方法:
1、网络安全理论知识(2天)
①了解行业相关背景,前景,确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。(非常重要)

2、渗透测试基础(一周)
①渗透测试的流程、分类、标准
②信息收集技术:主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理,利用方法、工具(MSF)、绕过IDS和反病毒侦察
④主机攻防演练:MS17-010、MS08-067、MS10-046、MS12-20等

3、操作系统基础(一周)
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全(系统入侵排查/系统加固基础)

4、计算机网络基础(一周)
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析(HTTP、TCP/IP、ARP等)
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御:主动/被动攻击、DDOS攻击、CVE漏洞复现

5、数据库基础操作(2天)
①数据库基础
②SQL语言基础
③数据库安全加固

6、Web渗透(1周)
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具:Nmap、BurpSuite、SQLMap、其他(菜刀、漏扫等)

在这里插入图片描述

恭喜你,如果学到这里,你基本可以从事一份网络安全相关的工作,比如渗透测试、Web 渗透、安全服务、安全分析等岗位;如果等保模块学的好,还可以从事等保工程师。薪资区间6k-15k。

到此为止,大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗?

想要入坑黑客&网络安全的朋友,给大家准备了一份:282G全网最全的网络安全资料包免费领取!
扫下方二维码,免费领取

有了这些基础,如果你要深入学习,可以参考下方这个超详细学习路线图,按照这个路线学习,完全够支撑你成为一名优秀的中高级网络安全工程师:

高清学习路线图或XMIND文件(点击下载原文件)

还有一些学习中收集的视频、文档资源,有需要的可以自取:
每个成长路线对应板块的配套视频:


当然除了有配套的视频,同时也为大家整理了各种文档和书籍资料&工具,并且已经帮大家分好类了。

因篇幅有限,仅展示部分资料,需要的可以【扫下方二维码免费领取】

猜你喜欢

转载自blog.csdn.net/text2207/article/details/129755283