Skip to content

Commit

Permalink
Add files via upload
Browse files Browse the repository at this point in the history
  • Loading branch information
@aldaor
aldaor authored Apr 4, 2019
1 parent 017bfce commit 6378d9c
Show file tree
Hide file tree
Showing 10 changed files with 424 additions and 0 deletions.
76 changes: 76 additions & 0 deletions InsufficientSessionExpiration/216294.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
ReportLink:https://hackerone.com/reports/216294
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/tcpiplab
ReportedTo:Urban Dictionary(urbandictionary)
BountyAmount:
Severity:high
State:Closed
DateOfDisclosure:20.06.2017 8:20:00

Summary:

# Session replay vulnerability in www.urbandictionary.com

I considered titling this bug "*Session tokens not expiring*", which is what you need to tell your development team. But I titled it as I did to emphasize at least one attack made possible by the bug. There may be others.

## Description
Privileged functions, e.g., `/handle.save.php` can still be used after the user has clicked the "sign out" link. The cause of the vulnerability seems to be that the server is not invalidating session cookies when the user "signs out". I observed session tokens remaining valid even 72 hours after being issued.

Exploitation requires the anti-CSRF `authenticity_token` from the privileged page from before the victim "logged out", and any one of the victim's `_rails_session` cookies from before the victim "logged out". Note that because the server issues a new cookie with each Response, the attacker may choose from among many cookies.

## Impact
1. Cookies that never expire can impact the security of the user:
1. The user's session is susceptible to hijacking or replay.
1. The user has no way of causing the application to invalidate their session. This is important in shared computing environments.
2. Cookies that never expire can impact the security of the server:
1. The time window to brute-force a valid session token is increased.
1. If many session tokens remain valid, brute-forcing has that many more chances to guess correctly.

## Step-by-step Reproduction Instructions
1. Set up an HTTP intercept proxy like Burp Suite or ZAP.

1. Authenticate to `http://www.urbandictionary.com/users.php` via the Gmail OAuth function, receiving a valid session cookie from `www.urbandictionary.com`, and then "sign out" by clicking `http://www.urbandictionary.com/auth/logout`.

1. Send a `POST` request to `https://www.urbandictionary.com/handle.save.php` containing:
1. The `authenticity_token` from the privileged page from before the user "logged out".
1. Any one of the user's `_rails_session` cookies from before the user "logged out".
1. In the body of the POST set `user[handle]` to a new value. I've used `H.H. Vong`.
1. In the body of the POST set `commit` to `Save`.

{F171456}

The screen-shot above shows how to use Burp Repeater to replay a session and modify the user handle.

Here is that request as a curl command:

```
$ curl -L -i -s -k -X $'POST' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0' -H $'Referer: https://www.urbandictionary.com/handle.php' -H $'Content-Type: application/x-www-form-urlencoded' -b $'_rails_session=bnBaYnJjSjNJcmxGN1JrWjFkbmUwa0NFY05GdThtcmtHQU0zTHhsem1iQngyQmhvYUdKQTRCVmNHNlBGRTEvRm9aczFwRXc5ekVUV2FEVDM4RSswQU9rejBReGc1M3dxVGhRV0REQmFCUWFkYWcwQ1RhV2NIN1VUalQyM09tNHAwS3lkc0JaRlJqNkxKd2xNZVdKQzhYOFpBdlhqRHhoYVplWmczTFZBL3hlb3E2YUxkVmp4NEkzZUxtZXBQa1ozME9MUFdXRHRDQStOWXdUT2xkcTRSdz09LS1LNXVZWmFBL0F5STRIUjkwTmdnczR3PT0%3D--4ea5f8f5d73379881a6db43b9b8cdcc9d7c89773' --data-binary $'authenticity_token=C4EmquHAIijNq8UrFfbdfm%2B3Bp5RxvL1BpzMdf3%2FJgtw%2FSn%2FgTt4AlFlIDWFivaesfXJFgNqrWS8DD85obbnpA%3D%3D&user%5Bhandle%5D=H.H.+Vong&commit=Save' $'https://www.urbandictionary.com/handle.save.php'
```

