Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Startup Finds Phish in Browsers

New company could help banks, other service providers to warn users when they've been phished

As a business, you want to know when your customers are being phished, but you don't want to violate their privacy. As a customer, you want your service providers to warn you of potential security threats -- but you don't want them pawing through your browser history.

A startup company has developed a new technology that could solve both problems. RavenWhite, a venture begun earlier this year by Indiana University professor Markus Jakobsson and RSA Labs, has completed an alpha version of the software and will begin testing it in banks and financial institutions in the next few weeks.

The software, called Remote Harm Detection (RHD), resides on the server of the financial institution or service provider and scans the user's browser history for known phishing or pharming sites. But don't get your user privacy pants in a bunch: the system is merely looking for matches to a blacklist.

RHD doesn't collect any data about which sites the user has visited, explains Ari Juels, head of RSA Labs and one of the founders of RavenWhite. In fact, it doesn't even know which blacklisted site the user has been on -- it simply registers a warning that the user's machine has tested positive for potential phishing infections, and then lets the server's owner decide what to do about it.

"There have been other systems that collected data about the user's click history, but these have been largely rejected because of privacy concerns," Juels observes. "This is the first system to detect the presence of a potential phishing threat without violating the end user's private browsing history or behavior in the process."

If RHD turns up a positive result, it can trigger the server to respond, Juels explains. "How it responds is up to the company that operates the server. The service provider may choose to isolate the user, or prevent the user from accessing certain functions, such as the ability to wire money offshore." Or the provider may simply use the information to warn the user of the possibility that they've been phished, he says.

Banks and other financial institutions have come under heavy fire from phishers over the past year, and they are looking for ways to identify users and customers that may be at risk, Juels says. "With RHD, they can get that information without requiring the user to do anything -- they don't have to install a client, or report anything, or even change their behavior," he says. "And it's all done in a way that doesn't threaten their privacy."

Juels says he isn't sure how long it will take for RHD to get through alpha and beta testing to become a commercial offering, but he did venture that one of its form factors might be a service, as well as raw software. "A service offering makes sense, because the technology requires that we continually update the blacklist of phishing sites," he says. That list will likely be drawn from the databases of several groups currently collecting phishing data, including the Anti-Phishing Working Group, he says.

RHD is a new direction for RavenWhite, which gained some notoriety earlier this year for developing a technology called "active cookies," which add an element of authentication to normal Web cookies that makes them more difficult to scan or steal. Active cookies help prevent attackers -- particularly pharmers -- from intercepting a user's connection to a trusted server and rerouting it to a phishing site or application.

"We're still working on active cookies, but we think RHD has a lot more potential," Juels says. The startup may eventually find a way to bundle active cookies together with RHD in a single offering, he says.

Separately, RavenWhite is working on a prototype of a technology that could help publishers and advertisers combat "click fraud," in which an attacker attempts to manipulate the traffic on specific Web pages in order to alter the results of pay-per-click advertising services.

Today, most click fraud defenses involve matching the origins of site clicks against a blacklist of known click fraud sites, Juel observes. RavenWhite is working on a whitelist approach that helps publishers build a list of known, legitimate Web surfers in order to reassure advertisers that the clicks they are buying are actually being initiated by real customer prospects.

The advertiser might pay a lower price for clicks from users or domains that aren't on the whitelist, and the technology could be used in conjunction with blacklists so that the advertiser does not pay at all for clicks from known click fraud locations, Juel explains. The click fraud application hasn't begun alpha testing yet, so it is probably even further away from commercial distribution than the RHD technology.

What do RHD, active cookies and click fraud have in common? "They are all ways to help protect the user from fraud without violating their privacy," says Juels. "That's the thread that ties all of this technology together."

— Tim Wilson, Site Editor, Dark Reading

  • RavenWhite Inc.

    Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
    Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
    7 Powerful Cybersecurity Skills the Energy Sector Needs Most
    Pam Baker, Contributing Writer,  6/22/2021
    Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
    Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
    Register for Dark Reading Newsletters
    White Papers
    Current Issue
    The State of Cybersecurity Incident Response
    In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
    Flash Poll
    How Enterprises are Developing Secure Applications
    How Enterprises are Developing Secure Applications
    Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel�s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
    PUBLISHED: 2021-06-22
    Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
    PUBLISHED: 2021-06-22
    Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
    PUBLISHED: 2021-06-22
    Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.