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.

Attacks/Breaches

2/28/2007
07:20 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

HID, IOActive Butt Heads Again

Rights and responsibilities of how, when to disclose vulnerabilities get revisited at Black Hat

ARLINGTON, Va. -- Black Hat DC -- HID Global and IOActive squared off face-to-face here today, after an IOActive researcher's briefing was yanked from the agenda this week following threats of a patent lawsuit by HID. (See Black Hat Cancels RFID Demo.)

The two remained at an impasse after Black Hat pulled together an impromptu RFID panel, minus IOActive's cloner research that prompted the debate, which included the ACLU, the Department of Homeland Security's US-CERT, and an RFID vendor who also does research. The panel re-convened in the Black Hat pressroom for a press conference, where it beat the drum some more.

HID spoke up publicly for the first time, and maintained that it had asked IOActive not to reveal source code, schematics, and to provide its solution to the flaws. "[We asked them] not to specifically target HID any more or less than any other vendor and to present solutions" to the problem, says Mike Davis, director of technology in the intellectual property department of HID.

"It was not a cease and desist" order, he says.

But IOActive sees it differently. Chris Paget, the researcher who built the RFID cloner and had planned to demonstrate it, says the ball is in HID's court. "It's up to HID to remove the threat of litigation so we can move forward and can talk in much greater detail," says Paget, director of research and development for IOActive.

Dan Kaminsky, director of penetration testing for IOActive, noted that the engineering side of the debate is less a conflict than the legal part. "I see no conflict" there, he says. "We could have worked together as engineers.

"Unfortunately, their initial communication with us was on legal grounds with very specific legal threats," Kaminsky says, adding that IOActive had no choice but to meet HID's demands and pull the presentation.

But HID's Davis says the RFID vendor did not ask IOActive to cancel its briefing at Black Hat. "We were surprised by their decision and to attribute it to a threat by HID. That was never HID's position."

The dispute and ongoing debate -- which both sides say they hope doesn't escalate legally -- strikes a nerve for enterprises. Paul Proctor, an analyst with Gartner, says organizations are purchasing the wrong RFID technology because it's the facilities management side of the house that's making those purchasing decisions.

"IT is not involved," he says.

HID and IOActive also were at odds over the responsible disclosure issue. "It's disingenuous and not proper to teach someone [and give] them carte blanche to build such a device and compromise security," says HID's Davis.

Paget maintains IOActive wasn't singling out HID. "We used the HID tag to develop the cloner because those are the tags we use in our building. There was no other reason."

Gartner's Proctor notes that a vulnerability, whether in the wild or well-known like RFID, merits disclosure to the end-user community to "raise awareness."

— Kelly Jackson Higgins, Senior Editor, Dark Reading

  • HID Global Corp.
  • IOActive

    Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio
     

    Recommended Reading:

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    COVID-19: Latest Security News & Commentary
    Dark Reading Staff 5/28/2020
    Stay-at-Home Orders Coincide With Massive DNS Surge
    Robert Lemos, Contributing Writer,  5/27/2020
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Write a Caption, Win a Starbucks Card! Click Here
    Latest Comment: Can you smell me now?
    Current Issue
    How Cybersecurity Incident Response Programs Work (and Why Some Don't)
    This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
    Flash Poll
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2020-11844
    PUBLISHED: 2020-05-29
    There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
    CVE-2020-6937
    PUBLISHED: 2020-05-29
    A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
    CVE-2020-7648
    PUBLISHED: 2020-05-29
    All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
    CVE-2020-7650
    PUBLISHED: 2020-05-29
    All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
    CVE-2020-7654
    PUBLISHED: 2020-05-29
    All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.