The MDS iNET 900 is an industrial wireless device for long distance networking and network–to-serial communications. It is used in Industrial, Scientific, and Medical (ISM) infrastructure. GE is the current vendor through acquisition of “Microwave Data Systems” or “MDS” in 2007. GE advertises the following security features: RADIUS authentication, VLAN traffic segmentation, proprietary hopping patterns (FHSS), and RC4-128 encryption among other standard features such as HTTPS, SSH, and SNMPv3.

The 900MHz radio band provides longer distance at the expense of lower bandwidth.

I purchased one of the devices for myself after seeing them in use at various clients hoping to learn more about how they work.

Features:

Wireless Encryption: The encryption, based on my research, appears to be 120-bit RC4 with an 8-bit key, sometimes referred to 128-bit WEP. WEP has been demonstrated to be completely vulnerable to cracking with minimal effort. Mitigating this of course are the 900MHz frequency, and the FHSS. [This device is not using WEP according to the manufacturer.]

Radio Obfuscation (FHSS): Frequency Hopping Spread Spectrum – Roughly 24 hours of channel analysis is required to determine the pseudo-random hopping algorithm. This is non-trivial and requires non-standard hardware and software to attack. According to the vendor the FHSS is there for channel avoidance rather than security, though some security it does provide.

MAC Filtering: The device does have the capability to filter communication to only MAC addresses in its whitelist. Of course, this is hardly a “security” feature as it doesn’t prevent eavesdropping or spoofing.

Pictures of the device itself:

Identified Hardware Components:

HALO_TG74-1406N1 10BASE-T Networking

Harris_HFA3841CN 2.4GHz WLAN Chip Set

LEVEL_ONE_LXT905 Universal 10BASE-T Transceiver

Linear_1374fd 4.5A 500kHz Step-Down Switching Regulator

LinearRegulatorLP3962 1.5A Fast Ultra Low Dropout Linear Regulator

Motorola MPC850 Microprocessor (the brains of this thing)

Micron MT48LC4M16A2TG Synchronous DRAM

Sipex_SP3238E RS-232 Transceivers

The web interface:

The MDS iNET 900 MHz radio does not appear capable of using SSL/TLS. Using the default of “basic” authentication, the username is passed in the clear with the password base64 encoded.

Furthermore, the web interface is based on a combination of HTML and CGI. Using Burp Suite, I was able to verify multiple XSS vulnerabilities which were reported to the vendor (nearly two years ago).

Reversing the firmware:

I downloaded the running version of firmware for the device I had and began research on how to unpack and reverse engineer firmware images for embedded devices.

First, lets figure out what we’re dealing with using binwalk:

# binwalk -Me inet-6_9_1.ipk
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
133           0x85            uImage header, header size: 64 bytes, header CRC: 0x552D426F, created: Mon Apr  2 20:29:53 2029, image size: 775040560 bytes, Data Address: 0x20285365, Entry Point: 0x70202039, data CRC: 0x20323031, image name: "13:29:55)"
137           0x89            U-Boot version string, "U-Boot 1.2.0 (Sep  9 2014 - 13:29:55)"
125452        0x1EA0C         Unix home path string: "/home/username/projects/nethop/nfsroot"
131049        0x1FFE9         uImage header, header size: 64 bytes, header CRC: 0x99070884, created: Tue Sep  9 10:30:04 2014, image size: 521370 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0x719F1214, OS: Linux, CPU: PowerPC, image type: OS Kernel Image, compression type: gzip, image name: "Linux 2.4.4 (allfs)"
131113        0x20029         gzip compressed data, maximum compression, has original file name: "vmlinux", from Unix, last modified: Tue Sep  9 10:30:03 2014
652515        0x9F4E3         CramFS filesystem, big endian size 3260416 version #2 sorted_dirs CRC 0x18780dd1, edition 0, 1867 blocks, 349 files

Next, we’ll extract the CramFS filesystem out of this package:

# dd bs=1 skip=652515 if=inet-8_1_1.ipk of=inet.img

And finally, because it’s using CramFS we’ll need to flip our endians

# cramfsswap inet.img endian_inet.img

Now we’re ready to mount our disk image and check out the files

# mount -o loop -t cramfs ./endian_inet.img mds_inet/

For instance, we can see the Linux MOTD:

# cat motd 
Linux 10.2.205.168 2.4.4 #1 Thu Jun 28 14:34:52 EDT 2001 ppc unknown

Welcome to MontaVista Software's Hard Hat Linux.

Ppcboot ftp://ftp.denx.de/pub/ppcboot/

While this provided a number of interesting details on the device, it didn’t provide quite the backdoor or 1337 vuln I was looking for. I used “strings” to triage binaries that may contain clues to passwords, backdoors, and other weirdness. Two hardcoded passwords were discovered, but according to the vendor (and my own research) are disabled before the device leaves the factory. I did find an easter egg, that when brought up with the vendor somewhat shocked them. Never had any one found it 🙂

While “strings” yielded less than hoped, I attempted to run the image in QEMU:

This “kinda” worked, in that the kernel would somewhat boot and would drop me to a menu, but most of the binaries appeared to be broken. Further researched pointed at missing or incompatable libraries in QEMU or the Debian Wheezy image I downloaded for this task. I could fire up the Debian PowerPC VM and mount the inet image.

qemu-system-ppc \
-hda debian_wheezy_powerpc_standard.qcow2 \
-hdd inet691/_inet-6_9_1.ipk.extracted/99C4E.cramfs \
-nographic

## login to new emulated machine
# mkdir /mnt/mds
# mount /dev/sdb /mnt/mds
# ln -s /mnt/mds/lib/-some stuff- /lib/
# mount -t proc none /mnt/mds/proc # Give it some devices like uptime
# chroot /mnt/mds

“/bin/init” and “/bin/menu” looked as though they launched, but functionality was extremely limited and I was running out of time for this project.

Other:

The MDS iNET relies on Mocana SSH, a proprietary SSH server. Mocana prides itself for the closed source nature of their software. Though, I may or may not have discovered the source after some intense Google-fu. Once again (possibly) proving that security through obscurity rarely works.

Conclusion:

I didn’t find any crazy 0days in this device, but I learned a lot about reversing firmware for an arcane PowerPC based system. All vulnerabilities were reported to the vendor, and newer firmware updates fix some of these issues. This particular device is growing out of fashion as faster devices are often required.