Android AndEngine Engine UML Class

Save the picture to your local machine and use a image viewer. If you try to view it using the browser it won't have enough resolution to be readable.

IsMessageAllowedByFilterEx

Just a reminder.

VU#273502 and change

Easyvista vulnerabilities quick view

I usually don't reverse text but sometimes I do.A couple of months ago I read some slides for a presentation about reverse engineering that stated capital letters "I don't reverse text" as a reference to web hacking. I'd like to state that sometimes I do, and I enjoy it; this being one of those occasions.

This post is a public disclosure of five bugs I found while at work, in an enterprise web application called Easyvista. Why the public disclosure you might ask? Not too often, but sometimes - mainly to friends that publish and expose their sites to the Internet - I pen test their sites for vulnerabilities. As problems are found, they're fixed as soon as I report them. This has no consequences because it's only one site, and once the bug is fixed the security hazard no longer persists. But, when dealing with applications and frameworks disseminated around the world, this sort of fix is not possible. The information of software vulnerability has to reach everyone, so those interested can verify if their platform is vulnerable, and fix it.  As I explained to the vendor, Staff&LIne, if done in a responsible and ethical manner, by allowing the vendor to fix the problem and notify their clients before going public, it is beneficial to all. Public disclosure done this way allows for users and security companies to become aware of the problem, and motivates them to contact the vendor for an update or upgrade of the software, mainly those clients who are no longer covered by a maintenance contract that automates this process.

Why should I update the application? It's just a web application. What is the risk to my organization?

Well, glad you asked. :) Besides corrupted data or exposure of management information, the real danger may lie in unauthorized admin access to the platform, as the application stores an organization inventory database: all machines, software, accounts, etc. This data can be used to leverage the information gathering phase of a major attack. So, if you're an Easyvista client please contact your vendor or support team as soon as possible and request for an update.

Let me introduce Easyvista to you by using the vendor words:

"EasyVista delivers a comprehensive, integrated, modular solution spanning the complete IT service management and asset management lifecycles. The EasyVista solution supports all 15 ITIL v3 processes including more than 300 out of the box workflow wizards."

And now, for something completely different: the technical details. Easyvista, as far as I care, is run in Apache web server. You can check this with any fingerprinting tool or just telnet it and observe the response headers:

HTTP/1.1 200 OK

Date: Thu, 05 Jan 2012 16:46:07 GMT

Server: Apache

X-Powered-By: PHP/4.4.1

The platform is developed in PHP, as seen by the accessed web page extensions (and the response headers - see above). The authentication is integrated with Microsoft's Active Directory (CAS model with SSO). The authentication is implemented in two different ways: a login page (/index.html) that requests your credentials, and a login pop box that asks for your credentials.

For what I can say, either of these authentications methods is vulnerable, because the flow path of execution and session setup ends up in the same vulnerable spot. Although, to be fair, I can’t really say if the vulnerability can be exploited if the SSPI module is not present as I didn’t access the application code.

The first authentication method, the login form:

The sequence of events when login in:

Let's peek at the index.php request:

POST /index.php HTTP/1.1

Host: XXXXXXXXXX

...

Content-Type: application/x-www-form-urlencoded

Content-Length: 107

url_account=50005&url_login=username&url_password=something&x=0&y=0&from_url=%2Findex.html

The second authentication method, uses SSPI Apache integrated authentication type.

This allows for NTLM negotiation, for example. Its execution flow is as follows:

Let's peek now at the index.php request:

POST /index.php?url_account=50005 HTTP/1.1

Host: XXXXXXXX

....

Content-Type: application/x-www-form-urlencoded

Content-Length: 36

SSPI_HEADER=domain_name%5Cuser_name

You see where we're going, right? (Yes, it is as easy as this.) Change the user_name to whatever user in the organization you want, and you get a session to that user. Remember that you're supposed to be in an Active Directory realm. So, you can grab a list of users from your outlook for example and try out any user, until you hit an administrator account.

The cherry on top of the cake is that you don't even have to login or provide any credential. If you use a direct link, like this:

http://servername/index.php?url_account=account_number&SSPI_HEADER=windows_domain\username

You will get a full working session with whatever user you want.

Index.php is the guilty one here. It trusts data that comes from the user while badly managing session data. It assumes that the user is authenticated and no longer validates the credentials.

The second problem found lies in the redirection page, indexphp_redirect.php, and is a reflected XSS attack. Watching the response given by the redirection page, we can defer our script attack:

HTTP/1.1 200 OK

...

Content-Length: 503

Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta http-equiv="X-UA-Compatible" content="IE=7"> <!-- IE7 mode --><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head><body><form name="frm" action="/index.php?url_account=5005 method="POST"><input type="hidden" name="SSPI_HEADER" value="domain_name\user_name"></form><script type="text/javascript" language="JavaScript">window.document.frm.submit()</script></body></html>

