My next class:

Most Anti-Privacy Web Browsing Tool Ever?

Published: 2012-07-23. Last Updated: 2012-07-23 02:29:56 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

For a while now, I got requests triggering our IDS, for their enormous cookie payload. The payload doesn't appear to be an attack, but includes tons of information, that appears to identify the user. These are not cookies we are setting, so some other site or tool is setting them. The content looks a bit like this may be used to pre-fill forms.

Please let me know if you have any idea what is sending all the data. I have no idea if this is legit, or just a "denial of service agains the analyst". But so far, it looks like the data is "real".

Over the last 10 days, I have seen 50 such requests for 13 different IPs. These are all "HEAD" requests and they hit various URLs on our site. Some have Google analytics "utm" strings appended to the URL indicating that they may come from Twitter related services. For example:

/podcast/podcast2671.mp3?utm_medium=twitter&utm_source=twitterfeed
 
All use the same user agent string, implying that they use Apple Safari, but the user agent isn't quite correct for Apple's Safari browser:
User Agent: AppleWebKit/525.13 (KHTML, like Gecko) Safari/525.13.

I am quoting a typical entry below, but I replaced and shortened some of the data with 'xxxxx'

charitydine[repeatad]=yes;
default_location[offset]=-4;
default_location[city]=ASHBURN;
ua-device[look]=web;
default_location[region_name]=VIRGINIA;
default_location[lat]=39.xxxx;
default_location[country_name_code]=US;
default_location[lng]=-77.xxxx;
default_location[country_name]=UNITED+STATES;
lsd=AXxxx_Jq;
pid.guid=xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx;
ua-device[mobile]=0;
ua-device[setDate]=134291xxxx; 
www.marykay.com=5711xxxxx.xxxxx.xxxx;
NSC_gbsfcvaa.dpn=ffffffff09091cc14xxxxxxxxxxxxx;
default_location[postal_code_number]=20146;
pds%5Fsess=d=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
default_location[locality_name]=ASHBURN;
www.apache.sid=bd28e6405d09ce1f263d9040bbae88db;
default_location[ip]=[IP address of request]
runkeeper.channel=web.activity.shorturl;
datr=ixELUAbi2WAU-IBZ34yrGE5v;
BIGipServerWWW.3NEWS.CO.NZ=1113893056.20480.0000;
default_location[lang]=US;
_shuffler.web_session=xxxxxxx[long URL encoded string]; 
vglnk.Agent.p=8645d6bf081026933xxxxxxxx; 
WP_SessionId_wishpot.com=3b0kpjwunqqkvexqgtbrbdt4; 
CB%5FSID=0f54b689a5314dbbbc1bff1eb8b68cbb-396224260-12-6; 
general%5Fmaturity=1; 
BIGipServerPOOL-xxx.xxx.x.xx-COMPLEX=xxxxx.20480.0000; 
locale=en-US; BIGipServerPOOL-xx.xxx.9.45-80=1392xxxx0.20480.0000; 
BIGipServerwebpool.microsites.prod=2xxxxx50.20480.0000; 
BIGipServerPOOL-94.236.9.5-80=3305285824.20480.0000; 
CakeCookie[user_uid]=xxxxxxxx
app.session=xxxxxxx--xxxxxxxxxx; 
BIGipServerwww-lb.informatica=xxxxx.20480.0000;
BIGipServerpool_www.briargatemedia.com_80=xxxxxx.20480.0000;
reg_fb_gate=http%3A%2F%2Fapps.facebook.com%2Ftopface%2Fhoroscope%2F%3Fref%3Dastro;
_trance-mixes.com_session=xxxxx; 
.ASPXANONYMOUS=ypvS7qCGzgEkAAAAYTxxxxxxGM1MTU5KOC9Bdg1cTmhf2I-v1VzJ8JuBtA1; 
jive.server.info=\"serverName=scn.sap.com:serverPort=80:contextPath=:localName=localhost.localdomain:localPort=9001:localAddr=127.0.0.1\"; 
BIGipServerPOOL-94.236.9.97-80=3422726336.20480.0000; 
derStandard%2Eat=MGUID=3507f291-5b32-4a36-8941-014aa483b475&Timestamp=2012-07-22T07:09:17; 
BIGipServerPOOL_198.101.142.28_80=4010062602.20480.0000; 
framework.security_id=e5003d6c6cef93db59e92c852aa37766; 
next=http%3A%2F%2Fwww.facebook.com%2Fpages%2FMy-Vault-Card%2F408213029194706%3Fref%3Dstream; 
next_path=%2Fpages%2FMy-Vault-Card%2F408213029194706%3Fref%3Dstream; 
gnm.m.u=On7_FOVzE7gcRS1hhjrvkwhl5cknme_4u1CVwx-62PSD_JY7vJm7IA; 
ASP.NET_SessionId_4=R1342036983; 
ASP.NET_SessionId=xsanyvzyuql4m245mkprzl45; 
=true; 
ax-sess-www.allfacebook.com=xxxOAEAK; 
connect.sid=LXjcpJkARqE4fNMmCGtL5o6Y.04kX5MkuGDxxxxxbSFgwi6gkWMj0vNnEH38; 
rack.session=7dca39e61fe4e8483f6740bedc6c68a6eebf3aacdf941bf8afbc0a06efe54140; 
_swombat.com_session=aba737b1ef62c56e8102e829ecb7d; 
cnetuk%3Aproduction%3Asid=kn1iu3s75pe6mulnopc2gafnh0; 
reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2Fphoto.php%3Fpid%3xxxxxx21304754582841; 
pds%5Flife=d=AQAC%2BDOCwhxxx=5; 
_session_id=1fa55bffc2162773f73d947ad45f243f; 
_bit=500be69b-00340-06202-441cf10a; 
cpsession=ff2f611c-d3f1-11e1-9a88-1231381f8344; 
SITE=FLPET; SECTION=HOME; 
ZDEDebuggerPresent=php,phtml,php3; 
snowball=xxxxxx-cf9e-43f8-b5fc-210449bd06bd; 
CAKEPHP=xxxxx; 
__cfduid=dc11c055eed8c7124c5686f5143e7f63f1342957212; 
spsite_sid=mgv7401bt5hadkhr733apu87g3; 
zdregion=xxxx; 
edition=us; 
session-zdnet-production=k9ia8jlxxxxxxxxbbes3hs3; 
NID=62=xxxxxx-jFcgLhqWQKx1D1z9_WRjn_xxxxxx-e5SnM0uw4mEwK;

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: cookies privacy web browser
8 comment(s)
My next class:

