Jump to content











Photo
- - - - -

BadBIOS


  • Please log in to reply
22 replies to this topic

#1 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 14 October 2013 - 02:18 PM

This may or may not be worthy of being in its own thread. I post this here only because of the similarities with the "strange malware" mentioned here.

 

Came across something interesting. Sounds similar to this particular mystery malware from this thread... except for that re-writing to the installation media thing. A user on Twitter (who seems to be well known to others, especially since they talk to @ioerror who has been interviewed by the media before, so he seems important) :unsure:

 

Anyways, this guy Dragosr ran across some BIOS level malware that survives a flash (not everything is replaced by a flash so no surprise), and has a "hypervisor" inside, restricts boot devices and re-writes files in a Windows OS. This particular behaviour reminded me of this thread's mention of a VM kept in the BIOS. Surely these things are possible? And yet, even this particular BIOS virus has its own outlandish behavioural claim, that it can use wireless without a wireless card being installed! This thing I am not familiar with, they use a term "SDR" to reference this.

 

 

 

...and that's not even interesting part. Seems to have a BIOS hypervisor, SDR functionality that bridges air gaps, wifi card removed.

https://twitter.com/...512915742937089

 

 

 

Copernicus BIOS verification. Also if tool is mysteriously failing or weird output full of FFs you may have problem. *

http://www.mitre.org...sumptions-about

https://twitter.com/...521551693217792

* Original tweet contained shortened URL, posted full URL for posterity's sake.

 

**WARNING**

Supposedly this link is to the captured BIOS ROM file. I have not confirmed. Also, there are complaints that Mega requires flash to download and works best in Chrome. So some of you may wish to use a VM to get this file. Also, I have not heard any confirmation that this file is what it is purported to be.

 

 

Friend put this link up(thanks). I didn't pick the site. It would be nice to understand what/who is behind this. https://t.co/zP3vEH8ITX

 

This URL I can't actually get to. In Iron it reroutes to this:

https://mega.co.nz/#!NV82CYwb!H9grtBJo5su_6jop1sOQRB2x_816h9YarEcq3I8Lvi8

I have downloaded this file, it is a tar.bz and is 7.7MB.

Original tweet:

https://twitter.com/...773435284787200

 

EDIT: strings list:

https://malwr.com/an...zlmNzYwMjEwNjM/

 

Lastly, another tweet that relates to BIOS tools, for those who might be interested.

 

 

@newshtwit To dissect the @dragosr image you first have to cut it apart with info from ich_descriptors_tool (flashrom) or ifdtool (coreboot)

https://twitter.com/...812191933018112

 

EDIT2: I can't open the bin file in any of my BIOS tools. :(


Edited by Tripredacus, 14 October 2013 - 04:42 PM.

  • RFC Rudel likes this

#2 AceInfinity

AceInfinity

    Frequent Member

  • Team Reboot
  • 228 posts
  • Location:Canada
  • Interests:Windows Security, Programming, Customizing & Crash Dump Analysis.
  •  
    Canada

Posted 14 October 2013 - 08:51 PM

Hmm, odd. Perhaps another relevant link: http://corelabs.core...ate_the_Rootkit

Some important bit of text:

show that the software mechanisms to protect the agent embedded in BIOS from tampering and re-flashing are insufficient to prevent malicious attacks if digitally signed BIOS updates are not enforced by the manufacturers as is the case in computers deployed globally as of 2009.



#3 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 15 October 2013 - 03:23 PM

It is true. After looking at the infected.bin file, I was surprised to see that there was a security certificate in there. I've looked at a few BIOSes in my time (mostly in recent years) and had not seen one before. However, the fact that a BIOS update may not overwrite everything isn't a foreign concept. Especially in these UEFI days, some BIOS manufacturers release separate update files for different areas of the firmware. As an example, on notebooks with an AMI BIOS, they have separate files for the main BIOS and another one for the ACPI 2.0 tables.



#4 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 31 October 2013 - 06:10 PM

New topic "badBIOS" has been created, splitting the original messages from http://reboot.pro/to...trange-malware/ after post #20

 

Let's get to the bottom of this.

 

:cheers:



#5 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 31 October 2013 - 09:05 PM

This "strange malware" dubbed BadBIOS was posted about on Ars Technica today:

http://arstechnica.c...-jumps-airgaps/



