I think few vulnerability researchers look for them, are unlikely to understand their potential value if found, and probably wouldn’t disclose them anyway. The vast majority of researchers focus on memory corruption issues, browser cross-domain leakage, custom Web application attacks, or flaws in online business logic processes. While all of those vulnerability types are important, subtle issues remain unexplored -- ignored, which could enable one to generate huge dollar figures with no one being the wiser. Oh, and no malware required! An example of one of these vulnerabilities is Cross-Site Cooking (circa 2006) found by Michal Zalewski. Remember it? Fortunately for many, Michal publicly disclosed and vendors patched causing it to be a forgettable non-issue going forward.Cross-Site Cooking enabled a website (ie http://www.example.com/) to set arbitrary cookies associated to an entire domain with a foreign TLD such as *.com.pl or *.com.fr. The cookie value would be sent to every website having those TLDs. This could lead to delete stored preferences, session identifiers, authentication data, cart contents, etc. Now assume for a moment a similar browser bug existed where a website could set arbitrary cookies for generic *.com, *.net, *.gov, *.mil, or better yet perhaps just *. That cookie value would be sent to all those TLD, or in the latter case all sites. If such a bug existed it would seriously impact all websites not reissuing a session ID post authentication. Forcefully load up (PHP|JSP|ASP)SESSIONID to website visitors and then walk into any account you’d like! While bad as that is defrauding affiliates and affiliate networks is another possibility.
For those unfamiliar, affiliate revenue is BIG business, and generates money based upon cost-per-click and cost-per-conversion. Five and six figures per month is not unheard of and commissions owed are largely tracked through the use of cookies. For a fraudster imagine being able to simultaneously load your Amazon, eBay, Google, etc. affiliate cookie into tens or even hundreds of thousands of browsers in a single banner campaign. Anytime they purchase something on those sites you get paid because your affiliate cookies was received -- stepping on any others if they exist. Kaaachink! Websites receiving unexpected affiliate cookies would more than likely not even see or log it. The same for the user-side of the connection. Plus, cookies have no information on what website set the cookie. All nicely invisible. The reality is we really have no idea if this hasn’t already happened. We do know is some browser plug-ins and ISPs do this sort of thing already (load up their affiliate cookies).
Other targets such as (transparent) proxies could be targeted in a similar way. I'm also keeping my eye on Cross-Origin Resource Sharing, Flash Cookies, and clever timing attacks. Oh, and all the new browser standards coming out. Guaranteed goodness inside. Happy hunting!
2 comments:
just fyi any scam involving fraudulent clicks is useless nowadays. you can still multi-stage csrf most ad campaigns but your affiliate managers will "scrub" leads if you don't have a realistic conversion rate.
so if you send a million clicks and have 2 conversions, you're not gonna get rich (the black hat way).
however, iframing someone into mpack to install some toolbar is still a great way to make money =]
@Arshan, of course you are right about the conversation fraud rate flags, but in my example this is not an issue.
We're not targeting clicks, only conversions. They affiliate network doesn't care about much of anything as long as a conversion is legit. And in this case, it is! The customers simply made a purchase without your help and your affiliate ID was assigned.
done deal.
Post a Comment