#java deserialization oracle

[forever-stuck-on-java-8]

Type erasure can really be a bitch sometimes

Scratch that, its a bitch most of the time

Like I get why its a thing and how we got here but dammit why is serialization/deserialization so hard sometimes

[michaelok]

Fun with Java Deserialization

Down the Rabbit Hole

I’ve just been scrambling down the rabbit hole to patch an app that Qualys is complaining has a deserialization vulnerability. What should have been a simple effort has turned into a mystery because, while we appear to have the correct libraries already in place, Qualys is still complaining about the error. A report that should be clean, to indicate compliance with GDPR, is instead “yellow”, or “orange”, or “red”, so fingers point, tempers flare, e-mails fly about, cc’ing higher and higher ups, so now we have assumptions, and based on those assumptions, tersely written orders, involvement by 3rd party vendors. Time to panic? Shall we be careful and tip-toe through the eggs?[0]

Well, it turns out to be a rather interesting mystery.

What is Java serialization?

First, some definitions are in order. What is Java serialization and why is it important? Perhaps Wikipedia[1] defines it the simplest:

A method for transferring data through the wires

Java serialization is a mechanism to store an object in a non-object form, i.e. a flat, serial stream rather than an object, so that it can be easily sent somewhere, such as to a filesystem, for example. It is also known as “marshaling”, “pickling”, “freezing” or “flattening”. Java programmers should be familiar with the concept, and with the Serializable interface, since it is required in various situations. For example, this technique is used for Oracle Coherence’s “Portable Object Format” to improve performance and support language independence.

Early Days of Java Serialization

Amazing to think that, back in the day, we used all the various tools required for distributed communication, whether simple like RMI and JMX, or more involved specs like CORBA and EJB, and we never thought much about the security aspects. I’m sure if I peruse my copy Henning and Vinoski’s definitive work on C++ and CORBA, I’ll find a chapter or so focusing on security[1], but I’m figuring, we, like everyone else, focused on the business details, getting the apps to communicate reliably, adding features, improving stability, etc, and not on whether there were any security holes, such as tricking a server into running cryptocurrency mining malware[2]. Yes, Bitcoin and the like did not even exist then.

The Biggest Wave of Remote Execution Bugs in History

Well, times change, and the twenty-year-old Java deserialization capability is the source of “nearly half of the vulnerabilities that have been patched in the JDK in the last 2 years” [3], so Oracle has plans in the works to completely revamp object serialization. Further note that this is not solely Oracle’s issue, nor is it limited to Java. Many other software vendors, and open source projects, whether tools or languages, have this weakness, such as Apache Commons Collections, Google Guava, Groovy, Jackson, and Spring.

It seems all the excitement, at least in the Java world, started when Chris Frohoff and Garbriel Lawrence presented their research on Java serialization “ultimately resulting in what can be readily described as the biggest wave of remote code execution bugs in Java history.” [6] However, it is important to note that this flaw is not limited to Java. While Frohoff and Lawrence focused on Java deserialization, Moritz Bechler wrote a paper that focuses on various Java open-source marshalling libraries:

Research into that matter indicated that these vulnerabilities are not exclusive to mechanisms as expressive as Java serialization or XStream, but some could possibly be applied to other mechanisms as well.

I think Moritz describes the heart of the issue the best:

Giving an attacker the opportunity to specify an arbitrary type to unmarshal into enables him to invoke a certain set of methods on an object of that type. Clearly the expectation is that these will be well-behaved – what could possibly go wrong?

Java deserialization

For our purposes, we focused on Java serialization and Apache Commons Collections. From the bug report COLLECTIONS-580[4]:

With InvokerTransformer serializable collections can be build that execute arbitrary Java code. sun.reflect.annotation.AnnotationInvocationHandler#readObject invokes #entrySet and #get on a deserialized collection.

If you have an endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, …) you can combine the two to create arbitrary remote code execution vulnerability.

The Qualys report didn’t have much in the way of details, other than a port and the commons-collections payloads that illustrated the vulnerability, but I guessed from that info that the scanner simply uses the work done by the original folks (Frohoff and Lawrence) [5] that discovered the flaw available as the ysoserial project below.

https://www.youtube.com/watch?v=KSA7vUkXGSg

Source code here: https://github.com/frohoff/ysoserial

Now, in the flurry of trying to fix this error, given the annoyingly vague details from Qualys, I had looked at all sorts of issues, after noticing a few extra JVM arguments in the Tomcat configuration that happened to be set for the instances that were failing with this error, but were not set on other instances. Apparently someone had decided to add these, without informing our team. Interesting.

Now, remember that according to the original bug report, this exploit requires (1) untrusted deserialization, it (2) some way to send a payload, i.e. something listening on a port, such as a JMX service. In fact, These extra JVM args were for supporting remote access via JMX, so unraveling the thread, I researched Tomcat 8 vulnerabilities especially related to JMX. While it turns out that JMX is a weak point (JBoss in particular had quite a well-known major JMX flaw), I did have any luck convincing the customer that they should shut down the port. It is used to gather monitoring metrics useful in determining application performance such as CPU load, memory, and even cache information. Ok, easy but drastic solutions were off the table. I was back to the drawing board.

Next, I tried to see why it was flagging Apache collections in the first place. Going back to the ysoserial project, was it incorrectly flagging Apache Commons Collections 3.2.2, or Collections4-4.1, despite the fact that the libs were fixed? Further looking at the specific payloads, Qualys/Ysoserial was complaining about Collections 3.2.1, which limited the test scenarios to try to get working

Now here’s the interesting part: with ysoserial, I was unable to get the exploit to work, as depicted in the Marshalling Pickles video. It was failing with a strange error I hadn’t seen before, something about filter setting a “rejected” status. Now, this led me to finding info about Oracle’s critical patch update (_121). I was running with latest & greatest JDK, release _192, however our production servers were running a very out-of-date version - surprise surprise.

Apparently, with Oracle JDK at release 121 or later, Oracle has started to address this vulnerability in an official way, rather than what exists currently which is a bunch of ad-hoc solutions, mainly whitelisting/blacklisting, which is a difficult without library support. Some would call this ‘whack-a-mole’, but I think this illustrates quite well the idea of a “patch”, i.e. there’s a leak, so run over and put some tape over it, but we aren’t solving the fundamental issue. In other words, the current defense against this attach is limited because we can’t possibly know what libraries customers will use, so the library maintainer has to scramble to plug the holes whenever they are discovered. Note that even the best of libraries like Groovy, Apache and Spring have had to fix this flaw.