The variable url_account is vulnerable to code injection, as long as an REFERER header is provided. I know you know how to spoof a REFERER header. Just set it to any value you want. As for the PoC, the following code will do the trick:

<html>

<head>

<meta http-equiv="X-UA-Compatible" content="IE=7">

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>

<body>

<form name="frm" action="http://server_name/sspi/indexphp_redirect.php" method="POST">

<input type="hidden" name="url_account" value='50005" method="POST"><script>alert("ola")</script> <po="'>

</form>

<script type="text/javascript" language="JavaScript">window.document.frm.submit()

</script>

</body>

</html>

And the result: 

A couple more issues were found:

-          A session fixation problem that allowed for CSRF attacks.

-          A database fingerprinting thru SQL filter parser bypass. I didn’t work much on this one to see if SQL injection was possible, but as this item is not yet fixed, I won’t give any more details about it.

And that's it for today.

Hope you enjoyed it.

(.Net) EP! (.Net) EP! Hurra!!

The subject of this post will be about the different paths we can opt to find the EP in a .Net process. As I’m very lazy, instead of creating my own demo program, I'll be working with a sample program called 02simple.exe that came with Advanced .Net debugging book, and available with source from its online site http://advanceddotnetdebugging.com/. In hope that Mario Hewardt forgives my "unauthorized" use of his software, let me give him my endorsement, by saying that the book is great. Be it for those who debug or reverse engineer .Net applications, be it for those who program in .Net and are trying to delve into the under layers of the CLR engine.

 

So, Let's first find out what we're trying to hit. Using Ildasm, available on the .NET SDK:

  

Dumping the metainfo in ildasm:

===========================================================

ScopeName : 02Simple.exe

MVID      : {39294D5C-77D0-4D3C-8BBC-18B40FFDE70A}

===========================================================

Global functions

-------------------------------------------------------

Global fields

------------------------------------------------------

Global MemberRefs

-------------------------------------------------------

TypeDef #1 (02000002)

-------------------------------------------------------

      TypDefName: Advanced.NET.Debugging.Chapter2.Simple  (02000002)

      Flags     : [NotPublic] [AutoLayout] [Class] [AnsiClass] [BeforeFieldInit]  (00100000)

      Extends   : 01000001 [TypeRef] System.Object

      Method #1 (06000001) [ENTRYPOINT]

      -------------------------------------------------------

            MethodName: Main (06000001)

            Flags     : [Private] [Static] [HideBySig] [ReuseSlot]  (00000091)

            RVA       : 0x00002050

            ImplFlags : [IL] [Managed]  (00000000)

            CallCnvntn: [DEFAULT]

            ReturnType: Void

            1 Arguments

                  Argument #1:  SZArray String

            1 Parameters

                  (1) ParamToken : (08000001) Name : args flags: [none] (00000000)

      Method #2 (06000002)

      -------------------------------------------------------

            MethodName: .ctor (06000002)

            Flags     : [Public] [HideBySig] [ReuseSlot] [SpecialName] [RTSpecialName] [.ctor]  (00001886)

            RVA       : 0x0000205e

            ImplFlags : [IL] [Managed]  (00000000)

            CallCnvntn: [DEFAULT]

            hasThis

            ReturnType: Void

            No arguments.

...

...

  

The entry point method is called Main as it is marked with a couple of special flags: STATIC and ENTRYPOINT. This is all information that we need to confirm our future findings, so let's start with windbg.

Open executable in windbg, first break is fired at:

ntdll!DbgBreakPoint:

7c90120e cc              int     3

7c90120f c3              ret

There is nothing here yet:

0:000> ~

.  0  Id: e28.91c Suspend: 1 Teb: 7ffdd000 Unfrozen

If we step through, we can see that we stopped during the loading phase:

0:000> t
eax=00241eb4 ebx=7ffde000 ecx=00000000 edx=00000001 esi=00241f48 edi=00241eb4

eip=7c90120f esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

ntdll!DbgBreakPoint+0x1:
7c90120f c3              ret
0:000> t

eax=00241eb4 ebx=7ffde000 ecx=00000000 edx=00000001 esi=00241f48 edi=00241eb4

eip=7c940442 esp=0012fb24 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

ntdll!LdrpInitializeProcess+0xffa:
7c940442 8b4368          mov     eax,dword ptr [ebx+68h] ds:0023:7ffde068=00000470

If we try to load sos:

.loadby sos mscorwks
Unable to find module 'mscorwks'

We're presented with an error message.

Let's try to load psscor2:

.load psscor2

It seems that it was successful, lets run some commands:

!help

-------------------------------------------------------------------------------

