The Current State of Automotive Security by Chris Valasek

33 %
67 %
Information about The Current State of Automotive Security by Chris Valasek
Technology

Published on March 12, 2014

Author: codeblue_jp

Source: slideshare.net

Description

Automotive computers, or Electronic Control Units (ECU), were originally introduced to help with fuel efficiency and emissions problems of the 1970s but evolved into integral parts of in-car entertainment, safety controls, and enhanced automotive functionality. This presentation will examine some controls in two modern automobiles from a security researcherís point of view. We will first cover the requisite tools and software needed to analyze a Controller Area Network (CAN) bus. Secondly, we will demo software to show how data can be read and written to the CAN bus. Then we will show how certain proprietary messages can be replayed by a device hooked up to an ODB-II connection to perform critical car functionality, such as braking and steering. Finally, weíll discuss aspects of reading and modifying the firmware of ECUs installed in todayís modern automobile.

Chris Valasek

Christopher Valasek is the Director of Security Intelligence at IOActive, an industry leader in comprehensive computer security services. Valasek specializes in offensive research methodologies with a focus in reverse engineering and exploitation. Valasek is known for his extensive research in the automotive field and his exploitation and reverse engineering of Windows. Valasek is also the Chairman of SummerCon, the nation’s oldest hacker conference. He holds a B.S. in Computer Science from the University of Pittsburgh.

The  current  state  of     automo/ve  security   Dr.  Charlie  Miller  (@0xcharlie)   Chris  Valasek  (@nudehaberdasher)  

INTRODUCTION  

Who   •  Charlie  Miller     [Security  Engineer]     |Twi2er|   •  Chris  Valasek     [Director  of  Security  Intelligence]  | IOAc8ve|    

Agenda   •  Anatomy  of  an  aJack   •  CAN  Basics   •  AJacking  the  CAN  bus   •  Securing  the  modern  vehicle  

ANATOMY  OF  AN  ATTACK  

Step  1:  Code  execu/on   •  Remote   Telema/cs  unit   TPMS   Bluetooth   “Connec/vity”  apps,   Web  browser,  etc  

Step  1:  Code  execu/on  (cont.)   •  Local  

Step  2:  CAN  message  injec/on   Compromised  ECU   ABS  ECU   Steering  ECU   Other  ECUs…  

AJack  Scenario   •  A  remote  vulnerability  s/ll  relies  on  ‘local’   informa/on   –  Example:  A  remote  exploit  targe/ng  a  vulnerability  in   the  Bluetooth  receiver  is  only  harmful  if  the  aJacker   knows  specific  informa/on  about  the  vehicle   •  Both  learning  the  local  control  and  remote   vulnerability  are  required     •  Local  can  actually  take  longer  due  to  being   different  for  every  vehicle   –  Remote  can  span  makes/models  due  to  nature  of   OEM  purchasing  of  devices  (i.e.  infotainment  systems)  

ELECTRONIC  CONTROL  UNITS   (ECUS)  

Electronic  Control  Units   •  Controls  almost  every  aspect  of  the  modern   automobile   •  Take  input  from  sensors  and  provide  output  to   actuators     •  Located  in  various  places  throughout  the  car   •  ECUs  are  running  custom  code  on  unusual   hardware   – Infotainment  systems  may  be  Linux/Windows   variant,  but  func/on  ECUs  are  custom  code  

ECU  Structure  

Ford  PCM  Connector  

Ford  PCM  ECU  

CAN  BASICS  

CAN  Overview   •  CAN  IDs  can  be  11  or  29  bits  long   •  Data  length  can  be  0  to  8  bytes  in  length   •  CAN  ID  is  used  as  a  priority  field   – CAN  ID  00  has  priority  over  CAN  ID  01   •  Interes/ng  data  is  in  the  applica/on  layer   •  Broadcast  in  nature.  Therefore  all  nodes  on  a   bus  will  see  all  messages  

