Let Me Get That Door for You: Remote Root Vulnerability in HID Door Controllers | Hacker News Reader

Let Me Get That Door for You: Remote Root Vulnerability in HID Door Controllers

blog.trendmicro.com

95 pointschoult50 comments

I think it's rather ironic that this was published by Trend Micro, a company that has had at least two critical vulnerabilities in their own "security" solution:

https://bugs.chromium.org/p/project-zero/issues/detail?id=69... https://bugs.chromium.org/p/project-zero/issues/detail?id=77...

I realize that the two teams are probably unrelated, but maybe it would be worth verifying that their "security" software is indeed, you know, secure.

Google has had security vulns too. Do you find it "ironic"[^1] that Tavis would disclose vulns in other companies software?

[^1]: You really should look up the definition of this word.

> Google has had security vulns too. Do you find it "ironic"[^1] that Tavis would disclose vulns in other companies software?

No, the thing in this instance is that a) Trend Micro is a dedicated "security" company and b) the vulnerabilities in its software were especially negligent.

> You really should look up the definition of this word.

One definition I found was "happening in the opposite way to what is expected, and typically causing wry amusement because of this". Considering that, I'm quite happy with my usage of the word. That said, English is not my first language and I often see people nitpicking about this particular word. My feeling is that people understood me just fine despite of it.

You expected an antivirus company to write perfect code and not have any vulns? That is hilarious.

Look up Fireye vs. ERNW. You will love that one.

> You expected an antivirus company to write perfect code and not have any vulns?

