Attacking Sandboxes
SkiifGeek writes "Many anti-malware applications use a sandbox as a tool to help identify potentially malicious software. Now knowledge is spreading about techniques and methods that can allow sandboxed software to target the sandbox itself (and by extension the application that applied it). While attacks that specifically target sandboxing applications are probably a little way off, this technology can be considered the logical extension of techniques and procedures to identify the presence of hosted systems (VMWare, Virtual PC, etc.)."
That malware detects VMs is old news. I'd wager about 60% of current malware has VM detection built in. About as many have debugger detection. Some overlapping allowed.
So far, malware that "breaks out" of the sandbox would be new to me (though I'd be grateful for a sample). Though, seriously, why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.
If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Malware's built-in detection makes hell of the casual e-sleuth's investigation techniques, and there seems only one sure-fire way to make sure malware behaves as you wish; keep it on a real system. I'm mostly speaking of network-oriented malware (ie: botnet clients), where you don't really care so much about what goes on with the infected system, so much as what occurs during the control/attack phase.
So, does anyone know of a particularly home-friendly way to handle a real-hardware box? I'm not sure of the best way to do this, but I assume it may simply require a CD/DVD that boots windows, instead of re-imaging the drive every time you want to test something new (which sounds quite...painful).
It's all layers of useless crap piled on top of eachother which doesn't stop the real problem of people falling for stupid fishing sites, and entering a password in a site that looks like their bank's. If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
When the real layer is equally insecure, how will you know you have reached it?
Isn't once enough for anyone? You did format and restore from a known good backup or install media afterwards didn't you? There's a tendency lately to trust that whoever had full control of your PC did nothing but run a set script and blindly hope that there is nothing else on there. I've played with various removal tools when people have given me compromised machines and different tools gave me different answers the other tools could not detect - perhaps there were some things neither could detect, hard to be sure especially when you are booting from a compromised system.
Fdisk it from orbit - it's the only way to be sure.
How does prevent the existing real time man in the middle attack?
e.g. user visits phisherman's site, phisherman's server visits bank, passes on RSA auth request to user's browser, user's browser passes auth request back to phisherman, who passes it to bank. Phisherman now logged on as user?
I remember when Lotus 1-2-3 had code designed to crash if was run with debug.
One line blog. I hear that they're called Twitters now.