Patrick

Script to defeat Java Application Blocked issues

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
Patrick submitted a new resource:

Script to defeat Java Application Blocked issues - How to stop the application blocking on entire IP address ranges.

Background
I made a post a few weeks ago on a way to manually defeat Java Application Blocked issues when trying to connect to various iKVM interfaces. Today I re-installed Windows 10 and lost my old exceptions.list file which had gotten pretty big.

I read Terry Kennedy's comment that the actual list is found in exception.sites...
Read more about this resource...
 

JeffroMart

Member
Jun 27, 2014
61
18
8
45
Thanks Patrick, I just used it, works great! Always a pain to manually enter across multiple addresses, NO LONGER!
 

xnoodle

Active Member
Jan 4, 2011
258
48
28
I wonder if Java will.. choke if I put in a blanket exception for 10.0.0.0/8 + 172.16.0.0/12...
 
May 8, 2015
142
24
18
33
I don't mean to be rude or come out of left field here... But why the h*** are we encouraging terrible security practices?
 

Emulsifide

Active Member
Dec 1, 2014
212
93
28
I don't mean to be rude or come out of left field here... But why the h*** are we encouraging terrible security practices?
Why is granting exceptions to known secure IP address ranges for iKVM purposes considered a terrible security practice? Just be smart about it and don't use it on every IP address range you can think of.
 
  • Like
Reactions: rockitlikeithott

cesmith9999

Well-Known Member
Mar 26, 2013
1,417
468
83
in my case I was taking his code and re-writing it in to powershell. which is native to windows 10. and means that you can use it immediately.

Really what we are doing is generating a list. and you can edit that list.

Chris
 