Comments

Could some kind of proxy being doing this; inadvertently merging cookies across domains? A closer look at the IPs might suggest if this is something misconfigured by an ISP, or someone tinkering with open proxies or Tor exit nodes.

Steven Chamberlain

Jul 23rd 2012
1 decade ago

Or maybe even a CDN acting crazy; allowing backends to set cookies for a domain that is shared by other customers. A lot of publishers seem to be mentioned in the above.

Steven Chamberlain

Jul 23rd 2012
1 decade ago

From what I recall, the default behavior for Safari in iOS is to accept cookies "from visited" sites and to block third-party cookies. The NoScript extension for Firefox can be used to accomplish a similar thing with third-party scripts.

The natural evolution for web-based advertising is to serve up advertising as if it were coming "from visited" sites. More third-party cookie information will migrate into duplicated site-specific cookie information. In order to serve user-specific content when a user visits a site, the server checks the provided cookie data, retrieves and caches user-specific content from a third party, serves up the web page with the user-specific content and sets additional cookie data to identify the user better.

This raises the question as to why a "HEAD" request is including such a large amount of cookie data that was never set by the site. It may be that this is a scan that is looking for sites that provide user-specific content (advertising, scripts, etc.).

Depending on how a web server retrieves user-specific content (ideally, such a server would be blocked from establishing outbound connections), it may also be a scan for servers that can establish outbound connections. Depending on what can be done with the embedded third-party cookie data (possibly session-specific), it may also be an attempt to retrieve information.

yvesk

Jul 23rd 2012
1 decade ago

The is the key set from an Id Vault USB encryption key. It stores encrypted logins, passwords, accounts and more that can be recalled by the computer once it is connected. The chatter is far from safe in my opinion, but that is no doubt what you are seeing.

Al of Your Data Center

Jul 23rd 2012
1 decade ago

It looks to me like something that's trying to exfiltrate data scraped out of an application. We've been dealing with some rather nasty malware that tries to do exactly this. Maybe the controllers messed up the phone-home location.

kjs3

Jul 23rd 2012
1 decade ago

The BIGipServer and BIGipServerpool items are typical for an F5 LTM that is doing persistence. Odd to see several of them glued into one packet. You can decode some of them, for example, BIGipServerPOOL-94.236.9.5-80=3305285824.20480.0000 is indicating a web server at 94.236.9.5, port 80 with a load balance selection on the back end of 192.168.2.197, port 80. Very odd.

dcb

Jul 23rd 2012
1 decade ago

Before 2009 this space was part of RIPE designation. After that it moved to Rackspace. If it is indeed a scraped block of info then it may date back a ways, or it could be on that cluster in Rackspace. I still think it is a key exchange to keep the USB lock secure and in sync (backed up) but I could be wrong. Finding out what is hosted on this cluster should answer the questions. Has anyone tried to send a packet out with this data to see what the server responds with?

Al of Your Data Center

Jul 24th 2012
1 decade ago

Obviously this is the accumulation of cookies from visits to *different* websites, and not specific to individual IPs or products mentioned. They were used in an HTTP HEAD query seen by Johannes to a server which presumably had nothing to do with the IPs or websites mentioned. The question is why are they all bundled together and being broadcast like this? Is it some broken software or a misconfiguration? Or did someone capture these beforehand, through whatever means, and is now maybe trying to bruteforce authenticated sessions to various sites?

Steven Chamberlain

Jul 24th 2012
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives