[unisog] Google Desktop (v3) [was (v4)
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