ransomware virus on Linux

[Matthias Apitz]

Hello,

I've read in the German computer magazine "iX 12/2015" about a threat
against Linux: Some ransomware malware encrypts your disk and the bad guys aking
for your money to get it decrypted again. All details about this story
and how to get it decrypted again w/o spending money is here:

http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/

Two questions remain:

The structure of the attack makes me think that it would work the same way on
FreeBSD too. Do we have already known attacks like this?

If we would have a known attack and test data from this (i.e. an
encrypted file system tree), I think it would be worth to check if the
software described by Bitdefender could be ported to FreeBSD too.

Any comments?

matthias

--
Matthias Apitz, ✉ gu...@unixarea.de, 🌐 http://www.unixarea.de/ ☎ +49-176-38902045
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"

[Polytropon]

On Thu, 19 Nov 2015 07:44:34 +0100, Matthias Apitz wrote:
>
> Hello,
>
> I've read in the German computer magazine "iX 12/2015" about a threat
> against Linux: Some ransomware malware encrypts your disk and the bad guys aking
> for your money to get it decrypted again.

The FBI recommends you simply pay:

https://securityledger.com/2015/10/fbis-advice-on-cryptolocker-just-pay-the-ransom/

Things can be so easy if you listen to the authorities and then
hand the costs over to your loyal customers who believe in your
expertness and professionalism. ;-)

> All details about this story
> and how to get it decrypted again w/o spending money is here:
>
> http://labs.bitdefender.com/2015/11/linux-ransomware-debut-fails-on-predictable-encryption-key/

In addition:

http://krebsonsecurity.com/2015/11/ransomware-now-gunning-for-your-web-sites/

https://github.com/eugenekolo/linux-ransomware-decrypter

> Two questions remain:
>
> The structure of the attack makes me think that it would work the same way on
> FreeBSD too.

As far as I understand: Yes, that would be possible (given that
the FreeBSD installation is much like the Linux installations
affected in terms of software versions in use).

> Do we have already known attacks like this?

Maybe those running a significant attack surface (i. e., old and
unpatched version of Magento, as the article you pointed to states),
could provide more information:

Linux.Encoder.1 is executed on the victim's Linux box
after remote attackers leverage a flaw in the popular
Magento content management system app.

Proper settings of (write) privilege, account separation, the use
of jails will probably make this harder to spread across a whole
system. The article mentions a few things to pay attention to.

> If we would have a known attack and test data from this (i.e. an
> encrypted file system tree), I think it would be worth to check if the
> software described by Bitdefender could be ported to FreeBSD too.

It would be interesting to see if the Linux version would work
on FreeBSD (via Linux ABI), because the file system access at
this point is still "abstracted" to the running program.


--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Olivier Nicole]

Hi,

>> The structure of the attack makes me think that it would work the same way on
>> FreeBSD too.
>
> As far as I understand: Yes, that would be possible (given that
> the FreeBSD installation is much like the Linux installations
> affected in terms of software versions in use).

I tend to think that by the time it comes on FreeBSD, the flaw on
generating the key will have been corrected (I am pretty sure it has
already been corrected for Linux). So the decryption script will not
work anymore.

Regards,

Olivier

[Brandon J. Wandersee]

Matthias Apitz writes:

> Any comments?


From what I've been able to glean, this seems a little bit overblown. I
don't doubt the effects are significant for the people experiencing
them, but it seems extremely limited. The program is said to "take advantage
of" an outdated, running instance of the Magento e-commerce software, so
I have to think that it can only be executed via Magento. It also
encrypts only directories that would absolutely require root privileges
to modify--e.g., it specifically encrypts /home, not individual user
directories, so even if you deliberately executed it as a regular user
it would have no effect.

So it only affects improperly configured servers that run outdated
versions of one specific piece of software. It's not something most of
us will have to ever worry about, and the onus really falls first on
Magento to prevent this sort of remote execution (which it apparently
did before the malware even made it into the wild), and then on sysadmins to
update to the newer, secure version.

--
=================================================================
:: Brandon Wandersee ::
:: brandon....@gmail.com ::
==================================================================
'A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.'
- Douglas Adams
==================================================================

[RW via freebsd-questions]

On Thu, 19 Nov 2015 16:20:28 -0600
Brandon J. Wandersee wrote:


> From what I've been able to glean, this seems a little bit overblown.
> I don't doubt the effects are significant for the people experiencing
> them, but it seems extremely limited. The program is said to "take
> advantage of" an outdated, running instance of the Magento e-commerce
> software, so I have to think that it can only be executed via
> Magento. It also encrypts only directories that would absolutely
> require root privileges to modify--e.g., it specifically
> encrypts /home, not individual user directories, so even if you
> deliberately executed it as a regular user it would have no effect.

I would guess it would recurse from /home into whatever it can
access - it probably just encrypts the files in place.

What worries me is that the next version might target Linux workstations
where there's a lot of very complex software running as the owner of
the user data.

[Charles Swiger]

On Nov 19, 2015, at 4:21 PM, RW via freebsd-questions <freebsd-...@freebsd.org> wrote:
> What worries me is that the next version might target Linux workstations
> where there's a lot of very complex software running as the owner of
> the user data.

Ransomware which encrypts your stuff isn't a major problem if you have a current backup.

So, verify that your backups work.

Regards,
--
-Chuck

[Ben Woods]

On Friday, 20 November 2015, Charles Swiger <csw...@mac.com> wrote:

> On Nov 19, 2015, at 4:21 PM, RW via freebsd-questions <

