Embedded problems: exploiting NULL pointer dereferences

Your device could be at risk

So we could remotely exploit a NULL pointer dereference if the code is running on a vulnerable architecture?

Barnaby Jack: Yes, if you can write to the NULL pointer with user defined data, this attack can certainly be exploited remotely. In fact, this attack is more reliable than a remote stack overflow, due to the fact that no offsets are required. You will always be writing to address 0.

The only data needed by an attacker is a copy of the vector table, which can be acquired by downloading and reversing the targets firmware, or retrieving the table via the JTAG interface. The vector table will remain static, and will only change with some firmware revisions.

The fact that your attack works without having to guess an offset means that it could be suitable for worms attacking these devices?

Barnaby Jack: As embedded exploitation is still in its infancy, I don't foresee a worm in the very near future - but yes, if a worm was targeting embedded devices, this would be a reliable attack vector.

What type of devices use this hardware?

Barnaby Jack: ARM cores are the most widely-used 32 bit cores in the world. Most mobile phones and PDA's are ARM based. Higher

end routers often use the XScale architecture, while home routers tend to split between ARM and MIPS based cores. In general, if you have a consumer electronics product, there is a high chance it has an ARM based processor.

Some of these devices features very limited resources, so what type of limits are there once you have broken in?

Barnaby Jack: As an example, I gave a live attack demonstration that remotely compromised a popular home router. The shellcode of the remote exploit first cleared the administrator password on the router by patching the password location in memory. The shellcode then set the flag that enables remote administration of the router. The exploit then forced a soft reset on the device. Once the device re-initialized, it was possible to log into the router, with administrator privileges, with no password, from anywhere on the internet.

The remote administration interface allows a remote firmware upgrade. The next step was to upload a modified version of the firmware. The firmware had additional code that would watch for any portable executable file being downloaded over the HTTP port. Once a PE file was detected, the PE file would be patched to include a stub that would retrieve a remote executable and execute the file, before returning to the host executable. i.e.: if a router you were using had been exploited, and the firmware patch was active, any seemingly legit executable download would be infected with a stub that would execute a file of my choosing. The hostile executable would run transparently along with the original executable.

This was a method to ultimately compromise an internal network via the router.

It really comes down to the creativity of the attacker, any device that is connected to a network poses a threat.

Was this example running on one of those cheap (like $100) SOHO routers?

Barnaby Jack: Yes, the example was a popular SOHO router. The same techniques used to exploit the cheaper consumer routers are applicable to high-end routers as well. In my opinion, the ideal attack for routers is a man-in-the-middle attack. The device sits on the perimeter, and sees all incoming and outgoing traffic. In my example, I injected data into incoming traffic to compromise internal hosts - but you could re-route traffic, sniff data, open a shell, the list goes on. Of course, any network connected device can be targeted, a router just seemed like an obvious example.

Sponsored: Balancing consumerization and corporate control




Biting the hand that feeds IT © 1998–2019