Boffins unveil SSD-Insider++, promise ransomware detection and recovery right in your storage

A team of researchers claim they can make SSDs impervious to ransomware attacks by detecting infections and reverting unexpected encryption within a matter of seconds, at the cost of a small increase in latency. The group includes engineers from South Korea’s Inha University, Daegu Institute of Science and Technology, and the …

[0x80004005]

Bin dun before...

Great, does this mean we can bring back VMS's semicolon operator?

MYFILE.TXT;1

MYFILE.TXT;2

It would never overwrite a file, instead, it gave you a new version ;2 ;3 etc.

The PURGE command would then kill off the plethora of old versions.

[Gordon 10]

Re: Bin dun before...

You misread the article. Thats exactly the command as it exists in the SSD firmware ;)

[Ian Johnston]

Re: Bin dun before...

That's the feature of VMS which I miss more than any other. I'd pay good money to have it available on Linux.

[Norman Nescio]

Re: Bin dun before...

I get something like it by using the NILFS2 filesystem. It has some downsides (no ACLs, for example), but I have been using it for years. Convert checkpoint to snapshot, mount snapshot read-only, recover previous version of file going back as far as the circular buffer allows. Of course, it might not be suitable for your particular use case, but I landed on it after looking for VMS-like behaviour with file versioning.

It is a pity that btrfs and bcachefs apparently can't do the same. I would love to be shown to be wrong.

NN

[JBowler]

Re: Bin dun before...

Nope. You could overwrite files in VMS - you just needed to know how (it wasn't, isn't, difficult).

[Mike 137]

"Unfortunately, this new feature may not be foolproof"

This is a neat idea conceptually. However if widely taken up, technologies such as this could also lead to rapid escalation of the threat, as perpetrators often have access to significant expertise and can counter relatively narrowly specified mechanisms quite soon after they are implemented.

I suspect that the strongest protection is still not allowing ransomware (or any other malware) to enter the organisation in the first place (or at least catching at or near the boundary before it gets a hold). It's interesting that the Jericho project didn't persist, or lead to widespread changes in the way we protect our infrastructures. De-perimeterisation never really took off.

[Gordon 10]

Re: "Unfortunately, this new feature may not be foolproof"

It's not a panacea but as part of a multi-layered defense I think it may have more value that you are crediting.

[Warm Braw]

Re: "Unfortunately, this new feature may not be foolproof"

rapid escalation of the threat

That was my initial take, too. It's unlikely you'd put all the functionality in the firmware - there'd presumably have to be some external interface through which suspected corruption could be reported and recovery attempted. And as soon as you have an external interface that allows the reassignment of data blocks between files, you have another potential exploit path.

Having said that, one of the big hazards of ransomware is not noticing until your entire backup cycle has also been corrupted. If you can come up with an early alert, that would be incredibly valuable. And presumably you could apply the same principles of detection to any storage medium that avoids rewriting blocks in place - either at the device level (like shingled magnetic recording) or at the filesystem level (journalling file systems).

[Pascal Monett]

"detecting infections and reverting unexpected encryption"

That an SSD can detect infection is already a surprise to me, but what really takes the cake is the "unexpected encryption" part of that declaration.

Please explain to me how an SSD can tell if an encryption is expected or not.

How can an SSD make the difference between the used deciding to encrypt files on the SSD and malware residing in RAM doing it ?

I would really like to know, and then explain to me how a malware author is not going to be able to replicate that.

[DJO]

Re: "detecting infections and reverting unexpected encryption"

The vast majority of files have a header that does not change, if suddenly a lot of files are having their headers muddled up then it's a high probability something wrong is happening.

That's the easiest approach, I assume they've got some other detection modes running.

As for miscreants fooling the detection, well inevitably after a while - not encrypting the first (and maybe last) few K of each file might be enough.

As with all white hat/black hat battles it's an ongoing effort of attack and counter-attack - as long as the firmware can be (safely and securely) updated, but that introduces a new attack vector so it can all rapidly get quite complicated.

[Anonymous Coward]

Re: "detecting infections and reverting unexpected encryption"

How does the firmware know what constitutes a file? At that level they're just blocks; they don't become files until they're processed by the filesystem and the filesystem driver is in the kernel* (ie software)

