Google considers following Mozilla, Microsoft, and dropping SHA-1 certificates early

Last month Microsoft said that it was considering ending support for TLS and SSL certificates that used the SHA-1 hashing algorithm, after Mozilla previously described a plan to do the same. Google is now thinking about joining those two companies and ending Chrome's support for SHA-1 certificates in the middle of next year too.

The underlying problem is that it has become too cost-effective to create forged certificates that use the SHA-1 hashing algorithm. As computers get faster, the cost of creating a fraudulent certificate goes down. Based on 2012 estimates, it was expected that criminals would be able to readily create such certificates by 2018. This declining cost led all three browser vendors to plan to end supporting any SHA-1 certificates issued after January 1, 2016, and all SHA-1 certificates after January 1, 2017.

Newer estimates have brought the cost of certificate fraud down further still. Through the use of cloud services such as Amazon's EC2, the compute power to create bogus SHA-1 certificates both costs less and is more accessible, such that SHA-1 certificates are arguably unsafe already. This led to reconsideration of the 2017 timetable. Mozilla and Microsoft are now contemplating bringing that January 1, 2017 date forward, to July 1, 2016, as long as the impact in-the-wild is not too serious.

Read 2 remaining paragraphs | Comments

Oracle settles with FTC over Java’s “deceptive” security patching

Way to go, Oracle. (credit: Oracle PR)

Oracle received a public slap on the wrist from the Federal Trade Commission over Java SE, the desktop runtime for Java. The FTC announced today that it had reached a settlement with Oracle Corporation over a complaint not about the security of Java itself, but about Oracle's patching process—and how it unintentionally left consumers to believe that the patches themselves were enough.

Java has been a source of perpetual security sorrow due to the number of exploitable flaws that have been discovered in various versions of Java SE. That's partially due to its huge installed base—over 850 million PCs are estimated to have Java SE installed on them, and it isn't always the most recent version. Older versions of Java create a major security risk—even when newer versions have been installed.

And there lies the rub of the FTC's complaint. Since at least 2010, Java SE updates have not done a thorough job of cleaning up the insecure versions—and, the FTC contends, Oracle failed to advise consumers doing the updating that the job was only half done.

Read 7 remaining paragraphs | Comments

Personal Device Security During the Holiday Season

Original release date: December 21, 2015

As the winter holiday travel season begins, US-CERT and Stop.Think.Connect would like to remind users to be mindful of the security risks associated with portable devices such as smart phones, tablets, and laptops. These devices offer a range of conveniences such as allowing us to order gifts on-the-go, providing us with directions, and even letting us download our boarding pass to pass through security with just our mobile device. However, with all of these added conveniences often come potential threats and vulnerabilities.

US-CERT would like to encourage users to review the following Cybersecurity Tips. Following the security practices suggested in each tip will help to keep your portable devices secure during the holiday season and throughout the year.


This product is provided subject to this Notification and this Privacy & Use policy.


Researchers confirm backdoor password in Juniper firewall code

The Juniper NetScreen 5200, one of the firewalls that carries the backdoor code inserted into Juniper's ScreenOS.

On December 17, Juniper Networks issued an urgent security advisory about "unauthorized code" found within the operating system used by some of the company's NetScreen firewalls and Secure Service Gateway (SSG) appliances. The vulnerability, which may have been in place in some firewalls as far back as 2012 and which shipped with systems to customers until late 2013, allows an attacker to gain remote administrative access to systems with telnet or ssh access enabled. And now researchers have both confirmed that the backdoor exists and developed a tool that can scan for affected systems.

In a post to the Rapid7 community blog site on December 20, Metasploit project founder and Rapid7 researcher H D Moore published an analysis of the affected versions of Juniper's ScreenOS operating system, including the administrative access password that had been hard-coded into the operating system. This backdoor, which was inserted into ScreenOS versions 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20, is a change to the code that authorizes administrative access with the password "<<< %s(un='%s') = %u"—a password that Moore notes was crafted to resemble debug code to evade detection during review.

Since this code is in the firmware of the affected Juniper NetScreen and SSG appliances, the only way to remove it is to re-flash the firmware with a new version of ScreenOS. Steve Puluka has written a guide on how to perform the upgrade and avoid some of the potential problems around installation, including dealing with the configuration of a new signing key for the upgrade.

Read 2 remaining paragraphs | Comments