Hi.
I'm Craig Young.
I'm a researcher with Tripwire VRT and I'm presenting today Android Web Login, 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 vuln 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 have introduced these
things called Web Login tokens.
These Web Login tokens.
Web Login 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 Web Login?
As I said, it's an Android token type.
You see on the screen here.
This is an example scheme for what a Web Login 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.
There'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 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 takeout 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.
We'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
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 access to the accounts DB, session identifiers are in there, everything
you need to get UberAuth and WebAuth.
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 ‑‑ if you're 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
e‑mails, 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 I ‑‑ or two apps that are on the DefCon CD 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 away.
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 log in with the service specified as finance and a continuation URL of finance.google.com.
This is your stock portfolio stuff which is 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 tube app 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 on to Google Play.
I gave it a very vague description saying that it's a testing application that shouldn't
be installed, 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 web log in 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 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 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 log in token. If accepted, that would
get egressed over SSL.
So here is 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 auth
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
. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 sure.
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 is 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 black list.
So look at this.
I'm 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.
It'll browse to Gmail.
It'll ask me to log in.
I'm going to unlock my tablet.
Hopefully it will connect to the DEF CON secure network.
Oh, there we go.
So switching over.
. . .
Beep.
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
e‑mail. You can go through Drive. The contacts are accessible. But some things that you can
use 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're 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
e‑mail address without having a password, which you could then use to reset the ‑‑
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.
Do you have more time to speak to that?
Perfect.
Ramble on.
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 at this time. Please try again later. We'll try it one more
time. Sometimes it works.
Okay.
But what we can still do, this is actually worked while I was in the speaker room ten
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 just 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 added
an 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.
Okay.
Okay.
Okay.
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 two 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 e‑mail 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 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.
Okay.
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.
Okay.
Okay.
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 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, or
using, 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 though I was able to get malware
in there pretty easily, it's better than some random Chinese app store. And although I've
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 of the sign-in cookies. That's accessible through the Google
Apps control panel as well as in the Gmail account settings, I believe. So 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 e‑mail 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 is 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 B-Side San
Francisco. And there's a Duo security blog post. If anybody has any questions, you can
find me, get me a beer, and we can talk shop or I'll maybe be out in the hall for a few
minutes. Thank you.