Many years ago I programed a console based multi protocol proxy (the sha0proxy) lately I created in dotnet a graphical verison of the tool, but due to the form referesh speed finally I implemented it in C++ with Qt.
This tool useful for reversing, exploiting & pentesting was finally called rproxy, and its a multi-protocol proxy over TCP or UDP.
Being in the middle of the communication you can view and modify the bytes before being sent to the client or server.
In the tools tab right now its possible to open the blob on radare2 for further reversing of the data structures or code.
A basic mutation based fuzzer is implemented for bug-hunting, just set the % ratio of mutation and the bytes will be modified during specific communications phase.
One of the powerful things of this tool is the scripting, it is possible to automate a modification in specific moment of the traffic flow.
For example a script with a single line: "IN 3 20 3F" will write a 0x3f on the offset 20 only on the third packet received from the server. I have used this feature for triggering vulnerabilities.
Regarding the saving and loading data from disk, it's possible to save and load data in raw and hex formats. Also can be configured for save all the communications or only specific emission.
In this article we are going to go through File Inclusion Vulnerability. Wikipedia defines File Inclusion Vulnerability as: "A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application." There are two types of File Inclusion Vulnerabilities, LFI (Local File Inclusion) and RFI (Remote File Inclusion). Offensive Security's Metasploit Unleashed guide describes LFI and RFI as: "LFI vulnerabilities allow an attacker to read (and sometimes execute) files on the victim machine. This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information. If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands. RFI vulnerabilities are easier to exploit but less common. Instead of accessing a file on the local machine, the attacker is able to execute code hosted on their own machine." In simpler terms LFI allows us to use the web application's execution engine (say php) to execute local files on the web server and RFI allows us to execute remote files, within the context of the target web server, which can be hosted anywhere remotely (given they can be accessed from the network on which web server is running). To follow along, click on the File Inclusion navigation link of DVWA, you should see a page like this:
Lets start by doing an LFI attack on the web application. Looking at the URL of the web application we can see a parameter named page which is used to load different php pages on the website.
Since it is loading different pages we can guess that it is loading local pages from the server and executing them. Lets try to get the famous /etc/passwd file found on every linux, to do that we have to find a way to access it via our LFI. We will start with this:
../etc/passwd
entering the above payload in the page parameter of the URL:
we get nothing back which means the page does not exist. Lets try to understand what we are trying to accomplish. We are asking for a file named passwd in a directory named etc which is one directory up from our current working directory. The etc directory lies at the root (/) of a linux file system. We tried to guess that we are in a directory (say www) which also lies at the root of the file system, that's why we tried to go up by one directory and then move to the etc directory which contains the passwd file. Our next guess will be that maybe we are two directories deeper, so we modify our payload to be like this:
../../etc/passwd
we get nothing back. We continue to modify our payload thinking we are one more directory deeper.
../../../etc/passwd
no luck again, lets try one more:
../../../../etc/passwd
nop nothing, we keep on going one directory deeper until we get seven directories deep and our payload becomes:
../../../../../../../etc/passwd
which returns the contents of passwd file as seen below:
This just means that we are currently working in a directory which is seven levels deep inside the root (/) directory. It also proves that our LFI is a success. We can also use php filters to get more and more information from the server. For example if we want to get the source code of the web server we can use php wrapper filter for that like this:
We will get a base64 encoded string. Lets copy that base64 encoded string in a file and save it as index.php.b64 (name can be anything) and then decode it like this:
cat index.php.b64 | base64 -d > index.php
We will now be able to read the web application's source code. But you maybe thinking why didn't we simply try to get index.php file without using php filter. The reason is because if we try to get a php file with LFI, the php file will be executed by the php interpreter rather than displayed as a text file. As a workaround we first encode it as base64 which the interpreter won't interpret since it is not php and thus will display the text. Next we will try to get a shell. Before php version 5.2, allow_url_include setting was enabled by default however after version 5.2 it was disabled by default. Since the version of php on which our dvwa app is running on is 5.2+ we cannot use the older methods like input wrapper or RFI to get shell on dvwa unless we change the default settings (which I won't). We will use the file upload functionality to get shell. We will upload a reverse shell using the file upload functionality and then access that uploaded reverse shell via LFI. Lets upload our reverse shell via File Upload functionality and then set up our netcat listener to listen for a connection coming from the server.
nc -lvnp 9999
Then using our LFI we will execute the uploaded reverse shell by accessing it using this url:
To learn more about File Upload Vulnerability and the reverse shell we have used here read Learning Web Pentesting With DVWA Part 5: Using File Upload to Get Shell. Attackers usually chain multiple vulnerabilities to get as much access as they can. This is a simple example of how multiple vulnerabilities (Unrestricted File Upload + LFI) can be used to scale up attacks. If you are interested in learning more about php wrappers then LFI CheetSheet is a good read and if you want to perform these attacks on the dvwa, then you'll have to enable allow_url_include setting by logging in to the dvwa server. That's it for today have fun. Leave your questions and queries in the comments below.
There are many basic shellcodes that can be emulated from the beginning from the end providing IOC like where is connecting and so on. But what can we do when the emulation get stuck at some point?
The console has many tools to interact with the emulator like it was a debugger but the shellcode really is not being executed so is safer than a debugger.
In some shellcodes the emulator emulates millions of instructions without problem, but in this case at instruction number 176 there is a crash, the [esp + 30h] contain an unexpected 0xffffffff.
There are two ways to trace the memory, tracing all memory operations with -m or inspecting specific place with -i which allow to use registers to express the memory location:
Eax is not a counter, is getting hardcoded values which is probably an API name:
In this case this shellcode depend on previous states and crash also in the debugger because of register values. this is just an example of how to operate in cases where is not fully emulated.
In next chapter will see how to unpack and dump to disk using the emulator.
Bob was tasked to break into XYZcorporation, so he pulled up the facility on google maps to see what the layout was. He was looking for any possible entry paths into the company headquarters. Online maps showed that the whole facility was surrounded by a security access gate. Not much else could be determined remotely so bob decided to take a drive to the facility and get a closer look.
Bob parked down the street in view of the entry gate. Upon arrival he noted the gate was un-manned and cars were rolling up to the gate typing in an access code or simply driving up to the gate as it opening automatically.Interestingly there was some kind of wireless technology in use.
How do we go from watching a car go through a gate, to having a physical device that opens the gate?
We will take a look at reversing a signal from an actual gate to program a remote with the proper RF signal.Learning how to perform these steps manually to get a better understanding of how RF remotes work in conjunction with automating processes with RFCrack.
In the the previous blogs, we sniffed signals and replayed them to perform actions. In this blog we are going to take a look at a signal and reverse it to create a physical device that will act as a replacement for the original device. Depending on the scenario this may be a better approach if you plan to enter the facility off hours when there is no signal to capture or you don't want to look suspicious.
Recon:
Lets first use the scanning functionality in RFCrack to find known frequencies. Weneed to understand the frequencies that gates usually use. This way we can set our scanner to a limited number of frequencies to rotate through. The smaller rage of frequencies used will provide a better chance of capturing a signal when a car opens the target gate. This would be beneficial if the scanning device is left unattended within a dropbox created with something like a Kali on a Raspberry Pi. One could access it from a good distance away by setting up a wifi hotspot or cellular connection.
Based on research remotes tend to use 315Mhz, 390Mhz, 433Mhz and a few other frequencies. So in our case we will start up RFCrack on those likely used frequencies and just let it run. We can also look up the FCID of our clicker to see what Frequencies manufactures are using. Although not standardized, similar technologies tend to use similar configurations. Below is from the data sheet located at https://fccid.io/HBW7922/Test-Report/test-report-1755584 which indicates that if this gate is compatible with a universal remote it should be using the 300,310, 315, 372, 390 Frequencies. Most notably the 310, 315 and 390 as the others are only on a couple configurations.
RFCrack Scanning:
Since the most used ranges are 310, 315, 390 within our universal clicker, lets set RFCrack scanner to rotate through those and scan for signals.If a number of cars go through the gate and there are no captures we can adjust the scanner later over our wifi connection from a distance.
Currently Scanning: 433000000 To cancel hit enter and wait a few seconds
Example of logging output:
From the above output you will see that a frequency was found on 390. However, if you had left this running for a few hours you could easily see all of the output in the log file located in your RFCrack/scanning_logs directory.For example the following captures were found in the log file in an easily parseable format:
Analyzing the signal to determine toggle switches:
Ok sweet, now we have a valid signal which will open the gate. Of course we could just replay this and open the gate, but we are going to create a physical device we can pass along to whoever needs entry regardless if they understand RF. No need to fumble around with a computer and look suspicious.Also replaying a signal with RFCrack is just to easy, nothing new to learn taking the easy route.
The first thing we are going to do is graph the capture and take a look at the wave pattern it creates. This can give us a lot of clues that might prove beneficial in figuring out the toggle switch pattern found in remotes. There are a few ways we can do this. If you don't have a yardstick at home you can capture the initial signal with your cheap RTL-SDR dongle as we did in the first RF blog. We could then open it in audacity. This signal is shown below.
Let RFCrack Plot the Signal For you:
The other option is let RFCrack help you out by taking a signal from the log output above and let RFCrack plot it for you.This saves time and allows you to use only one piece of hardware for all of the work.This can easily be done with the following command:
From the graph output we see 2 distinct crest lengths and some junk at either end we can throw away. These 2 unique crests correspond to our toggle switch positions of up/down giving us the following 2 possible scenarios using a 9 toggle switch remote based on the 9 crests above:
Possible toggle switch scenarios:
down down up up up down down down down
up up down down down up up up up
Configuring a remote:
Proper toggle switch configuration allows us to program a universal remote that sends a signal to the gate. However even with the proper toggle switch configuration the remote has many different signals it sends based on the manufacturer or type of signal.In order to figure out which configuration the gate is using without physically watching the gate open, we will rely on local signal analysis/comparison.
Programming a remote is done by clicking the device with the proper toggle switch configuration until the gate opens and the correct manufacturer is configured. Since we don't have access to the gate after capturing the initial signal we will instead compare each signal from he remote to the original captured signal.
Comparing Signals:
This can be done a few ways, one way is to use an RTLSDR and capture all of the presses followed by visually comparing the output in audacity. Instead I prefer to use one tool and automate this process with RFCrack so that on each click of the device we can compare a signal with the original capture. Since there are multiple signals sent with each click it will analyze all of them and provide a percent likelihood of match of all the signals in that click followed by a comparing the highest % match graph for visual confirmation. If you are seeing a 80-90% match you should have the correct signal match.
Note:Not every click will show output as some clicks will be on different frequencies, these don't matter since our recon confirmed the gate is communicating on 390Mhz.
In order to analyze the signals in real time you will need to open up your clicker and set the proper toggle switch settings followed by setting up a sniffer and live analysis with RFCrack:
Open up 2 terminals and use the following commands:
#Setup a sniffer on 390mhz Setup sniffer:python RFCrack.py -k -c -f 390000000.
#Monitor the log file, and provide the gates original signal Setup Analysis: python RFCrack.py -c -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c -n.
Cmd switches used
-k = known frequency
-c = compare mode
-f = frequency
-n = no yardstick needed for analysis
Make sure your remote is configured for one of the possible toggle configurations determined above. In the below example I am using the first configuration, any extra toggles left in the down position: (down down up up up down down down down)
Analyze Your Clicks:
Now with the two terminals open and running click the reset switch to the bottom left and hold till it flashes. Then keep clicking the left button and viewing the output in the sniffing analysis terminal which will provide the comparisons as graphs are loaded to validate the output.If you click the device and no output is seen, all that means is that the device is communicating on a frequency which we are not listening on.We don't care about those signals since they don't pertain to our target.
At around the 11th click you will see high likelihood of a match and a graph which is near identical. A few click outputs are shown below with the graph from the last output with a 97% match.It will always graph the highest percentage within a click.Sometimes there will be blank graphs when the data is wacky and doesn't work so well. This is fine since we don't care about wacky data.
You will notice the previous clicks did not show even close to a match, so its pretty easy to determine which is the right manufacture and setup for your target gate. Now just click the right hand button on the remote and it should be configured with the gates setup even though you are in another location setting up for your test.
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.05
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.12
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.14
Percent Chance of Match for press is: 0.20
Percent Chance of Match for press is: 0.19
Percent Chance of Match for press is: 0.25
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
----------Start Signals In Press--------------
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.93
Percent Chance of Match for press is: 0.97
Percent Chance of Match for press is: 0.90
Percent Chance of Match for press is: 0.88
Percent Chance of Match for press is: 0.44
----------End Signals In Press------------
For Visual of the last signal comparison go to ./imageOutput/LiveComparison.png
Graph Comparison Output for 97% Match:
Conclusion:
You have now walked through successfully reversing a toggle switch remote for a security gate. You took a raw signal and created a working device using only a Yardstick and RFCrack.This was just a quick tutorial on leveraging the skillsets you gained in previous blogs in order to learn how to analyzeRF signals within embedded devices. There are many scenarios these same techniques could assist in.We also covered a few new features in RF crack regarding logging, graphing and comparing signals.These are just a few of the features which have been added since the initial release. For more info and other features check the wiki.
