Jun 18 2014

Network Security Podcast, Episode 332

Published by under Podcast

We’d suspected this day would come for quite some time, but it’s time to make it official: The Network Security Podcast will no longer be a regular, weekly podcast, Rich Mogull and Zach Lanier will not be a consistent part of the podcast. The podcast will continue in some form, but it’ll be Martin doing any of the publishing.  Which isn’t really all that big of a change anyway.

Basically, all three of us have become incredibly busy in the last year.  Zach has a wedding to plan, a new job and has moved again.  Rich has more business and work than any time in living memory and has had to cut out anything not related to work or family.  And Martin moved to Europe and is on the road close to 50% of the time, further complicating everything.

There will still be microcasts and occasional interviews published through the podcast site, but for the most part we’re shutting down production.  It’s a sad day as we’ve been doing this podcast in one form or another for nearly almost 9 years.  We’ll miss talking to each other and our audience, but the needs of life have intervened and require our attention elsewhere.  You can catch all three of us at various conferences, either presenting or attending and know that we’ve always loved hearing feedback from you.

Keep an eye and ear open as there are already plans in process for what comes next.  You didn’t think Martin could stop talking, did you?

Network Security Podcast, Episode 332 – The End of an Era

Time: 50:58

 

Show Notes:


No responses yet

Jun 10 2014

If you don’t enter, you can’t win

Let me start by saying Nikita is brilliant and should be showered for accolades for coming up with this, presumably on the fly.

Let me give you some background.  Today was the day the letters about who’s talks were accepted for Defcon 22 came out.  Additionally, all the rejection letters for those not lucky (or well prepared enough) to be chosen to speak came out today.  I know my limitations, and as such, I haven’t submitted a talk to Defcon, other than being on panels and being part of the Defcon Comedy Jam in years past.  I also know I’m a smart ass and I jokingly asked Nikita on Twitter (@niki7a) “Can I get a #Defcon rejection letter?  Even though I never submitted anything.”  And here’s the reply I got.  As a coworker put it “So your talk on not submitting and regretting it was rejected because it wasn’t submitted and the rejection was song lyrics about not regretting your actions with a statement on why they regret rejecting your non-submitted non-submital? Meta.”

Martin,

The review board has reached a decision for your submission. Unfortunately, we will not be accepting your talk, “I didn’t bother to submit, and other regrets in the Hacker scene”, for DEF CON 22. If you submitted more than one paper, it may still be in review. Individual letters are sent out for each paper.

Every year, I have to write a bushel of rejection letters, and it’s never easy to shoot someone down who has put together a CFP. I really respect the effort each applicant puts into their work. The work you do, and the willingness to share your knowledge with the community is incredible, and I appreciate the fact you submitted with us. In a perfect world, every submission would be accepted and it’s contents shared with the community. Each talk has the potential to be the building blocks for a new idea, the solution to someone’s headache, the itch that needs scratching, or the salve for someone else’s.

In the end, I try to provide feedback for you so that when a talk is rejected you can get some sense of why and take that feedback to build a better paper. Hopefully, you can use it to submit it again to another conference, or again with us next year. Either way, Thank you again for the hard work. I’ve put together your feedback from the review board below.

———————————————
 We had to reject simply due to the fact that you didn’t submit. Maybe you will think about that next time. I mean seriously, like, what were you thinking?  I’d like to give you the following feedback as a way to help you understand this oversight on your part, perhaps my words will motivate you to improve your position for next year.

“And now, the end is here
And so I face the final curtain
My friend, I’ll say it clear
I’ll state my case, of which I’m certain
I’ve lived a life that’s full
I traveled each and ev’ry highway
And more, much more than this, I did it my way

Regrets, I’ve had a few
But then again, too few to mention
I did what I had to do and saw it through without exemption
I planned each charted course, each careful step along the byway
And more, much more than this, I did it my way

Yes, there were times, I’m sure you knew
When I bit off more than I could chew
But through it all, when there was doubt
I ate it up and spit it out
I faced it all and I stood tall and did it my way

I’ve loved, I’ve laughed and cried
I’ve had my fill, my share of losing
And now, as tears subside, I find it all so amusing
To think I did all that
And may I say, not in a shy way,
“Oh, no, oh, no, not me, I did it my way”

For what is a man, what has he got?
If not himself, then he has naught
To say the things he truly feels and not the words of one who kneels
The record shows I took the blows and did it my way!

[instrumental]

Yes, it was my way”

Thank you for your time, I can’t tell you how much I appreciate the opportunity you’ve given me to berate you over electronic medium, I can’t wait to see you at the show!

Please consider submitting or not submitting again in the future, and I hope that you enjoy DEF CON this year.

———————————————

Thanks,
Nikita Caine Kronenberg

There may be material here for a submission to Defcon 23.


No responses yet

Jun 03 2014

Well done, HITB, well done

Published by under Hacking,Personal,Public Speaking

One of the advantages of having moved to the UK from California last year is that I often get the chance to attend conferences I never would have dreamed of attending otherwise.  Thanks to this, last week I was able to attend one of the events I’d never hoped to be able to see otherwise, Hack in the Box Amsterdam.  And I’m very glad I did, as are my children, aka the Spawn.

