1 00:00:00,000 --> 00:00:01,417 Okay. 2 00:00:01,417 --> 00:00:03,667 Without any further adieu, we have a short talk, a 20 minute talk, 3 00:00:03,667 --> 00:00:06,042 Jaime Sanchez talking about building an Android IDS 4 00:00:06,042 --> 00:00:08,042 on the network level. 5 00:00:08,042 --> 00:00:09,125 Jaime, take it away. 6 00:00:10,999 --> 00:00:12,667 JAIME SANCHEZ: Hello. 7 00:00:13,999 --> 00:00:16,000 My name is Jaime Sanchez. 8 00:00:17,375 --> 00:00:20,125 I'm going to talk about building Android IDS 9 00:00:20,125 --> 00:00:22,375 on a network level. 10 00:00:22,834 --> 00:00:25,999 I work for security for about ten years. 11 00:00:25,999 --> 00:00:32,999 I work for international companies, especially as an advisor. 12 00:00:32,999 --> 00:00:36,999 In my free time, I enjoy doing research on security. 13 00:00:37,000 --> 00:00:39,125 And I work as an independent consultant. 14 00:00:39,125 --> 00:00:40,250 I'm from Spain. 15 00:00:41,834 --> 00:00:45,709 I have talked in other conference, in Spain, like, rootedCON 16 00:00:45,709 --> 00:00:47,834 and Nuit du Hack. 17 00:00:58,876 --> 00:01:00,584 I don't know what happened. 18 00:01:00,584 --> 00:01:04,083 Last night it's my first time in Vegas. 19 00:01:04,083 --> 00:01:08,083 Today I wake up, I was with two strippers. 20 00:01:08,584 --> 00:01:10,334 No, don't laugh. 21 00:01:10,999 --> 00:01:13,709 I know the reason of this. 22 00:01:13,999 --> 00:01:15,667 Just blame aliens. 23 00:01:15,667 --> 00:01:17,417 I'm sure they forced me to drink. 24 00:01:17,417 --> 00:01:18,459 I'm from Spain. 25 00:01:18,459 --> 00:01:19,626 I don't like partying. 26 00:01:19,626 --> 00:01:20,626 (Laughter). 27 00:01:20,626 --> 00:01:21,999 AUDIENCE MEMBER: Right! 28 00:01:21,999 --> 00:01:24,292 JAIME SANCHEZ: You know us. 29 00:01:24,918 --> 00:01:29,334 We have 20 minutes before I get with my lawyers to get divorced. 30 00:01:29,334 --> 00:01:30,918 So let's get (Laughter). 31 00:01:30,918 --> 00:01:32,459 So let's get down to business. 32 00:01:33,876 --> 00:01:38,834 The reason of this conference is Android has great access. 33 00:01:40,375 --> 00:01:42,584 Being popular is not always good. 34 00:01:42,751 --> 00:01:46,792 Because as it grows, do the attackers. 35 00:01:49,250 --> 00:01:54,209 There are over 100 million Android devices. 36 00:01:54,250 --> 00:01:57,999 It was from just last year, and we have our market share 37 00:01:57,999 --> 00:02:01,999 of nearly 50%, and there are several techniques that 38 00:02:01,999 --> 00:02:07,542 are used to detect malware and do attacks on mobile phones. 39 00:02:07,999 --> 00:02:13,167 I haven't seen any open source tool to detect and create patterns to look 40 00:02:13,167 --> 00:02:16,083 at these kinds of attacks. 41 00:02:16,501 --> 00:02:20,125 So we have in the last years, we have seen several exploits 42 00:02:20,125 --> 00:02:24,292 like the USSD exploit, several vulnerabilities from webkit 43 00:02:24,292 --> 00:02:28,083 and now there's a meterpreter for this. 44 00:02:38,626 --> 00:02:42,999 I took my mobile and my other mobile phone and I make a VPN tunnel 45 00:02:42,999 --> 00:02:44,999 with my computer. 46 00:02:44,999 --> 00:02:47,083 So I was trying to analyze all the traffic passing 47 00:02:47,083 --> 00:02:49,083 through my device. 48 00:02:49,083 --> 00:02:54,083 I launched this node on my computer to detect suspicious traffic 49 00:02:54,083 --> 00:02:58,626 and I could also use tools like TCP RAM. 50 00:02:58,626 --> 00:03:02,167 I would make all the analysis on the forensic as I could. 51 00:03:02,999 --> 00:03:07,083 Well, this type of IPS sucks, man. 52 00:03:07,083 --> 00:03:10,999 Are I have several problems because I have to take the traffic 53 00:03:10,999 --> 00:03:14,459 from my from my mobile phone to my computer that's 54 00:03:14,459 --> 00:03:16,999 a waste of bandwidth. 55 00:03:17,083 --> 00:03:19,999 I couldn't act like an IPS. 56 00:03:19,999 --> 00:03:21,626 Could detect all the attacks. 57 00:03:21,626 --> 00:03:26,626 I could take all the malware, but that was just after it happened. 58 00:03:26,626 --> 00:03:28,459 So that has no sense for me. 59 00:03:28,667 --> 00:03:30,626 There are a lot of signatures for snort. 60 00:03:30,626 --> 00:03:31,667 There are signatures for other things 61 00:03:31,667 --> 00:03:34,459 but they are not associated with Android. 62 00:03:35,584 --> 00:03:38,417 What's important is that we don't have any real 63 00:03:38,417 --> 00:03:40,999 notification for the user. 64 00:03:40,999 --> 00:03:44,083 So the user doesn't even know if an attack is happening or 65 00:03:44,083 --> 00:03:47,542 is infected by malware or anything. 66 00:03:47,542 --> 00:03:50,459 So I continue with my life. 67 00:03:54,709 --> 00:03:59,667 I made and OSfooler, it is for active fingerprinting 68 00:03:59,667 --> 00:04:04,626 and it takes events of code Q and that's when I come 69 00:04:04,626 --> 00:04:09,751 up with an idea on how to solve it problem. 70 00:04:09,999 --> 00:04:11,834 With this tool, I was able to modify in realtime 71 00:04:11,834 --> 00:04:15,375 all the traffic that was passing through my computer. 72 00:04:15,834 --> 00:04:20,542 So I found a problem that is the packets I want to capture, 73 00:04:20,542 --> 00:04:23,792 they are in kernel space. 74 00:04:23,792 --> 00:04:27,542 So the kernel distinction on the device, is right inside the colonel of space 75 00:04:27,542 --> 00:04:30,459 and I couldn't take the pacts to modify in realtime 76 00:04:30,459 --> 00:04:32,999 before the computer has it. 77 00:04:32,999 --> 00:04:34,792 I have to work in user space. 78 00:04:34,876 --> 00:04:39,501 So I have my own virtual memory and I have no other option. 79 00:04:39,501 --> 00:04:42,999 So for this approach to work, let me show you a little bit 80 00:04:42,999 --> 00:04:46,709 of the of the travel for pacts from the network card 81 00:04:46,709 --> 00:04:48,999 to the application. 82 00:04:49,167 --> 00:04:51,999 I call it how I met your packets. 83 00:04:51,999 --> 00:04:53,083 (Laughter). 84 00:04:53,125 --> 00:04:57,584 So the first thing, when the when the kernel takes a packet, put 85 00:04:57,584 --> 00:05:02,918 inside the process, the first one is taking directly from the network 86 00:05:02,918 --> 00:05:08,542 and put inside a buffer and then it goes with the software or hardware IRQ, 87 00:05:08,542 --> 00:05:12,792 it calls the CPU letting him know there's a new packet, 88 00:05:12,792 --> 00:05:17,542 but the special thing here is before it gets processed, we have 89 00:05:17,542 --> 00:05:21,626 to pass through the chains of IP tables. 90 00:05:21,626 --> 00:05:26,417 I'm sure you everyone knows the typical target destination, 91 00:05:26,417 --> 00:05:30,083 but here here's the special thing I found 92 00:05:30,083 --> 00:05:33,834 to make my ideas in my tools. 93 00:05:33,999 --> 00:05:39,501 Just after the IP tables, it gets through the IP layer and it checks 94 00:05:39,501 --> 00:05:43,918 the headers and this puts into in the kernels and 95 00:05:43,918 --> 00:05:47,083 the corresponding circuit. 96 00:05:48,792 --> 00:05:52,751 So we have several targets for IP tables. 97 00:05:53,083 --> 00:05:56,083 You know, you can accept packet, you can drop the packet. 98 00:05:56,083 --> 00:05:58,083 You can let the remote computer know that you 99 00:05:58,083 --> 00:06:01,999 have dropped a packet, but there's a special one, at queue, 100 00:06:01,999 --> 00:06:05,542 that's from packet space to user space. 101 00:06:06,083 --> 00:06:09,999 So a little of theory, is that this queue delegates 102 00:06:09,999 --> 00:06:14,334 the decision from user space to kernel space. 103 00:06:14,334 --> 00:06:17,209 So in user space, you must have a listener the taker 104 00:06:17,209 --> 00:06:19,334 of every packet. 105 00:06:19,876 --> 00:06:24,334 That's because you have to issue a verdict for etch each packet. 106 00:06:24,334 --> 00:06:25,751 You have to accept it. 107 00:06:25,751 --> 00:06:29,626 You can drop it, but you can modify in realtime before it gets 108 00:06:29,626 --> 00:06:32,250 into the TCP IP stack. 109 00:06:32,999 --> 00:06:36,626 You have to be very fast because if the queue gets full, 110 00:06:36,626 --> 00:06:40,876 all the packets that you receive will be dropped. 111 00:06:40,876 --> 00:06:46,542 So for summary, I'm capable of processing all incoming and 112 00:06:46,542 --> 00:06:51,999 all outgoing traffic inside of my device. 113 00:06:51,999 --> 00:06:53,334 I make my tool. 114 00:06:56,083 --> 00:06:59,999 I thought I was able to make a tool like this. 115 00:07:00,167 --> 00:07:02,918 If I'm able to issue a verdict for every packet, 116 00:07:02,918 --> 00:07:06,250 maybe I'm not also acting like an IDS. 117 00:07:06,250 --> 00:07:08,083 I'm acting too like an IPS. 118 00:07:08,667 --> 00:07:12,626 So the release of my tool was and then I moved to C and then 119 00:07:12,626 --> 00:07:14,999 to Python and C again. 120 00:07:19,542 --> 00:07:23,542 And then I get to Android IDS. 121 00:07:23,626 --> 00:07:28,083 This Android IDS is the first approach to create 122 00:07:28,083 --> 00:07:32,417 an source software that it's a network IDS and 123 00:07:32,417 --> 00:07:38,083 a network IPS that has produce real traffic analysis and look 124 00:07:38,083 --> 00:07:41,542 at the Internet protocol. 125 00:07:42,667 --> 00:07:46,250 I just say this like protocol searching, or protocol analysis, 126 00:07:46,250 --> 00:07:49,584 content mapping and content searching. 127 00:07:49,999 --> 00:07:53,083 It was it would be great if you were able to hook 128 00:07:53,083 --> 00:07:56,918 into the device and work at this, because you could reduce 129 00:07:56,918 --> 00:07:59,751 the amount of false positive. 130 00:07:59,999 --> 00:08:04,292 But there is some problems finding the the address of the table. 131 00:08:04,292 --> 00:08:05,792 There is there is there is the difference 132 00:08:05,792 --> 00:08:09,626 between the different versions of Android kernel. 133 00:08:09,626 --> 00:08:12,125 So this is something I have to work on. 134 00:08:13,125 --> 00:08:18,999 So the architectures should be a sensor and a server. 135 00:08:18,999 --> 00:08:22,209 The sensor is inside of our Android mobile device 136 00:08:22,209 --> 00:08:25,959 and run with no human interaction. 137 00:08:25,959 --> 00:08:28,834 It is responsible for analysis in traffic. 138 00:08:28,834 --> 00:08:32,667 It should send some push message to the mobile device 139 00:08:32,667 --> 00:08:39,999 of the the user can know if it's if it's having an attack or it's malware. 140 00:08:39,999 --> 00:08:41,083 So I dump this with an application you 141 00:08:41,083 --> 00:08:45,584 will see that's called notify my Android with the IP and realtime notifications. 142 00:08:45,999 --> 00:08:49,834 So it reports through the log in server if you want. 143 00:08:50,125 --> 00:08:53,459 You can do a devices log and you can create a VPN internal 144 00:08:53,459 --> 00:08:56,667 and do some custom reactive actions like dropping 145 00:08:56,667 --> 00:09:00,959 the packet and adding new rules to the API tables or run a script 146 00:09:00,959 --> 00:09:02,918 as we will see. 147 00:09:02,918 --> 00:09:06,999 And very important, it should be minimal overhead 148 00:09:06,999 --> 00:09:09,167 to the device. 149 00:09:09,459 --> 00:09:13,542 On the other side, we'll find the we'll find the server. 150 00:09:13,542 --> 00:09:17,834 The server is the only responsible for taking all the traffic. 151 00:09:17,959 --> 00:09:20,792 It should send the signatures, the updates signatures 152 00:09:20,792 --> 00:09:24,459 to the device and store the events in the database. 153 00:09:24,876 --> 00:09:30,292 Another feature is that we can do the statistical analysis of the packets 154 00:09:30,292 --> 00:09:33,959 in the server instead in the mobile device, 155 00:09:33,959 --> 00:09:38,999 because of the power of the computer, and we could use any CM 156 00:09:38,999 --> 00:09:43,834 or whatever you want to add, IP replication and correlation 157 00:09:43,834 --> 00:09:45,999 for the attacks. 158 00:09:46,250 --> 00:09:49,999 So the first thing I have to do is protocol analysis. 159 00:09:50,542 --> 00:09:52,083 As my day by day. 160 00:09:52,083 --> 00:09:54,999 So the packets, you know that packets don't conform 161 00:09:54,999 --> 00:09:58,292 to standards and some will almost rob them. 162 00:10:03,999 --> 00:10:08,709 These kinds of packets you can find in the service attacks in worms 163 00:10:08,709 --> 00:10:12,167 and virus and several of them have several anomalies 164 00:10:12,167 --> 00:10:15,999 because of programming with raw circuits. 165 00:10:15,999 --> 00:10:19,876 So as an example, you can see now that there 166 00:10:19,876 --> 00:10:22,501 is TCP IP packet. 167 00:10:22,501 --> 00:10:26,709 It has several flags activated and this kind of packet belongs 168 00:10:26,709 --> 00:10:31,999 to a network scanner and should be dropped and it should be reported 169 00:10:31,999 --> 00:10:34,709 to the to the server. 170 00:10:36,125 --> 00:10:39,999 So, as I told you, I have a tool, it was called OSfooler. 171 00:10:40,667 --> 00:10:45,209 It was for active and inactive fingerprinting. 172 00:10:45,209 --> 00:10:50,876 So I have to port all of my code because my tool was working okay. 173 00:10:50,876 --> 00:10:56,584 So I was trying to detect on drop packets from well known tools. 174 00:10:56,584 --> 00:11:01,250 In this case, the Nmap is 16 proofs, TCP IP and ICMP. 175 00:11:02,999 --> 00:11:08,083 And also you have how it get how it detects the attack. 176 00:11:08,083 --> 00:11:11,626 In this case, you are seeing that we are connected 177 00:11:11,626 --> 00:11:14,334 through to the mobile. 178 00:11:14,751 --> 00:11:16,999 We have to have the the device rooted 179 00:11:16,999 --> 00:11:21,751 because we need access to the IP table since and in this case, 180 00:11:21,751 --> 00:11:24,626 we are launching the IDS. 181 00:11:25,999 --> 00:11:27,999 It's in log in mode. 182 00:11:27,999 --> 00:11:33,292 You can see that it's log in almost every packet that has come 183 00:11:33,292 --> 00:11:38,417 to the mobile device and as you see, when it finished, 184 00:11:38,417 --> 00:11:45,375 the Nmap has detected that it has like a Linux box, 2.6 or 3.0. 185 00:11:45,876 --> 00:11:48,584 In this case, we have only logged all the attacks. 186 00:11:48,626 --> 00:11:50,709 It has a notification. 187 00:11:50,709 --> 00:11:54,999 It's disabled to not to stop the demo, and in this case, what we are going 188 00:11:54,999 --> 00:11:59,999 to do is to use the IDS to fool these kind of fingerprinting. 189 00:11:59,999 --> 00:12:03,334 We have to activate it and it's in an Android mode. 190 00:12:03,334 --> 00:12:06,999 So every packet has been dropped and reported to the central server 191 00:12:06,999 --> 00:12:11,083 and it's sending full packets to the attacker. 192 00:12:12,876 --> 00:12:17,876 You have seen now it's on a telephone. 193 00:12:17,876 --> 00:12:23,083 It's based on Linux 2.4, but it works with any other signature. 194 00:12:23,083 --> 00:12:25,125 I have to work on the on this release. 195 00:12:25,334 --> 00:12:28,999 And now you can see that through my Android, you have 196 00:12:28,999 --> 00:12:31,083 the two alerts. 197 00:12:31,083 --> 00:12:34,999 One is for log in, the scan and the second one is that we have 198 00:12:34,999 --> 00:12:39,292 the ideas in remote and it's in these scans. 199 00:12:40,083 --> 00:12:43,792 The next thing I have to take care of is pattern matching. 200 00:12:44,584 --> 00:12:48,417 I don't work for NSA, so I have to work for myself to look 201 00:12:48,417 --> 00:12:54,459 at the traffic and look for a sequence of bytes inside almost every packet. 202 00:12:54,459 --> 00:12:57,999 This is a problem because some of the some of the tacks are related 203 00:12:57,999 --> 00:13:01,918 to a well known port and if we have to inspect almost every packet, 204 00:13:01,918 --> 00:13:04,876 we can have some false positives. 205 00:13:04,999 --> 00:13:08,417 This can be done by using a full state packet mapping. 206 00:13:08,959 --> 00:13:10,999 I'm still using on it too. 207 00:13:11,375 --> 00:13:14,459 I want to search for a pattern through very 208 00:13:14,459 --> 00:13:20,626 through several packets and it's the only way to make it work. 209 00:13:20,959 --> 00:13:24,292 So another thing I have to deal with was the signatures. 210 00:13:24,292 --> 00:13:28,626 There are some signatures from emerging threats for Android, 211 00:13:28,626 --> 00:13:33,501 and I have to run it on a script to convert that from Snort 212 00:13:33,501 --> 00:13:35,709 to our format. 213 00:13:35,709 --> 00:13:40,999 In this case, it's only covered Snort rules. 214 00:13:43,167 --> 00:13:45,959 We can only search for a specific pattern 215 00:13:45,959 --> 00:13:48,250 for a specific string. 216 00:13:49,250 --> 00:13:52,292 We should work with preprocessors and isolate 217 00:13:52,292 --> 00:13:55,584 the flow but still working on it. 218 00:13:56,209 --> 00:13:59,999 Some of the things, the exploits we have seen, 219 00:13:59,999 --> 00:14:02,167 is the USSD code. 220 00:14:02,167 --> 00:14:05,999 The USSD code is a code that is entering to your phone 221 00:14:05,999 --> 00:14:09,167 to perform some actions, and it's used 222 00:14:09,167 --> 00:14:14,999 by the network providers to gain the users to some access like code 223 00:14:14,999 --> 00:14:19,417 for wording and any of those functions. 224 00:14:19,667 --> 00:14:21,959 It's very simple. 225 00:14:21,999 --> 00:14:24,792 It links the browser to the phone application. 226 00:14:24,792 --> 00:14:27,626 That means that when you get into the web application 227 00:14:27,626 --> 00:14:29,918 and you have this code, the phone 228 00:14:29,918 --> 00:14:34,999 without human interaction will show you telephone application. 229 00:14:36,918 --> 00:14:44,834 So this exploit was published one year or so ago and we have several web 230 00:14:44,834 --> 00:14:49,250 signatures and we can detect it. 231 00:14:49,250 --> 00:14:53,083 In this case, I have you have to detect it, our exploit, 232 00:14:53,083 --> 00:14:56,709 and Android browser mode crash. 233 00:14:56,709 --> 00:14:58,999 You can detect the payloads. 234 00:14:58,999 --> 00:15:01,751 You can detect almost everything that you want. 235 00:15:03,334 --> 00:15:07,834 The last thing, I wanted to deal with was the malware. 236 00:15:07,999 --> 00:15:09,876 There are a lot of malware for Android. 237 00:15:09,999 --> 00:15:13,083 Almost every malware has a pattern. 238 00:15:13,083 --> 00:15:15,209 I search in this case, the MSN. 239 00:15:15,999 --> 00:15:18,083 You can go from here. 240 00:15:18,083 --> 00:15:20,584 And when you get downloaded it connects through the command 241 00:15:20,584 --> 00:15:22,751 and control server. 242 00:15:22,751 --> 00:15:25,083 You can clarify the string that it's using to connect 243 00:15:25,083 --> 00:15:29,999 to the remote server and the string to find the pacts is the RQ.php. 244 00:15:30,999 --> 00:15:34,083 We could just do those proofs. 245 00:15:35,999 --> 00:15:38,834 If we have the pattern the malware is using, 246 00:15:38,834 --> 00:15:44,209 we can detect almost every malware we have, and not only detecting it. 247 00:15:44,209 --> 00:15:48,417 We can drop all of the traffic that it's sending. 248 00:15:48,501 --> 00:15:53,584 On the other side, we have the meterpreter, I think you know, 249 00:15:53,584 --> 00:15:57,999 it's an ostensible payload for metasploit. 250 00:16:00,792 --> 00:16:03,334 It has some featured like command history, 251 00:16:03,334 --> 00:16:07,417 and top conventions and some channels some modes. 252 00:16:07,999 --> 00:16:10,167 Now there's an Android version. 253 00:16:10,167 --> 00:16:15,083 What I have done is creating a package for Android, installing 254 00:16:15,083 --> 00:16:18,375 inside of my own system. 255 00:16:18,626 --> 00:16:23,417 And tried to detect all the traffic that it's having. 256 00:16:23,751 --> 00:16:25,918 So the processor is the same. 257 00:16:25,918 --> 00:16:28,999 We have to get inside our Android device. 258 00:16:28,999 --> 00:16:30,999 We have to be root and we should launch 259 00:16:30,999 --> 00:16:32,918 the script. 260 00:16:33,999 --> 00:16:38,999 In this video, we can show how was the soft installed, 261 00:16:38,999 --> 00:16:44,751 but there several methods for assigning this kind of malware 262 00:16:44,751 --> 00:16:50,751 and it will only have to take a listening circuit for metasploit 263 00:16:50,751 --> 00:16:56,751 and connect it back from the from the Android device. 264 00:16:57,334 --> 00:17:01,626 So now we are waiting until the circuit gets opened. 265 00:17:02,209 --> 00:17:04,959 And when it does, what we are going to see is just connect and see 266 00:17:04,959 --> 00:17:07,999 whether we can detect all the traffic that's passing. 267 00:17:09,501 --> 00:17:13,459 So just at the bottom, we have found it. 268 00:17:13,709 --> 00:17:16,999 We can see that there is several comments that it sends 269 00:17:16,999 --> 00:17:20,375 from the meterpreter to get the system information and so 270 00:17:20,375 --> 00:17:23,083 and we have several comments. 271 00:17:23,083 --> 00:17:27,083 We are running it one by one and when you recall, 272 00:17:27,083 --> 00:17:30,751 the channel is very easy to see which comment 273 00:17:30,751 --> 00:17:34,959 is being executed the fun thing is I could have done 274 00:17:34,959 --> 00:17:37,792 a personal consult now. 275 00:17:37,999 --> 00:17:40,999 You can use some kind of honeypot because you are able 276 00:17:40,999 --> 00:17:43,999 to modify the packet in realtime. 277 00:17:43,999 --> 00:17:46,626 If you get infected, you can fool the attacker too. 278 00:17:46,876 --> 00:17:51,501 You can show whatever directory you want. 279 00:17:51,501 --> 00:17:54,918 You can send it pictures when he's asking for the welcome list 280 00:17:54,918 --> 00:18:01,250 or you can send it any audio file when it's trying to attach to the microphone. 281 00:18:01,250 --> 00:18:03,167 In this case, you see it's very simple. 282 00:18:03,167 --> 00:18:07,918 You have not only are we going to log this, we are able to drop 283 00:18:07,918 --> 00:18:12,083 the packet too in this case I'm not going to drop 284 00:18:12,083 --> 00:18:14,667 all this session. 285 00:18:14,999 --> 00:18:17,667 You see that it's working and what I want to do is only drop 286 00:18:17,667 --> 00:18:20,584 the packets related with the web cam. 287 00:18:20,959 --> 00:18:24,959 So now you can see that there is no way to access to the web cam 288 00:18:24,959 --> 00:18:28,918 and the ideas is blocking all the traffic. 289 00:18:29,209 --> 00:18:36,542 So with this, that's the way I found to create ideas. 290 00:18:36,542 --> 00:18:37,459 You don't have to depend on the Snort or 291 00:18:37,459 --> 00:18:40,417 the commercial appliance that costs $20,000. 292 00:18:41,167 --> 00:18:45,709 You can do it by your own and the only thing you have to work 293 00:18:45,709 --> 00:18:49,167 is having a great signature database to work this 294 00:18:49,167 --> 00:18:54,792 because the Android devices are the next target for attackers. 295 00:18:54,999 --> 00:18:56,542 So that's it. 296 00:18:56,542 --> 00:18:57,542 (Applause). 297 00:18:57,542 --> 00:18:58,542 Thank you. 298 00:18:58,542 --> 00:19:01,250 This is this is guy's first time speaking at DEF CON. 299 00:19:01,250 --> 00:19:02,250 How did he do? 300 00:19:02,250 --> 00:19:03,501 (Applause) Good job.