Talk given at ISSA Wisconsin Chapter meeting, Jan 10, 2017. Abstract: ""Enterprise Java" is a term we hear daily. However, how many of us actually--empirically--know what that represents from a risk, threat, and exposure basis? From the asset(s) it's on and data it accesses to the enterprise at-large that it sits within. This talk will explore the size, scope, and omnipresence of "Enterprise Java" in all its forms; and seek to give it a quantifiable attack surface. This talk will encompass various exemplars of where Enterprise Java appears in the enterprise. From the overt and ubiquitous application servers to the not so overt (but still ubiquitous) use in network appliances and "devices" (IoT) emerging today; and what this means to the threat profiles and attack surfaces of your organization."

1. ENTERPRISE JAVA
Just What Is It and
the Risks, Threats, and Exposures
It Poses
By Alex Senkevitch, CISSP, CISM
Milwaukee Chapter
Meeting
10 Jan 2017

2. i
WHAT’S IN STORE
1.0 Background (this stuff)
2.0 Facets of an Attack Surface
2.1 The Java Programming Language
2.2 Application Containers
2.3 Container Extensions
2.4 Third-Party Frameworks and Libraries
3.0 Where Are the Wild Things?
4.0 Q&A

3. i
YOUR SPEAKER TODAY IS…
Alex Senkevitch, CISSP, CISM
o Working in security research and architecture in Fortune 500/Global
2000 for 20 years
o Worked in embedded systems and network engineering before that
o Have patents in multi-tiered security and event analytics systems
o Have multiple reported CVEs in Enterprise Java architectures; and
o Routinely continue find 0-days on an ongoing basis (for clients)
o Primary research interests are in data manipulation and “full” application
stacks, specifically Java and node.js stacks

4. i
FIRST, SOME TERMINOLOGY…
Java
Enterprise Java
Application Container
Application Stack

5. FACETS OF AN ATTACK SURFACE 2.0

6. i
SO HOW COMPLEX IS ENTERPRISE JAVA ANYWAY?
o “Enterprise Java” is:
o A programming language
o A virtual machine
o A container
o A container
o A container
o Vendor container extensions
o Industry container extensions
o Third-party frameworks
o Third-party libraries
Aggregate Attack Surface

7. FACETS OF AN ATTACK SURFACE
2.1
The Java Programming
Language

8. i
WHAT’S IN A LANGUAGE
o Initially started in 1991 (called Oak), for an “interactive television” project @ Sun Microsystems
o First public preview (1.0) in 1995, called Java (after the coffee)
o Abstracted from the hardware (“machine code”) via “byte-code” model
o Sun’s initial claim: Apps could be “100% Java” (no native code needed)
o Had five (5) design goals for the language, one of which was very interesting…
­ Goal #2: “1.2.2: Robust and Secure” (http://www.oracle.com/technetwork/java/intro-141325.html#367):
“Java technology is designed to operate in distributed environments, which means that security is of paramount
importance. With security features designed into the language and run-time system, Java technology lets you construct
applications that can't be invaded from outside. In the network environment, applications written in the Java
programming language are secure from intrusion by unauthorized code attempting to get behind the scenes and
create viruses or invade file systems.
­ “The best laid schemes o’ Mice an’ Men…” –Robert Burns (More on this to follow…)

9. i
JDK8
CODEBASE COMPLEXITY
Java 8 represents a ~1,900% increase
in API size and complexity since JDK1.0
…and that doesn’t include any third-party
code
(source: Java 8 Pocket Guide book by Robert Liguori, Patricia Liguori)
1.0

10. i
HOW A LANGUAGE GETS EXECUTED
Once compiled to byte-code (i.e., the Java
opcodes), a virtual machine is needed to
process it
The class files (compiled byte-code) are fed in
They are parse and processed through to
The Execution Engine
The Execution Engine then interfaces with the
underlying OS

11. i
WHEN 100% IS MORE LIKE 82%
o The Java Platform is 100%, well, Java code…right?
o Remember the JVM’s “Execution Engine”
o It passes off anything that the Java APIs can’t do within the JVM itself to the Native Method Interface
o Like: file system access, network access, security management, etc.
o So, what does that mean to me?
o When byte-code language A doesn’t match native language B’s structure and alignment…
o Language primitive mismatch bypasses (e.g., NUL byte bypasses)
o Encoding bypasses (e.g., Overlong UTF-8 bypass)
NOPE!

12. i
GOAL #2: JAVA IS SECURE BY DEFAULT…RIGHT?
o It’s secure because goal #2 says so, right?
o Unfortunately, no.
o The Java Platform shows security wasn’t the primary design focus:
o Limited to no bounds checking
o ZipEntry class allows relative (“../”) paths
o String concatenation of parametric constructors
o The parametric URI class constructors concatenate supplied parameter values
o Weak XML processor behavior by default
o Most packaged XML parsers allow inline DTD processing by default (e.g., DocumentBuilderFactory)

