April 23, 2014

NSA denies it knew about Heartbleed, says it is in the national interest for it to disclose vulnerabilities

odniIt looks like the ramifications of the Heartbleed bug in OpenSSL will be felt for quite a while to come. While security analysts are asking if the NSA had prior knowledge of the bug, cyber criminals are at work stealing data from sites which haven’t patched their servers and changed their SSL certificates. The Canadian Revenue Agency has said that the Heartbleed bug was the reason why an attacker was able to steal 900 social insurance numbers, and British parenting website Mumsnet said that username and password data used to authenticate users during log in was accessed before the site was able to patch its servers.

As for the NSA, the Director of National Intelligence has issued a statement saying that the NSA was not aware of the Heartbleed vulnerability until it was made public. The statement went on to say that the Federal government relies on OpenSSL the same as everyone else to protect the privacy of users of government websites and other online services.

However, what is even more important is that the statement categorically says that had the NSA, or any other of the agencies and organizations which make up the U.S. intelligence community, found the bug they would have reported it to the OpenSSL project.

“If the Federal government, including the intelligence community, had discovered this vulnerability prior to last week, it would have been disclosed to the community responsible for OpenSSL,” said the statement issued by the ODNI Public Affairs Office. The statement also said that when Federal agencies discover a new vulnerability “it is in the national interest to responsibly disclose the vulnerability rather than to hold it for an investigative or intelligence purpose.”

The Office of the Director of National Intelligence also said that in response to the President’s Review Group on Intelligence and Communications Technologies report that it had reinvigorated an interagency process for deciding when to share vulnerabilities.  According to the report, “The US Government should take additional steps to promote security, by (1) fully supporting and not undermining efforts to create encryption standards; (2) making clear that it will not in any way subvert, undermine, weaken, or make vulnerable generally available commercial encryption; and (3) supporting efforts to encourage the greater use of  encryption technology for data in transit, at rest, in the cloud, and in storage.” Such a statement is important following the accusations that the NSA tried (and succeeded) in weakening certain encryption standards.

The report also says that, “US policy should generally move to ensure that Zero Days are quickly blocked, so that the underlying vulnerabilities are patched on US Government and other networks. In  rare instances, US policy may briefly authorize using a Zero Day for high priority intelligence collection, following senior, interagency review involving all appropriate departments.”

This “rare” use of zero-day vulnerabilities was reiterated by the ODIN statement. “Unless there is a clear national security or law enforcement need, this process is biased toward responsibly disclosing such vulnerabilities.”

Heartbleed bug exposes OpenSSL’s secrets, patches available

heartbleedA serious security bug has been found in the ubiquitous OpenSSL encryption library that allows data to be stolen in its unencrypted form. According to the heartbleed.com website, which was set up expressly to inform system admins about the potential dangers, the Heartbleed bug can be exploited from the Internet and it allows an attacker to read up to 64k of the server’s memory at one time. By reading the memory an attacker can gain access to “the secret keys used to identify the service providers and to encrypt the traffic” along with “the names and passwords of the users and the actual content.” It means that attackers can eavesdrop communications that should have been otherwise encrypted.

A patched version of OpenSSL has already been published. According to the release notes, “a missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory” on a connected client or server. The OpenSSL project publicly thanked Neel Mehta of Google Security for discovering this bug and Adam Langley with Bodo Moeller for preparing the fix. It is recommended that all OpenSSL 1.0.1 users should upgrade to OpenSSL 1.0.1g. Those unable to immediately upgrade should recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. OpenSSL 1.0.0 and OpenSSL 0.9.8 are not vulnerable.

Heartbleed isn’t a design flaw in the SSL/TLS protocol specification but rather a bug in OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520).

Because the bug can expose the keys used for encrypting the connection, attackers are able to decrypt any past and future traffic to the encrypted connection since the primary keys have been exposed. Unfortunately to remedy the problem, not only does the server require patching but all the compromised keys need to be revoked and new keys reissued. It also means that users who have used an encrypted service (say a web mail service, online shopping or cloud service) will need to change their passwords as potentially the connection used to log in was not secure.

