First Java Zero-Day Attack in Two Years Targets NATO and US Defense Organizations

http://blog.trendmicro.com/pawn-storm-first-java-zero-day-attack-in-two-years-targets-nato-us-defense-organizations/

by wglb • 11 years ago

205 105 11 years ago

blog.trendmicro.com

JustSomeNobody2• 11 years ago

So, this is the Java plugin for browsers, right?

Why is there never a clear distinction?

smackfu2• 11 years ago

What would a security exploit in Java outside the browser look like?

dikaiosune• 11 years ago

Buffer overflow to a network socket opened by the JVM? Or a similar attack executed against the standard library's file IO?

lmm2• 11 years ago

http://download.oracle.com/sunalerts/1020226.1.html

tomjen3• 11 years ago

Buffer overflow in the jpg, png or bmp decoder libraries?

stonemetal• 11 years ago

There is a lot of enterprise, server side Java running around. It wouldn't surprise me if there were a vulnerability that could be used to attack it.

JustSomeNobody2• 11 years ago

Likely something in I/O. Obviously this would probably be much more difficult to exploit, but the potential is there.

bcg12• 11 years ago

Just one example...

Any Java application can run a SecurityManager:

http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityM...

For instance, Java application servers often have the capability to implement policies per application - so you can run the app server as a privileged user but do things like restrict access to parts of the file system, opening network sockets, using JNI, etc. Essentially this is the same mechanism that applets use to sandbox code. So any exploit that could circumvent this could have an effect outside of the browser, in theory.

bdamm• 11 years ago

I can think of a few:

* Bug in the default XML parsing library that exposes local files, existence of local files, or even allows a user-supplied XML to open a socket to a remote server? * Vulnerability in SecurityManager that allows a sandboxed jar more privileges than it is supposed to have? * Allowing a default RMI-JMX configuration to provide an attack vector to authenticated clients whereby they can upload arbitrary code that executes outside of a SecurityManager?

jph• 11 years ago

Reporting says this is for Java in the browser, on Windows, and the target must visit a malicious URL.

"[Emails] contained links to malicious domains hosting the Java exploit (JAVA_DLOADR.EFD). The exploit is designed to deliver a Trojan dropper (TROJ_DROPPR.CXC) that drops a payload detected as SPY_FAKEMS.C to the “login user” folder."

"The security firm noted that the vulnerability affects the latest version of Java, 1.8.0.45, but older versions such as 1.6 and 1.7 are not impacted."

"Disabling Java in your preferred browser is for now is a better option. Use a secondary browser with Java enabled to view sites you absolutely must visit and which require it."

"The attack leverages a three-year-old vulnerability in Microsoft Windows Common Controls CVE-2012-015."

https://www.securityweek.com/java-zero-day-used-attacks-nato...

chinathrow• 11 years ago

"Use a secondary browser within a throwaway VM with Java enabled to view sites. Also, do complain loudly to the org running that website."

Fixed that for them.

kawsper• 11 years ago

The danish government used a Java-applet to confirm your identity up until October 2014, where it was replaced with a Javascript version.

Even though it is now replaced, the install-base is still huge because people don't delete the plugins :(

mwill• 11 years ago

complain loudly to the org running that website

I lodge my sales tax via a java applet, recently I straight up could not get the applet to run on any of my machines after they went down for an update.

I called them up, and their answer was basically: "We can send you a paper form to submit but it will take x days to do that, you will be charged late fees and interest for not lodging on time"

gioele• 11 years ago

"Disabling Java in your preferred browser is for now is a better option. Use a secondary browser with Java enabled to view sites you absolutely must visit and which require it."

Do news sites say things like "Not using Safari is for now a better options" whenever somebody reports an exploitable security flaw in Safari or WebKit?

smt88• 11 years ago

Neither statement is unreasonable.

In this case, it's an easier statement to make, though, because Java is totally unnecessary for the vast majority of users. I've had it disabled for many years.

beagle3• 11 years ago

That was a common recommendation about IE back in the day.

gesman• 11 years ago

> The attack leverages a three-year-old vulnerability in Microsoft Windows Common Controls CVE-2012-015

MSFT provided a patch long time ago for this. Wouldn't it imply that applying MSFT's patch is enough?

sigzero• 11 years ago

