APK基础

APK文件格式

任意一个APK文件包含以下文件夹

assets

assets文件用来存放需要打包到Android应用程序的静态资源文件，例如图片资源文件、json配置文件、渠道配置文件、二进制数据文件、HTML5离线资源文件等。

assets目录支持任意深度的子目录，同时该目录下面的文件不会生成资源ID。

res

res也是存放资源目录的。但是它不支持任意深度的子目录，它里面存放的东西都是关于应用程序的资源（图标图片等），不能乱放乱改（需要符合它的规则）

lib

lib文件夹代表的是当前app所用得到的so文件，so文件就是利用底层的c，c++代码实现的。（也就是程序的依赖库）

META-INF

META-INF文件就是所用到的证书签名文件。

MANIFEST.MF(摘要文件)：程序遍历apk包中的所有文件，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果APK包的文件被修改，在APK安装校验时，被修改的文件与MAINFEST.MF的校验信息不通，程序将无法正常安装。

CERT.SF(对摘要文件的签名文件)：对于生成的MAINFEST.MF的文件利用SHA1-RSA算法对开发者的私钥进行签名。在安装时只有公共密钥才能对其解密。解密之后将其与未加密的摘要信息进行对比，如果相符则文件没有被修改。

CERT.RSA:保存公钥、加密算法等信息。

AndriodManifest.xml

这个是安卓应用程序的配置文件，它像一个目录一样，对apk进行了统一处理，包括指定索引等，记录版本等信息。其中Android应用的四大组件（Activity，Service，BroadcastReceiver和ContentProvider）均在此配置和声明。

class.dex

应用程序的可执行文件。可以看到此APP有多个dex，是因为当前的方法数超过65535，进行了分包处理。如果未超过，则只有一个dex。Android的所有代码都集中与此。可以通过反编译工具讲dex转化为jar包，再通过jd-gui查看其代码。

resources.arsc

该文件主要是资源索引表，用来描述具有id值的资源的配置信息。

APK打包流程

三个基本的东西：

APP资源文件（application resource），APP相关源码（application resource code），Aidl files（实现跨进程通讯AIDL的文件。其本质是安卓底层的一个接口）

流程：

APP资源文件通过工具AAPT生成了R.JAVA和Complied reousrces。

APP相关源码加上R.JAVA,java interface通过java Compiler工具生成为.class Files.

.class files在第三方文件库的加成下通过dex编译器生成dex文件。

Complied resoueces 和 other resources再加上dex文件通过工具apkbuilder生成.apk的安卓文件。

.apk安装包生成出来也不能直接用，需要工具Jarsigner加上签名需要的一个jar包keystore进行签名，拿到许可证，生成签了名的apk。

最后在通过工具aipalign压缩一下进行处理，就生成一个完整的apk文件。

APK安装流程

涉及到的目录

1. system/app：系统自带的应用程序，获得adb root权限才能删除。
2. data/app：用户程序安装的目录。安装时把apk文件复制到此处。
3. data/data：存放应用程序的数据。
4. data/dalvik-cache：将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件，其大小约为原始apk文件大小的四分之一。)

安装流程

在点击安装后流程可以分为两步：

拷贝apk和解析apk。

拷贝apk：

1. 复制APK 到/data/app/包名/目录下解压并扫描数据包。
2. 在 /data/data/目录下拷贝数据文件。

解析apk：

1. 对dex文件进行优化操作，保存在/data/dalvik-cache/里面。
2. 通过androidManifet.xml解析出四大组件。

卸载流程

删除安装过程中在上述三个目录下创建的文件及目录。

APK虚拟机

除了JAVA虚拟机之外，需要区分的是不同安卓版本，虚拟机不一样。

在Android5.0以下，使用的是DALVIK虚拟机，安卓5.0版本及以上就使用的

ART虚拟机。

DALVIK

Dalvik虚拟机它的本质是在/system/bin/dexopt

.dex=>dexopt=>.odex dalvi加载执行的是odex文件。

AOT

AOT虚拟机本质是/system/bin/dex2oat

其系统启动在于以下三个目录：

/system/app,/data/app,/system/framewok。

.dex=>dex2oat>.oat art加载执行的是oat文件。

项目技术分析

根据readme和pom文档可以知道该项目采用了以下技术：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

<dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-freemarker</artifactId>
    </dependency>

    <dependency>
      <groupId>com.alibaba</groupId>
      <artifactId>druid-spring-boot-starter</artifactId>
      <version>1.1.22</version>
    </dependency>
    <dependency>
      <groupId>org.mybatis.spring.boot</groupId>
      <artifactId>mybatis-spring-boot-starter</artifactId>
      <version>1.3.2</version>
    </dependency>
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.alibaba</groupId>
      <artifactId>fastjson</artifactId>
      <version>1.2.62</version>
    </dependency>
    <dependency>
      <groupId>org.apache.poi</groupId>
      <artifactId>poi-ooxml</artifactId>
      <version>3.17</version>
    </dependency>

