Interview: Troy Hunt, Architect at Pfizer Pharmaceuticals

Today, I'm pleased to have Troy Hunt with us. Troy has been building web applications in the finance, media and healthcare industries since the early days of the web in the mid '90s. Based out of Sydney Australia, he now works as an architect for Pfizer Pharmaceuticals’ Emerging Markets. 

His software interests focus on enabling people to be productive in delivering high quality applications within proven frameworks. He regularly blogs about application security, improving the software development process and all things technology related.

Troy and I discuss all of the recent high profile security breaches of Target, Home Depot and Apple and what that means for the state of security in today's landscape. He shares his thoughts on application security as it relates to the "internet of things" and the interconnected-ness of more and more mobile apps.  This leads into my belief that businesses can simply do a better job of delivering secure software and Troy thinks starts with helping developers better understanding the vulnerabilities in their code.

The following is a brief excerpt of our interview.

Jeff Williams: So if you're a CEO or CIO today and you're looking at this [high-profile data breach] situation, what's going on in your mind about security?

Troy Hunt: Look at a couple of things - I think the points there about frequency and scale is one of them. You mentioned sort of the surface of attack as well in terms of just the volume of applications out there. I think the other thing that's starting to strike me, and would be on my mind in a security capacity, is the number of different types of devices and online communication we're seeing. So, clearly a big thing in the industry now is "internet of things." Let's face it, "the Internet of things" is very exciting and I am very excited by the prospect of being able to control my light globes by my smartphone, but we're also seeing light globes controlled by smartphones such as the LIFX system actually having had vulnerabilities that will disclose WiFi credentials so that sort of thing worries me. What I find - I hate to say it but almost amusing - is you look at the breadth of internet connected things and the fact that they're now becoming vulnerable.

So, there's a toilet that they make in Japan called the Lixil Satis, and this toilet is a smartphone connected toilet. Now I know what you're thinking. "Why do I need to connect my toilet to my smartphone?" [Laughs] Now for those of you who have been to Japan before and seen some of the uniqueness of Japanese toilets you'll realize that there may not even need to be a reason, but they will find some way to make the technology work. Even in that case, in fact it was funny. I was talking about this at some events earlier last year, and I said, "Look, we connect all these things. We're going to now have to deal with the fact that we will have vulnerabilities" and sure enough, I think it was about August last year Trustwave came out with a security advisory for the Lixil Statis toilet seat because they had a risk in their Bluetooth implementation via WiFi default pin. Now you've got to imagine - I'm sitting here on the toilet and someone else is controlling the devices and the mechanics and these are very sophisticated Japanese toilets. They do have mechanics. Someone else is controlling that whilst I'm using it and that to me is a scary thought.

Jeff Williams: Well, that's what concerns me about the internet of things - I'm sure it's going to be the same types of vulnerabilities sort of recast in this new context but what's interesting is now the impacts are not just data and disclosures. It's not all just this virtual stuff. It's real world impacts. You know thermostats, and cars, all the way up to a nuclear plant, that's real world effects where people get hurt.

Troy Hunt: Yeah. Exactly. I think another one that illustrates that point really well is we're getting a lot of internet connected door locks, literally the front door to your home. So things like Lockitron, amazingly impressive. I just hope that they've got this security profile as good as it could possibly be because at the end of the day the value proposition of some of these connected devices such as the door locks is that you can unlock it remotely. Of course the concern is that if you can unlock it remotely chances are that somebody else may be able to unlock it remotely.

Jeff Williams: Yeah. It's fascinating. So let me ask you know you've done a lot of work with web applications, and we've talked about SQL injection, and cross-site scripting, and authentication problems a little bit, but what do you see as a kind of a hidden gem in there, like a concern that people really should be taking more seriously. What are some of those vulnerabilities that have you worried?

Troy Hunt: Well I think the thing that I'm a bit focused on at the moment Jeff is the way that our mobile apps are talking over the web. It's a little bit timely because I just got my last cert site course published last night which was about hacking your API first, like what sort of vulnerabilities do we see behind mobile API's? To me that's a bit of a hidden risk in that - take an example - if you have an invalid search on a website and you go there in your browser, you hear bells, and whistles, and blaring lights and all sorts of things go off, and you've got to sort of sign away your first born child before you're actually proceed with a connection within a cert and that's great. But then we move into the mobile world and these just get gobbled up. So, I just pushed a blog post a couple of hours ago where I showed look, here's a perfect example - we've got a taxi app here in Australia that I'd used quite extensively that was communicating with a web API backend so they're pretty normal there, but it was a self-signed cert that had expired a year ago and had no validation.

You get nothing in the client to indicate that that connection is actually insecure. Now if I go to the browser and try and do that license stuff go off everywhere but the web app or rather the mobile app just gobbles it up, so I think that is a really significant area of risk on the web that by all accounts is extremely prevalent and even just writing the course, the number of things that I've found and had to disclose privately it just boggled my mind.

