文章详情页 您现在的位置是:网站首页>文章详情

解决CVE漏洞黑科技

图片丢失 Jeyrce.Lu 发表于:2020年5月17日 10:50 分类:【服务器 2237次阅读

漏洞背景

某客户使用了我们的产品,用绿盟扫描出一堆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

文章评论区

作者名片

图片丢失
  • 作者昵称:Jeyrce.Lu
  • 原创文章:61篇
  • 转载文章:3篇
  • 加入本站:2068天

站点信息

  • 运行天数:2069天
  • 累计访问:164169人次
  • 今日访问:0人次
  • 原创文章:69篇
  • 转载文章:4篇
  • 微信公众号:第一时间获取更新信息