项目结构

通过对代码的一个大致结构分析，知道了它的主要功能都是在system目录下。

system目录下有class和template文件，template代表是前端，class是后端处理文件。

项目结构

根据项目的readme可以知道，该系统采用了SpringBoot+Shiro+Mybatis+Easyui。

代码审计

XSS漏洞审计

全局搜索关键字XSS，发现什么都没有搜出来，感觉应该是裸防护的，应该是全栈XSS。随便进入后台插框一次。

依次弹框出1，2，3

shiro反序列化漏洞(CVE-2019-12422 不存在)

通过pom文件可以知道

1
2
3
4
5

<dependency>
		<groupId>org.apache.shiro</groupId>
		<artifactId>shiro-core</artifactId>
		<version>1.4.0</version>
	</dependency>

虽然引入了shiro的包，也通过网上查证1.4.0确实有历史漏洞，但是shiro最主要的特征是是否具有remerberme字段，发现登录的时候并没有记住我功能，登录后也没有相关cookie。

全局搜索之后也没有类似cookiemanage字样，所以应该是没有该漏洞。

SQL注入(不存在)

因为该项目使用的是mybatis，mybatis的主要问题就是$和#的差距，但是全局搜索xml文档，发现并没有xml使用了$符号.

所以应该是不存在。

CSRF

CSRF的审计关键是在于查看数据包中是否具有token等校验字段。

发现并没有校验字段，于是生成csrf试探一手，用另一个账户登录。再点击该html，发现修改成功，证明有csrf漏洞存在。

前期准备

1
2
3
4
5
6
7

下载链接：
https://www.vulnhub.com/entry/darkhole-1,724/
攻击机：
kali：192.168.128.128
win11：192.168.128.1
靶机：
darkhole：192.168.128.0网段

项目结构分析

根据readme可以知道这个是SSM结构。

1
2
3
4
5
6
7
8
9
10
11

**技术框架**  </br>

核心框架：Spring Framework</br>

视图框架：Spring MVC </br>

持久层框架：MyBatis 3</br>

JS框架：jQuery</br>

富文本：kindeditor</br>

代码审计

XSS审计

全局搜索XSS，发现没有什么过滤器。

猜测大概率存在XSS漏洞。这里随便去后台加一手信息。

验证了XSS漏洞的存在。同时应该还有很多写数据的功能都存在XSS漏洞。

SQL注入

因为已经知道了是用的mybatis。所以全局搜索$符号，发现在MsgSystemMapper里面有一句话。

追踪溯源，发现是为了删除系统信息。

从控制层AdminMsgSystemController开始，到业务层和dao层，都没有发现对参数ids进行校验。可以确定有漏洞。

进入后台找到系统信息，删除系统信息列表。删除一个测试的消息内容，进行抓包。

添加payload：

1

ids=2 and sleep(2)

同时使用sqlmap也验证了一手

越权漏洞

在UserController里面可以看到updateuserInfo方法

貌似这里并没有做什么校验，而是直接带入了servicer层和dao层。

在xml里面也只有简单的

但是不排除会有mybatis的额外保护机制，所以复现一下为好。

将userid改为4，发包后去数据库中查看4的数据。

验证成功。

同时在管理员的密码修改界面，也能修改其他管理员账户的密码。

项目技术分析

根据项目readme文档可知，该项目采用了如下技术：

项目结构

通过上图可以看到该项目主要使用了分包分模块的架构及若依框架，其他的框架技术不难通过若依框架的通用技术分析出来。引入的开源组件通过pom.xml获取。

项目技术分析

通过项目结构，能够看出来使用的技术为前后端分离。在看readme文档可以发现，技术框架分别有：

漏洞审计思路

审计流程

1. 主要是看使用了什么框架，是ssm还是ssh，还是servelt等。
2. 看针对权限控制是否使用了shiro,springsecurity等统一的权限控制框架，如果未使用任务权限验证框架，而是采用了手动的人工权限验证，则容易存在业务逻辑漏洞。
3. 通过lib文件夹下，pom文件等查看使用的开源组件和版本信息，作为审计开源组件通用漏洞的突破口
4. 了解平台所使用的市场上常见的成熟的cms技术和版本，可以从供应链入手查找其他类似项目
5. 熟悉系统的源码构成，按照MVC思想，了解主要的功能模板和对应的javabean
6. 在1-5基础上针对各类漏洞源码分析发现漏洞