uncompiled.com

Computer scientists say they’ve discovered a “severe vulnerability” in the world’s most widely used software encryption package that allows them to retrieve a machine’s secret cryptographic key.

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

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

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

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

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

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

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

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

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

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

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

Source

============================================
TOOL: Harden SSL/TLS beta
OS: Windows (2000,XP,Seven,2003,2008,2008R2)
Requirement : .NET Framework 2.0
Author : Thierry Zoller for G-SEC Ltd.
============================================

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

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

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

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

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

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

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

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

Download and Information:

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

Documentation :

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

Video :

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

–

http://www.g-sec.lu

Thierry Zoller

Source

More than 300 Web sites are being pestered by infected computers that are part of the Pushdo botnet, according to security researchers.

The U.S. Federal Bureau of Investigation, Twitter, and PayPal are among the sites being hit, although it doesn’t appear the attacks are designed to knock the sites offline, said Steven Adair, of The Shadowserver Foundation, a group that tracks botnets.

Shadowserver was tipped off to the Pushdo issue by Joe Stewart, director of malware analysis at vendor SecureWorks.

Pushdo, which is also known as Pandex or Cutwail, has been around for about three years, according to a report from Trend Micro. Computers infected with Pushdo are used to send out spam, but the malware is capable of downloading other harmful code to a computer.

Pusho appears to have been recently updated to cause computers infected with it to make SSL (Secure Sockets Layer) connections to various Web sites. SSL is an encrypted protocol used to protect information exchanged.

The bots start to create an SSL connection and then disconnect, a process that is repeated, Adair said. Serving up SSL connections puts more of a burden on a Web site than HTTP connections, Adair said, but the traffic has been so sporadic that some large Web sites didn’t even notice.

“Despite how noisy it is, the traffic is still too infrequent and not large enough to really be seen as what we would think is an intentional DDOS attack,” Adair said in an e-mail exchange. “Much smaller botnets are capable of generating far more traffic and causing more of an impact to Web sites than what is being done with Pushdo.”

The traffic, however, is significant and results in large Web sites getting millions of hits across hundreds of thousands of IP (Internet Protocol) addresses. “This might be a big deal if you’re used to only getting a few hundred or thousands of hits a day or you don’t have unlimited bandwidth,” Adair wrote on Shadowserver’s blog.

One option for Web sites is to change their IP addresses, but that may only be a temporary fix. “We have also had numerous people write in offering assistance and feedback on ways to slow or stop these attacks,” Adair said. “We hope to put out an updated post that can help our system administrators associated with these Web sites soon.”

Source

Moxie Marlinspike, the man behind many SSL vulnerabilities/attacks has released an online WPA cracking service!

WPA Cracker is a cloud cracking service for penetration testers and network auditors who need to check the security of WPA-PSK protected wireless networks.
WPA-PSK networks are vulnerable to dictionary attacks, but running a respectable-sized dictionary over a WPA network handshake can take days or weeks. WPA Cracker gives you access to a 400CPU cluster that will run your network capture against a 135 million word dictionary created specifically for WPA passwords. While this job would take over 5 days on a contemporary dual-core PC, on our cluster it takes an average of 20 minutes, for only $17.

http://www.wpacracker.com/

US-CERT this week warned of a vulnerability that impacts a host of clientless SSL VPN products and could lead to bypassed authentication and other internet attacks.

Clientless SSL products provide web-based access to intranet sites, internal file shares and remote desktops, without needing to install a traditional VPN client.

Many of these products operate in a way that bypasses fundamental web browser domain-based security mechanisms, US-CERT said. Products from Cisco, Citrix, McAfee, Intel and a number of other vendors are affected.

The security mechanism that is bypassed is the same-origin policy, which is enforced by web browsers to prevent active content, such as JavaScript, hosted on one site from accessing or modifying data on a different site. Many clientless VPN products retrieve content from different sites and then present that content as coming from the SSL VPN, circumventing the same-origin restrictions.

Source

A Seattle computer security consultant says he’s developed a new way to exploit a recently disclosed bug in the SSL protocol, used to secure communications on the Internet. The attack, while difficult to execute, could give attackers a very powerful phishing attack.

Frank Heidt, CEO of Leviathan Security Group, says his “generic” proof-of-concept code could be used to attack a variety of Web sites. While the attack is extremely difficult to pull off — the hacker would first have to first pull off a man-in-the-middle attack, running code that compromises the victim’s network — it could have devastating consequences.

The attack exploits the SSL (Secure Sockets Layer) Authentication Gap bug, first disclosed on Nov. 5. One of the SSL bug’s discoverers, Marsh Ray at PhoneFactor, says he’s seen a demonstration of Heidt’s attack, and he’s convinced it could work. “He did show it to me and it’s the real deal,” Ray said.

The SSL Authentication flaw gives the attacker a way to change data being sent to the SSL server, but there’s still no way to read the information coming back. Heidt sends data that causes the SSL server to return a redirect message that then sends the Web browser to another page. He then uses that redirect message to move the victim to an insecure connection where the Web pages can be rewritten by Heidt’s computer before they are sent to the victim.

Source

The vulnerability in the design of the SSL/TLS protocol revealed earlier this month can apparently be used to carry out attacks in practice. On his blog, student Anil Kurmus reports that he was able to steal a Twitter password by using a man-in-the-middle attack. Until now it had been assumed that the problem was largely theoretical and would be made manifest only in very limited scenarios. The design weakness can be exploited by attackers to inject content into secure connections.

In his attack, Kurmus appended a test victim’s encrypted HTTPS request to his own Twitter request, effectively as a tweet. This does not allow the content of the packet to be viewed directly, but following decryption, the web server combines the two packets into one as a result of the TLS renegotiation vulnerability. In Kurmus’ test, this resulted in the victim’s HTTP request appearing as a tweet on Kurmus’ Twitter account with the victim’s user name and password visible in easily-decoded Base64 encoded form.

According to the report, Twitter introduced a fix last week which prevents exploitation of this vulnerability. Kurmus’ report omits specific details of how he triggered the TLS renegotiation in his attack, but there are several ways of achieving this. Using SSL client certificates as described in the original vulnerability report is just one possible approach.

Other web services in which an HTTP request containing the victim’s login details can be displayed as content, such as wikis, are in theory also affected by this problem. It would also be possible for an attacker to email himself a victim’s cookie via a webmail service.

The OpenSSL development team have responded to the problem by no longer allowing TLS renegotiation in version 0.9.8l. This can, however, result in some services no longer working properly. Numerous vendors, including Cisco and Juniper, have confirmed that their products are also vulnerable. The initial report on the problem focused primarily on the Apache and IIS web servers.

Source

A Swiss grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.

The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.

For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties.

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter’s servers, even though they were encrypted. He did it by injecting text that instructed Twitter’s application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.

Source

A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.

The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.

To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.

Source

Researchers say they’ve uncovered a flaw in the secure sockets layer protocol that allows attackers to inject text into encrypted traffic passing between two endpoints.

The vulnerability in the transport layer security protocol allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session, said Marsh Ray, a security researcher who discovered the bug. A typical SSL transaction may be broken into multiple sessions, providing the attacker ample opportunity to sneak password resets and other commands into communications believed to be cryptographically authenticated.

Practical attacks have been demonstrated against both the Apache and Microsoft IIS webservers communicating with a variety of client applications. A consortium of some of the world’s biggest technology companies have been meeting since late September to hash out a new industry standard that will fix the flaw. A draft is expected to be submitted on Thursday to the Internet Engineering Task Force.

Source