Authorization Bypass mixed with XSS in GiftCards

One of my favourite findings in the bug bounty programs is the one I reported to GiftCards. Although big part of it was considered a duplicate report; however, it was beautiful.

GiftCards provides selling eGift cards online.



I played in the Group Gift Manager section



I started editing a gift that I have already created and a wizard started.



I played with the intercepted  HTTP request and I made two attacks at the same time



I put the id of a Gift belonging to another user and I put a script in the body of the Gift receiver info and then



The script worked in the Dashboard page of the owner of the edited Gift ID. The authorization bypass issue existed in several steps of editing Group Gifts.

GiftCards fixed the issue. Acknowledgement is over http://www.giftcards.com/acknowledgements 

Yahoo Flickr Cross Site Request Forgery Issue

I would like to publish a vulnerability that I have previously reported to Yahoo in Flickr application.

My target was Cross Site Request Forgery (CSRF) where a victim is deceived to send a forged request to the server. I noticed the old mobile web site  http://m.flickr.com . It had a button at the bottom to switch to the new mobile web site.  I stayed in the old one because it will be deprecated soon and will probably not be taken care of.

The mobile site allows uploading pictures and writing comments on pics. I checked on the HTTP requests responsible for such operations. After analysing the parameters of adding comments HTTP request, there is a token called "sig" which seems to protect from CSRF issues :-(  The other parameters are identifiers for the pic and the comment which are predictable and  can be filled by the attacker

I played with the parameter in a repeater to check if the server really validates on such parameter. I resent the request with a dummy value in the "sig" parameter.

The request worked and the comment was added successfully. The server did not validate on the token to check if the value of the sig parameter is correct.  There is a potential for CSRF :-). I just need to provide a PoC.

Assume that an attacker wants to deceive a flickr user to add a comment on the pic whose id is 11343386244

Attacker will need to host a form that submits the request to add the comment. The form could be something like the code below:

<!--Generate the form-->
<form id="f1"  method="post" action="http://m.flickr.com/photo.gne">
<input type="hidden"  name ="id" value="11343386244"/>
<input  type="hidden" name ="done" value="1"/>
<input  type="hidden" name ="comment" value="The victim did not make this comment"/>
</form>

<!--Submit it-->
<script>
document.forms["f1"].submit()
</script>

When the victim visits the page while being logged into flickr, a request will be sent from his browser to add the comment.

It will lead to adding a comment by the victim on the pic available on on https://www.flickr.com/photos/108957606@N06/11343386244/

My name is currently listed on Yahoo hall of fame list on http://bugbounty.yahoo.com/security_wall.html

Apple Insecure Cookie Issue

I was playing in Apple bug bounty and I found this URL  https://clearmater.apple.com/procurement/index.php/auth/register It is intended for suppliers to register and edit their information.

I started testing for security issues. I thought of  examining authentication and session management. I investigated the HTTP requests and responses  responsible for authenticating and setting the session cookie.

The response below is returned when a POST request is sent to the URL https://clearmater.apple.com/procurement/index.php/auth/login  in order to submit the user name and password

 .

The response sets the cookie "ci_session" without the security flag. This flag is important because it enforces the browser to send the cookie over SSL. If this flag is not set, we can have a session hijacking attack.

This is the attack scenario:

1- Victim user logins on https://clearmater.apple.com/procurement/index.php

2- Attacker deceives the victim into visiting the  URL over HTTP  http://clearmater.apple.com/procurement/index.php while sniffing on the victim's netwrok

3- This is what the attacker can see in his sniffer:

 The session id was sent in clear text HTTP because the browser was not enforced to send the cookie over HTTPS. Note that the response tried to redirect the user to the HTTPS page. But, it is too late. The attacker already got the authentication session id from the sniffed request.

 4-  Now, the attacker can just reuse the session id to hijack the session of the user. The screen below shows a request sent using a repeater while using a captured "ci_session" value. The result is a full access on the supplier information.

Apple fixed the issue and added my name to their hall of fame over http://support.apple.com/kb/HT1318. Apple's bug bounty page is available on https://ssl.apple.com/au/support/security/

Authorization Bypass in eBay Marktplaats

Marktplaats http://www.marktplaats.nl/ is a website owned by eBay that allows users to buy and sell products in addition to posting jobs.

The job management feature got my interest. I added a job and played with the job removal feature.

If you click on the remove link, a request like the one below will be sent

 When I pulled the trigger and tried to tamper the jobid to a jobid of another user that I created, it gave me authorization bypass error :-(

So, I  postponed my tampering and moved towards the next step in the job removal process. The next step was the delete confirmation:

 

When I clicked on the "Delete" button, I tampered the  jobid



 The server responded to me with

It was a 302 status that redirected me to the successful deletion page. We have a vulnerability :-)

This is the normal scenario the app was expecting:

  This is what the attacker can do



Marktplaats fixed the issue and sent me a token of appreciation. I was not rewarded because another researcher has already reported the vulnerability.

Marktplaats bug bounty rules link is on http://statisch.marktplaats.nl/help/responsible_disclosure_policy_en.html

Authorization Bypass in Google Orkut

I was playing with Google Orkut during the bug bounty. Orkut is  a social networking web site owned by Google  at www.Orkut.com

I  was investigating the robots file on www.orkut.com/robots.txt and I found something suspicious. I found a messages page although there  was no link in the web site that directs to such page.

I navigated to the page and it was functional.

I targeted such page because I thought that it was ignored and that it would contain security flaws. I started inspecting the delete message feature:

