CISCO 0-day exploits

Tue Feb 11 07:09:37 UTC 2020

Disclaimer, I do not work for any vendor right now, and I don't sell any
product that might benefit from scaring anyone, so this is just some
whining for a real issue that someone needs to do something about.

I've worked for the CDP vendor for a long time, and I do concur to what
Saku is saying...the L3 packet of death [threat] is very real, and I'd like
to take this opportunity (the buzz around CDPwn) to say a thing or two
about these 'soft, mushy and vulnerable' code stacks we have running all
over the world, under our feet, waiting for someone with the right
incentive to take advantage of.

IMHO, "Skilled" software developers, and in parallel...'software
exploiters/reverse engineers' haven't been paying attention to these
'infrastructure' boxes (for now), maybe it is because they always had other
pieces of the technology stack to work with, and these other tech. stacks
were much more rewarding to spend time on (I'm quite sure Node.js /
Kubernetes for example...will have a lot more vulnerability researchers
looking at them than CDP/LLDP/SNMP....etc code). < and That is a serious
sustainability issue on our hands, the risk here is very high; when it
comes to infrastructure security of nations, especially in a world where
miscreants are no longer script kiddies but actual nation sponsored
soldiers...Even MBS is doing it in person.

Because the moment some miscreants from some oppressive regime decides to
do damage, and not necessarily remote code execution as many might think,
but more on the 'L3 packet of death' kind of situation that Saku mentioned
earlier, these miscreants have a lot to play with, and the attacks vector
is huge, it is green and it is ready for the ripe.

In my life time, I've looked at so many 'DDTS' descriptions, and I saw
nothing but an unwritten disclaimer of : 'I can be easily used for
DDoS'...and that is the case even if *SIRT did their brief analysis of
these bugs, so again, if some miscreants found it in themselves to look at
bugs with the right 'optics', we are going to be in an interesting
situation.

Luckily, we haven't seen a CDPwn/STPwn/BGPwn/NTPwn/*.*Pwn...etc
worm/ransomware yet, but we also don't have reason to think its not
possible, and to make matters worse, the code these babies are running is
ancient (in every possible way), many of the libraries used to develop that
code is glibc_ishy like in nature, and to make matters a bit more
interesting, patching those babies is not easy, and the nature of their
software architecture makes them even much more fragile than any piece of
cheap IP camera out there on the internet or on enterprise networks.

So yeah iACLs, CoPP and all sorts of basic precautions are needed, but I'm
thinking something more needs to be done, specially if these ancient code
stacks are being imported into new age 'IoT' devices, multiplying the
attack vector by a factor of too many.

~A

On Mon, Feb 10, 2020 at 5:42 AM Saku Ytti <saku at ytti.fi> wrote:

> On Mon, 10 Feb 2020 at 13:52, Jean | ddostest.me via NANOG
> <nanog at nanog.org> wrote:
>
> > I really thought that more Cisco devices were deployed among NANOG.
> >
> > I guess that these devices are not used anymore or maybe that I
> > understood wrong the severity of this CVE.
>
> Network devices are incredibly fragile and mostly work because no one
> is motivated to bring the infrastructure down. Getting any arbitrary
> vendor down if you have access to it on L2 is usually so easy you
> accidentally find ways to do it.
> There are various L3 packet of deaths where existing infra can be
> crashed with single packet, almost everyone has no or ridiculously
> broken iACL and control-plane protection, yet business does not seem
> to suffer from it.
>
> Probably lower availability if you do upgrade your devices just
> because there is a known issue, due to new production affecting
> issues.
>
> --
>   ++ytti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200210/a7f7f163/attachment.html>