1. The response will be a `302/Found` with the `Location` field set to `https://www.urbandictionary.com/users.php`. Your browser will follow the `302` redirect, issuing a `GET` request for the URL in the `Location` field. The server will respond with a `200/OK` status code.

{F171455}

The screen-shot above shows the Burp Repeater response with the rendered HTML displaying the successfully modified user handle.

If you're verifying this with `curl`, you could just `grep` for the modified value. Append this to the `curl` command previously specified: ` | grep -i vong`. Two lines of the HTML in the returned page will contain the newly modified handle:

```
<title>Urban Dictionary: Hello H.H. Vong</title>
<span>Hello H.H. Vong</span>
```

## Suggested Mitigation/Remediation Actions
1. Configure the server side application to invalidate a user's submitted session token:
1. When a new token is issued by the server side application, so that only one token is valid at any given time.
1. When the user submits a valid session token to `/auth/logout`.
1. When a valid session token has not been submitted to the server side application for greater than *n* seconds where *n* is some value consistent with your own internal policy.
1. When a valid session token, stored on the server, is older than *m* seconds, where *m* is the maximum age allowed for a session cookie, based on your own internal policy.

## Product, Version, and Configuration
* Kali Linux 2016.2
* Mozilla Firefox 45.7.0
* Burp Suite 1.7.17
* `curl` 7.52.1

Please let me know if you need more information about this issue. Thanks.
22 changes: 22 additions & 0 deletions InsufficientSessionExpiration/223327.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
ReportLink:https://hackerone.com/reports/223327
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/str33
ReportedTo:Weblate(weblate)
BountyAmount:
Severity:low
State:Closed
DateOfDisclosure:17.05.2017 14:24:34

Summary:

If an user changes his password, the session persists and new session ID won't be created.

POC -
1. Make any request and capture it using any proxy (burp)
2. Go to account settings and change the password.
3. Replay the captured request by changing any parameter(username or fullname)
4. You get a response saying our profile settings was updated.
5. When we view our profile, we can actually see that the changes have taken place.

Impact-
This has a fairly moderate impact as the session credentials are still in use even after password change.
37 changes: 37 additions & 0 deletions InsufficientSessionExpiration/250688.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
ReportLink:https://hackerone.com/reports/250688
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/sp1d3rs
ReportedTo:TTS Bug Bounty(tts)
BountyAmount:150.0
Severity:low
State:Closed
DateOfDisclosure:05.09.2017 19:47:58

Summary:

##Description
Hello. This issue is not very dangerous itself, but can be dangerous in combination of others (like XSS, or malicious access to the user account). The user/attacker, who got once valid cookie `federalist.sid` from the account, can use it as backdoor for some time, because it is not actually invalidated on Logout. Also, i discovered, that privilege escalation is possible (it is possible to attack another user account in some cases). Actually, logout just invalidating GitHub access token, but session still can be valid. How it can be used by attacker, or malicious user? Let's see the POC below.

##POC
Case 1. Using the flaw as BackDoor access to the account.
1) Login to the Federalist instance with your test account.
2) Save the `federalist.sid` cookie from the `/v0/me` endpoint using Burp or similar Web Debbuger.
3) Do logout.
4) Replay the request to the `/v0/me` endpoint using web debugger with same cookie. You will got 403 forbidden, as it should be.
5) Login with same account.
6) Replay the request to the `/v0/me` endpoint using web debugger with same cookie. You will got success response.
Case 2. Using the flaw (same session value) as BackDoor access to the account of another user.
Continue testing from the last step.
7) Do logout again.
8) Login with the second test account.
9) Replay the request to the `/v0/me` endpoint using web debugger with same cookie from previous steps. You will got success response, and info about users.

##Impact
Exploitation scenario.