Oh no, we must disable Java.

skruvmejsel• 11 years ago

Someone should update this page:

http://java-0day.com/

poooogles• 11 years ago

I literally just went there to check if it'd updated!

StevePerkins3• 11 years ago

I wish to God that Oracle would simply deprecate and discontinue browser-side Java applet support.

Whenever people see a headline like "Java Vulnerability Found!", it is virtually always referring to the client-side applet plugin. Yet 99% of readers don't understand that, and think that Java is insecure in general.

Whenever people see snark about Java installing the "Ask.com Toolbar", it is referring to the client-side JRE installer (i.e. applet plugin). That's virtually irrelevant to developers, because we install the full SDK which contains no crapware and never has. Yet 99% of readers don't understand that, and think that being a Java developer means dodging malware with every upgrade.

Java applets are basically the non-Microsoft business world's answer to ActiveX. A dead 1990's technology that no one has cared about in 15 years or more, which only still exists to support backwards-compatibility for some horrible crusty shops still running on XP or even NT/2000. No contemporary Java developer gives a fuck about applets, and by "contemporary" I mean "any greenfield development done since 9/11". However, we're all sick to death of having to defend our ecosystem against constant FUD, due to this horrible piece of obsolete legacy cruft.

Just kill it. Seriously.

1ris4• 11 years ago

I need java support in the Browser. Have you ever tried to use it? You have to do no less then 10 clicks with lots of warnings and restart the browser in order to activate it, and that's only for one site. And you have to repeat that for every website that uses java-applets.

It's a way easier to download a binary and execute that.

It's dead for the end-user for every meaningful definition of "dead".

Also ActiveX was the MS answer to Java, not the other way round.

philbarr3• 11 years ago

It's dead for the end-user for every meaningful definition of "dead".

Unfortunately not, there are MANY institutions that still rely on Java Applets.

yuhong• 11 years ago

Yea, this is exactly because of the security problems.

pjmlp• 11 years ago

Also ActiveX was the MS answer to Java, not the other way round.

Except ActiveX goes back to Windows 3.1 and OLE 2.0.

xbryanx• 11 years ago

One of those crufty little shops is ADP, one of the biggest payroll processors around. I hate that I have to use their applet crapstack, but it's not so simple to just turn it off.

StevePerkins3• 11 years ago

Very true, but Step #1 is to declare it deprecated.

Look, Microsoft is still struggling to retire Windows XP, a 14-year old operating system that was end-of-life'd over six years ago. However, at least they've been TRYING... and sending clear signals that support won't extend indefinitely.

Oracle, however, hasn't even begun the official process of winding down applet support. So why should ADP, or any other "captive-audience", "bare-minimum" crapshop even consider putting migration plans on their long-term timeline?

Just say it's deprecated. You don't even have to commit to a fixed end-of-life date yet. Just start the ball rolling with a signal that remaining on applets into the 2030's won't be a viable long-term vision. It might well take a decade or more to fully wind it down, but the first step is simply signaling your intention to eventually do so.

At this point, it's hard to argue that benefit of perpetual applet support isn't outweighed by the harm that it inflicts on public mindshare for the rest of your platform. At least start signalling that this cruft is going away eventually, to change the narrative about Java overall being cruft in general.

MichaelGG• 11 years ago

You can't. Plenty of expensive software runs a Java UI, browser hosted. Though, they often need older JVM versions as they don't run with the latest update.

I don't think Java is enabled by default in any install, is it? So what's the risk?

giancarlostoro• 11 years ago

It usually is, at least that's been my experience on Windows. I have to usually disable it myself after installing the JRE, because I know where that game is going (usually ends up being disabled by Firefox automatically eventually).

mcdougle2• 11 years ago

My company just transitioned to a Java applet-based time clocking/PTO/etc. management application.

The first time I opened it and it brought up the little Java prompt, I was like, "Really?"

malkia• 11 years ago

I hope it's not kronos. That one always started with the bereavement days shown.

kyllo• 11 years ago

I wish to God that Oracle would simply deprecate and discontinue browser-side Java applet support.

Oracle's flagship ERP product is Applet-based, so I doubt that's going to happen anytime soon.

JupiterMoon• 11 years ago

In some countries banks seemingly used to have to use Java for online banking (may not be the case anymore).

