😇
牛牛的安全 Odin
  • 个人介绍
  • 数据安全
  • 工控安全
    • 工控概念
  • 车联网安全合规
    • R155
    • CSMS\VTA
    • GDPR认证
  • 车联网安全
    • 漏洞订阅
    • 汽车攻击时间轴
    • 汽车信息安全研究
      • 车厂安全需求 Custom Requirement
      • 安全威胁
      • 参考文章
      • Who’s Behind the Wheel?
      • 安全研究基础
      • 智能网联汽车安全渗透指标
      • 智能网联汽车软件安全测试关键技术研究
      • 基于硬件在环的整车控制器功能安全测试技术研究
      • 智能网联汽车信息安全解决方案
      • 自动驾驶汽车的安全性-识别挑战
    • ECU逆向案例
      • 特斯拉攻击链
      • 汽车动力系统ECU固件逆向工程初探
  • 物联网安全
    • IoT 技术和协议
    • 智能设备常规测试思路总结
    • 各种调试接口(SWD、JTAG、Jlink、Ulink、STlink)的区别
    • QEMU 系统仿真
      • 如何“用 QEMU 模拟它”
      • 处理加密的路由器固件
    • 自动分析Automated Approach
    • IOT渗透测试(一)
    • 物联网安全目录
  • 固件分析案例
    • 智能门锁、手环
      • MCU固件反汇编
      • 云丁鹿客门锁中bootloader和FreeRTOS的分析
      • 云丁鹿客门锁BLE通信的分析(下)
      • 云丁鹿客门锁BLE通信的分析(中)
      • 云丁鹿客门锁BLE通信的分析(上)
      • 华为智联旗下小豚AI摄像头的完整分析(下)
      • 华为智联旗下小豚AI摄像头的完整分析(上)
      • 海康萤石智能门锁的网关分析(4)
      • 海康萤石智能门锁的网关分析(3)
      • 海康萤石智能门锁的网关分析(2)
      • 海康萤石智能门锁的网关分析(1)
      • idapython编写和调试
      • 果加智能门锁的全面分析(下)
      • 果加智能门锁的全面分析(中)
      • 果加智能门锁的全面分析(上)
      • BLE智能手环
      • 耶鲁智能门锁的简单测试(下)
      • 耶鲁智能门锁的简单测试(上)
      • 耶鲁门锁漏洞
      • 对一款BLE灯泡的分析
      • BLE协议栈与Android BLE接口简介
    • 在IoT设备中查找端口对应进程的四种方法
    • 路由器命令执行
    • 对基于Philips TriMedia CPU的网络摄像机进行逆向工程
    • 从Microsoft Band以及 Hello Sense 设备中提取自己的历史数据
    • CVE-2021-22909- 深入研究 UBIQUITI 固件更新错误
    • 复现|摄像头固件重打包
    • Dlink_DWR-932B路由器固件分析
    • 针对小米九号平衡车的无接触式攻击
    • 记一次智能印章设备的漏洞挖掘
  • APP 逆向
    • Go二进制文件逆向分析从基础到进阶——综述
    • Switch APP逆向分析
  • 传统静态代码分析
    • 静态分析案例
      • ELF恶意软件的静态分析原理和方法(上)
      • ELF恶意软件的静态分析原理和方法(下)
    • 静态代码分析工具清单
    • 企业级静态代码分析工具清单
  • 应用安全测试
    • DAST、SAST、IAST
    • IAST 工具初探
  • 芯片架构
    • ARM指令集概念
    • ARM指令集
    • 冯·诺伊曼结构
    • 指令集
    • 处理器架构、指令集和汇编语言,三者有何关系?
  • 病毒分析
    • 熊猫烧香
  • 编程知识
    • REST API 教程
  • 流量分析工具
    • 卡巴斯基开源的智能手机流量劫持工具
    • 利用 Burp Suite 劫持 Android App 的流量(二)
    • 利用 Burp Suite 劫持 Android App 的流量(一)
  • 区块链安全
    • 安全多方计算
    • Chainalysis 团队从区块链的角度分析发现 2020 年最大的 4 起勒索软件攻击实现存在关联
  • 攻击案例
    • 特斯拉Powerwall网关可能受到黑客攻击
  • 移动应用
    • Mac上使用Charles抓包
    • 手机抓包工具汇总
    • APP渗透测试流程和技巧大全
    • 加壳和脱壳
    • 浅谈 Android Dex 文件
    • 移动应用漏洞分析样例分享
    • 移动应用常见漏洞分析
    • 移动应用漏洞分析工具介绍
    • 渗透测试流程详解 及 移动APP安全测试要点
    • Frida Android hook
  • 安全设计
    • 【软件安全设计】安全开发生命周期(SDL)
