Attacking AUTOSAR using Software and Hardware Attacks Pascal al - - PowerPoint PPT Presentation

attacking autosar using software and hardware attacks
SMART_READER_LITE
LIVE PREVIEW

Attacking AUTOSAR using Software and Hardware Attacks Pascal al - - PowerPoint PPT Presentation

Attacking AUTOSAR using Software and Hardware Attacks Pascal al Nasahl Graz University of Technology Niek Timmer mers Riscure 1 Introduction 2 Introduction Niek Timmers Principal Security Analyst @ Riscure 3 Introduction


slide-1
SLIDE 1

1

Attacking AUTOSAR using Software and Hardware Attacks

Pascal al Nasahl Graz University of Technology Niek Timmer mers Riscure

slide-2
SLIDE 2

2

Introduction

slide-3
SLIDE 3

3

Introduction

  • Niek Timmers
  • Principal Security Analyst @ Riscure
slide-4
SLIDE 4

4

Introduction

  • Niek Timmers
  • Principal Security Analyst @ Riscure
  • Analyzing and testing of embedded technologies
slide-5
SLIDE 5

5

Introduction

  • Niek Timmers
  • Principal Security Analyst @ Riscure
  • Analyzing and testing of embedded technologies
  • Research
  • Automotive, secure boot, fault injection, etc.
  • More at niektimmers.com and riscure.com
slide-6
SLIDE 6

6

Introduction

  • Niek Timmers
  • Principal Security Analyst @ Riscure
  • Analyzing and testing of embedded technologies
  • Research
  • Automotive, secure boot, fault injection, etc.
  • More at niektimmers.com and riscure.com

Please visit Riscure’s booth for more information! 

slide-7
SLIDE 7

7

Today’s Agenda

slide-8
SLIDE 8

8

Today’s Agenda

  • Brief introduction to AUTOSAR Classic
slide-9
SLIDE 9

9

Today’s Agenda

  • Brief introduction to AUTOSAR Classic
  • Attacks on AUTOSAR
slide-10
SLIDE 10

10

Today’s Agenda

  • Brief introduction to AUTOSAR Classic
  • Attacks on AUTOSAR
  • Case study
slide-11
SLIDE 11

11

Today’s Agenda

  • Brief introduction to AUTOSAR Classic
  • Attacks on AUTOSAR
  • Case study
  • Wrap-up
slide-12
SLIDE 12

12

Today’s Agenda

  • Brief introduction to AUTOSAR Classic
  • Attacks on AUTOSAR
  • Case study
  • Wrap-up
  • Q&A
slide-13
SLIDE 13

13

AUTOSAR Classic

slide-14
SLIDE 14

14

AUTOSAR Classic

  • Layered software

architecture

slide-15
SLIDE 15

15

AUTOSAR Classic

  • Layered software

architecture

  • Most layers are independent

from the Microcontroller

slide-16
SLIDE 16

16

AUTOSAR Classic

  • Layered software

architecture

  • Most layers are independent

from the Microcontroller

  • Improve software reusability
slide-17
SLIDE 17

17

AUTOSAR Classic

Complex Drivers

Microcontroller

Runtime Environment

Microcontroller Drivers Memory Drivers I/O Drivers I/O Hardware Abstraction Memory Hardware Abstraction Memory Services System Services Onboard Device Abstraction Wireless Communication Drivers Communication Hardware Abstraction Off-board Communication Services

Application Layer

Crypto Drivers Crypto Hardware Abstraction Crypto Services Communication Drivers Communication Services Wireless Communication HW Abstraction

slide-18
SLIDE 18

18

AUTOSAR Classic

Complex Drivers

Microcontroller

Runtime Environment

Microcontroller Drivers Memory Drivers I/O Drivers I/O Hardware Abstraction Memory Hardware Abstraction Memory Services System Services Onboard Device Abstraction Wireless Communication Drivers Communication Hardware Abstraction Off-board Communication Services

Application Layer

Crypto Drivers Crypto Hardware Abstraction Crypto Services Communication Drivers Communication Services Wireless Communication HW Abstraction

Vulnerabilities can be introduced in any layer!

slide-19
SLIDE 19

19

Summary of AUTOSAR

slide-20
SLIDE 20

20

Summary of AUTOSAR

  • Complex software; will contain bugs/vulnerabilities
slide-21
SLIDE 21

21

Summary of AUTOSAR

  • Complex software; will contain bugs/vulnerabilities
  • Made by different vendors / developers
  • Do you trust your suppliers?
slide-22
SLIDE 22

