使用DAST在Android应用API中发现泄露的AWS凭证

本文详细介绍了如何利用移动安全框架(MobSF)的动态应用安全测试(DAST)功能,在Android应用的API流量中发现泄露的AWS访问密钥和密钥,并成功验证了对AWS资源的广泛访问权限。

发现隐藏威胁:我如何利用DAST在Android应用API中发现泄露的AWS凭证

大家好,欢迎回来!我有一段时间没写博客了,很高兴能与漏洞赏金社区分享这个最近的发现。在我最近的漏洞赏金狩猎冒险中,我发现了一个涉及Android应用API中泄露AWS凭证的关键漏洞。此漏洞有可能导致对AWS基础设施的接管。让我们深入探讨一下我如何使用动态应用安全测试(DAST)技术揭露这个隐藏的威胁。

理解DAST(动态应用安全测试)

什么是DAST? 动态应用安全测试是一种通过分析运行中的应用程序来测试其安全性的方法。与静态分析(在不执行代码的情况下检查代码)不同,DAST会与应用程序实时交互,以识别可能被攻击者利用的漏洞。

DAST的优势:

  • 真实世界模拟: 在应用程序运行时进行测试,提供其在实际攻击场景下行为方式的见解。
  • 全面覆盖: 可以识别那些仅通过静态分析可能不明显的漏洞。
  • 持续测试: 可以集成到CI/CD流水线中,实现持续的安全保障。

静态分析与动态分析的区别:

  • 静态分析: 检查应用程序的源代码、字节码或二进制代码。它有助于在开发过程早期发现问题。
  • 动态分析: 在应用程序运行状态下进行测试,更真实地反映应用程序在攻击下的表现。

工具包: 为了发现此漏洞,我使用的工具是移动安全框架。这是一个用于移动应用程序的自动化安全测试框架。它支持Android和iOS平台,并提供全面的静态和动态分析功能。

静态分析: 在之前的博客文章《通过Android应用静态安全分析入侵公司短信API服务提供商 | Bug Bounty POC》中,我们深入探讨了Android应用的静态分析,包括检查源代码是否存在漏洞、识别不安全的编码实践。

聚焦动态分析: 对于这篇博客文章,我们将重点介绍MobSF的动态分析功能。

设置测试环境

在深入探讨发现的漏洞之前,让我们先谈谈设置和用法。

准备测试环境: 如果您在安装MobSF或设置动态分析设备时遇到任何问题,请考虑阅读官方文档 https://mobsf.github.io/docs/#/dynamic_analyzer,大部分关于设置测试环境的内容都取自那里。

1. 设置MobSF: 下载最新的MobSF Docker镜像。

1
docker pull opensecurity/mobile-security-framework-mobsf:latest

2. 设置Android模拟器: 设置这些设备以运行应用程序。 我通常使用Android Studio模拟器,所以在这里分享步骤…

  • 创建一个不包含Google Play商店的Android虚拟设备。
  • 选择一个镜像。MobSF支持arm、arm64、x86和x86_64架构,Android版本为5.0至9.0,最高到API 28。
  • 不要从Android Studio IDE/AVD管理器UI启动AVD,而是使用模拟器命令从命令行运行AVD。
  • 将您的Android SDK模拟器目录添加到PATH环境变量。
    • 示例位置:
      • Mac - /Users/<user>/Library/Android/sdk/emulator
      • Linux - /home/<user>/Android/Sdk/emulator
      • Windows - C:\Users\<user>\AppData\Local\Android\Sdk\emulator
  • AVD命令行
    1
    2
    3
    4
    5
    
    $ emulator -list-avds
    Pixel_2_API_29
    Pixel_3_API_28
    Pixel_XL_API_24
    Pixel_XL_API_25
    
  • 在启动MobSF之前,使用模拟器命令行选项运行一个AVD。
    1
    
    $ emulator -avd Pixel_3_API_28 -writable-system -no-snapshot
    
  • 识别模拟器序列号。在此示例中,标识符是emulator-5554
  • 在运行MobSF Docker镜像时,将MOBSF_ANALYZER_IDENTIFIER设置为emulator-5554
  • 运行MobSF:
    1
    
    docker run -it --rm -p 8000:8000 -p 1337:1337 -e MOBSF_ANALYZER_IDENTIFIER=emulator-5554 opensecurity/mobile-security-framework-mobsf:latest
    

测试过程: MobSF实际上非常易于使用。您可以遵循一些在线教程和课程来学习如何使用MobSF。

上传与分析 基本上就是拖放文件进行扫描和分析。完成后,它会将您重定向到该应用程序的静态分析页面。 在该页面上,您可以点击“Start Dynamic Analysis”。 MobSF将在此处启动动态分析模块,界面如下所示。 界面导航非常简单,对于这篇博客,我们将专注于动态测试组件的Activity测试模块。

发现漏洞:

在我使用MobSF进行动态测试时,我专注于应用程序运行时背后发出了哪些请求。为此,我主要使用了“Activity Tester”选项。它的作用是逐一启动所有Activity,并记录发生的所有事情。 一旦Activity测试完成,我简单地生成了动态分析报告。 使用动态分析报告页面上的“HTTP(S) Traffic”按钮,我们可以看到Activity启动时背后发出的所有请求。 这会打开web_traffic.txt文件。

搜索泄漏信息 当我通常遵循此流程时,我会在Web流量文件中查找某些关键字,例如:

1
2
3
4
5
6
7
8
Secret
api
key
token
Authorization
AWS
AWSAccessID
AWSSecretKey

我在这里也做了同样的事情,这就是我的发现: 因此,当启动特定Activity时,应用程序正在向api.target.com/services.svc发出请求,从而在该POST请求的响应中泄露了AWSAccessIDAWSSecretKey

为了验证这些泄露的凭证,我使用我的awscli配置了这些凭证,并运行了一些基本命令来验证这些密钥所拥有的访问权限。 运行命令aws s3 ls显示我可以访问超过65个AWS S3存储桶。 我们甚至可以从可能导致子域名接管场景的存储桶上传和删除文件。 运行命令aws ec2 describe-instances显示了我有权访问的EC2实例。

影响分析: 为了进一步升级POC,我运行了一个脚本,通过查询IAM服务来枚举您的权限,如果不可行,我们可以暴力破解权限。我尝试使用CLI运行所有AWS服务的所有list*describe*get*命令,并标记出哪些命令有效。通过这种方式,我发现我对那个AWS账户拥有重要的访问权限。

1
我对该AWS账户拥有的访问权限

此时,我有足够的证据和影响来报告此漏洞,于是我提交了报告。

总结

就是这样。我们已经探讨了如何利用DAST来发现移动应用API中的关键漏洞,例如泄露的AWS凭证。通过利用MobSF等工具。希望这篇博客有所帮助,您能学到一些东西。如果您有任何问题或建议,请随时评论。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计