Friday, September 14, 2018

50% of firmware certs are expired?

So, anyway, I grabbed a bunch of firmware blobs (there were 99, to be precise) that I happened to have on this laptop, in order to look for more rootkit-like thingies, but I found some other bits that I found even more thought provoking, and I got sidetracked. I do have A.D.D. Oh look! A squirrel... (That's a joke, btw)

The first TPT (thought provoking thing) was that 38 of the 99 had certificates in them that said either "Do not trust - xxx Test PK", or "DO NOT TRUST - Lost Certificate", or "DO NOT SHIP - some_company Test KEK". That's about a third, and feels rather high.

It may be that the uploads that we are getting are not completely representative of what the Real World looks like. They might be coming out of test labs or something like that, which is plausible, because you have to be a bit of a geek to extract firmware. The other, and scarier, option here is that it _is_ representative of the Real World, and one in three computers has a "Do not trust" certificate in it. I hope that is not true.

The second TPT was that my program counted a total of 1,377 certificates, and fully 631 of them were expired. That's nearly 50%, and again, seems rather high.

Again, it might be that we are getting non-Real World firmwares being uploaded, but the other option here is that people are not updating their firmware, which seems likely to me.

The third TPT was that 24 of the blobs had a release date of 2018, and still had 42 expired certs in them. That seems weird.

The fourth TPT was that 5 of the 24 blobs from 2018 had a "Do not trust" cert in them. That seems way weird.

I can think of no reasonable explanation for number three and number four, unless they are coming out of labs, but I suspect that the real explanation is that manufacturers are simply not paying attention because no one is calling them out.

It's also a bit of worry that nothing in the firmware chain of trust seems to care about the dodgy certs. This implies, to me, that they could be replaced by out and out APT-level malware, and nothing and no one would notice.

The plot thickens.

The main thing we need is more samples, so if anyone wants to help, instructions about how to dump your firmware are here.

Stay tuned.

Wednesday, August 29, 2018

_Fourth_ Lenovo Rootkit variant

Hi folks,

As our ROM analysis tools continue to improve, we find more "interesting" things. Today, we seem to have found a fourth Lenovo Rootkit variant.

Admittedly, it might not be. It might be just unfortunately named (NovoSecEngine2), but it does seem to share about 97% of the code of some of the other variants, so it looks pretty suspicious.

If you read my other blogs, you will know that two of the variants had 0 detections, and one had a single detection, and unsurprisingly, this one has 0 out of 57 detects.

Again, it's important to understand that I am not suggesting that Lenovo did anything wrong. I think they were completely innocent, and just trying to make their products more secure, and I must emphasize that there is no reason to think any of these are still in circulation, unless someone hasn't updated their firmware.

It's simply instructive that there seem to be four variants, when everyone thought there was just one.

One wonders what else we will find.

Stay tuned.

Wednesday, August 22, 2018

Instructions on how to dump your firmware

Hi folks,

A number of people have asked me how they can participate in firmware gathering, and the short answer is, "Dump your firmware, and upload it to us, at https://armor.ai".

As you might expect, the actual answer is a little longer, so here are the instructions for firmware dumping...

On a Mac running High Sierra, it's easy, because there is a built-in command, eficheck. Here are the steps:

1) Open up a terminal

2) This command saves system's EFI firmware, type:

sudo /usr/libexec/firmwarecheckers/eficheck/eficheck --save -b YourFilenameOfChoice.bin

3) This command overwrites EFI variables portions, scrubbing any privacy-sensitive bits, enabling the image to be shared for analysis, type:

sudo /usr/libexec/firmwarecheckers/eficheck/eficheck --cleanup -b YourFilenameOfChoice.bin

4) upload firmware.bin to https://www.armor.ai/scan

Windows is trickier. There are a number of ways, but currently, the easiest seems to be these steps:

Either, (a) download your own version of ChipSec from https://github.com/chipsec, read the manual, and make your own zips, or (b) Download a version of ChipSec and an EFI shell from my DropBox (my EFI shell is set for an x86 machine)

https://www.dropbox.com/s/hyftzcttq14pm2p/chipsec.7z?dl=0
https://www.dropbox.com/s/7982bi2qrkhkosh/efi.7z?dl=0

and unzip each of those into the root of the thumb drive, and then:
(1) Boot your computer into BIOS, and turn off secure boot
(2) Boot into the thumb drive. This should bring up an EFI shell, that looks a lot like old MsDOS, but is neither Dos nor a Linux shell. It brings up a command prompt that says, “Shell>”
(5) You need to get into the root directory of the thumb drive, by typing FS0:
(I have seen machines where the thumb drive came up as FS1:, and even FS2:, but generally, it’s FS0:)
(6) You should then be able to do a Dir or LS, and see the Chipsec directory, and an EFI directory.
(7) Change directory to chipsec ... cd \chipsec
(8) type: python chipsec_util.py spi dump filename.bin
(9) type: exit

