App security specialist Build38 welcomes Manuel Holzhauer as new advisory board member

App security specialist Build38 welcomes Manuel Holzhauer as new advisory board member

Focus on digital transformation in the finance and insurance market

With immediate effect Manuel Holzhauer joins the advisory board of Build38. In doing so, the start-up benefits from its many years of experience and extensive network from its activities in the start-up, finance and insurance industries. Holzhauer currently operates as Insurance Industry Executive at Microsoft.

Before his current position at Microsoft, Manuel Holzhauer worked for many well-known companies and organizations such as PricewaterhouseCoopers, Accenture, Munich Re and the InsurTech Hub Munich. Through the InsurTech Hub, he has known and supported Build38 GmbH since its foundation. He has a passion for innovation and digital transformation in the finance and insurance sector. Especially in the financial industry, customer centricity is a decisive competitive factor. This applies to internal processes, but much more to external customer interfaces. Here, the focus should be on customer benefits at all times. For example, mobile apps can be used to implement new concepts that improve communication with customers and simplify the execution of transactions.

"Mobile apps as a front end to the customer are now very important to many companies. Here, developers and operators often focus on the functionalities or the user experience, but not on the necessary security and compliance. However, since the banking and insurance sectors in particular have security as a key value proposition, cyberattacks pose an enormous threat that can quickly become a reputational risk. Therefore, in my view, it is essential to take appropriate safety measures. For this reason, I see it as essential to integrate app security during the early development phase. This is exactly where Build38's innovative concept comes in," says Holzhauer.

"We are pleased to have Manuel Holzhauer on board, an experienced expert whose inspiring ideas and good relationships will help us build bridges in the world of finance and insurance. With his support, we are able to expand the reach of our app security approach, make new contacts and advance business processes," says Dr. Christian Schläger, CEO of Build38.

Manuel Holzhauer, new member in the advisory board
from Build38

Banking Fraud

The fundamentals of implementing strong Device Identification

The fundamentals of implementing strong Device Identification

Some weeks ago, IBM Trusteer reported a massive fraud operation against banks, which lead to losses in the order of millions of dollars. In a nutshell, attackers managed to 1) steal end user credentials and 2) bypass the fraud management scheme of the banks in order to automate millions of small transactions, which would go through unnoticed by the banks’ risk assessment infrastructure (and, potentially, also by the users).

The first step (stealing the bank customer’s credentials) was apparently done using some sort of social engineering attack (that involved installing malware in the end-user’s device). Whereas in the second step attackers used emulators to “trick” the fraud management system of the different banks. We believe it is fair to say that, in this case, the fraud management system failed to do its job, which is, precisely, to protect against situations like this one, where users have been tricked or deceived. So, let’s dig a bit more into this.

Identifying the weak spot

Let’s first try to understand what the anti-fraud system was supposed to be doing. From the reading, one can understand that it was supposed to detect situations where a user account was being used in a device other than the legitimate user’s one. This is a typical scenario for fraud management: if we see the user is using an iPhone, whereas normally they are connecting from a Samsung… Well, that is strange, isn’t it? So, this is why the hackers used emulators: because emulators gave them the ability to “trick” the anti-fraud solution to believe that they were using the end user’s device, when in fact they were not.

So, how might have this worked out? And let’s be clear here, we are entering the land of speculation as the researchers didn’t give enough details to know exactly how it worked. But it is safe to assume that attackers:

  1. Somehow managed to plant malware into the user’s device (e.g., via a phishing scam)
  2. Used this malware to steal credentials, device information and get access to SMS
  3. With the information harvested, set up an automated scheme that
    a) set up an emulator that looked (to the eyes of the anti-fraud system) exactly like a user’s device.
    b) logged in to the banking app using the stolen credentials. Since the device seemed to be the end user’s one, the anti-fraud system didn’t react.
    c) performed a small transaction, that would not raise any suspicious in the banks’ system (and, likely, would go unnoticed by the user), and, finally
    d) was able to repeat these steps millions of times in a matter of days, effectively stealing millions of dollars.

There are multiple things that could have been done differently in this scenario, but here we want to focus on how the attackers managed to “spoof” the device. Or, in other words, how strong was the device identification mechanism. In order to answer this question, let’s first put ourselves in the shoes of the attacker and let’s try to understand how they would go about “spoofing” an end user device.

