cancel
Showing results for 
Search instead for 
Did you mean: 
Regis
Level 12

Blocking internet Java ?

Given that there's a public exploit now avaialble for an unpatched Java issue.... curious how folks are responding and/or whether there's an easy way to tackle this in policy of the MWG.   What's the best way to cover this, using the safe assumption that exploits for this exist that'll bypass AV, and the best approach is to block all Java filetypes coming from the internet?

Refs on the issue:

http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html

https://community.rapid7.com/community/metasploit/blog/2012/08/27/lets-start-the-week-with-a-new-jav...

0 Kudos
13 Replies
McAfee Employee

Re: Blocking internet Java ?

Hi Regis,

There is a number of ways you can approach this.

You could build a rule to say:

Criteria: URL.Destination.IP is NOT in list <Internal Ranges> AND

MediaTypes.EnsuredTypes is in list <Java file types>

Action: Block

On top of that you could add in something about the user agent (the version has to be a certain version).

Criteria: URL.Destination.IP is NOT in list <Internal Ranges> AND

Header.Request.Get("User-Agent") does not equal "java 1.7.01 aka fixed version" AND

MediaTypes.EnsuredTypes is in list <Java file types>

Is this what you are looking for?

Best,

Jon

Regis
Level 12

Re: Blocking internet Java ?

That looks pretty close with some blanks filled in of course.   I need to review as i'm not sure what all the possible java media types might be...

Anyone else done this exercise?   

On a remediation front... Anyone aware of any unpatched security issues in teh latest Java 6?    

0 Kudos
McAfee Employee

Re: Blocking internet Java ?

You can see what all of the java related media types are by typing into the filter, see example below:

java.png

I havent read much further into the exploits yet, but based on the article you provided it only mentioned Java 7.

Best,

Jon

Regis
Level 12

Re: Blocking internet Java ?

Awesome.  One of those lovely moments that underscores just how great MWG's GUI is versus anything else I've seen in this space.  

asabban
Level 17

Re: Blocking internet Java ?

Hello,

blocking Java content is probably the most secure thing you can do, so I like this approach :-) If you need a more relaxed approach you could collect the user-agent strings used by Java to connect to the Internet. It usually contains the version number, so you can maintain the latest version numbers of Java (e.g. those versions you trust) in a string list like "Trusted Java Versions". Then you could say something like:

Rule Set Criteria: MediaTypes.EnsuredTypes is in list <Java file types>

First rule to allow Java objects which may be secure to open:

If

Header.Request.Get(User-Agent) is in list "Trusted Java Versions"

and

URL.IsMinimalRisk equals "true"

Then

Stop Rule Set (e.g. "Allow")

Second rule to block all others:

Always -> Block

So you will allow users to open Java objects if their Java Version is recent and the URL is not known as dangeous. Otherwise access to the Java Object will be denied. Of course you can combine it with a list of internal servers that you will always allow.

Best,

Andre

Regis
Level 12

Re: Blocking internet Java ?

asabban wrote:

Hello,

blocking Java content is probably the most secure thing you can do, so I like this approach :-) If you need a more relaxed approach you could collect the user-agent strings used by Java to connect to the Internet. It usually contains the version number, so you can maintain the latest version numbers of Java (e.g. those versions you trust) in a string list like "Trusted Java Versions". Then you could say something like:

Rule Set Criteria: MediaTypes.EnsuredTypes is in list <Java file types>

First rule to allow Java objects which may be secure to open:

If

Header.Request.Get(User-Agent) is in list "Trusted Java Versions"

and

URL.IsMinimalRisk equals "true"

Then

Stop Rule Set (e.g. "Allow")

Second rule to block all others:

Always -> Block

So you will allow users to open Java objects if their Java Version is recent and the URL is not known as dangeous. Otherwise access to the Java Object will be denied. Of course you can combine it with a list of internal servers that you will always allow.

Best,

Andre

Andre, I was intrigued with your suggestion.   Turns out there's an interesting problem with it. In my research implementing something like this,  I learned that Firefox Java plugin will send a java user agent string.

Bad news:  IE... doesn't. 

Have you observed anything different?

As such, if you have IE in the environment, I haven't seen a way to tell on the wire what Java version is in use.     I could envision some fanciness involving a remotely managed list of IP's  populated by automation from a corporate vulnerability scanning solution to help manage that, but doing it in real time on the wire appears to be a non starter for other than Firefox / Java.