One very worrying aspect of this bug is not only the widespread use of OpenSSL, but also that the first vulnerable version was published two years ago. If this bug has been previously found (but not disclosed) by cyber criminals or government run security agencies then the last two years worth of encrypted traffic should be deemed as exposed. Even if it wasn’t found but the traffic was recorded then there are probably lots of state level agencies working right now to siphon off keys from around the net before things are revoked and changed.

Many Android apps open to man-in-the-middle attacks due to weak SSL usage

After injecting a virus signature database via a MITM attack over broken SSL, the AntiVirus app recognized itself as a virus and recommended to delete the detected malware.

Security researchers from the Leibniz University of Hanover and the computer science department at the Philipps University of Marburg have tested 13,500 popular free Android apps and found that 8.0% of these apps contain SSL/TLS implementations that are vulnerable to  Man-in-the-Middle (MITM) attacks.

The researchers created a tool called MalloDroid which is designed to detect potential vulnerabilities against MITM attacks. The tool performs static code analysis to analyze the networking API calls and extract valid HTTP(S) URLs, check the validity of the SSL certificates of all the extracted HTTPS hosts; and  identify apps that contain non-default trust managers. Running the tool on the 13,500 samples showed that 1,074 of the apps exhibited some kind of potential vulnerability.

From this 1,074 app a further 100 apps were picked for manual audit to investigate different SSL problem  including the accepting of all SSL certificates regardless of their validity. This manual audit revealed that 41 of the apps were vulnerable to MITM attacks due to SSL misuse.

A particularly embarrassing case the researchers found that the Zoner AntiVirus app updated its virus signatures via a broken SSL connection. As the developers considered the connection to be secure and couldn’t be tampered with there is no built-in verification or validation of the signature files downloaded. This meant that the team was able to insert its own signatures files. In one test they added the signature for the anti-virus app itself. The app then proceeded to recognize itself as malware and recommended that itself be to deleted. The Zoner AntiVirus app has been downloaded more than 500,000 times!

By the end of their research the team had managed to capture credentials for American Express, Diners Club, Paypal, Facebook, Twitter, Google, Yahoo, Microsoft Live ID, Box, WordPress, IBM Sametime, remote servers, bank accounts and email accounts.

The total cumulative number of installs of all the MITM vulnerable apps is between 39.5 and 185 million users, according to the download numbers from Google’s Play Store.

90% of all HTTPS Websites Insecure

(LiveHacking.Com) – SSL Pulse, a new project that monitors the quality of SSL sites across the Internet and reports on its findings, has discovered that 90% of all HTTPS websites are insecure. The project has tested the top 200,000 SSL web sites on the Internet and discovered that nearly 180,000 of them are insecure.

The project measures key features about an SSL configuration and ranks the website according to the SSL Server Rating Guide. According to the report 40% of the worlds top SSL sites use 128 bit (or less) ciphers for data transfer and a handful of sites have certificates with keys below 1024 bits.

The biggest weaknesses are insecure renegotiation and susceptibility to a BEAST attack. Over 8,500 sites support insecure renegotiation which since 2009 as been considered insecure. A successful exploitation of this vulnerability allows an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. The results is that the attacker can impersonate a valid client and steal confidential data.

The SSL Pulse survey reports that 75% of SSL websites are still open to BEAST attacks. A BEAST attack is based on a flaw in the SSL protocol. A successful exploitation of this issue will result in a disclosure of a victim’s session cookies, allowing the attacker to completely hijack the application session. It was resolved in TLS v1.1, but now six years later, most clients and servers do not support newer protocol versions. To protected against a BEAST attack servers need to be configured to use TLS v1.1 or to only use RC4 with TLS v1.0 or SSL v3.0.

