java 反序列化漏洞

漏洞是利用apach commons-collections/

apache 建議升級該jar

https://commons.apache.org/proper/commons-collections/release_3_2_2.html

freebuf也分析能夠參考

http://www.freebuf.com/vuls/86566.html

關於反序列化漏洞原理的分析：

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

Java LOVES sending serialized objects all over the place. For example:

• In HTTP requests – Parameters, ViewState, Cookies, you name it.

• RMI – The extensively used Java RMI protocol is 100% based on serialization

• RMI over HTTP – Many Java thick client web apps use this – again 100% serialized objects

• JMX – Again, relies on serialized objects being shot over the wire

• Custom Protocols – Sending an receiving raw Java objects is the norm – which we’ll see in some of the exploits to come

Okay, so what you ask? Well what if we knew of an object that implemented a 「readObject」 method that did something dangerous? What if instead of appending an exclamation point to a user defined string, it could be massaged into running a user defined command on the operating system? That would be pretty bad.

Suppose such a vulnerable object existed, but wasn’t part of 「core」 Java, but instead just part of a library. Think about the requirements for exploitation:

• That library would need to be on the Java 「classpath」

• The application would need to deserialize untrusted user input

We’ve already determined that requirement 2 is very often satisfied. Requirement 1 could be satisfied if we could find such a vulnerability in a commonly used library…