That should allow you to boot back into BIOS, and turn secure boot back on, and then boot to your OS, and upload the captured file to https://www.armor.ai/scan

Be sure to put your email into the webpage, because some analyses take a while, and your email will allow us to send it to you, when it is complete.

Thanks in advance for your help

Monday, August 20, 2018

Three Lenovo "Rootkit" versions?

Hi folks, In 2015, Lenovo was accused of sending out laptops with a "rootkit" in the firmware. Lenovo essentially said, "Ooops... it was meant to be an updater, to help with security. We bought it from a third party, and assumed it was ok." They patched their firmware, and everyone moved on.

Now, I'm not suggesting for even a second that Lenovo did anything intentionally wrong. I think they were completely innocent, and just trying to make their products more secure, but here's where it gets interesting...

To this day, only one out of about sixty anti-malware products recognizes the rootkit as malicious. If you want to check, search VirusTotal for this sha256, d3c154a38823b09edd2e119ecfd8366c2c5e725fda4f744c04e2d26fcc7c5803, and you will see that only Endgame recognizes it.

This particular bit of software identifies itself as "NovoSecEngine2", in the firmware volume, and is 139,512 bytes long. Now that we have been able to analyze a bunch of firmware, we have found two other executables identifying themselves as NovoSecEngine and NovoSecEngine2. NovoSecEngine is 248,832 bytes long, and the second NovoSecEngine2 is 203,712 bytes long.

Guess how many of the sixty anti-malware programs recognize these two...none...zero...bupkiss. No one thinks they are variants of the rootkit.

This means that they are either completely different programs, accidentally sharing the rootkit name, or ... no one has analyzed them.

Our analysis of these two programs continues, and we will post more information as we figure it out, but what this probably really means is that no one is looking at the firmware, and everyone is relying on the "Hope and trust" method.

This, in turn, leads one to wonder how many other programs with rootkit capability lurk in our firmware.

Anything in the firmware is invisible to regular anti-malware programs.

Here are some rough stats from our initial research:

Manufacturers analyzed: {'Toshiba', 'Acer', 'Lenovo', 'Asrock', 'Desenvolvida por Positivo Informatica SA', 'Razer', 'Clevo', 'American Megatrends Inc./Advantech', 'American Megatrends Inc.', 'LG Electronics', 'Dell', 'ASUSTeK', 'Gygabyte', 'Intel', 'Sony', 'Hewlett-Packard', 'Apple Inc.'}

Total firmware analyzed: 550

Total firmware with portable executables analyzed: 515

Total portable executables analyzed: 131289

Total portable executables triggering one heuristic: 20964

Total portable executables triggering more than one heuristic: 3178

Average portable executables per ROM: 254

Average portable executables triggering heuristic per ROM: 40

Average portable executables triggering more than one heuristic per ROM: 6

Now, just because they are triggering our heuristics, doesn't mean they will definitely be bad. It just means that we think they are worthy of a closer look. We will be perfectly happy if all of them are completely innocent, but having been in the anti-malware business for a long time, we suspect we will find some number of Bad Things(tm).

If anyone wants to help, and can upload a firmware dump to us here, we will gladly take a look at it.

Stay tuned, folks, and keep safe.
*** Update: Just in case it's not clear, I don't think these three are currently around, unless someone hasn't updated their BIOS. I think Lenovo took care of it just fine at the time. The point I am trying to make is that there could be lots of other "backdoors" or "rootkits" in firmware, and no one would know. I'm trying to get more people to pay attention.

Wednesday, August 1, 2018

What's in your firmware, and why should you care?

Hi folks, Today, we have officially launched our new site, and product, armor.ai. This is a place where you can upload a firmware image, and get a report on what's in it.

For example, in my 2017 laptop, I have about 380 Windows PE format executables. This is what's known as the Unified Extensible Firmware Interface, or UEFI, for short. The idea is that this mechanism provides a much more flexible way for manufacturers to add new hardware, rather having to modify handwritten assembler, as with a traditional BIOS. This is Good Thing (tm), but they are compiled C code, and this, in turn, is a format well understood by attackers, and defenders, alike.

Fortunately, these programs are cryptographically signed, and are therefore immune to attack... unless...

(1) You can compromise the Root Of Trust. This is the first part of the chain, and is responsible for checking the crypto sig of everything else. This is really hard, and we don't _think_ anyone has done it yet, but we may be sure they are trying, or,

(2) A stolen certificate might be used to sign malicious code, or,

