Collaborate Disseminate
I spend a lot of time on Have I been pwned (HIBP) which consists of both maintaining and building out the software with new features as well as obviously sourcing new data for it on a regular basis. I make it freely available to the community and some time ago
Continue reading Breaches, “Have I been pwned?”, password reuse, 1Password and good deeds
Last month I was over in Norway doing training for ProgramUtvikling, the good folks who run the NDC conferences I’ve become so attached to. I was running my usual “Hack Yourself First” workshop which is targeted at software developers who’d like to get up to speed on the things they should be doing to protect their apps against today’s online threats. Across the two days of training, I cover 16 separate discrete modules ranging from SQL injection to password cracking to enumeration risks, basically all the highest priority security bits modern developers need to be thinking about. I also cover how to inspect, intercept and control API requests between rich client apps such as those you find on a modern smart phone and the services running on the back end server. And that’s where things got interesting.
One of the guys was a bit inspired by what we’d done and just happened to own one of these – the world’s best-selling electric car, a Nissan LEAF:
What the workshop attendee ultimately discovered was that not only could he connect to his LEAF over the internet and control features independently of how Nissan had designed the app, he could control other people’s LEAFs. I subsequently discovered that friend and fellow security researcher Scott Helme also has a LEAF so we recorded the following video to demonstrate the problem. I’m putting this up front here to clearly put into context what this risk enables someone to do then I’ll delve into the details over the remainder of the post:
We elected for me to sit outside in a sunny environment whilst Scott was shivering in the cold to demonstrate just how remote you can be and still control feature of someone else’s car, literally from the other end of the earth. Following is a complete walkthrough of the discovery process, how vehicles in other countries can also be controlled and a full disclosure timeline of my discussions with Nissan.
The LEAF is an electric car which is particularly popular in countries like Norway which offer massive financial incentives to stay away from combustion engines. It does all the things you’d expect of a modern EV and because it’s here in the era of the internet of things, it also has a companion app:
Back at my workshop in Oslo and being the curious type, Jan (not his real name – he requested to remain anonymous) goes back to his hotel after the first day of the course and proxies his iPhone through Fiddler running on his PC as we’d done during the day (this was on January 20). This takes a few minutes to setup and effectively what it means is that he can now observe how the mobile app talks to the online services. Jan then fires up the NissanConnect EV app:
I’m using publicly available screen grabs of the app in part so as not to disclose personal information about Jan and part because his app runs in Norwegian. When the app opens, he observes a request like this (I’ll obfuscate host names and the last five digits of VINs throughout this post):
GET https://[redacted].com/orchestration_1111/gdc/BatteryStatusRecordsRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris&TimeFrom=2014-09-27T09:15:21
Which returns the following JSON response:
This is pretty self-explanatory if you read through the response; we’re seeing the battery status of his LEAF. But what got Jan’s attention is not that he could get the vehicle’s present status, but rather that the request his phone had issued didn’t appear to contain any identity data about his authenticated session. In other words, he was accessing the API anonymously. It’s a GET request so there was nothing passed in the body nor was there anything like a bearer token in the request header. In fact, the only thing identifying his vehicle was the VIN which I’ve partially obfuscated in the URL above.
The VIN is the Vehicle Identification Number which uniquely identifies the chassis of his LEAF. It is by no means a “secret” suitable for authorisation purposes, the significance of which I’ll come back to shortly.
On the surface of it, it looked like anyone could get the battery status of Jan’s vehicle if they knew his VIN. Not ideal, but not exactly serious either as it’s a passive query (it doesn’t actually change anything on the vehicle) and there’s also nothing of a personal or sensitive nature returned in the response beyond potentially telling you when it was last driven based on the OperationDateAndTime field. So Jan kept looking.
He found he could check the status of the climate control using this request:
GET https://[redacted].com/orchestration_1111/gdc/RemoteACRecordsRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX
Which then returned a similar status result:
This is reflected within the app on this screen:
But again, it’s passive data – is the climate control on or off and as a result, what should the buttons say. But then he tried turning it on and observed this request:
GET https://[redacted].com/orchestration_1111/gdc/ACRemoteRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris
That request returned this response:
This time, personal information about Jan was returned, namely his user ID which was a variation of his actual name. The VIN passed in the request also came back in the response and a result key was returned.
He then turned the climate control off and watched as the app issued this request:
GET https://[redacted].com/orchestration_1111/gdc/ACRemoteOffRequest.php?RegionCode=NE&lg=no-NO&DCMID=&VIN=SJNFAAZE0U60XXXXX&tz=Europe/Paris
All of these requests were made without an auth token of any kind; they were issued anonymously. Jan checked them by loading them up in Chrome as well and sure enough, the response was returned just fine. By now, it was pretty clear the API had absolutely zero access controls but the potential for invoking it under the identity of other vehicles wasn’t yet clear.
When Jan came into the workshop the following day, he also brought in a picture he’d managed to locate by searching the web:
This was the vehicle’s VIN which clearly, left us curious (obfuscation is mine, it’s legible in its entirety on the web).
Let me clarify something before going any further and it’s something I harp on about in my workshops too; when a potential security flaw is identified, you’ve got to think very carefully about how you proceed with verification. You need to have a sufficient degree of confidence that it’s a legitimate flaw before reporting it ethically (which is what we ultimately did), but you also need to ensure you don’t breach someone else’s privacy or impact them adversely in any way. We wouldn’t, for example, want to start operating mechanical features of someone else’s car such as turning on the climate control nor would we want to retrieve personal information about them, even if it was just their username.
The VIN above differed merely by the last 5 digits. We grabbed the number and plugged it into the request to get the battery status – a request that didn’t change anything nor disclose anything private – and got this response:
This appeared to indicate that the response couldn’t be processed but it wasn’t clear why. On reflection, it’s possible that the VIN hadn’t been registered for the app. It could also be possible that one of the query string parameters in the first URL I shared above wasn’t valid for that VIN. For example, the RegionCode field may not have matched with the vehicle’s location. Without a positive result from the API, we couldn’t emphatically conclude that there was indeed a lack of authorisation.
The thing about VINs though is that they’re easily enumerable. Both Jan’s and the VIN found on the web were identical except for the last 5 digits which meant we could easily test for other matches using a tool like Burp suite. We proxied Chrome through Burp then issued the battery status request again:
We then sent it over to the Intruder feature and added one position for payload insertion:
This was the last five digits of the VIN, those being the ones which differed across both Jan’s and the number found online. (Note: not all LEAF VINs necessarily differ by just the last 5 digits, the VIN specification allows for the range to be broader, i.e. it may be the last 6 digits. Our test simply kept the range constrained between known numbers for the sake of time.) We then configured Burp to randomise those last 5 digits and choose integers between 10,000 and 30,000 which is the range both Jan’s and the VIN online fell within:
This gave us the ability to issue requests one after the other, each differing only by a unique VIN in the payload column. We didn’t need to test all 20,000 possible VINs within that range, we just had to issue requests until we found one that returned the battery status of another vehicle. We started Burp issuing the requests:
Request 0 in the screen above is the one to Jan’s car which returned a response size of 631 bytes. The subsequent responses with the randomised VINs mostly returned 288 bytes and the response you see in the screen above. Until we found one that didn’t:
This wasn’t Jan’s car; it was someone else’s LEAF. Our suspicion that the VIN was the only identifier required was confirmed and it became clear that there was a complete lack of auth on the service.
Of course it’s not just an issue related to retrieving vehicle status, remember the other APIs that can turn the climate control on or off. Anyone could potentially enumerate VINs and control the physical function of any vehicles that responded. That’s was a very serious issue. I reported it to Nissan the day after we discovered this (I wanted Jan to provide me with more information first), yet as of today – 32 days later – the issue remains unresolved. You can read the disclosure timeline further down but certainly there were many messages and a phone call over a period of more than four weeks and it’s only now that I’m disclosing publicly, right after I received an email from a Canadian follower…
By pure coincidence, just as we hit the four-week mark since initial disclosure and I was about to revert to Nissan yet again, an email landed in my inbox from a Canadian follower titled “weird Nissan api”. It started out like this:
I read your Vtech article and though that you would be well placed to appreciate this.
Im a Nissan Leaf owner and I found out that Nissan security is pretty abismal. They have an App to remote start charging, start/stop the AC/Heat, and get updated on current state of the vehicule.
http://itunes.apple.com/ca/app/nissan-canada-leaf/id450031231?mt=8
This came in just last weekend on 20 Feb and it went on to explain the following:
I found out that the whole API is unauthenticated and only require the VIN to target a vehicle. To add insult to injury those action are from simple http Get request.
details on how to: (site in french) http://menu-principal-forums-aveq.1097349.n5.nabble.com/Nissan-Canada-Leaf-Carwings-td37239i20.html#a38494
This is precisely what Jan had found in Oslo and what’s more, it was being discussed openly on a forum. Browsing through the discussion courtesy of Google translate, clearly people were not happy with the Nissan app. In fact, they were so unhappy that one post suggests taking the app out of the picture altogether and controlling the vehicle’s functions by making requests directly to the APIs:
For hard-core, the following information:
URL to activate / deactivate air conditioning / heating. Put your VIN in the URL, this works very well in your browser. Create bookmarks with these 2https://canada.nissanconnect.com/owners/leaf/setHvac?vin=1N4A…..5520&fan=on
https://canada.nissanconnect.com/owners/leaf/setHvac?vin=1N4A…..5520&fan=off
They go on to conclude precisely what we had earlier on:
In all this, it works for me without being authenticated, which is very surprising, and not safe at all, this means that anyone can act on any vehicle, provided it knows the VIN (in more is it not written down the visible windshield everyone?). Looks like the authentication uses has get the VIN in the user profile.
Now this was back in December so we’re talking a couple of months ago already. Note also that the URLs above are different to the API endpoints we saw for the Norwegian instance (I obfuscated the other host names as I’ve not seem them discussed publicly, but even the paths are different). It’s an odd design decision for a global car manufacturer to segment their app in this way. There are always local idiosyncrasies to be considered (particularly in the auto industry), but there appears to be very little reuse across Canada and Norway in terms of how the API is implemented. It has me wondering if perhaps the build of these apps is delegated to local groups who perhaps don’t pass through the same levels of rigour you’d expect at the global level.
The person who reported the Canadian finding to me finished up by saying this:
My hypothesis on this is that it was bound to surface due to the poor quality of the app, the more tech savvy “with free time” users will thinker with broken things to get them working for them. The fail was probably discovered soon after the app change and multiple times but by people that didn’t fully appreciate the greater implication or by people like me that didn’t know what to do with that knowledge.
His first sentence is spot on – the ease of discovery of this risk is high as is evidenced by three separate parties already finding it independently (my Norwegian student, the Canadian follower and the folks in the forum). The Norwegian case alone was cause for concern and the Canadian one showed that the issue was now well and truly out there in the public domain, but I wanted further verification which is where Scott Helme came into the picture.
It was by pure coincidence that Scott Helme from the video in the intro has a LEAF, that he’s a security professional and that I spent some time with him in the UK just after my Oslo workshop. It was then that the penny dropped and we both realised that he could be of assistance. He’s proofed everything I’ve written here and obviously also offered up his own car to verify that indeed, it’s only the VIN required to operate the functions described in this blog post. Given his involvement, I asked him if he wouldn’t mind sharing his own view of the situation and he gave me this paragraph:
Fortunately, the Nissan Leaf doesn’t have features like remote unlock or remote start, like some vehicles from other manufacturers do, because that would be a disaster with what’s been uncovered. Still, a malicious actor could cause a great deal of problems for owners of the Nissan Leaf. Being able to remotely turn on the AC for a car might not seem like a problem, but this could put a significant drain on the battery over a period of time as the attacker can keep activating it. It’s much like being able to start the engine in a petrol car to run the AC, it’s going to start consuming the fuel you have in the tank. If your car is parked on the drive overnight or at work for 10 hours and left running, you could have very little fuel left when you get back to it… You’d be stranded
Of course the other thing we covered in the video was pulling the driving history from the vehicle which looks like this:
These are two trips he took on Feb 21 when he dropped his son off at his parents. He took two other trips that day, one to go snowboarding and another one to return. They were all recorded by the vehicle and are publicly accessible if you know his VIN which again, is displayed in his windscreen or can simply be guessed by enumerating through those last five digits.
This gives you details on movements per day which raises all sorts of privacy risks. Scott gave me a comment on that too.
The other main concern here is that the telematics system in the car is leaking *all* of my historic driving data. That’s the details of every trip I’ve ever made in the car including when I made it, how far I drove and even how efficiently I drove. This could easily be used to build up a profile of my driving habits, considering it goes back almost 2 years, and predict when I will be away from home. This kind of data should be collected and secured with the utmost respect for my privacy.
Whilst it’s not specifically personally identifiable information such as the individual’s address, by the time you have a VIN which you know belongs to a LEAF registered within a specific country, it may not take too much effort to fill that gap. For example, down here in Australia we have services such as revscheck.com.au which can report on a pretty extensive set of data based on nothing more than a VIN. Jan sent me an equivalent service for Norway at vegvesen.no. I suspect that there are multiple other avenues where additional data about the vehicle and the owner can be retrieved once the VIN is known and that opens the door to a raft of other possible privacy risks.
The underlying risk is simple and I’ll quote Scott’s comments on it:
This API thing is just nuts. It’s not even like they just missed auth or didn’t check, it’s actually not implemented.
It was built, intentionally, without security…
Clearly the answer is to implement appropriate authorisation on all API calls, which when building an app in the first place would be a trivial feature to add. It’s trickier to add to a “brownfield” app though and in Nissan’s case, even trickier again because of the design of it. What’s unique about their approach is that Norway and the UK seem to be hitting a completely different set of APIs to Canada. In fact the European API is on a host not even owned by Nissan, it’s registered to “ZENRIN DataCom CO.,LTD.” which may mean that we’re looking at multiple API endpoints controlled by different parties that need to be rectified. Then of course the apps have to be updated across different client devices (iOS, Android, etc) and for different languages then pushed out to consumers. Whilst waiting for this to happen, LEAF owners remain at risk.
Because the question would inevitably arise, I asked Scott how he’d opt out of the service and he provided some steps:
Given the ease with which someone can enumerate valid VIN numbers, this issue raises a few concerns. It could be a huge inconvenience to have someone run my car flat by using the heating and accessories all day and the exposure of my entire driving history poses quite the privacy concern too. To disable CarWings, owners need to login to the service form their browser, it can’t be done through the mobile app. Once logged in, select ‘Configuration’ from the menu and there is a ‘Remove CarWings’ button. It appears to be greyed out but the button does work. Once clicked you will receive a prompt to confirm that you wish to disable CarWings and asked to provide a reason why. Click ‘Validate’ when the appropriate option has been selected and you will get a confirmation message that CarWings has been disabled. You should also receive a confirmation via email. Once Nissan have resolved this issue it should be safe to re-enable your CarWings account and resume using features associated with it. Simply login to your account and follow the prompts on screen.
Nissan’s “CarWings” is their telematics service and it’s accessible in the UK via this page on their website (other countries will have different URLs).
One of the key factors in publishing this now is the existence of multiple other public discussions about the unauthenticated API. The fact that only the VIN is required to invoke these services has been covered at length and published in locations including:
Whilst I haven’t linked directly to the resources, they’re easily discoverable via Google and demonstrate that there is ongoing public discussion via multiple channels, each documenting the lack of authorisation on the services.
I made multiple attempts over more than a month to get Nissan to resolve this and it was only after the Canadian email and French forum posts came to light that I eventually advised them I’d be publishing this post. Here’s the timeline (dates are Australian Eastern Standard time):
All in all, I sent ten emails (there was some to-and-fro) and had one phone call. This morning I did hear back with a request to wait “a few weeks” before publishing, but given the extensive online discussions in public forums and the more than one-month lead time there’d already been, I advised I’d be publishing later that night and have not heard back since. I also invited Nissan to make any comments they’d like to include in this post when I contacted them on 20 Feb or provide any feedback on why they might not consider this a risk. However, there was nothing to that effect when I heard back from them earlier today, but I’ll gladly add an update later on if they’d like to contribute.
I do want to make it clear though that especially in the earlier discussions, Nissan handled this really well. It was easy to get in touch with the right people quickly and they made the time to talk and understand the issue. They were receptive and whilst I obviously would have liked to see this rectified quickly, compared to most ethical disclosure experiences security researches have, Nissan was exemplary.
Just one last thing on how these vulnerabilities are discovered and reported because the ethics of this often comes up in my workshops. Risks like the one above were discovered by doing nothing more than using the app as it was intended to be used and observing the traffic going backwards and forwards. This is the mobile equivalent of opening your browser’s dev tools and watching the network tab. Sometimes (such as with the realestate.com.au vulnerability I reported last year), this is all that’s required. Other times and as was the case with the LEAF, it meant testing that the theory of one user being able to access another user’s resource could be proven. In a situation where it’s a car involved, you can’t exactly head out and buy a second one in order to prove that when accessing one you can change a parameter to access another and whilst the proof above did involve checking the battery status of another vehicle, it didn’t involve accessing any personally identifiable information or disadvantaging anyone in any way.
To me, it’s this simple: if the intent is ethical and any findings are reported privately and immediately the moment you’re confident a serious risk is present – and especially if it can be done without viewing anyone else’s private date – then I’m comfortable that’s in everybody’s best interests. If you report before being confident there’s a risk you end up wasting people’s time and if you don’t report, then you end up leaving people – and the organisation involved – at risk. A post such as this one is reviewed dozens of times over by myself and where possible, a peer or peers (Scott, in this case) to ensure fairness and accuracy.
Nissan need to fix this. It’s a different class of vulnerability to the Charlie Miller and Chris Valasek Jeep hacking shenanigans of last year, but in both good and bad ways. Good in that it doesn’t impact the driving controls of the vehicle, yet bad in that the ease of gaining access to vehicle controls in this fashion doesn’t get much easier – it’s profoundly trivial. As car manufacturers rush towards joining in on the “internet of things” craze, security cannot be an afterthought nor something we’re told they take seriously after realising that they didn’t take it seriously enough in the first place. Imagine getting it as wrong as Nissan has for something like Volvo’s “digital key” initiative where you unlock your car with your phone.
By pure coincidence, this week Nissan unveiled a revised LEAF at the GSMA Mobile World Congress. Clearly, like many car makers, their future involves a strong push for greater connectivity in their vehicles:
In a fully connected, fully mobile world, in-vehicle connectivity is an absolute must for today’s drivers. That is why Nissan is proud to be at the forefront of developing efficient and reliable in-vehicle connected technologies that are available and accessible to all
Amongst the list of features the media release talks about being added to the NissanConnect app is the ability to remotely show the vehicle position on a map and analyse your driving. Whilst there are obvious upsides to drivers having access to these features, seeing them presented within the security implementation of the current app would be very worrying for obvious reasons.
I would have preferred to see faster action from Nissan. In my view, this is the sort of flaw that needs to have the service pulled until it can be fixed properly and restored; it’s not a critical feature of the vehicle yet it has the potential to impact its physical function and there’s the privacy risk as well. Plus of course it’s already being discussed publicly via that Canadian forum so the risk is well and truly out in the public domain already. I want to see Nissan secure this; I own a Nissan myself (albeit not a connected one) which I’m passionate about and am very invested in the brand, both emotionally and financially. But they do need to take action on this because clearly the current state is not satisfactory.
Update 1, 25 Feb, 12:00: Nissan has now taken the service offline.
Update 2, 25 Feb, 14:20: Per the comment below and further correspondence I’ve had via email, it appears that Canadian resources are still accessible using only the VIN.
Continue reading Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs
Last month I was over in Norway doing training for ProgramUtvikling, the good folks who run the NDC conferences I’ve become so attached to. I was running my usual “Hack Yourself First” workshop which is targeted at software developers who’d like to get up
Continue reading Controlling vehicle features of Nissan LEAFs across the globe via vulnerable APIs
There are few more valuable skills for kids these days than knowing their way around technology. In fact, I’d argue that you could say the same for adults but particularly when you consider the skills that are going to be most valuable in the future for our children, understanding how the connected world functions is key. Their existence is fundamentally different to ours and if you were born in the 70’s like me (or even earlier), just think about how fundamentally different their education and social interactions are; we had no Wikipedia to refer to, no online discussions to ask questions in and frequently, not even a PC to type on (I was a teenager before my family had one). On the other hand, we had no social media to make dicks of ourselves on the public record nor camera phones to permanently record our misdeeds. Making tech savvy kids is not just about leveraging the technology for good, but ensuring they grow up using it responsibly.
I have a three-year-old daughter for whom technology is little more than Netflix and the occasional iPad puzzle. But I also have a six-year-old son – Ari – in his first year of school and I’ve been thinking about the best way of getting him more involved in technology in some sort of a coordinated, planned way as opposed to just allowing it to happen implicitly. I don’t necessarily think that six is the right age for all kids, but Ari tends to be quite conscientious and patient (virtues he’s more likely inherited from Kylie rather than me!), which predisposes him to sitting down and learning.
Entirely unexpectedly yet at the perfect time in his development, an opportunity presented itself when Lenovo sent me over a Yoga 900 (read the bit about Lenovo at the end of this post for the background, I want to focus on kids coding first). The best possible use I could think of for the machine was to give it to this guy:
Let me show you the first thing we’ve got him working on.
I get a lot of questions from people about how to get their kids involved in tech and what they should be learning so with this opportunity now presenting itself, I thought the best thing to do is use Ari to help answer those questions. I’ll try and keep this series going as I find good resources for kids and as he picks up new skills, but where I thought we’d start is with code.org. I used this site as part of the Hour of Code event in December when I helped out at the Microsoft store in Sydney, watching as kids of all ages started to learn the fundamentals of what it means to create software. It’s totally free and it’s all browser based so there’s nothing to install and it’ll work on most operating systems and devices.
Here’s how Ari went on his new machine:
In case you’re thinking “Hey, this doesn’t look like code”, take a step back for a moment and have a think about the behaviours he’s learning and these will particularly resonate if you’re from a software background yourself:
These are behaviours that are foundational to creating software and they’re all things I’ve done thousands of times before. I love that it’s all wrapped up in Minecraft (and other genres, for that matter), as it obviously increases the “stickiness” for kids and particularly at this age, they grow tired of things very quickly if you can’t keep them engaged.
I honestly have no idea, but I’ve taken inspiration from my mate Adam Cogan and I wanted to share what I think is just an outstanding result for getting kids involved in tech. Both his daughters started writing a blog and recording YouTube videos at a very early age. Eve’s blog was started four years ago when she was 10 and Ruby’s blog began when she was only 8. Have a flick through and consider the positive exposure they’re getting to technology and how they’re using that opportunity. Especially when watching their videos, you get a sense of the presence they’re starting to carve out for themselves online and how their familiarity with the technology is helping them not just with their studies now, but is paving the way for their future professional aspirations.
I’m sure there’ll be people who feel that level of exposure that early is too much and I’m sure that’s the case for many kids. It may be for Ari too, I don’t know yet, but I love the idea of being able to give kids the opportunity to embrace technology in such a positive, constructive way.
Let me set some context as to why Ari has this machine; I started buying Thinkpads in about 1996 back when they were made by IBM. They were rugged machines and mine travelled with me around the world in ‘99 when I spent a year overseas. Much of what I do today had its genesis in that machine; that was when I really started getting involved in the Microsoft stack, particularly classic ASP and SQL Server. When I arrived at Pfizer in 2001, Thinkpads were the standard machine and for the next 14 years, that’s all I used, even as Lenovo took over the PC business from IBM in ‘05. Even when I purchased my own machines, it was always a Thinkpad and in fact I’m writing this on my W540 that I purchased in 2014 which has now been around the world a dozen times and still feels like new.
I obviously share a lot of what I do via social media and frequently that includes pics of what I’m working on – literally the machine I’m working on – and combined with a healthy Twitter following, that makes for influence so they invited me into their Insiders program. I provide them with feedback on some of their product strategies and they occasionally send me Lenovo products. I always prioritise independence and yes, that includes expressing views on controversial things like Superfish (I have something specific in mind I want to write on this). By reading this blog you’re probably a lot like me in terms of most new technologies and gadgets exciting you and I’m genuinely enjoying exploring products I wouldn’t have previously thought to pay much attention to (how I ended up using the Yoga Tab 3 Pro is a perfect example!)
But the Yoga 900 really is a great device. I already had one which is now my default machine on planes or when doing things like email (I tend to save the bulkier W540 for things like coding and video editing). It’s also a perfect device for kids because it can do the tablet thing as well as being used as a normal PC with a proper keyboard. Plus, it’s a very sturdy piece of kit which I hope will be resilient to the inevitable battering that kids tend to give just about everything they get their hands on.
I’d love to hear suggestions from people about either what I should be teaching Ari next or what you’d like to know in order to help you support your kids. If it’s something we can make a useful video out of then we’ll give it our best shot!
Continue reading Kids and Code: Simple programming on code.org
There was a piece in the news the other day on how a high school teacher videod his sexual exploits then stored them on Dropbox, after which it was summarily compromised. The video was then posted to the school’s faculty page which obviously caused him enormous embarrassment then to top it off, the school fired him. This is a newsworthy story with regards to privacy and security and was worth sharing:
Probably don’t put these in Dropbox: “Teacher’s sex tape stolen from hacked Dropbox, posted on school site”: https://t.co/WaPlqqsbG8
— Troy Hunt (@troyhunt) February 18, 2016
There are many things wrong with this case totally outside the poor bloke’s control. Someone shouldn’t have illegally accessed his account. They shouldn’t have then posted his video. Kids then shouldn’t have shared stills of it via Snapchat. The school shouldn’t have fired him for it (the basis of which isn’t made clear in the story). The guy is the victim yet he well and truly got the short end of the straw.
In my rather analytical mind, there would have been an easy way to avoid this:
Yes, you have the right to privacy…
However, you can’t lose what you don’t have so maybe consider that too— Troy Hunt (@troyhunt) February 18, 2016
Makes sense, right? In fact, it’s a long held security truism applied time and again to system design – “Hey’’, let’s not capture birthdate / gender / sexuality if we don’t absolutely need it because that way, we can’t lose it”. It is the most fundamentally simple of principles.
Having travelled this path before, I expected someone might pull out the “victim blaming” card and this occasion didn’t disappoint:
@troyhunt Be careful, telling people not to put sensible data in the cloud is called “victim blaming” nowadays and makes you an evil sexist.
— jdax (@jdax) February 18, 2016
The issue of how “sensible” this data is aside, this is a term that has been popularised in the wake of numerous other similar incidents. These are cases where someone has recorded intimate photos or videos of themselves then lost control of them, after which many people say “it probably would have been better not to have recorded that in the first place”.
Sure enough, sooner or later, someone inevitably pulls the old line out:
@troyhunt victim blaming much?
— Rushed Kludge (@lolkthen_) February 18, 2016
Let’s get away from this ridiculous term for a moment – “victim blaming” – because that’s not what it is at all; no blame is being apportioned at the victim. It’s not saying that it’s their fault someone broke into their account and stole their personal files (although it’s highly likely in this particular case the guy was missing fundamental security controls such as multi step verification), rather that they are empowered to choose what they digitise and if they chose not to digitise their sex tapes or dick pics or whatever it is that would cause them great embarrassment should it be released, then it would not be released because it wouldn’t exist!
Same again with this one:
This is a horrible argument. By the same logic I’m to blame for getting hacked in the vtech hack… wrong https://t.co/X7bvC3wX0g
— Ben Dornis (@buildstarted) February 18, 2016
No, of course he’s not “to blame”, Ben made a judgement decision that most of us would consider perfectly reasonable by entrusting VTech with exactly the same class of data we’ve all trusted dozens of websites with. If Ben likes to take dick pics and backs them up to iCloud then gets them pwned per The Fappening of 2014, the person who compromises his account and leaks pictures of Little Ben is the one we should blame. However, Ben can choose whether he wants to expose himself (pardon the pun) to that risk or not by deciding whether Little Ben should be recorded for perpetuity in a way that may lead to redistribution in the future.
He did clarify a little later on though:
@troyhunt the way you wrote it suggested that if they didn’t have the video nothing bad would have happened but that just means you’d have
— Ben Dornis (@buildstarted) February 18, 2016
Yes! When I say that “you can’t lose what you don’t have”, I mean that if that bloke didn’t have a sex tape then it wouldn’t have been made public and that is simply not up for debate, it’s an immutable fact. If you digitise content of that nature, then you must also accept that it could one day be made public because that’s just simply the nature of a connected world. It’s not right – it sucks – and people like me spend a huge amount of our time trying to stop this sort of thing from happening in the first place. But people like me also give advice like I did in the tweets – do your own risk assessment and consider whether this is a wise thing to do.
Let me leave you with some suggestions because by no means do I want to deprive anyone of their inner voyeur. Here’s a good option for sex pictures:
You get a nice printout that you can store somewhere offline and because there’s no digitisation you dramatically reduce your attack surface (don’t then scan these and put them in your Dropbox though). They’re effectively “air-gapped” from the connected world which from a pure risk perspective, makes a lot of sense.
If videoing your sexual exploits is more your style, have a go at one of these:
It records direct to VHS and you can then whack it in your video player and relive the moment over and over again from the privacy of your own home. Like the polaroid option, it’s not digitised so you can’t accidentally back it up to the cloud and frankly, even copying them is a pain in the arse. It’s not fool proof mind you, let us not forget the Pamela Anderson and Tommy Lee situation in the late 90s, so do consider how you store the tapes once they contain sensitive footage.
Yes, this is somewhat tongue-in-cheek but the point is that if you want to capture these moments in time then there are ways of minimising your risk. People have every right to do exactly what this guy did but the stakes are very high if it all goes wrong and they should think carefully about whether that’s a risk they want to take.
The “victim blaming” response frustrates the hell out of me and it’s political correctness gone mad. It’s up to you what you do and don’t put on the web in this fashion and you get to make the decision on whether or not you want to expose yourself to these risks. But there’s no two ways about it: if you choose not to record your sexual exploits and put them in Dropbox, they won’t ever be made public per the story above. Call it what you want, but it’s that simple.
Some days, the news is dominated by a single security story and not just in the tech news either, but today the consumer news is all about Apple’s message to their customers. I’ve been getting a heap of media requests and seeing some really interesting things said about the story so let me distill all the noise into the genuinely interesting things that are worth knowing. There are way more angles to this than initially meet the eye, and it’s a truly significant point in time for online privacy.
In December last year, 14 people were killed and a bunch more injured in a mass shooting in San Bernardino, California. The FBI have said that the couple responsible for the incident had been radicalised by Islamic extremists and Obama consequently defined the shooting as an act of terrorism. Both shooters were subsequently killed in a fire fight with police.
The relevancy to Apple is that in the aftermath of the event, the FBI located one of the suspect’s iPhones but due to the effectiveness of Apple’s encryption, were unable to gain access to the information stored on it. Since iOS 8, Apple has stated that it “would be impossible” for them to decrypt a device since they don’t hold the encryption keys nor do they have any backdoors that would provide them with access. Consequently, the contents of the San Bernardino shooter’s iPhone have not been recoverable by the FBI.
This week, a judge in California ordered Apple to assist the FBI in accessing the contents of the San Bernardino shooter’s iPhone. Whilst it’s not been explicitly said exactly what information the FBI is seeking from the device, you could reasonably assume that they’ll be particularly interested in communication that the perpetrators had with other parties particularly given that “radicalised” implies they were coerced by others into holding extremist beliefs.
The privacy ramifications aside, there’s no doubting that there is information on the device that’s extremely valuable for legitimate law enforcement purposes. We want the FBI to track down anyone involved not just with this particular case, but responsible for influencing others to carry out similar attacks. The point of contention now is whether the court’s demand is in the public’s best interest or not.
One of the really interesting things we’ve seen as a result of the Ed Snowden leaks in 2013 is a visible shift in the positioning of privacy as a feature. To be fair, we were organically moving towards more encryption more of the time regardless of the NSA revelations, but inevitably that accelerated the shift and highlighted the need for both data encryption during transport over the web and at rest on devices.
It’s been interesting to watch Apple in particular highlight this. For example, their position on end-to-end encryption of iMessage and FaceTime which they call out in their iOS 9 feature list:
Conversations over iMessage and FaceTime are encrypted, including predictive text — so no one but you and the person you’re talking to can see or read what’s being said.
What’s intriguing about this approach is that when it works well, encryption is transparent. This is not a feature like you’d see showcased in an Apple product launch, not like Live Photos or even Touch ID. Consumers don’t “see” the encryption of iMessage nor the fact that evidently, without being able to unlock the device the data can’t even be read whilst at rest. In fact, you could even argue that so far this case around the court order had been very good publicity for Apple and you can just picture Tim saying “Your privacy is so important that we’re not even going to back down in the face of a legal demand from the US government”.
Apple has been quite smart in the way they’ve gone about their encryption insofar as they’ve effectively tied their own hands. By not holding keys they simply can’t bow to court orders to hand over data which is what makes this present situation quite unique. In this case, the court has had to ask for something quite different to the data itself…
There’s a bit of playing with words going on here and each side is clearly going to pick the ones that best serve their purposes. In Tim’s customer letter, he says the following:
The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor.
To which the DoJ says this:
BREAKING: White House says Department of Justice is not asking Apple to create a new backdoor, asking for access to one device.
— Reuters Top News (@Reuters) February 17, 2016
But it also begs the question – what exactly are the mechanics of gaining access to the data on a phone which is meant to be encrypted? Here’s the actual court order and specifically the assistance expected from Apple:
Apple’s reasonable technical assistance may include, but is not limited to: providing the FBI with a signed iPhone Software file, recovery bundle, or other Software Image File (“SIF”) that can be loaded onto the SUBJECT DEVICE. The SIF will load and run from Random Access Memory and will not modify the iOS on the actual phone, the user data partition or system partition on the device’s flash memory. The SIF will be coded by Apple with a unique identifier of the phone so that the SIF would only load and execute on the SUBJECT DEVICE. The SIF will be loaded via Device Firmware Upgrade (“DFU”) mode, recovery mode, or other applicable mode available to the FBI. Once active on the SUBJECT DEVICE, the SIF will accomplish the three functions specified in paragraph 2. The SIF will be loaded on the SUBJECT DEVICE at either a government facility, or alternatively, at an Apple facility; if the latter, Apple shall provide the government with remote access to the SUBJECT DEVICE through a computer allowing the government to conduct passcode recovery analysis.
Assuming that there genuinely aren’t any backdoors on the device at present, the approach seems to be to modify iOS (and Apple would need to digitally sign the software so the feds can’t do it themselves) such that it explicitly does have a weakness built into it, namely the ability to continually retry passcodes or in other words, brute force the locked device.
This weakness would rightly be classified as a backdoor, even if only a backdoor on a single phone per the request to limit it to the “subject device”. But this is really the heart of the issue in that what Apple is saying is that once this intentionally vulnerable version of the operating system exists, it will be requested again. The genie will be out of the bottle and this will almost certainly be the first of many requests.
That’s what this case implies – that they can’t get into the device without Apple’s help – and of course it suits Apple just fine for that to be the status quo because per the previous point, privacy is a very important marketing feature for them. There’s no doubt that US intelligence services are looking for weaknesses in the devices and naturally other nation states are doing just the same. In security terms, we tend to speak about “degrees of difficulty” when it comes to compromising a system rather than an absolute state of secure versus insecure. When it comes to iOS, it’s highly likely that the bar has been set very high, even for an adversary as well-equipped as the US government. The recent million-dollar bounty Zerodium put on a remotely exploitable iOS 9 jail break goes some way to demonstrating just how difficult it is to compromise the latest iOS version. (Note that the bounty was paid but a remote jail break is a far cry from decrypting a locked device.)
One theory is that even if the device is accessible via the FBI, they’d prefer to see this case go to trial:
if the gov hacks the iPhone themselves, they don’t get the legal precedent they are so desperate to establish in this case.
— Christopher Soghoian (@csoghoian) February 17, 2016
It’s an interesting point Chris makes and if the FBI really did want to establish precedent more than they actually wanted to just access the data, this would be the case to do it with. San Bernardino is the personification of what the government has tried so hard to convince the US population they need to be fearful of – terrorist acts on home soil. This case would garner more sympathy from the general populace than a one-off shooting or even a child abuse case because it’s precisely the thing that most people are so fearful of.
I suspect the most likely scenario is that firstly, Apple have genuinely not built any intentional backdoors into the device. Doing so and then being discovered (and certainly there are many other precedents of backdoors being identified by other researchers in other products), would be absolutely catastrophic for the brand when they’re pushing privacy so hard. Secondly, there are certainly various exploits available both developed by nation states and via the likes of Zerodium but it’s entirely possible that they don’t include the ability to decrypt a locked iOS 9 device. All speculation aside though, we just don’t know for sure but to Chris’ point, the outcome would be very a valuable precedent to set for either party.
Apple is presently the most valuable company in the world at $544 billion. They also have a cash stockpile of more than $200 billion so it would be fair to say they’re well-equipped for legal challenges. Consider also how high the stakes are; I’ve just talked about privacy as a feature and how much of their reputation they’re now staking on being a privacy-focused company. If they were to be forced into building the backdoor Tim talks about in his letter, there’d be enormous damage done to their brand, perhaps irreparable damage and for Apple in particular, image is everything.
This is a case that Apple is both well-equipped to fight and needs to fight. Not only that, but they’ve got a lot of public support from informed people that grasp the ramifications of what the court is asking them to do. They’ll throw serious resources at this and at the very least, it will likely be a protracted exercise regardless of the outcome. That in itself is significant because assuming the DoJ wants access to the device in order to establish connections and communications with other parties, time is important. How much value does the data hold if legal proceedings play out for years? What’s the half-life of this class of data and even if it’s short lived, how likely is the government to back off given the value of setting a precedent as I mentioned earlier?
Think back to 2013 – early 2013 – and the years leading up to it. Think specifically about Huawei, the Chinese manufacturer that builds a heap of networking products sold around the world. Well they were sold around the world until the US government banned them from selling to certain government departments due to the concerns around state-sponsored Chinese backdoors. This prompted Huawei to completely withdraw from the US market due to “geopolitical reasons”.
That was in April, just one month before Ed Snowden headed off to Hong Kong to release the troves of data he exfiltrated from the NSA, including information on their “Tailored Access Operations” program:
This is a picture of “supply chain interdiction” or in other words, intercepting routers en route to customers so that backdoors could be installed. Cisco were none too happy about this and swore black and blue it was news to them, but it also sheds some light on why the US would be so opposed to Huawei doing business locally; they want easier access to the supply chain so that they can compromise the devices themselves.
It goes both ways too and it was only a couple of years ago that China was doing the same thing regarding Windows 8. Going back even further, there were bans on Windows 2000 and Intel products for the same reason. The point is that the politics of the home state can have a huge impact on the global organisations attempting to do business on the world stage because we’ve consistently seen someone backdooring someone else. The bans on the products mentioned here were due to suspicions that other nation states were using them for espionage purposes (although I’m sure that behind closed doors these suspicions were probably proven on multiple occasions). Where does it leave the likes of Apple if they’re forced to bow to a highly publicised court order to backdoor their devices? Let’s look at what this means for the industry in the US.
There’s no escaping the impact that programs like the NSA’s PRISM have had on US tech companies:
The debate about how complicit these organisations were in PRISM aside, the very fact that we’re looking at data from US companies being retrieved directly by US intelligence services has had a major impact on the US tech industry. Indeed, this is undoubtedly one of the things that’s driven Apple to implement such strong encryption in the first place, but the impact is far broader than just.
For example, in increasingly privacy-conscious Europe, we’re seeing Microsoft now building out the Azure cloud platform in Germany such that their local telco Deutsche Telekom is the “data trustee”. In other words, all access to data in that location is now controlled by German law and as the headline in that link proclaims, the US government “can’t touch it”. It’s precisely because of programs like PRISM that a service of this nature is even in demand because quite simply, companies outside the US have lost trust in those within the US because of the impact of US government intervention.
The issue of data sovereignty is becoming particularly important as the example above highlights. Equally though, US companies are now going to great pains to demonstrate that local customers in international locations have a right to privacy and protection from US government overreach. The Microsoft case in Ireland is a perfect example of this where a legal case in the US has resulted in a request for data stored in their Ireland data centre. Microsoft is making a point of saying that “a U.S. judge has no authority to issue a warrant for information stored abroad” and that’s an enormously important position for them to take. Imagine the ramifications – imagine the damage the US government could do to Microsoft – if it transpires that they’re required to hand over that data. The loss of trust by international customers would have far-reaching ramifications.
The point as it relates to Apple and the FBI is that this case has the potential to do enormous damage not just to Apple’s international sales, but to other US based tech companies. Think about the impact in markets like China and India: here’s two countries with more internet connected citizens than the next twelve countries put together yet well under half their populations are even online. China in particular is the short to medium term growth market for Apple; given the friction already mentioned above between the two nations when it comes to trusting each other’s tech, what would be the impact of Apple granting the FBI access to the data?
One of the issues we always come up against when talking about backdoors is who gets access to them. Obviously the FBI wants to be able to force Apple into providing access to the data, but what if it’s the Australian Federal Police? Ok, we’re in bed together anyway courtesy of the Five Eyes arrangement, what about the Russian FSB? Should they be able to access this hypothetical backdoor if Apple builds it? What about China’s MSS?
If the US government dictating iPhone encryption design sounds ok to you, ask yourself how you’ll feel when China demands the same.
— Matthew Green (@matthew_d_green) February 17, 2016
The problem is that you’re talking about a multinational organisation attempting to run a global business then needing to get picky about who can exploit weaknesses deliberately designed into the product. It’s a very slippery slope once there is a backdoor. Without it, life is much simpler – nobody gets in – and clearly this is where Apple wants to be.
I’ll leave you with this tweet from Ed Snowden which is important in the context of the geopolitical ramifications of backdoors:
The New York Times: @FBI‘s war on #Apple will aid China. https://t.co/URWamc702q pic.twitter.com/KnHDsWIENY
— Edward Snowden (@Snowden) February 17, 2016
Remember, it was only a year ago that Obama was very vocal about China’s desire to have backdoors in products yet here we are, almost bang on 12 months later and we’re seeing the very same demand that so worried him about China issued directly from the US government.
One of the most insightful things I’ve read on the issue was this tweet by my friend Jeremiah Grossman:
Today would be the perfect day for Sundar Pichai (Google, CEO) to back up Tim Cook (Apple, CEO).
— Jeremiah Grossman (@jeremiahg) February 17, 2016
This is enormously poignant and it points to the need for a unified stance by the tech industry. When it’s Apple alone taking this stance (and obviously they’re the subject of the court order so you’d expect them to be the most vocal), it’s “The FBI v. Apple” when what we’d really like to see is Apple, Google, Microsoft and any other big players standing up and making this a tech industry issue, not an Apple issue. As I said earlier, the entire US tech industry has already been tarnished by the government, surely now is the time for a unified industry-wide stance?
However, shortly after Jeremiah’s tweet, Sundar Pichai did indeed speak up:
1/5 Important post by @tim_cook. Forcing companies to enable hacking could compromise users’ privacy
— sundarpichai (@sundarpichai) February 17, 2016
2/5 We know that law enforcement and intelligence agencies face significant challenges in protecting the public against crime and terrorism
— sundarpichai (@sundarpichai) February 17, 2016
3/5 We build secure products to keep your information safe and we give law enforcement access to data based on valid legal orders
— sundarpichai (@sundarpichai) February 17, 2016
4/5 But that’s wholly different than requiring companies to enable hacking of customer devices & data. Could be a troubling precedent
— sundarpichai (@sundarpichai) February 17, 2016
5/5 Looking forward to a thoughtful and open discussion on this important issue
— sundarpichai (@sundarpichai) February 17, 2016
The first tweet is refreshing; seeing the CEO of one of the world’s largest companies refer to one of their fiercest competitor’s positions in a favourable way is precisely what we want to see on such an important topic. (Keep in mind that Tim Cook has been critical of Google’s approach to privacy in the past too.) The subsequent ones water it down a bit though and I get the sense that Sundar’s position is far more fluid than Tim’s which as I mentioned earlier, has been staunchly in favour of strong encryption for some time now. Keep in mind also that due to the very long tail of old Android devices and low-spec hardware, most Android devices still don’t use full disk encryption so the court order is less of a pressing issue for Google than it is for Apple. (Incidentally, I looked for stats on Android disk encryption rates but couldn’t find anything authoritative, leave a comment with a link if you can point me at a resource.)
There’s a really good post over on the Trail of Bits blog which talks about the mechanics of how Apple can actually remove the brute force protection on the device and ultimately help the authorities gain access to the data. They make a very important observation that’s not often been represented elsewhere in the press and it’s this:
At this point it is very important to mention that the recovered iPhone is a 5C. The 5C model iPhone lacks TouchID and, therefore, lacks the single most important security feature produced by Apple: the Secure Enclave.
They explain how the Secure Enclave is a coprocessor within iOS that brokers access to the encryption keys. It leverages an additional embedded key such that both this key and the passcode entered by the user is required:
It keeps track of failed login attempts and independently degrades the retry rate after multiple failed passcodes are entered. The significance in terms of Apple being able to weaken the security is the difficulty they’d have in doing so with a Secure Enclave encrypted device:
If the San Bernardino gunmen had used an iPhone with the Secure Enclave, then there is little to nothing that Apple or the FBI could have done to guess the passcode
All iPhones with either Touch ID or an A7 processor or newer (so in other words, everything since the iPhone 5S) are equipped with a Secure Enclave. While the article doesn’t quite go to the point of claiming it’s impossible to breach (and to my earlier point, that’s just not a statement we like to make in security circles), clearly it does significantly raise the bar in terms of what’s required to circumvent the security controls. So in other words, if you can afford a newish, relatively high-end phone, you’re much better protected. This raises another issue altogether:
it’s great that the phone used by the rich protects them from the FBI.
What about the phones used by everyone else? https://t.co/fFxFBNnA1T— Christopher Soghoian (@csoghoian) February 17, 2016
The “digital security divide” is another issue for another story, but it’s a poignant observation when we’re talking about who’s at risk of surveillance. Equally poignant: if you were hell-bent on wreaking havoc and ready to go out in a hail of gunfire and didn’t want your device accessed by the feds, you’d simply go out and buy a current gen iPhone.
Edit, 19 Feb 2016: A day later, Trail of Bits have modified some of their guidance, most notably by adding an update to say: “Reframed “The Devil is in the Details” section and noted that Apple can equally subvert the security measures of the iPhone 5C and later devices that include the Secure Enclave via software updates”. The commentary in the ensuing day since this post does indeed indicate that newer devices are still at risk which also helps explain Apple’s emphatic defence of the court order.
We know that the media has a way of putting a spin on things that frequently misrepresents the underlying issue and it’s no surprise that we’re seeing a lot of this at present. Bruce Schneier summarised the problem quite succinctly:
Today I walked by a television showing CNN. The sound was off, but I saw an aerial scene which I presume was from San Bernardino, and the words “Apple privacy vs. national security.” If that’s the framing, we lose. I would have preferred to see “National security vs. FBI access.”
This is enormously important because if the hearts and minds of people get misdirected into believing that Apple’s approach is at odds with the best interests of the nation, there won’t be the groundswell of support that’s required to keep irrational court orders like this at bay.
This issue is much bigger than just Apple providing access to a single device, it’s much bigger than the encryption debate and it’s much bigger than just the US. There are angles to this we haven’t thought about yet and it’ll continue to be sensationalised by the press, misrepresented by the government and rebuked by Apple.
The ramifications of them actually complying with this court order would likely spread well beyond just compromising a device that’s in the physical possession of law enforcement. A precedent the likes of Apple being forced to weaken consumer protections will very likely then be applied to other channels; what would it mean for iMessage when the authorities identify targets actively communicating where they’re unable to gain physical access to the device? It sets an alarming precedent and all the same arguments mounted here by the FBI could just as easily be applied to end to end encryption.
But let me finish on a lighter note: this also has the potential to result in greater consumer privacy for everyone. In part because if Apple successfully defends their stance then they’ll have the precedent the next time the issue is raised. In part also because this incident may well prompt them to tie their own hands even further and indeed this appears to be the case with the newer generation of device. And finally, because the world is watching how this plays out and it will influence the position of other governments and tech companies outside the US. If sanity prevails, we may well all be better off for having gone through this.
Continue reading Everything you need to know about the Apple versus FBI case
The other day, a hacker compromised someone’s email account. It was almost certainly a phishing attack, he probably just sent them over an email claiming to be from the victim’s organisation and then just, well, asked for their credentials. From there, the attacker wandered over to the web portal of the victim’s organisation and attempted to logon, which unfortunately for him didn’t work. No worries, they simply called up the helpdesk who kindly gave him access. So now he’s logged in to the victim’s portal and he heads over to a virtualised environment which he authenticates to using the victim’s credentials from the first step. Now he has access to the victim’s documents and can begin traversing the network under the identity of his target. He grabs tens of thousands of records about the organisation’s employees… and dumps them publicly.
The organisation was the US Department of Justice and the dumped data was 20,000 FBI and 9,000 DHS records, according to Motherboard. Oh – the attacker was also a 16-year-old kid. Allegedly, it was the same kid who socially engineered his way into the director of the CIA’s account last year. Evidently, manipulating humans via these engineering attacks is a rather effective way of breaching systems!
Only a week ago, I launched my latest Pluralsight course, Ethical Hacking: Social Engineering. This was the fifth in the epic Ethical Hacking series I’ve been working on with a co-author and in my humble opinion, perhaps the best course I’ve created to date (I love that it’s so broadly relevant regardless of the viewer’s technical competency). Just as I was wrapping up the editing of the course during my European travels last month, I had the opportunity to record another Play by Play course – that is a video of myself and someone else as opposed to just a screen cast – so I grabbed my good mate and fellow Pluralsight author, Lars Klint. Just to give you a quick sense of what goes into one of these Play by Play courses, Lars snapped this pic of us setting up:
A Play by Play was a really good opportunity to talk about social engineering because it allowed us to demonstrate the nuances of human interaction which is pretty pivotal to this class of attack. The video format allowed me to show devices I was carrying with me, demonstrate how an attacker would execute computer based social engineering (there’s a great demo of BeEF in there), and also show human based attacks which relied on us both being present in the same place.
One of the techniques we show and discuss in the course is “tailgating” or in other words, a social engineer simply following someone else through an otherwise secure door in order to gain access to a premise. Quite coincidentally, I saw a great example of how circumventing physical security measures can be done as I arrived onsite to run a workshop shortly after this. I was waiting at the reception of a financial institution which had turnstiles in the foyer and employees would file through one by one, swiping their access card as they go… except for one lady. She turned up on crutches and was summarily issued around the side of the turnstiles by a friendly security guard without any swipe of her pass. This is precisely the sort of behaviour we demonstrate in the course, albeit with me carrying a box and seeking assistance through the door and it can be that easy.
I really enjoy doing these Play by Plays because they’re very candid discussions and super easy to watch. There’s hardly any editing compared to a normal Pluralsight course delivered as a screencast and the dynamics between the individuals make it a very different viewing experience. This is now the third Play by Play I’ve done and believe it or not, it’s now my twentieth Pluralsight course and I’m enormously happy that it’s now live.
Go and check it out at Play by Play: Social Engineering with Troy Hunt and Lars Klint.
Continue reading A social engineering Play by Play on Pluralsight with Lars Klint
I just spent almost a month in Europe and did an insane number of events: 7 workshops of 2 days each, 6 conference talks, video interviews, Pluralsight courses, media events, multiple user groups and amazingly, absolutely everything went perfectly to plan! Trips like that are both very intensive and very fulfilling and whilst 27 days was longer than I’d ideally like, I had a fantastic time in Europe so I’m coming back again – twice – in the coming months.
I’ve give you the tl;dr version first then explain what I’m doing after that:
Everything except for the private workshop in Barcelona is open to the public and I’m hoping to add other events around the May and June trips to make the most of being over the other side of the world (get in touch with me if you’re interested in a workshop at your company). Let me tell you a bit more about what I’m going to be getting up to.
I originally had to decline this event as it was just a bit close to the June travel and without other work to do whilst over there, it’s a huge commitment to justify when you’re coming from the other end of the earth.
But I kept hearing really good things about it and when you look at the list of speakers, obviously it’s a world class show. Fortunately, I had the Barcelona training come to fruition a couple of weeks ago so I was finally able to give the guys at Techorama the nod and lock it in. I’ll be doing two talks there – my favourite two talks – and I’m yet to do these anywhere and not have them rate through the roof so I’m pretty excited about doing these again in Belgium
You can buy tickets to Techorama here.
This is what gets me to events like Techorama these day – the ability to go and spend time in organisations training their teams to build secure software. These are highly engaging and interactive workshops that get participants actively exploiting risks in vulnerable software and learning defensive patterns to help keep their organisations away from the news headlines. If you read this blog frequently or follow my Twitter account, think of the workshops as all the sorts of things you see me talking about there but compressed into two days of in-person and hands on training.
I’m presently rebuilding troyhunt.com (which is long overdue) and I’ll have a bunch more workshop info on there. I reached out for some comments I could share in anticipation of them going into the new site, a couple of which I’ll share now:
Troy’s hand-on workshop’s with our team, really boosted the security awareness for all who participated. We found immediate benefits just from developers applying the knowledge learnt and discovering gaps in our existing systems. A lasting benefit was also seen, with security now a permanent and understood item of discussion in technical reviews.
– Glen Foley, Liberty, Australia (financial services)
That was down in Melbourne a couple of months ago and I really like the change in culture that exposure to security in these workshops drives.
Two days with Troy has shown us just how shockingly easy some vulnerabilities are to exploit, but we now feel a lot more prepared and equipped to defend ourselves.
He has put us in the mind set of thinking about security with every line of code we write, shown us how to attack our own code in a way it likely be attacked in the wild, and taught us how to avoid the common mistakes developers usually make. And all in a really engaging & interactive style.
Money well spent. I couldn’t recommend it enough.
– David Cook, Compare the Market, United Kingdom (insurance and finance comparisons)
This one was the last stop on my recent trip at a little spot called Peterborough and I was especially happy to see feedback about the engagement and interactivity. We’ve all been in training which is dull and hard to get immersed in and I put a huge amount of effort into making these events both fun and insightful. I want people to go away having loved spending 2 non-stop days delving deep into a topic that empowers them to make a really impactful change in their job and by all accounts, the workshops do just that.
Some of the other recent pics and feedback shared by those who were there tell the story firsthand:
NDC London 2016 workshops started today at DeVere Venues. Picture of @troyhunt Hack yourself workshop #ndclondon pic.twitter.com/xRwPJE8XsZ
— NDC (@NDC_Conferences) January 11, 2016
Great two day workshop at #ndclondon with @troyhunt – Hack yourself first. @mark_towndrow @jwpinner pic.twitter.com/b44eFhFA50
— Carl Jackson (@jackson_carl89) January 12, 2016
Workshop with @troyhunt was an eye opener: I did not suspect how easy it was to actually exploit an SQL-i vulnerability or XSS. Thanks Troy!
— Pierre Arnaud (@epsitec) January 13, 2016
Thank you @troyhunt for your wonderful workshop on security practices! It was very enlightening!
— James Bach (@mechaspam) January 13, 2016
Just finished Hack Yourself First workshop with @troyhunt Great to see developers engaging on all sorts of #security topics @ReedBusinessInf
— Steve Harwood (@steveharwood) January 19, 2016
Start of our 2 day security workshop at @justeat_tech with @troyhunt! pic.twitter.com/L13wPP3Z1F
— Dan Rowlands (@danrowlands) January 27, 2016
2 epic days with @troyhunt ! He’s an amazing knowledgeable speaker and his security workshop is a most for anyone developing web services
— João Lebre (@jplebre) January 28, 2016
Today’s training is in a 13th century barn which is without doubt, the coolest spot I’ve run a workshop in to date! pic.twitter.com/beCMiFgcCA
— Troy Hunt (@troyhunt) January 29, 2016
Lively security workshop with Troy Hunt at @comparethemkt today! #legend @troyhunt @comparemkttech pic.twitter.com/ud8quDuNLw
— Neil Studd (@neilstudd) February 2, 2016
Hopefully that gives you a bit of a sense of what goes on at these workshops. I’ve got a heap of other information offline (soon to go into the rebuilt website) so get in touch if you’re anywhere in the vicinity of Europe (or between Australia and there) and would like more details. Ideally I’ll do a couple of extra workshops on each trip but I’m going to avoid turning it into an epic like the last one so will keep the events to a minimum. Oh – I always try to get along to a local user group too so if there’s one you support and would like me to come and speak in the midst of a two-day workshop, I’d be more than happy to!
When it comes to NDC, I’m making things real easy these days – I’m going. No questions asked, I’ll be there. Oslo the last couple of years, London last month then Oslo again this coming June and for the first time, Australia in August. “Yes” to all and for the first time at NDC, I’ll also be keynoting in Norway.
I’m really excited about this event because without a shadow of a doubt, it’s the conference highlight of the year. It’s just so well run and as both a speaker and an attendee you’re exceptionally well looked after plus it’s a 2,000+ person show with some of the best tech speakers in the world. My keynote is already coming together (yes, I have nearly 4 months but I do like to plan in advance!) and I’m really looking forward to doing something a bit different. It’s not a security talk (although I’m sure some app sec will inevitably creep in), but it’s enormously entertaining and if I get it right, it’ll be insightful and educational as well.
You can buy tickets for NDC Oslo here and you’ve still got a few weeks left before the early bird pricing expires so hop to it!
As well as doing private workshops where I’m onsite at a specific organisation, I do the occasional public ones where anyone can register and come along. In June right after the NDC conference, I’ll be back in London courtesy of Learning Connexions:
Their site has an overview of the workshop which is the same one as I run privately albeit obviously open to the public. What I find really interesting about these workshops is the diversity of experiences the attendees bring; when you have 20 or 30 people from different backgrounds working in different organisations with different security challenges, you get a really rich dialogue that makes every workshop unique. In fact, to that effect and whether it’s public or private workshops, whilst I have a syllabus I’ve created and work to, the attendees always drive the discussion in the directions that best help address their specific needs. This is the joy of in-person workshops and I find it a really good way of balancing this form of teaching with what I do for Pluralsight. In fact most of the time when I run these events, individuals or organisations already have Pluralsight subscriptions and we structure the event so that they get the most out of each; heaps of interaction in the workshops followed by in-depth training on discrete topics if they want to drill into the Pluralsight content at a later date.
Last thing on workshops: one of the things I’m finding really curious is the number of times these events are leading to discoveries of nasty security risks in other people’s software. For example, last year after a workshop down here in Aus we ended up finding a rather serious oversight in the realestate.com.au app on Android which had their password transmission going over an unencrypted connection. More significantly, whilst in the UK we found a case of a taxi app leaking information about drivers and other passengers. The really intriguing one though is a major car manufacturer who exposes APIs in a way that allows anyone to control certain functions of their electric vehicles. The car one in particular is very serious and I’m now working with them privately to resolve the issue before I write about it further which in a very meta sort of way is another good lesson from the workshops; how to approach ethical disclosure. To be clear also, the sorts of risks we’re discovering here are found simply by observing the traffic between the client (frequently a mobile device) and the server when using the software as it was intended to be used. I’m astounded at the ease with which we continue to find these risks (this one about remotely controlling tractors is another good example), but equally, I’m delighted that just a couple of days of learning what vulnerable patterns look like is enough for people to make a really positive difference to online security.
I’ll be trying to lock down agendas over the next couple of weeks so I can book tickets in a busy time of year for Europe. If you’re interested in learning more about the workshops, ping me on troyhunt@hotmail.com
Continue reading More Europe, even more again and more workshops
We tend to get very focused on digital security controls; firewalls, antivirus, software updates and then all the usual practices I spend so much time talking to developers about, stuff like defending against SQL injection, cross site scripting and a whole raft of other attacks against systems. But the bigger risk – and it’s one that doesn’t get near as much coverage – is attacks against humans. Whereas most of the time we’re thinking about attacks against the systems, we tend to neglect weaknesses in the organic matter controlling them and as a result, social engineering attacks are enormously successful.
I’ve just wrapped up Ethical Hacking: Social Engineering and when reflecting on what I should write here, it was honestly hard to know where to even start. I’ll start somewhere that’s familiar to a lot of people – with this:
It’s now four years since I recorded this and it has well over a million views. It’s also where I kick off with the social engineering course because that’s exactly what goes on – a scammer tries to socially engineer me into believing that my PC is full of viruses and I should pay him money to fix them. I decided to include key parts of this video in the course and narrate them because it’s just such a great demonstration of so many social engineering behaviours. For example, the scammer begins by establishing authority in claiming he’s from Microsoft and has received alerts from my PC before instilling fear when he explains how my PC is infected with viruses. He proves his authenticity by taking me through the event log (these are the viruses, y’know!) then “fixing” the PC to create a debt he consequently attempts to monetise. I distil the lengthy video down into the key points that best demonstrate the attack styles and we see these behaviours repeated at numerous other points during the course.
One of the things I realised when writing this post was that there were some really interesting social engineering attacks that hit the tech headlines during my production of the course. For example, there was Brian Krebs’ post on PayPal’s lazy authentication which boiled down to people being able to easily – and repeatedly – take over his account just by relaying publicly available information about him to PayPal support. The other one that made quite a few headlines even in the consumer news was Amazon’s customer service back door. This one exploited Amazon’s online help service again, by using readily available information found on the web.
In fact, that’s a common theme in social engineering; the use of OSINT or “Open Source Intelligence” data and you can find it everywhere from social media sites to WHOIS records to online telephone books. The amount of information available on people is extensive and not just from disparate sources, but aggregated into services like pipl where you just pop in a name and get back a unified view of the individual. Try it on yourself and you might be surprised by just how much it finds.
There’s a heap of other aspects of social engineering I delve into in the course, one of the biggies being phishing. I walk through a bunch of typical examples, for example the affinity with attackers using subdomains such as paypal.com.attackers-real-domain.com in order to fool victims who focus solely on the first part of the URL. Whilst many phishing attacks stand out due to various obvious indicators (and indeed there’s a school of thought that suggests this is intentional), I’ve also seen some exceptionally good ones lately. You’re probably more technically inclined if you’re reading this blog and will know what to look for here, but do you think the average consumer could spot the phishing site below?
I also walk through how to mount your own phishing attack with the very cool Phish5 service and indeed I wrap up the course by saying you should go and give this a run to “condition the humans”. The traditional approaches to defending an organisation against social engineering attacks tend to be to force people through mundane training they must then sign off on and promptly forget or just to whack up a bunch of security posters which become “white noise” in the office, I mean just look at some of these! They don’t change behaviours, certainly not when compared to hitting them with a service like Phish5.
In creating this course, I drew from a bunch of first hand social engineering experiences I’ve previously written about, for example This is your bank, please verify your details and Happy birthday! Now anyone can login to your Betfair account. For those of you who watch the course I’m sure you’ll see a lot that resonates and you’ll identify all sorts of places that you’ve been exposed to social engineering either as a victim (if you have kids, you’ll have suffered physiological manipulation!) or opportunities where you could exercise it to your own advantage (I talk about my experience with identify verification at the doctor’s).
This is first and foremost the best social engineering course I could make and I’m enormously happy with how it’s turned out. Due to the nature of social engineering, unlike my other courses it’s a course that can be watched by anyone regardless of their technical competency because it’s so focused on human behaviours. Secondly, it also forms part of the Ethical Hacking series I’m contributing to and it’s now the fifth course I’ve contributed with fellow author Dale Meredith having created seven others. That distinction is important; if you want to study for your Certified Ethical Hacker cert then that’s great and we firmly believe that Pluralsight has the best possible material for that but equally, this course is much broader than just one certification as I said from the outset, each course must stand on its own as an exemplary example of security education on the discrete topic it covers.
I’ve spent a lot of time in TeamCity recently and the nightly code quality metrics coming from the dupe finder, FxCop and NDepend have been great.
What I’d really like to do is find a decent web app security scanner which can run against … Continue reading Are there any decent web app security scanners that can integrate with a build server?