That's a rhetorical question, by the way.

(* or at least hooked into it)

[DJO]

Re: "detecting infections and reverting unexpected encryption"

Valid points, this would be far better implemented at the file system level and probably easier too which makes me wonder why the file system writers haven't come up with something along these lines.

[Inkey]

Re: "detecting infections and reverting unexpected encryption"

"How does the firmware know what constitutes a file

its a good point but they must have an idea of how the cell patterns "look" under certain conditions.

Not sure the whole idea solves the problems it attempts to solve other than moving it on a bit ...

It's trained firmaware i presume ....

Trusting trust etc.

[DS999]

An SSD has no concept of "files"

It doesn't know an NTFS filesystem from an Oracle database, everything is just blocks.

They would have needed to add some ability to understand an NTFS filesystem for it to see if a bunch of files are replaced with identically named files of the same size within a short period of time. I can't really see any other way it could determine a "ransomware attack".

While false positives would be possible, I doubt many people do such encryption in place where they encrypt a bunch of files without changing their names in some way to reflect that new status, so this is probably fairly safe in most cases.

If this became a standard feature on SSDs it would be easy for ransomware to avoid. Buy one of the SSDs, reverse engineer how the algorithm works, and work around it. Maybe they can only encrypt a few files at a time, then do some other "make work" tasks to create and delete other files, then encrypt a few more, etc. It would take longer, but this runaround would only happen on an SSD so it would still be much faster than when ransomware attacks an HDD based system.

[Sirius Lee]

Re: "detecting infections and reverting unexpected encryption"

Maybe I'm on Windows and enable disk encryption?

[Wade Burchette]

Re: "detecting infections and reverting unexpected encryption"

Going further, how can a SSD tell if a file is encrypted or not? What is to prevent the ransomware creators triggering a TRIM command after a few encryptions? How does the system detect between ransomware encrypting files and a safe, bulk file operation?

It is an interesting concept. But they aren't thinking like the baddies. To thwart this system, all the ransomware has to do is encrypt a few files, run a TRIM operation, and then repeat until all the files are encrypted. The ransomware could even stagger the operation -- do 4 in the morning, another 4 in the afternoon, another 4 in the evening. It would, at least, stop the older ransomware infections. But I can already see how the blackhats can get around it.

[Gordon 10]

Re: "detecting infections and reverting unexpected encryption"

Duh. Its you thats not thinking it through. If the solution is in firmware the Trim command is also subject to interception and nulling/modification by this solution. Trim becomes "Trim everything except 1 known good copy".

[the spectacularly refined chap]

Re: "detecting infections and reverting unexpected encryption"

Going further, how can a SSD tell if a file is encrypted or not? What is to prevent the ransomware creators triggering a TRIM command after a few encryptions?

TRIM is an irrelevance here. For a start is doesn't actually delete any data, it simply marks logical blocks as not containing needed data so they can be overwritten without the data needing to be preserved first - the data itself gets overwritten at a later point on an as-needed basis.

Secondly it refers to logical blocks only. In this case where data is (logically) overwritten in place the physical blocks are replaced by spares. The logical blocks are still valid so there isn't anything to trim. The blocks containing the old data are marked as available for reuse but as before, that occurs on an as-needed basis rather than straight away.

[Phones Sheridan]

Re: "detecting infections and reverting unexpected encryption"

"Please explain to me how an SSD can tell if an encryption is expected or not."

That's what the mentioned software is for. Up pops the anti ransomware software notification "We have detected an unusual amount of files being encrypted. Is this you or ransomware?"

The threshold for the pop up will determine if the feature is nagging or not, but seeing as up to 10s of gigabytes of encrypted files could be reversed in minutes, that threshold can be very high.

[Graham 32]

Re: "detecting infections and reverting unexpected encryption"

You'd better have that software running all the time. If it's not there while, say, encrypting a drive for the first time it's likely the whole drive will be corrupted. Of course, anyone doing that would take a backup first.

[Anonymous Coward]

Where did you get that security "expert" from

Having worked through a ransomware attack the flaw in his argument a backup strategy isn't a great mitigator for a ransomware attack.

Firstly it requires extensive use of hot incremental backups to avoid significant data loss. The majority of firms still don't (and won't) do this.

