Hacker News Reader

Comment by ddevault | Hacker News Reader

It doesn't seem to have been mentioned on the forums, which is alarming, but the correct response to finding out your machine has been owned is to shut it the fuck down. Right away. Then boot up a rescue CD, which will have a known working system (read: not compromised), from which you can do some forensic work to find out how you were owned and what data is recoverable.

Take the data you can recover offline and then reinstall from scratch. Don't try to fix it, just recover what you can and throw the rest away.

View on HN

> from which you can do some forensic work to find out how you were owned

It's worth noting that if you are really serious about doing forensics and investigating the attack, then shutting down can be pretty destructive.

> what data is recoverable.

Another point I'd make is that try to recover as little as possible from the infected system and prefer using clean backups instead.

I agree on the overall sentiment though, attempting to recover a infected system is unnecessarily risky. Nuke it from the orbit, it is the only way to be sure.

I may be wrong, but these days doesn't malware have a loader (which has a hook in the boot cycle at some point) and a payload (which usually poses as an innocent file tucked away on your system somewhere). Even if you wholesale recover your data and include the payload, there is no loader hooked into your newly-installed system, rendering the payload a digital bullet without a corresponding gun. As far as I'm aware, infecting your MP3s or JPEGs was more something ye olde worms did, no?

Trying to make distinctions like this gets you back to "figuring out how you were owned", i.e. determining the transmission vectors and threats.

The reality is that decoders for complex file formats often have buffer overrun and code execution flaws. If such mechanisms were used in the original attack or if the malware has worm-like abilities to extend the attack from your compromised machine, then wouldn't it me likely that more such corrupted data is also being staged to your machine?

Also, a very real risk would be the huge number of little scripts and configuration files which offer embedded scripting syntaxes. A naive victim might think they can install a new OS and just "recover their custom configuration files", but they are really recovering the attacker's configuration which can include the actual malware activation or other fail-safe reinfection mechanisms.

The loader hook could well be in your .profile. Or the infection vector could be a naughty PDF just waiting to be thumbnailed again after a reinstall.

Could you elaborate are you referring to a specific PDF vulnerability? Could you share a link to it? Thanks.

This should do:

> In the first demo, I just select the PDF document with one click. This is enough to exploit the vulnerability, because the PDF document is implicitly read to gather extra information.

> In the second demo, I change the view to Thumbnails view. In a thumbnail view, the first page of a PDF document is rendered to be displayed in a thumbnail. Rendering the first page implies reading the PDF document, and hence triggering the vulnerability.

> In the third demo, I use my special PDF document with the malformed stream object in the metadata. When I hover with the mouse cursor over the document (I don’t click), a tooltip will appear with the file properties and metadata. But with my specially crafted PDF document, the vulnerability is triggered because the metadata is read to display the tooltip…

https://blog.didierstevens.com/2009/03/04/quickpost-jbig2dec...

There were wormable vulns in both ffmpeg-thumbnailer and Gnome’s thumbnailer in the past months.

So you shouldn’t trust that this doesn’t happen again.

well, when wannacry was around, you could "salvage" the decryption key from an infected machine before it was rebooted.

not saying your idea is bad advice but you need the full picture to counter ransomware attacks

Ironically, /dev/mem has been disabled to counter malware, otherwise you could do

    dd if=/dev/mem of=~/mem.img

to obtain an image dump which may contain the decryption key.

You could kexec a new kernel that didn't have that restriction.

And if you are paranoid, don't wait for proper shutdown, but pull the power plug. Don't bother with the network plug, pull the power plug right away. Some powners don't like interrupts and have a nice easter egg in the shutdown or network down procedure, e.g. erasing stuff you might not have backupped (which, I am sure, you have, right?).

> It doesn't seem to have been mentioned on the forums, which is alarming

Really?

>> Best thing to do when dealing with this kind of stuff is disconnect the network, cold reboot off a livecd and and go from there.

>> That means that they got root. You can't clean that up, its a reinstall. [...] If you want to do forensics, make a disc image of the install and work on that. You need the filesystem free space too, as that's where the interesting stuff will be.

Even better - make sure that everything is under version control or backed up so that in such a situation you can just reinstall from scratch without introducing the possibility of "recovering" infected files.

There’s still the possibility that the infected files have been already committed to version control or backups, before it activated.

In which case you just roll them back to a pre-infection state, since you have history.

great! with version control, you can see line-by-line where that infection was added... and when it was committed. Good!

As a developer, my laptop could blow up at any point and I’d lose very little of importance. Maybe an hours worth of work at most.

My real concern would be them grabbing secrets, not losing any data.

Reply on news.ycombinator.com