Muni System Hacker Hit Others By Scanning For Year-Old Java Vulnerability (arstechnica.com) 30
An anonymous reader quotes a report from Ars Technica: The attacker who infected servers and desktop computers at the San Francisco Metropolitan Transit Agency (SFMTA) with ransomware on November 25 apparently gained access to the agency's network by way of a known vulnerability in an Oracle WebLogic server. That vulnerability is similar to the one used to hack a Maryland hospital network's systems in April and infect multiple hospitals with crypto-ransomware. And evidence suggests that SFMTA wasn't specifically targeted by the attackers; the agency just came up as a target of opportunity through a vulnerability scan. In an e-mail to Ars, SFMTA spokesperson Paul Rose said that on November 25, "we became aware of a potential security issue with our computer systems, including e-mail." The ransomware "encrypted some systems mainly affecting computer workstations," he said, "as well as access to various systems. However, the SFMTA network was not breached from the outside, nor did hackers gain entry through our firewalls. Muni operations and safety were not affected. Our customer payment systems were not hacked. Also, despite media reports, no data was accessed from any of our servers." That description of the ransomware attack is not consistent with some of the evidence of previous ransomware attacks by those behind the SFMTA incident -- which Rose said primarily affected about 900 desktop computers throughout the agency. Based on communications uncovered from the ransomware operator behind the Muni attack published by security reporter Brian Krebs, an SFMTA Web-facing server was likely compromised by what is referred to as a "deserialization" attack after it was identified by a vulnerability scan. A security researcher told Krebs that he had been able to gain access to the mailbox used in the malware attack on the Russian e-mail and search provider Yandex by guessing its owner's security question, and he provided details from the mailbox and another linked mailbox on Yandex. Based on details found in e-mails for the accounts, the attacker ran a server loaded with open source vulnerability scanning tools to identify and compromise servers to use in spreading the ransomware, known as HDDCryptor and Mamba, within multiple organizations' networks.
LOL! (Score:1)
Oracle WebLogikz; It's got what plants crave!
Not Russia again (Score:5, Informative)
Re: (Score:2)
well.
russia, iran, whats the difference really to american media?
what's more perplexing is the spokesperson.
if it didn't affect any servers or payment systems - and how would they know - why shutdown the payments systems?
sounds like they don't even know what was compromised, really, or what the workstations were for either.
Re:Not Russia again (Score:4, Interesting)
Well, if you're under attack, you shut down everything to try to halt the attack. If the system is clean and shut down, it won't get infected. If it's infected, it won't spread.
So you shut it all down just as a precaution. Even if it compromised user data, if the system is off, that user data is staying on the system. Given it looks like it might have gotten into critical systems, this was probably the best course of action to prevent the spread.
Now, the interesting thing is - they had backups and have actually restored the critical systems from backups, which apparently pissed off the group to no end - they expected them to pay the $70K and apparently the messaging is getting more and more threatening as they bring up systems from backup. They actually are threatening to release the data, but no idea if it's a bluff or not.
I'm guessing the user workstations will just be reimaged and everything else restored, with a mandatory change in system passwords.
The hackers might have simply gotten too greedy - and attacked a target who not only not had the money to pay, but probably had enough skill and resources to do proper backups and thus it was cheaper to not pay and do the disaster plan than to pay. Even the worst attacks were only asking $20K or so which would shift the balance to "just pay it as it's going to cost more to recover it" to asking $70k which shifts the equation to "screw it, we're starting over as it's cheaper even if we have to give people free rides"
Re: (Score:2)
Come on, even the president-elect said LGBT were fine during its campaign!
Re: (Score:2)
There are probably most debauched cities. Unless you consider being gay and faithful to be worse than being straight with a different partner every day. But some people are fine associating with people who break the ten commandments regularly but as soon as someone is gay they freak out. Sure there are bible verses suggesting it is a sin, however there are other verses pointing out many other things that can be sins, such as remarriage after divorce or calling someone a fool. If someone really truly bel
Re: (Score:2)
Incompetent Summary & Title (Score:5, Insightful)
Not just WebLogic, also JBoss, Websphere, 1300 oth (Score:5, Informative)
The vulnerability isn't in Weblogic. It's actually a pair of screwups, one in Java itself and one in a very common library, used in thousands of applications.
As you may know, in Java most everything is an object. A string is an object, which has methods (executable functions). Also, Java is network-centric. So a lot of Java code, both library code and application code, sends objects over the network. When you submit your name to a Java application, some part of it is probably receiving the string object with your name, "Joe" or whatever. Because the string "Joe" is an object in Java, it can include executable methods. Whenever Java reads and deserializes an object from the network, Java AUTOMATICALLY calls the readObject() method of that object.
So to summarize, when your Java app wants to read data submitted in a form, Java automatically runs code that the user may have included in their submission. This sounds a bit dangerous, doesn't it?
Because it's dangerous, Java code that reads data over the network has to be very, very careful. The commons library didn't get this quite right, so all applications using the commons library ended up with a remote code execution vulnerability.
I can't put all, or even most, of the blame on the commons library, though, because Java itself set up a dangerous situation.
Going one level broader, the concept that you don't keep data and executable code separate is dangerous. That's precisely what strict object-oriented approaches require, though. If you can't accept data without accepting code attached to that data, that is dangerous, and that's exactly what OOP (in the strict sense) requires. Java has this issue mostly because it's "overly" object-oriented, because simple data like a string comes with executable code attached.
Re:Not just WebLogic, also JBoss, Websphere, 1300 (Score:5, Informative)
Going one level broader, the concept that you don't keep data and executable code separate is dangerous. That's precisely what strict object-oriented approaches require, though. If you can't accept data without accepting code attached to that data, that is dangerous, and that's exactly what OOP (in the strict sense) requires. Java has this issue mostly because it's "overly" object-oriented, because simple data like a string comes with executable code attached.
This is not quite right. Serialized objects only contain data and no code. But still code is being executed when deserializing an object (but this is code that already resides on the server-side and is not sent by the client). So the exploit is a bit more difficult. The original (I think?) description can be found here: https://foxglovesecurity.com/2... [foxglovesecurity.com]
Re: (Score:1)
So to summarize, when your Java app wants to read data submitted in a form, Java automatically runs code that the user may have included in their submission. This sounds a bit dangerous, doesn't it?
Serialized Java objects only contain data and not the class metadata or methods - readObject for String data executes the String.readObject code found in the runtime library on the server, not code from the client. If there is no such class in the servers class path or the version on the server is incompatible with the data then deserialisation will fail. Configuring a server to accept user code requires messing with the Remote Method Invocation API and at that point the security would become a completely u
Re: (Score:2)
Sorry but that isn't entirely accurate. The issue is that an application is deserializing arbitrary objects from untrusted sources. The foxglove article also overstates how frequently object serialization is used, it was largely replaced by XML and later JSON.
I can exploit at least three different application (Score:2)
The tool I worked on yesterday can exploit at least three different applications, so no, it's the library. (I do this for a living.) The library was caught by the trap that Java set.
Goodbye (Score:1)
Sack the person responsible for not applying the WebLogic patch and all the Security Managers upstream. Pour encourager les autres.
Transit Agency hit by Oracle Java vulnerability .. (Score:3)
"the attacker ran a server loaded with open source [arstechnica.com] vulnerability scanning tools to identify and compromise servers to use in spreading the ransomware, known as HDDCryptor and Mamba, within multiple organizations' networks".
Re: (Score:2)
Re: (Score:2)
> OS/2 when you need it???
It's ba-a-a-a-a-ck; or at least coming soon. I realize you might be asking the question sarcastically, but anyhow... http://www.techrepublic.com/ar... [techrepublic.com]
> From 'Blue Lion' to ArcaOS 5.0
>
> When the Blue Lion project was announced at the American WarpStock in
> October 2015, the name was only temporary. Following the close of events at
> WarpStock Europe, Arca Noae managing member Lewis Rosenthal noted
> in an interview that the final product name for the new OS/2 dist