Tip:
Highlight text to annotate it
X
>> CRAIG YOUNG: Hi, I'm Craig Young. I'm a researcher with Tripwire VERT, I'm presented
today, Android WebLogin, Google skeleton key. I'm a researcher with Tripwire's vulnerabilities
and research team. I look for bugs, fix bugs and write checks for a lot of them. Like a
lot of you, I like to break things and make things. One thing I'm definitely not is an
Android developer. 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 deduce friction, they have introduced
these things called WebLogin tokens. They allow you to bypass password prompts so you
don't have to enter your password upon your mobile phone or tablet or wherever else.
I found that security tools 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 WebLogin? As I said it's an Android token type. You see on the screen, this is
an example scheme for what a WebLogin token request would look like. What you get back
from this is a URL. You browse through 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 in 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 will have permission or whoever gets the token to access your GML on your drive,
lots of other things we will get into later. The permission prompt is only given once per
app per token type so the application can generate as many of these tokens as you want
if you approve them. There are some ways you can get the tokens without getting permission
which we will 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 WebLogin 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 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 will see how well my live demo goes.
You can do things like adding privileges, managing mailing lists and all sorts of good
things. 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
you can reset the user's password by having a WebLogin token. That didn't work with two‑step
verification because of the insistence on verifying a code that's sent to a phone. You
could also do Google data dumps. So Google takeout would allow you to download all 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 have called it, these have actually been addressed successfully.
I will get into that a little bit later. So some of the other things that I have been
finding that you can do, once you have the WebLogin token, you can go ahead and install
apps from the Google play store on to the device you have already compromised but also
other devices that are associated with that Google account.
You can also access other websites which might use Google federated log in 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 WebLogin
token. The approach I looked at or focused my research on is a more legitimate, using
malware that is 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 have also got
some other options if you can deploy a root exploit successfully, you have access to the
account's DB, session identifiers are in there and everything you need to get uber auth and
WebLogin token. The Chrome browser has a nice little insecure
feature, called auto sign it. What that does is generates a WebLogin token for you and
lets you get into any Google service for that device. And finally, if you have ‑‑ if
you are, 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 of being able
to get the accounts database, and then you are free to masquerade as the suspect, use
their ‑‑ view their emails, communicate as them, use Google talk as them, and 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 would do this without having root
access to the device. I have an app that is ‑‑ 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 advisories and
antivirus. Making the app was not difficult at all. I'm
not an Android programmer, reading some blog posts, it was more than enough. You can see
here, there's the token type and then I'm using the get auth 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 WebLogin 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 called ‑‑
I called Tubeapp which was intended to advertise itself as a YouTube downloader app. The Google
Apps administrator would use this application and it would go from your phone or tablet
and it would fetch your OAuth secret for the domain. It didn't do any egressing with this.
I had it appear on the screen. I didn't post it to Play or anything, but then my next step
was to make the stock view application. With this, I did post it on to Google play. I gave
it a vague description, saying it's a testing application that shouldn't be installed and
priced it 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 WebLogin token. If it's granted, it's going to request two
tokens. One will be used to launch the browser and show you your stock view feed and the
other one is silently posted to my web server. The next release I did of this, I added SSL
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 up more blatant that this app is doing
bad things and in response to some things that I saw with Bouncer or lack some of things
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 WebLogin token. If accepted that would
get addressed over as a cell. So here's what you see when you are installing
the application. It's requiring the find accounts open the device to enumerate accounts and
use beings on the device so you can use the get auth token 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 are running in some type 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 recognized as potentially malicious.
In any opinion, it should strike some red flags that my application is just requesting
a token and immediately sending it up to a server but it didn't raise any red flags with
Google. This is what it looked like in play store
this application provides quick access to your Google stock portfolio, while completely
compromising your privacy. (Laughter)
(Applause) 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. When I went back to start doing research for writing these slides now, I found that
Google Apps ‑‑ on Android's verify service or option on the device now would say installing
this app may harm your device this can be used to hack or spy on you and Google is recommending
you do not install it. The only caveat is 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 black list. 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 would recognize the used credentials is potentially
a privacy risk. Look out premium didn't seem to have a category for saying which applications
have the permission to request tokens on your behalf.
So demo time. We will see how this goes. First of all, this is a Chrome web browser that
is incognito, it has no access to anything. I will browse to gmail and I will log in.
I will unlock my tablet. Hopefully it will connect to the DEF CON secure network.
Oh, there we go. So switching over. This is just going to be telling 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 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 will go ahead and load that and now
you can see we are authenticated at stupid admin.
(Applause) 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 helpfully telling you that Google wants to make sure
that you are really asking for this data download. And along those same lines, if we go back
one more. You used to be able to add a recovery email address without 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 have now browsed to Google.com/a/domain
name. We can browse the users in the domain. We can go ahead and do things like resetting
a password. >> You have more time. The next speaker is
not here. Ramble on! >> CRAIG YOUNG: Perfect! So I guess I will
spend more time with the demo. I could show that password or specify a password that I'm
setting. I will just 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 at this time. Please try again later.
We will try it one more time. Sometimes it works. But what we can still do ‑‑ this
has actually worked when I was in the speaker room, 10 minutes ago or 20 minutes ago. What
we can still do is say, take this user and add to it, admin permissions, user admin.
It lets us do that. We can then reset the password. I will use an autogenerated password.
And now if we go and sign out from the WebLogin token session, we can sign back in here, hopefully
remember the user name that that was. Okay. So now we have admin consult that's
done through a password being manually entered. So in this context, you no longer have the
stipulations that you are 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 have 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 ‑‑ oops. 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 two that we did. This has initiated transfer ‑‑ or initiated document
ownership transfers. 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 WebLogin tokens. Let me sign off here.
Let me see if we have 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 let's pick a random app. Use accounts on this
device. That's good. Let's install that. And so now it's going and momentarily, actually,
already it's starting to download the new app. We can also abuse other sites that are
relying on the Google federated log in. For example, I picked a random example, get
satisfaction.com. If I click Google, log in with Google, it's now logged in, showing Craig
Young. If there's anything useful on here, somebody
could do something with that, but ‑‑ 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. Could
you 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 ‑‑
(Laughter). ‑‑ 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. Everybody since using Android with my Google Apps domain,
I was an admin. Not anymore. I have other users that don't associate with any Android
devices and my phone has add least some limited risk.
You also want to be very skeptical if you are getting requests from an application to
use a WebLogin token or the LSID, or the LSD session identifiers and I talked about that
in another talk, how you can use those. 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 though 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 did not detect this threat,
I do have faith that since it's signature based, it will most likely be able to pick
up things like root exploits that are known about. So that's a little bit more protection
there. If you have been pwned through this you want
to do some stepped to recover. First of all, you want to invalidate all of 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 being, just your individual account. You want to
go through gmail and make sure no one has added mail forwarders or figure out recovery
email addresses. It seems like Google has more or less protected against that. You want
to look for new domain admins, that's something you don't want. And I found that Google Apps,
the audit trail 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 is not being abused from your device, from your IP device, you will potentially
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 B‑sides
San Francisco, and there's a blog post. If you have any questions, you can find me,
get me a beer and we can talk shop or I will maybe be out in the hall for a few minutes.
Thank you. (Applause)