Sparkasse Safe - Two Functions One Token to Go

Bypassing using Exchange of Session Credentials

In recent weeks, a new application has been released at the sparkasse in germany. This is the "secure safe" for documents & data as a storage unit. The application was coordinated by the financial information department in development.

The application in online banking allows confidential documents to be stored securely and easily. Personal documents are stored securely. Online banking as a linked access gives you flexible access to all your own documents or data. There are currently various offers for online banking customers with suitable storage space at a relatively low price. Since we have some team members who also use the sparkasse application, we thought we would have a look at it.

To explain the whole security problem behind it we have to start at the beginning of the year a few months ago where a new function was implemented in the online banking of the sparkasse. The new function is a security mechanism that is used for queries via chip tan procedures to better protect customers in online banking. Every 3 months the PIN is requested via Chip TAN procedure to confirm the customer's identity once again for security reasons. The token is used for verification with the respective user account ID.

A few weeks ago, the safe function was then integrated into the user interface using the same procedure. Before the safe function is activated, it is also activated with the same PIN query via Chip TAN procedure.

At this point, our security researchers have identified an anomaly in the web application. The same mechanism is used without physical separation. This allows an attacker from outside who has a token for confirmation after 3 months to unlock the safe function. Shortly afterwards, a follow-up request is sent directly to the Web server with the contract form.

Shortly after we identified the vulnerability, we reported the strange procedure as a problem to the customer service of the sparkasse bank. When we received a feedback after about 4 weeks, a manager of the sparkasse bank called and informed us that the problem had been identified and was now being taken care of. Both functions should be safely separated and at the same time it should be prevented that contract forms are validly delivered by simple follow-up requests.

What can attackers do with the vulnerability?
Attackers can use an existing account to activate it on other accounts by saving the token of their requests and then using it on another account in an activation request. Thus allows them to receive the inner contract documents as confirmed user. At that point an attacker from the outside can access valid documents from inside after activation that are only intended for customers. At that point we need to mention it was not possible for us to access the other storages data, because the checks in the role system are valid so far.

A few days later, another call was made to the sparkasse bank, which thanked them for reporting the problem, as the problem was now on the screen of the finance informatics team. In the last few days, a correction of the settings as an adjustment were made that will resolves the problematic permanently. The correction should prevent that attackers capture the first token without interaction to use it in the followup request. Since the same cms is also used as standard by all other sparkasse banks, it can be assumed that it is also possible to outwit the security mechanism in this way. After the patch the function is uses a confirmation formular with a separate function.

At that point we say special thanks to our sparkasse bank manager that was coop and proxy enough to deliver the information to the developers. The sparkasse should note at this point that users of the bank are checking if the security measures are correctly, especially on new functions that needs to be confirmed as trusted. However for security reason no poc request log has been attached to preview in this article.

allinurl:/de/home/ /safe


Rate this article: 
Average: 4 (3 votes)

Add new comment

Plain text

  • No HTML tags allowed.