22

Summary of AUTOSAR

  • Complex software; will contain bugs/vulnerabilities
  • Made by different vendors / developers
  • Do you trust your suppliers?
  • Mature code due to safety requirements
  • i.e. MISRA-C
slide-23
SLIDE 23

23

Summary of AUTOSAR

  • Complex software; will contain bugs/vulnerabilities
  • Made by different vendors / developers
  • Do you trust your suppliers?
  • Mature code due to safety requirements
  • i.e. MISRA-C

Mature! But not guaranteed secure...

slide-24
SLIDE 24

24

What can go wrong?

slide-25
SLIDE 25

25

Potential MCAL vulnerabilities

slide-26
SLIDE 26

26

Potential MCAL vulnerabilities

slide-27
SLIDE 27

27

Potential MCAL vulnerabilities

Who verifies your MCAL for vulnerabilities?

slide-28
SLIDE 28

28

What about MISRA-C?!

slide-29
SLIDE 29

29

What about MISRA-C?!

slide-30
SLIDE 30

30

What about MISRA-C?!

You cannot conform to directives automagically…

slide-31
SLIDE 31

31

What else?

slide-32
SLIDE 32

32

Vulnerabilities in complex software

slide-33
SLIDE 33

33

Vulnerabilities in complex software

slide-34
SLIDE 34

34

Vulnerabilities in complex software

Who verifies your communication stack?

slide-35
SLIDE 35

35

Mitigating software vulnerabilities

slide-36
SLIDE 36

36

Mitigating software vulnerabilities

  • Minimize the low hanging fruit
  • Secure coding standard, code checkers, ...
slide-37
SLIDE 37

37

Mitigating software vulnerabilities

  • Minimize the low hanging fruit
  • Secure coding standard, code checkers, ...
  • Find vulnerabilities yourself before attackers do
  • Continuous security code reviews, ...
slide-38
SLIDE 38

38

Mitigating software vulnerabilities

  • Minimize the low hanging fruit
  • Secure coding standard, code checkers, ...
  • Find vulnerabilities yourself before attackers do
  • Continuous security code reviews, ...
  • Make it harder to exploit software vulnerabilities
  • Software exploitation mitigations, ...
slide-39
SLIDE 39

39

Sufficiently complex software has vulnerabilities.

slide-40
SLIDE 40

40

Finding them is not always trivial... Sufficiently complex software has vulnerabilities.

slide-41
SLIDE 41

41

What if an attacker cannot find any

  • r they are too difficult to exploit?

Finding them is not always trivial... Sufficiently complex software has vulnerabilities.

slide-42
SLIDE 42

42

Hardware attacks!?

slide-43
SLIDE 43

43

Hardware attacks!?

  • Attacker needs physcial access the ECU
slide-44
SLIDE 44

44

Hardware attacks!?

  • Attacker needs physcial access the ECU
  • Attacker often needs to open the ECU
slide-45
SLIDE 45

45

Hardware attacks!?

  • Attacker needs physcial access the ECU
  • Attacker often needs to open the ECU
  • Different types of HW attacks:
  • E.g. PCB-level, Fault injection, Side Channels, etc.
slide-46
SLIDE 46

46

Hardware attacks!?

  • Attacker needs physcial access the ECU
  • Attacker often needs to open the ECU
  • Different types of HW attacks:
  • E.g. PCB-level, Fault injection, Side Channels, etc.
  • Often a stepping stone for more scalable attacks
slide-47
SLIDE 47

47

Case study: FI on AUTOSAR

“Using FI to take control of an AUTOSAR-based ECU.”

slide-48
SLIDE 48

48

Case study: FI on AUTOSAR

  • Demonstration ECU implemented using:
  • STM32F4 development board
  • Arctic Core for AUTOSAR v3.1

“Using FI to take control of an AUTOSAR-based ECU.”

slide-49
SLIDE 49

49

Case study: FI on AUTOSAR

  • Demonstration ECU implemented using:
  • STM32F4 development board
  • Arctic Core for AUTOSAR v3.1
  • Attacking using a previously described FI fault model

“Using FI to take control of an AUTOSAR-based ECU.”

slide-50
SLIDE 50

50

Case study: FI on AUTOSAR

  • Demonstration ECU implemented using:
  • STM32F4 development board
  • Arctic Core for AUTOSAR v3.1
  • Attacking using a previously described FI fault model

“Using FI to take control of an AUTOSAR-based ECU.” Fault Injection? Fault model?

slide-51
SLIDE 51

51

Voltage Fault Injection

