Rose & Marinaldo

Rose

Hi there

How would you like to earn a 35% commission for each sale for life by
selling SEO services

Every website owner requires the use of search engine optimizaztion (SEO)
for their websites. Think about it, this is really hot

Simply register with us, generate your affiliate links and incorporate them
on your websites, thats it.
It takes only a few minutes to set up everything and the payouts are sent
by each end of the month

Click here to sign up with us, totally free:
https://www.creative-digital.co/join-our-affiliate-program/

See you inside
Cassandra

Rose

Hi there

How would you like to earn a 35% commission for each sale for life by
selling SEO services

Every website owner requires the use of search engine optimizaztion (SEO)
for their websites. Think about it, this is really hot

Simply register with us, generate your affiliate links and incorporate them
on your websites, thats it.
It takes only a few minutes to set up everything and the payouts are sent
by each end of the month

Click here to sign up with us, totally free:
https://www.creative-digital.co/join-our-affiliate-program/

See you inside
Emmett

Rose

Hi,

Having links from dead domains towards your website, is of no use. NONE !

Here you will get backlinks from established domains, which have tons of
ranking keywords

check out more details:
https://www.creative-digital.co/product/semrush-backlinks/

thanks and regards
Creative Digital

Unsubscribe:
https://mgdots.co/unsubscribe/

Rose

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.

Find the source code and binaries at github: https://github.com/sha0coder/reproxy

Related news

Rose

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.

http://localhost:9000/vulnerabilities/fi/?page=include.php

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:

http://localhost:9000/vulnerabilities/fi/?page=../etc/passwd

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:

php://filter/convert.base64-encode/resource=index.php

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:

http://localhost:9000/vulnerabilities/fi/?page=../../hackable/uploads/revshell.php

Voila! We have a shell.

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.

References:

FILE INCLUSION VULNERABILITIES: https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/
php://: https://www.php.net/manual/en/wrappers.php.php
LFI Cheat Sheet: https://highon.coffee/blog/lfi-cheat-sheet/
File inclusion vulnerability: https://en.wikipedia.org/wiki/File_inclusion_vulnerability
PHP 5.2.0 Release Announcement: https://www.php.net/releases/5_2_0.php

More information

Rose

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.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -vv

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:

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin -i 'dword ptr [esp + 0x30]'

Now we know that in position 174 the value 0xffffffff is set.

But we have more control if we set the console at first instruction with -c 1 and set a memory breakpoint on write.

This "dec" instruction changes the zero for the 0xffffffff, and the instruction 90 is what actually is changing the stack value.

Lets trace the eax register to see if its a kind of counter or what is doing.

target/release/scemu -f ~/Downloads/shellcodes_matched/drv_shellcode.bin --reg eax

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.

Related articles

Rose

Reversing Device Signals with RFCrack for Red Teaming

This blog was researched and automated by:
@Ficti0n

@GarrGhar
Mostly because someone didn't want to pay for a new clicker that was lost LOL

Websites:
Console Cowboys: http://consolecowboys.com
CC Labs: http://cclabs.io

CC Labs Github for RFCrack Code:
https://github.com/cclabsInc/RFCrack

Contrived Scenario:

Bob was tasked to break into XYZ corporation, 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.

Items used in this blog:

Garage Remote Clicker: https://goo.gl/7fDQ2N
YardStick One: https://goo.gl/wd88sr
RTL SDR: https://goo.gl/B5uUAR

Walkthrough Video:

Remotely sniffing signals for later analysis:

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. We need 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.

Destroy:RFCrack ficti0n$ python RFCrack.py -k -f 310000000 315000000 390000000

Currently Scanning: 310000000 To cancel hit enter and wait a few seconds

Currently Scanning: 315000000 To cancel hit enter and wait a few seconds

Currently Scanning: 390000000 To cancel hit enter and wait a few seconds

e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000

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:

Destroy:RFCrack ficti0n$ cd scanning_logs/

Destroy:scanning_logs ficti0n$ ls

Dec25_14:58:45.log Dec25_21:17:14.log Jan03_20:12:56.log

Destroy:scanning_logs ficti0n$ cat Dec25_21\:17\:14.log

A signal was found on :390000000

c0000000000000000000000000008000000000000ef801fe003fe0fffc1fff83fff07ffe0007c0000000000000000000000000000000000000000000001c0000000000000000050003fe0fbfc1fffc3fff83fff0003e00000000000000000000000000000000000000000000007c1fff83fff003fe007fc00ff83fff07ffe0fffc1fff8001f00000000000000000000000000000000000000000000003e0fffc1fff801ff003fe007fc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000001f07ffe0dffc00ff803ff007fe0fffc1fff83fff07ffe0007c000000000000000000000000000000000000000000

A signal was found on :390000000

e0000000000104007ffe0000003000001f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c00000000000000000000000000000000000000000000e0007f037fe007fc00ff801ff07ffe0fffe1fffc3fff0001f00000000000000000000000000000000000000000000003809f641fff801ff003fe00ffc1fff83fff07ffe0fffc000f80000000000000000000000000000000000000000000003c0bff01bdf003fe007fc00ff83fff07ffe0fffc1fff8001f0000000000000000000000000000000000000000000000380000000000000000002007ac115001fff07ffe0fffc000f8000000000000000000000000000000000000000

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:

Destroy:RFCrack ficti0n$ python RFCrack.py -n -g -u 1f0fffe0fffc01ff803ff007fe0fffc1fff83fff07ffe0007c

-n = No yardstick attached

-g = graph a single signal

-u = Use this piece of data

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.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.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 analyze RF 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.

Rose & Marinaldo

segunda-feira, 8 de janeiro de 2024

Collaboration request

sábado, 28 de outubro de 2023

Collaboration request

quinta-feira, 27 de julho de 2023

<> Semrush Links <>

segunda-feira, 5 de junho de 2023

Multi-Protocol Proxy Over TCP & UDP

Related news

Learning Web Pentesting With DVWA Part 6: File Inclusion

References:

More information

domingo, 4 de junho de 2023

Emulating Shellcodes - Chapter 1

Hacking Everything With RF And Software Defined Radio - Part 3

Reversing Device Signals with RFCrack for Red Teaming

Contrived Scenario:

Items used in this blog:

Walkthrough Video:

Remotely sniffing signals for later analysis:

Recon:

RFCrack Scanning:

Example of logging output:

Analyzing the signal to determine toggle switches:

Let RFCrack Plot the Signal For you:

Possible toggle switch scenarios:

Configuring a remote:

Comparing Signals:

Open up 2 terminals and use the following commands:

Analyze Your Clicks:

Graph Comparison Output for 97% Match:

Conclusion:

Related word

Eu

Quem sou eu

Mô

Malu

Marcadores

Arquivo do blog