欢迎光临
我们一直在努力

iOS设备本地授权中的漏洞和威胁

本文我们会介绍在iOS上执行本地授权的潜在威胁。你将了解如何保护你的资源免受未经授权的访问。

复杂的应用程序自然会限制对信息、数据或功能的访问。本文展示了我在iOS应用程序渗透测试中经常观察到的三种模式。它们都是由对设备和客户端检查的过度信任造成的。由于设备不应该被信任,开发人员必须记住,任何客户端检查都可以被绕过。

漏洞1:用户管理——iOS上的跨角色访问控制

如果当前登录的用户具有执行某些操作的适当角色,则第一个常见的易受攻击模式是不正确的验证。攻击场景如下:

1.第一次启动后,用户登录成功;

2.后端返回包含该角色的OAuth令牌;

3.应用程序通过检查签名来验证令牌;

4.如果验证成功,应用程序将用户的角色保存在用户默认值中;

5.基于该角色,应用程序授予对适当视图的访问权限。

当服务器没有验证用户是否应该有权访问该视图时,漏洞就开始出现了。此时用户可以在没有适当角色的情况下发送 HTTP 请求。由于服务器接受了该请求,攻击者执行了一个不应该具有访问权限的操作。

概念证明:

分析的应用程序将角色保存在使用 Passionfruit 观察到的用户默认值中:

1.png

攻击者附加 lldb 并覆盖角色值:

2.png

Passionfruit显示结果:

3.png

漏洞2:锁定功能

另一个糟糕模式的例子是限制功能或访问设备上已有的资源。有一次,在渗透测试期间,我分析了一个限制访问视频的视频流应用程序。如果用户购买了电影的访问权,他们就可以打开它。我研究了验证机制是如何工作的。事实证明,视频已被下载到设备上,然后执行了访问验证。让我们考虑以下 Swift 代码:

4.png

该代码包含一个检查用户是否拥有高级帐户的函数。它相应地返回一个布尔值。绕过该逻辑的最简单方法是附加 lldb 并更改返回函数。

所以,让我们在 hasPremium 函数上设置一个断点。

5.png

继续执行应用程序。

6.png

然后在函数之后直接更改 x0 寄存器的值。

7.png

正如你在下面的屏幕截图中所见,我们能够更改代码执行流程并修改返回值。请注意,我们已经在 Swift 编码的应用程序中做到了这一点。我多次从开发人员那里听说 Swift 不是 Objective-C,不能轻易操作。

iOS 应用内购买的威胁

用户在应用中的购买行为是应用最明显的盈利方式,在你的应用程序中滥用购买可能会直接骚扰你的业务,因此我决定专门针对该问题进行一些介绍。通过购买来实施安全应用程序必须在架构创建过程中开始。如果你不正确地实现应用程序,可能会导致前面小节中描述的错误。你可能会说:“有多少客户是能够附加调试器并修改代码执行流程的安全专家?”。虽然不是很多,但是,在大多数情况下,潜在的攻击者不必是安全专家甚至是开发人员。每个脚本小子都可以安装通用的调整,详情请看这里。另一种情况是“安全专家”将修补你的应用程序并将其放置在越狱者商店中。因此,同样,任何脚本小子都将能够获得包含所有优质内容的应用程序。

在下面的屏幕截图中,你可以看到使用苹果标准 StoreKit API 的交易过程。

8.png

用户点击“购买”按钮,App Store就会弹出提示,用户付费后,苹果就会发送收据给你。现在你可以验证收据是否有效,并授予对购买资源的访问权限。根据苹果的文件,收据包含购买信息、证书和签名。正如你可能猜到的那样,如果你在应用程序中本地进行收据验证,那你就出现潜在威胁了。安全地做到这一点的唯一方法是将访问逻辑移动到你的服务器!所以,算法应该是:

1.用户购买产品;

2.苹果的收据被发送到用户的设备;

3.用户的设备将收据连同会话标识符一起发送到你的服务器(你必须知道谁发送了收据);

4.服务器使用此 API 将收据发送给苹果。

现在你的服务器知道用户是否购买了产品。服务器应决定是否应授予访问权限。请记住,攻击者可能会更改服务器发送给你的应用程序的 HTTP 响应,确保你已经很好地设计了应用程序架构。

本文翻译自:https://www.securing.pl/en/vulnerabilities-and-threats-in-local-authorization-on-ios-devices/如若转载,请注明原文地址

赞(1) 打赏
未经允许不得转载:黑客技术网 » iOS设备本地授权中的漏洞和威胁
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