The research, done by Robert Hansen of SecTheory, shows that browsers such as Firefox, Internet Explorer and Chrome have a number of architectural problems that can essentially negate the security that SSL is meant to provide for sensitive Web transactions. The techniques that Hansen has developed, which he demonstrated at the Black Hat conference here Thursday, give an attacker the ability to do any number of nasty things to a target machine, including forcing the download of an executable file, overwriting the URL field in the browser and overwrite secure HTTPS cookies with non-secure cookies.

In all, Hansen found 24 problems before he decided to stop looking. “I had basically had to stop the research because there were just too many issues. I didn’t have time to deal with anymore,” Hansen said.

A big part of the problem, Hansen said in an interview, is that browsers don’t enforce policies that would isolate the tabs in an open browser from one another. This allows an attacker who can control one of the tabs, say a normal non-SSL session, to also affect content in the other tabs, even if they’re using SSL. Hansen identified several techniques that enable him to watch an SSL-protected session and glean a lot of information about what the user is doing, based on timing certain parts of the Web session and knowing how long it takes for part of a site to load. He also can tell whether a user is logged in on a given site and use a specific technique to log the user out so he can then watch the login operation and steal the credentials.

“When you look at it, what does SSL really offer? What this means is that for the average user, against a determined adversary, there really is no protection,” said Hansen, who presented his findings at the Black Hat conference here Thursday. “People give SSL and TLS a lot of credit, when it shouldn’t have any at all.”

SSL is the main transport security used by millions of Web sites to protect data being sent from browsers to Web servers. It’s been shown to be vulnerable to a number of different attacks, including several man-in-the-middle attacks, which could be used in conjunction with some of Hansen’s techniques to completely compromise a supposedly secure Web session.

“The most important thing is that if an attacker can map out the domain ahead of time, he can get a really good feel for how the site is built,” Hansen said. “If there’s a side channel, I can force them to precache some of the content on the page so that I don’t see that again when they reload the page. Then, the only thing you’re seeing are the things that are interesting to the attacker. You can map out the user’s flow around the site and the attacker can force the user to make an SSL connection to them so they can tell which SSL and HTTP headers are being sent in which direction. It’s about narrowing down the number of bytes that are interesting.”

As troubling as the problems that Hansen found are, he emphasized that they don’t mean that the sky is falling.

“You still need to be a man in the middle first and there are probably easier ways to attack people once you are, but there are a lot of issues here,” he said. “If there was better jitter and padding in SSL, a lof of this wouldn’t even be possible.”

Source

Security research firm Qualys is attempting to paint a detailed picture of SSL deployments and their shortcomings with a new, still under-development study that aims to deliver a deeper degree of information on the state of the SSL marketplace than what is currently known. Most industry intelligence on the subject thus far has come from Netcraft research reports and from vendor reports.

In its study, Qualys scanned 119 million domain names, but found that only 92 million were active. Approximately 12.4 million domains failed to resolve properly and 14.6 million failed to respond. Of the active domains that did respond, nearly 34 million responded to the Qualys scan on both port 80 and port 443. Port 80 is typically used for HTTP while port 443 is typically used for HTTPS-, SSL-secured Websites.

Digging a layer deeper into the active sites on Port 443, Ivan Ristic, director of engineering at Qualys, said in a Webcast that he found that only about 23 million of the sites were actually running SSL.

SSL certificates can be generated for any domain name. It is considered to be a best practice that the name on the SSL certificate matches the name of the domain on which the SSL certificate is being used, though Ristic’s research shows that’s not always the case.

“Only about 3.17 percent of the domain names matched,” Ristic said. “So we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside.”

Detecting invalid SSL certificates
In a preview of a talk set to be delivered at this summer’s Black Hat USA conference, Ristic explained that his company has had an SSL security-checking service available publicly for some time. However, the Qualys SSL checker required that users came to the site to check their own SSL status. With the new research conducted by Ristic, Qualys set about scanning the Internet to collect information on how sites are implementing SSL.

“For us, the question is: How exactly is SSL used on the Internet as a whole?” Ristic said during the Webcast. “Interestingly enough, as popular as SSL is, no one had made public the information about how it is used.”

According to VeriSign, there are currently approximately 193 million domain names. In terms of SSL, Netcraft reports that there are 1.5 million SSL certificates. Ristic decided to focus his research on the total number of .com, .net, .org, .biz, .us and .info domains, which total 119 million domain names in total.