Secondly the ransomware process is generally incremental itself which means you need a file by file analysis during the restore to figure out the most recent hot copy that's not encrypted.

Assuming this solution isn't snake oil it has the massive advantage it doesn't require proactive action by the users. You just specify these disks at purchase time and you are mostly protected.

Also whilst not underestimating the ransomware baddies - understanding actually how this protection works and circumventing it would not be a trivial task imo, as its operating several layers down the stack from where they operate at the OS level. They are good at finding OS exploits to get privileged access. I've seen no evidence as yet they can move deeper into the stack.

Again assuming it really works - as part of a layered anti-ransomware strategy I think this has promise. The latency is probably amenable to additional design or embedding some of the solution in hardware .

[Anonymous Coward]

Re: I've seen no evidence as yet they can move deeper into the stack.

it's just a matter of time, every new angle (a challenge, obstacle), particularly implemented widely, will make this 'area' the focus of attention for the bad guys.

[Missing Semicolon]

Anti ransomware adaptor

If the SSD manufacturers won't do it, why not build a box with a SATA plug and socket on it, that proxies all requests to the SSD, performing the ransomware detection and file versioning. Yes the performance will be worse, but for normal desktops it might be worth it.

[DJV]

Interesting idea

I would like to see some independent testing to see if it lives up to the claims. Do they see this as something like anti-virus where it can update the firmware should new threats/circumventions come along?

[Anonymous Coward]

File writes per day?

Seems to me a limit on the number of files that can be modified/deleted/written per day would be a fairly effective protection for a home user. I rarely work on more than 15 or 20 separate documents in a day, so just warn me if I'm working too hard.

Also - code in pub opening hours. If I am editing a document > 1 hour after opening time it probably isn't me, and if it is me, its probably a bad idea.

[TimMaher]

Re: 1 hour after opening time.

Pubs around here open by mid-day.

Hmm... nice thought.

Icon——-> by 4 in the afternoon.

[DJV]

Re: probably a bad idea

But will SSD-Insider++ be able to tell the difference between ransomware encryption taking place and drunken typing resulting in random gibberish? I suspect we may need to test that one to the limit! Appropriate icon -->

[Version 1.0]

An excellent collection of comments

They illustrate a range of approaches to "solving" the ransomware problems and extend ransomware too. I think this describes is a good precaution, it's not a solution but it could be very helpful. The solution is more likely to build a new operating system that prevents the entire malware attack methods - but I can't see that happening because it would have to limit many of today's commercial data theft "features".

[Anonymous Coward]

A major selling point of the technology is that it exists purely in firmware -

if I was a boss of an evil fake ransomware corporation, I would think: ah, that's interesting, so how can we implement our solutions around firmware...

[brainwrong]

I can't trust this bit >

"For recent HDDs - e.g., SMR [Shingled Magnetic Recording] drives - based on append-only magnetic media, the same idea of SSD-Insider++ can be directly applied," Lee told us."

Some testing I did on a DM-SMR drive I own indicated that large writes went directly to the shingled tracks, because they can. Only small writes and probably the start and end of large writes (i.e. not a full set of shingled tracks) go to the buffer area. So this won't work on SMR HDD's.

In any case, even with SSD's this all depends on the disk not being too full, is there enough internal overcapacity to guarantee its function?

[Anonymous Coward]

8% reduction in performance?

That is a rather healthy price to pay...

[JBowler]

You just have to perform backups/pushups/payments

> a standard backup process would still be efficient and is what the majority of companies already adhere to

Yet they keep on paying out. Fortunately the ransomware guys do go after those companies, because that's where the dosh is. For the rest of us it is truly a blessing to have all our data deleted, permanently. It opens up so many real life opportunities.

[HobartTas]

ZFS with snapshots provides sufficient protection for me from ransomware, however, ZFS does not work on Windows so that only applies to anything I manually transfer over to my ZFS NAS or after I backup my Windows box to the NAS.

[Sirius Lee]

If this is an effective approach, why doesn't Microsoft recommend that everyone enable file versioning. It's built into the OS and allows a user to roll back to previous versions that are stored on disk.

[DualMode]

These "New & Innovative Features" Look Familiar...

Suggest the "inventors" consult https://www.uspto.gov/ ...DualMode