start	end	text
1880	7820	Hello, my name is Arkady Litvinenko. I'm a lead penetration tester in a Russian company that
7820	16760	has the name Bizon. Also, I'm one of the organizers of the Russian conference of ZON in Moscow,
17240	27540	and one of the organizers of CTF ZON competitions, CTF, and also a co-author of DEFCON CTF.
27540	37020	So, today we will talk about online banking security. And firstly, among projects on my
37020	44480	job, I have a lot of security audits of different online banking applications. And during these
44480	52460	projects, I met and we met a lot of different vulnerabilities and other interesting things.
52460	58340	So, in this presentation, I want to share with you some experience that I got and some interesting
58340	69040	things. And so, this talk will be interesting for offensive and defensive specialists that
69820	77240	work with online banking applications. And also, it will be interesting for developers who
78400	83420	work with online banking and who is trying to make it safer.
85100	92000	But I tried to make this presentation with a growing difficulty level. So, I hope everyone
92000	97300	can get something new from this presentation and get something interesting from this presentation.
97300	101560	So, let's talk about the structure of this presentation, about what we are going to talk
101560	111040	about. So, firstly, we will talk about differences, about remote banking and online banking, and what
111040	117560	is remote banking and what is online banking. We will talk about web banking, mobile banking,
117560	124620	what differences between them. And after that, we will talk about testing approaches,
125030	134450	and how to test the web, mobile, and the server side of mobile banking, and what differences,
134920	141360	what guides we can use for this, and we usually use on our projects.
142450	150960	And the biggest part of this presentation, it will be vulnerability examples with detailed
150960	160300	information, how it works, how to exploit it, and maybe some bad practices of fixing it,
160300	166420	of avoiding it, and so on. And also, we will talk about best practices of how to avoid this
166420	173080	vulnerability, its vulnerabilities. So, let's begin from the differences. What is remote banking
173080	180540	services? It is when the client doesn't need to go to the office to do some actions in bank. For
181320	188820	transferring money, for checking the balance of the account, and some other things.
189060	195620	So, it can be anything. It can be ATM, it can be call center, it can be SMS banking, and also,
195620	204120	it can be a web and mobile banking. For example, we're going to get cash from the account, so we
204120	210520	come to ATM, and it is one of the examples of remote banking services. But there is another
211100	217260	type of banking services, it is online banking. It is not another, it is part of remote banking
217260	223920	services, but it is a thing that we are going to talk about today. So, online banking, it is
223920	230040	web banking and mobile banking. So, web banking, it is when you open the website of
231580	235920	a bank on the browser and do some actions, and for example, log into your account and do some
235920	242700	actions, maybe transfer money, checking balance, and other, and other. So, in mobile, it is totally
242700	249140	the same, but you have to download the application to your mobile, and after that, again, you log
249140	259360	into the account and do some actions. So, today, we're going to talk about online banking,
259360	265700	about web and mobile banking, yeah. And so, we're going to... and all vulnerabilities will be related
265700	274860	to these types. So, let's talk about how does it work. It is very, very simple image, yeah,
274860	282620	but it is a good image for showing that we're going to talk about. We are not going to talk
282620	287260	about infrastructure, our bank infrastructure, about processing, and other very, very complex
287260	294580	things. It is magic for us today, and it is like a black box for us. And so, we're going to talk
294580	301800	about the server side, about the API, yeah. We're going to talk about the frontend mobile. Frontend,
301800	313440	it is something that loads in the browser of clients. So, it can be Angular, it can be React
313440	320620	application, it can be HTML with IAC request, but it doesn't work like this now, usually. Maybe
320620	328960	there are banks with IAC requests, but I don't know. They didn't meet it. So, mobile, it is
328960	336940	totally the same, but mobile application, it is like a custom-made browser. And frontend and mobile,
336940	343900	work with API, yeah, with server side. And they send requests to API, and they get requests from
343900	354980	API, and they render it, they show UI to the clients, and the clients can work with this UI,
354980	360500	and do some actions, maybe clicking the buttons, and other things, and enter maybe some.
360500	372120	And so, usually, in banks, API, it is a similar API for the frontend, and the same, sorry, same
372120	378520	API for the frontend, and for the mobile. Sometimes, maybe there are differences. Maybe it is
378520	386780	split API, so different API for frontend, and different API for mobile. But usually, usually,
386780	395820	it is the same. And API, it is like something between... it is an application that
397620	404260	helps us to work with bank infrastructure. It has API methods, it has some functionality that
404260	411140	can be used by frontend, and that can be used by mobile. And after that, it sends to bank
411140	417740	infrastructure, and there is some magic in bank infrastructure. The bank infrastructure is very,
417740	424980	very complex. It can be anything. It can be monolith, it can be microservices, yeah. And so,
424980	431600	but today, it will be bank infrastructure, and API, it will be server-side for us.
433080	441120	And I think it is all that I wanted to say about how does it work. Again, it is very,
441120	447900	very simple. And we can't talk more detail, because it needs a lot of time. It is a huge topic.
448480	455200	So, testing approaches of server-side and bank infrastructure. Usually, it is... API, it is usual
455200	460800	web application, yeah. And bank infrastructure, it is a very complex thing. It is like
460800	465880	Zoho with different services. It can be anything. And so, it is
468380	475020	very hard to hack it without understanding how does it work. And so, you can only can try to
475020	481160	maybe use fuzzing and other things, and try to understand how does it work. And it is only one
481160	485920	way to understand how to hack the bank infrastructure. So, API, it is usual web
485920	494820	application, so it can have any web vulnerabilities. So, if I'm talking about the possible
494820	500260	vulnerabilities, like I said, it is usual web vulnerabilities. Yeah, it is everything from the
500260	507320	OWASP. Yeah, you just can take the checklist of OWASP and any vulnerability and the most related
507320	513820	to the server-side. So, also, it is misconfigurations. It can be anything like
513820	523820	Nginx misconfigurations, maybe other things. And also, it is logical vulnerabilities,
523820	532480	because the bank and the mobile banking, online banking, it is very, very complex thing. Yeah,
532480	541060	it has very, very complex architecture. And so, when architecture is complex,
541060	547220	developers can do a lot of mistakes in this. And so, it can be any logical vulnerabilities,
547840	559060	like, I don't know, leakage of sensitive data of clients. Maybe, if it's correct to say race
559060	567620	condition, but it is not logical vulnerability, but sometimes it can be based on logical
570480	580540	problems. And other vulnerabilities, it is only example. So, it can be anything.
581200	590000	Next one, it is front-end. So, it is user interface. Yeah, based on the data received from
590000	600400	API. And so, and because it loads in browser, yeah, browser take a lot of security job on itself.
600400	609820	And so, it is very big difference between the mobile application, yeah, and front-end,
609820	615820	because browser do a lot of security job by itself. But in mobile applications,
616540	625900	developers have to do the things by itself. And possible vulnerabilities, it is XSS, it is,
625900	635460	I don't know, DOM-based XSS, it is CSRF, yeah. Maybe forgotten or maybe unfinished pages, yeah.
635460	644940	Sometimes, for example, developers make and publish in production React application,
644940	651700	but this application has pages that doesn't work and they are invisible for clients.
651700	662520	But anyway, they exist in production. And so, after understanding and maybe reversing of
662520	672700	React application, yeah, you can find this and you can recover the API methods that
672700	681040	application sends to API and gets and it allow you to try more requests and
682520	691060	maybe find another vulnerabilities. And also, it can be unsafe communication with API server.
691840	698020	And it is everything about the society, it is everything about communication,
698020	703160	maybe other algorithms and so on, so on. And again, it is only examples,
703160	707400	maybe there are another ones. There are another ones, of course, there are.
708440	716540	So, if we're talking about mobile testing approaches, yeah. Like I said, mobile,
716540	726580	it is an application, it is like custom-made browser. And in this case, you have a lot of,
727220	735160	I don't know, security and customization features, yeah. And so, you have a lot of
735160	742240	possibilities to do something wrong. And in this case, possible vulnerabilities, it is
742240	751040	storing of sensitive data, yeah. And we will talk about this in one example a little bit later.
751040	755520	So, also, it is unsafe handling of external data. And
758400	766280	because there is one good example of vulnerability, when mobile application got
767730	775140	external data and save it to SQLite database. So, and there was a SQL injection in this.
775140	786760	And if you can sniff and if you can edit the traffic that application gets from the network,
786760	791940	yeah, you can do the SQL injection on the client side. It is very interesting thing.
792020	799280	So, also, it is unsafe work with mobile platform. It is, for example, IPC mechanism and
799280	806140	other things, maybe. And also, there are a lot of different things.
806780	812900	And let's talk about testing guides, testing approaches for every type of online banking,
814120	820860	yeah. For web banking, you know, in this slide, I wanted to set, I wanted to make the big
822200	833880	table with comparing of different guides and with choosing the best one. But, no, I just didn't find
833880	840680	any other good guides except Avast per Web and Avast per MSTG. So, maybe, you know, and
841680	848520	if you use something else, you can maybe share it in comments. So, it is really good because...
851440	859080	but for web banking, we also usually use Avast per Web, yeah. It has very good checklist and it
859080	866220	has a lot of different vulnerabilities. So, it is really great and good job of someone who made
866220	877740	this, yeah, of people who made this. And so, mobile banking, it is Avast per MSTG and Avast
877740	887080	Web guides. And Avast per MSTG, it is about everything that's related to mobile platform,
887080	894340	yeah, all vulnerabilities that's related to this one. And why Avast per Web here? Because we have
894860	905900	service side, yeah, and when we're watching the mobile application, we have to check the platform,
905900	912920	the application, and also we have to check the server side and how it communicates with a mobile
912920	919200	application. So, for the platform, for the application, we use Avast per MSTG. And for the
919200	930600	service side, we use Avast Web. And it has maybe some intersections, yeah. And so, in the best way,
930600	940300	this intersection should be fixed, yeah. And the best way is to have that one big checklist
940300	948340	and one big guide. And so, using of this checklist is very, very conveniently and
949370	957020	it is really helps us to don't forget something when we test it. So, after that, we
959140	965180	begin to talk about vulnerabilities. And now it is the biggest part and we will talk about this
966340	974360	until the finish of the presentation. And firstly, I want to say why I choose this vulnerability.
975340	979080	There are three options and there are three
981760	986580	reasons why I choose this. Firstly, it is, for example, some vulnerabilities are very common,
987190	994040	you can meet it in a lot of different applications. And it is very common. And
996700	1003900	this is a problem. So, the second one reason, it is because some vulnerabilities are really
1003900	1011900	interesting. And they are not common. Yeah, maybe it is very rare vulnerability. But anyway,
1011900	1016420	it is really, really interesting. And it is like really hacking. And for example,
1016420	1021500	like I said before, it is like making money from nothing. Yeah. And so on. And so, it is really,
1021500	1027800	really interesting and I love it. And so, the third one reason, it is because sometimes some
1027800	1033920	vulnerabilities are really hard to fix. Yeah. And developers are trying to fix it and make another
1033920	1040640	vulnerability. And so, we will talk about... I don't remember one example of this vulnerability.
1040640	1047080	And so, it... Okay, a little bit later we will talk about it. So, let's begin from the first
1047080	1054080	one vulnerability. And first vulnerability, it is rounding attack. It is currency rounding attack.
1054080	1062660	And it is one of my favorite vulnerability, because it is really, really hacking. Like I
1062660	1067240	said before, and I talk about this vulnerability, it is like making money from nothing. Yeah.
1067240	1073960	And so, first information that I found about this vulnerability, it was 2011, maybe 2012.
1074460	1082280	Maybe there are early information, but I didn't find. So, this vulnerability based on the
1083940	1093380	incorrect or unsafe using of round functions. Yeah. And later we will talk about example.
1093380	1100780	But now, very, very simple example of using of round functions. And it is very simple. But
1101620	1109700	for us, interesting last example, when we can... In round function, we can set what is...
1110740	1121000	We can set the decimal places that will be after rounding. And as you can see on this example here,
1121790	1133740	it is two decimal places after rounding. So, after rounding, we will get 1.52. Yeah. And so,
1134420	1136260	you can say that it is not
1138680	1144860	real vulnerability and it is not possible to meet it in real life. But... And for example,
1144860	1151540	all banks already fixed it and all companies that work with money already fixed it too.
1151540	1159820	And you can't meet it in real life. So, but no, there are examples and you can find it on Hacker
1159820	1167560	One. And I met this vulnerability two years ago and I know one very huge bank. And so,
1167560	1181800	no examples exist. So, let's watch the example. Yeah. For example, we have one account. Yeah. And
1181800	1189180	this account has two wallets, USD and ruble wallets. Yeah. And you can transfer money between
1189180	1198380	these wallets. And when you transfer money, the different currencies convert in between. Yeah. And
1198380	1207740	for example, in this case, we have unreal rates. But anyway, it is very comfortable for us for
1207740	1217780	calculations. So, current rates, it is 64 rubles for one dollar in case of buying. And the same
1217780	1229860	64 one USD in case of selling. And so, we have bank that use rounds into decimal places. Yeah.
1229860	1238060	And our goal is to become rich. So, what we can do? Let's watch the attack. Yeah.
1239840	1252360	We have, one second, we have one ruble on the ruble wallet and we send it to the USD wallet.
1252360	1261720	And after rounding, yeah, firstly, we convert it to the USD. And after that,
1262560	1273560	calls function rounding. And as a result, we will get 0.02 USD from one ruble. Yeah. After that,
1273560	1281500	we convert, we send this two cents back to the ruble wallet. Yeah. And
1283060	1296120	it will be already one ruble and 20. Yeah. And now we have profit 120%. Why it happened?
1296120	1306200	This has happened because of this. This is main reason. So, we had one number and after wallet,
1306200	1315440	it became more. Yeah. And this difference is very critical. So, we can get a big profit.
1315460	1326100	And you can say that now we have two additional ruble cents. Yeah. And it is not rich. Yeah.
1326120	1334560	But if you can repeat it 1,000 or maybe 1,000,000 times, you will get real money.
1334780	1341880	I think banks not allowed to make this a lot of time because anti-fraud and some other things.
1341880	1349020	But anyway, if this vulnerability exists, sometime someone can try to exploit it. And
1349760	1360520	it is, I think, the best way to fix it anyway. So, and I have very simple plot. Yeah.
1361260	1373140	Firstly, on the X, we have transfer amount rubles. Yeah. And the Y, we have profit and the persons.
1373140	1385680	And so, as you can see, the biggest profit when we send about, I don't know, 0.3, 0.4 rubles to
1385680	1396600	the dollars, to the USD. And in this case, the profit is the highest. Yeah. And as you can see,
1396600	1403000	if we send more, yeah, the profit less, less, less. And after some specific moment,
1403000	1412900	it is less than 100. So, it is non-profitable for us. And from this, you can see that it is
1412900	1418540	first way to how to avoid this vulnerability. It is set the limit of transaction. For example,
1418540	1426840	if we'll set the limit of transaction in 6 rubles, yeah, it will be unprofitable for anyone
1426840	1435420	who tried to exploit this vulnerability. So, also, there are two other ways. And
1436460	1446260	second one, it is that we shouldn't allow to clients to convert money from rubles to USD.
1446260	1460160	Instead of this, we should allow to buy USD. Yeah. For example, client will buy 0.01 USD.
1460600	1471800	And after that, client will get price. And after that, they can finish the transaction. So,
1472500	1479260	in this case, anyway, there is rounding. Yeah. And it will be. But in this case,
1479260	1487840	numbers are higher. The numbers are bigger, sorry. And it will be unprofitable for anyone
1487840	1494340	who is trying to exploit this vulnerability. So, and there is another way. It is adding commission
1494340	1500680	after certain number of transaction. It is not looks like good way. But
1502180	1511760	anyway, it works. And so, but it looks like not like good fix. So, but this vulnerability that
1511760	1518260	I found this rounding attack took two years ago, the bank fixed this by adding commission
1518260	1527340	after specific count of transactions. So, another example, it is sensitive data disclosure. It is
1527340	1534160	very common vulnerability that is you can meet in every and a lot of application. Not every,
1534160	1543320	but a lot of. But maybe, maybe in every. I don't know. So, let's watch an example,
1543320	1549780	good example, interesting example. And this example shows that what is convenient is not
1549780	1558120	always safe. So, we should look for balance between convenient and for between security.
1558120	1566100	And it is very important. And case, the bank added functionality that allowed to send money between
1566100	1577640	cards without login procedure. So, it looked like this. So, user enters firstly information about
1577640	1584800	source card, about their card. And after that, user enters the information about the destination
1584800	1592620	card. It is only PAN code. In the first step, we enter the PAN, CVV and expired date. So,
1592620	1602520	on the second, only PAN code. So, on the third step, user enters the amount of money for transfer.
1602860	1610540	And on the next step, system checks the balance and calculates the commission. And if everything
1610540	1620500	is okay, money is enough and so on, user gets SMS. The user that has the source card gets SMS.
1621220	1627200	After entering the code, the transaction is done. If code is okay. So, let's watch
1627200	1639520	into the HTTP request that was used for checking the balance. Yeah. And it was a problem. The
1639520	1649840	main problem was that this server didn't check the expiry date and didn't check the security code.
1649840	1664640	Yes. So, but it checked the money amount and card number. So, as a result, everyone could get balance
1664640	1671660	for any card in the bank. So, just by enumerating the card number and just by enumerating the money
1671660	1685240	amount. So, it worked like if you set too much money, yeah, server will return the error that
1685240	1694060	money is not enough. Yeah. In other case, it will be everything's okay, enter please code. Yeah.
1694060	1702920	Please enter the code. So, and you can set any card number. So, you can get information about
1702920	1712060	every card in bank. And it is not so good. Now, it fixed. Next vulnerability, it is unsafe OTP.
1712760	1721340	Firstly, what is OTP? OTP, it is one-time password. And it is usually one of the most
1722280	1728080	popular realization of second factor. Yeah. For example, you enter to the mobile banking. Yeah.
1728080	1736280	You enter your login and password. And after that, you get the SMS code or maybe push notification
1736280	1744880	or maybe something like this. Yeah. And you have to enter it to pass the second factor of
1744880	1754200	notification. And usually, usually, it deliver it via SMS. Yeah. And it is the most popular way
1754200	1764100	for delivering. So, let's watch an example. Yeah, we are hacker. Yeah. And we got access to
1764100	1771220	user account. And so, we want to get money of this client. So, we have to send this money from
1771220	1779840	our account to the... from user account to our account. Yeah. So, and for completing this
1779840	1785980	transaction, we have to enter the correct OTP. This OTP sends to the mobile of the client
1785980	1792920	and owner of this account. And so, we don't know this OTP. But we have to enter it. And so,
1792920	1798740	after free and correct... and every time when we create a transaction, we have only three tries.
1798740	1807800	After three incorrect entries, transaction will be canceled. And OTP has four random
1809120	1815680	digits. Yeah, digits. And it is, for example, one, two, three, four. Yeah.
1817180	1823340	So, how to make this transaction? How to finish this transaction?
1826040	1833240	It is like a little bit strange. But what if instead of brute-forcing OTP, yeah, we will try
1833240	1840100	to brute-force transactions. Yeah. What if it will be not brute-forcing, but it will be guessing?
1840640	1847500	Sounds strange. I'll explain. Okay. Very important thing. If we're not limited in the
1847500	1852580	number of new transactions, if we can create and create and create and so on, yeah, we can
1852580	1862720	try the next exploitation. We choose three different OTP. Yeah. It should be a potential
1862720	1869760	correct OTP. One, two, three, four, I don't know, five, five, five, five, six, six, six, six. Yeah.
1869760	1878840	And after that, we create new transaction. And try choosing OTP. Yeah. If it isn't correct,
1878840	1885500	to step two and create new transaction. But on this moment, it is, but every transaction,
1885500	1893240	it is regenerate the OTP. So, we can just brute-force it. We can just take the one big
1893240	1900660	dictionary. Yeah. And using this dictionary to enumerate, to brute-force all existing OTP.
1900660	1908140	No, it doesn't work like this. But it is very, very similar. Yeah. So, and we should repeat this
1908140	1916400	algorithm, this exploitation until we matched at least one OTP. If we matched at least one OTP,
1916400	1923320	the transaction will be finished. Yeah. And so, it is one big difference. It looks like brute-force,
1923320	1929940	but it isn't brute-force. It is guessing. So, in case of brute-force, we know about when it
1929940	1937780	will be finished. For example, dictionary has size 10,000 lines. So, it will be finished after
1938400	1946980	trying of 10,000 lines. So, in case of this brute-force, yeah, but it is guessing.
1947220	1952860	We're not sure when it will be finished. It can be finished on the next transaction,
1952860	1960020	or it can be finished after 20,000 transactions. Yeah. We're guessing. We're trying to enumerate
1960020	1973980	transactions. Yeah. Until the generated OTP didn't match our OTP. So, I'll explain everything.
1974520	1981860	No, I'm joking. I am not going. It is boring. So, no, no, no. But it is very interesting results.
1981860	1986880	Let's watch the results. So, probability of the successful transaction depends on the
1986880	1995100	number of attempts. So, in our guessing exploitation, yeah, after 3,000 attempts,
1995100	2003620	then it will be about 60% probability. Yeah. But if we can try 16,000 attempts,
2003620	2014980	it will be 99%. So, it is a really good result, I think. And let's watch a little bit more
2015720	2022160	complex example with new limitations. The same example, totally the same OTP,
2022160	2028740	totally the same situation, and so on. But after five canceled transactions, we can't create a new
2028740	2036200	one. We will be blocked for several times. For example, for 24 hours. Yeah. And so, what we can
2036200	2044840	do in this case? There are two possible approaches. First approach, it's totally the same
2044840	2056600	exploitation, totally the same steps, but we try not three OTP for each transaction, but two OTP.
2056600	2065120	So, in this case, we avoid the cancellation of transaction. And in this case,
2065120	2071820	creation of transaction will not be blocked. Yeah. So, it is one approach. Another one,
2071820	2076640	we can, in the beginning, create several thousands of transactions. Yeah. For example,
2076640	2082260	we can create 20,000 of transactions, and only after that, we will try the OTP.
2082280	2089100	So, in this case, yeah, we will block the creation of new transactions after trying the OTP. Yeah.
2089100	2097460	But it is not affected. It doesn't affect us, because we already created the 20,000. And
2098020	2105080	as you can see from the calculations, in case of 20,000, it will be more than 99%
2105840	2118700	probability of success. So, we will get profit. So, and also,
2118700	2128180	very good question. Is SMS a secure way of OTP delivery? Yeah. It is a good question,
2128180	2134980	because there are a lot of attacks against the SMS. It can be fake BTS. It can be
2134980	2141420	ratio of SIM card. It can be SS7 attacks. Yeah. For example, these two very
2145700	2153480	cheap things, it can be used for creating the fake BTS, for creating the fake station. Yeah.
2153480	2170440	And using this, you can try to attack the client. So, let's talk about the recommendations. Yeah.
2170440	2177560	Firstly, second factor should be enabled for all critical actions. Yeah. If you, for example,
2177560	2188120	login to account, if client, for example, logins to account, for example, if changes the profile
2188120	2198420	information, maybe other critical actions, it should be, client should enter the second factor.
2198420	2206520	Also, it is very important to limit the count of requested OTP. On the previous examples,
2206520	2214140	we tried to limit the creating of transactions, but sometimes it is a little bit hard. Maybe
2214140	2221570	you can make another vulnerability and so on. So, the best way is to control the OTP.
2221570	2231590	So, how many OTP, how many generation of OTP client asked. Yeah. And after specific count,
2231590	2241250	just stop this process. And also, maybe it is a good way to think about alternative for SMS,
2241250	2249230	because SMS not looks like the best way for delivering OTP. For example, we can watch on
2249230	2256750	the push notification, we can watch on the TOTP and HOTP. TOTP and HOTP, it is, for example,
2256750	2260630	Google notification, it is Microsoft notification. It is applications that you
2260630	2279210	have on your mobile phone and they use cryptography for OTP process. So,
2279210	2291430	it is totally silent because it doesn't have delivering. Yeah. So, client doesn't know about
2291430	2301530	that someone trying to brute force its second factor. Yeah. And so, sometimes it is very
2301530	2308090	critical because in case of SMS or maybe push notifications, client will get a lot of messages
2308650	2315530	about that and understood that something's wrong and maybe call to support and support will call
2315530	2324890	to security information specialists. And so, maybe attack will be stopped. But in case of TOTP and
2324890	2334690	HOTP, it doesn't look like this. Next vulnerability, it is unsafe randomization.
2335970	2343210	And it is, you can meet it in application where logic is based on the generation of
2343210	2354490	random values. It can be sessions, it can be OTP, maybe unique identifiers. Yeah. And it is,
2355590	2362810	for example, most common problems, it is using of unsafe predictable
2364370	2368870	random numbers generators. Yeah. In other case, it can be, for example, using the predictable
2368870	2377070	functions for creating, for example, sessions, maybe unique identifiers and so on. So, in a case
2377070	2387710	when attacker can recover the sequence of random values. Yeah. And it can be in case,
2387710	2393430	for example, incorrect initialization of random number generator and so on. And
2396010	2403190	it is one very known example when... it isn't online banking, of course, but anyway,
2403190	2411010	Russian engineer, they... but it wasn't one engineer, it was team. Okay, never mind.
2412770	2419430	A team of Russian engineers, so maybe one engineer, reversed the slot machine. Yeah. And
2419430	2429150	they recovered the sequence. They recovered it of algorithm, how it used randomization. Yeah.
2429150	2437350	And they developed their program. I don't know what they did, but they, for example,
2437350	2445410	they developed a program that helped to recover this sequence. For example, they came to the
2445410	2454630	slot machine. They played for several minutes. And in these several minutes, they got the sequence
2454630	2464330	what slot machine showed to them. Yeah. And using this information, they recovered them all sequence
2465150	2473810	of random. And they can... and they know what will be in the future. And so, using this cheat,
2473810	2481250	they can... they did a lot of money. And so, it is one of the good examples.
2481250	2491990	And so, another one good example, I heard from Timur Inusov. And he met... it is on his project.
2491990	2505730	So, for OTP generation was used LCG generator, yeah, for randomization. So, but using of LCG
2505730	2515870	is not okay, because it is not cryptography safe. And for example, when you have a sequence of
2515870	2523130	several generated codes, you can recover all sequence. So, you can predict next OTP codes.
2523370	2531670	And for OTP, it is very critical. So, something like this.
2532550	2539070	Another vulnerability, it is mobile banking identification. Yeah, it is not vulnerability,
2539070	2547710	but it is like evolution, yeah, for mobile banking identification. I'll explain, okay.
2547710	2556670	For example, we have case. Client installed our mobile banking application on the mobile phone,
2556670	2564950	and client, very good client, yeah, you know, they know a lot about security. And
2566590	2574830	so, client has very strong password, yeah. And on the mobile phone, and the very strong
2574830	2584550	password is not convenient, yeah, and it's not so comfortable. And so, our task is to
2585790	2591950	develop the simple authentication process, and that works after first login. For example,
2591950	2598390	first time a user enters their login and password. After that, something happens,
2598390	2604470	and user can enter there more simply. Yeah, for example, using PIN code or something like this.
2604470	2613390	And so, let's try to make this solution, yeah. Firstly, what is the most simple way?
2613390	2620990	After entering the login and password, the application just save the user password to file,
2620990	2625330	and every time when the user opens the application, the application sends the
2625330	2635070	password to the server and get the session, the live session. It is awful. It is totally unsafe.
2636770	2642650	Because of the saving of password, it is awful practice by design.
2642650	2649510	Do not do this. It is awful. The second problem that unlocked device provides access to mobile
2649510	2658490	functions. So, anyone who can get access to unlocked device, or maybe device
2659770	2671130	doesn't have PIN code because it didn't set. Yeah. So, in this case, anyone can just use
2671130	2678510	the mobile one. It isn't okay. And so, finding the second factor doesn't help in this case,
2678510	2687150	because this phone has the SIM card, and the SMS will be on this phone. So,
2687150	2694210	and the third one, the hacker can get access to the file with password, yeah. And in case,
2694210	2700310	for example, if application has vulnerabilities, yeah, or just because of hacker has
2700310	2709090	hacked the phone and now has root access. And in this case, hacker can just open any file on the
2709090	2719510	file system, almost. So, another case, after successful login, yeah, user sets the PIN code.
2720030	2728430	Yeah, and PIN code saves, or maybe not saves, but it uses it by checking the access by application,
2728430	2737350	and for example, now we use refresh token, yeah. And I forgot to say that the best practice,
2737350	2744890	save not password, but save the refresh token, yeah, and using the refresh token for creating
2745050	2754530	a live session. So, after first login, yeah, user set PIN code. This PIN code used for decrypting
2754530	2764430	encrypted refresh token, yeah. So, and also, this PIN code used for checking the access. So,
2764430	2772250	you open the mobile application, you enter the PIN code, PIN code, for example, comparing with
2772250	2776890	something, yeah, and for example, decrypting the refresh token, the refresh token sends to server,
2776890	2790870	and server backs a live session, yeah. Again, it is an awful realization, because firstly,
2790870	2796670	anyway, we store the refresh token in the file, so hacker, again, if there are vulnerabilities,
2796670	2805050	or if hacker have root access on the mobile, hacker can just get access to file with password.
2805050	2813170	In another case, encryption of token with short PIN code is useless, because PIN code is very short,
2813170	2822970	and brute force of this will be very fast. And also, any local checks, like PIN code check,
2822970	2830310	and other things can be easily bypassed by Frida, if you have enough access on the device.
2830310	2838150	So, it doesn't work like this. So, next realization, we save refresh token to the
2838150	2850290	kstore kchain, yeah. And you know, kstore kchain is the very good option, but it is unsafe only
2850290	2860090	in one case, when we enable the checking of biometric open code, when someone opens this
2860090	2866430	record. In this case, hacker can't get access to these records in kchain. In another case,
2866430	2875390	if no access checking, and the application just extract the data from kchain kstore without any
2877590	2884410	interactions with the user, in this case, it is totally unsafe. Not totally, but unsafe, because
2884410	2892950	of a hacker with root access can just extract it without any problems. So, also, it can be
2892950	2901890	problematic if a user has old device. And in this case, maybe problems with kstore kchain,
2901890	2911770	maybe just device don't have enough security functions, and so on. And also, but it is very
2911770	2917590	similar to the second one, and the third one, is that you completely dependency on the kstore
2917590	2926050	kchain security. So, if there are some problems with this, you have problems with the application.
2926920	2935750	And the last one realization, application asks user to set pin code, and this pin code will be
2936530	2947330	sent to API. So, API controls the identification process. And in this case, you can control
2948250	2954730	anything, like brute force, like enumeration, and other things. So, you can control anything.
2954730	2961790	In this case, it is totally the same. For example, in case of using kstore kchain,
2962570	2970250	user can't use any pin code, because it will be a pin code of device only. In case of the last
2970250	2977560	realization, user can use any pin code, because it is no limitation. And we can set, for example,
2977560	2986420	ask for the big pin code, like six symbols, maybe eight symbols, any pin code, and other things.
2987900	2995480	But it is very important, too, that now we have to protect our server-side, because
2995480	3002820	everything depends on our server-side. That's all that I wanted to show you.
3002820	3010940	So, now about conclusions. Firstly, there are good testing guides. There are good testing
3010940	3017000	approaches. And you can use it not only for testing the applications, but you can use it for
3017000	3024400	developing the application, for making applications. And it is really useful. It
3024400	3031420	has a lot of examples, and so on. Also, the next conclusion is sometimes convenience is the enemy
3031420	3040300	of security. And as you can saw from the example, yeah, third example with bank that added the
3040300	3046740	functionality of sending money between cards without login. It is sometimes too critical,
3046740	3051700	yeah. And so, it is very important to find the compromise between convenience and
3052300	3058920	between security. Next one, it is be careful with cryptography, randomizations, and other things,
3058920	3063720	because cryptography is really complex, and it is very important to understand what you do.
3063720	3071220	And just don't use cryptography without understanding. It is bad practice. And the
3071220	3080540	last one conclusion is use best practices, and use experience of other companies. Watch on other
3082040	3092040	products, watch on other applications, because a lot of problems, yeah, and some companies
3092720	3101140	already solved these problems. And if you find the correct solution, it will be very good.
3101500	3109700	And so, it is everything that I wanted to say. So, thank you for attention. I hope
3109700	3114720	you got something new from this presentation. Thank you.