Whilst bantering on IRC the other morning, I was pointed by one of the chaps to a device going cheap over at Amazon UK, a little USB stick by the name of the Yoggie Gatekeeper Pico. You may or may not have heard of it, I certainly hadn’t, but its function is to be a firewall, intrusion detection/prevention system, web filter/email scanner and antivirus, in personal and portable hardware form. Once installed, it will route all your network traffic through it and in theory protect you from any harmful bits and bytes which might be present. It’s really a neat little device, it’s good looking, small, light, pocketable and bus powered, and should save your CPU from sweating over some of the security stuff which is usually done in software.
Thanks to chz|bacon for making my photo a little less horrible.
But this means it must have a nice chunk of computing power inside it, right? Indeed it does. In fact, it’s a complete Linux machine in there, an XScale PXA270 CPU (ARMv5, apparently) running at nigh on 520MHz, with 128MB RAM and what appears to be 64MB of flash (via df -h, a 60MB partition shows up). Quite a capable machine, then, I recall my first smartphone being similarly spec’d, and it wasn’t half bad at the time. Anyway, here’s what it looks like when in service – do excuse the prehistoric browser, it’s an experimentation VM:
As you can see, it gives an at-a-glance view of just how screwed you would’ve been if you hadn’t had this device hooked up. The risk level meter seems a bit over-sensitive to me, but I suppose that’s a matter of opinion. Besides this view, it also gives some Flash-powered 3D graphs to show you the varying levels of you’re-boned as they happen. Here’s a snapshot:
This is all very well, an interesting concept, and one which appears to work reasonably well, but the company now appears to be defunct (http://www.yoggie.com) and the antivirus definitions and such are really rather outdated, mine says it was last updated in 2008 and it’s brand new, a stab in the dark but I’m guessing the servers which provided updates are now offline. So what do we do with them? Why, we root them, of course! They’re essentially dinky Linux PCs minus any sort of display, so there must be some use for them. I haven’t yet put mine to use, I’ve not had much time to mull it over in my mind, but in the meantime I thought I’d share with you a few clues towards rooting your own.
Having Googled about a bit beforehand, I came across precious little information from predecessors who attempted this endeavour, but I’m sure they saved me some considerable time. There’s this post referring to a similar, related device, but one with more capabilities and designed to be open from the get-go. Sadly, the USB model is earlier and considerably less open, so unlike the SOHO router version, I couldn’t just pop open an SSH connection and be on my way. Then there’s this thread and this exploit, which look pretty similar, but despite them being closer to my hardware, they refer to different firmware versions. Curiously, the forum post mentions two things of note, the first is that the device will pick up on attempted exploits (which I encountered, more on that shortly), and the second is that he believes as a result of that hack detection, the attempts are reported back to Yoggie for patching. Whether or not this is true I don’t know, but it’s an interesting concept. But having discovered these sources, I had some sort of idea where a hole might be hiding, and as it happened the vulnerability was there, as I’d hoped. Well, sort of. Despite my firmware version being lower than that of the forum poster’s device, I had a harder time getting in. It seems that at some point the Yoggie guys had partially closed the hole, but not entirely, which was a bit odd. In the exploits mentioned above, the founders of them used fairly straightforward hex encoded substitutes for the necessary punctuation, such as %20 for space and so on, but when I tried it, it flagged me for an attempted hack.
This is the frame in which the results of the diagnostics, ping and traceroute would normally appear, but when this version of the firmware spots a space, an angle-bracket, a pipe or an acute accent in the string which is supposed to be an IP address, it flags a hack attempt and stops doing whatever it was I’d asked it to do. This rendered the original hacks a bit useless in this instance, but I still had some faith in the lack of proper sanitation behind these text boxes. After a little faffing about experimenting with some different strings and whatnot I decided to try adding %0A, a line feed, after an IP address, which it didn’t barf on. Then I tried adding a command after it, nice and simple, an “ls”. What do you know? It worked. Obviously not that cleanly sanitised after all. It strikes me as a bit lazy to go and patch an exploit so half-arsedly that it leaves a gaping hole almost as big when it would make far more sense to only allow 0-9 and a dot/period/full-stop (circle as appropriate). Anyway, I did get a directory listing, which was definitely progress, then I tried a “uname” to make sure it wasn’t a fluke, and all was well there too, but again not that useful – what was I going to do with a single command and no arguments? I had to find a way to execute something more complex but without using spaces, given my lack of proper Linux knowledge, I did a bit more Googling, a quick glance at some threads about special characters which turned out to be inconclusive, then I tried curly brackets which also failed, and then I ended up staring at an ASCII/hex table. I thought there might be some character which would double as a space, but I tried a few likely candidates such as non-breaking space without any luck. I fiddled about some more and hit on the idea of trying tab. Now, normally this would probably auto-complete stuff in a Linux shell, but this wasn’t a Linux shell, and it’s sort of like a very wide space, right? I tagged on a %09 which is the hex code for tab and chucked a “-a” on the end, and…
…I’m fairly sure that’s not meant to be there. Success! One part is definitely good, I’ve got access, and it’s root access too, exactly as those who’d come up with the older exploits said. I took a leaf from the guys responsible for the other hacks and tried making a copy of my shadow file to a web-accessible txt file, and that worked perfectly with my new modifications.
Great, that’s definitely more than I started with, and it solves the space problem, but now I had to turn that into proper root access somehow, something useful, a shell. I considered a few options, none of which I knew anything in-depth about, perhaps I could create a new user with my root access, but that would require setting a password before I could SSH in, which is interactive or requires a combination of commands with a pipe, which is verboten. I considered a reverse shell, which after a brief period playing around with it, I got nothin’. In the documented hacks, they used this hole to write a whole new /etc/shadow file, but I couldn’t use angle-brackets, so I couldn’t echo anything to a file, so I set about thinking of other ways to get files into it. I tried wget, just in case I could download stuff right into the web server, that didn’t really work, it hung more often than not and it never downloaded the file. I know the device has wget, and root has access to it, but for some reason that just wasn’t playing ball. So if I can’t write a new file and I can’t download one, maybe I could upload? Well, there is provision for uploading a firmware file, but I don’t know what it does, and I didn’t want to brick my only device, so I thought it wise to leave that as a last resort. No new files, no echo redirection, no pipe, no download, no upload… guess I’ll have to modify the existing file some other way then. Which I did. My knowledge of Linux might be poor, but I happened to know that tools exist in most distros which enable string/text file manipulation, particularly awk and sed. Again Googling for assistance, the syntax of awk seemed to often contain too many forbidden characters, so I opted for sed. At this point I would’ve had to generate a new hash to place in the shadow file to give the root user a new password, but as luck would have it I stumbled across this post whilst looking for sed syntax samples, wherein the poster happens to have written a script which contains the exact command and arguments I need, including a pre-generated hash for the password string “password”. Brilliant! My lucky day, it seems. I swapped all the spaces for hex tabs, then ran the sed find/replace on my backup shadow.txt, and then I ran it again to verify, then I ran it again with properly escaped dollar signs which I’d forgotten to do, then I ran again to verify my fix, and then again with modifications to double check it was working reliably, then yet again to make sure I’d corrected my modification back to what they should be. I wanted to get this right, I didn’t feel like spending all that time to end up with a small plastic brick. Then I did it for real, on the active /etc/shadow file.
I think I’m going to call that a win. Everything else functions as it should, none of the original functionality is affected, except now I have full root access via a shell. Oh, how I missed that sweet, spartan, grey on black textual miracle. I never want to have to half-blindly fumble a textbox into submission with only half the keyboard at my disposal ever again.
For the benefit of those with similar devices, I’ll post the two strings which ended up being of use below, between this information and the previous hacks you’ll hopefully find it to be of some use in filling in some gaps, should your device be equally uncooperative.
First command: Perform a sed search/replace on the shadow file, replacing the root user line with one containing the password “password”.
Second command: Start up the dropbear SSH server on port 7290.
I would suggest starting small and less destructive, however, perhaps try 127.0.0.1%0Als first for a directory listing, or 127.0.0.1%0Auname%09-a to see if the tab substitute for a space works for you. To use all of these commands, paste them into the Ping or Traceroute textboxes on the Diagnostics tab, on the Support page of the web interface, then hit the respective button to the right. If they appear not to work, browse around the web interface a bit and make sure you’re logged in properly, it can be a bit temperamental, and if the commands seem to take too long, try again with google.com at the beginning instead of 127.0.0.1, sometimes it seems to work better, I have no idea why.
Be aware that these commands aren’t meant to be used this way, and there’s a very real chance they could brick your device forever, don’t use these commands on a device you need to keep running, on anyone else’s device without permission, or really anywhere at all, unless you’re prepared for everything to go horribly wrong. I got lucky, hopefully you will too.