reverse engineering

All posts tagged reverse engineering

I recently had an appointment at an ophthalmologist and because it was in New Mexico, where appointments mean nothing and linear time isn’t a thing, I had a long wait in the exam room. Stay with me I swear we are going to pen test some stuff. Most of the equipment in the room was from Welch-Allyn so why not take a look at their stuff to see how secure my data would be.

I’m not an amazing reverse engineer; it is on my list of things to improve so I took this opportunity to dig into some firmware upgrades. I’ve looked through firmware in the past and decompiling binary files never got me any results.

I was able to find the firmware for the Welch-Allyn RETeval-DR, it isn’t sold in the United States but the file was available for download without authentication.

https://www.welchallyn.com/content/dam/welchallyn/documents/upload-docs/RETeval/reteval-2.5.0.fw

Welch Allyn RETeval-DR™ Firmware
Version 2.5.0 | November 11, 2015
System requirements: Windows XP, Windows 8 and all previous versions
File type: .fw | File size: 35.2 MB

I used the ‘file’ command to learn some things about the .fw file type.

root@kali:~/Desktop/RETeval-DR# file reteval-2.5.0.fw 
reteval-2.5.0.fw: Zip archive data, at least v2.0 to extract

Zip archive, I know what to do with those. At this point I assumed that this was going to be another binary fine and wasn’t super excited. Extracting the contents of the zip file reveals a bunch of .img files and an install.sh script.

.fw File Contents

.fw File Contents

My first thought was that the install.sh file might contain a login of some sort or some other sensitive data. The script contains some checksum validation and uses dd to write the images to disk. A very helpful piece of text is the offsets for each file are directly after the seek= .

dd offset values

dd offset values

I mounted the rootfs.img and poked around the file system.

root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data# mount -t auto rootfs.img mnt/
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data# cd mnt
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data/mnt# ls
bin  boot  dev  etc  lib  lib32  linuxrc  lost+found  media  mnt  opt  proc  root  run  sbin  sys  tmp  usr  var

root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data/mnt/etc# cat passwd
root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
operator:x:37:37:Operator:/var:/bin/sh
haldaemon:x:68:68:hald:/:/bin/sh
dbus:x:81:81:dbus:/var/run/dbus:/bin/sh
ftp:x:83:83:ftp:/home/ftp:/bin/sh
nobody:x:99:99:nobody:/home:/bin/sh
sshd:x:103:99:Operator:/var:/bin/sh
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data/mnt/etc# cd shadow
bash: cd: shadow: Not a directory

root@kali:~/Desktop/RETeval-DR/reteval-2.5.0/data/mnt/etc# cat shadow
root::10933:0:99999:7:::
bin:*:10933:0:99999:7:::
daemon:*:10933:0:99999:7:::
adm:*:10933:0:99999:7:::
lp:*:10933:0:99999:7:::
sync:*:10933:0:99999:7:::
shutdown:*:10933:0:99999:7:::
halt:*:10933:0:99999:7:::
uucp:*:10933:0:99999:7:::
operator:*:10933:0:99999:7:::
ftp:*:10933:0:99999:7:::
nobody:*:10933:0:99999:7:::

Pretty sure this means that the root password is blank…OPSEC 101. Almost 90% of penetration testings is asking yourself ‘What would happen if I did this?’ So, What would happen if I wrote that to a new disk on a virtual machine?

VMWare Blank Drive

VMWare Blank Drive

 

/dev/sdb added

/dev/sdb added

We will need to install pv for the installation to work, pv monitors progress of data and as data gets piped to it directly after it is unzipped and before it gets to the dd command in the install script. Also, we need to make the script executable before we try to use it.

root@kali:~/Desktop/RETeval-DR/reteval-2.5.0# apt-get install pv
<Redacted the install text>
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0# chmod +x install.sh 
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0# ./install.sh --help
arguments:
  -a <archive name> (required)
  -b update boot loader too
  -d <destination> (required)
  -f fresh install (on PC)
  -n numeric progress
  -v print firmware version
examples:
  First time programming: -a firmware.fw -f -d /dev/sdc
  Firmware update: -a firmware.fw -d /dev/mmcblk0
root@kali:~/Desktop/RETeval-DR/reteval-2.5.0# ./install.sh -a ../reteval-2.5.0.fw -n -f -d /dev/sdb
<Redacted the install text>
/dev/sdb after dd

/dev/sdb after dd

I used fdisk /dev/sdb to set the bootable flag on partition 1 (/dev/sdb1).

fdisk Set Bootable

fdisk Set Bootable

I couldn’t get it to boot independently in a VM and I couldn’t get sdb3 or sdb4 to mount in my Kali Linux box. I tried to use the -t auto and it failed, I also tried every Linux type that I could with no luck. Oh, well. In a few minutes we found the default password for the device and determined if we could boot the drives up in VM. Not bad for an eye appointment.

Disclosure Notice: We contacted Welch-Allyn on May 17, 2017 and notified them of the issue. As of June 30th they had not given me any feedback about mitigation status so I am releasing this. Forty five days is more than enough time to mitigate this vulnerability.