May 8, 2015
142
24
18
33
Why is granting exceptions to known secure IP address ranges for iKVM purposes considered a terrible security practice? Just be smart about it and don't use it on every IP address range you can think of.
Assume breach. If an attacker is already inside (which they are if you're any reasonably sized or high value corporation) 9/10 times they'll be able to get onto that "known secure" vlan. Ignoring security practices in an IP space where only admins hang out to bypass security restrictions for Java of all things is lunacy. For example, if I were doing a red-team assessment and I owned an administrator account but perhaps it's not the domain admin, one thing I would certainly try is popping the domain admin with JAVA on the iKVM vlan. If I'm doing it you can be certain people that get paid to hack major corporations and governments 5 days a week for a living are trying and succeeding at doing the same things. Sure, realistically in 2016 it would be relatively straightforward to get domain admin even pivoting from an unprivileged account using PowerShell but why would you create more security risks?

I know most people don't think this way but we need to start. Sorry if I'm coming off as preachy or condescending. I really don't intend to. It's just hard to see such intelligent people in the tech community completely ignoring security.

Edit: I can't spell.
 
  • Like
Reactions: Emulsifide

azev

Well-Known Member
Jan 18, 2013
768
251
63
are saying that we should forgo using java ikvm all together ?? I mean what is the difference with manually opening 100 IP address individually because you have 100 server, than opening the whole /24 because that is your ILO vlan ?
 
May 8, 2015
142
24
18
33
are saying that we should forgo using java ikvm all together ?? I mean what is the difference with manually opening 100 IP address individually because you have 100 server, than opening the whole /24 because that is your ILO vlan ?
In a perfect world? I would love if everyone moved away from java ikvm but that's not realistic. And my point was not to create security exceptions on specific IP addresses. My point was to not create security exceptions for any IP address at all. (Bear with me here.) Make it a priority to update ikvm firmware. If your vendor doesn't support the latest acceptable security, demand it. Vendors are not going to change unless they get pressure from their customers. Threaten to switch to a different vendor. If you have a situation (and I do realize they exist although in my experience it's far more rare then a sysadmin would have you believe) where you have to utilize an insecure technology make sure that it's entirely segmented. You have to remember that security holes are like dominoes. If one falls over more often than not the rest will also. If you have a singular machine that requires you to circumvent Java's already weak security minimums, it should not be on the same vlan as other machines. It should be completely isolated, an unprivileged account with access only to that device should be used to manage it. It should have a completely unique password (so should every single one of your accounts.) And ideally it should be accessed from a machine (you can easily spin up a VM) that only has access to the machine with weakened security and nothing else. This way in the unlikely event that it gets pwned, (and taking these precautions would make it unlikely) an attacker is stuck in no mans land with no access to anything else that's valuable.

You should also have logging set up that's actually monitored so you know when the ikvm is accessed but that's a whole different can of worms...
 

Terry Kennedy

Well-Known Member
Jun 25, 2015
1,140
594
113
New York City
www.glaver.org
If your vendor doesn't support the latest acceptable security, demand it. Vendors are not going to change unless they get pressure from their customers. Threaten to switch to a different vendor.
With system replacement cycles stretching out to 5 years and beyond, companies are running systems that have moved to "mature support" (if supported at all beyond availiability of replacement parts). Even if customers can pressure those vendors to change their policies, that is usually only going to be reflected in new products - many vendors don't have the ability to "ramp back up" support on mature systems. I've run into this with various 2-, 3-, and 4-letter-name vendors.

This is not just an issue with Java. It affects things like SSL as well. To give a specific example (without naming names, but it was a 3-letter-name company), their SSL implementation was part of the RTOS package they purchased from their supplier (a well-known provider of that sort of thing). By the time SSL "broke" on that product, the RTOS supplier had obsoleted that package. In fact, newer products from the vendor (for the last several years) included a different, newer, RTOS / SSL. Due to the customer uproar about the older product's SSL no longer working (a campaign which I had a not-insignificant part in), the vendor paid the old RTOS supplier an also-not-insignificant amount of money to add a fix for that SSL problem to the obsolete RTOS. The vendor then resurrected their obsolete build system and built the first new firmware release in over 6 years (for hardware that was discontinued over 5 years ago). It went through internal testing, some bugs were fixed, and it was released to select customers (including me) for beta testing. It was approved and the vendor was going to publish it on their web site the following week. In the week between the approval and the publication, Firefox changed its behavior again and stopped working with the firmware due to a different SSL issue. Faced with the choice of paying the RTOS supplier to do a complete upgrade of the SSL package and hope that no future SSL issues would cause browsers to stop working, again, or to say "the hell with it" and decide that hardware that has been discontinued for over 5 years wasn't going to get that level of support, they went with the second choice. I can't blame them.

Another vendor, this one with a 2-letter-name (which recently changed its name to a 3-letter-name) sells combined hardware / software (OS) support for an obscene amount of money. How obscene? Well, you could buy 10 systems on the used market for less than the vendor charges for a year's support. Their SSL implementation? It's from 2007! Or perhaps older, as the latest remote management firmware reports a 2007 date. Their response to requests from customers paying the obscene amount of money for support? Pretty much "Derp!" Do you remember the old "We don't have to care - we're the phone company!" trope from before the Bell System breakup? Well, that's this vendor's apparent philosophy.

At the beginning of this year, I wrote a blog post titled "Is no crypto always better than bad crypto?" where I questioned the browser behavior of just going "nope - not gonna talk to that system" for certain categories of issues. You might want to take a look and see if you agree with me or not. Since I published that post, Firefox has changed its behavior slightly and there's a "yes, I know what I'm doing and I want to override this" checkbox in the Advanced dialog box for certain additional SSL issues that wasn't there when I wrote that post.
 
  • Like
Reactions: nthu9280

tby

Active Member
Aug 22, 2013
222
111
43
Snellville, GA
set-inform.com
If we're going to pressure vendors, how about we pressure them to stop bastardizing the VNC protocol and forcing their shit Java viewers upon us? Give us straight VNC! Or RDP! Or a pure Javascript / HTML5 front-end! Anything that saves me from having to install Java in the first damned place.
 

Patrick

Administrator
Staff member
Dec 21, 2010
12,511
5,792
113
If we're going to pressure vendors, how about we pressure them to stop bastardizing the VNC protocol and forcing their shit Java viewers upon us? Give us straight VNC! Or RDP! Or a pure Javascript / HTML5 front-end! Anything that saves me from having to install Java in the first damned place.
We had a Dell T630 in the lab. iDRAC 8 Enterprise had a HTML5 viewer.
 

TuxDude

Well-Known Member
Sep 17, 2011
616
338
63
We had a Dell T630 in the lab. iDRAC 8 Enterprise had a HTML5 viewer.
I just received a new Dell R730 at work a few days ago, also with iDRAC 8 Enterprise - even after ensure all firmware is up to date my console viewer is still Java based.
 

Jon Massey

Active Member
Nov 11, 2015
339
82
28
37
Addition as of recent JREs that block applications signed by MD5withRSA (as is the case with DRAC6 and may other BMC's iKVMs):

in $JRE$\lib\security\java.security remove/comment out MD5withRSA from any of the "disabledAlgorithms" config lines. On Windows 10 I did this in the 32-bit and 64-bit program files directories.