fernandotakai• 11 years ago

my bank in brazil still uses a java applet for "security measures". i complained about a thousand times but they still think it's more secure to use a java applet than using nothing.

Istof• 11 years ago

Plain java software can also have exploits made for them but they are not as widespread so it is not as common or not worth the trouble

rm_-rf_slash• 11 years ago

Ugh, how I envy your reason. Unfortunately, I work in higher education, where things move at an agonizing pace. As such, I end up having to use a lot of Java applets just for the sake of compatibility with the framework the college has been using for over a decade (Adobe ColdFusion). So, as much as I'd love to kill Java applets, I still rely on them. Sadly, this is a case where culture will have to change before tech will get its chance.

pkolaczk• 11 years ago

Killing it might be hard as long as companies like Cisco base their products on it. We tried a dozen of teleconferencing programs and none was able to beat Cisco Webex Java applet. Ugly? Maybe. Slow to start up? Indeed. But just works on anything (Windows/Max/Linux/Android etc.) and doesn't spin up the fans in my laptop to 100% like Google Hangout does.

krzyk• 11 years ago

Nope, Webex it doesn't work on: * Android (tested 4.4.4, app opens chrome on a page that asks to install the same app, when opening with firefox it says that it is not supported) - why app would open a browser is beyond me * Linux 64bit - screen shared by others is not visible

colechristensen• 11 years ago

A _lot_ of really shitty "web interfaces" which are actively supported/created/updated for enterprise products use java applets. They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).

Lots of companies and lots of developers give lots of fucks about Java web UIs. Because Java programmers are commodity programmers. Everyone knows the language and inexperienced programmers can be productive in it without any great risks. (Not to say that there should be any strong association between knowledge and usage of JVM tech and competence, it's just anything that reaches that depth of adoption is bound to have lots of ... mediocrity)

jebblue3• 11 years ago

> They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).

Including web or just client side? If the same UI's that you consider terrible on the JVM were ported to say, well pick any language/platform and ported exactly but using your preferred language and platform features; would the interfaces now be better since they are implemented on your desired language/platform?

bcg12• 11 years ago

You're probably right... at the very least, they should re-brand the applet container because it does create massive amounts of FUD.

As others have noted this is really a Windows issue, not an inherent flaw in Java. And as you note it seems to be a problem in the applet plugin, not necessarily the standalone J2SE runtime. It should be possible/obvious/necessary to install the two separately on Windows.

With the advent of things like NaCl, Emscripten, and WebAssembly these things should not be necessary anymore. Undoubtedly these new technologies will be able to properly sandbox untrusted obfuscated compiled code perfectly and should immediately supplant things like applets.

boobsbr2• 11 years ago

One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive.

After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop).

The most important requirement is to use the DB file installed in the user's hard drive (always same directory, no way to change it): can't generate new ones because the gov't program stores some cryptic arcane data in it, and even though we could reverse engineer it, we wouldn't be legally covered if we sent the wrong cryptic data.

Second requirement is: users are ignorant, don't know how to save files and how to navigate directory trees, 'computers = magic' to them.

How would you address this situation?

tokenizerrr• 11 years ago

Have them download and run a desktop program. You could even write it in Java and also bundle a jre within an exe for actually better overall experience for windows users.

The Web only goes so far.

logicallee2• 11 years ago

One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive...After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop)....
How would you address this situation?

Well, first I would sign up for a github account. You know steps two and three.

z3t4• 11 years ago

It's absurd that the official Java runtime for Windows comes with crapware and spyware ... Ohh, your program requires me to install Java? Then I think I'll pass. Just include the runtime (around 140mb) and your customers won't know or care that they are using Java!

jebblue3• 11 years ago

Cookies are the hidden spyware far worse then ticking a checkbox that asks if you want to install something.

bsder• 11 years ago

some horrible crusty shops still running on XP

Um, some shops still running on XP have a good reason to do so--generally some piece of hardware that the vendor never found worth the time to update the device driver.

The fact that Vista and later broke device driver compatibility with XP is THE single thing preventing those of us who would like to upgrade to a newer OS from doing so.

Microsoft thought that breaking compatibility with things like Visual Basic 6 and XP device drivers would force people to upgrade. Instead, it caused people to put a stake into the ground and never upgrade ever again.

