PG - Firmware Security 101 - Arpita Biswas

I welcome everyone and I'm especially thankful that you guys are here despite all the cool stuff happening outside free beer lock-picking everything a little bit about myself I'm Arpita Biswas I work as a security researcher at Palo Alto Networks I deal in system security firmware security looking at packets network security the whole range of it so and today we are going to talk about firmware security right this is a very weird area it's not Hardware it's not software it's somewhere in between and for many of us including me it was a steep learning curve so if not anything else I hope today that as you walk out you know that yes the stick the running curve is steep

but at the same time here are some ways to get started with it right cool so let's get started first I'll walk you through the outline the system architecture where does firmware fit into this whole hardware software LAN then we'll look at two common flavors of firmware one is bias and then the new version that CBF I will look at a few attack vectors how they attack having seen those we'll look at the defense vectors then we'll go through a few open source tools that I found very handy and finally if you guys want to tinker with the spi chip and try to read and write your own firmware how would you do it and then we'll open it up for

discussions ok so system architecture as you can see there's this layer of hardware that you can you have your laptop your desktops your PC's you open it up you can see the the fan you can see the network cards you can see the VGA and all that stuff on it on the other hand when you interact with it you have the user experience right you have the screen you click on buttons and you interact and make it do things or what you type YouTube videos but between these two ends there are a lot of things that so every time for example you open a dog it goes to the system call which is which is kind of an API exposed for

every for the user applications it then goes and gets all all the components work together to create a file goes to the hardware abstraction layer which then talk to the firmware of your hard drive and says hey listen I need to open a file so give me X Y Z mb of date of memory space in it and this dance happens back and forth every time we interact computers but the most crucial part that we're going to look at today is the firmware and and it sits closer to the hardware but it still interacts with the software so it bridges both these worlds the first your bus bias is basic input/output system and I'm pretty

sure a lot of us have seen the screen do a lot of blue text hunting our childhood but but behind this there's a series of complex dance that happens so when you power on it goes and fires up the circuitry for your spy chip which is serial peripheral interface this chip holds your first instructions that is executed after the power switch is on so this pi chip loads all the instructions it has on it into the CPU registers at a particular preset address and that's called as the CPU reset vector that's huge hexadecimal number out here once since then there's a kind of an inventory check that's done on the chipset right so it's called post

operating self-test post sorry power on self test and at this point the all the guy is trying to do is that okay I have 10 things on on my chipset which of them work which of them and was the error and set it up for the rest of the code to take over then we have the CMOS this is the second piece of non-volatile memory that's in your chipset it holds information about your BIOS as in three operating systems to boot which of those it's to be booted right away is what the BIOS I mean CMOS holds about the buyers then having known which operating system to load it goes ahead puts all those instructions at 7000 boots up gets

everything ready for the operating system and you can log in so roughly these are the four or five steps that happen on a BIOS moving on what oh by the way we are looking at the spike at one of the taxes on spy chip the second attack will be on the CMOS chip so keep in mind going on we have then coming up was the newer generation of firmware which is unified extensible firmware interface sure things have been tried so so bias is a very monolithic piece of code right which has preset address and everything so it started getting bloated up with all the legacy code then you have if I happen and we had a snazzy Oh

screen but behind this we also had a couple of newer options it was to then buy us it's more secure you have an option to pre verify what firmware images before you execute them kind of making it a bit more secure so similarly when we power on the SP I check loads on boots up sets of the code at the secure stage then it goes and does the inventory check which is the pre efi stage then we have the driver execution engine this is another crucial part here the driver execution engine doesn't care how you initialize it it says ok I see a ouija I see a network card you go guys go ahead initialize and come back to me

with the error code if any or let me know if it's working so it's completely agnostic of what's happening inside the initialization code and hence it decouples the form variations then we have the boot device being selected from the CMOS like in BIOS then the instructions are now executed in a secure shell called as the UEFI shell which is which has limited memory protections then the OS bootloader comes in page up every sets of the paging and the protection and everything and finally we login so between bias and you similar except that it's more blur and you have an option to do pretext before running those eggs firmware images having seen these two let's look at a few attack vectors first

how these are commonly known as evil made attacks and requires you to reflash the bios on your spy chip how do you do that sometimes in some chipsets the right protection bit is off or it's partially right protected not the entire region is right protected and then you also have physical access to the chipset and you use something like a pirate or a deadiy program in a board max which is something like this this is a deadiy prog by the way dairy prog with a flash clip bus pilot with the flash clip should we have my own setup here too you guys can take a look at it later on but this and read and write your firmware on