0 Kudos
McAfee Employee

Re: Blocking internet Java ?

Hi Regis,

I have seen Java launched by IE, use Java's own user agent (this is contradicting your findings). I was looking at a capture just yesterday which had this behavior, it was on Windows 7 with IE9 (from what I remember). In this user agent it included the java version and what not. Are you sure you were not looking at the initial requests for the java related files? How were you attempting to find the user-agent (with wireshark or in the logs)?

If using wireshark you can use the following filter:

http.user_agent contains "java"

Theoretically if you did have the java user-agent logged, you could get a trend of what the business needs are (assuming my observations held true). This could even be done with the Web Reporter usage summary reports, this would give you an idea of the URLs that people use to access java related applications.

Best,

Jon

0 Kudos
eelsasser
Level 15

Re: Blocking internet Java ?

One thing to note is that when you launch a Java app, it doesn't necessarily have to always download a .class or .jar file. If the code is already stored in cache from a previous download, it may already be resident on the machine and not download again. The media type filters would have no effect because the actual applet does not get downloaded.

I was helping another person block all java applets from download and it would not block because it didn't actually download. It just launched from cache.

I also see the "Java/version" user agent on the request to download the .jar. When an applet is actually launching though the web browser, it transitions control to the java loader, and that is waht invokes the download an execution.

hmmm, So now that I think about it, a GET /applet.jar that is coming from the browser could be an indication of something other than the the native loader downloading it. Wonder what that would mean from a security perspective?

As an experiment last year, I made make a simple little .class that only returns the java.version, java.vendor, os.name, and os.version and place that on a special block page that a user could go to (like a daily welcome page).

It would load, and some Ajax would make postback to the MWG to post the version to another (unseen) page.

If the postback had a version in it that you didn't like, MWG could send an email to an admin.

I also had it do version checks for Flash, Acrobat, RealPlayer, WMP, and whatever i could find that would be useful.

I have long since lost the code, but i did get it to work (in IE only).

Wish i had a screenshot or something. sigh.

umm, the point was, you could do something like that to be deterministic to what version is running on the machine instead of looking at potentially forged user agent strings...if you want to go through the trouble.

Regis
Level 12

Re: Blocking internet Java ?

eelsasser wrote:

One thing to note is that when you launch a Java app, it doesn't necessarily have to always download a .class or .jar file. If the code is already stored in cache from a previous download, it may already be resident on the machine and not download again. The media type filters would have no effect because the actual applet does not get downloaded.


Ah ha!   Andre--thanks for sharing this experience.  This is why I came to my earlier wrong conclusion about IE... because I wasn't seeing the JRE downloading the elements of the java tester since I'd had it in cache.  I just confirmed it with some retesting in IE and Chrome.    

http://www.java.com/en/download/testjava.jsp   was the page I'm using.

Retests today, though did show me that yes, IE too does give usable info to filter on Java versions.  partial Access.log entries for that site included:

1) in IE9 win7--the entries with Java user agents: 

...  200 "GET http://www.java.com/applet/TestJava/TestVM2.jar HTTP/1.1" "Business, Software/Hardware" "Minimal Risk" "application/java-archive" 111829 "Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_35" "" "0" ""

... 200 "GET http://www.java.com/applet/TestJava/lib/LatestJavaVersionXMLParser.jar HTTP/1.1" "Business, Software/Hardware" "Minimal Risk" "application/java-archive" 12433 "Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_35" "" "0" ""

... 200 "GET http://www.java.com/applet/javaLatestVersion.xml HTTP/1.1" "Business, Software/Hardware" "M nimal Risk" "text/xml" 1161 "Mozilla/4.0 (Windows 7 6.1) Java/1.6.0_35" "" "0" ""

2) I next hit the same URL in Chrome,  which gave similar access.log entries except with a 304 ( Not Modified ) return code.    

3) I then went back to IE and reloaded the tester page and  I didn't see any calls to grab those jars or xml files at all.  This is 100%  in line with Andre's explanation of the caching that occurs on the client machine (and why I must not have seen anything in our access.log's when I first tested IE and came to the wrong conclusion about its behavior, upthread).

Thanks for this very useful discussion gents.  

Message was edited by: Regis on 9/26/12 9:20:01 AM CDT
0 Kudos