One of the unique things about this year’s HITB was their choice of keynote speakers, which were all women.  None of them were asked to speak about “women in infosec”, nor were they discouraged from the topic.  But they were all women who are recognized as having accomplished great things in the security field.  Katie Moussouris opened up the conference talking about how the security community is finally at a point where we actually have the influence we’d always wanted, now we have to do something with it.  That and announcing her new role as the Chief Policy Officer for Hacker One, a bug bounty company.  The second day was opened by Jennifer Steffens, CEO of IOActive who called bullshit on the security community for being such a bunch of emo posers and pointed out what a wonderful time it is to be in security as well as illustrating some of the exemplars  in our field.  Both of these security professionals gave keynotes worthy of nearly any conference in the world.

The Haxpo, or vendor area as we generally call it, alongside the conference was also well worth the visit.  TOOOL was in evidence, as were a number of the local hacker spaces, but my favorite part of the show floor.  I picked up a HITB badge, Spawn0 got a TV-B-Gone and we both went to town with soldering irons.  Spawn0 was more successful than I was, as his TV-B-Gone worked while my badge didn’t, most likely due to lack of soldering skills on my part.  He’s just waiting for football (aka soccer) season to get into full swing to test it’s full capabilities.

Will I attend HITB again?  It depends; I’d just come off of two weeks of intensive travel and probably could have used downtime as much as I wanted to see this event.  But I’m very glad I went and got to meet additional members of the European security community.  Maybe next year I’ll try to avoid having so much travel leading up to the event.


No responses yet

May 06 2014

Network Security Podcast, Episode 331

Published by under Podcast

It’s been a while since we could last record a podcast, but at least we were able to get Rich and Martin together this week.  Zach was supposed to join us as well, but got called away to fight a fire at the last minute.  Such is life sometimes.  But we got this episode recorded, so let’s celebrate the small victories.  We don’t know when we’ll have the time for another one as most of the hosts are galavanting around the world and having fun.

Network Security Podcast, Episode 331, May 6, 2014

Time:  38:05

Show Notes:


No responses yet

May 01 2014

Thank you

Published by under Podcast

This week was the InfoSecurity Conference and BSides London, and along with them the EU Security Bloggers Meetup and Awards.  It was a good week to be in London, despite the Tube strikes, but the highlight obviously had to be Wednesday at the Meetup: we, the hosts of the Network Security Podcast, were recognized as the Best Security Podcast at the EU Security Bloggers Awards for 2014.  Thank you to the listeners who voted for us and the judges who selected our podcast as the winner!  I think I can speak for my cohosts when I say that we’re truly honored to be picked for this award.  All I had to do was move from California to the London area to make it happen.

When I started the Network Security Podcast in November of 2005, it was with a really cheap microphone and simple mission in mind.  I had a lot of opinions on the news in the information security industry; talking through them into a microphone was a good way to clarif2014-04-30 19.42.28y those opinions and share them with others.  When I enlisted the aid of Rich Mogull, it was to give me another person to discuss those opinions and have someone to expose the weaknesses in my logic.  Adding Zach Lanier to the mix brought someone with a much more technical background to the table.  We’ve continued podcasting so long because we enjoy the discussions and learning that a podcast creates.  But the most important thing that keeps us coming back again and again (though less often than before) is the feedback we get from listeners telling us that they’ve learned and enjoyed listening to the podcast.

The Network Security Podcast has never been something that we’ve done so we can earn an award or gain recognition, though those things never hurt a person’s ego.  We’ve done it because we enjoy having an excuse to get three people together on a semi-regular basis and hashing out a lot of the ideas we have circulating through our collective heads.  We use the stories that are happening to give us something to focus on, but it’s really the exchange of viewpoints that we value.  Equally important is the fact that other people in the security community find the interchange to be valuable and keep coming back episode after episode.  There aren’t too many events that we go to that someone doesn’t come up and say they’ve been a long term listener, something that happened to me at least five times at BSides London.

ZombieMartinBigThe EU Security Blogger Meetup and Awards couldn’t happen without the sponsors, especially Tripwire and Tenable, nor could it happen without the efforts of people like Jack Daniel, Brian Honan and Cindy Valladares (who’s responsible for the Zombie Martin picture to the left).  I’m sure there are a number of other people helping that I’m completely unaware of, and I’m sorry I can’t recognize them as well.  I’d like to congratulate the other winners of the EU Security Blogger awards.  It’s an amazing thing to be recognized not only by your audience but also by your peers and the people you respect.  I look forward to seeing everyone there again next year.

A closing thought:  the Network Security Podcast has been harder and harder to record since I moved to Europe.  Zach, Rich and I all have very hectic travel schedules and we haven’t been able to coordinate in order to record a show as often as we’d like.  While I don’t have any plans for the show to go away, we’re all aware that even going to an every two week publishing schedule hasn’t been as effective as we’d hoped and something has to change.  We don’t know exactly what that will be yet but we will let our listeners know as soon as possible.


No responses yet

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.


3 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


No responses yet

« Prev - Next »