So kudos to Oracle for taking some much needed steps in solving this problem. Here’s a little detail on the new feature that works to make the deserialization process more secure:

The core mechanism of deserialization filtering is based on an ObjectInputFilter interface which provides a configuration capability so that incoming data streams can be validated during the deserialization process. The status check on the incoming stream is determined by Status.ALLOWED, Status.REJECTED, or Status.UNDECIDED arguments of an enum type within ObjectInputFilter interface.

https://access.redhat.com/blogs/766093/posts/3135411

While it is the “official” way to deal with the deserialization issue, it remains to be seen how well this strategy will work. As a further research project, I’m curious whether this model might be used beyond Java serialization, i.e. in projects like Jackson. Does it add anything more than Jackson already has, or does it simplify it, etc.

This feature is targeted for Java 9, but was backported to 8, though it looks like it doesn’t have all the functionality that Java 9 supports.

So you are probably wondering what happened? Did we fix all of the above, and even throw in an upgrade Tomcat, like the Monty Python “Meaning of Life” movie “everything, with a cherry on top!” Well, finally, given a little guidance on where to look, the 3rd party developers - turned out that not only had they added the JVM args, they had also added in some extra code to handle the authentication. Which used - you guessed it - the _old_ 3.2.1 version of commons-collections. This code was also manually maintained, so while the app our team maintained received the updated commons jar in an automated fashion along with all the other updates, this little bit of code, tucked away on the server, was never updated.

Lessons learned? Off-the-wall custom authentication? Don’t do this. But if you do, don’t leave manually updated chunks of code lying around, and further, keep up with the patches!

[0] Yes, I’m reading William Finnegan’s “Barbarian Days: The Surfing Life”, Finnegan’s hilarious and fascinating account of being a surfer in the early days of the sport. At one point, he complains to his friend and fellow surfer, who is getting on his nerves, that he is tired of walking on eggs around him. Of course, in his anger, he mixed up the quote, and meant “walking on eggshells”.

[1] https://en.wikipedia.org/wiki/Serialization

[2] A quick look at the omniORB doc shows it has a feature called the “Dynamic Invocation Interface…Thus using the DII applications may invoke operations on any CORBA object, possibly determining the object’s interface dynamically by using an Interface Repository.” Sounds like reflection doesn’t it? I’m not aware of any specific vulnerabilities, but it does seem we’ve traded a bit of the security that invoking statically-compiled objects brings for convenience.

https://www.cl.cam.ac.uk/research/dtg/attarchive/omniORB/doc/3.0/omniORB/omniORB011.html

[3] https://www.siliconrepublic.com/enterprise/cryptocurrency-malware-monero-secureworks

The Java Object Serialization Specification for Java references a good set of guidelines on how to mitigate the vulnerability:

https://www.oracle.com/technetwork/java/seccodeguide-139067.html#8

[4] https://www.securityinfowatch.com/cybersecurity/information-security/article/12420169/oracle-plans-to-end-java-serialization-but-thats-not-the-end-of-the-story

[5] https://issues.apache.org/jira/browse/COLLECTIONS-580

[6]Which seems to be a pretty standard strategy these days, i.e. proprietary companies like Qualys leveraging open source and adding it to their toolset. AWS does this to great effect, and we, as the consumer, benefit by getting simple interfaces. However, we should not forget that much of the code we use today is Open-source software, in some way or another.

Stratechery, as usual, has a very thoughtful post about this very idea:

It’s hard to not be sympathetic to MongoDB Inc. and Redis Labs: both spent a lot of money and effort building their products, and now Amazon is making money off of them. But that’s the thing: Amazon isn’t making money by selling software, they are making money by providing a service that enterprises value, and both MongoDB and Redis are popular in large part because they were open source to begin with.

[snip]

That, though, should give pause to AWS, Microsoft, and Google. It is hard to imagine them ever paying for open source software, but at the same time, writing (public-facing) software isn’t necessarily the core competency of their cloud businesses. They too have benefited from open-source companies: they provide the means by which their performance, scalability, and availability are realized. Right now everyone is winning: simply following economic realities could, in the long run, mean everyone is worse off.

https://stratechery.com/2019/aws-mongodb-and-the-economic-realities-of-open-source/

[7] https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true

[8] https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062

[miralrd]

Java se development kit 10 install fails

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS INSTALL

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS UPDATE

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS PATCH

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS FULL

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS CODE

That gave me the idea to make sure the Windows installer service was running or that it might be an installer problem, but that didn't help either. But then instead of terminating, the temp file started running as a separate process, and after another short time the Windows installer started.

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS INSTALL

I tested the installer on a clean install virtual machine and it behaved the same way at the start. I managed to save the temp file before it got deleted and tried to run it directly but it also does nothing, albeit more quickly because it terminates right away. After another short time the JDK process terminates and the temp files and folders are deleted. The file in the temp directory with the same name is 190,569,048 bytes. The setup file is called jdk-8u74-windows-i586 and is 190,853,720 bytes long. After a short time this file disappears and is replaced by a file with the same name as the setup file, but with a slightly different size. Within that folder it creates a file jds*.tmp, where the * is again a number. When I double click the setup file it creates a folder in my temp directory called jds*.tmp, where the * is a number that varies.

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS FULL

This is not an issue because I am using the Administrator account, all permissions for all files and folders are set to Full Control, and there is no anti-virus. I researched the error and most of the suggestions had to do with accounts and permissions. But when I try to install it nothing happens. So I downloaded the latest Java SE Development Kit 8u74 from Oracle myself. The only additional information given in the log file is "Process returned error: 0x80048646". Everything worked except for Java SE Development Kit 7.0.550.13. I first installed Office, then I installed Visual Studio 2015. For a more complete list of the bug fixes included in this release, see the JDK 10.0.1 Bug Fixes page.I am setting up a clean install of Windows 7 Ultimate 32-bit.

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS PATCH

This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. To improve the strength of SSL/TLS connections, 3DES cipher suites have been disabled in SSL/TLS connections in the JDK via the Security Property.

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS CODE

The secure validation mode is enabled either by setting the property .secureValidation to true with the .setProperty() method, or by running the code with a SecurityManager. The secure validation mode of the XML Signature implementation has been enhanced to restrict EC keys less than 224 bits by default. XML Signatures Signed with EC Keys Less Than 224 Bits Disabled.The default pattern allows, , $Type, and but rejects all the others.Ĭustomers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable. The filter pattern uses the same format as jdk.serialFilter. If the system property is also supplied, it supersedes the security property value defined here. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by jdk.serialFilter is consulted. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. These applications can use the Cipher API directly as an alternative to using this class.Ī new security property named has been introduced. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (for example, GCM) if the application requires explicit notification when authentication fails. These exceptions are not re-thrown, so the client is not informed that integrity checks have failed. The specification of has been clarified to indicate that this class catches BadPaddingException and other exceptions thrown by failed integrity checks during decryption. For more information, see JRE Expiration Date.

