7 ms·

Java Primary Cause of 91 Percent of Attacks: Cisco

66 points by vellum 13y ago

meowface 13y ago
From working incident response and malware remediation in a fairly large company, I can definitely corroborate that statistic.
craigching 13y ago
Was the article clear but I missed it? The problem is the Java browser plugin, not Java proper, right? Does anyone have any examples of Java proper not being secure? Even more bizarre, at least to me, is this quote: > Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. What?
- MaulingMonkey 13y ago
  Define "Java proper". The article focuses on Java implementations being exploited without going into root causes behind the vulnerabilities. Skimming http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java I'd say there's evidence of fundamental problems, affecting Java insomuch as they influence Java's API design: - Huge attack surface (including native code in implementations) - Insufficiently defensive API design - Opt-into security ethos ("remember to escape, verify required permissions") rather than opt-out ("remember to unfreeze, untaint, verify unrequired permissions")
  - craigching 13y ago
    > Define "Java proper". Java not running in the browser, i.e. running as a service on the target platform. Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
    - gsg 13y ago
      The problem is that Java has consistently failed to be secure enough to safely execute untrusted code, that is code coming from unknown, potentially hostile sources. For running trusted code, Java is fine.
    - MaulingMonkey 13y ago
      > Java not running in the browser, i.e. running as a service on the target platform. Thank you for clarifying - my initial interpretation was wildly off. > Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser. I'm afraid I lack the practical detail you're probably after in terms of defending or mitigating attacks against Java services. Sorry! Some of the CVEs would still seem relevant, but you'd be better off turning to them directly instead of having me poorly parrot them.
- ChrisAntaki 13y ago
  That quote does seem off. Minified & concatenated JavaScript is pretty common these days. How many sites are serving up jQuery, unminified?
  - craigching 13y ago
    Yeah, I agree with you, but what does that quote in this article have anything to do with Java security issues? Though sometimes it seems that the JavaScript malware "obfuscations" appear to be more incriminating than if they had used legitimate obfuscations, right? At least every time I look at some post on a blog about malware it seems that the malware author could have benefitted from some sort to standard obfuscation technique like grunt, etc.
- talklittle 13y ago
  Yes it sounds like it's primarily about the Java browser plugin, based on the examples in the article. > Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. Those make sense as example heuristics for detecting malware-serving sites. What part doesn't make sense? I don't know of legitimate websites that obfuscate their JS. (Minification doesn't count.) Presumably they've found malware websites in the wild that obfuscate. Redirecting users in a jarring way is something malware sites actually do. Like going to example.com and it immediately redirects you to adsfa8sdjfa9sd8jfasd.com. The security guy isn't saying redirects are categorically bad, just that it's another heuristic that raises the chance you're currently viewing a malicious site.
  - craigching 13y ago
    > What part doesn't make sense? The part where the article is about Java security vulnerabilities and instead switches to talking about JavaScript, as if they were the same thing? I get the difference and don't need the education. I was wondering what this had to do with Java. If you care to explain that, I'll be happy to hear it ;)
    - dminor 13y ago
      > At the top of the list is a need for some form of behavior detection that monitors a user's chain of events before they land on an exploit. "For example, is a user requesting a Web page that included obfuscated JavaScript, and is the user being redirected?" Gundert asked. The article is about Java exploits, and then they discuss the potential to recognize what happens before the payload is delivered. If the web page includes obfuscated JavaScript, and the user is then redirected, that could be a sign that a (probably Java) exploit is in the user's near future.
      - craigching 13y ago
        > If the web page includes obfuscated JavaScript Ok, but how do you know that "obfuscated JavaScript" is "bad"? I obfuscate all of my javascript, it's called minimization, that's now inherently bad? Maybe browsers should require approval of redirects? Or make it an option? I mean that technique could apply to any sort of browser plugin (flash, or anything, not just java), what does obfuscated JavaScript have to do with redirects or Java in particular? The article is just being dishonest. I don't disagree that the Java plugin has had issues, but JavaScript redirects have nothing to do with it. Don't get me wrong, there are tons of inherent risks to the online experience, but let's not make shit up at the same time! Which is what it seems this article does.