“About 50% (99,903 sites) got an A, which is a good result. Unfortunately, many of these A-grade sites (still) support insecure renegotiation (8,522 sites, or 8.5% of the well-configured ones) or are vulnerable to the BEAST attack (72,357 sites, or 72.4% of the well-configured ones). This leaves us with only 19,024 sites (or 9.59% of all sites) that are genuinely secure at this level of analysis,” wrote Ivan Ristic, director of engineering at Qualys and creator of SSL Labs.

The project hopes that these startling numbers will raise awareness of these issues and help web site owners improve their SSL implementations.

New Security Updates For All Active Branches of PostgreSQL

(LiveHacking.Com) – New security updates for all active versions PostgreSQL, the object-relational database system, have been released by the PostgreSQL Global Development Group. The updates are available for versions 9.1.3, 9.0.7, 8.4.11 and 8.3.18.

The update fixes vulnerability in three areas:

  • Permissions on a function called by a trigger are not checked.
  • SSL certificate name checks are truncated to 32 characters, allowing connection spoofing under some circumstances.
  • Line breaks in object names can be exploited to execute code when loading a pg_dump file.

The first fix prevents users from defining triggers which execute functions for which the user does not have EXECUTE permission. The problem was that CREATE TRIGGER failed to make any permissions check on the trigger function to be called. If the trigger function was marked SECURITY DEFINER, privilege escalation becomes possible.

The SSL fix resolves a problem with SSL common name truncation, which could allow hijacking of an SSL connection under exceptional circumstances. Since the name extracted from an SSL certificate was incorrectly truncated to 32 characters it was theoretically possible to spoof the name on a false certificate.

The final security fix is to the pg_dump program. pg_dump copies object names into comments in a SQL script without sanitizing them by using an object name which includes a newline it is possible to add SQL commands to the dump script. When the dump script is reloaded, the command would be executed with the privileges of whoever is running the script.

Users of pg_dump, users of SSL certificates for validation or users of triggers using SECURITY DEFINER should upgrade their installations immediately.

This release also contains 45 fixes to version 9.1, and a smaller number of fixes to older versions, including:

  • Fix btree index corruption from insertions concurrent with vacuuming
  • Recover from errors occurring during WAL replay of DROP TABLESPACE
  • Fix transient zeroing of shared buffers during WAL replay
  • Fix postmaster to attempt restart after a hot-standby crash
  • Fix corner case in SSI transaction cleanup
  • Update per-column permissions, not only per-table permissions, when changing table owner
  • Fix handling of data-modifying WITH subplans in READ COMMITTED rechecking
  • Fix for “could not find plan for CTE” failures
  • Fix unsupported node type error caused by COLLATE in an INSERT expression
  • Avoid crashing when we have problems deleting table files post-commit
  • Fix recently-introduced memory leak in processing of inet/cidr
  • Fix GIN cost estimation to handle column IN (…) index conditions
  • Fix I/O-conversion-related memory leaks in plpgsql
  • Teach pg_upgrade to handle renaming of plpython’s shared library (affecting upgrades to 9.1)

More information about the updates, including a full list of fixes and changes, can be found in the 9.1.39.0.78.4.11 and 8.3.18 release notes.

PostgreSQL can be downloaded from:

Mozilla Sends Another Message to Certificate Authorities

(LiveHacking.Com) – Mozilla has sent an email to all certificate authorities in the Mozilla root program to reiterate that the issuance of subordinate CA certificates for the purposes of SSL man-in-the-middle interception or traffic management is unacceptable. Mozilla has asked the CAs to revoke any such certificates by April 27, 2012. After that date, if it is found that a subordinate CA is being used for MITM, Mozilla could remove the corresponding root certificate from the Mozilla root program. This would mean the applications like Mozilla FireFox wouldn’t accept the certificate when presented.

“We made it clear that this practice remains unacceptable even when the intended deployment of such a certificate is restricted to a closed network,” said Johnathan Nightingale, Senior Director of Firefox Engineering.

Mozilla also reinforced the the Certificate Authorities responsibilities reminding them that they are accountable for every certificate they sign, directly or through its subordinates.

