lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTin=694tAfcsFJD8vdk75E6JFtMUA0k+Xnek-iY3@mail.gmail.com>
Date: Mon, 28 Mar 2011 14:15:04 +0200
From: Michele Orru <antisnatchor@...il.com>
To: full-disclosure@...ts.grok.org.uk
Cc: bugtraq@...urityfocus.com
Subject: [AntiSnatchOr] DotCloud Beta Multiple
	Vulnerabilities

DotCloud Beta Multiple Vulnerabilities

 Name: DotCloud Beta Multiple Vulnerabilities
 Systems Affected: DotCloud current beta
 Severity: Medium
 Vendor: http://www.dotcloud.com
 Advisory: http://antisnatchor.com/dotcloud_beta_multiple_vulnerabilities
 Author: Michele "antisnatchor" Orru (michele.orru AT antisnatchor DOT com)
 Date: 20110328

I. BACKGROUND
DotCloud is a new managed IaaS aimed to create "mashups" of applications
ready-to-be-deployed.

II. DESCRIPTION
Multiple vulnerabilities have been identified in the web application
used to access the user API/SSH keys.

III. ANALYSIS
a. Open Redirection
The "next" parameter of the following URLs is vulnerable to Open Redirection:
http://www.dotcloud.com/account/create
http://www.dotcloud.com/account/login

To exploit Open Redirection on the first URL is enough to put a not
already registered email address
in the "email" parameter:

GET http://www.dotcloud.com/account/create?email=antisnatchor%40gmaill.com&password=antisnatchor123&password_confirm=antisnatchor123&invite_code=2x1hRF&next=http%3a//www.google.com
HTTP/1.1

The second one is present during the login action, so it's pre-authenticated and
this fact increases the security risk:

POST /account/login HTTP/1.1
Host: www.dotcloud.com
[...]
Content-Type: application/x-www-form-urlencoded
Content-Length: 87

email=antisnatchor%40gmail.com&password=antisnatchor123&next=http%3a//www.google.com

Open Redirection can be used for phishing purposes or
to execute malicious code on the victim behalf: it would be easy
for an attacker to exploit them to hook the victim browser to BeEF
and then redirect back the victim on the login page, while
logging their keystrokes with Javascript for example.

b. Credentials are sent in cleartext
No SSL certificates are used at all to protect sensitive informations
from eavesdropping attacks like MITM.

c. Sensitive form with autocomplete enabled
As can be seen in the login page:

<form action="/account/login" method="post" id="login-form" class="big">
    <fieldset>

    <p>
        <label for="email">Email Address</label>
        <input name="email" id="email" type="text" value="" tabindex="1" />
    </p>

    <p>
        <label for="password">Password</label>
        <input name="password" id="password" type="password" value=""
tabindex="2" />

the password form field don't have the autocomplete=off attribute in place.
This could lead an attacker to steal the credentials stored in the browsers
if having XSS in the next releases of the DotCloud webapp, or in this case
after exploiting the Open Redirection vulnerability.

d. Cookie without HttpOnly flag
Even if there are ways to bypass this security measure,
the HttpOnly flag should always be added to prevent
accessing the cookies from Javascript.

e. No anti-XSRF tokens on sensitive forms submissions
No unique tokens are added to sensitive forms to prevent
replay attacks like Cross Site Request Forgery.
At least the forms to change the API key and
the form to upload an SSH key should be protected
in this way, to prevent that in case of any XSS
that would be present in the next releases of the DotCloud webapp
things would't get worse.

IV. DETECTION

DotCloud current beta is vulnerable.

V. WORKAROUND

Redirects should not be controlled by users: build a server-side white
list of known-good
URLs where the redirect should point to, for example.

VI. VENDOR RESPONSE

Fixed from 14 March 2011.

VII. CVE INFORMATION

No CVE at this time.

VII. DISCLOSURE TIMELINE

20110307 Initial vendor contact
20110310 Initial vendor response
20110314 Vendor fixes issues
20110328 Public disclosure


VIII. CREDIT

Michele "antisnatchor" Orru'

IX. LEGAL NOTICES

Copyright (c) 2011 Michele "antisnatchor" Orru'

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without mine express
written consent. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please email me for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