Account Hijacking – Integria IMS

Most of the vulnerabilities I uncover fit neatly into a particular category like XSS, SQLi, or buffer overflow. Sometimes, though, looking outside the box can yield interesting finds. In this post I’ll discuss one such vulnerability I discovered in the community edition of Integria IMS server, a PHP-based IT helpdesk management system. The vulnerability resided in the password reset process and allowed an attacker to takeover any user account provided he or she knew the username. No authentication or user interaction were required.

During the password reset process, Integria generated an MD5 hash and emailed it to the user. The user would enter the hash into the password reset window and if the hash matched the copy the server had on record then the user was allowed to change their password.

There were two issues that combined to allow account hijacking:
– The generated MD5 hash was limited to just 100 possible values for any given user on any given Integria installation.
– The hash submission page lacked brute force protection.

The snippet of code that generated the hash looked something like this:

$resethash = md5($config["sitename"].rand(0,100).$recover)

The hash accepted 3 inputs – a value called $config[“sitename”], a random number between 0 and 100, and the variable “$recover” which turned out to be the username. An internal attacker with an account of their own would most likely know their organization’s username scheme and could enumerate usernames of fellow users. An external attacker could also enumerate usernames, but as it turned out the Integria server shipped with a default admin account enabled, with username ‘admin’, providing a common target across Integria deployments. Thus, the username did not add much randomness to the hash.

The random number afforded little protection since generating 100 MD5 hashes requires very little time or computing power. Only the $config[“sitename”] value was left providing any protection against brute force. At first I was unsure what this value represented but after trial and error I discovered it surfaced as the HTML title of the login page presented to unauthenticated users. Anyone could reach the login page so the $config[“sitename”] value didn’t help guard against attacks either.

The final roadblock was account lockout protection if the sever blocked hash submissions after a certain number of failed attempts. I wrote a script to generate the 100 password reset hashes for a test account and automatically submit them to the server. I ran it and the server did not block attempts to submit the password reset hash after any number of incorrect submissions. At this point we could initiate a password reset for a user, generate all 100 possible hashes, and submit each hash code until we found the one that worked. Or put another way, it was game over…

As of this writing it’s been over a year since a patch was released and updated Integria deployments should be immune. However, if you have an outdated Internet accessible Integria server with the default admin account enabled, please be advised your server is quite vulnerable to takeover. I plan to publish proof of concept code soon and provide a link here.

Shoutout and special thanks to the Integria team for their quick response and working to issue a patch! Thank you for reading, until next time, happy hunting…


Security Advisory – Multiple Cross Site Scripting Vulnerabilities in EspoCRM

Product: EspoCRM
Vendor: Letrium LTD/Open source software
Version: 4.5.0, possibly earlier
Category: Cross Site Scripting
Vendor notified: 2017-03-24
Patched: 2017-04-03
Disclosed: 2017-04-22
Researcher: Carl Pearson

Multiple persistent cross site scripting (XSS) vulnerabilities exist in EspoCRM v4.5.0, in the Knowledge Base article body text field, Accounts billing and shipping address fields, Contacts name and address fields, and Leads address fields. An authenticated EspoCRM user with appropriate permissions to each module could exploit these vulnerabilities to execute Javascript code in the context of other site users.


If successful, an attacker could obtain the victim’s session cookie and use it to gain access to their account. An attacker must be authenticated to the EspoCRM system and have authorization for each affected module in order to exploit the module’s XSS vulnerabilites.

Proof of Concept
See the attached report file for technical details.

EspoCRM v4.5.1 patches these issues. Updating any existing EspoCRM installs is recommended.

Product home:
Bug notice:
OWASP XSS overview:

This report may be edited to include a CVE number if one is assigned.

Security Advisory – Cross Site Request Forgery in Chyrp Lite

Product: Chyrp Lite
Vendor: Open source community
Version: 2016.04 “Lago” and earlier
Category: Cross site request forgery (CSRF)
Vendor Notified: 2017-01-05
Patched: 2017-01-06
Disclosed: 2017-03-06
Researcher(s): Carl Pearson
CVE: CVE-2017-1000008

A cross-site request forgery (CSRF) vulnerability exists in the user properites function of the Chyrp Lite blog engine. An unauthenticated remote attacker can exploit the vulnerability by tricking authenticated users into visiting a webpage under attacker control.

Proof of Concept
Example HTML attack form:

<!-- The form submits when this button is clicked. -->
<button onclick="document.csrf_form.submit()">Click to run</button>
<!-- Edit the 'action' attribute to reflect the IP address or hostname of the victim's Chyrp install. -->
<form name="csrf_form" id="csrf_form" method="POST" action="http://[host]/?action=controls">
	<input class="text" type="text" name="login" value="user" id="login" disabled="disabled"/>
	<input type="text" name="full_name" value="" id="full_name" tabindex="1"/>
	<input type="text" name="email" value="" id="email" tabindex="1"/>
	<input type="text" name="website" value="" id="website" tabindex="1"/>
	<input type="password" name="new_password1" value="apple" id="new_password1"/>
	<input type="password" name="new_password2" value="apple" id="new_password2"/>

If successful, an attacker can arbitrarily change the user’s password, email, and username to any desired values.

Chyrp Lite version 2017.01 “Swainson” patches this issue. Updating any existing Chyrp Lite installs is recommended.

Project home:
v2017.01 release notes:
OWASP CSRF overview:

Edit 7/13/17: CVE identifier added.

Security Advisory – Open URL Redirect in Koozali SME Server

Product: Koozali SME Server
Vendor: Koozali Foundation/Open Source Software
Version: 8.x, 9.x, 10.x
Category: Open URL Redirect
Vendor Notified: 2017-01-11
Patched: 2017-01-23
Disclosed: 2017-02-02
Researcher(s): Carl Pearson
CVE: CVE-2017-1000027

An open URL redirect vulnerability exists in the user login function of Koozali SME Server. The server fails to validate the URL value of the ‘back’ parameter. An unauthenticated remote attacker can exploit this vulnerability by crafting a link to the SME Server login page with an arbitrary attacker-chosen URL supplied for the ‘back’ parameter and convincing a user to click it. Upon login, the user is redirected to the URL supplied in the ‘back’ parameter. The user must supply valid credentials on the first login attempt or the URL changes and the attack fails.

Proof of Concept
The following link would redirect users to after successfully authenticating to the SME server:
https://[server name or IP]/server-common/cgi-bin/login?

The browser cookie/authentication token is tacked on as a parameter by the server before sending clients to the redirect URL. Therefore, if successful an attacker can obtain the authenticated user’s cookie and use it to gain access to their SME Server account.

Update the e-smith-manager package on an SME Server installation to the latest version (yum update e-smith-manager). Refer to the SME Server security notice here:,52838.0.html.

SME Server Security Notice:,52838.0.html
Project Home:
OWASP Open URL Redirects Overview:

Edit 7/13/17: CVE identifier added.