Information Security News
by Peter Bright
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.
We are detecting numerous login attempts against our ssh honeypots using the ScreenOSbackdoor password. Our honeypot doesnt emulate ScreenOS beyond the login banner, so we do not know what the attackers are up to, but some of the attacks appear to be manual in that we do see the attacker trying different commands.
We saw the first attempt at 17:43:43 UTC about an hour after I adjusted the kippo honeypot to return the Netscreen banner.
The most popular usernames so far:
+---------------+----------+| username | count(*) |+---------------+----------+| root | 29 || admin | 18 || netscreen | 8 || login | 8 || administrator | 5 || test | 4 || system | 2 || bob | 1 || sdes | 1 || sqzeds | 1 || sqzds | 1 |+---------------+----------+
The most frequent source IPs for this attack so far:
+-----------------+----------+| ip | count(*) |+-----------------+----------+| 22.214.171.124 | 24 || 126.96.36.199 | 8 || 188.8.131.52 | 7 || 184.108.40.206 | 7 || 220.127.116.11 | 5 || 18.104.22.168 | 4 |- Qualys (probably research)| 22.214.171.124 | 4 || 126.96.36.199 | 4 || 188.8.131.52 | 4 || 184.108.40.206 | 3 || 220.127.116.11 | 2 || 18.104.22.168 | 2 || 22.214.171.124 | 1 || 126.96.36.199 | 1 || 188.8.131.52 | 1 || 184.108.40.206 | 1 |+-----------------+----------+
Based on hour of day (UTC, Dec. 20th)
+------+----------+| hour | count(*) |+------+----------+| 17 | 1 |- honeypot was adjusted 16:55 to return Netscreen banner| 19 | 25 || 20 | 14 || 21 | 23 || 22 | 15 |+------+----------+
by Sean Gallagher
Oracle received a public slap on the wrist from the US 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.
by Sean Gallagher
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.
Hello Kitty hack exposes 3.3 million users' details, says infosec bod
Up to 3.3 million Hello Kitty users have had their personal data exposed due to a database breach at the brand's online community SanrioTown.com, a security researcher has discovered. The sanriotown.com breach had been discovered online by researcher ...
Database leak exposes 3.3 million Hello Kitty fans
Hello Kitty and Minnie Mouse arrested after fight over tip money in New York's ...
Hello Kitty hack: Parents warned as database leak hits 3.3m users
Today 3pm ET, 12pm PT: Special Webcast What you need to know about the Juniper backdoor">https://www.sans.org/webcasts/101482
We decided to move to raise our Infocon to yellow over the backdoor in Juniper devices. We decided to do this for a number of reasons:
- Juniper devices are popular, and many organizations depend on them to defend their networks
- The backdoor password is now known, and exploitation is trivial at this point. 
- With this week being a short week for many of us, addressing this issue today is critical
Who is affected by this issue?
Juniper devices running ScreenOS 6.3.0r17 through 6.3.0r20 are affected by the fixed backdoor password (CVE-2015-7755). 
Juniper devices running ScreenOS">
There are two distinct issues. First of all, affected devices can be accessed via telnet or ssh using a specific backdoor password. This password can not be removed or changed unless you apply Junipers patch. Secondly, a purposely introduced weakness in the IPSECencryption code allows an attacker familiar with the weakness to decrypt VPN traffic. 
Not really. To lower the probability of an exploit of the backdoor password, access to ssh and telnet can be restricted. Only administrative workstations should be able to connect to these systems via ssh, and nobody should be able to connect via telnet. This is best practice even without a backdoor. No workaround is available for the VPN decryption issue.
See the list of vulnerable ScreenOS versions available above. You can also try to log in to the device using the now known backdoor password:
%s(un=%s) = %u (less-than, less-than, less-than, space, percent, lower case s, openparentheses,lower caseu, lower casen, equal sign, single quote, percent sign, lower case s, single quote, close paranthesis, space, equal sign, space, percent sign, lower case u).
This login will look like any other login. Audit all logins to your Juniper devices running vulnerable versions of ScreenOS. The password has been made public yesterday (Sunday Dec 20th) evening. In particular if your device can be found in databases like Shodan, you should expect to be targeted.
FoxIT released snort rules that you can use to detect exploit attempts . The first signature just detected if a telnet session was established. It is not used to actually alert, but just sets the flowbit that is used by later signatures that look for the password. For the SSH login, the password is encrypted. The signature below will trigger on all SSH logins to a Juniper device and it just looks for the typical NetScreen SSH banner.">alert tcp $HOME_NET 23 - any any (msg:FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)
content:Remote Management Console|0d0a|
">alert tcp any any - $HOME_NET 23 (msg:FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt
alert tcp $HOME_NET 23 - any any (msg:FOX-SRT - Backdoor - Juniper ScreenOS successful logon
">alert tcp $HOME_NET 22 - $EXTERNAL_NET any (msg:FOX-SRT - Policy - Juniper ScreenOS SSH world reachable