the chipset provided your right spy chip is not right put it now since this can this comes in at such a low at such a starting point any any changes to the firmware and henceforth makes everything very persistent stealth very difficult to remove and hence making it very difficult to detect as well the next vector now access to the chipset so you can still do a remote BIOS update there's a mechanism for it you just hack it so you have a laptop you download your device where update on to onto your laptop but then that's a malicious piece of update well nobody cares and then the BIOS goes ahead and marks the CMOS bit as the update bit as on and

says hey listen the next time you reboot the firmware sees the CMOS has the buyout update BIOS update bit set so it says ok I have an update pending goes ahead triggers an SMI so what's an SMI SMI is system management interrupt and it's a mode where you even bypassed the operating system and has higher privileges than operating systems and that mode is called as the system management mode so enters the system management mode there are absolutely almost zero checks so you can then go ahead and agree recompile your BIOS that bias update in the sm ram which I mean SMF also has a area pre allocated for the BIOS updates to happen and that's known as sm ram and finally

you boot and nobody is any wiser because it was a like regular BIOS update so this attack can happen remotely now coming to the third attack this particular attack is only four we have five systems because this hooks on to the driver execution engine how so we okay by the way this was seen in the wild as and we have seen a few malware's which are the are key loaded types like the previous download the infected payload on the day then we modify the UA eyes CMOS bit and also the dxz bit so so remember in UEFI the DXE says okay here are the ten cards I need to initialize I don't care how you do it similarly it

goes the the malware goes ahead and attaches itself to as the eleven initial initialization module and it says that okay so when you boot up the next time instead of booting up the regular NTFS hard drive which has a the the good operating system boot up mine and that has a bad operating system and now that you have booted up you have no way to know whether in the in the good operating system or in the bad operating system so this was another commonly another attacks pretty interesting in my opinion but having seen these attack vectors there are ways there's still some ways to make sure that or at least to know how bad the security is in your

chipset so let's look at a few defensive approaches first please make sure that you have your bias and system passwords on so that anytime anybody tries to update your box you have to manually go in put in the bias update I mean sorry bios password and only then update your machine sometimes some other boards come also come with chassis intrusion detection that is if you if someone has opened your box in the production graph and put it back again the next night there's an alert saying that there was a someone open the chassis and if then you know that something's wrong and I better check also ensure that you spy your admirers boot blocks your SM Ram all

these non regular memory locations are right protected there is absolutely no reason for them to be right protected then you can also use tip that I will talk about in a minute to figure out how good or how bad your platforms security is if you are using UEFI please ensure that secure is on and boot guard is on so secure boot and boot guard and nothing but a check so every time you you load the next set of firmware instructions it goes ahead and checks but ROM matches the one that's on that that's supposed to be and if it is or if the right one only then it goes ahead and boots her so if you want to look at

up sec the tool that I just mentioned super youthful series of Python scripts you can also check whether your platform is or yeah look at chipset dot pi it's an by the way it's an open source tool that is available I'll share the links later on it also has tips like util dot PI which triggers a few exploits and a few other tools to do memory analysis and analysis of the firmware that's dumped out to check whether your bias is right protected or not this is one of the commands it checks whether and the SM Ram Society the spy and the alternate buuut block is there or not then you can also use SM Ram checks so whether the SM

Ram is right protected in with the entire region or not so it's something that looks like this see the bias right enable should be off and bias lock enable should be on and this is a back if your bias is not right it will show this huge remarks at the bottom check s mmm they're similar I would strongly recommend playing with it it's a very nifty and very cool set of tools that I found so overarching all of these there are a few guidelines that probably everyone should follow if your desktop or your system is one of those crucial ones always remember security so what you need to do is first thing ensure that the buyer that the the BIOS has

only local updates mechanism possible there's no way updated once you've ensured that make sure that the firmware update elf is stamped as in nobody can there's only one way to update the BIOS and that should be it there should any other bypasses third thing once you know that you want to update make sure the firmware update that you're giving is a pre verified authenticated digitally certified however there's a verified piece of software then ensure that there is only one SP the whole region is kind of right protected so that there's no passing around to write to it finally anti rollback protect so what have your firmware update in there shouldn't be a need for you to rollback or use the

backup because there has been attacks which used as malicious with malicious code and then later reboot up reboot using the backup boot up so that's there's no need for that right so so yeah and final if you want to still play with firmware having known all these attacks and defense vectors I use flat um that's an open sore with Linux you can read you can see that this bus pirate so sync up with I brought hello one no okay this is a and right to the flames but the firmware on your spy chip oh these are the connections to it the clips it's and this is the bus pirate that actually programs and this USB n

