[conspire] (forw) Re: [OCLUG] New FairWare Ransomware targeting Linux Computers

[Rick Moen]

I have a sunnily optimistic view that all articles on security are
useful, even if only as examples of how not to write articles on
security.

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Mon, 13 Feb 2017 15:00:42 -0800
From: Rick Moen <rick at linuxmafia.com>
To: oclug at mailman.oclug.org
Subject: Re: [OCLUG] New FairWare Ransomware targeting Linux Computers
Organization: If you lived here, you'd be $HOME already.

Quoting Carl Spitzer (cwsiv at juno.com):

> Is this really much of a threat???? 

As always in these stories, the first and most important question -- the
question the stories address least often and least well, and often last
if at all -- is how the undesired code gets executed and achieves
('escalates' to) the authority needed to do its harm.

As you get to know this subject better, you should stop and ponder _why_
IT coverage almost invariably lacks, downplays, or does a sucky job on,
that crucial detail.  Clue:  It's because these tend to be republished
promotional material (press releases) from antimalware/security firms.
Which, hey, have to make the rent by finding customers.

In this case, lo!  Right down near the bottom:

   Update 9/1/16: It has been discovered that Fairware is being installed
   via hacked Redis servers. More information can be found here: Hacked
   Redis Servers being used to install the Fairware Ransomware Attack

What is a Redis Server (what is Redis)? 

Redis is a key-value database with DB replication and an in-RAM cache as
main storage.  You use it as glue to make huge Web sites work.
Competitors include NoSQL, dbm, and ArangoDB.


The article you quoted is an IT piece by one Lawrence Abrams: 
https://www.bleepingcomputer.com/news/security/new-fairware-ransomware-targeting-linux-computers/
His 'Update 9/1/16' points to a second piece,  This is the one Abrams
says 
https://www.bleepingcomputer.com/news/security/hacked-redis-servers-being-used-to-install-the-fairware-ransomware-attack/

2nd article cites Abrams's source as 'a new article by Duo Security'.
Article is at
https://duo.com/blog/over-18000-redis-instances-targeted-by-fake-ransomware , 
and describes the problem as erroneous Redis site configuration that
permits arbitrary outsiders to remotely manipulate stored key-value
pairs and worse things:

  Redis is intended to be used in trusted environments, and so it ships
  with a permissive security configuration, which is fine, unless you just
  put it on the Internet. That said, one of the fundamental laws of the
  Internet of Things is that if it can talk on a network, someone will put
  on the Internet.

  The issue is that we see many devices running Redis that are exposed to
  the Internet, which goes against the recommendations made by the Redis
  developers. Exposing Redis directly to the Internet allows attackers to
  view/modify the stored data. Even more importantly, attackers are able
  to remotely configure the Redis instance which, as we’ll see in this
  post, can lead to a complete compromise of the device.

Eh, ola.  As the great philosopher B. Bunny says, 'What a maroon.'  
I refer to the Web site constructors in question, not Duo Security. 
As it very clearly says in the Redis documentation, you put it as part
of a tiered architecture as rear-end software behind Web caches /
front-end Web servers / load-balancers (or otherwise sandboxed).

So, what does J. Random Cracker do with a remote Redis database that was
incompetently left exposed directly to the Internet?

  The key called "crackit" was found on most of the hosts and contained
  a public SSH key as the associated value. This led us to this post by
  the author of Redis describing the Redis security model and showing how
  an attacker could take over a host running Redis.

  In a nutshell, this attack is performed by:

  Sending a CONFIG command telling Redis to store key/values on disk in
  the “/root/.ssh/authorized_keys” file
  Setting a key/value pair with the value being a public SSH key
  The attacker can now log into the Redis instance via SSH as the root
  user.

The 'post by the author of Redis' is at http://antirez.com/news/96 .
The author's example of compromising a Redis instance is an instance
running on MacOS X (a Macbook Air) with grunt-user authority, and the
ssh key snuck in is /home/antirez/.ssh/id_rsa and
/home/antirez/.ssh/id_rsa.pub, which then gets an entry in
/Users/antirez/.ssh/authorized.keys .

