cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1960
Views
0
Helpful
7
Replies

All signature alerts have backwards attacker and victim IPs

jp.senior
Level 1
Level 1

Hi, all.

Using IPS S661 and 7.0.7(E4) and AIP-SSM in a few locations, most if not all of the signatures for attacker and victim are completely backwards.

Should I have turned the IPS on in an active mode it would have shunned critical infrastructure hosts, web proxy appliances, etc.

What is the best way for the IPS to know what we consider 'inside' and 'outside' ?           

Modifying individual signatures isn't an acceptable option as I can't possibly modify each and every single one.

Regards,

-JP

7 Replies 7

Are you really talking about the "Attacker" and "Victim" or do you talk about the "Location"?

The first should be fine for most build-in signatures. The Location is controlled by your configuration there you can "name" your networks and these names are displayed together with the attacker and the victim.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

Thank you for your reply, Karsten.

I mean specifically 'attacker' and 'victim' in all of the alert settings. If the IPS should decide to shun an "attacker" host (deny-attacker-inline action), it would block my trusted hosts, not the exploited website out in the wild.

That's really strange. Please enable a verbose alert on a signature that you know to fail (and that won't have sensitive content) and show the log-message of the event.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

Here's one that just came in 5 minutes ago.

192.168.1.15 is an example IP of an internal host being served with a malicious cookie from 203.0.113.13.   If the deny-attacker-inline or shun command fired, it would have blocked the internal host, not the actual IP originating the attack.

8/28/2012 8:55 AM : CISCO-CIDS-MIB:ciscoCidsAlert  SNMP Trap

     Received Time:8/28/2012 8:55:25 AM

     Source:127.0.0.1(SITE-IPS)

     Community:snip!

     Variable Bindings

          sysUpTime:= 12 days 18 hours 53 minutes 48.73 seconds (110482873)

          snmpTrapOID:= CISCO-CIDS-MIB:ciscoCidsAlert (1.3.6.1.4.1.9.9.383.0.1)

          cidsGeneralEventId:= 1355060886281233658

          cidsGeneralLocalTime:= 8/28/2012 9:55:25 AM

          cidsGeneralUTCTime:= 8/28/2012 2:55:25 PM

          cidsGeneralOriginatorHostId:= SITE-IPS2

          cidsAlertSeverity:= high

          cidsAlertAlarmTraits:= 2147483648

          cidsAlertSignature:= Crafted Session Cookie Value

          cidsAlertSignatureSigName:= RhinoSoft Serv-U TEA Decoding Buffer Overflow

          cidsAlertSignatureSigId:= 22839

          cidsAlertSignatureSubSigId:= 0

          cidsAlertSignatureVersion:= S458

          cidsAlertInterfaceGroup:= 0

          cidsAlertVlan:= 0

          cidsAlertAttackerContext:= ZUNsaWVudElEPTAmcGFyZW50RG9jSWQ9ZjBlNzExNzgtODkyMy1hODE1LTFk

MGMtZDQ2NjI3OGZjNmU5JnRpbWVzdGFtcD0wJm9yaWdpbklzVGVtcGxhdGU9

MCZ1c2VyPSZleHRyYV9tc2c9ZWRpdG9yU3RhcnRlZCBIVFRQLzEuMQ0KQWNj

ZQ==

          cidsAlertAttackerAddress:= 192.168.1.15:58127

          cidsAlertVictimAddress:= osIdSource="unknown" osRelevance="unknown" osType="unknown" 203.0.113.13:80

          cidsAlertDetails:= InterfaceAttributes:  context="single_vf" physical="Unknown" backplane="GigabitEthernet0/1" ;

          cidsAlertEventRiskRating:= 70

          cidsAlert.26:= 3

          cidsAlert.27:= 6

          cidsAlert.42:= 70

Here's output from the show events on the IPS itself. Previous was from an SNMP trap I had configured.

The IPS identifies locality as an object I have already defined previously.

