Skip to content

Prezi Bug Bounty

November 11, 2013

Vulnerability Reported:

SSL Not Enforced for web service calls made from the Prezi Desktop application

SSL is not enforced on some web service calls made between the Prezi Desktop application and the server.

  • The authentication from the Prezi desktop application happens over HTTPS as expected.
  • As soon as the user is authenticated, the server assigns a session cookie ‘prezi-auth’ and sets in the response header. An important point to note here is that there is no ‘Secure’ flag on this cookie. As per Prezi folks, they said the site is not fully functional over HTTPS as of now and hence there is no secure flag. This makes sense not implementing the secure flag. However, this introduces further risks as I will discuss below.
  • Once the authentication is done, the Desktop application makes some web service calls over HTTPS. This can be verified by setting up a proxy and having the traffic from Internet Explorer go through the proxy. Now, since SSL is not being enforced here, by simply replacing the HTTPS with HTTP yielded valid responses. And, since the session cookie ‘prezi-auth’ did not have a secure flag, this was visible over HTTP.

You may ask so what? Isn’t that how the system is designed? Isn’t it just the web service calls where you are just retrieving information (that might not be sensitive enough)? What can an attacker possibly do intercepting the HTTP traffic? All these are valid questions. And, yes till now, it is not that high of a risk.

But, taking it one step further, if an attacker can intercept this traffic and capture the ‘prezi-auth’ session cookie, he could then use this value to impersonate the prezi user on the web application too. And, by doing that, the attacker has complete access to the prezi user’s account where he could update profile information, create prezi’s and do everything that a normal prezi user can.

 

Summary:

There is an option where you can implement HTTPS throughout the web application and once you do that, all the requests over HTTP are redirected to HTTPS. So, essentially, SSL is enforced on the web application but not on the Desktop application. And, because of this, by using the session cookie from the Desktop application, an attacker can potentially gain complete control of the prezi user’s web application account.

Some web services where SSL was not being enforced:

http://prezi.com/api/token/objectlibraryservice/list/
http://prezi.com/backend/conversion/urlconv/desktop/
http://prezi.com/backend/upload/token/desktop/
http://prezi.com/api/token/objectlibraryservice/list/
http://prezi.com/api/token/themeservice/list/
http://themeservice.prezi.com/theme/user/
http://objectlibrary.prezi.com/object/user/

 

Attack Scenario:

1. A prezi user opens the Desktop application and logs in. He is assigned a “prezi-auth” session cookie by the server. This is over HTTPS which is fine. Also assume that an attacker is eavesdropping on this network and can see any requests/responses being transmitted over HTTP.

2. Attacker sends an email to the prezi user with a link which auto-submits a POST request on the user’s behalf to the URL http://prezi.com/api/token/objectlibraryservice/list/. Note that this is meant to be over HTTPS but the attacker is making the user go to the HTTP link. Since, SSL is not enforced, this request will be successfully processed by the server.

NOTE: You can consider this like a CSRF attack or tricking the user in order to click a link and send a request to the server over HTTP. I am sure there can be other avenues where a user can be tricked to do this. It doesn’t have to be a CSRF attack vector. I am considering CSRF here just for the sake of it and a PoC. Also notice that there are no CSRF tokens present either in the header or in the POST body of this request which makes it even easier.

3. Now, the attacker eavesdropping sees this request over HTTP and he can capture the “prezi-auth” session cookie. This cookie should really have the Secure flag to avoid this but since it does not have the secure flag, this value will be transmitted over HTTP since the user is logged in his Prezi account.

4. The attacker can then use the captured prezi-auth session cookie and impersonate the user in the web application.

 

Screenshots:

ssl not enforced on webservices

 

A valid response is received when a request is sent over HTTP. Notice that I had the SSL option enabled in the website.

impersonating the user

Sending a request to the web application at the URL /settings/ with just the captured ‘prezi-auth’ session cookie yielded the profile page of the prezi user account

Prezi’s Response:

They said it was a nice finding but since the site is not fully over HTTPS, they cannot give me a bounty. But, they will send me some swag. I agree with them and it is up to their discretion to judge this. I am happy with the token of appreciation in form of tshirt, sunglasses, etc. Something is better than nothing.

 

Advertisements

From → Security

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: