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