删库跑路未遂

20191029175312-tiger

惊魂 rm -rf /*

话不多说，先上图。胖友你是否也有过这么脑残的行为！！root 猛如虎！！root 下的 rm 猛如虎！！

2019102917494-rm

冷静思考

心里暗想，这难道要删库跑路吗！搬着指头算了一下，上面装了多少个环境：K8s 集群 + TSDB + CDH；虽然不是生产环境，但这么多系统，多多少少还是有点懵逼加心慌。

简单检查了一下 K8s 集群、TSDB、 CDH发现这些应用都还是正常的，祈求上天保佑没删什么重要的文件！🙏🙏🙏

为什么连不上SSH

仔细一对比发现 /bin 目录不见的，这下搞的有点大，难怪 ssh 连不上了，应该是找不到相关的二进制文件了。也有可能是 .ssh 被删除了，必须 ssh 上去验证一下才能确定

现在的问题是怎么恢复 /bin 这个目录，关键是 ssh 不上去；开始思考怎么拿到 shell；以前研究过一点渗透测试，于是开始思考怎么利用上面的应用软件来搞事。

想办法拿shell权限

还必须是 root 权限；

CDH

之前在安装 CDH 的时候已经做过 SSH 互信，当然我本地不能连上去，做了 SSH 互信也没用。然后把方向调转到了 CDH Web 管理界面，到 web 界面逛了一圈没发现有现成的入口可以利用，先暂时放弃这条路。

K8s

比较下来感觉还是 K8s 希望大一点，我简单试了几次，部署了个测试的 pod 到该节点上去，可以部署成功，但是 ssh 上去连接到的是 Container 内的 ssh。也操作不了宿主机。突然一个灵光闪现，把宿主机的根路径挂我我容器里面来，感觉可行，于是就创建了如下的 pod。

由于一开始我没指定 pod 部署的 node，老是会把这个 pod 部署到其他节点上去，通过下面的方法查询 node 的 label，然后进行指定：

# 查询 node 标签
$ kubectl describe node "dbnode2.localdomain"

从结果中选取一个能标识 node 的 label，我们就选取kubernetes.io/hostname=dbnode2.localdomain

Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=dbnode2.localdomain
        kubernetes.io/os=linux

最终 pod 的配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox
    resources:
      limits:
        cpu: 200m
        memory: 100Mi
      requests:
        cpu: 100m
        memory: 50Mi
    stdin: true
    securityContext:
      privileged: true
    volumeMounts:
    - name: host-root-volume
      mountPath: /host
      readOnly: true
  volumes:
  - name: host-root-volume
    hostPath:
      path: /
  hostNetwork: true
  hostPID: true
  restartPolicy: Never
  nodeSelector:
    kubernetes.io/hostname: dbnode2.localdomain

# 部署pod
kubectl create -f privileged-pod.yaml
# 查看，pod 已经在运行了
kubectl get pods -o=wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP             NODE                  NOMINATED NODE   READINESS GATES
privileged-pod                            1/1     Running   0          8s    10.115.0.223   dbnode2.localdomain   <none>           <none>
# ssh 连接
kubectl exec -ti privileged-pod sh
# 查看挂载目录，果然挂上来了
/ # ls /host
bin  boot  data1  data2  data3  data4  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

分析到底是缺了什么导致 ssh 不能连接，进入 .ssh 目录发现文件还在，先还原 /bin 看看，发现该目录上只读的。刚燃起的信心又凉了半截，仔细一看发现 readOnly: true 果断改成 readOnly: false。

# 发现没有 w 权限，执行创建还是没权限
/ # ls -na
dr-xr-xr-x   21 0        0             4096 Oct 29 09:29 host
# 添加权限然后再创建然后成功了
/ # chmod u+w /host

幸运的是发现 /bin 原来是 /usr/bin 的一个软连接，搞半天删了个软件链接，看来机会大大的有，于是新建一个软连接

ln -s bin usr/bin

然后在 ssh 试一下，发现成功的了！！卧槽感动的想哭！！再次提醒自己一边 root 猛如虎！rm 猛如虎！这次真的不用跑了。

总结

最小权限原则无论是什么时候都适用，就算因为 0day 被攻破了，黑客拿到的是非 root 权限，那么黑客能做的事业有限。
rm 必须谨慎使用，特别是加上 -rf 两个参数，特别是在 root 权限下执行。
不要心存侥幸，墨菲定律，凡事有几率的事情都一定会发生。

本文由 zealzhangz 创作，采用知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: 2019/10/30 10:18