Bluetooth security dangers ignored, say experts

Bluetooth security dangers ignored, say experts

Summary: Howard Schmidt, a former White House cybersecurity adviser, and RFID researcher Adam Laurie have warned that communications protocols are ripe for abuse

SHARE:
TOPICS: Security
1

Former White House cybersecurity adviser Howard Schmidt has warned of the dangers of flaws in Bluetooth protocols, claiming these vulnerabilities are unrecognised.

Schmidt, who is a board member for protocol-testing company Codenomicon, told ZDNet.co.uk at the Infosecurity Europe 2008 conference on Tuesday that protocols used in Bluetooth communications are vulnerable to attack and that device manufacturers and security professionals do not give enough credence to the problem.

"Bluetooth has been compromised," said Schmidt. "Fifteen of the [27] different protocols have vulnerabilities. Anything with multiple ports out there is looming for someone to use it."

Schmidt said that individual protocols, as well as the way protocols interact with each other, introduce security holes.

"It's like the 'whack a mole' game," said Schmidt. "The [flaws] pop up, you hit them with a hammer, and they pop up somewhere else. It's a constantly moving target."

While these flaws are only accessible by technically proficient hackers, Schmidt said the vulnerabilities are widespread and difficult to address, as standards cannot be updated in the same way as other software. Many protocols are apparently affected, included 802.11n, and those designed using ASN.1, a language employed in protocols used by the military and emergency services.

Flaws in communications protocols built using ASN.1 can be exploited to send malformed packets to crash systems and, depending on the implementation, can be subject to buffer overflow attacks which can lead to arbitrary code being executed, Schmidt warned.

Adam Laurie, an RFID and communications protocol security researcher and consultant, agreed that communications protocols implementations in the main do not have adequate security, because the protocols are being used outside of the specifications for which they were originally intended.

"A lot of what I look at is about unexpected interactions between different protocols," Laurie told ZDNet.co.uk. "There are a lot of Bluetooth hacks. Bluetooth is a good example. It started out as serial cable profile, then infrared, then became Bluetooth without anyone taking into account the change in the overall attack surface. Anyone within 100 metres can now connect to a Bluetooth device and device manufacturers haven't taken a step back and changed the protocols."

Laurie is notable for cracking RFID communications in UK passport chips, and also for managing to access a hotel web server and back-end system through the infrared TV remote in his hotel room.

At the conference Laurie also took the opportunity to call for the Oyster smartcards used in London's transport system to be replaced, in light of recent hacks to similar cards in the Netherlands that are based on the same Mifare technology from NXP.

"My understanding is there are now three [Mifare] cracks at least," Laurie said in his keynote speech on RFID flaws. Speaking to ZDNet.co.uk after his speech, Laurie said he thought Transport for London (TfL), the body that runs the Oyster card scheme, "ought to think about upgrading as soon as possible".

Laurie said the Dutch government had been right to announce it was replacing the Mifare-based cards. "I applaud the Dutch government for jumping straight on it," he said. "It would be better if TfL just got on with it. It's a bit of an arms race — once you know it can be done, that's enough of an impetus to say: 'We will get on and do it.'" He added that he thought it unlikely that this would happen until someone specifically demonstrated an Oyster card being cracked.

A spokesperson for TfL told ZDNet.co.uk on Wednesday that the Oyster system incorporates additional security systems in addition to what is already built into Mifare. "We wouldn't go into what security systems we've got, but we do have extra layers within the whole Oyster system," the spokesperson claimed. "We run daily tests for any cloned cards or rogue devices and none have been discovered. We are aware of the situation in Holland but, at this stage, there's no reason to migrate to a different system due to any security concerns."

Topic: Security

Tom Espiner

About Tom Espiner

Tom is a technology reporter for ZDNet.com. He covers the security beat, writing about everything from hacking and cybercrime to threats and mitigation. He also focuses on open source and emerging technologies, all the while trying to cut through greenwash.

David Meyer

About David Meyer

David Meyer is a freelance technology journalist. He fell into journalism when he realised his musical career wouldn't pay the bills. David's main focus is on communications, as well as internet technologies, regulation and mobile devices.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

1 comment
Log in or register to join the discussion
  • No security flaws in the ASN.1 standard

    The statements about ASN.1 in the article above are incorrect. ASN.1 is a well-established standard language that is used in many different standard communications protocols to define the structure of the messages and their encodings. As a standard language, ASN.1 is very mature and very stable, and has no security vulnerabilities. Over the long history of this standard (two decades), there have been reports of security flaws in some of its implementations. Now and then there have also been allegations that the language itself had flaws, but such allegations were never substantiated.

    Around the year 2002 there was a surge in the level of public concern and in the number of security vulnerability reports on certain implementations of communications protocols specified in ASN.1. As the increased level of concern was reflected in the press, many articles that mentioned security vulnerabilities associated with "ASN.1" were posted on the Web at that time, and many of those articles are still popping up today on Web searches. The issues referred to in those reports were solved by correcting bugs in the various implementations, and it was never necessary to modify the ASN.1 standard itself. Some ASN.1 implementations, such as OSS Nokalva's ASN.1 tools, were found to be free of the bugs that were plaguing certain other ASN.1 implementations, suggesting that the use of professional ASN.1 tools by a protocol implementer greatly reduces the risk of security flaws being present in the final product.

    The key point, anyway, is that while some implementations may be buggy (and hence contain security weaknesses), the ASN.1 language itself has no such weaknesses.
    alessandrot