Slashdot Mirror
Hiding a Rootkit In System Management Mode
Sniper223 notes a PC World article on a new kind of rootkit recently developed by researchers, which will be demoed at Black Hat in August. The rootkit runs in System Management Mode, a longtime feature of x86 architecture that allows for code to run in a locked part of memory. It is said to be harder to detect, potentially, than VM-based rootkits. The article notes that the technique is unlikely to lead to widespread expoitation: "Being divorced from the operating system makes the SMM rootkit stealthy, but it also means that hackers have to write this driver code expressly for the system they are attacking."
And I toggle it to disabled. Problem solved?
i have norton, problem solved.
Oh boy, I love ridiculously overly dramatic BS! Yes it's very easy for it to hide there and for there to be basically no signs that it's there. OMG everyone run for the hills! Oh wait, malware doesn't just sit there, it does stuff. It runs threads, it reads from and writes files on the hard drive, and it has to at some point send some sort of data over the internet or local network. So yeah, no virus can hide and still cause damage and spread while remaining undetected.
Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
With all the security issues that we hear so much about, I have decided that one potential way of avoiding most of them is to run a liveCD distro of whatever OS when working with sensitive data.
I do all my internet banking via freeBSIE now - yes it takes a veeeeery long time to boot, and I know that it doesn't solve ALL of the problems but it has to eliminate enouogh problems to be a viable solution.
Agree / disagree ?
Interesting, but I heard of this technique at the Ekoparty 2007 conference (link), in a talk given by Rodrigo Rubira Branco (BSDaemon), so is nothing new in the security field. Except if there is a working proof of concept this time.
In theory, SMM is the ultimate rootkit hiding place. In practice, it's difficult to exploit on a wide scale. Getting the system to execute rootkit code in SMM isn't easy. You're going to need an exploitable BIOS bug, or the ability to reflash the ROM. Either is going to be very system-specific.
Lets say you are an evil terrorist hell-bent on infultrating the American military and wrecking havoc.
It seems to me that this would be exactly the sort of thing you'd look for. Military machines are specced very precisely, you'd know exactly what hardware was on the system so drivers wouldn't be much of an issue.
All you'd have to do is sneak your code in here once, and the timebomb would be ticking for when you want to activate it. Yeah, it wouldn't be easy to get it on there, but it means breaking through once allows you to lay a trap for another time. That sounds pretty serious to me.
What about vulnerabilities in onboard IPMI cards? Our new servers have ARM-based cards running Linux. The built-in HTTP server is vulnerable to a widely-known buffer overflow:
landonf@ahost:~> telnet XXX.XXX.XXX.XXX 80Trying XXX.XXX.XXX.XXX...
Connected to XXX.XXX.XXX.XXX.
Escape character is '^]'.
GET
Connection closed by foreign host.
landonf@timor:~> telnet XXX.XXX.XXX.XXX 80
Trying XXX.XXX.XXX.XXX...
telnet: connect to address XXX.XXX.XXX.XXX: Connection refused
Seems like a recipe for compromised data centers, to me. Re-imaging a machine won't touch the IPMI card.
http://plausible.coop
Obviously I don't like hearing about nasty, or potentially nasty, vulnerabilities in common systems; but these sorts of situations do seem like an argument for more openness in computer systems, right down to the dark, embedded corners. Particularly with these dark, embedded, corners taking on more and more functions. If you can pull stuff like this with the BIOS, I hate to think what a full EFI setup could be doing(particularly if the OEM enthusiasm for shittastic bundleware reaches that level of the system). Time and again, we see that we cannot trust what we cannot verify.
This has already been discussed about two years ago. Basically you can't carry it out because every chipset blocks write access to this memory part by doing a complete remapping of the memory layout in hardware. Together with a very short list of mainboards where the developers forget to set up the necessary flags through the BIOS code.
In system management mode, the processor runs code from memory (SMRAM) that can't be seen by the operating system. The usual way of handling this is to map the SMM memory into the address space at 0xa0000 - that is, where the legacy graphics framebuffer is. Normal accesses to this address space are redirected to the graphics card by the northbridge. In SMM, accesses to this address space are diverted to real memory and the magic code is run.
Obviously, it has to be possible for the BIOS to put code their in the first place. There's a configuration flag in the northbridge (on recent Intel chipsets, it's byte 0x9d of the PCI configuration space on the host bridge) that controls whether accesses are directed to the graphics hardware or physical memory. The BIOS can set that to do the initial setup. Once it's done that, the bit is flipped and normal code can no longer see the SMM code. The vulnerability lies in the fact that OS code could reset that bit, gain access to the SMRAM and modify it. Any BIOS I've seen from the past couple of years has gone a step further and set an additional bit that prevents this from occuring. Once that bit is set, the only way for normal code to gain access to the SMRAM region is for the machine to be reset. This happens before any OS code gets run, so there's no opportunity to install hostile SMM handlers.
Is it still possible to exploit? Yes. If the attacker can modify your BIOS they can modify the code that it copies into SMRAM. However, if the attacker can modify your BIOS then they've already won even without using SMM. The initial bootloader uses BIOS calls to read data off disk, so a sufficiently intelligent attack could rewrite that in order to boot a modified kernel. In versions of Windows before Vista, most graphics drivers still made BIOS calls. A modified BIOS could do anything it wanted to with those without looking suspicious in the slightest. Like the article says, it's unlikely that this'll be common. But to be honest, I don't see it happening in the real world at all.
(Today I have been trying to work out just WTF a Dell laptop does when it enters system management mode in response to a brightness hotkey press. The locking down of SMRAM makes this effectively impossible)
The problem with the "invisible to antivirus" argument is that it assumes the system is pre-infected. To root a remote system you need to get the code onto the system and execute the software that puts it in SMM, and during that process any anti-virus is able to inspect it. The question is will the anti-virus heuristics or signature-based methods actually catch it?
TFS says the code must be specifically targeted to a particular machine which, on a PC, means a very big challenge.
On a Mac, however, you could easily target a very large number of people using only a very small number of hardware variations. Could this exploit be better suited to Macs than PCs? On the other hand, it also seems like it would be equally easier to detect the problem, since your algorithm can be fairly specific (both in terms of Macs and PCs), since the code needed to exploit would be rather specific.
Science Museum of Manitoba, eh!
Infuriate left and right
Forgive me if there is such a thing but it seems to me that HW vendors should be providing some sort of AV type program that runs at startup. For example I use a Toshiba Satellite A30 laptop. At startup it should spend 60 seconds running a scan and acting / reporting appropriately.
There would be requirements for updating and such but this can be worked out.
Is there such a thing already? And if not - is it possible to do?
I quess I should feel lucky.
It strikes me that Interrupt 19 is a heck of a lot easier to use and not hardware dependant providing that the CPU is any version of x86 and int 19 isn't disabled. Curiously, most CMOS, even modern ones, leave int 19 wide open by default so it can reboot the system without clearing memory or restoring interrupt vectors. How easy is that?
Have a look at General Software's Firmbase technology. They are using the SMM for lots of crazy stuff - a tiny OS is running in SMM mode. It is interacting with USB, network adapter, serial ports etc. It has a web server, telnet server, snmp server... It is possible to get a prompt on serial port to poke the hw registers, memory, cpu registers etc while the main OS is running and doesn't have a clue what's going on. This comes very handy when developing drivers for such systems, but if some evil bios engineer would add an exploit to SMM, nobody would figure out where to look for it.
Because (and I do think that windows started doing this too) Linux uses the BIOS to boot minimally and then drops BIOS completely.
Does this either
a) stop a BIOS call being issued
b) reset the BIOS completely
I think, because the SCSI BIOS is rerun too, causing your devices to be reassigned, that it is the latter.
What scares me, is this, in regards to what YOU stated, here:
.avi internally & plays it back, from INSIDE of the .scr file no less, making it "1 moving part only" basically):
"You're going to need an exploitable BIOS bug, or the ability to reflash the ROM" - by Anonymous Coward on Sunday May 11, @09:47PM I've thought about that for years now, + mentioned in discussions just like this one on various forums I have attended over time
HERE is how I would go about it (not that I would), thru this combination of fairly easily done techniques, which I have used before in programs, & list an example below? It's PROBABLY do that!
(In a "blended threat" type of virus/trojan/rootkit/spyware etc.? DOABLE!)
For example, tools by ASUS &/or GIGABYTE (& probably other vendors) allow BIOS FLASH thru Windows (& probably for LINUX too by now, but you LINUX folks tell us more on that note)...
So, that said & aside?
What says a Virus/Trojan/Spyware/Malware-in-general can't use that tech too?
I.E.-> It's NOT THAT HARD to store ANYKIND of file (including BIOS image data, OR another program, say in the case of malware? A driver) or data inside an application as a runtime extractable + even memory resident (instead of disk) resource, & run a program over it + use it from memory even...
E.G.-> I do it inside this app (stores an
----
APK Doctor Who ScreenSaver 2008++ v. 1.0
http://www.drwhodaily.com/community/index.php?s=4c91394a4eeba63a7acde25e70dbbe64&showtopic=386
----
AND - the same basic idea & technique could be done via a virus, albeit for nefarious purposes!
Simply by using what's noted above, for flashing a PROM whose data it stores internally (BIOS IMAGE FILE + possibly a PnP loadable driver) & probably via the use of a driver stored internally as well as a runtime extractable & useable (Plug & Play dynamically loaded drivers DO exist on Windows, not sure on Linux though) as well!
& voila: FLASHED BIOSES FROM A VIRUS!
Think about it...
(The code's out there for BIOS flashing WHILE IN WINDOWS no less, in legit tools so far @ least afaik ONLY!)
BUT, I saw code for that @ ROOTKIT.COM no less, but I can see it being hardware specific (BIOS specific actually in this case, bios flashing viruses etc.) - still, doesn't make it "undoable" though. Far from it...
& the technique I extoll of storing even BIOS IMAGE DATA (or other programs, even drivers & use them) inside of any program (virus/trojan/rootkit/spyware etc. et al) is not difficult to do @ all, because of resource storage programs use...
APK
You are being MICROattacked, from various angles, in a SOFT manner.
So... when you disagree but use a whole paragraph to point out that what you were disagreeing with actually has merit... does that make you sound smart?