Tag Archives: penetration testing

The Case of the Customer Data and the Third-Party Analytics Site

Leave a reply

I recently had an article published on the NCC Group blog about a pentest during which it became clear that customer personal data was being sent to a third party. It’s common for websites to use metrics/analytics services to collect usage data on how users are interacting with the sites. I thought it would be useful to highlight the danger of sensitive data being accidentally sent to third parties without due care and attention paid to GDPR. Have a read!

Missing XSS flaws with innerHTML and jQuery

Leave a reply

I thought a couple of gotchas when testing for XSS could be a useful post. Not new, especially, but I haven’t posted for a while. It shows how you might think you’ve covered an area of a web application and declared it free from XSS but in fact there might be a bug left behind. Continue reading →

Testing for POODLE_TLS Manually

9 Replies

Testing for the original POODLE vulnerability was easy because it was an inherent problem with SSLv3, so if you find SSLv3 enabled then you’ve found POODLE (although other factors such as cipher suite preference have a role to play – see my previous post). Like Heartbleed, though, testing for POODLE over TLS is conceptually easy but it falls within a class of flaws that requires bespoke tools as an unpatched version of openssl, for example, won’t do what you want it to do. This article discusses how the Python tlslite library can be used to test for POODLE_TLS – and so much more. Continue reading →

When HTML Encoding Helped XSS

1 Reply

Recently I was pentesting a web app that had an unauthenticated XSS vulnerability but there was some heavy filtering in place. Nonetheless I was able to achieve session fixation using a combination of a technique I previously explained and some fun filter workarounds – including using the application’s own defensive HTML encoding to create a working XSS payload! Continue reading →

SS-Hell: the Devil is in the Details

Leave a reply

Penetration test reports commonly contain mention of vulnerabilities in SSL/TLS (hereafter referred to as just SSL). In many cases, this is due to system administrators not understanding the details of these services’ configuration and assuming that simply using SSL provides security. The issues identified during penetration tests are usually low in severity, as an average attacker would find them difficult to exploit, but they should be taken seriously to ensure that data in transit is properly secured. If something’s worth doing, it’s worth doing well. This whitepaper, co-written with Will Alexander, discusses how organisations can avoid SSL issues commonly found during penetration tests, ensure that data in transit is properly secured and ultimately instil in users a sense of confidence that their information is adequately protected.

Thoughts on Testing for POODLE

Leave a reply

I recently did an internal presentation on POODLE – what the flaw is and how to test for it – and a version of the slides can be found here. Obviously much has been written about the vulnerability, its mitigations and what the future holds. What follows expands on the testing aspect of the presentation, with a few pointers on manual checks if you feel you need to verify or clarify – and possibly even add to – what the tools are telling you. Continue reading →

Testing for Cipher Suite Preference

Leave a reply

It’s often important to know which SSL/TLS cipher suite is preferred by a server to alter the risk rating of a particular issue. For POODLE, if the server prefers RC4 ciphers over SSLv3 connections then it’s very unlikely that a connection will be vulnerable to POODLE. Similarly, if a server prefers block ciphers then reporting RC4 support should be appropriately adjusted. Occasionally tools conflict over which cipher suite is preferred so I thought I’d write up how to resolve this manaully in the spirit of the SSL/TLS manual cheatsheet. Continue reading →

Testing for TCP/IP Timestamps

2 Replies

It always used to be a stock joke in my old workplace that if you were having a tough time finding issues in a pentest then you could always rely on “TCP/IP timestamps”. Recently I did a re-test (based on another company’s report) that included this issue and found that it’s easy for this to be a false positive. I thought I’d write up this finding – as much for the journey I took through Nessus, Nmap, hping and Wireshark as for the result itself. Continue reading →

The Small Print for OpenSSL legacy_renegotiation

Leave a reply

The other day my attention was drawn to a switch in OpenSSL called -legacy_rengotation. I pulled up the built-in help for s_client and, sure enough, there it was. So I trawled back through the release notes and it looked to have been there since version 0.9.8m. I couldn’t believe that I hadn’t spotted this before: it looked like the perfect way to test for insecure renegotiation without the faff of having to recompile OpenSSL or use an older version. But after a bit of testing this proved to be a red herring… Continue reading →

SQL Injection in Search Fields

6 Replies

A quick posting about a fun SQL injection I cracked last week (of course, it’s only when you’ve cracked them that they’re fun!). A colleague had found the classic sign of a problem – add a single quote and you get an error – but was having no luck doing anything more. I was getting nowhere with my test so I thought I’d take a look for a change of scene. The input field was in a search box so, for example, search=keyword' returned an error but search=keyword'' was fine. Anything more exciting than that, however, such as search=keyword' and '1'='1, didn’t seem to work as expected: in this case, an error was returned instead of the same set of results that the normal search=keyword produced. Continue reading →