This is an exampre of how the function works:

In spite of this, as you can see, some sensible chars aren’t escaped like the % that can be useful in a LIKE query.

The mysql_escape_string have some vulnerability partially patched with the mysql_real_escape_string.
Particularly mysql_escape_string don’t require authentication and can be insert before the mysql_connect function.
This means that it doesn’t verify the database character encoding, but analyzes and sanitizes the string one byte at time also if the batabase encoding is multi bytes (GBK, UTF-8, Big5).

Take a look at this example of mysql authentication using PHP code:

If we suppose that the db encoding is GBK (in this case I forced it in the PHP code: mysql_query("SET CHARACTER SET 'gbk'")) we can try to take advantage of the use of different encoding type.
First of all let’s try to use PHP to see difference between GBK and ASCII, before and after mysql_escape_string()
Use the follow php sample:

Image 1

Now modify the previous sample and load it:

Image 1

Ok, the string that reaches the MySQL will be \xbf\x5c\x27; now, if the charset on MySQL is GBK, the behaviour will be the same of the PHP page: a kanji and a single quote that is what we need for a SQLi.
In the image 3 you can see actually the result:

Image 3

The only encoding I found to be vulnerable are GBK and BIG5 because are the only that have \x5c as second byte of an allowed character.
But you can explore more by referring to this site.
Also I can’t find a way to force the DB chatset before MySQL connection, so I suppose that SQLi can be reached only if the GBK is already the BD charset.

You can try to read the following posts to get more info about mysrl_real_escape and this kind of vulnerability:
https://security.stackexchange.com/questions/8028/does-mysql-escape-string-have-any-security-vulnerabilities-if-all-tables-using-l
https://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
https://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string
https://stackoverflow.com/questions/3665572/mysql-escape-string-vs-mysql-real-escape-string
https://www.sans.org/reading-room/whitepapers/application/web-application-injection-vulnerabilities-web-app-039-s-security-nemesis-34247

I’m not talking here about the exploit, but only about the shellcode creation and choices motivations. This exemple can be easly fit to other situations and replicated without inserting it in an exploit, but simply tested in a developer or in a custom binary file.

I started from this sample code. It uses the Windows API function MessageBoxA to popup a message

Looking up the MessageBoxA function in Google reveals four arguments:

So the sample code pushes in the stack all the arguments and then call the address of the function already loaded in memory.

Some things to underline:
– at the end of every argument a null byte is insered (\x00)
– the arguments are pushed in reverse order into the stack (LIFO)
– this is only a shellcode and it has to be appended to a program; this program must have the function MessageBoxA (user32.dll) loaded in memory.
– the address of the function (0x7E45058A) is hadrcoded and works only on the Operating System the shellcode is written for.
– the hardcoded address doesn’t work in random space address context (ASLR or EMET)

Starting from this sample I want to use the System() function to pass commands to the interpreter (typically CMD.EXE); I search in MSDN specifications and I found that it needs only one parameter: the command I want to pass.

First I have to determinate, using the debugger, if the function is loaded in memory, so in Olly I search for “Names in all modules” and, luckly I found it in the msvcrt.dll (Figure 1) at address 0x77BF93C7 (Figure 2).

Figure 1

Figure 2

So the testing shell code will be like this:

Ok, now I have the test shellcode; I can do it directly in Olly. I open the debugger, attach a program, edit the first few lines, put a brake point at the end of my code and run the program (Figure 3).
Remember that the msvcrt.dll must be one of the module loaded by the program attached to the debugger.

Figure 3

Note that the net user/net localgroup need the admin privilege to be executed, so in a real exploit the target program must be started using elevated rights. On the other hand the first command, the echo one, will work also with low privilege.

I continue my tests about EMETv4. This time I’ve installed EMETv4 on the same machine HP-CLI01 and HP-SRV01 (note that framework 4 is required ). The only configuration I set is the “recommended” one.

