解决CVE漏洞黑科技

漏洞背景

某客户使用了我们的产品，用绿盟扫描出一堆CVE漏洞，反馈到这边来让我们解决掉。别的也还好，一通升级到最新稳定版本，完事一扫描全给解决了，唯独剩下openssh用户枚举漏洞，解决起来着实麻烦。

实际上呢，用户的产品属于内网产品，根本没有任何暴露在公网的可能性，并且机器直接面向的是运维用户，漏洞风险其实是可以忽略不计的（运维总不可能一天到晚想着攻击自己负责运维的服务器），但是客户属于那种很严肃的，死活就是要解决，那行吧，咱干。

客户的机器不能链接外网，也没有准备本地yum源，因此我得将依赖包下载好，然后用客户的堡垒机跳过去。当我下了一大堆安装包好不容易输了5次密码登录上服务器之后，我傻眼了。服务器上没有安装gcc！这都2020年了，服务器竟然没有装gcc！我忍，我去安装下gcc吧，可是当我将gcc源码上传时我又傻眼了，这特喵的简直是无底洞，依赖还缺依赖，这整个操作系统基本相当于啥都没有，这要是靠人力一个一个依赖去安装，猴年马月是个头。

现在我只能尝试另一种思路，那就是模拟一个生产环境，在能连外网的环境中使用yum、rpm等包管理工具自动将所有依赖下载下来，最后再上传到服务器直接装rpm包。可是，事情就没那么顺利。首先，要将客户使用的操作系统镜像给拉出来，这就花费了1天时间申请，通过后又输了5次密码，链接堡垒机，授权一大堆，然后完了终于将镜像拉出来了。镜像要传给我，使用某云盘，200k的速度，下了整整6个小时。

就在我要开干时，我们老大终于看不下去了，时间不能浪费在这点鸡毛蒜皮的小问题上，咱们得用些特殊方法提高下生产力，因此也就有了下文。

扫描原理

CVE漏洞扫描到底是怎么做的呢？他会真的使用某些探测程序去尝试攻击服务，然后验证出我们使用的组件存在某些漏洞吗？不会。这一点很重要，否则我们的“升级”方法肯定是不好使的。CVE扫描实际上是检查一下所使用服务组件的版本，然后结合各大权威平台公布的漏洞信息，爆出其中可能存在的漏洞问题。

修改原理

那么有了以上原理支撑，我们似乎就可以通过“升级”版本来规避掉这些漏洞了。

（1）将openssh重新编译，“升级”他的版本

（2）将现有的openssh版本号给“升级”

方法（1）需要付出的代价不比升级openssh小，所以直接放弃了。那么在一个应用开发过程中，我们“升级”版本是一件很容易的事情，我们可以直接改掉标识版本号的文件，可是当前服务已经打包成二进制文件了，我们该如何去改呢？其实也有办法，我们总能通过一些工具让二进制文件中的字符肉眼可辩。

“升级”步骤

（1）查看当前openssh版本号

# sshd -v
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips

（2）查看二进制文件中版本号相关字符

# strings /usr/sbin/sshd | grep OpenSSH_7.4
OpenSSH_7.4p1-RHEL7-7.4p1-21
OpenSSH_7.4
OpenSSH_7.4p1

（3）备份旧版

# cp /usr/sbin/sshd /usr/sbin/sshd.bak

（4）“升级”到最新稳定版本

# sed -i 's/OpenSSH_7.4/WoquSSH_8.x/g' /usr/sbin/sshd
//  len(OpenSSH_7.4) == len(OpenSSH_8.x)

（5）校验openssh版本

# sshd -v
OpenSSH_8.xp1, OpenSSL 1.0.1e-fips 11 Feb 2013
# systemctl restart sshd

经过这么一番操作，可以发现openssh成功被“升级”到了8.x的稳定版本，此时我们打开一个终端尝试链接，没有任何问题，下班。

版权声明 本文属于本站  原创作品，文章版权归本站及作者所有，请尊重作者的创作成果，转载、引用自觉附上本文永久地址： http://blog.lujianxin.com/x/art/hg08ylmf4vj1