>>Ok, hello and welcome to our talk. Thank you all for coming. Um, I’m Siegfried and this is my colleague, Stephan, and today we will talk about Android password manager apps. Um we are both from Germany, from an institute called Fraunhofer SIT. A short announcement: um as last year, we did it again. Um, so we imported a couple of beers from Germany, actually from Munich, and we brought it to Vegas and well, unfortunately we weren’t allowed to bring it on stage, but it’s safe somewhere in the in the crowd. So feel free to come after our talk outside the hall and grab a beer. So there are 20 cool Bavarian beers outside. [applause]
Thank you. Good, so let’s start with the um introductions. Stephan, will you say, would you like to say a few words?
>>Yeah, hello, my name is Stephan. I’m also employee of the Fraunhofer Institute and I’m working there as a security researcher with the focus on Android security.
>>Thank you, Stephan. Um, I’m Siegfried. I’m head of the department of secure software engineering. Um my main research focusses on static and dynamic code analysis in order to find vulnerabilities or malicious activities in aps or in software in general. But this talk is not about us, um it is about our group, our hacking group, um called teamsik. We are a group um of students from the university and a couple of guys from our research institute and we meet up regularly once a week and um we sit together and we look into interesting um security problems or issues and this time we looked into password managers and um yeah, this is why we are here and we are presenting our results. So the credits also go to those brilliant students and not to us, so they helped us a lot. Good, so let’s start with the motivation. Um I guess all of you have seen such kind of screens want to create once you want to create an account for instance on google or something. Um the the thing you are at a point at the slide is that we have a policy, a password policy, which is very great. So a password has to have a certain length to be secure, it has to have, has to contain a certain characters, upper and lower letters and special characters and so on and so forth, which is very great even if you um services tell you hey, this is a well-used password, choose another one. This is very cool um it is very great for security reasons, um but so the wish is basically that it remembers such kind of passwords, even longer ones. I mean, personally I’m not able to remember such kind of passwords, even when you think about that an average user has 30 to whatever, 50 different services and it, so it’s very hard. So password managers came up with, or or no, password generator tools came up with the cool idea to link, basically the generated password to a sentence. So in this case for instance the password is, the generated password is X3-R and so on and obviously the sentence you have to, you can connect to this password is XBOX3-ROPE skype TOKYO and so on. Well, it’s a nice try, um but even though I’m not able to to connect this sentence to the password, so still this this is a very big problem. So the point here is we should come up with some complex passwords but it is very hard to remember them or to so. So what does the reality look like?  At least what we figured out in my personal environment I have a lot of friends that make use of old-school notebooks. So they store or they write down the passwords on page whatever 120 between a very secret text or something this which only they know. Um it’s interesting, and but what we all know that it doesn’t work and it doesn’t really protect your passwords. Um on the other side password recycling um from our current project, not this one, a new one, one we are currently working on, we see that one that is also known, is that a lot of users make use of the same password for all the different accounts. Um this is also not a good idea, and then well, there’s also like single sign-ons. This kind of things where you have one account and when you login you can also login to another account. Um well there are also security issues with that and if you lose the first, basically password, it’s a problem. And this basically brings me to our topic today, to password managers.
So for a password manager you have a very long list of passwords which protect or which protects the um accounts, your credentials for Google or whatever, all your different accounts. You only have to remember the long one and then it decrypts all your other credentials. Well, and we ask ourselves the question, um at least in the mobile world and did these guys implement in a secure cure way or were there some security issues? Doing though what we did as a first step we went on Google Play and we downloaded a couple of um password managers um listed by the top download rates there. Um first question which probably comes into your mind: why is it only nine and why only those and why isn’t there xyz? Um a very easy answer. So our group usually sits together and then we split it up into sub-groups and each sub-group takes 1 or 2 apps and looks into it. So every group had an app and looked into it and in all of the groups and every group found vulnerabilities, so in the end wa it was not fun anymore and after a while we stopped it and we summed everything up. So this is the reason we didn’t look into other password managers as well. So, spoiler: um we found 26 vulnerabilities in total, as already mentioned, at least one in all of them, um in each of them. And while a couple of them were already presented at a different conference “Hack in a box” this year, er but for Def Con we will show the remaining ones and we will also explain um our findings from a different angle, we will explain, give you more details. Ok, so what will be the topics today? Um apart from the goal of extracting the master password or distort credentials is always a fun game in our group to check out the premium features if we can get the premium features for free. So we’ll talk about this in a second and then we will talk about reinserting the password as is. So can someone reset the master password in order to then have access to the stored credentials, and then in the second part we will talk about breaking C.I.A without ROOT, meaning having access or extracting the master password without ROOT or extracting the um the stored credentials without ROOT. For confidentiality reasons integrity like um, modifying them and the availability er um like, blocking it that the user cannot um log in to this again. Um everything is important without ROOT so because if it would be rooted to the device it would be kind of much easier to access this kind of thing. So we, basically our goal was to do it without ROOT. Er we tackled it from 3 different angles. Um the first one: lost device scenario: a tackle on basically if I find a smart phone and I can enter it and I can then click on the password manager, for instance, is it possible for us to have, get access to the credentials without even entering the master password? Er second scenario: man-in-the-middle attack: so if I’m sitting in the same network and they are synchronizing their um credentials, for instance, is it possible to to extract it? And via third party app: this means that if I install my application on the device, is it possible that this third party application kind of be malicious, um can have access to the master password or the stored credentials.
Ok, so let’s get started: premium upgrade for free! Good, so we looked into different apps and a couple of them had the premium features. So you have to pay in order to get super cool new features and in this particular case you had to pay $3 in order to get like um export import cvs files, theme selection where you could choose between black and white, very cool. Well, even $3 is not a lot we wanted to try if we can still er still have access to these super features without paying. Um on the right-hand side you see that um, well, once you interact with the app there is a screen like a settings in a database, which already promotes that there are more features but you have to pay for them, so they are greyed out, in this case, AUTO BACKUP, for instance if you would like to do a Google Drive backup, you cannot do it without paying. So if you pay the $3, so then you you can enjoy with it. And this this slide is important, be we will later see why.
Before coming to this very very brief overview about Android IPC communication especially intent communication, for those of you who are not so familiar with Android. Um, well if one application App 1 wants to talk to App 2, for instance, in Android it is usually in the most of the cases it is not done directly. So it’s done by a so-called intent. So an intent is sent basically to the operating system to Android and then Android decides which application should receive this message or the data which should be shared. Um how is how does it work? Well, application 2 has so-called filters, so application 2 can define a filter so the operating system knows hey this application is allowed to or this application wants to know later if some or a specific intent is sent. Um of course application 2 can also use some security mechanism to pro to prohibit that it receives intent er which shouldn’t be um received by this application. Um and the same works um of course if in one application there are usually more components in Android, while for instance activities. If one UI wants to share data with another UI the same principle works, so it’s sent first to the Android operating system and then it’s sent back the intent to the second UI, for instance. Good. The same works if you apply er if you plug in a smart phone um to to your er er sorry a PC through your smartphone you can also send so-called intents um to the Android operating system and then it sends the intent to the application 2 for instance. A very brief overview we were done um, but I guess this is enough information. Um well I can give more info, but it is not necessary for this talk or for the following slides.
Good, so let’s coming back to our backup feature. Um so we were curious, how did they implement um the backup handling? Or sorry sorry the the pro the upgrade the pro feature? And well I simplified the code here because it was a little bit more sophisticated, but um the important points are here. What they did is they stored if a PAID or not into a field, so basically into RAM and once they receive an intent um with the key like PAID-STATUS and the values in digit 2, they set the PAID value to true. And once they render basically the UI then they enable this backup, Google backup, for instance. So what does this mean? This means well if I connect a PC or any application to it which sends intent for instance with the adb shell command to the Android operating system, well I can enable the features without any pain. Ya, this is so simple. Um the only problem here is that it is not persistent because it’s stored in RAM, so if I close the application and I open it again it is disable again. But what you can do is once you sent the intent and you see the features like Google drive backup, you can then click on YES I would like to use Google drive backup and this setting is stored persistently, so this means I once send er an intent and then Google drive back-up, I click on it and I close the application and I open it again it is greyed out, but it’s enabled the setup. So you basically own it and you can do with whatever you want. [applause]
Ok, so let’s talk about resetting a master password. Good, um so this is a a common way or common process that we found in the apps. It’s not in channel what we found those apps we looked into how they handled forgetting or resetting the master password. So once the user forgets the master password he clicks on Forgot Password and then he gets a screen showing please enter usually 4 digits and these 4 digits are sent um to your email a client email account, which is connected to the password manager. So you open the email client, you extract a 4 digits and you paste it into your app and then the verification is done. If this is correct then we come to the second stage, the security question. Well this is predefined by the user. Well, whatever, the name of your mother or something, you type this and well if it is correct then you can reset the master password and once you reset the master password, you have access to all the stored um er credentials, basically, well this is obvious. Good, so we will focus on the following um on this particular part on the security question. And the whole thing is from a lost device scenario, so this means we find a smart phone, we have access to it and, yeah, we will s, basically, this is the scenario. So we started again looking into the Android manifest, which is the configuration via an Android, which contains all these intent filters as well and we found an interesting intent filter that there is which can be received which, so this activity which is triggered then can receive external intents, and once you send an intent you get a basic er an activity called DeepLinkActivity. It doesn’t sound so fancy, we will see. So start while you can do this. Start with like for instance with a PC again or you can do this as well with an with an application. So once they send this command to the device or the application’s install I will get a screen like this. Well, it doesn’t sound er doesn’t look very cool, so in this middle part there is supposed to the app list all the stored credentials. They use an app for things like Google, Facebook, and so on and so forth. So luckily or fortunate they didn’t list the username and password immediately when we sent this intent, because this would mean that you basically circumvent the authorization with the master password and you will immediately see the credentials. So at least they didn’t do that wrong, which is very good. Um but then we saw an interesting um settings um at the bot at the top of the er activity and once you click on the setting you will see that there are different settings. And er one of them is the Reset Security Question. Well, this is all done without any entering password and then, well yeah it can choose a new security question, whatever the name of my mother or something like this and enter it and it basically connects you to the you email acclount, email account which, well, which is connected to the er password manager application and the old security question is basically overwritten. So what this means, this means we we own this part in in the process. However the verification code via email, um this is the problem, but well we’re saying if you find a device and you have an email account, an email client, for instance, gmail, you also can open the gmail account to have access to the verification code, then paste this into your application, then do the um um security question process and then you can reset the master password when you have access to all the stored data. So this is er the the only drawback here that you er well have to have access to the to the email client as well. Good, so this was it from my part. I will now hand over to Stephan who will continue with the rest of our findings.
>> Ok, thank you Siegfried. Um I will talk now about getting access to the Holy Grail, so their their Master Secret, what is the master secret in the password manager? It can be the the main password which is used when entered at the beginning, which is used to encrypt your credentials. It can be just a 4 digit pin which protects your stored credential or it can also be the the master key, which is used for encrypting all your data. If you can get access to this master secret, you have the jackpot. And accessing or extracting this Master Secret can be separated of course in two phases of stages. In the beginning we have some kind of extraction process. This can be done in severals ways by backup, man in the middle attacks. Um we will explain it in the next slides in more detail and the second phase then would be. In some cases the the master password or the keys are additionally protected, so we have also um to to break this protection. We will um explain this protection then in the second stage. So, okay, let’s begin with the man-in-the-middle attack. There was one password manager which has a user authentication and synchronization at the back-end. The synchronization was implemented by a HTTP request, but I think everybody is aware HTTP is not secure against man-in-the-middle, so the developer decided okay, we have to protect our information, let’s implement some custom encryption or protect them by encryption protocol. And of course we can er attack this custom encryption protocol and yeah, it’s broken by this sign. How the um protocol looks in em let’s say in abstract detail we’ll show here in the next slide. In reality it’s much more complicated and a lot of maths, attaching and bit shifting, but it can be reduced very easy. So, we have in the beginning our POST-request, in the header we have some timestamps and the body is transferring our encrypted payload. The encrypted payload is encrypted with AES, so AES is secure, that’s no problem, but you know symmetric cipher in communication? So what about the key? There we have different options. Everybody already knows the key, we have some key exchange or we derive the key from a common secret. In this case you’ll remember in the header there’s a timestamp. The client uses this timestamp as a seed. From the seed he generates the random key and this random key is used as a AES. The server also has the timestamp, used it as a seed, so he deterministically can calculate the key. So I think you can imagine what an attacker can do and what the fail is, so for whom who doesn’t see the problem, here is again our man-in-the-middle settings and when the our man-in-the-middle attacker also can get the time from the header, he just can also generate the seed, the random key and eavesdrop the whole traffic. Why they have done this I don’t know, this is your seed broken by the time, so how to do it in the right way. If you want to do encryption or secure communication in Android, use simply SSL or TLS. You can do this in one line. This this broken implementation had a lot of classes, methods, whatever, just look at the developer instruction you see. Make an https request and everything is secure. If you want to improve or let’s say, have stronger TLS, like, pinning, also use the API. The new Android API supports it. If if you have, or implement for older versions, use some reliable libraries, also, but in the case of er libraries, cross-check it because older versions can contain bugs. So another attack how to get access to the master secret without Root would be using the browser file access.
So at first a short introduction. So if you look at the password manager, they they s um they offer different kinds of convenience functions. One function should be to automatically complete your forms. If the user goes onto a website, say Twitter or Facebook, the password manager recognizes Oh, there’s some stored credentials, I will automatically fill it in and you just have to click to log in. But this is not working in reality because there there come a browser like Firefox or Dolphin that don’t provide an API for this. So what the password manager developers do: Yeah of course it’s very easy in Android to implement our own browser. So you can use the view app view it’s based on the WebKit or on the new Chrome engine to easily implement a browser. The advantages are that the password manager apps now have full control over its own browser and they can um realize their automatic injection function. So the disadvantages: the er browser is part of the password manager, so it’s part of the process, so it’s running in the same let’s say sandbox. And now, what can be happen if, you for instance enter a file URL. So an XML file where the password manager can store the the master password. So, you get it. [laughter and applause] In the in this case you see okay, there’s an additional protection. The stored master password is basically 4 encrypted encoded and it’s also additionally encrypted. In a few minutes I will also show how we break this, but at first another way to get the master secret. This is a so-called residue attack. For whom is not aware about this kind of attack, I’ll give at first a short introduction about the AccountManager. So the Android AccountManager is provided by the ope operating system. It’s some kind of central service where application can store um information like security tokens or temporarily access tokens. It’s based on a SQLITE database and um this SQLITE database is only accessible with system privileges. This means other applications cannot directly access this account manager database. If they want to access it they have to use the API, and the API should ensure that there’s no application accessing data of another application. So that there’s a strict data isolation. So also if you look at the developer, um Android has um fewer Google wrote a few interesting information. It says that you should not pass passwords or sensitive information in this account. Just use it for for temporary tokens or data that will get invalidated. So also interesting that er um second state, if you use the credentials for protecting something valuable, if you look in the context of password managers, your master password protecting all your credentials I think this should be valuable data. Um so next I will show you a short demo of how to protect this AccountManager without Root privileges and then I will explain the attack the attack in a few slides in more details. So we have prepared a a sorry. We have prepared a demo video. This is our device. On this device um I have installed one of our password manager that we will use against this attack. At first I start this password manager and here you see I enter the master password. This is a very complex password um and I will unlock it. And you will see that I have stored some credentials for my Twitter account. But because of the complex password I cannot keep it in mind, I use a convenient function and enable the pin locking. So I set a pin, a very secure pin. So, I just have to keep this pin in mind. Now there’s an information of last password saved for quick pin unlocking, so the password will be stored, but it’s stored in a protected way. So everything is ok, and I speed up the video a bit, so I quit the application, I restart it. And you see now I have my pin for unlocking it. So everything is fine. Now, on the other side on the left I will, I will there will be a small window in a few seconds. This is from a rooted device that just shows again the database entry from this AccountManager database. So you see now in this database is something stored, our email address, some some information, coded and encrypted information. And now the target will be to get access to this information via an app. Um and we will show you now how this tool work. So we install now our attacker app. And again, this device is completely unrooted. So for demo I put on the app a few buttons. If you want to use an attacker app you have to hide all this stuff. So at first you register an account. There you will see an exception. What this exception means is that you will explain in the slides. Then I will uninstall the target app, so I remove completely the application. So it’s go it will be uninstalled from the operating system and it’s gone. Now if I click on extract the password, I will get all the stored account information. And then the next step I will also when I click on decrypt you will see our master password again. So [applause] this is all working without Root and how is this attack working in detail? Ok here you see our smartphone again, you see the AccountManager, API and the um account database. So at first we install our target app and this target app defines for the AccountManager API so-called account type. Imagine this is a kind of database primary key. It’s a identifier for the um database row entry. We have our email address and in this case our secret password. So the application will be installed, the AccountManager API enters everything in the account database. There is also an association between the app and database and the UID so that the API can identify the corresponding application to the matching database entry. Now we install our attacker app. So the attacker app can also be defined as an account type. This is completely free, everybody can define it. We will install it and the AccountManager will now check OK there’s another app with this account type, but the UID is not matching, so we cannot enter or access this information. So we throw in an exception as a warning and so the attacker app will catch this. Now in the next step you saw we uninstalled our target app, so the application will be removed but the problem is now the operating system sees: Oh okay there is another application which is still reducing the account type. The operating system is not comparing anymore the new ID so it thinks okay, the account type is not matching to the data, so let’s keep the data. And after that the application can directly access this data without any problem. And the last thing you saw was the encryption. The encryption was very easy, um dash line has an application with a native library which has all the encryption and decryption process implemented statically. Let’s put this library into my application and we will be able to decrypt this. So, a hint: if you ever lost or forgot your master password, just take the library and you can decrypt it by yourself. [applause and laughter] So, this brings me to the last um um um step of our extraction process, let’s say um the decryption process they’re a bit of a crypto and crypto fails. So at first let’s begin with what is good crypto? There was a guy and he was called Kerckhoff. He were I think around 133 years ago he already defined how good crypto must be implemented. And he just says good crypto should not rely on the on the secrecy of the algorithm, it just should depend on your or on one secret. So here is a brief overview how correct crypto should work. We have the the master secret, and in most cases we have a password. This password should be cemented with some salt, depending the the salt lays the different standards, like the nest, who describes how long the salt should be. In this combination there should be done a key stretching or key derivation function. And the output of this function is this builds our encryption key. In combination with a reliable algorithm, like AES, we can do our encryption and decryption. So this is, let’s say, a scheme how correct or good crypto should be done. So what we find or found bad crypto. So again we have our master password. Everybody knows this of this password manager application, you have to enter it at the beginning. And the first step if the password is too short, they start to enlarge it by just adding zeros. There’s no key stretching, nothing. The second thing is um okay um keeping this password in mind is very complex, you saw it. So we have to store it. But um storing the master password in plain text is not a good idea. Despite of this we saw it also in all your applications and we don’t explain it in detail, because explaining a plain word password is done. So um to protect it they used static keys and if they want to encrypt now something they grab the store to let’s say master key and use AES to encrypt everything. So this means now that if our attacker get access to this stored password, it just somehow needs to get access to the static key. How do we get access to the static key? We found a few examples. The first one is just part of the app code. You just take it out of the app and you can decrypt the master password. And with this master password you can access your stored credentials. The second one was more complex, it was more sophisticated and split up in two parts. So they put it together dynamically [background laughter] um, yah, um another form we found that was very weird, this was a kind of obfuscation. So I don’t know where the developer thought about it, but he was um setting up a um random encryption key. The random encryption key had always the size of 9 and he implemented a own random function, so he had an array with 55 different characters and used the random function and grabbed 9 difference. So, let’s say the first fail, there’s no secure in them. So he uses this random key to protect his master password. So okay we have no static key, there is nothing in the code, but there is now the problem um yeah, that we have to somehow store this um key. So he implemented an obfuscation. And this obfuscated key is then stored on the device, so if our attacker gets now access to the encrypted key and to the obfuscated key and can the obfuscated um, he gets again the master password. So now to look a bit into detail of this um obfuscation. So as I’ve said, in the beginning we had our obfuscation key, we had always the fixed sides of the lengths, at 12. And of course, for deobfuscation, there’s some black box, algorithm. To be honest, we were too lazy to reverse and degenerate completely, because then we’d had to do a lot of shape-shifting and swapping and so on, so we just tried to break it dynamically by trial and error. If you could break this we would get the random key. And of course then with AES we could decrypt the master password. So we played a bit around with just a keys. And if you take a look at the table, um we modified several parts of this um random key and you see if you modify, for instance, the first and the second part of the key, the first to three parts of the obfuscated key is modified. If you change the third um part the fourth obfuscated part is changed, and so on. We also saw that these parts are independent, so if we, let’s say, change in the first part of something, there are no changes at the end. And so this this brings us to to the easy parts, cause if we have something of the lengths, three to break, it we very easily can can bruteforce this. So we just simply check the Reverse Lookup table by bruteforcing all random parts and obfuscated part combinations. And with the bruteforce with the Reverse Lookup table as you can see here we can simply calculate the random key and with this random key we again can um decrypt the master password. So what I want to show with this slide, I don’t want to blame this algorithm in detail because there are also a lot of other algorithms. What I want to say is just that if you do encryption, you do it rightly obfuscation is just security by obs obscurity. There is always someone who will break it, so don’t use such nonsense if you implement security applications. Now also some recommendations of how to do it right. So Android provides a secure store for credentials. Use the KeyStore and um of course, I know sometimes developers say that Android 2 or Android 3 does not support the KeyStore, but Android 2 or Android 3 is not secure by design, so don’t target this user, don’t support them. Use Key derivation function, there’s PBKDF2 (API), it’s a bit slow but there’s already a cool Open Source um a library from Facebook called Conceal, it has a bit fast or a more faster and secure key derivation function. Don’t use any static keys, um hard coded, splitted up, hidden in some images or something. It is just security upon security. If you use AES depending, use the secure um cipher modes. Also some point where I didn’t talk in detail about but were told the Android user developer aware are aware of it. Password managers don’t need a backup flag because they have the backend synchronization, their data are implicitly backed up. So this backup flag just opens a new attack target to get access to your confidential data. If you have a master password or you provide a master password for it’s storage function, don’t store it in plaintext. So we saw this also the same. Don’t store it in the local app folder. There’s always a way to get access to it. Use the KeyStore. Here is now a short overview of um all our um findings. At the top you saw, um you see again all the password managers. On the left row you saw the different kinds of vulnerabilities we found. The first row we showed is somehow to to get access to the master password or to the pin, hardcoded keys. The sandbox bypassing was just a browser attack. We did not talk um about on this talk about the side channel attacks. We presented that hack in a box, but the idea was a lot of password manager abuse, the channel for transferring credentials to other applications. We had also seen this sub domain problems, this was also very funny. Um the idea was um that if you store your credentials to um on four different sub domains, the browser did not distinguish between them. So this means that if you had a um domain like my secrets.example.com and you store your credentials em er and your password manager didn’t distinguish between security and for instance attacker for example.com. Um data leakage was a problem of the implemented browser, partial encryption. We also saw one password manager who did not completely encrypt all your stored information and the broken synchronization we showed also in the appli in the beginning of the talk. So let me give you a short summary. Siegfried also introduced um desk we will need, we need password managers because of the complexity of all the passwords. And um if they, you have to store them somehow. And um we also gave um different types how we attack them all without ROOT. If you get ROOT access it must be a this would be a much more worse scenario. And we also gave a few recommendation how to do it right and a summary of all our findings. The last thin I want to mention is all the findings we had you will find also on our website. We will also announce the in a responsible disclosure process to the vendors. All our findings are fixed but there are no guarantees that there are not any other additional vulnerabilities. So this is for all Android security, er reverse engineers, hackers and so on. Keep your eyes open if you find anything.
>> What I want to mention is that this is not a complete presentation what we did. For sure there is more.
>> Yah but um look into it a announce it to the vendors, because a lot of people store their sensitive information there, so let’s say, protect them. Um so this would be the the end of the presentation. Siegfried already mentioned that we brought some beer. We can er, if you have some questions come to us, we can drinks and talk about it in the hall. If you are just thirsty you can also grab a beer. Or if you are too shy to talk to us um, you can also write us an email. Um so thank you for your um attention. This is the end. [applause]