“Introducing faults into a chip in order to change its intented behavior.”

slide-52
SLIDE 52

52

Voltage Fault Injection

“Introducing faults into a chip in order to change its intented behavior.”

slide-53
SLIDE 53

53

Voltage Fault Injection

“Introducing faults into a chip in order to change its intented behavior.”

slide-54
SLIDE 54

54

Voltage Fault Injection

“Introducing faults into a chip in order to change its intended behavior.”

slide-55
SLIDE 55

55

Voltage Fault Injection

“Introducing faults into a chip in order to change its intented behavior.”

slide-56
SLIDE 56

56

Fa Faul ult Inj njection ction Setup up

slide-57
SLIDE 57

57

Fa Faul ult Inj njection ction Setup up

slide-58
SLIDE 58

58

Fa Faul ult Inj njection ction Setup up

slide-59
SLIDE 59

59

USB

Fa Faul ult Inj njection ction Setup up

slide-60
SLIDE 60

60

USB

Fa Faul ult Inj njection ction Setup up

CAN

slide-61
SLIDE 61

61

Voltage USB

Fa Faul ult Inj njection ction Setup up

CAN

slide-62
SLIDE 62

62

Voltage USB Reset

Fa Faul ult Inj njection ction Setup up

CAN

slide-63
SLIDE 63

63

What can we do with fault injection?

slide-64
SLIDE 64

64

Fault Injection Fault Model

“Instruction corruption.”

slide-65
SLIDE 65

65

Fault Injection Fault Model

  • Glitches can be used to modify instruction

“Instruction corruption.”

slide-66
SLIDE 66

66

Fault Injection Fault Model

  • Glitches can be used to modify instruction
  • In other words, we can modify software

“Instruction corruption.”

slide-67
SLIDE 67

67

Fault Injection Fault Model

  • Glitches can be used to modify instruction
  • In other words, we can modify software
  • Fault injection breaks any software security model

“Instruction corruption.”

slide-68
SLIDE 68

68

How can we use this to attack AUTOSAR-based ECUs?

slide-69
SLIDE 69

69

Attacking AUTOSAR

slide-70
SLIDE 70

70

Attacking AUTOSAR

  • Our goal is to execute arbitrary code
slide-71
SLIDE 71

71

Attacking AUTOSAR

  • Our goal is to execute arbitrary code
  • Our only entry into the device is the CAN bus
slide-72
SLIDE 72

72

Attacking AUTOSAR

  • Our goal is to execute arbitrary code
  • Our only entry into the device is the CAN bus
  • Of course, we have physical access…
slide-73
SLIDE 73

73

AUTOSAR’s PDU Router

slide-74
SLIDE 74

74

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame

slide-75
SLIDE 75

75

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame 2. Frame passes the CAN interface

slide-76
SLIDE 76

76

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame 2. Frame passes the CAN interface 3. Payload is reassembled by ISO-TP

slide-77
SLIDE 77

77

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame 2. Frame passes the CAN interface 3. Payload is reassembled by ISO-TP 4. Payload is copied to COM or DCM

slide-78
SLIDE 78

78

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame 2. Frame passes the CAN interface 3. Payload is reassembled by ISO-TP 4. Payload is copied to COM or DCM 5. COM or DCM handles the payload

slide-79
SLIDE 79

79

Where do we attack?!

slide-80
SLIDE 80

80

AUTOSAR’s PDU Router

1. CAN driver receives 8-byte CAN frame 2. Frame passes the CAN interface 3. Payload is reassembled by ISO-TP 4. Payload is copied to COM or DCM 5. COM or DCM handles the payload

slide-81
SLIDE 81

81

Attacking AUTOSAR’s PDU router

slide-82
SLIDE 82

82

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)
slide-83
SLIDE 83

83

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)

Copy ‘Our task’ to ‘free memory’ Our task

slide-84
SLIDE 84

84

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task

slide-85
SLIDE 85

85

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Continue with current task

slide-86
SLIDE 86

86

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Pointers pointing to the start of the payload Continue with current task

slide-87
SLIDE 87

87

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)
  • Step 2: We inject the glitch when the pointers are being copied

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Pointers pointing to the start of the payload Continue with current task

slide-88
SLIDE 88

88

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)
  • Step 2: We inject the glitch when the pointers are being copied
  • Step 3: Successful glitches load a pointer into the PC register

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Pointers pointing to the start of the payload Continue with current task

slide-89
SLIDE 89

