Apr 06 2014

NSP Microcast – BSides London 2014

This afternoon I had a chance to talk to two of the main organizers of one of the biggest security events of the year, BSides London.  Paul Batson and Thomas Fisher have been working tirelessly (or maybe tiredly) for months to bring together all of the disparate elements required to make a conference come together.  And it’s no mean feat when the people you’re working with are all volunteers and the money comes from sponsors, both of whom believe in your cause.  This year will be my first chance to go to BSides London (this is the fourth) and I’m really looking forward to it.

-Martin

NSPMicrocast-BSidesLDN-2014
Time: 18:00


No responses yet

Apr 05 2014

Hack my ride

Published by under Hacking,Risk,Security Advisories

Important:  Read the stuff at the end of this post.  I got a lot of feedback and I’ve added it there.  Unlike some people, I actually want to be told when I’m wrong and learn from the experience.

I don’t own a Tesla S and probably never will.  They’re beautiful cars, they’re (sort of) ecologically friendly, and they show that you have more money than common sense.  I use a car to get my family from point A to point B and showing off my wealth (or lack there of) has never actually been part of the equation in buying a car.  And one more reason I don’t think I’ll ever buy a Tesla is that I’m beginning to think they’re as insecure as all get out, at least from the network perspective.

Last week hacker* Nitesh Dhanjani wrote his experience with exploring the remote control possibilities of the Tesla Model S P85+.  It starts with being able to unlock the doors, check the location, etc.  And it ends with a total lack of security for the site and tools needed to control the car.  The web site for controling your new Tesla has minimal password complexity controls, six characters with at least one letter and one number.  I have no idea if it’ll even let you use symbols, but I’m guessing that’s either not supported or only a minimal subset of symbols are available.  Which means password complexity is very low by almost any standard.  Then there’s the fact that Tesla doesn’t have rudimentary controls around the web site, such as rate limits on password guesses or account lock out, which they’ve hopefully changed by now.  Which gives you an easily guessed password combined with a site that allows unlimited guesses, making the possibility of brute forcing the password very real.  That’s not even including the fact that so many people reuse account names and passwords, so there’s a good chance you can find a compromised account database with the owner’s details if you search for a little while.

That’s great so far.  Now let’s add to this the fact that your Tesla S has wifi/4G wireless access.  And there’s also a 4-pin connector in the dashboard that leads to the network inside your car.  It’s running all sorts of wonderful things in that network too, none of which could possibly be vulnerable to outside attacks, right?  SSH? Check.  DNS? Check.  Web Server? Check. Telnet?  Check.  Wait, telnet?  Seriously?  Oh, and “1050/tcp open java or OTGfileshare”.  Yes, I really want either java or an open file share running in my car.  At least one person was able to get Firefox running on the console of their Tesla, [Correction: x-11 forwarding misconfiguration, not running on the Tesla]  even if was flipped on its head for some odd reason.  Any or all of these services running on the car’s internal network could have vulnerabilities that allow configuration change, remote code execution or even full root access to the system.  Or maybe they just allow for the systems to be rebooted, not something you really want when your driving on the winding coastal roads of California. [I've been told it's just the displays that would be affected, none of the handling characteristics would change. Still disconcerting]

