1 00:00:00,100 --> 00:00:06,150 - Hello all and welcome to the new video of Android Security and Exploitation by 2 00:00:06,150 --> 00:00:12,040 Pentester Academy. My name is Aditya and I'm your course instructor for this entire 3 00:00:12,040 --> 00:00:18,020 training series. So, this training is available at PentesterAcademy.com and you 4 00:00:18,020 --> 00:00:21,650 can also check out the certifications at securitytube-training.com. In this video, 5 00:00:21,650 --> 00:00:29,790 we are going to have a look at the Client Side Injection which is another 6 00:00:29,790 --> 00:00:37,000 vulnerability. Basically something common which you see in web applications as well. 7 00:00:37,000 --> 00:00:43,670 Basically, Client Side Injection means is, let's say if an application is taking 8 00:00:43,670 --> 00:00:50,310 input from the user and it's parsing in, parsing it to may be some SQLite queries 9 00:00:50,310 --> 00:00:55,850 and it's not validating what kind of input the user has given. So that is where 10 00:00:55,850 --> 00:01:00,650 injection attacks can take place. Now it could be in the case of SQLite, it could 11 00:01:00,650 --> 00:01:06,310 be in the case of some other component, but this is the whole underlying concept. 12 00:01:06,310 --> 00:01:12,630 So in terms of SQLite injection as you know that Android applications store the 13 00:01:12,630 --> 00:01:21,590 database as SQLite. One of the use cases of SQLite injection will be if an 14 00:01:21,590 --> 00:01:27,270 application is doing some kind of local validation or storing something in the 15 00:01:27,270 --> 00:01:33,690 local database and is taking input from the user and not verifying it or not 16 00:01:33,690 --> 00:01:38,640 sanitizing it before passing it to the SQLite queries then that application might 17 00:01:38,640 --> 00:01:47,250 be vulnerable to SQLite injection. Let's take an example, we have an application 18 00:01:47,250 --> 00:01:56,150 called sqliteapp.apk in the Client Side Injection folder and let's first of all 19 00:01:56,150 --> 00:02:12,370 connect to a VM, Genymotion VM, 192.168.57.102. 192.168.57.102. We have 20 00:02:12,370 --> 00:02:23,630 the device listed over here. Let's go ahead and install the sqliteapp.apk. This 21 00:02:23,630 --> 00:02:30,120 is how the application looks like and let's first go ahead and register 22 00:02:30,120 --> 00:02:37,230 ourselves. Maybe I'll just give Aditya password, register and enter some of my 23 00:02:37,230 --> 00:02:47,070 personal details over here. So, Gupta, adi@attify.com, phone number and just 24 00:02:47,070 --> 00:02:56,092 submit. Now if I have to log in, I need to know my password in order to fetch the 25 00:02:56,092 --> 00:03:00,726 details. So, once I enter the correct password, then I can click on login and 26 00:03:00,726 --> 00:03:07,449 and it will fetch up my details. What our goal is over here is we have to somehow 27 00:03:07,449 --> 00:03:14,537 bypass this particular validation. So the first thing we'll do is, we'll simply 28 00:03:14,537 --> 00:03:28,290 reverse the application using dex2jar. So dex2jar sqliteapp.apk. Now dex2jar has 29 00:03:28,290 --> 00:03:35,642 successfully reversed the application and we can basically use jd-gui to open the 30 00:03:35,642 --> 00:03:47,287 jar file which was created. And here if you look inside of the database connector 31 00:03:47,287 --> 00:03:53,370 class, we'll basically see the addRecord and the getRecord methods. The addRecord 32 00:03:53,370 --> 00:04:02,770 method simply enters the user values into a database called vulnerable-db and 33 00:04:02,770 --> 00:04:09,810 getRecord selects the data from the vulnerable-db and shows it to the user. 34 00:04:09,810 --> 00:04:16,300 Now we can confirm it by simply doing an adb shell and going inside 35 00:04:16,300 --> 00:04:26,010 data/data/com.attify.sqliteapp. If you look inside the databases, you'll have a 36 00:04:26,010 --> 00:04:36,980 vulnerable-db over here and if you open it up with sqlite3, .tables then select * 37 00:04:36,980 --> 00:04:45,063 from USER RECORDS. So we'll basically see the entry over here inside the table 38 00:04:45,063 --> 00:04:50,709 called USER RECORDS, inside the database called vulnerable-db which is exactly what 39 00:04:50,709 --> 00:05:03,524 we saw inside the jd-gui. Now since we know how it is basically...let's open 40 00:05:03,524 --> 00:05:12,359 jd-gui sqliteapp. Now since we know that how it is parsing the user input values 41 00:05:12,359 --> 00:05:18,777 into the SQLite query, we can try to find a bypass for this. So if you look over 42 00:05:18,777 --> 00:05:23,829 here, this is the select * from USER RECORDS where username equals to the user 43 00:05:23,829 --> 00:05:38,281 input and password equals to the user input. So if we open leafpad... If you 44 00:05:38,281 --> 00:05:47,360 look over here, this is the username and this is the password. So what we can do is 45 00:05:47,360 --> 00:05:55,350 we can try to make the application believe that the user exists and the validation is 46 00:05:55,350 --> 00:06:04,613 correct by adding or by putting something like 1'or'1=1 inside the paramString. Now 47 00:06:04,613 --> 00:06:11,904 1'or'1=1 is a one of the like most popular strings in SQLite injection or SQL 48 00:06:11,904 --> 00:06:17,550 injection where you can simply make the SQL query believe that this particular 49 00:06:17,550 --> 00:06:22,606 statement is true. If you look over here this statement now becomes SELECT*FROM 50 00:06:22,606 --> 00:06:31,096 USER_RECORDS WHERE USERNAME=1 or basically adding a condition and saying or 1=1. Now 51 00:06:31,096 --> 00:06:37,353 since 1=1 is always true, the application thinks that this particular statement is 52 00:06:37,353 --> 00:06:43,466 returning true and thus the validation is accepted. So let's try to perform the same 53 00:06:43,466 --> 00:06:54,008 thing over here and maybe enter some incorrect password and simply add, let's 54 00:06:54,008 --> 00:07:10,156 say 1'or'1=1. Basically clicking on login. Now we are able to see the user records. 55 00:07:10,156 --> 00:07:15,844 So this is what happens in the SQLite or Client Side Injection and one of the ways 56 00:07:15,844 --> 00:07:22,729 to bypass or actually I mean protect it is by sanitizing the user input before 57 00:07:22,729 --> 00:07:31,098 applying the SQL queries. So this is how the sample code look like which was there 58 00:07:31,098 --> 00:07:38,978 in the application and that's one of the most common mistakes made by the 59 00:07:38,978 --> 00:07:45,072 developers of not validating the user inputs. So that's all for this video. I 60 00:07:45,072 --> 00:07:50,048 hope you like the video and if you have any feedback or queries, feel free to drop 61 00:07:50,048 --> 00:07:56,000 me a mail at adi@attify.com. Also you can tweet to me @adi1391.