Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guessable recordIDs allow access to past and future room recordings #9443

Open
defnull opened this issue May 6, 2020 · 12 comments
Open

Guessable recordIDs allow access to past and future room recordings #9443

defnull opened this issue May 6, 2020 · 12 comments

Comments

@defnull
Copy link
Contributor

@defnull defnull commented May 6, 2020

Describe the bug
Some front-ends (e.g. greenlight) implement persistent and configurable "rooms" and re-use the same meetingID for all meetings created for that room. This results in predictable internalMeetingID and recordID values (sha256(meetingID) + '-' + epoch_seconds). Any user that joined the room at least once, or got a presentation link, knows the static part of the recordID and may be able to guess the correct timestamp to find past or future recordings from the same room.

For the user, it may not be obvious that using a room for more than one meeting or sharing a single presentation link might expose all past and future recordings from the same room. Probing presentation links does not require a login and is not rate-limited. Knowing the rough starting time of a meeting helps to quickly get results. All front-ends that rely on the secrecy of meetingIDs (e.g. greenlight) to protect 'unlisted' recordings are affected.

I initially reported this as a Greenlight issue (see bigbluebutton/greenlight#1466) but other frond-ends may be affected as well. @farhatahmad commented that this could more easily be fixed in BBB directly. For example, by randomizing the generation of internalMeetingID and/or recordID (or at least the guessable per-meeting suffix).

To Reproduce

  1. Join a Meeting in Greenlight and watch the API traffic a bit, or wait for someone to share a presentation link. Extract the internalMeetingID/recordID.
  2. Increment or decrement the timestamp in the recordID to find other recordings from the same Greenlight room.
  3. ...
  4. Profit

Expected behavior
RecordIDs should be hard or impossible to guess. Users should not be able to access recordings they do not have a presentation link for.

Actual behavior
Nosy users may be able to guess valid presentation links.

@defnull
Copy link
Contributor Author

@defnull defnull commented May 6, 2020

Why this is also a BBB issue and not only a front-end issue: If a meeting is recorded, the presenter/moderator should be allowed to assume that participants cannot access recordings until a presentation link is shared. Looks like this is not the case, though. Joining the meeting exposes the internalMeetingID and thus the (future) recordID. This effectively allows any participant, even guests, to access the recording without authorization. No guessing involved.

@ichdasich
Copy link

@ichdasich ichdasich commented May 7, 2020

Throwing in https://github.com/ichdasich/bbb-rec-perm here as an example how to add auth again (was in greenlight/#1466); The auth callback could also re-authenticate against GL with further restrictions if combined with BASIC.

@ichdasich
Copy link

@ichdasich ichdasich commented Jun 20, 2020

So, I also implemented auth against GL (extensible, technically, to $whatever).

Question is, whether it would make sense to pull the auth-hooks into BBB base?

@matiasilva
Copy link
Collaborator

@matiasilva matiasilva commented Jun 20, 2020

Could you give us a demo so we can see it in action?

@ichdasich
Copy link

@ichdasich ichdasich commented Jun 23, 2020

Passwordless bbb-rec-perm (deny access to private recordings, only allow access to public/unlisted recordings, default to private) is in production on https://bbb.surfcloud.nl/ ; Registration is open, please feel free to take a test-ride.

I have an instance with the password based auth running on a dev-vm on my workstation: https://bbb.home.aperture-labs.org/

Caveat: The dev VM only runs between ~0900 and ~0100 UTC. Apart from that, registration is open; again, please feel free to give it a test-run.

Settings for the auth-script are:
Public - No auth & listed
Unlisted - All users with a GL account
Private - Only owner + shared

@ichdasich
Copy link

@ichdasich ichdasich commented Jun 24, 2020

@matiasilva can you let me know when you folks at blindisght had your demo so I can take the VM out of autostart?

@matiasilva
Copy link
Collaborator

@matiasilva matiasilva commented Jun 24, 2020

I'm flattered, but like you I'm just another interested volunteer. Feel free to take it out, I've tested it and taken my observations :)

@ichdasich
Copy link

@ichdasich ichdasich commented Jun 24, 2020

kk, took it down. Just assumed you were with blindsight due to some rather authoritative comments in other tickets. :-)

@stale
Copy link

@stale stale bot commented Jul 31, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Jul 31, 2021
@ichdasich
Copy link

@ichdasich ichdasich commented Jul 31, 2021

So... Greenlight now has some depublishing mechanic going... but for published recordings this remains pretty much recent, no?

@stale stale bot removed the status: stale label Jul 31, 2021
@stale
Copy link

@stale stale bot commented Apr 27, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Apr 27, 2022
@TheJJ
Copy link

@TheJJ TheJJ commented May 13, 2022

record ids are not randomizable yet -> not solved

@stale stale bot removed the status: stale label May 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants