April 4, 2016 By Larry Loeb 2 min read

Security researchers at Sucuri revisited a paper written in 2012 focused on the security of API calls. When used, these calls assumed the integrity of underlying libraries such as JSSE, OpenSSL and GnuTLS, or of data transport libraries such as cURL. However, researchers discovered the TLS certificate used to validate the entire transaction can be spoofed.

Specifically, the original research paper noted that the underlying sources of this vulnerability include “SSL libraries such as OpenSSL, GnuTLS, JSSE, CryptoAPI, etc., as well as higher-level data transport libraries such as cURL, Apache HttpClient, andurllib, that act as wrappers around SSL libraries.” The authors also cited the concern that software may leverage “Web-services middleware such as Apache Axis, Axis 2 or Codehaus XFire.”

Sucuri found that use of these libraries made it hard or impossible to check revocation status of a TLS certificate, as well as other verification problems. This would leave the client open to a man-in-the-middle (MitM) attack.

The TLS Certificate Problem

Here’s how such an attack would work: The server on the other end of the TLS conversation — the API server — authenticates itself by sending an X.509 certificate to the client. The client must verify the certificate’s signature against the list of known root certificates.

If unchecked, the validity of the X.509 certificate is in question, and the client can be spoofed by the invalid certificate of the API server. The user wouldn’t even know the spoofing was taking place since the browser is untouched in all of this.

PHP addressed some of these concerns in its 5.6 release; Python did the same in 2014.

Sucuri researchers decided to use these new languages and see what would still break by testing TLS. According to the blog, “all programming language implementations fail to check if a certificate is revoked,” which is a recognized OWASP vulnerability. So things are broken by default unless corrective action is taken.

Mitigation Methods

There are some mitigation routes available. Upgrading to the latest version of languages will remove many certificate verification problems, although not the revocation aspect.

With Python, for example, one must pass the context parameter to verify the certificate. Similarly, the http.client.HTTPSConnection constructor must also pass the context parameter.

TLS implementation in PHP 5.5 and below is broken with the use of stream functions, Sucuri reported. Using cURL functions instead of stream functions and upgrading to PHP 5.6 whenever possible will help.

There are also Web services that can test any APIs a server is using. This kind of service can identify problem situations that may arise from the use of shared or unmaintained programs.

The end result is that TLS can still be broken, even four years after significant faults were pointed out. The remedies are there, but their use must be vigilant for them to be effective.

More from

NIST’s role in the global tech race against AI

4 min read - Last year, the United States Secretary of Commerce announced that the National Institute of Standards and Technology (NIST) has been put in charge of launching a new public working group on artificial intelligence (AI) that will build on the success of the NIST AI Risk Management Framework to address this rapidly advancing technology.However, recent budget cuts at NIST, along with a lack of strategy implementation, have called into question the agency’s ability to lead this critical effort. Ultimately, the success…

Researchers develop malicious AI ‘worm’ targeting generative AI systems

2 min read - Researchers have created a new, never-seen-before kind of malware they call the "Morris II" worm, which uses popular AI services to spread itself, infect new systems and steal data. The name references the original Morris computer worm that wreaked havoc on the internet in 1988.The worm demonstrates the potential dangers of AI security threats and creates a new urgency around securing AI models.New worm utilizes adversarial self-replicating promptThe researchers from Cornell Tech, the Israel Institute of Technology and Intuit, used what’s…

Passwords, passkeys and familiarity bias

5 min read - As passkey (passwordless authentication) adoption proceeds, misconceptions abound. There appears to be a widespread impression that passkeys may be more convenient and less secure than passwords. The reality is that they are both more secure and more convenient — possibly a first in cybersecurity.Most of us could be forgiven for not realizing passwordless authentication is more secure than passwords. Thinking back to the first couple of use cases I was exposed to — a phone operating system (OS) and a…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today