#6 RFC Rudel

RFC Rudel
  • Members
  • 7 posts
  •  
    Argentina

Posted 01 November 2013 - 05:47 AM

My experience whit malware bios that use paravirtualization/hypervisor and have many self-defense’s (compromising optical media, and OS during install) work a very low level.

They don’t need to disable os tools, they give you false data, a disable of regedit or any other tool will be like show itself up (a complex malware using that? It may get some other malware that the compromising one allow in), the key to this type of malware is reinfectionon on reinstall and to be almost undetectable.

On the subject on spread using RF, I would say no way, but this are not car engines that can be taken apart…,so I try get an open mind.
How about Broadband over power line using the psu…… (They don’t think about that one….)

Write or wrong about this type of malware the problem is the lack of tools.



My sincere apologies to the community, I promise to keep whit the other tread and I fail to deliver, I was a disrespect to this community invitation.

Edited by RFC Rudel, 01 November 2013 - 05:50 AM.


#7 dencorso

dencorso

    Frequent Member

  • Advanced user
  • 142 posts
  •  
    Brazil

Posted 01 November 2013 - 07:48 AM

The technology seems to be RTL-SDR, which must be already present in the machine and active, for air-gap bridging to be possible, AFAICS...



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 01 November 2013 - 10:15 AM

I don't know. :unsure:

Some of the claims/hints/whatever seem credible, some much less.

On one hand if the report came from a "common user" it would be discarded instantly as FUD, on the other, a security expert/analyst can produce much more focused/detailed reports/whitepapers/studies than what the good Dragos Ruiu has posted (here and there).

 

This piece of code allegedly can:

  1. hide itself into BIOS
  2. hide itself into UEFI 
  3. hide itself inside USB stick controllers
  4. hide itself into network cards flash
  5. hide itself into audio card/controller
  6. hide  itself into Windows 8.x fonts
  7. spread itself through USB sticks
  8. spread itself through speakers/microphone
  9. affect Windows (7 or 8.x) operation
  10. affect Mac OSX operations
  11. affect BSD operations

each of the above, taken by itself, is of course well possible, but all 11 "features" (and possibly even more that I missed) all together into a tiny piece of code are tough to believe.

As well, it is "queer" the "cross compatibility" on very different (unspecified) hardware and Operating Systems.

And - as a side note - such a "smart" whatever can seemingly be easily detected simply because it makes the machine not able to boot from CD anymore and/or creates (unspecified) "esoteric problems with partition tables".

 

I personally - besides any possible amount of truth/reliability on the guy's reports - do not like his generic attitude towards our Russian friends:

Infected systems seem to reprogram the flash controllers on USB sticks (and cd drives, more on that later) to attack the system (bios?). There are only like ten different kinds of flash controllers used in all the different brands of memory sticks and all of them are reprogrammable, so writing a generic attack is totally feasible. Coincidentally the only sites I've found with flash controller reset software, are .ru sites, and seem to 404 on infected systems.

 

Coincidentally I find a lot of USB stick low-level controller software on Chinese sites (besides the .ru ones), and the 404 may be a 12th feature :ph34r: a form of browser hijacking. :w00t:

 

From the very scarce preliminary reports, it seems to me a bit too much.

 

:cheers:

Wonko



#9 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 01 November 2013 - 02:19 PM

I agree with the "unbelievability" and also (like the other "strange malware") there is little actual information except for people talking about it. I only know one other person on Twitter who claimed to have gotten the BIOS from Dragos to spread on his own PCs, the other people can't replicate. No pictures, no videos yet.

 

Here is a video that shows SDR in action.



#10 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 01 November 2013 - 03:05 PM

There is nice presentation from 6 years ago on a related topic: https://www.blackhat...-07-heasman.pdf


  • Tripredacus likes this

#11 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 01 November 2013 - 03:12 PM

I have uploaded the BIOS dump file referenced in the first post here to reboot.pro:

http://reboot.pro/fi...bios-dump-file/



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 02 November 2013 - 06:50 PM

Just for the record:

http://www.rootwyrm....lysis-is-wrong/

 

:cheers:

Wonko



#13 dencorso

dencorso

    Frequent Member

  • Advanced user
  • 142 posts
  •  
    Brazil

Posted 02 November 2013 - 07:30 PM

:worship: You sure do rock! :1st:



