[SystemSafety] The Crisis of Connected Cars. Also connection in general

[Peter Bernard Ladkin]

On 2017-08-25 13:46 , Martyn Thomas wrote:
> http://blog.trendmicro.com/trendlabs-security-intelligence/connected-car-hack/
> 
> " ... what should the security industry’s response be when a hack is found that is not only
> successful in being able to drastically affect the performance and function of the car, but is also
> stealthy and vendor neutral? Enter the hack that does just that—one that has been discovered and
> proven to be effective ......"

Topic 1. CAN Bus

I took a look at this last week, and again just now after this appeared in the Risks Forum Digest.
The TrendMicro essay suggests that they install/inject something which modifies existing CAN-Bus
packets from a specific device so that they are determined to be erroneous and the device is locked
out of the bus per CAN specification. They sort-of claim not to need physical access, but they
obviously do need to be able to get to some port at some time, and they have to have something
attached to the bus which modifies existing bus packets continually.

They also don't say anything about the design of the trojan agent, so one has no idea what it does.
It is not a frame-injection attack. I didn't quite believe they didn't need physical access. You
can't modify bus frames without having some node on the network doing it.

This is actually an academic thesis (see below). They need to - and do - attach a rogue node, a
diagnostic-port dongle. The key point of the exercise is that people have been aware of how to
detect and defend against frame-injection attacks for a while, most of the well-publicised previous
attacks have been frame-injection, and this is not one of those.

A key feature is that this is not just theory, but was tried out on an unmodified Alfa Romeo. They
attached a custom-built dongle to the diagnostic port.

The scientific paper appeared at the 14th International Conference on Detection of Intrusions and
Malware, and Vulnerability Assessment, DIMVA 2017, in Bonn in July 2017. The conference volume was
published in the LNCS series http://www.springer.com/de/book/9783319608754 and costs just over €55
as e-book, just over €70 as paper. The article itself is entitled A Stealth, Selective, Link-Layer
Denial-of-Service Attack Against Automotive Networks, is 21pp long and costs just under €30 to buy.

The paper itself stems from academic work by Andrea Palanca under Prof. Stefano Zanero at the
Politecnico di Milano and is a thesis (tesi di laurea - it doesn't specify for what academic grade)
from the academic year 2015-6, so the work is at least a year old. The thesis is written in English
and is available at https://www.politesi.polimi.it/bitstream/10589/126393/1/tesi_palanca.pdf

The source code for the board used in the dongle is contained in the thesis. It is 76 lines long,
with the first 6 lines commentary (Listing 5.5, pp58-60).

The thesis is written in astonishingly good technical English and is very readable.

He does discuss countermeasures, but misses what to me is the most obvious one, which is to
implement bus-system integrity checks on start-up. He does discuss a specific one, based on using
electrical properties to discover a rogue node, but that is very specific, and takes longer to
describe than the five words I just used.

Topic 2. Resilience.

I appear to be getting some emails from SRI's Computer Science Laboratory again, although I still
cannot reach their WWW site or effectively send mails to PGN or John Rushby - SRI in generally
apparently has cut off DNS service to Germany and the Netherlands, for some weeks now, I understand
deliberately. Rumor has it that SRI has been suffering sustained Internet attacks originating in the
Netherlands and Germany.

I discovered this some weeks ago, when I couldn't reach PGN. I have two email accounts, the Uni one
going through my faculty servers, and the causalis one going through some ISP's servers in Southern
Germany. Sending mail didn't work through either. DNS queries for the MX record of csl.sri.com
turned up nothing - neither was the A record for the WWW server www.csl.sri.com visible. I did
manage to get my ISP help-line responder to query DNS. They used Google's server 8.8.8.8 - and
succeeded! I asked them to use their own, but at that point the dialog faded (I have never mastered
the art of leading people through diagnostics over the telephone that do not fit their world view,
which in the case of help-line personnel is often limited). Sören Bollmann in my group noted that
Amazon's farm server in Frankfurt also didn't answer the queries positively. Sascha Frey in my
faculty noted that SRI's authoritative relay machines were not answering queries from TechFak, Uni-BI.

I sent PGN a note for the Risks Forum remarking on the fragility of this communication structure we
have built up over the last forty years (not published). I used to work at SRI a third of a century
ago and now I can't communicate with them. At least the postal services used to have a legal
obligation to deliver letters.

I participate in a closed mailing list run through SRI on engineering matters very important to me.
I've been on it for twenty-five years. Now, I'm just blocked (sending and receiving).

There are also key papers archived on the SRI WWW site. I can't reach it any more.

This has been going on now for three weeks.

What might this have to do with safety? It is another example of lack of resilience in our new
communications infrastructure. We discussed on this list Roger Kemp's studies of the December 2015
outage in Lancaster. In 2010-11 I participated in a year-long research group on Communicating
Disaster, convened at the ZiF, our local center for interdisciplinary research which convenes such
groups of researchers from all over the world for up to a year. It was organised by and mainly
filled with sociologists who specialised in disaster organisation and relief. One eminent researcher
was really convinced of the possibilities of using Twitter for emergency social communications. She
had done excellent work on it, but of course it all presumes the cell-phone net is up and running
and everyone has fully-charged phones. We learnt through Lancaster how reliable that hypothesis is.

Our electricity supply went down on Sunday. The substation with its 10KV -> 400V/230V transformer
(trafo in everyday German. The spoken words are often smaller than they look in print :-) ) is a
small shed across the road from my house, so I get to chat with the repairpeople and look at their
network maps and so on. The substations run autonomously for their areas, but when one goes out
there is the possibility to supply current from others. They have to be manually switched on-site.
It doesn't take long, about an hour or so. Somebody comes out (15-20 minutes, longer on Sunday),
diagnoses the local fault (quarter to half an hour), goes to another box/other boxes and switches
it/them through (ten minutes to a quarter hour) and then comes back to run checks before leaving
(quarter hour). Sunday we had a faulty switch. They switched to external supply from other boxes.
Monday they replaced the switch. I asked how often they went out (and the trafo). Apparently
Bielefeld has about a thousand boxes, so it is a regular occurrence (either switch or trafo), but
individual reliability is high. In eleven years here, for example, this is as far as I know the
first occurrence of faulty kit I have experienced. I wonder what it is going to be like in ten
years, when everybody wants to recharge their electric cars at home? Even supposing all those Mode 1
recharger boxes are correctly installed. This question is asked quite regularly, but this summer it
seems as if lots of key players and commentators have decided that electric vehicles are the (only)
future. Time to reread Roger Kemp's RAEng report
http://www.raeng.org.uk/publications/reports/electric-vehicles
-- 

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170901/5201af57/attachment.sig>