Lets suppose, that some Federalist user worked on his PC, and did logout from Github and Federalist. It is supposed, that malicious user can't access his account without GitHub credentials. But, because `federalist.sid` was not invalidated properly, it is only a temporary restriction for the attacker. Let's suppose, that attacker somehow got `federalist.sid` cookie (using XSS, physical access to the PC, or attacker was previously the legit user, and saved cookie for the future access). He can't access the API just now, (as it throws 403), but he will can, when the login action will be performed on that PC again. Session will become valid, and, not matter, which user did the login! For example, if the second user logged in to the Federalist from different account, old `federalist.sid` will be assigned to him, and attacker's backdoor `federalist.sid` will work for the another account!
Sure the session cookie has limited lifetime, but still, insufficient invalidation can pose some risks.

##Suggested fix
1. The session cookie should be destroyed on user logout.
2. The new session cookie should be established on login.
30 changes: 30 additions & 0 deletions InsufficientSessionExpiration/272839.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
ReportLink:https://hackerone.com/reports/272839
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/wdem
ReportedTo:Unikrn(unikrn)
BountyAmount:40.0
Severity:medium
State:Closed
DateOfDisclosure:05.10.2017 16:03:13

Summary:

**Summary:** [Weak session id implementation]

**Description:** [Unikrn does not change session id after password is changed. Reusing same session ids, after password is changed is highly risky.
Example scenario: Hacker has successfully brute forced the password of a victim and has access to the account. The victim notices that something's off and chooses to change the password of the account. Hacker has still full access to the account, even after the password is changed, because of the working session id that he got from the server when he logged in to the victim's account.]


## Steps To Reproduce:

(Add details for how we can reproduce the issue)

1. [Intercept requests when logged in to unikrn and retrieve current session id]
2. [Change the password of the user]
3. [Do the step 1 again and compare the session id]

## Supporting Material/References:

If necessary, check my Proof of Concept video.

https://drive.google.com/file/d/0B28KqsVY5jK6aVdTYzg5RTNMcGM/view
21 changes: 21 additions & 0 deletions InsufficientSessionExpiration/273881.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
ReportLink:https://hackerone.com/reports/273881
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/nullsaint
ReportedTo:Automattic(automattic)
BountyAmount:
Severity:
State:Closed
DateOfDisclosure:09.11.2017 13:11:40

Summary:

Hi there,
I found broken session bug on your website.Your website is unable to validate the session.That may lead takeover victims account.

Reproduce:
1.Go to https://polldaddy.com and log into your account from two different browsers.
2.Now change password from any browser you already logged in
3.You will be still logged into another browser.

Kindly fix this issue.
Thx,
19 changes: 19 additions & 0 deletions InsufficientSessionExpiration/280585.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
ReportLink:https://hackerone.com/reports/280585
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/craxermgr
ReportedTo:Boozt Fashion AB(boozt)
BountyAmount:
Severity:medium
State:Closed
DateOfDisclosure:23.10.2017 10:00:09

Summary:

Your system does not change session id after password is changed. Reusing same session ids, after password is changed is highly risky.

Example scenario: Hacker has successfully brute forced the password of a victim and has access to the account. The victim notices that something's off and chooses to change the password of the account. Hacker has still full access to the account, even after the password is changed, because of the working session id that he got from the server when he logged in to the victim's account

To reproduce...
1. Login to your account
2. visit my profile and go to change password.
3. After changing the password, Your are still logged in,,..
73 changes: 73 additions & 0 deletions InsufficientSessionExpiration/293363.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
ReportLink:https://hackerone.com/reports/293363
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/gregoryvperry
ReportedTo:Uber(uber)
BountyAmount:
Severity:medium
State:Closed
DateOfDisclosure:24.12.2017 20:16:44

Summary:

## Summary
The Microsoft Store Uber App (Windows Phone Architecture) does not properly revoke or expire a rider's x-uber-token upon app signout.

## Security Impact
When a user logs out/signs off of the app, the logout process is handled only locally on the application side, and without any type of x-uber-token revocation or expiration at the Uber customer endpoint. This results in the x-uber-token still being active even after a user has logged out, giving an attacker the ability to access and/or modify all aspects of an Uber Rider's (and potentially Driver's) customer information.

