
HiddenWasp Malware Stings Targeted Linux Systems - botzombie
https://www.intezer.com/blog-hiddenwasp-malware-targeting-linux-systems/
======
jorangreef
I work on an email startup in private beta.

While developing our antivirus system, I was surprised to find that most email
providers do not block ZIP attachments containing SH shell script files, nor
ZIP attachments containing extension-less files with the executable bit set,
nor ZIP attachments containing symlink traversal paths, nor any attachments
which start with the shebang "#!" shell script signature, nor any which start
with ELF or MACH O signatures.

In addition, for a recent sample of 15,000 attachments, we found 700 viruses,
of which less than 50% were detected by the top 30 engines on VirusTotal. In
particular, ClamAV, which is used by most Linux systems, had a less than 1%
success rate. Ironically, most email providers know to block EXE attachments,
even in ZIP attachments, but now its Linux and Mac users that are being left
behind.

~~~
xorcist
Is it really that strange? Windows email clients tend to run code in
attachments just by clicking them (or, in some cases, just viewing them). So
the risk factor in letting these emails in is quite large.

That's not as common with other platforms. Even the common GUI platforms on
Linux would require the user to manually save the file and explicitly marking
the file as executable. Nobody would conflate user friendliness with the ease
of running untrusted code.

Defaults does make a difference. Even as these users are "left behind" in
email filtering, we're seeing limited effects of malware with the more popular
Linux platforms such as Android and the various desktops.

~~~
IronBacon
> _Even the common GUI platforms on Linux would require the user to manually
> save the file and explicitly marking the file as executable._

If someone can find a way to drop a text file in my "~/.config/autostart" dir,
next time I log in my Gnome desktop will happily execute the command present
in the "Exec" line and it doesn't require the execute bit.

I think something similar could be done using "~/.local/share/applications",
overriding an installed application next time that application is launched,
but it probably would show two icons; the autostart at the moment is more
stealth.

~~~
mbrumlow
I think the point is -- do to that you would have to have the email client do
it.

While once it is out side the control of the email client -- as the quote
suggest, it's up to the user -- not the email client to do the dirty work.

The notion is that on windows, even a all knowing user who knew the email
contained a virus after viewing it would be helpless as the email client
already did the steps required to make the virus active. Where as on Linux,
the user would still need to be the facilitator -- not the email client
blindly destroying your system.

As a example. You can email me virus all day long, and it is not likely I will
get infected because of how my email client handles files and attachments. If
I were to switch to a windows based system using a windows client then all
bets are off.

tl;dr your exception would mean the bad thing we are talking about already
happened. If they could get your email client to write to that file they
probably already had enough control to do whatever you are suggesting they put
in autostart.

~~~
IronBacon
> _The notion is that on windows, even a all knowing user who knew the email
> contained a virus after viewing it would be helpless as the email client
> already did the steps required to make the virus active. Where as on Linux,
> the user would still need to be the facilitator -- not the email client
> blindly destroying your system._

OK, I see your point, normal usage against exploits, and usually security goes
against convenience.

I don't know if I'm overly paranoid, but in this specific case I've started
long time ago to keep my autostart dir read only. At the same time I've dirs
in my command path that are writable by my user (but those need the execute
bit tho)...

~~~
jorangreef
Keeping your autostart directory read-only is a great idea.

After that, a ZIP symlink traversal could still drop a script in your command
path directories that are writable by your user. The execute bit is not a
hurdle, unzip utilities will typically preserve the execute bit on Unix
systems.

