Author Archives: Jerome

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 →

POODLE and the TLS_FALLBACK_SCSV Remedy

6 Replies

The POODLE attack announced very recently depends largely on a protocol downgrade attack (which I covered in my SSL/TLS presentation at BSides). I don’t think this aspect of TLS security was widely appreciated – but it is now! It’s a fair bet that any technical article about POODLE includes the phrase “TLS_FALLBACK_SCSV” as a remedy. This article discusses the mechanism proposed to protect us from attackers forcing TLS downgrades. NEW (16/10/14): while I was writing this I thought of a small but potential compatibility problem, which in fact could do us all a favour. I checked with the authors of the RFC and Adam Langley was kind enough to reply back so I’ve added added a new section below. 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

4 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 →

Session Fixation and XSS Working Hand-in-Hand

Leave a reply

Often a combination of security flaws come together to produce a unique attack vector. Individually the flaws may not amount to much but together they make an interesting combo. This is invariably more interesting from a pentesting point of view because you know that a tool couldn’t positively find it. Session fixation is one such scenario because usually a few requirements must be met for the attack to work. I thought I’d write up a recent session fixation flaw because the act of forcing the cookie onto the victim involved a little twist on overwriting session cookies that made a reflective XSS attack last a lot longer while also laughing in the face of httponly. Continue reading →

Three Cheers for DirBuster

3 Replies

Not exactly wizard stuff today, more like back to basics perhaps – but sometimes they’re worth revisiting. I’ve had some good DirBuster finds three tests in a row so I thought I’d write them up as a case study. It’s a reminder that there’s some very low-hanging fruit out there that may not always get picked. I’ve also put together a walk-through for many of DirBuster’s features and I aim to show that, as with many tools, a few minutes of manual work can produce a faster set of more meaningful results. Continue reading →

A Tricky Case of XSS

1 Reply

On a recent test I came across a reflective XSS condition within a file upload page. When the extension was deemed invalid by the application, it was returned unsanitised within the error message. Not only did this turn out to be an exercise in exploiting reflective XSS in multipart/form-data but there were some pretty hefty restrictions on allowed characters too. Worthy of a post I thought. Continue reading →

DOM XSS by Misusing Bootstrap

1 Reply

First of all, let me make it clear that this article is not about XSS in Bootstrap itself (the very popular libraries originally from Twitter to fancify your website), it’s about XSS as a result of using Bootstrap in an insecure fashion. It’s based on a real penetration test – the site in question wasn’t vulnerable but it was immediately clear how things could have gone wrong. I thought it would be an interesting XSS article, being both DOM-based and making use of a big-name library like Bootstrap. Continue reading →