Normal  CAN  message   •  Ford  Escape     –  IDH: 03, IDL: B1, Len: 08, Data: 80 00 00 00 00 00 00 00 •  Toyota  Prius   –  IDH: 00, IDL: B6, Len: 04, Data: 33 A8 00 95 •  Varying:  Lengths,  IDs,  Data   –  Toyota  has  a  checksum  of  “95”  at  the  app  layer   *  This  format  was  designed  by  us  to  be  human   readable  and  diges/ble  by  our  API  

Diagnos/c  Example   •  Ford  Escape  communica/ng  with  ABS  ECU   –  IDH: 07, IDL: 60, Len: 08, Data: 03 14 FF 00 00 00 00 00 IDH: 07, IDL: 68, Len: 08, Data: 03 7F 14 78 00 00 00 00 IDH: 07, IDL: 68, Len: 08, Data: 03 54 FF 00 00 00 00 00 •  Each  ECU  has  one  or  more  IDs  associated   – In  this  case,  ABS  is  0760   •  Responses  are  8  more  than  ID   •  Mainly  used  by  mechanics,  but  we’ll  show   how  some  are  used  by  us…  

STANDARDS  &  PROTOCOLS  

Useful  Standards  &  Protocols   •  ISO  15765-­‐2  (ISO-­‐TP)   – Standard  for  sending  arbitrary  length  data  over   CAN   •  ISO  14229/14230   – Standard  for  services  running  on  the  ECU   – No  service  is  mandatory   – Defines  certain  bytes  for  diagnos/c  purposes  

Services:  SecurityAccess   •  SecurityAccess  is  used  to  perform  sensi/ve  diagnos/c  ac/ons     (such  as  reprogramming  an  ECU)   –  IDH: 07, IDL: 26, Len: 08, Data: 02 27 01 00 00 00 00 00 IDH: 07, IDL: 2E, Len: 08, Data: 05 67 01 54 61 B6 00 00 IDH: 07, IDL: 26, Len: 08, Data: 05 27 02 D0 B6 F1 00 00 IDH: 07, IDL: 2E, Len: 08, Data: 02 67 02 00 00 00 00 00 •  Authen/ca/on  with  0726  (SJB)   –  27  01  =>  Request  Seed   •  ECU  sends  back  OK  and  seed  (challenge)   •  Programmer  sends  back  response   •  ECU  Sends  back  OK   –  67  02  =>  OK  for  security  level  02  

Services:  InputOuputControl   •  Authorized  tools  to  control  or  monitor   external  inputs  to  the  ECU  (i.e.  do  stuff)   –  IDH: 07, IDL: E0, Len: 08, Data: 06 2F 03 07 03 00 00 00 IDH: 07, IDL: E8, Len: 08, Data: 06 6F 03 07 03 36 90 00 •  Send  inputOutputControl  test  to  07E0   – 2F  =>  ISO-­‐14229  code  for  inputOutputControl   – 03  07  =>  The  control  to  be  tested   – 03  00  00  =>  Data  provided  for  the  test  

Some  other  interes/ng  PIDs   •  ECUReset   •  ReadMemoryByAddress   •  Rou/neControl     •  RequestDownload   •  RequestUpload   •  TransferData   •  TesterPresent   •  WriteMemoryByAddress  

Systemic  Issues   •  CAN  was  designed  decades  ago  without   security  in  mind   •  CAN,  by  nature,  does  not  support   authoriza/on,  authen/ca/on,  or  encryp/on   •  An  industry  relying  solely  on  entry  point   security  is  doomed  to  fail   •  Although  aJack  data  will  vary,  methods  are   universal  across  make  and  manufacturer  

CURRENT  ATTACKS  

Injec/on  Limita/ons   •  Not  all  func/ons  in  an  automobile  are   performed  over  CAN  (yet)   – Electric  ThroJle  in  Ford  Escape     •  Original  vs.  Forged  Messages   – S/ll  have  legi/mate  coming  from  the  ECU,  forging   may  produce  varying  results   •  Safety  features  might  need  bypassed   – Toyota  speed  limit  for  steering  during  IPAS    

Speedometer:  Ford   •  Set  the  speedometer  to  arbitrary  values   •  CAN  ID:  0201   •  Length:  08   •  Format:  AA  BB  00  00  CC  DD  00  00   •  Speed  =>  0.0065  *  (CC  DD)  –  67   •  RPM  =>  0.25  *  (AA  BB)  –  24   •  Example  (20.1mph  |  2233  rpm):     IDH: 02, IDL: 01, Len: 08, Data: 23 45 00 00 34 56 00 00

