Hacking and Securing the Tandberg C20 by xorcist (xorcist@gmx.net) Introduction to the C20 The Tandberg C20 is a hi-def video conferencing solution. It consists of a base unit containing a few fairly standard Linux-based microcontroller boards, and an externally mountable 1080p camera. You have to add your own hi-def display. It talks H.323, and is pretty good at what it does, but is probably way overpriced for what it is (list price is $7900!). The microcontrollers are all Tandberg branded internally, but they appear to vary little, if at all, from ordinary reference designs. Internally, there are 4 microcontrollers: one MPC8347 PPC with 512 MB of RAM and 2 GB of flash, and three ARM boards with 128 MB of RAM each. The PPC runs the show, and the ARM boards handle peripheral video functions, the OSD/menus, etc. How can such a meager offering do real-time 1080p encoding and decoding? The magic is in the FPGA chips that are controlled by the ARM boards. Apparently, all the R&D effort on Tandberg's part went into those FPGAs, because the rest of the system is a joke. I haven't gotten around to trying to sort those out, partly because I don't know of a way to decompile the FPGA core to VHDL or Verilog, but mostly because I just don't care about the specifics of their hardware codecs. Plus, there is just too much else going on with this thing, as we'll soon see. When I said the microcontrollers all appear off-the-shelf, I meant it. For nearly $8k, you might expect to get a tightly integrated and polished device. No, none of that here. Internally, the ARM boards are networked over gigabit Ethernet to the PPC board. The PPC hosts a normal tftp boot process for the ARMs, and the ARMs mount their userland tools over NFS from the PPC. A similar platform could be pieced together from Gumstix and eval boards for a third of the price, if not less. The exact hardware details (number of ARM boards, etc) of their other products differ somewhat from the C20, but they all seem to use this same code base, so most of what we're doing here should apply to other Tandberg products as well. Getting in, and getting our feet wet This is the the easy part. Just plug the C20 into your LAN, and power on the device. Let it boot up, and ssh or telnet to it. You can also null cable into the serial port. Username: root. Password is... drumroll for suspense... any god damned thing you like. Yes, internally the PPC issues public-key authenticated SSH connections to the ARM boards (read the '/bin/runonarms' script to find out how to connect to them) for executing remote commands, but the system accounts all have blank passwords for logging in to the PPC host from the outside. You can set a password on the web interface, but the text logins are entirely unprotected. I guess at eight grand apiece, these guys can afford to smoke a lot of top quality dope. I made them an offer to suppress this article for an ounce and a connect with their dealer, but they declined... so you benefit. [excerpt from /etc/rc.sysinit] # Create /etc/password file # FIXME! root should have x in the password field as well, and # the password should be set correctly later. echo "root::0:0:root:/root:/ bin/bash" > /etc/passwd echo "root:x:0:root" > /etc/group echo "selectsw::0:0:selectsw user:/root:/bin/selectswsh" >> /etc/passwd echo "nobody:x:1:1:Nobody:/:/ bin/false" >> /etc/passwd echo "nobody:x:1:nobody" >> /etc/group [/excerpt] A FIXME note!?! Seriously? They knew it was broken, but they shipped it anyway, and the mistake is recreated every time the thing boots! I'm not really sure why the hell they would do that. They could have at least put a default password on it. It gets worse, though, because you have to jump through hoops to fix it. First, there is no 'passwd' command on the system, which is totally unacceptable since the vast majority of that 2 GB of flash is unused. Netcat is installed, along with several 'mkfs' variants for filesystems that aren't used. But no 'passwd'. Secondly, it wouldn't really do you any good, because the PPC boots with '/' as a ramdisk. So, anything you do is wiped out on reboot anyhow. The ramdisk image where 'rc.sysinit' is located contains some proprietary headers, so it can't be easily modified. Lovely. The sad thing is, there is a config disk image that is mounted read/write for saving configuration information, and '/etc/passwd' could easily have been copied from there. Tandberg security just sucks that bad. Actually, no. It's not quite that. Tandberg has no security, and that's what sucks... or rules, depending on your perspective. I don't usually like to add conspiracy when stupidity suffices as an explanation, but leaving out a root password and giving no facility for changing it is so stupid that it makes me wonder if these devices weren't intentionally left wide open. Seeing as they are marketed to executives for "virtual board rooms" and not priced for your average home user, the clientele would be worth snooping on as well. It is perhaps also worth mentioning that the C20 phones home to Tandberg via NTP. So Tandberg techs certainly have the IP addresses of all the devices out there. Anyone who doesn't firewall port 22 and 23 by default can be snooped on by any bored employees. Hey, it's easier to leave out the root password than building in a backdoor right? And it gives plausible deniability. Nice. Passive eavesdropping, and other tricks But, whatever. So we own this thing. Now what? Since we aren't talking about a great deal of CPU power or storage, our applications are somewhat limited. The thing is, though, that since most of the device actions happen on the FPGAs, the resources of the PPC and ARMs are pretty much unused, so we can get away with loading them up some without affecting normal operation. And hey, a 400 MHz PPC might not impress your kids today, but it is a pretty capable machine for a guy who cut his teeth on 8-bit hardware. Anyhow, without any extra work, we can now use an SSH bounce attack to leverage an attack on the internal network the device resides on, or just reflect off of it to a third-party host to hide our origin. We can also restart dropbear, giving it the -a flag so that we can forward remote ports out to wherever we like as well. But we can do better. First things first, get yourself a cross-compiler set up for PPC and ARM. This will give you the most flexibility in producing binaries. If you're lazy, or just want to fix the security problem on your device and maybe install a few extra tools, you can use pre-compiled packages from the PPC Slackintosh distro. How about we install tcpdump? With tcpdump, you can eavesdrop on the H.323 traffic, ship it back to some other host, and replay it (netpoke!) with your H.323 client of choice. It took some doing to make it all work, but I was able to spy on both sides of a conference this way. Device operation doesn't suffer, provided they have enough bandwidth to accommodate the extra traffic. It's an altogether usable, and fairly stealthy, way to eavesdrop on both sides. Rather scary, actually. It might be easier to just strip out the payload data from tcpdump and assemble files for later playback. Another neat trick to try if you have two of these things might be to criss-cross the internal LANs. The iptables kernel modules are installed, but not loaded by default, so you can set the PPC up to route for the ARM boards to get to the wider network. Set up IP aliases on the ARMs, change the internal netmask, and modify '/etc/hosts' on both PPC boards so that the main app on tanberg1 talks to tanberg2's ARMs and vice versa. I haven't tried this, but I think it could be made to work fairly easily. By doing it one way, it should also be possible to have one Tandberg device spy on another and be able to entirely take over the UI functions as well. Getting it secured This isn't really hard, but it is sort of a pain in the ass. I won't get into the gory details, but will just give a rough sketch of how to approach it... there may be a better way that gets rid of that damned empty password file altogether. The situation is somewhat easier if you have a serial console because you can kill network daemons and other stuff that keeps you from unmounting the disk images that you may like to modify. First things first, get a working '/bin/passwd' installed, either compile it yourself, or use the pre-built tarball. Change the password on the system accounts and verify proper functionality. To save our changes out, we need to modify the Tandberg disk images. The default mount table looks like this: none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev type ramfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) none on /tmp type tmpfs (rw) none on /var type tmpfs (rw) /dev/mtdblock1 on /mnt/base type yaffs2 (rw,noatime) /mnt/base/image1/extra.img on /extra type ext2 (ro,noatime, loop=/dev/loop0) /mnt/base/image1/config.img on /config type ext2 (rw,noatime,loop=/dev/loop1) /mnt/base/image1/user.img on /user type ext2 (rw,noatime,loop=/dev/loop3) /mnt/base/image1/apps.img on /apps type ext2 (ro,noatime,loop=/dev/loop4) /mnt/base/image1/tools.img on /tools type ext2 (ro,noatime,loop=/dev/loop5) /mnt/base/image1/www.img on /www type ext2 (ro,noatime,loop=/dev/loop6) /mnt/base/image1/wsgi.img on /wsgi type ext2 (ro,noatime,loop=/dev/loop7) /mnt/base/image1/sounds.img on /sounds type ext2 (ro,noatime,loop=/dev/loop8) /mnt/base/image1/posters.img on /posters type ext2 (ro,noatime,loop=/dev/loop9) /mnt/base/image1/secure.img on /secure type ext2 (ro,noatime,loop=/dev/loop10) /mnt/base/image1/arm/user.img on /armuser type ext2 (rw,loop=/dev/loop2) There are also files in '/mnt/base/image1/partitions.conf.d' that are relevant. Below is the '/mnt/base/image1/partitions.conf.d/main' file. There are some others as well. config.img /config rw,save arm/user.img /armuser rw,save user.img /user rw,save apps.img /apps ro,postprocess=postprocess tools.img /tools ro,postprocess=postprocess web.img /web ro www.img /www ro,postprocess=postprocess wsgi.img /wsgi ro sounds.img /sounds ro posters.img /posters ro This file shows where disk images located in '/mnt/base/image1' are to be mounted. The 'postprocess=postprocess' param says to run a script, called "postprocess" after the image is mounted. They use this to copy files from the disk images into the ramdisk area. The idea here is to modify the script on 'extra.img' to replace the password file. This image is mounted first, prior to the tools or secure images being mounted. At this point in the boot stage, no network daemons are running, so this is as good a time to do it as any. On top of that, it would be nice to resize the image and copy our own tools to it so that they are available on boot up as well. There are, no doubt, many ways to achieve this. Here is the way I found easiest, if a bit dirty: Make a new image called 'extras.new.img', and copy the material from /extra to it, along with the bins and libs you want to add on. Modify the postprocess script to fix the password file and to copy or symlink your custom tools into the main ramdisk tree. Now for the dirty part: Just move 'extra.img' to 'extra.old.img' and move 'extra.new.img' to 'extra.img' and reboot. You'll probably boot up and have it not work. At least, it didn't work for me. I think the failure to unmount the image properly causes a dirty bit to be set in the image1 tree, and when the system boots up it creates a new directory, '/mnt/base/image2', with all new images in there, and you're running out of that instead. No worries, though. Since everything is all read-only anyhow, we're safe. Just rm the active symlink pointing to image2, point it to image1, and reboot once more. You can also actually 'rm -rf image2' entirely before the reboot. It's safe. You'll finally boot up out of the modified image1 directory, this time with your properly mounted new images. At this point you might want to also edit the files in 'partitions.conf.d' to mount everything on the system read-write, instead of read-only, for future ease in adding/modifying the system. You'll need yet one more reboot for it all to be active if you do. Wrap up The main lesson here, if you haven't learned it already, is that each and every device needs to be audited when it comes online on your network, even if it is "just" a video conferencing engine. A single insecure device can leave your entire network open to intrusion. If you're using one of these things, you should at least make sure ports 22 and 23 are firewalled against public hosts. If you're in a big company and don't want some guy in the mailroom to be able to snoop in on the corporate board meetings, you might need to have someone get in there and clean up Tandberg's mess as well. If you're scanning the public IP ranges looking for weak SSH passwords, sooner or later you might run into one of these things. Wait until late at night, refer back to this article, reboot it a few times, get your tools on it, and add it to your botnet! It may not be the sexiest Linux box, but it is unlikely to be audited or go offline and, as long as you don't break the video conferencing functions, no one is likely to notice you... ever. Greets to sryth, wipeout and jow from the land down under. I'll be home soon, fellas.
