Another XSS In Google Search Appliance
$30,000 and vulnerabilities to boot! Google’s search appliance appears to be vulnerable to another XSS vulnerability, according to Mustlive’s disclosure. It comes complete with a Google dork. Not good. Mustlive has contacted Google, who to my knowledge has not let their customers know that they are vulnerable - if I’m wrong, someone please correct me.
Here are a few examples: gsa.icann.org and search.york.ac.uk.
This obviously puts any site that uses Google’s search appliance with this particular vulnerability in it at risk (there are, as of this writing 186,000 listings on the Google dork). Time to patch up - once Google comes out with one, that is.



September 21st, 2007 at 11:45 am
RSnake, http://websecurity.com.ua/1365/ - it is holes at MI5 site, and my disclosure is http://websecurity.com.ua/1368/ ;-).
And for me Google show up to 195000 sites in my dork :-). Yes, Google need to fix these XSS holes.
For current time (after almost one day) they didn’t answer me, except default answer. Google need to work faster, a lot of people are using their products.
September 21st, 2007 at 12:11 pm
Whoops - updated with the correct URL. Sorry, Mustlive!
September 21st, 2007 at 12:35 pm
Best example is with Mustlive’s comment: sweet irony at MI5’s hole!
The moral could be “never trust another company with something sensitive” (but i can’t remember it exactly); the same is with banks (look at the Northern Rock situation in the UK)
Then again..
September 21st, 2007 at 4:10 pm
hoath
Just before holes at MI5’s site, I wrote about hole at MI6’s site www.sis.gov.uk (http://websecurity.com.ua/1361/)
The hole also in local search engine, not Google’s engine this time, but still vulnerable. So every site’s search engine (and Google Search Appliance in particular) and whole sites of people who take care about its security, and sites of special services especially, need to be security audited. MI5 and MI6 need to attend to security of their sites.
September 21st, 2007 at 7:24 pm
Nice work MustLive ^^
trying to get things done in utf7 was a pain in the ass..
September 21st, 2007 at 7:33 pm
Nice work MustLive
September 22nd, 2007 at 10:11 am
Hilarious and very good too. Goooooooooooooooogle.
September 22nd, 2007 at 11:54 am
MustLive can you tell me which lang you use in blog… need for babelfishing :=)
September 23rd, 2007 at 10:37 am
the .ua TLD of his website would suggest it’s ukrainian .. but i can’t tell languages with the cyrillic alphabet apart - all russian to me
September 24th, 2007 at 11:08 am
Not all Google appliances seem to be vulnerable as advertised (although problematic nonetheless)
/export/hda3/4.6.4/local/conf/frontends/x/domain_filter (No such file or directory)
Is above output a product of not configuring a filter?
That using the stated: /search?ie=%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E&site=x&output=xml_no_dtd’&client=x&proxystylesheet=x’
Anyone have a unit they can pull apart?
September 24th, 2007 at 12:07 pm
@digi - Hahah… if I did I probably wouldn’t be willing to sacrifice $30k
September 24th, 2007 at 2:43 pm
digi…
FYI, the code is POC code
the x should be replaced with whatever the filter name is on the site you are testing…
look at the mi5 examples
site=x
client=x
proxystylesheet=x
are all changed to
site=mi5
client=mi5
proxystylesheet=mi5
This is not to say that all appliances are vulnerable…the ones I have been checking return:
“Temporary server error. Try again in a minute.”
September 25th, 2007 at 10:45 am
Config changed in my previous example to protect the guilty (I didn’t use X’s really, although, I fat fingered my filter which led to other interesting things).
Configuring per spec, results in your message. If you configured the way I did initially, you find that you can reproduce your temporary server error elsewhere in the string, indicating to me more issues exist in a proven vulnerable device.
I wonder if this bug has been quietly fixed on newer devices. I can’t reproduce on this one.
September 26th, 2007 at 8:13 am
Well, maybe it is only affecting Google Minis.
IŽve done several attempts to GSAs and it didnŽt work.
You can check the software version (if avaliable) on port 8000.
York website is using google mini accordng to its website and the icaan can be checked here: http://gsa.icann.org:8000/EnterpriseController
altough it states Google Search Appliance, the software version says its a Mini.
IŽll keep my research on.
September 29th, 2007 at 6:58 am
Dhaval Shah and guys, at my site I use Ukrainian language. If you need to translate my posts you can use services which support ukr-eng translation (like translate.meta.ua).
gsaXpert, you need to check (if you want) what type of Google search is vulnerable Google Mini or Google Search Appliance (or both). Because as I found on web sites where I tested these XSS holes (mi5, icaan and york) they are using GSA.
Like icaan’ site tell (gsa.icann.org:8000/EnterpriseController), they are using GSA (gsa.icann.org:8000/EnterpriseController?actionType=about) as it written on pages (but they have Mini logo). And york’s site tell (http://search.york.ac.uk/search) that they are using Google Search Appliance. So I wrote that holes are in GSA.
October 1st, 2007 at 2:11 am
MustLive,
First of all, youŽve done a pretty impressive work finding those bugs.
IŽve done a deeper research and IŽve found that the logo determines wich product is.
You can check it at:
(Google minis)
http://gsa.icann.org:8000/images/google_sm.gif
(Google Search Appliances)
http://web.search.cornell.edu:8000/images/google_sm.gif
http://search.who.int:8000/images/google_sm.gif
http://find.stanford.edu:8000/images/google_sm.gif
On the York website you can find:
http://www.york.ac.uk/coord/docs/searchhelp.htm
Where it states: “The University uses Google Mini to index information”
Thanks for your help!
Sincerely,
gsaXpert
October 3rd, 2007 at 2:06 am
At last, Google officially recognized this bug.
https://support.google.com/enterprise/public/ga-2007-09-m.html
Guess what? it only affects Mini systems.
Closed
October 3rd, 2007 at 8:02 am
Twelve days to admit it’s a problem. Interesting. Still waiting on the google desktop issues to come back - they’re still looking into those apparently. Best and the brightest!