Tag: CERT

RESEARCH | January 17, 2018

Easy SSL Certificate Testing

By Enrique Nissim
tl;dr: Certslayer allows testing of how an application handles SSL certificates and whether or not it is verifying relevant details on them to prevent MiTM attacks: https://github.com/n3k/CertSlayer.

During application source code reviews, we often find that developers forget to enable all the security checks done over SSL certificates before going to production. Certificate-based authentication is one of the foundations of SSL/TLS, and its purpose is to ensure that a client is communicating with a legitimate server. Thus, if the application isn’t strictly verifying all the relevant details of the certificate presented by a server, it is susceptible to eavesdropping and tampering from any attacker having a suitable position in the network.The following Java code block nullifies all the certificate verification checks:
 
X509TrustManager local1 = new X509TrustManager()
{
       public void checkClientTrusted(X509Certificate[]
       paramAnonymousArrayOfX509Certificate,
       String paramAnonymousString)
       throws CertificateException { }
 
       public void checkServerTrusted(X509Certificate[]
       paramAnonymousArrayOfX509Certificate,
       String paramAnonymousString)
       throws CertificateException { }
 
       public X509Certificate[] getAcceptedIssuers()
       {
              return null;
       }

 

}
 
Similarly, the following python code using urllib2 disables SSL verification:
 
import urllib2
import ssl
 
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
 
