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