Jeff Williams: Yeah. I know several security researchers who they just take mobile apps and figure out what service those apps are talking to, and then they just start going directly to the service to see what they can make it do, and they're just finding vulnerabilities right and left because nobody ever expected the service to be accessed that way. Their SSL is just one aspect of that. There's all the access control and authentication and injection kind of problems. They're all rampant in those services.

Troy Hunt: Yeah. Absolutely. I think the assumption that developers are making is that if they build the app and they build the service then they control the ecosystem and everything in between those two things and what they overlook is that at the end of the day it's just going to talk out over ACTP or ATPDS and either way that is an intercept-able communication. There's an example that I use in a lot of presentations because it's just the right balance of kind of interesting but it isn't going to get me into trouble or anybody else too, and that is the British Airways app.

When you open up the British Airways app you can authenticate inevitably into a backend service as a member of their loyalty program after which it will give you the credentials for the WiFi in the lounges so you can actually get some decent internet. What I show in these demos is look, here's what we'll do - we'll open up Fiddler, we'll proxy the traffic from the IRS device through Fiddler and then as soon as you open the British Airways app before any author or anything else, all the WiFi passwords get sent down of the device. Here it is.

They've just done it on HTDP input. So effectively they're doing their authorization within the client after all of the data is sent. Now this is only WiFi passwords so you're not going to exactly... it's not a sort of treasure trove of personal data ... but that pattern thing that's replicated to far more sensitive classes of information as well.

Jeff Williams: So, let's talk a little bit about the process that organizations are using to build software. What are some of the things that enterprises can do to do a better job of delivering secure software?

Troy Hunt: To me it really sort of starts at the beginning, which is the developers. Say of course we need to have all of the things kind of post-development in terms of security review and ongoing analysis, but the reality of it is the vast majority of the risks we're seeing are risks that are programmed into the code. In my mind, we need to get back to the source of where we're introducing those and that is when we have people building code that does things like it does authorization after the data is already sent to the device. That needs to be an awareness campaign back on the developer's end. I think really the answer there is training. I also think that a lot of this comes down to unless we can help software developer's understand how the risk is exploited, it's very difficult to get them to write secure code.

So I see a lot of incidents where security teams will send developer's findings and they'll say, "You've got a SQL injection. Fix it" and the developers never mounted a SQL injection attack before. They don't know what the value proposition is of actually pramatarizing queries and whitelisting all this sort of thing. They really don't get vested in the secure profile of that app until they can experience it firsthand. Then you see the lights go on, they go "Oh man, you can do that. Wow." [Laughs]

Jeff Williams: Yeah. It is exactly that. It's like that eureka moment that you see students have. Actually that's exactly why I wrote Webgo back in 2000 because it's a whole different thing that tells somebody about SQL injection than to show them.

Troy Hunt: Yeah. Exactly. Here's the thing, right? Developers love actually experimenting and pulling things apart and seeing how things work, and when they get to play with this sort of stuff and they get just enough guidance to kind of get into and roam free a little bit, they love doing it too. They really get invested in the process.

Jeff Williams: Yeah. I couldn't agree more. I read somewhere that you said I will not run web security analyzers without first understanding web security.

Troy Hunt: [Laughs] I said that yesterday. So the premise of that memo, and this was an introduction to a post or review of Netspark which is obviously done and make analysis software, that the premise is really the... it's kind of the point I made earlier where unless developers actually understand the execution of the risks it's very hard to get them to mitigate them properly. A really good example is I've seen a lot of findings recently for websites that don't have a cross frame origins hitters in order to prevent click checking attacks. Developers will get this and they'll go, "Well what do I do with this? What is this XFO hitter? Why do I need this? How does it work?" So it's fantastic that tools can find things like that and finding something like a missing XFO hitter is dead-simple and in terms an automatable process. I want to make sure that people understand what is the value proposition of doing this because again if they're not invested in that process and invested in what the upside of it is for the organization, it's very hard to get them to actually invest the time to mitigate it properly and not just make a scan pass.

Jeff Williams: Yeah. It's tough because oftentimes developers are busy building awesome logic and building awesome apps. They don't want to spend the time to learn about options or some obscure security saying.

Troy Hunt: Yeah. I think that's true to a degree. I guess we could say that in a way security is not a deliverable. It's normally not there on the requirements list. It's kind of implied but it's implied in the same way that performance is implied in that they're both pretty essential and if you don't do them it may seriously jeopardize the success of your app. I do think though that when developers can get in and play with things and when they sort of get a little bit of an introduction, they do actually enjoy it. They sort of get pleasure out of the process. Certainly when I go, and present, and show people things, everybody seems to get really involved. [Laughs] By all accounts they like watching my courses and things but they've got to be given the opportunity because they don't know what they don't know, right?