11 Finding Software Bugs in Embedded Devices
191
mount -t proc proc /proc
mount -t ramfs ramfs /var
mkdir /var/tmp
mkdir /var/ppp/
mkdir /var/log
mkdir /var/run
mkdir /var/lock
mkdir /var/flash
#iwcontrol is required for RTL8185 Wireless driver
#iwcontrol auth &
#busybox insmod /lib/modules/2.4.26-uc0/kernel/drivers/usb/quickcam.o
/bin/webs -u root -d /www -i /var/run/thttpd.pid &
#ifconfig wlan0 up promisc
Fig. 11.1 Example of a boot script taken from an IP camera
unsafe defaults and hard-coded credentials. Configuration files are of further use
in estimating the set of programs utilized and the initial global configuration of a
device, in the absence of physical access to it. For example, by examination of its
boot scripts, we are able to learn which services present in its firmware (among
potentially hundreds) are actually utilized by the device, this can aid in reducing the
amount of time taken by more complex analysis approaches described later.
Manual methods are often sufficient for analysis of a few firmware images
and, with limited scope, analysis of things such as the device’s configuration. For
example, to estimate the set of processes started by a firmware one can inspect the
contents of a boot script, e.g., /etc/rcS.
Figure 11.1 details such a boot script taken from the firmware of an IP camera.
We are able to observe that the device’s primary functionality is orchestrated by
the /bin/webs binary, which we would then analyze further using the methods
detailed in Sect. 11.3.2.
11.3.1.2 Software Version Analysis
Many devices are not designed to receive firmware updates. This prohibits patching
against known security vulnerabilities and can often render a device useless to an
end-user. This prevents abusing the firmware update as an attack vector. However,
when a vulnerability is discovered, the only effective mitigation is to replace the
device with a new one.
Many devices are designed to be updated and vendors provide firmware updates.
However, the mechanisms for applying those updates are often not standardized and
are largely ad-hoc. They also heavily rely on the end-user’s diligence (to identify that
an update is available) and action (to actually apply the updates). The end-result of
this is that an overwhelming majority of devices are left unpatched against known
vulnerabilities. Thus, a further step in the analysis of firmware is to identify the
191
mount -t proc proc /proc
mount -t ramfs ramfs /var
mkdir /var/tmp
mkdir /var/ppp/
mkdir /var/log
mkdir /var/run
mkdir /var/lock
mkdir /var/flash
#iwcontrol is required for RTL8185 Wireless driver
#iwcontrol auth &
#busybox insmod /lib/modules/2.4.26-uc0/kernel/drivers/usb/quickcam.o
/bin/webs -u root -d /www -i /var/run/thttpd.pid &
#ifconfig wlan0 up promisc
Fig. 11.1 Example of a boot script taken from an IP camera
unsafe defaults and hard-coded credentials. Configuration files are of further use
in estimating the set of programs utilized and the initial global configuration of a
device, in the absence of physical access to it. For example, by examination of its
boot scripts, we are able to learn which services present in its firmware (among
potentially hundreds) are actually utilized by the device, this can aid in reducing the
amount of time taken by more complex analysis approaches described later.
Manual methods are often sufficient for analysis of a few firmware images
and, with limited scope, analysis of things such as the device’s configuration. For
example, to estimate the set of processes started by a firmware one can inspect the
contents of a boot script, e.g., /etc/rcS.
Figure 11.1 details such a boot script taken from the firmware of an IP camera.
We are able to observe that the device’s primary functionality is orchestrated by
the /bin/webs binary, which we would then analyze further using the methods
detailed in Sect. 11.3.2.
11.3.1.2 Software Version Analysis
Many devices are not designed to receive firmware updates. This prohibits patching
against known security vulnerabilities and can often render a device useless to an
end-user. This prevents abusing the firmware update as an attack vector. However,
when a vulnerability is discovered, the only effective mitigation is to replace the
device with a new one.
Many devices are designed to be updated and vendors provide firmware updates.
However, the mechanisms for applying those updates are often not standardized and
are largely ad-hoc. They also heavily rely on the end-user’s diligence (to identify that
an update is available) and action (to actually apply the updates). The end-result of
this is that an overwhelming majority of devices are left unpatched against known
vulnerabilities. Thus, a further step in the analysis of firmware is to identify the