• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

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


Recommended Posts

本文将介绍在iOS上执行本地授权的潜在威胁。您将学习如何保护您的资源免受未经授权的访问。

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

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

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

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

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

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

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

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

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

概念证明:

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

1.png

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

2.png

西番莲果显示结果:

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 响应,确保你已经很好地设计了应用程序架构。

Link to comment
Share on other sites