 It's a pleasure to introduce the next speaker, Vincent Hauquat. He's studying computer science in Erlangen. He's doing his master with a focus on IT security. But the work he is presenting us now, he actually completed before during an assistant position beforehand. And it is about insecurity of app-based ton of indication in online banking. Give us a welcome, applause for Vincent, please. Welcome from my side. My name is Vincent Hauquat. Last autumn, my colleague and I had a look at the security of app-based ton of indication. Maybe one of you has already heard about it on Heise. Two weeks ago, I got a call from the German bank institution, Mr. Mayer, as I want to call him now, asked me what he's doing between what I'm doing between Christmas and New Year. He actually wanted to know if his PR department actually needs to get ready for a new attack or he just, Vincent says that he hopes that the bank already has a template drafted up. It makes it easier for the next time it happens. But online banking is so established these days that it affects us all. A special property of it is that in the time between its creation in the 80s and now, it turned into a two-factor authentication procedure. You usually have a username and password and a ton. Mostly, the ton procedure was modified for security reasons. It usually works this way. For completeness' sakes, I want to draft it up here. You log into the portal. You use your username and password. You create a transaction. And in the second step, you have to verify it with a ton. Usually, it used to be an old system where you had a list on paper. The new system or newer is with using a phone. But this is also leaky or insecure as we found. And then there's also the special hardware devices that are pretty commonplace. This last one is actually already pretty safe. But if you believe the banking institution, then there is a pressing need in the population to always and everywhere be able to execute your transactions. So let's have a show of hands who, at the moment, is doing an online transaction. So if you want to do it everywhere, of course, you don't want to have an extra device that you have to carry with you. So what they did is they discovered a device that everyone always has with them. And it's called the smartphone. And it's, of course, it's secure. OK, now you only have one device instead of two. And therefore, you only have a one-factor procedure in result. So what happens is you use your banking app on the smartphone, use your username and password, create a wire transfer. And then you have to switch to the TAN app. And instead of just using the paper, you go to the TAN app. And most banking companies in Germany are already a big fan and apply this kind of system. The ones that haven't are pretty sure they're already working on it, so they can catch up. One or two guys in the room in front of me are already worried. But let's detail how the actual attack would look like. Well, we already know that Malware in the official app stores for the mobile systems is in the fiction. On my own chair at university, there's a guy called Dominik Meyer. And he showed that the Google Play Store just can effectively protect against Malware. The idea was to bring some Malware to the Google app store. And it was his bachelor thesis. And he told his tutor, yeah, that he was ready already. So it was really quick. And that was in 2014, by the way. And what he did was he zipped a root exploit. Well, he just zipped it and he uploaded it. There was no password, nothing else. Just uploaded it. But that's not only a theory. At the same time, we made this app. There was the app Brain Test that had about 100, 500,000 downloads. This app actually did what the theory might be to the mobile 10 area. And it hacks the software and just relates on the hardware. I chose the Sparkas for this example because it's my bank and is one of the first companies to offer this. So we tried to see what can you actually do and how can you attack it. Well, the first thing, you could copy the app or you could reverse engineer the protocol. But that's pretty much concentrated on the TAN app. The problem itself of the TAN area was the two-factor authentication. You could manipulate the transaction. So we manipulate the transaction the user makes in real time. So how did we do this? How was the scenario we thought about? On the left, you can see the Sparkas app. You use it to log into your online banking and to fill in the transaction file. And this goes to the Sparkas and server. And that sends a message to the actually app. And so they are requested to change to the S-TAN app and to transfer it to the Sparkas app. And it's so much automated that you actually ask yourself why you have two apps for this. What we do before, after filling in the information on the Sparkas app, we manipulate the data. And we change the address. We change the amount. And the Sparkas sends the same details to the TAN app and then shows it there. And before showing it there, we manipulate it to the original data. So the user can't see this and just says OK and accepts the payment. What are the security measures for this? So the Sparkas app is pretty easy on this. So it doesn't really have security measures. You have a route. You can see if you have the route on the device. On the other side, the S-TAN app tries to use more measures than one to keep itself safe from malware. But all these measures, even the Sparkas is not sure about all these measures. And if they are really working, they have a route detection. If route is not available, the app just quits. It's a static analysis, by the way. And it's TÜV approved. It's German quality. So from this mark on, we were pretty amazed. But then we see what the actual security measures are. So we found out the Sparkas isn't so sure about their own security measures. So they bought something from Promen. They made a native library, the so-called Promen Shield. And the library is, of course, encoded. And it's upfascated with a special key. So you can't just patch out the library. Yeah, just take it out. They took strings from the Java logics and pushes it into the library. The app itself sets static fields with strings, or they have an index. So that makes it difficult to just pull down the library from the app. It detects routes, debuggers, repackaging. But it doesn't really handle it. So that's the reason is they want to sell a library that works with any software so that it's not personalized on this app. Well, so this is how it's implemented. There's callbacks in the Java code for the events, for example, debuggers or route. The app itself implements the interface. And if it detects it, it calls the code. So on the button, there's a routing status. It's in a parameter Z. And it checks if it's rooted or not. And then it quits just if you don't have the root status. If this event comes, the methods end and the app runs. It's a paradox because this app doesn't have a status. It just delivers strings. Even if root is already detected, I didn't think it was so easy. So we look at the transaction itself. So at first, you have the login window with a name and a password. And you also have the information that the device is rooted, by the way. And in this case, I made a transaction to the tax payment place. And on the next place, we manipulated the data in the background. And you can't really see it. And you are asked to change to push turn so you can put the push into the turn into the actual app. So we do this with our password again in the push turn app. And it's highly likely that it's the same password than in this Sparkhassen app. And then we look at the transaction details. It's 10 cents. So this might be the eBahn, whatever. And it looks good to my turn to Sparkhassen. And then we just remember the last two digits of the transaction number. And you can set the transaction. But if we look into our transaction details, there's a different amount of money on a transaction to the tax payments. So anyone who knows the story knows what comes later. So this is the statement from the Sparkhassen. Well, it's an old version. Yeah, that shouldn't work anymore. So there's a new version since 16th October in a Google Play Store. It's not possible anymore. So well, it's nothing new for us. The Sparkhassen didn't really read it carefully. So we already said that in the current version, the kind of way the attack works, it works differently in the new app. But we can still do it with a little more work. So let's see how the new app works. In order to drive an attack against the new version, we just have to think about what's different this time. Well, at PromoNor, maybe the bank, they realized that it doesn't really make sense what they did so far. Therefore, they don't use Java callbacks anymore, but rather just crash the app if they detect root or debugger or whatever. And then they open a page in the browser. And therefore, you can't just circumvent the root detection anymore that way, or at least it easily. So what we did is we used the expose in order for a proof of concept. And the dot doesn't work anymore. So that's bad. But in order to still make it work, we first have to circumvent root detection and the expose detection. So how does it work? So far, I did pretty well with the approach of just thinking about how I would do it. So what I would do is I would just look through the file system with characteristic things. So and it turns out, yeah, that's what they did. They look for s-fit-su. So what you do is you rename these programs in the file system that these characteristic files that the app is looking for. And suddenly it works again. But that's annoying, because obviously you still want stuff for the other apps to work. And if you rename it, then it doesn't work anymore. So what happens is you usually don't just run the command and not use the full path, but rather just the command name, because it uses the path expansion. So what you did is you changed the path. And it still works everywhere. And the app just doesn't realize it anymore. Perfect. A little bit more paradox now, because the actual app recognizes this, but the promo library doesn't. So you still get the warning in the app, even though it now doesn't crash anymore. So how does the expose detection work? Same approach. What would I would do? Probably they just look for something characteristic that is unique for exposed. And this list shows you what they're looking for. So we now have to get rid of this somehow. And it still has to work. The first four, you can just delete or rename or whatever. You don't need them. So that's easy. And the other three are a little more tricky, because you actually use them. But let's just rename them. And you obviously have to resolve the dependency among them. But it's not enough. So this is actually working a little better than I expected. So they actually look in the executable and look for the string exposed. And then they determine that if they find this string, then obviously it's installed. So I just recompile it, and it works. That's it. So let's do a demo. Same approach. We open the app. We enter our password. This time, we actually look at the specific version of the app. So I can show you this is the version from the 7th of December. That's the most recent one until two hours ago. So let's enter our wire transfer not to the tax collectors, but rather to the library of my university. I actually have to pay a fine. My bank account isn't filled, as you can see. So I had to use something small. But OK, here you can see the push time app has already opened up. So the integration actually was increased. So here you can see again the free URL I want to transfer. And let's have a look at the version again of the push time app. So yeah, this is also the latest version. So yeah, the data is correct. Time is correct. Everything's OK. So let's just confirm. So we go back to the original app. Yeah, the transfer was received. And if you now look into the details of the transaction, so I already paid for some Christmas shopping. And here is the four-year 20 instead of the three-year that I actually was confirming. So yeah, it still works. So wow. And it also has a different info line. So I'm a little quicker than I thought. So we have more time for questions. What can you say about app-based transactions? It's pretty weak. The callbacks are a little more difficult to hack. So you can't just have root. But it's still a game that Sparkhase and other distributors will lose at some point. The root detection, for example, usually causes hassle for the users because it has false positives on some points. So you have to ask yourself if this transaction method is still good for them. But what I actually did was quite weird. I actually circumvented stuff that a normal user does. So I didn't really prevent a real attack. Someone who's actually rooting his own machine has really much difficulties. And a normal user won't install a binary somewhere. Root isn't set for this hack. In this case, it would have been easy enough to use a root exploit. And then you also don't have the hassle with a root detection. And I still have a few slides here. And I want to thank you for your attention. Thank you very much, Vincent. Thanks a lot, Vincent. Great talk. So, and we now have time for questions. So if you're online, please write in the IRC. Guys in the room, just go to the microphone. We'll give you a few more minutes to think about it. And I look up. Dear people who are asking questions from the net, I can't see you right now. But if you have any questions, you can read a question. Then I'll just do it. Shata A wants to know, are there also weaknesses in the optic ton procedures? So with phototun, you mean with this ton, kind of, you mean phototun? QR ton and phototun is pretty similar. You scan a code. And then you get a ton. But that differentiates from the device. You can't really use it on one device. Of course, you can scan the QR with your own device. But it's a little different here. And there's a lot of more weaknesses there. So you can copy the app. But that's not comparable to the scenario we had with the mobile ton systems. I'd like to ask you a question. You described how the app is actually hardening itself against debugging. How exactly did you find the transaction details and how did you manipulate them so that you could transfer them to the bank? The problem is that there are only measurements on the analysis basis. So you can't really shoot an attack. The attack itself was made in post. That's a special framework that hooks JavaScript. For the proof of concept, this was easy enough. So most measures that are documented here can't really save yourself from a real attack. Because they usually just only if so, the Sparkers can say, well, yeah, this attack doesn't work anymore. I'm interested in how the app scans against exposed. That looks pretty ridiculous. Can you do this in a proper way that actually would work? Or is there without hope? Yeah, that's a little difficult to make it properly. You need to have trustworthy requests. And who's allowed to be a macro stick? So that's a little difficult. And I don't have an idea right now to how to make it more efficient or to efficiently prevent it. Thanks for the demonstration. I was actually really delighted to see that the distribution into two apps actually doesn't give you anything as an added value. What's your estimation that is it possible in the future to have apps of an authentication mechanism in Android that actually do what they should after routing? Or this looks like a signer approach than what they tried so far? That's really deep into what you are told about. There's a secure world and an insecure world. There's a trust down in RIM that's not used in Android. Samsung has something like Nox that's similar, but you have to buy it. And you don't know how long it might take on Android. So it will take a while, I guess. I can deduce from your explanations that there is a fundamental problem with the combination of two apps on the same device that it actually renders the two-factor authentication useless, and the security can only improve by using two separate devices that have to be compromised. That's what I was talking about. And I have a quote on this. By the way, it's not what I'm only talking about. Even in the Buffin Journal, the ton shouldn't be on the same smartphone that they use for online banking. If someone hacks your smartphone, he can use both methods. That's really clever. You get it to the point. Some people wanted to know, maybe this has already been answered, but if you have two different procedures, maybe app and PC, if it's secure then. Well, it's still have same problems like you are and Photo10. But it's still quite safe. If I use this 10 methods on my computer, it's not worse than an SMS ton, for example. It's comparable. Yeah, this seems relatively new from my own experience. I know that when you use mobile 10 with my device, then I'm not allowed to start the transaction from the same device. So they actually filtered mobile host names. And then the vendor that created the software that they actually released the same app under a different logo. So I can only deduce that they know that it's crap. So I have a different quote here. The MARSI is the internet standard for internet payments. The time is over right now. So you have to have strong customer authorization. But you can interpret everything into this here. So it has a Q&A that's longer than the actual text of this information. And after that, app-based security measurements and the actual online banking have to be on different machines. So it's actually questionable whether this method is supposed to be allowed to live. May I ask how you do wire transfers? Or what do you recommend? I use Chypton. And I actually use it on my mobile device. But usually just when I'm longer somewhere, I don't really have the need to make transactions wherever I am. I actually can say Chypton is really good. Thank you very much. Thanks a lot. He actually promised to stay here if you have some questions. So just walk up to him and chat him up. You guys have been listening to the translation.