Author: trizaeron

by trizaeron on Privilege Escalation

Hijacking SmartSheet accounts via “Import Users”

Update:
From DJ Hanson at Smartsheet

Speaking as Director of Information Security @Smartsheet, we are grateful to Mr. Trigo for his continuing research on our platform, and the professional manner in which he conducts his responsible disclosure practices. The nature and pattern of this particular issue is such that we are able to conclude that this vector was never exploited by anyone other than Mr. Trigo, working against two accounts under his direct control. Within 4 hours of being made aware of this, our security, operations, quality assurance, and development teams deployed an update to our platform, eliminating the flaw.

We can unequivocally state that there was no disclosure or impact to any customer accounts or data. It is our view that openly rewarding and celebrating the findings of well-intentioned researchers is an essential part of a healthy and mature security program. We have been very impressed with the work and quality of the researchers @Bugcrowd and hope to continue our relationship with them and their community of professionals.

Hi everyone!

This blog post is about the vulnerability I found in Smartsheet.com as part of its private bug bounty program via Bugcrowd. The bug lies in the “import users” feature of Smartsheet which allows anyone with malicious intent to hijack and fully take over millions of Smartsheet accounts.

About Smartsheet:

As according to its website, Smartsheet is a “Software as a Service” (SaaS) company which offers enterprise-ready cloud app for work management and collaboration. The company  states that it has 65,000 businesses and millions of users in over 175 countries.

About and how I found the Bug:

The bug is clearly an insecure direct object references which again, allows anybody to hijack Smartsheet accounts without user interaction.

It was my first time to be invited in a Bugcrowd private program so I decided to give it a try. The time of launch is 1600 GMT on April 7 this year – that is 12:00 AM here in the Philippines.

As part of my testing methodology, access control vulnerabilities are the first on my lists. I registered two (2) accounts for testing purposes where account 1 served as the attacker while the other is the victim account.

On browsing the Smartsheet Dashboard, I observed that it allows you to Import Users in “User Management” page – Account administration. It was the erring page.

import users smartsheet

In the import process, you need a csv file and set up it with columns First Names, Last Names and Email. What was interesting  is that you can also pre-select roles for the account to be imported.

The roles are:

  1. licensed user ( can create and own sheets )
  2. system admin ( can manage users and accounts )
  3. group admin ( can create and edit groups )
  4. resource viewer ( can access resource views )

During my testing, I imported a csv file with my controlled user details ( email address ) against my victim account and was given all permissions. The import was successful, and I had verified there was a bug in the “import user” feature/section.

Bug Technical Details:

The flaw resides in /b/uploadimport endpoint. While processing the POST request, it actually has multiple parameters but what caught my attention is the value of parm1, which is my user id (1071208).

