
Let Me Get That Door for You: Remote Root Vulnerability in HID Door Controllers - choult
http://blog.trendmicro.com/let-get-door-remote-root-vulnerability-hid-door-controllers/
======
jnky
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=693) [https://bugs.chromium.org/p/project-
zero/issues/detail?id=77...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=773)

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.

~~~
dfc
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.

~~~
jnky
> 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.

~~~
dfc
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.

~~~
pilif
> 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.

~~~
dfc
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...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label%3AProduct-
Avast&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids)

Comodo (9): [https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label%3AVendor-
Comodo&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids)

ESET (3): [https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label%3AVendor-
ESET&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids)

FireEye (2): [https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label%3AVendor-
FireEye&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=ids)

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

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

All in one list: [https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q...](https://bugs.chromium.org/p/project-
zero/issues/list?can=1&q=label%3AVendor-Comodo%2CVendor-Kaspersky%2CVendor-
ESET%2CVendor-AVAST%2CVendor-FireEye%2CVendor-
TrendMicro&sort=severity&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary+Severity&cells=ids)

~~~
pilif
> 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.

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

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

~~~
rconti
Quit bringing up the Renaissance Society of America!

------
feintruled
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.

------
panic
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.

~~~
TeMPOraL
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.

~~~
LunaSea
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.

~~~
TeMPOraL
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.

~~~
nolok
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

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

~~~
TeMPOraL
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](https://technet.microsoft.com/en-
us/library/dd347677.aspx).

~~~
CaptSpify
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?

~~~
TeMPOraL
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.

------
tallanvor
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.

~~~
drzaiusapelord
>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.

~~~
tallanvor
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.

~~~
drzaiusapelord
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.

------
lazyjones
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.?

~~~
TeMPOraL
> _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).

~~~
lazyjones
> _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...

~~~
superuser2
>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.

------
bobedybobbob
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.

~~~
Avernar
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.

------
JdeBP
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...](https://github.com/brad-anton/VertX/blob/master/Attacking%20Proximity%20Card%20Access%20Systems-v0.1.pdf)

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

------
superuser2
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.

------
jrcii
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!"

------
bpchaps
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. ;)

------
userbinator
_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.

~~~
TeMPOraL
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.

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

~~~
userbinator
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.

------
droopybuns
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.

