'

The Current State of Automotive Security by Chris Valasek

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

INTRODUCTION  


Слайд 2

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


Слайд 3

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


Слайд 4

ANATOMY  OF  AN  ATTACK  


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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)  


Слайд 9

ELECTRONIC  CONTROL  UNITS   (ECUS)  


Слайд 10

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  


Слайд 11

ECU  Structure  


Слайд 12

Ford  PCM  Connector  


Слайд 13

Ford  PCM  ECU  


Слайд 14

CAN  BASICS  


Слайд 15

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  


Слайд 16

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  


Слайд 17

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…  


Слайд 18

STANDARDS  &  PROTOCOLS  


Слайд 19

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  


Слайд 20

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


Слайд 21

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  


Слайд 22

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


Слайд 23

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  


Слайд 24

CURRENT  ATTACKS  


Слайд 25

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    


Слайд 26

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


Слайд 27

Speedometer:  Ford  II  


Слайд 28

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


Слайд 29

Braking:  Toyota  II    


Слайд 30

Steering:  Toyota  II  


Слайд 31

Accelera/on:  Toyota  II  


Слайд 32

DIAGNOSTIC  CAN  INJECTION  


Слайд 33

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  


Слайд 34

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


Слайд 35

Reversing  the  Ford  IDS  tool  


Слайд 36

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


Слайд 37

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


Слайд 38

Kill  Engine:  Ford  


Слайд 39

Lights:  Toyota  


Слайд 40

Lights:  Ford  


Слайд 41

Horn:  Toyota  


Слайд 42

Seat  Belt:  Toyota  


Слайд 43

Doors  Lock/Unlock:  Toyota  


Слайд 44

Fuel  Gauge:  Toyota  


Слайд 45

Disable  brakes:  Ford  


Слайд 46

FIRMWARE  


Слайд 47

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


Слайд 48

Disassembling   target  processor  Motorola  HCS12X  


Слайд 49

Con/nued  access  


Слайд 50

SECURING  THE  MODERN  VEHICLE  


Слайд 51

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


Слайд 52

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  


Слайд 53

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  


Слайд 54

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  


Слайд 55

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  


Слайд 56

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  


Слайд 57

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  


Слайд 58

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  


Слайд 59

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  


Слайд 60

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  


Слайд 61

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)   100 90 80 70 60 50 40 30 20 10 0 Frequency distribution of 0201 CAN id


Слайд 62

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  


Слайд 63

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)  


Слайд 64

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  


Слайд 65

CONCLUSION  


Слайд 66

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  


Слайд 67

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


Слайд 68


×

HTML:





Ссылка: