Are We Prepared for the Cyber Security Threats That Come With SCA?
First published: 22/09/2021
updated: 21/10/2022
Fabien Ignaccolo
In June, the EBA published a report on the progress of SCA roll-out throughout the European Union. The report showed significant progress amongst issuing PSPs, which resulted in a sharp decrease in fraud rates. Now, this is obviously great news and is indeed the intended purpose of PSD2. However, can we let our guards down? Time has certainly shown us that fraudsters continuously improve upon their level of innovation. As such, we can reasonably expect them to up their game even more so now that SCA has come into full swing.
The Report
As of mid-2021, 85-90% of PSUs (Payment Services Users) have been enabled on SCA by issuing PSPs, with just a few regions lagging behind. This is not only in line with expectations but has also impacted fraud rates. The average value of fraudulent transactions across the EU decreased between June 2020 and April 2021 by ~50% (from 0.12% to 0.06%) for issuing PSPs, and ~40% (from 0.17% to 0.10%) for acquiring PSPs.
Hackers Won’t Stay Idle
The decrease in fraud and in card-not-present fraud is both significant and warmly welcomed. But where are the fraudsters? Hackers? Information thieves? Have they gone to other regions outside of Europe? Have they paused to see how the SCA playing field goes over? We think not. Europe remains an attractive target, and they will most likely strike at some point, in one way or another.
Riskified, in its “The Dark Side of PSD2” white paper, reported a sharp increase in the dark web’s PSD2 mentions within carding forums, particularly around Q3/Q4 of 2020. It’s a sign that hackers are on it, preparing and exchanging sophisticated attack ideas. The report also mentioned how beginners can start training on the dark web to design payment attacks for just a few hundred bucks.
Threats: SIM-Swap and Re-enrolment
Threats are usually a mix between social engineering and technical solutions. Good ol’ threats will still be a go-to method because they prey on people’s shortcomings rather than technical hacks. Although, regarding the latter, fraudsters will certainly refine their strategies via banking malware.
Historically, an attacker’s first way to gain device control occurred around the re-enrolment phase. This is because it’s one of the most critical processes when it comes to security, which is also why we view this attack as one of “the classics.”
Let’s take a look at the SIM-swap attack. In this scenario, a fraudster would trick a phone operator into issuing a new SIM card, pretending that the actual owner lost it. Then, the OTP sent by SMS would be intercepted and used by the fraudster who has taken control of the SIM. Technically, this falls outside of the SCA process because there, the transaction amount and transaction recipient are authenticated by the right person in a ‘what you see is what you sign’ fashion. However, with that being said, there are still some technical solutions that exist to counter it.
If a person is tricked into genuinely authenticating a rogue transaction, you must look more closely at the KYC process. Unfortunately, regarding social engineering, there is no technical solution available. Only training and general awareness on basic security measures and routines can make the user aware that they might be under attack.
Keep in mind that once in control of a device, it becomes much easier for the attacker to control the SCA process. So, if you want to prevent SIM-swap attacks, avoid using weak factors such as SMS, and make sure that when using a new device, either a KYC is performed or the process is anchored in an already secure device. (Read more about the link between SCA and KYC here.)
New Kid on the Block
A good SCA solution can and must (according to PSD2’s paragraph 89) counter innovative attacks. These new attacks could, for instance, exploit zero-day software or firmware vulnerabilities.
Banking malware is big here and is relatively easy for a user to catch through a rogue app, infected video, or SMS. Once installed at root level, it can access vital information and wreak havoc on bank accounts. Sadly, the EBA is unlikely to care about excuses related to the phone running an old operating system or the user being tricked into installing a fraudulent app.
When these attacks do occur, it is also unlikely that they will be detected. As such, the security design of the SCA solution must be made so that it can counter it. Malware on mobiles work differently from PCs, so you have to adapt their respective security measures accordingly. For more on the subject of malware, we recommend checking out our blog on innovative malware attacks.
Separate Execution Environments
Separate execution environments mandated by PSD2 RTS must be fully implemented and impossible to break. Any change - or attempt to change - the transaction should raise the alarm and help an issuing PSP turn down a rogue transaction.
However, there are many other possible attacks on multi-factor authentication, each intending to break one factor in order to compromise another. That being said, banking malwares are certainly the most innovative way of attacking a transaction and its authentication process. Yet, the security provided by SCA should make sure that if one factor is compromised, the integrity of the other one(s) is preserved. For more on the subject, check out this article on hacking multi-factor authentication.
Ultimately, strengthening SCA is the best way to fight fraud. The challenge for issuing PSPs will be to make sure they educate their customers on potential fraud and the importance of sourcing the right SCA solution (including both 2FA and minimum compliant security). This protection is not only crucial for the present - it should be seen as a long-term investment into financial security.
Not all SCA solutions are created equal, so remember to choose wisely and stay sharp as we wait for innovative fraudsters to make their next move.
——————
For more on the subject of SCA updates, check out this OBE blog post with some additional thoughts by Okay’s CTO Erik Vasaasen.