This is an archive post from the Netsparker (now Invicti) blog. Please note that the content may not reflect current product names and features in the Invicti offering.
I'm sure lots of you are sad that Black Hat USA 2017 and DEF CON 25 are over. You had a hell of a time in Las Vegas, were given the opportunity to listen to some great talks and meet people who share the same interest. And of course, you've learned a lot and attended many great workshops. If one or more of these points apply to you, this article is probably not interesting for you.
You will find this article interesting if:
- Everybody told you that you need to bring a dedicated travel phone when you pass the customs, however the same people are calling you an idiot for planning to get a burner phone for Black Hat. Out of confusion you just stayed at home.
- All you wanted is to see the great talks at DEF CON but it got cancelled yet again!
- You passed out at the bar when the cons started and woke up to people carrying their IMSI catchers out of the hotel at the end of DEF CON. Nothing to see here.
- Your husband, wife or partner made you sleep on the couch until the end of the conferences because you suggesting to fly a few thousand miles to Sin City and leave them alone at home with the kids.
Or in other words: you couldn't attend. In all of those cases, you were probably interested in seeing the awesome talks. Now I have good news and bad news for you. The bad ones first: There are no videos yet. Yes, both conferences will make videos of the talks available in the course of the following months. However, for now, all you can get are shaky three minute clips of one hour presentations and short PoC videos you won't understand if you didn't see the talk.
Now the good news. There are slides available. Yes, we've sifted through hours worth of "What if I told you?" memes and countless pages with the same diagram but different arrows and we've come up with a list of our favorite slides and papers concerning web application security.
JSON attacks by Alvaro Muñoz and Oleksandr Mirosh
We've heard it countless times in recent years; don't use dangerous deserialization functions on user input, just use JSON instead. Let's just say this didn't work out too well. Thanks to these slides you'll get the idea why JSON deserialization is not a good idea either. An absolute must-read if you are a developer, or hacker.
Game of Chromes by Tomer Cohen
Do you keep track of all the extensions you have installed? You probably have a weather widget next to the URL bar, an extension that replaces every occurrence of "APT" with "16 year old hacker" and hopefully an Ad Blocker. However, after reading this paper you'll probably strip them down to a minimum. You'll probably also spend the rest of the day scrolling through your Facebook messages, just to see if a malicious plugin sent a message to some guy you haven't talked to for three years, asking him if he would like to install the coolest Chrome extension you've seen in a while. Awkward.
- A malicious Chrome extension was spreading through facebook messages
- Copy of a legitimate extension in the chrome web store
- It loaded a script over the internet and injected it into every single page
- Created wix pages that redirected to attacker's website
- At a later stage, it used social logins with the victim's Facebook for wix to avoid bot detection
Abusing Certificate Transparency by Hanno Böck
A modern web without TLS? Not gonna happen. That's why we are amongst the proud sponsors of the Let's Encrypt certificate authority. One particularly useful approach to further secure TLS is the certificate transparency log; whenever a new certificate is created it can be submitted there for anyone to see. So no need to disable zone transfers anymore, yay! *cough*. In the future certificates that aren't in the log won't be accepted by browsers like Google Chrome. Those Certificate Transparency logs are public and Hanno Böck shows you how attackers can abuse this fact to automatically take over web servers by using install scripts before the user can. But don't worry, he'll also show you how to avoid that effectively.
- He uses crt.sh to find (sub)domains that just got their SSL certificate
- He then checks if there's an install script, e.g. for wordpress
- If there is one, he installs the script using his own database and installs a backdoor script on the server
- After that he reverts all the changes he made, presenting the user with a fresh install script again, however, it still contains the backdoor
Driving down the rabbit hole by Jesse Michael, Mickey Shkatov and Oleksandr Bazhaniuk
Alright, you found it out. This one is not purely about web applications. However, it should serve as a quick reminder that you should regularly check if the services you rely on are still up and running. And also that their domain names are not for sale. In this case, it was enough to run `strings` on some debug files to find an expired domain from Nissan. After the researchers registered it they received some interesting data via POST requests. Not only usernames and passwords but also some location data that was showing where the vehicles were driving. On a map, they showed that one car seems to have driven into the Delaware River. Let's just hope this had nothing to do with their research.
- They got the complete dashboard of a wrecked Nissan
- Could obtain navigation system debug data from it
- They ran strings on the debug files and found the following URL:
- Since it was expired they registered the domain and got POST requests from different cars, containing location data of different cars.
A new era of SSRF by Orange Tsai
One of my personal favorites this year. If you've ever written a vulnerability free, RFC conform URL parser you are probably someone with an infinite amount of time and wisdom on your hand. But we mere humans have to rely on the parsers that come with the respective programming language or - even worse - on external libraries. However, it turns out that even the developers of those external parsers are human beings like you and me and make mistakes as well. The author shows how weird the URL parsers of those libraries behave, why CRLF injection is not only a server side problem and even implies that he has at least 3 bypasses for the SSRF protection in WordPress. I for one look forward to see the video of the presentation.
- He uses @, #, &, spaces etc. to fool parsers into checking the wrong host name
- Using HTTPS he shows how to use spaces and CRLF to craft valid SMTP requests
- He will also show how to abuse the full-width latin capital letter N (U+FF2E) to bypass filters in node.js
Web Cache Deception attack by Omer Gil
Okay okay, right at the beginning of this article I told you that we would scroll through all the articles with the same pictures but different arrows for you. But that's what you'll find within these slides. However, if you click through exactly 28 pictures of what I assume is the same dog you'll end up on slide 25. This is where the author describes an awesome attack technique that takes advantage of a common (mis)configuration of caching servers together with the behaviour of some web application programming languages and frameworks. So if you like dogs (and let's be honest, who doesn't?) and want to read about cool new attack methods (and let's be honest, who doesn't?) then you shouldn't miss out this article. However, if you don't like dogs but are into cool new attack methods anyway, you can just read the white paper.
- You must be able to add a file extension that's cached by a misconfigured intermediate proxy by default, e.g. /index.php/file.css to exploit this vulnerability
- After that, you have to make a victim visit the page
- It will be cached by the intermediate proxy and once you open it in your browser, you will see the victim's cached response.
Bypassing XSS Mitigations via script gadgets by Sebastian Lekies, Krzysztof Kotowicz and Eduardo Vela Nava
Ah yes, the famous black list filters. If you like XSS and challenges you should try to bypass one. More often than not it's pretty easy. Some of them block certain keywords like 'iframe' or 'document' some literally have a regex pattern like <script>.*</script> and others try to prevent exploitation by blacklisting 'alert'. Way to go. But the authors don't seem to be interested in the easy ones. Instead, they are trying to fool strict filters with harmless tags and attributes that become dangerous thanks to existing code on the vulnerable pages. How probable it is to find existing gadgets and how easy it is to exploit them is explained in the slides.
- Knockout: <div data-bind="value:'alert(1)'"></div>
- Ajaxify: <div class="document-script">alert(1)</div>
- Bootstrap: <div data-toggle=tooltip data-html=true title='<script>alert(1)</script>'>
How abusing Docker api led to remote code execution by Michael Cherny and Sagie Dulce
Did you know how easy it is to abuse internal services using DNS rebinding? Or how dangerous enabled REST APIs are even if they are only reachable on localhost? If not you a) need to be strong now and b) should read our blog post on how hackers can use vulnerable web applications to bypass corporate firewalls.
In this presentation, the author explains how it is possible to get remote code execution by using the Docker REST API if it is enabled. And it seems like this is pretty common. So if you run a docker container, make sure to disable the API and read the linked paper.
- They abused the REST API on port 2375
- Since it binds on localhost by default either CSRF or SSRF are required for exploitation
- The vulnerable endpoint is localhost:2375/build
- A post request to the following URL will create a docker container from a github repository and use the same network as the host machine
That’s All from Black Hat and Def Con Folks!
Those were our favorite talks of this years DEF CON 25 and Black Hat USA conferences. We are looking forward to seeing the videos of all the slides and hope you enjoyed them as much as we did. It's time to leave the couch now and buy some flowers for your better half.