Powered by GitBook
On this page
  1. 流量分析工具

利用 Burp Suite 劫持 Android App 的流量(一)

Previous利用 Burp Suite 劫持 Android App 的流量(二)Next区块链安全

Last updated 3 years ago

在Android应用程序进行安全评估时,通常会进行两方面的评估:移动前端和后端API。为了检查API的安全性,你将需要大量的文档,例如Swagger或Postman文件,或者可以让移动应用程序为你生成所有流量,并简单地通过代理(MitM攻击)拦截和修改流量。

有时候设置代理确实很容易,在本文中,我将使用PortSwigger的Burp 套件代理,但是相同的步骤当然可以用于任何HTTP代理。在所有示例中,代理将托管在端口8080上的192.168.1.100。检查从最基本的开始,越到后来越复杂。

设置设备

首先,我们需要确保设备上的所有设置都是正确的。无论你尝试使用MitM的应用程序如何,这些步骤均适用。

是否在设备上配置了代理?

很明显,第一步是在设备上配置代理。使用者介面会因你的Android版本而有所不同,但找起来并不难。

完整性检查

进入“设置”>“连接”>“Wi-Fi”,选择你所使用Wi-Fi网络,点击“高级”>“代理”>“手动”,然后输入你的代理详细信息:

代理主机名:192.168.1.100;

代理端口:8080;

Burp是否监听所有接口?

默认情况下,Burp只监听本地接口(127.0.0.1),但是由于我们想要从不同的设备连接,Burp需要监听已经加入Wi-Fi网络的特定接口。你可以监听所有接口,也可以监听特定接口(如果你知道需要哪个接口)。作为完整性检查,我通常使用“监听所有接口”。请注意,Burp有一个API,它可以允许其他使用相同Wi-Fi网络的人查询你的代理并从中检索信息。

完整性检查

在你的主机上导航到http://192.168.1.100:8080,应该会出现欢迎界面。

解决方案

在Burp中,进入“代理”>“选项”>在“代理监听器”窗口中单击你的代理,然后在“绑定到地址”配置上选中“所有接口”。

你的设备可以连接到代理吗?

有些网络具有主机/客户端隔离,不允许客户端相互通信。在这种情况下,你的设备将不能连接到代理,因为路由器不允许。

完整性检查

在该设备上打开浏览器,导航到http://192.168.1.100:8080。你应该会看到Burp的欢迎屏幕。如果你在前面的检查中已经配置了代理,你还应该能够导航到http://burp。

解决方案

这里有一些选择:

1.设置一个禁用主机/客户端隔离的自定义无线网络;

2.将代理托管在可访问的设备上,例如AWS ec2实例;

3.执行一个ARP欺骗攻击,以欺骗移动设备,使其相信你是路由器;

4.使用adb反向代理通过USB的流量:

4.1将设备上的代理配置为在端口8080上转到127.0.0.1;

4.2通过USB连接设备,并确保adb设备显示你的设备;

4.3执行adb reverse tcp:8080 tcp:8080,它将

4.4现在,你应该能够浏览到http://127.0.0.1:8080并看到Burp的欢迎屏幕;

你可以代理HTTP流量吗?

HTTP流量的步骤通常比HTTPS流量容易得多,因此此处的快速状态检查可确保你的代理正确设置且可被设备访问。

完整性检查

导航到http://neverssl.com并确保你在Burp中看到了该请求。 Neverssl.com是一个不使用HSTS的网站,并且永远不会将你发送到HTTPS版本,从而使其成为测试纯文本流量的理想选择。

注: HTTP Strict Transport Security (通常简称为HSTS)是一个安全功能,它告诉浏览器只能通过HTTPS访问当前资源,而不是HTTP。

解决方案

1.把以前的检查再检查一遍,可能有些地方不对;

2.Burp的拦截已启用,请求正在等待你的批准;

设备上是否已安装Burp证书?

为了拦截HTTPS流量,需要在设备上安装代理的证书。

完整性检查

进入设置>安全性>受信任的凭据>用户,并确保列出了你的证书。另外,你可以尝试拦截来自设备浏览器的HTTPS流量。

解决方案

许多地方都有记录,但是这里有一个简短的摘要:

1.在浏览器中导航到http://burp;

2.点击右上方的“CA证书”,将开始下载;

3.使用adb或文件管理器将扩展名从der更改为crt:

adb shell mv /sdcard/Download/cacert.der /sdcard/Download/cacert.crt;

4.使用文件管理器导航到该文件并打开该文件以启动安装;

