1. 极安网首页
  2. 网络安全书籍

WebHacking101中文版第五章:应用逻辑漏洞

应用逻辑漏洞不同于其他我们讨论过的类型。虽然 HTML 注入、HTML 参数污染和 XSS 都涉及到提交一些类型的潜在恶意输入,应用落地及漏洞实际上涉及到操纵场景和利用 Web APP 代码中的 Bug。

这一类型攻击的一个值得注意的例子是 Egor Homakov 对 Github 的渗透,Github 使用 RoR 编写。如果你不熟悉 Rails,他是一个非常流行的 Web 框架,在开发 Web 站点时,它可以处理很多繁杂的东西。

在 2012 年 3 月,Egor 通知了 Rails 社区,通常,Rails 会接受所有提交给它的参数,并使用这些值来更新数据库记录(取决于开发者的实现。Rails 核心开发者的想法是,使用 Rails 的 Web 开发者应该负责填补它们的安全间隙,并定义那个值能够由用户提交来更新记录。这个行为已经在社区内人人皆知了,但是 Github 上的线程展示了很少的人能够鉴别出来它带来的风险(https://github.com/rails/rails/issues/5228)。

当核心开发者不同意他的时候,Egor 继续利用 Github 上的认证漏洞,通过猜测和提交参数值,它包含创建日期(如果你熟悉 Rails 并且知道多数数据库记录包含创建和更新日期列,它就不太困难)。因此,它在 Github 上传了一个票据,年份是未来的某个日期。它也设法更新 SHH 访问密钥,这可以使他访问 Github 官方的代码仓库。

之前提到了,这个渗透通过 Github 后端代码实现,它并没有合理验证 Egor 所做的事情,这在随后可用于更新数据库记录。这里,Egor 发现了叫做大量赋值漏洞的东西。

应用逻辑漏洞,即发现前面讨论的这种类型的攻击,更加有技巧性,因为它们依赖代码判定的创造性思维,并且并不仅仅是提交潜在的恶意代码,开发者没有转义它。(不要尝试在这里简化其它类型的漏洞,一些 XSS 攻击也很复杂!)

使用 Github 的例子,Egor 知道了系统基于 Rails 以及 Rails 如何处理用户输入。在其他例子中,它涉及直接编程调用 API 来测试应用的行为,就像 Shopify 的管理员权限绕过那样。或者,它涉及重复使用来自认证 API 调用的返回值,来进行后续的API 调用,本不应该允许你这么做。

示例

1. Shopify 管理员权限绕过

难度:低

URL:shop.myshopify.com/admin/mobile_devices.json

报告链接:https://hackerone.com/reports/100938

报告日期:2015.11.22

奖金:$500

描述:

Shopify 是一个巨大并健壮的平台,它包含 Web UI 以及受支持的 API。这个例子中,API 不验证一些权限,而 Web UI 明显会这么做。因此,商店的管理员,它们不被允许接受邮件提醒,可以通过操作 API 终端来绕过这个安全设置,在它们的 Apple 设备中收到提醒。

根据报告,黑客只需要:

  • 使用完全访问权限的账号登录 Shopify 移动应用
  • 拦截POST /admin/mobile_devices.json的请求
  • 移除该账号的所有权限
  • 移除添加的移动端提醒
  • 重放POST /admin/mobile_devices.json的请求

这样做之后,用户可以接收到所有商店处的订单的移动端提醒,因此忽略了商店配置的安全设置。

重要结论

这里有两个重要结论。首先,并不是所有东西都涉及代码注入。始终记住使用代码并观察向站点传递了什么信息,并玩玩它看看什么会发生。这里,所有发生的事情是,移除 POST 参数来绕过安全检查。其次,再说一遍,不是所有攻击都基于 HTML 页面。API 终端始终是一个潜在的漏洞区域,所以确保你考虑并测试了它们。

2. 星巴克竞态条件

难度:中

URL:Starbucks.com

报告链接:http://sakurity.com/blog/2015/05/21/starbucks.html

报告日期:2015.5.21

奖金:无

描述:

如果你不熟悉竞态条件,本质上它是两个潜在的进程彼此竞争来完成任务,基于一个厨师场景,它在请求被执行期间变得无效。换句话说,这是一个场景,其中你拥有两个进程,它们本应该是互斥的,不应该同时完成,但是因为它们几乎同时执行,它们被允许这么做了。

这里是一个例子:

  1. 你在手机上登录进了你的银行站点,并请求将 $500 从你的一个仅仅拥有 $500 的账户转到另一个账户。
  2. 这个请求花费很长时间(但是仍然处理),所以你在你的笔记本上登录,并且再次执行了相同请求。
  3. 笔记本的请求几乎立即完成了,但是你的手机也是这样。
  4. 你刷新了银行账户,并发现你的账户里有 $1000。这意味着请求执行了两次,这本不应被允许,因为你一开始只拥有 $500。

虽然这个很基础,理念都是一样的,一些条件存在于请求开始,在完成时,并不存在了。

所以,回到这个例子,Egor 测试了从一个星巴克的卡中转账,并且发现他成功触发了竞态条件。请求使用 CURL 程序几乎同时创建。

重要结论

竞态条件 是个有趣的攻击向量,它有时存在于应用处理一些类型的余额的地方,例如金额、积分,以及其他。发现这些漏洞并不总是发生在第一次尝试的时候,并且可能需要执行多次重复同时的请求。这里,Egor 在成功之前执行了 6 次请求。但是要记住在测试它的时候,要注意流量负荷,避免使用连续的测试请求危害到站点。

3. Binary.com 权限提升

难度:低

URL:binary.com

报告链接:https://hackerone.com/reports/98247

报告日期:2015.11.14

奖金:$300

描述:

这真是一个直接的漏洞,不需要过多解析。

本质上,在这个场景下,用户能够登录任何账户,代表被黑的用户账户,并查看敏感信息,或执行操作,并且一切只需要知道用户的 UID。

在你渗透之前,如果你登录了Binary.com/cashier,并查看了页面的 HTML,你会注意到有个<iframe>标签包含 PIN 参数。这个参数实际上就是你的账户 ID。

下面,如果你编辑了 HTML,并且插入了另一个 PIN,站点就会自动在新账户上执行操作,而不验证密码或者任何其他凭据。换句话说,站点会将你看做你所提供的账户的拥有者。

同样,所需的一切就是知道某人的账户号码。你甚至可以在出现在iframe中的时间修改为PAYOUT,来触发另一个账户的付款操作。但是,Bianry.com表示,所有取款都需要手动人工复查,但是这并不是说,这就一定会被发现。

重要结论

如果你寻找基于漏洞的认证,要留意凭据传递给站点的地方。虽然这个漏洞通过查看页面源码来实现,你也可以在使用代理拦截器的时候,留意传递的信息。

如果你的确发现了被传递的一些类型的凭据,但他们看起来没有加密时,要注意了,并且尝试玩玩它们。这里,PIN 是CRXXXXXX而密码是0e552ae717a1d08cb134f132。显然 PIN 没有解密,但是密码加密了。未加密的值是一个非常好的地方,你可以从这里下手。

原创文章,作者: Admin ,转载请注明出处:https://secvery.com/3325.html