sticks to your dev machine which is where you have your recompile bios on it so now some open source tools we google has this huge branch they their Chromebooks use core boot which is an op firmware they have a payload called C bias which is specifically for BIOS flavors then we have Tiana core which is for UEFI flavors we also have chipset like we meant saw a few examples before then we have flash rom it comes as a default in most of the Linux distributions nowadays we also have UEFI parcel that does a good job of if you give it up unknown UEFI image it will parse out all the the ROM and the efi header and and the MCH

and all those bins in it we also have minnowboard max that's another tool that's use and buzz pirate like we just saw

okay so now let's open up or any questions and answers if you still have any crystals left alright anyone have questions raise your hand oh I think the wait for the mic if you still want to read up apart from the open source links here like we have there's one time when I tried to use a SPF like flasher I had to desolder the chip before it would actually write to it a lot of times when you just try to clip the chip directly it will power on other components that would try to tamper our way like tamper with the chip because you are essentially powering on the other components that is reading and writing

to the chip at the same time have you had that problem at all I'm just gonna carries lots and a lot times so hello yeah so many times chipsets have their own write protections or their own country and it's completely secluded so you sp remove the chip from but that are also a few jumper cables on the chipset so if you

[Music]

yeah so you have a few right predict jumper cables around if you take them apart or used easier to hack chipsets like wool Chromebooks so they do a good job of keeping their core boot code updated with their chipset settles do you recommend trying to verify the existing firmware that's on a device's if it's already been compromised and if so how would you go about doing that sure you should do that in both cases when you want to just verify if everything is all right and also have a backup of your firmware before you try to write to it so that it can restore and so what you do is you read out the fubar dot rom put it into flash rom and

then you can extract out the MRC dot bin the rom dot bin and all those sides and give it to chipset so chip stick does a good job of passing through the binaries and checking whether the the the right protection bits are on in BIOS or if it's in there some RAM and all that stuff you chips ik has a way to verify roms that you just pass on as a parameter the chipset will actually pull off in some method the existing firmware and do a comparison to the file that you provided know what it will do is it will ensure that the right protection bits are on but if you want to verify the

shock you either read out the char from the TPMS on the chipset or contact the OEM or the manufacturer for verifying

thanks for the talk I think you did a good job considering your mic issues you really yeah yes now this working I think there's ghosts in the wires can you trust data returned by the SPI from the ship you're reading like is that like returning of data is that handled by the firmware itself or is this like a pure Hardware thing or could you potentially mess with that if you managed to infect the firmware so every time you read out from the firmware there's a small chance that you have corrupted it and all that you have read out a bad firmware so yes those things happen and the way to verify it so if I

get a question right if you want to take out firmware and verify that's the right firmware which is on the chipset is that what you asked yeah so assuming that what's on the spy chip is correct there are corruptions that happen when you copy out the way to verify that is either you do it two three times and verify that the Shai is right now assuming that what's on the spy chip is also not right then then we have bigger troubles but but the image so let's say you read out three times the Shah of all the three times without any rights to the spy chip should be the same and that's how you verify

I'm reading out the image what I think he's asking is the firmware itself's not involved in reading out these image from this via spy so barring a whole nother level of exploit against like the mask ROM the chip which is unheard of as far as I know you can trust what you actually read out via spy so a spy yeah the the BIOS has a header and you just read out according to the header parameters on there which is what the flash rom and bus pilot details but yes if your firmware itself is bad then you better and not look at it based on his question I just wanted to know if there's like a database that you can

download and just verify while you're offline or if there's a database something like virustotal that you can just upload your firmware and just know what's happening that was my first thing my second thing was if for some reason I believe that has been compromised let's have a company how would I go about to just trying to go back and trying to do like forensics like firmware wise so as far as I know there is no virus total database for farmers yet but if you follow UEFI parser there are a few dumps out there which mat coreboot has a few there's a guy called John Lewis who has a few roms out on a sample internet

but there's no official database of firmwares the second thing is if how can you do forensics on firmware updates I would track the CMOS bit the CMOS registers because that's where all the BIOS settings are and if anybody has tinkered with it remotely it would be in the CMOS registers but if you have local access like there's no bias password or there's no badging in into your lab machines then I would first make sure that local access is restricted and then in monitor the CMOS register bit for activities all right I think we're out of time for questions ok I'll be hanging outside so feel free to come up [Applause]