Understanding the Ins and Outs of Java Vulnerabilities and What to do About it
March 13, 2013
Many organizations are jumping on the “Death to Java” bandwagon, ranting about turning off Java to eliminate risk. However, it is important to put the issue in the proper context. The reality is that a Java vulnerability is not the end game for a cyber criminal, it is merely a delivery mechanism in the quest to install and execute bigger malware. There is no “one size fits all” recommendation for eliminating Java risks. But, you do want to eliminate as much exploitable surface area as reasonably possible on your critical endpoints. This should be the philosophy engrained in every organization’s security culture. If you’re not having this conversation about Java - and quite frankly all of the third-party applications in your environment - you are missing the mark and not calculating your risk. Join Paul Henry and Russ Ernst as they bring us up to speed on the Java vulnerabilities and how to limit your exposure without going overboard.
Russ: Hello. Welcome, everyone and thank you for joining us on today's webinar, Understanding the Ins and Outs of Java Vulnerabilities and what to do about it. My name is Russ Ernst. I'm a group product manager here at Lumension and I'm joined today by security and forensics expert with Lumension Paul Henry. You no doubt hear a lot about the rash of Java vulnerabilities and in fact, most recently, they've averaged roughly one new zero day a day for almost a week now reducing...and reducing that exploitable surface area on your critical endpoints is definitely a conversation you need to be having within your organization. So we're gonna talk today about how to do that.
As you know, many IT departments out there are also jumping on the death to Java bandwagon and what we can do about reducing our dependence on Java in the environment. So today we're going to expand this discussion from what to do about Java to how to disabling it and moving on and why moving on may not be your best long-term strategy.
So one quick housekeeping note here for audience members. If you have questions, please submit them via the question box at the top of your screen. So keep in mind this is an interactive webcast so as your questions come in, we'll be answering them through the webcast and getting to as many of them as we can during this allotted time.
So Paul, at this time, I'll turn it over to you.
Paul: All right. Thank you very much, Russ. Great to be here today. Interesting topic we're gonna cover. Very interesting topic. Now, before we get too down...too far down the road I should say with Java, I think it's really important to get an overall perspective on malware in general, the history of malware. You know, if we go back, you know, around 25 years ago or so, one of the first recorded PC bits of malware that we had out there was Elk Cloner. Elk Cloner was kind of interesting. You know, when you talk about malware, everybody right away thinks about Microsoft. It's just interesting that the first recorded piece of PC malware out there in '82 actually was Elk Cloner and it impacted the good old Apple too if anybody remembers that. It was rather interesting. The delivery mechanism for it, of course, was a floppy disk. The end game for the bad guy was to get that malware on that floppy disk to operate on that user's PC. So again, the delivery mechanism was a floppy. The end game was to run that malware on your Apple Two PC.
As we progressed, you know, up through the years through, you know, the '86, '91 timeframe, you know, we saw a lot more floppy delivery mechanisms out there, malwares such as Brian, Jerusalem. You know, we also had the Morris Worm and we also had Michelangelo. Again, the important thing to keep in mind historically was that, you know, the delivery mechanism pretty much stayed the same, was pretty much delivered primarily by floppies and the end game was to operate that malware within your environment. As we moved into the early 90s, macros took hold. You know, we had macros in everything from Word documents to spreadsheets etc. etc. and it became the delivery mechanism but it's important to keep in mind that the end game again was to download and run malware, you know, unauthorized applications, scripts, etc. etc. within your environment.
As we moved toward the late 90s, it all became about email. Email became the delivery vehicle of choice for the bad guys. You know, it was kind of wild because everybody was putting in, you know, antispam filters, antimalware filters to try to combat the threat. It really did take off very, very problematic. Email attachments were the bane of the internet as we got into the mid to late 90s.
Beyond that, as we got into 2000 we started to see a lot of web based malware. This would be drive by type malware, scanning malware, you know, things like CodeRed, Nimda, FriendGreeting, SoBig, we had the Blaster Worm, Slammer Worm etc. So again, we transitioned from the delivery mechanism of an email attachment to actually delivering malware from visited websites and delivering malware over TCPIP across the public internet. We saw a resurgence again in malware around 2004. Again, they figured out how to bypass our filtering and again, we saw a major resurgence of mail based malware around just prior to 2004. Right after that, we saw a huge uptick in rootkits. So up through 2004, it was primarily the bad guys altering their delivery mechanism to try to outwit us in how they would get that malware on our machine. Around the '04, '05 timeframe, we saw the malware itself getting much more powerful, literally taking complete control of your box.
Then as we moved in toward '06 and '07 we saw a huge uptick in crimeware packages. They were kind of interesting. Still are in fact today. I don't know if you're aware of it or not but most of the crimeware packages out there rely on vulnerabilities that are months to in some cases year or more old. If people have simply patched their machines, crimeware, you know, packages like Mpack really wouldn't be an issue. You know, it's somewhat ironic but we're not seeing a lot of day zero malware in these crimeware packages. It's primarily vulnerabilities that we'd had patches for for quite some time.
As we moved into 2007, 2008, Sequel Injection became the rage. We also had a lot of, you know, credential theft. People would steal FTP credentials for a given server and then they would go in via the FTP server and modify the web server to deliver malware again. As we progressed, of course, toward current day, we got into APT. With APT, the delivery mechanism is all over the map. If you look at Flamer [SP] and, you know, Stuxnet and the like, it covers everything. You know, spearfishing emails, USB keys, you know, we have the hack of the Microsoft update servers with the MD5 hash collision. You know, it's just really a matter of malware historically altering the delivery mechanism in an effort to outwit our defenses.
You know, it's been a big problem for us. We have focused our defenses on the delivery mechanism, not the end game. Of course, again, the end game is to cause that malware to execute on our machines. I think that, you know, our defensive efforts have been somewhat misguided over the years in that light. Personal opinion there but I really think we've missed the mark.
Now, if we look at the growth of malware, you know, back in the 90s, unique instances of malware really began to kick off. You know, I've been in the business a long, long time. I can still remember when, you know, we were talking just in the hundreds of pieces of malware that were known on the public internet. By 1990, we had 9,044 samples. By 1994, jumped up to 28,613. '99 was 98,000. 2005, 300,000. In 2006, we had almost a million unique instances of malware. Now, the bad guys had recognized that we were primarily defending ourselves using signatures. So what do you do when you wanna defeat a signature based defense? Well, you simply alter a single byte in your malware. You create a unique instance of that malware and you're gonna blow right past most signature based defenses. We saw that really take off back in the 2007 timeframe was the most dramatic jump we've seen to date. By 2007, we had over five million unique samples of malware. Now, since 2007, malware samples have been literally doubling each and every year.
Again, the bad guys recognize that we're focused on the delivery mechanism and that we're primarily protecting ourselves using some form of a signature whether it be AV signature, IDS, IPS etc. And again, all they're doing is altering a byte or so in their code and it blows right through the signatures. Now, of course, yes, there are heuristic capabilities in some AV products and some IDS, IPS products but unfortunately, because of the performance impact they cause, most people don't use them. So again, when you're looking at malware, we've seen explosive growth in the unique instances of malware and it's primarily to try to defeat our defenses.
Now, again, we're focusing on the delivery mechanism. We're focusing on a signature for known malware and that's what really put us in a bad position that we're in today. Had we simply focused on the end game, preventing unauthorized executables from operating within the environment, we would've been years ahead of the bad guys.
So what did we learn from history? Well, we've been fighting the wrong battle, folks. Again, we're focusing on the delivery mechanism, not the end game. And again, we're paying the price for that. we simply cannot keep up with the unlimited ways malware can be delivered and obfuscated as it's delivered. Again, we've all heard about the issue with everything from USB sticks etc. etc. We have a new issue. Patch Tuesday here was just yesterday. Microsoft released a patch for a new USB issue that can potentially allow someone to access directly to RAM if they take advantage of that vulnerability. So we're gonna see yet more USB delivered malware here in the not too distant future. I've got a feeling that's gonna get rather ugly.
Now, definition of insanity. Again, you know, I've talked to this point numerous times here and it really does fit today. You know, doing the same thing over and over again and expecting a different result, that's the best definition of insanity I've ever heard. You know, if we continue down the current path, only looking at the delivery mechanism and trying to protect ourselves by identifying every known piece of malware the bad guys might throw at us, we're gonna be talking about this issue for the next 25 years. Again, it is much more effective to not focus on the delivery mechanism but to actually focus on the end game, preventing unauthorized binaries and/or scripts from executing within your environment in the first place.
Russ: And so that's so true. I mean, I've heard recently this analogy that the industry here seems to be focused on building bigger and bigger walls and the bad guys keep building bigger and bigger ladders. And so, it's...again, it's just this definition of insanity, trying to do the same thing and expecting a different result. So just a note to audience members too...and if you have any questions for us, please submit them via the question box at the top of the screen and we'll try to answer as many as we can during this time.
Paul: Cool. Yeah, it truly is an arms race that we can't win. We're outmanned. Today, with state sponsored, you know, cyber issues, we're outspent as well. I mean, some of these governments print the money, okay. And they're definitely not having the budget issues that we're having on the defensive side of it. Now, looking specifically at Java, if you go out to a site such as Secunia, a great vulnerability reporting site and you simply type in Java, you're gonna find that there are 1,342 Java-related issues that are being reported at Secunia. Don't make the mistake of assuming that that's related directly to the current issue. It covers 129 different Java related products.
If you focus your search specifically on Oracle Java, you'll find that there's roughly 159 reported issues within the Secunia database. Puts it into a little bit better perspective. And yes, any company that writes code will have issues but a secure coding effort, of course, can help reduce the number of issues. You know, Microsoft is a good example of that. Again, over time, they reduce the number of critical vulnerabilities, although they're certainly creeping up a bit today. But again, it's primarily because of a secure coding effort, good product...you know, product control, we'll say, to help reduce the number of issues associated with that code.
Now, Oracle, as well, has been a little slow to fix their problems. You know, they're not the only one out there, and Russ, I'm sure you've got some input on that in just a moment here, but back in September of 2012, Gowdiak at Security Explorations had said that he had, you know, had 29 issues reported to Oracle over the course of a year. He had also reported two to Apple. Well, at the time of the article here, you know, back in September again, 2012, he said there were still 25 issues remaining to be addressed by Oracle. So again, think about that for a moment. Here are security researchers or, you know, presenting details to vendors such as Oracle that generally always includes proof of concept code. He had submitted 29 and only a handful were ever addressed. Twenty-five issues still remained outstanding by Oracle.
Russ: Yeah. This is really just showing that, in general, now that Oracle is really the application of note today being targeted, they're finding that even though Oracle has had a quarterly security update cycle for a while now, they're really finding that that cycle's not fast enough to keep up with the number of new exploits being reported in Java. This is really strikingly similar to what we’ve heard back, you know, in May of 2009, when Adobe was that...really, that targeted application of choice. And back then, Adobe really took some public steps to improve security, what they call through three steps. Number one was code hardening, number two was incident response, process improvements, and number three was through regular security updates.
And I just heard Brad Arkin speak at RSA a few weeks ago and it was really quite insightful. What he had talked about...their time to release a patch for a known vulnerability back before they put these steps in place went from around 90 days, 90 days to patch a known vulnerability, to under 6 days in 2011 with...you know, when they talk about incident response times actually measured in hours today. That's a company that's really learned from being the target of attacks.
Paul: You know, it's good that you brought that up because that's one measure a lot of people miss. You know, I don't care who you are. If you're writing code, you're gonna have vulnerabilities. It's a simply fact of life. So looking at the number of vulnerabilities in a given product is really not a good measure of the security we'll say of the team that's writing the code. A good measure of it is really how long does it take them to correct that vulnerability. You know, that data is out there if you look at sites like Bug Track and of course Secunia, they do reveal those numbers and it's kinda frightening because there's some major vendors out there that have taken a year or longer to patch vulnerabilities that were being used in the wild. It's just amazing that they could leave us in that position as long as they had.
Now, going back to looking at Oracle, back on March 4th of 2012, Security Explorations again submitted a number of issues to Oracle. In fact, it was 60 along with proof of concept code. Now, Oracle tends to focus their efforts on patches only for exploits known to be actively being used in the wild. They're simply overwhelmed today. Consequently, we really have a significant pipeline of unpatched vulnerabilities that really should be cause for concern for everyone. And again, these were submitted March 4th of 2012 and there's quite a few of those that were submitted that still remain unpatched today.
Well, some people consider Oracle to perhaps be sloppy. I put the question mark there. It's not a statement. It truly is a question. I'll leave that up to the audience to make the decision. You know, with the recent emergency release of two patches for Java 7, Oracle inadvertently made a previously undisclosed vulnerability exploitable. You know, Java 7 was a result of over five years of development and testing. Quite a few people today are questioning whether or not enough testing was done prior to its release. You know, we've had vendors make mistakes in the...you know, missteps in the past. Everyone, of course, remembers Apple when they did the upgrade to the new operating system. If you went through the upgrade process, they had a debug switch that inadvertently was left turned on for the keychain and actually was kind of wild because all of your user credentials were actually being written out to your log files in the clear. If you were running time machine, now you had multiple copies of your log files with your user credentials in the clear. So vendors do make missteps, occasional missteps. But again, we're just seeing this as a bit of a trend with Oracle. You know, they patch one problem and introduce two more. Not a good way to go moving forward.
So again, more on this...
Russ: Sorry about that, Paul. There have been a couple of questions that have come up asking about what that site is that you...we referenced a couple of times. And I think it's the Secunia Vulnerability Database.
Paul: Yeah, secunia.org. S-E-C-U-N-I-A .org. Good vulnerability reporting site. Another good one, of course, was the old Bug Track. They were purchased by Symantec. A number of good vulnerability reporting sites out there today.
Russ: Yeah, we've also had a...we used the Lumension Endpoint Intelligence Center here, [email protected] is another good place where you can find some more information about this.
Paul: All right, good. So back onto Oracle here and the question on is Oracle sloppy. Well, within days of the release of patches for Java 7...it was actually update 11. Security researched Adam again reported two new vulnerabilities including a complete Java sandbox bypass. Now, in his own words...I read the article as quickly as it came out. He stated, "Although it locked the office door in update 7u11, Oracle left the entrance to the building open."
Very, very true statement there. You know, every vendor I've seen to date that has built a sandbox to try to shore up what you could simply call bad code has had the sandbox hacked. I really haven't seen very effective use of sandbox to date. Pretty much everyone I've seen out there with a few exceptions has been literally bypassed rendering your code dramatically insecure. Again, in my view, a better approach would be to clean up your code before you wrap yet more code around it. Adding more code, you're simply increasing the overall threat and the low buy in of itself. A couple of vendors have kinda gotten it right. If you look at VM-ware, they've dramatically reduced the code base itself from ESX has created the new product ESXI. And again, the primary thought behind that is by simply making the code base smaller, you're reducing the overall threat envelope.
Now we've gotta talk about Apple and how Apple relates to the overall Java issue. Back in September of 2012, Apple fell really dangerously out of sync with Oracle. There were three vulnerabilities that were out in the wild being used. Apple pushed a patch out to their users for one of them. If you got the popup on your iMac or your MacBook Pro, it said it was the patch for the Java issues. A lot of people thought installing that patch was gonna solve their Java problems and, you know, they installed the patch and then just went back about their business of surfing the web. Unfortunately, again, they only patched one of the three issues that were currently being used in the wild. Again, Apple really seems to have completely abandoned Java at this point. You know, it used to be that when a patch came out they would build it very quickly into their patch environment and they push that out to their users. it seems that after September of 2012 they kind of abandoned it. Now they're simply telling users to go get patches directly from Oracle and in fact, they're doing something else. It's really upset a lot of people. They're actually disabling Java in the browser without any notification whatsoever to the user base. You know, so if you're involved in some training exercises etc. etc. you fire up your browser and you try to reach out to that site to do your training and you simply can't connect. Do some digging around with Google. You'll find that you now have to go out to Oracle, download the Java patch yourself and install it on your Mac and that will reenable Java on the Mac but the Apple...again, they seem to have abandoned, you know, patching Java themselves. They're leaving it now all on the user and they're actually blacklisting Java. When a new vulnerability shows up in the wild that's actively being exploited, instead of pushing out a patch, Apple simply disables Java. They blacklist it and again, it's up to the user to try to clean up the damage from that.
We do have a blog post that gets into a lot more detail on that. We're showing it on the slide here if anybody would care to take a look.
Russ: Yeah, and really Apple famously decoupled Java from their Mac operating system with the release of 10.7 Lion. When that was released back in July of 2011...that's really kind of what kicked off this opportunity for the bad guys to start taking advantage of that lag time between when a Java vulnerability was discovered and when it was actually patched by Oracle which really left those Mac users waiting and without any of the ownership of Apple as they have in the past. So it kind of really led down this dark path that we saw famously exploited back in...like you had mentioned, Paul, back in September of 2012.
Paul: Yep, yeah. Well, it's certainly not getting any better here lately. I think the important thing for people to keep in mind again however is that Java is nothing more than a delivery vehicle for a malicious payload. Again, we are still focusing on the delivery mechanism. We should be focusing on the endgame. Let's go a little further down the road with Java here. You know, if we look at the timeline, on February 1st, we received patched from Oracle for Java that corrected roughly 50 issues. Just 18 days later, February 19th, we received patches for yet an additional 6 issues. Now, since that February 19th patch, we've had two new issues that have been reported which brings us to a total now of seven known vulnerabilities in the latest release. This is...proof of concept code has been delivered and you can expect that that's probably being used in the wild.
And then just last week we had the Pwn2Own Contest. Three more Oracle vulnerabilities were found and disclosed at Pwn2Own. So the problem seems to be getting almost worse, not better. I can understand why some people are literally insisting that they simply call Java at this point. What's important for people to keep in mind however, again, Java is simply a delivery mechanism. If everybody turned off Java tomorrow, it's not gonna solve the problem. They're simply gonna switch to an alternate delivery mechanism. Could be QuickTime, could be any number of other applications...add-ins, we'll call them, that people are running on their machines that they're unfortunately not keeping up to speed with patches on. So again, just definitely keep in mind here, folks, Java is nothing more than a delivery mechanism. We need to switch our focus from that delivery mechanism to the end game, again, preventing those malicious apps from running within our environments.
Russ: That is such a good point, Paul. And going back to that history that we talked about earlier in that it's just about where the bad guys are exploiting that main line of communication into the environment, whether it was floppy disks back in the day or email now. It's really...the bad guys are really just targeting those free and pervasive applications in the environment. We saw this three or four years ago with the targeted attacks against Adobe Reader and now we're seeing it through Java. And if we take the drastic measures of just removing Java as you mentioned, it's just...they're just gonna move on to the next one.
Paul: Yeah. We've seen it just time and time again. If you go back just a couple of years ago, it was all about Adobe. It was Flash, it was Reader, etc. You know, today, the focus is Java. Tomorrow, who knows? With this new vulnerability that was discovered regarding USB sticks, we're probably gonna see a resurgence in USB delivered malware as well. So again, the delivery mechanism is gonna change regularly. The bad guys alter the delivery mechanism because that's where our defenses are pointing, okay. And again, they're simply gonna change it. It's not gonna solve the problem. It's really just gonna move the problem.
Now, we're still seeing never-ending headlines from Java with issues. Again, you guys can read as well as I can here that...you know, we've seen it used on users' home PCs. We've seen folks like Facebook. It's absolutely slammed with it. We saw the problems other security vendors themselves had with Java. It truly is not something that's going to go away any time soon. I expect it's gonna continue for quite some time. Again, I would encourage people not to get wrapped around the wheel with killing Java. Keep in mind, Java's nothing but a, you know, a delivery mechanism.
Let me try to explain it this way. If Java is used to download a brand-new day zero piece of malware into your environment and you're relying primarily on signature-based defenses that are looking at that delivery mechanism, what's gonna happen with that piece of malware when it gets into your environment? Well, quite simply, it's gonna be allowed to execute. There's not a signature that matches it. We don't have heuristic data, we'll say, perhaps on it. It will execute.
Now, if we flip that around and we go back to, you know, what was brought about in orange book, you know, if we go back 25 years ago, and that would be to the positive security model, the whitelist model. In a whitelist model, if a binary, or for that matter, a script is delivered into your environment, regardless of how it's delivered, USB key, Java, whatever, what happens to that piece of malware? Well, it's denied by default unless you explicitly permit it to run, unless the hash MD5 or SHA-1 actually matches showing that that piece of code has not been modified, by default, that code is not allowed to operate.
You know, we're all wrapped around the wheel here on, you know, turning off Java, but it really doesn't solve the problem. What solves the problem is not allowing unauthorized code to execute in our environments and that's the end of the story on that. Again, I think that we're focusing on the wrong area. We're focusing primarily on the delivery mechanism. We're trying to block every known piece of badware out there and, you know, 70 million or the current number of samples in the database today for unique instances of malware, we can't possibly have enough computing power to check every single, you know, piece of code that crosses the wire, again, all 70 million signatures. The time is now to move away from that archaic and obsolete blacklist model and move more toward a whitelist model.
Again, a whitelist solution effectively eliminates the ability for the bad guy to achieve the end game. The end game, of course, is not the delivery of the malware. It's the execution of that malware within the environment itself.
Russ: We had a couple of questions on the line here too, Paul. So first, isn't Java that much more attractive since it is cross platform?
Paul: Well, actually, it's kind of ironic because about a month ago, I saw my first cross platform piece of Java malware. It would execute on a Windows box or on a Mac, Kind of interesting. You know, popularity of a product is what drives the bad guys to focus on that product. You know, for years, some vendors have really kinda gotten a little security by obscurity advantage out of that. You know, we've all watched Apple over the last decade claim that Apples don't get viruses, Apples are more secure than windows etc. etc. Well, the truth of the matter is nobody was writing malware for an Apple because they weren't being used. Nobody cared, okay? They were such an insignificant part of the overall marketplace...you know, bad guy's not gonna waste his time and effort creating a piece of malware that's only gonna run on 5% of the machines out there in the user base. They're gonna go for that 95%.
So yeah, I mean, Windows has been the focus for many, many years. As Windows improved its security processes and its flaw remediation capabilities, we saw a shift from Windows to all the third-party addons. That included QuickTime, Adobe, now Java, etc., because people simply aren't patching those products. Now, of course, Java's one of the most popular ones out there today. It's one of the most popular addons that we have. So of course, that is gonna be the primary focus for the bad guys. It's not necessarily the cross-platform capability of it. It's the overall popularity of it. You wanna hammer a lot of machines, write some malware that executes via Java, you're good to go. It's just much more efficient for the bad guys.
And again, if everybody turned off Java tomorrow, they're simply gonna move to the next piece of low-hanging fruit. You know, in many instances, you'll find that that's gonna be things such as QuickTime. You may see Flash back. You know, I mentioned that I think USB sticks are gonna become another, you know, vector yet again because of that patch that just came out, you know, yesterday. And again, we can't forget about Apple, by and of themselves. You know, Apple has gained a significant amount of popularity. They've caught the attention of the bad guys, okay. So I think that we're gonna see a lot more malware specific to Apple. and we can't of course forget about BYOD, mobile devices themselves. Within the last three months, I saw my first piece of malware that would be infecting an Android phone that could then transfer malware from the Android phone to the user's PC. So I think that, again...go ahead.
Russ: [inaudible 00:31:46] It's not about Java being cross platform. It's really the targeting of the free and pervasive applications that are out there. and we've seen this, you know, again, with the Adobe Readers of the day and the Flash and whatever was targeted. That's where the main users were at. It wasn't necessarily that it was cross platform. We have so many...if you think about it, so many different applications today that are cross platform. If you think about Reader as being cross platform, Java of course, cross platform, Firefox. we've even seen a lot of different vulnerabilities in Microsoft Word of Excel that were cross platform because there were shared components between the Windows version and the Mac version. So it's not necessarily that it's cross platform. It's just that they are targeting the free and pervasive and relatively unpatched type of applications.
Paul: Yep, yeah. And again, just to reiterate what I really hope people will take away from this podcast today is that Java is nothing but yet another delivery mechanism. Turning off Java is not gonna solve your problem. Again, we have to switch our defenses to looking more at preventing the end game, which again is running a malicious binary or a script within your environment and not wasting our time focusing on the delivery mechanism. Again, if everybody simply moved away from that old negative security model to the positive security model, you wouldn't care about how malware was being delivered because it couldn't execute in the first place.
So again, that to me is really one of the more important things to consider here. You know, there's a lot of security folks out there that are, you know, doing the hand waving, "Turn off Java. Kill Java. Java must die." I have to disagree completely. Java is nothing but a delivery mechanism and if you think that turning off Java is somehow gonna dramatically improve your security posture, it'll be short lived. Again, they will change vectors, they will change the delivery mechanism quickly, and you're gonna find yourself in the same position. By focusing on the delivery mechanism, you're locked in an arms race that you simply cannot win. The only way you're gonna step ahead of the bad guys and step ahead of this problem is to stop focusing only on the delivery mechanism and, you know, allocate some of those resources to focusing on the actual end game for the bad guys, and that's running those binaries and scripts that are unauthorized, not explicitly permitted, they're not validated with a hash from running in your environment in the first place.
Now, Russ, at this point, I'll go ahead and turn it over to you. You can discuss what people can do right now.
Russ: All right. Actually, there's a couple more questions that are coming in so I'll take these now.
Russ: The first one I'll take is, is the presentation available today? Yeah, we'll make this available right after the webcast today. So hold tight for those details. And the second one is what about server applications such as security and antivirus tools and UPS monitoring software, all of which seem to use Java for their management consoles? Do you have to rely on vendors to patch these or should you just try to patch them on your own?
Paul: Well, the problem there is that if they're making any modifications, if there's any customization to the code, applying the Java patch could very well break that code. You really need to have a lab environment where you can test it before you push that patch out. That's a problem across the board. We see it on all kinds of equipment out there.
As an example, not to try to change it here but if you're running VM-ware...you know, VM-ware...if you're looking at ESX was using a Red Hat shell. You couldn't deploy a Red Hat patch to the VM-ware product. You'd break it because they had customized it. Same thing here with Java. People regularly create custom code to work with Java and if you deploy the Java patch to that custom code, you will break that code. You really need to amp up the pressure on your vendors. Hopefully, they're not gonna take the path that Apple took and simply completely abandon it. They'll still be a resource for you but definitely need to push up the pressure on the vendors to get those patches rolled out quicker. There are compensating controls you can use as well and I'm sure Russ is gonna cover those as we move forward over the next couple of slides.
Russ: Yep. So one more question I wanna bring out here too is...it's a little bit different. I know we're talking a lot about Java today but a question's coming in about Flash. So how's the Flash vulnerability going to be handled by the...if Flash is run through Internet Explorer and you authorize Internet Explorer, are you still vulnerable to the exploit?
Paul: Well, if you in fact have that Flash code as being authorized, came from a site that you trusted, yes, you have your browser marked as trusted but think about what the bad guy is doing. He's using Java...excuse me. Flash and the browser as a delivery mechanism in an attempt to get some code running on your PC. So if you were still using a blacklist model, you'd be hosed. If you went with the positive security model, a whitelist model, even though the browser downloaded the malware, the malware could not execute. It's not gonna have a signature that matches. It's not going to have that, you know, explicit authorization from the administrator to run that code. You know, the worst-case scenario here, they might DOS your browser, all right. But they're not gonna be permitted to run that malicious code within your environment. So again, looking at flash, it's a delivery, you know, a delivery mechanism that's coupled to the browser. The bad guys' end game is to download a binary and then execute it.
Now, we do have more current generation malware today where they're actually...they're not writing that code on hard drives as they're downloading. They're actually inserting it directly into a running process in RAM. So a current generation...you know, a positive security model, a whitelist product doesn't only focus on code that's written to the hard drive for testing it. It'll actually...it actually has the ability to look at things such as DLLs running in RAM and if it determines that code has been injected into that DLL, it can kill the process. So again, some really cool capability in current generation, you know, positive security model, whitelisting products out there. They're not simply looking at the hard drive. They also offer that very necessary level of protection for DLL injection type malware that really is kind of the rage today. The bad guys recognize that, "Hey, if we stuff our malware directly into RAM, their disk based solutions including some whitelisting products are gonna completely miss it."
Hence, you know, higher end vendors have added in the ability to validate RAM as well. So there's been a lot of changes in that marketplace, you know, whitelisting, positive security, products in general have improved dramatically. If you haven't looked at it in a few years, I would highly encourage you to. It's not your grandfather's whitelisting product, so to say.
Russ: Yeah, absolutely. And that actually answers one of the questions that just came in too is how does it handle code that exploits Java in memory but doesn't permanently modify the Java exe. That's exactly what you were just talking about too.
Paul: Yes, exactly. And in fact, it's kind of wild. I worked a lot with Metasploit myself in my own [inaudible 00:38:58] and it's one of my favorite attack vectors is to fire up a Meterpreter and insert it into a running process. I never touch the hard drive. You know, we've bene trained from an IR perspective to do what? To pull the plug and image the hard disk. Well, if you have a DLL injection, you pull the plug. You've now lost all of your evidence that it ever occurred. It's pretty wild. You know, it's kind of a...somewhat ironic but built in function that's in Windows that helps protect you from RAM based malware. It's called Patch Tuesday. So once a month, we're rebooting our Windows boxes and it whips out any malware that might be sitting in RAM. I just thought that was somewhat ironic.
Russ: It's really funny. These reflective memory injection attacks are pretty nasty and we've seen it even a few years back where Google was targeted by the Aurora malware. In fact, in 2009. And they didn't even know about it on their systems for about six months. So yeah. That can be pretty nasty.
Paul: Oh, yeah. It's built into Metasploit today. Again, inserting a Meterpreter into a running process is [inaudible 00:39:56] kiddy level today.
Russ: Yeah, so I'll...let's move onto the slide then and what can we do right now? And there are really some basic steps that companies can do right now and we've got four steps here that really follow the general dimensions of patch best practices, what we've called the patch process wheel around discover, assess, remediate, report. And specifically, how we apply those to Java is really broken down here. Identify number one within your own organization. Is there a real business or usability need for Java in your environment? Take a look at your own line of business applications. Are they written so that they require the use of the Java plugin? Why do you really need to have Java in your environment? That's the number one question you need to ask even if you...if you're considering even ripping it out of your environment. Make sure you understand what that impact is gonna be first before you decide to do that.
Secondly, try to get an assessment of how often or how pervasive Java is currently running in your environment. You know, identify those assets that don't require the Java plugin and then if they don't, ensure that the plugin is disabled.
Number three, ensure that all the Java plugin instances are patched on an aggressive schedule. This is really critical because this is an inherent issue with how Java is patched today or how Java can be installed today is that you can have multiple instances of Java on the same endpoint and it could be even more confusing too if you use the standalone Java update tool that's only gonna update one version of that instance of Java. And so, end users have this feeling that they're fully patched because they've run this Java update tool and yet they might have an older version of 1.4 or 1.5 that's still vulnerable running on their endpoint.
So it's really important to understand exactly what's out there, you know. Do a pretty thorough assessment of what's out there. And then number four, isolate your critical systems that are business process sensitive from the production environment as much as possible. Really, this is about context of the vulnerability itself. What is that end game? What are the bad guys really trying to get at? Is it your own company related data that you're trying to protect? Is it IP, is it trade secrets, is it your...is it credit card information? What is it that you're trying to protect? Isolate those machines and protect those as much as possible.
Again, this is really all around these general best practices that we've been preaching for a long time. Get back to the more thorough defense-in-depth strategy that we've been preaching for a long time too. And all these components should be in place for all applications running in your environment, not just for Java. I understand Java is one that's targeted today but really take a thorough assessment of all those applications that are running in your environment today. And this should be part of your overall corporate IT patch process.
Paul: Yeah, it's been a problem now for a couple of decades. You know, it's kinda crazy that we get ourselves into that position but there really has to be a specific business use for anything that you're gonna allow to operate within your environments today. It's referred to as enforcing the rule of least privilege. Man, if we simply did that one step, it would dramatically change everybody's threat envelope. It really is great low hanging fruit and it's a step in many organizations to simply miss. You've got to enforce that rule of least privilege.
Russ: Yeah, I'm so glad you brought that up too because that's really...when we talk...we'll get to this in a couple of slides too. When we talk about the overall defense-in-depth strategy, right at the base of that defense-in-depth strategy are these basic configuration assessments and configuration management and patch management practices that should be in every organization. The tools are out there. The management tools are out there. The visibility is out there. IT administrators should know what configurations they're running on their end point and they should know. They should be following this principle of least privilege and that's the very most basic configuration that they should be thinking about in their environment. And it's making an assessment to say, "Is it even..." From a...is there even a business reason for my users to be running this in my environment?
So let's get back to this overall question. Would it just be easier to abandon Java? It sounds so easy to just to say, "Let's pull the plug. Let's rip it out of the environment." You know, we've even talked about this earlier, Paul, where you said Apple started to just regularly without notification just start to disable it from Mac endpoints thinking that that's gonna be the way that it solves the problem. But are you sure that you've even removed all instances of Java? As we talked about, you can have multiple instances of Java running side by side. Are you sure that you're even taking care of it when you're trying to disable it from a single console? And does that even really solve the problem? You know, do your line of business applications require Java [inaudible 00:44:47] question here a minute ago alluded to. Some of your business-critical applications use Java for their console and some of them...you may have an actual legitimate business reason for running Java. A lot of companies are building their own internally developed applications, monitoring applications off of Java. Make sure that you have a very thorough understanding of what the impact is going to be to turning off Java before you just start pulling the plug. It's all about understanding that…the impact to your own environment before you start taking any harsh action.
Paul: You know, ironically, there's a number of security products that actually require Java today. You simply cannot just turn it off.
Russ: That's true. Because you might be opening up even bigger holes. So we alluded to this, but let's just like get right down to the heart of it. What is that end game? Focus on that end game. And that...really, the best approach that we recommend and that we've been alluding to this whole time is use the layer controls that use mitigating layer controls and processes on endpoints. It's not just about a single tool. It's not just about a single silver bullet that's gonna solve all of your problems. And this is beyond just the current Java exploit of the day. This is a general security best practice. Your application control...use application control whitelisting to defend against the unknown payloads, whether it's an executable payload or in memory payload.
Enable your native memory security controls in Windows including your DEP and ASLR to limit the success of generic memory-based attacks. Deploy your advanced memory injection attack protection including your RMI and Skape/JT to interrupt advanced memory attacks. As we talked about...as you talked about, Paul, at the very beginning of this, the defense...I'm sorry. The attack method of choice today is really around APT. And in APT, what we're seeing more and more are these advanced memory injection attacks. So it's very critical to start thinking about that too beyond just the traditional whitelisting approach.
Use device control to block the USB-borne malware. Perfect timing here when we saw this come out with Patch Tuesday yesterday was a USB-based attack. And so definitely, you have to be thinking about what USB drives are coming into your environment, that port control.
Utilize strong patch management practices. Of course. I mean, this is one of those basic measures that every IT organization should be focusing on as a basic defense-in-depth, have strong patch management practices. So many of these malware delivery mechanisms exploit known vulnerabilities for which there's been a patch out for years and years. I keep thinking back to the issue that was exploited a couple of years ago through the...now, it's escaping me. But the attack on the nuclear plant. And that was...I mean, that was based off of MS08-064 patch and here it was...and here's a patch that was out for four or five years still being used to exploit in a state-sponsored way.
Make sure you blacklist your outdated plugin versions. You know, this is another thing that I thought was kind of ironic when we're starting to see this focus on the Java update is that you run the standalone Java update tool to hopefully make your system more secure. And what's included in that installer but they're trying to bundle an installer for some kind of a browser search tool, some kind of a browser tool. I thought that was so ironic that you have, you know, a company that's trying to focus on security and trying to give best practices there and what do they do? They bundle more of an attack surface into your environment.
Paul: Yeah, a few people have joked that with the vulnerability issues with Java, it's really not vulnerability issues. They're just trying to promote the use of this browser tool.
Russ: That's exactly right. You know, it's...what's gonna be next? It's gonna be those browser tools for the Ask Toolbar, right, or the Yahoo Toolbar.
Russ: Is there any business purpose to have that in your environment? And then we had on here too, adopt the concept of the least privilege for end users. We've already talked about that.
So this is the slide that we were just alluding to here. The focus on a defense-in-depth strategy and this is really something that we highlight here, as I mentioned, in that it's not just about a single silver bullet. It's really about this complete defense-in-depth. And really, at the base of that we say, "Have your patch and configuration management under control. Control that vulnerability landscape." You have to have that regular patch process in your environment to plug these vulnerabilities, plug the holes that are in your environment that are being exploited on a day-to-day basis.
Layer on top of that is your application control. Control that grey. And it's not just about white or blacklists anymore. It's really about controlling that grey in the middle and making that whitelist operational beyond just saying, "Here's a lockdown state. I don't expect it to change ever again." That's just not realistic any longer. We expect the endpoint landscape to change on a daily basis in order for us to stay operation. So it's being able to manage that grey within your application control solution.
There's hard drive and media encryption. Control that data, you know. Make sure you understand the importance of the data in your environment. How many laptops are running up there with an unencrypted hard drive where you may think that the endpoint is secure but all it takes is just taking out the hard drive and you have access to all that data.
Then device control on top of that. Control the flow. That's that port control. Make sure you understand what's that attack vector to the USB.
And then, finally, you know, AV. It's an old tool but it's still a good tool. Control that known bad just as a final mitigating step. It's not...again, it's...we are really...can get quickly behind that. What did you say the number was, Paul? Seventy million known pieces of malware that's out there today? It's hard to keep track of all that in one definition file but it's still yet another tool at our toolbox.
And so, we really like to preach that successful risk mitigation starts with that solid vulnerability management foundation augmented by these additional layered defenses.
So that takes us to the end of the main webinar here. Before we get into any more of the questions that have come in, let me take this opportunity to make our viewers aware of some free resources and tools that Lumension makes available. So we have a free application scanner and you can use this tool...like we had talked about in the mitigating steps up above, you can use this tool to see how pervasive Java is in your environment today. You can also see what versions of Java are running in your environment. You can also see what other third-party applications are installed in your [inaudible 00:52:10]
So this is a free scanner you can install today and run just to give you an overall view of the threat landscape in your environment through these pervasive third-party applications. You can also see then how many of those Yahoo toolbars or Ask toolbars are installed.
Next, we have a free vulnerability scanner as well. This is another free tool that we offer to scan and identify those latent Java vulnerabilities in your network. What systems are unpatched in your environment? What are the actually...the unpatched vulnerabilities that are out there on your network today, whether they're Java based or non-Java based. This is a free scanner that we make available to let you know what are all those holes that need to be patched out there today.
And we really do emphasize a complete defense-in-depth approach as we've talked about to endpoint security. Protecting your organization from third party application risks and known executables and you can start a 30-day virtual trial of this as well. There's some links there too and...to start that.
So with that, I'm wanted to take a look at some other questions that have come in. Does Lumension have an automation tool for removing outdated versions of Java since patches still apply to all installed instances on the machine? That's a great question. Through the patch remediation solution, we have today, we do have content that's specifically targets, you know, removing Java in the environment. So yep. That is a great question because there are so many legacy installed versions of all older applications that are out there whether it be Java or Firefox. Think of how many old Firefox 3.0 versions are running out there or we heard too where companies will say, "Yeah, I know I'm running a vulnerable version of Adobe, for example, Acrobat. I know I'm running Acrobat 7.0 in my environment that hasn't been patched in years but we just don't have the budget right now to upgrade to the latest version and I still need to be able to generate .pdfs." So that's a big issue in the environments out there today.
Are there any known attacks against tablets by Apple or the Microsoft surface? Are tablets a more secure endpoint to be used? You wanna handle that one, Paul?
Paul: Yeah, sure. You know, again, it kinda depends on the tablet. If you look at Apple, Apple themselves, they literally whitelist every application that can run on their tablet. A lot of people have pushed back hard on that. They don't wanna be told what they can run on their tablet etc. etc. I've gotta tell you I use one myself. I feel quite comfortable using it because I know that the code has been inspected etc. Now, if you contrast that to let's say an Android tablet, Android has their own marketplace. Today, they have a product they refer to as the Google Bouncer that will inspect new applications that are uploaded into the Android or Google marketplace. The problem is that when the vendor creates a patch or an update for their software, it completely bypasses the Google marketplace. No inspection is done on the updates. What I've seen people doing here for the last couple of years actually...the original code that they write for that Android product is clean. It doesn't do anything bad. When they push up that patch that gives you those new features for the product, that's when the bad things start to happen.
So again, on the Apple side of things, people tend to frown on it but Apple does whitelist everything. You're not gonna run something on that Apple box or I should say that Apple tablet unless Apple has tested it and validated that in fact it's not gonna cause any harm. We have the opposite issue then on the Android where they're not whitelisting it. People tend to gravitate to that because again, nobody wants to be told what they can run but again, you're taking some inherent risk with that.
Now, speaking about the new product from Microsoft, the Surface. You know, the RT does have a smaller we'll say operating system associated with it, smaller code base but it still has had its issues and even the newest one, the Surface Pro. I just picked one up myself. It as well has had some issues. In fact, we just had a patch for the latest and greatest browser from Microsoft that actually did in fact impact even the Surface Pro.
So from that perspective, yeah. I believe that there is a security damage in the fact that Apple does the whitelist approach on their tablets more so than they actually do on their PCs themselves, the iMac etc. etc. Behind that, of course, we have that whole issue today with Android and the fact that the Google Bouncer doesn't check the updates so there are some serious risks there. Now, as well, you know, if you're gonna root your Apple device, you're kinda on your own. It's somewhat ironic but the only worm that's ever targeted an iPad targeted rooted iPads. They were jailbroken and the people that jailbroke it never changed the default SSH credentials. And the worm simply scanned looking for that SSH port, used the default credentials and they owned your box. Well, if that happened to you, that's your own fault for having rooted it in the first place. You bypassed the whitelisting capability of the product. I hope that answered it well enough.
Russ: Yeah, no. I would just add to that I agree that...it's funny...we...as Apple users, they talk about how great the App Store is. Well, the App Store is one giant whitelist for Apple products, right. And so there...depending on the vendor, you've got different coverage controls for vulnerability management and Apple really had taken this whitelist approach. Microsoft already has their built-in update cycle that targets their RTA end machines and for Google, I think it's very...that is probably the biggest attack surface today especially since you have so many vendors out there, so many hardware vendors that are creating their own versions of the Android operating system and have to run their own patch cycles on their own customized version of Android. And so that the [inaudible 00:58:24]
Paul: Yeah, carriers are the ones that are...sorry for the interruption there but people need to clearly understand that if you bought an Android phone and you need a patch, you don't go out to Google we'll say to download it from the marketplace. You're gonna have to wait for that patch to get pushed out by your carrier. A lot of people tend to miss that.
Russ: Yep, exactly, exactly. There's one other question here. You mentioned a few slides ago about DLL attacks on memory. I wonder how Lumension Endpoint Management Security Suite handles and protects against the DLL attack vector. We actually have an RMI protection built into our application whitelisting solution. So that's our reflective memory injection protection. That's a very advanced application control setting that's not available on many application control products.
Another comment here. Scary good info. Thank you for that. Definitely can be scary but again, I think with a lot of the patch best practices that are out there and this overall defense-in-depth solution that's out there...it's taking these steps. It doesn't matter if you're...if the bad guys are targeting Java or just the next application. It's taking these steps that's gonna lead you to a much safer environment.
So we've answered a lot of these questions. I really appreciate this constant feedback and any answers we don't get to today during this webcast, we'll address after the vent as well through email. So running out of time now. I'd like to thank you, Paul, for your participation in today's event. Please remember there will be a recording of this webcast that will also be available on line through the Lumension website very shortly at www.lumension.com. For more information on Lumension or any of Lumension solutions, you can contact us by going to...let me forward to the next slide that has all this contact information. You can go to www.lumension.com. That's L-U-M-E-N-S-I-O-N. You can visit our blog at blog.lumension.com or give us a call, 888-725-7828. Or email us at [email protected] Thanks for attending today. This now concludes our webcast.