Credit card statement disclosure vulnerability in Viseca's eXpense portal
As a security company we try to use services that are solid, trustworthy and secure and therefore we do our due diligence if we find the time for it. Checking products for IT security issues in a non-intrusive way is a part of that. You can call it supply chain security if you like.
To avoid scanning credit card paper statements sent by snail mail every month, Pentagrid was looking for an option to receive them electronically. For our bank though, the only option was to sign up for Viseca's eXpense platform, which allows access to business credit card statements in PDF format. However, uppon login into the portal for the first time, our experienced analyst's gut feeling told us something is not right. For example, the second-factor authentication when doing a login on the eXpense platform was simply typing the last four digits of our telephone number. And that's definitely not state-of-the-art security.
We decided to have a quick look. Our experience in web application security analysis told us that the download function for PDF statements was a good candidate to have a look at. We've seen this kind of functionality fail in many applications before. You may guess, what happened.
Approach
Before signing up to Viseca's eXpense platform, we noticed that Viseca provides a demo account for a login into the eXpense platform publicly on their website.
When using the "demo" login credentials for Viseca's eXpense portal, Pentagrid was able to access the platform and then download Pentagrid's own credit card statement.
After we found this security issue, we immediately started our Coordinated Disclosure process and tried to contact Viseca's Chief Information Security Office (CISO). We sent the first draft of vulnerability details on the following day (see timeline below).
Later on we realised that logging into demo account wasn't even necessary, knowing the URL was sufficient. The identified security issue was therefore missing authentication as well as a standard Indirect Object Reference (IDOR) authorisation vulnerability.
We did not conduct any further security analysis to find other issues, but it was recommended to Viseca to conduct a full security analysis on the service.
Impact
The vulnerability allows downloading credit card statements of business customers of Viseca. As Viseca is handling credit cards for most Swiss banks (except very large banks such as UBS), it is assumed many if not most businesses with a credit card in Switzerland would have been susceptible.
A credit card statement includes statements for one or more credit cards. The credit card statement includes the company address, the card account number, the card owner's names, the masked form of the credit card numbers (in the form 1111 11XX XXXX 1111), the card limits, type of card and payments made with the cards in the statement date range. Payments often allow to map the card owner to a geolocation at a certain point in time and it can reveal business relationships and preferred places for meeting customers outside of office buildings.
Timeline
2022-11-10: Vulnerability noticed. Initial contact request via LinkedIn.
2022-11-11: Initial contact with Viseca including telephone call. Initial response by Viseca. Technical details and disclosure deadline (2023-02-09) communicated.
2022-11-15: Further communication, clarifying that the demo account is not necessary and that the
visecaStatementIdparameter is mainly a timestamp.2022-11-17: Viseca communicates that countermeasures are planned: Removing the demo account, fix/patch the vulnerabilities ("this week"), monitoring and investigation, check why internal security checks of supplier didn't catch it earlier.
2022-11-23: Findings retested by Pentagrid, unauthenticated download of Pentagrid's statement is not possible anymore.
2022-11-25: Viseca informs that the issue was fixed and a security analysis is currently taking place.
2022-12-19: Viseca provides feedback on an earlier version of this advisory.
2023-03-20: Publication of advisory.
2023-03-20: Republik published a background story: Zehntausende Schweizer Kreditkarten-Abrechnungen offen zugänglich im Internet.
Affected Components
Affected was the Viseca eXpense solution web application, which is a third-party product hosted on the third-party domain https://www.dcalonline.com/. This website indicates in it's footer that "Fiserv, Inc" is the owner. The endpoint for the PDF download responds with some interesting HTTP headers that seem to indicate that an Oracle system is used as the underlying technology:
It is unknown to Pentagrid if other instances of the same software on the Internet are present or if only Viseca and Swiss Business Credit cards are affected.
Technical Details
The security issue is a standard Indirect Object Reference (IDOR) authorisation vulnerability paired with a missing authentication check (there is no need to send an HTTP cookie or similar). It could be exploited by knowing the correct URL. The following URL was taken from the authenticated area of the demo account:
Although this particular URL is referenced in the application for the demo account, it will not return a PDF. This is probably the case because there is no PDF present for the demo account or because the statement is too old (year 2020).
The cardId parameter in the URL has to be any valid cardId, but it doesn't matter which cardId. There seems to be no correlation on the server-side between cardId and visecaStatementId and therefore using the demo account's cardId of 763454 is sufficient to download other user's credit card statement.
By providing any valid visecaStatementId it seemed possible to download arbitrary credit card statements from other customers of Viseca. We used one of Pentagrid's visecaStatementId to download Pentagrid's credit card statement with the demo account. It was possible to download Pentagrid's credit card statement in PDF format without any authentication.
The only thing left to proof was that the visecaStatementId does not include sufficient entropy and is therefore guessable and can be brute-forced. If we look at the visecaStatementId it can be noticed that it starts with a time stamp of year, month, day. So we had a proper look at Pentagrid's credit card statement visecaStatementId, which was 20221022093536019983. After a while we had the idea to extract meta data of the PDF statement:
% exiftool -a -u -g1 statement.pdf [...] Producer : Compart MFFPDF I/O Filter 2019-07-30 00:56:08 Creator : Compart Docponent API (201908-STABLE) Create Date : 2022:10:22 09:35:36+01:00 Modify Date : 2022:10:22 09:35:36+01:00 [...]
By writing the visecaStatementId and the create date of the PDF above each other and inserting spaces shows that the visecaStatementId has very little entropy as it includes a full timestamp including hour, minutes and seconds:
The timezone (+01) seems to be just a coincidence that it matches with the number in the visecaStatementId. The last six digits for Pentagrid in the last few monthly statements were:
2021-10: 025323 2021-11: 021534 2021-12: 020879 2022-01: 020786 2022-02: 021019 2022-03: 020725 2022-04: 025125 2022-05: 020649 2022-06: 020541 2022-07: 024985 2022-08: 019883 2022-09: 025733 2022-10: 019983
These digits do not include a lot of entropy and seem to vary between the numbers 19983 and 25733. These numbers are assumed to be incrementing IDs per month over all statements of all customers.
Therefore, Pentagrid concludes that the visecaStatementId is just a timestamp of the creation date of the PDF plus six digits. As credit card statements are likely to be created in sequence as a massive batch job, the entropy of the visecaStatementId is even lower than expected.
Unfortunately, this endpoint on the webserver did not support HTTP HEAD, Range, If-Modified-Since or other HTTP request techniques that would have allowed Pentagrid to get metadata information about a PDF file (e.g. their byte length in the Content-Length header) or a side-channel (e.g. response time difference) without receiving the full PDF. The full PDF includes sensitive information of third-parties and therefore we did not want to access this data. This prevented us from brute-forcing visecaStatementId to prove our point: It is assumed that when the last six digits would be incremented or decremented, PDF credit card statements of other companies could be downloaded.
Precondition
There were no special preconditions for exploitation, it was feasible for every user on the Internet. An attacker had to know timestamps when credit card statements were created, for example by having legitimate access to statements or by guessing or brute-forcing.
Recommendation
During the disclosure process Pentagrid recommended Viseca to:
Take the expense portal offline immediately until the issue is resolved or prevent the portal from acquiring Viseca credit card statements.
Contact the third-party who is running the affected service and require an emergency change to fix the issue.
Start an investigation if the issue was exploited in the past.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.
Check if Web Application Firewall (WAF) rules could be put in place that prevent or mitigate the issue from arising in the future.
Conduct security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.
Pentagrid recommended Fiserv to:
Take the expense portal offline immediately until the issue is resolved.
Do a root cause analysis of the security issue and fix it (e.g. check the role concept, authentication and authorisation model of the website).
Conduct security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.
Start an investigation if the issue was exploited in the past.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.
Pentagrid recommends business customers to:
Take the usual precautions regarding credit card fraud.
Check the regulatory obligations that might apply in case of such an issue and take appropriate actions.
Resolution
According to Viseca, the following actions took place:
Contacted the third-party who is running the affected service and requested an emergency change to resolve the issue.
Analyzed log files for any signs the vulnerability had been exploited and found no indication of unauthorized access or disclosure of customer information.
Checked wether regulatory notifications are required and, if so, take required actions.
Checked if Web Application Firewall (WAF) rules could be put in place to prevent or mitigate the similar issues from arising in the future.
Conducted security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.
According to Viseca, the owner took the following actions:
Conducted a root cause analysis of the security issue and resolved it.
Conducted security measures such as contracting a third-party to do a security analysis of the issue including code review to identify potential further issues.
Credits
The vulnerability has been found by Pentagrid.