- jsaxton86 13y ago
  The Java browser plugin runs unsigned applets in a sandbox. Sandboxed applications can only use a subset of Java that should make it impossible to cause serious damage to the host system. However, if an attacker can break out of the sandbox, they can do whatever they want, so this is a pretty common attack vector. If you're interested, I spent some time figuring out how these attacks work and I blogged about it here: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...
  - jebblue 13y ago
    What's the difference between that and running JavaScript unfettered? If the confines of the Java Sandbox can be challenged by hackers, JavaScript's day is coming and it will be huge.
    - craigching 13y ago
      > What's the difference between that and running JavaScript unfettered? Except that the article is specifically about the Java plugin for browsers. But, that said, the fact that there have been so many Java exploits reported compared to JavaScript exploits probably says a lot about the major browser developers (Mozilla, Google, Apple, Microsoft) compared to Oracle/Sun.
    - meowface 13y ago
      The difference is that Javascript generally has no API for accessing file system and OS resources, but Java applets by default give full access to the entire Java standard library; it simply restricts certain parts of it with the sandbox. If a Java applet can find a way to access things on the blacklist, then it can download and run any file with your OS user privileges. With Javascript there isn't actually a sandbox to break out of.
      - kleiba 13y ago
        Is there an implementation of the JVM in Javascript? That should address some of the issues outlined.
- gizmo686 13y ago
  >Does anyone have any examples of Java proper not being secure? What would Java proper being insecure look like. If your code is running in a normal JVM, then you can already write arbitrary data to a file and simply exec it, trivially giving you arbitrary code execution without breaking any part of the run-time.
  - craigching 13y ago
    Yes, I understand. The point being that this article is about the Java browser plugin and security vulnerabilities surrounding that particular part of Java and being conflated to Java in the large. The article does a poor job of pointing this out and seems inflammatory.
  - justincormack 13y ago
    Well there are other uses of the Java sandbox, although not many.
  - gohrt 13y ago
    Insecure networked Java means that (hypothetically, or with that floating point parse bug of ~2011), user input could cause a program to behave in ways not intended by the author. Insecure "local" Java would be something like an equivalent of XSRF , mixing data from multiple sources in unintended ways, or leaking data from your user account/ security context to a place visible by other accounts/roles on the system.
- MichaelGG 13y ago
  There have been numerous classloader bugs and sandbox bypasses, right? Most of the time this doesn't matter since you're not sandboxing non-browser code.
- nhebb 13y ago
  > Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. What? This was addressed on reddit [1]: Since I'm the person who submitted this data for the annual security report inside of Cisco and also have the interviews surrounding this... 91% of client side compromises had to do with the java plugin to the browser. Java applets, not server side java. Sometimes JavaScript is used to obfuscate the applet, the applet load, or the entire page, the vulnerability is not in JavaScript. [1] http://www.reddit.com/r/programming/comments/1vj917/java_primary_cause_of_91_percent_of_attacks_cisco/cesybqn http://www.reddit.com/r/programming/comments/1vj917/java_pri...
- ExpiredLink 13y ago
  > The problem is the Java browser plugin, not Java proper, right? Clueless Java bashing as usual. Nobody uses Java applets any more.
  - pkolaczk 13y ago
    Oh really? Cisco Webex (Java) is IMHO still unbeaten by JS solutions like Google Hangouts[1] or JoinMe[2], despite its old-fashioned L&F. Also, what about banks in Norway? [1] Fast refresh, but poor image quality. [2] Terribly slow refresh, audio doesn't work on Linux, needs to use skype/phone.
joeevans 13y ago
Yes. And cars primary cause of 91 percent of car accidents.
rbanffy 13y ago
How many of these are OS-specific? I run OpenJDK on Linux - how much should I worry?
- justincormack 13y ago
  the Java part of the attack is usually cross platform, depends what payloads they add after that. I would not rely on it...
  - rbanffy 13y ago
    I had hopes it depended on the N part of JNI. I guess the plug-in will continue disabled on my main browser. It's particularly distressing since the only real use the plugin gets is on the banking and government sites I have to use :-( where a such major screw up is exceedingly major.
- meowface 13y ago
  The sandbox bypass vulns almost always also affect OpenJDK and IBM JVM. Your best bet is to keep the Java browser plugin disabled as much as you possibly can, no matter your OS or browser.
