Future of Malware??

Martyr

very interesting
from an administrator view, of course..you should read this stuff.
malware development is reaching new levels every year.

Explaining security vulnerabilities, possible exploitation scenarios, and prevention in a systematic manner, this guide to BIOS exploitation describes the reverse-engineering techniques used to gather information from BIOS and expansion ROMs. SMBIOS/DMI exploitation techniques—including BIOS rootkits and computer defense—and the exploitation of embedded x86 BIOS are also covered.

BIOS-Disassembly Ninjutsu Uncovered

there hasn't really been anything like this before.

one chapter in Greg Hoglunds breaking code book about a "hardware virus" which discussed some possible ways to write "cavity infectors" for hardware devices that had eeproms..but little or nothing on BIOS exploitation.

another good paper released recently was Implementing and Detecting a PCI Rootkit

of course, if you were developing operating systems, at a low-level, you would probably know all this stuff already.
and there is plenty of driver source code in linux to play around with..

NutJob

Crazy stuff but i dont see this going mainstream (but i could be wrong):)

Martyr

Crazy stuff but i dont see this going mainstream (but i could be wrong)

well, i would agree with you there, too.
With Vista being released next year & EFI replacing the BIOS, it wouldn't be very easy to write a virus that is portable across all systems.

EFI will support SMBIOS & ACPI though, so..there is still potential to use ACPI as attack vector.
same bloke wrote a paper on that as well..here

the paper about PCI rootkits is very good, what it says in a nutshell, is that all PCI devices have potential to store embedded code inside its ROM. Which can be flashed by user of computer (providing they have appropriate privileges)

each device has an optional ROM header, where it has details of the devices configuration.

For example, most, if not all PCI graphics cards would have embedded 16-bit real-mode x86 assembly code, that when executed by the BIOS would hook INT 10h (Video Services)

EEPROMs could have 64K bytes of storage capacity.
optional ROM code might only take up about 50% of this, leaving a cavity of 32K bytes, which is plenty for malicious code to remain undetected without proper detection tools..(anyone know any that exist, publicly??)

Even DVD/CDRW devices have capacity to store malware.
But again, different vendors use different microcontrollers & usually the datasheets are only available from the manufacturer after signing non-disclosure agreement.

while you could dump the firmware to disk, you then have the problem of identifying what type of assembly code it uses & what chip it runs on.

of course, you can look inside for model-number and google it, but sometimes you can never find anything about the chip.

if its just 1 specific target, then there is no reason why this PCI method (and others) could not work, providing the attacker has good understanding of the architecture.

only time will tell though.

monkey tennis

NutJob wrote:

Crazy stuff but i dont see this going mainstream (but i could be wrong):)

Not for a while, at any rate. But once one skilled hax0r decides to experiment with this, the door will be open for all the skript kiddies to copy and modify his/her methods. If general OS security/user intelligence improves to the level where it's easier to infect hardware (yeah, right) then this method could become more mainstream.

Definitely interesting though..... (ok, we need a shifty eyes smiley)

Capt'n Midnight

monkey tennis wrote:

Not for a while, at any rate. But once one skilled hax0r decides to experiment with this, the door will be open for all the skript kiddies to copy and modify his/her methods. If general OS security/user intelligence improves to the level where it's easier to infect hardware (yeah, right) then this method could become more mainstream.

Definitely interesting though..... (ok, we need a shifty eyes smiley)

If the BIOS controls the onboard NIC then you could simply instruct it to look at the ethernet frames that come through and have the BIOS write data to the boot sector / last track on the HDD. So the BIOS rootkit can be told what to do regardless of any software firewall / OS on the machine. And you don't need to know the IP of the machine, as it checks packets as they arrive and leaves the upper layers to the code it pulls down. Unlikely but with something like 1 in 10 PC's being DELL's with Broadcom NIC's you could hit a lot of machines fairly easily.

Or something like that.

Also to watch out for are many corporate PC's can have their BIOS updated by SNMP management utilities. And you can kill BIOS's by flashing junk or worse by setting a higher voltage than the chip can take. Really bad DoS

Martyr