## Reproduction Steps
1. Login using the Microsoft Store Uber App with an interception proxy to capture the session data. Make a note of the issued x-uber-token.
2. Logout of the Microsoft Store Uber App.
3. Using the Python POC code below, gain access to the Rider Dispatch View using the x-uber-token issued from Step 1 above:

-----

import requests

response = requests.get(
'https://cn-sjc1.uber.com/rt/riders/1ad0f5c1-1ac0-4c2c-a34a-36f267d7ae6f/dispatch-view',
headers={ 'accept-encoding': 'gzip, '
'deflate',
'accept-language': 'en; '
'q=1.0, '
'fr; '
'q=0.9, '
'de; '
'q=0.8, '
'zh-Hans; '
'q=0.7, '
'zh-Hant; '
'q=0.6, '
'ja; '
'q=0.5',
'charset': 'utf-8',
'user-agent': 'client/windows-phone/0.0.0.',
'x-uber-client-name': 'client',
'x-uber-client-version': '6.2.8',
'x-uber-device': 'windows-phone',
'x-uber-device-epoch': '1511637222701',
'x-uber-device-language': 'en',
'x-uber-device-location-altitude': '100',
'x-uber-device-location-latitude': '37.4291076516301',
'x-uber-device-location-longitude': '-77.5513191759734',
'x-uber-device-model': 'LENOVO '
'80TJ',
'x-uber-device-os': '10.0.16299',
'x-uber-token': '5ead9f1ab28780d48f8caa9d41a22973'}
)

print(response.text)

-----

## Specifics
* GregPerry804@gmail.com was the account used for this attack.
* All Uber customer endpoints used by the Microsoft Store Uber App will still accept a x-uber-token as valid, after the user has signed off/logged out of their Microsoft Store Uber App session.

## Impact

An attacker with access to a previously used x-uber-token, even after the user has logged out of the Microsoft Store Uber App, can still modify a rider's profile, access previous trip histories, schedule and/or cancel Uber driver dispatches, and access and/or modify stored payment information.

Driver functionality was not tested. If the Uber Driver role is also implemented within the Microsoft Phone Architecture Uber App, then all functionality encapsulated within the app as relates to driver functionality could be observed and/or modified as well.

Given the lack of certificate pinning in the Microsoft Store Uber App, this vulnerability is not theoretical and with x-uber-tokens easily harvested at public WiFi hotspots where the app is being used.
43 changes: 43 additions & 0 deletions InsufficientSessionExpiration/347748.txt
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
ReportLink:https://hackerone.com/reports/347748
WeaknessName:Insufficient Session Expiration
Reporter:https://hackerone.com/arjuniet
ReportedTo:Twitter(twitter)
BountyAmount:560.0
Severity:medium
State:Closed
DateOfDisclosure:26.06.2018 22:00:48

Summary:

> NOTE! Thanks for submitting a report! Please replace *all* the [square] sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!

**Summary:** Sessions are not properly logged out/ Information Leak

**Description:** I have two accounts that I control from my mobile Browser , As a concept of Session handling by browsers at a time one can only use one account with proper mapping of session and generated cookies . But when someone send DM or other data for my logged out account i still get web Notifications , where i can read the DM of that logged out account .
All the Testing is done on Chrome Browser of my phone , I have video for the same

## Steps To Reproduce:

(Add details for how we can reproduce the issue)

1. login with multiple accounts in Twitter one by one , saving your credentials for future
2. Enable web push notifications for twitter
3 now as a normal scenario login to one account and ask your friend to send you DM on
account other account which is not logged in
4 . you can see the DM in the android notifications for websites that saying notification for mobile.twitter.com and DM displayed

## Impact : session mishandling leading to my private data leak , on clicking the notification my cookies of one account is being taken with the request for other account

Moreover i am working on it , hope will help you to get your service better . please revert



## Supporting Material/References:

* List any additional material (e.g. screenshots, logs, etc.)

## Impact

1 .Session mishandling leading to my private data leak ,
2. on clicking the notification my cookies of one account is being taken with the request for other account
3 . information getting delivered even after the session isnt their can lead to privacy breach
Loading

0 comments on commit 6378d9c

Please sign in to comment.