I did a security workshop in a faraway land recently. I’ll not say which one because I want to ensure there’s an appropriate level of anonymity for this story as it could be rather inconvenient for the subject of it otherwise.
Anyway, I do my usual thing of showing attendees how to hack their own things. We do SQL injection and XSS and a whole bunch of other really hands on stuff targeted at developers. The niche I find myself filling these days is security content that talks to folks who actually build stuff and don’t live in security land where everything is, well, a little bit different. By no means do I mean that in a negative way, but security content produced by security people tends to end up talking their language and not resonating as well as it should with the folks who are primarily building rather than breaking. One of the very developer-centric things I do in my workshops is teach them how to use Fiddler to monitor (and modify) traffic between rich client apps and back end APIs. And that’s where it all started to get a bit interesting.
So we do this exercise where everyone proxies their phones through Fiddler (or Charles for the Mac folks) and identifies how their favourite apps are communicating with the back end. We talk about secure versus insecure patterns, how HTTPS can still be circumvented when you own the device and how terribly, woefully bad many of the apps we use every day are. We then go on and use Fiddler Script to modify responses from the server before they hit the device and of course everyone goes to their favourite shopping or real estate or car app and gets it to display a Ferrari selling for $50 (or something like that). One guy – a tester rather than a developer – goes back to his hotel room afterwards and tests an app his company builds. And that’s where it got really interesting…
It turns out his company makes software that controls very large agricultural machinery. They have a rich client app on a portable device which talks to an API back end. The device is provided to the good folks working the land with this machinery and they use it to autonomously control very big things that without saying too much and possibly leading to an uncomfortable discussion for the guy, are enormously expensive and could be caused to do serious damage if someone malicious could take control of them. Which is exactly what he found could be done; a lack of appropriate access controls meant that one customer could see and control another customers’ things. Remember now, these aren’t server things, they’re big moving things in “the real world”. He proceeds to tell the developers who apparently weren’t real happy with his discovery but I imagine they’d be even less happy had Farmer Joe figured out he could literally – physically – crash Farmer Bob’s things.
We spent about 45 minutes on this exercise and that’s all it took for the guy to have enough competency to identify a very serious risk. These issues are not rocket science, they’re well established risks for which technology pros simply need to learn the patterns. But this is often the way with security, in fact just this week at the Microsoft Ignite conference down here in Australia I shared this one:
Definitely agree with this one - we keep getting pwned by things we can easily defend against #msauignite pic.twitter.com/e6atCEbgzV
— Troy Hunt (@troyhunt) November 17, 2015 It’s easy to defend against this stuff, we just need to teach people the patterns.
That was a very long intro to my latest Pluralsight course – Ethical Hacking: Hacking Web Servers. This marks my fourth entry in the Ethical Hacking series and the eighth course overall when you include my partner in the series, Dale Meredith (he’s doing great work on the more infrastructure-orientated courses). This course is hot on the heels of Ethical Hacking: Hacking Web Applications and it’s a pretty closely related course. It’s not always a clear line where the app ends and the server begins but as I said when I kicked off the ethical hacking series, we’re aligning to the CEH syllabus here so that folks can go through and get their cert so it’s important we tick that box.
That said, there’s lots of genuinely new content I haven’t covered before in this course. This ranges from the arguably more app-centric than server centric practice of mirroring a site offline for easier identification of risks right through to demonstrating how a web server like IIS sandboxes websites via independent worker processes for each app pool (I demo how these spin up when a site starts). There’s a lot of other guidance in there of a more general server admin nature too, particularly around practices such as patch management and planning for end of life. Just to make the point clear about this as well, I show how easy it is to discover literally millions of sites running on servers that are no longer supported.
Without giving too much away as to why, this was also a course that caused some, well, let’s say “creative” discussions with the folks who help ensure that Pluralsight doesn’t put anything out that might be a bit too edgy. I talk about very specific incidents and show some pretty nasty attacks that looked like they might have ended up on the cutting room floor, but fortunately my powers of persuasion were strong that day and everything I recorded made the final cut. (Incidentally, for those not aware, everything produced on Pluralsight gets extensively peer reviewed for accuracy, quality and fit with how the company would like to see courses produced.)
Ethical Hacking: Hacking Web Servers is now live! The remaining Ethical Hacking courses will be landing over the next few months too.
Oh – and if you want to jump into an in-person workshop and (possibly) replicate the experience of the guy in the story above, I’m doing a publicly available one at NDC in London in Jan then another one the week after in Oslo.