[nsp-sec] [TLP:RED] Possible IOS(-XR) SNMP security issue

[Smith, Donald]

Did you really mean RED?

Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting. In most circumstances, TLP:RED should be exchanged verbally or in person

So we can't share this beyond this list and its membership (at this time).
Your welcome to keep it that way, but suspect you wanted us to share internally (perhaps old TLP:AMBER internal only ...?)

Your also welcome to release any part of this under any sharing framework you define!! But currently I can't discuss this with my router or snmp teams.



if (initial_ttl!=255) then (rfc5082_compliant==0)
Donald.Smith at centurylink.com

________________________________________
From: nsp-security [nsp-security-bounces at puck.nether.net] on behalf of Chris Morrow [morrowc at ops-netman.net]
Sent: Friday, October 27, 2017 12:09 PM
To: Dominik Bay
Cc: 'nsp-security at puck.nether.net'
Subject: Re: [nsp-sec] [TLP:RED] Possible IOS(-XR) SNMP security issue

----------- nsp-security Confidential --------

At Fri, 27 Oct 2017 18:39:15 +0100,
Dominik Bay <db at rrbone.net> wrote:
>
> ----------- nsp-security Confidential --------
>
> THE FOLLOWING MESSAGE IS TLP RED
>
> Folks,
>
> we are currently seeing the following issue mentioned below.
> My description is deliberately vague in some points to protect the innocent.
>
> 1. Found a compromised server hosting (daily) varying dumps of (mostly)
> full IOS and IOS-XR PE and CE configurations (Internet connected
> equipment as far as I can tell)
>
> 2. Devices have proper SNMP and VTY ACLs, mostly average to strong
> passwords by judging clear text and decoded type 7 passwords

this DOES require RW community though, right? (or did you mean there's
a bug where you can do RW things when no RW is configured... which
would be horrid)

>
> Theory:
> - Attacker bypasses ACL by spoofing nearby IPs
> - Attacker uses bug in IOS(-XR) SNMP stack to trigger configuration
> up/download to device
> - Attacker uses information from config upload for further penetration
>
>
> >From config headers I see the following versions across devices:
>
> !! IOS XR Configuration 4.2.1
> !! IOS XR Configuration 4.2.4
>
> version 12.1
> version 12.2 (12.2(55)SE9 confirmed running on an affected device)
> version 12.3
> version 12.4
> version 15.0
> version 15.1
> version 15.2
> version 15.3
> version 15.4
> version 15.5
> version 15.6
> version 16.4
>
> If someone is seeing attacks on their infrastructure with known old or
> current SNMP communities please let me or your LEA know. We are trying
> to coordinate with German LEA on this matter and are providing them with
> a more conclusive report tomorrow.
>
> Cheers,
> Dominik
>
> --
> rrbone UG (haftungsbeschraenkt) - Ruhrallee 9 - 44139 Dortmund
> HR B 23168 Amtsgericht Dortmund - Geschaeftsfuehrer: Dominik Bay
>
>
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
>
> Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
> community. Confidentiality is essential for effective Internet security counter-measures.
> _______________________________________________


_______________________________________________
nsp-security mailing list
nsp-security at puck.nether.net
https://puck.nether.net/mailman/listinfo/nsp-security

Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
community. Confidentiality is essential for effective Internet security counter-measures.
_______________________________________________
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.