S111 and Signature 3531 (Cisco Telnet DOS)

[pbobby]

Come on Cisco, please tell us the details of this signature.

I would be naive to say that all 'bleeding edge' signatures are accurate as opposed to cosmetic. Everyone races to provide signatures for the latest and greatest threats, but the details of this signature show me nothing. I can pursuade my management that we are protected from 0-day Cisco Telnet DOS attacks... 'cause they're stupid, but I know better.

SERVICE.GENERIC? What is this new category of signatures that aren't documented anywhere? 3531 and 3530 the only two signatures so far.

It's bad enough as it is that IDS does not fully protect your network, now we have to trust Cisco gets the signatures right? I myself have contributed trouble reports to bleeding-edge signatures, and saw them get patched with the next Sxxx update; will the same happen with this one?

SIGID: 3531 <protected>

SubSig: 0 <protected>

AlarmDelayTimer:

AlarmInterval:

AlarmSeverity: high <defaulted>

AlarmThrottle:

AlarmTraits:

CapturePacket: False <defaulted>

ChokeThreshold:

DesiredIpProtocol:

DstPort: 23 <defaulted>

Enabled: True <defaulted>

EventAction:

FlipAddr:

IntermediateInstructions: 0 <protected>

MaxInspectLength:

MaxTTL:

MinHits:

PayloadSource: L4header <defaulted>

Protocol: TCP <defaulted>

ResetAfterIdle: 15 <defaulted>

SigComment:

SigName: Cisco IOS Telnet DoS <protected>

SigStringInfo: Cisco IOS Telnet DoS <defaulted>

SigVersion: S111 <defaulted>

SrcPort:

StorageKey: AaBb <defaulted>

SummaryKey: Axxx <defaulted>

ThrottleInterval: 15 <defaulted>

WantFrag:

Bleeding-snort rule

alert tcp any any -> $HOME_NET 23 (msg:"BLEEDING-EDGE Cisco Telnet Buffer Overflow"; content:"|3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 3f 61 7e 20 25 25 25 25 25 58 58|"; flow:to_server,established; threshold:type limit, track by_src, count 1, seconds 120; reference:url,www.cisco.com/warp/public/707/cisco-sn-20040326-exploits.shtml; classtype:attempted-dos; sid:2000005; rev:1;)

Is this the same payload in your signature?

[pbobby]

Signature triggering on Chat Server connection attempts.

Attempts to port 23 on the internal Bantu chat server

[micballa]

If you are seeing false positives, we suggest you filter this signature down to just cisco devices. I will research this issue further, and a traffic sample will help us will help us.

Thank you,

Jason

[micballa]

Our internal product security team has not made public externally the exact details of the IOS telnet DOS. As per our legal policies, we cannot divulge more information about this vulnerability than PSIRT allows. Please visit http://www.cisco.com/go/psirt for more information regarding this policy and to view the security announcement that this signature relates to. However, we can definitively say that the snort signature that you have provided does not in fact detect the vulnerability in question.

thank you,

Jason

[pbobby]

Couple of issues here:

After enabling this new signature, I started receiving false positives right away. Does this not occur within your own testing environment?

I can provide traffic dumps if you like, I've done it before. Should I just accept this as par for the course when releasing signatures to handle barely released/understood issues? The DCOM issue had the same problem, granted it was not a Cisco product affected, but this is a Cisco Telnet DOS, wouldn't Cisco fully understand how to create an accurate signature for this one? If not, then document it in the Known Benign Triggers section of the nsdb entry.

"this signature fires when it detects what a packet that may cause the Cisco IOS Telnet DoS." is quoted directly from the nsdb page. I know I'm probably upsetting you guys, but it just indicates a rush to get the signature out to provide some level of confidence to your customers. And it's this that I am questioning.

I understand your reluctance to disclose actual exploit details for fear of hackers taking advantage, but that's always the risk. Your policy isn't going to change because of my little rant I understand, but my confidence in Cisco's ability to address 0day issues is not high because of situations exactly like this: brand new signatures triggering under false positive conditions and being kept closed as to their details.

[managed.security]

Hi...

I'm also very much interested in this discussion and following closely. One of my clients has unix telnet server which is triggering false positives. I'm eager to know if cisco has any updates

[mcerha]

Cisco has a general policy to provide the full details for every signature. In some extraordinary circumstances, we are bound legally and by policy to not disclose the explicit workings of a signature. This does present the obvious problem of when a signature like this is misbehaving. In this particular case, I can confirm that we are seeing the problem internally and are working on a solution. The implementation for this signature is using a specialized protocol decoder which may have a miconfiguration or bug issue. Once we have a viable solution, we will publish a new signature update. I apologize for any inconvenience this may have caused and thank you for your feedback.