terminado• 11 years ago

There's a typo in the CVE number. It's: CVE-2012-0158

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0...

...and how is this not a Windows vulnerability, and instead Java?

Someone12342• 11 years ago

My guess would be that Java continues to run an unpatched copy of MSCOMCTL.OCX. If you look at the CVE-2012-0158 patches[0] you'll notice that Microsoft had to patch a lot of software individually, I guess Java just was never fixed.

So it is a Java issue only in the sense that Oracle needs to update it. Obviously the original "bad code" was from Microsoft.

[0] https://technet.microsoft.com/en-us/library/security/ms12-02... [1] https://community.emc.com/community/connect/rsaxchange/netwi...

ackalker2• 11 years ago

Isn't the "Malicious Software Removal Tool" from Microsoft supposed to scan for such things? Obviously it isn't a full-fledged virus scanner, but I would expect scanning the system for outdated DLLs and such to be well within its reach.

dboreham• 11 years ago

This story is odd. Perhaps it is pure click-bait? Why would an attack that depends on a vulnerability Microsoft fixed three years ago be successful or even attempted today?? And...if someone were running a machine without this MS patch, and presumably also without a browser that makes you perform handstands while singing "There's no business like show business" before it will run Java, then wouldn't they also be vulnerable to hundreds of other issues fixed in the past few years??

crisnoble• 11 years ago

then wouldn't they also be vulnerable to hundreds of other issues fixed in the past few years?

That is a scary thought. I guess this is what happens when you cling to using XP and IE8 after Microsoft has ended support.

based2• 11 years ago

http://www.reddit.com/r/netsec/comments/3d4cd4/ssd_advisory_...

http://www.oracle.com/technetwork/topics/security/cpujul2015...

http://www.oracle.com/technetwork/topics/security/alerts-086...

https://news.ycombinator.com/item?id=9877218

https://news.ycombinator.com/item?id=9877941

bmir-alum-0074• 11 years ago

JVM & CLR runtimes probably account for 75% of all enterprise backend apps running on server gear in production right now. Both have been beaten on for so long that they're both fairly reliable, which is not to say either bug free (reliable or secure), resource efficient or maximally productive, just more usable in production on average.

On the client side (browser-land), JavaScript (and HTML & CSS) is ubiquitous. The issue of course is that every browser is "especially" different. So it makes no sense to deploy browser extensions unless things need to talk to other local apps. It makes more sense to develop hybrid native apps which are mostly html5 using something like QtWebKit and add your own per-platform goop rather than try to use something like node-webkit, phonegap (cordova) or appcelerator, because, inevitably, system-specific code will be needed, and not having direct access to APIs because of limited proxy/thunk/trampoline code doesn't make for happy developers. Java tried to do the hybrid way using JNI, which could load dll's, dylib's and so's dynamically (I wrote a custom, cross-platform (Linux, Windows), CD-ROM-based app installer using Java + JNI in 1995 by the way, it was trivial.. And then I wrote a Java source to MIPS binary, direct, non-JIT compiler in C++ in 1999.).

iso8859-13• 11 years ago

Is your installer open-source? I'd like to read it.

bmir-alum-0074• 11 years ago

It was written clean-room in some client's office (no NDA, but still, engineering ethics), but I may have a copy somewhere on a backup in offline IRL storage, but it was written for JDK 1.2-1.4 IIRC so it won't run and it's chocked full of confidential / proprietary apps (which it installs). It called a few C Win32 APIs to create icons and write registry entries, on Linux I think it just wrote files and maybe ran `ldconfig`. It was super dumb, fugly but it shipped and worked consistently. There was even Swing (pre-AWT) skinnable branding background images. It was probably 450 lines of Java and 80 lines of C. Autoplay even worked decently on Windows and it came up in under 8 seconds because I optimized the ISO image for file load order to minimize seeks, and that's booting an entire 1.4 JRE from a 4x CD-ROM drive to a usable, interactive state.

bitwize• 11 years ago

Thanks, Hacking Team!

jebblue3• 11 years ago

Outside of security, an HTML5/CSS3/JaaScript site still can't do what a Java Applet could do 2 decades ago.

First Java Zero-Day Attack in Two Years Targets NATO and US Defense Organizations

Related Stories