Lance James, Daylight Fraud Prevention @ CodeCon 2006, 12:30pm Friday

To begin my series of prejudicial CodeCon session previews:

Lance James (Secure Science): Daylight Fraud Protection, 12:30pm Friday @ Codecon 2006

Daylight Fraud-Prevention* (DFP) is a suite of technologies offering a powerful proactive defense against scammers and online criminals...

[using] ...a combination of detection, identification, prevention, and tracking methodologies.

The DFP description and website are long on highfalutin' terminology but short on details, but here's what it appears DFP does in more plain language:

1. DFP rejects image requests without acceptable REFERRER info, so that phishers can't easily use your own hosted images against you.

   One possible phisher countermeasure might be to get a target's browser to visit the source page in an unnoticed way, loading its cache with the images using the right referrer -- then reusing the images (unless the source site cripples image caching) such that the use generates no hits against the source site.

   More likely, phishers would just download the images and host them at the same fly-by-night sites (or hijacked machines) used for their other hosting. Which brings us to...

2. DFP watermarks every outgoing image to be uniquely trackable and correlatable with original requestor -- so that if it's later seen on a phishing attempt, the perpetrator's IP address on the original fetch can be retrieved.

   Possible phisher countermeasures include scrubbing received images t remove the watermarks, or most likely just ensuring that another IP not traceable to them appears in the original site logs. For example, the images could be swiped from some innocent rube's session-in-progress (or cache on disk), setting up a convenient patsy. Or most likely, they'd just use a IP-hiding proxy to download the images in the first place. Which brings us to...

3. DFP attempts to discover the real IP of any site accesses, either when retrieving images or trying out harvested username/password combos. They probably do this by consulting the extra headers added by polite proxies or some sort of Java or Javascript page insert.

   Indeed, visiting their test page discovered my private NAT address, apparently by use of a Java applet. Visiting the same page via the free Anonymizer gave a blank page warning that an Applet had been disabled. Visiting the original test page after disabling Java in my browser gave the same blank, inert page. (The Applet itself must trigger redirection to the page that reports the discovered IP.)

   Phishers are likely to just use effective anonymizing proxies or disable Java before interacting with targets sites. Or, cause Java itself to give misleading IP info, by using a private NAT address that looks like an open-internet address.

4. DFP works to hide form parameters from locally-installed malware that is presumed able to spy even on SSL transactions. I suspect it does this through transforms on form parameter names on initial outbound display that are reversed on submission, or perhaps Javascript-based scrambling of form contents.

   DFP form-parameter scrambling could be considered just a mildly good hygenic measure against the most simpleminded traffic-scrapers. But largely, once you assume deeply intrusive malware is on the target's machine, it's game over. So what if you scramble the forms? The malware can read all keystrokes, package up and send off entire cache contents and form submissions for studious analysis by smart humans, and so on. A little parameter-scrambling isn't going to help that.

All these steps are reasonable and likely to make marginal improvements in fraud-resistance, but all could be easily defeated by a savvy phisher aware of their existence. All send the signal: we're more vigilant than average, and so might encourage lazy phishers to concentrate their efforts elsewhere. ("Bear menaces two men. One puts on sneakers. 'You can't outrun a bear.' 'I only have to outrun you.'")

DFP techniques wouldn't be more secure via obscurity -- but they might entrap a larger proportion of naive phishers if generally not publicized. So SecureScience might enjoy more success showing their wares only in private to potential customers (banks), rather than on a public demo site and CodeCon. Their decision to present is thus curious.

The DFP public website has odd and paranoid disclaimers like "Confidential and Proprietary Information. FOIA Exempt. Patent Pending Daylight Technology." Should CodeCon require a patent-disclosure statement of presenters? Allow attendees to leave the room before they are "contaminated" by the presentation of a possible patent-troll?

Update (2:27pm Friday): I completely missed this session. Someone please let me know if I got anything wrong.

Technorati Tags: codecon, codecon2006, daylight fraud prevention, secure science, phishing, fraud, security

«»