#badBIOS @dragosr vs Mac, Linux and PC

4: cyb/sec/#badBIOS/ 
30: summary:
. malware that spreads via usb devices
can infect other usb devices,
and the problem is not the os;
it is the hardware and usb standards
which expose the os to malware infection .
. Dragos Ruiu talks about a mac infection
which sounds like the one I got;
it prevented me from reinstalling the os;
and it started infecting my chromebook,
but the chrome os was able to clean it up .
. my 2005 ubuntu laptop was not so lucky .
. a laptop in my future that will likely do well
is one running the xen hypervisor,
hardened with the Qubes OS .
(see #Qubes #Xen vs Dragos Ruiu's #badBIOS).

11.5: co.self/dream: #badBIOS/usb infection is game-over:
. in this dream,
a guy seems caught with mouth open and head thrown back;
and, being colored flat black like hit by a death ray,
it reminded me of usb infection .

11.4: news.cyb/sec/#badBIOS:
arstechnica.com/security/2013/10/meet-badbios-...

Three years ago, security consultant Dragos Ruiu
was in his lab when he noticed something
highly unusual: his MacBook Air, on which he had
just installed a fresh copy of OS X,
spontaneously updated the firmware that helps it boot.
Stranger still, when Ruiu then tried to
boot the machine off a CD ROM, it refused.
. the malware is believed to be
transmitted through USB drives,
and infects the Basic Input/Output System (BIOS),
Unified Extensible Firmware Interface (UEFI),
and possibly other firmware standards .
. the malware can attack a wide variety of platforms,
escape common forms of detection,
and survive most attempts to eradicate it.

Dragos Ruiu 10.23:

. simply plugging in a USB device from an infected system
into a clean one is sufficient to infect.
This was on a BSD system,
so this is definitely not a Windows issue.
- and it's a low level issue,
I didn't even mount the volume and it was infected.
Could this be an overflow
in the way bios id's the drive?
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.

[30: -- suggesting you could fix your usb stick
by going to a .ru site,
and the malware tries to prevent such .]

The tell [consistent symptom of having this infection]
 is still that #badBIOS systems refuse to boot CDs
(this is across all os's, including my Macs)
there are other more esoteric problems with
partition tables and devices on infected systems.
Also, USB cd drives are affected,
I've bricked a few plugging and unplugging them too fast
(presumably as they were being reflashed)
on infected systems.
Unsafely ejecting USB memory sticks
has also bricked them a few times
on #badBIOS systems for clean systems,
though mysteriously they are "fixed" and reset
by just simply replugging them into an infected system.

erratasec.com 2013.10:

. malware can overwrite the BIOS flash memory,
adding their own code that runs on startup.
. the malware theory Dragos proposes
has focused just on the BIOS flash memory,
but there are other places viral code can hide.
Each device in the computer has its own microprocessor,
sometimes called a "microcontroller".
Each microcontroller has its own
flash memory and "firmware",
most of which can themselves be updated.
Examples include:
trackpad, keyboard, battery, SD card reader,
camera, disk drive, bluetooth, wifi, Ethernet,
graphics processor, system agent, and CPU.
That last bit might surprise you,
but an Intel x86 CPU
at the heart of your computer itself
 has an embedded microcontroller,
controlling such things as frequency
in order to conserve power.
While these devices seem diverse,
there are in fact only a few manufacturers
of microcontrollers and flash memory.
Thus, once a hacker has written viral code for one,
let's say the battery controller,
it's not too difficult to extend the code to
also infect the trackpad, for example.
A virus can overwrite any microcontroller flash memory
and stay resident in the system
despite complete wipes of the system,
even wiping the primary BIOS.
The upshot is this:
when a system gets infected by a virus,
the infection can likely become permanent,
being nearly impossible to completely remove .
There's just too many places code can hide,
and too many components that can interfere
with you trying to disinfect the system.
. unplugging a USB stick from an infected machine
and then plugging it into an uninfected machine
will transfer the virus.
This relies upon two important features of USB:
the first is that USB devices contain their own
 microprocessor/firmware (of course),
and the second that drivers are buggy.
There are only a few popular vendors of
USB thumbdrive controllers.
There is a great website "http://flashboot.ru"
that documents all of them.
. they also have software to reprogram them
 to emulate a CD-ROM drive,
making "read-only flash drives",
but you can also use this software to
download new firmware to the flash drives.
Thus, it's pretty straightforward for malware to
overwrite flash drive firmwares .
Once USB drive has hostile firmware,
it can now attack new machines when it's plugged in.
The reason is that software in Windows/Linux/Mac
that talks to USB devices
is inherently insecure.
They assume that all USB devices are friendly
rather than hostile,
and believe whatever these devices tell them.
This allows hostile devices to exploit vulnerabilities
 in driver code.
For example, USB drivers are full of "buffer overflow" bugs.
Let's say that you have a buffer that's supposed to be
less than 16 bytes according to the specification,
but a hostile USB device gives you 100 bytes instead.
Driver writers don't check that sort of thing,
thus allowing a hostile USB device to
take control of the host system.

replies to Dragos Ruiu 10.23:

Edward J 2:59 AM:
I have been owned for 2 years now
[malware has "owned" is computer]
and went through 40 new Mac and PC computers.
I would take them back a few days after I bought them
because they were already hacked by then.
I actually got banned from returning things at Best Buy
due to abusing the policy!
http://wtfisthisapple.blogspot.com
http://hackfromhell.blogspot.com

Douglas Otis:

I ran into this issue several years ago.
Attempts to reflash the Bios
would cause the source media to be erased.
I had to use read-only media to reflash the bios
which was a PITA[pain].
It also refused to boot from optical media.
This was why I felt reflashing was in order.
The different BIOS manufactures all used
 the same vulnerable compression code
 where signature checks were bypassed
by giving the BIOS an evil logo to display. 

Dennis Roos:

So, this is finally happening?
It has been talked about for years ;)
[ pci rootkits, blackhat.com 2007 .pdf *]
In order to capture the traffic on the
USB bus that infects new devices,
have a look at Travis Goodspeed's work on
the GoodFET/FaceDancer board: 

*:
[ here is a summary of that .pdf,
providing some terminology used later:

a rootkit in the system bios via
the acpi (advanced config and power interface):
. the acpi tables within the bios
could be modified to contain malicious
 aml (acpi machine language)
that allowed the root kit bootstrap code to
overwrite kernel code and data .
. intel secureFlash and phoenix trustedCore motherboards
prevent the system bios from being
overwritten with unsigned updates .
. the pci (peripheral component interconnect)
is a bus for attaching pci devices,
graphics cards, network cards, and storage controllers;
the north bridge is connecting
the host cpu bus to the root pci bus;
the south bridge connects the
root pci bus to the isa bus,
and also incorporates the interrupt controller,
the ide controller, the usb host controller
and the dma controller .
. pci speed limits impeded graphics performance,
so then the agp (accelerated graphics port) was created;
likewise, the pci express specification is even faster .

]-blackhat.com

coresecurity.com`BIOS Rootkits:

Traditionally rootkit research has focused on accomplishing
persistence and stealthiness with software running at
the user or kernel level within the os;
The techniques used to run code undetected
have evolved over time ...
A potentially much more dangerous scenario
is that of malware that can effectively
avoid detection and removal because
it has stored itself on the computer's BIOS,
the firmware that runs during the boot process
prior to execution of the operating system itself.
Such malware would resist reinstallation of the os,
and even replacement of the hard disk ...
In 2009 Alfredo Ortega and Anibal Sacco
discovered a generic technique to
modify the BIOS of certain chipsets
so that they could insert homebrewed rootkit code.
The technique is applicable to any computer that supports
installation of BIOS updates that are
not digitally signed using cryptographically strong methods.
-- see Persistent BIOS infection .

Michael Schuh:

 Rutkowska showed it is possible to
make the ACPI-Rootkit undetecteable.
wikipedia.org/wiki/Blue_Pill_(software)
it is even able to manipulate the
bios-settings and much more.

WhirIedPeas [and a reply]:

Malware can run at different layers
on modern compute systems.
From top to bottom; Application level,
user-mode, kernel-mode, boot-sector,
firmware and finally microcode.
To understand the true significance of these levels,
a layperson would first need to understand
the process which occurs
every time their machines boot up:
Power is applied; the BIOS boot program runs;
it's job is to play any microcode updates into the CPU
and find the boot device;
the boot device runs it's boot-sector;
the boot-sector finds the kernel
and loads it into memory;
the kernel starts the first
user-mode process (init or smss);
initial user-mode process
starts up all the processes.
The lower you are in that chain of processes,
the easier it is to control/modify everything above.
[. he suggests the NSA likely has
a CPU microcode rootkit.]
BIOS is a type of firmware,
the most advanced type of firmware in most systems.
There are only a handful of companies in the world
who write these BIOS programs.
As far as resources, you have Phrack #66
which outlines how to create malicious VMware
and Award BIOS, the Maux firmware project,
and in 2009 there was that case of those used Dell servers
which had BIOS rootkits.
PC BIOS/firmware/SMM attacks: 
"BIOS Chronomancy: Fixing the Core Root of Trust
for Measurement" By Butterworth et al. [blackhat 2013]
"Defeating Signed BIOS Enforcement" [Kallenberg et al.]
It was also their "Copernicus" BIOS inspection tool
that prompted this little wild goose chase
(even if experts eventually said
that his BIOS dump looks clean): [mitre.org]

Fábio Olivé Nov 1:

The only common thing you'd have
between all these OSes on modern machines
is ACPI.  Neither OpenBSD or Linux
use the BIOS during normal operation,
except when ACPI and SMM take over
and preempt the OS.
So maybe a possible attack vector would be
ACPI dealing with the USB device before the
OS has a chance to interact with it,
the device exploits bugs in the ACPI
and installs SMM code that will preempt the OS
when it wants, and then hides the
exploit area of the device
so that you won't find anything. 

Thomas Spear Nov 1:

Carlos Ferreira said "How in the world,
can a simple query from the BIOS to the device,
 re-write the BIOS itself? "
By living in the VGA or network firmware.
It can run on either of those CPUs
-- more likely the VGA
since we're already using CUDA et al
to do things like airsnort.
Does anyone know if the Northbridge or southbridge
of current motherboards is reprogrammable?
I believe on AMD systems one of the two is
integrated into the CPU along with the memory controller.
. theoretically, its possible for the malware to
create processes only within the GPU and video memory,
thereby avoiding detection from process lists.
 -- being that Nvidia's CUDA and ATI's equivalent
are OS-agnostic, it's easy to see how this could
 run across multiple OSs .

Virus in acpi Monday, January 10, 2011:

There are many Virtualization techs that do not require VT CPUS;
If you look at linux/mac projects there are many types,
the thing is that some use that tech to make virus.
M$ have many holes, adobe too,
a remote execution bug will allow code injection,
. they use cpu bugs too, they have many ways to get in.
from what I read they can virtualize with only
 600k injected on the bios.
early example: Blue_Pill
. first thing,
your PC uses a simulated efi to boot....,
all your Windows installations use fake components,
fake drivers (all signed, they hack that too).
. here's a must read:
(root kit in acpi/ pic card) [blackhat 2007]
. they use acpi because of the irq
 and that IRQ in Windows work as SYSTEM
 so they own you, a look at your IRQ tables
 and hardware will show it:
look for fake hardware Fireware/usb disabled in bios ...

19: @dragosr updates:

dragosr 12 Nov Things I learned at PacSec: 
8051 keyboard controller CPU core
is nearly universal across all
PC, Mac, Intel, AMD, Via... #badBIOS
dragosr 12 Nov
8051 kb controller firmware
is stored on reprogrammable serial EEPROM.
#badBIOS on Mac messed with
kb drivers, openbsd pckbc errors
xabean 12 Nov
.@dragosr if your #badbios is talking to
8051 MCUs and reflashing them (kbd ctlr),
that's the same MCU in Phison flash ctlrs.
dragosr 12 Nov
Interesting, 8051 cpu core phison flash controller
used in most popular SD cards too. #badBIOS
Akiba shops advertising it as sales feature
zumarek 13 Nov
@dragosr @newsycombinator
so is UEFI and AMT present on
all computers infected with #badBIOS (I think).
dragosr 13 Nov  
@zumarek
nope some are old school award bios boxes, commel le564.
Waiting to get CLCC carrier and flash reader to extract.
dragosr ‏14 Nov
PacSec: Pierre Chiffier, EFI byte code could
easily be used to create hw independent malware (x86, arm...)
analysis complicated, no tools
dragosr 14 Nov
PacSec: Pierre Chiffier, most likely place to
store EFI byte code malware
is the fonts files.
dragosr ‏14 Nov
PacSec: MITRE folks will be putting out
advisories on multiple vulns in SMM
that enable corrupting BIOS and defeat reflashing.
dragosr 14 Nov
Read my last few tweets and
consider again how implausible or not
threats like #badBIOS are.
This industry faces clear, present threat.

30: @dragosr updates:

cynicalsecurity 14 Nov
.@dragosr I think the threat has been around
for a long time except not in mainstream.
Think PacSec 2008: no reactions to my talk...
dragosr 14 Nov
@cynicalsecurity wel maybe there was a reaction and development,
but we are just now noticing it and isolating :-)
dragosr ‏19 Nov
ACPI tools are crude, all I've found so far
are obsd ACPI dumpers. Still looking.
Need ACPI table disasm.
dragosr ‏19 Nov
And before anyone asks
I haven't ID'ed any #badBIOS ACPI stuff,
built ACPI less kernels as test,
not interesting data.
dragosr 19 Nov
ACPI hooks all kind of interesting spots across all OSes.
Tables allow full binary exec.
dragosr ‏20 Nov
It looks like one of the backup copies
#badBIOS keeps around for resiliency
is stored in pagefile.sys on windows systems.
clever/tricky
dragosr ‏21 Nov
One reason #badBIOS is difficult to detect is because
instead of modifying .exe's directly,
it applies patches to prefetch (.pf) files.
aionescu 21 Nov
@dragosr .pf files contain nothing but
timestamps, DLL names, and run counts.
Nothing to "patch".
What you're describing isn't possible.
dragosr 21 Nov 
@aionescu heh,
let's look at those prefetch files
and prefetch functionality
a little deeper, i suggest :)
bellytales 21 Nov
@dragosr @aionescu
literally wrote the book on windows internals.
I think you might be misunderstanding
what .pf files do.
dragosr 21 Nov
@bellytales @aionescu ok,
I know how I would do it. ymmv :)
or maybe I'm wrong. but
seems pretty clear to me.
... ‏and more importantly,
when I killed the pf files,
procmon started reporting info again :)...
for a short time :)
bellytales ‏@bellytales 21 Nov
@dragosr @aionescu Of course, that's normal.
just like all of the other logs.
What you're infected with is called Microsoft Windows.
dragosr 21 Nov
@bellytales @aionescu because google update always
messes with dhcp and interface configurations?
cliffcheney 23 Nov
@dragosr How would I go about imaging a macbook pro firmware?
‏dragosr
Damn fine q. @cliffcheney "How would I go about
 imaging a macbook pro firmware?"
copernicus doesn't run on macs.
zumarek 23 Nov
@dragosr @cliffcheney is this to restore or forensic ?
c7zero 23 Nov
@dragosr can help with that or run from Win bootable USB
snare 23 Nov
@dragosr @cliffcheney flashrom supports many chipsets.
I've ripped a few MBPs with it.
1147700 Nov 24
@snare @dragosr you must
not use chipset when paranoia dumping the BIOS/ME.
chipsets can and will hide sections.
use ext. reader instead.
@dragosr 24 Nov
@1147700 @snare everyone is pointing me at the xeltec 5000
as the programmer/reader to get
1147700 Nov 25
@dragosr @snare what are you trying to dump?
this is an expensive parallel dumper
... for SPI flashes as BIOS/ME
we used a Dediprog SF100, or an openbiosprog
- both in flashrom (where I d go and peek 4 more)
snare 25 Nov
@1147700 @dragosr I used a buspirate for offline dumping.
was a bit flaky, but did the job.