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.