
Zero-days in Cisco Discovery Protocol - pimterry
https://www.armis.com/cdpwn/
======
pixelpoet
Does anyone actually have faith in their hw+sw security these days? The
speculative execution stuff on CPUs, system code full of buffer overflow /
privilege escalation bugs, attacks that can work across airgaps using high
frequency sounds, all the attacks on various hash functions, fake digital
signatures, sandbox escapes, ... it goes on and on and each time you realise
that it's been wide open for ages, and whichever security researcher found it
could just as well have sold the exploit for lots of money instead.

Even as a fairly tech savvy guy I wouldn't actually know how to make a truly
secure computing environment short of putting the whole thing in a silent
Faraday cage and having metal detecting scans going in and out.

~~~
tptacek
The speculative execution stuff is fascinating and a little terrifying but,
_for the most part_ , has been of little practical impact so far, at least
after the first round of Meltdown/Spectre fixes.

Attacks on various hash functions are not really a thing. We've known not to
use SHA-1 for over a decade, and cryptographers working in the space have
started saying we may never find a viable preimage attack on MD5, let alone
SHA-1. We are on pretty sound footing with hash functions; what you were doing
in a competent system 10 years ago (using SHA-2) is still the right thing
today.

I've been a vulnerability researcher since around 1995. I feel significantly
better about security today than I have at any point in the past. We've been
doing an imperfect but steady job of shutting down bug classes for decades,
with the obvious and most important factor being the deprecation of insecure
systems languages.

~~~
senderista
I don't see C anywhere near being "deprecated" in general. Usage of
Rust/Zig/ATS/whatever is a rounding error by comparison to C/C++, even for new
projects. Anecdotally, I've been interviewing with a few startups building
ambitious infrastructure-level projects, and none of them are using Rust.
C/C++ is still the only game in town outside the HN bubble.

~~~
tptacek
If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises
aren't compatible, because I am talking about things like Java and Python. In
the 1990s and early 2000s, we were still building application code in C/C++.

~~~
senderista
Hmm, I had in mind the phrase “insecure systems languages”, but I don’t want
to get into a boring debate about what “systems languages” or “systems
programming” mean...

~~~
tptacek
It's at least as much my fault as yours, since I said "systems language" as a
shorthand for C/C++, not to describe the problem domain, and it's true that
the modern zero-cost-abstraction memory-safe languages that can displace the
last of the C/C++ code are very new. We'll be out of the era of C/C++ when a
mainstream browser is written in one of them.

~~~
pixelpoet
As I understand it, Firefox now has substantial parts written in Rust,
Mozilla's own language. Also, unless the OS and drivers are written in a
memory-safe language as well, that castle is to a degree built on sand.

~~~
vardump
> Also, unless the OS and drivers are written in a memory-safe language as
> well, that castle is to a degree built on sand.

You have to start from somewhere. There's Rust. I'd like to see some more
language (and tooling) competition with systems that can prove functionality
at compile time in practical situations.

Not impressed with current C/C++ static analysis landscape. I've used a ton of
static analysis for writing Windows kernel drivers for instance — from known
tools like Microsoft's Prefast (requires a ton of annotation, sigh!) to clang.
And others. And fuzzing on top.

But it still doesn't come anywhere near replacing a good pair of eyes and some
hard thinking. And I'm not talking about logic bugs here, but for example
concurrency and memory safety related issues. I've had plenty of "quality
time" (not!) with the kernel debugger...

I'm _very_ seriously considering to use Rust instead of C/C++ whenever I have
my next Windows (or other OS) kernel mode project. Even though some consider
it a bit unproven in this space. At this point, I don't feel like C/C++ is
proven either...

To a bit lesser degree, same for anything that touches untrusted inputs,
directly or indirectly. Even if you can sandbox it.

I do need to work around some issues with Rust. Like to learn how to minimize
code size for those situations where it is a constraint. Like device firmware.
However I feel that's easier than writing bulletproof C/C++ code.

~~~
pjmlp
Part of me would like to see .NET Native available on all levels of the stack,
but with WinDev vs DevTools politics, that is unfortunately just wishful
thinking.

------
LeonM
If this bug was discovered in a Huawei device we'd immediately call it a
backdoor and plea to ban all these devices from our critical infrastructures.

And yet, when Cisco has a security bug we patiently wait for the patch and
move on with our business.

