Friday, May 28, 2010

Comments broken…

It looks like commenting is currently broken on the blog, trying to figure it out.  Since I’ve been too lazy to build and run my own blogging system, I’m at the mercy of the Googleplex to get this sorted out.  Sorry…

[update: it looks like only the last post has broken comments]

Jack

Thursday, May 27, 2010

Continuing the car-rant

Time to resume the review of the car security paper.  I will not pick it apart completely, but I do need to hit several more points in this post and then I'll wrap up the car rant in one more post on access to tools and information.
Backing up a bit, one thing I skipped over was the choice of automobiles.  They chose one pair of identical cars, testing one stationary and one on a test track.  Their reasoning behind the small sample, and not identifying the car, is stated as:
"We believe the risks identified in this paper arise from the architecture of the modern automobile and not simply from design decisions made by any single manufacturer. For this reason, we have chosen not to identify the particular make and model used in our tests. We believe that other automobile manufacturers and models with similar features may have similar security properties."
I am uncomfortable with these blanket assumptions for a few reasons.  First, it is irresponsible to praise or damn an entire industry based on a single sample.  Second, I assume the technology levels of auto manufacturers have been somewhat leveled by regulatory and market pressures, but it is naive to think they are all the same, or that they all treat digital security the same.  Time for another trip back in time: Going back to the pre-OBD-II days, some manufacturers had barely moved out of the seventies, while others had forged well ahead.  For example, there was some argument of the number of pins to be included in the proposed standard connector- many manufacturers complained loudly and said it was impossible to supplied the required information in the small number of connectors.  Chrysler also complained about the proposal, but their complaint was that they were already supplying more information than required in a smaller connector, Chrysler objected to needlessly adding pins.  At this time, Ford technicians were still using breakout boxes and meters for some testing while many Chrysler vehicles were connected to in-shop computers to do the same, only faster and more reliably.  At the same time (early 90's) we had data capture devices available for Chrysler products which let us capture system data while on the road.  I remember dumping the contents to the shop computer, then to floppy so that I could wave them in engineers faces at conferences.  "If you look here on the fuel injector and ignition timing traces..." was a lot better than "I don't know, but the customer still isn't happy".  Moving forward, up until a couple of years ago I know that the quality and technology of diagnostic equipment varied widely between manufacturers.  From what little I've seen from friends and clients this still appears to be true.  I do not think it is unreasonable to conclude from this that testing of multiple manufacturer's systems is warranted before making any sweeping statements.
A technical and safety nitpick: On page nine, section V. B., they discuss the setup for the stationary tests.  They raised the car on jackstands and ran the drivetrain at speeds for the tests with the wheels and powertrain unloaded.  This means the operating environment of the vehicle was artificial and bearings were spun without load- a bad idea.  Also, without the weight of the vehicle on the wheels, had something malfunctioned there could have been out-of-control vibration, possibly bouncing the car off the stands with catastrophic results.  (This one is not theoretical, I've seen bad things).  In this configuration, they tested the electronic braking system- the rear wheels were stationary while the front wheels spun at 40 MPH.  Since there are wheel speed sensors on each wheel, this put the system in an unnatural state, it is not surprising they experienced different results between the static and road tests.  They did understand this, but understanding that they were "doing it wrong" is not especially confidence inspiring.  Although they repeated some tests on the road, it just shows a basic lack of awareness- especially considering the information they could have gathered by running the system on a chassis dynamometer.  Dynos are not rare anymore, either- state emissions testing stations in many states are equipped with rudimentary ones, and performance and speed shops have reliable ones available.  Running on  a dyno would not have solved the wheel speed sensor issue, but it would have addressed load and safety issues.  As far as the the wheel speed issues, depending on the sensor it may have been possible to solve with a simple little hack of the sensor outputs while stationary.
Moving forward to page twelve, we return to good (and disturbing) information:
"The fact that many of these safety-critical attacks are still effective in the road setting suggests that few DeviceControl functions are actually disabled when the car is at speed while driving, despite the clear capability and intention in the standard to do so."
Again with the poorly implemented or enforced standard- this is critical information from the report.  They also found that it was possible to bridge the high- and low-speed busses, that is just plain wrong, and potentially terrifying.  More important findings, I really wish I wasn't questioning everything by this point.
Hopefully you have read the report, don't just accept their findings (or my observations), but put some thought of your own into it.  I hope there is follow up study, and it is done with more caution and better research.
There is one more petty thing I wish to bring up.  They refer to computer managed automobiles as "cyber-physical vehicles", what the [heck] does that mean?  We do not need more cyber-hyphenated nonsense terms.
One more quick car post is coming, then back to your irregularly-scheduled drivel.

Jack

Tuesday, May 25, 2010

Scalable is an abused word.

Vendors love to tell us how "scalable" their products are.  Many, however, fail to grasp that scales have two ends- if you start in the middle and only scale "up", your product is not truly scalable, so stop saying it is.

That's it, just another bit of bitterness from a small business advocate.

 

Jack

Wherein Jack plays paper shredder

In my last post I started a series of rants about cars.  As I said, it has been simmering for a while, but a paper called Experimental Security Analysis of a Modern Automobile (PDF) pushed me to write.  While the first post was not specifically about this paper, this post and some later ones will be.  I'll reiterate that there is a lot of good information in the paper, but you need to sift through a bit of arrogance and ignorance to get maximum benefit from it.  While that is almost universally true of all papers, especially academic ones (they rarely have, or even give credit to, trench-level experience), it is often hard to accept the valid parts of a paper after discovering glaring errors.
Let's start with an excerpt from the very promising abstract:
"Abstract: Modern automobiles are no longer mere mechanical devices; they are pervasively monitored and controlled by dozens of digital computers coordinated via internal vehicular networks.  While this transformation has driven major advancements in efficiency and safety, it has also introduced a range of new potential risks. In this paper we experimentally evaluate these issues on a modern automobile and demonstrate the fragility of the underlying system structure."
(Note: In the Olden Days, we also had systems which "pervasively monitored and controlled " cars, they were called "drivers").
Damn right, cars have become more computerized and the systems are networked- and now more vehicles have multiple wireless communication systems, most (if not all) with some level of access to the onboard networks.  There's a recipe for a playground of badness.  So is this paper.  Rather than shred it entirely, I'll call out a few things which set me off. 
But first, venture back in time with me.  In the early sixties, we had cars with electrically-controlled transmissions.  Not especially reliable, but we had them.  Cars had computers before that, but we didn't call them that.  They were called "automatic transmissions", controlled by hydraulic decision engines which selected the appropriate gear based an a variety of variable inputs- including throttle position, engine load, engine speed, road speed- all under amazing temperature and vibration extremes.  There have been a lot of interesting technologies in autos, often appearing earlier than people realize.  And tinkerers, mechanics, racers, gear-heads, whatever you want to call them started hacking cars and their systems as soon as they got their hands on them.  And it was not new with cars, we've tinkered and pushed the limits of stuff since crawling out of the primordial ooze.  I think a weekend in the pits at an SCCA event might prove eye opening for many- the creativity is amazing.
Diving into a few specifics of the paper, we don't make it out of the first page before we get our first warning:
"Through 80 years of mass-production, the passenger automobile has remained superficially static: a single gasoline-powered internal combustion engine; four wheels; and the familiar user interface of steering wheel, throttle, gearshift, and brake. However, in the past two decades the underlying control systems have changed dramatically."
Maybe we'll let this slide, a bit of hyperbole to start the paper off.  We'll ignore diesel engines, the move from manual to automatic transmissions, front to rear wheel drive, etc.  But then we get to:
"While the automotive industry has always considered safety a critical engineering concern (indeed, much of this new software has been introduced specifically to increase safety, e.g., Anti-lock Brake Systems)"
Anti-lock brakes have certainly evolved considerably, but ABS was effectively mandated for heavy trucks by US FMVSS 121 in 1975.  Yeah, Gerry Ford was in the White House, scourge of disco was beginning to destroy a generation, and polyester was an acceptable fabric for something called the "leisure suit".  Not quite "new" systems.  Maybe I'm still nitpicking.  Cars are different than trucks (but not that different in many ways).  There really is a lot of good information in this paper.  (Of course, if they had let their mechanics read it after getting their cars serviced it would have been a lot better).
Then, we get to this gem:
"In this paper we intentionally and explicitly skirt the question of a threat model. Instead, we focus primarily on what an attacker could do to a car if she was able to maliciously communicate on the car’s internal network. That said, this does beg the question of how she might be able to gain such access.
"While we leave a full analysis of the modern automobile’s attack surface to future research, we briefly describe here the two kinds of vectors by which one might gain access to a car’s internal networks. The first is physical access."
Another little insight for you: if I have physical access to your car, I can now do with a computer, cables and custom software what has been possible for almost eighty years with a pocketknife- damage your brakes.  (Note, cars have been around for over a century, but use of hydraulic brakes was not widespread until the thirties).  You can really get creative with digital attacks, but you've been able to do creative brake damage by exploiting physical and hydraulic vulnerabilities, there's plenty more than simply cutting lines which can be done.  Switching gears (sorry, had to) to traditional information security, ignoring the threat model is best practices.  No, wait, ignoring threat models it is a horrible idea, but sadly common.
"The other vector is via the numerous wireless interfaces implemented in the modern automobile."
Now we're talking, this is a huge problem (at least potentially), and it needs a lot of research.  Skipping forward to section IV. C., there is more critical information.  Not surprising, but important- there are poor standards, implemented poorly and un-enforced.  That is not shocking to those of us in infosec, but especially scary when we're talking about interaction of physical safety systems.  It is a bit depressing that they are surprised by this, and surprised how easily the systems fell to fuzzing attacks, another sign that the authors may not have the real-world experience I would like.
I'll continue the rantview in an upcoming post, but I may become snarky, and possibly mean about it.

Jack

Sunday, May 23, 2010

Some folks need to get over themselves.

This is a multi-part car rant, wherein I insult some "hackers" and "academics" who richly deserve it.  The targets of my scorn are not likely to hear my rants, as they have anatomically unlikely body parts shielding their ears (entire heads, actually).

Where to start...

NEWS FLASH: Car people have been "hardware hacking" longer than you have been alive.  They have also been hacking electrical and electronic systems for many decades.  And hacking onboard computer systems for a few decades.  Just because some computer literate folks decided to play with cars, "hacking cars" is new and newsworthy?  To the folks who believe this, get over yourselves.  Some might say "but Jack, computers make cars too complicated for the dumb mechanics and knuckle-dragging gear heads who beat us up in High School."  To these people I say, you weren't beaten badly enough or often enough in High School.

Back in the dark ages, when I was a mechanic, we did creative tuning and repair when we had to.  Early emissions and computer systems were less than ideal in function and reliability, so we adapted the tricks we knew and added more to compensate.  For example, there is still a handful of mixed resistors in my tool box, we used those to tune gauges- and later to tune the inputs computers received from sensors.  Strategically placed vacuum bleed valves, creative use of timers and relays, and so on- were nothing new to a competent mechanic as we dealt with the influx of computers in autos.  We played mix and match with parts- computers, sensors, chips, whatever we could.  Sure, we were not hacking code, but we broke things just enough to make them work.  If you expand the scope to cover auto racing, especially the cheap, "run what you brung" classes, the ingenuity has been amazing.  Phrases like "you can't do that" and "watch me" have been heard in the pits since the first races.

So when I see stories about car hacking I get a little twitchy.  There are cool projects, like OpenOtto, an open framework for accessing automotive systems and networks, and most folks involved in that seem to have a clue.  I do occasionally hear the odd stupid remark about it (generally from people who don't understand the fundamental difference between data and information), but overall I hope it develops into a powerful and easy to use tool.

What triggered this bit of Goodwill Towards Men?  It has been simmering for a while, but a paper called Experimental Security Analysis of a Modern Automobile (PDF) pushed me over the edge of reason.  Fine, farther over the edge.  There is a lot of good information in the paper, and some crap, and a fair bit of academic arrogance.  I'll start the dissection of the paper in an upcoming post.

 

Jack

Wednesday, May 19, 2010

Observing observers.

Here's a little experiment in observation for you- the next time you are in an airport, watch the watchers.  If you haven't tried it before you are in for an education.  There are a few classes of "watchers" in most airports, I want to focus on three, starting with TSA employees.

Note: TSA bashing is always good fun, but that isn't the point here.  Well, maybe just a little.

When you are in line for the security theater checkpoints, watch the TSA agents as they observe the passengers.  Are they scanning the entire area occasionally, or are they focused on a narrow space?  Do they look around at all?  How do they look at people?  How do they observe the non-passengers (crew, staff, etc.) as they go through security?  What happens when they leave their posts, do they wander off aimlessly, or scan the crowds as they head off wherever they are going?

Next up, "real" law enforcement.  Not just any policeman or sheriff, but you'll know them when you see them.  They see everyone.  They check everyone's eyes, hands and waist- not in a forced, "I just learned this in a webinar" way, but in a fluid and practiced "I am not getting sucker-punched again" way.  You'll know it when someone triggers their interest- the police are generally discreet about it, but it is often clear when someone is getting a secondary (and more thorough) inspection.  They also walk the halls with one shoulder against a wall to reduce the area they need to cover, and to reduce their attack surface.  And they don't stop looking as long as they're in public.

Casa de Sunglasses FashionistaNow, finally, the last group.  The ennui-ridden would-be fashionistas working at the Casa de Sunglasses kiosks  (or whatever they're called).  Really.  Like the police, not all have the skill, but you'll know the ones I mean when you see them.  They see everyone, they see the eyes, the hands- and if not the waist, they are certainly checking out other areas of the bodies of passers-by.  Sure, some people get checked out a lot closer than others, but no one gets by without at least a cursory look.  (I feel like a piece of meat when they look at me like that.  OK, they do not look at me like that.  But a boy can dream).

That's it.  No grandiose conclusions from me- but if you think about it, you may have some new ideas about education, motivation, and observation.  And you might become a bit more observant yourself.

 

Jack

Sunday, May 16, 2010

PDFs are the devil.

This isn't new, but a lot of folks don't seem to realize just how bad PDFs are.  Remember when we told people to send us PDFs instead of Word documents because we thought PDFs were "safe"?  Boy, were we wrong.  OK, we weren't wrong, but times (and threats) have certainly changed.  Now, with the XML-based Office file formats and the proliferation of PDF malware, I'm much more leery of PDFs than DOCX files.  The PDF specs are part of the problem, and the implementations of PDF readers are another part of the problem- the specs allow for things like embedded executables, and the implementations are buggy.  If you haven't read about these issues, check out the articles below:

http://www.f-secure.com/weblog/archives/00001903.html

http://www.f-secure.com/weblog/archives/00001923.html

http://blog.didierstevens.com/2010/03/31/escape-from-foxit-reader/

Some have suggested disabling JavaScript in your PDF reader, but that doesn't resolve all of the issues.  I don't have a perfect solution, but I do have a suggestion, one that I've adopted- it is far from perfect, (it is slow and lacks features), but it works to add a layer of protection when viewing PDFs online.  Gpdf can be deployed to your browsers (Google Chrome and Mozilla FireFox only), it will open PDFs in Google Docs, this moves rendering to Google's servers and adds a big layer of protection to your browser.  Information and installation instructions are available from http://blog.arpitnext.com/gpdf.  Google docs rewrites PDFs on the fly, and adds a significant layer of protection.  Now don't be naive, Google rewrites the PDF so they can see what you are reading, and any anti-malware systems they use are to protect their servers, not you- they are Google, after all.

As I said, Gpdf is not perfect, but it is a step forward.  Which is the right direction.

 

Jack

Friday, May 14, 2010

Who's up for a SecTorBus trip?

We tried last year, and it almost, very nearly, happened.  But it did not.  Maybe with a bit more lead time we can do it this fall, a road trip to Toronto for the awesome SecTor security conference.  Like a Shmoobus, but headed north instead of south.  Interested? Email me at work, jdaniel [at] astaro.com  I'll try to get them to sponsor again (they're cool like that).

Possible routes are Boston to Northern Virginia to Toronto, or maybe Northern Virginia to Boston to Toronto.  It depends on who joins us, and which highway that stand beside waiting for a ride.

And, no, it will not look like this:

bus

Let me know...

Jack

Wednesday, May 12, 2010

Quick Update on HacKid

HacKid is coming together nicely, with events in the Boston area (Cambridge, actually) and Northern Virginia.  It looks like the inaugural event on the weekend of August 28-29.  The website and wiki have been updated, and there's more information on the latest episode of the Southern Fried Security podcast.

Round up the little guttersnipes and get them involved.  You, too.

 

Jack

Wednesday, May 5, 2010

HacKid Conferences

Have kids? Nieces, nephews, grandkids? Maybe Big Brother/Big Sister or some other rent-a-youth? Perhaps you just want to boost your chances of working with functional young folks in several years when they join the workforce.  Chris Hoff had a great idea at SOURCE Boston this year, he brought his three daughters- which got him thinking about kids, conferences and hacking.

The result sounds like a great idea, HacKid conferences, check out the site for more info, then join and contribute to the wiki.  It looks like Labor Day weekend will be the first round of events, but keep an eye on the HacKid site for updates.

 

Jack