JAVA SE DEVELOPMENT KIT 10 INSTALL FAILS UPDATE

After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. This JRE (version 10.0.1) will expire with the release of the next critical patch update scheduled for July 17, 2018.įor systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 10.0.1) on August 17, 2018. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. The JRE expires whenever a new release with security vulnerability fixes becomes available.

[computingpostcom]

Welcome to this guide on how to install Java 17 (OpenJDK 17) on Ubuntu 22.04|20.04|18.04. Java is a high-level object-oriented programming language and computing platform intended to let application developers write once and run everywhere. This means that a compiled java code runs on all platforms that support Java without the need for recompilation. JDK is a collection of various programming tools such as JRE(Java Runtime Environment), Java, Javac, Jar, and many others. Java 17 LTS is the latest long-term support release for the Java SE platform released on 14 September 2021. Java 17 comes with the following amazing features: Enhanced pseudo-random number generators New rendering pipeline for MacOS, using the Apple Metal API as an alternative to the existing pipeline that uses the deprecated OpenGL API Remove the Experimental AOT and JIT Compiler Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them. Removal of the Remote Method Invocation (RMI) Activation mechanism Deprecate the Applet API for Removal Porting the JDK to MacOS/AArch64 in response to Apple’s plan to transition its Macintosh computers from x64 to AArch64 Strong encapsulation for JDK internals Context-specific deserialization filters The foreign function and memory API which allows Java programs to interoperate with code and data outside of the Java runtime With the above information, we are now set to dive into the Java 17 LTS installation. In this guide, we will cover 2 methods to get Java 17 installed on Ubuntu 22.04|20.04|18.04. OpenJDK from APT repos OpenJDK Manually Oracle JDK/JRE from PPA Oracle JDK manual install Option 1 – Install OpenJDK 17 on Ubuntu 22.04|20.04|18.04 from APT The easiest and quickest way is installation OpenJDK 17 on Ubuntu 22.04|20.04|18.04 from OS upstream repositories. sudo apt update sudo apt install openjdk-17-jdk For JRE run the following commands to install sudo apt install openjdk-17-jre Check Java version to validate a successful installation: $ java --version openjdk 17.0.3 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-Ubuntu-0ubuntu0.22.04.1) OpenJDK 64-Bit Server VM (build 17.0.3+7-Ubuntu-0ubuntu0.22.04.1, mixed mode, sharing) Option 2 – Install OpenJDK 17 on Ubuntu 22.04|20.04|18.04 Manually Java OpenJDK 17 is an open-source implementation of the Java SE platform. Since the OpenJDK versions available in the default repositories are not up to date, we will have to download the Open-source JDK 17 using the wget command. ### Linux 64-bit ### wget https://download.java.net/java/GA/jdk17.0.2/dfd4a8d0985749f896bed50d7138ee7f/8/GPL/openjdk-17.0.2_linux-x64_bin.tar.gz ### Linux ARM64 ### wget https://download.java.net/java/GA/jdk17.0.2/dfd4a8d0985749f896bed50d7138ee7f/8/GPL/openjdk-17.0.2_linux-aarch64_bin.tar.gz Extract the downloaded tarball. ### Linux 64-bit ### tar xvf openjdk-17.0.2_linux-x64_bin.tar.gz ### Linux ARM64 ### tar xvf openjdk-17.0.2_linux-aarch64_bin.tar.gz Then move the extracted file to the /opt/ directory as shown. sudo mv jdk-17.0.2/ /opt/jdk-17/ Set the environment variables. echo 'export JAVA_HOME=/opt/jdk-17' | sudo tee /etc/profile.d/java17.sh echo 'export PATH=$JAVA_HOME/bin:$PATH'|sudo tee -a /etc/profile.d/java17.sh source /etc/profile.d/java17.sh Verify the Java installation as below. $ echo $JAVA_HOME /opt/jdk-17 Check the installed version of Java. $ java --version openjdk 17.0.2 2022-01-18 OpenJDK Runtime Environment (build 17.0.2+8-86) OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing) Option 3 – Install Oracle JDK 17 on Ubuntu 22.04|20.04|18.04 For this option, we download the production-ready Java from the Java SE Downloads page. Alternatively, one can install Oracle JDK 17 on Ubuntu using the “Linux Uprising” team PPA installer script which automatically downloads and sets the default Java version on Ubuntu 64-bit based systems.

