本文最后更新于:星期五, 十月 9日 2020, 10:10 上午

快起床!OpenSSH 被爆 RCE 啦(逃

光速上线

2020 年 7 月 18 日,研究人员 Chinmay Pandya 公开了一个 OpenSSH 的高危漏洞,OpenSSH 的 8.3p1 中的 scp 可被注入任意命令,导致任意命令执行,声称绝大多数 Linux 系统都受影响。

看到这个消息的第一时间,我的第一反应是“卧槽”,第二反应是“最近又有的忙了”…大早上早点都没吃,直奔工位开始看漏洞信息,当我看到这个研究人员居然公布了 poc 之后又喊了一句“卧槽”…

冷静下来之后,梳理了一下漏洞生命线:

  • 发现漏洞:2020.07.09
  • 通知厂商:2020.07.09
  • 厂商确认:2020.07.09
  • 获取 CVE:2020.07.16
  • 细节公开:2020.07.18

回想之前的几次经历,通用组件的漏洞在第一时间公开 poc,有以下几种情况:

  1. 漏洞危害低,无所谓:本次 level 是高危,不符
  2. 漏洞发现人不遵守业内的默认规则,第一时间对外公开:有可能?
  3. 厂商忽略漏洞,无所谓:本次 level 是高危,不太像…
  4. 其他黑阔成功复现漏洞:本次公开的人是漏洞发现人本人,排除

仔细再回想一下 scp。scp 大家都熟悉的,它是 secure copy 的缩写,在 Linux 系统下基于 ssh 进行远程文件拷贝。scp 实际上算是 rcp 的加强版。所以这个漏洞起码要突破 2 种防御:

  1. ssh 权限认证
  2. 可能存在的命令过滤

漏洞分析

好了,接着看公布的漏洞信息:

意思就是拷贝文件到远程服务器的时候,文件路径会被拼接到“本地“ scp 命令。这里的 “本地” 是对服务器而言,也就是服务器要执行的命令。
比如执行:

scp SourceFile user@host:directory/TargetFile

服务器会执行:

scp -t directory/TargetFile
`

而当创建 local command 的时候,由于没有对文件名做过滤,于是造成了命令注入。

怪怪的,并没有提怎么绕过权限验证。

看一下 poc:

scp /sourcefile remoteserver:'`touch /tmp/exploit.sh`/targetfile'

啊这…并没有绕过权限认证…

所以这个漏洞需要通过 ssh 认证才能利用,那么利用场景就相当苛刻了。我能想到的只有一个:

被禁止 ssh 登陆,但是能用 scp 的用户,可以通过这个漏洞远程执行命令。

问题是如何配置这样的用户呢?我们知道可以在 /etc/ssh/sshd_config 里面通过 AllowUsers(白名单)或者 DenyUsers(黑名单)来限制某个用户无法通过 ssh 登陆。但是然后 scp 要怎么放行呢?

利用场景

想了半天实在想不到,然后发现作者有给出漏洞的利用场景:

  1. ssh 被 ban 的时候,通过在 authorized_keys 中加 command 的方式,执行 scp。看起来可行?但是感觉有点离谱…
  2. scp 可支持文件夹拷贝,即-r 参数,若攻击者创建一个可命令注入的文件名,欺骗别人去 scp。可以,这个稍微靠谱一点…

第二个没啥好说的,社工完事。第一个我复现了一下:

  1. 首先新建一个用户:useradd -m scp-test
  2. 加密码:passwd scp-test
  3. 禁止 ssh 登陆:DenyUsers scp-test
  4. 重启 sshd:service sshd restart
  5. 新增 key:command="id > /tmp/test" ssh-rsa AAAAB3Nza...

然后就 ssh 上去测试一下。结果发现需要密码,说明无法登陆:Permission denied, please try again.,查看 /tmp/ 下也无 test 文件。

那我们换一种禁用方式试试:usermod scp-test -s /sbin/nologin。测试结果是可以通过认证但是没法登陆:This account is currently not available.,同样 /tmp/ 下也无 test 文件。

上面这个测试的结果说明,若禁止某个用户登录,则无法使用 command="cmd" 执行命令。所以第一点完全就是错误的…或者是我理解错了…

P.S. 这篇文章写完之后,有人正好提了一个 issue:

看来他也有这个疑惑…

可能大家不太懂 command="cmd" 这个的作用是什么?这个英文名应该是 forced command,作用嘛,我的理解就是,如果在公钥之前配置了这个,则会强制在登陆之后执行这个命令/脚本,执行完毕之后就断开连接。然后里面就可以进行命令过滤啊、监控啊等等。若没有配置,就会拉起 shell,比如 bash 或者 zsh,这个应该是看 /etc/shadow 里的配置。

在自己的服务器上通过 forced command 限制登陆的用户能使用的命令,然后还得让 scp 能正常使用,这样的配置是很难配的。因为你根本不知道执行 scp 的时候,传输的是什么数据(除非你去看源码,我这么懒的人…),搭建环境麻烦,很大程度上意味着难以利用。

而作者给出的危害示例也有点凑数…

都能执行任意命令了,谁还 DOS 呢…可能是对能 RCE 真的没信心吧。

最后,来看一下官方给出的回复:

People should use rsync or something else instead if they are concerned.

如果你介意,去用 rsync 吧…

至此,关于这个漏洞的所有信息都过了一遍,我们可以放心大胆地说出:鸡肋!

一些想法

  1. 在对漏洞没有把握的情况下,尽可能按照最坏的打算进行思考,按照最高危害性去想它的利用条件、利用场景、修复方案,不要着急质疑一个漏洞的有效性。
  2. 要去看漏洞的原始信息,带着自己的见解去思考,乙方或者其他人的观点可以参考,但是不要被带节奏。
  3. 回想之前是否有类似的事件出现,以及它们之间是否有联系?
  4. 多积累自己的经验与判断,形成对漏洞的直觉,并根据事实,去不断改进这个感觉,让它越来越准。
  5. 一个漏洞的等级不应该只通过危害去衡量,利用条件也是很重要的一个点。

来呀快活呀


过程记录      Linux CVE Vuln Poc&Exp 应急响应

本博客所有文章除特别声明外,均采用 CC BY-SA 3.0协议 。转载请注明出处!

从算数扩展到 RCE 上一篇
Linux 定时任务详解 下一篇