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.
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.
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...