no. But I expect them to have their shit together well enough to not be the laughing stock of the internet because of how amateurish their flaws are (come on - unauthenticated remote accessible JS shell with full local machine access? This didn't even happen to microsoft in the 90ies)

AV programs are by definition in an utterly exposed spot on your machine: They run in a privileged account and they intercept all reads and writes to the disk. They also unpack every archive, parse every file, check every single byte written. An AV program is opening every mail attachment, practically inspecting and sometimes even partially running every trojan on your machine, even those you blatantly ignore as being spam.

For an application in such an exposed point on your machine, I expect them to at least follow current security-best-practices, tough honestly, I would wish they would go far beyond that due to the immense risk they subject themselves to.

And then we have trend micro, an AV program, which opens a remote accessible RPC endpoint which can be used by everyone. This is the exact opposite of what I'm expecting them to be doing.

I did not realize that Trend Micro was held to such a high standard. My (uninformed) opinion of them was that they were nowhere close to best of breed.

But more importantly, it seems like there is a difference between the way things are and the way you think things ought to be. Look at all of the AV industry bugs from google's project zero:

Avast (9): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

Comodo (9): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

ESET (3): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

FireEye (2): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

Kaspersky [you will love the archive unpacking vulns] (15): https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

malwarebytes (1): https://bugs.chromium.org/p/project-zero/issues/detail?id=71...

All in one list: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...

> I did not realize that Trend Micro was held to such a high standard

nope. Not Trend Micro. All of them. And as long as they are failing as spectacularly as you're pointing out here, my recommendation is to not use AV software and instead use whitelisting of allowed applications.

this looks like it may have come from ZDI which was only just recently purchased by trendmicro

I can't be the only one who thought HID was Human Interface Device, the category of USB device, at first.

I had one of these on a key fob for an apartment building. I thought the exact same thing every time I saw the HID letters embossed on it.

I always think that too, although I can't be the only one who has used HID prox tags in virtually every company I've ever worked for, virtually every datacenter I've ever visited, etc...

It's the same as with the RSA company - another confusing name.

Quit bringing up the Renaissance Society of America!

I was thinking High Intensity Discharge, but I do more lighting than progrmaming

And I thought that the exploit they used in Mr. Robot to remotely unlock all doors in a building at once was far fetched! This is basically exactly it.

The concept of programming by string substitution really needs to die, and operating systems need to stop enabling it with functions like system(). Any time you have to think about "sanitizing" strings, terrible mistakes are going to happen.

That's what we've got from switching from Lisp machines to x86 and C.

It's funny how the 'stitching strings together' problem was solved 50 years ago and the modern web still didn't get the memo.

I don't think anyone got the memo in any industry. Also if Lisp would be more popular in the industry I'm sure that we would find similar vulnerabilities as well.

No doubt about vulnerabilities. But I'm not talking about vulnerabilities, but about a particular kind of stupid behaviour that creates an immense class of vulnerabilities. Stitching, parsing and reparsing strings is not the right way to handle structured data. We knew that for almost half the century, we had tools for doing it properly since about the same time, and yet most popular frameworks, tools and even Unix itself are stuck deep in that mistake.

On that note, using powershell for a while really made me wish Unix would move to something beyond mere pipes. I love the Unix command line, but sharing structured data seamlessly is simply better

Yeah, PowerShell is great. It's a bit cumbersome to use for me[0], but passing objects instead of plaintext is a step (back) in the right direction.

[0] - Maybe I'm missing some sane config sets? I'm not a very experienced PS user.

What makes powershell's system better? I've never used it

You pass around .NET objects instead of plaintext. Which means information you work on retains its metadata even after lots of piping, and you don't have to invent ad-hoc sed/awk-based microparsers that will break on another machine anyway (be it because of different locale or different command implementation). You operate on objects, and in the end - if you're printing to e.g. terminal - you decide how to display the data.

A simple example - equivalent of ls -la with sorting by size: Get-ChildItem | Sort-Object length. You can sort like that because each entry returned by Get-ChildItem is in fact an object. In case of files, it's an object of type System.IO.FileInfo. Some of available properties are:

    Attributes                Property       System.IO.FileAttributes Attributes {get;set;}
    CreationTime              Property       datetime CreationTime {get;set;}
    CreationTimeUtc           Property       datetime CreationTimeUtc {get;set;}
    Directory                 Property       System.IO.DirectoryInfo Directory {get;}
    DirectoryName             Property       string DirectoryName {get;}
    Exists                    Property       bool Exists {get;}
    Extension                 Property       string Extension {get;}
    FullName                  Property       string FullName {get;}
    IsReadOnly                Property       bool IsReadOnly {get;set;}
    LastAccessTime            Property       datetime LastAccessTime {get;set;}
    LastAccessTimeUtc         Property       datetime LastAccessTimeUtc {get;set;}
    LastWriteTime             Property       datetime LastWriteTime {get;set;}
    LastWriteTimeUtc          Property       datetime LastWriteTimeUtc {get;set;}
    Length                    Property       long Length {get;}
    Name                      Property       string Name {get;}
    BaseName                  ScriptProperty System.Object BaseName {get=if ($this.Extension.Length -gt 0){$this.Name.Re...
    VersionInfo               ScriptProperty System.Object VersionInfo {get=[System.Diagnostics.FileVersionInfo]::GetVer...

You can sort by any of these. And each object has even more methods available, like Delete(), Encrypt() or SetAccessControl().

Examples of formatting: https://technet.microsoft.com/en-us/library/dd347677.aspx.

Coming from Unix, this seems super unintuitive, but that's probably just my background. Do you find it tough to figure out what you need to do?

You have to learn a few things, just like you have to learn them on Unix. You need to familiarize yourself with some basic cmdlets like Get-ChildItem or Format-Table or Sort-Object, etc. Just like you need to learn about ls or grep or the test syntax under Unix.

PowerShell is pretty discoverable though (not as discoverable as one may be used to in Lisp ecosystem, but still). For instance, I can fetch the list of properties like the one I pasted in my previous comment by using: Get-ChildItem somefile | Get-Member. It's roughly equivalent to ls filename | <something that would describe the file's properties if the result wasn't plaintext>.

Personally, I do find cmdlets a bit cumbersome to type in even with TAB-completion, but fortunately PowerShell defines a lot of aliases - like (again, I'm just copying what I found after typing "alias"):

    CommandType     Name
    -----------     ----
    (...)
    Alias           cat -> Get-Content
    Alias           cd -> Set-Location
    Alias           chdir -> Set-Location
    Alias           clear -> Clear-Host
    Alias           cp -> Copy-Item
    Alias           diff -> Compare-Object
    Alias           dnsn -> Disconnect-PSSession
    Alias           echo -> Write-Output
    Alias           kill -> Stop-Process
    Alias           ls -> Get-ChildItem
    Alias           man -> help
    Alias           mount -> New-PSDrive
    Alias           pushd -> Push-Location
    Alias           pwd -> Get-Location
    Alias           rm -> Remove-Item
    Alias           tee -> Tee-Object
    (...)

So e.g. ls | Get-Member works too.

The cmdlets however are often more powerful than their bash/Unix equivalent and - again - they work with objects, which you can always inspect if you're not sure what properties and methods they expose.

It's a really stupid bug, and a somewhat dangerous vulnerability, but hopefully places like airports have IT teams in place that are at least competent enough to put these devices on a separate VLAN and locking it down.

On average, my guess is that small businesses are more vulnerable to this, but that's mitigated by them being less likely to be targeted by a hack this sophisticated.

That being said, incompetence can be found everywhere, and obviously it's important for the vulnerability to be fixed.

>IT teams in place that are at least competent enough to put these devices on a separate VLAN and locking it down.

The problem here is that the way this stuff has grown through the past 50+ years is that IT does "computers" and facilities does "physical security." These realms of responsibility have been seperate, but now are really IT.

Now that everything is tcp/ip, well, everything is "computers" now but many organizations struggle with this. IT departments aren't given these responsibilities and old school bureaucrats and rent-seekers don't want to give this to IT. So a lot of these largely blue collar types just call in some vendor who they can't judge nor can they question in regards to technical topics (yeah networking, PoE devices, IoT, remote connectivity, etc is a bit different than running analog doorbell cable that clicks doors open).

I had this fight recently at work. It was a political shitstorm about IT replacing the old school phone system with a proper VOIP system and to take over physical security keycards. This fight only ended when the VP in charge of those things retired. These people don't want to modernize and if they do, they'll do their best not to do it with IT. They'll just call some shit vendor who will take them for a ride and security will absolutely not be a concern. Of course that'll be easy to hack. No one is auditing this, setting up vlans, applying patches, auditing products before buying them, etc. We're in this ugly transition stage where everything is going to be a 'smart' device, but the people who are used to dumb devices are still employed. They can't be retrained and they don't want to be. Until these people retire, expect more stupidly simple physical security exploits.

This is going to be at anything government or union run. The protectionism, corruption, incompetence, etc will stymy any attempt at best practices, so no surprise to see airports in this article.

It's fair enough to note that IT may not own these systems, but they still have to interact with IT infrastructure at some point. But you're also right that politics can make things much more difficult than they should be.

The article doesn't specifically state that any airports or other sites are vulnerable, just that they could be.

You'd think so, but 'building operations' just buys their own internet line and off they go. These large organizations are all silo'd. I suspect we're blaming IT for a lot of things they have no jurisdiction over.

In fact, have you seen some of these automation sites? They're geared towards tradespeople and not towards IT. They know who their customers are.

One thing to note is that one has to gain physical access to the network (i.e. find a network plug) to perform the attack. The door controllers might be the least of your worries if this happens.

This is an astonishing level of incompetence for "A worldwide trusted provider of Secure Identity Solutions". Isn't there any competition in that market, or pressure to be scrutinized for certification/suitability for government contracts etc.?

> Isn't there any competition in that market

Whether there is or there isn't, it doesn't matter. People buying these systems are usually not competent enough to evaluate security issues, and companies do their best to hide information about such incidents while spending tons of money on marketing. Competition doesn't solve those issues when its the salesmen who control information flow to customer (or in other words, it pretty much never solves those issues).

> Competition doesn't solve those issues when its the salesmen who control information flow to customer

Wouldn't a competent competitor aim to point out flaws in such products and claim they're doing it better? Unless security is just a buzzword and not a real feature in this market, that is...

Every salesperson points out flaws in competitive products and claims they're doing it better. I'm willing to bet that HID's sales people can find lots of stuff their competitors do that they are doing better. We just happen to be focused on security here.

not a real feature in this market

I wouldn't be surprised if this was the case. It's very likely that since security in an access control product is key (heh!), the customer simply assumes everything on the market is secure.

>not a real feature in this market

Entirely possible. I'd guess that most of these systems replace mechanical locks wide open to anyone with the right tools and a few hours of lockpicking training. In retrofits it's common for the mechanical lock to still be there as an override, so bumping/picking may still be the weakest link.

Most are probably also deployed next to windows which are vulnerable to rocks, and on doors which wouldn't stand up to a crowbar or boot.

Access control is mostly about deterring casual users and bounding/monitoring/revoking the access of legitimate employees. Systems designed to stand up to teams of security experts are something else entirely.

Nearly all door controllers are broken. I hope someone comes out with a secure alternative soon but fear that the cost of installation that comes with these devices will prevent many people from upgrading.

There were secure alternatives available several years ago. Unfortunately the industry is moving from code running on bare metal to having the main panels and now the door controllers run a full embedded OS. The complexity of how everthing interacts now has increased exponentialy so your attack surface is now much larger. All for easier initial development.

And if you found that interesting, you'll possibly find this slideshow, a 2012 presentation by Brad Antoniewicz of Foundstone, interesting as well.

* https://github.com/brad-anton/VertX/blob/master/Attacking%20...

"Linux on a cris". Passwordless regular user, no shadow passwords, root with a crackable password, and a telnet server enabled.

Sad as this is, realize that the cheap mechanical locks it replaced weren't much better. The attacks aren't necessarily harder, just different and more familiar to us. Bumping and picking can be pretty trivial to people well-versed in locksmithing just like obvious vulnerabilities are trivial to those of us well-versed in software.

Headlines like this just reinforce my feeling that the "Internet of Things" concept is bad/premature. Maybe I'm pessimistic, but it strikes me as "Let's take this network technology that we've yet to make reliably secure or private and put it in everything!"

At the past two office I've worked at, sliding a belt through the glass door to activate the motion sensor works pretty well for when you leave your badge at your desk. ;)

Discoveryd then builds up a path to /mnt/apps/bin/blink and calls system() to run the blink program with that number as an argument.

I have a feeling this is similar to the left-pad debacle... a whole separate binary just to blink an LED? "Blink n times" should be nothing more than a loop with two delays and presumably a write to a GPIO device in the middle. Unwarranted complexity strikes again.

Does anyone recognise the architecture? "JSR" and "MOVE.D" brings up some PDP-11(?) docs, which doesn't seem right.

It feels ok for me. It's kind of the Unix way, with all the /bin/true, /bin/false, /dev/zero, etc. That /mnt/apps/bin/blink may just be exactly that "loop with two delays and presumably a write to a GPIO device in the middle", written in C or even hand-written in ASM.

The problem isn't 'blink'. The problem is calling it via system() and handing unsanitized user input to system().

I wonder why it calls daemon() immediately before calling system().

That's too narrow in scope. The fact that they decided to make such a trivial function an externally invoked binary is also a large contributing factor, and should not be overlooked. There would otherwise be no need to use system(), "sanitize" user input, etc.

> Does anyone recognise the architecture?

At the first glance, assembly looks a bit like ETRAX CRIS.

https://en.wikipedia.org/wiki/ETRAX_CRIS

The issue with leftpad was not how trivial it was, but how easily it was lost, and broke so many dependent packages, when the maintainer had a bad day. That could have been any package. It was just a coincidence that leftpad was so small.

JSR and MOVE.D are also features of m68k, but the mnemonics don't seem to match the opcodes. Maybe it's "Coldfire".

Trend Micro has such a slimey leadership team that it is hard for me to see anything they do in a positive light. They desperately need to rebrand.

Reply on news.ycombinator.com