Multi-platform Java bot marshals ZOMBIE FORCE against spammers Miscreants have brewed a multi-platform strain of malware capable of infecting Windows, Mac OS and Linux PCs. The evil bot, which surfaced in early January, was written entirely in Java and designed to take advantage of the CVE-2013-2465 vulnerability (a Java flaw patched by Oracle last June) to infect victims. The malware - …
Or Oracle, whose insistence of never certifying their enterprise products on anything resembling current software versions is legendary.
The recommendations for our E-Business Suite product are JRE6 (not 7) and IE 9 (6 months ago it was IE 8).
You try telling the finance department that they are required to use airgapped machines to access their pet system, because it is a massive security risk to allow their normal laptops to do so and thus have exploitable code installed on machines that can browse the internet.
It doesn't end well, usually :'(
As to why you'd also want to restrict outgoing data in your firewall.
I've seen numerous of examples where people focus all their attention to incoming, but when it comes to outgoing it's basically a "allow all keep state" kind of rule. Apparently this makes a lot of people feel safe, I dunno...
I understand your sentiments, but software installed without permission to force someone's computer to engage in activities which are illegal (regardless of the target) in most jurisdictions most certainly is malware.
Another thought : what better site to practice on in order to perfect your bot than one which is odious and unlikely to bring the authorities down on you. I'd be concerned about who their next target is.
Miscreants have brewed a multi-platform strain of malware capable of infecting Windows, Mac OS and Linux PCs.
The malware - dubbed Client Side Java by Kaspersky Lab - has reportedly infected 'three billion devices', which would make it the world's most successful bot net.
Command and control traffic has been traced to a firm in Silicon Valley.
The blog entry mentioned in the article mentions how the bot arranges to have itself executed at start-up. Windows is pretty conventional (registry hacks), I can't comment on Apple, but on Linux it attempts to add stuff into the bootscripts in /etc/init.d. Made me laugh that - any sysadmin worth their command prompt will have ensured that /etc/init.d cannot be added to by normal users (pretty standard security measure), and unless they are complete idiots they won't put themselves in a position of receiving the bot when they are logged in as root (they should log in as a normal user first of all, then elevate themselves to root privileges via "su".
Saying that, hats of to the guys who took this thing apart and worked out how it works - they really had to sweat that one.
Unfortunately, java applications frequently run as root, usually with no good reason or with a reason that is limited in scope and can be avoided. If such an application (and/or the underlying JVM) is vulnerable then it is not inconceivable that something will be inserted into /etc/init.d and enabled. It is also not inconceivable that it will not be noticed for a while.
Note that there is no setuid in java. You cannot do what you need with enhanced privileges and relinquish them, limiting the target for malware. Not in pure java, anyway: you can call setuid() with JNI, but that is not pure java and is not typically included in the toolbox of the average java programmer.
So, while Linux is quite secure by design (e.g., /etc/init.d is owned by root out of the box, no need for an admin to "harden" it) it won't help much if the admins disregard vulnerabilities one after another, e.g., install a vulnerable JRE and run random java code with root permissions.
java applications frequently run as root
Just like _almost_every_ application can be run as root. For stupidity there is really no upper bound out there. You'd still have to manually and specifically launch it with su/sudo, or if already logged as uid=0. The most possible scenario (and perhaps, most vulnerable) when java is web browser plugin (I think FF now disables it by default). Then it would be run as a progeny and would inherit the uid of the parent process. So one has to be ... extra smart to do just that.
Those who run JVM specifically for other purposes are are likely to create a special user or group for it and change to that when needed, when launching it from the shell, to minimize the threat.
Another point is that on a GNU/Linux distro you get updates without much headache suffered by most Windows users, such, as:
* it is not done from the same interface (one update interface for ALL programs)
* no need to reboot a machine (most update would just need to restart an app)
* more resilient, if a kernel update is buggy and you cannot boot into the fresh kernel, things are modular, the older kernels are kept together with the new to be able to boot into
etc
Unfortunately, java applications frequently run as root
Really? Only time I've ever encountered one was a numpty who ran Tomcat as root in order to be able to bind to port 80. Changed to run on 8080 with a port forwarding rule on each machine - as it should be. Never seen a Java client or user application running as root.
I took it off my systems quite some time ago.
I know someone is going to say something about the web being limited to me then. It is... to an extent. I let the site owners know that I refuse to install it AND if they are an online rertailer, I let them know which products I would have bought so that they can calculate their loses. If enough of us do that, we can force a change.
Java should have died a long long time ago. Like 1996...
I refuse to purchase from any websites that require javascript, let alone Java. (though if they have a non premium rate sales line, I might use that.)
I do quite often let them know, if they have an email address, and one ticket site actually fixed the problems, so they won't lose further business from me. (The problem was actually with the card authentication, so I guess they moaned that they were losing custom.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
