Embed Size (px)
Citation preview
Automotive Exploitation Sandbox:A Hands-on Educational Introduction to Embedded Device Exploitation
Nathaniel [email protected]
Red Balloon Security
Red Balloon Security
Jatin [email protected]
Red Balloon Security
Philippe [email protected]
Red Balloon Security
AbstractAutomative managers, domain experts, and inter-
ested nontechnical personnel who have traditionallynot needed to be aware of security issues, now facethe at times daunting task of familiarizing themselveswith the whole field of security knowledge. The goalof the Automotive Exploitation Sandbox is to edu-cate stakeholders who may not have any security back-ground and provide hands-on exposure to automotiveattack chains with real hardware. In this paper andthe accompanying presentation, we describe the goalsand creation of the Automotive Exploitation Sandboxalong with a live demonstration. The Automotive Ex-ploitation Sandbox will be hosted and open for freepublic usage at the conclusion of the presentation athttps://sandbox.redballoonsecurity.com.
1 Goals
The goals of the Automotive Exploitation Sandbox aretwofold:
• To educate all stakeholders about what typical auto-motive attack chains look like.
• To provide hands-on experience with real hardware.
Providing a hands-on experience requires realistic ex-ploits. At the very least, the exploits used should be realcode exploiting a synthetic vulnerability implanted intothe device used for the sandbox. To provide further real-ism, known existing vulnerabilities could be used. Whilegoing into the full technical instructions sufficient to haveusers write their own exploit implementations is out ofscope, part of the educational experience provided by theAutomotive Exploitation Sandbox will be overviews ofhow such vulnerabilities are found and exploits are made.
In order to be accessible to all stakeholders includingmanagement and automotive engineers, the AutomotiveExploitation Sandbox must be:
• Free and publicly accessible.
• Clearly described with instructions targeted towardspeople without any particular technical or securitybackground.
• Remotely accessible as even the most inexpensivehardware platforms are cost prohibitive for widedistribution.
2 Design
The design of the Automotive Exploitation Sandbox cen-ters around the requirements for remote accessibility aswell as to use physical hardware to achieve realism. Thefirst step of the design process was choosing a target de-vice. We choose the SABRE lite board. The SABRE liteis a relatively low cost development board with a quadcore ARM processor. Importantly, it supports QNX, amicro kernel operating system common in automotivedevices.
Using QNX as the operating system for the Automo-tive Exploitation Sandbox provides additional realismover using a common consumer focused Linux operat-ing system. With an operating system selected, the nextsoftware required is a network server. Lighttpd providesa simple light weight web server. In practice, many em-bedded devices host a loosely secured web server. Inthe future, other network facing services can be used todemonstrate a larger variety of services. A commandinjection vulnerability is intentionally injected into theLighttpd server to provide access to a user privilege levelremote shell.
With the device and software chosen, the remainingAutomotive Exploitation Sandbox design focuses on theinfrastructure required to cleanly reset the devices, se-curely host the sandbox, and host the exploitation in-structions. Figure 1 provides an overview of the phys-ical design. Reseting one of the SABRE Lite boards to
1
Walkthrough Web Sever
SABRE Lite
Board 1
SABRE Lite
Board 1
SABRE
Remote C
ontrolled Power
Power Reset Manager
TFTPBoot Sever
Firewall
SABRE LiteBoard 1
SABRE LiteBoard 2
SABRE LiteBoard 3
Internet
Power
Network
Figure 1: Physical layout of the sandbox. Remote powercontrols and remote boot via TFTP allow for a clean resetof the boards.
a clean state requires a reliable method for restarting thedevice and loading a pristine boot image. Furthermore,such reseting must be automated. The reliable restartis achieved by connecting all the boards to remote con-trolled power that can be programmatically managed. Toensure that the firmware booted is pristine and unmod-ified, each board’s boot loader is programmed to bootfrom a network TFTP server rather than local storage,which could be modified once users obtain root accessas part of the Automotive Exploitation Sandbox experi-ence.
Now that reseting each board is automated, the ques-tion remains as to how often to reset a board. Ideally,each user of the Automotive Exploitation Sandbox wouldbe able to reserve a particular board and have it reset oncethe user finishes the sandbox exercise. Unfortunately,this could lead to unintentional or even intentional de-nial of service if users do not relinquish their reserveddevices. For the initial design, a simple timer is imple-mented, with a count down displayed for each board al-lowing users to start with a board that has sufficient timeremaining to complete the sandbox exercise before itsnext scheduled reset. This approach does have the down-side of requiring users to complete the entire exercise inone session or being forced to start fresh. The base countdown time is set based on timing how long it took somebeta testing nontechnical users to complete the exercise.
As a sandbox with public users, the devices and net-work must be isolated for security purposes. As shown inFigure 1, the design includes a firewall, which is config-
ured limit traffic to the expected ports used in the direc-tions. The servers hosting the instructions, TFTP server,and remote power controls are all further isolated fromthe actual SABRE Lite boards. This reduces the prob-ability of a malicious user jumping from one of the in-tentionally vulnerable sandbox devices to a server con-trolling parts of the Automotive Exploitation Sandbox.As a final layer of defense to protect from the scenariowhere the sandbox infrastructure is compromised, theentire firewall and network are isolated and unconnectedfrom any organization network.
While fully automated with the automatic reset of thesandbox devices, if something does go wrong manual in-tervention would be required. In order to alert the systemadministration whenever such intervention is required,an automatic monitoring system is in place. This systemmonitors for both device downtime and potential abusealerting the system administrator in either case.
3 Exploitation Walkthrough
The accompanying presentation includes a live demon-stration of the Automotive Exploitation Sandbox. In thissection, we will go through a brief overview of the ex-ploitation process. The full instructions with step by stepdetails, command text, and even video tutorials will beavailable to users via the walkthrough web server seenin Figure 1. The core walkthrough is visualized acrossFigures 2, 4, and 6.
3.1 Exercised Vulnerabilities Summary
While the following subsections will go into a more de-tailed overview of the walkthrough that users of the Au-tomotive Exploitation Sandbox experience, this sectionprovides a summary of the types of vulnerabilities cov-ered in the walkthrough.
Command Injection A user inserts escape charactersalong with their own command into a data field that islater used to execute a server-side command thus alsoexecuting the user’s command. A simple ping commandfield taking a user specified IP address is used for thisexample in the Automotive Exploitation Sandbox.
Heap Overflow A user overflows a data structure lo-cated in the heap, which is a scratch space programs useto store temporary information in memory, to overwritedata that the program is relying on to determine its con-trol flow. In order to demonstrate a wide variety of vul-nerabilities, an Echo service that is flawed with an ex-ploitable heap overflow is added to the device. This is an
2
File System Applications IO
Shell
Vulnerablesystem call
file upload ‘nc’TCP/IPWeb
Server
QNX Micro Kernel
/tmp/nc
su
Secret Data
I2C
UART
CAN
Web Server
Attacker
OR
command injection
heapoverflow
Figure 2: Overview of stage 1 of the Automotive Ex-ploitation Sandbox. The user obtains an unprivileged re-mote shell.
alternate route to the first stage attack when a trivial com-mand injection is not available. The crux of the problemis to overwrite a function pointer with the system func-tion and then invoke it on our buffer. We designed theEcho service so as to make this attack easy. For the Au-tomotive Exploitation Sandbox, users will be suppliedwith a script that will take a command as an input andgenerate a suitable curl request.
Kernel Memory Modification An arbitrary kernelmemory modification is a vulnerability class that allowsfor the user to modify arbitrary kernel memory, whichcan be leveraged to gain root privilege and take over theentire device. For this exercise, the vulnerability is in-jected as a system call that the user can leverage to gainthe kernel write primitive. System calls that fail to prop-erly verify user input are the typical attack vector for thistype of attack chain.
3.2 Stage 1: Obtain Remote Shell
The first stage of the Automotive Exploitation Sandboxwalkthrough instructs the user on how to obtain a userprivilege remote shell on the device. Figure 2 visual-izes this process. First, the user uploads the netcat binarynamed ‘nc’ to through the normal file upload feature ofthe web server. Then, using the synthetic vulnerabilityintroduced into the web server cgi script, the user willinject a command to start the shell listening for remoteconnections via netcat. At the end of this stage, the userconnects to the remote shell via ‘nc’ and can verify thatthey are running as the user ‘nobody.’ For an example ofwhat the remote shell looks like, see Figure 3.
Figure 3: Example of the user connecting to the remoteshell and executing commands remotely on the device.
File System Applications IO
QNX Micro Kernel
Use vulnerable
system call to modify ‘su’
Web Server
Vulnerablesystem call
Shell
Secret Data
/tmp/nc
su
I2C
UART
CAN
TCP/IP
Attacker
Figure 4: Stage 2 of the Automotive Exploitation Sand-box. The user exploits a synthetic vulnerable system callto modify the ‘su’ binary to bypass its password check.
3.3 Stage 2: Privilege Escalation
The second stage leads the user through the process of es-calating from a user account to a root privileged account.While the vulnerability exploited is a synthetic vulner-able system call injected into the QNX kernel, similarvulnerabilities have been reported in the past. An exploitpayload program is provided to the user that can exercisethis vulnerable system call to modify arbitrary memory.The details of designing and writing such a payload isleft as an exercise to the user.
To escalate their user privilege, the instructions takethe user through the process of modifying the ‘su’ binaryto work without a password. The details of how an at-tacker would reverse engineer the ‘su’ binary to figureout where to patch the code is documented in depth in anoptional to read document. Figure 5 is an example figurefrom that document showing an IDA Pro disassembly ofthe ‘su’ binary password checking function. The last stepin stage 2 is for the user to use the provided payload tomodify the ‘su’ binary via their user remote shell. Theuser then ends up with a root shell on the device.
3.4 Stage 3: Post Exploitation
The last stage of the Automotive Exploitation Sandboxwalks the user through post-compromise attacker actions
3
Figure 5: IDA Pro disassembly of the ‘su’ binary pass-word verifying function.
File System Applications IO
QNX Micro Kernel
Web Server
Vulnerablesystem call
HACKED
Secret Data
su
I2C
UART
CAN
Shell
TCP/IP
Attacker
/tmp/nc
Deface Web Server
Capture confidential
data
Figure 6: Stage 3 of the Automotive Exploitation Sand-box. The user is walked through defacing the web serverand obtaining the secret data.
including obtaining secret data and modifying the web
server content. Notably missing is installing a persistentrootkit. This typical attacker behavior is left out of theexercise as by design the devices are restored to a pris-tine state each reboot so that the next user can go throughthe exercise. A future version of the exercise with a sep-arate on demand reseting of devices could provide sucha scenario. Figure 6 illustrates these two attacker goals.
The user is walked through the process of using thesame memory modifying payload to change memory inthe web server changing the content served. This lets theuser have a visual impact posting whatever text they de-sire on the device web page. After this portion of the ex-ercise, a number of users experience an eureka momentseeing the effect of their actions and thus understandinghow a malicious actor can do the same. Additionally, asecret data file is left on the device with root only readpermissions so that now with root access the user canread the secret data.
4 Future Work
The Automotive Exploitation Sandbox could be builtupon as a testbed to measure and verify various defensivetechnologies. In its current single device design, it couldprovide a testing platform to demonstrate host-baseddefenses. Expanding the sandbox into a multi-devicetestbed could allow for firewall and network defensesto be tested. To fully test various defenses, additionalclasses of attacks and payloads will be required. Feed-back on the Automotive Exploitation Sandbox is wel-come at [email protected] in or-der to further refine it and make it as useful to the com-munity as possible.
5 Conclusion
Overall, while a fairly simple scenario, the AutomotiveExploitation Sandbox is capable of walking nontechnicalusers through the typical steps of remote exploit, priv-ilege escalation, and malicious actions to educate userson what such processes might look like on real hard-ware. The hands-on experience provided by the Auto-motive Exploitation Sandbox can be an eye opening ex-perience for users without previous security experience.Even advanced users can also enjoy the sandbox experi-ence as its real hardware and software allow explorationand deviations from the standard walkthrough.
6 Access
Visit https://sandbox.redballoonsecurity.com for access.Public access will be available after the presentation.
4
