1. Shell on Wheels:
Darren Martyn
Xiphos Research
darren.martyn@xiphosresearch.co.uk
Exploitation of endpoint wireless devices for mostly fun and
possibly profit

2. whoami
• Darren Martyn / @infodox (twitter)
• Penetration Tester & Researcher @ Xiphos Research Ltd
• Forensics & Chemistry Student @ GMIT

3. whoami: alternatively
• An “unethical immoral twit” – Graham Cluley
• “A bad influence” - Anon

4. what?
• Today we will look at owning those “free WiFi” access points
on just about every bus ever.
• Sorry guys. Not Charlie Miller style bus owning here. Nothing
explodes/catches fire/crashes.
• Still, will make bus rides a lot more fun!

5. who?

6. who?

7. what do they have in common?

8. what do they have in common?
The magic box of Wi-Fi!

9. Let’s explore the magic box!
• i486 Embedded Processor (so, x86)
• One or more (usually two) data cards for cell connectivity
• WiFi, Ethernet, GPS, serial
• Unfortunately, I was unable to acquire my own magic box

10. But firmware is good too!
• Via googling, came across a random FTP server containing 108
firmware images for these devices (courtesy of an engineer)
• Judicious application of wget. (anonymous login FTW)
• Now we have firmware images

11. Because of scale we scripted binwalk…

12. Next up, scripting uncramfs…
Trigger Warning: Filthy Code Ahead

13. find . –name “vuln”
• Took a fairly blind approach to finding vulns
• “Grep and gripe” kind of things
• First off, looked at the web interface of device

14. Anyone see why this prompted interest?

15. Scripting is Magic…

16. Scripting is Magic…

17. Some numbers
• All 108 were vulnerable to ShellShock
• All 108 had the same shitty CGI script
• 106 used thttpd rooting as root
• 2 ran lighttpd. Also as root

18. Fingerprinting Web Server

19. Remote Root Everywhere

20. Going beyond Rootshells
• So we can execute code as root
• Leverage this to bypass auth and get at the web interface?
• Dump settings from the device?
• Persistent (firmware) rootkits?

21. Bypassing Auth
• Uses .htpasswd for auth
• Wrote a simple script to enable/disable auth
• Simply mv the .htpasswd to disable, mv back to re-enable

22. Bypassing Auth

23. Dumping Settings
• With Auth bypassed, we can wget “moovbox.settings” from
the device
• Sqlite3 database, contains passwords and such
• The Sqlite database was a mess, so I wrote a parser to dump
the goods from it

24. Settings Parser

25. Remote Settings Grabber
• Just for shits and giggles, I wrote an auto settings downloader
• Disable auth on device
• Dump database from device (save as md5sum of file)
• Re-enable auth on device

26. Remote Settings Grabber

27. Further firmware analysis
• Lets look for more fun stuff in this firmware
• First off, we analyse the passwd files
• 4 unique hashes

28. The Hashes
• I have yet to crack these. People have been trying and failing
for about a month. Can you succeed?
root:$1$5jjAfVIS$dIG6AvGNwq8EENjTHnfpK/
root:$1$jb.3W.1D$8FeBW.T/x2wwJVB.lp.gv1
root:$1$bw7WuzHj$aU6V7omf9zBWA2sEaJv9p1
root:$6$W74jOIhT$QaYoDDN.N1SRgyG5ALymJHcYc9TmXKcITXyCstG
DdK9cXOssLOTMQPl2uRm.wsNZ7oE5byOOrdNlvNxyguqVs/

29. SSH Keys
• Protip: Hardcoded SSH Keys Suck
• They all have /etc/ssh/ keys. RSA and DSA
• They also have the same /etc/ssh_key privkey, which is a bit
unusual...

30. /etc/ssh_key
• Now, this is an odd one. It matches exactly two boxes in the
wild – both hosts in Germany
• As to wtf these are, I have no idea
• If anyone can figure it out, it would be great ;)
• 89.110.151.186 & 89.110.148.26 (who is this?)

31. Using SSH keys to fingerprint

32. Look! Duplicate Keys! Everywhere!

33. Let’s go after SSL keys…
• OpenVPN Keys: find . -name "*.key" (108)
> 2e465be3c06ea7db968347aaa3df7d37
> All identical
• SSL Keys: find . -name "*.pem" (973)
> Also the same…

34. SSL Keys
• 6 of them on each image. All identical across images:
> 7135ad5b7fd5fb2eb23f8dfecf74919d
> cb5199178e4649461928356c7cbdae74
> de2c6949bd1bca55c20d9610510a08d1
> 905a7590ee039a788a08d4dfd15d2582
> a926c2beaa439f37bc62a5678a4e5906
> 35a569e0e768495554c4cbddd787f9e4

35. God damn it – all the same?!?!
• These are also good for remote fingerprinting
• And probably traffic interception...
• “You guys are bad at this!” is the only apt response to the
vendor

36. Owning the Client
• Interestingly, these devices do intercept HTTP(s) traffic
• This is for site blocking and to inject banner ads
• Seems to use Privoxy and some scripts to do this

37. (More) Owning the Client
• Devices all have this wonderful traffic interception suite
• Modify existing JS injector to inject BeEF, perhaps?
• Not tested for obvious reasons, but doable 

38. (Yet More) Owning the Client
• These devices have libpcap installed
• Dropping a working packet sniffer is easy
• Sniff cleartext credentials over the wire... All their traffic is
going through you!

39. Remember I said SSL interception?
• Some of these devices observed in the wild tamper with HTTPS
traffic
• Self signed keys observed with SSL'd sites, etc.
• Seemingly generated from the keys stored on device
• Use your imagination 

40. LOLSSL

41. So what about rootkits?
• This is where it gets really fun. And fairly untested
• While attempting to repack firmware, I noticed there were two
variants of image in there
• Variant 1 was just a raw CRAMFS image
• Variant 2 was [header][CRAMFS image]

42. Challenges
• So the raw CRAMFS one, we can just repack and upload
• The other one... I had to try make sense of the header
• This is untested on a live device, so don't try this unless you are
willing to break stuff

43. Header Structure

44. Creating ‘doored firmware
• Add backdoors to extracted CramFS filesystem
• Repackage CramFS filesystem
• If needed, append the weird header so that CramFS magic
starts at offset 0x64

45. How do install our firmware?

46. Suggested Payloads for Modified Firmware
• Script Injector as mentioned previously using already existing
code on the device!
• Traffic sniffer ala LinuxFlasher.A rootkit 
• Remote shell/file xfer – “tshd” or similar with a hourly callback
to C2?

47. Some Conclusions
• These devices have no security
• If you use free WiFi on public transport, expect to be owned.
(well, thats to be expected?)
• If you are a vendor of such devices, start taking security bloody
seriously

48. Afterthoughts: Concerning Disclosure
• Tried emailing icomera, did not receive response
• Made repeated attempts with no success, however, normally
when I try alert vendors about stuff they get annoying and
irritable

49. Afterthoughts: Concerning Patching
• Icomera claim on their blog to have patched the ShellShock
exploit
• However, as its up to end users to patch their boxen (no auto
updater), this is kinda useless
• All the devices I see ITW are vulnerable still
• Raises concerns over Internet of Junk and updates

50. Thanks
• f1nux and the BsidesHN crew for making this event happen <3
• Co-workers for letting me off to do science and supporting it
• Various friends (you know who you are) for helping out
• Icomera, for making such a wonderful product I have
something to talk about 

51. Contact
Email: darren.martyn@xiphosresearch.com
Web: www.xiphosresearch.com
Twitter: @info_dox