> freebsd-...@freebsd.org <javascript:;>> wrote:
> > What worries me is that the next version might target Linux workstations
> > where there's a lot of very complex software running as the owner of
> > the user data.
>
> Ransomware which encrypts your stuff isn't a major problem if you have a
> current backup.
>
> So, verify that your backups work.
>
> Regards,
> --
> -Chuck
>
>

Similarly, I believe regular automatic ZFS snapshotting can be effective
against this. Files encrypted? zfs rollback to 15 minutes ago when they
weren't encrypted. Problem solved.

Regards,
Ben


--

--
From: Benjamin Woods
wood...@gmail.com

[Garance A Drosehn]

On 19 Nov 2015, Charles Swiger wrote:

> On Nov 19, 2015, at 4:21 PM, RW via freebsd-questions
> <freebsd-...@freebsd.org> wrote:
>> What worries me is that the next version might target Linux
>> workstations
>> where there's a lot of very complex software running as the owner of
>> the user data.
>
> Ransomware which encrypts your stuff isn't a major problem if you have
> a current backup.
>
> So, verify that your backups work.

Which really means: Verify that your *restores* work! :)

(Certainly I've seen cases where someone was running backups
regularly & automatically, and everything looked fine. But when
they finally needed to restore something, they found out that those
backups were not really working, or were working but not backing up
as much as the user thought they were backing up)

--
Garance Alistair Drosehn = dro...@rpi.edu
Senior Systems Programmer or g...@FreeBSD.org
Rensselaer Polytechnic Institute; Troy, NY; USA

[Matthias Fechner]

Am 20.11.2015 um 01:21 schrieb RW via freebsd-questions:
> I would guess it would recurse from /home into whatever it can
> access - it probably just encrypts the files in place.

so a good reason to have a ZFS with regluar snapshots.
If really all data would be encrypted the worm has write access to it
you will have the snapshots and the backup you can use.
Not very convinient but it makes again clear, make backups and keep your
software updated.


KR
Matthias

--

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

[Charles Swiger]

Hi, Garance--

On Nov 20, 2015, at 7:57 AM, Garance A Drosehn <dro...@rpi.edu> wrote:
>> So, verify that your backups work.
>
> Which really means: Verify that your *restores* work! :)

Indeed: it is not a working backup if you cannot restore the data.

Regards,
--
-Chuck

[Mike Jeays]

Also make sure that your backups are off-line, so they can't be hit by the malware
at the same time.

[Polytropon]

On Fri, 20 Nov 2015 10:57:37 -0500, Garance A Drosehn wrote:
> On 19 Nov 2015, Charles Swiger wrote:
>
> > On Nov 19, 2015, at 4:21 PM, RW via freebsd-questions
> > <freebsd-...@freebsd.org> wrote:
> >> What worries me is that the next version might target Linux
> >> workstations
> >> where there's a lot of very complex software running as the owner of
> >> the user data.
> >
> > Ransomware which encrypts your stuff isn't a major problem if you have
> > a current backup.
> >
> > So, verify that your backups work.
>
> Which really means: Verify that your *restores* work! :)

That's already in the definition: A backup which you cannot
restore is not a backup - it's garbage. :-)

> (Certainly I've seen cases where someone was running backups
> regularly & automatically, and everything looked fine. But when
> they finally needed to restore something, they found out that those
> backups were not really working, or were working but not backing up
> as much as the user thought they were backing up)

True, I've seen that too. Untested backups with "experts"
relying on them (and other "experts"' assurance that everything
would work if needed). The worst thing _I_ have actually seen
in reality was (many years ago) a customer who's "professional
consultant" had messed up the backup process so nothing was
written to the tapes, and nobody had checked the logs, so
the customer ended up with a box of blank tapes; the box was
labeled "BACKUP". You can imagine how "satistied" the customer
was with his expensive "service" when the worst case happened,
disks crashed, and he would just have to restore yesterday's
backup... :-)

--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

[Arthur Chance]

On 21/11/2015 04:57, Polytropon wrote:
> On Fri, 20 Nov 2015 10:57:37 -0500, Garance A Drosehn wrote:
>> (Certainly I've seen cases where someone was running backups
>> regularly & automatically, and everything looked fine. But when
>> they finally needed to restore something, they found out that those
>> backups were not really working, or were working but not backing up
>> as much as the user thought they were backing up)
>
> True, I've seen that too. Untested backups with "experts"
> relying on them (and other "experts"' assurance that everything
> would work if needed). The worst thing _I_ have actually seen
> in reality was (many years ago) a customer who's "professional
> consultant" had messed up the backup process so nothing was
> written to the tapes, and nobody had checked the logs, so
> the customer ended up with a box of blank tapes; the box was
> labeled "BACKUP". You can imagine how "satistied" the customer
> was with his expensive "service" when the worst case happened,
> disks crashed, and he would just have to restore yesterday's
> backup... :-)

I had exactly the same experience - box full of Exabyte dump tapes, all
carefully labelled with day and date they'd been in the drive, all
pristine except for a little wear from sitting unmoving in the drive.
The person responsible swore that they'd actually tried a restore when
they'd set up the system and it had worked.

Fortunately it was not the system disk that had failed, only the drive
holding the customer's data, and I was able to restore the lost data,
and explain why the test restore had worked - there was a very large
regular file on the system disk called /dev/rmt0 (*). After that I got
into the habit of doing

ln -s rmt0 /dev/rmt0

on all machines without mt devices, to cause dumping to the non-existent
default device to fail with a "too many symbolic links" error.

(*) or whatever the default dump(8) device was.

--
Moore's Law of Mad Science: Every eighteen months, the minimum IQ
necessary to destroy the world drops by one point.