Most notably, this is NOT the same as being able to get to the host's
/root/.ssh/authorized_keys .

The norm on Linux is to run services using service accounts, e.g., exim4
runs as user Debian-exim (on Debian), Apache httpd runs as user
www-data, etc.  There's an extremely good reason why you don't run
public-facing daemons with root authority, though a few _start_ with
root or root-equivalent authority just long enough to bind to a port
number below 1024 and then drop privilege immediately after doing so.
It's thus exceedingly unclear how any non-root process, even under
malign remote control, can overwrite /root/.ssh/authorized_keys without
a great deal more magic not in evidence (i.e., something else
extraordinary to escalate to root privilege, a
not-appearing-in-this-film abrecedabra).

In fairness, Redis is pretty specialised software for very large
Web sites, so there actually are _not_ maintained packages for many
Linux distributions, last I checked.  Often, Operations people build it
locally, as, e.g., via these instructions:
https://thomashunter.name/blog/installing-redis-on-debian/  
Notice that, as per tradition and the norms of Sysadmin 101, one
of the first things you do is create user redis and group redis to run
the daemon as -- not the root user.


So, to recap so far, Lawrence Abrams cites Duo Security.  Duo Security
points to a blog post by Redis's author claiming it explains how to 
remotely overwrite /root/.ssh/authorized_keys on a publicly exposed
Redis server -- even though the blog post doesn't say that.  There's a
big leap of logic unexplained.

Duo Security then goes on (on
https://duo.com/blog/over-18000-redis-instances-targeted-by-fake-ransomware)
to explain what happens when it deliberately exposes a new Redis
instance, impliedly running with root-user authority, to the Internet. 
Et voila, attacker writes data to /root/.ssh/authorized_keys .  But why
is Duo Security going out of its way to run a public-facing daemon with
root privilege?  Sounds like an artificially bad implementation
decision, to me.  

Let me be polite and put it this way:  Gosh, what am I missing, here?
(I could also be less polite.)

Just to complete the run-through, let's run with the assumption that
some hapless sysadmin has deployed a public-facing Redis instance
(ignoring the documentation saying not to do that), and for reasons that
passeth understanding has done so with root-user authority.  Righty-oh,
remote malign parties now have root-user ssh keypair control of the
server, and can do all sorts of indelicate things to it.  What next?

Original Lawrence Abrams piece, citing Duo Security, claims 18,000 
compromised Redis servers around the world are the locus of 'a new attack
called FairWare Ransomware'.  This is the hilarious bit, and almost
worth the long walk, the word 'attack' in this context.

Consider, through a tortuous and not-very-credible series of steps, a 
remote attacker has accepted the remote root-user access that the
amazingly incompetent sysadmin offered to all comers by going out of
his/her way to run a publicly-exposed Redis server with root privilege.
The remote intruder is now in absolutely control and can do anything
with the server -- make it play the Liberty Bell March, install HAL9000
software on it, anything.

With this set of hypothetical facts, the intruder installing a new
ransomware kit is an 'attack'.  And _this_ is the news story?  'A new
attack called FairWare Ransomware'?

Now, _that_, good people, is comedy.  Almost worth the buildup.


You, Carl Spitzer, asked 'Is this really much of a threat?'  Let's 
answer this via checkboxes.

[ ]  I work as a sysadmin in Operations at a very big Web site.
[ ]  I need to architect a key-value database for our site, and picked
     Redis.
[ ]  I ignore basic documentation stating how to never use software. 
[ ]  I am going to install Redis publicly exposed even though that 
     is not the standard deployment.
[ ]  I go out of my way and manually override Linux distribution 
     configurations (or, if it isn't a distro package, override 
     common sense) to force no-auth network daemons with local
     filesystem write capabilities to run as the root user.
[ ]  I never do backups of anything.

Someone who checks all six checkboxes could be screwed by the ransomware
'attack'.


_______________________________________________
OCLUG mailing list -- OCLUG at mailman.oclug.org
http://mailman.oclug.org/mailman/listinfo/oclug

----- End forwarded message -----