topic Re: All signature alerts have backwards attacker and victim IPs in Network Security

All signature alerts have backwards attacker and victim IPs

jp.senior — Sun, 10 Mar 2019 12:45:18 GMT

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

All signature alerts have backwards attacker and victim IPs

Karsten Iwen — Fri, 17 Aug 2012 21:24:16 GMT

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

Re: All signature alerts have backwards attacker and victim IPs

jp.senior — Tue, 28 Aug 2012 14:53:27 GMT

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.

Re: All signature alerts have backwards attacker and victim IPs

Karsten Iwen — Tue, 28 Aug 2012 14:56:51 GMT

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

Re: All signature alerts have backwards attacker and victim IPs

jp.senior — Tue, 28 Aug 2012 15:01:23 GMT

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

Re: All signature alerts have backwards attacker and victim IPs

jp.senior — Tue, 28 Aug 2012 15:09:17 GMT

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

Re: All signature alerts have backwards attacker and victim IPs

nearchib — Thu, 06 Sep 2012 18:18:35 GMT

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

Re: All signature alerts have backwards attacker and victim IPs

jp.senior — Fri, 14 Sep 2012 15:24:28 GMT

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