Home » Articles » Security audit - ithub.gov.ro

Security audit - ithub.gov.ro

Mon Aug 15, 2016

GovITHub is the government program that proposes to create the community of those that believe in a digital future for Romania, by changing public services with the help of technology.

Few days ago I decided to do a security audit for ithub.gov.ro since they are dealing with personal data and you can never be extra careful about your privacy. Below are the issues I have encountered while auditing the website.

1. XML-RPC endpoint

XML-RPC interface is enabled, it should be turned off unless used by Webpack or any blogging-software like Live Writer. Which they shouldn’t.

2. Outdated theme

The theme used, Zerif Lite by ThemeIsle, is an older version (last version being 1.8.4.5, site is currently using 1.8.3.5).

3. Outdated plugins with severe vulnerabilities

Some of the plugins used are outdated and are having serious vulnerabilities:

  • Profile Builder 2.1.2 (last version is 2.4.4) has several serious vulnerabilities (1, 2) that allow a malicious user to elevate the privileges of low level WordPress user roles to administrator, giving them full control of the website.

More precisely, the password is reset using a static-generated hash, consisting of the user name, user id and two static strings, and this hash is calculated when the password-reset is requested. If you know the user name and id (for example, usually administrator has admin as the user name and 1 as the user id), you can use a small Python script to calculate the password-reset hash:

import md5
m = md5.new()
userName = raw_input("Username:")
m.update(userName + "RMPBP" + raw_input("UserID:") + "PWRCVR")
print str(m.hexdigest())

Submitting the generated string to the endpoint responsable for the password reset will reset the password.

/front-end/wppb.recover.password.php?submited=yes&loginName=admin&key=PASS_RESET_HASH

4. File enumeration vulnerability

User-uploaded files are not renamed using a random pattern and are vulnerable to file enumeration: someone can write a bash script that can extract both the uploaded photos and CVs. Photos being public might not be considered an issue (I definitely think it is a bad choice), but CVs being able to be downloaded and inspected is a major privacy issue, personal information (full name, phone numbers, e-mail addresses, street address, any other personal data) is visible to any malicious user.

For example:

http://ithub.gov.ro/wp-content/uploads/2016/08/cv-1.pdf
http://ithub.gov.ro/wp-content/uploads/2016/08/cv-2.pdf
http://ithub.gov.ro/wp-content/uploads/2016/08/curriculum-vitae.pdf

And:

http://ithub.gov.ro/wp-content/uploads/2016/08/resume.pdf
http://ithub.gov.ro/wp-content/uploads/2016/08/resume-1.pdf

Or the photos:

http://ithub.gov.ro/wp-content/uploads/2016/08/me.jpg
http://ithub.gov.ro/wp-content/uploads/2016/08/me-13.jpg
http://ithub.gov.ro/wp-content/uploads/2016/08/photo.png

Or browse using the most-used first names in Romania:

http://ithub.gov.ro/wp-content/uploads/2016/08/alex.jpg
http://ithub.gov.ro/wp-content/uploads/2016/08/mihai.jpg
http://ithub.gov.ro/wp-content/uploads/2016/08/ioana.jpg

Using an external dictionary file to download via cURL both the photos and the CVs is very easy, therefore it’s a serious privacy issue: a malicious user can read the personal information and use it to reset the passwords for various web services.

The file name of user-uploaded files should be changed to a random 32-character string or a GUID to stop any Forced Browsing vulnerabilities.

A simple random string generation function written in PHP is below:

<?php
function random_string($length = 32) {
    return substr(
        str_shuffle(
            str_repeat(
                $str = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ', ceil($length / strlen($str))
            )
        ), 1, $length
    );
}
?>

Also, for some strange reason, the site’s firewall is blocking all Tor traffic (just this subdomain, not the whole gov.ro domain), that should not happen. Blocking Tor is bad for privacy.

Time-frame

  • August 7, 2016 - vulnerabilities disclosed to the site owner.
  • August 8, 2016 - issues fixed by the site owner.
  • August 15, 2016 - audit published.

  « Previous: Next: »