~~~
layer4
I think Cisco’s [existing] reputation goes a long way

~~~
driverdan
Their reputation for security flaws like this and helping suppress human
rights by selling hardware to the Chinese government?

~~~
whatthesmack
Perhaps. But also their reputation for actually originating ideas and
technology (or legally acquiring them) instead of stealing swaths of
intellectual property like Huawei has and does.

------
bifrost
I've read through the description and now the whitepaper and I've got a few
takeaways.

1\. These attacks can't be carried out over the internet, you need local
access. Thats easier than you'd think with employees with unsecured
laptops/vms/etc.

2\. The exploit(s) appears to be RCE in the OS that runs on the device, but
not neccesarily translating into executing configuration commands on the
control plane. But its not a big leap to make configuration changes...

3\. The DoS case doesn't seem great either but also requires local access.

4\. The string format bug has the most entertainment value for me -> You can
spew CDP packets into a switch/device which potentially overwrite other
devices CDP data, which means you could potentially issue a poweroff or change
the name of said device.

5\. The phone vulnerability is good too -> If you can broadcast/spew CDP from
your host, you can be annoying to phones.

6\. The cameras can only be harassed by plugging directly into it, rendering
the vuln somewhat useless.

My takeaway is that you can't easily escalate vlan privileges via CDP which is
good, but you can def monkey with the controlplane and maybe someone will come
up with a way to change the IOS configuration.

~~~
fulafel
They can be carried over the internet: VPN vulnerabilities are pretty common,
eg [https://www.us-cert.gov/ncas/current-
activity/2019/07/26/vul...](https://www.us-cert.gov/ncas/current-
activity/2019/07/26/vulnerabilities-multiple-vpn-applications)

VPNs commonly bridge at layer 2, that's a direct path to pwnage in this case.

~~~
bifrost
You'd have to -

A: own the VPN endpoint (unlikely)

B: own a local laptop and bridge the network together (more likely), but
owning a local laptop is better than using a VPN.

~~~
fulafel
C: own the vpn gateway

I think A and C are somewhat "likely" threats roo.

------
ga-vu
They're not zero-days if they've been privately disclosed and patches are
available.

~~~
mitchs
I'd argue with most enterprise's upgrade cycle for this gear it is better than
a 0 day, it is a -5 to -3 year exploit.

------
kitteh
Security best practices have always recommended disabling CDP in an untrusted
environment (that applies to things like LLDP, too). It is comical to see how
many people leave both of those running on internet exchange points or
sometimes worse things (like ospf or isis). The general default on nature of
products to enable this is unfortunate.

~~~
fulafel
Security best practices have always recommended treating all networks as
untrusted and having non-internet-hardened stuff turned off by default in
network facing products. You're right of course too, but Cisco is the real bad
guy here.

~~~
kitteh
Eh, I know a lot of folks who do enable CDP/LLDP for internal device to
internal device links for discovery and troubleshooting. But they don't turn
it on any customer/external facing interfaces (this enforcement thru offline
config generation). So there can be a time and a place for it under the right
conditions provided you understand the security risks (possibility of someone
plugging something on an internal link, changing the router config
incorrectly).

------
jeffrallen
Nice reminder that fuzzing protocol decoders is a good plan. Also a nice time
to ask yourself if your last protocol decoding code should have been a
structured parser instead of a handmade hack.
[https://objectcomputing.com/resources/publications/sett/marc...](https://objectcomputing.com/resources/publications/sett/march-2016-protocol-
parsing-in-scala-part-i)

------
eternalny1
The NSA used to intercept Cisco routers in-transit to swap them out for back-
doored ones.

I'm sure they knew about these, that's the problem, the NSA "hoards" zero-days
instead of alerting the manufacturers.

And then we end up with nonsense like this, and you know half of these won't
be patched for years, if ever.

Tens of millions of Cisco devices.

~~~
yjftsjthsd-h
If they have a known exploit in the normal firmware, why bother MITMing
hardware in order to backdoor it?

~~~
eternalny1
They may not have known about these protocol flaws at the time they were
intercepting the physical devices.

Either that, or they were not vulnerable to these exploits at the time.

------
geocar
This doesn’t surprise me. I’ve avoided Cisco equipment since I wrote cdp-tools
over a decade ago. During development (reverse engineering) lots of things I
tried crashed switches and routers. No faith in anything Cisco makes after
that.

