

Google Apps Security Vulnerability Puts Organizations’ Data at Risk - ddent
https://www.danieldent.com/blog/google-apps-security-vulnerability/

======
kevinoconnor7
I respectfully disagree with the Daniel's blog post. Changing a password
should not inherently reset all application-specific passwords, and though he
doesn't mention it, it shouldn't revoke all OAuth associations either.

Perhaps I look at it in a different view point. Application-specific
passwords, username/password combo, and OAuth are all separate authentication
methods. The compromise of one shouldn't necessarily compromise the others
(though additions/modifications subsequent to a compromise should be suspect).
When the protocol for disabling a user is that you use the reset password
functionality, that's using the wrong tool for the job. This is especially
true when a disable user button is quite prominent on the Google Apps admin
dashboard.

I worked in a K-12 school district for a while and password resets were a
fairly frequent event. We also had many other web services that used Google
OAuth. I'm not sure I would be keen on having to reset all of their accounts
every time they forgot their password. At least 95% of password resets I did
were because of forgotten passwords (remember, Google Apps doesn't have a
forgot password system) and not due to a compromise or suspected compromise.

Finally, I'm not really sure what the point of changing a user's password to
disable an account is. The argument could be made that you might want access
to some of their data, but there's other tools in Google Apps admin dashboard
for that. Want an e-mail audit? That's there (well, it was an API when I last
used the dashboard extensively). There's also tools to migrate all their
Google Drive data to another user. If you have the higher end Google Apps
account, then you'll have Google Apps Vault which will give admins access to
almost all of the user's data even once the account is suspended.

------
PeterWhittaker
Headline is stated linkbaitly, poorly.

tl;dr: Admin reset password to disable user access, was irked that app-
specific passwords were not revoked. Did not read docs how to revoke app-
specific passwords.

Should there be a simpler interface for admins? (Revoke all access YES/NO?)
Arguably, yes. Is this a vulnerability? Arguably.

My complaint with the headline is that it implies that Google App
organizations are at risk RIGHT NOW and that these organizations should be up
in arms RIGHT NOW.

Instead, there is a mild to moderate risk of continued access to very specific
data - which will vary by organization - by terminated employees whose access
should be revoked. In the case of email, e.g., they may - and likely do? -
already have all their old email on their computer, so the risk increase is
mild for this case. Other apps will vary.

Better headline: _Google Apps user deprovisioning controls inordinately
complex, may lead to post-termination security exposure_

------
mifreewil
If you're changing a user's password to revoke access with Google Apps, you're
doing it wrong.

Google Apps gives you two options to revoke access: suspending a user and
deleting a user. If you suspend a user, you can later re-enable that user. In
the event of firing an employee, you probably want to go ahead right away and
delete the user - upon doing so you will be prompted to transfer any data to
another user.

Edit: Perhaps, they should add a checkbox to revoke application-specific
passwords in the change password interface.

------
blauwbilgorgel
I don't see a security vulnerability, but bad security practice.

Either they: Delete the account. All is well.

Either they: Take over the account. It is common sense then to change the
phone number associated with the account. All is well.

You could solve this "bug" by reading the documentation and creating a better
security protocol (which is currently putting your organizations' data at
risk).

I clicked the title with just one thought it the back of my mind: "If this is
an active serious vulnerability then why did OP not apply for the
vulnerability program and have it fixed beforehand"?

My experience with the vulnerability team has been great (one honorable
mention and one pay-out). If you did not get an honorable mention then it
means the security team did not file a bug report. Your feedback could
probably still be used to improve the UI.

As an aside: Hunting real security bugs on Google domains is insanely
addictive (because they are so hard to find). Try to generate all their
different error screens. Try to find the Google property running on aspx. To
practice there is also [https://google-gruyere.appspot.com/](https://google-
gruyere.appspot.com/)

------
cheald
I eagerly await the follow-up blog post, wherein Google's "Forgot Password"
feature which allows a user to reset their password via a secondary linked
account is decried as another gaping DEFCON 1 security hole that deserves a
$10,000 reward check.

Come on. If a user shouldn't have an account anymore, _delete the account_.

------
hnews779
I actually had this happen at my company. We had a dispute with a past
employee and they started bringing up issues they shouldn't have known about.
Eventually we figured it out.

~~~
greglama
Holy shit I would have been pretty pissed. That could have gone even worse....

------
tlandia
For Google Docs/Drive, the data transfer is simple. Other apps? Not so much.
And that's not even getting into third-party apps that use google apps
authentication.