If the BIOS controls the onboard NIC then you could simply instruct it to look at the ethernet frames that come through and have the BIOS write data to the boot sector / last track on the HDD. So the BIOS rootkit can be told what to do regardless of any software firewall / OS on the machine. And you don't need to know the IP of the machine, as it checks packets as they arrive and leaves the upper layers to the code it pulls down. Unlikely but with something like 1 in 10 PC's being DELL's with Broadcom NIC's you could hit a lot of machines fairly easily.

exactly what i was thinking
in my college, they buy DELL pcs in bulk, most of the machines have the same hardware.(not that i'm gonna try doin anything to them)

alot of people seem to buy from dell too.

Black Swan

Average Joe wrote:

the paper about PCI rootkits is very good, what it says in a nutshell, is that all PCI devices have potential to store embedded code inside its ROM. Which can be flashed by user of computer (providing they have appropriate privileges)

EEPROMs could have 64K bytes of storage capacity.
optional ROM code might only take up about 50% of this, leaving a cavity of 32K bytes, which is plenty for malicious code to remain undetected without proper detection tools..(anyone know any that exist, publicly??)

Blacklight rootkit scanner? (free)
www.f-secure.com/blacklight

Martyr

Blacklight rootkit scanner? (free)
www.f-secure.com/blacklight

i don't know if it detects PCI rootkits, but i would doubt it.
low risk of getting a rootkit in your pci devices, isn't it?
the potential is there though.

NutJob

The anti-malware research has made some strides in the past year or two with tools as Joe has mentioned which all seem to work as lie detectors.

These methods although can be best described as heuristic are effective at identifying unusul application behavior when a piece of Malware attempts to hide its disk footprint and the more stealth used the more likely the Malware will turn up.

Obviously this starts to break down when looking at Worms like Code red which had no disk footprint and now the possibility of using a polymorphic loader stub(if a stub is actually needed) and leaving ur code burned into an eprom on a network card etc.

Makes for a good evolution of rootkit technology but some of the methods both in implementation(then modified by Av companies for detection have the potential at best for some blue screening by buggy code and at worst bricked hardware.

The most like likely solution to this will come from hardware vendors blocking this kind of access to devices with a physical jumper but only time will tell on this one.

Martyr

here is a good list of current anti-rootkit applications.

Obviously this starts to break down when looking at Worms like Code red which had no disk footprint and now the possibility of using a polymorphic loader stub(if a stub is actually needed) and leaving ur code burned into an eprom on a network card etc.

in the pci specification 2.1 document it says the following on page 219 about ROM header extensions.

The standard header for PCI Expansion ROM images is expanded slightly for PCcompatibility.
Two fields are added, one at offset 02h provides the initialization size for
the image. Offset 03h is the entry point for the expansion ROM INIT function.

Offset Length Value Description
0h 1 55h ROM Signature byte 1
1h 1 AAh ROM Signature byte 2
2h 1 xx Initialization Size - size of the code in units of
512 bytes.
3h 3 xx Entry point for INIT function. POST does a
FAR CALL to this location.
6h-17h 12h xx Reserved (application unique data)
18h-19h 2 xx Pointer to PCI Data Structure

assuming an attacker would insert control to his code using a JMP/CALL at the entry of the INIT function (not using Entry Point Obscuring), then current av methods (including pci device enumeration) would probably be sufficient enough to detect most malicious code.(unless they use metamorphic code)

or indeed overwrite the ROM header, if possible.

The most like likely solution to this will come from hardware vendors blocking this kind of access to devices with a physical jumper but only time will tell on this one.

these were apparently present in the past on some devices, but not in recent years, maybe good idea to bring them back..

Capt'n Midnight

Lets not forget all the other devices on your network , most can be flashed and most network printers have hard drives. HTTP/SNMP/TFTP are ways into them.

Martyr

Lets not forget all the other devices on your network , most can be flashed and most network printers have hard drives. HTTP/SNMP/TFTP are ways into them.

i did not know printers had hard drives..
i'd imagine all the internet enabled appliances of the future to include similar features.

NutJob

I can see it now malware flashing ur linksys with openwrt images with tons of nasty scripts. (could be done today)

Gets even better when its flashed over wireless and turns into a brick

Nearly worth a POC