89

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)
  • Step 2: We inject the glitch when the pointers are being copied
  • Step 3: Successful glitches load a pointer into the PC register
  • Step 4: MCU will execute the ISO-TP message (blue blocks)

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Pointers pointing to the start of the payload Continue with current task

slide-90
SLIDE 90

90

Attacking AUTOSAR’s PDU router

  • Step 1: Send an ISO-TP CAN message (< 4096 bytes)
  • Step 2: We inject the glitch when the pointers are being copied
  • Step 3: Successful glitches load a pointer into the PC register
  • Step 4: MCU will execute the ISO-TP message (blue blocks)
  • Step 5: Wait for IDLE task to be scheduled and execute our task

Modify pointer of IDLE task to ‘free memory’ Copy ‘Our task’ to ‘free memory’ Our task Pointers pointing to the start of the payload Continue with current task

slide-91
SLIDE 91

91

Why does this work?

slide-92
SLIDE 92

92

Attacking AUTOSAR’s PDU Router

slide-93
SLIDE 93

93

Attacking AUTOSAR’s PDU Router

Disassembled memcpy()

slide-94
SLIDE 94

94

Attacking AUTOSAR’s PDU Router

Disassembled memcpy()

slide-95
SLIDE 95

95

Attacking AUTOSAR’s PDU Router

Disassembled memcpy() We take control of the Program Counter (PC) during the copy!

slide-96
SLIDE 96

96

We have our own task. Now what?!

slide-97
SLIDE 97

97

Post Exploitation

slide-98
SLIDE 98

98

Post Exploitation

  • Extract information (secrets)
slide-99
SLIDE 99

99

Post Exploitation

  • Extract information (secrets)
  • Analyze firmware dynamically
slide-100
SLIDE 100

100

Post Exploitation

  • Extract information (secrets)
  • Analyze firmware dynamically
  • Perform additional attacks (e.g. side channel attack)
slide-101
SLIDE 101

101

Post Exploitation

  • Extract information (secrets)
  • Analyze firmware dynamically
  • Perform additional attacks (e.g. side channel attack)
  • Add (malicious) and/or change functionality
slide-102
SLIDE 102

102

Is all hope lost?

slide-103
SLIDE 103

103

Hardening AUTOSAR-based ECUs

slide-104
SLIDE 104

104

Hardening AUTOSAR-based ECUs

  • Adhere to (automotive) security guidelines/standards
slide-105
SLIDE 105

105

Hardening AUTOSAR-based ECUs

  • Adhere to (automotive) security guidelines/standards
  • Make use of strong (hardware-based) security
slide-106
SLIDE 106

106

Hardening AUTOSAR-based ECUs

  • Adhere to (automotive) security guidelines/standards
  • Make use of strong (hardware-based) security
  • Minimize attack surface and increase attack complexity
slide-107
SLIDE 107

107

Hardening AUTOSAR-based ECUs

  • Adhere to (automotive) security guidelines/standards
  • Make use of strong (hardware-based) security
  • Minimize attack surface and increase attack complexity
  • Consult internal/external embedded security experts
slide-108
SLIDE 108

108

To wrap up…

slide-109
SLIDE 109

109

Takeaways

slide-110
SLIDE 110

110

Takeaways

  • Devices (incl. AUTOSAR-based ECUs) will be hacked
slide-111
SLIDE 111

111

Takeaways

  • Devices (incl. AUTOSAR-based ECUs) will be hacked
  • Not AUTOSAR’s fault!
slide-112
SLIDE 112

112

Takeaways

  • Devices (incl. AUTOSAR-based ECUs) will be hacked
  • Not AUTOSAR’s fault!
  • No (known) software vulnerabilities ≠ secure
slide-113
SLIDE 113

113

Takeaways

  • Devices (incl. AUTOSAR-based ECUs) will be hacked
  • Not AUTOSAR’s fault!
  • No (known) software vulnerabilities ≠ secure
  • Hardware attacks are efficient and do scale
slide-114
SLIDE 114

114

Thank you. Questions?

Niek Timmers niek@riscure.com / @tieknimmers

slide-115
SLIDE 115

115

Challenge your security

Riscur cure B.V. Frontier Building, Delftechpark 49 2628 XJ Delft The Netherlands Phone: +31 15 251 40 90 inforequest@riscure.com Riscur scure North th America ica 550 Kearny St., Suite 330 San Francisco, CA 94108 USA Phone: +1 650 646 99 79 inforequest@riscure.com Riscur cure Chin ina Room 2030-31, No. 989, Changle Road, Shanghai 200031 China Phone: +86 21 5117 5435 inforcn@riscure.com