ISSSource White Papers

Posts Tagged ‘Secure Sockets Layer’

Friday, April 24, 2015 @ 05:04 PM gHale

A bug in an older version of a widely used networking library for iOS and OS X can end up exploited to decrypt the secure traffic from almost 1,000 iOS apps, allowing an attacker access to vital user information.

Build 2.5.1 of open source AFNetworking ended up affected by a security vulnerability that disables SSL (secure sockets layer) certificate validation, permitting someone to intercept the connection and read the encrypted information in plain text.

Attack Trend: Fileless Malware
Ransomware Focuses on Outdated Plug-Ins
Malware Goes Invisible
New Ransomware Hits the Street

The security flaw ended up patched in late March, but not all developers integrated the updated code into their apps, leaving their users exposed, especially those using the older versions.

Research from analytics firm SourceDNA created fingerprints for tracking down the free apps that contain AFNetworking 2.5.1 and discovered about 1,000 products did not move to the safer version of the library.

The faulty release of AFNetworking is included in software from major developers, such as Yahoo (Yahoo Finance 2.3.2) and Microsoft (OneDrive 5.1).

Their apps, however, updated to new versions that rely on a secure variant of the networking library, so users should simply install the latest revision.

On the other hand, there are other developers who have not made the switch and whose users may become victims. Two of them are (build 3.3.2 and 3.3.3) and Citrix (OpenVoice Audio Conferencing 1.4.0 and 1.5.1).

To help users and developers identify the hazardous products, SourceDNA released a service that checks if the apps from a developer are vulnerable.

According to SourceDNA, the number of users impacted amounts to millions. Developers have started to address the risk and released updates for their products, so clients should be able to install the new, risk-free revisions.

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.

Patches Issued for Apache Tomcat
After False Start, Apache Struts Fixed
DoS Risk with Apache Tomcat Servers
DDoS Attacks Break Records

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.

Routers Hit in DNS Hijack
Hole in Cisco Small Biz Routers
Backdoor Found in Routers
D-Link Patches Router Bugs

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.

Monday, April 22, 2013 @ 09:04 AM gHale

Thirteen popular home and small office routers contain security problems that could allow a hacker to snoop or modify network traffic, new research said.

All of the routers tested by Independent Security Evaluators (ISE), a security consultancy based in Baltimore, MD, could end up taken over if the hacker had access credentials. The tested products came from Linksys, Belkin, Netgear, Verizon and D-Link.

Backdoor Found on Router
Moxa Mitigates Router Hole
Router Vulnerability Unveiled
Junos OS Open to Attacks

All of the router models evaluated ran their company’s latest firmware and ended up tested with their default, out-of-the-box configurations. Consumers have few options for mitigating the attacks, ISE said in its report.

“Successful mitigation often requires a level of sophistication and skill beyond that of the average user,” ISE said.

Compromised routers are valuable to hackers, since they can intercept the traffic of anyone on that network. If the traffic is unencrypted, the attacker can view it.

Man-in-the-middle attacks can let a hacker launch more sophisticated attacks on all users in the router’s domain, ISE said. Hackers can perform attacks such as sniffing and rerouting non-SSL (Secure Sockets Layer) traffic, tampering with DNS (Domain Name System) settings and conducting distributed denial-of-service attacks.

ISPs deploying large numbers of vulnerable routers could also give hackers a way into their own core infrastructure, ISE wrote.

ISE listed a few of the routers it studied, writing that it has notified vendors and worked in some cases on mitigations. It did not list product details for five of the routers, presumably because patches are not ready for release.

The consultancy divided the attacks into those which required an attacker to be on the same network and those on networks that could suffer a remote attack. Two routers from Belkin, the N300 and N900, were vulnerable to a remote attack that did not require the hacker to have authentication credentials.

All of the named products were vulnerable to an authenticated attack if the hacker was on the same network and had login credentials or access to a victim who had an active session on the particular network.

Those products were the Linksys WRT310v2, Netgear’s WNDR4700, TP-Link’s WR1043N, Verizon’s FiOS Actiontec MI424WR-GEN3I, D-Link’s DIR865L and Belkin’s N300, N900 and F5D8236-4 v2 models.

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.

BYOD Coming to Plant Floor
App on iPhone Insecure
Beware of False Browser Updates
Printers Provide Backdoor

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.”

Monday, August 13, 2012 @ 06:08 PM gHale

Companies or organizations now have a guide to help prepare for the risks posed by a security breach that affects certificate authorities (CAs).

The bulletin, a result of the collaboration between National Institute of Standards and Technology’s (NIST) Information Technology Laboratory (ITL) and the EKCM solutions provider, is not only meant to alert, but also to advise government and private agencies on what must happen in case certificates end up fraudulently issued. The advisory covers pre- and post-incident responses.

Security Firm Updates Key Leak
Rogue SSL Certificate Plan Proposed
NASA Investigates Compromise
U.S. Jams Taliban, Yemen Frequencies

In the past few years, digital certificates, their issuers and private keys have become a tempting target for cyber criminals, since these elements can allow them to gain unauthorized access to the sensitive information.

“Certificate authorities have increasingly become targets for sophisticated cyber attacks, particularly as the use of digital certificates for Secure Sockets Layer (SSL) has become widespread,” said Paul Turner, vice president of products and strategy at Venafi.

“Recent attacks on CAs make it imperative that organizations ensure they are using secure CAs, and are prepared to respond to CA compromises and the issuance of fraudulent certificates.”

Large organizations may use up to tens of thousands of certificates and encryption keys to secure their communications and they need to be aware of the fact misplacing any one of them could have devastating consequences.