Clean previous OpenJDK installation: sudo rm /etc/profile.d/java17.sh exit Add the PPA repository to your Ubuntu system. sudo add-apt-repository ppa:linuxuprising/java Then install Oracle JDK 17 as shown. sudo apt update sudo apt install oracle-java17-installer Accept installation prompts: Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: binutils binutils-common binutils-x86-64-linux-gnu gsfonts gsfonts-x11 java-common libbinutils libctf-nobfd0 libctf0 libfontenc1 oracle-java17-set-default x11-common xfonts-encodings xfonts-utils Suggested packages: binutils-doc binfmt-support visualvm ttf-baekmuk | ttf-unfonts | ttf-unfonts-core ttf-kochi-gothic | ttf-sazanami-gothic ttf-kochi-mincho | ttf-sazanami-mincho ttf-arphic-uming firefox | firefox-2 | iceweasel | mozilla-firefox | iceape-browser | mozilla-browser | epiphany-gecko | epiphany-webkit | epiphany-browser | galeon | midbrowser | moblin-web-browser | xulrunner | xulrunner-1.9 | konqueror | chromium-browser | midori | google-chrome The following NEW packages will be installed: binutils binutils-common binutils-x86-64-linux-gnu gsfonts gsfonts-x11 java-common libbinutils libctf-nobfd0 libctf0 libfontenc1 oracle-java17-installer oracle-java17-set-default x11-common xfonts-encodings xfonts-utils 0 upgraded, 15 newly installed, 0 to remove and 68 not upgraded. Need to get 6260 kB of archives. After this operation, 20.0 MB of additional disk space will be used. Do you want to continue? [Y/n] y You will see this installer window where you are supposed to agree to the License Terms. Agree to the License Terms by clicking Yes Verify the installed version of Java by checking the version. $ java -version java version "17.0.1" 2021-10-19 LTS Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39) Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed mode, sharing) $ javac -version javac 17 Option 4 – Manually install Oracle JDK 17 on Ubuntu 22.04|20.04|18.04 The official Oracle JDK is a development environment for building applications and components using the Java programming language. This toolkit includes tools for developing and testing programs written in the Java programming language and running on the Java platform. We’ll download Oracle JDK 17 Debian installer wget https://download.oracle.com/java/17/archive/jdk-17.0.3_linux-x64_bin.deb Run the installer after it’s downloaded: sudo apt install ./jdk-17.0.3_linux-x64_bin.deb Additional dependencies should be installed automatically: Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'jdk-17' instead of './jdk-17.0.3_linux-x64_bin.deb' The following additional packages will be installed: libc6-i386 libc6-x32 libxtst6 The following NEW packages will be installed: jdk-17 libc6-i386 libc6-x32 libxtst6 0 upgraded, 4 newly installed, 0 to remove and 63 not upgraded. Need to get 5517 kB/161 MB of archives. After this operation, 346 MB of additional disk space will be used. Do you want to continue? [Y/n] y Set JAVA environment echo 'export JAVA_HOME=/usr/lib/jvm/jdk-17/' | sudo tee -a /etc/profile echo 'export PATH=$PATH:$JAVA_HOME/bin' | sudo tee -a /etc/profile Source the file and confirm Java version: $ source /etc/profile $ echo $JAVA_HOME /usr/lib/jvm/jdk-17/ $ java -version java version "17.0.2" 2022-01-18 LTS Java(TM) SE Runtime Environment (build 17.0.2+8-LTS-86) Java HotSpot(TM) 64-Bit Server VM (build 17.0.2+8-LTS-86, mixed mode, sharing) Set Default Java Version on Ubuntu 22.04|20.04|18.04 Setting the default Java version applies in instances where you have multiple Java versions installed on your system. First, you need to list all the available versions. sudo update-alternatives --config java Output: There are 2 choices for the alternative java (providing /usr/bin/java).

Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 auto mode 1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode 2 /usr/lib/jvm/java-17-oracle/bin/java 1091 manual mode Press to keep the current choice[*], or type selection number: 2 From the output, select the Java version you want to set as your default version by entering the number as shown above. Verify the set version $ java -version java version "17.0.1" 2021-10-19 LTS Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39) Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed mode, sharing) Setting JAVA_HOME Environment Variable. Setting the JAVA_HOME environment variable is important as it is used by Java applications to determine the install location of Java and the exact version to use when running the applications. We will set a persistent path so we edit the file /etc/profile as below. sudo vi /etc/profile In the file, add the Java path as shown. JAVA_HOME="/path/to/java/install" In this case, my Java path will be. JAVA_HOME="/usr/lib/jvm/java-17-oracle" For these changes to apply, you require to log in and log out or use the source command. source /etc/environment Verify the set variables. $ echo $JAVA_HOME /usr/lib/jvm/java-17-oracle Test the Java Installation We will now test the Java installation using a simple HTML file. In this guide, we will create an HTML file with the name Hello_World.java. cat > Hello_World.java

[pj011235]

Inside Java Newscast: Java 17 features and...

Tune in to the latest Inside Java Newscast to take a closer look at the list of JEPs for #Java17, including Sealed Classes, Context-Specific Deserialization Filters, and more!

Inside Java Newscast: Java 17 features and...

Java 17, the next long-term support release, enters feature freeze, and the release preparations begin now—a good time to take a closer look at the list of JEPs and the development process.

Oracle Champions

[javiersaro]

Diving into Java records: Serialization,...

Take a deep dive into records in #Java, including serialization and deserialization, marshaling and unmarshaling, and state validation of records.

Diving into Java records: Serialization,...

Existing frameworks and libraries that access instance variables through getters and setters won’t work with records. This blog shows you what to do.

Oracle Champions

[terabitweb]

Original Post from Trend Micro Author: Trend Micro

By: Sivathmican Sivakumaran (Vulnerability Researcher)

Oracle WebLogic has recently disclosed and patched remote-code-execution (RCE) vulnerabilities in its software, many of which were due to insecure deserialization. Oracle addressed the most recent vulnerability, CVE-2019-2729, in an out-of-band security patch on June 18, 2019. CVE-2019-2729 was assigned a CVSS score of 9.8, making it a critical vulnerability. This vulnerability is relatively easily exploitable, but requires Java Development Kit (JDK) 1.6. By default, WebLogic version 10.3.6 is shipped with JDK 1.6.

CVE-2019-2729 is essentially a bypass to CVE-2019-2725. This security issue, however, first surfaced in April 24 2017 as CVE-2017-3506.  We took a closer look at CVE-2019-2729 to see how this class of vulnerability has been remediated  — particularly via blacklisting or whitelisting — and why it has become a recurring security issue.

