[unisog] Google Desktop (v3) [was (v4)

Michael Holstein michael.holstein at csuohio.edu
Mon Feb 13 17:28:50 GMT 2006

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) :

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; )

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.

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.


Michael Holstein CISSP GCIA
Cleveland State University

More information about the unisog mailing list