This was the request sent when deleting a particular message:

 The server reads the id passed in the "msg" parameter and deletes the message. I tried to abuse this feature and put an id of another user that I created.

The message was deleted :-)
 

I was so happy at the beginning before I realized that the message ids are not so predictable. :-(

Sample message id:
U0707254179/SB/0765222224/U0707254179

Sample message id for another user
U0707246461/SB/0765210864/U0707246461

This will make the vulnerability not exploitable. I thought of asking for help from Google to find a solution for this problem. I used the Google search :

site:orkut.com inurl:msg inurl:messages.aspx

It revealed messages ids in the URLs. Although such URLs will lead to 404 pages, they reveal  message ids which can be used by an attacker to  exploit such vulnerability :-).

Those message sections were also vulnerable the same way:
–    Unauthorized movement of messages between folders
–    Unauthorized marking of messages to be read/unread

Google fixed the issue immediately and  acknowledged me in their news feeds:

Google rewarded me and added my name to the rewarded hall of fame list :-)
https://www.google.com.eg/about/appsecurity/hall-of-fame/reward/

Google's bug bounty program is the best. The rules link is on https://www.google.com.eg/about/appsecurity/reward-program/

Stored XSS in Cisco Meraki

I would like to elaborate the stored XSS finding that I have reported to Cisco Meraki during the bug bounty program.

I was navigating Cisco Meraki  web site over https://meraki.cisco.com/. It enables administrators to manage their organization networks  over the web.

 

While  testing for XSS, I searched for places where data is inserted in a page and retrieved in another. I found the "Change log" section which enables the organization manager to  view configuration changes performed by administrators on the organization networks.

 

Each administrator should have access only to the network he manages in a certain organization . What if one of the administrators is evil and wants to execute malicious scripts in the page of the manager who has access to all networks in such organization? I thought about this risk and started to find a way to do it.

This is a way to do it:

I checked how the change log page is rendered. It displays the values of "Label", "Old Value", "New Value".  They represent the values entered by the administrator while changing a setting in a network. 

A variable called "changes"  in the "Change log" page holds these values. The function "make_change_log_table" reads the contents of the variable and displays the table:

 

<script type='text/javascript'>

    var changes = [{"new_text":"America - Belize","time":1365963215.47505,"category":"Network-wide settings","admin_name":"hassan","meraki_admin_change":false,"time_str":"Apr 14 18:13", "admin_email":"test@gmail.com", "network_url_tag":"abbas3", "label":"Local time zone","network_encrypted_id":"123HRcx", "network_name":"abbas3","old_text":"America - Los Angeles","ssid_name":null},....]
 ......

make_change_log_table(changes);

I wanted to enter malicious script in those values and see how they will be rendered. So, I visited a page where you can change a network configuration. An example page is the radio setting page:

When the admin clicks on the "Save Changes" button, a request is sent to the server having the parameter "settings_change_hash" which is filled with the new settings change in JSON format. 

This is a sample request:

POST /abbas5/n/DBR9eax/manage/configure/update_radio HTTP/1.1

Host: n23.meraki.com

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0

X-Requested-With: XMLHttpRequest

Content-Length: 318

Cookie:  registered=true; dash_auth=MO-dsPG4hdypf6ABCauH60MzelPo4hdnfTPG0Z9suIwdXqYug1ABCkqmjMVN4YYc2plL2334_OyzBFRFgkjw5q3Ouxk8Y5LwjO-b860DXY4CqyXAnDl84ozpVDDV2C-ASCka16EsAXObJYo9lU-1hxtuVn; _session_id=f8239db220b1280bcf42ab20bdeb6bd6; (referral)|utmcmd=referral|utmcct=/login/new_account

Connection: keep-alive

Pragma: no-cache

Cache-Control: no-cache

authenticity_token=28nABCvKbZ0lQWehVH%2Bn0a8sHABCbs2zPRgSoonQZbE%3D&node_group%5Bcountry_code%5D=DZ&node_group%5Btxpow_control%5D=off&radio_changes=&

settings_change_hash={"node_group[country_code]":{"label":"Country","new_text":"Algeria","old_text":"United States"}}

I intercepted such request and made my injection in the "label" value. I chose the "label" field because it was a hidden and filled secretly.  The app will probably trust it. So,  I filled the "settings_change_hash" parameter with the value:

 

{"node_group[country_code]":{"label":"Country<script>alert(document.cookie)</script>", "new_text":"Algeria","old_text":"United States"}}

When I visited the change log page, BOOM !!

 This is what happened.  The response returned in the following context:

<script type='text/javascript'>

    var changes = [{"new_text":"Algeria","time":1365961405.36341,"category":"Radio settings","admin_name":"hassan","meraki_admin_change":false, "time_str":"Apr 14 17:43", "admin_email":"test@gmail.com","network_url_tag":"abbas5", "label":"Country<script>alert(document.cookie)<\/script>" ,"network_encrypted_id":"DBR9eax","network_name":"abbas5", "old_text":"United States","ssid_name":null}

......

make_change_log_table(changes);

The script is properly escaped in the variable "changes". Note that </script> was replaced by <\/script> in the response.  However,  the function "make_change_log_table(changes)" read the contents of the "changes" variable  and rendered the value of the "label" item without escaping causing the script to execute. This issue was present only in the "label" value. It was trusted by the app and the result was a malicious script executing in the organization administrator page.

Cisco Meraki fixed the issue immediately and rewarded me.

Bug bounty program rules for Cisco Meraki is available on https://meraki.cisco.com/trust/#srp