00:09:01.107,00:09:06.212 [applause] >>Oh ya that's the kind of subdued no sleep kinda hungover response I was looking 00:09:06.212,00:09:12.252 for. [laughter] So it is Defcon Sunday. Everything's a little bit slower everything's a little 00:09:12.252,00:09:17.857 bit more chill. How many people have to go home today? Aw that's too bad. How many people have to 00:09:17.857,00:09:22.862 go to work tomorrow? You've made a huge mistake. [laughter] I made that mistake once. I will 00:09:26.466,00:09:31.838 never do it again. You might make alternate plans um well either way thank you guys for 00:09:31.838,00:09:36.109 coming out. Um a few years ago at a couple different conferences actually I got stuck 00:09:36.109,00:09:41.114 with the Sunday morning hangover crowd um and it was no fun. So these guys are real real 00:09:43.183,00:09:48.188 troopers for getting here up soberish and ready to give you guys a awesome talk about how 00:09:51.958,00:09:56.963 fucked uh antivirus is on cell phones. So um uh let's give Stephan and Siegfried a big 00:09:59.833,00:10:04.771 round of applause. [applause] Have a great time. [applause] >> Ya good morning thank you. Um 00:10:10.343,00:10:16.182 I'm Siegfried and this is my colleague uh Stephan and today we will talk about uh anti-virus 00:10:16.182,00:10:21.020 applications in the mobile world and this was us trying to work together with our team members 00:10:21.020,00:10:27.427 uh Stephan, Michael, [coughing] Andreas, Phillip, and Daniel. Well so let's get started um 00:10:27.427,00:10:32.599 before we get started with the talk a a short announcement. Since this is our first Defcon 00:10:32.599,00:10:38.905 talk and uh since we're both from Germany we thought it is a cool idea to bring uh some local 00:10:38.905,00:10:43.910 beer to Defcon.So [whooping] [applause] So so this is what we did so we we we checked in this 00:10:47.447,00:10:52.385 bottle of this box of beer at the air port and the lady at the check-in counter was like what 00:10:52.385,00:10:57.824 the heck are you doing? Ha um she said like um I think it won't arrive in the US because 00:10:57.824,00:11:02.095 you are not allowed to do this and I said well let's give it a try and long story short so the 00:11:02.095,00:11:08.067 box arrived and it's over there only one bottle didn't make it but there are 19's left so after 00:11:08.067,00:11:13.072 the talk please feel free to come and have a beer. [laughter] [applause] okay so so let's get 00:11:18.411,00:11:22.882 started with the real talk. Uh a short a few words about ourselves so Stephan would you 00:11:22.882,00:11:29.789 like to say a few words? >>Ya hello good morning uh I'm Stephan and I'm a member of the 00:11:29.789,00:11:35.495 mobile test lab at the Fraunhofer Institute and I'm working on uh mobile securities 00:11:35.495,00:11:40.500 especially on uh Android and Android application security. >>Ya thank you. Uh I'm 00:11:42.802,00:11:48.308 Siegfried. I'm a fourth year Phd student at a German university at called TU Darmstadt in 00:11:48.308,00:11:52.879 Fraunhofer SIT about I'm about to graduate by the end of this year. [coughing] Uh my main 00:11:52.879,00:11:57.817 research focus is on static and dynamic code analysis in the context of war. Detecting 00:11:57.817,00:12:02.922 vulnerabilities or detecting malicious behavior um but this work was not only us it is 00:12:02.922,00:12:09.228 basically our team uh we established a hacking group called Team Sick half a year ago 00:12:09.228,00:12:15.201 and uh it's basically located at the university and we look into different um interesting 00:12:15.201,00:12:21.040 security topics and the anti-virus application was one of our first projects and uh we 00:12:21.040,00:12:27.380 will show you now the results of our findings. Okay so let's start with a little bit off 00:12:27.380,00:12:33.586 about motivation. Um I guess I do not need a motivation here in front of you guys uh but this 00:12:33.586,00:12:38.591 was is an interesting one. So a lot of banking applica- uh banking uh vendors and they have 00:12:40.893,00:12:45.898 some FHQ. In the FHQ there saying um you should install your mobile anti-virus um 00:12:48.468,00:12:54.407 application in order to seek in order to be secure and to securely use our um whatever 00:12:54.407,00:13:00.279 mobile transaction uh banking application so this they really rely on um anti-virus 00:13:00.279,00:13:05.985 applications and this is was is somehow interesting. So do they really protect us? These 00:13:05.985,00:13:11.224 anti-virus applications or if not then all this reliability of this banking application for 00:13:11.224,00:13:16.996 instance is somehow broken. So let's start a little bit about um uh some background 00:13:16.996,00:13:22.001 information um as we all know anti-virus application try to protect us um and their core is 00:13:24.637,00:13:29.742 the malware detection engine or the virus detection engine while it's based on signatures or 00:13:29.742,00:13:34.814 behavior um but in the mobile world apart from that these vendors have a lot of different 00:13:34.814,00:13:39.919 other features and these features are interesting for the rest of the talk. I will show 4 00:13:39.919,00:13:45.458 of them now. Um my favorite one is the lost and theft protection. So this means when 00:13:45.458,00:13:51.064 you lose your device there is a feature that you can remotely wipe or remotely block your 00:13:51.064,00:13:56.235 smart phone which which some other stole from you. Um there is a feature called device 00:13:56.235,00:14:01.974 configuration advisor uh which in Android you have a lot of security settings and it might 00:14:01.974,00:14:07.146 be the case that you did not set it in a secure way so this application warns you and say 00:14:07.146,00:14:11.184 well you probably should enable this or that feature you shouldn't do this and that. 00:14:11.184,00:14:16.255 There is secure browsing well this is well known I guess from the PC world um if you would 00:14:16.255,00:14:20.793 like to um um um browse a website or if you would like to open a website which is 00:14:20.793,00:14:25.798 malicious and they block it for you and spam protection is um in a mobile area more on um um SMS 00:14:28.334,00:14:33.339 spam or phone spam. And depending on the the vendor some of them offer these feature for 00:14:35.775,00:14:40.546 free or some you have to pay an amount so it's like a pro versions so you have to pay a 00:14:40.546,00:14:46.152 certain amount of money and then you get these nice features. So let's dig a little bit deeper 00:14:46.152,00:14:51.290 into these applications. Um I show you one um application I guess as the [inaudible word] 00:14:51.290,00:14:57.730 (5:50) application and this is the manifest so all permission it requires and but this is not 00:14:57.730,00:15:01.801 only conspiracy all of them require so many permission. As you can see there's like SNS 00:15:01.801,00:15:06.072 contact all this sensitive permission and why well it's obvious because from a previous 00:15:06.072,00:15:11.277 lab we've learned that they have a couple of features and the developer if they implement 00:15:11.277,00:15:16.549 these features they have to access certain security uh secure API codes. So they need 00:15:16.549,00:15:21.521 all these um API's all these sensitive API's so what while this is somewhat interesting 00:15:21.521,00:15:27.093 right because if you are able to do some remote code execution or something like this um you don't 00:15:27.093,00:15:31.764 need actually route so it might be enough if you only have this anti-virus application installed 00:15:31.764,00:15:36.169 because then you have access to a lot of sensitive data and you can easily um send it back. So 00:15:36.169,00:15:40.239 this was something where we started and was very interesting to see and then as a next step 00:15:40.239,00:15:45.344 what we did we looked on the Google Play store and we checked out a couple of applications. So 00:15:45.344,00:15:49.949 we picked only those Android application we had at least one million downloads because 00:15:49.949,00:15:54.821 they're the most interesting ones um they were Android, Helm, MEMbo Bytes, SSid, Avira, 00:15:54.821,00:15:59.826 Kaspersky, McAfee and Cheetah Mobile uh security. Uh I know there are more um well known um 00:16:02.328,00:16:09.235 AV vendors. The reason why picked only these 7 were we were our group um our group had 7 sub 00:16:09.235,00:16:14.640 groups and each of the group looked into one application therefore we had 7 so.Bu-but we 00:16:14.640,00:16:21.614 did not look into any other vendors. So let's get started with the real talk. Um for this 00:16:21.614,00:16:27.887 talk um we focus on 4 different uh challenges and there were a lot more challenges. In the end 00:16:27.887,00:16:32.191 of the talk you see uh our white paper and the link to the white papers so you can read all the 00:16:32.191,00:16:38.531 details but for this talk uh we will focus on 4 um challenges. First is it possible to do this 00:16:38.531,00:16:43.903 premium upgrade for free? Second, uh my favorite one misuse lost device features so 00:16:43.903,00:16:49.375 if actually possible if you have a anti-virus application installed to turn it into 00:16:49.375,00:16:54.881 Ransomer so actually to turn it into malware. Uh third one, remotely influence the scan 00:16:54.881,00:17:00.920 behavior so targeting the heart of these AV um applications and the fourth one uh is it possible 00:17:00.920,00:17:06.659 to do the remote code execution. Uh in the following we will show now a couple of um examples and 00:17:06.659,00:17:11.898 concrete exams and give you an overview um what what we found. So let's start with the first 00:17:11.898,00:17:18.271 one a premium upgrade for free and for this example we we have 2 examples. The first one is a 00:17:18.271,00:17:22.541 Android helm it's a very easy example and the second is a little bit more sophisticated. 00:17:22.541,00:17:29.181 Okay when you look at the Play Store for this antivirus application this Android Helm. 00:17:29.181,00:17:35.354 You see that it has a different versions of it. When you look very closely and also it it 00:17:35.354,00:17:40.359 differs from the price. So it starts from 9 Euro 99 which is almost now 9 dollars up to 129 00:17:43.429,00:17:50.069 dollars or Euros. Um so the reason is they offer different models so instance I guess the 00:17:50.069,00:17:56.909 129 dollar one was a uh unlimited usage of all the pro features and the 9 dollar 99 I 00:17:56.909,00:18:01.714 guess only you keys can use it only for one month or something like this it really it varies 00:18:01.714,00:18:06.719 and the the free version which is our very left one uh it's for free but it doesn't have the pro 00:18:06.719,00:18:11.590 features but you can of course pay a certain amount and then you get the pro features 00:18:11.590,00:18:17.129 depending monthly or yearly basis. So as a first thing what we did we would like to know how 00:18:17.129,00:18:23.135 did they check if it if it paid or not. And then we looked into the code and uh we found an 00:18:23.135,00:18:29.976 interesting code snippet uh saying thank you for upgrading to pro and uh putBoolean uh is 00:18:29.976,00:18:35.214 pro and true. So for those of you who are not familiar with Android uh in Android you have a 00:18:35.214,00:18:40.219 so called a sharedpreferences file. Uh this is an XML file which stores key valued pairs 00:18:42.688,00:18:49.395 and um it's only accessible within the application uh if you implement in a secure way. Um in 00:18:49.395,00:18:55.768 this case it stores as a key is pro and um as a value true. So when you when we looked at this 00:18:55.768,00:19:00.973 sharedpreferences file at the installation times or without any um uh pro feature enabled or 00:19:00.973,00:19:05.511 paying stuff uh you see that there are already a couple of key valued paired storage but 00:19:05.511,00:19:10.516 there was not no east pro 4's or something. So what would you do right? There's a first step of 00:19:10.516,00:19:15.688 course you add something like Boolean S pro at true and see what happens and this is what we 00:19:15.688,00:19:21.227 did we added this and then we started it and ya here you go so this was actually [laughter] so 00:19:21.227,00:19:27.500 so this was enough [applause] uh for for this application to upgrade it to to pro um. Just 00:19:27.500,00:19:33.172 for completeness for the first uh attack what I've shown an uh it's a mandatory to be uh have a 00:19:33.172,00:19:38.244 rooted device. Um now I will show you a very quick overview um how you do this without route 00:19:38.244,00:19:42.214 uh this is all well known but just for completeness. Uh You have your mobile device on the 00:19:42.214,00:19:46.886 left and then you have um the the PC and you have you can communicate with the PC via the 00:19:46.886,00:19:52.958 ADB uh debug bridge. So what do you do? You basically back up this application and since the 00:19:52.958,00:19:57.997 application allows the backup it is possible to backup the application and this backup also 00:19:57.997,00:20:02.401 includes the shared preferences file and then what do you do? You basically do a little bit of 00:20:02.401,00:20:06.839 scripting and there are already a couple of scripts out there which do this everything for you 00:20:06.839,00:20:12.511 and then you add this new line this is pro true and then you do a restore back uh enter your 00:20:12.511,00:20:18.551 application and here we go that's it and you can do it without route. Good. So this was 00:20:18.551,00:20:23.556 the warm up um and as a next step I would like to talk about with the how ESET did this um 00:20:26.225,00:20:31.297 good. In ESET it was a little bit a different uh situation what they had. They did not 00:20:31.297,00:20:36.068 check this on the client site they check the verification if it is a pro feature on the 00:20:36.068,00:20:41.240 server site. So you have your application on the left hand side and the back end is on the 00:20:41.240,00:20:45.044 right hand side and what you do you send you have an authentication with you use 00:20:45.044,00:20:49.482 username and password and if the username and password is sent at a backend it is checked if this 00:20:49.482,00:20:54.753 is the pro feature if you paid for a pro feature and if yes it sends you back yes you paid and 00:20:54.753,00:20:59.759 then you uh can enable this. Um so how could an attack work? Um we what we only will we need is 00:21:01.760,00:21:06.165 the username and a password because if you have the username and a password uh we can 00:21:06.165,00:21:11.670 whatever. Get our own application and set the username as a username and the password 00:21:11.670,00:21:17.042 as a password and we can basically we have the same features as the the the the 00:21:17.042,00:21:22.381 features from the from the victim. So how can we do this because eh what they did they 00:21:22.381,00:21:28.354 did a good job they did a TLS protection at least it will not send by a plain text and ya. So 00:21:28.354,00:21:34.493 what can we do? Well there are well known vulnerabilities to SSL TLS what we wouldn't lie 00:21:34.493,00:21:39.031 what we didn't like to whatever to crypt or breaking stuff or something like this isn't there 00:21:39.031,00:21:45.538 an easier way to do this um and ya so. The the problem with an Android at least with TLS and 00:21:45.538,00:21:49.909 SSL implementation is it's not that the protocol is the problem it's the problem that the 00:21:49.909,00:21:54.813 developers implement this in an insecure way they do so-some mistakes and it's stuff and a 00:21:54.813,00:22:00.786 very common mistake is that they do not check uh the SSL certificate for instance. Uh 00:22:00.786,00:22:06.859 more concrete in Android if you for instance as a developer you uh create an SSL communication 00:22:06.859,00:22:13.866 via HTTPS uh the operating system itself checks um if there is a if the certificate is 00:22:13.866,00:22:19.605 really the server certificate it does some a chaining stuff but you as a developer for what for 00:22:19.605,00:22:25.277 you can do this by yourself so you can check these by yourself and as an example what you have 00:22:25.277,00:22:30.950 to do if you would like if you whatever do not trust uh Android or Google or if you say I have 00:22:30.950,00:22:35.221 my own checks. You an do this by yourself the only thing what you have to do you have to implement 00:22:35.221,00:22:40.492 this X509 trust manager for instance and then you have to implement a couple of methods 00:22:40.492,00:22:45.531 which do the checking. And one method is the check server trusted method and within the 00:22:45.531,00:22:50.102 body you have to implement for instance as it says pending and all that stuff um what do you 00:22:50.102,00:22:55.574 have to do. And uh well so this is so did ESET uh for whatever reason they implemented their 00:22:55.574,00:23:00.879 own X509 trust manager and then we also saw the check server trusted method and when but when 00:23:00.879,00:23:06.285 we looked into the body we saw it was empty. So what does this mean? This mean they do not 00:23:06.285,00:23:11.257 check if there's if I do a man a middle attack and I have my own certificate this method gets 00:23:11.257,00:23:15.995 caught and it does nothing so what? As a cell is basically broken so we can do a man in 00:23:15.995,00:23:21.433 middle here. So the first so now we are at a situation that we can do a man in middle so we are 00:23:21.433,00:23:25.938 sitting in the middle of uh ESET and uh back end and then we basically sniff what's going 00:23:25.938,00:23:32.845 over the wire. And um as I mentioned for what we did as a test we set up um our pass uh 00:23:32.845,00:23:37.583 username is Tester and the password was test and then we looked at the wire and what we 00:23:37.583,00:23:41.720 found was something like interesting. So the username the license username is probably 00:23:41.720,00:23:47.693 username and the belly was not tester so they somehow encrypted it additionally. So this means 00:23:47.693,00:23:52.197 they did not rely on the TLS protection or they put an additional encryption layer on 00:23:52.197,00:23:58.203 their the credentials which were sent uh somewhere interesting. Then we were interested in well 00:23:58.203,00:24:03.542 how do they do this and and um well when you use when you look at the password thing you see 00:24:03.542,00:24:09.148 some interesting things. When you look at the bay 6040 corded value for tester it is 15D6B1 00:24:09.148,00:24:14.153 and so on and for test it's 15D6 and so on. So this is somehow interesting right so it looks uh 00:24:16.955,00:24:22.528 similar. So let's look up uh a little bit deeper in this. So what we did is next we did a so 00:24:22.528,00:24:29.201 called uh chosen plaintext uh attack. So we used as a username for instance AAAAAAA and so on 00:24:29.201,00:24:34.039 the first we looked at a cipher how the cipher looked like. When you look at this table you see 00:24:34.039,00:24:40.713 that every second byte is reddened in it it's useless so we can easily remove it and then 00:24:40.713,00:24:46.352 when you look at the positions of the plain text the characters there the first character if the 00:24:46.352,00:24:51.724 first character is an A for instance the cipher is always 0. If the first character is a B 00:24:51.724,00:24:56.895 The cyphers'll always be 6 and so on and so forth. So this showed us that first of all a 00:24:56.895,00:25:01.667 second byte is not required. Second there is somehow no chaining involved in this 00:25:01.667,00:25:07.139 encryption scheme and it looks like a simple substitution. So maybe some of you have already 00:25:07.139,00:25:13.812 seen how the substitution works but I will show it to you know in in more detail. So let's come 00:25:13.812,00:25:19.885 to this point here. So first we used is the letter A and you have a cipher 0. So how can you 00:25:19.885,00:25:25.657 come from an A to a 0? Hmm Obvious right so use X or with A as a first position let's verify 00:25:25.657,00:25:30.662 if this is correct. We use B as the first letter X or with A is 3 right so we do the same C X or 00:25:33.298,00:25:38.504 With A is 2 which is correct here. So this showed us is somehow just a simple X or with 00:25:38.504,00:25:44.143 a key. So what do you do as a next step? Of course you create a very long um um plain text you 00:25:44.143,00:25:49.882 create then you look at the cipher. You do an X or and then you have the key that's it. Just 00:25:49.882,00:25:55.154 for verification so first uh we broke the SSL TLS communication because it was implemented in an 00:25:55.154,00:26:01.059 insecure way, second we figured out their encryption scheme uh we had the key here and then for 00:26:01.059,00:26:06.465 instance for the user tester um this is the encrypted one and then we X ored it with the key 00:26:06.465,00:26:13.038 and we got tester. So here we go this was it and um here we go. Good. [applause] ya thank you. 00:26:13.038,00:26:18.043 Uh next challenge's so I will hand over to Stephan and he will talk about uh the next 3 00:26:22.014,00:26:28.420 challenges. >>Okay hi. Um I will now present uh rest of our challenges and the next will be 00:26:28.420,00:26:34.927 Seigfried's favorite uh misuse lost device feature. Um here we have again our old friend the 00:26:34.927,00:26:39.698 Android Helmet if you remember this was the one with a sophisticated uh license 00:26:39.698,00:26:45.737 verification and so we thought okay lets to cool so we'll look into the um lost device 00:26:45.737,00:26:52.578 features. Uh showed uh somebody what what do we understand on the lost device features. Sig 00:26:52.578,00:26:57.316 Siegfried also explained it's a very easy functions so if you have installed this uh 00:26:57.316,00:27:03.088 anti-virus application you can activate this feature and if you get lost your uh smartphone or 00:27:03.088,00:27:09.361 it gets stolen you can use another smartphone or a desktop PC and remotely activate some 00:27:09.361,00:27:15.767 features like uh device location, remote wiping, or also remote locking and the question 00:27:15.767,00:27:22.708 is now can we for instance abuse this uh remote wiping or this the uh remote locking um without 00:27:22.708,00:27:27.713 any authentication and so transform the um antivirus application into a malware and 00:27:29.982,00:27:36.955 uh for instance lock it remotely and blackmail the user. [coughing] How is remote 00:27:36.955,00:27:42.995 communication in this services implemented in con? Um at first test uh Google cloud messaging 00:27:42.995,00:27:49.735 this is um service by Google which you can implement and use and um for communicating the the 00:27:49.735,00:27:55.173 um smartphone. There were also some other push uh service provider and you also can use 00:27:55.173,00:28:00.479 the S's SMS message messaging system. This means if you want to trigger something on the 00:28:00.479,00:28:06.618 device remotely you just send uh S uh SMS message and the application will get the message 00:28:06.618,00:28:13.125 and for instance execute some comment. In our case this application uses uh SMS message 00:28:13.125,00:28:18.130 communication. So here you see an excerpt from the application and here it explains how the um 00:28:21.667,00:28:28.373 anti-theft feature or the remote protocol for SMS is working. So by default this feature is not 00:28:28.373,00:28:34.746 activated this is an important fact and we'll explain later why this is a problem here and if 00:28:34.746,00:28:39.885 you activate the feature the user has to define 2 phone numbers from a friend so if his 00:28:39.885,00:28:44.389 device gets lost he can go to a friend and say hey sorry I want to track my device can you 00:28:44.389,00:28:50.262 borrow me your handy and then he can send the comment SMS. The comment SMS you see also listed 00:28:50.262,00:28:55.767 here as a prefix you have a password so it looks okay you have to authenticate and then 00:28:55.767,00:29:00.606 you have a space and then the comment. For instance if you want to trick uh the location 00:29:00.606,00:29:05.611 you send from your friends handy the uh an SMS with your password a space and the comment locate. 00:29:08.647,00:29:14.119 Let's take a look more detailed on the process so on the left side you see the user he's 00:29:14.119,00:29:19.291 sending an SMS and the application itself is in some kind of uh wait state waiting 00:29:19.291,00:29:25.297 for the SMS. For all of our Android people it's just as simple. Broadcast receiver which 00:29:25.297,00:29:30.302 receive the SMS message and execute some reaction. So here you see our um SMS message. At 00:29:32.738,00:29:38.910 the beginning you have password here. My pass separate pass space and the comment in here uh 00:29:38.910,00:29:45.517 here is an example wipe. Eternally the application now splits the text into 2 parts on 00:29:45.517,00:29:51.423 the space side so we have the internal variable its called an SMS password. In this case it's 00:29:51.423,00:29:57.863 our password my pass and the second variable is the comment uh here it's wipe. Then there's 00:29:57.863,00:30:03.869 a password check. It checks if the uh transferred password in the SMS is matching to the 00:30:03.869,00:30:09.841 stored password in the application. If this fails the comment will not be executed and 00:30:09.841,00:30:14.846 it's getting back to the wait state. If the password is equal it will execute uh the comment. 00:30:17.015,00:30:22.287 Okay now where's the implementation flaw in this process. As I already mentioned 00:30:22.287,00:30:28.527 by default this feature is not activated. So it's means it's deactivated and as an attacker 00:30:28.527,00:30:33.532 can uh use this um deactivated uh feature. So on the left side you again see our attacker. He 00:30:35.600,00:30:40.605 will send mal uh malicious SMS. Um for this case he has to know the number of the victim and he 00:30:44.543,00:30:49.581 sends a simple crafted SMS it looks like the following. At the beginning we have an empty 00:30:49.581,00:30:54.586 string then we have a space the our comment an additional space and some ya uh irrelevant 00:30:57.155,00:31:02.094 string. The application now will split at the wipe. The first variable our SMS password is 00:31:04.796,00:31:11.369 empty the comment you see is our wipe and now if you have the password check process and the 00:31:11.369,00:31:16.742 default the password is an empty string. Now when we compare our empty string with our 00:31:16.742,00:31:21.747 transferred password the empty string this is matching and the comment is executed. Now you're 00:31:23.782,00:31:26.785 asking okay [applause] [cough] [applause] Now you're asking but um what about the friends 00:31:26.785,00:31:33.258 telephone numbers it also checked yes but it's the same process. If there's no number 00:31:33.258,00:31:38.263 it's an empty string and also in SMS you can spoof the number I think this is nothing new. Okay 00:31:41.967,00:31:48.740 so as you see they failed something in the process [laughter] Okay second challenge 00:31:48.740,00:31:54.446 now uh the third challenge is um can we remotely influence the scan engine or the behavior of 00:31:54.446,00:32:00.085 the scan engine. Here we have a new example. Here we choose the malware the malwarebyte 00:32:00.085,00:32:05.991 anti-virus application and at the beginning here you see a short scheme. As you know the 00:32:05.991,00:32:12.397 most um or every anti-virus application does it's own signature updates every hour 00:32:12.397,00:32:18.737 everyday and so on to p um keep the signature database um up to date. In this case the mother 00:32:18.737,00:32:23.742 byte application is doing this by plain text HTTP so um HTTP is not anywhere uh protected you 00:32:26.278,00:32:31.283 have no authentication no confidentiality no integrity check and um smartphone are 00:32:33.685,00:32:39.758 wireless devices so you can imagine wireless communication in unprotected traffic is uh not 00:32:39.758,00:32:46.464 such a good idea. So in our first step we set up again a simple man in the middle uh 00:32:46.464,00:32:52.771 listening on the HTTP traffic and what we saw is that the um the signature request to the 00:32:52.771,00:32:59.744 back end responses with the signature update. In this case this is an zip archive which is 00:32:59.744,00:33:04.683 um additionally encrypted. encryption algorithms algorithm is our c4 um i don't know but uh 00:33:07.686,00:33:12.691 our C4 is not the best. Uh the algorithm for doing um secure encryption right um ya we were 00:33:15.260,00:33:20.932 too lazy to break it um and it's much easier because the symmetric key of the um 00:33:20.932,00:33:26.371 signature encryption is stored in plain text in the application [low talking] so if you look 00:33:26.371,00:33:31.243 into the application or make some string you will find the crypter key. The man in the 00:33:31.243,00:33:36.248 middle attacker simply decrypts uh the archive can remove for instance the signature um 00:33:39.251,00:33:44.256 repackage re encrypt and forward it to the victim and now um the scan engine has UFCC empty 00:33:46.324,00:33:52.197 signatures and is it's next level attack for instance he can send uh well know mal malware or 00:33:52.197,00:33:57.202 rat tool and uh hijack smartphone and uh the victim is not protected anymore. Ya um as 00:33:59.871,00:34:06.278 I already mentioned it's uh simple plain text attack it's not so sophisticated. So we show 00:34:06.278,00:34:12.984 you the last challenge. It's more um complex it's now um remote code executional so can 00:34:12.984,00:34:18.390 we inject an anti-virus applications some foreign code and remotely trigger this code 00:34:18.390,00:34:23.395 execution and as you think yes we can and we here for this example we choose uh Kasperski 00:34:26.197,00:34:31.202 antivirus and internet security application. Here again at first as you see okay we uh have our 00:34:33.838,00:34:40.578 HTTP requests for the signature update. No encryption no authentication but in this case 00:34:40.578,00:34:45.750 Kaspersky has done better work they've implemented some integrity protection. I think 00:34:45.750,00:34:52.357 the update is not so um that you need uh confidentiality but uh integrity protection is very 00:34:52.357,00:34:57.329 important so if a man in the middle attacker tries to modify the update or the signature 00:34:57.329,00:35:03.301 files the application will reject this so at the beginning we thought okay um Kaspersky has 00:35:03.301,00:35:09.174 done good work everything is okay. So despite of this we set up our man in the middle 00:35:09.174,00:35:15.313 attacker and looked at uh different HTP requests as you can see the application is 00:35:15.313,00:35:20.318 transferring some uh zip archives some XML files and some uh [cough] jar files. What do 00:35:22.654,00:35:27.659 you see here in this um zip archive this is just um some uh company internal advertisement 00:35:30.895,00:35:37.102 and containing some XML HTML files some configuration XML files and an interesting file is 00:35:37.102,00:35:42.107 the route detector dot jar file. This uh jar file contains some um Android executable code you 00:35:44.442,00:35:49.981 can imagine is um more generic cause a library containing executable code which will be 00:35:49.981,00:35:54.986 loaded from the application during run time and in our first step we'll ope we just injected 00:35:57.255,00:36:02.193 some um text file into the archives and ya there's a signature protection and we 00:36:04.562,00:36:09.567 could not modify or inject some executable code in this route injector but the zip archive um 00:36:11.836,00:36:15.507 was not it looked uh seems that the zip archive is not protected. There was uh no 00:36:15.507,00:36:17.509 rejection when we entered the um our evil txt file. Okay now we take a look into the application 00:36:17.509,00:36:19.511 folder. Here you see now the the application folder and our zip archive which is extracted after 00:36:19.511,00:36:21.513 the update from the application. Here you see as I mentioned this is just some simple 00:36:21.513,00:36:24.949 advertisement banner with some java script CSS HTML files so it seems it's not so so critical 00:36:24.949,00:36:29.954 and at the end here you see our uh injected evil dot teegs T file. So at first we think 00:36:52.477,00:36:58.817 thought okay we can do nothing just enter the text file or just [inaudible word] file. Some file 00:36:58.817,00:37:05.557 is a problem because the code will not be executed. So let's take a more detailed look in the 00:37:05.557,00:37:10.562 rest of the files the application contains and here we have some additional files. 00:37:10.562,00:37:15.900 Again you see in the middle our route detector file which will be loaded by the update but we 00:37:15.900,00:37:22.040 also have a PDM dot jar file. As already mentioned it contains executable code like a library 00:37:22.040,00:37:27.745 which is loaded during the run time but this PDM dot jar file is not loaded with the update. 00:37:27.745,00:37:33.384 It's part of the application so for the Android guys it's um in the APK files though at the 00:37:33.384,00:37:38.389 first installation the PDM dot jar file is already there. As I said it's part of APK, contains 00:37:40.825,00:37:45.830 executable code and our route detector is fine so this is not really a tech corrector but 00:37:48.066,00:37:54.139 let's take a look at our PDM jar file. Now we injected instead of uh the text file we injected 00:37:54.139,00:38:00.178 really a PDM file a PDM dot jar file with our own crafted executable code but the problem 00:38:00.178,00:38:05.116 is as you see the PDM dot jar file is still in this zip um folder or in this folder which 00:38:08.486,00:38:13.491 which is created by extracting the the advertisement library. So we have some to find some way 00:38:15.527,00:38:20.532 to breakout of this archive and to override the PDM dot jar file and um [cough] one one technique 00:38:24.169,00:38:30.575 for this could be path traversing or directory traversing. This means if the um 00:38:30.575,00:38:35.580 zip library for instance which is used by Kasperski does not uh evaluate the um file names in 00:38:38.449,00:38:43.454 the zip archive correctly we can perhaps inject some um malform malformed um archive uh uh file 00:38:46.791,00:38:52.530 names and because of missing escaping we can break out of this uh directory and override 00:38:52.530,00:38:57.535 this PDM dot jar file. So um I will now show just the the exploit and explain it in a few 00:39:00.905,00:39:07.178 details. As I said we have to override the PDM file with our manipulated file so we crafted 00:39:07.178,00:39:12.183 our own zip file and if you look at the content of the zip file it's lis as you can see we have 00:39:15.153,00:39:20.158 our CSS HTML advertisements stuff and our own PDM jar file but uh this is no um folder 00:39:22.694,00:39:28.566 prefix as we as you see this relative path and the dots and slash slashes are part of the 00:39:28.566,00:39:33.571 file name. This means the whole file is named dot dot slash dot dot and so on and because of the 00:39:35.673,00:39:41.946 um an um erroneous uh implementation of the zip library in the application it 00:39:41.946,00:39:48.119 will be extracted and paths will be interpreted and our PDM dot jar file will be overwritten and 00:39:48.119,00:39:54.392 loaded by the application on the next startup. So uh I get for sure try to get for sure summary 00:39:54.392,00:39:59.297 again of the attack because it contain more steps and was a bit more complex and at first at the 00:39:59.297,00:40:03.868 beginning we found an unprotected communication because of the HTP update 00:40:03.868,00:40:08.873 requests. Then we augmented our zip file with this uh renamed uh directory or path traversing 00:40:11.042,00:40:16.614 file. This uh was possible because the advertisement archive was not integrate 00:40:16.614,00:40:21.619 integrity protected and the um zip library which is used um contained implementation flaw. 00:40:23.922,00:40:28.926 We overwrite existing executable code by our own code. [coughing] and at the end when the app 00:40:31.062,00:40:38.002 restarts this injected code will be executed and this is working. We have no demo but a relied it 00:40:38.002,00:40:44.776 was working. Okay so our challenges are solved here or the examples we wanted to 00:40:44.776,00:40:49.781 present to you. Here you see a summary of all our findings on on the top of the table you see 00:40:52.016,00:40:57.288 again the the different applica- uh the different apps we analyzed. On the left side you 00:40:57.288,00:41:03.561 saw the different type of vulnera vulnerabilities and possible attacks and if you take 00:41:03.561,00:41:08.566 a more detailed look in it you see nee each application has at least 2 or more vulnerabilities. 00:41:10.635,00:41:14.872 If your interested on the advisaries and more details of the vulnerabilities on the 00:41:14.872,00:41:20.878 attacks. On the bottom you see the link to the um detailed advisories. Uh these are also 00:41:20.878,00:41:25.883 the advisories we send to the different um anti-virus uh vendors. At the end we want to 00:41:28.853,00:41:34.292 give just some um experiences which we made at the responsible disclosure process with the 00:41:34.292,00:41:40.798 different companies. We informed all companies but as you see one did not uh fix the 00:41:40.798,00:41:47.171 vulnerability. They did not react on our um announcement we tried sever several ways. We 00:41:47.171,00:41:52.176 sent emails we tried rep forums we also tried to contact them by the Google Play store but uh 00:41:54.612,00:42:01.319 there was no reaction so if someone is here from uh Android tell em uh please come up later 00:42:01.319,00:42:06.657 or in the end you find our contact informations. Other fails we had during the 00:42:06.657,00:42:11.062 responsible disclosure was some of the app companies which provide websites where we can 00:42:11.062,00:42:15.533 announce when we have found a vulnerability and they also provide a public key that you 00:42:15.533,00:42:21.506 can transfer your email confidential but on one the public key was expired so how to 00:42:21.506,00:42:26.878 transfer it. I wrote an email. Can you send me a key? Here comes the answer there were keys 00:42:26.878,00:42:32.383 on the website. I wrote again the keys expired. Okay thank you we send you a new one. Another 00:42:32.383,00:42:37.388 website contains a public key PGP key and it was valid but the email was not matching. So again 00:42:39.791,00:42:45.897 send me a correct email and some other did not also did not react. Phoned them by email and 00:42:45.897,00:42:51.602 so on but there we had luck because uh we met the um research director of uh 00:42:51.602,00:42:57.742 antivirus security of this company at some conference. I was telling him about my problem 00:42:57.742,00:43:02.680 half an hour later I had a PGP key and an email. Um what did we learn? Ya also big security 00:43:06.050,00:43:11.055 companies fail in implementation. It's it's um developer are just humans. Human 00:43:13.524,00:43:19.297 makes mistakes but on the other side and um this companies work a lot of people who sh who are 00:43:19.297,00:43:24.302 awares of those problems and um they sometimes should look into their own code or um make some 00:43:26.537,00:43:32.143 uh code audit internally or externally. There's still room for the improvement in the 00:43:32.143,00:43:37.148 responsible disclosure process and um the last thing is a bit more funny um they also it seems 00:43:39.584,00:43:45.189 they also will reuse their code in different products because I think the most of you know the 00:43:45.189,00:43:51.596 name Tevis Romandy. He was also hunting box in a Windows anti-virus applications and he 00:43:51.596,00:43:56.601 found we found also one buck which he found in another application but um um he was 00:43:59.070,00:44:04.008 faster in announcing it so I missed a buck bounty. Yo um this is our presentation you can see 00:44:07.145,00:44:13.351 our contact information also a Twitter handle of and the website of our students group. 00:44:13.351,00:44:18.356 They also find the advisories and more informations about our project and um ya thank you for 00:44:20.458,00:44:25.196 your attention. If you have questions feel free. You will also a secret announce you can 00:44:25.196,00:44:30.568 meet us later or here now we have some beer we can drink a beer discuss about this uh 00:44:30.568,00:44:35.573 security or Android security just uh feel free. Ya thank you. [applause]