13. i
THE JAVA COMMUNITY PROCESS (JCP)
Created by Sun Microsystems because they didn’t want to work with international
standards organizations (e.g., ISO)
The means by which additional functionality is introduced to the Java Platform
This is done by means of Java Specification Requests (JSR)
A JSR can be for something as small as a modified time format
Or as large as a a whole new container extension (e.g., the Portlet API, JSR 186 &
286)

14. i
UNDER THE HOOD: OBJECT SERIALIZATION
Java Serialization is Sun’s solution to the Marshalling/Unmarshalling problem in
Object Oriented Programming
Marshalling converts an object from its resident format in memory, to a serialized
(linear binary) format suitable to transmitting or storing
Unmarshalling is the reverse
Exposure:
­ Once marshalled, all protections of the JVM and language specification are removed
­ If used as form input, there’s no way to validate the input without processing it first (unmarshalling)
­ There are very limited restrictions that can be put on remote requests to marshall objects

15. i
UNDER THE HOOD: THE RMI API
Remote Method Invocation (RMI) API
Initially released in JDK 1.1 (Feb 1997)
Was Sun’s answer to Remote Procedure Calls (RPCs) in conventional systems
Initially only allowed communications from JVM to JVM
­ This manner of communications is called the Java Remote Method Protocol (JRMP)
­ It is the default transport protocol for RMI
Was later adapted to use CORBA to allow JVM to non-JVM communications
­ This manner of communication is called RMI over IIOP (RMI-IIOP)
­ This is used broadly by large commercial Enterprise Java containers
Between these two milestones, some vendors introduced their own proprietary protocols
­ WebLogic’s “T3” protocol—which is hard-wired into WebLogic to this day

16. FACETS OF AN ATTACK SURFACE 2.2
Application Containers

17. i
STATS 101: WHAT’S IN USE THESE DAYS
(source:
Java
Tools
and
Technologies
Landscape
2016;
RebelLabs)
o Majority are using open source
o Majority are using a “lightweight”
footprint
o For commercial products, dev
deployments != production

18. i
CONTAINER (IN)SECURITY
Apache Tomcat became the de facto reference implementation
With that, also came all of its bad designs and configurations:
­ The “AutoDeployer” functionality
­ Ability to access the application ClassLoader via web deployment configurations
­ The InvokerServlet (for objects, EJBs, etc.)
­ Has been adopted, in some form, by every commercial container incorporating Tomcat
­ Implied trust in the instrumentation implementation
­ Java Management Extensions (JMX) using Management Beans (MBeans) over insecure RMI servers
­ Tunneling of RMI, JMX, and other protocols in-band to HTTP

19. FACETS OF AN ATTACK SURFACE 2.3
Container Extensions

20. i
THERE ARE EXTENSIONS?!
Vendor extensions
IBM WebSphere
BEA/Oracle WebLogic
Oracle JBoss/WildFly
Industry extensions
OASIS
Eclipse Foundation
OSGi Alliance
JCP Extensions
JSR 186 & 286 – The Portlet API – Introduced the notion of a new container type: the Portal Server

21. FACETS OF AN ATTACK SURFACE
2.4
Third-Party Frameworks and
Libraries

22. i
TAXONOMY OF A FRAMEWORK OR LIBRARY
o Basically, anything not covered by the language, core APIs, or Java EE APIs
o “Enterprise” frameworks were rolled out before J2EE was
o It’s the reason J2EE came about
o They are unregulated relative to each other, or the core APIs
o The vast majority of code each framework or library introduces…is unused by the
application importing them!
o “I just need a template engine for my forms…maybe something with domain/range validation”
o The majority of an application’s deployed size is from third-party code
o Increased size == increased risks, threats, and exposures

23. i
WHAT’S IN USE TODAY
o Spring wins!
o But we see unmaintained
frameworks still in use (7% Struts)
(source:
Java
Tools
and
Technologies
Landscape
2016;
RebelLabs)

24. i
HOW BAD COULD IT BE?
Spring – remote code execution
Struts 1.x – remote arbitrary classloader access
Struts 2.x – remote arbitrary classloader access
Apache Jakarta Commons – remote code execution via Java serialization
manipulation

25. LIVE FIRE EXERCISES (DEMO)
Image: US Marines assigned to Mike
Battery, 4th Battalion, 14th Marines - 2004

26. WHERE ARE THE WILD THINGS?
3.0
Overt and Covert Places
Enterprise Java Appears
© Maurice Sendak

27. i
WHERE THEY LIVE
Overt Locations
Application Servers
Big Data servers
Android OS (Dalvik JVM)
Desktops
Covert Locations
Network applications
­ Most “black box” application servers
­ Mail gateways, SIP servers, etc.
Consumer devices (your new fridge)
­ IoT devices
­ Set-top boxes
­ SIP handsets
Database Engines
­ RDBMS SQL/J implementations

28. QUESTIONS & ANSWERS