evIdsAlert: eventId=1355060886281233658 severity=high vendor=Cisco alarmTraits=2147483648

  originator:

    hostId: SITE-IPS2

    appName: sensorApp

    appInstanceId: 460

  time: 2012/08/28 14:55:25 2012/08/28 09:55:25 GMT-05:00

  signature: description=RhinoSoft Serv-U TEA Decoding Buffer Overflow id=22839 created=20100105 type=vulnerability version=S458

    subsigId: 0

    sigDetails: Crafted Session Cookie Value

    marsCategory: Penetrate/BufferOverflow/Web

  interfaceGroup: vs0

  vlan: 0

  participants:

    attacker:

      addr: locality=PROXYOBJECT 192.168.1.13

      port: 58127

    target:

      addr: locality=OUT 203.0.113.13

      port: 80

      os: idSource=unknown relevance=unknown type=unknown

  actions:

    snmpTrapRequested: true

  context:

    fromAttacker:

000000  65 43 6C 69 65 6E 74 49  44 3D 30 26 70 61 72 65  eClientID=0&pare

000010  6E 74 44 6F 63 49 64 3D  66 30 65 37 31 31 37 38  ntDocId=f0e71178

000020  2D 38 39 32 33 2D 61 38  31 35 2D 31 64 30 63 2D  -8923-a815-1d0c-

000030  64 34 36 36 32 37 38 66  63 36 65 39 26 74 69 6D  d466278fc6e9&tim

000040  65 73 74 61 6D 70 3D 30  26 6F 72 69 67 69 6E 49  estamp=0&originI

000050  73 54 65 6D 70 6C 61 74  65 3D 30 26 75 73 65 72  sTemplate=0&user

000060  3D 26 65 78 74 72 61 5F  6D 73 67 3D 65 64 69 74  =&extra_msg=edit

000070  6F 72 53 74 61 72 74 65  64 20 48 54 54 50 2F 31  orStarted HTTP/1

000080  2E 31 0D 0A 41 63 63 65                           .1..Acce

  alertDetails: InterfaceAttributes:  context="single_vf" physical="Unknown" backplane="GigabitEthernet0/1" ;

  riskRatingValue: targetValueRating=medium 70

  threatRatingValue: 70

  interface: backplane=GigabitEthernet0/1 context=single_vf physical=Unknown GigabitEthernet0/1

  protocol: tcp

Hi jp.senior,

The signature "RhinoSoft Serv-U TEA Decoding Buffer Overflow" seems to have the correct value for swap-attacker-victim set.

As you can see from the context buffer, the victim port is 80 (the webserver) which is exploited via a large Cookie: value from the client (attacker).

Maybe i'm misunderstanding the issue?

Regards

Neil Archibad

Cisco IPS Signature Development Team

Thanks for your reply Neil!

I'm still not sure - I did some more packet captures on that sort of event.  The internet server gave the cookie to the inside PC on my network. My PC did not craft a malicious cookie.

Another example can be found here - windows media player network sharing service.  The client PC at the address below is clean and free of any discernable malware.  Only when we visit the website captured does this remote execution alert come up.

I cannot find any exceptions anywhere in that the attacker and victim IP addresses are correct.  I've properly specified locality but it seems like the IPS just doesn't care.  Again, if I enabled shunning/blocking, reams of trusted inside source IP addresses would be blocked when the client/victim pair is totally backwards.

evIdsAlert: eventId=1332568783191289629 severity=high vendor=Cisco alarmTraits=2147483648

  originator:

    hostId: cal-ips1

    appName: sensorApp

    appInstanceId: 457

  time: 2012/09/14 15:09:41 2012/09/14 09:09:41 GMT-07:00

  signature: description=Windows Media Player Network Sharing Service Remote Code Execution id=30459 created=20101011 type=vulnerability version=S519

    subsigId: 0

    sigDetails: CVE-2010-3225

    marsCategory: Penetrate/RemoteCmdExec/Misc

  interfaceGroup: vs0

  vlan: 0

  participants:

    attacker:

      addr: locality=grp-LAN 172.16.7.21

      port: 51446

    target:

      addr: locality=OUT 204.188.138.127

      port: 554

      os: idSource=unknown relevance=unknown type=unknown

  actions:

    snmpTrapRequested: true

  alertDetails: InterfaceAttributes:  context="single_vf" physical="Unknown" backplane="GigabitEthernet0/1" ; Component Signature List: 30459.1 30459.2  ;

  riskRatingValue: targetValueRating=medium 75

  threatRatingValue: 75

  interface: backplane=GigabitEthernet0/1 context=single_vf physical=Unknown GigabitEthernet0/1

  protocol: tcp

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card