The relevant step here is not so much 3.b, but rather step 2: collecting the right device information to be used later on. Because the most important thing the attacker needs to know is which information does the fraud management system use to identify a device. At the end, this is the information the hackers need to extract (using the malware) from the end user device to be able to spoof it.

Most likely, the fraud management system uses many different values to identify a device: some of them are obvious, but other ones not so much. Among the obvious ones we can find things like the device manufacturer, the device model, the operating system version, the Android ID (for Android devices) or the IDFV (for iOS ones) … But these are not really interesting, as any device identification system would use them.

The real strength of the device identification system resides on the not-so-obvious device identifiers, especially how many of them are used and, also, how well protected are they. Notice that it is not that important which parameter is being used, but how difficult it is for an attacker to know that it is being used. At the end, the ultimate goal of the attacker is to write a piece of malware that will gather it later on – and this is what we want to prevent.

Exploiting the weakness

So: how could an attacker know the device identifiers that are being used?

  • The easiest approach would likely be to sniff the information transmitted from the app to the backend, using a MITM attack. By analyzing the traffic, the attacker would get a good understanding of which identifiers are being used.
  • Another option would be to read through the source code of the application, in order to find the routines that gather this information and send it to the backend systems. Since the source code is likely to not be available to the attacker, the alternative will be the decompiled binary. It is not as useful as the source code, but a good amount of information can be extracted from a decompiled binary performing static analysis.
  • Finally, the last option available (because it’s the most difficult one) to the hacker would be to use dynamic analysis. Examples of dynamic analysis include debugging the application while it is executing, using a hooking framework (like Frida), etc.

Notice that the options listed above are not mutually exclusive: the attacker needs to succeed in only one of them in order to succeed in the whole attack. So, solutions that prevent only one of the scenarios will make the attacker’s life difficult but will not, ultimately, prevent them from succeeding.

Protecting your app

Considering all of this, we could say that a strong device identification scheme should:

  1. Use many, non-obvious, device identifiers. The more device identifiers, the better.
  2. Protect against MITM attacks. Sniffing network traffic yields a lot of information, so a good protection on this front is a must.
  3. Obfuscate the sensitive parts of the binary. In the case of mobile apps, attackers will always have access to the binary, so proper obfuscation to prevent static analysis is crucial.
  4. Prevent against dynamic analysis. When static analysis is not enough, attackers will fall back to dynamic analysis: debugging, instrumenting, modifying the app, etc. This means that preventing against debuggers, hooking frameworks (such as Frida) and code injection, among others, is also important.

Taking a broader perspective, we can conclude that proper endpoint protection is a must for fraud-prevention solutions based on end-user device identification. Otherwise, attackers will manage to feed “fake” data that will bypass the protections implemented in the backend.

Nordic IT Security Summit Logo

Secure Mobile Banking: Build38 present at the Nordic IT Security Summit

Secure Mobile Banking: Build38 present at the Nordic IT Security Summit

Cybersecurity event for the financial sector

Cyberattacks are occurring more and more frequently around the world. Especially banks and financial institutions are very much affected. To support the financial sector on cybersecurity, the Financial Institutions Edition of the annual Nordic IT Security (NITS) Summit has been launched. This will provide a platform for the fintech, e-commerce and mobile banking industries, offering an optimal opportunity for networking and mutual exchange. The event will take place on April 15 and 16, 2021. In total, many industry leaders will participate in the Summit, outlining their visions and sharing valuable business insights. It will also be possible to browse virtual exhibitions, in which the latest technologies are presented. Build38, an expert in mobile banking app security, is also part of the digital event.

Especially due to the Corona situation, mobile payment is used even more frequently by customers. At the same time, it has also brought it increasingly into the focus of cybercriminals, who hack banking apps to gain access to customers' personal payment data. However, this risk can be eliminated with the early integration of a multi-layered security framework that includes all necessary security functions. Build38 has developed such a framework, which prevents known and unknown attacks at all times and thus optimally secures banking apps. In line with the Shift Left Security approach, the Software Development Kit (SDK) can be integrated in a very short time during the early development phase. This ensures security from the outset. During the event, attendees will be able to learn in-depth about Build38's Trusted Application Kit (T.A.K).

Further information about the event can be found here: