Slashdot Mirror
Out-of-Date Apps Put 3 Million Servers At Risk of Crypto Ransomware Infections (arstechnica.com)
An anonymous reader cites an article on Ars Technica: More than 3 million Internet-accessible servers are at risk of being infected with crypto ransomware because they're running vulnerable software, including out-of-date versions of Red Hat's JBoss enterprise application, researchers from Cisco Systems said Friday. About 2,100 of those servers have already been compromised by webshells that give attackers persistent control over the machines, making it possible for them to be infected at any time, the Cisco researchers reported in a blog post. The compromised servers are connected to about 1,600 different IP addresses belonging to schools, governments, aviation companies, and other types of organizations. Some of the compromised servers belonged to school districts that were running the Destiny management system that many school libraries use to keep track of books and other assets. Cisco representatives notified officials at Destiny developer Follett Learning of the compromise, and the Follett officials said they fixed a security vulnerability in the program. Follett also told Cisco the updated Destiny software also scans computers for signs of infection and removes any identified backdoors.
because they're running vulnerable software, including out-of-date versions of Red Hat's JBoss enterprise application
...and...
hat were running the Destiny management system that many school libraries use to keep track of books and other assets
So is this a JBoss issue? A Destiny Management System issue? What is the vector? The summary is unclear on exactly what the issue is...
If you want news from today, you have to come back tomorrow.
At least they are protected against all the other kinds of malware.
How the heck would using Rust instead have prevented these kinds of incidents from happening? How can we be so sure that Rust is really "secure"? After all, that's what we were all told about Java back in the 1990s! Again and again we were told how the JVM had sandboxing and bytecode verification and stuff like that, and how that would make software written in Java ultra-secure. But if Java can suffer from these kinds of problems, then why shouldn't we expect Rust to suffer from such problems, too?
There was an earlier Slashdot post about how Apple wants people to buy new devices and software on a regular basis, but the most popular comments were about how old software is the best, and that there's never a reason to update it, so long as the software is doing what you got it for in the first place. Now there's this article in which the solution to the problem is to update the software. Oh, what am I supposed to think?!
I think this is the third submission the past 2 days when manish takes and replaces the links from a submission with ArsTechnica articles. What's the deal? Are you getting paid to promote their crappy articles?
If I were to gain access to a machine like this and install a persistent web shell, I would then patch the underlying vulnerability in order to maintain control. Otherwise, the next guy to come along and exploit the defect can just kick me out. What fun is that?
I put my JBoss in containers on VMs on VPS on Cloudy providers.
I am invincible!
Wait, we're saying "apps" to describe non-mobile software now? Is that what we're doing? Could we avoid that if I asked politely?
is there really nothing else happening in the world?
Very timely, I ran a Qualys scan and it flagged jboss as a vulnerability. Qualys says it's a level 5 threat, highest level, so I told the web team to fix it.
Unfortunately all the Qualys scan says is that JBoss is out of support and no longer receives security patches.
The web project manager asked me "so is it just because it's old, or is it a specific vulnerability?"
I'll be sending him these articles.
It looks like an RMI / Apache Commons thing.
A bunch of popular Java application servers like JBoss, WebLogic, WebSphere or applications like Jenkins use RMI or at least similar (de)serialization of Java objects for a variety of things like e.g. remote management. They also seem to be rather trusting of the clients and serialized objects they receive and deserialize on the server side.
Now, if I remember correctly, you can only deserialize classes on your CLASSPATH, so you usually can't just send a serialized instance of net.some.exploit.MyEvilAndUnsafeToDeserializeObject.class and expect it to work on servers because they usually won't have your net.some.exploit.MyEvilAndUnsafeToDeserializeObject.class on their classpath
So someone looked for popular Java libraries which do some unsafe serialization/deserialization stuff and are used by lots of server software and found that the Apache Commons Collections library contains some dangerous deserialization code and is used by a lot of software - like JBoss and the others mentioned.
So if a server does RMI or RMI-like services and uses that library, you can basically get a remote shell on that server by sending some evil RMI to whatever port/servlet/service on that server accepts RMI or some other (proprietary) protocol which uses serialized Java objects somewhere.
Timmy Cook is protecting his and your Gay Child Porn stash from the sticky fingers of the FBI.
Now that says it all.
Apparently, this idiotic term is trying to assimilate things it has absolutely no business describing.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Sounds like that manager will be out of a job aoon and will be having a hard time finding a job as no one will hire him. Though, they may hire him as an intern.
Today's app technology relies on apping your apps. Proper apping involves server apps, client apps and mobile apps. You've got to appify your app architecture, to leverage apps into the apping future. If you fail to appify your apps while apping then you're not apping correctly and apparently, a luddite.
Be a good apper, don't be old. Cuz non-apping old people suck! Amirite?
Reported attacks have been on out-of-date and unpatched Jboss Community and older EAP versions. More details here:
http://developers.redhat.com/blog/2016/04/19/security-update-samassamsam-ransomeware-and-jboss/