(3) Something malicious might be installed at the factory. It'd never happen, right? Except it already has, at least once, but that's another story.

Extracting a firmware image is mostly complicated, and is not an end-user play, but if you are a geek, and want to know what's in your firmware, there are a couple of ways to get the image.

On a Mac, running High Sierra, you can simply open a terminal, and type "sudo /usr/libexec/firmwarecheckers/eficheck/eficheck --save -b out.bin", and then upload it to armor.ai.

Any machine running Windows 8 or higher, should be using UEFI, and, for Intel based machines, the best approach at this point, is to use Chipsec, and open source tool found here. This requires reading their manual, but is easy enough once you get the idea.

We will make easier mechanisms available as we build them.

Folks, this is tricky stuff, but we need to pay more attention to it, because anything running in the firmware has complete control over the rest of the computer, and probably cannot be seen by anything running at the operating system level. Anything in the firmware is potentially a rootkit.

As well as your own, or your business, computer, think about critical infrastructure devices, medical devices, automobiles, and all IoT devices. They all have firmware, and no one really knows what's in it.

We need to find out.

Tuesday, July 31, 2018

Ok, this was scary

Tonight, I had to file a claim for one of my teenager's phones. It's dead. I called AT&T, and after quite a bit of (perfectly reasonable) back and forth about whether it was a warranty, or an insurance claim, I finally got through to an appropriate insurance person.

In order to validate that I was who I claimed to be, they asked me (reasonably enough) my last four of my social, but then they said, "and, now sir, just a couple more questions, compiled from publicly available information..."

Having been here before, I immediately, and metaphorically, gasped, and the first question was, "What color is your 2007 Chevy Express?"

I answered, "White", and they asked me another, obvious question, which I answered correctly, and the claim went on from there, but...

How the hell did they know that I had a 2007 Chevy Express????

And, they had it at their fingertips!!!!

If you are not seriously disturbed by this, you are not paying attention.

Folks, this is the Privacy Revolution in action.

If you need more, I suggest you read this,, and this, and this.

George Orwell was right. He just got the dates wrong.

:-(

Stand by for more information, and try to stay safe.

Friday, May 4, 2018

Bad Comcast, bad!

So, anyway, a couple of days ago, I decided to hang out a honeypot. This involved logging into my cable modem, to set a DMZ, and then to add a particular IP address into it. This worked just fine, but then I decided to double check what IPs were connected to my modem.

As expected, nearly all the connected devices had an address like 10.1.10.xxx. This was fine, but I was surprised to see a stray address... 30.18.32.173.

By my understanding (and from what I could find on google), nobody other than my provider, Comcast, should be able to connect to my modem from the outside, and yet here was an obvious outsider.

A quick search of who this IP might belong to, revealed that it was a DoD, or military, IP address.

As you might expect, this got my attention, and I started regular monitoring of my modem.

Regular monitoring revealed that there were about six foreign addresses that connected to my two cable modems, some more persistently than others, but, again, by my understanding, no one should connecting, other than Comcast.

I thought, "They must have my password!", so I changed it, and rebooted my modems.

They continue to connect.

I have no way to tell what port, and service, they are connecting to, so I have no idea what they might have been trying to do. This is not a Good Thing (tm).

The obvious answer here is that my modem firmware has been compromised, and I have no way to check that.

This is where is gets nasty.

I called Comcast, to try to get some support.

I first fought my way through the voice activated menus (sucks if you have an Australian accent), and finally got to a human, whose principal task was to sell me an upgrade.

This failed, so he switched me through to tech support.

This guy spoke better English, but after a while came to understand that he had no idea what I was talking about, and switched me through to the next level support.

This guy listened to me, but his response, from which he could not be shifted, was, "We just rent you the modem. Your network security is your responsibility."

I am _perfectly_ happy to make _my_ network secure, but he was immune to my argument that it was his kit, and was actually outside my network.

He basically ignored me.

I still have no understanding of why remote IPs can connect to me, but I'm working on it.

The _really_ interesting thought here is, "If it can happen to me, who else is it happening to?"

If you are a Comcast customer, and want to check, the basic routine is to point your browser at 10.1.10.1, and log in. The default id is "cusadmin", and the default password is "highspeed".

You then go to "Gateway summary", select "Network", and scroll down to select "Connected computers".

If you see any addresses, outside the pattern of your computer addresses, then you have the same issue.

I'm _sure_ there is a perfectly reasonable, legitimate explanation, but I just can't see it yet, and Comcast did crappy tech support.

I would hate to think that the firmware of my modem had been compromised, and that people were monitoring my Internet traffic. That would never happen, right?

Please let me know if you see similar patterns.

The Internet is tricky. Stay safe, folks.