IoT (Internet of Things) and OT (Operational Technology) are the current buzzwords for networked devices on which our modern society is based on. In this area, the used operating systems are summarized with the term firmware. The devices themselves, also called embedded devices, are essential in the private and industrial environments as well as in the so-called critical infrastructure.
Penetration testing of these systems is quite complex as we have to deal with different architectures, optimized operating systems, and special protocols. EMBA is an open-source firmware analyzer with the goal to simplify and optimize the complex task of firmware security analysis. EMBA supports the penetration tester with the automated detection of 1-day vulnerabilities on binary level. This goes far beyond the plain CVE detection: With EMBA you always know which public exploits are available for the target firmware. Besides the detection of already known vulnerabilities, EMBA also supports the tester on the next 0-day. For this, EMBA identifies critical binary functions, protection mechanisms and services with network behavior on a binary level. There are many other features built into EMBA, such as fully automated firmware extraction, finding file system vulnerabilities, hard-coded credentials, and more.
EMBA is the open-source firmware scanner, created by penetration testers for penetration testers.
Project page: https://github.com/e-m-b-a/emba
Conference page: https://www.blackhat.com/asia-22/arsenal/schedule/index.html#emba-open-source-firmware-security-testing-26210
5. What the firmware analysis
• Firmware is the operating system
• Linux analysis techniques can be used quite often and are well known
• Commercial tools are available, but they are expensive and limited
• EMBA has no limits, costs no money and gives the best results
6. The typical workflow
• Do some strings
• Do some binwalk
• Do some find
• Do some regex
• Do a lot google
• Load something into IDA/Ghidra
• Do something
7. EMBA to the rescue
Get the firmware (vendor, hardware)
Extract the firmware (e.g., Linux filesystem, Kernel)
Analyze the firmware
Report all the things
Firmware
binary file
EMBA
extractor
modules
EMBA
analyzer
modules
EMBA live
tester
modules
EMBA final
aggregator
Web
report
generator
Access the
firmware
9. Get the firmware
• Updates from vendor / web site
• Shell access – copy the filesystem via scp, ftp, tftp, nc or to storage device
• Other vulnerabilities e.g., command injection
• Desolder Flash memory and extract the content
• JTAG / SWD
• Communication sniffing (e.g., SPI)
10. EMBA Workflow Firmware
binary file
EMBA
extractor
modules
EMBA
analyzer
modules
EMBA live
tester
modules
EMBA final
aggregator
Access the
firmware
Web
report
generator
12. That was easy …
But what if binwalk fails?
You can try to use other tools like Freetz-NG (AVM firmware)
13. That was easy …
What if there are some deb, ipk, or apk packages in the firmware?
14. The EMBA extraction process
EMBA
extraction
modules
Ext/UFS
filesystems
VMWare
images
Encrypted
images
Special
binaries
Other
systems
Mount &
copy
Mount &
copy
Decrypt
(leaked keys)
Custom
tool
Binwalk
Identify Linux
root
filesystem
Deep
extraction
EMBA
analyzer
FACT
extractor
Identify Linux
root
filesystem
Identify Linux
root
filesystem
OK
Not ok Not ok
OK
15. EMBA Workflow Firmware
binary file
EMBA
extractor
modules
EMBA
analyzer
modules
EMBA live
tester
modules
EMBA final
aggregator
Access the
firmware
Web
report
generator
16. Finally, we have something extracted
Which files and directories are there?
Which binaries, configuration files, …
Which architecture are we dealing with?
Which binary protections are in use?
Which Software versions in use?
Is some outdated software in use?
Which areas are from the vendor, which are open source?
Where are possible weak spots or interesting functions used?
Which kernel?
Are there hard-coded passwords?
Scripting issues (shell, python, php, …)?
Insecure permissions?
Weak configurations?
Public exploits?
Dynamic analysis?
Reporting
EMBA
analyzer
modules
17. Don’t reinvent the wheel
Multiple Linux tools
binwalk
Freetz-NG
FACT extractor
Checksec.sh
CVE and CVSS databases
CVE-Search
CVE-Searchsploit
cwe-checker
GHIDRA
Docker
Radare2
fdtdump
linux-exploit-suggester
OpenSSL
uboot mkimage
objdump
pixd
bandit
progpilot
Qemu
shellcheck
sshdcc
tree
unzip
sudo parser
sshdc
Yara
and others …
See also: https://github.com/e-m-b-a/emba/wiki/Installation#dependencies
19. What the 0day?
• 0day – unknown vulnerability (There is no patch available)
• You have to find the vulnerability by yourself
• The goal of every penetration tester is to find 0days
• 1day – already known vulnerability (Patches are in theory available)
• You have to identify the components with exact version details and match it
against a vulnerability database
• The goal of every penetration tester is to do this automagically and do not
waste time with it
20. Weak binary functions
When using legacy C functions such as strcpy, it’s up
to the developer to make sure the size of the buffer
to be written to is large enough to avoid buffer
overruns. If this is not done properly, it can result in
a buffer overflow, causing the program to crash at a
minimum. At worst, a carefully crafted overflow can
cause malicious code to be executed.
Source: https://rules.sonarsource.com/c/RSPEC-1081
22. Identify interesting spots
See also: https://github.com/darkarnium/secpub/blob/master/Vulnerabilities/Multivendor/ncc2/README.md by @Darkarnium
23. Identify interesting spots
See also: https://flattsecurity.medium.com/finding-bugs-to-trigger-unauthenticated-command-injection-in-a-netgear-router-psv-2022-0044-2b394fb9edc by @stereotype32
25. What the 1day?
• 0day – unknown vulnerability (There is no patch available)
• You have to find the vulnerability by yourself
• The goal of every penetration tester is to find 0days
• 1day – already known vulnerability (Patches are in theory available)
• You have to identify the components with exact version details and match it
against a vulnerability database
• The goal of every penetration tester is to do this automagically and do not
waste time with it
26. What’s the problem?!?
• We are working on the compiled/packed firmware
• Mostly no source code with component versions available
• No standardised format of version details
• No standardised mechanism/parameter on how to get version details
27. Version detection in EMBA
We need a database with regular expressions for the identification of
version details
28. Version detection in EMBA
Static analysis Dynamic analysis
EMBA database with version identifiers
Output generation with Qemu
Output generation with string analysis,
kernel modules, path details
