I Know Who You Work For

Other than asking a visitor directly, there are five ways I know of for http://maliciouswebsite/ to find out where a visitor is employed. Depending on the visitor’s browser set-up, most of the time one of them should be able to get the job done.

1) Clickjacking (Likejacking, Followjacking, etc.)

As we’ve learned from the previous section, combining Login-Detection with Likejacking, Followjacking, etc. allows a website such as http://maliciouswebsite/ to quickly determine a Web visitor’s real name. The visitor need do nothing more than click on something.

In the case of Facebook and a Likejacking attack, a visitor’s publicly available profile information will often contain the name of their employer. As for Twitter and a Followjacking attack, it is possible their employer could be named in their accounts description, but the likelihood is much less than Facebook and the data is definitely not well-formed. I’d place Google+ in a similar league. LinkedIn, however, is a professional identity social network, so clickjacking a LinkedIn Follow button and obtaining a person’s real name and employer is practically a given.

While I’ve not personally measured this in the wild, I’d hazard a guess that almost everyone online has an account on Facebook, Twitter, Google, or LinkedIn. I’d also bet that most people are probably logged in to one of these services all the time. If both assumptions are generally true, the odds are good that one of these deanonymizing clickjacking attacks is going to succeed when a browser visits http://maliciouswebsite/. But, if not, there are several more techniques that can be attempted.

 

2) Browser Intranet Hacking

Every corporate network is likely to have an Intranet website with a unique hostname that all employees, and only employees, can access — intranet systems such as HR portals (i.e. http://humanresources.corp/), CRMs (i.e. http://crm.corp/), and corporate directories (i.e. http://directory.corp/), to list a few common examples. Because these systems are not accessible to the outside world, only employees sitting on the Intranet network, or perhaps a VPN’ed in, can get to them, and this actually aids in employer identification from within a browser.

If http://maliciouswebsite/ knows the Intranet URLs of target firms  — not exactly well guarded secrets — it can force a visitor’s browser to make Web requests to these and detect if they exist. This technique is very nearly the same as the one described in the Login-Detection section. Many people will be surprised to learn that nothing technologically prevents http://maliciouswebsite/ from forcing Web traffic to Intranet locations that are not externally available.

Use IMG, SCRIPT, IFRAME, and LINK tags to look for resources in well-known locations. For example:

<* img src=”http://humanresources.corp/image.png” onload=”employee()” />

or…

<* iframe src=”http://humanresources.corp/” onload=”employee()” ><* /iframe>

99.99% of the time these Web requests will simply timeout. However, if the OnLoad event handler fires, the visitor is probably an employee of the organization belonging to that URL. At its core, this is the same browser Intranet Hacking trick first disclosed by Robert Hansen and myself back in 2006 and later improved upon in 2007, and it remains useful for all sorts of things to this very day, including employer identification. This technique was also recently used as part of an attack that compromised millions of DSL routers in Brazil.

Over the years I’ve managed to identify quite a number of such Intranet hostnames for Google, Yahoo, Microsoft, and so on. (I’ll be keeping the list to myself — revealing it is not necessary to convey the concept.)

 

3) IP-Address Geolocation

In the previous section on IP-Geolocation, I described how IP Addresses can be associated to particular locations through a variety of methods. http://maliciouswebsite/ can often find out what network the browser is on, and that will often include the names of companies, universities, military bases, and so on.

 

4) Multi-Website Tracking

In an earlier section, the concept of browser interrogation was explained. As part of that discussion I described how a browser visiting SiteA may harvest and store detailed information via a third-party Javascript tracker (ie Google Analytics, Coremetrics, and thousands others). When the visitor moves onto SiteB, a tracker from the same provider may be present and may collect even more data.

 

“A mashup is a self-inflicted XSS attack.”

- Douglas Crockford

 

A great deal of data may be passively collected: what Web pages were visited and when, from work or at home, how long they stayed, where they went afterwards, where the mouse hovered, the last thing say saw before purchasing, etc. Visitor data can also be actively gathered when visitors fill out a Web form with additional personal information like their name, address, telephone number, etc. Over time, as the visitor interacts with hundreds and thousands of websites, all of which have the same and multiple third-party Javascript trackers present, a fairly comprehensive visitor profile is created. This profile is identifiable from one website to the next by “cookies” kept in the visitor’s browser.

“Cookies” is in quotes because there are at least 12 locations where such data can be stored in a browser. These include Standard HTTP Cookies, Internet Explorer userData storage, Flash Cookies (LSOs), Web cache, Silverlight Isolated Storage, HTTP ETags, window.name caching, RGB values of auto-generated force-cached PNGs using HTML5 Canvas tag to read pixels (cookies) back out, Web History, HTML5 Local Storage, HTML5 Global Storage, HTML5 Database Storage via SQLite. Keep this in mind the next time you “delete your cookies.” Are you 100% certain you removed all of them?

Back to the point. Nothing technologically prevents third-party tracking firms from reselling the visitor profile information they’ve collected to other website owners. Two such examples are DemandBase and LeadLander, but there are hundreds of others. Website marketers find it extremely powerful to customize content for each individual visitor. Third-party tracking firms fill that need. So as soon as a browser visits a Web page, a third-party tracking company can look up the cookie ID stored in the browser, look up its profile data in their database, and supply it to the website owner on the fly. That’s how they can instantly know who you work for, your age, and so on.

 

5) CSS History Sniffing

Up until fairly recently it was trivial for http://maliciouswebsite/ to detect what URLs a browser has previously been to. As basically everyone online knows, purple colored hyperlinks are those they have been to before and the blue ones they have not. This color difference was detectable using either Javascript getComputedStyle or the CSS :visited psuedo class. With just a little bit of Web code, http://maliciouswebsite/ could check the visited status of hundreds, even thousands of URLs per second. In an instant it would know what social networks, banks, adult entertainment, etc. website a browser had been to — a huge privacy leak.

Fortunately, all of today’s most popular browsers have fixed CSS History Sniffing. The attack technique is no longer possible — at least, not at anything near the speed and accuracy at which it could be performed previously. However, because of the historical significance of CSS History Sniffing and the number of old and vulnerable browsers that remain in circulation, especially in a corporate environment, it is helpful to learn how the technique can lead to employee identification.

In the Browser Intranet Hacking section above I described how a list of company internal URLs can be created that only employees may visit. CSS History Sniffing can leverage that list as well. Only employees of an organization associated to one of the URLs would have its color be purple. The technique is really just that simple.

 

I Know…

This entry was posted in Web Application Security on by .

About Jeremiah Grossman

Jeremiah Grossman is the Founder and interim CEO of WhiteHat Security, where he is responsible for Web security R&D and industry outreach. Over the last decade, Jeremiah has written dozens of articles, white papers, and is a published author. His work has been featured in the Wall Street Journal, Forbes, NY Times and hundreds of other media outlets around the world. As a well-known security expert and industry veteran, Jeremiah has been a guest speaker on six continents at hundreds of events including TED, BlackHat Briefings, RSA, SANS, and others. He has been invited to guest lecture at top universities such as UC Berkeley, Stanford, Harvard, UoW Madison, and UCLA. Jeremiah is also a co-founder of the Web Application Security Consortium (WASC) and previously named one of InfoWorld's Top 25 CTOs. He serves on the advisory board of two hot start-ups, Risk I/O and SD Elements, and is a Brazilian Jiu-Jitsu Black Belt. Before founding WhiteHat, he was an information security officer at Yahoo! Jeremiah can be found on Twitter @jeremiahg.