# Rails Security (上)

Author: 乌云历史资料库 (@wooyun_archive)
Published: 2016-03-09T02:20:00Z
Canonical: https://wepostx.com/topics/116

> 乌云历史资料归档
>
> **原始作者：** Lobsiinvok
> **原始编号：** superkieran-wooyundrops:1077
> **原始发布时间：** 2016-03-09 10:20
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**

---

Author: Lobsiinvok

# 0x00 前言

Rails是Ruby广泛应用方式之一，在Rails平台上设计出一套独特的MVC开发架构，采取模型（Model）、外观（View）、控制器（Controller）分离的开发方式，不但减少了开发中的问题，更简化了许多繁复的动作。
此篇讲稿分为上下部份，因为最近在开发Rails，需要针对安全问题做把关，便借此机会针对历史上Rails发生过的安全问题进行归纳与整理。
这篇讲稿承蒙安全领域研究上的先进，在自行吸收转​​换后，如有笔误或理解错误的地方还望各位见谅并纠正我，感谢 :D

快速跳转

- Mass assignment

- Unsafe Query Generation

- Content_tag

- YAML.load

- Dynamic Render Path

- Reference

# 0x01 Mass assignment

- 让Rails developers爱上的毒药(toxic)

- ActiveRecord在新增物件时可传入Hash直接设定多项属性

- 若没有限制可传入的参数会造成物件属性可被任意修改

![原文图片](/media/2016/06/d2ed8f7f8c9cbb60f775bb23c4cb2964)

- 透过新增/修改送出的属性，可以变更任意物件属性

- [Case](https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation)

- Rails 3.2.3后，config.active_record.whitelist_attributes = true

![原文图片](/media/2016/06/1f4a2f233d19ca0594f72a3a56a011db)

- Rails 4后，Rails Core内建strong_parameters

- 更适当地将处理的过程锁定在Controller layer

- 更有弹性地针对属性作过滤

# 0x02 Unsafe Query Generation

- Rake在处理params时，有时候会产生Unsafe的query

![原文图片](/media/2016/06/188c03b760be0ed4963ffa4e08ca54b2)

- 透过伪造params[:token]成[], [nil], [nil, nil, ...]或['foo', nil]，都能够通过.nil?的检查，使得SQL语句被安插IS NULL or IN ('foo', NULL)造成非预期的结果

- 在Rails 3.2.8增加deep_munge方法来消除掉Hash里的nil

- commit中可看到类似的检查

![原文图片](/media/2016/06/0d757f3ee94c0a7c7b4031534e50fc41)

### Code for Testing

![原文图片](/media/2016/06/40ccbe91451f39185d2bce937bf205be)

Rails 3.1.0: 成功绕过nil?的检查

![原文图片](/media/2016/06/2c25564bdcef36ec0d84f4fc4b5a9e0c)

Rails 4.2.5: 被拦截，直接替换成nil

![原文图片](/media/2016/06/5846f718ae5ec8afed0cefd96438c016)

# 0x03 Content_tag

Rails提供content_tag方便产生HTML

- 尽管方便，产生出的HTML是safe的吗？很显然的并不是！

