It was a few months ago when Troy announced that I'd be teaming up with him to deliver Hack Yourself First workshops and since then I've gotten myself up to speed with the material and delivered my first few events. It turns out that delivering a hacking workshop can be really good fun and you often come across real security issues with applications whilst you do it!
Hack Yourself First
The Hack Yourself Workshop was created and delivered by Troy Hunt and has been exceptionally well received around the world. The demand for the training has been so high that Troy announced I'd be joining him to team up and deliver the workshops too! I will, generally speaking, be working on the Europe side of the world and Troy on his end of the planet! It makes great sense and I spent the first few months of this year revising the material, perfecting demos and getting myself ready for my first deliveries. I've been delivering training for a couple of years now so there were some aspects of being a trainer that I'm well prepared for, but learning a whole new course and working for a good friend and world renowned expert comes with added pressure. Still though, the time came and 3 weeks ago it was time for my first ever delivery in Denmark, followed quickly by my second delivery in Ireland and my third delivery last week at SteelCon. The course went great, everyone had a blast and the feedback was fantastic, I think it's fair to say it went really, really well. Alongside being massively happy with how it all came together and that Troy won't be firing me, we found a few issues and one where I had to advise the person who found it to reach out to the company and notify them!
Proxying mobile app traffic
You can see the full course schedule on Troy's Workshop Page but on the first day, just after lunch, we setup everyone's phone to proxy traffic through their laptop. We also install a root CA so that the proxy can decrypt the traffic and we start to look at how to inspect and... have fun with... the traffic going to and from smartphone apps. As part of this those attending the workshop can also open up websites in their browser and test normal web apps to see if they're making any background API calls too. This is where things have become a little more interesting when I've been delivering the course, we found a few issues, one of which was pretty serious.
Telmore and email disclosure
Telmore are a mobile phone company in Denmark and on their website they have a fairly standard 'forgot password' page: https://www.telmore.dk/info/glemt-adgangskode/
The problem with this page is that if you input a valid telephone number the service will confirm that and provide back most of the email address that the reset link was sent to! If it was my email address for example, it'd say 'an email has been sent to scott*****@hotmail.com'. It would redact the second half of the alias but provide the rest of the email address which is a completely unnecessary and a fairly obvious leak of data. We checked the response itself to make sure the raw data coming back was redacted, and it wasn't being done client side for example, and it was redacted from the server. Still though, there's just no need and mobile phone numbers are sequential too, making them easy to enumerate. Good news though, there does appear to be a captcha on that page now.
Dashlane's user enumeration API
Another leaky feature in an application was found the same day by Jacob Hammer in the Dashlane website. If you go to their login page the first step only asks for your email address. This presents a problem because they can only really let you progress to the next step if you enter an email address that's correct.
Sure enough Dashlane have an enpodint that they call that's literally named /authentication/exists...
Account enumeration as a service?! 🤔 pic.twitter.com/ptTP1Qcixb
— Scott Helme (@Scott_Helme) June 22, 2018
I know applications can sometimes leak information about whether or not an account exists but to have an API endpoint that is intended to do this? On a password manager? It just seems like there's a better way.
Pizza with plain text credit cards
This was a particularly bad one and I had to advise the person that found it, Greg Farrell, to get in touch with the company pretty quickly and notify them. In short, the entire application runs over HTTP to the API behind it... That includes, geo-location data, name, address and... full credit card details...
This is pretty bad in many ways, leaking accurate GPS data, personal data like name/address and of course leaking card data like this puts them in breach of PCI DSS too. It also leaks information of his order history and previous addresses. I did take a quick look by grabbing the app and proxying it myself. You could see Greg was using Charles Proxy on Mac and I grabbed the Android app and used Fiddler on my Windows PC to test it. 100,000+ downloads on Android is worrying...
The app does indeed communicate over HTTP for GPS data and all other queries I checked.
The problem was I needed an Irish phone number to register and login, so I just mashed the keyboard and guessed one that had the correct prefix to see if I could register and get through to complete my order... The API returned something for me.
Yep, seems the last few digits I guessed actually belonged to someone and the API returned the details of who they were. Eugh, this is genuinely not what I was trying to do at all, I was looking to get a screenshot of HTTP card details and here we are now with another problem instead. I tried it on the website and found that has exactly the same problem, but at least the website talks over HTTPS. Funny how the thing you can see has HTTPS but the thing you can't see doesn't have HTTPS...
Still though, to be fair the vendor did move the payment form to HTTPS pretty quickly and said they would move the rest of the endpoints to HTTPS and also not return the account data until after the user had provided the verification code. I can confirm that at the point of publication this issue is also now resolved.
The value of offensive skills
The Hack Yourself First course is 2 days and whilst it's a pretty intense course, it's also great fun and we do huge amounts of hands on hacking. A lot of attendees looked at and thought about their company's own apps/sites and went away with ideas on how to improve them too. It's not a course that's going to turn you into a fully qualified penetration tester but that's not the point either. Finding issues like this is indicative of exactly the problems we still face out in the big wide web. This training covers exactly the kind of things that organisations need to equip themselves with to start increasing the level of security knowledge within their teams. It's also the same course where it was discovered that you could hack a car as Troy and myself wrote about at the time! Do you really want to miss out?