Posts Tagged ‘Secure Sockets Layer’
Monday, June 9, 2014 @ 11:06 AM gHale
Widely used open source SSL/TLS cryptographic library, GnuTLS, is vulnerable to a buffer overflow vulnerability that could crash TLS clients or execute malicious code on underlying systems.
The GnuTLS library implements secure sockets layer (SSL) and transport layer security (TLS) protocols on computers, servers, and software to provide encrypted communications over insecure channels.
The bug (CVE-2014-3466), discovered by Joonas Kuorilehto of security firm Codenomicon, resides in the way GnuTLS parses the session ID from the server response during a TLS handshake, according to Kuorilehto’s report.
It does not check the length of session ID value in the ServerHello message, which allows a malicious server to send an excessively long value in order to execute buffer overflow. The issue could end up exploited by sending payload code from a malicious server to clients as they establish encrypted HTTPS connections.
This problem differs from Heartbleed, which could end up exploited from both sides i.e. Server (the computer connected to) or the Client (i.e. the computer that initiated the connection). The GnuTLS Remote Code Execution vulnerability will only work from the server to a connecting client.
Red Hat has already issued a patch for this vulnerability as “A flaw was found in the way GnuTLS parsed session ids from Server Hello packets of the TLS/SSL handshake.”
“A malicious server could use this flaw to send an excessively long session id value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code,” said the Bug Tracker blog
“The flaw is in read_server_hello() / _gnutls_read_server_hello(), where session_id_len is checked to not exceed incoming packet size, but not checked to ensure it does not exceed maximum session id length.”
Radare blog also published an in-depth technical analysis including the proof-of-concept of the this vulnerability, which shows the vulnerability can end up exploited by any threat actor to execute any type of malicious code. The GnuTLS project issued updated version 3.1.25, 3.2.15 and 3.3.3 in order to patch the vulnerability.
Thursday, March 6, 2014 @ 02:03 PM gHale
There is a new man-in-the-middle attack that goes against the cryptographic protocol TLS, used to encrypt online banking and shopping, and other sensitive connections, to thwart eavesdroppers, researchers said.
TheTriple Handshake attack can overcome key checks carried out to verify the identity of a user connecting to a server over a secure connection.
It is possible to for a malicious system to intercept a user’s login credential (a client certificate in this case) and masquerade as that victim with any server that also accepts the same credential, said researchers at the French National Institute for Research in Computer Science and Control (INRIA).
In addition, the attack has implications for the security of SSL (Secure Sockets Layer), the widely used predecessor to TLS (Transport Layer Security), the researchers said.
“We have discovered a new class of attacks against applications that rely on the TLS Internet Standard for securing their communications,” said the researchers Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet, Alfredo Pironti and Pierre-Yves Strub in a paper on the subject. “Essentially, if a user connects to a malicious website and presents a TLS client certificate, the malicious website can then impersonate the user at any other website that accepts the same TLS client certificate. The attacks work with all TLS and SSL versions, as well as the DTLS variant.”
Online websites and similar services typically use usernames and passwords rather than TLS client certificates to log users in. This limits the impact of the attack. In practice the flaw becomes more of a problem when it comes to logging into Wi-Fi access points.
“Variants of our attacks apply to specific scenarios of standard authentication protocols that rely on TLS, such as the PEAP Wi Fi authentication mechanism,” the researchers said, adding their exploit is similar to a previously uncovered cryptographic flaw – the 2009 Ray and Rex TLS renegotiation attack.
The researchers advocate short term application-level mitigations as well as long-term changes to the TLS protocol to strengthen the standard and safeguard its users against this latest attack and other assaults along the same lines.
“Let me stress that the attacks we found exploit a protocol-level issue, and not specific implementation bugs,” Pironti said. “We also propose short-term application-level mitigation, but we aim at getting the protocol fixed, which would solve the issue at its root.”
The French team have already notified major vendors of TLS software implementations (at Microsoft, Google and others) as well as the Internet Engineering Task Force (IETF) about their research. The researchers disclosed the attack and possible countermeasures at an IETF meeting in London on Tuesday night.
Click here for an outline of their research.
Thursday, December 6, 2012 @ 04:12 PM gHale
Mobile devices continue to strike fear in the hearts of security professionals and the news doesn’t get any better with the release of a new study showing mobile browsers are so unsafe that even experts are unable to detect when their smartphones have landed on potentially dangerous websites.
Like their counterparts for desktop platforms, mobile browsers incorporate a range of security and cryptographic tools to provide a secure Web-browsing experience.
However, in one critical area that informs user decisions — the incorporation of tiny graphical indicators in a browser’s URL field — all of the leading mobile browsers fail to meet security guidelines recommended by the World Wide Web Consortium (W3C) for browser safety, leaving even expert users with no way to determine if the websites they visit are real or imposter sites phishing for personal data, according to a study from Georgia Tech.
“We found vulnerabilities in all 10 of the mobile browsers we tested, which together account for more than 90 percent of the mobile browsers in use today in the United States,” said Patrick Traynor, assistant professor in Georgia Tech’s School of Computer Science. “The basic question we asked was, ‘Does this browser provide enough information for even an information-security expert to determine security standing?’ With all 10 of the leading browsers on the market today, the answer was no.”
The graphic icons at issue are called either SSL (“secure sockets layer”) or TLS (“transport layer security”) indicators, and they serve to alert users when their connection to the destination website is secure and the website they see is actually the site they intended to visit.
The tiny “lock” icon that typically appears in a desktop browser window when users are providing payment information in an online transaction is one example of an SSL indicator. Another is the “https” keyword that appears in the beginning of a desktop browser’s URL field.
W3C issued specific recommendations for how SSL indicators should go into a browser’s user interface, and for the most part, Traynor said, desktop browsers do a good job of following those recommendations. In mobile browsers, however, the guidelines are inconsistent at best and often not at all.
The principal reason for this, Traynor said, is the much smaller screen size with which designers of mobile browsers have to work. Often there simply isn’t room to incorporate SSL indicators in the same way as with desktop browsers. However, given that mobile devices will face more frequent attacks from cyber criminals, the vulnerability is almost sure to lead to increased cyber crime unless it ends up addressed.
“Research has shown that mobile browser users are three times more likely to access phishing sites than users of desktop browsers,” said Chaitrali Amrutkar, a Ph.D. student in the School of Computer Science and principal author of the paper that described the SSL research. “Is that all due to the lack of these SSL indicators? Probably not, but giving these tools a consistent and complete presence in mobile browsers would definitely help.”
Traynor and Amrutkar said the study, essentially a measurement analysis of the current state of visual security indicators in mobile browsers, is a necessary first step in developing a uniform set of security recommendations that can apply to mobile browsers.
“We understand the dilemma facing designers of mobile browsers, and it looks like all of them tried to do the best they could in balancing everything that has to fit within those small screens,” Traynor said. “But the fact is that all of them ended up doing something just a little different — and all inferior to desktop browsers. With a little coordination, we can do a better job and make mobile browsing a safer experience for all users.”
Thursday, September 1, 2011 @ 03:09 PM gHale
A Dutch Certificate Authority (CA) suffered a hack attack and web sites now face security breaches.
DigiNotar, issues SSL (Secure Sockets Layer) and EVSSL (Extended Validation) certificates, which Web browsers validate to ensure people are not visiting a fake website that is trying to appear legitimate.
DigiNotar sells these digital certificates to legitimate website owners. But DigiNotar issued a digital certificate for the google.com domain, a mistake that could allow a skilled attacker to intercept someone’s email.
Google said the fraudulent certificate targeted users in Iran, although a security feature in its Chrome browser detected the certificate, tipping off users with a warning.
DigiNotar, a subsidiary of a security company called Vasco Data Security International, issued a statement saying it discovered on July 19 during an audit its infrastructure that issues the certificates suffered a breach.
Attackers created fraudulent certificates for “several dozen” websites, but most were revoked after their discovery, said Jochem Binst, corporate communications director for Vasco. The company at first reported several dozen, now the number could go over 500.
But the digital certificate for google.com — issued July 10 — only went live Sunday, Binst said. In its statement, Vasco said the Dutch Computer Emergency Response Team notified them the certificate was still live. They finally revoked it Monday this week, Binst said.
Officials still don’t know how attackers breached DigiNotar’s certificate-issuing infrastructure or how long they had access, but an audit is under way.
“We are in the course of doing an extra audit and those findings will probably be known by the end of the week,” Binst said.
DigiNotar is halting sales of digital certificates as it investigates, Binst said. DigiNotar primarily sells its digital certificates to businesses in the Netherlands.
Those businesses will have a hard time over the next few days. Google, Mozilla and Microsoft have revoked or are in the process of revoking DigiNotar’s authority to vouch for its certificates. That means people who go to websites using those certificates will likely see a warning saying the website is untrusted and they should not access it.
Binst said DigiNotar is contacting its customers. One option to fix the problem is to have those websites switch over certificates issued by the Dutch government, although he could not say which agency would issue those replacement certificates. Another option, Binst said, is to approach the browser makers to make technical changes to honor its certificates.
Binst could not say how many customers DigiNotar has for its digital certificates, but Vasco said in its statement that the subsidiary’s revenue from issuing digital certificates was less than $144,000 for the first six months this year.