View
10
Download
0
Category
Preview:
Citation preview
1
Attacking AUTOSAR using
Software and Hardware Attacks
Pascal Nasahl
Graz University of Technology
Niek Timmers
Riscure
2
Introduction
3
Introduction
• Niek Timmers
• Principal Security Analyst @ Riscure
4
Introduction
• Niek Timmers
• Principal Security Analyst @ Riscure
• Analyzing and testing of embedded technologies
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
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!
7
Today’s Agenda
8
Today’s Agenda
•Brief introduction to AUTOSAR Classic
9
Today’s Agenda
•Brief introduction to AUTOSAR Classic
•Attacks on AUTOSAR
10
Today’s Agenda
•Brief introduction to AUTOSAR Classic
•Attacks on AUTOSAR
•Case study
11
Today’s Agenda
•Brief introduction to AUTOSAR Classic
•Attacks on AUTOSAR
•Case study
•Wrap-up
12
Today’s Agenda
•Brief introduction to AUTOSAR Classic
•Attacks on AUTOSAR
•Case study
•Wrap-up
•Q&A
13
AUTOSAR Classic
14
AUTOSAR Classic
• Layered software
architecture
15
AUTOSAR Classic
• Layered software
architecture
• Most layers are independent
from the Microcontroller
16
AUTOSAR Classic
• Layered software
architecture
• Most layers are independent
from the Microcontroller
• Improve software reusability
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
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!
19
Summary of AUTOSAR
20
Summary of AUTOSAR
•Complex software; will contain bugs/vulnerabilities
21
Summary of AUTOSAR
•Complex software; will contain bugs/vulnerabilities
•Made by different vendors / developers• Do you trust your suppliers?
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
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...
24
What can go wrong?
25
Potential MCAL vulnerabilities
26
Potential MCAL vulnerabilities
27
Potential MCAL vulnerabilities
Who verifies your MCAL for vulnerabilities?
28
What about MISRA-C?!
29
What about MISRA-C?!
30
What about MISRA-C?!
You cannot conform to directives automagically…
31
What else?
32
Vulnerabilities in complex software
33
Vulnerabilities in complex software
34
Vulnerabilities in complex software
Who verifies your communication stack?
35
Mitigating software vulnerabilities
36
Mitigating software vulnerabilities
•Minimize the low hanging fruit• Secure coding standard, code checkers, ...
37
Mitigating software vulnerabilities
•Minimize the low hanging fruit• Secure coding standard, code checkers, ...
•Find vulnerabilities yourself before attackers do• Continuous security code reviews, ...
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, ...
39
Sufficiently complex software
has vulnerabilities.
40
Finding them is not always trivial...
Sufficiently complex software
has vulnerabilities.
41
What if an attacker cannot find any
or they are too difficult to exploit?
Finding them is not always trivial...
Sufficiently complex software
has vulnerabilities.
42
Hardware attacks!?
43
Hardware attacks!?
•Attacker needs physcial access the ECU
44
Hardware attacks!?
•Attacker needs physcial access the ECU
•Attacker often needs to open the ECU
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.
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
47
Case study: FI on AUTOSAR
“Using FI to take control of an AUTOSAR-based ECU.”
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.”
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.”
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?
51
Voltage Fault Injection“Introducing faults into a chip in order to change its intented behavior.”
52
Voltage Fault Injection“Introducing faults into a chip in order to change its intented behavior.”
53
Voltage Fault Injection“Introducing faults into a chip in order to change its intented behavior.”
54
Voltage Fault Injection“Introducing faults into a chip in order to change its intended behavior.”
55
Voltage Fault Injection“Introducing faults into a chip in order to change its intented behavior.”
56
Fault Injection Setup
57
Fault Injection Setup
58
Fault Injection Setup
59
USB
Fault Injection Setup
60
USB
Fault Injection Setup
CAN
61
Voltage
USB
Fault Injection Setup
CAN
62
Voltage
USB
Reset
Fault Injection Setup
CAN
63
What can we do with fault injection?
64
Fault Injection Fault Model
“Instruction corruption.”
65
Fault Injection Fault Model
• Glitches can be used to modify instruction
“Instruction corruption.”
66
Fault Injection Fault Model
• Glitches can be used to modify instruction
• In other words, we can modify software
“Instruction corruption.”
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.”
68
How can we use this to attack
AUTOSAR-based ECUs?
69
Attacking AUTOSAR
70
Attacking AUTOSAR
•Our goal is to execute arbitrary code
71
Attacking AUTOSAR
•Our goal is to execute arbitrary code
•Our only entry into the device is the CAN bus
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…
73
AUTOSAR’s PDU Router
74
AUTOSAR’s PDU Router
1. CAN driver receives 8-byte CAN frame
75
AUTOSAR’s PDU Router
1. CAN driver receives 8-byte CAN frame
2. Frame passes the CAN interface
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
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
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
79
Where do we attack?!
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
81
Attacking AUTOSAR’s PDU router
82
Attacking AUTOSAR’s PDU router
• Step 1: Send an ISO-TP CAN message (< 4096 bytes)
83
Attacking AUTOSAR’s PDU router
• Step 1: Send an ISO-TP CAN message (< 4096 bytes)
Copy ‘Our task’
to ‘free memory’
Our
task
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
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
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
taskPointers pointing to the start of the payload
Continue with
current task
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
taskPointers pointing to the start of the payload
Continue with
current task
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
taskPointers pointing to the start of the payload
Continue with
current task
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
taskPointers pointing to the start of the payload
Continue with
current task
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
taskPointers pointing to the start of the payload
Continue with
current task
91
Why does this work?
92
Attacking AUTOSAR’s PDU Router
93
Attacking AUTOSAR’s PDU Router
Disassembled
memcpy()
94
Attacking AUTOSAR’s PDU Router
Disassembled
memcpy()
95
Attacking AUTOSAR’s PDU Router
Disassembled
memcpy()
We take control of the Program Counter (PC) during the copy!
96
We have our own task. Now what?!
97
Post Exploitation
98
Post Exploitation
•Extract information (secrets)
99
Post Exploitation
•Extract information (secrets)
•Analyze firmware dynamically
100
Post Exploitation
•Extract information (secrets)
•Analyze firmware dynamically
•Perform additional attacks (e.g. side channel attack)
101
Post Exploitation
•Extract information (secrets)
•Analyze firmware dynamically
•Perform additional attacks (e.g. side channel attack)
•Add (malicious) and/or change functionality
102
Is all hope lost?
103
Hardening AUTOSAR-based ECUs
104
Hardening AUTOSAR-based ECUs
•Adhere to (automotive) security guidelines/standards
105
Hardening AUTOSAR-based ECUs
•Adhere to (automotive) security guidelines/standards
•Make use of strong (hardware-based) security
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
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
108
To wrap up…
109
Takeaways
110
Takeaways
•Devices (incl. AUTOSAR-based ECUs) will be hacked
111
Takeaways
•Devices (incl. AUTOSAR-based ECUs) will be hacked
•Not AUTOSAR’s fault!
112
Takeaways
•Devices (incl. AUTOSAR-based ECUs) will be hacked
•Not AUTOSAR’s fault!
•No (known) software vulnerabilities ≠ secure
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
115
Challenge your security
Riscure B.V.
Frontier Building, Delftechpark 49
2628 XJ Delft
The Netherlands
Phone: +31 15 251 40 90
inforequest@riscure.com
Riscure North America
550 Kearny St., Suite 330
San Francisco, CA 94108 USA
Phone: +1 650 646 99 79
inforequest@riscure.com
Riscure China
Room 2030-31, No. 989, Changle Road, Shanghai 200031
China
Phone: +86 21 5117 5435
inforcn@riscure.com
Recommended