Test4
Target: Windows Server 2003 SP2 eng; Host Name: HP-SRV01; IP Address: 192.168.34.135
Vulnerability: CVE-2008-4250 (SMB)
Exploit used: ms08_067_netapi from metasploit
EMET agent: installed with recommended settings.

This is MSFConsolle ouput of the exploit:

The target is powned. Take a look at the process number 4016: 4016  3560  EMET_Agent.exe
The EMET_Agent is running but the exploit still works.

Test 5
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2008-4250 (IE6)
Exploit used: ms10_002_aurora from metasploit
EMET agent: installed with recommended settings.

I setup the exploit exactly as test 2 but this time EMET works well and stops me.
When I start IE6 on the target machine and point to the evil page the aurora exploit cause the crash of Internet Exploter as wished. so I restart the target machine and retry: same result, IE6 crash. I want to double check this and I exclude iexplorer.exe from EMEC configuration and this time the exploit has worked.

This is a drow: exploit 1 – EMEC 1.

Test 6
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2003-0264 (slmail55_4433)
Exploit used: my version of this well known exploit
EMET agent: installed with recommended settings.

Also in this case, with defaul settings the exploit works:

Again, after a reboot, EMET doesn’t stop the attack, so I try to adjust some settings. If I modify the profile template from “recommended” to “maximum” and reboot, EMET doesn’t allow the execution of code: the DEP block the execution from the address space. I double check it and retry my attack with basic settings: the exploit is not stopped. Also in this case let’s take 2 steps back and debug the application while EMET is blocking the execution (Image1)

Image 1

Conclusions
I consider the EMET idea extremly useful and I think that this program, if implemented, will be able to increase the system security. Nowaday the bigest problems, from my viewpoint, are:
– not all moules are present and activated (SEHOP e ASLR)
– not all installed programs are controlled by default
– On my tests, on Windows XP, I have a problem with the EMET_agent when start the GUI (image2) and when I reboot (image3).
– I would be happier if FrameWork4 is not a requirement.

Image 2

Image 3

The practice
I will test 3 attacks:
– To Operating system vulnerability (SMB)
– To Microsoft software (IE6)
– To non Microsoft Software (SLMail)

Target machines:
– Windows XP SP3 eng (Host Name: HP-CLI01; IP Address: 192.168.34.134)
– Windows Server 2003 SP2 eng (Host Name: HP-Srv01; IP Address: 192.168.34.135)

Attack machine:
– Linux BackTrack 5R2 (Host Name: bt; IP Address: 192.168.34.132)

Note that both Operating systems and vulnerability are rather old. I use these because I hope that EMET will work well on known exploits, better than with unknown one. So let’s start the phase 1: system without EMETv4.

Test 1
Target: Windows Server 2003 SP2 eng; Host Name: HP-Srv01; IP Address: 192.168.34.135
Vulnerability: CVE-2008-4250 (SMB)
Exploit used: ms08_067_netapi from metasploit

Look at the Metasploit Framework Consolle running on Linux machine:

Test 1 succesfull

Test 2
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2008-4250 (IE6)
Exploit used: ms10_002_aurora from metasploit

On the Linux machine I start a http server with evil page (https://192.168.34.132:8080/evil) using Metasploit:

Now in the target machine I start Internet Explorer 6, browse to the evil page and the msf consolle continues:

Test 2 succesfull

Test 3
Target: Windows XP SP3 eng; Host Name: HP-CLI01; IP Address: 192.168.34.134
Vulnerability: CVE-2003-0264 (slmail55_4433)
Exploit used: my version of this well known exploit

Take a look at the target machine:

Now, let’s run the exploit from the attacker machine and re-run netstat

The payload of the exploit was a bind shell on port 4444, indeed a TCP listener is now working this port.
On the Linux machine I am able to connect to this listener a get a remore shell:

The following screenshot is the exploit in acrion:

Image 1

Image 2

[end of phase 1] Take a look at the [phase 2]