#14 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 03 November 2013 - 11:10 AM

Recent article: http://blog.erratase...ml#.UnYs3kC6NvI



#15 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 04 November 2013 - 04:17 PM

Just for the record:

http://www.rootwyrm....lysis-is-wrong/

 

:cheers:

Wonko

 

Just for the record, the guy who wrote that article didn't even open the infected rom file. However, it did lead me to a BIOS tool that could open it.

 

Spoiler

 

A bunch of files found in kit.gz, which was a large file uploaded to Mega. Not sure if this information is worth anything.

http://pastebin.com/EG6g58VJ

 

The kit also contained those TTF fonts. Someone decided to check them all out:

https://gist.github....heck_result.txt

 

I didn't save the link to the kit. :( But here are some dumps from something...

http://pacsec.jp/cookiejar.zip

 

Since everyone wants dumps. http://pacsec.jp/cookiejar.zip  md5 31ef92aaf55c2a1ccc419bb7d6f4291b - procmon CSV of their uninstall, and quiet after

https://twitter.com/...448446171963392



#16 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 05 November 2013 - 03:15 PM

Here is an article which talks about hard drive stuff gleaned from an infected system.

https://plus.google....sts/bop8ufrMp7s

For those without Google+ here is a quote:

 

 
TGZ of DD dumps of compromised #badBIOS obsd system with variant disk sections

http://goo.gl/G0Mz4w

the naming syntax is:
d[block-size or 512b if no block size][skip amount in blocks]

(if there is no block size it meand dd default 512b)

those are all dds from same drive, on the affected system running in ramdisk

Note diff results based on skip, and that the drive reurns all nulls except MBR if you start reading from beginning

The interesting ones are the ones aroung skip=104216 bs=512b
especially the first ones that returned ~64k... the disk returned all nulls with reads beginning earlier in the disk than that.