Ristic explained that he built a virtual machine that was able to run 2,000 threads in parallel to scan those millions of domain names. The process took him two days at a speed of 1,000 servers scanned per second.

In response to a question from InternetNews.com about his testing hardware and software infrastructure, Ristic noted that the scanning software had been custom-written for the task.

“The hardware was nothing special — I’m using a virtual server in the cloud and it’s just a medium-sized box,” Ristic said. “The trick to why the tests are quick is that it’s only a couple of network packets that are being exchanged, and that’s enough to determine if the server on the other side is capable of supporting the protocol.”

As part of the complete report that he is working on, Ristic said that he’ll be doing a deeper analysis of 720,000 SSL certificates that he uncovered in his initial scan and considers valid. The plan is to collect up to 300 data points on each SSL server to better understand how the certificates are deployed and configured.

Source

The security appliance company is profitable and growing — its earnings last quarter were 17% higher than for the same quarter last year — but with the security appliances industry consolidating, it needs to grow faster, says Patrick Sweeney, vice president of product management for SonicWall. The company has $200 million in cash as well, he says.

If approved by shareholders, the deal will enable faster development of the company’s next big product push, called Super Massive, a jump to 10Gbit/s speeds for its unified threat management hardware with all the security features turned on, he says. “It’s important for us to grow as fast or faster than the market,” he says. “This will allow us to build a larger company a lot faster.”

Size is important because the industry is consolidating, he says, pointing to HP’s purchase of 3Com and its security devices division Tipping Point, making smaller companies more vulnerable.

As a listed company, SonicWall’s goals were constrained to ever increasing 90-day demands between fiscal reporting quarters, which limits longer term investments that can alter a company’s strategic course, he says.

SonicWall, which makes unified threat management, firewall, VPN and backup appliances as well as endpoint security, email security and antispam software, says the deal will buy out current shareholders for $11.50 per share in cash, which is 63 percent more than the stock is going for publicly. Stockholders still have to approve the deal, and that is expected by early in the fourth quarter of this year.

Source

An uninitialised buffer in the EVP_PKEY_verify_recover() function in version 1.0.0 can be exploited to make an invalid RSA key appear to be valid. Since very few applications have used this recently-introduced function, the scope of this problem is limited. The OpenSSL developers say that pkeyutl is currently one of the only OpenSSL tools to access this function.

Source

As I was logging into Gliffy today for the first time in a few years, I noticed that there were two buttons to submit the login form with: one for a ‘basic’ login and one for a ‘secure’ login. To me, a secure login in 2010 is a basic login. The people behind Gliffy however believe that protecting your login credentials is worth at least $5/mo to you.

In a business model that offers both free and paid accounts, I feel that a company should make you pay for added features, storage, or accessibility to data that you are using their site for. I, like most people, realize that ad-based sites aren’t the preferred option. A site like Gliffy allows for many areas to make users pay for ‘more’. The number of documents you are able to store, file upload size limits, the number of users allowed to access your files. With all of these major points of wanting to upgrade, why nickel-and-dime our security?

It’s appreciated whenever a company offers free service, of any magnitude. What’s not appreciated, however, is when a company feels that they should charge you to securely give your username and a password to a form. The sharing of data networks is only continuing to grow and as-such, a vast majority of web sites (reputable ones, at least) at the very least encrypt your login credentials. Whether they encrypt all data during your session is a whole different matter, but most can agree that protecting credentials is a general necessity.

This isn’t meant to be a launch point for ‘well SSL is useless anyways’. SSL for credential logins is useful in the vast majority of situations people actually deal with every day. At this point in the Internet and networking, not allowing someone to choose to login securely with personal credentials for a reputable and fairly well-known (for the context) company, is ridiculous.

Lastly, I am not complaining that the Gliffy site doesn’t run in SSL for all content, merely that an SSL login should be provided, free of charge, to anyone using their service. This is a standard practice for most web sites and Gliffy should step-up and do the right thing for everyone’s privacy.

The root in question was added by RSA several years ago, but when Mozilla recently contacted the company “to confirm current contact and audit information” for the root, RSA was unable to offer details about the status of the root, Johnathan Nightingale, director of Firefox Development, said in a Tuesday blog post.

This prompted some worries among Mozilla developers, who said that VeriSign also could not take ownership of the root. Root certificates are critical parts of browsers, as they are used to sign, or validate, the authenticity of other certificates, such SSL connections used to secure website communications.

