[00:01.880 --> 00:07.820] Hello, my name is Arkady Litvinenko. I'm a lead penetration tester in a Russian company that [00:07.820 --> 00:16.760] has the name Bizon. Also, I'm one of the organizers of the Russian conference of ZON in Moscow, [00:17.240 --> 00:27.540] and one of the organizers of CTF ZON competitions, CTF, and also a co-author of DEFCON CTF. [00:27.540 --> 00:37.020] So, today we will talk about online banking security. And firstly, among projects on my [00:37.020 --> 00:44.480] job, I have a lot of security audits of different online banking applications. And during these [00:44.480 --> 00:52.460] projects, I met and we met a lot of different vulnerabilities and other interesting things. [00:52.460 --> 00:58.340] So, in this presentation, I want to share with you some experience that I got and some interesting [00:58.340 --> 01:09.040] things. And so, this talk will be interesting for offensive and defensive specialists that [01:09.820 --> 01:17.240] work with online banking applications. And also, it will be interesting for developers who [01:18.400 --> 01:23.420] work with online banking and who is trying to make it safer. [01:25.100 --> 01:32.000] But I tried to make this presentation with a growing difficulty level. So, I hope everyone [01:32.000 --> 01:37.300] can get something new from this presentation and get something interesting from this presentation. [01:37.300 --> 01:41.560] So, let's talk about the structure of this presentation, about what we are going to talk [01:41.560 --> 01:51.040] about. So, firstly, we will talk about differences, about remote banking and online banking, and what [01:51.040 --> 01:57.560] is remote banking and what is online banking. We will talk about web banking, mobile banking, [01:57.560 --> 02:04.620] what differences between them. And after that, we will talk about testing approaches, [02:05.030 --> 02:14.450] and how to test the web, mobile, and the server side of mobile banking, and what differences, [02:14.920 --> 02:21.360] what guides we can use for this, and we usually use on our projects. [02:22.450 --> 02:30.960] And the biggest part of this presentation, it will be vulnerability examples with detailed [02:30.960 --> 02:40.300] information, how it works, how to exploit it, and maybe some bad practices of fixing it, [02:40.300 --> 02:46.420] of avoiding it, and so on. And also, we will talk about best practices of how to avoid this [02:46.420 --> 02:53.080] vulnerability, its vulnerabilities. So, let's begin from the differences. What is remote banking [02:53.080 --> 03:00.540] services? It is when the client doesn't need to go to the office to do some actions in bank. For [03:01.320 --> 03:08.820] transferring money, for checking the balance of the account, and some other things. [03:09.060 --> 03:15.620] So, it can be anything. It can be ATM, it can be call center, it can be SMS banking, and also, [03:15.620 --> 03:24.120] it can be a web and mobile banking. For example, we're going to get cash from the account, so we [03:24.120 --> 03:30.520] come to ATM, and it is one of the examples of remote banking services. But there is another [03:31.100 --> 03:37.260] type of banking services, it is online banking. It is not another, it is part of remote banking [03:37.260 --> 03:43.920] services, but it is a thing that we are going to talk about today. So, online banking, it is [03:43.920 --> 03:50.040] web banking and mobile banking. So, web banking, it is when you open the website of [03:51.580 --> 03:55.920] a bank on the browser and do some actions, and for example, log into your account and do some [03:55.920 --> 04:02.700] actions, maybe transfer money, checking balance, and other, and other. So, in mobile, it is totally [04:02.700 --> 04:09.140] the same, but you have to download the application to your mobile, and after that, again, you log [04:09.140 --> 04:19.360] into the account and do some actions. So, today, we're going to talk about online banking, [04:19.360 --> 04:25.700] about web and mobile banking, yeah. And so, we're going to... and all vulnerabilities will be related [04:25.700 --> 04:34.860] to these types. So, let's talk about how does it work. It is very, very simple image, yeah, [04:34.860 --> 04:42.620] but it is a good image for showing that we're going to talk about. We are not going to talk [04:42.620 --> 04:47.260] about infrastructure, our bank infrastructure, about processing, and other very, very complex [04:47.260 --> 04:54.580] things. It is magic for us today, and it is like a black box for us. And so, we're going to talk [04:54.580 --> 05:01.800] about the server side, about the API, yeah. We're going to talk about the frontend mobile. Frontend, [05:01.800 --> 05:13.440] it is something that loads in the browser of clients. So, it can be Angular, it can be React [05:13.440 --> 05:20.620] application, it can be HTML with IAC request, but it doesn't work like this now, usually. Maybe [05:20.620 --> 05:28.960] there are banks with IAC requests, but I don't know. They didn't meet it. So, mobile, it is [05:28.960 --> 05:36.940] totally the same, but mobile application, it is like a custom-made browser. And frontend and mobile, [05:36.940 --> 05:43.900] work with API, yeah, with server side. And they send requests to API, and they get requests from [05:43.900 --> 05:54.980] API, and they render it, they show UI to the clients, and the clients can work with this UI, [05:54.980 --> 06:00.500] and do some actions, maybe clicking the buttons, and other things, and enter maybe some. [06:00.500 --> 06:12.120] And so, usually, in banks, API, it is a similar API for the frontend, and the same, sorry, same [06:12.120 --> 06:18.520] API for the frontend, and for the mobile. Sometimes, maybe there are differences. Maybe it is [06:18.520 --> 06:26.780] split API, so different API for frontend, and different API for mobile. But usually, usually, [06:26.780 --> 06:35.820] it is the same. And API, it is like something between... it is an application that [06:37.620 --> 06:44.260] helps us to work with bank infrastructure. It has API methods, it has some functionality that [06:44.260 --> 06:51.140] can be used by frontend, and that can be used by mobile. And after that, it sends to bank [06:51.140 --> 06:57.740] infrastructure, and there is some magic in bank infrastructure. The bank infrastructure is very, [06:57.740 --> 07:04.980] very complex. It can be anything. It can be monolith, it can be microservices, yeah. And so, [07:04.980 --> 07:11.600] but today, it will be bank infrastructure, and API, it will be server-side for us. [07:13.080 --> 07:21.120] And I think it is all that I wanted to say about how does it work. Again, it is very, [07:21.120 --> 07:27.900] very simple. And we can't talk more detail, because it needs a lot of time. It is a huge topic. [07:28.480 --> 07:35.200] So, testing approaches of server-side and bank infrastructure. Usually, it is... API, it is usual [07:35.200 --> 07:40.800] web application, yeah. And bank infrastructure, it is a very complex thing. It is like [07:40.800 --> 07:45.880] Zoho with different services. It can be anything. And so, it is [07:48.380 --> 07:55.020] very hard to hack it without understanding how does it work. And so, you can only can try to [07:55.020 --> 08:01.160] maybe use fuzzing and other things, and try to understand how does it work. And it is only one [08:01.160 --> 08:05.920] way to understand how to hack the bank infrastructure. So, API, it is usual web [08:05.920 --> 08:14.820] application, so it can have any web vulnerabilities. So, if I'm talking about the possible [08:14.820 --> 08:20.260] vulnerabilities, like I said, it is usual web vulnerabilities. Yeah, it is everything from the [08:20.260 --> 08:27.320] OWASP. Yeah, you just can take the checklist of OWASP and any vulnerability and the most related [08:27.320 --> 08:33.820] to the server-side. So, also, it is misconfigurations. It can be anything like [08:33.820 --> 08:43.820] Nginx misconfigurations, maybe other things. And also, it is logical vulnerabilities, [08:43.820 --> 08:52.480] because the bank and the mobile banking, online banking, it is very, very complex thing. Yeah, [08:52.480 --> 09:01.060] it has very, very complex architecture. And so, when architecture is complex, [09:01.060 --> 09:07.220] developers can do a lot of mistakes in this. And so, it can be any logical vulnerabilities, [09:07.840 --> 09:19.060] like, I don't know, leakage of sensitive data of clients. Maybe, if it's correct to say race [09:19.060 --> 09:27.620] condition, but it is not logical vulnerability, but sometimes it can be based on logical [09:30.480 --> 09:40.540] problems. And other vulnerabilities, it is only example. So, it can be anything. [09:41.200 --> 09:50.000] Next one, it is front-end. So, it is user interface. Yeah, based on the data received from [09:50.000 --> 10:00.400] API. And so, and because it loads in browser, yeah, browser take a lot of security job on itself. [10:00.400 --> 10:09.820] And so, it is very big difference between the mobile application, yeah, and front-end, [10:09.820 --> 10:15.820] because browser do a lot of security job by itself. But in mobile applications, [10:16.540 --> 10:25.900] developers have to do the things by itself. And possible vulnerabilities, it is XSS, it is, [10:25.900 --> 10:35.460] I don't know, DOM-based XSS, it is CSRF, yeah. Maybe forgotten or maybe unfinished pages, yeah. [10:35.460 --> 10:44.940] Sometimes, for example, developers make and publish in production React application, [10:44.940 --> 10:51.700] but this application has pages that doesn't work and they are invisible for clients. [10:51.700 --> 11:02.520] But anyway, they exist in production. And so, after understanding and maybe reversing of [11:02.520 --> 11:12.700] React application, yeah, you can find this and you can recover the API methods that [11:12.700 --> 11:21.040] application sends to API and gets and it allow you to try more requests and [11:22.520 --> 11:31.060] maybe find another vulnerabilities. And also, it can be unsafe communication with API server. [11:31.840 --> 11:38.020] And it is everything about the society, it is everything about communication, [11:38.020 --> 11:43.160] maybe other algorithms and so on, so on. And again, it is only examples, [11:43.160 --> 11:47.400] maybe there are another ones. There are another ones, of course, there are. [11:48.440 --> 11:56.540] So, if we're talking about mobile testing approaches, yeah. Like I said, mobile, [11:56.540 --> 12:06.580] it is an application, it is like custom-made browser. And in this case, you have a lot of, [12:07.220 --> 12:15.160] I don't know, security and customization features, yeah. And so, you have a lot of [12:15.160 --> 12:22.240] possibilities to do something wrong. And in this case, possible vulnerabilities, it is [12:22.240 --> 12:31.040] storing of sensitive data, yeah. And we will talk about this in one example a little bit later. [12:31.040 --> 12:35.520] So, also, it is unsafe handling of external data. And [12:38.400 --> 12:46.280] because there is one good example of vulnerability, when mobile application got [12:47.730 --> 12:55.140] external data and save it to SQLite database. So, and there was a SQL injection in this. [12:55.140 --> 13:06.760] And if you can sniff and if you can edit the traffic that application gets from the network, [13:06.760 --> 13:11.940] yeah, you can do the SQL injection on the client side. It is very interesting thing. [13:12.020 --> 13:19.280] So, also, it is unsafe work with mobile platform. It is, for example, IPC mechanism and [13:19.280 --> 13:26.140] other things, maybe. And also, there are a lot of different things. [13:26.780 --> 13:32.900] And let's talk about testing guides, testing approaches for every type of online banking, [13:34.120 --> 13:40.860] yeah. For web banking, you know, in this slide, I wanted to set, I wanted to make the big [13:42.200 --> 13:53.880] table with comparing of different guides and with choosing the best one. But, no, I just didn't find [13:53.880 --> 14:00.680] any other good guides except Avast per Web and Avast per MSTG. So, maybe, you know, and [14:01.680 --> 14:08.520] if you use something else, you can maybe share it in comments. So, it is really good because... [14:11.440 --> 14:19.080] but for web banking, we also usually use Avast per Web, yeah. It has very good checklist and it [14:19.080 --> 14:26.220] has a lot of different vulnerabilities. So, it is really great and good job of someone who made [14:26.220 --> 14:37.740] this, yeah, of people who made this. And so, mobile banking, it is Avast per MSTG and Avast [14:37.740 --> 14:47.080] Web guides. And Avast per MSTG, it is about everything that's related to mobile platform, [14:47.080 --> 14:54.340] yeah, all vulnerabilities that's related to this one. And why Avast per Web here? Because we have [14:54.860 --> 15:05.900] service side, yeah, and when we're watching the mobile application, we have to check the platform, [15:05.900 --> 15:12.920] the application, and also we have to check the server side and how it communicates with a mobile [15:12.920 --> 15:19.200] application. So, for the platform, for the application, we use Avast per MSTG. And for the [15:19.200 --> 15:30.600] service side, we use Avast Web. And it has maybe some intersections, yeah. And so, in the best way, [15:30.600 --> 15:40.300] this intersection should be fixed, yeah. And the best way is to have that one big checklist [15:40.300 --> 15:48.340] and one big guide. And so, using of this checklist is very, very conveniently and [15:49.370 --> 15:57.020] it is really helps us to don't forget something when we test it. So, after that, we [15:59.140 --> 16:05.180] begin to talk about vulnerabilities. And now it is the biggest part and we will talk about this [16:06.340 --> 16:14.360] until the finish of the presentation. And firstly, I want to say why I choose this vulnerability. [16:15.340 --> 16:19.080] There are three options and there are three [16:21.760 --> 16:26.580] reasons why I choose this. Firstly, it is, for example, some vulnerabilities are very common, [16:27.190 --> 16:34.040] you can meet it in a lot of different applications. And it is very common. And [16:36.700 --> 16:43.900] this is a problem. So, the second one reason, it is because some vulnerabilities are really [16:43.900 --> 16:51.900] interesting. And they are not common. Yeah, maybe it is very rare vulnerability. But anyway, [16:51.900 --> 16:56.420] it is really, really interesting. And it is like really hacking. And for example, [16:56.420 --> 17:01.500] like I said before, it is like making money from nothing. Yeah. And so on. And so, it is really, [17:01.500 --> 17:07.800] really interesting and I love it. And so, the third one reason, it is because sometimes some [17:07.800 --> 17:13.920] vulnerabilities are really hard to fix. Yeah. And developers are trying to fix it and make another [17:13.920 --> 17:20.640] vulnerability. And so, we will talk about... I don't remember one example of this vulnerability. [17:20.640 --> 17:27.080] And so, it... Okay, a little bit later we will talk about it. So, let's begin from the first [17:27.080 --> 17:34.080] one vulnerability. And first vulnerability, it is rounding attack. It is currency rounding attack. [17:34.080 --> 17:42.660] And it is one of my favorite vulnerability, because it is really, really hacking. Like I [17:42.660 --> 17:47.240] said before, and I talk about this vulnerability, it is like making money from nothing. Yeah. [17:47.240 --> 17:53.960] And so, first information that I found about this vulnerability, it was 2011, maybe 2012. [17:54.460 --> 18:02.280] Maybe there are early information, but I didn't find. So, this vulnerability based on the [18:03.940 --> 18:13.380] incorrect or unsafe using of round functions. Yeah. And later we will talk about example. [18:13.380 --> 18:20.780] But now, very, very simple example of using of round functions. And it is very simple. But [18:21.620 --> 18:29.700] for us, interesting last example, when we can... In round function, we can set what is... [18:30.740 --> 18:41.000] We can set the decimal places that will be after rounding. And as you can see on this example here, [18:41.790 --> 18:53.740] it is two decimal places after rounding. So, after rounding, we will get 1.52. Yeah. And so, [18:54.420 --> 18:56.260] you can say that it is not [18:58.680 --> 19:04.860] real vulnerability and it is not possible to meet it in real life. But... And for example, [19:04.860 --> 19:11.540] all banks already fixed it and all companies that work with money already fixed it too. [19:11.540 --> 19:19.820] And you can't meet it in real life. So, but no, there are examples and you can find it on Hacker [19:19.820 --> 19:27.560] One. And I met this vulnerability two years ago and I know one very huge bank. And so, [19:27.560 --> 19:41.800] no examples exist. So, let's watch the example. Yeah. For example, we have one account. Yeah. And [19:41.800 --> 19:49.180] this account has two wallets, USD and ruble wallets. Yeah. And you can transfer money between [19:49.180 --> 19:58.380] these wallets. And when you transfer money, the different currencies convert in between. Yeah. And [19:58.380 --> 20:07.740] for example, in this case, we have unreal rates. But anyway, it is very comfortable for us for [20:07.740 --> 20:17.780] calculations. So, current rates, it is 64 rubles for one dollar in case of buying. And the same [20:17.780 --> 20:29.860] 64 one USD in case of selling. And so, we have bank that use rounds into decimal places. Yeah. [20:29.860 --> 20:38.060] And our goal is to become rich. So, what we can do? Let's watch the attack. Yeah. [20:39.840 --> 20:52.360] We have, one second, we have one ruble on the ruble wallet and we send it to the USD wallet. [20:52.360 --> 21:01.720] And after rounding, yeah, firstly, we convert it to the USD. And after that, [21:02.560 --> 21:13.560] calls function rounding. And as a result, we will get 0.02 USD from one ruble. Yeah. After that, [21:13.560 --> 21:21.500] we convert, we send this two cents back to the ruble wallet. Yeah. And [21:23.060 --> 21:36.120] it will be already one ruble and 20. Yeah. And now we have profit 120%. Why it happened? [21:36.120 --> 21:46.200] This has happened because of this. This is main reason. So, we had one number and after wallet, [21:46.200 --> 21:55.440] it became more. Yeah. And this difference is very critical. So, we can get a big profit. [21:55.460 --> 22:06.100] And you can say that now we have two additional ruble cents. Yeah. And it is not rich. Yeah. [22:06.120 --> 22:14.560] But if you can repeat it 1,000 or maybe 1,000,000 times, you will get real money. [22:14.780 --> 22:21.880] I think banks not allowed to make this a lot of time because anti-fraud and some other things. [22:21.880 --> 22:29.020] But anyway, if this vulnerability exists, sometime someone can try to exploit it. And [22:29.760 --> 22:40.520] it is, I think, the best way to fix it anyway. So, and I have very simple plot. Yeah. [22:41.260 --> 22:53.140] Firstly, on the X, we have transfer amount rubles. Yeah. And the Y, we have profit and the persons. [22:53.140 --> 23:05.680] And so, as you can see, the biggest profit when we send about, I don't know, 0.3, 0.4 rubles to [23:05.680 --> 23:16.600] the dollars, to the USD. And in this case, the profit is the highest. Yeah. And as you can see, [23:16.600 --> 23:23.000] if we send more, yeah, the profit less, less, less. And after some specific moment, [23:23.000 --> 23:32.900] it is less than 100. So, it is non-profitable for us. And from this, you can see that it is [23:32.900 --> 23:38.540] first way to how to avoid this vulnerability. It is set the limit of transaction. For example, [23:38.540 --> 23:46.840] if we'll set the limit of transaction in 6 rubles, yeah, it will be unprofitable for anyone [23:46.840 --> 23:55.420] who tried to exploit this vulnerability. So, also, there are two other ways. And [23:56.460 --> 24:06.260] second one, it is that we shouldn't allow to clients to convert money from rubles to USD. [24:06.260 --> 24:20.160] Instead of this, we should allow to buy USD. Yeah. For example, client will buy 0.01 USD. [24:20.600 --> 24:31.800] And after that, client will get price. And after that, they can finish the transaction. So, [24:32.500 --> 24:39.260] in this case, anyway, there is rounding. Yeah. And it will be. But in this case, [24:39.260 --> 24:47.840] numbers are higher. The numbers are bigger, sorry. And it will be unprofitable for anyone [24:47.840 --> 24:54.340] who is trying to exploit this vulnerability. So, and there is another way. It is adding commission [24:54.340 --> 25:00.680] after certain number of transaction. It is not looks like good way. But [25:02.180 --> 25:11.760] anyway, it works. And so, but it looks like not like good fix. So, but this vulnerability that [25:11.760 --> 25:18.260] I found this rounding attack took two years ago, the bank fixed this by adding commission [25:18.260 --> 25:27.340] after specific count of transactions. So, another example, it is sensitive data disclosure. It is [25:27.340 --> 25:34.160] very common vulnerability that is you can meet in every and a lot of application. Not every, [25:34.160 --> 25:43.320] but a lot of. But maybe, maybe in every. I don't know. So, let's watch an example, [25:43.320 --> 25:49.780] good example, interesting example. And this example shows that what is convenient is not [25:49.780 --> 25:58.120] always safe. So, we should look for balance between convenient and for between security. [25:58.120 --> 26:06.100] And it is very important. And case, the bank added functionality that allowed to send money between [26:06.100 --> 26:17.640] cards without login procedure. So, it looked like this. So, user enters firstly information about [26:17.640 --> 26:24.800] source card, about their card. And after that, user enters the information about the destination [26:24.800 --> 26:32.620] card. It is only PAN code. In the first step, we enter the PAN, CVV and expired date. So, [26:32.620 --> 26:42.520] on the second, only PAN code. So, on the third step, user enters the amount of money for transfer. [26:42.860 --> 26:50.540] And on the next step, system checks the balance and calculates the commission. And if everything [26:50.540 --> 27:00.500] is okay, money is enough and so on, user gets SMS. The user that has the source card gets SMS. [27:01.220 --> 27:07.200] After entering the code, the transaction is done. If code is okay. So, let's watch [27:07.200 --> 27:19.520] into the HTTP request that was used for checking the balance. Yeah. And it was a problem. The [27:19.520 --> 27:29.840] main problem was that this server didn't check the expiry date and didn't check the security code. [27:29.840 --> 27:44.640] Yes. So, but it checked the money amount and card number. So, as a result, everyone could get balance [27:44.640 --> 27:51.660] for any card in the bank. So, just by enumerating the card number and just by enumerating the money [27:51.660 --> 28:05.240] amount. So, it worked like if you set too much money, yeah, server will return the error that [28:05.240 --> 28:14.060] money is not enough. Yeah. In other case, it will be everything's okay, enter please code. Yeah. [28:14.060 --> 28:22.920] Please enter the code. So, and you can set any card number. So, you can get information about [28:22.920 --> 28:32.060] every card in bank. And it is not so good. Now, it fixed. Next vulnerability, it is unsafe OTP. [28:32.760 --> 28:41.340] Firstly, what is OTP? OTP, it is one-time password. And it is usually one of the most [28:42.280 --> 28:48.080] popular realization of second factor. Yeah. For example, you enter to the mobile banking. Yeah. [28:48.080 --> 28:56.280] You enter your login and password. And after that, you get the SMS code or maybe push notification [28:56.280 --> 29:04.880] or maybe something like this. Yeah. And you have to enter it to pass the second factor of [29:04.880 --> 29:14.200] notification. And usually, usually, it deliver it via SMS. Yeah. And it is the most popular way [29:14.200 --> 29:24.100] for delivering. So, let's watch an example. Yeah, we are hacker. Yeah. And we got access to [29:24.100 --> 29:31.220] user account. And so, we want to get money of this client. So, we have to send this money from [29:31.220 --> 29:39.840] our account to the... from user account to our account. Yeah. So, and for completing this [29:39.840 --> 29:45.980] transaction, we have to enter the correct OTP. This OTP sends to the mobile of the client [29:45.980 --> 29:52.920] and owner of this account. And so, we don't know this OTP. But we have to enter it. And so, [29:52.920 --> 29:58.740] after free and correct... and every time when we create a transaction, we have only three tries. [29:58.740 --> 30:07.800] After three incorrect entries, transaction will be canceled. And OTP has four random [30:09.120 --> 30:15.680] digits. Yeah, digits. And it is, for example, one, two, three, four. Yeah. [30:17.180 --> 30:23.340] So, how to make this transaction? How to finish this transaction? [30:26.040 --> 30:33.240] It is like a little bit strange. But what if instead of brute-forcing OTP, yeah, we will try [30:33.240 --> 30:40.100] to brute-force transactions. Yeah. What if it will be not brute-forcing, but it will be guessing? [30:40.640 --> 30:47.500] Sounds strange. I'll explain. Okay. Very important thing. If we're not limited in the [30:47.500 --> 30:52.580] number of new transactions, if we can create and create and create and so on, yeah, we can [30:52.580 --> 31:02.720] try the next exploitation. We choose three different OTP. Yeah. It should be a potential [31:02.720 --> 31:09.760] correct OTP. One, two, three, four, I don't know, five, five, five, five, six, six, six, six. Yeah. [31:09.760 --> 31:18.840] And after that, we create new transaction. And try choosing OTP. Yeah. If it isn't correct, [31:18.840 --> 31:25.500] to step two and create new transaction. But on this moment, it is, but every transaction, [31:25.500 --> 31:33.240] it is regenerate the OTP. So, we can just brute-force it. We can just take the one big [31:33.240 --> 31:40.660] dictionary. Yeah. And using this dictionary to enumerate, to brute-force all existing OTP. [31:40.660 --> 31:48.140] No, it doesn't work like this. But it is very, very similar. Yeah. So, and we should repeat this [31:48.140 --> 31:56.400] algorithm, this exploitation until we matched at least one OTP. If we matched at least one OTP, [31:56.400 --> 32:03.320] the transaction will be finished. Yeah. And so, it is one big difference. It looks like brute-force, [32:03.320 --> 32:09.940] but it isn't brute-force. It is guessing. So, in case of brute-force, we know about when it [32:09.940 --> 32:17.780] will be finished. For example, dictionary has size 10,000 lines. So, it will be finished after [32:18.400 --> 32:26.980] trying of 10,000 lines. So, in case of this brute-force, yeah, but it is guessing. [32:27.220 --> 32:32.860] We're not sure when it will be finished. It can be finished on the next transaction, [32:32.860 --> 32:40.020] or it can be finished after 20,000 transactions. Yeah. We're guessing. We're trying to enumerate [32:40.020 --> 32:53.980] transactions. Yeah. Until the generated OTP didn't match our OTP. So, I'll explain everything. [32:54.520 --> 33:01.860] No, I'm joking. I am not going. It is boring. So, no, no, no. But it is very interesting results. [33:01.860 --> 33:06.880] Let's watch the results. So, probability of the successful transaction depends on the [33:06.880 --> 33:15.100] number of attempts. So, in our guessing exploitation, yeah, after 3,000 attempts, [33:15.100 --> 33:23.620] then it will be about 60% probability. Yeah. But if we can try 16,000 attempts, [33:23.620 --> 33:34.980] it will be 99%. So, it is a really good result, I think. And let's watch a little bit more [33:35.720 --> 33:42.160] complex example with new limitations. The same example, totally the same OTP, [33:42.160 --> 33:48.740] totally the same situation, and so on. But after five canceled transactions, we can't create a new [33:48.740 --> 33:56.200] one. We will be blocked for several times. For example, for 24 hours. Yeah. And so, what we can [33:56.200 --> 34:04.840] do in this case? There are two possible approaches. First approach, it's totally the same [34:04.840 --> 34:16.600] exploitation, totally the same steps, but we try not three OTP for each transaction, but two OTP. [34:16.600 --> 34:25.120] So, in this case, we avoid the cancellation of transaction. And in this case, [34:25.120 --> 34:31.820] creation of transaction will not be blocked. Yeah. So, it is one approach. Another one, [34:31.820 --> 34:36.640] we can, in the beginning, create several thousands of transactions. Yeah. For example, [34:36.640 --> 34:42.260] we can create 20,000 of transactions, and only after that, we will try the OTP. [34:42.280 --> 34:49.100] So, in this case, yeah, we will block the creation of new transactions after trying the OTP. Yeah. [34:49.100 --> 34:57.460] But it is not affected. It doesn't affect us, because we already created the 20,000. And [34:58.020 --> 35:05.080] as you can see from the calculations, in case of 20,000, it will be more than 99% [35:05.840 --> 35:18.700] probability of success. So, we will get profit. So, and also, [35:18.700 --> 35:28.180] very good question. Is SMS a secure way of OTP delivery? Yeah. It is a good question, [35:28.180 --> 35:34.980] because there are a lot of attacks against the SMS. It can be fake BTS. It can be [35:34.980 --> 35:41.420] ratio of SIM card. It can be SS7 attacks. Yeah. For example, these two very [35:45.700 --> 35:53.480] cheap things, it can be used for creating the fake BTS, for creating the fake station. Yeah. [35:53.480 --> 36:10.440] And using this, you can try to attack the client. So, let's talk about the recommendations. Yeah. [36:10.440 --> 36:17.560] Firstly, second factor should be enabled for all critical actions. Yeah. If you, for example, [36:17.560 --> 36:28.120] login to account, if client, for example, logins to account, for example, if changes the profile [36:28.120 --> 36:38.420] information, maybe other critical actions, it should be, client should enter the second factor. [36:38.420 --> 36:46.520] Also, it is very important to limit the count of requested OTP. On the previous examples, [36:46.520 --> 36:54.140] we tried to limit the creating of transactions, but sometimes it is a little bit hard. Maybe [36:54.140 --> 37:01.570] you can make another vulnerability and so on. So, the best way is to control the OTP. [37:01.570 --> 37:11.590] So, how many OTP, how many generation of OTP client asked. Yeah. And after specific count, [37:11.590 --> 37:21.250] just stop this process. And also, maybe it is a good way to think about alternative for SMS, [37:21.250 --> 37:29.230] because SMS not looks like the best way for delivering OTP. For example, we can watch on [37:29.230 --> 37:36.750] the push notification, we can watch on the TOTP and HOTP. TOTP and HOTP, it is, for example, [37:36.750 --> 37:40.630] Google notification, it is Microsoft notification. It is applications that you [37:40.630 --> 37:59.210] have on your mobile phone and they use cryptography for OTP process. So, [37:59.210 --> 38:11.430] it is totally silent because it doesn't have delivering. Yeah. So, client doesn't know about [38:11.430 --> 38:21.530] that someone trying to brute force its second factor. Yeah. And so, sometimes it is very [38:21.530 --> 38:28.090] critical because in case of SMS or maybe push notifications, client will get a lot of messages [38:28.650 --> 38:35.530] about that and understood that something's wrong and maybe call to support and support will call [38:35.530 --> 38:44.890] to security information specialists. And so, maybe attack will be stopped. But in case of TOTP and [38:44.890 --> 38:54.690] HOTP, it doesn't look like this. Next vulnerability, it is unsafe randomization. [38:55.970 --> 39:03.210] And it is, you can meet it in application where logic is based on the generation of [39:03.210 --> 39:14.490] random values. It can be sessions, it can be OTP, maybe unique identifiers. Yeah. And it is, [39:15.590 --> 39:22.810] for example, most common problems, it is using of unsafe predictable [39:24.370 --> 39:28.870] random numbers generators. Yeah. In other case, it can be, for example, using the predictable [39:28.870 --> 39:37.070] functions for creating, for example, sessions, maybe unique identifiers and so on. So, in a case [39:37.070 --> 39:47.710] when attacker can recover the sequence of random values. Yeah. And it can be in case, [39:47.710 --> 39:53.430] for example, incorrect initialization of random number generator and so on. And [39:56.010 --> 40:03.190] it is one very known example when... it isn't online banking, of course, but anyway, [40:03.190 --> 40:11.010] Russian engineer, they... but it wasn't one engineer, it was team. Okay, never mind. [40:12.770 --> 40:19.430] A team of Russian engineers, so maybe one engineer, reversed the slot machine. Yeah. And [40:19.430 --> 40:29.150] they recovered the sequence. They recovered it of algorithm, how it used randomization. Yeah. [40:29.150 --> 40:37.350] And they developed their program. I don't know what they did, but they, for example, [40:37.350 --> 40:45.410] they developed a program that helped to recover this sequence. For example, they came to the [40:45.410 --> 40:54.630] slot machine. They played for several minutes. And in these several minutes, they got the sequence [40:54.630 --> 41:04.330] what slot machine showed to them. Yeah. And using this information, they recovered them all sequence [41:05.150 --> 41:13.810] of random. And they can... and they know what will be in the future. And so, using this cheat, [41:13.810 --> 41:21.250] they can... they did a lot of money. And so, it is one of the good examples. [41:21.250 --> 41:31.990] And so, another one good example, I heard from Timur Inusov. And he met... it is on his project. [41:31.990 --> 41:45.730] So, for OTP generation was used LCG generator, yeah, for randomization. So, but using of LCG [41:45.730 --> 41:55.870] is not okay, because it is not cryptography safe. And for example, when you have a sequence of [41:55.870 --> 42:03.130] several generated codes, you can recover all sequence. So, you can predict next OTP codes. [42:03.370 --> 42:11.670] And for OTP, it is very critical. So, something like this. [42:12.550 --> 42:19.070] Another vulnerability, it is mobile banking identification. Yeah, it is not vulnerability, [42:19.070 --> 42:27.710] but it is like evolution, yeah, for mobile banking identification. I'll explain, okay. [42:27.710 --> 42:36.670] For example, we have case. Client installed our mobile banking application on the mobile phone, [42:36.670 --> 42:44.950] and client, very good client, yeah, you know, they know a lot about security. And [42:46.590 --> 42:54.830] so, client has very strong password, yeah. And on the mobile phone, and the very strong [42:54.830 --> 43:04.550] password is not convenient, yeah, and it's not so comfortable. And so, our task is to [43:05.790 --> 43:11.950] develop the simple authentication process, and that works after first login. For example, [43:11.950 --> 43:18.390] first time a user enters their login and password. After that, something happens, [43:18.390 --> 43:24.470] and user can enter there more simply. Yeah, for example, using PIN code or something like this. [43:24.470 --> 43:33.390] And so, let's try to make this solution, yeah. Firstly, what is the most simple way? [43:33.390 --> 43:40.990] After entering the login and password, the application just save the user password to file, [43:40.990 --> 43:45.330] and every time when the user opens the application, the application sends the [43:45.330 --> 43:55.070] password to the server and get the session, the live session. It is awful. It is totally unsafe. [43:56.770 --> 44:02.650] Because of the saving of password, it is awful practice by design. [44:02.650 --> 44:09.510] Do not do this. It is awful. The second problem that unlocked device provides access to mobile [44:09.510 --> 44:18.490] functions. So, anyone who can get access to unlocked device, or maybe device [44:19.770 --> 44:31.130] doesn't have PIN code because it didn't set. Yeah. So, in this case, anyone can just use [44:31.130 --> 44:38.510] the mobile one. It isn't okay. And so, finding the second factor doesn't help in this case, [44:38.510 --> 44:47.150] because this phone has the SIM card, and the SMS will be on this phone. So, [44:47.150 --> 44:54.210] and the third one, the hacker can get access to the file with password, yeah. And in case, [44:54.210 --> 45:00.310] for example, if application has vulnerabilities, yeah, or just because of hacker has [45:00.310 --> 45:09.090] hacked the phone and now has root access. And in this case, hacker can just open any file on the [45:09.090 --> 45:19.510] file system, almost. So, another case, after successful login, yeah, user sets the PIN code. [45:20.030 --> 45:28.430] Yeah, and PIN code saves, or maybe not saves, but it uses it by checking the access by application, [45:28.430 --> 45:37.350] and for example, now we use refresh token, yeah. And I forgot to say that the best practice, [45:37.350 --> 45:44.890] save not password, but save the refresh token, yeah, and using the refresh token for creating [45:45.050 --> 45:54.530] a live session. So, after first login, yeah, user set PIN code. This PIN code used for decrypting [45:54.530 --> 46:04.430] encrypted refresh token, yeah. So, and also, this PIN code used for checking the access. So, [46:04.430 --> 46:12.250] you open the mobile application, you enter the PIN code, PIN code, for example, comparing with [46:12.250 --> 46:16.890] something, yeah, and for example, decrypting the refresh token, the refresh token sends to server, [46:16.890 --> 46:30.870] and server backs a live session, yeah. Again, it is an awful realization, because firstly, [46:30.870 --> 46:36.670] anyway, we store the refresh token in the file, so hacker, again, if there are vulnerabilities, [46:36.670 --> 46:45.050] or if hacker have root access on the mobile, hacker can just get access to file with password. [46:45.050 --> 46:53.170] In another case, encryption of token with short PIN code is useless, because PIN code is very short, [46:53.170 --> 47:02.970] and brute force of this will be very fast. And also, any local checks, like PIN code check, [47:02.970 --> 47:10.310] and other things can be easily bypassed by Frida, if you have enough access on the device. [47:10.310 --> 47:18.150] So, it doesn't work like this. So, next realization, we save refresh token to the [47:18.150 --> 47:30.290] kstore kchain, yeah. And you know, kstore kchain is the very good option, but it is unsafe only [47:30.290 --> 47:40.090] in one case, when we enable the checking of biometric open code, when someone opens this [47:40.090 --> 47:46.430] record. In this case, hacker can't get access to these records in kchain. In another case, [47:46.430 --> 47:55.390] if no access checking, and the application just extract the data from kchain kstore without any [47:57.590 --> 48:04.410] interactions with the user, in this case, it is totally unsafe. Not totally, but unsafe, because [48:04.410 --> 48:12.950] of a hacker with root access can just extract it without any problems. So, also, it can be [48:12.950 --> 48:21.890] problematic if a user has old device. And in this case, maybe problems with kstore kchain, [48:21.890 --> 48:31.770] maybe just device don't have enough security functions, and so on. And also, but it is very [48:31.770 --> 48:37.590] similar to the second one, and the third one, is that you completely dependency on the kstore [48:37.590 --> 48:46.050] kchain security. So, if there are some problems with this, you have problems with the application. [48:46.920 --> 48:55.750] And the last one realization, application asks user to set pin code, and this pin code will be [48:56.530 --> 49:07.330] sent to API. So, API controls the identification process. And in this case, you can control [49:08.250 --> 49:14.730] anything, like brute force, like enumeration, and other things. So, you can control anything. [49:14.730 --> 49:21.790] In this case, it is totally the same. For example, in case of using kstore kchain, [49:22.570 --> 49:30.250] user can't use any pin code, because it will be a pin code of device only. In case of the last [49:30.250 --> 49:37.560] realization, user can use any pin code, because it is no limitation. And we can set, for example, [49:37.560 --> 49:46.420] ask for the big pin code, like six symbols, maybe eight symbols, any pin code, and other things. [49:47.900 --> 49:55.480] But it is very important, too, that now we have to protect our server-side, because [49:55.480 --> 50:02.820] everything depends on our server-side. That's all that I wanted to show you. [50:02.820 --> 50:10.940] So, now about conclusions. Firstly, there are good testing guides. There are good testing [50:10.940 --> 50:17.000] approaches. And you can use it not only for testing the applications, but you can use it for [50:17.000 --> 50:24.400] developing the application, for making applications. And it is really useful. It [50:24.400 --> 50:31.420] has a lot of examples, and so on. Also, the next conclusion is sometimes convenience is the enemy [50:31.420 --> 50:40.300] of security. And as you can saw from the example, yeah, third example with bank that added the [50:40.300 --> 50:46.740] functionality of sending money between cards without login. It is sometimes too critical, [50:46.740 --> 50:51.700] yeah. And so, it is very important to find the compromise between convenience and [50:52.300 --> 50:58.920] between security. Next one, it is be careful with cryptography, randomizations, and other things, [50:58.920 --> 51:03.720] because cryptography is really complex, and it is very important to understand what you do. [51:03.720 --> 51:11.220] And just don't use cryptography without understanding. It is bad practice. And the [51:11.220 --> 51:20.540] last one conclusion is use best practices, and use experience of other companies. Watch on other [51:22.040 --> 51:32.040] products, watch on other applications, because a lot of problems, yeah, and some companies [51:32.720 --> 51:41.140] already solved these problems. And if you find the correct solution, it will be very good. [51:41.500 --> 51:49.700] And so, it is everything that I wanted to say. So, thank you for attention. I hope [51:49.700 --> 51:54.720] you got something new from this presentation. Thank you.