你的Burp证书是否已安装为根证书?

Android最新版本的应用程序默认不相信用户证书,至于具体原因请点此https://blog.nviso.eu/2017/12/22/intercepting-https-traffic-from-apps-on-android-7-using-magisk-burp/。或者,你可以重新打包应用程序,将相关的控件添加到network_security_policy.xml文件中,但是将根CA保存在系统CA存储中可以避免其他步骤(如第三方框架)的麻烦,因此这是我的首选方法。

完整性检查

进入设置>安全性>受信任的凭据>系统,并确保列出了你的证书。

解决方案

为了将你的证书列为根证书,你的设备需要使用Magisk作为根目录:

1.正常安装客户端证书(请参阅以前的检查);

2.安装MagiskTrustUser模块;

3.重新启动设备以启用模块;

4.再次重启以触发文件复制;

或者,你可以:

1.确保证书的格式正确,然后将其复制/粘贴到/ system / etc / security / cacerts目录中。但是,要使其正常工作,你的/ system分区需要是可写的。一些根方法允许这样做,但它非常复杂,而Magisk更好,获得正确格式的证书也有点复杂。

2.修改networkSecurityConfig,以将用户证书包括为信任锚(请参见下文)。不过,将你的证书作为系统证书会更好,所以我很少采用这种方法。

你的Burp证书有适当的有效期吗?

Google以及Android正在积极缩短leaf证书的最长接受期限,如果你的leaf证书的有效日期过长,Android / Chrome将不会接受它。

完整性检查

使用浏览器连接到你的代理,并调查根CA和leaf证书的证书有效期。如果短于1年,那就好了。如果证书的有效期较长,我喜欢安全一点,创建一个新的CA,你也可以使用Android上最新版本的Chrome浏览器来验证证书的有效期。如果有错误,Chrome将显示以下错误:ERR_CERT_VALIDITY_TOO_LONG

解决方案

这里有两种可能的解决方案:

1.确保你安装了最新版本的Burp,这会减少生成的leaf证书的有效期;

2.创建自己的根CA,它的有效期仅为365天。这个根CA生成的证书也将小于365天。这是我的首选选项,因为证书可以与团队成员共享,并且可以安装在约定期间使用的所有设备上。

设置应用程序

现在设备可以使用了,现在该看看应用程序的详细信息了。

应用程序代理可以识别吗?

许多应用程序简单地忽略了系统的代理设置,使用标准库的应用程序通常会使用系统代理设置,但是依赖于解释语言的应用程序(例如Xamarin和Unity)或本地编译的应用程序(例如Flutter)通常要求开发人员将代理支持明确地编程到应用程序中。

完整性检查

在运行应用程序时,你应该在Burp的Proxy选项卡中看到你的HTTPS数据,或者应该在仪表板面板上Burp的事件日志中看到HTTPS连接错误。由于整个设备都是代理的,你会看到许多来自使用SSL锁定的应用程序的被阻止的请求(例如谷歌Play),所以看看你是否能找到一个与应用程序相关的域。如果你没有看到任何相关的失败连接, 则说明你的应用程序很可能没有代理。

作为额外的完整性检查,你可以查看应用程序是否使用了第三方框架。如果应用程序是用Flutter编写的,它肯定没有代理意识,而如果它是用Xamarin或Unity编写的,它很有可能会忽略系统的代理设置。

用apktool反编译:apktool d myapp.apk;

通过已知的位置:

Flutter: myapp/lib/arm64-v8a/libflutter.so

Xamarin: myapp/unknown/assemblies/Mono.Android.dll

Unity: myapp/lib/arm64-v8a/libunity.so

解决方案

有几件事可以尝试:

使用ProxyDroid(仅限root用户),尽管它是一个旧应用,但仍然可以很好地运行。 ProxyDroid使用iptables来强制将流量重定向到你的代理;

通过第二个无线接口设置自定义热点,并使用iptables自己重定向流量。你可以在mitmproxy文档中找到设置,它是另一个有用的HTTP代理,同样的设置也适用于Burp。

在这两种情况下,你都已从“代理意识”设置转换为“透明代理”设置。你必须做两件事:

1.在设备上禁用代理。如果你不这样做,那么Burp将同时收到代理请求和透明请求,二者互不兼容;

2.配置Burp以支持透明代理通过代理>选项>活动代理>编辑>请求处理>支持不可见代理;

再次执行完整性检查,现在希望能在Burp的事件日志中看到SSL错误。

在下一篇文章中,我还会详细介绍“应用程序是否使用了自定义端口?”,“应用程序是否使用SSL锁定?”等问题。