ZIP directory traversals are as old as the hills, yet they are still a thing:
[https://snyk.io/research/zip-slip-
vulnerability](https://snyk.io/research/zip-slip-vulnerability).

ZIP symlink traversals are even more powerful, yet they are hardly spoken of.

Ideally, you want your email provider to be blocking ZIP attachments with
symlink traversals or execute bits (but I am not aware of any which do).

------
bayareanative
Antivirus is always a "closing the barn door after the horse has left"... it's
completely reactionary/inadequate as it almost always relies on other people
reporting a problem, so it's always behind and a Tragedy of the Commons in
that very little of actual malware is ever reported. HIDS isn't much better.
NIDS is slightly more useful as it's independent of the endpoint, but can also
be evaded to a degree. Both HIDS/NIDS aren't great on their own because
they're really the last lines of defense to tell you you're pwned.

In previous life, I inherited a bunch of Win2k database servers that were
running on unfiltered public IPs (yuck!).. and several of them had
undetectable, stealth rootkit malware that wasn't economically-feasible to
remove (Microsoft and Winternals were in the loop).. and because they
"couldn't be reimagined," network rules were used to disconnect it from bot
operations. Yuck. Don't put unsecured or fragile anything on public IPs
because odds are they will be pwnes with variants of malware no AV has ever
seen, and it will be a persistent threat (APT) that won't be evident until
later.

The best defenses include, but aren't limited to:

\- Never run untrusted code.

\- Never allow untrusted write and execute.

\- Don't do email / browser operations with admin credentials. Do it in a VM
maybe or a separate machine as a normal, unprivileged user is best.

\- Least privilege, all the things.

\- Verify cryptographic signatures enforcing chain-/web-of-trust of
source/binaries/packages.

\- Holistic defense-in-depth.

\- Minimalism/minimal attack surfaces.

\- Don't run fragile, unconfigured OSes on unfiltered public IP's. (Please.)

------
ddtaylor
Can anyone summarize what the attack vector is? Fake repositories? Bad
maintainers? Fake tutorials?

~~~
jorangreef
A shell script with an SH extension, possibly (my guess) delivered as an email
attachment.

The article does not provide details, but does list a few steps to the
exploit, the first being Linux users (as opposed to Linux servers) with poor
antivirus.

For example, ZIP email attachments can contain extension-less files with the
executable bit set. This would be one easy way of getting the initial payload
bootstrapped.

------
xupybd
Well that is scary. What anti virus / security tools do others on here run. On
Linux I run nothing. I'm concerned that this might not be okay any more.

~~~
shakna
> The malware is still active and has a zero-detection rate in all major anti-
> virus systems.

Anti virus wouldn't really help in this case. I should also point out that it
appears that HiddenWasp is targeting systems that are already compromised in
some form.

The "achilles heel" of these sorts of CnC attacks tends to be, and is
apparently so in this case, that they do need to phone home.

In this case, the IP addresses are known, and blackholing them with your
firewall (try something like ufw [1], if you don't have one), or your hosts
file, is enough. Using something like pi-hole you can also deploy these
protections for every device on your network.

There are quite a few hosts lists maintained out in the wild [0], and tools
like fail2ban to protect against brute-force attacks.

But, as usual, by far and away the safest way to protect your system is to not
run untrusted code. You probably have a package manager, going outside it
tends to be less safe.

[0] For example:
[https://github.com/mitchellkrogza/Ultimate.Hosts.Blacklist](https://github.com/mitchellkrogza/Ultimate.Hosts.Blacklist)

[1]
[https://wiki.archlinux.org/index.php/Uncomplicated_Firewall#...](https://wiki.archlinux.org/index.php/Uncomplicated_Firewall#Black_listing_IP_addresses)

~~~
pushpop
Even using the official repos doesn’t guarantee you to be safe. The project
developer might have had their development machine hacked and/or their source
repository hacked and malicious code inserted. So when Arch / Ubuntu / etc
package maintainers pull the latest source, unless they’re doing very thorough
diffs of each source file, they could easily miss the injected malicious code
and subsequently repackage that for the distro. What has actually happened
before.

Also if your Linux / UNIX machine has an addressable WAN IP then you have all
the usual risks of involved with hosting services on the public internet. A
few years ago there was a spate of compromised web servers with the malware
running as Apache modules.

So there aren’t really any guarantees when running Linux.

------
newnewpdro
The article says to examine 'ld.so' files, but I don't remember the
interpreter being named 'ld.so' in remotely recent history.

Perhaps it's a Debianism, but it's been '/lib/ld-linux.so.$ver' for ages:

    
    
      $ readelf -p .rodata /lib/ld-linux.so.2  | grep '/etc/ld\.so\.preload'
        [  2d9c]  /etc/ld.so.preload

~~~
saagarjha
I don't think the article says this?

> The malware will attempt to find the dynamic linker binary within these
> paths. The dynamic linker filename is usually prefixed with ld-<version
> number>.

~~~
newnewpdro
'In addition, in order to check if your system is infected, you can search for
“ld.so” files — if any of the files do not contain the string
‘/etc/ld.so.preload’, your system may be compromised.'

~~~
saagarjha
I think they're assuming that readers will excuse them for a bit of sloppiness
for brevity's sake.

------
tyingq
Confused by:

VER=`echo $(uname -a)`

Versus just:

VER=$(uname -a)

or

VER=`uname -a`

~~~
saagarjha
People writing rootkits are not necessarily experts in shell scripting :)

~~~
FullyFunctional
Look no further than the chain of xors that amount to ... ^ 0x22. These people
really don't know much.

ISTM, the only interesting thing is the "user-mode rootkit" mentioned in the
beginning. Anything installed after that is moot and completely irrelevant. If
anyone gets root on your machine, it's already game over.

However, if your attack vector is getting me to execute a random .sh from you,
then I'll roll my eyes and get on with life.

~~~
jorangreef
If your email firewall allows random .sh attachments, then you are vulnerable
to at least two attacks:

1\. Someone targets you specifically, knowing you are a software developer, by
impersonating a trusted third-party contact and sending you a ZIP attachment
with the contents of an open source project you are known to work on. ZIP
attachments preserve the executable bit, and you wouldn't see any .sh
extension because it would be an extension-less shell script. It would
probably just look like a binary you are used to clicking.

2\. Someone impersonates a trusted third-party contact, sending you a ZIP
attachment with a symlink traversal to overwrite your .bashrc as soon as you
unzip the attachment with a double-click, or as soon as unpatched middleware
unzips it for you.

------
kevin_thibedeau
Why would you bother with four constant XORs in a row with no intervening
operations.

~~~
panpanna
There is subtraction between second and third xor.

But xor 1-2 can be combined, so does xor 3-4.

~~~
saagarjha
Presumably they were talking about this: [https://github.com/jgamblin/Mirai-
Source-Code/blob/master/mi...](https://github.com/jgamblin/Mirai-Source-
Code/blob/master/mirai/bot/scanner.c#L975)

