From CSV to CMD to qwerty

The ongoing breach stories of targeted email campaigns harbouring malicious attachments made me think of writing up a summary of a presentation I gave at the amazing NCC Con held in Dublin in January this year. The talk was based on a pentesting war story that started off exploiting the old (but I believe often overlooked) Dynamic Data Exchange (DDE) trick to go from an Excel export function in a web app to OS code running on users’ workstations. From there, the story takes us on to domain creds via some NTLMv2 theory (without a pentest laptop), a bug in hashcat and a new script “catflap”. Continue reading

Testing for Anti-Virus on File Upload

One of the issues on a standard web app checklist is to test whether or not an application that supports file upload is scanning those files for malware. This article reviews the methodology and highlights the danger of corrupting an EICAR test file so that it no longer acts as a valid test. It is based on an internal presentation I gave, the slides for which are here. Continue reading

Testing for POODLE_TLS Manually

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

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

Thoughts on Testing for POODLE

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

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

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

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