PSSCOR is a debugger extension DLL designed to aid in the debugging of managed

programs. Functions are listed by category, then roughly in order of

importance. Shortcut names for popular functions are listed i...

...

Ok, some more:

!dumpdomain

Failed to find runtime DLL (mscorwks.dll), 0x80004005

Extension commands need mscorwks.dll in order to have something to do.

Yes, psscor2.dll is much friendlier than sos.dll, maybe because it is used by Microsoft employees. Both errors relate to the same situation, mscorwks.dll isn't yet loaded, so we need to wait until this module is loaded before trying to use any of the debugger metadata interpreter extensions commands.

So, first approach is to:

0:000> sxe ld mscorwks.dll

0:000> g

ModLoad: 79e70000 7a400000   C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

eax=00000000 ebx=00000000 ecx=008f0000 edx=7c90e514 esi=00000000 edi=00000000

eip=7c90e514 esp=0012f1bc ebp=0012f2b0 iopl=0         nv up ei ng nz ac pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000296

ntdll!KiFastSystemCallRet:

7c90e514 c3              ret

0:000> k

ChildEBP RetAddr 

0012f1b8 7c90d52a ntdll!KiFastSystemCallRet

0012f1bc 7c91bd23 ntdll!NtMapViewOfSection+0xc

0012f2b0 7c91626a ntdll!LdrpMapDll+0x330

0012f570 7c9164d3 ntdll!LdrpLoadDll+0x1e9

0012f818 7c801bbd ntdll!LdrLoadDll+0x230

0012f880 7900921b KERNEL32!LoadLibraryExW+0x18e

0012f8a4 7900923e mscoree!WszLoadLibraryEx+0x75

0012f8bc 79007b5a mscoree!LoadLibraryWrapperForEE+0x10

0012ffa4 79007c02 mscoree!GetInstallation+0x1cc

0012ffc0 7c817077 mscoree!_CorExeMain+0x12

0012fff0 00000000 KERNEL32!BaseProcessStart+0x23

Lets try it again:

0:000> .loadby sos mscorwks

No error, so the load was successful. Let's try running some commands:

0:000> !dumpdomain

--------------------------------------

System Domain: 00000000

Unable to get system domain info

Yey!! It worked. But we've got only the system domain, and even the system domain doesn't seem to be fully setup. Let's try to resolve the main entry to a valid IP address:

0:000> !name2ee 02simple Advanced.NET.Debugging.Chapter2.Simple.Main

Nothing happened. Damn. We can't breakpoint anything yet, because nothing has been setup yet. So let's resort to sosex.dll by Steve Johnson:

0:000> !load sosex

0:000> !mbm Advanced.NET.Debugging.Chapter2.Simple.Main

The breakpoint could not be resolved immediately.

Further attempts will be made as modules are loaded.

0:000> g

(a64.2c8): CLR notification exception - code e0444143 (first chance)

(a64.2c8): CLR notification exception - code e0444143 (first chance)

Breakpoint: Matching method Advanced.NET.Debugging.Chapter2.Simple.Main resolved, but not yet jitted. Setting JIT notification...

(a64.2c8): CLR notification exception - code e0444143 (first chance)

Breakpoint: JIT notification received for method Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[]).

Breakpoint set at Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[]).

Breakpoint 0 hit

eax=00922ff0 ebx=0012f4ac ecx=01292e14 edx=00000000 esi=00181718 edi=00000000

eip=00c70085 esp=0012f47c ebp=0012f480 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

00c70085 90              nop

We broke at 00c70085. Let's see what we've got there:

0:000> !u @eip

Normal JIT generated code

Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])

Begin 00c70070, size 27

00c70070 55              push    ebp

00c70071 8bec            mov     ebp,esp

00c70073 50              push    eax

00c70074 894dfc          mov     dword ptr [ebp-4],ecx

00c70077 833d142e920000  cmp     dword ptr ds:[922E14h],0

00c7007e 7405            je      00c70085

00c70080 e83ca64579      call    mscorwks!JIT_DbgIsJustMyCode (7a0ca6c1)

>>> 00c70085 90              nop

00c70086 8b0d30202902    mov     ecx,dword ptr ds:[2292030h] ("Welcome to Advanced .NET Debugging!")

00c7008c e88738b278      call    mscorlib_ni+0x6d3918 (79793918) (System.Console.WriteLine(System.String), mdToken: 060007c8)

00c70091 90              nop

00c70092 90              nop

00c70093 8be5            mov     esp,ebp

00c70095 5d              pop     ebp

00c70096 c3              ret

We're in!! But the code is already Jitted, and we still needed to know the function name we're looking for, in order to set a breakpoint on it. Although we were able to find the EP in memory, why should we need to resort to ildasm?