hrjet 13y ago
IMO, Java in its own interest should not install/enable the Java browser plugin by default after installation of a JRE. Java as a browser plugin is outdated in this decade of HTML5. Sure, it might be irreplaceable in some niches; for those users, the plugin could be made available as a separate installation. Sadly, I am not hopeful that Oracle will lead the way here. They are going the other way and installing third-party utilities (the Ask.com toolbar) while installing Java.
- yuhong 13y ago
  I think they are already going to default to only running signed applets in a a future update.
  - smoyer 13y ago
    Those changes were released in Java 7u51 just last week. But it will take a long time for everyone to upgrade (if ever). It is possible to completely disable Java in the browser, but it takes some work (often you have to find a link in the browser's installation directory).
- mweibel 13y ago
  After reading your comment I went to the control panel of java and there you can at least disable the browser plugin. But removing it entirely would be better
n3m6 13y ago
Dear lord. People still use Java in the browser?
louwrentius 13y ago
It's maybe a trivial and often-held opinion but nonetheless: client-side Java should die. Server-side, it's quite strong and capable, but client-side Java has proven itself to be a significant security threat. And as stated by 'hrjet' there is no significant reason to use Java in the browser anymore. Organisations still relying on legacy applications requiring old Java versions should really look into their priorities. For companies it may be wise to only install Java on a few terminal servers / citrix servers (closely monitored, no internet access) and keep the user desktop clean from Java.
- pjmlp 13y ago
  First step would be to keep the deskop clean from C.
trumbitta2 13y ago
Can somebody update the title with something like: "The Java browser plugin cause..."?
- rjzzleep 13y ago
  sadly the damage is already done. i remember a year ago the department of health in louisiana would choose sharepoint 2010 over anything with a java backend because they thought java was too insecure.
  - pjmlp 13y ago
    Somehow Sun is the one to blame here, by having the great idea of calling everything just Java on the Java ecosystem. If this confuse us with deep computing knowledge, what to say from the average public.
  - raverbashing 13y ago
    I fail to see what the problem is The company developing the Java browser plugin is the same that develops the Java Runtime. Problems arise from lack of validation of untrusted data, be that either coming from a webpage or a request to a server.
jgalt212 13y ago
I wonder if the NSA pays (directly or indirectly) Oracle to slow walk these Java applet vulnerability updates.
wes-exp 13y ago
But Java is "enterprise"!!!1

66 points by vellum 13y ago

From working incident response and malware remediation in a fairly large company, I can definitely corroborate that statistic.

craigching 13y ago

Was the article clear but I missed it? The problem is the Java browser plugin, not Java proper, right? Does anyone have any examples of Java proper not being secure? Even more bizarre, at least to me, is this quote: > Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. What?

MaulingMonkey 13y ago
Define "Java proper". The article focuses on Java implementations being exploited without going into root causes behind the vulnerabilities. Skimming http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Java I'd say there's evidence of fundamental problems, affecting Java insomuch as they influence Java's API design: - Huge attack surface (including native code in implementations) - Insufficiently defensive API design - Opt-into security ethos ("remember to escape, verify required permissions") rather than opt-out ("remember to unfreeze, untaint, verify unrequired permissions")
- craigching 13y ago
  > Define "Java proper". Java not running in the browser, i.e. running as a service on the target platform. Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser.
  - gsg 13y ago
    The problem is that Java has consistently failed to be secure enough to safely execute untrusted code, that is code coming from unknown, potentially hostile sources. For running trusted code, Java is fine.
  - MaulingMonkey 13y ago
    > Java not running in the browser, i.e. running as a service on the target platform. Thank you for clarifying - my initial interpretation was wildly off. > Personally I am not a proponent of running Java in a browser, but I am a proponent of the JVM as a service. So please educate me on the security issues as they relate to running Java not in a browser. I'm afraid I lack the practical detail you're probably after in terms of defending or mitigating attacks against Java services. Sorry! Some of the CVEs would still seem relevant, but you'd be better off turning to them directly instead of having me poorly parrot them.
ChrisAntaki 13y ago
That quote does seem off. Minified & concatenated JavaScript is pretty common these days. How many sites are serving up jQuery, unminified?
- craigching 13y ago
  Yeah, I agree with you, but what does that quote in this article have anything to do with Java security issues? Though sometimes it seems that the JavaScript malware "obfuscations" appear to be more incriminating than if they had used legitimate obfuscations, right? At least every time I look at some post on a blog about malware it seems that the malware author could have benefitted from some sort to standard obfuscation technique like grunt, etc.
talklittle 13y ago
Yes it sounds like it's primarily about the Java browser plugin, based on the examples in the article. > Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. Those make sense as example heuristics for detecting malware-serving sites. What part doesn't make sense? I don't know of legitimate websites that obfuscate their JS. (Minification doesn't count.) Presumably they've found malware websites in the wild that obfuscate. Redirecting users in a jarring way is something malware sites actually do. Like going to example.com and it immediately redirects you to adsfa8sdjfa9sd8jfasd.com. The security guy isn't saying redirects are categorically bad, just that it's another heuristic that raises the chance you're currently viewing a malicious site.
- craigching 13y ago
  > What part doesn't make sense? The part where the article is about Java security vulnerabilities and instead switches to talking about JavaScript, as if they were the same thing? I get the difference and don't need the education. I was wondering what this had to do with Java. If you care to explain that, I'll be happy to hear it ;)
  - dminor 13y ago
    > At the top of the list is a need for some form of behavior detection that monitors a user's chain of events before they land on an exploit. "For example, is a user requesting a Web page that included obfuscated JavaScript, and is the user being redirected?" Gundert asked. The article is about Java exploits, and then they discuss the potential to recognize what happens before the payload is delivered. If the web page includes obfuscated JavaScript, and the user is then redirected, that could be a sign that a (probably Java) exploit is in the user's near future.
    - craigching 13y ago
      > If the web page includes obfuscated JavaScript Ok, but how do you know that "obfuscated JavaScript" is "bad"? I obfuscate all of my javascript, it's called minimization, that's now inherently bad? Maybe browsers should require approval of redirects? Or make it an option? I mean that technique could apply to any sort of browser plugin (flash, or anything, not just java), what does obfuscated JavaScript have to do with redirects or Java in particular? The article is just being dishonest. I don't disagree that the Java plugin has had issues, but JavaScript redirects have nothing to do with it. Don't get me wrong, there are tons of inherent risks to the online experience, but let's not make shit up at the same time! Which is what it seems this article does.