Speedometer:  Ford  II  

*  Please  see  paper  for  packet  dissec/on  and  code.    

Braking:  Toyota  II    

Steering:  Toyota  II  

Accelera/on:  Toyota  II  

DIAGNOSTIC  CAN  INJECTION  

SecurityAccess   •  A  few  ECUs  from  each  car  responded  and   accepted  the  SecurityAccess  service   •  For  these  ECUs  we’ve  figured  out  the  secrets   to  produce  valid  keys  from  the  seeds  provided   •  This  permits  the  ECUs  to  be  put  in   reprogramming  mode  and  other  special   diagnos/c  states  

SecurityAccess:  Ford   •  PAM  doesn’t  send  random  seeds   •  IDH: 07, IDL: 36, Len: 08, Data: 02 27 01 00 00 00 00 00 •  IDH: 07, IDL: 3E, Len: 08, Data: 05 67 01 11 22 33 00 00 •  IDH: 07, IDL: 36, Len: 08, Data: 05 27 02 CB BF 91 00 00 •  IDH: 07, IDL: 3E, Len: 08, Data: 02 67 02 00 00 00 00 00 •  Other  ECUs  do  send  random  seeds  

Reversing  the  Ford  IDS  tool  

Ford  Escape  keys   secret_keys = { 0x727: "50 C8 6A 49 F1", 0x733: "AA BB CC DD EE", 0x736: "08 30 61 55 AA", 0x737: "52 6F 77 61 6E", 0x760: "5B 41 74 65 7D", 0x765: "96 A2 3B 83 9B", 0x7a6: "50 C8 6A 49 F1", 0x7e0: "08 30 61 A4 C5",} secret_keys2 = { 0x7e0: "44 49 4F 44 45", 0x737: "5A 89 E4 41 72”}

Academic  research   •  securityAccess  to  ECU  then  diagnos/c  messages  using  the   ‘DeviceControl’  Service    

Kill  Engine:  Ford  

Lights:  Toyota  

Lights:  Ford  

Horn:  Toyota  

Seat  Belt:  Toyota  

Doors  Lock/Unlock:  Toyota  

Fuel  Gauge:  Toyota  

Disable  brakes:  Ford  

FIRMWARE  

Dumping  firmware   Freescale  USB  S08/HCS12  BDM  Mul/link  In-­‐Circuit  Debugger/ Programmer  is  connected  to  the  BDM  header  

Disassembling   target  processor  Motorola  HCS12X  

Con/nued  access  

SECURING  THE  MODERN  VEHICLE  

There  are  a  few  strategies   •  Secure  remote  endpoints   •  Cryptographically  verify  messages   •  Segment  CAN  network/isolate  ECUs   •  Detect/prevent  aJacks  real-­‐/me  

Industry  Statement   “Our  focus,  and  that  of  the  en/re  auto  industry,  is   to  prevent  hacking  into  a  vehicle's  by-­‐wire  control   system  from  a  remote/wireless  device  outside  of   the  vehicle.    Toyota  has  developed  very  strict  and   effec/ve  firewall  technology  against  such  remote   and  wireless  services.    We  con/nue  to  try  to  hack   our    systems  and  have  a  considerable  investment  in   state  of  the  art  electro-­‐magne/c  R&D  facili/es.    We   believe  our  systems  are  robust  and  secure.”      -­‐  John  Hanson  |  Toyota  Motor  Sales  U.S.A  

External  Security  Dependencies   •  Total  security  is  not  achievable     –  Humans  make  mistakes   –  We  haven’t  been  able  to  secure  PCs,  what  make  you   think  automo/ve  is  different?   –  Enterprises  do  not  implement  a  single  /ered  approach   with  PCs,  why  should  automobiles?     –  3rd  party  assessment  appears  to  be  rare   –  ECU  patching  for  known  vulnerabili/es  can  be   complicated   –  Addi/onal  remote  aJack  vectors  being  added  each   year  

Cryptography/Authen/ca/on   •  Many  suggest  encryp/ng  applica/on-­‐layer  data   –  Unfortunately  doesn’t  seem  viable  at  this  point  due  to   real-­‐/me  necessity  of  the  automo/ve  system   –  Example:  The  brakes  have  to  work  in  real-­‐/me  and  can   NEVER  take  too  long   –  Key  management  is  also  difficult   •  If  its  in  the  ECU,  it  can  probably  be  reversed   –  Reverse  Engineering  of  the  ECU/mechanics  tools  can   result  in  cryptography  being  subverted   –  Should  not  rely  on  obscurity  to  protect  driver  

More  on  obscurity  and  security   •  "One  reason  for  the  industry's  success  in  preven4ng  bad   actors  from  doing  malicious  things  to  vehicles  is  that   individual  automakers  have  done  a  very  good  job  of  keeping   security  sensi4ve  informa4on  from  falling  into  the  wrong   hands,"  wrote  Mitch  Bainwol,  the  CEO  of  the  Alliance  of   Automobile  Manufacturers  and  Mike  Stanton  of  the   Associa/on  of  Global  Automakers   •  If  the  only  thing  preven/ng  a  bad  guy  from  crashing  your  car   is  that  they  have  to  look  hard  for  the  info,  there  is  no  real   security  

Segmenta/on   •  Isolate  ECUs  on  different  CAN  buses   – Bridging  traffic  is  s/ll  necessary   •  Example:  Infotainment  system  s/ll  needs  to  get   messages  about  speed   •  Status  of  car  must  be  presented  on  instrument  cluster   – Bridge  must  NOT  forward  incorrect  traffic   – Bridge  is  now  the  weakest  link  /  aJack  target   – CAN  bridges  will  be  proprietary  in  nature,  forcing   them  to  be  updated  &  augmented  constantly  

Detec/on  of  aJacks   •  Don’t  exclusively  rely  on  making  aJacks   difficult,  instead  focus  on  detec/ng  aJacks   and  taking  ac/on   •  Can’t  always  stop  aJack,  but  you  can  take   ac/on  when  one  is  happening   •  Analogous  to  IDS/IPS  in  enterprise   environments  

Advantages   •  Vehicular  networks  are  especially  well  suited   for  aJack  detec/on   •  CAN  messages  are  very  standard  and   predictable   •  The  frequency  of  messages  and  their  content   vary  in  predictable  ways   •  AJacks  stand  out  and  can  easily  be  detected  

CAN  Traffic  is  Simple   •  We  recorded  CAN  traffic  while  driving  around   for  15  minutes   •  The  CAN  ID’s  found  in  the  first  second  of  the   trip  were  recorded  for  both  Ford  and  Toyota   •  No  addi/onal  CAN  ID’s  were  found  the  rest  of   the  trip   •  Any  addi/onal  CAN  ID’s  (such  as  diagnos/c   messages)  would  be  suspicious  

Frequency  of  CAN  messages   •  Frequency  of  messages  from  IDs  does  not  have   much  devia/on   •  Comparison  of  messages  from  the  start  of  a   capture  and  in  random  loca/ons  within  the  same   capture   Hit  Counts:  Primary[03A9]  =>  9          |  Secondary[03A9]  =>  5   Hit  Counts:  Primary[0255]  =>  166  |  Secondary[0255]  =>  119   Hit  Counts:  Primary[0230]  =>  991  |  Secondary[0230]  =>  1011   Hit  Counts:  Primary[0250]  =>  168  |  Secondary[0250]  =>  209   Hit  Counts:  Primary[03C4]  =>  41      |  Secondary[03C4]  =>  46   Hit  Counts:  Primary[0340]  =>  80      |  Secondary[0340]  =>  82   Hit  Counts:  Primary[0422]  =>  83      |  Secondary[0422]  =>  36   Hit  Counts:  Primary[0423]  =>  17      |  Secondary[0423]  =>  6   Hit  Counts:  Primary[0420]  =>  83      |  Secondary[0420]  =>  47   Hit  Counts:  Primary[0200]  =>  496  |  Secondary[0200]  =>  630  

Detec/ng  AJacks:  Normal  Packets   •  Our  injec/on  aJacks  are  ‘loud’   –  Use  high  frequency  of  packets  to  ensure  that  it  out  numbers  legi/mate   traffic   •  Example:  Sending  speed  packets  will  conflict  with  actual  speed     (in  MPH  and  frequency)   •  Frequency  per  second  (we  send  about  20x  faster)   0 10 20 30 40 50 60 70 80 90 100 Frequency distribution of 0201 CAN id

Detec/ng  AJacks:  Diagnos/c   Messages   •  Diagnos/c  packets  are  usually  performed   when  mechanics  are  performing  tests   – Not  while  car  is  moving  (or  at  least  driving  at   highway  speeds)   •  Our  aJacks  based  on  this  would  easily  be   detected   •  ALL  significant  aJacks  outlines  in   “Experimental  Security  Analysis  of  a  Modern   Automobile”  stem  from  diagnos/c  messages  

Ac/ons  to  take   •  Alert  driver   •  Shut  down  CAN  network     (for  example,  short  CAN  Hi  to  CAN  Lo)   •  Safely  stop  vehicle   •  Poten/ally  ignore  certain  messages  for  a   period  of  /me  (if  not  cri/cal)  

The  detec/on  code   •  Add  an  IPS  ECU  to  each  CAN  network   •  Add  code  to  exis/ng  ECUs   •  Add  hardware  module  which  plugs  into  obdii   port  

CONCLUSION  

Conclusion   •  AJacks  consist  of  two  sides:  compromise  &  control   •  Vehicles  can  be  physically  controlled  via  the  CAN  bus   by  malicious  aJackers   •  CAN  and  corresponding  architecture  were  NOT   designed  with  security  in  mind   •  Relying  solely  on  external  input  security  is  imperfect  at   best   •  A  layered  approach  to  security  is  beJer  (and  cheaper)   •  Generically  detec/ng  &  protec/ng  the  vehicle  appears   to  be  the  most  effec/ve  method  for  automo/ve  safety  

Ques/ons?   •  Dr.  Charlie  Miller  (@0xcharlie)   –  TwiJer  Guy   –  cmiller@openrce.org   •  Chris  Valasek  (@nudehaberdasher)   –  Director  of  Security  Intelligence  @  IOAc/ve   –  cvalasek@gmail.com  

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

The Current State of Automotive Security - YouTube

Chris Valasek, Director of Security Intelligence, IOActive As automobiles become more connected, thoughts go towards their vulnerability to ...
Read more

CodeBlue01 : The Current State of Automotive Security by ...

by Chris Valasek ... The Cybersecurity Trilogy: Three Problems, Three Solutions - Connected Car Expo 2015 - Duration: 34:38.
Read more

4th Cyber Security for Automotive San Francisco

... into the current state of the automotive OE's and ... the Automotive Industry . Security experts from ... Chris Clark Principal Security ...
Read more

Chris Valasek | RSA Conference

Chris Valasek, Security lead at Uber ATC. ... The Current State of Automotive Security USA 2014; Chris’s Sessions Intro to Car Hacking USA 2016;
Read more

Codeblue01 : The Current State Of Automotive Security By ...

... The Current State Of Automotive Security By Chris Valasek; ... The Current State of Automotive Security by Chris Valasek For More Information ...
Read more

The Current State of Automotive Security by Chris Valasek ...

Automotive computers, or Electronic Control Units (ECU), were originally introduced to help with fuel efficiency and emissions problems of the 1970s but ...
Read more

IOActive | Automotive Cyber Security Summit

The Current State of Automotive Attacks and Protections. ... About Chris Valasek ... About Automotive Cyber Security Summit
Read more

IOActive | CODE BLUE

The Current State of Automotive Security. ... Chris Valasek will discuss how automotive networks ... and IBM Internet Security Systems. Valasek is also ...
Read more

The Current State of Automotive Security | USA 2014 | RSA ...

Chris Valasek Security Engineer, Uber ATC Speaker ... The Current State of Automotive Security Upcoming Conferences Abu Dhabi 2016. USA 2017.
Read more