New DOS tool overloads SSL servers with ease

The DOS attack tool takes advantage of a feature in SSL that can be maliciously exploited to overload servers using a single laptop

A newly released denial-of-service (DOS) tool can be used to bring down SSL servers using an average laptop computer and a standard DSL connection.

Called THC-SSL-DOS, the tool was created by German hacking outfit The Hackers Choice (THC) and exploits a rarely used, but widely available, feature in the SSL protocol called SSL renegotiation.

[ Learn how to greatly reduce the threat of malicious attacks with InfoWorld's Insider Threat Deep Dive PDF special report. ]

This type of attack is not new. In fact, vendors have known about the issue since 2003 and, according to the THC, the method was used in last year's DOS attacks against MasterCard.

The hacking outfit decided to release the tool now because it has already been leaked online a couple of months ago. "We are hoping that the fishy security in SSL does not go unnoticed. The industry should step in to fix the problem so that citizens are safe and secure again," a THC member said.

It's worth pointing out that even without SSL renegotiation enabled, attackers can still use THC-SSL-DOS successfully against servers. However, such attacks would require more than a single laptop.

"It still works if SSL renegotiation is not supported but requires some modifications and more bots before an effect can be seen," the group noted. "Taking on larger server farms who make use of SSL load balancers required 20 average size laptops and about 120kbit/sec of traffic," it added.

This is not the first time when SSL renegotiation exposed servers to security risks. Back in November 2009, a Turkish grad student devised a proof-of-concept man-in-the-middle attack that exploited a vulnerability in this SSL feature to steal Twitter login credentials passed over secure connections. Read More...

THC SSL DoS/DDoS Tool Released For Download

THC-SSL-DOS is a tool to verify the performance of SSL. Establishing a secure SSL connection requires 15x more processing power on the server than on the client. THC-SSL-DOS exploits this asymmetric property by overloading the server and knocking it off the Internet. This problem affects all SSL implementations today. The vendors are aware of this problem since 2003 and the topic has been widely discussed.

This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection.

Usage

./thc-ssl-dos 127.3.133.7 443
Handshakes 0 [0.00 h/s], 0 Conn, 0 Err
Secure Renegotiation support: yes
Handshakes 0 [0.00 h/s], 97 Conn, 0 Err
Handshakes 68 [67.39 h/s], 97 Conn, 0 Err
Handshakes 148 [79.91 h/s], 97 Conn, 0 Err
Handshakes 228 [80.32 h/s], 100 Conn, 0 Err
Handshakes 308 [80.62 h/s], 100 Conn, 0 Err
Handshakes 390 [81.10 h/s], 100 Conn, 0 Err
Handshakes 470 [80.24 h/s], 100 Conn, 0 Err

Comparing flood DDoS vs. SSL-Exhaustion attack

A traditional flood DDoS attack cannot be mounted from a single DSL connection. This is because the bandwidth of a server is far superior to the bandwidth of a DSL connection: A DSL connection is not an equal opponent to challenge the bandwidth of a server.

This is turned upside down for THC-SSL-DOS: The processing capacity for SSL handshakes is far superior at the client side: A laptop on a DSL connection can challenge a server on a 30Gbit link. Traditional DDoS attacks based on flooding are sub optimal: Servers are prepared to handle large amount of traffic and clients are constantly sending requests to the server even when not under attack.

The SSL-handshake is only done at the beginning of a secure session and only if security is required. Servers are _not_ prepared to handle large amount of SSL Handshakes. The worst attack scenario is an SSL-Exhaustion attack mounted from thousands of clients (SSL-DDoS).

Tips & Tricks for Whitehats

1. The average server can do 300 handshakes per second. This would require 10-25% of your laptops CPU.
2. Use multiple hosts (SSL-DOS) if an SSL Accelerator is used.
3. Be smart in target acquisition: The HTTPS Port (443) is not always the best choice. Other SSL enabled ports are more unlikely to use an SSL Accelerator (like the POP3S, SMTPS, … or the secure database port).

Counter measurements
No real solutions exists. The following steps can mitigate (but not solve) the problem:

1. Disable SSL-Renegotiation
2. Invest into SSL Accelerator

Either of these countermeasures can be circumventing by modifying THC-SSL-DOS. A better solution is desireable. Somebody should fix this.

You can download THC-SSL-DOS here:

Windows: thc-ssl-dos-1.4-win-bin.zip

Linux: thc-ssl-dos-1.4.tar.gz

Or read more here. Read More...

Report: Smartphones will become a way to attack otherwise protected devices

Compromised smartphones will infect computers when they dock in much the same way malware gets onto laptops via thumb drives

Smartphones will become an increasing menace to network security that could drop malware onto protected devices when they dock to sync or plug into USB ports to charge, security experts say in a Georgia Tech report.

Compromised smartphones will infect computers they may plug into for otherwise legitimate reasons, much the same way malware such as Stuxnet found its way onto laptops via thumb drives, according to the "Emerging Cyber Threats Report 2012" (PDF) released at the Georgia Tech Cyber Security Summit 2011" today. It was presented by the Georgia Tech Information Security Center and Georgia Tech Research Institute. [ Stay ahead of advances in mobile technology with InfoWorld's Mobile Edge blog and Mobilize newsletter. ]

ONLINE SECURITY: Father of SSL says despite attacks it has lots of life left

The report warns that "mobile phones will be a new on-ramp to planting malware on more secure devices." The document cites an anonymous industry source saying that "... someone who just needs to charge his phone can introduce malware as soon as it's plugged into a computer within that location."

Other problems include the differences between laptop browsers and those used on smartphones. The latter display address bars fleetingly, leaving little time to observe the safety status of sites being visited, the report says. "If a user does click on a malicious link on a mobile browser," the report says, "it becomes easier to obfuscate the attack since the Web address bar is not visible."

Finding information about SSL certificates a site may be using may be difficult if the information is available through the browser at all, the researchers say.

Touch screens on smartphones may make users more susceptible to clicking on links that seem legitimate but mask malicious sites beneath them, which could lead to drive-by downloads of malware.

Patches and updates for smartphones are woefully infrequent, the report says. "While computers can be manually configured not to trust compromised certificates or can receive a software patch in a matter of days, it can take months to remediate the same threat on mobile devices -- leaving mobile users vulnerable in the meantime."

Meanwhile, the authors say that bot masters will find more ways to make money off their zombie machines beyond using them as spam or DDoS engines. For example, a downloader controlled by a bot master could infect machines with reconnaissance malware that profiles the user of the machine for marketing purposes. The information can be sold and resold until a legitimate business buys the information as part of a lead-generation effort, the report says.

Or alternatively, the zombies could be queried for personal technical details as a way to design a long-term stealthy attack to compromise data. Botnet operators will work more to create bot armies that they lease to others for whatever purpose they have in mind. "Infrastructure and information sharing will also occur more regularly between botnet operators and other malicious actors," the report says. Read More...

Secure web browsing cracked by BEAST

A pair of researchers have unveiled a serious new attack on web browser security.

The researchers used this week's Ekoparty security conference in Buenos Aires to unveil a new tool that attacks TLS and SSL, the cryptographic protocols used to establish secure web connections.

The ability to crack encrypted web traffic removes the safety net that protects you when you're doing sensitive online tasks like banking or using credit cards.
The tool, known as BEAST (Browser Exploit Against SSL/TLS), compromises TLS by exploiting a vulnerability that has been known about for years but which has been treated as a theoretical problem until now.

However, although researchers Thai Duong and Juliano Rizzo have significantly raised the stakes it's probably too early to start hoarding tins of beans and donning our tin foil hats.

Right now the attack can take up to half an hour to execute. Although the researchers have hinted that this can be significantly reduced the fact is that if you have the malicious nature, time and access required to execute this attack then there are probably easier ways to exercise your criminal ambitions.

Even when governments attack weapons manufacturers, they don't need to get any more high-tech then basic con tricks like spear-phishing.

The danger of BEASTly attacks against TLS has moved a little closer but we probably have enough time to react before it becomes practical.

A good start would be for browser and server vendors to pull their collective fingers out and start supporting versions 1.1 and 1.2 of TLS. Both of them have specific defences against this kind of attack but unfortunately support for them is poor.

Duong and Rizzo tipped off the major browser vendors about their findings months ago but so far the only response appears to have come from the folks at Chrome. A fix for the attack is currently under test in the development version of their browser.

If you run a web server and you're concerned you may want to take a look at switching them so that they prefer the rc4-sha cipher. It's widely supported and isn't vulnerable to this kind of attack.

Although the BEAST attack is targeted at browsers there are plenty of other applications that rely on TLS, not least mail servers. Although BEAST isn't targeted at them I'm sure it will have raised eyebrows and their vendors will be taking a keen interest. Keep an eye out for updates and advisories.

If you want to know more about how the attack actually works then I recommend you take a look at nickm's excellent and accessible write-up over at the Tor project.

nb : nakedsecurity.sophos

Read More...

Fixes in the Works For SSL Attack, But Support Lacking for Newer Versions of Protocol

With the release of the BEAST SSL attack research due tomorrow, researchers are beginning to take note of potential fixes and mitigations for the attack. One of the possibilities is moving to newer versions of TLS that are not vulnerable to the attack, but the problem is that there is precious little adoption of those newer versions.

Some of the browser vendors have been looking at possible remedies for the attack on TLS developed by Juliano Rizzo and Thai Duong, and Opera was the first to develop a fix for it. The company initially implemented the fix in its browser, but then discovered that it broke a small percentage of sites and did not push the fix into the final version of Opera. The default configuration of Opera isn't vulnerable to the new attack, but if users change some settings, the browser can become susceptible to the attack.

Rizzo and Duong's attack, which Rizzo will present at the Ekoparty conference on Friday, is aimed at TLS 1.0, which is an older version of the protocol, and the newer versions are not vulnerable. However, as Opera's own research found, the adoption of TLS 1.1 and 1.2 among Web sites is far too low to just make the switch in the browser. Opera found that just 0.25 percent of sites supports TLS 1.1 and 0.02 percent support version 1.2. TLS 1.0 is quite an old standard, and even versions 1.1 and 1.2 have been approved for several years now, but many of the more recent versions of the major browsers don't support the newer releases of TLS, which presents a problem for site operators who would like to upgrade. If their users can't handle TLS 1.1 or 1.2, upgrading could cost them customers.

For example, the latest version of Mozilla Firefox has the boxes for SSL 3.0 and TLS 1.0 checked by default and there is no option for users to enable support for newer versions of TLS. Internet Explorer 9 gives users the ability to enable support for TLS 1.1 and 1.2 in Internet Options under the Advanced tab. But, unless the site on the other end of the connection is using a newer version of the protocol as well, that doesn't do the user much good.

Opera isn't the only vendor who is working on a fix. Google also has been preparing a patch for its Chrome browser and the company has pushed that fix to its development channel already, officials say. The company is hoping to have the fix go through the typical process of moving to the beta channel and then the stable channel without having to push it out as an emergency fix.

A new report by security researcher Thierry Zoller that looked at browser support for various versions of the TLS protocol found that support for anything newer than TLS 1.0 is quite spotty. Also in the report, Zoller recommends that sites that use SSL drop support for SSL 2.0 and 3.0 and only support TLS 1.0 and later.

nb : threatpost Read More...

Researchers claim to have broken SSL/TLS encryption

Two security researchers claim to have found a way of breaking the SSL/TLS encryption that is widely used to guarantee the reliability and privacy of data exchanged between web browsers and servers.

The researchers, Thai Duong and Juliano Rizzo, are due to demonstrate their Browser Exploit Against SSL/TLS (Beast) at the Ekoparty security conference on Friday 23 September.

News of the Beast ahead of the demonstration has created a stir in the security community, according to Help Net Security.

The latest two versions (1.1 and 1.2) of the TLS cryptographic protocol are reportedly invulnerable to the exploit, but the majority of websites, VPNs and instant messaging services in operation use the vulnerable version 1.0 because of its compatibility with the widest range of other web technologies.

Beast consists of JavaScript code that works with a network sniffer to decrypt the cookies that carry user credentials to access accounts.

Unlike most published attacks against https that focus on the authenticity property of SSL, Beast attacks the confidentiality of the protocol, Duong told The Register.

Duong and Rizzo claim that Beast implements the first attack that actually decrypts https requests.

The researchers claim they have been working with browser and SSL suppliers since May, but every fix proposed so far has proved to be incompatible with some existing SSL applications.

Philip Hoyer, director of Strategy Solutions at ActivIdentity, said if the claims are true, authentication should be done as an ever-changing and one-time password, so even if the attacker sees a password, it always changes and hence cannot be guessed for the next authentication.

This can be achieved by many techniques, he said, both using one-time password (OTP) technology and public key infrastructure (PKI) using a challenge response.

"But this won't help to a level that is needed since the attacker can then simply read and hijack your session. So the only true defence from fraudulent transactions is to sign the transaction or part of the transaction data so that the attacker cannot inject bogus material," said Hoyer.

This means effectively using a token with a pin pad to enter transaction details or signing the transaction using a PKI certificate.

"This allows a cryptographic signature that the attacker can't forge and is intrinsically linked to the transaction data that is independent from the transport security and cannot be forged by the spying attacker," he said.

Hoyer believes this is the only way to stay secure until the infrastructure has been upgraded from TLS V1.0.

nb : computerweekly

Read More...

Security failures could erode public trust in the Internet

Recent attacks could reverberate and undercut the public's faith that the Internet is a trustworthy medium for doing business

There's big trouble in the world of information security, and yet it seems that only a handful of us techies have noticed. What's the problem, you ask? Well, there are actually several problems, but they're all related to one very important issue: public trust. Let's take a look.

The first problem cropped up a few months ago when some miscreants succeeded in compromising a pile of RSA's SecureID tokens, rendering many devices vulnerable to serious attack. That attack caused RSA to undertake a costly replacement of many tokens for its customers. It was also reported to be the key enabler for additional attacks against some of those customers.

[ Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

More recently, there have been a few attacks against some commercial certificate authorities (CA) such as DigiNotar in the Netherlands. That one resulted in the attackers generating hundreds of forged SSL certificates purporting to be from Microsoft, Google, and many others.

What do these things have in common, and why should we be so concerned about them? They erode the confidence of some pretty important security infrastructures. In the cases above -- which are just a few among many we've seen lately -- the products involved are used by thousands and thousands of companies and individuals.

The situation with SSL certificates is even more dire -- they are used by millions of people. Indeed, every browser on the planet that can connect to an encrypted site uses SSL, and the certificates form the hierarchical basis of that trust.

SSL certificates need to be signed by a CA. Our browsers and operating systems come with a set of trusted "root CAs." Any SSL certificate signed by a trusted root CA is itself trusted.

So the problem when someone is able to successfully attack a CA is that our basis of trust is compromised, making possible a man-in-the-middle attack, among other things. And that's exactly what reportedly happened to hundreds or thousands of Google Mail customers in Iran. Their "trusted" connections to Google Mail have potentially (or actually) been compromised, exposing their log-in credentials to the attackers -- or worse.

There are some short-term responses that need to be done, of course, and by and large, they are being properly pursued. The DigiNotar CA organization has now effectively been disabled for any computer that has been updated by Microsoft, Apple, etc. Any SSL certificate signed by DigiNotar should now be unworkable.

But that's really not where my primary concern lies. I have strong confidence that the various operating system and browser vendors will quickly patch their products. It's the longer-term issues that are more troubling to me.

My concern is that public trust in vital infrastructures is being severely eroded. That public trust is the real victim of these attacks. If people and companies feel they can no longer use their systems securely, the trickle-down impact can be enormous. It's not likely something we'll notice immediately. The patching and such will be taken care of in an orderly manner. The trust erosion is something that will play out over time, and it can have a crippling effect on our systems. I hope I'm proved wrong on this.

Because of this, operators of public trust systems such as CAs have a greater burden of security that they simply must practice. Things like patch management, secure configurations and application security are considered to be important to normal companies, but they're even more important for systems involving the public trust.

As consumers of these products, we must not accept anything less than extreme care with these public trust systems. Failures there are costly in long-term ways. I've even seen some declarations of "the death of SSL" as a result of these recent attacks.

So what sorts of things should we ensure are in place with our public trust infrastructures? Certainly, they should all follow best-practice approaches in all their security processes and procedures. They should also undergo mandatory and detailed audits of their security. Personally, I want the results of those audits to be openly available.

Now, when I say "audits" in this context, I am talking about significant scrutiny, down to source-code analysis of the applications in use.

I know that much of what I'm saying here is already in place for registered CAs and such, but clearly there have been failures in the recent attacks I cite. I hope that in the response to these attacks the root causes of the failures are carefully studied and analyzed -- and the results become publicized so that we may all benefit from that knowledge.

We all want our systems to be sufficiently trustworthy so that we can put our most important business systems on the Internet. To continue to do that, our security infrastructures simply must be the best of the best. Failing to do that will exact a high price on the public trust -- one that the economies of the world shouldn't have to overcome in today's harsh climate. We must do better.

With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.

nb : infowordl Read More...

Microsoft fixes SSL 'kill switch' blooper

The company has re-released an update for Windows XP and Windows Server 2003 after it left machines unprotected last week

Microsoft re-released an update today for Windows XP to correct a snafu that left users vulnerable to potential "man-in-the-middle" attacks for most of last week.

Monday's update addressed a gaffe introduced last week when Microsoft blocked six additional root certificates issued by DigiNotar that were cross-signed by a pair of other CAs (certificate authorities).

[ Get all the details you need on deploying and using Windows 7 in the InfoWorld editors' 21-page Windows 7 Deep Dive PDF special report. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]

Servers run by Dutch CA DigiNotar were hacked starting in June, and attackers stole more than 500 SSL (secure socket layer) certificates, including many used by the Dutch government.

SSL certificates are used by websites and browsers to identify a site as legitimate -- that gmail.com or hotmail.com are actually what they claim -- and illegally-obtained certificates can be abused to disguise unauthorized domains using "man-in-the-middle" attacks to snoop on digital communications and harvest account credentials.

One certificate stolen from DigiNotar was used to spy on 300,000 Iranians for about a month this summer.

Today, Microsoft admitted that the update it shipped to Windows XP and Server 2003 users last Tuesday was flawed.

"The versions...for Windows XP and for Windows Server 2003 contained only the latest six digital certificates cross-signed by GTE and Entrust," said Microsoft in a revised support document . "These versions of the update did not contain the digital certificates that were included in [earlier updates]."

The earlier update, delivered by Microsoft on Sept. 6, blocked five DigiNotar root certificates.

"If you installed update 2616676 and had not already installed update 2607712 or update 2524375, your system would not have been protected from the use of fraudulent digital certificates," Microsoft admitted.

The re-released update for XP and Server 2003 has been added to Windows Update, Microsoft said. Customers who do not have Automatic Updates enabled should manually download and install the new version of the DigiNotar blocker.
Windows Vista, Windows 7, Server 2008, and Server 2008 R2 were not affected by the update goof, said Microsoft.

nb : infoworld Read More...

New Attack Breaks Confidentiality Model of SSL, Allows Theft of Encrypted Cookies

Two researchers have developed a new attack on TLS 1.0/SSL 3.0 that enables them to decrypt client requests on the fly and hijack supposedly confidential sessions with sensitive sites such as online banking, e-commerce and payment sites. The attack breaks the confidentiality model of the protocol and is the first known exploitation of a long-known flaw in TLS, potentially affecting the security of transactions on millions of sites.

The attack, developed by Juliano Rizzo and Thai Duong, will be presented at the Ekoparty conference in Argentina on Friday, and, unlike many other attacks on TLS and SSL, it has nothing to do with the certificate trust model in the protocol. Instead, the researchers have developed a tool called BEAST that enables them to grab and decrypt HTTPS cookies from active user sessions. The attack can even decrypt cookies that are marked HTTPS only from sites that use HTTP Strict Transport Security, which forces browsers to communicate over TLS/SSL when it's available.

The researchers use what's known as a block-wise chosen-plaintext attack against the AES encryption algorithm that's used in TLS/SSL.  In order to execute their attack, Rizzo and Duong use BEAST (Browser Exploit Against SSL/TLS) against a victim who is on a network on which they have a man-in-the-middle position. Once a victim visits a high-value site, such as PayPal, that uses TLS 1.0, and logs in and receives a cookie, they inject the client-side BEAST code into the victim's browser. This can be done through the use of an iframe ad or just loading the BEAST JavaScript into the victim's browser.

After the BEAST agent is loaded, the second part of the tool, a network sniffer, looks for active TLS connections and then grabs and decrypts the HTTPS cookie, enabling the attacker to hijack the victim's session with that site. Once that encrypted connection with the site is established, the victim can move off to another tab or do other things on the machine and the attack will still work. The attack forces the browser to load pages from the target site, and the tool then decrypts the first part of the request to the Web server, which includes the secure cookie. The researchers have the ability to decrypt those cookies from within SSL sessions, which essentially negates the confidentiality promise of the protocol.

The decryption process is fast enough that it's likely imperceptible users, and the researchers said that in a targeted attack, they likely could steal the cookie from a specific site within five minutes of loading the tool. Rizzo and Duong said that their attack exploits a vulnerability in the TLS1.0 protocol that has been known for quite some time, but was thought to be unexploitable.

"It is worth noting that the vulnerability that BEAST exploits has been presented since the very first version of SSL. Most people in the crypto and security community have concluded that it is non-exploitable, that's why it has been largely ignored for many years. Our work has two contributions," Duong said in an email interview. "We introduce a practical and efficient plaintext-recovery attack for that vulnerability. It's an enhancement of something crypto people call 'block-wise chosen-plaintext attack'. We present one application the attack: BEAST. BEAST focuses on SSL implementations on browsers which is HTTPS. BEAST works for most major browsers and websites."

The researchers said that the browser-based attack is just one variant. They said they also could implement a similar attack against other services that use SSL, such as instant-messaging clients or VPNs.

"While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests," Duong said. "While fixing the authenticity vulnerabilities may require a new trust model, fixing the vulnerability that BEAST exploits may require a major change to the protocol itself. Actually we have worked with browser and SSL vendors since early May, and every single proposed fix is incompatible with some existing SSL applications."

Rizzo and Duong are well-known in the security world for the research last year, also presented at Ekoparty, on the padding oracle attack on ASP.NET applications. That research prompted an emergency out-of-band patch from Microsoft. Opera already has implemented a fix for the TLS attack, and the researchers have been in touch with the other major browser vendors, but it's not clear when their fixes will be available.

"Browser vendors are implementing a workaround to stop this attack but the real solution is switching to a new protocol," Rizzo said.

nb : threatpost Read More...

Symantec cloud-based service seeks out 'rogue certificates'

The Symantec Certificate Intelligence Center keeps track of SSL server certificates used by an organization

Symantec this week introduced what it calls the Symantec Certificate Intelligence Center, a cloud-based service that works with an on-premises software component to keep track of SSL server certificates used by an organization.

"Every SSL certificate comes with a shelf life, as they expire in one, two or three years," says Amar Doshi, Symantec senior manager, product management. Symantec Certificate Intelligence Center lets IT managers track both public Web-facing and internally-used certificates in order to act before these certificates expire. The service is similar to one offered by competitor Venafi, he says.

[ The Web browser is your portal to the world -- as well as the conduit that lets in many security threats. InfoWorld's expert contributors show you how to secure your Web browsers in this "Web Browser Security Deep Dive" PDF guide. ]

[ See also: HP's "Secure Boardroom" gives execs online view of organization's security posture]
In addition, Symantec's cloud-based service, working in conjunction with the on-premises component, which is available based on Red Hat Linux or VMware-based virtual appliance, can scan to detect so-called "rogue certificates," Doshi says.

Rogue certificates have been discovered in corporate networks because someone at a company went and got them from a certificate authority that was not the usual source, or sometimes this has even been done maliciously. The bottom line is the certificate isn't officially recorded as in use by the business. The certificate-scanning service would be able to seek them out and report back on them, he says.

Symantec last year acquired the VeriSign trust services group for over $1 billion. The Symantec Certificate Intelligence Center service, now in beta, is the first new major product/service roll-out since the time of the acquisition.

nb : infoworld Read More...

Email Spam - Using DKIM Verification for analysis

A few days ago I received a spam email from my friend Jack on my personal Gmail account. The email came from his Yahoo! Mail account and looked in every way legitimate, except that it had no subject and contained only a link. The recipient list, unlike many spam bulk emails, wasn't even in alphabetical order.

About an hour later I received another email from the same friend, this time sending a legitimate bulk email to multiple recipients apologizing for spamming them.

Email spam coming from your account is embarrassing, and in all cases the first thing you should do is change your password because the most likely cause of spam email being sent from your account is that your email password credentials were stolen.

Was His Email Account Hacked?

Jack, who I contacted for more details, at first refused to believe that his password was compromised, until I laid out two possible reasons why spam had been sent out from his account and let him decide which was more likely:

1. Yahoo!'s private key had been stolen and used to sign spam emails.
2. His Yahoo! email password, which he most likely uses on multiple Web sites, was somehow phished or stolen.

Being the smart friend that he is, Jack went with option number 2.

DKIM Signatures

Let me share how I came to my conclusion and how DomainKeys Identified Mail (DKIM) verification can be used in analysis to verify that the email sent came from Yahoo!, was not forged, and that his credentials were used to send the email.



Figure 1: Spam Email - click this link to view the original email with headers removed for privacy reasons.

For the purposes of this blog post, I'm going to focus less on what happens to the user when they click on the URL, and more on how we can determine whether the email was sent from Yahoo! using the credentials of the user in question ( I will state that Websense had the URL above categorized into Web and Email Spam as it's a Fake Canadian Pharmaceutical website).

When you look at an email, much like a Web page, there is more than meets the eye on the details behind that email. Gmail allows you to view the email as we see it above or in its original form, which has more details than the average person would ever want to see. Here is a snippet:

Figure2 : Spam Email snippet in original form with personal details removed

One interesting header in the email is the header called the DKIM signature:



The DKIM signature is a signature used by the SMTP receiver of an email to verify that it came from the server it claims to come from and that the message hasn't been tampered with.

DKIM Algorithm

In this case Gmail received a message from Yahoo!, looked at the DKIM signature, and applied the following algorithm:

1. Took a SHA-256 as the cryptographic hash of the message.
2. Signed SHA-256 hash using RSA as the public key encryption scheme.
3. Encoded the encrypted hash using Base64.

So, for someone to send an email claiming to originate from Yahoo! and pass through a server that checks the DKIM signature, they would have to obtain the private key that Yahoo! uses for signing email messages from Yahoo! mail servers.

Verifying DKIM Signatures

Let's manually verify the DKIM signature to make sure it came from Yahoo!.

To do this we have to retrieve Yahoo!'s public key. To retrieve DKIM public keys the SMTP receiver uses DNS and looks at the TXT resource record type.
Using the s and d fields in the DKIM signature, which stands for the selector, we're going to make a manual DNS query for the TEXT resource record type for a host in the form: s._domainkey.d

s1024._domainkey.yahoo.com is the host we'll want to do the DNS look up the public key.

We can programmatically do this with a PERL using a set of scripts I co-wrote with my colleague David Saunders. The first script will pull the public key from the DNS request:


./get_dkim_key.pl s1024._domainkey.yahoo.com
host: s1024._domainkey.yahoo.com key: k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/xhy+1xtj4RkdV7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB; n=A 1024 bit key;
Figure 3: Script to fetch Yahoo! DKIM public key - full script source code can be found here

As you can see, the script above fetches the DKIM public key which allows us to verify the message. To accomplish this we could use PERL's Crypt::OpenSSL::DSA or various other libraries and languages, but instead we're going to use a CPAN module Mail::DKIM::Verifier against the initial message that includes the DKIM signature and all lines below to verify whether the message is valid and hasn't been tampered with. Mail::DKIM::Verifier will even download the public key so you don't have to fetch it explicitly. Here is a script you can use for verification of an email message that includes a DKIM signature:


./dkim_verify.pl message.txt
file: message.txt
pass
message.txt passed DKIM validation
Figure 4: DKIM verification script - full script source code can be found here

Conclusion

OK, so let's tie this all together. We received a SPAM email and wanted to verify that it came from Yahoo! as opposed to an open relay or a server claiming to be Yahoo!. The email message contained a DKIM signature, which we used to verify the DNS domain, the email sender, and the message integrity. Using the provided scripts, we verified this information, which led us to conclude that:

1. The email message was sent from Yahoo!.
2. The headers, including who it was sent from, were not forged.

All of this leads us to the conclusion that the person's email account that the spam email was sent from was most likely compromised by stolen password credentials. This isn't to say that digital certificates can't be stolen or replaced, this can happen, e.g. DigiNotar CA, but these types of occurrences are rare.

Back to my friend Jack, a smart technical guy who probably still doesn't understand how his credentials were stolen. Upon questioning Jack, he disclosed his password to me, which wasn't one I'd consider easy to brute force, but added that he uses that password on multiple Web sites and had recently signed up for about 4 different sites using that password where he used his email address as his username.

My advice to everyone is never use your email address password anywhere else but for your email account, and especially not on sites where your user name is your email address and your password is the password you use for that email address. You should realize that Web site databases get compromised all the time, so whether Jack's credentials were stolen because he was unknowingly phished, his computer had a keylogger on it, or one of the sites he registered for using his email address and email address password stole it, we'll never know. The important thing is that after such an incident to change the password to your email account.

DKIM signatures are used by all major Web-based email providers, including Yahoo!, Gmail, Microsoft Live, etc. If you see a DKIM signature, you can verify the DNS domain of an email sender and the message integrity by using the PERL scripts linked in this blog.

nb : community.websense Read More...

Mozilla Asks Firefox CAs to Audit Security Systems in Wake of DigiNotar Hack

Already having revoked trust in the root certificates issued by DigiNotar, Mozilla is taking steps to avoid having to repeat that process with any other certificate authority trusted by Firefox, asking all of the CAs involved in the root program to conduct audits of their PKIs and verify that two-factor authentication and other safeguards are in place to protect against the issuance of rogue certificates.

Mozilla officials have notified all of the CAs involved in the organization's trusted root program for Firefox that they need to perform the audits and other required actions within the next eight days and send the results to Mozilla. The message, also posted to the Mozilla developer security policy group on Google, sends a clear message that Mozilla officials have little interest in seeing a rerun of the DigiNotar episode with another certificate authority.

"Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates," Kathleen Wilson, owner of the Mozilla CA certificates module, said in the message. "Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve."

In addition to requiring that all trusted CAs perform an audit of their PKIs and look for signs of a compromise, Mozilla also is asking the CAs to confirm that they have two-factor authentication in place on all systems from which certificates can be issued; compile a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have
cross-signed; ensure that they automatic blocks in place for issuing certificates for high-value domains such as Google and Yahoo, which were targeted by the DigiNotar attacker; and for each of the third-party CAs or RAs, make sure that there are technical controls in place to limit their ability to issue certificates to only companies that they have confirmed that they do business with, or send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operation.

The request by Mozilla comes just a few days after the organization moved to revoke trust in all of DigiNotar's certificates in the wake of the compromise of the company's CA system by an attacker who was able to issue more than 500 rogue SSL certificates to himself. Some of the certificates were issued for high-profile domains such as *.google.com, cia.gov, addons.mozilla.org and others. That revocation rendered all of the certificates issued by DigiNotar to any site invalid for Firefox users.

The way that Mozilla made the changes in Firefox 6.0.2 is a little obscure. DigiNotar root certificates still are present in the browser's list of certificates, but when a user clicks on one of them and then clicks on Edit Trust, all of the options are un-checked by default. That means that none of the certificates by default is trusted by Firefox for mail, sites or software, but users can still edit that setting and check whichever boxes they choose.

Now, Mozilla officials are hoping to head off another such incident before it occurs by requiring all of the CAs trusted by Firefox to inspect their own systems and ensure that they have the proper security controls in place to help prevent a similar compromise. GlobalSign, one of the larger CAs in the industry, is in the middle of an investigation of its own, sparked by a message from the DigiNotar attacker saying that he also had penetrated GlobalSign's network, as well as the infrastructures of three other unnamed CAs.

nb : threatpost Read More...

Certificate hacks: PKI didn't fail us, humans did

After latest attack, GlobalSign stopped issuing SSL certificates. But the real problem is that few pay attention to warnings anyway

With the high likelihood that GlobalSign has been hacked, this brings to at least three the number of popular public PKI certification authorities (CAs) attacked in recent months by a single hacker. The other CAs are Comodo and DigiNotar.

The computer security world is aflutter because hundreds of bogus digital certificates have been issued. "It's a massive failure of PKI," they say. "It proves that there's too much trust spread around," say others.

But it's hard for me to get worked up about any public CA or PKI compromise. Here's why: Almost nobody pays serious attention to digital certificate warning messages in the first place.

I've yet to see the person who, when presented with a certificate error, didn't continue on and visit the website they were trying to access. Most users are simply annoyed by digital certificate warning messages. How dare they get in the way of a quick-loading Web page!

It's not just mom and granddad who are ignoring digital certificate warnings. A few years ago, a survey revealed that the more users knew about digital certificates and PKI, the more likely they were to ignore the warnings.

Part of the problem is that for as long as public PKI has been in existence -- nearly two decades -- it has tended to be implemented poorly. Websites with SSL certificates are notorious for having mistakes in their certificates. Mostly they have incorrect host names, where the subject name does not match the host name being contacted -- but certificates are often expired or have other x.509 mistakes. I attended a Black Hat Las Vegas 2010 conference on the subject where Ivan Ristic, directory of engineering at Qualys, revealed that the majority of websites using SSL certificates had errors.

Qualys found 22.65 million SSL-enabled websites and hosts on the Internet (out of hundreds of millions of websites). Only 720,000 had SSL certificates with a valid name match. Only 28 percent of the most popular SSL websites had a proper name, although 70 percent had digital certificates that were linked to a trusted CA. That's good. But 28 percent were untrusted, and 4 percent had trust chains that could not be verified.
Moreover, Qualys said more than 2 percent of the 22.65 million sites were suspicious. More than 137,000 certs were expired, 96,000 were self-signed, and more than 1,000 were revoked (but still being used).

Twenty-one thousand had invalid digital signatures, and more than 57,000 had unknown CAs. Ninety-nine digital certificates had known bad keys left over from the Debian random number generator vulnerability, which was found and fixed more than a year before.

I'm sure that these statistics have improved over the last year, but if only 3 percent of SSL-enabled sites (720,000 divided by 22.65 million) had a correct and valid SSL certificate (including only 28 percent of popular websites), can we really ask end-users to rely on public PKI?

Don't get me wrong: I'm sad anytime I hear that a CA is hacked. CAs have heavy, tight security around the digital certificates that can issue other certificates. Most are protected by hardware security modules (HSMs), which usually require smart cards, USB tokens, or some other physical security device. In fact, it usually takes multiple physical tokens (each attached to different people) in order to access the important digital certificates. HSMs should be used by any company with a PKI, but especially by CAs.

The Comodo hacker referenced above talks about being thwarted by an HSM. My guess is that the other compromised CAs were either not using HSMs or were not using them appropriately.

The bottom line is that PKI didn't fail us. Its mathematical beauty and potential assurance is something rare in the computer security world. If run correctly, it would greatly benefit our online world. But as with most ongoing security risks, human nature ruins the promise.

nb : infoworld

 

Read More...

Apple Mum On Plans To Protect Users From Diginotar SSL Hack

Apple is keeping mum about when - or if - it will blacklist SSL certificates more than a week after other browser makers moved to break trust with the disgraced Dutch certificate authority Diginotar.

With each new day revealing more about the extent of the breach, experts warn that Apple is leaving users of the company's Safari Web Browser and mobile devices vulnerable to man in the middle attacks.

Apple's Safari Web browser and iOS mobile devices have not been updated to reflect the breach at Diginotar. That means that Websites using fraudulent certificates issued by the compromised certificate authority wouldn't be treated as "high risk" by Safari or iOS-based devices like the iPhone and iPad. Apple did not not responded to multiple requests for comments on its plans to address the Diginotar compromise from Threatpost.

Competing browser vendors including Microsoft, Google and The Mozilla Foundation moved to break trust with Diginotar's compromised certificate authorities almost immediately after word of a fraudulent certificate for Google.com issued by Diginotar broke on August 27th. Both companies have taken additional steps since then to expand the reach of their bans as more information about the extent of the breach has been made public. Specialty browser makers like The Tor Project have responded in a similar fashion.

Not so, Apple, which hasn't issued an update to its Mac OSX or iOS mobile operating systems, nor its Safari Web browser to address the compromise.  Nor has Apple given its tens of millions of users any concrete advice on how to protect themselves from man in the middle attacks using rogue Diginotar-issued certificates in the absence of a vendor patch. Some advice has trickled online. Coriolis Systems, an independent software firm that created the iPartition and iDefrag programs for Apple's Mac operating system, published instructions on disabling the DigiNotar root CA on their Mac systems manually, though it was subsequently revealed that doing so wouldn't entirely protect users from man in the middle attacks. The plog ps-enable has issued more exacting instructions to completely revoke trust in Diginotar from the Mac OS X keychain, the Mac's built-in password and certificate management system. However, Apple has neither endorsed nor refuted those manual workarounds.

That has left Mac and iOS users scrambling for answers on how to protect themselves. "Basically, until Apple either releases a security update with this CA cert removed, or adds a way for me to remove it myself, nobody is allowed to use iPads or iPhones for any company-related purpose at work," wrote a user with the handle John Simpson on an Apple support forum.

Roel Schouwenberg, a senior security analyst at Kaspersky Lab, said that the delay is puzzling, but that Apple was similarly slow to respond to the breach of Comodo, another certificate authority, in March.
"It's very surprising Apple isn't just going out and fixing these issues. Especially when you consider the fix should be easy and security can be leveraged as a differentiator," Schouwenberg said.

He said the delay may be linked to problems revoking EV (or "extended verification") SSL certificates in OSX. Whatever the case, he said the company's lack of communication about when or if a fix is coming is inexcusable. "If there is a technical reason for their slow response to these issues they should communicate it. Either way, their silence is not acceptable. It's all the more reason not to use Safari."

nb : threatpost Read More...

Researcher raps Apple for not blocking stolen SSL certificates

Apple is 'dragging its feet' by not matching rivals such as Microsoft and Google in barring access to sites secured with suspect DigiNotar certificates

A security researcher criticized Apple for what he called "foot dragging" over the DigiNotar certificate fiasco, and urged the company to quickly update Mac OS X to protect users.

"We're looking at some very serious issues [about trust on the Web] and it doesn't help matters when Apple is dragging its feet," said Paul Henry, a security and forensics analyst with Arizona-based Lumension.

[ Also on InfoWorld: Debacle deepens for hacked SSL certificates issuer. | Find out how to block the viruses, worms, and other malware that threaten your business, with hands-on advice from InfoWorld's expert contributors in InfoWorld's "Malware Deep Dive" PDF guide. ]

Unlike Microsoft, which updated Windows Tuesday to block all SSL (secure socket layer) certificates issued by DigiNotar, Apple has not updated Mac OS X to do the same.

DigiNotar, one of hundreds of firms authorized to issue digital certificates that authenticate a website's identity, admitted on Aug. 30 that its servers were compromised weeks earlier. A report made public Monday said that hackers had acquired 531 certificates, including many used by the Dutch government, and that DigiNotar was unaware of the intrusion for weeks.

Because almost all the people who were routed to a site secured with one of the stolen certificates were from Iran, many experts suspect that the DigiNotar hack was sponsored or encouraged by the Iranian government, which could use them to spy on its citizens.

Microsoft isn't the only software maker to block all DigiNotar certificates: Google, Mozilla, and Opera have also issued new versions of their browsers -- Chrome, Firefox, and Opera -- to completely, or in Opera's case, partially prevent users from reaching websites secured with a DigiNotar certificate.
Users of Safari on Mac OS X, however, remain at risk to possible "man-in-the-middle" attacks based on the fraudulently obtained certificates.

And that rubbed Henry the wrong way. "Mac users have been left hanging in the wind," Henry said.
Because Safari relies on the underlying operating system to tell it which certificates have been revoked or banned entirely, Apple must update Mac OS X. The Windows edition of Safari, which has a negligible share of the browser market, taps Windows' certificate list: That version is safe to use once Microsoft's Tuesday patch is applied.

Henry admitted he wasn't surprised by the fact that Apple was odd-man out.
"No, I'm not, not after it took them a month to respond to the Comodo issue," Henry said, referring to a smaller-scale hack of another certificate authority last March.

Then, Apple updated Mac OS X on April 14, nearly a month after Comodo discovered the intrusion and began notifying browser makers. Microsoft had patched Windows to block the stolen Comodo certificates on March 23, while Google and Mozilla had even earlier.

The DigiNotar hack, however, was larger -- criminals acquired only nine certificates from Comodo -- and more serious in that the Dutch government relied on DigiNotar to secure its websites.

And then there are the boasts made by an unidentified hacker who has claimed responsibility for both the Comodo and DigiNotar breaches.

On Monday, that hacker -- known only as "Comodohacker" -- also asserted that he had penetrated four other CAs, or certificate authorities, including GlobalSign, a U.S.-based CA much more widely used than DigiNotar.

Tuesday, GlobalSign suspended certificate sales and said it had launched an investigation into Comodohacker's claims. A day later the New Hampshire company said it had hired Fox-IT, the forensics firm that is still digging into the DigiNotar hack for the Dutch government.

If Comodohacker's claims are accurate, and there are other CAs besides DigiNotar that have issued unauthorized SSL certificates, Apple's sluggishness is even more inexcusable, Henry said.

"We may be looking at the tip of the iceberg," said Henry. "If there are four other CAs [involved] as this guy claims, we could be in a hell of a mess in the next few months. We'll be playing catch-up, but that seems to be more difficult for Apple than for Microsoft, or Google and Mozilla."
But Henry didn't limit his criticism to Apple.

"What about smartphones ?" he asked. "I'm not aware of a single carrier or vendor that has pushed out a browser update for this."

Neither Google nor Apple have said anything about plans for updating Android or iOS to follow the road taken by most desktop browsers. The companies declined to comment Tuesday for a story written by IDG News Service reporter Robert McMillan. (Like Computerworld, IDG News is part of IDG.)

According to Web metrics company Net Applications, about three-out-of-four Mac OS X users run Safari as their primary browser.

Until Apple updates Mac OS X, users should browse with Chrome or Firefox, Henry said. Neither requires Mac OS X to be updated to block all DigiNotar certificates.

nb : infoworld Read More...

Are Some Certificate Authorities Too Big To Fail?

In the wake of this weekend's revelations of the seriousness of the attack on certificate authority DigiNotar, security experts have renewed criticism of the Internet's digital certificate infrastructure, with some wondering if larger certificate authorities (CAs) might be too big to fail.

DigiNotar's network had significant security weaknesses that allowed an attacker to issue an unknown number of untraceable certificates, a report by Dutch security firm Fox-IT found. The situation has led the Dutch government to take over operations of the CA, and major browser vendors to patch their products, breaking the trust their software has of secure-sockets layer (SSL) certificates issued by DigiNotar.

Revoking Diginotar’s authority was necessary because the company failed to secure its infrastructure, allowing an unknown number of certificates to be created, says Moxie Marlinspike, chief technology officer of startup mobile security firm Whisper Systems. The result will likely be that DigiNotar will not survive as a certificate authority.

"It's not a simple matter of removing certificates from a database, because they're not in any databases," says Marlinspike, who presented an alternative approach to the current SSL infrastructure last month at DEFCON. "We may never track them all down."

While revoking trust in Diginotar may help bring that crisis to a close, Marlinspike is among a large number of security researchers who worry that larger firms such as Comodo or VeriSign may likewise be vulnerable.  Unlike Diginotar, those  larger certificate authorities may be “too big to fail” – forcing browser makers to keep them on their lists of trusted issuers out of fear of the disruption that blacklisting them would cause.

In March, certificate authority Comodo acknowledged that an attacker had been able to issue at least nine certificates for major domains, such as Google and Yahoo. However, because of the limited nature of the breach, browser makers decided only to revoke the fraudulent certificates.

Yet it is unclear whether a more significant breach would have resulted in Comodo losing its authority, says Peter Gutmann, a researcher in computer science at the University of Auckland.

"Once you've issued enough (certificates), the browser vendors won't pull your CA cert any more because it would affect too many people," Gutmann says. "This is what saved Comodo. In Diginotar's case they were small enough that the browser vendors could pull their certs."

Mozilla justified its decision to rescind trust in DigiNotar by noting that the extent of the breach is still unknown, that DigiNotar failed to notify the public in a timely manner, and that attacks using the certificates have been document in the wild, Johnathan Nightingale, Director of Firefox Engineering, stated in a post on Friday.

"The integrity of the SSL system cannot be maintained in secrecy," Nightingale wrote. "Incidents like this one demonstrate the need for active, immediate and comprehensive communication between CAs and software vendors to keep our collective users safe online."

Comodo argues that it avoided that kind of “worst case” scenario because it had a diverse set of defenses in place to limit the breach.

As certificate authorities grow, so does their responsibility to provide better security, he said. "Larger CAs should have more resources for monitoring, detecting and reacting quickly to these kind of attacks," said Melih Abdulhayoglu, CEO of Comodo. "If you remember Comodo reacted within minutes and provided transparency to the world in a timely manner."

Security researchers, however, argue that the best defense against a breach at a certificate authority is for browser makers to find other ways to ensure online safety.

"I might say that concentrating all risk in a single, failure-prone mechanism that has been shown to have zero effect in stopping the bad guys  is a really, really bad idea," says the University of Auckland's Gutmann.

Part of the problem is that attacks on third-party trust providers  such as Comodo, RSA and DigiNotar are a new trend, says Jeff Hudson, CEO of Venafi, a maker of certificate management software.  As security professionals focus on the problem, better policies will be put in place that will mitigate the threat of a major breach at a large CA.

Rather than place total trust in a CA, for example, users in the future might be able to decide who to trust or have a sliding scale of risk. A valid certificate, brand-name domain and valid domain-name record would be positive factors. A certificate issued by a compromised CA, for example, a suspicious DNS record, or just-issued certificate would be negative factors.

For now, however, companies that rely on SSL certificates for their business need to be prepared for the worst, Hudson says.

"Right now, the state of preparedness for failure is dismal," he says. "People have to recognize this and be ready. You have to know who your trust providers are, where you assets are, and be ready to swap out a provider's certificates in hours."

nb : threatpost Read More...

GlobalSign Stops Issuing Certs As It Investigates Claims of Compromise

GlobalSign, a major certificate authority that was named by the hacker who has claimed credit for the DigiNotar hack as another CA he has compromised, has stopped issuing certificates for the time being while it investigates the claims and determines whether its network has in fact been compromised. It also has hired Fox-IT, the same company that investigated the attack at DigiNotar, to perform the audit of its systems.

The company said on Tuesday that it made the decision after seeing the message posted by the attacker known as Comodohacker on Pastebin, in which he said that he had compromised four other high-profile CAs in addition to DigiNotar, explicitly naming GlobalSign as one of them.

"On Sep 5th 2011 the individual/group previously confirmed to have hacked several Comodo resellers, claimed responsibility for the recent DigiNotar hack. In his message posted on Pastebin, he also referred to having access to 4 further high profile Certificate Authorities, and named GlobalSign as one of the 4," GlobalSign said in a statement.

"GlobalSign takes this claim very seriously and is currently investigating. As a responsible CA, we have decided to temporarily cease issuance of all Certificates until the investigation is complete. We will post updates as frequently as possible."

GlobalSign officials said on Wednesday that the company has retained Fox-IT, a Dutch security firm, to help conduct the investigation into a possible breach of its system.

In his messages on Pastebin posted Tuesday, Comodohacker said that he had attacked DigiNotar in retaliation for the Srebrenica massacre in 1995 and that he had also compromised four other CAs and still had the ability to issue himself all manner of certificates from them. In one message, the attacker said that despite Microsoft's claims to the contrary, he still had the ability to send updates from the Windows Update domain. That domain is one of the ones for which he had obtained a certificate from DigiNotar.

"I'm able to issue windows update, Microsoft's statement about Windows Update and that I can't issue such update is totally false! I already reversed ENTIRE windows update protocol, how it reads XMLs via SSL which includes URL, KB no, SHA-1 hash of file for each update, how it verifies that downloaded file is signed using WinVerifyTrust API, and... Simply I can issue updates via windows update!" the message said in part.

Microsoft has issued an update for Windows users that revokes the trust for all of the DigiNotar root certificates, effectively making all of the certificates issued by the company untrusted in Windows.

 nb : threatpost Read More...

DigiNotar certificates are pulled, but not on smartphones

Neither Google nor Apple have announced plans to revoke certificates issued by DigiNotar in their smartphone OSes

Browser makers have generally been quick to react to the computer compromise at digital certificate issuer DigiNotar, but that hasn't been the case for all mobile phone makers.

On Tuesday neither Google nor Apple would comment on whether they plan to revoke certificates issued by DigiNotar for Android or the iPhone, even as desktop software makers pulled the plug on the Dutch company's certificates.

[ Also on InfoWorld: Debacle deepens for hacked SSL certificates issuer. | iPhone, BlackBerry, or Android? Whatever handheld you use or manage, turn to InfoWorld for the latest developments. Subscribe to InfoWorld's Mobilize newsletter today. ]

Apple hasn't said anything about the DigiNotar situation since it was disclosed last week, but Google was quick to revoke the company's certificates for its Chrome browser last week. Its silence Tuesday spoke to the complexity of its situation as both a victim of the attacks and a provider of the software that can thwart them. The problem is that Google's Android phones are updated via mobile phone carriers, companies that are typically much slower to issue patches than PC software vendors such as Microsoft.

Google needs to work carefully with carriers before they can push out patches, said Marsh Ray, a senior software engineer with online authentication vendor PhoneFactor. "What if the carrier's only payment method is a Web page using a certificate signed by DigiNotar?" he said in an instant message interview. "It would be disaster if Google pushed such an update blindly."

Developers on the unofficial community Android distribution, Cyanogenmod, expressed similar reservations in their discussion forum. Worried about the possible fallout, they were initially reluctant to push out an update that revoked DigiNotar's certificates, but they changed their mind as the seriousness of the situation became clear.

Apple issues its patches directly to iPhone users, but it too must be sure to keep its carrier partners happy.
The lack of patches raises questions for mobile phone users in Iran, who may not be able to tell who they should trust on the Internet. Iranian users were the target of the DigiNotar hack, and as many as 300,000 of them have been directed to fake websites that used the bogus certificates, forensic auditors investigating the incident reported Monday.

The digital break-in seems to have been a data-gathering expedition, designed to steal Gmail messages and other information.

In fact, the hackers who broke into DigiNotar issued hundreds of digital certificates, including one for Google.com, which allowed them to take a first step in tricking Internet users into believing that one of their servers actually belonged to Google. The second step is to take control of the network's Domain Name System (DNS) and direct users to the fake site whenever they type in the Google.com address.

Microsoft's Windows Phone software does not include DigiNotar in its list of trusted certificate authorities and that appears to be the case on at least some BlackBerry phones as well. As was the case with their smart-phone competitors, neither Microsoft nor Research In Motion could answer questions on this topic Tuesday.

Roel Schouwenberg, a security researcher with antivirus vendor Kaspersky Lab is distrurbed by Google's silence, in particular, on the matter, because Google was one of the first companies to patch its Web browser. "The fact that google on the one hand has been very proactive while at the same time keeping radio silence about any update for Android is very worrisome," he said.

He said that the fact that Google must rely on mobile carriers to push out its patches could become a bigger problem as more attacks against phones surface. "Can you imagine if HP or Dell laptops received Windows updates one or two months after they were published for the general public?"

nb : infoworld Read More...

Debacle deepens for hacked SSL certificates issuer

Report indicates widespread compromise of DigiNotar's infrastructure and questions industry's response to breaches

 

The attack on DigiNotar, an issuer of SSL certificates, appears more serious than originally thought. A report by the company hired to analyze the breach raised its estimate of the number of fraudulently created certificates and found substantial security weaknesses in Diginotar's infrastructure.

The report by Dutch security firm Fox-IT (PDF) found at least 531 certificates had been fraudulently created by an intruder into their systems, an increase from last week's estimate of more than 270. The attacker gained administration rights to firm's domain server, which managed all of DigiNotar's certificate infrastructure, a significant network weakness, the report stated.

"All CA [certificate authority] servers were members of one Windows domain, which made it possible to access them all using one obtained user/password combination," the report stated. "The password was not very strong and could easily be brute-forced."

More than 300,000 unique IP addresses -- almost entirely from Iran -- validated a fraudulent certificate issued for Google's domain. Each time a browser encounters a new certificate, the software checks its validity with DigiNotar. The fact that nearly all the validation checks came from Iran could indicate that the nation's government may have been involved in the attack. The Dutch government is currently investigating the possibility.

The breach of DigiNotar and its aftermath has caused security experts to question the capability of the SSL certificate infrastructure -- responsible for issuing and verifying signatures used to secure online communications and transactions -- to respond to major security events. Major browser makers, including Google and Microsoft, have issued patches that will invalidate all certificates issue by DigiNotar. Yet the impact of the breach goes beyond just browsers: Certificates were issued for Microsoft's Windows Update mechanism and Google's Android code signatures.

Add to that the uncertainty regarding the breach and the industry will feel the effects of the attack for months, if not longer.

"With some 500 authorities out there globally, it's hard to believe Diginotar is the only compromised CA out there," Roel Schouwenberg, senior researcher for security firm Kaspersky, said in a blog post. "DigiNotar will quite likely go out of business. This should serve as a very strong message for CAs to go public with any breach."

On Monday, the hacker that claimed responsibility for breaching certificate authority Comodo, posted an online statement taking credit for the DigiNotar hack. While the timing -- a statement coming much later than the attack and coinciding with the issuance of the Fox-IT report -- suggested mere braggadocio, details found by the security firm corroborated the hacker's claims. Specifically, a specialized script intended to exfiltrate certificates also included a statement taunting DigiNotar.

"In the text, the hacker left his fingerprint: Janam Fadaye Rahbar," the report stated. "The same text was found in the Comodo hack in March of this year."

The Dutch government has taken over operations of the certificate authority, which is a subsidiary of security firm VASCO, after declaring the company's authentication infrastructure untrusted.

nb : infoworld Read More...

GlobalSign stops issuing SSL certificates in response to Iranian hacker

 

Earlier today a person calling himself ComodoHacker made a submission to text posting site Pastebin.com. Similar to a previous post by ComodoHacker it is fair to call it a bit of a bragging rant.


Last March ComodoHacker claimed responsibility for the first attack against a certificate authority that resulted in bogus SSL certificates being issued in the wild.

In addition to claiming his attacks are far more sophisticated than Stuxnet and distancing himself from the Iranian government, he also claims to have compromised four other certificate authorities, including GlobalSign.

GlobalSign, the fifth largest certificate issuer according to NetCraft, responded to this news by immediately ceasing any further signing of certificates while they investigate.

Their response is interesting. While we don't know if they have been compromised (and arguably, neither do they) they are making a tough choice that is what we should expect from organizations whose business models rely on trust.

It's possible the accusations are simply from an anonymous raving lunatic. Yet they could be true, and rather than put the greater internet community at risk, GlobalSign is forgoing some revenue out of an abundance of caution.

That's great news. Let's hope that the accusations are false and everything is safe and secure at GlobalSign and the other three unnamed victims.

While I have argued for a long time that the certificate system is fragile and arguably broken, I'd rather not have two examples in one week to support my arguments.

nb : nakedsecurity.sophos Read More...