Improper Authentication in snipe/snipe-it

Valid

Reported on

Aug 28th 2022


Description

There are two permissions not working correctly: The Licenses -> View and Modify License Files & the Self -> Create API Keys permission.

License Files

Files can be uploaded to licenses. There is a permission for users called View and Modify License Files. However, this permission is ineffective. A user without this permission is still able to access files uploaded to licenses as long as they have the View permission for licenses. Additionally, they can enumerate all uploaded files by simply incrementing the identifier for the file in the URL, since it is a simple counter.

Proof of Concept

Steps to reproduce:

1. Login as admin
2. Go to Licenses and create a new license with arbitrary values
3. Click on the License, go to File Uploads and Upload any 2-3 PoC files
4. Observe that the download links for the uploaded files are of the form `/licenses/<license_id>/showfile/<file_id>`. `file_id` increments for each additional file uploaded
5. Go to People and create a new user. Make sure to deny all permissions except for the `Licenses -> View` permission. In particular `View and Modify License Files` is denied, i.e. the user should not be able to view license files
6. Login as the newly created user, click on Licenses and click on the license created earlier. Note that a click on `File Uploads` does nothing
7. The URL should now be `/licenses/<license_id>`
8. Append `/showfile/3` to the URL and observe that the first uploaded file is downloaded
9. All files can be enumerated by incrementing the `file_id`

PoC Request from User with only Licenses -> View Permission:

GET /licenses/1/showfile/3 HTTP/1.1
Host: 127.0.0.1:8000
Connection: close
Cookie: snipeit_session=bFxcGzG8fZAfZvPFivACCT7XN9GXdYRBhrvLgZuh
Content-Length: 2

API Keys

A user can create API keys to authenticate to API endpoints. There is a permission called Create API keys, however, even users without this permission are able to create API keys, thus rendering the permission ineffective.

Proof of Concept

Steps to reproduce:

1. Login as admin
2. Go to People and Create a new User. Make Sure to deny all permissions. In particular `Self -> Create API keys` is denied, i.e. the user should not be able to create API keys
3. Login as the newly created user
4. Take note of the cookie `snipeit_session` and the `csrf-token` in the HTML head which is set in the response to `/account/view-assets`
5. Make the request to create an API key and observe that an API key is returned

API Creation Request (replace the CSRF Token and session cookie accordingly):

POST /oauth/personal-access-tokens HTTP/1.1
Host: 127.0.0.1:8000
X-CSRF-TOKEN: wqLZMfHIXhA8WdsJLmghGHird8AWlDYb8SeEIAIp
Content-Type: application/json;charset=utf-8
Connection: close
Cookie: snipeit_session=CAwxBX0UfnzSh4GD2mIASL0Fp2eoUegXBxOWRN3d
Content-Length: 38


{"name":"asd","scopes":[],"errors":[]}

The created API key is valid although the user does not have the permission to create API keys.

Impact

Users can access license files & create API keys without the corresponding permissions.

Occurrences

The permission check seems to be ineffective.

We are processing your report and will contact the snipe/snipe-it team within 24 hours. a month ago
We have contacted a member of the snipe/snipe-it team and are waiting to hear back 25 days ago
We have sent a follow up to the snipe/snipe-it team. We will try again in 7 days. 22 days ago
snipe/snipe-it maintainer has acknowledged this report 22 days ago
snipe validated this vulnerability 11 days ago

Hi there - thanks for this :)

Okay, there are two (kind of unrelated) issues here. The API auth stuff kind of doesn't matter TBH, since the API checks the individual gates on what a user can do via the API. If they have no permissions, they can't actually do anything with the API anyway, so while this is technically incorrect, the risk here is pretty small. Unfortunately, that /oauth/personal-access-token is built into Laravel itself which is why it exists outside of our normal gating system.

I think in order to truly remediate this, we'd need to override the built-in Laravel magic here.

For the file access stuff, you're 100% right - I've got a fix on deck that I'm testing now. (I think these probably should have been two different Huntr issues, since one is effectively exploiting a session replay, versus a missing gate. The enumeration part kinda doesn't matter, since we don't restrict access on a file by file basis, just by the license itself.

You did actually miss one thing tho, which I discovered as I was testing 😬😬 We're not actually checking against full company support - which means:

  • IF you have full company support enabled AND
  • IF you have a (non-superadmin) user that can view license files
  • We are NOT actually checking that the license file belongs to a license that belongs to a company the user is allowed to see. We're skipping the "companyable" step entirely 😬

So that's fun.

Anyway, we're till working on this. I should have something for you this week.

Best regards, Snipe

vautia has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
We have sent a fix follow up to the snipe/snipe-it team. We will try again in 7 days. 8 days ago
snipe confirmed that a fix has been merged on dcab13 7 days ago
snipe has been awarded the fix bounty
to join this conversation