“We expect every root in our program to have a clear and active owner, and failing to get that clarity from RSA, we moved to pull this root from the product,” Nightingale said. “RSA has since confirmed that this root is no longer needed and can be removed from the product. That clarity, while late, is welcome and confirms our original decision…We regularly check for roots whose audits have lapsed or for whom we don’t have an up-to-date point of contact — it’s part of keeping our root program healthy.”

The root certificate, RSA Security 1024 V3, also appears in Apple’s root store. A spokesperson for the computing giant could not be reached for comment on Wednesday.

Source

http://www.openssl.org/

The OpenSSL project team is pleased to announce the release of
version 1.0.0 of our open source toolkit for SSL/TLS. This new
OpenSSL version is a major release and incorporates many new
features as well as major fixes compared to 0.9.8n. For a complete
list of changes, please see http://www.openssl.org/source/exp/CHANGES .

The most significant changes are:

o RFC3280 path validation: sufficient to process PKITS tests.
o Integrated support for PVK files and keyblobs.
o Change default private key format to PKCS#8.
o CMS support: able to process all examples in RFC4134
o Streaming ASN1 encode support for PKCS#7 and CMS.
o Multiple signer and signer add support for PKCS#7 and CMS.
o ASN1 printing support.
o Whirlpool hash algorithm added.
o RFC3161 time stamp support.
o New generalised public key API supporting ENGINE based algorithms.
o New generalised public key API utilities.
o New ENGINE supporting GOST algorithms.
o SSL/TLS GOST ciphersuite support.
o PKCS#7 and CMS GOST support.
o RFC4279 PSK ciphersuite support.
o Supported points format extension for ECC ciphersuites.
o ecdsa-with-SHA224/256/384/512 signature types.
o dsa-with-SHA224 and dsa-with-SHA256 signature types.
o Opaque PRF Input TLS extension support.
o Updated time routines to avoid OS limitations.

We consider OpenSSL 1.0.0 to be the best version of OpenSSL available
and we strongly recommend that users of older versions upgrade as
soon as possible. OpenSSL 1.0.0 is available for download via HTTP
and FTP from the following master locations (you can find the various
FTP mirrors under http://www.openssl.org/source/mirror.html):

* http://www.openssl.org/source/
* ftp://ftp.openssl.org/source/

The distribution file name is:

o openssl-1.0.0.tar.gz
Size: 4010166
MD5 checksum: 89eaa86e25b2845f920ec00ae4c864ed
SHA1 checksum: 3f800ea9fa3da1c0f576d689be7dca3d55a4cb62

The checksums were calculated using the following commands:

openssl md5 openssl-1.0.0.tar.gz
openssl sha1 openssl-1.0.0.tar.gz

Yours,

The OpenSSL Project Team…

Mark J. Cox Nils Larsch Ulf Möller
Ralf S. Engelschall Ben Laurie Andy Polyakov
Dr. Stephen Henson Richard Levitte Geoff Thorpe
Lutz Jänicke Bodo Möller

Source

Affected versions depend on the C compiler used with OpenSSL:

- If ‘short’ is a 16-bit integer, this issue applies only to OpenSSL 0.9.8m.
- Otherwise, this issue applies to OpenSSL 0.9.8f through 0.9.8m.

Users of OpenSSL should update to the OpenSSL 0.9.8n release, which contains a
patch to correct this issue. If upgrading is not immediately possible, the
source code patch provided in this advisory should be applied.

Bodo Moeller and Adam Langley (Google) have identified the vulnerability
and prepared the fix.

Patch
—–

— ssl/s3_pkt.c 24 Jan 2010 13:52:38 -0000 1.57.2.9
+++ ssl/s3_pkt.c 24 Mar 2010 00:00:00 -0000
@@ -291,9 +291,9 @@
if (version != s->version)
{
SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_WRONG_VERSION_NUMBER);
- /* Send back error using their
- * version number :-) */
- s->version=version;
+ if ((s->version & 0xFF00) == (version & 0xFF00))
+ /* Send back error using their minor version number :-) */
+ s->version = (unsigned short)version;
al=SSL_AD_PROTOCOL_VERSION;
goto f_err;
}

This vulnerability is tracked as CVE-2010-0740.

Source

The bug in the OpenSSL cryptographic library is significant because the open-source package is used to protect sensitive data in countless applications and operating systems throughout the world. Although the attack technique is difficult to carry out, it could eventually be applied to a wide variety of devices, particularly media players and smartphones with anti-copying mechanisms.

