Secure boot [LWN.net]

Secure boot

Posted Feb 20, 2013 9:36 UTC (Wed) by man_ls (guest, #15091)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by drag
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

I don't think that secure boot is a big improvement. For me (I want to run Debian on my machines) it is definitely more trouble than it's worth. Perhaps if you want to run stock Red Hat on stock hardware -- and that is the point: vendor lock-in. So thanks but no thanks.

For the record, cleaning up an 0wned machine can be very instructive. I have had the pleasure of doing it on one client's machine and it was a very interesting experience: from the trojaned SSH to the spam sender to a script that (I suspect) tried to flood the connections of any white hat that tried to recover the machine (e.g. me). And as a bonus, something like 50 GB worth of vuln scan data gathered by the machine in its free time. After a huge upgrade, several scans and some very basic cleanup the problems have not resurfaced. Perhaps the intruders were not very good at their job.

to post comments

Secure boot

Posted Feb 21, 2013 16:46 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

There is no way for you to know that you cleaned up that machine properly.

That's the problem.

It's one thing to screw around with a 'owned' machine for your own bemusement, but it's quite another to actually get it to a point were you know it is secure.

With a kernel level root kit you must not trust any user space tools. This means that any sort of checksum utility or package checking feature provided by RPM or apt is completely worthless. Any anti-virus or root kit checker is completely worthless. Any access to any compromised binaries can be intercepted and redirected to their 'proper' versions. Payloads, directories, and volumes that potentially contain many GB of data can be easily hidden completely from the root user.

None of this is 'special' or '7331' features. This is very routine stuff that is common to inject and use in any compromised machine.

For example I help a friend try to clean up a Windows XP machine.

In this particular case I believe it was a web exploit that caused the attacker to get access to the machine. From that point they installed a rootkit that subverted the NT kernel. From what I read it installed a driver into the kernel using APIs provided for the file systems. It created a secret subvolume in the main C drive that allowed them to install and run whatever they wanted.

Exploit leaded to root kit. The rootkit then would download various payloads that would try to do things like send spam or try to gleam bank passwords and such things.

These 'payloads' would be what would be noticed by the user. Their google searches would get all screwed up. Or the anti-virus would notice changes to the system binaries and such things. You'd run the ant-adware or anti-virus utilities that various websites would recommend you to use to remove this or that troublesome software and that would work.. but you'd never hit the rootkit.

Then some days later the rootkit would just download and install some other malware.

So people's machines would seem like they would get compromised over and over again, but it really only needed to happen once.

> Perhaps the intruders were not very good at their job.

Perhaps the intruders didn't give a crap if you detected them or not.

Or perhaps they thought the administrator was incompetent enough enough that they wouldn't notice and that when you did notice they changed their approach to something more secretive.

Really the only appropriate action, unless you are seeking to press charges or something like that, would be to wipe the server and restore it from a known good backup. Anything else is a disservice to yourself or the people you are trying to help. Cleaning up manually may help or may not. It's really impossible to be sure.

Cleaning up a compromise

Posted Feb 21, 2013 17:32 UTC (Thu) by man_ls (guest, #15091) [Link]

You have a point, of course. But it largely depends on the context. An absolute like "there is no way to know you succeeded so better wipe the whole machine" can be true if you are working for the NSA. In this particular case the crackers just wanted to send their bloody spam from the server; they were not interested in anything else. In fact we were getting lots of abuse reports, which stopped after the cleanup. It is possible that the spammers still had another backdoor into the system (besides the compromised SSH binary), but why would they enter the machine and not send any more spam? In this case the proof is in the pudding.

Rootkit detectors are supposed to work well, at least in Linux. It is an arms race between them and rootkit developers, but in this case my money is definitely on the good guys. On Windows it is probably harder to be thorough.

On my personal desktop machine I would be much more paranoid. On this particular web server wiping it out was more trouble than doing a cleanup, and by the way the customer wanted it this way. Perhaps a poor excuse, but good enough for me in this situation. So I am not going to advice anyone else to clean up a compromised machine, just to consider carefully your options.

Secure boot

Posted Feb 22, 2013 13:30 UTC (Fri) by ekj (guest, #1524) [Link]

You can boot to a known-good rescue-system from a usb-stick or cd-rom or whatever, and use the tools there to scan your system.

Ofcourse this is only good if you trust your bios to actually load what you tell it to load, but that's true with secure boot too: if you don't trust your bios to load what you tell it to, then there's little reason to trust the same bios to correctly implement secure boot.