But lots of networks I was connected to learned my topology from CDP so I
needed to speak CDP...

------
crmrc114
Do we really need half of the features pre-installed on our cisco devices.
Like honestly- I really wish I could "tune" my ios firmware and remove things
I dont need so I could reduce my attack surface.

Since its not called out clearly in the title this affects cicso's LLDP
implementation as well [https://go.armis.com/hubfs/White-papers/Armis-CDPwn-
WP.pdf](https://go.armis.com/hubfs/White-papers/Armis-CDPwn-WP.pdf)

~~~
socceroos
That's what I was taught to do by my dad. Take the uncompiled kernel, remove
_every_ driver and feature from it that you don't use for your use-case and
then compile. Then go through hardening steps at each layer, chroot all the
things, tripwire, etc. Compile all applications configuring for only the
features you're going to use. Get a report on all versions and subscribe to
vulnerability mailing lists.

And then at the end, understand that you have a system that is still
vulnerable so set up a regular cadence of maintenance.

It's a bit harder to do these days for various reasons.

------
Scarbutt
Anything about all the other millions of devices(different brands) that
implement CDP?

------
walshemj
From my CCNA days I seem to recall that this protocol is a local one and would
require a break into another host on the network.

Though the diagram shows the core switch directly connected to the internet
instead of having an external router connect to the internet - which was the
design CISCO suggested back when in did my CCNMA evening class

~~~
keyme
The article does not suggest that devices can be attacked from the internet.
The threat is VLAN hopping or lateral movement. That illustration is
oversimplified.

~~~
bifrost
I read through it - it doesn't seem like VLAN hopping would really be possible
unless you can straight up get into the control plane and change the port
configuration. Thats at least 2-3 more steps from "RCE" basically.

------
Cyph0n
Damn, that’s a wide array of devices...

------
thatiscool
not a backdoor?

~~~
AdmiralAsshat
"Backdoor" usually implies the vulnerability was put in there intentionally.

~~~
dx87
They might be alluding to the fact that depending on who manufactures the
device, security vulnerabilities will be reported as a backdoor.

~~~
AdmiralAsshat
Admittedly I didn't read the whitepaper, but the CVEs that were mentioned on
the page summary sounded like your run-of-the-mill stack overflow or string
vulnerabilities. So yes, the end result might be the same (i.e. remote
takeover), but I would hesitate to call them backdoors unless it was
demonstrated that this vulnerability was intentionally known or left unfixed
for the purposes of being abused by parties in the know.

~~~
simion314
The idea if the same bug was in a Chinese product the title would have been
"backdoor injected" ... see yesterday and recent articles on HN.

~~~
IAmEveryone
I searched and only found something about a vulnerability in "HiSilicone"
hardware mentioned yesterday.

That article mentions a pre-installed telnet server including accounts that
can be started with the right command send over TCP. Whereas here, it's
apparently a typical buffer overflow resulting in arbitrary (but BYOT (bring
your own Telnet)) code execution.

Sure, maybe Cisco is just better at disguising their backdoors for plausible
deniability. But with what's known, intent seems far more likely in
yesterday's case than this.

~~~
simion314
The article title was different initially and was something that included
backdoor,injected,Huawei(was no direct relation with Huawei). There were also
many similar reports about US routes and IOT having default passwords or easy
to guess passwords but each time the stupidity is assumed. Also the Windows
"NSA key" article and comments were very convincing that for sure it was
nothing evil and was never used anyway.

------
gist
Represents most of what I hate about the 'security industrial complex'. Self
serving and to that point at the bottom of the page is a link saying:

'With the discovery of the CDPwn vulnerabilities, organizations from every
industry as well as governments are looking for a way to identify which of
their devices are impacted by these vulnerabilities. Armis offers a CDPwn Risk
Assessment to help organizations looking to understand their exposure.'

Then - 'Request a CDPWN threat assessment'.

~~~
miah_
My thoughts as well. I'm interested in hearing about new novel security
issues; I'm not interested in reading a advertisement. With widespread
deployment of IP Phones and the like, I think this is a interesting find. But
at the same time I wish I read about this on bugtraq.

~~~
drcross
Same. I'm a CCIE and after a five minute skim I can't tell if this is
grandstanding or an actual threat. Best practice is to disable CDP on all
eternal interfaces. This is a given.

~~~
Bluecobra
There's a funny name and a logo, so grandstanding.

