1 00:00:01,880 --> 00:00:05,120 Hello, my name is Arkady Litvinenko. 2 00:00:05,120 --> 00:00:09,140 I'm a lead penetration tester in a Russian company that has the name Bizon. 3 00:00:09,320 --> 00: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. 4 00:00:27,540 --> 00:00:32,400 So, today we will talk about online banking security. 5 00:00:33,300 --> 00:00:43,660 And firstly, among projects on my job, I have a lot of security audits of different online banking applications. 6 00:00:43,660 --> 00:00:52,460 And during these projects, I met and we met a lot of different vulnerabilities and other interesting things. 7 00:00:52,460 --> 00:00:59,320 So, in this presentation, I want to share with you some experience that I got and some interesting things. 8 00:00:59,320 --> 00:01:12,720 And so, this talk will be interesting for offensive and defensive specialists that work with online banking applications. 9 00:01:12,720 --> 00:01:23,420 And also, it will be interesting for developers who work with online banking and who is trying to make it safer. 10 00:01:25,100 --> 00:01:30,620 But I tried to make this presentation with a growing difficulty level. 11 00:01:30,620 --> 00:01:37,300 So, I hope everyone can get something new from this presentation and get something interesting from this presentation. 12 00:01:37,300 --> 00:01:42,140 So, let's talk about the structure of this presentation, about what we are going to talk about. 13 00:01:42,300 --> 00: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. 14 00:01:54,280 --> 00:01:59,320 We will talk about web banking, mobile banking, what differences between them. 15 00:01:59,320 --> 00: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. 16 00:02:22,450 --> 00: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. 17 00:02:42,700 --> 00:02:48,440 And also, we will talk about best practices of how to avoid this vulnerability, its vulnerabilities. 18 00:02:48,440 --> 00:02:50,720 So, let's begin from the differences. 19 00:02:51,560 --> 00:02:54,240 What is remote banking services? 20 00:02:54,380 --> 00:03:00,400 It is when the client doesn't need to go to the office to do some actions in bank. 21 00:03:00,400 --> 00:03:08,820 For transferring money, for checking the balance of the account, and some other things. 22 00:03:09,060 --> 00:03:10,700 So, it can be anything. 23 00:03:10,700 --> 00: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. 24 00:03:18,680 --> 00: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. 25 00:03:29,100 --> 00:03:34,900 But there is another type of banking services, it is online banking. 26 00:03:34,900 --> 00: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. 27 00:03:42,660 --> 00:03:46,160 So, online banking, it is web banking and mobile banking. 28 00:03:46,160 --> 00: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. 29 00:04:00,260 --> 00: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. 30 00:04:15,580 --> 00:04:21,600 So, today, we're going to talk about online banking, about web and mobile banking, yeah. 31 00:04:21,600 --> 00:04:26,920 And so, we're going to... and all vulnerabilities will be related to these types. 32 00:04:27,260 --> 00:04:32,560 So, let's talk about how does it work. 33 00:04:32,560 --> 00: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. 34 00:04:41,560 --> 00:04:47,900 We are not going to talk about infrastructure, our bank infrastructure, about processing, and other very, very complex things. 35 00:04:47,900 --> 00:04:53,580 It is magic for us today, and it is like a black box for us. 36 00:04:53,580 --> 00:04:58,180 And so, we're going to talk about the server side, about the API, yeah. 37 00:04:58,580 --> 00:05:01,100 We're going to talk about the frontend mobile. 38 00:05:01,160 --> 00:05:09,160 Frontend, it is something that loads in the browser of clients. 39 00:05:09,160 --> 00: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. 40 00:05:20,480 --> 00:05:23,840 Maybe there are banks with IAC requests, but I don't know. 41 00:05:23,880 --> 00:05:26,080 They didn't meet it. 42 00:05:26,160 --> 00:05:33,840 So, mobile, it is totally the same, but mobile application, it is like a custom-made browser. 43 00:05:34,020 --> 00:05:40,600 And frontend and mobile, work with API, yeah, with server side. 44 00:05:40,600 --> 00: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. 45 00:06:00,500 --> 00: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. 46 00:06:15,260 --> 00:06:17,600 Sometimes, maybe there are differences. 47 00:06:17,600 --> 00:06:25,520 Maybe it is split API, so different API for frontend, and different API for mobile. 48 00:06:25,520 --> 00:06:27,940 But usually, usually, it is the same. 49 00:06:28,200 --> 00:06:40,140 And API, it is like something between... it is an application that helps us to work with bank infrastructure. 50 00:06:40,280 --> 00:06:47,560 It has API methods, it has some functionality that can be used by frontend, and that can be used by mobile. 51 00:06:47,680 --> 00:06:54,920 And after that, it sends to bank infrastructure, and there is some magic in bank infrastructure. 52 00:06:55,640 --> 00:06:58,400 The bank infrastructure is very, very complex. 53 00:06:58,400 --> 00:06:59,380 It can be anything. 54 00:06:59,380 --> 00:07:04,320 It can be monolith, it can be microservices, yeah. 55 00:07:04,320 --> 00:07:11,600 And so, but today, it will be bank infrastructure, and API, it will be server-side for us. 56 00:07:13,080 --> 00:07:19,140 And I think it is all that I wanted to say about how does it work. 57 00:07:19,840 --> 00:07:21,580 Again, it is very, very simple. 58 00:07:21,580 --> 00:07:25,860 And we can't talk more detail, because it needs a lot of time. 59 00:07:26,640 --> 00:07:27,900 It is a huge topic. 60 00:07:28,480 --> 00:07:32,700 So, testing approaches of server-side and bank infrastructure. 61 00:07:32,740 --> 00:07:36,380 Usually, it is... API, it is usual web application, yeah. 62 00:07:36,380 --> 00:07:39,740 And bank infrastructure, it is a very complex thing. 63 00:07:39,740 --> 00:07:43,220 It is like Zoho with different services. 64 00:07:43,220 --> 00:07:44,780 It can be anything. 65 00:07:44,820 --> 00:07:52,640 And so, it is very hard to hack it without understanding how does it work. 66 00:07:52,640 --> 00: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. 67 00:08:00,040 --> 00:08:04,540 And it is only one way to understand how to hack the bank infrastructure. 68 00:08:04,600 --> 00:08:12,000 So, API, it is usual web application, so it can have any web vulnerabilities. 69 00:08:12,480 --> 00:08:18,420 So, if I'm talking about the possible vulnerabilities, like I said, it is usual web vulnerabilities. 70 00:08:18,420 --> 00:08:21,100 Yeah, it is everything from the OWASP. 71 00:08:21,100 --> 00:08:29,740 Yeah, you just can take the checklist of OWASP and any vulnerability and the most related to the server-side. 72 00:08:29,740 --> 00:08:32,180 So, also, it is misconfigurations. 73 00:08:32,180 --> 00:08:38,300 It can be anything like Nginx misconfigurations, maybe other things. 74 00:08:38,300 --> 00:08:52,240 And also, it is logical vulnerabilities, because the bank and the mobile banking, online banking, it is very, very complex thing. 75 00:08:52,240 --> 00:08:57,060 Yeah, it has very, very complex architecture. 76 00:08:57,060 --> 00:09:03,840 And so, when architecture is complex, developers can do a lot of mistakes in this. 77 00:09:03,840 --> 00:09:15,000 And so, it can be any logical vulnerabilities, like, I don't know, leakage of sensitive data of clients. 78 00:09:15,820 --> 00: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. 79 00:09:32,860 --> 00:09:36,300 And other vulnerabilities, it is only example. 80 00:09:36,300 --> 00:09:40,540 So, it can be anything. 81 00:09:41,200 --> 00:09:43,880 Next one, it is front-end. 82 00:09:43,880 --> 00:09:47,340 So, it is user interface. 83 00:09:47,340 --> 00:09:51,060 Yeah, based on the data received from API. 84 00:09:51,060 --> 00:10:00,400 And so, and because it loads in browser, yeah, browser take a lot of security job on itself. 85 00:10:00,400 --> 00: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. 86 00:10:13,060 --> 00:10:20,700 But in mobile applications, developers have to do the things by itself. 87 00:10:21,600 --> 00:10:30,860 And possible vulnerabilities, it is XSS, it is, I don't know, DOM-based XSS, it is CSRF, yeah. 88 00:10:30,860 --> 00:10:35,460 Maybe forgotten or maybe unfinished pages, yeah. 89 00:10:35,460 --> 00: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. 90 00:10:51,700 --> 00:10:55,340 But anyway, they exist in production. 91 00:10:55,340 --> 00: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. 92 00:11:25,840 --> 00:11:31,060 And also, it can be unsafe communication with API server. 93 00:11:31,840 --> 00:11:41,220 And it is everything about the society, it is everything about communication, maybe other algorithms and so on, so on. 94 00:11:41,300 --> 00:11:44,920 And again, it is only examples, maybe there are another ones. 95 00:11:45,040 --> 00:11:47,400 There are another ones, of course, there are. 96 00:11:48,440 --> 00:11:54,900 So, if we're talking about mobile testing approaches, yeah. 97 00:11:55,100 --> 00:12:00,720 Like I said, mobile, it is an application, it is like custom-made browser. 98 00:12:01,020 --> 00:12:13,320 And in this case, you have a lot of, I don't know, security and customization features, yeah. 99 00:12:13,320 --> 00:12:17,360 And so, you have a lot of possibilities to do something wrong. 100 00:12:17,660 --> 00:12:25,520 And in this case, possible vulnerabilities, it is storing of sensitive data, yeah. 101 00:12:25,720 --> 00:12:31,040 And we will talk about this in one example a little bit later. 102 00:12:31,040 --> 00:12:35,500 So, also, it is unsafe handling of external data. 103 00:12:35,520 --> 00:12:51,960 And because there is one good example of vulnerability, when mobile application got external data and save it to SQLite database. 104 00:12:51,960 --> 00:12:55,140 So, and there was a SQL injection in this. 105 00:12:55,140 --> 00: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. 106 00:13:10,420 --> 00:13:11,940 It is very interesting thing. 107 00:13:12,020 --> 00:13:16,900 So, also, it is unsafe work with mobile platform. 108 00:13:16,900 --> 00:13:21,740 It is, for example, IPC mechanism and other things, maybe. 109 00:13:22,180 --> 00:13:26,140 And also, there are a lot of different things. 110 00:13:26,780 --> 00:13:35,200 And let's talk about testing guides, testing approaches for every type of online banking, yeah. 111 00:13:35,200 --> 00: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. 112 00:13:51,780 --> 00:13:59,060 But, no, I just didn't find any other good guides except Avast per Web and Avast per MSTG. 113 00:13:59,060 --> 00:14:06,160 So, maybe, you know, and if you use something else, you can maybe share it in comments. 114 00:14:06,160 --> 00:14:08,520 So, it is really good because... 115 00:14:11,440 --> 00:14:17,080 but for web banking, we also usually use Avast per Web, yeah. 116 00:14:17,080 --> 00:14:21,840 It has very good checklist and it has a lot of different vulnerabilities. 117 00:14:21,840 --> 00:14:29,840 So, it is really great and good job of someone who made this, yeah, of people who made this. 118 00:14:29,840 --> 00:14:39,680 And so, mobile banking, it is Avast per MSTG and Avast Web guides. 119 00:14:39,680 --> 00: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. 120 00:14:50,220 --> 00:14:53,260 And why Avast per Web here? 121 00:14:53,260 --> 00: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. 122 00:15:13,940 --> 00:15:18,360 So, for the platform, for the application, we use Avast per MSTG. 123 00:15:18,360 --> 00:15:22,100 And for the service side, we use Avast Web. 124 00:15:22,100 --> 00:15:28,020 And it has maybe some intersections, yeah. 125 00:15:28,020 --> 00:15:33,840 And so, in the best way, this intersection should be fixed, yeah. 126 00:15:33,840 --> 00:15:42,760 And the best way is to have that one big checklist and one big guide. 127 00:15:42,900 --> 00: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. 128 00:15:55,100 --> 00:16:01,660 So, after that, we begin to talk about vulnerabilities. 129 00:16:01,880 --> 00:16:09,060 And now it is the biggest part and we will talk about this until the finish of the presentation. 130 00:16:10,100 --> 00:16:14,360 And firstly, I want to say why I choose this vulnerability. 131 00:16:15,340 --> 00:16:23,360 There are three options and there are three reasons why I choose this. 132 00:16:23,360 --> 00:16:30,740 Firstly, it is, for example, some vulnerabilities are very common, you can meet it in a lot of different applications. 133 00:16:30,740 --> 00:16:33,320 And it is very common. 134 00:16:34,040 --> 00:16:37,980 And this is a problem. 135 00:16:37,980 --> 00:16:44,960 So, the second one reason, it is because some vulnerabilities are really interesting. 136 00:16:45,360 --> 00:16:47,760 And they are not common. 137 00:16:47,760 --> 00:16:51,260 Yeah, maybe it is very rare vulnerability. 138 00:16:51,260 --> 00:16:53,620 But anyway, it is really, really interesting. 139 00:16:53,620 --> 00:16:55,520 And it is like really hacking. 140 00:16:55,520 --> 00:16:58,980 And for example, like I said before, it is like making money from nothing. 141 00:16:58,980 --> 00:16:59,300 Yeah. 142 00:16:59,300 --> 00:17:00,320 And so on. 143 00:17:00,320 --> 00:17:03,300 And so, it is really, really interesting and I love it. 144 00:17:03,300 --> 00:17:10,140 And so, the third one reason, it is because sometimes some vulnerabilities are really hard to fix. 145 00:17:10,140 --> 00:17:10,540 Yeah. 146 00:17:10,540 --> 00:17:14,820 And developers are trying to fix it and make another vulnerability. 147 00:17:14,900 --> 00:17:20,640 And so, we will talk about... I don't remember one example of this vulnerability. 148 00:17:20,640 --> 00:17:25,240 And so, it... Okay, a little bit later we will talk about it. 149 00:17:25,240 --> 00:17:28,200 So, let's begin from the first one vulnerability. 150 00:17:29,020 --> 00:17:32,460 And first vulnerability, it is rounding attack. 151 00:17:32,460 --> 00:17:34,080 It is currency rounding attack. 152 00:17:34,080 --> 00:17:41,700 And it is one of my favorite vulnerability, because it is really, really hacking. 153 00:17:41,700 --> 00:17:46,880 Like I said before, and I talk about this vulnerability, it is like making money from nothing. 154 00:17:46,880 --> 00:17:47,240 Yeah. 155 00:17:47,240 --> 00:17:53,960 And so, first information that I found about this vulnerability, it was 2011, maybe 2012. 156 00:17:54,460 --> 00:17:58,300 Maybe there are early information, but I didn't find. 157 00:17:58,300 --> 00:18:08,500 So, this vulnerability based on the incorrect or unsafe using of round functions. 158 00:18:08,500 --> 00:18:09,220 Yeah. 159 00:18:09,380 --> 00:18:13,380 And later we will talk about example. 160 00:18:13,380 --> 00:18:17,620 But now, very, very simple example of using of round functions. 161 00:18:17,620 --> 00:18:19,720 And it is very simple. 162 00:18:20,180 --> 00:18:29,700 But for us, interesting last example, when we can... In round function, we can set what is... 163 00:18:30,740 --> 00:18:35,400 We can set the decimal places that will be after rounding. 164 00:18:35,400 --> 00:18:44,880 And as you can see on this example here, it is two decimal places after rounding. 165 00:18:44,880 --> 00:18:51,160 So, after rounding, we will get 1.52. 166 00:18:51,160 --> 00:18:51,780 Yeah. 167 00:18:51,900 --> 00: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. 168 00:19:03,120 --> 00:19:11,540 But... And for example, all banks already fixed it and all companies that work with money already fixed it too. 169 00:19:11,540 --> 00:19:14,460 And you can't meet it in real life. 170 00:19:14,460 --> 00:19:20,520 So, but no, there are examples and you can find it on Hacker One. 171 00:19:20,520 --> 00:19:26,380 And I met this vulnerability two years ago and I know one very huge bank. 172 00:19:26,380 --> 00:19:31,320 And so, no examples exist. 173 00:19:31,500 --> 00:19:36,200 So, let's watch the example. 174 00:19:36,200 --> 00:19:36,760 Yeah. 175 00:19:36,760 --> 00:19:41,320 For example, we have one account. 176 00:19:41,320 --> 00:19:41,600 Yeah. 177 00:19:41,600 --> 00:19:46,760 And this account has two wallets, USD and ruble wallets. 178 00:19:46,760 --> 00:19:47,000 Yeah. 179 00:19:47,000 --> 00:19:50,320 And you can transfer money between these wallets. 180 00:19:50,320 --> 00:19:58,060 And when you transfer money, the different currencies convert in between. 181 00:19:58,060 --> 00:19:58,200 Yeah. 182 00:19:58,200 --> 00:20:03,860 And for example, in this case, we have unreal rates. 183 00:20:03,860 --> 00:20:08,840 But anyway, it is very comfortable for us for calculations. 184 00:20:08,840 --> 00:20:16,820 So, current rates, it is 64 rubles for one dollar in case of buying. 185 00:20:16,820 --> 00:20:23,520 And the same 64 one USD in case of selling. 186 00:20:23,560 --> 00:20:29,500 And so, we have bank that use rounds into decimal places. 187 00:20:29,500 --> 00:20:29,860 Yeah. 188 00:20:29,860 --> 00:20:32,980 And our goal is to become rich. 189 00:20:32,980 --> 00:20:34,980 So, what we can do? 190 00:20:35,320 --> 00:20:37,360 Let's watch the attack. 191 00:20:37,360 --> 00:20:38,060 Yeah. 192 00:20:39,840 --> 00:20:52,360 We have, one second, we have one ruble on the ruble wallet and we send it to the USD wallet. 193 00:20:52,360 --> 00:20:58,380 And after rounding, yeah, firstly, we convert it to the USD. 194 00:20:58,380 --> 00:21:04,480 And after that, calls function rounding. 195 00:21:04,480 --> 00:21:11,560 And as a result, we will get 0.02 USD from one ruble. 196 00:21:11,560 --> 00:21:12,300 Yeah. 197 00:21:12,300 --> 00:21:20,540 After that, we convert, we send this two cents back to the ruble wallet. 198 00:21:20,540 --> 00:21:20,940 Yeah. 199 00:21:20,940 --> 00:21:27,600 And it will be already one ruble and 20. 200 00:21:27,600 --> 00:21:28,380 Yeah. 201 00:21:28,380 --> 00:21:33,520 And now we have profit 120%. 202 00:21:33,520 --> 00:21:36,120 Why it happened? 203 00:21:36,120 --> 00:21:38,700 This has happened because of this. 204 00:21:38,700 --> 00:21:41,500 This is main reason. 205 00:21:41,500 --> 00:21:49,080 So, we had one number and after wallet, it became more. 206 00:21:49,080 --> 00:21:49,460 Yeah. 207 00:21:49,460 --> 00:21:53,320 And this difference is very critical. 208 00:21:53,320 --> 00:21:55,440 So, we can get a big profit. 209 00:21:55,460 --> 00:22:02,020 And you can say that now we have two additional ruble cents. 210 00:22:02,020 --> 00:22:02,580 Yeah. 211 00:22:02,580 --> 00:22:05,940 And it is not rich. 212 00:22:05,940 --> 00:22:06,100 Yeah. 213 00:22:06,120 --> 00:22:14,560 But if you can repeat it 1,000 or maybe 1,000,000 times, you will get real money. 214 00:22:14,780 --> 00:22:21,880 I think banks not allowed to make this a lot of time because anti-fraud and some other things. 215 00:22:21,880 --> 00:22:28,780 But anyway, if this vulnerability exists, sometime someone can try to exploit it. 216 00:22:28,780 --> 00:22:33,560 And it is, I think, the best way to fix it anyway. 217 00:22:35,260 --> 00:22:39,900 So, and I have very simple plot. 218 00:22:39,900 --> 00:22:40,520 Yeah. 219 00:22:41,260 --> 00:22:46,140 Firstly, on the X, we have transfer amount rubles. 220 00:22:46,140 --> 00:22:46,880 Yeah. 221 00:22:46,880 --> 00:22:53,140 And the Y, we have profit and the persons. 222 00:22:53,140 --> 00: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. 223 00:23:07,740 --> 00:23:12,620 And in this case, the profit is the highest. 224 00:23:12,700 --> 00:23:13,120 Yeah. 225 00:23:13,860 --> 00:23:21,020 And as you can see, if we send more, yeah, the profit less, less, less. 226 00:23:21,020 --> 00:23:24,720 And after some specific moment, it is less than 100. 227 00:23:24,720 --> 00:23:27,120 So, it is non-profitable for us. 228 00:23:27,380 --> 00:23:35,560 And from this, you can see that it is first way to how to avoid this vulnerability. 229 00:23:35,560 --> 00:23:38,000 It is set the limit of transaction. 230 00:23:38,000 --> 00: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. 231 00:23:49,500 --> 00:23:55,380 So, also, there are two other ways. 232 00:23:55,380 --> 00:24:06,260 And second one, it is that we shouldn't allow to clients to convert money from rubles to USD. 233 00:24:06,260 --> 00:24:11,620 Instead of this, we should allow to buy USD. 234 00:24:11,620 --> 00:24:11,760 Yeah. 235 00:24:11,760 --> 00:24:20,160 For example, client will buy 0.01 USD. 236 00:24:20,600 --> 00:24:25,120 And after that, client will get price. 237 00:24:25,120 --> 00:24:30,700 And after that, they can finish the transaction. 238 00:24:30,700 --> 00:24:35,600 So, in this case, anyway, there is rounding. 239 00:24:35,600 --> 00:24:35,980 Yeah. 240 00:24:35,980 --> 00:24:37,620 And it will be. 241 00:24:37,620 --> 00:24:41,540 But in this case, numbers are higher. 242 00:24:41,540 --> 00:24:43,720 The numbers are bigger, sorry. 243 00:24:43,800 --> 00:24:50,520 And it will be unprofitable for anyone who is trying to exploit this vulnerability. 244 00:24:50,720 --> 00:24:52,440 So, and there is another way. 245 00:24:52,440 --> 00:24:56,580 It is adding commission after certain number of transaction. 246 00:24:56,580 --> 00:25:00,240 It is not looks like good way. 247 00:25:00,280 --> 00:25:03,920 But anyway, it works. 248 00:25:03,920 --> 00:25:09,620 And so, but it looks like not like good fix. 249 00:25:09,620 --> 00: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. 250 00:25:20,740 --> 00:25:27,080 So, another example, it is sensitive data disclosure. 251 00:25:27,080 --> 00:25:33,740 It is very common vulnerability that is you can meet in every and a lot of application. 252 00:25:33,740 --> 00:25:35,420 Not every, but a lot of. 253 00:25:35,420 --> 00:25:37,200 But maybe, maybe in every. 254 00:25:37,200 --> 00:25:38,240 I don't know. 255 00:25:38,960 --> 00:25:45,840 So, let's watch an example, good example, interesting example. 256 00:25:45,840 --> 00:25:51,000 And this example shows that what is convenient is not always safe. 257 00:25:51,000 --> 00:25:58,120 So, we should look for balance between convenient and for between security. 258 00:25:58,120 --> 00:25:59,820 And it is very important. 259 00:25:59,820 --> 00:26:10,720 And case, the bank added functionality that allowed to send money between cards without login procedure. 260 00:26:11,240 --> 00:26:14,960 So, it looked like this. 261 00:26:14,960 --> 00:26:21,100 So, user enters firstly information about source card, about their card. 262 00:26:21,100 --> 00:26:25,760 And after that, user enters the information about the destination card. 263 00:26:25,760 --> 00:26:28,220 It is only PAN code. 264 00:26:28,220 --> 00:26:32,060 In the first step, we enter the PAN, CVV and expired date. 265 00:26:32,060 --> 00:26:34,900 So, on the second, only PAN code. 266 00:26:34,900 --> 00:26:42,520 So, on the third step, user enters the amount of money for transfer. 267 00:26:42,860 --> 00:26:49,200 And on the next step, system checks the balance and calculates the commission. 268 00:26:49,200 --> 00:26:55,140 And if everything is okay, money is enough and so on, user gets SMS. 269 00:26:55,460 --> 00:27:00,500 The user that has the source card gets SMS. 270 00:27:01,220 --> 00:27:04,280 After entering the code, the transaction is done. 271 00:27:04,280 --> 00:27:05,800 If code is okay. 272 00:27:05,800 --> 00:27:13,220 So, let's watch into the HTTP request that was used for checking the balance. 273 00:27:13,220 --> 00:27:13,940 Yeah. 274 00:27:15,220 --> 00:27:19,340 And it was a problem. 275 00:27:19,340 --> 00:27:29,840 The main problem was that this server didn't check the expiry date and didn't check the security code. 276 00:27:29,840 --> 00:27:30,640 Yes. 277 00:27:30,680 --> 00:27:35,500 So, but it checked the money amount and card number. 278 00:27:35,620 --> 00:27:46,740 So, as a result, everyone could get balance for any card in the bank. 279 00:27:46,740 --> 00:27:52,700 So, just by enumerating the card number and just by enumerating the money amount. 280 00:27:52,820 --> 00:28:07,020 So, it worked like if you set too much money, yeah, server will return the error that money is not enough. 281 00:28:07,020 --> 00:28:07,320 Yeah. 282 00:28:07,320 --> 00:28:13,640 In other case, it will be everything's okay, enter please code. 283 00:28:13,640 --> 00:28:14,060 Yeah. 284 00:28:14,060 --> 00:28:15,500 Please enter the code. 285 00:28:15,560 --> 00:28:19,440 So, and you can set any card number. 286 00:28:19,440 --> 00:28:24,580 So, you can get information about every card in bank. 287 00:28:24,780 --> 00:28:26,660 And it is not so good. 288 00:28:26,660 --> 00:28:27,700 Now, it fixed. 289 00:28:28,420 --> 00:28:32,060 Next vulnerability, it is unsafe OTP. 290 00:28:32,760 --> 00:28:34,420 Firstly, what is OTP? 291 00:28:34,420 --> 00:28:36,460 OTP, it is one-time password. 292 00:28:36,740 --> 00:28:44,860 And it is usually one of the most popular realization of second factor. 293 00:28:44,860 --> 00:28:44,940 Yeah. 294 00:28:44,940 --> 00:28:47,840 For example, you enter to the mobile banking. 295 00:28:47,840 --> 00:28:48,080 Yeah. 296 00:28:48,080 --> 00:28:50,400 You enter your login and password. 297 00:28:50,460 --> 00:28:58,200 And after that, you get the SMS code or maybe push notification or maybe something like this. 298 00:28:58,200 --> 00:28:58,460 Yeah. 299 00:28:58,460 --> 00:29:05,980 And you have to enter it to pass the second factor of notification. 300 00:29:06,240 --> 00:29:10,900 And usually, usually, it deliver it via SMS. 301 00:29:10,900 --> 00:29:11,220 Yeah. 302 00:29:11,220 --> 00:29:15,540 And it is the most popular way for delivering. 303 00:29:15,820 --> 00:29:20,400 So, let's watch an example. 304 00:29:20,440 --> 00:29:22,040 Yeah, we are hacker. 305 00:29:22,040 --> 00:29:22,440 Yeah. 306 00:29:22,440 --> 00:29:25,520 And we got access to user account. 307 00:29:25,780 --> 00:29:29,220 And so, we want to get money of this client. 308 00:29:29,220 --> 00:29:36,660 So, we have to send this money from our account to the... from user account to our account. 309 00:29:36,660 --> 00:29:37,260 Yeah. 310 00:29:37,300 --> 00:29:42,420 So, and for completing this transaction, we have to enter the correct OTP. 311 00:29:42,420 --> 00:29:48,320 This OTP sends to the mobile of the client and owner of this account. 312 00:29:48,320 --> 00:29:50,400 And so, we don't know this OTP. 313 00:29:50,400 --> 00:29:52,060 But we have to enter it. 314 00:29:52,060 --> 00:29:58,740 And so, after free and correct... and every time when we create a transaction, we have only three tries. 315 00:29:58,740 --> 00:30:03,200 After three incorrect entries, transaction will be canceled. 316 00:30:03,540 --> 00:30:10,120 And OTP has four random digits. 317 00:30:10,120 --> 00:30:11,060 Yeah, digits. 318 00:30:11,360 --> 00:30:15,080 And it is, for example, one, two, three, four. 319 00:30:15,080 --> 00:30:15,680 Yeah. 320 00:30:17,180 --> 00:30:21,980 So, how to make this transaction? 321 00:30:21,980 --> 00:30:23,340 How to finish this transaction? 322 00:30:26,040 --> 00:30:30,240 It is like a little bit strange. 323 00:30:30,240 --> 00:30:35,300 But what if instead of brute-forcing OTP, yeah, we will try to brute-force transactions. 324 00:30:35,600 --> 00:30:35,940 Yeah. 325 00:30:35,960 --> 00:30:40,100 What if it will be not brute-forcing, but it will be guessing? 326 00:30:40,640 --> 00:30:41,480 Sounds strange. 327 00:30:41,480 --> 00:30:42,980 I'll explain. 328 00:30:42,980 --> 00:30:43,720 Okay. 329 00:30:44,540 --> 00:30:45,800 Very important thing. 330 00:30:45,800 --> 00: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. 331 00:30:55,900 --> 00:30:58,460 We choose three different OTP. 332 00:30:58,560 --> 00:30:59,080 Yeah. 333 00:30:59,500 --> 00:31:03,880 It should be a potential correct OTP. 334 00:31:03,880 --> 00:31:09,260 One, two, three, four, I don't know, five, five, five, five, six, six, six, six. 335 00:31:09,260 --> 00:31:09,760 Yeah. 336 00:31:09,760 --> 00:31:12,380 And after that, we create new transaction. 337 00:31:12,760 --> 00:31:15,520 And try choosing OTP. 338 00:31:15,880 --> 00:31:16,620 Yeah. 339 00:31:17,120 --> 00:31:21,540 If it isn't correct, to step two and create new transaction. 340 00:31:21,680 --> 00:31:28,220 But on this moment, it is, but every transaction, it is regenerate the OTP. 341 00:31:28,280 --> 00:31:31,240 So, we can just brute-force it. 342 00:31:31,240 --> 00:31:34,320 We can just take the one big dictionary. 343 00:31:34,320 --> 00:31:34,600 Yeah. 344 00:31:34,600 --> 00:31:40,660 And using this dictionary to enumerate, to brute-force all existing OTP. 345 00:31:40,660 --> 00:31:42,120 No, it doesn't work like this. 346 00:31:42,120 --> 00:31:45,800 But it is very, very similar. 347 00:31:45,800 --> 00:31:46,340 Yeah. 348 00:31:46,340 --> 00:31:53,340 So, and we should repeat this algorithm, this exploitation until we matched at least one OTP. 349 00:31:53,540 --> 00:31:59,240 If we matched at least one OTP, the transaction will be finished. 350 00:31:59,240 --> 00:31:59,500 Yeah. 351 00:31:59,500 --> 00:32:02,320 And so, it is one big difference. 352 00:32:02,320 --> 00:32:04,420 It looks like brute-force, but it isn't brute-force. 353 00:32:04,420 --> 00:32:05,440 It is guessing. 354 00:32:05,440 --> 00:32:11,020 So, in case of brute-force, we know about when it will be finished. 355 00:32:11,020 --> 00:32:15,460 For example, dictionary has size 10,000 lines. 356 00:32:15,460 --> 00:32:21,540 So, it will be finished after trying of 10,000 lines. 357 00:32:21,540 --> 00:32:26,980 So, in case of this brute-force, yeah, but it is guessing. 358 00:32:27,220 --> 00:32:29,460 We're not sure when it will be finished. 359 00:32:29,460 --> 00:32:37,440 It can be finished on the next transaction, or it can be finished after 20,000 transactions. 360 00:32:37,440 --> 00:32:37,740 Yeah. 361 00:32:37,740 --> 00:32:38,640 We're guessing. 362 00:32:38,640 --> 00:32:41,260 We're trying to enumerate transactions. 363 00:32:41,400 --> 00:32:41,800 Yeah. 364 00:32:41,800 --> 00:32:50,140 Until the generated OTP didn't match our OTP. 365 00:32:51,100 --> 00:32:53,980 So, I'll explain everything. 366 00:32:54,520 --> 00:32:55,780 No, I'm joking. 367 00:32:55,780 --> 00:32:56,820 I am not going. 368 00:32:56,820 --> 00:32:57,700 It is boring. 369 00:32:57,700 --> 00:32:59,220 So, no, no, no. 370 00:32:59,220 --> 00:33:01,860 But it is very interesting results. 371 00:33:01,860 --> 00:33:03,320 Let's watch the results. 372 00:33:03,320 --> 00:33:08,020 So, probability of the successful transaction depends on the number of attempts. 373 00:33:08,020 --> 00:33:19,460 So, in our guessing exploitation, yeah, after 3,000 attempts, then it will be about 60% probability. 374 00:33:19,460 --> 00:33:19,820 Yeah. 375 00:33:19,820 --> 00:33:25,520 But if we can try 16,000 attempts, it will be 99%. 376 00:33:25,520 --> 00:33:30,440 So, it is a really good result, I think. 377 00:33:31,340 --> 00:33:39,040 And let's watch a little bit more complex example with new limitations. 378 00:33:39,100 --> 00:33:44,020 The same example, totally the same OTP, totally the same situation, and so on. 379 00:33:44,020 --> 00:33:49,200 But after five canceled transactions, we can't create a new one. 380 00:33:49,200 --> 00:33:51,460 We will be blocked for several times. 381 00:33:51,460 --> 00:33:54,620 For example, for 24 hours. 382 00:33:54,640 --> 00:33:55,260 Yeah. 383 00:33:55,280 --> 00:33:57,480 And so, what we can do in this case? 384 00:33:58,060 --> 00:34:00,740 There are two possible approaches. 385 00:34:00,880 --> 00: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. 386 00:34:16,600 --> 00:34:21,420 So, in this case, we avoid the cancellation of transaction. 387 00:34:21,420 --> 00:34:28,160 And in this case, creation of transaction will not be blocked. 388 00:34:28,480 --> 00:34:28,780 Yeah. 389 00:34:28,780 --> 00:34:30,820 So, it is one approach. 390 00:34:30,840 --> 00:34:36,160 Another one, we can, in the beginning, create several thousands of transactions. 391 00:34:36,160 --> 00:34:36,260 Yeah. 392 00:34:36,260 --> 00:34:42,260 For example, we can create 20,000 of transactions, and only after that, we will try the OTP. 393 00:34:42,280 --> 00:34:48,780 So, in this case, yeah, we will block the creation of new transactions after trying the OTP. 394 00:34:48,780 --> 00:34:49,100 Yeah. 395 00:34:49,100 --> 00:34:51,180 But it is not affected. 396 00:34:51,180 --> 00:34:57,100 It doesn't affect us, because we already created the 20,000. 397 00:34:57,100 --> 00: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. 398 00:35:07,700 --> 00:35:14,580 So, we will get profit. 399 00:35:15,020 --> 00:35:19,980 So, and also, very good question. 400 00:35:19,980 --> 00:35:24,300 Is SMS a secure way of OTP delivery? 401 00:35:24,300 --> 00:35:24,780 Yeah. 402 00:35:24,780 --> 00:35:32,420 It is a good question, because there are a lot of attacks against the SMS. 403 00:35:32,420 --> 00:35:34,520 It can be fake BTS. 404 00:35:34,520 --> 00:35:36,500 It can be ratio of SIM card. 405 00:35:36,500 --> 00:35:38,220 It can be SS7 attacks. 406 00:35:38,220 --> 00:35:38,600 Yeah. 407 00:35:38,600 --> 00:35:41,420 For example, these two very 408 00:35:45,700 --> 00:35:53,160 cheap things, it can be used for creating the fake BTS, for creating the fake station. 409 00:35:53,160 --> 00:35:53,480 Yeah. 410 00:35:53,480 --> 00:35:59,920 And using this, you can try to attack the client. 411 00:36:02,360 --> 00:36:09,560 So, let's talk about the recommendations. 412 00:36:09,560 --> 00:36:10,440 Yeah. 413 00:36:10,440 --> 00:36:15,800 Firstly, second factor should be enabled for all critical actions. 414 00:36:15,800 --> 00:36:16,060 Yeah. 415 00:36:16,060 --> 00: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. 416 00:36:38,420 --> 00:36:45,240 Also, it is very important to limit the count of requested OTP. 417 00:36:45,240 --> 00:36:53,540 On the previous examples, we tried to limit the creating of transactions, but sometimes it is a little bit hard. 418 00:36:53,540 --> 00:36:57,100 Maybe you can make another vulnerability and so on. 419 00:36:57,100 --> 00:37:01,570 So, the best way is to control the OTP. 420 00:37:01,570 --> 00:37:09,370 So, how many OTP, how many generation of OTP client asked. 421 00:37:09,370 --> 00:37:09,730 Yeah. 422 00:37:09,730 --> 00:37:13,450 And after specific count, just stop this process. 423 00:37:13,630 --> 00: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. 424 00:37:28,070 --> 00:37:33,950 For example, we can watch on the push notification, we can watch on the TOTP and HOTP. 425 00:37:33,950 --> 00:37:39,510 TOTP and HOTP, it is, for example, Google notification, it is Microsoft notification. 426 00:37:39,510 --> 00:37:50,730 It is applications that you have on your mobile phone and they use cryptography for OTP process. 427 00:37:50,830 --> 00:38:07,350 So, it is totally silent because it doesn't have delivering. 428 00:38:07,350 --> 00:38:07,750 Yeah. 429 00:38:07,750 --> 00:38:16,410 So, client doesn't know about that someone trying to brute force its second factor. 430 00:38:16,630 --> 00:38:17,390 Yeah. 431 00:38:17,770 --> 00: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. 432 00:38:39,390 --> 00:38:43,230 And so, maybe attack will be stopped. 433 00:38:43,230 --> 00:38:49,110 But in case of TOTP and HOTP, it doesn't look like this. 434 00:38:49,290 --> 00:38:54,690 Next vulnerability, it is unsafe randomization. 435 00:38:55,970 --> 00:39:04,330 And it is, you can meet it in application where logic is based on the generation of random values. 436 00:39:04,330 --> 00:39:09,770 It can be sessions, it can be OTP, maybe unique identifiers. 437 00:39:10,130 --> 00:39:10,690 Yeah. 438 00:39:10,690 --> 00:39:26,170 And it is, for example, most common problems, it is using of unsafe predictable random numbers generators. 439 00:39:26,170 --> 00:39:26,390 Yeah. 440 00:39:26,390 --> 00: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. 441 00:39:36,090 --> 00:39:45,550 So, in a case when attacker can recover the sequence of random values. 442 00:39:45,550 --> 00:39:45,770 Yeah. 443 00:39:45,770 --> 00:39:53,190 And it can be in case, for example, incorrect initialization of random number generator and so on. 444 00:39:53,190 --> 00: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. 445 00:40:09,490 --> 00:40:11,010 Okay, never mind. 446 00:40:12,770 --> 00:40:18,770 A team of Russian engineers, so maybe one engineer, reversed the slot machine. 447 00:40:18,770 --> 00:40:19,110 Yeah. 448 00:40:19,110 --> 00:40:23,670 And they recovered the sequence. 449 00:40:23,670 --> 00:40:28,610 They recovered it of algorithm, how it used randomization. 450 00:40:28,610 --> 00:40:29,150 Yeah. 451 00:40:29,150 --> 00:40:33,730 And they developed their program. 452 00:40:33,730 --> 00:40:43,530 I don't know what they did, but they, for example, they developed a program that helped to recover this sequence. 453 00:40:43,530 --> 00:40:46,730 For example, they came to the slot machine. 454 00:40:46,730 --> 00:40:49,430 They played for several minutes. 455 00:40:49,430 --> 00:40:58,150 And in these several minutes, they got the sequence what slot machine showed to them. 456 00:40:58,150 --> 00:40:58,410 Yeah. 457 00:40:58,410 --> 00:41:06,590 And using this information, they recovered them all sequence of random. 458 00:41:06,590 --> 00:41:11,730 And they can... and they know what will be in the future. 459 00:41:11,730 --> 00:41:18,050 And so, using this cheat, they can... they did a lot of money. 460 00:41:18,050 --> 00:41:21,250 And so, it is one of the good examples. 461 00:41:21,250 --> 00:41:25,890 And so, another one good example, I heard from Timur Inusov. 462 00:41:25,890 --> 00:41:31,990 And he met... it is on his project. 463 00:41:31,990 --> 00:41:43,670 So , for OTP generation was used LCG generator, yeah, for randomization. 464 00:41:43,670 --> 00:41:50,690 So, but using of LCG is not okay, because it is not cryptography safe. 465 00:41:51,570 --> 00:42:00,130 And for example, when you have a sequence of several generated codes, you can recover all sequence. 466 00:42:00,130 --> 00:42:03,130 So, you can predict next OTP codes. 467 00:42:03,370 --> 00:42:06,890 And for OTP, it is very critical. 468 00:42:07,170 --> 00:42:11,670 So, something like this. 469 00:42:12,550 --> 00:42:16,990 Another vulnerability, it is mobile banking identification. 470 00:42:17,110 --> 00:42:26,250 Yeah, it is not vulnerability, but it is like evolution, yeah, for mobile banking identification. 471 00:42:26,250 --> 00:42:27,710 I'll explain, okay. 472 00:42:27,710 --> 00:42:29,510 For example, we have case. 473 00:42:29,510 --> 00: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. 474 00:42:44,930 --> 00:42:50,070 And so, client has very strong password, yeah. 475 00:42:50,070 --> 00:42:59,910 And on the mobile phone, and the very strong password is not convenient, yeah, and it's not so comfortable. 476 00:42:59,910 --> 00:43:11,250 And so, our task is to develop the simple authentication process, and that works after first login. 477 00:43:11,250 --> 00:43:15,030 For example, first time a user enters their login and password. 478 00:43:15,030 --> 00:43:21,590 After that, something happens, and user can enter there more simply. 479 00:43:21,730 --> 00:43:24,470 Yeah, for example, using PIN code or something like this. 480 00:43:24,470 --> 00:43:30,210 And so, let's try to make this solution, yeah. 481 00:43:30,210 --> 00:43:33,390 Firstly, what is the most simple way? 482 00:43:33,390 --> 00: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. 483 00:43:50,790 --> 00:43:52,890 It is awful. 484 00:43:52,890 --> 00:43:55,070 It is totally unsafe. 485 00:43:56,770 --> 00:44:02,650 Because of the saving of password, it is awful practice by design. 486 00:44:02,650 --> 00:44:03,810 Do not do this. 487 00:44:03,810 --> 00:44:05,230 It is awful. 488 00:44:05,790 --> 00:44:10,610 The second problem that unlocked device provides access to mobile functions. 489 00:44:10,610 --> 00: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. 490 00:44:26,890 --> 00:44:27,510 Yeah. 491 00:44:27,630 --> 00:44:32,190 So, in this case, anyone can just use the mobile one. 492 00:44:32,190 --> 00:44:33,430 It isn't okay. 493 00:44:34,330 --> 00: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. 494 00:44:45,210 --> 00:44:53,270 So, and the third one, the hacker can get access to the file with password, yeah. 495 00:44:53,270 --> 00: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. 496 00:45:04,910 --> 00:45:11,090 And in this case, hacker can just open any file on the file system, almost. 497 00:45:11,250 --> 00:45:19,510 So, another case, after successful login, yeah, user sets the PIN code. 498 00:45:20,030 --> 00: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. 499 00:45:33,030 --> 00: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. 500 00:45:46,930 --> 00:45:52,290 So, after first login, yeah, user set PIN code. 501 00:45:52,290 --> 00:45:57,070 This PIN code used for decrypting encrypted refresh token, yeah. 502 00:45:57,070 --> 00:46:04,250 So, and also, this PIN code used for checking the access. 503 00:46:04,250 --> 00: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. 504 00:46:23,550 --> 00: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. 505 00:46:45,050 --> 00: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. 506 00:46:59,110 --> 00: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. 507 00:47:10,310 --> 00:47:12,910 So, it doesn't work like this. 508 00:47:12,950 --> 00:47:20,310 So, next realization, we save refresh token to the kstore kchain, yeah. 509 00:47:20,310 --> 00: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. 510 00:47:40,610 --> 00:47:44,890 In this case, hacker can't get access to these records in kchain. 511 00:47:44,890 --> 00: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. 512 00:48:02,150 --> 00:48:11,050 Not totally, but unsafe, because of a hacker with root access can just extract it without any problems. 513 00:48:11,050 --> 00:48:17,190 So, also, it can be problematic if a user has old device. 514 00:48:17,330 --> 00:48:29,670 And in this case, maybe problems with kstore kchain, maybe just device don't have enough security functions, and so on. 515 00:48:29,670 --> 00: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. 516 00:48:39,050 --> 00:48:46,050 So, if there are some problems with this, you have problems with the application. 517 00:48:46,920 --> 00:49:00,670 And the last one realization, application asks user to set pin code, and this pin code will be sent to API. 518 00:49:00,690 --> 00:49:04,930 So, API controls the identification process. 519 00:49:04,930 --> 00:49:12,670 And in this case, you can control anything, like brute force, like enumeration, and other things. 520 00:49:12,670 --> 00:49:14,730 So, you can control anything. 521 00:49:14,730 --> 00:49:17,950 In this case, it is totally the same. 522 00:49:18,990 --> 00: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. 523 00:49:27,950 --> 00:49:36,130 In case of the last realization, user can use any pin code, because it is no limitation. 524 00:49:36,130 --> 00: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. 525 00:49:47,900 --> 00: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. 526 00:49:59,220 --> 00:50:02,820 That's all that I wanted to show you. 527 00:50:02,820 --> 00:50:04,800 So, now about conclusions. 528 00:50:05,380 --> 00:50:10,120 Firstly, there are good testing guides. 529 00:50:10,120 --> 00:50:12,060 There are good testing approaches. 530 00:50:12,060 --> 00: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. 531 00:50:20,960 --> 00:50:24,200 And it is really useful. 532 00:50:24,200 --> 00:50:27,140 It has a lot of examples, and so on. 533 00:50:27,320 --> 00:50:32,620 Also, the next conclusion is sometimes convenience is the enemy of security. 534 00:50:32,620 --> 00: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. 535 00:50:44,600 --> 00:50:47,180 It is sometimes too critical, yeah. 536 00:50:47,180 --> 00:50:53,820 And so, it is very important to find the compromise between convenience and between security. 537 00:50:54,260 --> 00: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. 538 00:51:03,720 --> 00:51:07,900 And just don't use cryptography without understanding. 539 00:51:07,900 --> 00:51:09,960 It is bad practice. 540 00:51:10,300 --> 00:51:18,680 And the last one conclusion is use best practices, and use experience of other companies. 541 00:51:19,000 --> 00:51:34,540 Watch on other products, watch on other applications, because a lot of problems, yeah, and some companies already solved these problems. 542 00:51:34,540 --> 00:51:41,140 And if you find the correct solution, it will be very good. 543 00:51:41,500 --> 00:51:47,100 And so, it is everything that I wanted to say. 544 00:51:47,420 --> 00:51:49,120 So, thank you for attention. 545 00:51:49,120 --> 00:51:53,620 I hope you got something new from this presentation. 546 00:51:53,620 --> 00:51:54,720 Thank you.