huntr.dev Open in urlscan Pro
2600:9000:223d:a600:14:bb32:5f00:93a1 Public Scan

Back to summary

URL:
https://huntr.dev/bounties/6d8ffcc6-c6e3-4385-8ead-bdbbbacf79e9/
Submission: On September 21 via api (September 21st 2022, 6:48:35 pm UTC) from US — Scanned from DE

Form analysis
0 forms found in the DOM

Text Content

huntr
Open menu
/
Bounties Community More

Responsible disclosure policy

FAQ

Hacktivity

Leaderboard

Submit report Login

Logout

huntr
Close menu
/

--------------------------------------------------------------------------------

Bounties
Find your next target
Submission
Submit a report
Hacktivity
Browse public reports
Leaderboard
Our leaderboard

--------------------------------------------------------------------------------

Policy FAQ Contact us
Login

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

ProfileController.php L82-L101

The permission check seems to be ineffective.

REFERENCES

* CWE-287 - Improper Authentication

We are processing your report and will contact the snipe/snipe-it team within 24
hours. 24 days ago
We have contacted a member of the snipe/snipe-it team and are waiting to hear
back 23 days ago
We have sent a follow up to the snipe/snipe-it team. We will try again in 7
days. 20 days ago
A snipe/snipe-it maintainer has acknowledged this report 20 days ago
snipe validated this vulnerability 10 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. 7 days ago
snipe confirmed that a fix has been merged on dcab13 5 days ago
snipe has been awarded the fix bounty
ProfileController.php#L82-L101 has been validated
Sign in to join this conversation
CVE ID

CVE-2022-3173 (published)
Vulnerability Type
CWE-287: Improper Authentication
Severity
Medium (4.3)
Registry
Other
Affected Version

6.0.10

Visibility
Public
Status
Fixed

Found by

vautia
@vautia
legend

Fixed by

snipe
@snipe
maintainer

This report was seen 242 times.
We are processing your report and will contact the snipe/snipe-it team within 24
hours. 24 days ago
We have contacted a member of the snipe/snipe-it team and are waiting to hear
back 23 days ago
We have sent a follow up to the snipe/snipe-it team. We will try again in 7
days. 20 days ago
A snipe/snipe-it maintainer has acknowledged this report 20 days ago
snipe validated this vulnerability 10 days ago

Hi there - thanks for this :)

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

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:

So that's fun.

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

Best regards, Snipe

2022 © 418sec

HUNTR

* home
* hacktivity
* leaderboard
* FAQ
* contact us
* terms
* privacy policy

PART OF 418SEC

* company
* about
* team

Chat with us

huntr.dev Open in urlscan Pro 2600:9000:223d:a600:14:bb32:5f00:93a1 Public Scan

Form analysis 0 forms found in the DOM

Text Content

huntr.dev Open in urlscan Pro
2600:9000:223d:a600:14:bb32:5f00:93a1 Public Scan

Form analysis
0 forms found in the DOM