full-disclosure - blocking Google Desktop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon Feb 13 17:34:30 2006
From: michael.holstein at csuohio.edu (Michael Holstein)
Subject: blocking Google Desktop

First, I made a mistake in the version number. The current/new one is 
version 3 (the one that uploads your data to Google)

I've been experimenting with Snort sigs to detect this.

Google Desktop uses a unique user-agent (I got a tip about this from 
another user at full-disclosure -- thanks Charles!) :

User-Agent: Mozilla/4.0 (compatible; Google Desktop)

So here is a snort sig for that ...

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg: "BLEEDING-EDGE Google 
Desktop User-Agent Detected"; flow: to_server,established; 
content:"User-Agent\: Mozilla/4.0 (compatible\; Google Desktop)"; 
nocase; classtype: policy-violation; sid: 3000001; rev:1; )

That sig would at least let you know who's using it, but blocking that 
traffic wouldn't do anything except prevent the RSS feeds (news, 
weather, etc) from loading.

Now, for the file-specific stuff, since that's all done over SSL to 
google.com :

Upon examining the SSL/TLS session setup, I wrote this one to flag the 
certificate Google is using (from Thwarte). This will probably change 
when they change/renew their certificates.

alert tcp $EXTERNAL_NET 443 -> $HOME_NET 1024:65535 (msg: "BLEEDING-EDGE 
Google SSL key exchange"; flow: from_server,established; content:"|30 36 
30 36 30 37 32 32 31 32 35 34 5A 30 68 31|"; rawbytes; content:"|77 77 
77 2E 67 6F 6F 67 6C 65 2E 63 6F 6D|"; rawbytes; 
classtype:policy-violation; sid: 3000002; rev:1; )

Note that this also flags logons to gmail.

The fetches with the "Google Desktop" user-agent happen first when the 
application is started -- then you get the SSL setup for any new data to 
be uploaded to Google's servers.

Unfortunately, the dynamic/activate stuff in snort dosen't let you do an 
"alert" action after an activate -- because it's designed to just dump 
the next (n) packets. If there was a good way to chain the two rules 
together -- to say "after seeing 1, do REACT on #2" you could reliably 
kill any SSL/TLS sessions from somebody running Google Desktop, thus 
preventing the upload of anything.

Thoughts?

Michael Holstein CISSP GCIA
Cleveland State University