“Wherever you need to verify the origin of a piece of software or a piece of information, those building blocks come in handy,” said Karsten Nohl, an independent security researcher who in unrelated attacks has broken encryption in widely used smartcards and cordless phones. “The OpenSSL library provides much more than just SSL.”

The scientists, from the University of Michigan’s electrical engineering and computer science departments, said the bug is easily fixed by applying cryptographic “salt” to an underlying error-checking algorithm. The additional randomization would make the attack unfeasible.

An OpenSSL official, who asked that his name not be published, said engineers are in the process of pushing out a patch and stressed the attack is difficult to carry out in real-world settings.

The university scientists found that they could deduce tiny pieces of a private key by injecting slight fluctuations in a device’s power supply as it was processing encrypted messages. In a little more than 100 hours, they were able to feed the device enough “transient faults” that they were able to assemble the entirety of its 1024-bit key.

“This is probably not as much of a threat to a server system as it is to a consumer device,” said Todd Austin, one of the scientists who devised the attack. “The place where this would be more applicable would be if you want to attack a Blu-ray player (where) you have an environment where someone is giving you a device that has a private key to protect intellectual property and you have physical access to the device.”

Servers, by contrast, would be much harder to attack because they are generally located in places that prevent people from manipulating their power supply. But that doesn’t mean they’re immune to such exploits. In events where a machine was overheating or otherwise experiencing power fluctuations, the vulnerability will cause servers to leak secret data that could be intercepted by attackers.

The scientists are also experimenting with the possibility of exploiting the bug using lasers or natural radiation sources, they said.

The attack is enabled by what the researchers described as a “severe vulnerability” in the OpenSSL innards that carry out authentication based on the RSA public key encryption algorithm. It resides in the so-called fixed window exponentiation algorithm of the open-source crypto library, which is used when errors arise. By triggering a single-bit error in a multiplication operation, the scientists were able to force OpenSSL to divulge 4 bits of the secret key.

Once they gathered about 8,800 malformed messages from the targeted device, they fed the data into an 81-machine cluster of 2.4 GHz Pentium-4 systems running a custom-designed algorithm. They applied the technique to an embedded hardware device consisting of a Sparc processor running a Linux operating system and were able to extract its 1024-bit private key in 104 hours.

The researchers said it may be possible to apply the method to other crypto libraries, such as one offered by the Mozilla Foundation.

Source

Developed as part of G-SEC’s investigation into the
“Secure SSL/TLS configuration Report 2010″ (to be
published) we developed this little tool.

“Harden SSL/TLS” hardens the default SSL/TLS settings of
Windows 2000,2003,2008,2008R2, XP,Vista,7. It allows to
remotely set SSL/TLS policies allowing or denying certain
ciphers/hashes or complete ciphersuites.

It took longer then I expected to create this tool, Windows
7 really strengthened the cryptosuites and introduced a new
way Windows handles SCHANNEL policies and required quite
some re-engineering. For instance, I had to create a mini
state engine just for the preferred cipher list.

Harden SSL/TLS allows setting policies with regards
to what ciphers and protocols are available to applications
that use SCHANNEL crypto interface. A lot of windows
applications do use this interface, for instance IIS, Google
Chrome as well as Apple Safari and many more.

By changing the settings you can indirectly control
what ciphers and protocols these applications are
allowed to use and stay compliant to whatever policies
you use.

Note: unfortunately neither chrome nor safari make use
of the new TLS 1.2 protocol that Windows 7 introduced
(hint hint). They both use SCHANNEL and just need to
add a parameter to the SCHANNEL initialization in
order to support it. (Let’s see who is first)

It allows to allow or deny:
· Hashes
· Keyexchange algorithms
· Protocols
· Ciphers & Ciphersuites
· Priority of preferred Ciphersuites

Advanced mode
· Re-enable ECC P521 mode on Windows7 and 2008R2
(P521 mode was available on Vista and 2008 but removed in
Windows7 and 2008R2)
· Enable TLS 1.2 support on IIS 7.5 (off by default)
· Set TLS Cache size and timeout

Download and Information:

http://blog.g-sec.lu/2010/02/harden-ssltls-tool-release.html

Documentation :

http://www.g-sec.lu/sslharden/documentation.pdf

Video :

http://www.g-sec.lu/sslharden/harde_ssl.swf

–

http://www.g-sec.lu

Thierry Zoller

Source