Slashdot Mirror
Muni System Hacker Hit Others By Scanning For Year-Old Java Vulnerability (arstechnica.com)
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.
Oracle WebLogikz; It's got what plants crave!
The summary points finger to Russia, but Brian Kerb's article has strong hints that the hacker is from Iran. Russia was just the country hosting the hacker's e-mail provider.
Come on, even the president-elect said LGBT were fine during its campaign!
Everything I write is lies, read between the lines.
A vulnerability in WebLogic is no more a Java vulnerability than an old httpd is a C vulnerability.
Sack the person responsible for not applying the WebLogic patch and all the Security Managers upstream. Pour encourager les autres.
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 believes this is a religious issue then remember let he who is without sin cast the first stone. Anyone who accuses others of sin while pretending to be better than them is a hypocrite, even if anonymous.
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.
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...
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.
Very well explained. But how client code can go beyond the sand box and become saved code that re-executes on demand is a more interesting problem that must be addressed by Oracle or they will be eaten alive by the competition. The whole point of java was to make client data into objects in the first place, those objects were then supposed to be single executable not saved within the server objects framework. So the flaw being exploited here must be an incomplete close call clearing the code from the data. I thought that the garbage collection in java was set up specifically for security reasons to prevent exactly this from happening. I guess some clown must have opened a way around it after Oracle bought up Sun. FIGURES they were always a bunch of cheapo route around coders at Ellison Inc!
Bro, a public transit hack wouldn't even qualify as news, if it hadn't happened in the Brogrammer Hive.
Is there a contest on slashdot as to how to talk about malware without mentioning that it will only run on Microsoft Windows?
"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".
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 unrelated and self inflicted configuration issue.
The exploit uses a broken readObject implementation of a class already on the server to execute the untrusted data. That broken readObject implementation is part of the commons library.
Not only in Slashdot, but I am digressing.
OpenJDK JEP 290 will add a serialization whitelisting/filtering facility at the Java runtime level to help applications combat this type of vulnerability.
High Five! I live in Las Vegas, We have everyone here.. Gay Straight Tranny. the way i grew up understanding it and had this beat into me by my god fearing republican father. What they do is none of your business, unless they try to push it onto you and force you to do the same. Your business does not go beyond the tip of your nose. so if its past the tip of your nose, and you don't like what they're doing with themselves you have all right to walk away. Now the gay/straight/tranny that try to force their lifestyle onto others who don't want to be a part, or around it. Shall burn in hell! or at least thats how i see it.
" 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. "
That's a federal crime, right?
Can anyone explain how the ticketing system was taken down by malware on office desktops ?
OS/2 when you need it???
And here I thought it was corrupt agents of a large SF financial institution who were opening bogus accounts in customer's names that were being referred to. And the exec who retired with a huge golden parachute instead of a prison sentence.
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.
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.