CVE-2020-15778：鸡肋的高危

快起床！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. 一个漏洞的等级不应该只通过危害去衡量，利用条件也是很重要的一个点。

来呀快活呀