Firmware Integrity
Firmware Integrity
The custom firmware and/or compiled binaries can be uploaded to exploit integrity or signature verification flaws. The following steps can be followed for backdoor bind shell compilation:
The firmware can be extracted using firmware-mod-kit (FMK).
The target firmware architecture and endianness should be identified.
A cross compiler can be built using Buildroot or other suitable methods for the environment.
The backdoor can be built using the cross compiler.
The backdoor can be copied to the extracted firmware /usr/bin directory.
The appropriate QEMU binary can be copied to the extracted firmware rootfs.
The backdoor can be emulated using chroot and QEMU.
The backdoor can be accessed via netcat.
The QEMU binary should be removed from the extracted firmware rootfs.
The modified firmware can be repackaged using FMK.
The backdoored firmware can be tested by emulating it with firmware analysis toolkit (FAT) and connecting to the target backdoor IP and port using netcat.
If a root shell has already been obtained through dynamic analysis, bootloader manipulation, or hardware security testing, precompiled malicious binaries such as implants or reverse shells can be executed. Automated payload/implant tools like the Metasploit framework and 'msfvenom' can be leveraged using the following steps:
The target firmware architecture and endianness should be identified.
Msfvenom can be used to specify the target payload, attacker host IP, listening port number, filetype, architecture, platform, and the output file.
The payload can be transferred to the compromised device and ensured that it has execution permissions.
Metasploit can be prepared to handle incoming requests by starting msfconsole and configuring the settings according to the payload.
The meterpreter reverse shell can be executed on the compromised device.
Meterpreter sessions can be monitored as they open.
Post-exploitation activities can be performed.
If possible, vulnerabilities within startup scripts can be exploited to gain persistent access to a device across reboots. These vulnerabilities arise when startup scripts reference, symbolically link, or depend on code located in untrusted mounted locations such as SD cards and flash volumes used for storing data outside of root filesystems.
References
For further information check https://scriptingxss.gitbook.io/firmware-security-testing-methodology/
Last updated