 Hi, I'm Craig Young. I'm a researcher with Tripwire Avert and I'm presenting today Android Weblogging, Google Skeleton Key. So a little bit about myself. As I said, I'm a researcher with Tripwire's vulnerability and exposures research team, which means that I look for bugs, fix bugs, write bone checks for them. So like a lot of you, I like to break things. I also like to make things. One thing that I am definitely not is an Android developer. So please, if you look at the source code on the DEF CON CD, go easy on me. So the goal of this talk is raising awareness. I want to raise awareness about the fact that the Android ecosystem has made some compromises of people's security and their privacy in order to give a good user experience. So in order to reduce friction from using Google services, they've introduced these things called Weblogging tokens. These Weblogging tokens allow you to bypass password prompts so that you don't have to be entering your password on your mobile phone or your tablet or wherever else. I found that security tools that are out there for endpoint protection, they don't recognize this type of threat. They don't do anything to protect against it. And in the end, it only takes one token to fully compromise a Google apps domain, one token from the right user. So what is Weblogging? As I said, it's an Android token type. You see on the screen here, this is an example scheme for what a Weblogging token request would look like. What you get back from this is a URL. You browse to that URL and you get cookies that authenticate you to Google services, basically all of them. So this is a way of getting access without having a password. So there's some ways that I found that you could abuse this technology. For one thing, as you saw on the previous slide, it was the token type is requesting a specific service, but when you get the cookies back, these cookies are not limited to any services. It's just as if you had logged in from the web browser pretty much. So although you might be asked for permission to access your YouTube account, the app is also going to have permission or whoever gets the token to access your Gmail and your drive. Lots of other things we'll get into later. The permission prompt is only given once per app, per token type. So an application can generate as many of these tokens as they want if you've approved them. It's also some ways that you could get these tokens without asking permission, which we'll get into. And that's involving having root or physical access on the device. So the focus of this is about how to attack Google apps. So as I said, the first step is you need to retrieve a web login token for a domain admin. From there, you can continue on to the Google apps control panel and basically you have access to do whatever you might want to do. Some of the things that you can do, listed out here, you can disable two step verification, you can reset passwords for any users in the domain. You can add super users, although Google did attempt to fix this. We'll see how well my live demo goes. You can do things like adding privileges, removing privileges, deleting users, managing mailing lists, all sorts of good things. So also regular Google accounts are subject to some vulnerabilities from this as well or some exposure, I should say. If you are just a regular Gmail user and your phone is compromised such that somebody has your web login token, they then have full access to your Google drive, your calendar, your Gmail and voice, whatever other services you might have enabled. Initially when I started looking at this, you could also reset the user's password just by having this web login token. Of course, that did not work with two step verification because of the insistence on verifying a code that's sent to the phone. You could also do Google data dump. So Google take out would allow you to download all of the contacts from the target account. You could also download the drive documents, various other things. These, the ability to reset the passwords and the ability to get the Google data dump as I've called it, these have actually been addressed successfully. I'll get into that a little bit later. So some of the other things that I've been finding that you can do, once you have the web login token, you can go ahead and install apps from the Google Play Store onto the device you've already compromised but also other devices that are associated with that Google account. You can also access other websites which might use Google federated login and Google sites, you can make a website on behalf of the victim. These are all things that are applicable for Google apps and regular Google users. So how do you go about getting a web login token? The approach that I looked at or focused my research on is a more legitimate way using malware that's going to make a request using the account manager API to get one of these tokens and then egress it off to a server or use it on the device. You've also got some other options. If you can deploy a root exploit successfully, you've got to access the accounts DB, session identifiers are in there, everything you need to get uber auth and web login tokens. Also, of course, if you have physical access to the device, even if it's just momentary, the Chrome browser has this nice little insecure feature called auto sign it. What that does is generates a web login token for you and lets you get into basically any Google service from that device. And finally, if you have, if you're for example in law enforcement or something along those lines, you have access to a suspect's device that's been perhaps partially damaged, not really usable. But you can do chip off forensics, extract memory, and you get back to number two here of being able to get the accounts database. And then you're free to masquerade as the other suspect. Use their, view their emails, communicate as them, use Google talk as them, look through Google voice phone records. So the proof of concepts that I went through, my main goal was to be able to make a token stealing app that was going to do this without having to have root access to the device. I have an app that, or two apps that are on the DEF CON CD that you can take a look at along with source code. My secondary objective was to be able to publish this in Google play and see whether or not Bouncer would notice something suspicious about this. And then also, of course, I wanted to take a look at where the endpoint protection tools might fall or weigh in on this type of application. So privacy advisors and antivirus, that means. So making the app was not difficult at all. I'm not an Android developer but just reading some API documentation and some helpful blog posts was more than enough to get going and do this within a couple hours. You can see here there's the token type and then I'm using the get off token method from account manager, which generates a message like what you see on the bottom of the screen, which you can see it's requesting access or permission to web login with the service specified as finance and a continuation URL of finance.google.com. This is your stock portfolio stuff, which not particularly sensitive information for most people. So the revisions that I went through to get here, I started out with something I called TubeApp, which was intended to advertise itself as a YouTube downloader app, but then in actuality it was relying on that a Google Apps administrator would be using this application. It would go into the Google Apps control panel from your phone or your tablet, and it would fetch your OAuth secret for the domain. It did not do any kind of egressing with this. I just had it displayed on the screen, didn't post this to play or anything, but then my next step was to make the stock viewer application. So with this, I did post it onto Google Play. I gave it a very vague description saying that it's a testing application that shouldn't be installed, priced at $150 to avoid inadvertent or curious downloaders. And for this first revision of stock view, I made it so that all it would do is ask you for permission to access your web login token. If it's granted, it's going to request two tokens. One of them is going to be used to launch the browser and show you your stock view feed, and the other one is silently posted to my web server. So the next release that I did of this, I added S cell support because really I didn't like having my tokens go over in plain text, but I also updated the description in Google Play to make it much more blatant that this app is doing bad things. And in response to some things that I saw with Bouncer or lack of some things that I saw with Bouncer, I also added some code so that no matter what, when you run the application, it's going to enumerate your accounts list through the account manager API. This requires no permission request except for in the application manifest, and that would get immediately uploaded. Then you would be prompted for permission for the web login token. If accepted, that would get egressed over S cell. So here's what you see when you're installing the application. It's requiring the find accounts on the device to enumerate accounts and use accounts on the device so that you can use the get off token method from account manager. And of course, full network access for being able to egress off the device. And once again, you see the permission prompt that you get the first time you run it. If you allow access, you will never see that message again. So I published it in Google Play. They did not flag anything on submission. I didn't receive anything in my server logs indicating that Google Bouncer had actually executed the application in such a way that it would make my request. It brings up some questions. Namely, whether Google Bouncer is really running all of the apps that are being submitted or if they're running in some kind of limited environment that does not actually have support for Google accounts such that these account manager requests would just be skipped over and not recognize this potentially malicious. In my opinion, it should strike some red flags that my application is just requesting a token and immediately sending it up to a web server, but did not raise any flags with Google. This is what it looked like in the Play Store. I don't know how well you're able to read this, so I'm going to read it for you. This application provides quick access to your Google stock portfolio while completely compromising your privacy. If you prefer convenience over security, then this app is for you. This application is currently under testing and should not be installed by anyone ever. And of course, this was up, but a month later, probably somebody noticed this was a little bit suspicious looking and reported it. And my Google wallet account got suspended. I think it was up for about a month. I wasn't really paying much attention to it, but when I went back to start doing research for writing these slides now, I found that Google Apps or Android's Verify service or option on the device now would say, installing this app may harm your device. This app can be used to track or spy on you and that Google's recommending you do not install it. The only caveat about this is that if I rebuild my app and give it a slightly different name, this warning never comes up again because I guess it's just a blacklist. So looking at Endpoint Protection, I scanned five of the popular tools that I was familiar with. None of them found any risks. Looking at the privacy advisors, I found that Avast actually would recognize that the used credentials is potentially a privacy risk. Lookout Premium didn't seem to have a category for saying which applications have the permission to request tokens on your behalf. So demo time. And we'll see how this goes. First of all, this is a Chrome web browser that is in incognito mode, no cookies, no access to anything. I'll browse to Gmail. It'll ask me to log in. I'm going to unlock my tablet. Hopefully it will connect to the DefCon secure network. Oh, there we go. So switching over. This is just going to be tailing the logs from my web server. And as you see here, the tablet is slowly loading the Google finance page. Maybe some of you can see that. But more importantly, what we have here, this first request shows the accounts that were connected or configured on the tablet. And then the second one in this URL parameter, this is the URL that was returned as the token. This does have an expiration on it. If you don't use it quickly enough, it will not work. But I'll go ahead and load that. And now you can see we are authenticated as StupidAdmin at MindSculptors.net. You can then see that you can access their email. You can go through Drive. The contacts are accessible. But some things that used to be very interesting to me here, if you go into account, you have your download, your data. If you tried to do this two weeks ago, it would just let you download all the data. Now you have a security notice that's hopefully telling you that Google wants to make sure that you're really asking for this data download. And along those same lines, if I go back one more, you used to be able to add a recovery email address without having a password, which you could then use to reset the password on the account. This is now blocked off, but fortunately or unfortunately, depending on how you look at it, the Google Apps Control Panel is still completely accessible. So I've now browsed to Google.com slash A slash domain name. We can view the users in the domain. We can go ahead and do things like resetting a password. So I guess we'll spend a little more time with the demo here. So now I've just done an auto-generate password and you can see that I can show that password. I could also specify a password that I'm setting. I'm just going to go ahead and reset that password again without showing it this time. We could also do something like adding a new user, which is over here. So this is something that Google has actually tried to fix. The other day I recorded a demo because I noticed that they blocked off access to this vector. So we'll see if it works now. I've had mixed success since then. So yeah, you see we are unable to process your request this time. Please try again later. We'll try it one more time. Sometimes it works. But what we can still do, this is actually worked while I was in the speaker room 10 minutes ago, 20 minutes ago. But what we can still do is say take this user and add to it admin permissions. Super admin. Let's us do that. We can then reset the password for this user. I'm just going to use an auto-generated password. And now if we go and sign out from the web login token session, we can then just sign back in here. Hopefully remember the username that that was. Okay, so now we have admin console that is actually done through a password being manually entered. So in this context, you no longer have the stipulations that you're going to get that error that we had before when trying to create an account. So I can now add a user to the account. Hopefully this will still work and it does. So now we've added a new admin user to this domain. Some of the other things that I had mentioned that you can do, actually I haven't mentioned this yet, but let's say we want to transfer documents from a Google account to another Google account. The ability to say transfer from this user to the new admin 2 that we did. This has initiated transfer or initiated document ownership transfer. So now that new account that we just created has access to all of the data that was in the Google drive for that other user. There are some email notifications going out about that, but looking at some other interesting things that we can do, I'm actually going to get back in the context of the web login token. So let me sign out here. Let me see if we got a new token now. So that looks like the old token. Oh, there we go. So now the new token, as you can see here, if we copy this back into that, we're back here and we can go to play.google.com and pick a random app, use accounts on this device. That's good. Let's install that. And so now it's going in momentarily, actually already it's starting to download the new app. We can also use other sites that are relying on the Google federated login. So for example, I picked a random example, getsatisfaction.com. If I click Google, login with Google, it's now logged in showing Craig Young. If there was anything useful on here, somebody could do something with that. And since we have a few extra minutes, I'm thinking if there's anything else I want to show in here. Calendar is accessible. You can create appointments. Oh, here's an interesting one. You can go to history.google.com and see it says only you can see your history, but it's a little less than accurate. So I think let's jump back over to the slides. So how do you avoid being a victim? First of all, I used to do this ever since using Android with my Google Apps domain. I always was an admin user on the device. Not anymore. I've created other users that do not associate with any Android devices and my phone has at least some limited risk. You also want to be very skeptical if you're getting requests from an application to use a web login token or the LSID or SID session identifiers, which I've talked about in another talk, how you can use those to get other tokens. You want to stick with trusted app stores and vendors. I know that's a loaded thing, but I think still sticking with Play, for example, even that I was able to get malware in there pretty easily, it's better than some random Chinese app store. And although I found that antivirus didn't detect this threat, I do have faith that since it is signature based, it's most likely going to be able to pick up things like root exploits that are known about. So that's a little bit more protection there. If you've been pwned through this, you want to do some steps to recover. First of all, you want to invalidate all the sign-in cookies that's accessible through the Google Apps control panel, as well as in the Gmail account settings, I believe. You want to reset passwords for basically everything on your domain, or if it's just your individual account, just your individual account. You want to go through Gmail and make sure that nobody's added mail-forwarders or figured out how to add recovery email addresses, even though it seems now that Google has more or less protected against that. Of course, you want to look for new domain admins, that's something you don't want. And I found that Google Apps, the audit trail that it leaves, is very effective. It tells you which actions were unauthorized or it could let you know which actions were unauthorized, because it's recording everything that's done at a pretty granular level. And it is reporting IP addresses, so as long as the token's not being abused from your device, from your IP address, you are potentially going to get some information on how to track down who attacked you. So in the process of doing this, there's some links up here in the slides that you can check out. The first one is a blog post that explains all about account manager. They were looking at it for other purposes, but you can also check out, I did a talk at Beside San Francisco, and there's a duo security blog post. If anybody has any questions, you can find me, get me a beer and can talk shop, or I'll maybe be out in the hall for a few minutes. Thank you.