General News

- This is a renewed up; former articles are accessible through 'Papers' section.
- To all of the former 41 RSS subscribers: Please subscribe through the new link again.

Login Form




Visits today:0
Visits yesterday:16
Visits in this month:475
Visits total:5036

Feeds



Metasploit Framework 3.5.1 Local Privilege Escalation Vulnerability (Exploiting the "Exploiter")
Written by Eduardo Prado (edu)   
Friday, 04 February 2011 03:14

Metasploit Project is developed by a group of skilled security researchers to provide people all over the world with penetration testing resources. The popular open source program Metasploit Framework, has been much improved since its early days, beating even commercial softwares.

Metasploit programs such as Metasploit Framework, Express and Pro are tools designed to perform penetration tests on different platforms, using different exploitation techniques and a large database of exploit codes with the goal to identify potentially exploitable flaws on clients and servers and give system administrators the opportunity to patch before the bad guys exploit them.

A local privilege escalation vulnerability exists in the Metasploit Framework 3.5.1 software on Windows systems, because the installer by default copies all the files to a folder (framework) in the root directory and does not enforce ACLs to prevent restricted users from writting files. The ACLs for directories created in the root drive by default permits restricted users to create folders and files in all subfolders.

By placing a DLL file in the %systemdrive%\framework\postgresql\bin it is possible to get it loaded by a program (postgres.exe) that is executed by the frameworkPostgreSQL´s service executable (pg_ctl.exe), every time the service starts, with NT AUTHORITY\SYSTEM user privileges, being able to run arbitrary code in the local system. Notice the service startup is set to automatic by default.

Possible Dll names :

- dnsapi.dll (warning: causes the service to be terminated silently)

- rasadhlp.dll

- hnetcfg.dll

Others exist but have not been tested.

Tested on Windows XP SP3 and Windows 7

Visit: Metasploit Official Website

 
Hijacking the Hijacker
Written by Eduardo Prado (edu)   
Thursday, 13 January 2011 20:41

On Windows operating systems, most of the times people should only blame theirselves for getting infected by malware, because they are not cautious when the operating system warns them about eg. opening "sexy-pictures.exe" and similar, received by e-mail and instant messengers.. Not only can these malwares steal sensitive data and give the creator(s) remote access and at times make the computer a "zombie" of a botnet but also make the infection obvious by hijacking the webbrowser and the user´s desktop. In the case of hijacking the desktop they usually display porn banners, sometimes they put a message telling the user needs to purchase a specific Antivirus software to get rid of malware installed on the computer as well, so that they are able to steal money and credit card information.

Not satisfied in making the infection obvious, malware creators also like to add a startup entry to popular registry locations such as the :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

In the "Shell" string value they append data so it will be set to something like this : "Explorer.exe malware.exe" and then they place the file "malware.exe" in the system directory and it will be started by Windows Explorer on every boot. As these malwares can, for instance, hijack the desktop, nothing more fair than hijacking them as a reward, right?

Well, sure! By abusing the creators lack of knowledge or lack of patience to write code properly/safely, we can hijack their execution in case they edit the above entry (which is widely used by malwares) without even touching the registry and without even having administrative privileges, on Windows XP, 2000, 2003 Server. All we have to do is place an executable called "malware.exe" in the current logged on user´s base directory (%userprofile%). Because Windows Explorer on the above versions of Windows starts in the user´s base directory and malware writers usually don´t provide a full path to their malware we are able to successfully hijack the execution of it, rendering it "dead" in the system in case of course it didnt add additional startup entries. This issue happens because of a common vulnerability in Windows OS : Relative paths! This rised security problems in the past and is also the cause for another vulnerability I posted in march of 2010, in the HTML Help Control´s (hhctrl.ocx) function "HTMLHelpA()" that loads CHM help files from the same directory where the program invoking help starts in, and was the source for the "Remote DLL Loading Hijack" mess.

 
Secumania's back alright!
Written by Saeed Beiki (cephexin)   
Wednesday, 05 January 2011 21:03

Hi there
Well, hell, we're back again after a long (long) downtime. The team has got another chance to provide some stuff to the wild. Keep back and reading.

 
First Remote Code Execution Vulnerability Affecting Microsoft Notepad
Written by Eduardo Prado (edu)   
Saturday, 06 March 2010 00:00

We are going to show you a little creativity; the process of triggering the first remote code execution vulnerability that affects Microsoft Notepad via innocent TXT documents. You've heard so many times people saying "Notepad is too simple. It is impossible to find a code execution bug." Well impossible is simply what has not yet been accomplished.This issue was successfully tested on the following operating systems:

-Windows 2000 Professional SP4

-Windows XP SP3

-Windows 2003 Server SP2

The research paper can be read here . The demonstration for this vulnerability can be downloaded here.