Why would you bother with four constant XORs in a row with no intervening operations.
But xor 1-2 can be combined, so does xor 3-4.
11–20 of 42 posts
Why would you bother with four constant XORs in a row with no intervening operations.
But xor 1-2 can be combined, so does xor 3-4.
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.
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.
Can anyone summarize what the attack vector is? Fake repositories? Bad maintainers? Fake tutorials?
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.
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.
> 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…
If this is something you want from your email provider, along with some other simple defenses [1][2], then please drop me an email at joran@ronomon.com, I work on an email startup in private beta.
[1] https://blog.cotten.io/ghost-emails-hacking-gmails-ux-to-hid...
[2] https://snyk.io/blog/how-to-crash-an-email-server-with-a-sin...
Confused by: VER=`echo $(uname -a)` Versus just: VER=$(uname -a) or VER=`uname -a`
1. They're mixing a Bourne-ism (backquotes) with a Bash-ism (dollar-parens). I don't know why. 2. This could be an attempt to normalize and reduce whitespace, including eliminating newlines (though you should prevent injection of arguments to `echo`): bash$ Temp=$(echo " a b c ") bash$ echo "[${Temp}]" [ a b c ] bash$ Temp=`echo $(echo " a b c ")` bash$ echo "[${Temp}]" [a b c] bash$ Temp=$(echo $(echo " a b c ")) ba…
Can anyone summarize what the attack vector is? Fake repositories? Bad maintainers? Fake tutorials?
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.
Why would you bother with four constant XORs in a row with no intervening operations.
There is subtraction between second and third xor. But xor 1-2 can be combined, so does xor 3-4.
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
> The malware will attempt to find the dynamic linker binary within these paths. The dynamic linker filename is usually prefixed with ld-.
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
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- .