So now we’ve got two fairly egregious methods of connecting to your Tesla with minimal security standards.  The first is remote and allows for control of doors, sunroofs, braking and suspension profiles.  The last two should concern everyone.  While there are probably physical controls in place to keep the profiles of brakes and suspension from getting too far outside of the range of acceptable usage, I wouldn’t be willing to bet on it, given the otherwise lax security measures on the remote controls for the car.  The second method of connecting to the Tesla does require physical access, but it sounds like this is built for the engineers and technicians who work on Teslas [Correction:  The connection only allows for access to the entertainment system and there is an airgap between that and the CANBUS systems.  However, I don't trust airgaps], and is likely to allow much greater control of the car and the various parameters of its design.  Even less technologically advanced cars have the ability to make fairly advanced modification of the functioning of a car once you have access to the software, so Tesla probably has extremely advanced configuration capabilities.  Meaning everything from how the car charges when plugged in to what shows up on the dash as you’re driving to manipulating acceleration and braking are within the realm of possibility.

As the Internet of Things becomes our daily reality, this sort of lax security on something as potentially deadly as an automobile is inexcusable.   It wouldn’t take much of a tweak to the normal operation of a car to make it uncontrollable in the wrong situation.  We haven’t seen anyone killed by having their car hacked yet, but it’s only a matter of time if companies aren’t willing to take the time to properly secure the systems that go into making the car run.  While it’s important in the current marketing environment to make every device as configurable from you phone as possible, there have to be sufficient controls in place to make that configurability safe and secure as well.  Yes, it might mean that you, Tesla, have to make your users go through two or three more steps in order to set up their systems for control, but it’s worth the effort.  After all, who will be liable, who will be in the courts for years when the first person claims that their car was hacked, which is what caused the accident?  Even if having a car hacked isn’t the cause of an accident, it can’t be too long before someone uses that as their defense and still costs the company millions in legal defense.

Let’s end this with a little thought experiment.  The four pin connector in the Tesla has a full TCP stack and runs on a known set of IP’s, 192.168.90.100-102.  Say I grabbed a Teensy 3.1, with built in wi-fi capabilities, and added an ethernet shield.  With the current arduino libraries, I can create a wi-fi receiver that takes my traffic and routes it to the wired network, which just happens to have an accessible network inside the Tesla.  Now I have a device that’s a small portal directly into your car that I can connect to from several hundred feet away, farther if I want to make myself a high gain pringles can yagi antenna.  We’re not talking high technology spy gear, we’re talking about a weekend project I could do with my kids that would result in a package no bigger than a pack of cards.  I could put this in the glove box with a single cable leading to the car’s ethernet port.  Anything a Tesla engineer could control on the car, I could control remotely.  Suddenly I have the biggest remote control car on the block, which just happens to be the Tesla you’re sitting in.

This is why we have to secure the Internet of things.  If I can imagine it, you better believe there’s already someone else out there working on it.

* Hacker == someone who makes technology do things the engineers who designed it didn’t intend it to do.

Added, 9:15 GMT:  So I got some feedback very quickly after posting this.  And I admit a lot of what I’m saying here is based on guesswork, assumptions and third party statements.  It’s my blog, I get to do that.  Both Beau and the Kos have a lot more to say about why many of my assumptions are wrong.  And they probably know more about cars than I do.  So teach me.  There will be follow up.

Thanks to @chriseng for basic spell checking.  I do indeed know the difference between ‘break’ and ‘brake’, just not before breakfast.

@beauwoods: “Infotainment network and CANBUS are separate. The other issue is the equivalent threat model of a big rock to a window.” In other words, there’s a very real airgap between the two systems and it’d be impossible to control one from the other.

@theKos called my statement about the password limitations silly, stated that running Firefox on the system was a x-forward misconfiguration, that rebooting the displays won’t affect the running of the car, and that all products have vulnerabilities.  I really have to challenge the last statement as a fallacy: knowing that all products have vulnerabilities doesn’t make them more acceptable in any way.


2 responses so far

Mar 31 2014

Network Security Podcast, Episode 330

Published by under Podcast

It only took 4+ weeks, but Martin and Zach are back on the air. Rich is back to his “(Inter)National Man of Mystery” routine, so he missed out on the somewhat lively discussion about drones, “secure” browsers, PCI, and, of course, the NSA.

Network Security Podcast, Episode 330
Time: 37:27

Show Notes:


One response so far

Mar 23 2014

NSPMicrocast – RSAC2014 – DoSArrest

Published by under Podcast

Most of the time my competitors are afraid to talk to me on the podcast.  I’m a nice guy to the people I interview, so I don’t know why they’d be afraid.  And this year at RSAC, Jag Bains the CTO at DoSArrest took a chance and talked to me.  While I did bring up that we’re competitors, I let Jag explain to me how his company works and what they protect their customers from DDoS.  I still think we do it better, but it’s good to hear what other people in the same field are doing.

NSPMicrocast – RSAC2014 – DoSArrest


3 responses so far

Mar 23 2014

NSP Microcast – RSAC2014 – BeyondTrust

Published by under Podcast

I had a chance to sit down with BeyondTrust CTO, Marc Maiffret.  I’ve had conversations with Marc before, but I haven’t seen him since he has been at BeyondTrust, so I took this time to find out what they do and how it would be used by the average enterprise.  As with all my interviews at RSAC, I asked Marc how he felt the spying revelations of the last year have affected the security landscape, his company and him personally.

NSPMicrocast-RSAC2014-BeyondTrust


One response so far

Mar 20 2014

European InfoSec Blogger Awards

Next month is Infosecurity Europe here in London, taking place from 29 April until 1 May, as well as BSides London on 29 April.  I’ve never had the chance to go to either event and I’m really looking forward to my first time.  Another event that’s happening alongside both of these is the European Security Bloggers Meetup at the Teck Pub (appropriately named place for our group).  Many people may not know it, but I’ve been one of the people organizing the RSA Security Bloggers Meetup from the very start and I’ve been the MC for almost every single one.  So I’m very excited to see how the event translates to London and the European community.  I know it won’t be the same event, which is why I want to go.  Brian Honan is hosting with a little help from Jack Daniel and Tenable Security, which pretty much guaruntees this will be a most interesting shindig.

One of the aspects of the Meetup since the second or third year has been the recognition of bloggers and podcasters by the security community, the Security Bloggers Awards.  As one of the organizers of the Security Bloggers Meetup, I’ve always held my blog and my podcast as being out of the running for any recognition in the RSA version of these awards. I didn’t want there to be any potential conflict of interest with the awards, so it was easier to opt out of the competition all together.  Some people might say it’s because I feared folks like the Security Weekly Podcast and Exotic Liability taking the awards even with my competition, but I’m going to stick with my story of conflict of interests.  

But a funny thing happened last year; I moved my family to London.  Which means I’m now a European blogger and podcaster.  And since I have absolutely nothing to do with the European Security Bloggers Meetup or the European Information Security Bloggers Awards, I feel free to compete and do my best as a transplant to take whatever awards I can wrest away from the natives!  It also helps that the only ‘competition’ here in the UK that I know of are the Eurotrash Security Podcast and Finux Tech Weekly. And I’m pretty sure you have to have actually posted within the last year and you can’t have any pictures of WickedClownUK in spandex.  Not just can’t have them on your site, you can’t even be in possession of them.  Since the ‘rules’ of this competition are … well, non-existant, if I can convince voters of these requirements, it helps my efforts.

So go vote for Rich, Zach and me as the hosts of the Network Security Podcasts for Best European Security Podcast of 2014!  Sure, I’m the only one of the three of us that actually lives in Europe.  Yes, I’m not really European, I’m an American transplant.  But none of that is nearly as important as not letting Chris John Riley win the award!  So vote early, vote often, and just vote for the Network Security Podcast!  Or at least go vote, since I’m not really all that attached to winning an award, truth be told.

Hmmm, vote for the Network Security Blog as the Best Personal Security Blog too while you’re there.  Maybe I do care about awards after all.

 

 


No responses yet

Mar 20 2014

NSP Microcast – RSAC2014 – Denim Group

Published by under Podcast,Risk

I caught up with John Dickson and Dan Cornell from the Denim Group to talk about creating secure coding environments within companies, the importance of having trainers who are themselves coders and, of course, a little bit about spying.  Which turned into a lot of bit about spying.  I should have asked them where the name ‘Denim Group’ comes from.

NSP Microcast – RSAC2014 – Denim Group


No responses yet

Mar 18 2014

NSP Microcast – RSAC2014 – Utimaco

I spent a few minutes with the CEO of Utimaco, Malte Pollman at RSAC this year.  Malte explains why Hardware Security Modules are important to the web of trust of the Internet, why lawful interception is a not in conflict with that web of trust.  As with all my interviews at RSAC, I asked Malte how the last year’s worth of spying revelations have affected his company and him personally.  Also, I have a problem pronouncing the company name, which for the record is you-tee-make-oh.

NSPMicrocast-RSAC2014-Utimaco


No responses yet

Mar 15 2014

NSP Microcast – BSidesSF with Trey Ford

I caught Trey Ford right after his talk at the BSides Conference in San Francisco last month to talk about the efforts he’s making on behalf of Rapid7 and the security community.  It may be a sign that we’re a maturing industry when we’ve got folks like Trey traveling to Washington, DC in order to talk to lawmakers about how what they’re doing affects our lives.  And, as with all my interviews this year, I ask Trey how revelations about our government has affected his personal as well as professional life.  Check out his site at Password123.org.

NSPMicrocast – BSidesSF – Trey Ford


No responses yet

Mar 09 2014

Mt. Gox Doxed

I’ve never owned a bitcoin, I’ve never mined a bitcoin, in fact I’ve never really talked to anyone who’s used them extensively.  I have kept half an eye on the larger bitcoin stories though, and the recent disclosures that bitcoin exchange Mt. Gox was victim of hackers who stole the entire of the content in their vault, worth hundreds of millions of dollars (or pounds) have kept my interest.  I know I’m not the only one who’s smelled something more than a little off about the whole story and I’m sure I’m not the only one.  Apparently a hacker, or hackers, who also felt something wasn’t right on the mountain decided to do something about it: they doxed* Mt. Gox and it’s CEO, Mark Karpeles.

We don’t know yet if the files that hackers exposed to the internet were actually legitimate files from Mt. Gox and Mr. Karpeles yet, but this isn’t the only disclosure the company is potentially facing.  Another hacker has claimed to have about 20Gigs of information about the company, their users and plenty of interesting documents.  Between the two, if even a little of the data is valid, it’ll spell out a lot of trouble for Mt. Gox and it’s users.  If I were a prosecutor who had any remote possiblity of being involved in this case, I’d be collecting every piece of information and disclosed file I could, with big plans for using them in court at a later date.  

In any case, I occasionally read articles that say the Mt. Gox experience shows that bitcoins are an unusable and ultimately doomed form of currency because they’re a digital only medium and that they’ll always be open to fraud and theft because of it.  I laugh at those people.  Have they looked at our modern banking system and realized that 99% of the money in the world now only exists in digital format somewhere, sometimes with hard copy, but generally not?  Yes, we’ve had more time to figure out how to secure the banking systems, but they’re still mostly digital.  And eventually someone will do the same to a bank as was done to Mt. Gox.

*Doxed:  to have your personal information discovered or stolen and published on the Internet.


3 responses so far

Next »