Dear Maintainers,
I hope this message finds you well. I am writing to you on behalf of the Intel Product Security Incident Response Team (PSIRT). We have identified a potential vulnerability in one of your products and would like to report it to you for further investigation and mitigation.
As part of our commitment to responsible disclosure and in alignment with ISO/IEC 29147 and 30111 standards for vulnerability handling and disclosure, we aim to work collaboratively with you to address this issue.
We have evaluated the potential vulnerability report for completeness. The vulnerability report is attached to this report for your review. Kindly acknowledge receipt of this report within 30 days via [email protected].
We expect that any impacted vendors will mitigate and disclose the potential vulnerabilities within a reasonable, agreed-upon time period. We look forward to your prompt acknowledgment and to working together to address this potential vulnerability. Should you have any questions or require further information, please do not hesitate to contact Intel PSIRT via [email protected].
Best regards,
Intel PSIRT
Summary
An authenticated user can exploit the Insecure Direct Object Reference (IDOR) vulnerability that may lead to unauthorized cross-tenant access (list tenant user accounts, add user account into other tenant)
Details
Unauthorized cross-tenant access: list user from other tenant (e.g., via GET /<tenant_id>/user/list), add user account to other tenant (POST /<tenant_id>/user).
PoC
Issue visible from code review analysis (https://github.com/infiniflow/ragflow/blob/main/api/apps/tenant_app.py) – code does not verify that user who send the request has relationship with <tenant_id> provided in URL and just use provided tenant_id to retrieve information from the backend.
Method UserTenantService.get_by_tenant_id (source code https://github.com/infiniflow/ragflow/blob/main/api/db/services/user_service.py) does not provide any additional validation or filtering.
As a result is it possible to provide another tenant_id and retrieve information from another tenant (broken access control).
To dynamically check it for GET request, you may follow the following steps:
- Sign-up into application with [email protected] email.
- Sign-in with created [email protected] account and obtain tenant_id – it can be captured via browser DevTools by inspecting JSON response on GET https:///v1/user/tenant_info (“tenant_id” filed) – let’s call it tenant1
- Using UI (“Profile” -> “Team” -> “Invite”) – invite another testing account into tenant 1
- Logout from tenant 1
- Sign-up into application with another email- [email protected] email.
- Sign-in with created [email protected] account and invoke (e.g. using BurpSuite) the following APIs using tenant1 id captured in step 2
Configuration/Testing Information to Aid in Understanding the POC
Environment described in https://github.com/infiniflow/ragflow?tab=readme-ov-file#-launch-service-from-source-for-development
Also, this security issue theoretically can be observed on demo environment available in https://demo.ragflow.io/
###Mitigation
To mitigate this issue, at the source code level it is necessary to validate provided untrusted <tenant_id> parameter - check that user, who sent request (this data available via current_user.id) belongs to provided <tenant_id> and reject request if user is not belong to tenant.
This validation shall be implemented for the following endpoints:
• GET /<tenant_id>/user/list"
• POST /<tenant_id>/user', methods
• DELETE /<tenant_id>/user/<user_id>
• PUT /agree/<tenant_id>
Also, for reference similar issues with similar CVSS and attack vector:
• https://huntr.com/bounties/c01e0c7f-68d8-45cf-91d2-521c97f33b00
• https://huntr.com/bounties/afecd927-b5f6-44ba-9147-5c45091beda5
Infiniflow_Ragflow issue.pdf
This was found by Intel employees. Please acknowledge Alexander Barabanov as the finder.
AlexanderBarabanov Reporter
Dear Maintainers,
I hope this message finds you well. I am writing to you on behalf of the Intel Product Security Incident Response Team (PSIRT). We have identified a potential vulnerability in one of your products and would like to report it to you for further investigation and mitigation.
As part of our commitment to responsible disclosure and in alignment with ISO/IEC 29147 and 30111 standards for vulnerability handling and disclosure, we aim to work collaboratively with you to address this issue.
We have evaluated the potential vulnerability report for completeness. The vulnerability report is attached to this report for your review. Kindly acknowledge receipt of this report within 30 days via [email protected].
We expect that any impacted vendors will mitigate and disclose the potential vulnerabilities within a reasonable, agreed-upon time period. We look forward to your prompt acknowledgment and to working together to address this potential vulnerability. Should you have any questions or require further information, please do not hesitate to contact Intel PSIRT via [email protected].
Best regards,
Intel PSIRT
Summary
An authenticated user can exploit the Insecure Direct Object Reference (IDOR) vulnerability that may lead to unauthorized cross-tenant access (list tenant user accounts, add user account into other tenant)
Details
Unauthorized cross-tenant access: list user from other tenant (e.g., via GET /<tenant_id>/user/list), add user account to other tenant (POST /<tenant_id>/user).
PoC
Issue visible from code review analysis (https://github.com/infiniflow/ragflow/blob/main/api/apps/tenant_app.py) – code does not verify that user who send the request has relationship with <tenant_id> provided in URL and just use provided tenant_id to retrieve information from the backend.
Method UserTenantService.get_by_tenant_id (source code https://github.com/infiniflow/ragflow/blob/main/api/db/services/user_service.py) does not provide any additional validation or filtering.
As a result is it possible to provide another tenant_id and retrieve information from another tenant (broken access control).
To dynamically check it for GET request, you may follow the following steps:
Configuration/Testing Information to Aid in Understanding the POC
Environment described in https://github.com/infiniflow/ragflow?tab=readme-ov-file#-launch-service-from-source-for-development
Also, this security issue theoretically can be observed on demo environment available in https://demo.ragflow.io/
###Mitigation
To mitigate this issue, at the source code level it is necessary to validate provided untrusted <tenant_id> parameter - check that user, who sent request (this data available via current_user.id) belongs to provided <tenant_id> and reject request if user is not belong to tenant.
This validation shall be implemented for the following endpoints:
• GET /<tenant_id>/user/list"
• POST /<tenant_id>/user', methods
• DELETE /<tenant_id>/user/<user_id>
• PUT /agree/<tenant_id>
Also, for reference similar issues with similar CVSS and attack vector:
• https://huntr.com/bounties/c01e0c7f-68d8-45cf-91d2-521c97f33b00
• https://huntr.com/bounties/afecd927-b5f6-44ba-9147-5c45091beda5
Infiniflow_Ragflow issue.pdf
This was found by Intel employees. Please acknowledge Alexander Barabanov as the finder.