jsaxton86 13y ago
The Java browser plugin runs unsigned applets in a sandbox. Sandboxed applications can only use a subset of Java that should make it impossible to cause serious damage to the host system. However, if an attacker can break out of the sandbox, they can do whatever they want, so this is a pretty common attack vector. If you're interested, I spent some time figuring out how these attacks work and I blogged about it here: http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-part-2/ http://jsaxton.com/fun-with-wireshark-and-ie-java-exploits-p...
- jebblue 13y ago
  What's the difference between that and running JavaScript unfettered? If the confines of the Java Sandbox can be challenged by hackers, JavaScript's day is coming and it will be huge.
  - craigching 13y ago
    > What's the difference between that and running JavaScript unfettered? Except that the article is specifically about the Java plugin for browsers. But, that said, the fact that there have been so many Java exploits reported compared to JavaScript exploits probably says a lot about the major browser developers (Mozilla, Google, Apple, Microsoft) compared to Oracle/Sun.
  - meowface 13y ago
    The difference is that Javascript generally has no API for accessing file system and OS resources, but Java applets by default give full access to the entire Java standard library; it simply restricts certain parts of it with the sandbox. If a Java applet can find a way to access things on the blacklist, then it can download and run any file with your OS user privileges. With Javascript there isn't actually a sandbox to break out of.
    - kleiba 13y ago
      Is there an implementation of the JVM in Javascript? That should address some of the issues outlined.
gizmo686 13y ago
>Does anyone have any examples of Java proper not being secure? What would Java proper being insecure look like. If your code is running in a normal JVM, then you can already write arbitrary data to a file and simply exec it, trivially giving you arbitrary code execution without breaking any part of the run-time.
- craigching 13y ago
  Yes, I understand. The point being that this article is about the Java browser plugin and security vulnerabilities surrounding that particular part of Java and being conflated to Java in the large. The article does a poor job of pointing this out and seems inflammatory.
- justincormack 13y ago
  Well there are other uses of the Java sandbox, although not many.
- gohrt 13y ago
  Insecure networked Java means that (hypothetically, or with that floating point parse bug of ~2011), user input could cause a program to behave in ways not intended by the author. Insecure "local" Java would be something like an equivalent of XSRF , mixing data from multiple sources in unintended ways, or leaking data from your user account/ security context to a place visible by other accounts/roles on the system.