x2 means the second time I poked at that region(it changed though somehow these dumps don't seem to reflect that, odd)

(sorry don't recall why I called the e# dumps that, it turned out to be insignificant)

dtgz md5 44ec7b2259210dd6e7075b98768e8daa

files less than 1M thats all dd returned, large ones i truncated
The drive was a Seagate Momentus 7200.2 500Gb traditional disk.

On those DD's infected BIOS complained that the drive was not bootable. (had to fdisk update the boot sector and rebuild the partition table which returned all nulls from within the infected boot system to be able to boot from CD and extract the images)

The reason I'm doing this from within the infected system is that external analysis of infected drives on non-infected systems previously seemed to yeld nothing interesting on the drive or the boot sector. Though I haven't checked starting reads on funny sections of the disk yet with an extracted drive. I will check this drive with funny reads from an infected system reading on an uninfected system next to compare.

cheers,
--dr

 

 

Another fellow looked at some stuff. Not sure what it is so maybe one of you guys know:

https://twitter.com/...452554537156608



#17 RFC Rudel

RFC Rudel
  • Members
  • 7 posts
  •  
    Argentina

Posted 05 November 2013 - 08:52 PM

I agree that cant be all claims true, false positives are always there

But the compatibility and standards can be used to exploit holes (acpi tables for example)

Edited by RFC Rudel, 05 November 2013 - 08:55 PM.


#18 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 06 November 2013 - 03:58 PM

As with RFC Rudel's virus report, lack of duplication amongst researchers have led to skepticism on whether or not this actually exists.

http://arstechnica.c...malware-claims/

To be sure, I doubt that anyone had tried to apply the "infected" BIOS to their own computer. :lamo:

 

The above link has one to Reddit saying where to get the stock BIOS from.

http://www.reddit.co...ing_sdr/ccpw67k

 

I did a compare from both the BIOS tool and a hex editor showing the small differences.

strange_compare_zps098850f7.jpg

 

Note: Windiff can't read hex so doing a compare on the BIOS files themselves isn't very helpful.

Here is the "difference" as seen in the hex editor

hex_compare_zps532a91d5.jpg

There is one other big difference. The BIOS file from Dell does not have the Thawte Consulting security certificate in it.

 

EDIT: picture of the cert references:

thawteHex_zps1466a4a6.jpg


Edited by Tripredacus, 06 November 2013 - 08:33 PM.

  • AceInfinity likes this

#19 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 06 November 2013 - 08:30 PM

Interesting information arriving each day.  :)



#20 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 08 November 2013 - 03:45 PM

I'm pretty much done with what I can do with the actual BIOS files, here is my closing thoughts on that. (I may take a look at the Kit next)

 

Here are some other strings from the infected1.bin that are not in the stock BIOS.

sal.policy
prtc.offset
ACLE_ENTRY_4
ACLE_ENTRY_3
ACLE_ENTRY_2
ACLE_ENTRY_1
ACLE_ENTRY_0
net.tls.Configuration
Data.Provisioning.State
ME_CFG_WRK
AppRule.0D
HCIMeUnCfgState
WOP_primary
LastKnownCpuComplexId

Unfortunately, this doesn't actually prove anything, neither does the Thawte certificate. I have some thoughts just on this BIOS alone that I will share.

 

1. This BIOS is from a UEFI 2.3.1 capable Dell/Alienware system. I do not have access to this type of hardware, but do have access to other brands that use the same base BIOS model... that being Aptio EFI. There are similarities in BIOSes from different hardware because they use the same base, but it is the individual manufacturers that often must make them different and applicable to that hardware. As is common amongst ODMs is that they take shortcuts. I run into it all the time where the ODM will make their BIOS and still have the default values in SMBIOS and ACPI fields, rather than following their respective specifications. For an example, GUID blacklists exist because ODMs do not always generate valid UUIDs for their hardware, or maybe the SMBIOS field containing the Manufacturer or Model might just say "To be filled by OEM" or "Type2-BoardProductName1" or "Notebook." This is the case with both the Infected and stock Alienware BIOS. As compared to an Asus BIOS, except for the PeiMain index, no other Indexes in the BIOS update are named in the Alienware bin. While the Asus BIOS does not label all of the indexes, at least 50% have names.

 

2. I have no actual experience with looking at a BIOS of a system that has an active AMT or IME. The stuff I deal with has those items either disabled or unconfigured. Without having the ability to see what a BIOS dump of an AMT or IME activated system, there is no way to determine what a BIOS dump from that type of system would look like. And because we are dealing with specifics, a comparison BIOS dump would be needed from another system of the same model (AMT and/or IME activated) that was not infected and on the same BIOS version. This is a requirement for proper comparison.

 

3. Dragosr had used the Copernicus BIOS tool to dump the Alienware BIOS. This isn't the only BIOS dumper available and we have no comparison data whether or not there is any deviation or difference between dumping tools. And I already know that the Copernicus tool is fairly particular about what it works with. It does say this someplace (readme or the program itself, I forget) as I was not able to use it to dump an Intel BIOS.

 

4. BIOS updates typically do not write to all sections of the firmware. That being said, it is expected that a firmware dumped from a system has differences with the BIOS file from the website. This could mean that the string list posted above, or the Thawte certificate is part of the original firmware flash that is on the chip when installed at the factory.

 

5. And lastly, we so far have not seen any BIOS specific information such as SMBIOS and ACPI entries. When we're talking about standard BIOS locations (that malware would certainly take advantage of) we are talking about these places. While they may exist at different memory locations, their locations and what data is supposed to be in them are contained in their respective specs and standards. Its obvious from both the dumped or website BIOS that this information isn't in either of these files. It was already pointed out that there is no mention of Dell or Alienware in either file and this is true. It is possible that Copernicus doesn't grab this information, and typically a stock BIOS update does not change this information unless needed.



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 November 2013 - 04:50 PM

4. BIOS updates typically do not write to all sections of the firmware. 

So, a typical BIOS update that will be dd-ed on a 1 Mb chip and that is 1,048,576 bytes in size typically won't write to all sections?

 

Interesting news. 

 

:cheers:

Wonko



#22 RFC Rudel

RFC Rudel
  • Members
  • 7 posts
  •  
    Argentina

Posted 10 November 2013 - 06:35 AM

The problem is how you can trust any dump from the compromised system.

 

And the lack of tools and proper procedures to show a low level malware end up in sharing a story.....

 

Credibility is a mayor factor when you are unable to get the smoking gun.



#23 Brito

Brito

    Platinum Member

  • .script developer
  • 10616 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 December 2013 - 12:49 PM

BadBIOS is becoming a self-fulfilling prophecy regardless of being real in the first place or not: http://arstechnica.c...audible-sound/#!


  • Tripredacus likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users