[sourcecode language=”plain”]POST /b/uploadimport HTTP/1.1
Host: app.smartsheet.com
Connection: keep-alive
Content-Length: 1009
Origin: https://app.smartsheet.com
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Content-Type: multipart/form-data; boundary=—-WebKitFormBoundaryQX3fAkoAQI8uwbiZ
Accept: */*
Referer: https://app.smartsheet.com/b/home
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,fil;q=0.6,zh-TW;q=0.4
Cookie: redacted

fa_importOrgUsers
——WebKitFormBoundaryQX3fAkoAQI8uwbiZ
Content-Disposition: form-data; name="parm1"

1071208
[/sourcecode]

You only need to change the value of that parameter to your target account ( I used burp proxy during the testing ).

You will get a 200 OK response:

[sourcecode language=”plain”]HTTP/1.1 200 OK
Server: Apache
Vary: X-Forwarded-For,Accept-Encoding
x-smartsheet-instance-id: nominal.ss-app-1609
Cache-Control: max-age=0
Cache-Control: no-cache
Cache-Control: must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Length: 22
Connection: close
Content-Type: text/plain;charset=UTF-8
[/sourcecode]

It became possible because there was no check whether the user who is requesting the import has the the right privilege.

Below is the full HTTP request:

Steps to Reproduce (modified, used in my actual submission):

(Two accounts are needed, account 1 as attacker and account 2 as victim)

  1. Authenticate your attacker account
  2. Click on ” Account ” Menu in the left side of the screen
  3. Another form will pop up, click on ” User Management ” then ” Import Users”
  4. Select your excel file with user details, controlled email address
  5. Tick on admin permissions 1,2,3,4 for full permission of our account to be imported.
  6. Before hitting import, fire up your intercepting proxy ( Burp )
  7. Hit the import button now and you will see the request just like above
  8. Change the value of parm1 which is 1071208 to your victim – target account
  9. Forward the request
  10. A verification email will be sent to our imported – attacker controlled email, follow the link in the email
  11. Exploit successful.

Smartsheet fixed the vulnerability and awarded me the maximum bounty in its program – $2,000.

Thank you Smartsheet for the permission to disclose this bug!  :)

by trizaeron on XSS

Square Bug Bounty – XSS

Two weeks ago, Square launches its own bug bounty program that rewards external security researchers starting from $250, no maximum bounty reward is stated though.

I reported a couple of bugs but most of them were tagged as duplicated. As of the moment, I earned just $750.

Now, I’ll be sharing 2 XSS in Square’s appointments.

Square Appointments is a new online tool by Square to provide simple booking experience that lets businesses manage appointments, save time and avoid losing sales from customers.

The tool is actually announced publicly by Square, few days after it announced its bug bounty program. I accidentally stumbled upon an article of the news while searching about Square, in connection to mapping my program target – Square Inc.

Simple XSS in setting up business website:

In Square Appointments’ setting, public profile, you are asked to provide your business website.

square up biz profile

I input javascript:alert(document.cookie) in business website field and submit.

public profile square up

That escalated quickly! There is no error upon saving my business field set up as javascript:alert(1). The javascript vector executes upon clicking the business site link located at the bottom right side of my booking site.

Bypass the Client Side block for XSS execution!

Pretty easy right? I thought of testing the other input fields, the Facebook profile and the Twitter username.

Tested the same vector now, javascript:alert(document.cookie) but it ends up caught on client-side error – not Facebook and or Twitter URLs!

Did you notice it? I mentioned of client-side error, It could meant, the server was not doing the same way!

So, for the bypass and served as Proof of Concept ( POC ):

1. Go over to https://squareup.com/appointments/business/profile
2. Input https://www.facebook.com/sample in the Facebook Profile field and https://twitter.com/sample in the Twitter URL field.
3. Click on Save ( You must have intercepted the request, I use BURP )
4. Modify the URLs for Facebook and Twitter inputted on the fly, as for me I changed it to javascript:alert(/forFacebook/) and javascript:alert(/forTwitter/) respectively.

for_facebookIt executes upon clicking the social media icons in the “Share” menu.

Saved! We bypassed it by modifying our request on the fly changing the social media URLs to our vector.

For information, the block is only in the client side and does not happen on the server side, it must be on both. Client side blockage can be trivially bypassed.

Unfortunately, even those bugs are both valid there was no reward issued since its tagged as duplicated. Here is what the Square security team stated.

Note: The XSSs are fixed now!

frans rosen - idol

 

You may want to visit my Hackerone Profile, www.hackerone.com/trizaeron.

by trizaeron on Authentication

Security vs Usability – Reauthentication

I am one of those reporters that always point out the need of re authentication when it comes to sensitive and confidential settings. What I am up, is the company to implement re authentication on such.

Of course on a password change page, a re authentication is necessary – that is providing the current password. But, on other actions such as email address change and or deletion of an account ( depending of how the application works ) some people are just ignoring the risk.

The two scenarios I can think where this becomes applicable is when:

  1. Attacker manages to hijack an account ( Via XSS )
  2. A computer that is left open

Would you leave the security of your application with usability? The risk of an account being taken over ( email address change ), credit card leakage, and other confidential settings you can think of.

I believe, security weighs over usability on such cases. Yes, it may hamper the usability of your application(a bit ) but it increases your customer security.

Hope this helps you, an add-on in your bug report methodology.