Major Google Security Flaw To Remove Sites From The Index

Posted By on Tuesday, May 29th, 2007 on 5:16 am CET

This is the google removal tool that could devastate many sites and businesses if someone gained access.

You could wipe sites out of Google in an instant!

Well,,, they have left a bit of a hole somewhere.

Tool > http://services.google.com:8882/urlconsole/controller

With a file name chopped open >> http://services.google.com:8882/urlconsole
Whats scary is there is some passwords if you poke around.

This is a large hole inside Google’s service: “the removal of websites tool” .

Apparently it is a simple directory that wasn’t protected, so we can traverse up their directory root and browse folders. A study gave me the impression this hole is unique, legit and not a honey pot. Now it can happen the best of the best that a directory becomes readable. But, one must never, ever, not in a million years, store your database connection info in a folder that can be viewed remotely. Like the www folder.

security hole in google

I found the following information in the folders:

# Database stuff
DBDriver = org.gjt.mm.mysql.Driver
DBUrl = jdbc:mysql://localhost/dbRemoveUrl
DBLogin = root
# put password in before the push
DBPassword = k00k00

Another file shows me this:

update.db: mysql -uroot -pk00k00 < schema.mysql

What strikes me most is that they log in as root user and second the utter simplicity of the used passwords: 6 chars long 4 digits and two letters in the first one. A little ironic regarding Google’s advisory on password strength. Anyway, I fetched a few files before this thing is taken down. Ah well, I didn’t hack anything did I?

The Live URI:

http://services.google.com:8882/urlconsole/controller?cmd=reload&lastcmd=login

Files to browse:

http://services.google.com:8882/urlconsole/

You can download a rar file with a few Google files here:
https://www.syndk8.com/googlehole.rar (since removed)

Snippet of their files:
# Properties file for urlremover application
# Copyright 2000 and onwards, Google, Inc.
# Maintained by sanjeev@google
#
# Note: development settings are maintained in config.txt, remember to
# update that file in conjunction with this one.

# General App settings
# Front door name (needed for embedding urls in emails)
frontDoor=http://services.google.com:8882/urlconsole/controller

# How long we wait before timing out the session
# e.g. so if a user stays on a single page longer
# then this amount of time he will be sent to the login
# page again.
SESSION_timeout_minutes = 5

# Client IP Blacklist file
bannedNetworks = /apps/com/google/urlremover/badip.txt

# Proxy settings
proxySet = true
proxyHost = proxy
proxyPort = 80
userAgent = googlebot-urlconsole

# Database stuff
DBDriver = org.gjt.mm.mysql.Driver
DBUrl = jdbc:mysql://localhost/dbRemoveUrl
DBLogin = root
# put password in before the push
DBPassword = k00k00

# Publisher stuff
# ackQueue and outputQueue must already exist. Use
# google/setup/pcqueue.py create <pathOfQueue> 128
# to create them. Also,
# //depot/ops/production/master/files/etc/cron.hourly/dynamic_gws_data_push>
# must agree with us on where the queues are located.

ackQueue = /apps/publish/publish_ack_queue
ackDir = /apps/publish/publish_ack
outputDir = /apps/publish/current
outputQueue = /apps/publish/publish_queue

BadAll = badurls_autonoreturn
BadSnippet = badurls_autonosnippet
BadCache = badurls_autonocache
BadMsgids = autobadmsgids
Porn = badurls_autoporn
BadImages = badurls_autoimage
ImageTweak = badurls_autoimagetweak
BadOdp = badurls_autonoodp
BadDemoteGws = badurls_autodemotegws
BadSpam = badurls_autospam
BadSupplemental = badurls_autosupplemental

 

Comments below archived for posterity from when i consolidated the site.

inkredibl on 30.05.2007 said:
You can’t connect from outside anyway (I guess). MySQL has specific permissions to localhost, so you’ll have to connect from localhost in order to get the permissions, also the connection from outside is probably even impossible because of a bind to localhost. If I’m right, then the root user and even password are only symbolic security measures, the real security comes from the fact that you can’t gain access to the server itself. Either way, if you’d have the access, you could easily look for a password in the local file system. Not that big a deal I guess…

Earl Grey on 30.05.2007 said:
A server always connect to a localhost, cause that is where the database is: local, just a joke. Normally it is possible to connect remotely to their database, no problem. And it is certainly a big deal, not for me, but if I live in the area of mountain view and had my wrireless latop with me, I would hop their network for sure. Afterall, it’s Google isn’t it? You seem to have good knowledge on their architecture, are you working at Google? ^^
Carl on 30.05.2007 said:
Reading through the information that you have listed, you need two things to achieve access to / control over the MySQL databases:

1 – A local shell account in order to login on localhost to the MySQL server. MySQL can be configured to deny connections from any location, or accept connections from any location (including localhost), so it isn’t always safe to assume that localhost will always be there and configured for you to play with (though you do have a legitimate account and password supplied in the info you managed to extract). Even if you got on the local network segment, there is no guarantee that you will get anywhere near the server. A good admin will tighten access controls so that it is not possible to authenticate except through a certain few accounts and authorised channels (not necessarily localhost).

2 – If you don’t get a local shell account, you need to be able to be able to subvert the schema.mysql file. From what you have reported, it looks like you don’t get the chance to push data to the site, so you need to do more work to gain control over that data.

So, where to look? Think Java and Python. Unless Google is riding their patch cycle very hard, there are bound to be some tasty vulnerabilities in the Java and Python interpreters running the code (both have had interesting holes closed recently).

As the first comment said – interesting, but nothing much more than that. I would rate this – Information disclosure and directory traversal, nothing else.
Earl Grey on 30.05.2007 said:
Granted, it could have been restricted in the firewall, but we never know for sure cause I didn’t try. I also didn’t try to telnet to it, but who knows a simple Java connection could have proved it though:

public static Connection connect(){
try{
String uri =
“jdbc:mysql://services.google.com:3306/dbRemoveUrl”;
conn = DriverManager.getConnection(uri, “root”, “k00k00″);
}
catch(Exception e){
System.err.println(“Exception: ” + e.getMessage()); }
return conn; }
}
collier on 31.05.2007 said:
It now just redirects and tells you to login with your google account

inkredibl on 31.05.2007 said:
Nowadays MySQL’s default settings on Unix machines tend to be either “disable_networking = yes” or “bind_address = 127.0.0.1″, either way you’ll have to be on the same machine to be able to connect to the MySQL server (and this has nothing to do with firewalls). But as I said in my previous post – being on the same machine means You’ve got it, even if you don’t have any MySQL passwords (yet), because you’ll probably will be able to read any PHP files there anyway.
And no, I do NOT work for Google, I just know MySQL quite well and my networking knowledge isn’t too bad either. ;)

Earl Grey on 31.05.2007 said:
@inkredibl

Thanks for elaborating on the subject, it’s nice to see some good insights on the matter. Learned quite a few new things.

I think this is something that must be addressed, people lay too much faith in Google.

m1t0s1s on 08.06.2007 said:
I wonder if sanjeev at google is sanjeev agrawal? http://www.linkedin.com/in/sanjeevagrawal2007

No comments yet


 


Leave a Reply

Archives


Discuss this in the Black Hat SEO forum
on grey?