WEBVTT 00:01.880 --> 00:05.120 Hello, my name is Arkady Litvinenko. 00:05.120 --> 00:09.140 I'm a lead penetration tester in a Russian company that has the name Bizon. 00:09.320 --> 00:27.540 Also, I'm one of the organizers of the Russian conference of ZON in Moscow, and one of the organizers of CTF ZON competitions, CTF, and also a co-author of DEFCON CTF. 00:27.540 --> 00:32.400 So, today we will talk about online banking security. 00:33.300 --> 00:43.660 And firstly, among projects on my job, I have a lot of security audits of different online banking applications. 00:43.660 --> 00:52.460 And during these projects, I met and we met a lot of different vulnerabilities and other interesting things. 00:52.460 --> 00:59.320 So, in this presentation, I want to share with you some experience that I got and some interesting things. 00:59.320 --> 01:12.720 And so, this talk will be interesting for offensive and defensive specialists that work with online banking applications. 01:12.720 --> 01:23.420 And also, it will be interesting for developers who work with online banking and who is trying to make it safer. 01:25.100 --> 01:30.620 But I tried to make this presentation with a growing difficulty level. 01:30.620 --> 01:37.300 So, I hope everyone can get something new from this presentation and get something interesting from this presentation. 01:37.300 --> 01:42.140 So, let's talk about the structure of this presentation, about what we are going to talk about. 01:42.300 --> 01:54.280 So, firstly, we will talk about differences, about remote banking and online banking, and what is remote banking and what is online banking. 01:54.280 --> 01:59.320 We will talk about web banking, mobile banking, what differences between them. 01:59.320 --> 02:21.360 And after that, we will talk about testing approaches, and how to test the web, mobile, and the server side of mobile banking, and what differences, what guides we can use for this, and we usually use on our projects. 02:22.450 --> 02:42.700 And the biggest part of this presentation, it will be vulnerability examples with detailed information, how it works, how to exploit it, and maybe some bad practices of fixing it, of avoiding it, and so on. 02:42.700 --> 02:48.440 And also, we will talk about best practices of how to avoid this vulnerability, its vulnerabilities. 02:48.440 --> 02:50.720 So, let's begin from the differences. 02:51.560 --> 02:54.240 What is remote banking services? 02:54.380 --> 03:00.400 It is when the client doesn't need to go to the office to do some actions in bank. 03:00.400 --> 03:08.820 For transferring money, for checking the balance of the account, and some other things. 03:09.060 --> 03:10.700 So, it can be anything. 03:10.700 --> 03:17.580 It can be ATM, it can be call center, it can be SMS banking, and also, it can be a web and mobile banking. 03:18.680 --> 03:28.440 For example, we're going to get cash from the account, so we come to ATM, and it is one of the examples of remote banking services. 03:29.100 --> 03:34.900 But there is another type of banking services, it is online banking. 03:34.900 --> 03:42.660 It is not another, it is part of remote banking services, but it is a thing that we are going to talk about today. 03:42.660 --> 03:46.160 So, online banking, it is web banking and mobile banking. 03:46.160 --> 04:00.240 So, web banking, it is when you open the website of a bank on the browser and do some actions, and for example, log into your account and do some actions, maybe transfer money, checking balance, and other, and other. 04:00.260 --> 04:11.960 So, in mobile, it is totally the same, but you have to download the application to your mobile, and after that, again, you log into the account and do some actions. 04:15.580 --> 04:21.600 So, today, we're going to talk about online banking, about web and mobile banking, yeah. 04:21.600 --> 04:26.920 And so, we're going to... and all vulnerabilities will be related to these types. 04:27.260 --> 04:32.560 So, let's talk about how does it work. 04:32.560 --> 04:41.560 It is very, very simple image, yeah, but it is a good image for showing that we're going to talk about. 04:41.560 --> 04:47.900 We are not going to talk about infrastructure, our bank infrastructure, about processing, and other very, very complex things. 04:47.900 --> 04:53.580 It is magic for us today, and it is like a black box for us. 04:53.580 --> 04:58.180 And so, we're going to talk about the server side, about the API, yeah. 04:58.580 --> 05:01.100 We're going to talk about the frontend mobile. 05:01.160 --> 05:09.160 Frontend, it is something that loads in the browser of clients. 05:09.160 --> 05:20.480 So, it can be Angular, it can be React application, it can be HTML with IAC request, but it doesn't work like this now, usually. 05:20.480 --> 05:23.840 Maybe there are banks with IAC requests, but I don't know. 05:23.880 --> 05:26.080 They didn't meet it. 05:26.160 --> 05:33.840 So, mobile, it is totally the same, but mobile application, it is like a custom-made browser. 05:34.020 --> 05:40.600 And frontend and mobile, work with API, yeah, with server side. 05:40.600 --> 06:00.500 And they send requests to API, and they get requests from API, and they render it, they show UI to the clients, and the clients can work with this UI, and do some actions, maybe clicking the buttons, and other things, and enter maybe some. 06:00.500 --> 06:15.260 And so, usually, in banks, API, it is a similar API for the frontend, and the same, sorry, same API for the frontend, and for the mobile. 06:15.260 --> 06:17.600 Sometimes, maybe there are differences. 06:17.600 --> 06:25.520 Maybe it is split API, so different API for frontend, and different API for mobile. 06:25.520 --> 06:27.940 But usually, usually, it is the same. 06:28.200 --> 06:40.140 And API, it is like something between... it is an application that helps us to work with bank infrastructure. 06:40.280 --> 06:47.560 It has API methods, it has some functionality that can be used by frontend, and that can be used by mobile. 06:47.680 --> 06:54.920 And after that, it sends to bank infrastructure, and there is some magic in bank infrastructure. 06:55.640 --> 06:58.400 The bank infrastructure is very, very complex. 06:58.400 --> 06:59.380 It can be anything. 06:59.380 --> 07:04.320 It can be monolith, it can be microservices, yeah. 07:04.320 --> 07:11.600 And so, but today, it will be bank infrastructure, and API, it will be server-side for us. 07:13.080 --> 07:19.140 And I think it is all that I wanted to say about how does it work. 07:19.840 --> 07:21.580 Again, it is very, very simple. 07:21.580 --> 07:25.860 And we can't talk more detail, because it needs a lot of time. 07:26.640 --> 07:27.900 It is a huge topic. 07:28.480 --> 07:32.700 So, testing approaches of server-side and bank infrastructure. 07:32.740 --> 07:36.380 Usually, it is... API, it is usual web application, yeah. 07:36.380 --> 07:39.740 And bank infrastructure, it is a very complex thing. 07:39.740 --> 07:43.220 It is like Zoho with different services. 07:43.220 --> 07:44.780 It can be anything. 07:44.820 --> 07:52.640 And so, it is very hard to hack it without understanding how does it work. 07:52.640 --> 08:00.040 And so, you can only can try to maybe use fuzzing and other things, and try to understand how does it work. 08:00.040 --> 08:04.540 And it is only one way to understand how to hack the bank infrastructure. 08:04.600 --> 08:12.000 So, API, it is usual web application, so it can have any web vulnerabilities. 08:12.480 --> 08:18.420 So, if I'm talking about the possible vulnerabilities, like I said, it is usual web vulnerabilities. 08:18.420 --> 08:21.100 Yeah, it is everything from the OWASP. 08:21.100 --> 08:29.740 Yeah, you just can take the checklist of OWASP and any vulnerability and the most related to the server-side. 08:29.740 --> 08:32.180 So, also, it is misconfigurations. 08:32.180 --> 08:38.300 It can be anything like Nginx misconfigurations, maybe other things. 08:38.300 --> 08:52.240 And also, it is logical vulnerabilities, because the bank and the mobile banking, online banking, it is very, very complex thing. 08:52.240 --> 08:57.060 Yeah, it has very, very complex architecture. 08:57.060 --> 09:03.840 And so, when architecture is complex, developers can do a lot of mistakes in this. 09:03.840 --> 09:15.000 And so, it can be any logical vulnerabilities, like, I don't know, leakage of sensitive data of clients. 09:15.820 --> 09:31.760 Maybe, if it's correct to say race condition, but it is not logical vulnerability, but sometimes it can be based on logical problems. 09:32.860 --> 09:36.300 And other vulnerabilities, it is only example. 09:36.300 --> 09:40.540 So, it can be anything. 09:41.200 --> 09:43.880 Next one, it is front-end. 09:43.880 --> 09:47.340 So, it is user interface. 09:47.340 --> 09:51.060 Yeah, based on the data received from API. 09:51.060 --> 10:00.400 And so, and because it loads in browser, yeah, browser take a lot of security job on itself. 10:00.400 --> 10:12.920 And so, it is very big difference between the mobile application, yeah, and front-end, because browser do a lot of security job by itself. 10:13.060 --> 10:20.700 But in mobile applications, developers have to do the things by itself. 10:21.600 --> 10:30.860 And possible vulnerabilities, it is XSS, it is, I don't know, DOM-based XSS, it is CSRF, yeah. 10:30.860 --> 10:35.460 Maybe forgotten or maybe unfinished pages, yeah. 10:35.460 --> 10:51.700 Sometimes, for example, developers make and publish in production React application, but this application has pages that doesn't work and they are invisible for clients. 10:51.700 --> 10:55.340 But anyway, they exist in production. 10:55.340 --> 11:25.500 And so, after understanding and maybe reversing of React application, yeah, you can find this and you can recover the API methods that application sends to API and gets and it allow you to try more requests and maybe find another vulnerabilities. 11:25.840 --> 11:31.060 And also, it can be unsafe communication with API server. 11:31.840 --> 11:41.220 And it is everything about the society, it is everything about communication, maybe other algorithms and so on, so on. 11:41.300 --> 11:44.920 And again, it is only examples, maybe there are another ones. 11:45.040 --> 11:47.400 There are another ones, of course, there are. 11:48.440 --> 11:54.900 So, if we're talking about mobile testing approaches, yeah. 11:55.100 --> 12:00.720 Like I said, mobile, it is an application, it is like custom-made browser. 12:01.020 --> 12:13.320 And in this case, you have a lot of, I don't know, security and customization features, yeah. 12:13.320 --> 12:17.360 And so, you have a lot of possibilities to do something wrong. 12:17.660 --> 12:25.520 And in this case, possible vulnerabilities, it is storing of sensitive data, yeah. 12:25.720 --> 12:31.040 And we will talk about this in one example a little bit later. 12:31.040 --> 12:35.500 So, also, it is unsafe handling of external data. 12:35.520 --> 12:51.960 And because there is one good example of vulnerability, when mobile application got external data and save it to SQLite database. 12:51.960 --> 12:55.140 So, and there was a SQL injection in this. 12:55.140 --> 13:10.420 And if you can sniff and if you can edit the traffic that application gets from the network, yeah, you can do the SQL injection on the client side. 13:10.420 --> 13:11.940 It is very interesting thing. 13:12.020 --> 13:16.900 So, also, it is unsafe work with mobile platform. 13:16.900 --> 13:21.740 It is, for example, IPC mechanism and other things, maybe. 13:22.180 --> 13:26.140 And also, there are a lot of different things. 13:26.780 --> 13:35.200 And let's talk about testing guides, testing approaches for every type of online banking, yeah. 13:35.200 --> 13:51.780 For web banking, you know, in this slide, I wanted to set, I wanted to make the big table with comparing of different guides and with choosing the best one. 13:51.780 --> 13:59.060 But, no, I just didn't find any other good guides except Avast per Web and Avast per MSTG. 13:59.060 --> 14:06.160 So, maybe, you know, and if you use something else, you can maybe share it in comments. 14:06.160 --> 14:08.520 So, it is really good because... 14:11.440 --> 14:17.080 but for web banking, we also usually use Avast per Web, yeah. 14:17.080 --> 14:21.840 It has very good checklist and it has a lot of different vulnerabilities. 14:21.840 --> 14:29.840 So, it is really great and good job of someone who made this, yeah, of people who made this. 14:29.840 --> 14:39.680 And so, mobile banking, it is Avast per MSTG and Avast Web guides. 14:39.680 --> 14:50.220 And Avast per MSTG, it is about everything that's related to mobile platform, yeah, all vulnerabilities that's related to this one. 14:50.220 --> 14:53.260 And why Avast per Web here? 14:53.260 --> 15:13.940 Because we have service side, yeah, and when we're watching the mobile application, we have to check the platform, the application, and also we have to check the server side and how it communicates with a mobile application. 15:13.940 --> 15:18.360 So, for the platform, for the application, we use Avast per MSTG. 15:18.360 --> 15:22.100 And for the service side, we use Avast Web. 15:22.100 --> 15:28.020 And it has maybe some intersections, yeah. 15:28.020 --> 15:33.840 And so, in the best way, this intersection should be fixed, yeah. 15:33.840 --> 15:42.760 And the best way is to have that one big checklist and one big guide. 15:42.900 --> 15:54.700 And so, using of this checklist is very, very conveniently and it is really helps us to don't forget something when we test it. 15:55.100 --> 16:01.660 So, after that, we begin to talk about vulnerabilities. 16:01.880 --> 16:09.060 And now it is the biggest part and we will talk about this until the finish of the presentation. 16:10.100 --> 16:14.360 And firstly, I want to say why I choose this vulnerability. 16:15.340 --> 16:23.360 There are three options and there are three reasons why I choose this. 16:23.360 --> 16:30.740 Firstly, it is, for example, some vulnerabilities are very common, you can meet it in a lot of different applications. 16:30.740 --> 16:33.320 And it is very common. 16:34.040 --> 16:37.980 And this is a problem. 16:37.980 --> 16:44.960 So, the second one reason, it is because some vulnerabilities are really interesting. 16:45.360 --> 16:47.760 And they are not common. 16:47.760 --> 16:51.260 Yeah, maybe it is very rare vulnerability. 16:51.260 --> 16:53.620 But anyway, it is really, really interesting. 16:53.620 --> 16:55.520 And it is like really hacking. 16:55.520 --> 16:58.980 And for example, like I said before, it is like making money from nothing. 16:58.980 --> 16:59.300 Yeah. 16:59.300 --> 17:00.320 And so on. 17:00.320 --> 17:03.300 And so, it is really, really interesting and I love it. 17:03.300 --> 17:10.140 And so, the third one reason, it is because sometimes some vulnerabilities are really hard to fix. 17:10.140 --> 17:10.540 Yeah. 17:10.540 --> 17:14.820 And developers are trying to fix it and make another vulnerability. 17:14.900 --> 17:20.640 And so, we will talk about... I don't remember one example of this vulnerability. 17:20.640 --> 17:25.240 And so, it... Okay, a little bit later we will talk about it. 17:25.240 --> 17:28.200 So, let's begin from the first one vulnerability. 17:29.020 --> 17:32.460 And first vulnerability, it is rounding attack. 17:32.460 --> 17:34.080 It is currency rounding attack. 17:34.080 --> 17:41.700 And it is one of my favorite vulnerability, because it is really, really hacking. 17:41.700 --> 17:46.880 Like I said before, and I talk about this vulnerability, it is like making money from nothing. 17:46.880 --> 17:47.240 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 --> 17:58.300 Maybe there are early information, but I didn't find. 17:58.300 --> 18:08.500 So, this vulnerability based on the incorrect or unsafe using of round functions. 18:08.500 --> 18:09.220 Yeah. 18:09.380 --> 18:13.380 And later we will talk about example. 18:13.380 --> 18:17.620 But now, very, very simple example of using of round functions. 18:17.620 --> 18:19.720 And it is very simple. 18:20.180 --> 18:29.700 But for us, interesting last example, when we can... In round function, we can set what is... 18:30.740 --> 18:35.400 We can set the decimal places that will be after rounding. 18:35.400 --> 18:44.880 And as you can see on this example here, it is two decimal places after rounding. 18:44.880 --> 18:51.160 So, after rounding, we will get 1.52. 18:51.160 --> 18:51.780 Yeah. 18:51.900 --> 19:03.040 And so, you can say that it is not real vulnerability and it is not possible to meet it in real life. 19:03.120 --> 19:11.540 But... And for example, all banks already fixed it and all companies that work with money already fixed it too. 19:11.540 --> 19:14.460 And you can't meet it in real life. 19:14.460 --> 19:20.520 So, but no, there are examples and you can find it on Hacker One. 19:20.520 --> 19:26.380 And I met this vulnerability two years ago and I know one very huge bank. 19:26.380 --> 19:31.320 And so, no examples exist. 19:31.500 --> 19:36.200 So, let's watch the example. 19:36.200 --> 19:36.760 Yeah. 19:36.760 --> 19:41.320 For example, we have one account. 19:41.320 --> 19:41.600 Yeah. 19:41.600 --> 19:46.760 And this account has two wallets, USD and ruble wallets. 19:46.760 --> 19:47.000 Yeah. 19:47.000 --> 19:50.320 And you can transfer money between these wallets. 19:50.320 --> 19:58.060 And when you transfer money, the different currencies convert in between. 19:58.060 --> 19:58.200 Yeah. 19:58.200 --> 20:03.860 And for example, in this case, we have unreal rates. 20:03.860 --> 20:08.840 But anyway, it is very comfortable for us for calculations. 20:08.840 --> 20:16.820 So, current rates, it is 64 rubles for one dollar in case of buying. 20:16.820 --> 20:23.520 And the same 64 one USD in case of selling. 20:23.560 --> 20:29.500 And so, we have bank that use rounds into decimal places. 20:29.500 --> 20:29.860 Yeah. 20:29.860 --> 20:32.980 And our goal is to become rich. 20:32.980 --> 20:34.980 So, what we can do? 20:35.320 --> 20:37.360 Let's watch the attack. 20:37.360 --> 20:38.060 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 --> 20:58.380 And after rounding, yeah, firstly, we convert it to the USD. 20:58.380 --> 21:04.480 And after that, calls function rounding. 21:04.480 --> 21:11.560 And as a result, we will get 0.02 USD from one ruble. 21:11.560 --> 21:12.300 Yeah. 21:12.300 --> 21:20.540 After that, we convert, we send this two cents back to the ruble wallet. 21:20.540 --> 21:20.940 Yeah. 21:20.940 --> 21:27.600 And it will be already one ruble and 20. 21:27.600 --> 21:28.380 Yeah. 21:28.380 --> 21:33.520 And now we have profit 120%. 21:33.520 --> 21:36.120 Why it happened? 21:36.120 --> 21:38.700 This has happened because of this. 21:38.700 --> 21:41.500 This is main reason. 21:41.500 --> 21:49.080 So, we had one number and after wallet, it became more. 21:49.080 --> 21:49.460 Yeah. 21:49.460 --> 21:53.320 And this difference is very critical. 21:53.320 --> 21:55.440 So, we can get a big profit. 21:55.460 --> 22:02.020 And you can say that now we have two additional ruble cents. 22:02.020 --> 22:02.580 Yeah. 22:02.580 --> 22:05.940 And it is not rich. 22:05.940 --> 22:06.100 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:28.780 But anyway, if this vulnerability exists, sometime someone can try to exploit it. 22:28.780 --> 22:33.560 And it is, I think, the best way to fix it anyway. 22:35.260 --> 22:39.900 So, and I have very simple plot. 22:39.900 --> 22:40.520 Yeah. 22:41.260 --> 22:46.140 Firstly, on the X, we have transfer amount rubles. 22:46.140 --> 22:46.880 Yeah. 22:46.880 --> 22:53.140 And the Y, we have profit and the persons. 22:53.140 --> 23:07.740 And so, as you can see, the biggest profit when we send about, I don't know, 0.3, 0.4 rubles to the dollars, to the USD. 23:07.740 --> 23:12.620 And in this case, the profit is the highest. 23:12.700 --> 23:13.120 Yeah. 23:13.860 --> 23:21.020 And as you can see, if we send more, yeah, the profit less, less, less. 23:21.020 --> 23:24.720 And after some specific moment, it is less than 100. 23:24.720 --> 23:27.120 So, it is non-profitable for us. 23:27.380 --> 23:35.560 And from this, you can see that it is first way to how to avoid this vulnerability. 23:35.560 --> 23:38.000 It is set the limit of transaction. 23:38.000 --> 23:49.280 For example, if we'll set the limit of transaction in 6 rubles, yeah, it will be unprofitable for anyone who tried to exploit this vulnerability. 23:49.500 --> 23:55.380 So, also, there are two other ways. 23:55.380 --> 24:06.260 And second one, it is that we shouldn't allow to clients to convert money from rubles to USD. 24:06.260 --> 24:11.620 Instead of this, we should allow to buy USD. 24:11.620 --> 24:11.760 Yeah. 24:11.760 --> 24:20.160 For example, client will buy 0.01 USD. 24:20.600 --> 24:25.120 And after that, client will get price. 24:25.120 --> 24:30.700 And after that, they can finish the transaction. 24:30.700 --> 24:35.600 So, in this case, anyway, there is rounding. 24:35.600 --> 24:35.980 Yeah. 24:35.980 --> 24:37.620 And it will be. 24:37.620 --> 24:41.540 But in this case, numbers are higher. 24:41.540 --> 24:43.720 The numbers are bigger, sorry. 24:43.800 --> 24:50.520 And it will be unprofitable for anyone who is trying to exploit this vulnerability. 24:50.720 --> 24:52.440 So, and there is another way. 24:52.440 --> 24:56.580 It is adding commission after certain number of transaction. 24:56.580 --> 25:00.240 It is not looks like good way. 25:00.280 --> 25:03.920 But anyway, it works. 25:03.920 --> 25:09.620 And so, but it looks like not like good fix. 25:09.620 --> 25:20.740 So, but this vulnerability that I found this rounding attack took two years ago, the bank fixed this by adding commission after specific count of transactions. 25:20.740 --> 25:27.080 So, another example, it is sensitive data disclosure. 25:27.080 --> 25:33.740 It is very common vulnerability that is you can meet in every and a lot of application. 25:33.740 --> 25:35.420 Not every, but a lot of. 25:35.420 --> 25:37.200 But maybe, maybe in every. 25:37.200 --> 25:38.240 I don't know. 25:38.960 --> 25:45.840 So, let's watch an example, good example, interesting example. 25:45.840 --> 25:51.000 And this example shows that what is convenient is not always safe. 25:51.000 --> 25:58.120 So, we should look for balance between convenient and for between security. 25:58.120 --> 25:59.820 And it is very important. 25:59.820 --> 26:10.720 And case, the bank added functionality that allowed to send money between cards without login procedure. 26:11.240 --> 26:14.960 So, it looked like this. 26:14.960 --> 26:21.100 So, user enters firstly information about source card, about their card. 26:21.100 --> 26:25.760 And after that, user enters the information about the destination card. 26:25.760 --> 26:28.220 It is only PAN code. 26:28.220 --> 26:32.060 In the first step, we enter the PAN, CVV and expired date. 26:32.060 --> 26:34.900 So, on the second, only PAN code. 26:34.900 --> 26:42.520 So, on the third step, user enters the amount of money for transfer. 26:42.860 --> 26:49.200 And on the next step, system checks the balance and calculates the commission. 26:49.200 --> 26:55.140 And if everything is okay, money is enough and so on, user gets SMS. 26:55.460 --> 27:00.500 The user that has the source card gets SMS. 27:01.220 --> 27:04.280 After entering the code, the transaction is done. 27:04.280 --> 27:05.800 If code is okay. 27:05.800 --> 27:13.220 So, let's watch into the HTTP request that was used for checking the balance. 27:13.220 --> 27:13.940 Yeah. 27:15.220 --> 27:19.340 And it was a problem. 27:19.340 --> 27:29.840 The main problem was that this server didn't check the expiry date and didn't check the security code. 27:29.840 --> 27:30.640 Yes. 27:30.680 --> 27:35.500 So, but it checked the money amount and card number. 27:35.620 --> 27:46.740 So, as a result, everyone could get balance for any card in the bank. 27:46.740 --> 27:52.700 So, just by enumerating the card number and just by enumerating the money amount. 27:52.820 --> 28:07.020 So, it worked like if you set too much money, yeah, server will return the error that money is not enough. 28:07.020 --> 28:07.320 Yeah. 28:07.320 --> 28:13.640 In other case, it will be everything's okay, enter please code. 28:13.640 --> 28:14.060 Yeah. 28:14.060 --> 28:15.500 Please enter the code. 28:15.560 --> 28:19.440 So, and you can set any card number. 28:19.440 --> 28:24.580 So, you can get information about every card in bank. 28:24.780 --> 28:26.660 And it is not so good. 28:26.660 --> 28:27.700 Now, it fixed. 28:28.420 --> 28:32.060 Next vulnerability, it is unsafe OTP. 28:32.760 --> 28:34.420 Firstly, what is OTP? 28:34.420 --> 28:36.460 OTP, it is one-time password. 28:36.740 --> 28:44.860 And it is usually one of the most popular realization of second factor. 28:44.860 --> 28:44.940 Yeah. 28:44.940 --> 28:47.840 For example, you enter to the mobile banking. 28:47.840 --> 28:48.080 Yeah. 28:48.080 --> 28:50.400 You enter your login and password. 28:50.460 --> 28:58.200 And after that, you get the SMS code or maybe push notification or maybe something like this. 28:58.200 --> 28:58.460 Yeah. 28:58.460 --> 29:05.980 And you have to enter it to pass the second factor of notification. 29:06.240 --> 29:10.900 And usually, usually, it deliver it via SMS. 29:10.900 --> 29:11.220 Yeah. 29:11.220 --> 29:15.540 And it is the most popular way for delivering. 29:15.820 --> 29:20.400 So, let's watch an example. 29:20.440 --> 29:22.040 Yeah, we are hacker. 29:22.040 --> 29:22.440 Yeah. 29:22.440 --> 29:25.520 And we got access to user account. 29:25.780 --> 29:29.220 And so, we want to get money of this client. 29:29.220 --> 29:36.660 So, we have to send this money from our account to the... from user account to our account. 29:36.660 --> 29:37.260 Yeah. 29:37.300 --> 29:42.420 So, and for completing this transaction, we have to enter the correct OTP. 29:42.420 --> 29:48.320 This OTP sends to the mobile of the client and owner of this account. 29:48.320 --> 29:50.400 And so, we don't know this OTP. 29:50.400 --> 29:52.060 But we have to enter it. 29:52.060 --> 29:58.740 And so, after free and correct... and every time when we create a transaction, we have only three tries. 29:58.740 --> 30:03.200 After three incorrect entries, transaction will be canceled. 30:03.540 --> 30:10.120 And OTP has four random digits. 30:10.120 --> 30:11.060 Yeah, digits. 30:11.360 --> 30:15.080 And it is, for example, one, two, three, four. 30:15.080 --> 30:15.680 Yeah. 30:17.180 --> 30:21.980 So, how to make this transaction? 30:21.980 --> 30:23.340 How to finish this transaction? 30:26.040 --> 30:30.240 It is like a little bit strange. 30:30.240 --> 30:35.300 But what if instead of brute-forcing OTP, yeah, we will try to brute-force transactions. 30:35.600 --> 30:35.940 Yeah. 30:35.960 --> 30:40.100 What if it will be not brute-forcing, but it will be guessing? 30:40.640 --> 30:41.480 Sounds strange. 30:41.480 --> 30:42.980 I'll explain. 30:42.980 --> 30:43.720 Okay. 30:44.540 --> 30:45.800 Very important thing. 30:45.800 --> 30:55.900 If we're not limited in the number of new transactions, if we can create and create and create and so on, yeah, we can try the next exploitation. 30:55.900 --> 30:58.460 We choose three different OTP. 30:58.560 --> 30:59.080 Yeah. 30:59.500 --> 31:03.880 It should be a potential correct OTP. 31:03.880 --> 31:09.260 One, two, three, four, I don't know, five, five, five, five, six, six, six, six. 31:09.260 --> 31:09.760 Yeah. 31:09.760 --> 31:12.380 And after that, we create new transaction. 31:12.760 --> 31:15.520 And try choosing OTP. 31:15.880 --> 31:16.620 Yeah. 31:17.120 --> 31:21.540 If it isn't correct, to step two and create new transaction. 31:21.680 --> 31:28.220 But on this moment, it is, but every transaction, it is regenerate the OTP. 31:28.280 --> 31:31.240 So, we can just brute-force it. 31:31.240 --> 31:34.320 We can just take the one big dictionary. 31:34.320 --> 31:34.600 Yeah. 31:34.600 --> 31:40.660 And using this dictionary to enumerate, to brute-force all existing OTP. 31:40.660 --> 31:42.120 No, it doesn't work like this. 31:42.120 --> 31:45.800 But it is very, very similar. 31:45.800 --> 31:46.340 Yeah. 31:46.340 --> 31:53.340 So, and we should repeat this algorithm, this exploitation until we matched at least one OTP. 31:53.540 --> 31:59.240 If we matched at least one OTP, the transaction will be finished. 31:59.240 --> 31:59.500 Yeah. 31:59.500 --> 32:02.320 And so, it is one big difference. 32:02.320 --> 32:04.420 It looks like brute-force, but it isn't brute-force. 32:04.420 --> 32:05.440 It is guessing. 32:05.440 --> 32:11.020 So, in case of brute-force, we know about when it will be finished. 32:11.020 --> 32:15.460 For example, dictionary has size 10,000 lines. 32:15.460 --> 32:21.540 So, it will be finished after trying of 10,000 lines. 32:21.540 --> 32:26.980 So, in case of this brute-force, yeah, but it is guessing. 32:27.220 --> 32:29.460 We're not sure when it will be finished. 32:29.460 --> 32:37.440 It can be finished on the next transaction, or it can be finished after 20,000 transactions. 32:37.440 --> 32:37.740 Yeah. 32:37.740 --> 32:38.640 We're guessing. 32:38.640 --> 32:41.260 We're trying to enumerate transactions. 32:41.400 --> 32:41.800 Yeah. 32:41.800 --> 32:50.140 Until the generated OTP didn't match our OTP. 32:51.100 --> 32:53.980 So, I'll explain everything. 32:54.520 --> 32:55.780 No, I'm joking. 32:55.780 --> 32:56.820 I am not going. 32:56.820 --> 32:57.700 It is boring. 32:57.700 --> 32:59.220 So, no, no, no. 32:59.220 --> 33:01.860 But it is very interesting results. 33:01.860 --> 33:03.320 Let's watch the results. 33:03.320 --> 33:08.020 So, probability of the successful transaction depends on the number of attempts. 33:08.020 --> 33:19.460 So, in our guessing exploitation, yeah, after 3,000 attempts, then it will be about 60% probability. 33:19.460 --> 33:19.820 Yeah. 33:19.820 --> 33:25.520 But if we can try 16,000 attempts, it will be 99%. 33:25.520 --> 33:30.440 So, it is a really good result, I think. 33:31.340 --> 33:39.040 And let's watch a little bit more complex example with new limitations. 33:39.100 --> 33:44.020 The same example, totally the same OTP, totally the same situation, and so on. 33:44.020 --> 33:49.200 But after five canceled transactions, we can't create a new one. 33:49.200 --> 33:51.460 We will be blocked for several times. 33:51.460 --> 33:54.620 For example, for 24 hours. 33:54.640 --> 33:55.260 Yeah. 33:55.280 --> 33:57.480 And so, what we can do in this case? 33:58.060 --> 34:00.740 There are two possible approaches. 34:00.880 --> 34:16.600 First approach, it's totally the same exploitation, totally the same steps, but we try not three OTP for each transaction, but two OTP. 34:16.600 --> 34:21.420 So, in this case, we avoid the cancellation of transaction. 34:21.420 --> 34:28.160 And in this case, creation of transaction will not be blocked. 34:28.480 --> 34:28.780 Yeah. 34:28.780 --> 34:30.820 So, it is one approach. 34:30.840 --> 34:36.160 Another one, we can, in the beginning, create several thousands of transactions. 34:36.160 --> 34:36.260 Yeah. 34:36.260 --> 34:42.260 For example, we can create 20,000 of transactions, and only after that, we will try the OTP. 34:42.280 --> 34:48.780 So, in this case, yeah, we will block the creation of new transactions after trying the OTP. 34:48.780 --> 34:49.100 Yeah. 34:49.100 --> 34:51.180 But it is not affected. 34:51.180 --> 34:57.100 It doesn't affect us, because we already created the 20,000. 34:57.100 --> 35:07.700 And as you can see from the calculations, in case of 20,000, it will be more than 99% probability of success. 35:07.700 --> 35:14.580 So, we will get profit. 35:15.020 --> 35:19.980 So, and also, very good question. 35:19.980 --> 35:24.300 Is SMS a secure way of OTP delivery? 35:24.300 --> 35:24.780 Yeah. 35:24.780 --> 35:32.420 It is a good question, because there are a lot of attacks against the SMS. 35:32.420 --> 35:34.520 It can be fake BTS. 35:34.520 --> 35:36.500 It can be ratio of SIM card. 35:36.500 --> 35:38.220 It can be SS7 attacks. 35:38.220 --> 35:38.600 Yeah. 35:38.600 --> 35:41.420 For example, these two very 35:45.700 --> 35:53.160 cheap things, it can be used for creating the fake BTS, for creating the fake station. 35:53.160 --> 35:53.480 Yeah. 35:53.480 --> 35:59.920 And using this, you can try to attack the client. 36:02.360 --> 36:09.560 So, let's talk about the recommendations. 36:09.560 --> 36:10.440 Yeah. 36:10.440 --> 36:15.800 Firstly, second factor should be enabled for all critical actions. 36:15.800 --> 36:16.060 Yeah. 36:16.060 --> 36:38.420 If you, for example, login to account, if client, for example, logins to account, for example, if changes the profile information, maybe other critical actions, it should be, client should enter the second factor. 36:38.420 --> 36:45.240 Also, it is very important to limit the count of requested OTP. 36:45.240 --> 36:53.540 On the previous examples, we tried to limit the creating of transactions, but sometimes it is a little bit hard. 36:53.540 --> 36:57.100 Maybe you can make another vulnerability and so on. 36:57.100 --> 37:01.570 So, the best way is to control the OTP. 37:01.570 --> 37:09.370 So, how many OTP, how many generation of OTP client asked. 37:09.370 --> 37:09.730 Yeah. 37:09.730 --> 37:13.450 And after specific count, just stop this process. 37:13.630 --> 37:28.070 And also, maybe it is a good way to think about alternative for SMS, because SMS not looks like the best way for delivering OTP. 37:28.070 --> 37:33.950 For example, we can watch on the push notification, we can watch on the TOTP and HOTP. 37:33.950 --> 37:39.510 TOTP and HOTP, it is, for example, Google notification, it is Microsoft notification. 37:39.510 --> 37:50.730 It is applications that you have on your mobile phone and they use cryptography for OTP process. 37:50.830 --> 38:07.350 So, it is totally silent because it doesn't have delivering. 38:07.350 --> 38:07.750 Yeah. 38:07.750 --> 38:16.410 So, client doesn't know about that someone trying to brute force its second factor. 38:16.630 --> 38:17.390 Yeah. 38:17.770 --> 38:39.390 And so, sometimes it is very critical because in case of SMS or maybe push notifications, client will get a lot of messages about that and understood that something's wrong and maybe call to support and support will call to security information specialists. 38:39.390 --> 38:43.230 And so, maybe attack will be stopped. 38:43.230 --> 38:49.110 But in case of TOTP and HOTP, it doesn't look like this. 38:49.290 --> 38:54.690 Next vulnerability, it is unsafe randomization. 38:55.970 --> 39:04.330 And it is, you can meet it in application where logic is based on the generation of random values. 39:04.330 --> 39:09.770 It can be sessions, it can be OTP, maybe unique identifiers. 39:10.130 --> 39:10.690 Yeah. 39:10.690 --> 39:26.170 And it is, for example, most common problems, it is using of unsafe predictable random numbers generators. 39:26.170 --> 39:26.390 Yeah. 39:26.390 --> 39:36.090 In other case, it can be, for example, using the predictable functions for creating, for example, sessions, maybe unique identifiers and so on. 39:36.090 --> 39:45.550 So, in a case when attacker can recover the sequence of random values. 39:45.550 --> 39:45.770 Yeah. 39:45.770 --> 39:53.190 And it can be in case, for example, incorrect initialization of random number generator and so on. 39:53.190 --> 40:09.490 And it is one very known example when... it isn't online banking, of course, but anyway, Russian engineer, they... but it wasn't one engineer, it was team. 40:09.490 --> 40:11.010 Okay, never mind. 40:12.770 --> 40:18.770 A team of Russian engineers, so maybe one engineer, reversed the slot machine. 40:18.770 --> 40:19.110 Yeah. 40:19.110 --> 40:23.670 And they recovered the sequence. 40:23.670 --> 40:28.610 They recovered it of algorithm, how it used randomization. 40:28.610 --> 40:29.150 Yeah. 40:29.150 --> 40:33.730 And they developed their program. 40:33.730 --> 40:43.530 I don't know what they did, but they, for example, they developed a program that helped to recover this sequence. 40:43.530 --> 40:46.730 For example, they came to the slot machine. 40:46.730 --> 40:49.430 They played for several minutes. 40:49.430 --> 40:58.150 And in these several minutes, they got the sequence what slot machine showed to them. 40:58.150 --> 40:58.410 Yeah. 40:58.410 --> 41:06.590 And using this information, they recovered them all sequence of random. 41:06.590 --> 41:11.730 And they can... and they know what will be in the future. 41:11.730 --> 41:18.050 And so, using this cheat, they can... they did a lot of money. 41:18.050 --> 41:21.250 And so, it is one of the good examples. 41:21.250 --> 41:25.890 And so, another one good example, I heard from Timur Inusov. 41:25.890 --> 41:31.990 And he met... it is on his project. 41:31.990 --> 41:43.670 So , for OTP generation was used LCG generator, yeah, for randomization. 41:43.670 --> 41:50.690 So, but using of LCG is not okay, because it is not cryptography safe. 41:51.570 --> 42:00.130 And for example, when you have a sequence of several generated codes, you can recover all sequence. 42:00.130 --> 42:03.130 So, you can predict next OTP codes. 42:03.370 --> 42:06.890 And for OTP, it is very critical. 42:07.170 --> 42:11.670 So, something like this. 42:12.550 --> 42:16.990 Another vulnerability, it is mobile banking identification. 42:17.110 --> 42:26.250 Yeah, it is not vulnerability, but it is like evolution, yeah, for mobile banking identification. 42:26.250 --> 42:27.710 I'll explain, okay. 42:27.710 --> 42:29.510 For example, we have case. 42:29.510 --> 42:44.850 Client installed our mobile banking application on the mobile phone, and client, very good client, yeah, you know, they know a lot about security. 42:44.930 --> 42:50.070 And so, client has very strong password, yeah. 42:50.070 --> 42:59.910 And on the mobile phone, and the very strong password is not convenient, yeah, and it's not so comfortable. 42:59.910 --> 43:11.250 And so, our task is to develop the simple authentication process, and that works after first login. 43:11.250 --> 43:15.030 For example, first time a user enters their login and password. 43:15.030 --> 43:21.590 After that, something happens, and user can enter there more simply. 43:21.730 --> 43:24.470 Yeah, for example, using PIN code or something like this. 43:24.470 --> 43:30.210 And so, let's try to make this solution, yeah. 43:30.210 --> 43:33.390 Firstly, what is the most simple way? 43:33.390 --> 43:49.990 After entering the login and password, the application just save the user password to file, and every time when the user opens the application, the application sends the password to the server and get the session, the live session. 43:50.790 --> 43:52.890 It is awful. 43:52.890 --> 43:55.070 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:03.810 Do not do this. 44:03.810 --> 44:05.230 It is awful. 44:05.790 --> 44:10.610 The second problem that unlocked device provides access to mobile functions. 44:10.610 --> 44:26.710 So, anyone who can get access to unlocked device, or maybe device doesn't have PIN code because it didn't set. 44:26.890 --> 44:27.510 Yeah. 44:27.630 --> 44:32.190 So, in this case, anyone can just use the mobile one. 44:32.190 --> 44:33.430 It isn't okay. 44:34.330 --> 44:45.210 And so, finding the second factor doesn't help in this case, because this phone has the SIM card, and the SMS will be on this phone. 44:45.210 --> 44:53.270 So, and the third one, the hacker can get access to the file with password, yeah. 44:53.270 --> 45:04.790 And in case, for example, if application has vulnerabilities, yeah, or just because of hacker has hacked the phone and now has root access. 45:04.910 --> 45:11.090 And in this case, hacker can just open any file on the file system, almost. 45:11.250 --> 45:19.510 So, another case, after successful login, yeah, user sets the PIN code. 45:20.030 --> 45:33.030 Yeah, and PIN code saves, or maybe not saves, but it uses it by checking the access by application, and for example, now we use refresh token, yeah. 45:33.030 --> 45:46.050 And I forgot to say that the best practice, save not password, but save the refresh token, yeah, and using the refresh token for creating a live session. 45:46.930 --> 45:52.290 So, after first login, yeah, user set PIN code. 45:52.290 --> 45:57.070 This PIN code used for decrypting encrypted refresh token, yeah. 45:57.070 --> 46:04.250 So, and also, this PIN code used for checking the access. 46:04.250 --> 46:22.770 So, you open the mobile application, you enter the PIN code, PIN code, for example, comparing with something, yeah, and for example, decrypting the refresh token, the refresh token sends to server, and server backs a live session, yeah. 46:23.550 --> 46:45.050 Again, it is an awful realization, because firstly, anyway, we store the refresh token in the file, so hacker, again, if there are vulnerabilities, or if hacker have root access on the mobile, hacker can just get access to file with password. 46:45.050 --> 46:56.810 In another case, encryption of token with short PIN code is useless, because PIN code is very short, and brute force of this will be very fast. 46:59.110 --> 47:10.310 And also, any local checks, like PIN code check, and other things can be easily bypassed by Frida, if you have enough access on the device. 47:10.310 --> 47:12.910 So, it doesn't work like this. 47:12.950 --> 47:20.310 So, next realization, we save refresh token to the kstore kchain, yeah. 47:20.310 --> 47:40.610 And you know, kstore kchain is the very good option, but it is unsafe only in one case, when we enable the checking of biometric open code, when someone opens this record. 47:40.610 --> 47:44.890 In this case, hacker can't get access to these records in kchain. 47:44.890 --> 48:02.050 In another case, if no access checking, and the application just extract the data from kchain kstore without any interactions with the user, in this case, it is totally unsafe. 48:02.150 --> 48:11.050 Not totally, but unsafe, because of a hacker with root access can just extract it without any problems. 48:11.050 --> 48:17.190 So, also, it can be problematic if a user has old device. 48:17.330 --> 48:29.670 And in this case, maybe problems with kstore kchain, maybe just device don't have enough security functions, and so on. 48:29.670 --> 48:39.050 And also, but it is very similar to the second one, and the third one, is that you completely dependency on the kstore kchain security. 48:39.050 --> 48:46.050 So, if there are some problems with this, you have problems with the application. 48:46.920 --> 49:00.670 And the last one realization, application asks user to set pin code, and this pin code will be sent to API. 49:00.690 --> 49:04.930 So, API controls the identification process. 49:04.930 --> 49:12.670 And in this case, you can control anything, like brute force, like enumeration, and other things. 49:12.670 --> 49:14.730 So, you can control anything. 49:14.730 --> 49:17.950 In this case, it is totally the same. 49:18.990 --> 49:27.950 For example, in case of using kstore kchain, user can't use any pin code, because it will be a pin code of device only. 49:27.950 --> 49:36.130 In case of the last realization, user can use any pin code, because it is no limitation. 49:36.130 --> 49:46.420 And we can set, for example, ask for the big pin code, like six symbols, maybe eight symbols, any pin code, and other things. 49:47.900 --> 49:58.600 But it is very important, too, that now we have to protect our server-side, because everything depends on our server-side. 49:59.220 --> 50:02.820 That's all that I wanted to show you. 50:02.820 --> 50:04.800 So, now about conclusions. 50:05.380 --> 50:10.120 Firstly, there are good testing guides. 50:10.120 --> 50:12.060 There are good testing approaches. 50:12.060 --> 50:20.960 And you can use it not only for testing the applications, but you can use it for developing the application, for making applications. 50:20.960 --> 50:24.200 And it is really useful. 50:24.200 --> 50:27.140 It has a lot of examples, and so on. 50:27.320 --> 50:32.620 Also, the next conclusion is sometimes convenience is the enemy of security. 50:32.620 --> 50:44.300 And as you can saw from the example, yeah, third example with bank that added the functionality of sending money between cards without login. 50:44.600 --> 50:47.180 It is sometimes too critical, yeah. 50:47.180 --> 50:53.820 And so, it is very important to find the compromise between convenience and between security. 50:54.260 --> 51:03.720 Next one, it is be careful with cryptography, randomizations, and other things, because cryptography is really complex, and it is very important to understand what you do. 51:03.720 --> 51:07.900 And just don't use cryptography without understanding. 51:07.900 --> 51:09.960 It is bad practice. 51:10.300 --> 51:18.680 And the last one conclusion is use best practices, and use experience of other companies. 51:19.000 --> 51:34.540 Watch on other products, watch on other applications, because a lot of problems, yeah, and some companies already solved these problems. 51:34.540 --> 51:41.140 And if you find the correct solution, it will be very good. 51:41.500 --> 51:47.100 And so, it is everything that I wanted to say. 51:47.420 --> 51:49.120 So, thank you for attention. 51:49.120 --> 51:53.620 I hope you got something new from this presentation. 51:53.620 --> 51:54.720 Thank you.