MichaelGG 13y ago
There have been numerous classloader bugs and sandbox bypasses, right? Most of the time this doesn't matter since you're not sandboxing non-browser code.
nhebb 13y ago
> Most legitimate Websites will not use hidden or obfuscated JavaScript, and few will redirect users without authorization, he explained. What? This was addressed on reddit [1]: Since I'm the person who submitted this data for the annual security report inside of Cisco and also have the interviews surrounding this... 91% of client side compromises had to do with the java plugin to the browser. Java applets, not server side java. Sometimes JavaScript is used to obfuscate the applet, the applet load, or the entire page, the vulnerability is not in JavaScript. [1] http://www.reddit.com/r/programming/comments/1vj917/java_primary_cause_of_91_percent_of_attacks_cisco/cesybqn http://www.reddit.com/r/programming/comments/1vj917/java_pri...
ExpiredLink 13y ago
> The problem is the Java browser plugin, not Java proper, right? Clueless Java bashing as usual. Nobody uses Java applets any more.
- pkolaczk 13y ago
  Oh really? Cisco Webex (Java) is IMHO still unbeaten by JS solutions like Google Hangouts[1] or JoinMe[2], despite its old-fashioned L&F. Also, what about banks in Norway? [1] Fast refresh, but poor image quality. [2] Terribly slow refresh, audio doesn't work on Linux, needs to use skype/phone.

joeevans 13y ago

Yes. And cars primary cause of 91 percent of car accidents.

rbanffy 13y ago

How many of these are OS-specific? I run OpenJDK on Linux - how much should I worry?

justincormack 13y ago
the Java part of the attack is usually cross platform, depends what payloads they add after that. I would not rely on it...
- rbanffy 13y ago
  I had hopes it depended on the N part of JNI. I guess the plug-in will continue disabled on my main browser. It's particularly distressing since the only real use the plugin gets is on the banking and government sites I have to use :-( where a such major screw up is exceedingly major.
meowface 13y ago
The sandbox bypass vulns almost always also affect OpenJDK and IBM JVM. Your best bet is to keep the Java browser plugin disabled as much as you possibly can, no matter your OS or browser.

hrjet 13y ago

IMO, Java in its own interest should not install/enable the Java browser plugin by default after installation of a JRE. Java as a browser plugin is outdated in this decade of HTML5. Sure, it might be irreplaceable in some niches; for those users, the plugin could be made available as a separate installation. Sadly, I am not hopeful that Oracle will lead the way here. They are going the other way and installing third-party utilities (the Ask.com toolbar) while installing Java.

yuhong 13y ago
I think they are already going to default to only running signed applets in a a future update.
- smoyer 13y ago
  Those changes were released in Java 7u51 just last week. But it will take a long time for everyone to upgrade (if ever). It is possible to completely disable Java in the browser, but it takes some work (often you have to find a link in the browser's installation directory).
mweibel 13y ago
After reading your comment I went to the control panel of java and there you can at least disable the browser plugin. But removing it entirely would be better

n3m6 13y ago

Dear lord. People still use Java in the browser?

louwrentius 13y ago

It's maybe a trivial and often-held opinion but nonetheless: client-side Java should die. Server-side, it's quite strong and capable, but client-side Java has proven itself to be a significant security threat. And as stated by 'hrjet' there is no significant reason to use Java in the browser anymore. Organisations still relying on legacy applications requiring old Java versions should really look into their priorities. For companies it may be wise to only install Java on a few terminal servers / citrix servers (closely monitored, no internet access) and keep the user desktop clean from Java.

pjmlp 13y ago
First step would be to keep the deskop clean from C.

trumbitta2 13y ago

Can somebody update the title with something like: "The Java browser plugin cause..."?

rjzzleep 13y ago
sadly the damage is already done. i remember a year ago the department of health in louisiana would choose sharepoint 2010 over anything with a java backend because they thought java was too insecure.
- pjmlp 13y ago
  Somehow Sun is the one to blame here, by having the great idea of calling everything just Java on the Java ecosystem. If this confuse us with deep computing knowledge, what to say from the average public.
- raverbashing 13y ago
  I fail to see what the problem is The company developing the Java browser plugin is the same that develops the Java Runtime. Problems arise from lack of validation of untrusted data, be that either coming from a webpage or a request to a server.

jgalt212 13y ago

I wonder if the NSA pays (directly or indirectly) Oracle to slow walk these Java applet vulnerability updates.

wes-exp 13y ago

But Java is "enterprise"!!!1