urllib2.urlopen(“https://www.ioactive.com”, context=ctx)
 
These issues are not hard to spot while reading code, but what about a complete black box approach? Here is where Certslayer comes to the rescue.
 
How does it work?
 
Proxy Mode
Certslayer starts a proxy server and monitors for specified domains. Whenever a client makes a request to a targeted domain, the proxy redirects the request to an internal web server, presenting a special certificate as a test-case. If the internal web server receives the request, it means the client accepted the test certificate, and the connection was successful at the TLS level. On the other hand, if the internal web server doesn’t receive a request, it means the client rejected the presented certificate and aborted the connection.
 
For testing mobile applications, the proxy mode is very useful. All a tester needs to do is install the certificate authority (Certslayer CA) in the phone as trusted and configure the system proxy before running the tool. Simply by using the application,  generates requests to its server’s backend which are trapped by the proxy monitor and redirected accordingly to the internal web server. This approach also reveals if there is any sort of certificate pinning in place, as the request will not succeed when a valid certificate signed by the CA gets presented.
 
A simple way to test in this mode is to configure the browser proxy and navigate to a target domain. For example, the next command will start the proxy mode on port 9090 and will monitor requests to www.ioactive.com:
C:\CertSlayerCertSlayer>python CertSlayer.py -d www.ioactive.com -m proxy -p 9090
 
 

Currently, the following certificate test-cases are available (and will run in order):

  • CertificateInvalidCASignature
  • CertificateUnknownCA
  • CertificateSignedWithCA
  • CertificateSelfSigned
  • CertificateWrongCN
  • CertificateSignWithMD5
  • CertificateSignWithMD4
  • CertificateExpired
  • CertificateNotYetValid
 
Navigating with firefox to https://www.ioactive.com will throw a “Secure Connection Failed”:
 
The error code explains the problem: SEC_ERROR_BAD_SIGNATURE, which matches the first test-case in the list. At this point, Certslayer has already prepared the next test-case in the list. By reloading the page with F5, we get the next result.
 
 
At the end, a csv file will generate containing the results of each test-case. The following table summarizes them for this example:
 

Stand-alone Mode

Proxy mode is not useful when testing a web application or web service that allows fetching resources from a specified endpoint. In most instances, there won’t be a way to install a root CA at the application backend for doing these tests. However, there are applications that include this feature in their design, like, for instance, cloud applications that allow interacting with third party services.

 

In these scenarios, besides checking for SSRF vulnerabilities, we also need to check if the requester is actually verifying the presented certificate. We do this using Certslayer standalone mode. Standalone mode binds a web server configured with a test-certificate to all network interfaces and waits for connections.

 

I recently tested a cloud application that allowed installing a root CA to enable interaction with custom SOAP services served over HTTPS. Using the standalone mode, I found the library in use wasn’t correctly checking the certificate common name (CN). To run the test-suite, I registered a temporary DNS name (http://ipq.co/) to my public IP address and ran Certslayer with the following command:
 
C:CertSlayerCertSlayer>python CertSlayer.py -m standalone -p 4444 -i j22d1i.ipq.co
 
+ Setting up WebServer with Test: Trusted CA Invalid Signature
>> Hit enter for setting the next TestCase
 
The command initialized standalone mode listening on port 4444. The test certificates then used j22d1i.ipq.co as the CN. 

After this, I instructed the application to perform the request to my server:
 
POST /tools/soapconnector HTTP/1.1
Host: foo.com
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Content-Length: 55
Cookie: –
Connection: close
 
 
{“version”:”1.0″,”wsdl”:”https://j22d1i.ipq.co:4444/”}
 
 
Server response:
{“status”:500,”title”:”Problem accessing WSDL description”,”detail”:”We couldn’t open a connection to the service (Describe URL: https://j22d1i.ipq.co:4444/). Reason: Signature does not match. Check the availability of the service and try again”}
 
 
The connection was refused. The server error described the reason why: the CA signature didn’t match. Hitting enter in the python console made the tool prepare the next test case:
 
+ Killing previous server
j22d1i.ipq.co,Trusted CA Invalid Signature,Certificate Rejected,Certificate Rejected
+ Setting up WebServer with Test: Signed with CertSlayer CA
>> Hit enter for setting the next TestCase
 

Here, the connection succeeded because the tool presented a valid certificate signed with Certslayer CA:

 

Server Response:
 
{“status”:500,”detail”: “We couldn’t process the WSDL https://j22d1i.ipq.co:4444/. Verify the validity of the WSDL file and that it’s available in the specified location.”}
 
Certslayer output:
j22d1i.ipq.co,Signed with CertSlayer CA,Certificate Accepted,Certificate Accepted
xxx.yyy.zzz.www – – [14/Dec/2017 18:35:04] “GET / HTTP/1.1” 200 –
 
When the web server is configured with a certificate with a wrong CN, the expected result is that the client will abort the connection. However, this particular application accepted the certificate anyway:
+ Setting up WebServer with Test: Wrong CNAME
>> Hit enter for setting the next TestCase
xxx.yyy.zzz.www – – [14/Dec/2017 18:35:54] “GET / HTTP/1.1” 200 –
j22d1i.ipq.co,Wrong CNAME,Certificate Rejected,Certificate Accepted
 
 
As before, a csv file was generated containing all the test cases with the actual and expected results. For this particular engagement, the result was:
 

A similar tool exists called tslpretense, the main difference is that, instead of using a proxy to intercept requests to targeted domains, it requires configuring the test runner as a gateway so that all traffic the client generates goes through it. Configuring a gateway host this way is tedious, which is the primary reason Certslayer was created.
 
I hope you find this tool useful during penetration testing engagements 🙂

 

INSIGHTS | October 17, 2013

Strike Two for the Emergency Alerting System and Vendor Openness

By Mike Davis
Back in July I posted a rant about my experiences reporting the DASDEC issues and the problems I had getting things fixed. Some months have passed and I thought it would be a good time to take a look at how the vulnerable systems have progressed since then.

Well, back then my biggest complaint was the lack of forthrightness in Monroe Electronics’ public reporting of the issues; they were treated as a marketing problem rather than a security one. The end result (at the time) was that there were more vulnerable systems available on the internet – not fewer – even though many of the deployed appliances had adopted the 2.0-2 patch.

What I didn’t know at the time was that the 2.0-2 patch wasn’t as effective as one would have hoped; in most cases bad and predictable credentials were left in place intentionally – as in I was informed that Monroe Electronics were “intentionally not removing the exposed key(s) out of concern for breaking things.”

In addition to not removing the exposed keys, it didn’t appear that anyone even tried to review or audit any other aspect of the DASDEC security before pushing the update out. If someone told you that you had a shared SSH key for root you might say… check the root password wasn’t the same for every box too right? Yeah… you’d think so wouldn’t you!

After discovering that most of the “patched” servers running 2.0-2 were still vulnerable to the exposed SSH key I decided to dig deeper in to the newly issued security patch and discovered another series of flaws which exposed more credentials (allowing unauthenticated alerts) along with a mixed bag of predictable and hardcoded keys and passwords. Oh, and that there are web accessible back-ups containing credentials.

Even new features introduced to the 2.0-2 version since I first looked at the technology appeared to contain a new batch of hardcoded (in their configuration) credentials.

Upon our last contact with CERT we were informed that ‘[t]hese findings are entering the realms of “not terribly serious” and “not something the vendor can practically do much about.”‘

Go team cyber-security!

So… on one hand we’ve had one zombie alert and a good hand-full of responsibly disclosed issues which began back in January 2013… on the other hand I’m not sure anything changed except for a few default passwords and some version numbers.

Let’s not forget that the EAS is a critical national infrastructure component designed to save lives in an emergency. Ten months on and the entire system appears more vulnerable than when we began pointing out the vulnerabilities.
INSIGHTS | September 10, 2013

Vulnerability bureaucracy: Unchanged after 12 years

By Cesar Cerrudo

One of my tasks at IOActive Labs is to deal with vulnerabilities; report them, try to get them fixed, publish advisories, etc. This isn’t new to me. I started to report vulnerabilities something like 12 years ago and over that time I have reported hundreds of vulnerabilities – many of them found by me and by other people too.

Since the early 2000’s I have encountered several problems when reporting vulnerabilities:
  • Vendor not responding
  • Vendor responding aggressively
  • Vendor responding but choosing not to fix the vulnerability
  • Vendor releasing flawed patches or didn’t patch some vulnerabilities at all
  • Vendor failing to meet deadlines agreed by themselves

It’s really sad to tell that, as of right now, 12 years later, I continue to see most (if not all) of the same problems. Not only that, but some organizations that are supposed to help and coordinate vulnerability reporting and disclosure (CERTs) are starting to fail, being non responsive and not contributing much to the effort.

This shouldn’t be a big problem if you are reporting low impact or unimportant vulnerabilities, but most of the time the team here at IOActive report critical vulnerabilities affecting systems ranging from critical infrastructure to the most popular commercial applications, OS’s, etc. used by millions of people around the world. There is a big responsibility upon us to work with the affected vendors to get the vulnerabilities fixed and thinking about how bad things could be if they are exploited.

It’s also surprising to sometimes see the tardy response from some teams that are supposed to act and respond fast such as Android security team given that Google has some strong vulnerability polices (1, 2):

It would be nice if most vendors, CERTs, etc. are aware of the following:
  • Independent researchers and security consulting companies report vulnerabilities on a voluntary basis.
  • Independent researchers and security consulting companies have no obligation to report security vulnerabilities.
  • Independent researchers and security consulting companies often invest a lot of time, effort and resources finding vulnerabilities and trying to get them fixed.
  • Vendors and CERTs should be more appreciative of the people reporting vulnerabilities and, at the very least, be more responsive than they typically are today.
  • Vendors and CERTs should adhere and comply with their own defined deadlines.
I would like for vendors and CERTs to start improving a little and becoming more responsive; the attack surface grows everyday and vulnerabilities affect our lives more and more. The more we depend on technology the more the vulnerabilities will impact us.

There shouldn’t be vulnerability bureaucracy.

If there’s one thing that vendors and CERTs could do to improve the situation, that would be for them to step-up and be accountable for the vulnerability information entrusted to them.

 

I hope that in the following 12 years something will change for the better.
INSIGHTS | June 28, 2012

Thoughts on FIRST Conference 2012

By Eireann Leverett

I recently had the opportunity to attend the FIRST Conference in Malta and meet Computer Emergency Response Teams from around the world. Some of these teams and I have been working together to reduce the internet exposure of Industrial Control Systems, and I met new teams who are interested in the data I share. For those of you who do not work with CERTs, FIRST is the glue that holds together the international collaborative efforts of these teams—they serve as both an organization that makes trusted introductions, and vets new teams or researchers (such as myself).

It was quite an honor to present a talk to this audience of 500 people from strong technical teams around the world. However, the purpose of this post is not my presentation, but rather to focus on all of the other great content that can be found in such forums. While it is impossible to mention all the presentations I saw in one blog post, I’d like to highlight a few.
A session from ENISA and RAND focused on the technical and legal barriers to international collaboration between National CERTS in Europe. I’m interested in this because during the process of sharing my research with various CERTs, I have come to understand they aren’t equal, they’re interested in different types of information, and they operate within different legal frameworks. For example, in some European countries an IP address is considered private information and will not be accepted in incident reports from other teams. Dr. Silvia Portesi and Neil Robinson covered a great wealth of this material type in their presentation and report, which can be found at the following location:
In the United Kingdom, this problem has been analyzed by Andrew Cormack, Chief Regulatory Advisor at Janet. If I recall correctly, our privacy model is far more usable in this respect  and Andrew explained it to me like this:
If an organization cannot handle private data to help protect privacy (which is part of its mission), then we are inhibiting the mission of the organization with our interpretation of the law.
This is relevant to any security researcher who works within incident response frameworks in Europe and who takes a global view of security problems.
Unfortunately, by attending this talk—which was directly relevant to my work—I had to miss a talk by Eldar Lillevik and Marie Moe of the NorCERT team. I had wanted to meet with them regarding some data I shared months ago while working in Norway. Luckily, I bumped into them later and they kindly shared the details I had missed; they also spent some of their valuable time helping me improve my own reporting capabilities for CERTs and correcting some of my misunderstandings. They are incredibly knowledgeable people, and I thank them for both their time and their patience with my questions.
Of course, I also met with the usual suspects in ICS/Smart Grid/SCADA security: ICS-CERT and Siemens. ICS-CERT was there to present on what has been an extraordinary year in ICS incident response. Of note, Siemens operates the only corporate incident response team in the ICS arena that’s devoted to their own products. We collectively shared information and renewed commitments to progress the ICS agenda in Incident Response by continuing international collaboration and research. I understand that GE-CIRT was there too, and apparently they presented on models of Incident Response.
Google Incident Response gave some excellent presentations on detecting and preventing data exfiltration, and network defense. This team impressed me greatly: they presented as technically-savvy, capable defenders who are actively pursuing new forensic techniques. They demonstrated clearly their operational maturity: no longer playing with “models,” they are committed to holistic operational security and aggressive defense.
Austrian CERT delivered a very good presentation on handling Critical Infrastructure Information Protection that focused on the Incident Response approach to critical infrastructure. This is a difficult area to work in because standard forensic approaches in some countries—such as seizing a server used in a crime—aren’t appropriate in control system environments. We met later to talk over dinner and I look forward to working with them again.
Finally, I performed a simple but important function of my own work, which comprises meeting people face-to-face and verifying their identities. This includes our mutually signing crypto-keys, which allows us to find and identify other trusted researchers in case of an emergency. Now that SCADA security is a global problem, I believe it’s incredibly important (and useful) to have contacts around the world with which IOActive already shares a secure channel

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close