Android 应用程序是在开发应用程序时建立的数据和资源文件的归档文件。 Android 应用程序的扩展名是.apk,意思是应用程序包,在大多数状况下包括如下文件和文件夹:php
为了验证这一点,咱们可使用任何归档管理器应用程序(如 7zip,WinRAR 或任何首选应用程序)简单地解压缩应用程序。 在 Linux 或 Mac 上,咱们能够简单地使用unzip命令来展现压缩包的内容,以下面的截图所示android
Android 应用程序由各类组件组成,它们一块儿建立可工做的应用程序。 这些组件是活动,服务,广播接收器,内容供应器和共享首选项。 在继续以前,让咱们快速浏览一下这些不一样的组件: git
Android应用程序只是一个数据和资源的归档文件。 即便这样,咱们不能简单地解压缩归档包(.apk)来得到可读的源代码。 对于这些状况,咱们必须依赖于将字节代码(如在classes.dex中)转换为可读源代码的工具github
在mac os系统上反编译android apk,首先须要准备好如下3个文件:算法
一、apktool:https://ibotpeaches.github.io/Apktool/install/ shell
二、dex2jar:https://github.com/pxb1988/dex2jar 数据库
三、jd-gui:http://jd.benow.ca后端
打开jd-gui工具,将classes-dex2jar.jar拖入便可 浏览器
使用 Apktool 逆向 Android 应用 缓存
另外一种逆向 Android应用程序的方法是将.dex文件转换为 smali 文件。 smali 是一种文件格式,其语法与称为 Jasmine 的语言相似。咱们如今不会深刻了解 smali 文件格式。有关更多信息,请参阅在线 wikihttps://code.google.com/p/smali/wiki/,以便深刻了解 smali
1)将.apk文件与 Apktool 二进制文件一块儿传递给命令行。一旦反编译完成,Apktool 将使用应用程序名称建立一个新的文件夹,其中会存储全部的文件。为了反编译,咱们只需调用apktool d [app-name].apk (-d标志表示反编译)
2)apktool b [decompiled folder name] [target-app-name].apk 生成class.DEX2jar.jar 文件
Android 应用程序一般包含许多安全漏洞,大多数时候是因为开发人员的错误和安全编码实践的无视
许多应用程序使用内容供应器来存储和查询应用程序中的数据或来自电话的数据。 除非已经定义了内容提供者可使用权限来访问,不然任何其余应用均可以使用应用所定义的内容供应器,来访问应用的数据。 全部内容供应器具备惟一的统一资源标识符(URI)以便被识别和查询。 内容提供者的 URI 的命名标准惯例是以content://开始。
若是 Android API 版本低于 17,则内容供应器的默认属性是始终导出。 这意味着除非开发人员指定权限,不然任何应用程序均可以使用应用程序的内容供应器,来访问和查询数据。 全部内容供应器都须要在AndroidManifest.xml中注册。 所以,咱们能够对应用程序使用 Apktool,并经过查看AndroidManifest.xml文件检查内容供应器
定义内容供应器的通常方法以下所示:
<provider
android:name="com.test.example.DataProvider"
android:authorities ="com.test.example.DataProvider">
</provider>
简单地查看定义它们的AndroidManifest.xml文件,或者咱们可使用一个简单的grep命令,从应用程序代码中获取内容供应器 ,使用grep –R 'content://'
经过建立另外一个没有任何权限的应用程序来查询内容供应器,而后查询漏洞应用程序的内容供应器。 为了快速得到信息,咱们还可使用adb查询内容供应器,咱们能够在如下命令中看到:
adb shell content query - - uri [URI of the content provider]
还可使用 MWR 实验室的另外一个名为 Drozer 的工具,以便在 Android 应用程序中找到泄漏的内容供应器漏洞。 咱们能够从官方网站https://labs.mwrinfosecurity.com/tools/drozer/下载并安装 Droze
一旦咱们安装了它,咱们须要将代理组件agent.apk安装到咱们的模拟器,它位于下载的.zip文件内。 该代理是系统和设备相互交互所需的。 咱们还须要在每次启动模拟器时转发一个特定的端口(31415),以便创建链接。 要在 Mac 和其余相似平台上安装设备,咱们能够按照https://www.mwrinfosecurity.com/system/assets/559/original/mwri_drozer-users-guide_2013-09-11.pdf上提供的在线指南
此后,咱们须要访问终端并启动 Drozer,并将其链接到模拟器/设备。 为此,咱们须要输入drozer console connect
dz> run app.provider.finduri com.threebanana.notes
Scanning com.threebanana.notes…
content://com.threebanana.notes.provider.NotePad/notes
content://com.threebanana.notes.provider.NotePadPending/notes/
content://com.threebanana.notes.provider.NotePad/media
content://com.threebanana.notes.provider.NotePad/topnotes/
content://com.threebanana.notes.provider.NotePad/media_with_owner/
content://com.threebanana.notes.provider.NotePad/add_media_for_note
content://com.threebanana.notes.provider.NotePad/notes_show_deleted
content://com.threebanana.notes.provider.NotePad/notes_with_images/
一旦咱们有了 URI,咱们如今可使用 Drozer 应用程序查询它。 为了查询它,咱们须要运行app.provider.query模块并指定内容供应器的 URI,以下面的截图所示
若是 Drozer 可以查询和显示来自内容供应器的数据,这意味着内容供应器泄漏数据而且存在漏洞,由于 Drozer 没有被明确地授予使用数据集的任何权限。
为了修复此漏洞,开发人员须要作的是,在建立内容供应器时指定参数android:exported = false,或者建立一些新的权限,另外一个应用程序在访问供应器以前必须请求它
一般,开发人员为应用程序存储数据时,未指定文件的正确文件权限。 这些文件有时被标记为全局可读,而且能够由任何其它应用程序访问而不须要请求权限,
为了检查这个漏洞,咱们所须要作的是访问adb shell,以后使用cd进入/data/data/[package name of the app]
若是咱们在这里执行一个简单的ls -l,就能够看到文件和文件夹的文件权限:
# ls -l /data/data/com.aditya.example/files/userinfo.xml
-rw-rw-rw- app_200 app_200 22034 2013-11-07 00:01 userinfo.xml
这里咱们可使用find来搜索权限。
find /data/data/ -perm [permissions value]
若是咱们执行cat userinfo.xml,它储存了应用的用户的用户名和密码。
#grep 'password' /data/data/com.aditya.example/files/userinfo.xml
<password>mysecretpassword</password>
这意味着任何其余应用程序也能够查看和窃取用户的机密登陆凭据。 能够经过在开发应用程序时指定正确的文件权限,以及一块儿计算密码与盐的散列来避免此漏洞
顾名思义,应用程序中的路径遍历漏洞容许攻击者使用漏洞应用程序的供应器读取其余系统文件。
此漏洞也可使用咱们以前讨论的工具 Drozer 进行检查。 在这里,咱们用例子来讲明由 Seafastian Guerrero 发现的 Adobe Reader Android 应用程序漏洞(http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-adobe-reader-android-application)。 此漏洞存在于 Adobe Reader 10.3.1 中,并在之后的版本中进行了修补。 你能够从http://androiddrawer.com下载各类 Android 应用程序的旧版本
咱们将启动 Drozer,并运行app.provider.finduri模块来查找内容供应器 URI。
dz> run app.provider.finduri com.adobe.reader
Scanning com.adobe.reader...
content://com.adobe.reader.fileprovider/
content://com.adobe.reader.fileprov
一旦咱们找到了 URI,咱们如今可使用app.provider.read搜索并利用本地文件包含漏洞。 在这里,我尝试从系统中读取一些文件,如/etc/hosts和/proc/cpuinfo,它们默认存在于全部的 Android 实例中,由于它是基于 Linux 的文件系统。
dz> run app.provider.read content://com.adobe.reader.fileprovider/../../../../etc/hosts
127.0.0.1 localhost
客户端攻击一般发生在应用程序未检查用户输入的时候。 例如,在对 SQLite 数据库的查询期间,应用程序正在解析用户输入,由于它位于查询语句中。
让咱们举一个应用程序的示例,它检查本地 SQLite 数据库,来根据登陆凭据验证用户。 所以,当用户提供用户名和密码时,正在运行的查询将以下所示:
SELECT * FROM 'users' where username='user-input-username' and password='user-input-password'
如今,在正常状况下,这将正常工做,用户输入其真正的登陆凭据,而且查询取决于条件将返回true或false。
SELECT * FROM 'users' where username='aditya' and password='mysecretpass
可是,若是攻击者输入 SQL 语句而不是正常的用户名怎么办? 请参考如下代码:
SELECT * FROM 'users' where username='1' or '1' = '1' - - and password='mysecretpassword
所以,在这种状况下,即便用户不知道用户名和密码,他们能够经过使用1'or'1'='1查询来轻松绕过它,这在全部状况下都返回true。 所以,应用程序开发人员必须在应用程序中进行适当的检查,来检查用户输入。
咱们还可使用 Drozer 的app.provider.query来利用 SQL 注入漏洞。 其语法看起来像:
run app.provider.query [Content Provider URI] --projection "* FROM SQLITE_MASTER WHERE type='table';- -"
如今,这将返回 SQLite 数据库中整个表的列表,它的信息存储在SQLITE_MASTER中。 您还能够继续并执行更多的 SQL 查询,来从应用程序提取更多的信息。 为了使用 Drozer 实战漏洞利用,你能够从https://www.mwrinfosecurity.com/products/drozer/community-edition/下载他们的漏洞应用程序
Web 应用程序开放安全项目(OWASP)是涉及安全和漏洞搜索的标准之一。 它还发布了前 10 名漏洞的列表,其中包括在各类平台中最多见和重要的漏洞。
能够在https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks上找到 OWASP 移动版的前 10 个指南。 若是咱们查看 OWASP 移动项目,如下是它涵盖的移动应用程序的 10 个安全问题:
让咱们逐一介绍它们,并快速了解它们在移动应用程序中的关系,以及咱们如何检测它们:
第一个 OWASP 漏洞是服务端弱控制,顾名思义,服务端不以安全的方式将数据从移动应用程序发送到服务端,或者在发送数据时暴露一些敏感的 API。 例如,考虑一个 Android 应用程序发送登陆凭据到服务器进行身份验证,而不验证输入。 攻击者能够以这样的方式修改凭证,以便访问服务器的敏感或未受权区域。 此漏洞可视为移动应用程序和 Web 应用程序中的一个漏洞。
这仅仅意味着,应用相关信息以用户可访问的方式在设备上存储。 许多 Android 应用程序在共享首选项,SQLite(纯文本格式)或外部存储器中,存储与用户相关的私密信息或应用程序信息。 开发人员应该始终记住,即便应用程序在数据文件夹(/data/data/package-name)中存储敏感信息,只要手机已 root,恶意应用程序/攻击者就能够访问它。
许多 Android 开发人员依赖于经过不安全模式的网络来发送数据,例如 HTTP 或没有正确实现 SSL 的形式。 这使得应用程序易受到网络上发生的全部不一样类型的攻击,例如流量拦截,从应用程序向服务器发送数据时操纵参数,以及修改响应来访问应用程序的锁定区域。
当应用程序将数据存储在自己易受攻击的位置时,会出现此漏洞。 这些可能包括剪贴板,URL 缓存,浏览器 Cookie,HTML5DataStorage,统计数据等。 一个例子是用户登陆到他们的银行应用程序,他们的密码已经复制到剪贴板。 如今,即便是恶意应用程序也能够访问用户剪贴板中的数据。
若是 Android 应用程序或通常的移动应用程序在没有适当安全措施的状况下,尝试基于客户端检查来验证或受权用户,则这些应用程序最容易受到攻击。 应该注意的是,一旦手机已 root,大多数客户端保护能够被攻击者绕过。 所以,建议应用程序开发人员使用服务器端身份验证和受权进行适当的检查,一旦验证成功,请使用随机生成的令牌,以便在移动设备上验证用户。
这仅仅表示使用不安全的密码函数来加密数据部分。 这可能包括一些已知存在漏洞的算法,如 MD5,SHA1,RC2,甚至是没有适当的安全措施的定制算法。
这在Android应用程序中是可行的,主要成因是使用 SQLite 进行数据存储。 咱们将在本书的各章中执行注入攻击。
在移动应用程序中,开发人员应始终过滤和验证用户提供的输入或其余相关输入,而且不该该像在应用程序中那样使用它们。 不受信任的输入一般会致使应用程序中的其余安全风险,如客户端注入。
在为移动应用程序执行会话处理时,开发人员须要处理不少因素,例如认证 cookie 的正常过时,安全令牌建立,cookie 生成和轮换,以及没法使后端的会话无效。 必须在 Web 应用程序和 Android 应用程序之间维护正确的安全同步。
这意味着不能正确地防止应用程序被逆向或反编译。 诸如 Apktool 和 dex2jar 之类的工具可用于逆向 Android 应用程序,若是没有遵循正确的开发实践,它会暴露应用程序的各类安全风险。 为了防止经过逆向攻击来分析应用程序,开发人员可使用 ProGuard 和 DashO 等工具。
在本章中,咱们学习了使用各类方法来逆转 Android 应用程序并分析源代码。 咱们还学习了如何修改源代码,而后从新编译应用程序,来绕过某些保护。 此外,咱们还看到了如何使用 Drozer 等工具寻找 Android 应用程序中的漏洞。 你还能够经过http://labs.securitycompass.com/exploit-me/亲自尝试 Exploit-Me 实验室中的各类漏洞,它由 Security Compass 开发。