uncompiled.com

Symantec has completed the $1.28bn (£890m) acquisition of VeriSign’s identity and authentication business in a deal which will expand its web site authentication and fraud prevention capabilities.

The purchase will give Symantec VeriSign’s Secure Sockets Layer (SSL) and Code Signing Certificate services, the Managed Public Key Infrastructure services, the VeriSign Trust Seal, the VeriSign Identity Protection (VIP) authentication service and the VIP Fraud Detection service.

Symantec is now looking to incorporate VeriSign’s trusted check mark symbol in a new logo for itself and its Norton consumer security brand, set for a December release.

“Enterprises and consumers expect simple and secure access to information from any device, protection from identity fraud, and online experiences that are user friendly and hassle free,” said Enrique Salem, president and chief executive of Symantec.

“The combination of Symantec’s leading security solutions with VeriSign’s security products, services and recognition as the most trusted brand online, uniquely positions Symantec to drive the adoption of identity security and restore trust online.”

Integration efforts will include combining VeriSign’s SSL and client Public Key Infrastructure authentication services with Symantec Protection Center to provide a unified enterprise security management solution, said Symantec.

VeriSign’s identity security services will also be incorporated into Symantec’s data loss prevention solutions and Data Insight technology.

Source

Security expert Georgi Guninski has pointed out a security issue in the 1.0 branch of OpenSSL that potentially allows SSL servers to compromise clients. Apparently the hole can be exploited simply by sending a specially crafted certificate to the client, causing deallocated memory to be accessed in the ssl3_get_key_exchange function (in ssl\s3_clnt.c). While this usually only causes an application to crash, it can potentially also be exploited to execute injected code.

Guninski included a certificate and a flawed key for recreating the problem in the report he released on the Full Disclosure mailing list. When tested briefly by the The H’s associates at heise Security on an current Ubuntu 10.04 system with OpenSSL 0.9.8k, a certificate belonging to an RSA key of only 4006 bits in length (and where q is not prime) only produced a warning that the certificate was flawed.

As virtually none of the Linux distributions use OpenSSL 1.0.x, the hole is unlikely to create major concerns. An update has yet to be released by the OpenSSL developers, but the issue is already being discussed on the OpenSSL developer mailing list.

Source

Two researchers at the Black Hat conference in Las Vegas on Thursday exposed 24 ways hackers can hijack seemingly secure browser sessions.

Robert Hansen and Josh Sokol demonstrated methods attackers can use to take over users’ accounts or assume control of a website without the need for any exploits, due to the way browsers implement “HTTPS.” HTTPS, a combination of the Hypertext Transfer Protocol with the SSL/TLS Protocol, allows a website owner to encrypt a session using a digital certificate.

For any of the two dozen attacks to work, however, a criminal would have to have assumed control of a user’s computer via a man-in-the-middle (MITM) exploit, by which an attacker intercepts communications between two systems.

But the researchers wanted to show that HTTPS protection alone won’t stop bad things from happening.

For example, the pair detailed an attack known as “session fixation” that takes advantage of the fact that banks using HTTPS don’t change a user’s cookie after they login — they simply mark it as valid. As a result, an attacker with MITM control could visit the bank site ahead of the user and set the cookie, essentially logging in the crook as the legitimate user.

Another scenario, known as “delayed pop-up,” involves a user who visits a website, such as a bank, and clicks on a link to go the SSL-protected version of the site. This opens a second tab, but if the attacker has control of the first tab, he is able to change the other HTTPS tab to redirect users to malicious executables or authentication forms.

Still, the reliance on MITM makes the scenarios Hansen and Sokol demonstrated unlikely to happen on a widespread scale, they said.

“You’d have to be a very determined attacker,” Hansen said. “And determined attackers have a lot of other avenues for attack.”

He did say that while “the world is not crashing,” website owners and users should take the threats seriously as they have the potential to threaten secure electronic commerce. Potential mitigations include the browser makers offering tab, port and cookie sandboxing controls.

Hansen added that there are likely “hundreds” of other similar vulnerabilities.

Source

LAS VEGAS–A security researcher has found a slew of fundamental problems with the way that modern browsers are designed and built, leading to serious questions about the security of these applications and the way that they handle SSL sessions.

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

It should be no surprise that the SSL security certificate business is big business, considering how SSL certificates are seen as being on the frontlines of securing Web transactions against fraud. But new data suggests that SSL certificates are not all being configured correctly.

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

SonicWall directors have accepted a US$717 million offer to sell the company to a group headed by Thoma Bravo, a private equity investment firm, with the aim of growing the company faster and developing products quicker than it could as a listed company.

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

The OpenSSL developers have released versions 0.9.8o and 1.0.0a, fixing two security problems. A flaw in the ASN.1 parser can be exploited to write to invalid memory addresses using specially crafted “Cryptographic Message Syntax” (CMS) structures. The flaw potentially allows arbitrary code to be injected in order to compromise a system. CMS is not enabled by default in the 0.9.8 branch of OpenSSL, but it is enabled in the 1.0.0 branch.

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

Update: So as you can see from the comment section, Chris Kohlhardt, the CEO of Gliffy took the time to reply and set the record straight from their end. Their login process is SSL-enabled for all, despite their statement of “Secure SSL login” only for Premium accounts is apparently an error in… semantics? It’s not really up to me to figure out whether the person who wrote that site copy is unaware of what the difference between a ‘secure SSL login’ and ‘secure browsing’ is, but I’d at least say to get that changed and not expect consumers to view an HTML source to find out the truth.

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.

Mozilla has removed a deserted root certificate authority from its Firefox web browser after initially being unable to determine its current owner.

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

OpenSSL – The Open Source toolkit for SSL/TLS

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