Comelec Hack: 2013, 2016 and revelation of #pr.is0n3r

Original Post: https://www.facebook.com/notes/clifford-trigo/comelec-hack-2013-2016-and-revelation-of-pris0n3r/1001530523228999

Many of you may not know that the Commission of Election website (
www.comelec.gov.ph) became a target by Anonymous Philippines led by a user with handle #pr.is0n3r before the 2013 general election.
During that time a video was published by the same user, mainly giving “COMELEC” a warning of possible electoral fraud. Allegedly, PCOS machines can be tampered and CF cards can be manipulated.
Watch:
https://www.youtube.com/watch?v=xXl3LMjug-k 

The end part of the video showed the COMELEC website being penetrated using SQL injection. Data was extracted from the COMELEC Database wherein it appeared to be also downloaded locally.
Do you think Comelec is seriously securing your personal information?
I have tried to reach the user behind the handle pr.is0n3r and asked him if he still has access in the comelec website, he replied with revelations. According to him:
  • In 2013, before he got access to COMELEC’s server, somebody had an uploaded web shell already. Guess who? Our friendly neighbor – China. ( The same with Banko Sentral ng Pilipinas )
  • The last time he had access was after the 2016 defacement.
  • About 5 critical vulnerabilities can be exploited in the website.
  • He is 99% sure he can access the website once it’s up again.
  • He is most concerned of the government being unaware that we are already infiltrated by foreigners and only react to the latest defacement/leak. …”hindi nila alam na hacked na sila matagal na ng taga ibang bansa. Na gather na nila ang info natin sir matagal na. Hindi lang nag rereact ang mga chinese hackers, yun ang nakakatakot dahil tahimik sila at we dont know ano ang plans nila.”

additional information by #pR.is0n3r in Anonymous Philippines page.

Comelec Hack 2016

Late Sunday night of March 27, 2016 – Anonymous Philippines struck again by defacing the comelec website. The hacktivists also provided a video with similar message to the 2013 version. https://www.youtube.com/watch?v=cTJjMTnEJdE
The difference between the two is that the 2016 version showed hackers gaining root privileges by leveraging what appears to be an XPath injection vulnerability.
Hours later that defacement, a hacker group calling themselves as Lulzsec Pilipinas claimed to have compromised the comelec site as well then accessed and dumped its Database over the web. That’s 300+GB of compressed data.
An investigative report by Trendmicro said the leaked database contained a huge number of sensitive personally identifiable information (PII).
Comelec doesn’t seems to take serious security measures, even displaying sensitive info in plain text!
After the 2013 attack, COMELEC should have known and expected the possibilities of being hacked again. And yet, they seem to not care at all.
In the case of recent hacking incident, COMELEC should have filed a report to National Privacy Commision in which they didn’t. Why? Do they really value protecting our sensitive info – the Filipino people? They have failed us.

Paul Biteng

A friend of mine, Paul Biteng was nabbed by NBI agents in his house last Wednesday night. He was tagged as suspect of the latest defacement, where media reports said he admitted but not of the database leakage.
For the information of everybody, I and Paul along with our friends at Invalid Web Security are active participants of bug bounty programs.
We strongly believe Paul is not part of the database leakage. We are standing behind him through all of this.
Whatever is being uploaded on the web will always be on the web. ask wehaveyourdata.com!

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).

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

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:

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

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!  :)

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.

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.