- Ref: [brakeman](https://github.com/presidentbeef/brakeman/blob/master/lib/brakeman/checks/check_content_tag.rb)

![原文图片](/media/2016/06/066fc5d9fdf0507c01fd2a008db35005)

- In latest rails 4.2.5, attr still can be injected with any html data.

![原文图片](/media/2016/06/41d2947540fb5d8d823e4f70ebfbc218)

- 尽管attr values​​有escape，但跟button_to一起作用时却……

![原文图片](/media/2016/06/d69e17c3228a9f33ba207a663114016b)

### Why？

- Content_tag回传html_safe的字串，代表此字串在后续输出时不再做escape

- 建立在attacker无法构建html_safe型的字串(等价于raw)

- 丢给button_to时因为不再做escape导致XSS问题

# 0x04 YAML.load

### 难得一见的RCE漏洞(CVE-2013-0156)

- 主因出在YAML

- CVE-2013-0156发生在可透过YAML解析时指定tag的方式覆盖已经载入的instance

- 在rails3后已从DEFAULT_PARSERS移除

![原文图片](/media/2016/06/1a8567a2f18433d8fb08321db3f1b199)

- 此次问题发生在XML解析

- 在解析时会经过Hash.from_xml(request.raw_post)，底处是到typecast_xml_value进行xml的处理，[这篇](http://drops.wooyun.org/papers/61)前辈的文章解释得很清楚，因为typecast_xml_value里针对xml node type可以进行YAML的解析调用(允许的type定义在ActiveSupport::XmlMini::PARSING)，因此造成RCE问题

- 透过patch可以更明显看到修补后的不同

![原文图片](/media/2016/06/1d6210f0bc5b16042a3b59e08fc5e656)

![原文图片](/media/2016/06/23b155779a767ee922c0150b806b8ef4)

Ref: [Rails 3.2](https://github.com/rails/rails/commit/43109ecb986470ef023a7e91beb9812718f000fe)

### Proof
Rails 3.1: 成功执行指令

![原文图片](/media/2016/06/634116d79a280de5971ed7ec51d4e2a3)

### 难得一见的RCE漏洞(CVE-2013-0333)

- CVE-2013-0333问题一样发生在YAML.load

- 在rails 3.0.19(含)前，rails3.0.x的JSON Parser竟然是使用YAML作为Backend

- 问题发生在YAML backend中的convert_json_to_yaml

- [这篇](http://ronin-ruby.github.io/blog/2013/01/28/new-rails-poc.html)讲得很详细

- Patch for CVE-2013-0333

![原文图片](/media/2016/06/34b903e0d88c94fc04323808b4bb427b)

[Rails 3.0.20](https://github.com/rails/rails/commit/5375dce1ac29141821a48fdc683e6b797f61f113)

# 0x05 Dynamic Render Path

Render是处理request的一连串过程

- 除了Insecure Direct Object Reference的安全问题，[DEVCORE](http://devco.re/blog/2015/07/24/the-vulnerability-of-dynamic-render-paths-in-rails/)也在进行渗透测试时发现潜在的RCE问题

- rails目前最新版本4.2.5预设也是用ERB去做样板处理，但在rails5开发过程中已经加入此次[commit](https://github.com/rails/rails/commit/4be859f0fdf7b3059a28d03c279f03f5938efc80)

- 动态样板间接变成LFI问题，搭配上面所述的default_template_handler为ERB，只要找到有调用ruby code的样板或是可自行写入的档案，就能够造成RCE

![原文图片](/media/2016/06/98ac1b099dbbddf8050ed2b3e9aab11b)

![原文图片](/media/2016/06/fde1871d802b0627d772fdcbf605b1ab)

- 真实环境下发生的问题可以前往[DEVCORE](http://devco.re/blog/2015/07/24/the-vulnerability-of-dynamic-render-paths-in-rails/)查看

- 如果有类似开发环境应立即处理，default_template_handler要到rails5才转换成RAW

- 改以白名单的方式限制template名称或是根据commit的内容手动Patch

# 0x06 Reference

- [The Ruby/GitHub hack: translated](http://blog.erratasec.com/2012/03/rubygithub-hack-translated.html#.VnfEIxV97IU)

- [How Does Rack Parse Query Params? With Parse_nested_query](http://codefol.io/posts/How-Does-Rack-Parse-Query-Params-With-parse-nested-query)

- [Cross Site Scripting (Content Tag)](http://brakemanscanner.org/docs/warning_types/content_tag/)

- [Bad coding style can lead to XSS in Ruby on Rails](https://en.internetwache.org/bad-coding-style-can-lead-to-xss-in-ruby-on-rails-14-10-2014/)

- [分析下难得一见的ROR的RCE（CVE－2013－0156）](http://drops.wooyun.org/papers/61)

- [Rails PoC exploit for CVE-2013-0333](http://ronin-ruby.github.io/blog/2013/01/28/new-rails-poc.html)

- [Dynamic Render Path](http://brakemanscanner.org/docs/warning_types/dynamic_render_paths/)

- [Rails 动态样板路径的风险](http://devco.re/blog/2015/07/24/the-vulnerability-of-dynamic-render-paths-in-rails/)

## Replies