Friday, February 5, 2016

Severity: High - OpenSSL Security Advisory

28th Jan 2016

NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES ONLY ARE BEING APPLIED.

DH small subgroups (CVE-2016-0701)


Severity: High

Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite.


OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk.

OpenSSL before 1.0.2f will reuse the key if:
• SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set.
• SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key.
• Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2.

It will not reuse the key for DHE ciphers suites if:
• SSL_OP_SINGLE_DH_USE is set
• SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this.

Non-safe primes are generated by OpenSSL when using:
• genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way.
• dhparam with the -dsaparam option. This has always been documented as requiring the single use.

The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact.

Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact.

This issue affects OpenSSL version 1.0.2.

OpenSSL 1.0.2 users should upgrade to 1.0.2f


OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42 based parameters. It is possible to generate parameters using non "safe" primes, but this option has always been documented as requiring single use and is not the default or believed to be common. However, as a precaution, the SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r.


This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso (Adobe). The fix was developed by Matt Caswell of the OpenSSL development team (incorporating some work originally written by Stephen Henson of the OpenSSL core team).


SSLv2 doesn't block disabled ciphers (CVE-2015-3197)




Severity: Low
A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 users should upgrade to 1.0.1r
This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Nimrod Aviram with further development by Viktor Dukhovni of the OpenSSL development team.

An update on DHE man-in-the-middle protection (Logjam)

A previously published vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits in releases 1.0.2b and 1.0.1n.

This limit has been increased to 1024 bits in this release, to offer stronger cryptographic assurance for all TLS connections using ephemeral Diffie-Hellman key exchange.

OpenSSL 1.0.2 users should upgrade to 1.0.2f
OpenSSL 1.0.1 users should upgrade to 1.0.1r

The fix was developed by Kurt Roeckx of the OpenSSL development team. Note

As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates.

References

URL for this Security Advisory: https://www.openssl.org/news/secadv/20160128.txt

Note: the online version of the advisory may be updated with additional details over time.

For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html

Sunday, December 27, 2015

Second Amendment Bolt Action Pen

Friday, December 25, 2015

Fun Video

Fun video featuring pens I've made along with two time laps clips.

Friday, December 18, 2015

Juniper Releases Out-of-band Security Advisory for ScreenOS

I realize that as I post this most of who read this the subject isn't in their day-to-day responsibilities, but folks; this is a REALLY BIG deal.


Reading the information it says that the unauthorized code they found in the FIREWALLS they create have had this problem since the release of their 6.2 version. That was seven (plus) years ago in 2008. To go on and read you'll see where the access allowed the attacker to delete any references to their presence in the log files.


So even if this isn't your cup of tea you may want to pass this along to someone in your IT department because Juniper Firewalls are pretty popular.


Read More:
https://www.us-cert.gov/ncas/current-activity/2015/12/17/Juniper-Releases-Out-band-Security-Advisory-ScreenOS



Friday, December 4, 2015

Dorkbot

Systems Affected

Microsoft Windows

Overview

Dorkbot is a botnet used to steal online payment, participate in distributed denial-of-service (DDoS) attacks, and deliver other types of malware to victims’ computers. According to Microsoft, the family of malware used in this botnet “has infected more than one million personal computers in over 190 countries over the course of the past year.” The United States Department of Homeland Security (DHS), in collaboration with the Federal Bureau of Investigation (FBI) and Microsoft, is releasing this Technical Alert to provide further information about Dorkbot.

Description

Dorkbot-infected systems are used by cyber criminals to steal sensitive information (such as user account credentials), launch denial-of-service (DoS) attacks, disable security protection, and distribute several malware variants to victims’ computers. Dorkbot is commonly spread via malicious links sent through social networks instant message programs or through infected USB devices.
In addition, Dorkbot’s backdoor functionality allows a remote attacker to exploit infected system. According to Microsoft’s analysis, a remote attacker may be able to:
  • Download and run a file from a specified URL;
  • Collect logon information and passwords through form grabbing, FTP, POP3, or Internet Explorer and Firefox cached login details; or
  • Block or redirect certain domains and websites (e.g., security sites).

Impact

A system infected with Dorkbot may be used to send spam, participate in DDoS attacks, or harvest users' credentials for online services, including banking services.

Solution

Users are advised to take the following actions to remediate Dorkbot infections:
  • Use and maintain anti-virus software – Anti-virus software recognizes and protects your computer against most known viruses. Even though Dorkbot is designed to evade detection, security companies are continuously updating their software to counter these advanced threats. Therefore, it is important to keep your anti-virus software up-to-date. If you suspect you may be a victim of Dorkbot, update your anti-virus software definitions and run a full-system scan. (See Understanding Anti-Virus Software for more information.)
  • Change your passwords – Your original passwords may have been compromised during the infection, so you should change them. (See Choosing and Protecting Passwords for more information.)
  • Keep your operating system and application software up-to-date – Install software patches so that attackers cannot take advantage of known problems or vulnerabilities. You should enable automatic updates of the operating system if this option is available. (See Understanding Patches for more information.)
  • Use anti-malware tools – Using a legitimate program that identifies and removes malware can help eliminate an infection. Users can consider employing a remediation tool (see example below) to help remove Dorkbot from their systems.
  • Disable Autorun­ – Dorkbot tries to use the Windows Autorun function to propagate via removable drives (e.g., USB flash drive). You can disable Autorun to stop the threat from spreading.

Microsoft

http://www.microsoft.com/security/scanner/en-us/default.aspx (link is external)
The above example does not constitute an exhaustive list. The U.S. Government does not endorse or support any particular product or vendor.

References

Second IRS Tax Security Tip

The Internal Revenue Service (IRS) has released the second in a series of tips intended to increase public awareness of how to protect personal and financial data online and at home. A new tip will be available each Monday through the start of the tax season in January, and will continue through the April tax deadline. US-CERT and the IRS recommend taxpayers prepare for heightened risk this tax season and remain vigilant year-round.


The second tip focuses on awareness of phishing attempts and prevention of malware infection when conducting business online. US-CERT encourages users and administrators to review IRS Security Awareness Tax Tip Number 2 for additional information.




https://www.us-cert.gov/ncas/current-activity/2015/12/03/IRS-Releases-Second-Tax-Security-Tip