How do I get started with bug bounty hunting? How do I improve my skills?
These are some simple steps that every bug bounty hunter can use to get started and improve their skills:
Learn to make it; then break it! A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.
Read books. Lots of books. One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".
Join discussions and ask questions. As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.
Participate in open source projects; learn to code. Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.
Help others. If you can teach it, you have mastered it. Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.
Smile when you get feedback and use it to your advantage. The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.
Learn to approach a target. The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.
A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe." As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.
Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.
This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.
Weaknesses of XML Encryption
Implementations of XML Encryption can be vulnerable to adaptive chosen ciphertext attacks. This is a class of attacks in which the attacker sends a sequence of manipulated ciphertexts to a decryption oracle as a way to gain information about the plaintext content.
Falsely implemented XML Encryption can be broken using:
an attack against the CBC-mode decryption (quite similar to a padding oracle attack) [3] or
a Bleichenbacher attack against the RSA-PKCS#1 encryption of the session key [4].
SAML makes use of XML Encryption and its implementations could, therefore, also be vulnerable to these attacks.
XML Encryption in SAML
To support confidential transmission of sensitive data within the SAML Assertion, assertions can be encrypted using XML Encryption. An EncryptedAssertion is shown in the abridged example below.
The EncryptedAssertion contains an EncryptedData element, which in turn is the parent of the EncryptionMethod, KeyInfo, and CipherData elements. SAML makes use of what is referred to as a hybrid encryption scheme. This is done using a session key which symmetrically encrypts the payload data (the example uses AES-128 in CBC mode), resulting in the ciphertext contained in the EncryptedAssertion/EncryptedData/CipherData/CipherValue child element. The session key itself is encrypted using an asymmetric encryption scheme. In our example, RSA-PKCS#1.5 encryption is used with the public key of the recipient, allowing the contents of the the EncryptedKey child element to be derived from the KeyInfo element.
Encryption Attacker
Our BurpSuite extension EsPReSSO can help detect vulnerable implementations with the newly integrated Encryption Attacker within EsPReSSO's SAML module.
Once a SAML response which contains an EncryptedAssertion has been intercepted, open the SAML tab, select the Attacks pane, and choose Encryption from the dropdown menu. This works in Burp's Proxy, as well as in the Repeater tool, and is depicted below.
As sketched out above, the symmetric session key is encrypted using the recipient's public key. Since the key is public, anybody can use it to encrypt a selected symmetric key and submit a valid encryption of arbitrary messages to the recipient. This is incredibly helpful because it allows us to produce ciphertexts that decrypt the chosen plaintexts. To accomplish this, one can purposefully send invalidly padded messages, or messages containing invalid XML, as a method to trigger and analyze the different reactions of the decryption endpoint (i.e, turning the endpoint into a decryption oracle). To facilitate these investigations, the new Encryption Attacker makes this process dead simple.
The screenshot above shows the essential interface of the new encryption tab: At the top, the certificate used to encrypt the symmetric session key can be pasted into the text field. This field will be pre-filled automatically if the intercepted SAML message includes a certificate in the KeyInfo child element of the EncryptedData element. The Update Certificate checkboxes above the text area can be used to include the certificate in the manipulated SAML message. In the Symmetric Key text field, the hexadecimal value of the symmetric session key can be set. Choose the asymmetric algorithm from the dropdown menu and click Encrypt key -- this will update the corresponding KeyInfo elements of the intercepted SAML message.
The payload in the text area labeled XML data can now be entered. Any update in the XML data field will also be reflected in the hexadecimal representation of the payload (found on right of the XML data field). Note that this is automatically padded to the blocklength required by the symmetric algorithm selected below. However, the payload and the padding can be manually adjusted in the hex editor field.
Eventually, click the Encrypt content button to generate the encrypted payload. This will apply the changes to the intercepted SAML message, and the manipulated message using Burp's Forward or Go button can now be forwarded, as usual.
Probing for Bleichenbacher Oracles
Bleichenbacher's attack against RSA-PKCS1 v1.5 encryption abuses the malleability of RSA to draw conclusions about the plaintext by multiplying the ciphertext with adaptively chosen values, and observing differences in the received responses. If the (error-) responses differ for valid and invalid PKCS1 v1.5 ciphertexts, Bleichenbachers' algorithm can be used to decrypt the ciphertext without knowing the private key [6].
To determine whether or not a SAML endpoint is vulnerable to Bleichenbacher's Attack, we simply need to check if we can distinguish those responses received when submitting ciphertexts that are decrypted into invalidly formatted PKCS1 v1.5 plaintexts, from the responses we receive when sending ciphertexts that are decrypted into validly formatted plaintexts.
Recall that PKCS1 v1.5 mandates a certain format of the encrypted plaintext, namely a concatenation of a BlockType 00 02, a randomized PaddingString (PS) that includes no 00 bytes, a 00 (NULL-byte) as delimiter, and the actual plaintext message. The whole sequence should be equal in size to the modulus of the RSA key used. That is, given the byte length k of the RSA modulus and the message length |m|, PS has the length |PS| = k - 3 - |m|. Furthermore, PKCS1 v1.5 demands that |PS| to be at least eight bytes long [5].
In SAML, the recipient's public key is usually known because it is published in the metadata, or even included in the EncryptedAssertion. For this reason, we do not need to fiddle around with manipulated ciphertexts. Instead, we simply submit a validly formatted RSA-PKCS1 v1.5 encrypted message and an encrypted message which deciphers into an invalidly formatted plaintext. As an example, assume an RSA public key of 2048 bits which we want to use to encrypt a 16 byte session key `01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10` (hexadecimal representation). |PS|$ is $2048/8 - 3 - 16 = 237, so a valid PKCS1 v1.5 plaintext, ready to be encrypted using `AA` for all 237 padding bytes, could look like the listing shown below.
00 02 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
In the Encryption attack pane of EsPReSSO, ensure that the correct public key certificate has been added to the Certificate field. Insert a valid plaintext, such as the one above, into the Symmetric Key field and select Plain RSA encryption from the Algorithm drop down menu. Click the Encrypt button to compute the RSA transformation and apply the new EncryptedKey element to the intercepted SAML message. Now, submit the message by clicking Burp's Go or Forward button and carefully inspect the response.
Next, repeat the steps outlined above, but this time submit an invalid PKCS1 v1.5 message. For example, consider using an invalid BlockType of `12 34` instead of `00 02`, or replace the `00` delimiter so that the decryptor is unable to determine the actual message after decrypting the ciphertext. If you are able to determine from the recieved responses whether or not the submitted ciphertext decrypted into a valid PKCS1 v1.5 formatted plaintext, chances are high that the decryptor can be used as a Bleichenbacher oracle. Don't forget to take into account the actual XML data, i.e., the assertion encrypted with the new session key; by submitting valid or invalid XML, or by removing signatures from the SAML message or the assertion you may increase your chances of detecting differences in the returned responses.
Probing for Oracles in CBC-Mode Decryption
Another known attack on XML Encryption is aimed at the Cipher Block Chaining (CBC) mode, which can be used with the block ciphers AES or 3DES [2]. The attack is described in detail in this referenced paper [3] and is quite similar to Padding-Oracle attacks on CBC mode; the malleability of CBC mode encryption enables the attacker to perform a bytewise, adaptive manipulation of the ciphertext blocks which are subsequently sent to the decryptor. In most cases, the manipulated ciphertext will not decrypt to valid XML and an error will be returned. Sometimes, however, the plaintext will be parsed as valid XML, in which cases an error is thrown later on at the application layer. The attacker observes the differences in the responses in order to turn the decryptor into a ciphertext validity oracle which can be used to break the encryption. Due to some particularities of the XML format, this attack can be very efficient, enabling decryption with about 14 requests per byte, and it is even possible to fully automate the process [7].
In order to determine if a particular SAML service provider is vulnerable to this attack, we can avoid the cumbersome ciphertext manipulation, if we are in possession of the decryptor's public key: In the Encryption Attacker tab of EsPReSSO, add the public key certificate to the Certificate field (if necessary) and insert a symmetric key of your own devising into the Symmetric Key text field. Select an appropriate RSA encryption method and click the Encrypt button to apply the new EncryptedKey element to the original SAML message.
An XML message can now be inserted into the XML data text field. Select a CBC mode encryption algorithm and click Encrypt to apply the changes. As in the example above, press Burp's Go or Forward button to send the message and carefully inspect the response. Try sending invalid XML, e.g., by not closing a tag or using the `&` character without a valid entity and keep an eye open for differences in the returned responses. To manipulate the padding, the text field on the right side shows the hexadecimal representation of the plaintext, including the CBC padding. If you send a single block and set the last byte, which indicates the padding length to the blocksize, i.e. 16 or 0x10 for AES, the ciphertext should decrypt into an empty string and is generally considered "valid" XML.
Please refer to the original paper for more details, tips, and tricks for performing the actual attack [3].
Summary
The new XML Encryption attacker included in EsPReSSO can help security auditors to quickly assess if a SAML endpoint is vulnerable to known attacks against XML Encryption. To this end, the decryptor's public key is used in order to send suitable test vectors that can be provided in plaintext. Ciphertext manipulation is, therefore, not required. The actual process of decrypting an intercepted SAML message is, however, considered out of scope and not implemented in EsPReSSO.
In case you wonder how XML Encryption can be used in a secure fashion, here are some considerations [6]:
Always use an authenticated encryption mode such as AES-GCM instead of the CBC-mode encryption.
Using RSA-PKCS1 v1.5 within XML Encryption is particularly difficult to do in a secure manner, and it is recommended to use RSA with Optimal Asymmetric Encryption Padding (OAEP) instead [2].
Apply a digital signature over the whole SAML response, and ensure it is properly validated before attempting to decrypt the assertion. This should thwart the attack as a manipulated response can be recognized as such and should be rejected.
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
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.
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.
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 thiswill 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 somepadding 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)
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:
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)
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:
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?
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?
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:
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:
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.
"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. Basicallythe 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.