In order to mitigate the risks posed by an incident that affects a CA, organizations must secure their CAs, they must establish a proper inventory of all the certificates they utilize (and a separate inventory for trusted anchors), identify certificate replacement procedures, and seek out backup sources for the rapid acquisition of new certificates.

“Because certificates are typically installed and managed by individual administrators in disparate departments, most organizations and executives are not aware of their dependence on certificates for security,” Turner added.

“Nor are they aware of the significant disruption to business operations that would result if they had to replace all affected certificates following a CA compromise.

“If enterprises are not prepared to respond to a CA compromise,” Turner said, “they have overlooked business continuity planning that could prevent extended downtime for a majority of their applications and systems.”

Tuesday, December 20, 2011 @ 06:12 PM gHale

A consortium of companies published a set of security practices they want all web authentication authorities to follow for their secure sockets layer (SSL) certificates for browsers and other software.

The baseline requirements, published this week by the Certification Authority/Browser (CAB) Forum, should prevent security breaches that compromise the tangled web of trust that forms the underpinning of the SSL certificate system. Its release follows years of mismanagement by individual certificate authorities permitted to issue credentials that are trusted by web browsers. Most notable is this year’s breach of DigiNotar, which led to the issuance of a fraudulent certificate used to snoop on 300,000 Gmail users in Iran.

Looking for a SSL Fix
Targeted Attacks on Rise
Compromise: When to Revoke Certificates
Microsoft Fixes SSL Miscue
DigiNotar Out as CA Provider

The four dozen or so members of the CAB Forum still have a way to go, since their requirements are meaningless unless the software makers who place their trust in the authorities mandate them.

And it’s not yet clear when that will come to pass. Of five browser makers queried, only Opera has committed to make compliance with the requirements a condition for including an authority’s root certificate in its software. A Mozilla official, meanwhile, said the requirements would be a part of the discussions among developers in online forums.

A Microsoft statement said the company “will work with the industry Auditors and Certificate authorities to get the new guidelines factored into the Microsoft Root Program.” A Google spokesman said Chrome trusts whatever CAs have trust in the underlying operating system. Apple did not respond.

As the terms suggest, the baseline requirements would serve as a set of industry practices each CA would need to follow to remain in good standing. Among other things, they would require them to “develop, implement, and maintain a security plan” to prevent the types of breaches that hit DigiNotar. The guidelines also mandate the reporting of breaches and the revocation of any fraudulently issued certificates that resulted, and require the use of certificates with RSA signing keys of 1024 bits or higher.

As useful as each requirement is, this week’s release only underscores the problems with the SSL system. With some 650 entities around the world authorized to issue certificates trusted by Internet Explorer, Chrome, Firefox, and other browsers, all it takes is the incompetence or malfeasance of one of them to bring the entire system down. Even if the requirements become a condition adopted by all browser makers, it’s not clear they have the will or the ability to adequately enforce the measures.

Tuesday, December 6, 2011 @ 06:12 PM gHale

To improve the security of the Secure Sockets Layer (SSL) encryption protocol that millions of websites use to protect communications against eavesdropping and counterfeiting, Google security researchers are looking at an overhaul.

The changes would fix a structural flaw that allows any one of the more than 600 bodies authorized to issue valid digital certificates to generate a website credential without the permission of the underlying domain name holder.

Targeted Attacks on Rise
Compromise: When to Revoke Certificates
Microsoft Fixes SSL Miscue
DigiNotar Out as CA Provider

The consequences of fraudulently issued certificates came to light in late August when hackers pierced the defenses of Netherlands-based DigiNotar and minted bogus certificates for Google and other high-profile websites.

One of the fraudulent credentials, for Google mail, was used to snoop on as many as 300,000 users, most of them from Iran.

Under changes proposed by Google security researchers Ben Laurie and Adam Langley, all certificate authorities would have to publish the cryptographic details of every website certificate to a publicly accessible log cryptographically signed to guarantee its accuracy. The overhaul, they said, should make it impossible – or at least much more difficult – for certificates to go out without the knowledge of the domain name holder.

“We believe that this design will have a significant, positive impact on an important part of the internet security and that it’s deployable,” Langley said. “We also believe that any design that shares those two properties ends up looking a lot like it.”

Some of the ideas overlap with recommendations recently published by the Electronic Frontier Foundation for improving the security of SSL.

While few disagree that SSL in its current form is broken, finding agreement on a way to fix the fragile certificate authority infrastructure has been difficult. Indeed, within hours of Laurie and Langley’s plan going public, critics were already saying it was unworkable. Among the complaints was the idea it would require the divulging of information considered proprietary in the fiercely competitive market for SSL certificates.

“I assume that CAs wouldn’t agree to provide their entire customer data to the public (and competition),” Eddy Nigg, COO and CTO of StartCom, the Israeli-based operator of StartSSL. He held out a voluntary set of baseline requirements recently adopted by the CA/Browser Forum as a more effective fix. Members of the forum hope to make the requirements mandatory for all CAs.

Nigg also said Laurie and Langley’s proposal could place significant technical burdens on website operators and browser makers. One or more authorities would have to be established to compile the lists around the clock and make them available to millions of users each time they access an SSL-protected page, and both activities would require considerable bandwidth and processing resources to be done properly.

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.

Breach: More SCADA System Holes
Compliance Does Not Mean Secure
ICS, SCADA Security Boot Camp
SCADA Hacking via Search Engines

DigiNotar sells these digital certificates to legitimate website owners. But DigiNotar issued a digital certificate for the 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 — 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.

Archived Entries