This isn’t the first time Mozilla has asked CAs to be more responsible. In September 2011 Mozilla sent a message to all the certificate authorities (which participate in the Mozilla root certificate program) requesting that they complete an audit of their PKI systems. This call to review and confirm the integrity of their certificate systems came after Mozilla removed the DigiNotar root certificate in response to its failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates.

Is SSL Falling Apart? New Research Papers Find More Holes

(LiveHacking.Com) – Two new research papers (here and here) have been published which examine the low level details of SSL, specifically randomness aspects, and the results are surprising. According to the “Ron was wrong, Whit is right” paper,  two out of every one thousand RSA moduli that on the Internet today offer no security. While the Princeton’s Center for Information Technology Policy blog shows that 0.4% of all the public keys used for SSL web site security can be remotely compromised.

Two in one thousand is  0.2%, Princeton is talking 0.4%. These aren’t huge numbers… but a search on Google for how many sites have “https://” in the URL shows 19,640,000,000 sites. Some of these are sites about HTTPS and aren’t secure sites. If just one quarter of those are really using https, that is 4,910,000,000 sites. 0.4% of 1,964,000,000. That is a lot of SSL certificates. And a huge potential number of sites which can be hacked.

“Our conclusion is that the validity of the assumption is questionable and that generating keys in the real world for “multiple-secrets” cryptosystems such as RSA is signi cantly riskier than for “single-secret” ones such as ElGamal or (EC)DSA which are based on Die-Hellman,” wrote Arjen K. Lenstra et al.

SSL has been having a hard time recently and it is starting to look as if this system isn’t as robust as previously thought. Recent SSL stories include the BEAST, Diginotar and Verisign.

“Unfortunately, we’ve found vulnerable devices from nearly every major manufacturer and we suspect that more than 200,000 devices, representing 4.1% of the SSL keys in our dataset, were generated with poor entropy. Any weak keys found to be generated by a device suggests that the entire class of devices may be vulnerable upon further analysis,” wrote Nadia Heninger.

OpenSSL Fix Flaw in Recent Bug Fix

(LiveHacking.Com) – Earlier this month, the OpenSSL project released updates to two new versions (OpenSSL 1.0.0f and 0.9.8s) of the popular open source toolkit for SSL/TLS to fix a total of six security flaws. One of the vulnerabilities fixed (CVE-2011-4108) was in OpenSSL’s DTLS implementation which allowed an efficient plaintext recovery attack. However Antonio Martin from Cisco Systems, Inc found a flaw in the in the fix that can be exploited in a denial of service attack. Only DTLS applications using OpenSSL 1.0.0f and 0.9.8s are affected.

To remedy this the OpenSSL project have now released OpenSSL 1.0.0g and OpenSSL 0.9.8t.

Microsoft Fixes Eight Security Vulnerabilities in its Products

(LiveHacking.Com) – Microsoft has released seven security bulletins as part of its Patch Tuesday program. One of seven bulletins is rated Critical, with the remaining six classified as Important. The Critical bulletin addresses two issues in Windows Media Player. If exploited these vulnerabilities would allow remote code execution on the affected PC. Although there are no known active exploitations of these bugs, they can be triggered by a hacker crafting a malicious MIDI or DirectShow file. If the user then opened this file their PC would become vulnerable as the attacker could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