Let's try it another way. From the beginning again:

0:000> bu mscorwks!ClassLoader::RunMain

0:000> g

*** WARNING: Unable to verify checksum for C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\7124a40b9998f7b63c86bd1a2125ce26\mscorlib.ni.dll

Breakpoint 1 hit

eax=0012f81c ebx=00000000 ecx=79f54ea1 edx=80000001 esi=00922ff0 edi=00000000

eip=79f4088d esp=0012f7e4 ebp=0012fa48 iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

mscorwks!ClassLoader::RunMain:

79f4088d 6838010000      push    138h

0:000> .load psscor2

0:000> !dumpdomain

--------------------------------------

System Domain: 7a3bd058

LowFrequencyHeap: 7a3bd07c

HighFrequencyHeap: 7a3bd0c8

StubHeap: 7a3bd114

Stage: OPEN

Name: System Domain

--------------------------------------

Shared Domain: 7a3bc9a8

LowFrequencyHeap: 7a3bc9cc

HighFrequencyHeap: 7a3bca18

StubHeap: 7a3bca64

Stage: OPEN

Name: Shared Domain

Assembly: 0018f638

--------------------------------------

Domain 1: 0014c488

LowFrequencyHeap: 0014c4ac

HighFrequencyHeap: 0014c4f8

StubHeap: 0014c544

Stage: OPEN

SecurityDescriptor: 0014d7b0

Name: 02Simple.exe

Assembly: 0018f638 [C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll]

ClassLoader: 0018f6b8

SecurityDescriptor: 0018d310

  Module Name

790c1000 C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll

Assembly: 00193508 [D:\development\programming\debuggingdotnet\02Simple.exe]

ClassLoader: 00197f30

SecurityDescriptor: 001933d0

  Module Name

00922c5c D:\development\programming\debuggingdotnet\02Simple.exe

As seen, the domains have been setup, and ClassLoader::RunMain is about to run the method we want having ESI pointing to it. esi=00922ff0. Let's confirm this:

!dumpmd @esi

Method Name: Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])

Class: 0092125c

MethodTable: 00923004

mdToken: 06000001

Module: 00922c5c

IsJitted: no

m_CodeOrIL: ffffffff

Yes. We reached EP, fast and simple without having to reverse or decode anything. Just using windbg. Let's what more we can get from here:

0:000> !name2ee 02simple.exe Advanced.NET.Debugging.Chapter2.Simple.Main

Module: 00922c5c (02Simple.exe)

Token: 0x06000001

MethodDesc: 00922ff0

Name: Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])

Not JITTED yet. Use !bpmd -md 00922ff0 to break on run.

Everything checks. Notice something cool: the code is not jitted yet. So we can check it against the ildasm output:

0:000> !DumpIL @esi
ilAddr = 00402050

IL_0000: nop

IL_0001: ldstr "Welcome to Advanced .NET Debugging!"

IL_0006: call System.Console::WriteLine

IL_000b: nop

IL_000c: ret

How cool is this? Can we change the IL on runtime? Perhaps with some sort of hooking?

Now, let the crl jit the code and watch the result:

!bpmd -md 00922ff0

MethodDesc = 00922ff0

Adding pending breakpoints...

0:000> g

(c34.7cc): CLR notification exception - code e0444143 (first chance)

JITTED 02Simple!Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])

Setting breakpoint: bp 00C70070 [Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])]

Breakpoint 2 hit

eax=00922ff0 ebx=0012f4ac ecx=01292e14 edx=00000000 esi=00181718 edi=00000000

eip=00c70070 esp=0012f484 ebp=0012f490 iopl=0         nv up ei pl nz ac po nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000212

00c70070 55              push    ebp

We're back to the same point before:

!u @eip

Normal JIT generated code

Advanced.NET.Debugging.Chapter2.Simple.Main(System.String[])

Begin 00c70070, size 27

>>> 00c70070 55              push    ebp

00c70071 8bec            mov     ebp,esp

00c70073 50              push    eax

00c70074 894dfc          mov     dword ptr [ebp-4],ecx

00c70077 833d142e920000  cmp     dword ptr ds:[922E14h],0

00c7007e 7405            je      00c70085

00c70080 e83ca64579      call    mscorwks!JIT_DbgIsJustMyCode (7a0ca6c1)

00c70085 90              nop

00c70086 8b0d30202902    mov     ecx,dword ptr ds:[2292030h]

00c7008c e88738b278      call    mscorlib_ni+0x6d3918 (79793918) (System.Console.WriteLine(System.String), mdToken: 060007c8)

00c70091 90              nop

00c70092 90              nop

00c70093 8be5            mov     esp,ebp

00c70095 5d              pop     ebp

00c70096 c3              ret

Hope you enjoyed it.