Meraki RCE: When Red Team and Vulnerability Research Fell in Love

Part 1

When I joined Salesforce, before moving over to vulnerability research, I worked in the Red Team. Our mission was to strengthen Salesforce’s security posture by acting as an external attacker.

In one assessment, I installed a pwnplug inside a meeting room. Unfortunately, when I went back to the office to check the shell, I learned that I had ended up plugged into a VoIP VLAN. Not very promising from an attacker point of view, but I decided to see what I could glean from this VLAN anyway.

Initial Recon

The switch I was able to reach from the pwnplug was Meraki branded. These kind of devices are connected to a cloud that allows sysadmins to manage multiple network devices remotely through a web interface. I was able to view the management interface as seen below:

I couldn’t find any public exploit that could successfully compromise the Meraki device providing a shell I could use to access other VLANs. In fact, even authorized sysadmins can’t SSH to the device directly — they must use the web interface to perform any management actions. Only two options remained: giving up and trying a completely different attack vector, or doing some research and finding a Remote Code Execution exploit. I opted for the second one. First, I tried poking around in the switch’s web portal trying to find more information (and hopefully execute code) through the webUI. The attack surface is very restricted, and most web sections require authentication.

Time to think about a different approach.

Hardware Hacking

I’ve always liked taking things apart, and every time I do it something extraordinary happens: somehow screws reproduce and I always get some extra ones when I mount things back. Through similar magic, I somehow managed to acquire a Meraki MX80 security appliance to play with. At this point I took the hardware pentesting approach: extract the firmware, with the goal of reverse engineering the CGIs and binaries that listen at any port. After opening the device, I noticed its 1Tb hard drive. After extracting and mounting it, I could see that no filesystem resides in the hard drive — it’s just used to store cache information.

I suspected that the OS filesystem must be in flash memory in the device’s circuit board. After some hours of testing with a multimeter and logical analyzer, I found an open serial connection that gave me full root access to the device. It uses U-Boot as bootloader as you can see in the next screenshot after setting up the correct baudrate.

The baudrate of the serial communication is 57600. To be able to connect to it I used a Raspberry Pi through the serial interface:

Once I got root access, I extracted all the configuration files; webUI configuration files, /etc/passwd, and so forth. Lighttpd, the web server used to serve the web portal, stores the credentials for the protected areas of the web portal in the /tmp/lighttpd-htpasswd.conf file which contained the following content:

m00180A07A354:/# cat /tmp/lighttpd-htpasswd.*
mf_test:$1$$ZbKKXKQQpKjTbTPeMZwk..
admin:$1$$G7.z4WDwEF7FvCK4H6cah/
Q2DN-GY83-EZBU:$1$$qRPK7m23GJusamGpoGLby/
q2dn-gy83-ezbu:$1$$qRPK7m23GJusamGpoGLby/

The last two entries correspond with the unique serial number of the device, but as you can see there are two users, mf_test and admin, that are commonly included in every version of the firmware. The credentials are hashed using MD5, and after some laborious time in the Salesforce cracking rig, I cracked one of them:

mf_test:mf_test

These credentials can be used to access any restricted site within the web server and modify the config, plus other interesting pages I will touch upon later. The system passwords are stored in /etc/password as follows:

m00180A07A354:/etc# cat passwd
root:!:0:0:root:/tmp:/bin/ash
nobody:*:65534:65534:nobody:/var:/bin/false
meraki:MvCWFGH8/CrXM:0:0:meraki:/tmp:/usr/bin/logincheck
mf:$1$$CgXoxAaejQmJWRkDiclb6/:0:0:meraki:/tmp:/usr/bin/mf_logincheck

I tried to crack those credentials for a little while but I couldn’t. SSH seems to be restricted so passwords cannot be used.

In the next post I will show how not only how I fully compromised the device getting a root shell but how I managed to have a partially working Meraki device in a Ubuntu VM. Doing this research was crucial to achieve the Red Team objectives.

(This post was originally published on 1–16–17.)

Note: Salesforce supports coordinated vulnerability disclosure. All vulnerabilities discovered and described within this post have been reported to and fixed by Cisco. Part two of this series will include further details, including CVE assignments uniquely identifying these issues.