The remaining fixes are:

  • Vulnerability in Windows Object Packager That Could Allow Remote Code Execution – The vulnerability could allow remote code execution if a user opens a legitimate file with an embedded packaged object that is located in the same network directory as a specially crafted executable file.
  • Vulnerability in Windows Client/Server Run-time Subsystem That Could Allow Elevation of Privilege – The vulnerability could allow elevation of privilege if an attacker logs on to an affected system and runs a specially crafted application. The attacker could then take complete control of the affected system and install programs; view, change, or delete data; or create new accounts with full user rights. This vulnerability can only be exploited on systems configured with a Chinese, Japanese, or Korean system locale.
  • Vulnerability in Microsoft Windows That Could Allow Remote Code Execution – The vulnerability could allow remote code execution if a user opens a specially crafted Microsoft Office file containing a malicious embedded ClickOnce application.
  • Vulnerability in SSL/TLS Could Allow Information Disclosure – This vulnerability affects the SSL 3.0 and TLS 1.0 protocols and is not specific to the Windows operating system. The vulnerability could allow information disclosure if an attacker intercepts encrypted web traffic served from an affected system. TLS 1.1, TLS 1.2, and all cipher suites that do not use CBC mode are not affected. This should protect users  from the tool known as BEAST (Browser Exploit Against SSL/TLS).
  • Vulnerability in AntiXSS Library Could Allow Information Disclosure – The vulnerability could allow information disclosure if a an attacker passes a malicious script to a website using the sanitization function of the AntiXSS Library.

Six Security Flaws Fixed in OpenSSL

(LiveHacking.Com) – The OpenSSL project team has released two new versions of the popular open source toolkit for SSL/TLS. OpenSSL 1.0.0f and 0.9.8s fix a total of six security flaws. Of the six fixes, four apply to 1.0.0f and 0.9.8s together and then each version has one unique fix for its code stream.

The relevant security advisory lists the following:

  1. DTLS Plaintext Recovery Attack (CVE-2011-4108) - Nadhem Alfardan and Kenny Paterson have discovered an extension of the Vaudenay padding oracle attack on CBC mode encryption which enables an efficient plaintext recovery attack against the OpenSSL implementation of DTLS. Their attack exploits timing differences arising during decryption processing. A research paper describing this attack can befound at http://www.isg.rhul.ac.uk/~kp/dtls.pdf
  2. Double-free in Policy Checks (CVE-2011-4109) - If X509_V_FLAG_POLICY_CHECK is set in OpenSSL 0.9.8, then a policy check failure can lead to a double-free. The bug does not occur unless this flag is set. Users of OpenSSL 1.0.0 are not affected.
  3. Uninitialized SSL 3.0 Padding (CVE-2011-4576) - OpenSSL prior to 1.0.0f and 0.9.8s failed to clear the bytes used as block cipher padding in SSL 3.0 records. This affects both clients and servers that accept SSL 3.0 handshakes: those that call SSL_CTX_new with SSLv3_{server|client}_method or SSLv23_{server|client}_method. It does not affect TLS. As a result, in each record, up to 15 bytes of uninitialized memory may be sent, encrypted, to the SSL peer. This could include sensitive contents of previously freed memory. However, in practice, most deployments do not use SSL_MODE_RELEASE_BUFFERS and therefore have a single write buffer per connection. That write buffer is partially filled with non-sensitive, handshake data at the beginning of the connection and, thereafter, only records which are longer any any previously sent record leak any non-encrypted data. This, combined with the small number of bytes leaked per record, serves to limit to severity of this issue.
  4. Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577) - RFC 3779 data can be included in certificates, and if it is malformed, may trigger an assertion failure. This could be used in a denial-of-service attack. Note, however, that in the standard release of OpenSSL, RFC 3779 support is disabled by default, and in this case OpenSSL is not vulnerable. Builds of OpenSSL are vulnerable if configured with “enable-rfc3779″.
  5. SGC Restart DoS Attack (CVE-2011-4619) - Support for handshake restarts for server gated cryptograpy (SGC) can be used in a denial-of-service attack.
  6. Invalid GOST parameters DoS Attack (CVE-2012-0027) - A malicious TLS client can send an invalid set of GOST parameters which will cause the server to crash due to lack of error checking. This could be used in a denial-of-service attack. Only users of the OpenSSL GOST ENGINE are affected by this bug.

OpenSSL 1.0.0f  is considered the current best version of OpenSSL available and it is recommended that users of older versions upgrade as soon as possible. OpenSSL 1.0.0f is available for download via HTTP and FTP from the following master locations:

For a complete list of changes, please seehttp://cvs.openssl.org/getfile?f=openssl/CHANGES&v=OpenSSL_1_0_0f.