Ever wanted to turn your AV console into an Incident Response & Threat Hunting machine? Rastrea2r (pronounced "rastreador" - hunter- in Spanish) is a multi-platform open source tool that allows incident responders and SOC analysts to triage suspect systems and hunt for Indicators of Compromise (IOCs) across thousands of endpoints in minutes. To parse and collect artifacts of interest from remote systems (including memory dumps), rastrea2r can execute sysinternal, system commands and other 3rd party tools across multiples endpoints, saving the output to a centralized share for automated or manual analysis. By using a client/server RESTful API, rastrea2r can also hunt for IOCs on disk and memory across multiple systems using YARA rules. As a command line tool, rastrea2r can be easily integrated within McAfee ePO, as well as other AV consoles and orchestration tools, allowing incident responders and SOC analysts to collect forensic evidence and hunt for IOCs without the need for an additional agent, with 'gusto' and style!
Dependencies
Python 2.7.x
git
bottle
requests
yara-python
Quickstart
Clone the project to your local directory (or download the zip file of the project)
All the dependencies necessary for the tool to run can be installed within a virtual environment via the provided makefile.
$make help help - display this makefile's help information venv - create a virtual environment for development clean - clean all files using .gitignore rules scrub - clean all files, even untracked files test - run tests test-verbose - run tests [verbosely] check-coverage - perform test coverage checks check-style - perform pep8 check fix-style - perform check with autopep8 fixes docs - generate project documentation check-docs - quick check docs consistency serve-docs - serve project html documentation dist - create a wheel distribution package dist-test - test a wheel distribution package dist-upload - upload a wheel distribution package
Create a virtual environment with all dependencies
$make venv //Upon successful creation of the virtualenvironment, enter the virtualenvironment as instructed, for ex: $source /Users/ssbhat/.venvs/rastrea2r/bin/activate
Start the rastrea2r server by going to $PROJECT_HOME/src/rastrea2r/server folder
$cd src/rastrea2r/server/ $python rastrea2r_server_v0.3.py Bottle v0.12.13 server starting up (using WSGIRefServer())... Listening on http://0.0.0.0:8080/
Now execute the client program, depending on which platform you are trying to scan choose the target python script appropriately. Currently Windows, Linux and Mac platforms are supported.
Rastrea2r RESTful remote Yara/Triage tool for Incident Responders
positional arguments: {yara-disk,yara-mem,triage}
modes of operation yara-disk Yara scan for file/directory objects on disk yara-mem Yara scan for running processes in memory triage Collect triage information from endpoint
optional arguments: -h, --help show this help message and exit -v, --version show program's version number and exit
Further more, the available options under each command can be viewed by executing the help option. i,e
yara-disk: Yara scan for file/directory objects on disk
yara-mem: Yara scan for running processes in memory
memdump: Acquires a memory dump from the endpoint ** Windows only
triage: Collects triage information from the endpoint ** Windows only
Notes For memdump and triage modules, SMB shares must be set up in this specific way:
Binaries (sysinternals, batch files and others) must be located in a shared folder called TOOLS (read only)
\path-to-share-foldertools
Output is sent to a shared folder called DATA (write only)
\path-to-share-folderdata
For yara-mem and yara-disk scans, the yara rules must be in the same directory where the server is executed from.
The RESTful API server stores data received in a file called results.txt in the same directory.
Contributing to rastrea2r project The Developer Documentation provides complete information on how to contribute to rastrea2r project Demo videos on Youtube
As you might have heard, we recently got our paper on padding oracle attacks accepted to the USENIX Security Conference. In this paper, we describe and evaluate a scanning methodology with which we found several padding oracle vulnerabilities in devices from various vendors. In total, we found that 1.83% of the Alexa Top 1 Million have padding oracle vulnerabilities. To test whether a server is vulnerable, we specified different padding oracle vectors which we send to the system under test, using different cipher suites and protocol versions. If the server does not behave identically (on both the TLS and TCP layers), we consider it to be vulnerable to a padding oracle attack, since it is leaking information about the plaintext via behavior differences. Depending on the responses to such padding oracle vectors, one can estimate which implementation is responsible for the vulnerability. We contacted quite a few website owners and tried to cooperate with them, to find out which vendors and TLS stacks are responsible for the identified vulnerabilities. You can find our current disclosure status on this issue on https://github.com/RUB-NDS/TLS-Padding-Oracles. We are currently in contact with other vendors to fix the remaining vulnerabilities, but the some of the rare (in terms of the number of affected hosts) vulnerabilities are currently not attributed. To fix the remaining vulnerabilities, we ask for your assistance to help get rid of this issue. For this purpose, we integrated a standalone version of our padding oracle evaluation tool into our TLS-Scanner (v.2.7) project. This tool allows you (among other things) to evaluate if a specific server is vulnerable.
When the tool detects a vulnerability, it tries to attribute the vulnerability to a specific vendor or CVE. If we already know of the vulnerability of the server you scanned, the tool will print its details. If the tool does not have a description of the vulnerability in its database, it will ask you to notify us about the vulnerable server, such that we can notify the vendor and get the device fixed. To be clear: the tool never sends any data to us - you have the choice of whether to notify us (and what details to include). There is a chance that the tool's attribution is also mistaken, that is, the tool lists a vendor for your host, but you know for sure that you do not use an implementation by this vendor. Please contact us in such cases as well.
How to use the Tool
First, you need to grab hold of the tool. There are 3 ways to get your hands dirty: pre-compiled, self-compiled or Docker. We provide a pre-compiled version of the tool since the compilation process can get quite messy if you are not familiar with java and maven. You can directly download the resulting project here. However, if you also want to play around with the code, you have to compile everything yourself.
Building the TLS-Scanner
For this, you will need (Git), maven (sudo apt-get install maven), OpenJDK-8 (I can guarantee that this version works, other versions might work as well, have not tested it).
You will need to get TLS-Attacker 2.9 (if you do not already have it): Now we can clone and install the TLS-Scanner
Docker
We also provide a Dockerfile, which lets you run the scanner directly
Getting Started
If you start the TLS-Scanner you should be greeted by a usage info, similar to the one below:
or
This should give you an overview of the supported command line flags. The only really required one is the -connect flag (similar to OpenSSL and TLS-Attacker), with which you specify which host to scan. The most basic command is therefore:
Your output may look something like this:
By default, TLS-Scanner will run single-threaded. In such cases the scanning will take a while; just how long it will take depends on your server configuration. The scanner also supports multi-threading, which drastically improves the performance. There are two parameters to play around with, -threads, which controls how many different "probes" are executed in parallel, and -aggressive , which controls how many handshakes can be executed simultaneously. If you want the fastest results the following parameters are usually a good choice:
But lets get back to the results of the Scanner. Currently the Scanner supports a bunch of well known tests, like supported ciphersuites or protocol versions. These are very similar to what you may be used to from other scanners like ssllabs or testssl.sh.
Padding Oracles
The main advantage of our scanner is the ability to scan for padding oracle vulnerabilities (which is probably why you are reading this post). You will see if you are vulnerable in the "Attack Vulnerabilities" section. For example, when scanning hackmanit.de, the result is false. Good for us! But as you might have seen there is also another section in the scanner report:"PaddingOracle Responsemap" This section lists the responses of the scanned host for each padding oracle vector, for each cipher suite and protocol version. For hackmanit.de, there is no detected difference in responses, which means hackmanit.de is not vulnerable to the attack: If we want, we can also look at the concrete responses of the server. For this purpose, we start the scanner with the -reportDetail flag:
With this flag we now get the following details:
So what does this all mean? First of all, we named our malformed records. The interpretation of those names is visualized in the following table:
BasicMac-<position>-<XOR>
A Record with ApplicationData, MAC and padding bytes, where the padding byte at <position> is XOR'd <XOR>
MissingMacByteFirst
A Record without ApplicationData, where the first byte of the MAC is missing
MissingMacByteLast
A Record without ApplicationData, where the last byte of the MAC is missing
Plain FF
A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xFF
Plain 3F
A Record without ApplicationData & MAC which only contains Paddingbytes: 64* 0xF3
A Record with invalid padding and valid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The Padding is invalid at <position>.
A Record with valid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at <position>.
A Record with invalid padding and invalid MAC. The Record contains <appDataLength> many ApplicationData bytes and <paddingBytes> many PaddingBytes. The MAC is invalid at the first position. The Padding is invalid at <position>.
Next to the name you can see what the actual response from the server was. Alert messages which are in [] brackets indicate that the alert was a fatal alert while () brackets indicate a warning alert. ENC means that the messages were encrypted (which is not always the case). The last symbol in each line indicates the state of the socket. An X represents a closed socket with a TCP FIN, a T indicates that the socket was still open at the time of measurement and an @ indicates that the socket was closed with an RST. So how did Hackmanit respond? We see a [BAD_RECORD_MAC] ENC X, which means we received an ENCrypted FATAL BAD_RECORD_MAC alert, and the TCP connection was closed with a TCP FIN. If a server appears to be vulnerable, the scanner will execute the scan a total of three times to confirm the vulnerability. Since this response is identical to all our vectors, we know that the server was not vulnerable and the scanner is not re-executing the workflows.
Here is an example of a vulnerable host: As you can see, this time the workflows got executed multiple times, and the scanner reports the cipher suite and version as vulnerable because of "SOCKET_STATE". This means that in some cases the socket state revealed information about the plaintext. If you look closely, you can see that for ValPadInvMac-[0]-0-59, ValPadInvMac-[8]-0-59 and ValPadInvMac-[15]-0-59 the server failed to close the TCP socket, while for all other vectors the TCP connect was closed with a TCP FIN. The server was therefore vulnerable.
Since the server was vulnerable, TLS-Scanner will also print an additional section: "PaddingOracle Details"
In this section we try to identify the vulnerability. In the example above, TLS-Scanner will print the following:
As you can see, we attribute this vulnerability to OpenSSL <1.0.2r. We do so by looking at the exact responses to our malformed records. We additionally print two important facts about the vulnerability: Whether it is observable and its strength. The precise details of these properties are beyond the scope of this blogpost, but the short version is: If an oracle is observable, a man in the middle attacker can see the differences between the vectors by passively observing the traffic, without relying on browser or application specific tricks. A strong oracle has no limitations in the number of consecutive bytes an attacker can decrypt. If an oracle is STRONG and OBSERVABLE, then an attacker can realistically exploit it. This is the case in the example above. For more details on this, you will have to wait for the paper.
Attribution
As you can see, we try to fingerprint the responsible device/implementation. However, we were not able to identify all vulnerable implementations yet. If we cannot attribute a vulnerability you will receive the following message:
Could not identify the vulnerability. Please contact us if you know which software/hardware is generating this behavior.
If you encounter this message, we do not know yet who is responsible for this padding oracle and would be happy to know which device/vendor is responsible. If you know who is, please contact us so that we can get in contact with the vendor to fix the issue. To reiterate, the tool never sends any data back to us, and it is your choice whether to contact us manually or not.
There are also some cases in which we can identify the vendor, but the vendor has not patched the vulnerability yet. If you encounter such a host, the scanner will tell you that we know the responsible vendor. To prevent abuse, we do not include further details.
Non-Determinism and Errors
In some cases, the scanner is unable to scan for padding oracles and reports ERROR or non-deterministic responses. The ERROR cases appear if the scanner failed could not handshake with the specified cipher suite and protocol version. This might be due to a bug in the tested TLS-Server or a bug in TLS-Attacker or TLS-Scanner. If you think the handshake fails because of an issue on our side, please open an issue on Github, and we will investigate. The more interesting cases are the non-deterministic ones. In such cases the scanner observed non-identical scan results in three separate scans. This can be due to non-determinism in the software, connection errors, server load or non-homogeneous load balancing. Currently, you will have to analyze these cases manually. In the paper, we excluded such hosts from our study because we did not want to artificially improve our results. But we understand that you as a tester want to know if the server is vulnerable or not. If the server is not truly vulnerable you would see the differences between the answers spread across all the different vectors. If the differences only appear on a subset of malformed records the server is very likely vulnerable. If you are unsure, you can also always scan multiple times (or scan slowly), increase the timeout, or if you are entirely lost get in touch with us.
How YOU can help
Please use the scanner on all your hosts and check for padding oracle vulnerabilities. If the scanner can identify your vulnerability, a patch should already be available. Please patch your system! If the scanner does not identify the vulnerability (and instructs you to contact us), please contact us with the details (robert.merget@rub.de). If you can provide us with the detailed output of the scanner or even better, the name of the host, with the corresponding vendor, we could match the results with our database and help fix the issue. We can already attribute over 90% of the vulnerabilities, but there is still a lot to be discovered. We mostly scanned the Alexa top 1-million on port 443. Other protocols like IMAPS, POP3S, etc. might have different implementations with different vulnerabilities. If you find vulnerabilities with our tool, please give us credit. It helps us to get more funding for our project.
Issues with the Scanner
A notable feature of our scanner is that we do not actively try to avoid intolerances (like not scanning with a lot of cipher suites in the Hello messages etc.). We believe that doing so would hide important bugs. We are currently experimenting with intolerances checks, but the feature is now still in beta. If we cannot scan a server (most of the time due to intolerances or SNI problems), the scanner will report a lot of intolerances and usually no supported protocol versions. Some intolerances may trick the scanner into reporting false results. At the current stage, we cannot make any guarantees. If you are using this tool during a pentest, it might be smart to rescan with other scanners (like the recently released padcheck tool from our colleague Craig Young) to find the ground truth (this is good advice in general, since other mainstream scanners likely have the same issues). Note however that it is very unlikely that the scanner reports a false positive on a padding oracle scan.
Conclusion
There are still a lot of padding oracle vulnerabilities out there - and a lot of them are still unpatched. We hope you will find some bugs with the tool :) Happy H4cking :D
"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...
YardStick One Unleashed, Automating RF Attacks In Python - An RFCat Primer
I decided to dive into our current device a bit more before moving on to a new device, and really ramp up the skillsets with RFCat and the Yardstick.So for this blog you will need our previous Target and a Yardstick One. We will be hacking everyting using only the Yardstick and Python.
So last time we scanned for signals with GQRX and a Software Defined Radio device. We took the demodulated wave forms in Audacity and discerned what the binary representation of our wave forms were by decoding them manually. We then transferred those into a hex format that our yardstick understood.However there is a way to do everything with our Yardstick. It will require a bit more understanding of the RFCat library, and a bit of python.
This blog will be your RFCAT primer and coding tutorial, but don't be scared with the word "Programming" I will be using simple code, nothing complicated.So if your a programmer, tune out any coding explanation and understand RFCat, if your not a coder, then use this as a jumping point to start making some quick python scripts for hacking.
Video Series PlayList Associated with this blog:
The first thing we did in our last blog after looking up the frequency was to open up GQRX and check if we can see our devices signals. As it turns out you can actually do this in python with RFCat. Which is really convenient if you left your Software Defined Radio dongle at home but happen to have access to a Yardstick.
RFCat as a Spectrum Analyzer:
In order to use RFCat as a spectrum analyzer we need to make sure we have RFcat installed and a few prerequisites such as python and PySide modules.I actually did this inside of an Ubuntu VMware because Pyside was giving me issues on OSX and I didn't feel like trying to fix it. So If you spin up an ubuntu vm you can do the following to get things up and running..
Install Spectrum Analyzer PreReqs:
sudo pip install PySide
sudo apt-get install ipython
Plug in your adapter and type in the following:
rfcat -r
d.specan(315000000)
You will then see the below output of RFCat Specan running in the 315 MHz range.
Click our doorbell, or trip the motion sensor and you will see a frequency spike as shown in the second picture.
This is similar to what you saw in GQRX but all with your Yardstick and the Python RFCat library.
So everything seems to be working and we can see our devices transmitting on the 315MHz frequency.Unfortunately we have no record button on Spescan. This leaves us to dive a little deeper into RFCat. We will see what RFCat can do for us in the recording and sniffing capacity.
Sniffing RF Data With The YardStick and Python:
In RFCat there is a simple listening command in our interactive session which will give us an idea of what is being transmitted and in what type of data format we are recieving. When using GQRX we received a WAV file, but what does RFCat give us?One thing I have realized over the years is programming is all about dealing with data in various formats and figuring out how to parse and use it in various implementations. So the first thing we have to figure out is what kind of data we are dealing with.
Lets hop back into RFCat and set a few parameters so the yardstick knows to listen on 315MHz and to use ASK modulation.The settings below should all be familiar from our last blog with an exception of "lowball" which configures the radio to use the lowest level of filtering. We basically want to see everything but may experience some noise by not filtering it out.. For example before you hit your doorbell button you may see random FF FF FF FF data outputted to the screen.
Below is the cmdline input needed and some example output. After all of our settings are in place we can use RF.listen() to start listening for everything in the 315000000 frequency range and have it output to the screen.
After you set it up, you can press the button on your doorbell and you will receive the following output. We have lots of zeros and what might be some hex output.
Destroy ficti0n$rfcat -r
>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFlisten()
Entering RFlisten mode...packets arriving will be displayed on the screen
If you hit "ENTER" in your terminal you will stop receiving packets and drop back into a python interactive terminal. If we take a look at the repeating pattern in the above output, it looks like some random patterns and then a repeating pattern of, 84e708421084e738.If we convert that to binary we can compare with what we decoded WAV from our previous blog.
Since we are already in a python terminal you can type the following to see the binary representation:
Lets break that up into 8 bit bytes and compare it to our previous blogs binary, hmm its lot different then what we originally decoded the signal to be:
If we take the above capture data and format it correctly for RFcat with the replay code from the last blog. When we send it over, it does indeed ring the doorbell, thats interesting. A completely different value in both hex and in binary and still we get a doorbell to ring. So the variance we talked about last time extends a bit more. Below is the code with the new hex from the capture data:
I will also take a minute to note something before we continue. I had a little trouble at first when using a telescopic antenna in RFcat and the YardStick.So I will list those issues below as notes for you to play with if you run into random looking captures when pressing your doorbell button.
When using a telescopic antenna closed I had almost repeating output with some random bits flipped
When extending the antenna it went crazy output with random noise
I then used a small rubber ducky antenna and got the repeating output shown above.
What we have done so far:
So above, we managed to figure out the following all in RFCat
Verify the frequency with RFCat
How can I listen for it and capture a transmission with RFCat
How can I send this transmission with RFCat
We have basically eliminated the immediate need for the graphical tools that we were using in the last blog. Not to say that they are not useful. They absolutely are, and we should use them often and know how to work with all kinds of formats and understand everything.. However, if we are living in a reality that all we have is a Yardstick and no other tools. We are not helpless and we can still kick some serious RF butt.
Now we are going to take this a bit further so we can learn some more about RFCat, Python and mistakesI made when trying to automate this stuff. I found some interesting quirks I had to work through and I would like to save others some time who are also in the learning process as I am.
Using RFrecv() for Listening:
Ok first thing I learned is that RFListen() is not all that useful when it comes to automating this stuff. I tried to set its output to a variable but that did not seem to work.. So instead we will be working with another feature that lets us listen and that is RFrecv().If we fire up our RFCat in the terminal again we can give that a try:
Destroy:~ ficti0n$ rfcat -r
>>> d.setFreq(315000000)
>>> d.setMdmModulation(MOD_ASK_OOK)
>>> d.setMdmDRate(4800)
>>> d.setMaxPower()
>>> d.lowball()
>>> d.RFrecv()
Traceback (most recent call last):
File "", line 1, in
File "/Library/Python/2.7/site-packages/rflib/chipcon_nic.py", line 1376, in RFrecv
data = self.recv(APP_NIC, NIC_RECV, timeout)
File "/Library/Python/2.7/site-packages/rflib/chipcon_usb.py", line 664, in recv
raise(ChipconUsbTimeoutException())
ChipconUsbTimeoutException: Timeout waiting for USB response.
OK thats not cool we are getting a weird error if we don't get a signal right away regarding ChipconUsbTimeoutException.
No problem since we are in a python terminal we can just capture this exception and pass it, then continue with sniffing.This is done with a Try/Except block.
try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
...
That looks a little better, I am no longer receiving errors, but lets put this in a loop so we are continuously listening with RFrecv() and press our doorbell so we can capture our doorbell signal.Below is the output of a random signal that came in followed by our doorbell.. but its all kinds of crazy looking and a bit hard to read:
try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
...
while True:
... try:
... d.RFrecv()
... except ChipconUsbTimeoutException:
... pass
Lets try to fix the output a little and make it more readable by encoding it before we view it. Open up your text editor and use the following code.What we are doing here is simply setting up our listener as we did before and then setting it to a variable we can use.
Line 12: Setting our RFrecv() output to the variable y and z. The y variable is the output that we want
Line 13: We will wrap the y variable with an encode function to encode it with a HEX encoding.
Line 14: After that we just print it out.
When we run this script from the command line we will get a much nicer output shown below, much like we did with the RFlisten function above. The big difference being that our data is now set to the variable "capture"on line 13 and we can do what we want with that data. For example we can directly replay that data rather then manually performing the actions.
Parsing and replaying data:
This actually took me a bit of time to figure out, so we need to do a few things to get this to work:
We need to parse out the data from the surrounding 0s
We need to convert it to a format we can send (tricker then it sounds)
We need to add padding and send that data over (We know how to do this already)
Parsing Data:
So with this I first tried all kinds of regular expressions, but for some reason the inverse of more then 3 zeros in a row does not seem to work. I am no regex master but that seemed like it should be working. I then tried a few creative solutions reducing repeating zeros down to pairs that I could split on with string functions. This actually worked well but then my buddy showed me this which was more efficient:
re.split ('0000*', capture)
All this is doing is using the regex library to parse on a set of 4 or more zerosand return whats left in a list of useable hex data for sending.So lets add that into our code and give it a try to see what we get back. I made the following code changes:
Line 2: Import the Regex library
Line 11: We defined the capture variable so we can access it outside of the Try Block and the loop
Line 21: We created a payloads variable and created a list from the capture file of non 0000 blocks
Line 22: We print out our list of useable payloads which can been seen in the below output
Data Format Woes:
So we have data in a list we can pull from, thats awesome but I ran into a few issues. I first tried to parse this data into the \x format we normally used when sending our attack payloads manually, but that actually does not work. Reason being that if I use a code snippet like the following to convert this data into the right format everything looks ok and something like this \x84\xe7\x08\x42\x10\x84\xe7.But it won't actually work when I send it with RFCat. For some reason when you paste in your own hex its in a different format then if you programmatically create hex like below. You don't really need to understand the code below, just know it takes our payload and creates the hex in a visual format to what we used in the last blog:
DON'T USE THIS.. IT WONT WORK!!!
for payload in payloads:
formatted = ""
if (len(payload) > 6) and (len(payload) % 2 == 0):
print "Currently being formatted: " + payload
iterator = iter(payload)
for i in iterator:
formatted += ('\\x'+i + next(iterator))
else:
continue
Formatted Hex Vs Manually Pasted Hex
So lets compare the outputs of our manually created Hex String versus what we get when we format with the above code
Below is the output of the following:
Your encoded capture
Your parsed payloads in a nice list
Your payload being processed into hex.
But this is where things go wrong, you then have :
Your nicely formatted Hex created by your code above (Yay for us)
Then you have your manually pasted in hex from your original attack payloads as unprintable characters(What?)
You can clearly see there is a major difference between when we manually paste in our hex like we did in the last blog and when we create it from our capture file.This led to another sleepless night of researching whats going on. I did a bunch of troubleshooting until I found some code on the RFcat site and saw it using the BitString library and something called BitArray.The examples for this library were using binary data instead of hex and then converting it.
BitString BitArray Formating FTW:
If you remember above we created binary input with some python, so lets use that code in our current program template and then feed it into byteArray and see what happens. We can install bitstring with the following:
Install Bitstring:
sudo pip install bitstring
Our New code using BitString:
Line 2: I imported bitstring
Line 25: I added a for loop to go through our payload list one by one
Line 27: I convert our current payload to binary
Line 28: I take that binary and I feed it into bitstring to fix the formatting issues
Lines 29-30:Print out our binary and our new data that match our manually pasted data format, shown below
With these conversions the data above looks like its correct to attack our target devices. I know this seems like a lot of steps, but honestly this is only 50 lines of code in all to automate our replay attacks in a simple way.It is also very easy if you know what your doing and don't spend all of your time figuring it out like I did. You just need to understand how to work with the types of data each component understands.
With this latest code update we are ready to send our code with a simple modification to our RFxmit line from the last blog. We will now change RXxmit to take our formatted variable and then append our padding:
Below is our full code to automate this attack, with a few changeups, but not many.. Really all I did was add some conditional statements to limit our data to longer payloads that are divisible by 2 since our hex takes 2 string characters for example \x41 is the string character 4 and 1.I originally did this for the iterator code which required the proper amount of characters but decided to leave it since it makes sense anyway.I also set it so that if there is a capture it breaks out of the loop. This way we are not continuously attacking every transmission we see. Instead for our testing we can hit our doorbell, replay all the values before our script finishes and exits.
Note: I sent similar code to a friend and had him run it against a black box real world target. He had permission to attack this target via the owner of a facility and it worked flawlessly. So although a doorbell is a trivial target. This same research applies to garages, gates, and any other signal not using protection mechanism such as rolling code, multiple frequencies at once etc.
Also note that when you run this, almost all of the payloads in your list will ring the doorbell which is why I put a timing variable before the sending command. This way your doorbell isn't overburdened. I already broke a few of these devices during testing LOL.
I have since modified this code to be more effective, and have additional features and more niceties, I will release that code when its ready.. For now enjoy the below code and hit me up with any questions or comments.
I hope this blog is helpful in demystifying RFCat in order to successfully perform/automate attacks with only Python and your Yardstick One. This is essentially a few nights of my research posted here for everyone to learn from. Because it was a pain to find useful information, and I would like to save other people a lot of sleepless nights. I am by no means the master of RF or RFCat, there is tons more to learn. Up next I will get back on track with a real world attack against a device and creating our own keyfobs to replay our attacks in the future.
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.
Peruano,Ingeniero UNI Lima 68, diplomado en el CEPE Paris 71, Doctorado en Economia en Grenoble 73, Profesor Principal de la UNI, fue Presidente de la ADUNI 79, Presidente del capitulo de ingenieros industriales y economistas, Secretario general y Decano Nacional del Colegio de Ingenieros del Peru, Regidor Metropolitano de Lima 83-89, Presidente de la empresa de servicios informaticos de Lima (SERMIN), Presidente del Servicio de Catastro Integral de Lima, Director de la empresa inmobiliaria de Lima EMILIMA, Director del Banco Central Reserva del Peru 2001-2006. Representante del Peru en FLAR, CEMLA y la conferencia de NN.UU. sobre Finanzas para el desarrollo. Elegido consejero del Consejo Nacional de la Magistratura, fue su presidente 2011 y dirige la comision de evaluacion y ratificacion de jueces y fiscales. Profesor invitado en Francia, profesor de la escuela de postgrado en la FIIS-UNI es miembro emerito de la Orden de Ingenieria y recibio la distincion de la Antorcha de Habich-UNI
