
uh good morning everyone and welcome to bides Las Vegas this talk is from firmware to exploit given by Michael mner a few announcements before we begin we would like to thank our sponsor especially our Diamond sponsor Doby and our gold sponsor Prisma Cloud blue cat Toyota it's with their support that and with other sponsors donors and volunteers that make this event possible these talks are being streamed live and as a courtesy to our speakers and audience we ask that you check to make sure your cell phones are set to silent if you have any questions use the audience mic so that YouTube can hear you as well and uh with that let's get started please welcome
Michael thank you very much so uh hello besides Las Vegas great to have you all here and great being part of this wonderful event so the next 20 minutes are around the real world firmware analysis with Amber Amber stands for embedded analyzer and is a fully automated security and vulnerability analyzer for firmare of embedded devices and the best thing on amember is it is open source so right after a talk you can go straight to a GitHub rapo download Amber and start analyzing firr and at the end making the internet of things a little bit more secure so my name is Michael mesner I'm a penetration tester and security researcher at Sean energy and during my
daily business I perform penetration tests on critical systems and environments and this is the area where we developed Amber and where we are using Amber on a regular base but first things first so in today's environments everything is now connected it starts with your private iot at home or better it starts with your iot on your body probably you have a smartwatch the Smartwatch is connected to the smartphone and the smartphone is connected to the rest of the world or you're going to work by car your car gets updates over the air which means over the Internet the traffic lights are connected critical infrastructure highly interconnected if you're working in a big company or in a small company it
doesn't matter your it infrastructure um your OT infrastructure IC everything is connected and on the bottom level there are running these little gray boxes yeah know they are not always little and not always great but they're running some operating system on it this could be in rare cases a full-blown Linux operating system in more cases it is a it is a strip down Linux operating system you will find some real-time operating systems like VX works or in very rare cases you will also find some Windows operating systems um the generic term for this systems is firmware and according to a firmware expert company called eclypsium um femra is the most exploited category over the LA over the
last few years and if you take a look at the Microsoft digital defense report from last year we will see that they found out that 30% more than 30% of the analyzed firra has more than 10 known critical vulnerabilities so from our perspective it is time to take a deeper look at Ferra security but how to start um in my environment I typically have the the real device on the on hand and we are trying to move away from the blackbox only approach to a more gray boxes an analysis Style with fer analysis with the fer we are able to understand the inner workings of the device and we are starting with some information gathering like doing strings
on the firra binary or doing some some entropy analysis we're using wellknown and established extraction Frameworks like unop um we're doing configuration analysis find some files do a lot of research and at the end we try to identify the juicy stuff of the firm we try to find weaknesses configuration errors and vulnerabilities and to understand the inner working of the firmware all of this takes time and um time is typically the um the the limited factor in such a penetration test so Amber think about Amber it is like an an automation framework for firmware analysis so you just need the firmware binary you drop it into Amber Amber extracts it Amber is doing the anal analysis for you and finally
generates a nice and shiny HTML report but how do we get access to the firmware the easiest way is just go go to the window website download the firmware and you're ready to go but sometimes the firmware update files are incomplete sometimes they're encrypted or they're just not there or behind the pay wall so you need other mechanisms to access the firmware um one possibility if you have the device you and you have shell access to the device just copy directly from the device or you can probably use other command uh other vulnerabilities like command injection vulnerabilities that you can exploit and get access to the device another possibility is getting getting access by the hardware you can try to identify
debuging ports like U or jtec you can try to sniff the communication between the flash storage and the CPU because the firmare needs to get transferred to the CPU for execution and finally the more invasive attacks like desoldering the flash storage and extracting the flash storage than via a specialized flashh reader at the end um you will have access to the fir you have the firmare um and now you can start analyzing the firmware and you will have a lot of questions for the firmware you just a few examples um where are the binaries which binaries where are the libraries which configuration files or there other configuration mistakes which kernel is running on the on the system
and so on and so on one of these questions is probably regarding your software inventory the world speaks around Asom um this esom or soft software inventory is really interesting from a penetration tester perspective because there are probably some some vulnerabilities and exploits for free there so at the end you need to identify the software components you need to find the exact version detail and then you're ready to go you can uh queries vulnerability databases like the CV database then you can query exploit databases and you get probably a one day for free the goal for every penetration tester is not doing this manually the goal is that this should happen automatically in the background and
Amber um has a hybrid approach implemented for doing this so first first of all we are trying to analyze a package management system if it's available on the firm room we then use static analysis like we doing strings on every binary or we doing hex stump or um query the kernel modules for the for the exact kernel version and additionally we try to run every binary in an emulated environment we will see it on the next slide and finally we also try to run the whole firmware in an emulated environment we will see this also later on so regarding the emulation of every binary Amber runs through all of the binaries identifies the architecture of
the binary it chooses the Right emulator and then it starts uh with the trial of every binary to emulate it to run it in an emulator with different parameters like minus V minus capital V minus minus help and Amber collects the output that it's generated now and here you can see an example from busy box busy box splits out a lot of output uh with minus minus help and in this output you will also find the version identifier uh we are currently able to detect more than 600 different version identifiers and um we collect all of these version identifiers we agregate them together and at the end we have the software component we have have the um
identified version and now we can start clearing databases like the CV database with the CV database we get the known vulnerabilities with a rating the CVSs score and finally with the CVA identifier we can then query further databases like um the Metasploit database for uh quite stable exploits or the exploit database exploit DP or packet storm or whatever you want and you get a quite good overview of the real world exploit exploitability of the firmare and all of this happens in the background and you're now able to um focus on the interesting stuff so analyze the fare for fresh exploits for Ser day vulnerabilities usually this is the goal of every penetration tester to find
currently unknown vulnerabilities and you want to spend as much much time as possible on this so um I will show you uh little vulnerability we found ages ago in a in a home consumer device it is in the command. PHP file the interesting thing now is that the command. PHP was not interl from the web interface so from a blackbox approach there is the risk that you're missing this file and you're missing a um a critical vulnerability as soon as you have access to the firmware you can walk through the firmware you can find all the script files and you can analyze them and this is quite timec consuming again but Amber can do it also so Amber can use this uh
can check all of the PHP files and use srab for example to do static Source static code analysis and as everything is Interlink on the HTML report you can just click uh on the on the possible results uh for your further teer down and you get direct access to the source code with um the suspicious area highlighted and you can see there that the vulnerability is easy to detect is the CMD parameter is passed to execute function and then it is just executed on the operating system so hooray we have found our first zero day but Amber can also help you in not only help Amber cannot only help you in um um scripting languages it can also help
you in identifying the juicy stuff on on binary level so you can see a typical output from Amber um this is from a firmware that was analyzed a while ago from security researcher and guess in which binary there were the vulnerabilities yes in the NCC binary and Ember checks every binary for legacy C functions like string copy and um if there are Legacy C functions very often used there is the risk that something goes wrong and then we are matching this with with some other POS some other interesting criterias like um is the um like an educated guess if the binary is a known Linux file or is it it is not a known Linux file if not
then it is probably something from a vendor that won't take a look at it then it shows the binary protections are the symbols in the binary and finally um is are the network capabilities in the binary but now we have a a serero day vulnerability we have a binary in the next firra that is quite suspicious but till today or till now we do not know if something of these vulnerabilities or possible vulnerabilities is exposed and exploitable so we thought a while ago um how can we improve this now and we introduced the um full system emulation framework and with this framework we are now able to move away from the static only approach in finding vulnerabilities
to a more Dynamic approach so in an Ideal World we can just boot up the device and we can verify our vulnerabilities we're using a technique that is called Q uh that is called emulation um we're using qo for this and according to Wikipedia an emulator is Hardware or software that enables one computer called The Host which is our for example our Kali Linux um to behave like another computer called the guest the guest is the firra the embedded device and we are now trying to execute code or binaries from the guest from The firmware on our host system on our car Linux system at the end we are trying to boot up the firm um on on a different
architecture with we we are dealing with with a lot of issues is there we have a different architecture we have a different kernel for example and so on and so on nevertheless um it was 2016 where um a research project called thadine showed us that it is possible to um automatically boot up a lot of firmware um to a state where we can interact over the network in 2020 the successor project Firma um improved the success rate massively the problem now is that both projects are not actively maintained anymore and so we thought about this issue and we decided to do a complete reimplementation as Amber modules with this reimplementation we can now um further
maintain our this um emulation engine we were able to improve this emulation engine in multiple areas like we can now we are now supporting more architectures than before and now it is possible to automatically use this full system mode emulation during our firmware analysis during our automated firmware analyses and now let's go back again to our Ser vulnerability that we that we found out a little bit before um we know that there is a vulnerability but we do not know if if the vulnerability is really exposed and we can exploit it so now Amber is doing its magic it is trying to emulate the firmer and it shows us the final emulation state or it tries to to Ping
the or the emulated firra it tries to do an nmap port scan and if there are web interfaces detected it shows us a nice and shiny screenshot of the web interface and we can see that there's a configuration interface probably working because we got a nice and shiny screenshot from it but um Amber is doing much more now and by crawling the whole web interface or the web server for the whole f for all of the F files so at the end we know which files are exposed via the web interface so we can see that uh the command PHP file is exposed by the web interface and now Amber is doing um um crosschecking to uh
if there are further results already available and Emma sees okay we have already a possible vulnerability um identified via our static source code analysis and now you can just again click on it do some manual analysis on there Additionally you can now use this system mode emulation um to further exploit this vulnerability you can write your own proof of concept you can write your exploit for this vulnerability now in emulation without owning the real device and for this talk we thought about um if we should show the exploit development process now in emulation but on the other hand we thought okay then you can see that it's possible but we know that it's possible so probably it
would be much more useful to give you the possibility to not just use one exploit or one proof of concept in your firmare analysis in the future but to use I think more than 2,000 exploits in your fare analysis process in the future so we integrated the Met exploit framework as one of these analyzer modules for the life life testing and now um during our firmware analysis process it is now possible or Amber is doing again some crosschecking um I've mentioned before that we are doing Port scanning on the emulated system um so we can now cross check against the Metasploit database with the default ports we doing crosschecking regarding the operating system and then we're
using the Met blit framework in an automated way to first try to check uh use the check functionality from every module if there is no check functionality available we are trying to really exploit the vulnerabilities and you can see it here that uh the vulnerability the command. PHP vulnerability now was identified and verified with an um successful exploitation attempt at the end you get again a nice and shiny HTML Report with all of the vulnerabilities that we were able to verify um via exploitation and probably the season security guys here can remember the DB toone feature from Metasploit which was removed years ago um this is more or less DB out toone for firmare but in a safe and secure
environment because it is in an emulated environment now so um we've shown now that firmware analysis is not only configuration analysis it is not only generating an as bom it is more an hybrid mechanism it is static analysis it is dynamic analysis and at the end you get a much better understanding of the real world risk of the firal and um last week we have released version 130 from Ember and there we introduced a quite interesting nice new feature the AI assistant firmware analysis so from now on you can also use chat GPD to get a second op second opinion second meaning of the of the possible vulnerabilities so thank you very much I think do we have some questions
now
so most of the discussion was on Linux does this support analyzing other real-time operating systems or other situations other than embedded Linux um so so Linux is quite a nice Target because it can do a lot of an analysis quite automatically um we also support the real-time operating systems but with a limited um anal analysis mechanisms so we are able to generate an Asom for these real-time operating systems we are also supporting um uev analysis via um the FW hunt me um um open source project from Bally um so we are trying to also support other operating systems other than Linux yes all right thank you excellent
work yeah so I'm curious about the dynamic part of the emulation so if you have firmware for an MCU which is not emulated in qmu for an example um are there any future plans for how you would extend it if it's not possible to emulate it at the current time or um yeah C currently if uh qo is not able to emulate it then we are definitely failing MH um and um if qo is able to watch these uh controllers in the future then uh there are definitely uh plans to make it also possibly Amber so we actively maintain the um Firma emulation mechanism because it is so great and so helpful thank you very much it's a very
cool project thank
you so I do need to ask what is the AI assisted Edition so um um we can query chat GPD via the API so um currently we get results from Sam grab and other static source code analysis tools and if you enable the AI assistant mechanism then we upload these files to Jet GPT and ask GPT for an analysis and uh the results are quite interesting and quite good so you get a quite nice uh second opinion on the vulnerability that are already found bya other tools and in the future we are planning to um also include this possibility for not analy static already found vulnerabilities so that we can extend it massively in the
future would it do also with some binary code you showed us uh string copy or this kind of thing and maybe trying to get the assembly around the function to figure out if it's somehow vulnerable we have already we did some tests on with the um with the D compiler from radari 2 but the results were not that good um but probably in the future if the results are getting better then probably we can also do some some interesting analysis via VIA GPT there thank you that's very cool you're
welcome so um you talked about uh binary analysis um what about compressed binaries like ufi measures and stuff can you give us more details on that um um you you mean what analysis mechanisms we using for finding interesting stuff for binary analysis yes um f first of all we are we are counting the usage of Legacy C functions um how many times they they used and this is not by itself a vulnerability but the more often they used the the more likely it is that there are some problems um in there um we are we are testing the binaries regarding um regarding the binary protections we are testing the used functions in the binaries um if there
are functions used that are that are indicated for network activity and um we we are doing some further analysis where we we are generating from every binary uh the whole output by by the strings command and we are analyzing this output for private keys for passwords and um some some other stuff like this so multiple things that we are doing in the background here
no more questions then I think we are ready to go for lunch thank you very much