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.
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.
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= .
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?
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>
I used fdisk /dev/sdb to set the bootable flag on partition 1 (/dev/sdb1).
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.