Welcome and thanks for attending. This is Java Every Day's Exploiting Software Running
on 3 Billion Devices. It's an honor to be speaking in front of you all today. I've been
coming to this con for almost a decade now and this is the first time I'm presenting
and I'm happy to be here. From the looks of it, more than half of you are hung over, so
we're going to take it real slow in the beginning and we'll speed up. You're welcome. So we
hope you enjoy this tour of Java's attack surface and you walk away with a greater understanding
of the vulnerabilities that affect Java and where you can find your next zero day.
The first thing we're going to do is start with the solution actually provided to us
by the U.S. government. Unless it's absolutely necessary to run Java in a web browser, disable
it as described below even after updating to 7 U11. This will help mitigate other Java
vulnerabilities that may be discovered in the future. So this actually came from an
advisory on the day that they released U11.
So the U11 is a great source of information. It's a great source of information. It's a
great tool. If the U.S. government is telling you that you should not use the latest version
of a software, you know it's been a rough year for a piece of software.
But as we know, nobody in this room is actually going to follow what the U.S. government has
to say, so we're forced to do this presentation. So for the agenda, we're going to take a tour
of Java's attack surface. We're going to describe the different vulnerability types that exist
in the framework itself. Then we're going to go through a set of five case studies of
the top vulnerability types in the Java framework.
We'll provide you a set of proof of concepts for triggering those bugs. We actually just
released them last week at Black Hat. They've all been patched. They're from our researchers
in the Zero Day Initiative program. But they're good examples of the classic vulnerability
types in Java. Then we're going to take that and we're going to look at what's being used
in the landscape by attackers and then take an independent look at what Oracle is doing
to fix the problem in Java.
So a quick introduction. If you don't know who I am, my name is Brian Gorence. I work
for Hewlett Packard. I run the Zero Day Initiative program, which is the world's largest vendor
agnostic bug bounty program. So we buy vulnerabilities and exploits. So if you have some and you
want to sell them, let me know. I also run the Pwn2Own hacking competition. And I do root
cause analysis on ZDI submissions. I'm a family man. I've got two kids and a wonderful
wife. And when I'm not spending time with them, I'm looking at assembly code, looking
for bugs.
Hey. I'm Jaylos.
Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos.
Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos.
Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi.
I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos.
Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos.
Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos. Hi. I'm Jaylos.
of submissions in late 2012, early 2013. And at the time the industry was focused on the
sandbox bypass issue. We wanted to look independently at the framework itself and see if that was
actually the case. We wanted to determine what the most common vulnerability type was,
which part of the architecture, specifically the subcomponents of the architecture, contained
the most vulnerabilities and which ones produced the most severe vulnerabilities. Tying that
with what's actually being used in the landscape to determine whether the CVSS scoring system
was correct for those vulnerabilities. And then we also wanted to take that independent
look at Java Oracle's response to the increased vulnerability discoveries in their product.
So let's talk about the sample set that we had for this analysis. We scoped ourselves
to modern‑day Java vulnerabilities, everything ‑‑ every issue patched between 2011 and 2013.
We performed a root cause analysis on over
a hundred and
20 unique Java vulnerabilities. This is probably the largest collection of Java vulnerabilities
outside of Oracle or the NSA or some other nation states. We had the entire zero day
initiative database, numerous vulnerability feeds, all the big name penetration testing
tools and we actually had six Java zero days that we've already submitted to Oracle for
patching in this analysis as well. So this is actually trending for next year's patches
too. When we looked at the threat landscape,
we worked with reversing labs and they provided us a sample set of 52,000 Java malware samples
so we could understand what's actually being used out there today.
If we look at the footprint of Java, it has a huge installation base and that's what makes
it a big red target for attackers. And they actually boast about it ‑‑ Oracle boasts
about it during the installation process. Three billion devices run Java. According
to Oracle, one point billion desktops actually run Java itself. And they produce ‑‑ somebody
produces 1.4 billion Java cards every year. I have no idea what a Java card is, but I'm
pretty sure it can't be updated and if it's running any part of Java, it's probably got
a vulnerability in it. So the other interesting thing is that schools are using Java for ‑‑
their base language for computer science students. So we have thousands and thousands of developers
coming out every year and their core language is Java. As a result, there's been a massive
widespread adoption of Java in the marketplace, in the financial marketplace and in the mobile
space. So it's a really good way to get around Java. And I think the other interesting thing,
too, is that it's a good target for attackers. If we look at the architecture itself, it's
on the slide right here, there's over 50 subcomponents and that's what we're focusing on in this presentation
is what is the most vulnerable pieces of this architecture. And we'll cover a couple
of them which will come up later in the presentation. The deployment subcomponent consists of the
Java Web Star capabilities and the applet capabilities. Java FX is a set of APIs for
creating and delivering rich Internet applications. Java 2D, while it produces a lot of data,
uses 2D graphics. And the library subcomponent, the actual lang and util components provide
the basic functionality for almost every application that's out there. So there is a wide range
of capabilities and it allows developers to quickly implement complicated tasks and deploy
applications quickly. Kind of write once, run everywhere.
Let's look at the vulnerabilities themselves. What you're seeing here is patch statistics
from Oracle, from their patch releases. They've actually patched year over year more vulnerabilities
every year with 50 vulnerabilities being patched that were remotely exploitable in
2011 with over 130 vulnerabilities remotely exploitable in the first half of 2013. So
there's been a huge increase in research in that area and patching in that area. And when
they release a patch, they actually provide quite a bit of metadata. And what you see
on the screen is Java's SE risk matrix.
And it will tell application developers and people deploying the patches what they should
know about the vulnerabilities themselves. And what we see on the screen is a 2D component
vulnerability. It is remotely exploitable without authentication. It garners a score
of ‑‑ a CVSS score of 10.0, which is the most severe vulnerability. And so there's
a lot of information there that we can look at and try to analyze to determine what the
most vulnerable piece of the architecture is. The interesting thing about Oracle is that,
for example, in the way that they actually score the CVSS is they use ‑‑ they assume
that all the users running Java web start and applets are running with administrative
privileges so they are actually giving themselves a more severe score on CVSS than most vendors
probably would. If we take a look just at the information
that's available from the patches, we can see ‑‑ we can start to determine component
rankings for the most vulnerable components in the architecture. And the five that you
on the screen are actually responsible for half of the remotely exploitable vulnerabilities
in Java to date or for 2011 through 2013. Deployment being number one, 2D being number
two, followed by libraries, Java FX and AWT. But if you actually look at the rankings,
you see that the 2D component is producing vulnerabilities with the CVSS score of 9.43
on average. So you can argue that that is actually the worst component in the architecture.
Some other interesting statistics is the 2D ‑‑ there's been several components
that have been patched in every single patch release over the last two and a half years.
That would be deployment and 2D. And at one point there was two components that had double‑digit
CDE counts in a single patch. The deployment which had ten vulnerabilities patched in
February 2013 and Java FX with 12 vulnerabilities in February 2013.
If we tie that with the zero‑day initiative submissions, we start to see that there are
some interesting stuff. We see that on average the zero‑day initiative is receiving about
five Java zero days every quarter with a high of 33 in one quarter thanks to Ben Murphy
and Vitaly for the highest count submitted to our program in one quarter. Our researchers
actually account for 36% of Java vulnerabilities with CVSS score 9 or higher. And that's a
lot of vulnerabilities being patched. On average our researchers are scoring about a 9.28 in
CVSS, so they're focusing on severe vulnerabilities in the framework itself. And we can look
at it in two ways. Either the ZDI researchers are focusing on the components that produce
the most vulnerabilities or the components that they're focusing on end up in the most
vulnerable list when they start looking at them. So it just depends on your perspective.
So what we did is we took the 120 vulnerabilities that we had, we performed a root cause analysis
on it, and we bucketed them into the blue boxes up here.
And the first one is ‑‑
PRIVILEGE IN SANDBOX ISSUES, FOLLOWED BY BUFFER OVERFLOWS, FOLLOWED BY IMPROPER RESTRICTIONS
ON BUFFER OPERATIONS, UNTRUSTED POINTER DEREFERENCES, INTEGRATE OVERFLOW AND A BUNCH OF OTHER ISSUES.
AND WHAT WE FOUND OUT WAS THAT THE SANDBOX BYPASS ISSUE WAS THE MOST POPULAR VULNERABILITY
IN OUR COLLECTION, FOLLOWED BY BUFFER OVERFLOWS. BUT WE COULD TAKE AN EVEN MORE GRANULAR LOOK
AT THEM, THOSE SPECIFIC ISSUES, BY BREAKING THEM OUT INTO EVEN FURTHER SUBCATEGORIES.
SO WE BROKE THEM OUT INTO UNSAFE REFLECTION, WHICH IS THE ABUSE OF THE REFLECTION APIs
TO GAIN ACCESS TO RESTRICTED COMPONENTS AND BYPASS THE SANDBOX. ANOTHER SUBCATEGORY WAS
LEAST PRIVILEGE VIOLATIONS, WHICH IS THE ABUSE OF JAVA'S DUE PRIVILEGE BLOCKS TO EXECUTE
CODE AT A HIGHER PRIVILEGE. AND THEN TYPE CONFUSION, WHICH ARE VULNERABILITIES THAT
CONFUSE JAVA'S TYPE SYSTEM, EITHER THROUGH THE USE OF UNSERIALIZED ‑‑ DESERIALIZED
UNTRUSTED DATA OR OTHER TECHNIQUES.
WE HAD THE CLASSIC HEAP‑BASED BUFFER OVERFLOW AND STACK‑BASED BUFFER OVERFLOW. AND THEN
VARIOUS OTHER, LIKE I SAID, PROCESS CONTROL ISSUES. BUT THE KEY TAKE‑AWAY FOR THIS IS
THAT JAVA SUFFERS FROM EVERY MAJOR CLASS OF BUG THAT'S OUT THERE, AND IT'S A REALLY
GOOD CASE STUDY ON BASICALLY EVERYTHING. ALL RIGHT. SO WE TAKE A LOOK SPECIFICALLY
AT THE SANDBOX BYPASS ISSUE. THOSE ACCOUNTED FOR HALF OF THE VULNERABILITIES IN OUR DATA
SET. IF YOU LOOK AT THE PIE CHART, YOU CAN SEE THAT THE UNSAFE REFLECTION VULNERABILITY
ACCOUNTED FOR HALF OF THOSE. AND THEN FOLLOWED BY LEAST PRIVILEGE VIOLATION, WHICH ACCOUNTED
FOR A QUARTER. THE INTERESTING THING ABOUT THESE IS THEY'RE REALLY POPULAR IN THE EXPLOIT
KIT COMMUNITY BECAUSE YOU DON'T HAVE TO BYPASS ANY OS MITIGATIONS, THEY JUST WORK. YOU DON'T
HAVE TO BYPASS DEP, YOU DON'T HAVE TO BYPASS ASLR, THEY JUST WORK EVERY SINGLE TIME.
EVERY TIME YOU CLICK ON IT, A CALCULATOR POPS UP. IT'S QUITE GOOD. IF YOU LOOK THERE
ON THE ACTUAL TIMELINE ITSELF, WHAT YOU'RE SEEING IS IN THE BLUE CHART, THE ACTUAL TIMELINE,
THOSE ARE THE SUBMISSIONS INTO THE ZERO DAY INITIATIVES SPECIFICALLY FOR SANDBOX BYPASS
ISSUES. SO WE'VE BEEN RECEIVING THESE SINCE EARLY 2011 AND LATE 2010. SO ORACLE'S ACTUALLY
KNOWN ABOUT THESE ISSUES FOR SOME TIME. IF WE LOOK SPECIFICALLY AT MEMORY CORRUPTION
STYLE OF VULNERABILITIES, OUT OF BOUNDS RIGHTS AND HEAT-BASED BUFFER OVERFORCE, YOU CAN
SEE THERE'S TWO CAUSES FOR THE ACCESS VIOLATIONS IN THOSE TWO CLASSES SO WE COULD FURTHER ANALYZE
THOSE BUGS. WE FOUND OUT THAT A THIRD OF THEM WERE CAUSED BY INTEGER OVERFLOWS CAUSING AN
ALLOCATION OF A SMALLER THAN INTENDED BUFFER AND THE REST WERE INCORRECT ARITHMETIC OPERATIONS.
SO IT'S JUST INTERESTING TO SEE THAT THERE'S DIFFERENT TYPES OF MEMORY CORRUPTION ISSUES
AND THE GRANULARITY THAT YOU CAN GET TO. SO TAKING ALL THIS INFORMATION, ALL THE PUBLICLY
AVAILABLE INFORMATION, ALL THE INFORMATION FROM THE ZDI WERE ABLE TO DETERMINE THE TOP
SEVEN VULNERABILITY CLASSES IN JAVA, NUMBER ONE BEING THE UNSAFE REFLECTION VULNERABILITY
WHICH IS MOST POPULAR IN THE LIBRARY SUBCOMPONENT, FOLLOWED BY LEAST PRIVILEGE WHICH WAS ALSO
THE MOST POPULAR IN THE LIBRARY SUBCOMPONENT, FOLLOWED BY TWO CLASSIC MEMORY CORRUPTION
ISSUES, AGAIN, AND LIKE WE TALKED EARLIER, MOST OF THESE ENDED UP IN THE 2D SUBCOMPONENT
WHICH WAS HEAT-BASED BUFFER OVERFLOWS AND OUT OF BOUNDS RIGHTS. THE UNTRUSTED POINTER
DEREFERENCE WHICH IS ACTUALLY MY FAVORITE BUG IN THE JAVA FRAMEWORK, I DON'T KNOW WHY
THEY EXIST BUT THEY DO AND THEY'RE QUITE FUNNY WHEN THEY HAPPEN, FOLLOWED BY WE HAVE HEAT-BASED
BUFFER OVERFLOWS DUE TO INTAGER OVERFLOWS AND THEN TYPE CONFUSION ISSUES. BUT TO MAKE
IT EVEN MORE INTERESTING, WE WANTED TO LAY ALL OF THAT INFORMATION ON TOP OF THE ARCHITECTURE
ITSELF SO WE COULD UNDERSTAND WHAT TYPE OF VULNERABILITIES EXISTED IN WHICH SUBCOMPONENTS.
AND THAT'S WHAT YOU'RE SEEING.
THIS IS REALLY ONE OF THE FIRST TIMES THERE'S BEEN A ROAD MAP FOR VULNERABILITIES IN JAVA
FOR YOU TO START LOOKING FOR THEM. WHAT YOU SEE IS THE SUBCOMPONENTS, THEN THE PACKAGES
THAT HAD VULNERABLE CODE IN THEM, FOLLOWED BY THE TYPE OF VULNERABILITIES THAT EXISTED
IN THAT CODE BASE. AND YOU SEE THE 2D COMPONENT SUFFERS FROM MEMORY CORRUPTION ISSUES AND
THAT'S MOSTLY DUE TO ITS NATIVE CODE USE. THE DEPLOYMENT SUBCOMPONENT SUFFERED FROM
NUMEROUS COMMAND INJECTION AND PROCESS CONTROL PROBLEMS.
AND THE REST OF THEM ON THE SLIDE HERE WERE SANDBOX BYPASS ISSUES.
THE REST OF THE SUBCOMPONENTS IN THE ARCHITECTURE, WE HAD THE JAVA FX COMPONENT WHICH SUFFERED
FROM A LOT OF UNTRUSTED POINTER DEREFERENCES AND THAT'S ACTUALLY ONE OF OUR CASE STUDIES.
THE LIBRARY SUBCOMPONENT WHICH SUFFERED FROM SANDBOX ISSUES AND ONE OF THE SUBCOMPONENTS
ON THE SCREEN IS ACTUALLY RELATIVELY INTERESTING BECAUSE IT SUFFERS FROM BOTH SANDBOX AND MEMORY
CORRUPTION ISSUES. SO THAT'S THE SOUND COMPONENT.
BUT THIS IS REALLY VALUABLE FOR THIS AUDIENCE SPECIFICALLY BECAUSE IT'S A MAPPING THAT YOU
CAN USE TO GO BUG HUNTING AND LOOK FOR STUFF AND HOPEFULLY SUBMIT THEM TO THE ZERO DAY
INITIATIVE BUT THE ‑‑ BASICALLY YOU'RE ABLE TO TAKE A LOOK AT THE 2D COMPONENT AND
YOU KNOW THAT YOU SHOULD BE LOOKING FOR HEAT BASED STUFF OR OVERFLOWS OR MEMORY CORRUPTION
ISSUES. IT'S ALSO USEFUL WHEN A PATCH COMES OUT.
YOU CAN USE THIS AS A WAY TO SCOPE WHAT YOU NEED TO LOOK FOR WHEN ORACLE PATCHES BECAUSE
THEY GIVE YOU WIDESPREAD.
WHICH COMPONENT THEY'RE PATCHING IN THAT PATCH ITSELF.
SO NOW WHAT WE'RE GOING TO DO IS TAKE A LOOK AT A SET OF CASE STUDIES FOR THE MOST POPULAR
VULNERABILITY TYPES THAT WE TALKED ABOUT IN THE SLIDES.
THERE'S A SANDBOX ‑‑ WE'RE GOING TO DO TWO CASE STUDIES ON SANDBOX ISSUES IN THE
LIBRARY SUBCOMPONENT, TWO DIFFERENT MEMORY CORRUPTION ISSUES IN THE 2D COMPONENT AND
UNTRUSTED POINTER DEREFERENCING IN THE JAVA FX COMPONENT.
AND AGAIN, THESE POCS WERE JUST RELEASED AND SO, YOU KNOW, THIS IS PROBABLY ONE OF THE
‑‑ THE SECOND TIME THEY'VE ACTUALLY BEEN SHOWN PUBLICLY.
ALL RIGHT.
SO THE FIRST BUG WE'RE GOING TO GO OVER IS IN THE LIBRARY SUBCOMPONENT AND IT'S A PRIVILEGED
AND SANDBOX ISSUE DUE TO UNSAFE REFLECTION.
BUT AS A QUICK PRIMER ON WHAT UNSAFE REFLECTION IS, IMAGINE YOU HAVE A DISPATCH METHOD THAT
TAKES A STRING AND THEN SOME ARBITRARY NUMBER OF ARGUMENTS.
BASED ON THE STRING, IT THEN WILL LOOK UP A FUNCTION AND MAKE A CALL.
SO IF YOU PASS IT ADD, IT WILL LOOK UP THE ADD METHOD.
AND DYNAMICALLY INVOKE IT.
UNSAFE REFLECTION IS WHEN YOU DON'T HAVE PROPER VALIDATION ON THAT STRING SUCH THAT YOU COULD
CALL THE DELETE EVERYTHING METHOD OR SOMETHING ELSE.
IN CVE 2013-2436, BEN MURPHY FOUND THAT, WELL, USING SECURITY EXPLORATIONS ISSUE 54, AND
I'LL TALK ABOUT THAT IN A SEC, YOU COULD ACHIEVE A SANDBOX BYPASS.
ISSUE 54 MAKES USE OF THE INVOKE DYNAMIC JVM OPCODE TO GET ACCESS TO A PROTECTED METHOD
OF A CLASS WITHOUT ACTUALLY HAVING ‑‑ WITHOUT HAVING A CLASS.
HAVING AN INSTANCE OF IT.
IT REQUIRES THE USE OF A CUSTOM CREATED CLASS, WHICH MEANS USUALLY THE USE OF A FRAMEWORK
SUCH AS ASM2, BUT IF YOU REALLY WANTED, YOU COULD HARD CODE THE BYTES.
AFTER YOU'VE DONE THAT, YOU CAN USE METHOD HANDLE.BINDTO TO GET ON THE CLASS LETTER,
AND THAT WILL BIND THE METHOD HANDLE TO THE CLASS LETTER SUCH THAT YOU CAN ACTUALLY INVOKE
IT.
ONCE YOU'VE DONE THAT, ALL YOU HAVE TO DO IS CREATE A PERMISSION DOMAIN THAT CONTAINS
ALL PERMISSION.
AND YOU'LL BE ABLE TO LOAD IT.
GO TO CLASS AND DISABLE THE SECURITY MANAGER.
YOU DO THAT EITHER THROUGH THE USE OF A STATIC INITIALIZER WITHIN THAT CLASS OR WITHIN A
METHOD IN THAT CLASS.
AND I'LL GO INTO THAT IN THIS SLIDE.
SO HERE YOU CAN SEE ‑‑ INVOKE DYNAMIC WOULD BE OUR CUSTOM CREATED CLASS AND GET
CLASS HANDLE WOULD BE THE METHOD WE'VE DEFINED WITHIN IT.
ALL THAT WILL DO IS MAKE A CALL AND IT WILL CALL THE SET DEFINE CLASS HANDLE METHOD HERE
AND IT WILL SEND A MESSAGE.
IN THIS CASE IT WILL BE A METHOD HANDLE TO THE CLASS LOADER'S PROTECTED DEFINE CLASS
METHOD.
WE THEN SAVE IT OFF INTO OUR DEFINE CLASS HANDLE STATIC VARIABLE SO WE CAN ACCESS IT
LATER ON.
ONCE WE'VE DONE THAT, THEN WE CREATE A PERMISSION OBJECT AND ADD ALL PERMISSION TO IT AND CREATE
A PROTECTION DOMAIN BASED OFF THAT.
ONCE WE'VE DONE THAT, WE GET ACCESS TO OUR CLASS LOADER AND WE BIND THE METHOD HANDLE
TO OUR CLASS LOADER.
AT THIS POINT WE CAN INVOKE THE DEFINE CLASS METHOD.
AND LOAD A MALICIOUS CLASS THAT WILL THEN BE ABLE TO DISABLE THE SANDBOX OR THE SECURITY
MANAGER.
THIS WAS PATCHED IN JDK 7 UPDATE 21 THROUGH THE USE OF THE CONVERT OR BY UPDATING THE
CONVERT METHOD IN SUN INVOKE UTIL.WRAPPER.
THE MAIN TAKEAWAY HERE IS THAT THERE'S NOW AN IF CHECK SUCH THAT IF THE PARAMETER CLASS
IS NOT AN INTERFACE, WE WILL CAST THE GIVEN OBJECT TO THE GIVEN CLASS.
WE CAN SEE IN THE PREVIOUS VERSION THAT THERE IS NO SUCH CHECK.
AND AS A RESULT, THE AFTERMENTION POC WILL RESULT IN A CLASS CAST EXCEPTION.
THE NEXT WEAKNESS IS ALSO IN THE LIBRARY SUBCOMPONENT AND IT IS A PRIVILEGE AND SANDBOX ISSUE DUE
TO LEAST PRIVILEGE VIOLATION.
LEAST PRIVILEGE VIOLATION EXISTS BECAUSE OF THE ACCESS CONTROLLER'S DUE PRIVILEGE BLOCKS.
THEY TAKE TWO ARGUMENTS OR THE DUE PRIVILEGE BLOCKS TAKES TWO ARGUMENTS, THE FIRST OF
WHICH IS A CLASS THAT CAN BE ANONYMOUS OR OTHERWISE.
THAT EXPOSES A RUN METHOD.
THIS RUN METHOD WILL GET RUN AT A DIFFERENT CONTEXT THAN YOU'RE CURRENTLY WITHIN.
THE SECOND OPTIONAL ARGUMENT IS AN ACCESS CONTROL CONTEXT AND THAT'S BASICALLY A SAVED
STATE OF THE SECURITY CONTEXT THAT YOU'RE RUNNING WITHIN.
WHEN YOU'RE RUNNING AN UNTRUSTED APLET, YOU'RE GOING TO HAVE A MUCH LOWER PRIVILEGE LEVEL
THAN SAY THE LIBRARY CODE WHICH COULD DO WHATEVER IT WANTED.
BEN MURPHY FOUND IN CVE 2013-1484 THAT PROXY.NEWPROXY INSTANCE DOES NOT SAVE THE CALLER'S ACCESS
CONTROL CONTEXT.
AS A RESULT, IT WILL USE THE LIBRARIES.
UNFORTUNATELY, IT REQUIRES AN INVOCATION HANDLER THAT IS ABLE TO EXECUTE AN ARBITRARY STATEMENT.
HE THEN FOUND THAT METHOD HANDLE PROXIES HAS A METHOD AS INTERFACE INSTANCE THAT CAN DO
EXACTLY THIS AND USING THIS YOU CAN ACCESS THE DEFINE CLASS METHOD OF CLASS LOADER AND
LOAD A MALICIOUS CLASS.
YOU STILL HAVE ONE HURDLE TO GO THROUGH IN THAT YOU HAVE TO BE ABLE TO EXECUTE THIS BOUND
METHOD WITHOUT PUTTING ANY USER FRAMES ON THE STACK, BUT THAT'S STILL DOABLE.
SO HERE WE CAN SEE A LITTLE SNIPPET OF WHAT YOU WOULD HAVE TO DO.
YOU WOULD START OFF BY DECIDING ON A CLASS THAT HAS AN INSTANCE METHOD YOU WANT TO RUN
AT A HIGHER PRIVILEGE AND YOU WOULD INSTANTIATE IT.
YOU THEN CREATE A METHOD TYPE BASED OFF THE INSTANCE METHOD'S RETURN VALUE AND THE PARAMETERS
IT TAKES AND THE CLASSES FOR PARAMETERS IT TAKES.
YOU THEN USE THE FIND VIRTUAL METHOD TO LOOK UP THAT METHOD BASED OFF THE DESIRED CLASS,
THE NAME OF THE METHOD.
AND THE METHOD TYPE YOU JUST CREATED.
YOU BIND IT TO THE ‑‑ YOU BIND THE METHOD HANDLE YOU JUST CREATED TO THE DESIRED CLASS
AND THEN YOU RUN THIS METHOD HANDLE.DROP ARGUMENTS WHICH AS THE NAME IMPLIES DROPS ARGUMENTS.
WHAT THIS MEANS IS THAT WHEN THE METHOD HANDLE IS ACTUALLY INVOKED, IN THIS CASE THE FIRST
THREE ARGUMENTS, A OBJECT ARGUMENT, A METHOD ARGUMENT AND AN OBJECT ARRAY ARGUMENT WILL
JUST BE DROPPED AND NOT BE SENT TO THE ACTUAL METHOD THAT'S BEING CALLED.
AT THIS POINT YOU CREATE YOUR INVOCATION HANDLE.
BY MAKING USE OF METHOD HANDLES.AS INTERFACE INSTANCE AND YOU STILL HAVE TO CREATE THE
PROXY WITH PROXY.NEW PROXY INSTANCE AND YOU'LL HAVE TO DO THAT IN A WAY THAT DOES NOT ADD
USER FRAMES BUT THAT IS DOABLE.
WE HAVEN'T ADDED IT BECAUSE ADDING IT MAKES IT VERY CLEAR WHAT THE ACTUAL EXPLOIT IS.
SO THIS WAS PATCHED IN THREE CLASSES.
FIRST CLASS IS THE METHOD HANDLES CLASS AND THAT WAS PATCHED FIRST IN THE FIND VIRTUAL
METHOD.
WHICH NOW MAKES USE OF THE FIND VIRTUAL METHOD.
THE MAIN TAKE AWAY FROM THIS IS THAT YOU HAVE THE POTENTIAL FOR NULL TO BE RETURNED
HERE WHICH MEANS WHEN YOU CALL ACCESS VIRTUAL RIGHT BELOW AND FIND VIRTUAL YOU COULD POTENTIALLY
BE SENDING NULL THERE.
IN METHOD HANDLE PROXIES YOU HAVE AN UPDATED AS INTERFACE INSTANCE METHOD WHICH NOW MAKES
USE OF THE MAYBE BIND CALLER FUNCTION.
AND IN THE MAYBE BIND CALLER THE MAIN TAKE AWAY IS THAT IF THE PARAMETER CLASS IS NULL
OR IF THE PARAMETER CLASS IS NULL YOU CAN USE THE MAYBE BIND CALLER FUNCTION.
IF THE PARAMETER CLASS IS CLASS LOADERS NULL WHICH MEANS IT'S LIBRARY CODE, THEN WE'LL
JUST RETURN THE METHOD HANDLE WITHOUT ANY FURTHER MODIFICATION OF IT.
ONLY THEN WILL WE, IF THAT'S NOT THE CASE, WILL WE CALL THE MAYBE OR THE BIND CALLER
METHOD.
THE LAST FUNCTION OR LAST CLASS THAT WAS MODIFIED AS A RESULT OF THIS PATCH IS THE
METHOD HANDLE IMPLEMENTATION CLASS AND SPECIFICALLY THE BIND CALLER METHOD.
THE MAIN TAKE AWAY HERE IS THAT THE PARAMETER CLASS IF IT'S NULL WILL JUST THROW AN INTERNAL
ERROR.
PREVIOUS TO THIS YOU WOULD TRY.
TO CONTINUE ON USING A C TRAMPOLINE.
THAT SAID WE WOULDN'T ACTUALLY MAKE IT HERE BECAUSE WE WOULD DIE IN THIS CHECK AND JUST
RETURN THE METHOD HANDLE.
ALL RIGHT.
SO THE NEXT BUG IS IN THE 2D SUBCOMPONENT AND IS A HEAT BASE BUFFER OVERFLOW DUE TO
INTEGER OVERFLOW.
IT WAS REPORTED TO US BY AXT AXT AND CVE20130809 EXISTS IN NATIVE C CODE.
JAVA HAS WHAT'S CALLED JAVA NATIVE INTERFACE.
AND THAT ALLOWS FOR, WELL, NATIVE CODE TO BE CALLED FROM JAVA LAND.
IN THIS PARTICULAR CASE THE ISSUE LIES IN SUN ADWT MEDIALIB MLIB IMAGE CREATE.
AND THE ISSUE LIES BECAUSE OF, WELL, IMPROPER VALIDATION.
YOU HAVE FOUR ARGUMENTS THAT ARE PASSED TO THIS FUNCTION MLIB IMAGE CREATE.
THE FIRST IS MLIB TYPE AND THAT'S JUST A TYPE SPECIFIER THAT'S USED IN A SWITCH STATEMENT
LATER ON.
THEN YOU HAVE THREE ARGUMENTS, CHANNELS, WIDTH AND HEIGHT THAT ARE ALL MLIB S32 WHICH IS
A TYPE DEF FOR A SINE 32 BIT INTEGER.
SO THERE ARE SOME BOUNDS PLACED ON THE INPUT VARIABLES IN THAT WIDTH AND HEIGHT MUST BE
GREATER THAN ONE OR GREATER THAN ZERO AND CHANNELS MUST BE GREATER THAN ONE AND LESS
THAN FOUR.
BUT THEN ONCE THAT'S DONE, IF THE MLIB TYPE IS MLIB INT, WE WILL MULTIPLY HEIGHT AND
CHANNELS BY FOUR AND SORRY, WIDTH AND CHANNELS BY FOUR AND SET THAT TO WB.
THEN LATER ON WE WILL MULTIPLY THAT VALUE BY HEIGHT.
SO IF HEIGHT TIMES WIDTH TIMES WIDTH.
CHANNELS TIMES FOUR IS GREATER THAN TWO TO THE 32ND POWER, WE'LL END UP SETTING A VALUE
TO MALIC THAT IS SMALLER THAN WE ACTUALLY REQUIRE.
AS A RESULT, WHEN WE ACTUALLY START WRITING TO THIS BUFFER, WE'LL OVERFLUE.
THIS WAS PATCHED IN JDK 7 UPDATE 17 THROUGH THE USE OF THE SAFE TO MULT MACRO.
AND THEY ADDED THIS CHECK ‑‑ THEY ADDED THE USE OF THIS MACRO EVERY TIME THEY DID
ANY SORT OF MULTIPLICATION.
SO HERE WE CAN SEE THAT THEY'RE MAKING USE OF THE SAFE TO MULT MACRO.
AND IF IT FAILS, THEY'LL RETURN NULL.
OTHERWISE THEY'LL ACTUALLY DO THE MULTIPLICATION ON WIDTH AND CHANNELS.
HERE WE CAN SEE THAT WE'RE MAKING USE OF THE MACRO YET AGAIN AND CHECKING IT AGAINST WB
AND FOUR AND ONLY IF IT SUCCEEDS WILL WE MULTIPLY WB BY FOUR.
SAME GOES FOR WB AND HEIGHT BEFORE PASSING IT TO MALIC.
SO THE NEXT VULNERABILITY IS ALSO IN THE 2D SUBCOMPONENT AND IS AN OUT OF BOUNDS WRITE
DUE TO INTEGER OVERFLOW.
IT WAS REPORTED TO US BY VITALIY TOROPOLOV.
AND IT EXISTS IN THE IT ALSO EXISTS IN NATIVE CODE, SPECIFICALLY IN SUN ADWT ADWT IMAGE REP.
IT'S ACCESSIBLE VIA SUN ADWT IMAGE IMAGE REPRESENTATION AND THE ISSUE LIES IN THE LAST PARAMETER WHICH
IS AN INTEGER COMPONENT RASPBERRY OBJECT THAT HAS A SCAN LINE STRIDE FIELD THAT IS
USED WITHOUT ANY VALIDATION WHATSOEVER.
SO HERE WE CAN SEE A SNIPPET OF THE SET ICM PIXELS FUNCTION WHERE WHICH IS THE VULNERABLE
FUNCTION.
AND HERE WE CAN SEE THAT THE J OBJECT GICT IS THAT.
IT'S THE IMAGE COMPONENT RASPBERRY.
HERE IS WHERE WE'RE GETTING ACCESS TO THE SCAN LINE STRIDE FIELD AND WE'RE NOW SETTING
DESTINATION AND SOURCE POINTERS.
YOU CAN SEE THAT THE DESTINATION POINTER IS BEING SET BASED OFF SOME MATH THAT USES THE
SCAN LINE STRIDE FIELD.
WE THEN HAVE AN OUTER FORELOOP WHERE YOU HAVE THE SOURCE POINTER AND DESTINATION POINTER
INCREMENTED BY PIXEL STRIDE AND SCAN LINE STRIDE.
AND THIS IS DONE WITHOUT ANY SORT OF VALIDATION TO PREVENT INTEGER OVERFLOW.
WE THEN UPDATE THE SOURCE AND DESTINATION POINTERS THAT WE'RE ACTUALLY GOING TO BE WRITING
TO AND THEN INSIDE OUR INTERLOOP WE ONCE AGAIN INCREMENT DESTINATION POINTER WITHOUT ANY VALIDATION
WHATSOEVER.
FINALLY WE ACTUALLY HAVE THE WRITES TO IT.
SO THIS WAS PATCHED IN JDK 7 UPDATE 21 THROUGH THE USE OF THREE NEW MACROS, CHECK STRIDE,
CHECK SOURCE AND CHECK DESK AND IN ADDITION ORACLE ACTUALLY DID PROPER PATCHING OF THIS
FUNCTION BY ACTUALLY VALIDATING EVERY ARGUMENT TO THIS FUNCTION.
SO HERE ARE THE THREE MACROS.
YOU CAN SEE THAT THEY'RE CHECKING FOR ANY INTEGER OVERFLOW BY ACTUALLY DOING THE CALCULATIONS.
IF ONE OCCURS, THEN THEY'LL RETURN FALSE AND NOT CONTINUE ON.
SAME GOES FOR THE CHECK SOURCE AND THE CHECK DESK FUNCTIONS.
AND HERE YOU CAN SEE THAT NOW X AND W AND Y AND H ARE NOW ACTUALLY BEING VALIDATED
AND YOU CAN SEE THAT THE DATA OFFSETS ARRAY IS ALSO BEING CHECKED JUST IN THIS CASE TO
MAKE SURE IT'S NOT NULL.
AND THEN HERE'S THE DATA OFFSETS ARRAY.
AND HERE YOU CAN SEE THE USE OF THE THREE NEW MACROS.
SO THE LAST VULNERABILITY IS IN THE JAVA FX SUBCOMPONENT AND IS AN UNTRUSTED PORNIDI
REFERENCE WHICH AS BRIAN MENTIONED IS HIS FAVORITE BUG IN JAVA.
IT WAS REPORTED TO US BY VITALIY TOROPOV AND THIS PARTICULAR ONE EXISTS IN THE COM
SUN WEB PAIN PLATFORM WEB PAGE CLASS.
THE ISSUE LIES BECAUSE THE WEB PAGE CLASS HAS NATIVE FUNCTIONS THAT ARE EXECUTED THROUGH
JAVA NATIVE INTERFACE.
AND ONE OF THEM WILL ALLOCATE A BUFFER INSIDE.
THIS IS THEN STORED IN THE P PAGE PRIVATE INSTANCE VARIABLE.
THERE IS A PUBLIC GET PAGE ACCESSOR METHOD AND SOME OF THE METHODS WITHIN THE WEB PAGE
CLASS WILL DIRECTLY ACCESS THE P PAGE VARIABLE WHEREAS OTHERS WILL ACTUALLY MAKE USE OF THE
GET PAGE ACCESSOR METHOD.
AS A RESULT WE CAN SUBCLASS THE CLASS AND REIMPLEMENT GET PAGE AND WE CAN ACHIEVE MEMORY
CORRUPTION.
SO HERE WE CAN SEE THAT THE CLASS IS INDEED PUBLIC WHICH MEANS WE
CAN SUBCLASS IT.
HERE WE CAN SEE THAT THE GET PAGE METHOD IS ALSO PUBLIC WHICH ALSO MEANS WE CAN SUBCLASS
IT.
AND HERE IS ONE OF THE NATIVE FUNCTIONS TWK SET EDITABLE.
IT'S PRIVATE BUT ABOVE IT WE CAN SEE THAT THERE'S A SET EDITABLE FUNCTION THAT IS PUBLIC
SO WE CAN ACTUALLY CALL IT AND WITHIN IT WE SEE A CALL TO TWK SET EDITABLE WHERE WE'RE
USING GET PAGE, THE VALUE RETURNED BY GET PAGE AS THE PARAMETER.
SO THIS WAS PATCHED.
IN AN INTERESTING WAY.
WE ACTUALLY GOT A SLEW OF UNTRUSTED POINTER DEREFS ALL AT THE SAME TIME AND IN JDK 7 UPDATE
13, ORACLE IN KIND OF A MAKE THE HURTING STOP REACTION JUST FLAT OUT BANNED THE COM SUN
WEB PAIN PACKAGE.
AS A RESULT, ANY ATTEMPT TO ACCESS ANY CLASS WITHIN THAT PACKAGE OR SUBPACKAGE WOULD RESULT
IN A PACKAGE ACCESS EXCEPTION ERROR.
THERE'S ALSO A PACKAGE DEFINITION RESTRICTION LIST AND THAT ALSO CONTAINS THE SAME THING.
IN FACT, BRIAN WILL GO INTO THAT A LITTLE LATER.
IT THEN PROPERLY PATCHES THIS IN JDK 7 UPDATE 21 BY MAKING THE GET PAGE METHOD PACKAGE PRIVATE
AND FINAL.
AND WITH THAT, I'M GOING TO TURN IT BACK OVER TO BRIAN SO HE CAN GO OVER TO PONE TO OWN AND
HOW THESE ARE UTILIZED IN THE THREAT LANDSCAPE.
ALL RIGHT, SO THE FIRST PLACE WE'RE GOING TO LOOK AT TO SEE HOW PEOPLE ARE ACTUALLY
USING THE BUGS THEMSELVES IS PONE TO OWN.
THIS YEAR WHEN WE'RE ORGANIZING PONE TO OWN, WE DECIDED TO EXPAND THE SCOPE OF THE COMPETITION,
INCLUDE BROWSER PLUGINS INTO IT, MOSTLY BECAUSE THEY WERE BEING USED BY MALWARE AND THEY WERE
BEING UTILIZED IN TARGETED ATTACKS, SO WE ADDED FLASH, READER AND OF COURSE JAVA.
AND WHEN WE DID THAT, SOME PEOPLE THOUGHT WE WERE MAKING IT TOO EASY AND YOU CAN SEE
COASTY'S QUOTE UP THERE, ZDI IS GIVING OUT $20,000 FOR FREE, WHICH AT THE TIME IT
FELT LIKE THAT BECAUSE THERE WAS A LOT OF ZERO DAY ACTIVITY GOING ON IN JAVA, THERE
WAS A LOT OF INDEPENDENT DISCOVERY GOING ON, BUT WE THOUGHT IT WAS IMPORTANT TO HIGHLIGHT
THE BROWSER PLUGINS.
AND WHAT OUR EXPECTATION WAS WAS THAT THE RESEARCHERS WHO WERE GOING TO COME AND PARTICIPATE
IN PONDO WOULD BRING SANDBOX BYPASSES DUE TO UNSAFE REFLECTION, BUT THAT ACTUALLY TURNED
OUT NOT TO BE THE CASE.
THEY ACTUALLY BROUGHT THE TOP FOUR VULNERABILITY TYPES AFFECTING JAVA, AND IF WE LOOK AT THE
ACTUAL PARTICIPANTS, JAMES BROUGHT A LEAST PRIVILEGE VIOLATION, JOSH DRAKE BROUGHT A
OUT OF BOUNDS WRITE AND READ, VOOPIN SECURITY BROUGHT A HEAT BASED BUFFER OVERFLOW AND
BEN MURPHY BROUGHT AN UNSAFE REFLECTION BUG.
SO IT'S KIND OF INTERESTING.
IT'S INTERESTING TO SEE THAT BASICALLY ALL THE TOP VULNERABILITY TYPES COULD BE LEVERAGED
AND USED TO WIN MONEY IN OUR COMPETITION.
ONE OF MY FAVORITE QUOTES WHEN WE WERE RUNNING PONDO WAS VOOPIN SECURITY, WE ASKED THEM IF
THEY WERE GOING TO BRING US AN UNSAFE REFLECTION VULNERABILITY AND THEY GO, AND CHOKEY SAYS,
OF COURSE WE'VE GOT UNSAFE REFLECTION VULNERABILITIES, BUT WE WANTED TO BRING YOU SOMETHING INTERESTING.
SO THEY BROUGHT THE HEAT BASED BUFFER OVERFLOW.
SO LOOKING AT THE LANDSCAPE ITSELF, THE EXPLOIT KIT AUTHORS ARE REALLY JUMPING ON THE BANDWAGON.
YOU CAN SEE THAT IN THE CHART.
THIS CHART IS DEPICTING THE 52,000 MAUER SAMPLES THAT WE HAD AND WHICH VULNERABILITY TYPES
AND CVEs THEY WERE LEVERAGING.
AND YOU SEE A HUGE INCREASE IN DECEMBER AND JANUARY, THE RECENT MONTHS.
THIS ACTUALLY MIRRORS THE INDEPENDENT DISCOVERIES THAT WERE GOING ON AT THE TIME.
AND SO THAT'S JUST AN INTERESTING DATA POINT THAT PEOPLE ARE LOOKING AT JAVA, IT IS A VERY
POPULAR APPLICATION TO AUDIT.
AND IF YOU'RE AN EXPLOIT KIT DEVELOPER, YOU ACTUALLY PRETTY MUCH ARE REQUIRED TO INCLUDE
TWO PLUS JAVA VULNERABILITIES JUST TO STAY COMPETITIVE WITH THE OTHER EXPLOIT KITS ON
THE MARKET.
SO IT'S QUITE A COMPETITIVE MARKER OUT THERE FOR JAVA BUGS.
THE ATTACKERS ARE UPPING THEIR GAME.
ONE OF THE INTERESTING THINGS ABOUT THE CHART ITSELF IS IT SHOWS THAT VULNERABILITIES IN
2011 THAT WERE DISCOVERED IN 2011 ARE STILL ACTIVELY BEING USED ON THE WEB.
AND THAT'S BECAUSE THE INSTALLATION PROCESS FOR JAVA IS LESS THAN OPTIMAL.
THERE HAS BEEN SEVERAL STUDIES THAT HAVE COME OUT RECENTLY STATING THAT 93% OF THE
INSTALL BASE HASN'T UPDATED TO THE LATEST PATCH A MONTH AFTER IT'S RELEASED AND SOMETIMES
EVEN UP TO A YEAR.
AND THE FACT IS THAT MULTIPLE MAJOR VERSIONS OF JAVA CAN BE INSTALLED ON A DESKTOP AT ONE
TIME.
AND AS A RESULT, ATTACKERS CAN ACTUALLY TARGET OLDER VERSIONS.
SO WE WANTED TO LOOK AT WHAT'S ACTUALLY BEING UTILIZED COMPARED TO WHAT'S ACTUALLY IN
THE FRAMEWORK ITSELF.
AND WHAT WE SEE IS THAT TYPE CONFUSION IS ACTUALLY THE MOST COMMON BUG TO BE UTILIZED
IN THE LANDSCAPE WITH OVER TWO-THIRDS OF THE SAMPLE SET BEING A TYPE CONFUSION BUG.
WHAT YOU SEE IS UNSAFE REFLECTION TAKING A QUARTER FOLLOWED BY LEAST PRIVILEGE VIOLATION
AND THE THREE OF THE SANDBOX ISSUES ACCOUNT FOR ALMOST 90% OF THE ACTUAL ACTIVITY OUT
THERE ON THE WEB.
MEMORY CORRUPTION ISSUES DO END UP BEING EXPLOITED BUT IT'S VERY RARE AND SO THERE'S
MORE FOCUS.
AND IN REALITY.
THE SANDBOX ISSUES ARE WORTH MORE BECAUSE YOU DON'T HAVE TO BYPASS OS MITIGATIONS LIKE
DEP AND ASLR.
SO NOW WE'RE GOING TO GO THROUGH SEVERAL EXPLOITATION TECHNIQUES AND ONE THAT IS NOT AS COMMON BUT
INTERESTING TO LOOK AT.
ALL RIGHT.
SO THE MAIN GOAL WITH JOB EXPLOITATION IS AT LEAST WITH SANDBOX BYPASSES IS TO RUN
SYSTEM.SET SECURITY MANAGER AND PASS NO AS THE ARGUMENT.
THIS HAS THE EFFECT OF NULLIFYING THE SECURITY MANAGER WHICH MEANS AT THAT POINT YOU CAN
X ‑‑ YOU CAN RUN OR DOWNLOAD ANYTHING YOU WANT.
FOR MEMORY CORRUPTION YOU USUALLY HAVE YOUR USUAL TECHNIQUES SUCH AS OVERWRITING A FUNCTION
POINTER BUT YOU STILL HAVE TO BYPASS DEP AND ASLR.
SOMETHING THAT'S POTENTIALLY EASIER IS A TECHNIQUE THAT WAS GIVEN TO US BY VITALI TURAPOV
WHICH IS TO MAKE USE OF THE JAVA BEAN STATEMENT CLASS.
AND I'LL GO INTO THAT ON THE NEXT SLIDE.
SO JAVA BEAN STATEMENT REPRESENTS A JAVA ‑‑ SINGLE JAVA EXPRESSION OF THE FORM INSTANCE
VARIABLE DOT INSTANCE METHOD AND THEN ARGUMENTS.
DO IS SAY YOU HAVE AN OUT OF BOUNDS WRITE AND AN OUT OF BOUNDS READ, YOU COULD ALLOCATE
YOUR BUFFER THAT'S VULNERABLE, THEN ALLOCATE ‑‑ OR CREATE A STATEMENT.
A STATEMENT HAS AN IMPLICITLY CREATED ACCESS CONTROL CONTEXT THAT IS, WELL, CLEARLY GOING
TO BE WEAKER SINCE YOU'RE GOING TO HAVE IT CREATED IN YOUR UNTRUSTED APPLETTE.
YOU THEN CREATE A MORE POWERFUL ACCESS CONTROL CONTEXT BY CREATING A PERMISSIONS OBJECT,
ADDING ALL PERMISSION TO IT, THEN YOU CREATE A PROTECTION DOMAIN ARRAY OUT OF THAT AND
THEN CREATE AN ‑‑
ACCESS CONTROL CONTEXT USING THAT.
YOU THEN USE YOUR MEMORY CORRUPTION BUG TO BASICALLY SWAP OR REPLACE THE STATEMENTS ACCESS
CONTROL CONTEXT WITH YOURS AND THEN YOU CAN JUST EXECUTE THE STATEMENT AND IT WILL EXECUTE
WITH MORE PRIVILEGES.
NOW GOING TO GO THROUGH A PIECE OF MAUER WE HAVE THAT ACTUALLY MAKES USE OF A SANDBOX
BYPASS AND IT'S CVE20125076, BASIC FUNCTIONALITY AND I'LL SHOW THE CODE IN A SEC, MAKES USE
OF THE GENERIC CONSTRUCTOR CLASS TO INSTANTIATE A ‑‑
ANONYMOUS CLASS LOADER INSTANCE, ONCE IT DOES THAT IT USES MANAGE OBJECT MANAGER FACTORY
TO GET ACCESS TO THE LOAD CLASS PROTECTED METHOD AND IT THEN USES THE ‑‑ IT THEN INVOKES
THAT CLASS ‑‑ INVOKES THAT METHOD ON A MALICIOUS CLASS THAT IMPLEMENTS PRIVILEGE
EXCEPTION ACTION AND ONCE IT'S DONE THAT IT THEN NULLIFIES THE SECURITY MANAGER AND
RUNS ITS STAGE TWO.
SO HERE WE SEE THAT THE FIRST THING IT'S DOING IS GETTING THE JOB
VERSION AND CHECKING TO SEE IF IT'S 1.7.
SO IF IT'S NOT JDK7 IT'S JUST GOING TO BAIL OUT.
IF IT IS, IT THEN GRABS THE CLASS THAT IMPLEMENTS PRIVILEGE EXCEPTION ACTION AND TURNS IT INTO
AN ARRAY OF BITES.
WE THEN MAKE USE OF GENERIC CONSTRUCTOR TO INSTANTIATE THE ANONYMOUS CLASS LOADER AND
WE THEN GET ACCESS TO THE LOAD CLASS PROTECTED METHOD USING MANAGE OBJECT MANAGER FACTORY.
AT THIS POINT WE INVOKE THE METHOD AND LOAD OUR MALICIOUS CLASS.
AND WE THEN CALL METHOD WITHIN IT AND FORGOT TO MENTION ALL THESE FUNCTION NAMES ARE OBVIOUSLY
VERY CLEAR AND EASY TO UNDERSTAND BECAUSE WE'VE DEOFFUSCATED IT.
THIS PARTICULAR PIECE OF MALWARE WAS USING ALATORY'S JAVA OFFUSCATOR BUT THEY DID NOT
USE ADVANCED OPTIONS SUCH AS CODE FLOW OFFUSCATION AND IT MADE IT VERY EASY TO DEOFFUSCATE.
WE WERE ABLE TO JUST USE NORMAL COMPILER OPTIMIZATIONS TO REMOVE BASICALLY DEAD CODE.
SO CONTINUING ON, WE CALL THE TRIGGER DEPRIV BLOCK METHOD.
AND WE GIVE IT TWO ARGUMENTS, THE CLASS WE JUST LOADED AND A BASICALLY A STRING THAT'S
GIVEN BY THE HTML THAT SERVED THIS PIECE OF MALWARE UP.
WITHIN THE MALICIOUS CLASS, WE START OFF IN THE TRIGGER DEPRIV BLOCK METHOD AND WE FIRST
‑‑ WHOA ‑‑ ALL RIGHT ‑‑ SORRY ABOUT THAT ‑‑ ALL RIGHT, SO WE FIRST TAKE OUR
STRING AND WE SPLIT IT BY THE CHARACTERS H AND J.
THEN WE TURN THAT INTO ‑‑
TO ANOTHER STRING THAT WE PASS LATER ON.
WE THEN GET ACCESS TO THE GIVEN CLASS AS CONSTRUCTOR AND INSANTIATE IT AND PASS IT THE STRING
THAT WE JUST CREATED.
AT THIS POINT WE END UP IN THE CONSTRUCTOR AND THE FIRST THING WE DO IS MAKE A CALL TO
ACCESS CONTROLLER'S DUE PRIVILEGE BLOCK AND WE PASS THIS AS THE VARIABLE.
THIS HAS THE EFFECT OF ‑‑ BECAUSE WE'RE IN ‑‑ BECAUSE WE IMPLEMENT PRIVILEGE EXCEPTION
ACTION, THIS HAS THE EFFECT OF CALLING OUR RUN METHOD AND SPECIFICALLY NULLIFIES THE SECURITY
ENTER.
AT THIS POINT EVERYTHING AFTER THIS IS STAGE TWO BECAUSE THE VULNERABILITY HAS FULLY TAKEN
PLACE.
SO NOW WE MAKE ‑‑ NOW WE CALL OUR STAGE TWO METHOD.
AND THE FIRST THING WE DO IS GRAB THE URL ‑‑ CREATE A HANDLE TO THE URL THAT WE WERE GIVEN
AND THEN WE CREATE A NEW FILE ON DISC IN OUR APP DATA DIRECTORIES CALLED JAVA IOTEMPTER.
WE THEN GO THROUGH AND DOWNLOAD THE FILE AND DROP IT INTO ‑‑ DOWNLOAD THE FILE FROM
THE URL.
THEN WE TRY TO EXECUTE IT AS AN EXECUTABLE AND FAILING THAT WE WILL THEN TRY TO LOAD
IT AS A DLL.
AT THIS POINT I'M GOING TO HAND IT BACK OVER TO BRIAN SO THAT HE CAN GO OVER HOW ORACLE
HAS BEEN DEALING WITH ALL OF THIS.
ALL RIGHT.
SO WE KIND OF HAVE A UNIQUE PERSPECTIVE ON VENDORS AND HOW THEY HANDLE VULNERABILITY DISCLOSURES
BECAUSE WE HANDLE SO MANY OF THEM.
WE'VE DONE OVER 200 JUST THIS YEAR, ZERO DAYS PATCHED THROUGH THE VENDORS.
IN THE CASE OF ORACLE.
AND ON AVERAGE THEY ARE TAKING ABOUT THREE MONTHS TO TURN AROUND A ZERO DAY SUBMISSION
WHICH PUTS THEM RIGHT IN THE MIDDLE OF A PACK FOR VENDORS BUT IN REALITY WHAT'S GOING ON
WITH THEM IS THEY'VE DECREASED THEIR TURN AROUND TIME YEAR OVER YEAR WHILE THE VULNERABILITY
SUBMISSIONS HAVE GONE UP AND SO IT'S ACTUALLY QUITE A FEAT WHEN IN 2011 YOU PATCHED 50 BUGS
AND THEN IN 2013 YOU PATCHED OVER 130 AND YOU'RE ACTUALLY DECREASING YOUR TURN AROUND
TIME SO FROM AN EXTERNAL PERSPECTIVE IT ACTUALLY LOOKS LIKE THEY'RE STAFFING UP THE RESPONSE
ORGANIZATION TO HANDLE SOME OF THE VULNERABILITIES THAT ARE BEING DISCOVERED.
THEY RELEASE ‑‑ THEY'VE INCREASED THEIR PATCH CYCLE, THEY RELEASE ABOUT FOUR TIMES
A YEAR, SOMETIMES MORE WHEN ZERO DAYS ARE DISCOVERED BUT THEY'VE ACTUALLY MADE PUBLIC
COMMITMENTS TO THEIR CUSTOMERS TO ACTUALLY DECREASE THE AMOUNT OF TIME IT TAKES TO TURN
A PATCH WHEN A ZERO DAY IS DISCOVERED.
ONE OF THE THINGS THAT'S NOT REALLY REPORTED VERY OFTEN IS THAT THEY'RE AGGRESSIVELY ADJUSTING
THE ATTACK SURFACE FOR JAVA WHICH WE'LL GO OVER NEXT.
THEY'VE ACTUALLY KILLED SEVERAL OF THE CASES THAT WE PURCHASED AND KILLED IN THIS PERSPECTIVE
MEANS WE'VE PURCHASED THE VULNERABILITY, WE'VE VERIFIED THAT IT WORKS AND THEY RELEASE A
PATCH AND IT KILLS THE BUG.
AND SO IN U13 THEY KILLED THREE AND IN U15 THEY KILLED TWO.
THIS IS DUE TO INCREASED APPLICATION RESTRICTIONS AND ALSO TIGHTENING THEM UP OF THE LEAST PRIVILEGE
VIOLATION BUGS.
WHAT YOU SEE ON THE SCREEN IS ACTUALLY THE ADJUSTMENTS TO THE ATTACK SURFACE THAT THEY'VE
MADE OVER THE LAST SEVERAL RELEASES.
WE BASELINED IT IN U9 AND THEY HAD ABOUT 12 PACKAGES IN THE RESTRICTION LIST AND YOU
SEE IN U10 AND U11 THEY DIDN'T CHANGE IT AND IN U13 THEY ADDED ANOTHER DOZEN OR SO PACKAGES
TO THE PACKAGE RESTRICTION LIST AND ONE OF THOSE PACKAGES IS THE COM SUN WEB PAIN PACKAGE
THAT WE ACTUALLY WENT OVER IN THE CASE STUDIES.
THEY'RE ACTUALLY ADDING THOSE IN THERE AS BUGS ARE DISCOVERED AND TRYING TO TIGHTEN UP THE
ATTACK SURFACE.
IN U15?
YOU SEE THAT THEY ACTUALLY REMOVE PACKAGES, WHICH IS KIND OF STRANGE, BUT WHAT THEY'RE
ACTUALLY DOING IS REMOVING LOWER LEVEL PACKAGES AND ADDING HIGHER LEVEL PACKAGES.
AND SO YOU SEE THAT IT'S COM SUN JMX REMOTE.UTIL WAS REMOVED AND COM SUN JMX WAS ADDED.
SO THERE'S FURTHER TIGHTENING THE AVAILABLE PACKAGES THAT AN APPLICANT CAN GET TO.
IN U21 THEY MADE A LOT OF CHANGES.
YOU SEE THERE BUT THE SAME SORT OF THING, REMOVING LOWER LEVEL PACKAGES AND ADDING MORE
PACKAGES.
THE INTERESTING THING IS FOR EVERYBODY IN THIS AUCTION.
THOSE ARE WHERE YOU WANT TO LOOK WHEN THEY RELEASE A PATCH, IF YOU'RE DOING A ONE DAY
PATCH ANALYSIS OR EXPUT DEVELOPMENT, BECAUSE THERE'S VULNERABILITIES IN THAT CODE BASE
THAT THEY'RE TRYING TO REMOVE.
AND SO YOU CAN TAKE THIS AND THE MAPPING THAT WE PROVIDED AND YOU CAN UNDERSTAND AND REDUCE
THE AMOUNT OF WORK THAT YOU HAVE TO DO TO LOOK FOR BUGS IN THE PROGRAM, IN JAVA ITSELF,
AND YOU CAN SEE THAT THEY'RE CHANGING QUITE A BIT.
SO WHAT YOU SEE ON THE SCREEN IS THE FULL PACKAGE RESTRICTION LIST FOR JDK7 U25.
THERE'S 43 PACKAGES IN THE LIST RIGHT NOW AND THAT'S QUITE A CHANGE FROM U9 WHICH HAD
12.
AND YOU SEE A LOT OF COM, SON, ORG, APACHE PACKAGES AND SO YOU CAN EXPECT IN THE FUTURE
THAT THEY'LL PROBABLY REMOVE SOME OF THOSE AND ADD A HIGHER LEVEL PACKAGE.
SO IN CONCLUSION, YOU KNOW, ORACLE HAS WEATHERED QUITE THE STORM OVER THE LAST TWO AND A HALF
YEARS, THREE YEARS.
THEY'VE HAD A LARGE NUMBER OF VULNERABILITY DISCOVERIES AND JUST THROUGH OUR PROGRAM ALONE
WE'VE HAD 50-PLUS JAVA ZERO DAY SUBMISSIONS OVER THE LAST TWO YEARS.
THE LAST THREE QUARTERS.
ATTACKERS ARE LEVERAGING THEM MOST RECENTLY IN ATTACKS AGAINST FACEBOOK AND APPLE.
AND YOU'VE SEEN SOME OF THE LARGEST JAVA SECURITY UPDATES TO DATE.
EVERYBODY'S FOCUSING ON THE SANDBOX BYPASS WITH UNSAFE REFLECTION BEING THE MOST PROLIFIC
VULNERABILITY IN THE ARCHITECTURE, FOLLOWED BY TYPE CONFUSION BEING THE MOST POPULARLY
USED VULNERABILITY, MOST EXPLOITED VULNERABILITY.
THE 2D COMPONENT ACTUALLY PRODUCES THE MOST SEVERE VULNERABILITIES BUT IT'S JUST NOT USED.
AND SO.
WHEN THEY COME OUT WITH A 2D COMPONENT WITH A CVSS SCORE OF A 10, IT'S NOT IN REALITY
AS IMPORTANT AS THE SANDBOX BYPASS ISSUE WHICH USUALLY GARNERS LIKE AN 8.6 OR 7.6.
THEY'VE DONE SOME PROCESS IMPROVEMENTS IN ORACLE.
WE TALKED ABOUT HOW THEY ADJUSTED THE ATTACK SURFACE AND THE INCREASED PATCHING.
AND SO THEY'RE ACTUALLY WORKING TO FIX THE ISSUES THAT THEY HAVE.
WE WANT TO THANK EVERYBODY FOR SHOWING UP TODAY AND WE WANT TO THANK THE RESEARCHERS
WHO SUBMITTED ZERO DAY JAVA CASES TO US OVER THE LAST THREE YEARS.
IF YOU HAVE A JAVA ZERO DAY AND YOU'D LIKE TO SELL IT, MAKE SOME LEGAL MONEY, WE'RE THE
AVENUE TO DO THAT.
YOU CAN SUBMIT IT AT ZERODAYINITIATIVE.COM AND WE'LL PAY YOU AND HANDLE ALL THE RESPONSIBLE
DISCLOSURE FOR YOU.
WE ALSO WANT TO THANK REVERSING LABS AND SECURITY EXPLORATIONS FOR PROVIDING ADDITIONAL
INFORMATION TO HELP US VALIDATE SOME OF THE ASSUMPTIONS WE HAD EARLY ON IN THE PAPER
DEVELOPMENT.
SO THANKS FOR ATTENDING.
GOOD LUCK BUG HUNTING.
AND WE'LL BE IN THE CHILL OUT ROUND TO ANSWER SOME QUESTIONS IF YOU HAVE THEM.
THANK YOU.