Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Update for Safari to version 5.1.10 is out - http://support.apple.com/kb/HT5921
OS X v10.8.5 update - details here: http://support.apple.com/kb/HT5880

Java and Old Hash Algorithms

Published: 2013-09-13
Last Updated: 2013-09-13 15:43:22 UTC
by Rob VandenBrink (Version: 1)
5 comment(s)

David, one of our readers, emailed wih a question - when he tries to interact with a particular print driver, he gets a Java error:

PKIX path validation failed:
java.security.cert.CertPathValidatorException:
Algorithm constraints check failed: MD2withRSA

This error comes up because as of Java 7, MD2 hashing and any RSA hash under 1024 bits are disabled.  Since this is a (very) old printer driver, the fact that it still uses MD2 is not a surprise - but what to do next?

OK - the obvious answer is to upgrade out of the problem - if the driver has an update, apply it.  But how do we get to the interface given the Java situation?  The answer is buried in the Java config files - - edit the file java.securty, which in Windows is found at: "C:\Program Files (x86)\Java\jre7\lib\security"

In this file, you'll find the line:

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

Edit or comment out this line, and MD2 will work for you again. But don't leave it like this - this enables all those certs with weak hashes, which leaves you open to a world of hurt.  In this case, it gets you access back to the interface so you can upgrade to a newer version.  If there is no newer version, it gives you access until you can upgrade the hardware or app that's causing the problem.

===============
Rob VandenBrink
Metafore

Keywords:
5 comment(s)

Happy Friday the 13th !

Published: 2013-09-13
Last Updated: 2013-09-13 15:41:38 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

My, how things have changed since 1987 – especially in the world malware!  In that year, the Jerusalem Virus hooked the old DOS Interrupts (int 21h for those who did assembler back in the day) for operation.  Since everything else also used INT 21h, including Netware clients (remember Netware?) and most DOS services, this malware slammed the already slow computers of the day with an additional performance hit.  Once on your system, this one infected all exe’s on the drive, growing them all by a specific number of bytes (depending on the variant).  On Friday the 13th, it then deleted all the EXE’s on the infected system.

If you’re interested, there’s more on this oldie here: http://en.wikipedia.org/wiki/Jerusalem_%28computer_virus%29.  I’d guess that the AV folks all have a page on this one as well.

In today's terms,  there is no point to this “vintage virus”, aside from infecting as many computers and as many executables as possible, then doing the mass-destruction thing when the countdown expires.  Mainly it’s a “because I can” piece of destructive code.

These days, most attacks and malware is all about theft of dollars, credentials or information of some kind.  It’s become a business like any other, and like other businesses “follow the money” is the best way of determining motivation and what’s happening behind any smokescreen involved.  Often we have to follow the packets, or the log entries, or the code along the way, but the end goal and motivation is most often financial.  It’s protecting this target information that keeps us all awake at nights, and drives the entire security effort that we’re all a part of.

Anyway, if you still have a DOS or Windows/9x system (sadly, I’ve still got a client running a pharmaceutical manufacturing system on Win9x), today might be a bad day for you.  But if not, take a minute to think about what we’re protecting, and (as always) what you may have missed.  

Speaking of oldies but goodies, and things missed - it might be a good day to look ahead and deal with a few loose ends in today’s infrastructure:

  • think about knocking that last Win2K server out of your infrastructure - moving it to a VM did NOT solve this issue forever
  • Or deal with that ticking time-bomb of the XP stations still left in the infrastructure.  Microsoft recently posted an article on the risks of running XP past April 8,2014 (less than 7 months away !! )  http://blogs.technet.com/b/security/archive/2013/08/15/the-risk-of-running-windows-xp-after-support-ends.aspx.  If you think XP has been a bit quiet on the security front lately, consider that this is likely because the bad guys are saving all their zero days up for April 9 of next year.  I know of a few large organizations (>5,000 stations) that have put this off long enough that getting this project planned and done in time might not be possible.  If you are still running XP on April 9, you may end up having to explain to shareholders why your business was partially or mostly offline for the last 10 weeks of Q2 2014 !!

If money is the motivation for many of today's attacks and malware, XP and Win2K are the unlocked doors in the neighborhood - it's time and past time to get these things battened down!
 

===============
Rob VandenBrink
Metafore

Keywords:
0 comment(s)
Diary Archives