The Root Cause of CVE-2019-2725 and CVE-2019-2729 Context propagation in WebLogic servers makes it possible to carry application context information within a supported protocol. This information is carried via extensible markup language-serialized Java (XML) Objects. By default, the following URLs accepts context information via simple object access protocol (SOAP) requests: /_async/* /wls-wsat/*

The serialized XML data is contained within tags of a SOAP request.  The deserialization of the WorkContext information is implemented in the WorkContextXmlInputAdapter  class, as shown in Figure 1.

Figure 1. The WorkContextXmlInputAdapter class where the deserialization of WorkContext information is implemented

As shown above, the XMLDecoder class is used to deserialize the context information. It should be noted that XMLDecoder is a class that  should not be used with untrusted input. As demonstrated in other research efforts, it allows arbitrary method and constructor calls on arbitrary types. Due to the risks of using XMLDecoder and as a mitigation for CVE-2017-3506, a validate() function has been added to WorkContextXmlInputAdapter to filter out malicious tags prior to deserialization.

In the case of CVE-2019-2725, the validate() function prior to the vulnerability is shown in Figure 2.

Figure 2. The validate() function prior to CVE-2019-2725

As shown above, many tags required for RCE are effectively blacklisted. However, validate() fails to account for the tag, which can allow the attacker to initiate any class with arbitrary constructor arguments. This could be used in multiple ways to achieve arbitrary code execution. An example is to initiate a UnitOfWorkChangeSet object, which accepts a byte array as a constructor argument.

Figure 3. Code snippet showing how UnitOfWorkChangeSet indiscriminately deseralizes a byte array once initialized

As shown in Figure 3, UnitOfWorkChangeSet will indiscriminately deserialize this byte array upon initialization. A byte array with a crafted malicious serialized object, for instance, can be used to achieve arbitrary code execution. A Python snippet, shown in Figure 4, can then be used to generate attack traffic.

Figure 4. Python proof of concept (PoC) capable of generating attack traffic using the Jdk7u21 payload generated by ysoserial

Naturally, since the tag is required for this exploit to work, Oracle proceeds to add this tag to the blacklist as the patch to CVE-2019-2725.

Figure 5. Blacklist of the tag used to remediate CVE-2019-2725

CVE-2019-2729: A Bypass of CVE-2019-2725 On the other hand, it turns out that the bypass for CVE-2019-2725 was not all that complicated. In fact, for JDK 1.6, the functionality of the tag is effectively replaced by using a tag. Simply replacing the tag with the tag effectively bypasses the blacklist.

Figure 6. The tag (highlighted) that bypasses the blacklist for the tag

The more interesting thing in this case is the way CVE-2019-2729 was patched: Oracle opted to use a whitelist instead of a blacklist. This is achieved via the newly introduced validateFormat() function with the whitelist rules being defined in WorkContextFormatInfo.

Figure 7. Code snippet showing how a whitelist is used to remediate CVE-2019-2729

As can be seen in Figure 7, the tag is still allowed by the whitelist, but it is only allowed to contain “class” attributes with “byte” value or  a “length” attribute with any value.

Best Practices Although at first it may not seem so black and white, generally using a whitelist to block malicious content is more effective than using a blacklist, especially when it comes to preventing bypasses that may reintroduce a security issue. System administrators, developers, and IT/security teams should always adopt best practices and mitigations, which include:

Upgrading to a non-vulnerable version of the product using Oracle’s emergency patch

Preventing access to vulnerable components by deleting war and wls-wsat.war then restarting the WebLogic service (prevents access to the vuln URLs).

Restricting access to the affected communication port to trusted hosts only

Proactively monitoring, detecting, and blocking malicious traffic through intrusion prevention systems

Adding layers of security mechanisms such as virtual patching, which preempts exploitation of known, unknown, and undisclosed vulnerabilities; and application control, which prevents unauthorized or suspicious applications from executing

The Trend Micro Deep Security and Vulnerability Protection solutions protect systems and users via the following Deep Packet Inspection (DPI) rule:

1009816 – Oracle Weblogic Server Remote Code Execution Vulnerability (CVE-2019-2729)

The Trend Micro Deep Discovery Inspector protects customers from threats that may exploit CVE-2019-2729 via this DDI rule:

2903: Possible Oracle Weblogic Remote Command Execution Exploit – HTTP (Request)

Trend Micro TippingPoint® Threat Protection System has posted a Customer Shield Writer (CSW) file for this vulnerability that are available for customers to download on TMC. The applicable rule is as follows:

C1000001: HTTP: Oracle WebLogic Server Remote Code Execution Vulnerability

The post Using Whitelisting to Remediate an RCE Vulnerability (CVE-2019-2729) in Oracle WebLogic appeared first on .

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Trend Micro Using Whitelisting to Remediate an RCE Vulnerability (CVE-2019-2729) in Oracle WebLogic Original Post from Trend Micro Author: Trend Micro By: Sivathmican Sivakumaran (Vulnerability Researcher) Oracle WebLogic has recently disclosed and patched remote-code-execution (RCE) vulnerabilities in its software, many of which were due to insecure deserialization.

[ramansec-blog]

Faulty Patch for Oracle WebLogic Flaw Opens Updated Servers to Hackers Again

Faulty Patch for Oracle WebLogic Flaw Opens Updated Servers to Hackers Again

Earlier this month, Oracle patched a highly critical Java deserialization remote code execution vulnerability in its WebLogic Server component of Fusion Middleware that could allow attackers to easily gain complete control of a vulnerable server.

However, a security researcher, who operates through the Twitter handle @pyn3rd and claims to be part of the Alibaba security team, has now found a

S…

[alissaselezneva]

Announcing GraalVM: Run Programs Faster Anywhere

By: Thomas Wuerthinger and the GraalVM Team 

Current production virtual machines (VMs) provide high-performance execution of programs only for a specific language or a very small set of languages. Compilation, memory management, and tooling are maintained separately for different languages, violating the ‘don’t repeat yourself’ (DRY) principle. This leads not only to a larger burden for the VM implementers, but also for developers due to inconsistent performance characteristics, tooling, and configuration. Furthermore, communication between programs written in different languages requires costly serialization and deserialization logic. Finally, high-performance VMs are heavyweight processes with high memory footprint and difficult to embed.

Several years ago, to address these shortcomings, Oracle Labs started a new research project for exploring a novel architecture for virtual machines. Our vision was to create a single VM that would provide high performance for all programming languages, therefore facilitating communication between programs. This architecture would support unified language-agnostic tooling for better maintainability and its embeddability would make the VM ubiquitous across the stack.

To meet this goal, we have invented a new approach for building such a VM. After years of extensive research and development, we are now ready to present the first production-ready release.

Introducing GraalVM

Today, we are pleased to announce the 1.0 release of GraalVM, a universal virtual machine designed for a polyglot world.

GraalVM provides high performance for individual languages and interoperability with zero performance overhead for creating polyglot applications. Instead of converting data structures at language boundaries, GraalVM allows objects and arrays to be used directly by foreign languages.

Example scenarios include accessing functionality of a Java library from Node.js code, calling a Python statistical routine from Java, or using R to create a complex SVG plot from data managed by another language. With GraalVM, programmers are free to use whatever language they think is most productive to solve the current task.

GraalVM 1.0 allows you to run:

– JVM-based languages like Java, Scala, Groovy, or Kotlin – JavaScript (including Node.js) – LLVM bitcode (created from programs written in e.g. C, C++, or Rust) – Experimental versions of Ruby, R, and Python

GraalVM can either run standalone, embedded as part of platforms like OpenJDK or Node.js, or even embedded inside databases such as MySQL or the Oracle RDBMS. Applications can be deployed flexibly across the stack via the standardized GraalVM execution environments. In the case of data processing engines, GraalVM directly exposes the data stored in custom formats to the running program without any conversion overhead.

For JVM-based languages, GraalVM offers a mechanism to create precompiled native images with instant start-up and low memory footprint. The image generation process runs a static analysis to find any code reachable from the main Java method and then performs a full ahead-of-time (AOT) compilation. The resulting native binary contains the whole program in machine code form for immediate execution. It can be linked with other native programs and can optionally include the GraalVM compiler for complementary just-in-time (JIT) compilation support to run any GraalVM-based language with high performance.

A major advantage of the GraalVM ecosystem is language-agnostic tooling that is applicable in all GraalVM deployments. The core GraalVM installation provides a language-agnostic debugger, profiler, and heap viewer. We invite third-party tool developers and language developers to enrich the GraalVM ecosystem using the instrumentation API or the language-implementation API. We envision GraalVM as a language-level virtualization layer that allows leveraging tools and embeddings across all languages.

GraalVM in Production

Twitter is one of the companies deploying GraalVM in production already today for executing their Scala-based microservices. The aggressive optimizations of the GraalVM compiler reduces object allocations and improves overall execution speed. This results in fewer garbage collection pauses and less computing power necessary for running the platform. See this presentation from a Twitter JVM Engineer describing their experiences in detail and how they are using the GraalVM compiler to save money. In the current 1.0 release, we recommend JVM-based languages and JavaScript (including Node.js) for production use while R, Ruby, Python and LLVM-based languages are still experimental.

Getting Started

The binary of the GraalVM v1.0 (release candidate) Community Edition (CE) built from the GraalVM open source repository on GitHub is available here.

We are looking for feedback from the community for this release candidate. We welcome feedback in the form of GitHub issues or GitHub pull requests.

In addition to the GraalVM CE, we also provide the GraalVM v1.0 (release candidate) Enterprise Edition (EE) for better security, scalability, and performance in production environments. GraalVM EE is available on Oracle Cloud Infrastructure and can be downloaded from the Oracle Technology Network for evaluation. For production use of GraalVM EE, please contact graalvm-enterprise_grp_ww@oracle.com.

Stay Connected

The latest up-to-date downloads and documentation can be found at www.graalvm.org. Follow our daily development, request enhancements, or report issues via our GitHub repository at www.github.com/oracle/graal. We encourage you to subscribe to these GraalVM mailing lists:

– graalvm-announce@oss.oracle.com – graalvm-users@oss.oracle.com – graalvm-dev@oss.oracle.com

We communicate via the @graalvm alias on Twitter and watch for any tweet or Stack Overflow question with the #GraalVM hash tag.

Future

This first release is only the beginning. We are working on improving all aspects of GraalVM; in particular the support for Python, R and Ruby.

GraalVM is an open ecosystem and we encourage building your own languages or tools on top of it. We want to make GraalVM a collaborative project enabling standardized language execution and a rich set of language-agnostic tooling. Please find more at www.graalvm.org on how to:

– Allow your own language to run on GraalVM – build language-agnostic tools for GraalVM – embed GraalVM in your own application

We look forward to building this next generation technology for a polyglot world together with you!

  https://blogs.oracle.com/announcing-graalvm%3A-run-programs-faster-anywhere

from WordPress https://reviewandbonuss.wordpress.com/2018/04/26/announcing-graalvm-run-programs-faster-anywhere/

[securitynewswire]

Yet another gadget for java deserialization Misusing Oracle JDBC for SSRFattacks

SNPX.com : http://dlvr.it/QB9vLX

[terabitweb]

Original Post from Security Affairs Author: Pierluigi Paganini

The CVE-2019-2725 vulnerability in Oracle WebLogic recently, addressed by the company, is being exploited in cryptojacking attacks, Trend Micro reports.

Experts at Trend Micro reported that the recently patched CVE-2019-2725 vulnerability in Oracle WebLogic is being exploited in cryptojacking attacks.

The flaw is a deserialization remote command execution zero-day vulnerability that affects the Oracle WebLogic wls9_async and wls–wsat components.

The issue affects all Weblogic versions, including the latest one, that have the wls9_async_response.war and wls-wsat.war components enabled.

Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation, it is used by numerous applications and web enterprise portals based on Java technology.

An attacker could exploit the vulnerability to remotely execute commands without authorization by sending a specially crafted HTTP request.

The CVE-2019-2725 flaw was patched in late April, unfortunately, a few days later threat actors started exploiting the Oracle WebLogic Server vulnerability to deliver the Sodinokibi ransomware.

After the publication of the security advisory, experts at the SANS Institute reported that the flaw was already being actively exploited in cryptojacking campaigns. Experts at Trend Micro now confirm the SANS report and add that attackers are using an interesting obfuscation technique.

The malware used in this campaign hides its malicious codes in certificate files to evade detection.

Once the malware is executed it exploits the CVE-2019-2725 flaw to execute a command and perform a series of routines. 

“The purpose of the command is to perform a series of routines. First, PowerShell (PS) is used to download a certificate file from the command-and-control (C&C) server and save it under %APPDATA% using the file name cert.cer (detected by Trend Micro as Coinminer.Win32.MALXMR.TIAOODCJ.component).” reads the analysis published by Trend Micro.

“It then employs the component CertUtil, which is used to manage certificates in Windows, to decode the file.”

The attack chains starts with a PowerShell that downloads a certificate file from the C2 server. The malicious code uses the CertUtil tool to decode the file, then execute it using PowerShell. The downloaded file is then deleted using cmd.

The certificate file appears as a Privacy-Enhanced Mail (PEM) format certificate, it is in the form of a PowerShell command instead of the X.509 TLS file format.

“One interesting characteristic of the downloaded certificate file is that it requires that it be decoded twice before the PS command is revealed, which is unusual since the command from the exploit only uses CertUtil once.” continues the experts. “There is also the possibility that the certificate file we downloaded is different from the file that was actually intended to be downloaded by the remote command, perhaps because it is continuously being updated by the threat actors.”

The command in the certificate file is used by crooks to download and execute another PowerShell script in memory. The script downloads and executes multiple files, including Sysupdate.exe (Monero miner), Config.json (configuration file for the miner), Networkservice.exe (likely used for propagation and exploitation of WebLogic), Update.ps1 (the PowerShell script in memory), Sysguard .exe (watchdog for the miner process), and Clean.bat (deletes other components). 

Experts noticed that the update.ps1 file that contains the decoded certificate file is replaced with the new update.ps1 and a scheduled task is created to execute the new PowerShell script every 30 minutes.

The idea of hiding malware into certificate is not a novelty, experts at Sophos explored this technique in a proof of concept late last year.

“However, oddly enough, upon execution of the PS command from the decoded certificate file, other malicious files are downloaded without being hidden via the certificate file format mentioned earlier.” concludes Trend Micro. “This might indicate that the obfuscation method is currently being tested for its effectiveness, with its expansion to other malware variants pegged at a later date,”

window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";

try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}

Pierluigi Paganini

(SecurityAffairs – CVE-2019-2725, Oracle WebLogic)

The post CVE-2019-2725 Oracle WebLogic flaw exploited in cryptojacking campaign appeared first on Security Affairs.

#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Pierluigi Paganini CVE-2019-2725 Oracle WebLogic flaw exploited in cryptojacking campaign Original Post from Security Affairs Author: Pierluigi Paganini The CVE-2019-2725 vulnerability in Oracle WebLogic recently, addressed by the company, is being exploited in cryptojacking attacks, Trend Micro reports.

[terabitweb]

Original Post from Security Affairs Author: Pierluigi Paganini

Security experts are warning of a dangerous zero-day remote code vulnerability that affects the Oracle WebLogic service platform.

Oracle WebLogic wls9_async and wls-wsat components are affected by a deserialization remote command execution zero-day vulnerability.

New Oracle #WebLogic #RCE #Deserialization 0-day Vulnerability. No vendor fix yet! Speak to @waratek for guaranteed active protection against 0-day RCE attacks with no blacklists, signatures, or profiling #NoSourceCodeChanges https://t.co/mvtOGKpKPh pic.twitter.com/K6q7RVnCn6

— Waratek (@waratek) April 24, 2019

This zero-day flaw affects all Weblogic versions, including the latest one, that have the wls9_async_response.war and wls-wsat.war components enabled.

Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation, it is used by numerous applications and web enterprise portals based on Java technology. The flaw received the identifier CNVD-C-2019-48814.

An attacker could exploit the vulnerability to remotely execute commands without authorization by sending a specially crafted HTTP request.

According to the bulletin CNTA-2019-0015 issued by CNCERT/CC, the flaw affects the WebLogic 10.x and WebLogic 12.1.3 versions. The criticality flaw has not yet been addressed by Oracle.

Experts recomments to disable vulnerable modules “wls9_async_response.war” and “wls-wsat.war”, or to inhibit access to URLs ��/ _async / * “and” / wls-wsat / * “within Oracle WebLogic installs.

Experts at KnownSec 404 Team searched for vulnerable instances online by using the ZoomEye search engine, they found 36,173 installs, most of them in the US and China.

Experts at F5 Labs revealed to have already spotted a campaign exploiting the zero-day flaw in Weblogic servers.

[In Review] Watch out! New campaign spotted targeting #Weblogic servers using a zero-day deserialization vulnerability leading to Remote Code Execution. #0day pic.twitter.com/eNTEOTa90U

— F5 Labs (@F5Labs) April 23, 2019

window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";

try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}

Pierluigi Paganini

(SecurityAffairs – Weblogic, zero-day)

The post Zero-day vulnerability in Oracle WebLogic appeared first on Security Affairs.

#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Pierluigi Paganini Zero-day vulnerability in Oracle WebLogic Original Post from Security Affairs Author: Pierluigi Paganini Security experts are warning of a dangerous zero-day remote code vulnerability that affects the Oracle WebLogic service platform.

[terabitweb]

Original Post from Security Affairs Author: Pierluigi Paganini

Security experts are warning of a dangerous zero-day remote code vulnerability that affects the Oracle WebLogic service platform.

Oracle WebLogic wls9_async and wls-wsat components are affected by a deserialization remote command execution zero-day vulnerability.

New Oracle #WebLogic #RCE #Deserialization 0-day Vulnerability. No vendor fix yet! Speak to @waratek for guaranteed active protection against 0-day RCE attacks with no blacklists, signatures, or profiling #NoSourceCodeChanges https://t.co/mvtOGKpKPh pic.twitter.com/K6q7RVnCn6

— Waratek (@waratek) April 24, 2019

This zero-day flaw affects all Weblogic versions, including the latest one, that have the wls9_async_response.war and wls-wsat.war components enabled.

Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation, it is used by numerous applications and web enterprise portals based on Java technology. The flaw received the identifier CNVD-C-2019-48814.

An attacker could exploit the vulnerability to remotely execute commands without authorization by sending a specially crafted HTTP request.

According to the bulletin CNTA-2019-0015 issued by CNCERT/CC, the flaw affects the WebLogic 10.x and WebLogic 12.1.3 versions. The criticality flaw has not yet been addressed by Oracle.

Experts recomments to disable vulnerable modules “wls9_async_response.war” and “wls-wsat.war”, or to inhibit access to URLs “/ _async / * “and” / wls-wsat / * “within Oracle WebLogic installs.

Experts at KnownSec 404 Team searched for vulnerable instances online by using the ZoomEye search engine, they found 36,173 installs, most of them in the US and China.

Experts at F5 Labs revealed to have already spotted a campaign exploiting the zero-day flaw in Weblogic servers.

[In Review] Watch out! New campaign spotted targeting #Weblogic servers using a zero-day deserialization vulnerability leading to Remote Code Execution. #0day pic.twitter.com/eNTEOTa90U

— F5 Labs (@F5Labs) April 23, 2019

window._mNHandle = window._mNHandle || {}; window._mNHandle.queue = window._mNHandle.queue || []; medianet_versionId = "3121199";

try { window._mNHandle.queue.push(function () { window._mNDetails.loadTag("762221962", "300x250", "762221962"); }); } catch (error) {}

Pierluigi Paganini

(SecurityAffairs – Weblogic, zero-day)

The post Zero-day vulnerability in Oracle WebLogic appeared first on Security Affairs.

#gallery-0-6 { margin: auto; } #gallery-0-6 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-6 img { border: 2px solid #cfcfcf; } #gallery-0-6 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Pierluigi Paganini Zero-day vulnerability in Oracle WebLogic Original Post from Security Affairs Author: Pierluigi Paganini Security experts are warning of a dangerous zero-day remote code vulnerability that affects the Oracle WebLogic service platform.

[terabitweb]

Original Post from Rapid7 Author: Erin Bleiweiss

Your workflow just got easier

Are you tired of copy/pasting module names from the search results before you can use them? Thanks to this enhancement (PR #11652) by Brent Cook, you can now run search with the -u flag to automatically use a module if there is only one result. Now you’re one step closer to popping a shell!

A pair of new JSO modules

Metasploit published research a few weeks ago on Java Serialized Object exploitation. This week, we landed two of the modules mentioned in that report—PRs #11134 and #11136, both by Andrés Rodríguez. These two modules both exploit vulnerabilities in Oracle Weblogic Server that can lead to unauthenticated remote code execution.

New modules (5)

Cisco RV320 and RV325 Unauthenticated Remote Code Execution by Benjamin Grap, Philip Huppert, and RedTeam Pentesting GmbH, which exploits CVE-2019-1652

Oracle Weblogic Server Deserialization RCE – MarshalledObject by Aaron Soto, Andres Rodriguez, and Jacob Baines, which exploits CVE-2016-3510

Oracle Weblogic Server Deserialization RCE – RMI UnicastRef by Aaron Soto, Andres Rodriguez, and Jacob Baines, which exploits CVE-2017-3248

ES File Explorer Open Port by fs0c131y, h00die, moonbocal, and 小荷才露尖尖角, which exploits CVE-2019-6447

CAN Flood by Pietro Biondi

Enhancements and features

PR #11635 by Pearce Barry enhances msftidy to check for a missing Authors field in exploit, auxiliary, and post modules.

PR #11579 by Matteo Malvica adds expanded support and documentation for newer versions of Splunk to the exploit/multi/http/splunk_upload_app_exec module.

Bugs fixed

PR #11636 by bcoles fixes the version detection in the exploit/multi/postgres/postgres_createlang module, which adds stability to its check method.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

Pull Requests 5.0.14…5.0.15

Full diff 5.0.14…5.0.15

We recently announced the release of Metasploit 5. You can get it by cloning the Metasploit Framework repo (master branch). To install fresh without using git, you can use the open-source-only Nightly Installers or the binary installers, which also include the commercial editions).

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Erin Bleiweiss Metasploit Wrap-Up Original Post from Rapid7 Author: Erin Bleiweiss Your workflow just got easier Are you tired of copy/pasting module names from the…

[terabitweb]

Original Post from Rapid7 Author: Shelby Pace

Introducing Metasploit Development Diaries

We are happy to introduce a new quarterly series, the Metasploit Development Diaries. The dev diaries walk users and developers through some example exploits and give detailed analysis of how the exploits operate and how Metasploit evaluates vulnerabilities for inclusion in Framework. The first in the dev diaries series features technical analysis by sinn3r and includes modules from community members and fellow researchers Mehmet Ince, Green-m, and Alex Gonzalez.

You can check out the dev diaries here. If you’re in the mood for even more research, we published a practical exploitation guide to Java Serialized Objects (JSOs) last week. As part of that research, Aaron Soto added native support to Metasploit for building Java deserialization payloads with ysoserial.

RCE Everywhere!

The CMS Made Simple Showtime2 File Upload module contributed by fabiocogno allows an authenticated user with the Use Showtime2 privilege to gain code execution through the application’s failure to validate the extension for watermarked files. This module works on various versions including 3.6.0-3.6.2.

acamro added a module that exploits a Java deserialization vulnerability in Oracle’s Weblogic Server through the server’s T3 interface. This works for versions 10.3.6.0 and 12.1.3.0.

New Modules (2)

CMS Made Simple (CMSMS) Showtime2 File Upload RCE by Daniele Scanu and Fabio Cogno, which exploits CVE-2019-9692

Oracle Weblogic Server Deserialization RCE – Raw Object by Aaron Soto, Andres Rodriguez, and Stephen Breen, which exploits CVE-2015-4852

Enhancements and features

PR 11628 by rwincey added support for newer Outlook versions to the windows/gather/credentials/outlook post module. This module can now gather credentials from Outlook 2013, 2016, and Office 365.

PR 11622 by h00die introduced more hash-identifying capabilities that also puts hashes in JtR format.

PR 11619 by bcoles added further error handling to modules/exploits/linux/http/panos_readsessionvars.

PR 11616 by brimstone fixed an issue with Meterpreter’s paranoid mode.

PR 11615 by h00die added functionality that exports credentials in the JtR format by specifying the JtR extension for a file when using creds -o.

PR 11605 by Green-m made enhancements to msfconsole’s load command by adding tab completion for plugins regardless of being loaded or not. This PR also added a new switch to the load command that displays loaded plugins.

PR 11603 by Green-m added better error-handling when attempting to load the aggregator plugin in framework.

PR 11570 by h00die added a new advanced option, DeleteTempFiles that prevents the deletion of temporary files in case the file will be needed elsewhere.

Bugs fixed

PR 11631 by mkienow-r7 fixed an issue with the generation of payloads with PayloadUUIDTracking enabled. These payloads would be assigned non-existent workspaces at msfconsole startup.

PR 11614 by bwatters-r7 updated payloads to bring in fixes for both the Java meterpreter and the php meterpreter.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:

Pull Requests 5.0.13…5.0.14

Full diff 5.0.13…5.0.14

We recently-announced the release of Metasploit 5. You can get it by cloning the Metasploit Framework repo (master branch). To install fresh without using git, you can use the open-source-only Nightly Installers, or the binary installers (which also include the commercial editions).

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Shelby Pace Metasploit Wrap-Up Original Post from Rapid7 Author: Shelby Pace Introducing Metasploit Development Diaries We are happy to introduce a new quarterly series, the…

[terabitweb]

Original Post from Rapid7 Author: Aaron Soto

Java Serialized Objects (JSOs) are a reliable attack vector and present a rising threat to enterprise networks, as evidenced by a significant increase in both CVE assignments and public exploits. The Metasploit Framework team has seen a marked uptick in community exploit submissions, and Rapid7’s Project Sonar was able to highlight the prevalence of internet-accessible JSO-based applications with an internet-wide scan. The result of this research is our new report, Java Serialization: A Practical Exploitation Guide.

JSOs provide a flexible way of exchanging data between services, often using files or network connections, and are used to transport complex Java objects around. Their innate flexibility makes them a boon to developers; consequently, they are a major part of the underlying architecture of many Java-based projects. Yet that same flexibility also aids attackers by allowing them to package malicious objects for execution on remote targets. Unless code designers go to lengths to check serialized objects before acting on them, the characteristics that make JSOs attractive to software developers also offer a reliable malicious code execution vector.

Unlike many exploits, JSO-based exploits don’t involve putting the target system into an unpredictable state. As a result, exploits are easy to write and test, even for low-skill attackers. Our new paper, Java Serialization: A Practical Exploitation Guide, examines the attack surface provided by JSOs, analyzes deserialization vulnerability trends across CVEs, and measures the public visibility of one such vulnerable service. We go on to demonstrate how defenders can test their networks, highlighting new functionality within the Metasploit Framework.

You can read the full report here. The latest additions to Metasploit Framework are documented on our wiki. For more on the internet exposure of Java deserialization attack surfaces and Oracle WebLogic, join Jon Hart and Tod Beardsley for a live webcast on March 26 at 2 p.m. EST.

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Aaron Soto A Serial Problem: Exploitation and Exposure of Java Serialized Objects Original Post from Rapid7 Author: Aaron Soto Java Serialized Objects (JSOs) are a reliable attack vector and present a rising threat to enterprise networks, as evidenced by a significant increase in both CVE assignments and public exploits.