False Positives for id=12713 version=S149

Just started receiving numerous firings of 12713. Looks like false positives. Is anyone else observing this?
Cisco MARS is creating the following : System Rule: DoS: Network - Success Likely
thanks
John Stark

This is indeed a false positive. You can either filter out trusted hosts or create a metasignature using this signature as a component to reduce the chance of false positives.
Tune signature 3327-6 and remove the produce alert action.
Create a custom signature as follows:
Engine Meta
Component list:
3327-6
3328-0
Meta-reset-interval = 2
Severity high
Summarize
Met-key = Axxx – 1 unique victim
Component-list-in order = false
Event action: produce alert
This signature will only fire when signatures 3327-6 and 3328-0 fire. Since 3327-6 would have no event action of its own you would not see alerts from it.
Note that this signature does not have as high fidelity as the original 3327-6, that being said signature 3327-0 detects almost all public exploits for this vulnerability. We will note this in the NSDB.

Similar Messages

  • False positive for Windows RPC DCOM Overflow id=3327 version=S188

    Hi,
    Could you take a look at the below capture to see if there is false positive at work.
    Thanks,
    Matt
    signature: description=Windows RPC DCOM Overflow id=3327 version=S188
    subsigId: 6
    sigDetails: \\\x3c400 chars>\
    interfaceGroup:
    vlan: 0
    participants:
    attacker:
    addr: locality=INTERNAL <address removed>
    port: 1914
    target:
    addr: locality=INTERNAL <address removed>
    port: 445
    context:
    fromTarget:
    000000 63 00 5F 00 66 00 73 00 2E 00 6E 00 6F 00 72 00 c._.f.s...n.o.r.
    000010 74 00 68 00 62 00 61 00 79 00 62 00 61 00 6E 00 t.h.b.a.y.b.a.n.
    000020 63 00 6F 00 72 00 70 00 2E 00 63 00 6F 00 6D 00 c.o.r.p...c.o.m.
    000030 00 00 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 ....W.i.n.d.o.w.
    000040 73 00 20 00 35 00 2E 00 30 00 00 00 57 00 69 00 s. .5...0...W.i.
    000050 6E 00 64 00 6F 00 77 00 73 00 20 00 32 00 30 00 n.d.o.w.s. .2.0.
    000060 30 00 30 00 20 00 4C 00 41 00 4E 00 20 00 4D 00 0.0. .L.A.N. .M.
    000070 61 00 6E 00 61 00 67 00 65 00 72 00 00 00 00 00 a.n.a.g.e.r.....
    000080 00 7E FF 53 4D 42 73 00 00 00 00 98 07 C8 00 00 .~.SMBs.........
    000090 00 00 00 00 00 00 00 00 00 00 00 00 FF FE 00 48 ...............H
    0000A0 C0 3E 04 FF 00 7E 00 00 00 09 00 53 00 A1 07 30 .>...~.....S...0
    0000B0 05 A0 03 0A 01 00 57 00 69 00 6E 00 64 00 6F 00 ......W.i.n.d.o.
    0000C0 77 00 73 00 20 00 35 00 2E 00 30 00 00 00 57 00 w.s. .5...0...W.
    0000D0 69 00 6E 00 64 00 6F 00 77 00 73 00 20 00 32 00 i.n.d.o.w.s. .2.
    0000E0 30 00 30 00 30 00 20 00 4C 00 41 00 4E 00 20 00 0.0.0. .L.A.N. .
    0000F0 4D 00 61 00 6E 00 61 00 67 00 65 00 72 00 00 00 M.a.n.a.g.e.r...
    fromAttacker:
    000000 00 04 41 32 00 01 00 00 00 00 00 71 00 00 00 00 ..A2.......q....
    000010 00 D4 00 00 80 B9 00 A1 6F 30 6D A2 6B 04 69 4E ........o0m.k.iN
    000020 54 4C 4D 53 53 50 00 03 00 00 00 01 00 01 00 58 TLMSSP.........X
    000030 00 00 00 00 00 00 00 59 00 00 00 00 00 00 00 48 .......Y.......H
    000040 00 00 00 00 00 00 00 48 00 00 00 10 00 10 00 48 .......H.......H
    000050 00 00 00 10 00 10 00 59 00 00 00 15 8A 88 E2 05 .......Y........
    000060 00 93 08 00 00 00 0F 47 00 57 00 2D 00 30 00 30 .......G.W.-.0.0
    000070 00 32 00 38 00 37 00 00 46 5A 5E 7D 09 B9 25 FB .2.8.7..FZ^}..%.
    000080 EF 1F 07 DE BD 60 85 13 57 00 69 00 6E 00 64 00 .....`..W.i.n.d.
    000090 6F 00 77 00 73 00 20 00 32 00 30 00 30 00 30 00 o.w.s. .2.0.0.0.
    0000A0 20 00 32 00 31 00 39 00 35 00 00 00 57 00 69 00 .2.1.9.5...W.i.
    0000B0 6E 00 64 00 6F 00 77 00 73 00 20 00 32 00 30 00 n.d.o.w.s. .2.0.
    0000C0 30 00 30 00 20 00 35 00 2E 00 30 00 00 00 00 00 0.0. .5...0.....
    0000D0 00 00 00 58 FF 53 4D 42 75 00 00 00 00 18 07 C8 ...X.SMBu.......
    0000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FE ................
    0000F0 00 48 00 3F 04 FF 00 58 00 08 00 01 00 2D 00 00 .H.?...X.....-..

    This is indeed a false positive. You can either filter out trusted hosts or create a metasignature using this signature as a component to reduce the chance of false positives.
    Tune signature 3327-6 and remove the produce alert action.
    Create a custom signature as follows:
    Engine Meta
    Component list:
    3327-6
    3328-0
    Meta-reset-interval = 2
    Severity high
    Summarize
    Met-key = Axxx – 1 unique victim
    Component-list-in order = false
    Event action: produce alert
    This signature will only fire when signatures 3327-6 and 3328-0 fire. Since 3327-6 would have no event action of its own you would not see alerts from it.
    Note that this signature does not have as high fidelity as the original 3327-6, that being said signature 3327-0 detects almost all public exploits for this vulnerability. We will note this in the NSDB.

  • The Accessibility Object for AS2 is returning a false positive for AS2 with IE10 on Windows 8 Pro.

    There is an issue with the our legacy content player, which is written in Flash Actionscript 1 & 2.  This
    player behaves fine in most browsers on most platforms, but in IE10 on Windows 8 it doesn't work
    properly.
    Internet Explorer 110
    Version:  10.0.9200.16688
    Update Version:  10.0.9 (KB2870699)
    Windows 8 Pro
    This seems to because of the Flash engine's Accessibility object using the Microsoft Active
    Accessibility (MSAA) API to detect the presence of Screen Readers.  This detection is creating a false
    positive on Windows 8 machines and that may be due to the touch screen support on that platform.  This
    doesn't appear to be occuring with Chrome or Firefox on the same platform; however.  So I suspect that
    IE or IE's Flash compenent is doing something different than these other browsers.

    This is legacy code and is too close to its end-of-life to justify porting to AS3.  As far as a work-around I am already looking into it. I was hoping that someone had already encountered this issue and created a work-around.  This would have saved time.
    Any other takers?

  • False positive for GNU Bash Remote Code Execution Vulnerabil​ity

    Dear Team, 
    in my customer, one of banking in brunei want to access several finance website such as www.iifm.net etc. Tipping point IPS blokec to access the website with report as a 16800: TCP: GNU Bash Remote Code Execution Vulnerability ( Low Severity). The site is normal and legal website. Our question is the several website is needed to access by our employee due to the dailiy working. Please advice 
    Best Regards
    Yudi

    Hello Yuibagan,
    This is the Consumer products forum.
    You need to be in the HP Enterprise Business Community for IT related issues for servers, etc.
    I think you will want to post this question in the Security section. Dont post the same question more than once as you did here.
    HP Networking
    You will also want to take a look at the Articles and updates explaining GNU Bash here:
    GNU Bash vulnerability "Shellshock" (CVE-2014-6271... - HP Enterprise Business Community
    HP Security Research: GNU Bash vulnerability "Shel... - HP Enterprise Business Community
    HP AppDefender and HP WebInspect updates: GNU Bash... - HP Enterprise Business Community
    HPSR Software Security Content 2014 Update 3 - HP Enterprise Business Community
    Good luck

  • False positive for 16800: TCP: GNU Bash Remote Code Execution Vulnerability

    Dear Team, 
    in my customer, one of banking in brunei want to access several finance website such as www.iifm.net etc. Tipping point IPS blokec to access the website with report as a 16800: TCP: GNU Bash Remote Code Execution Vulnerability ( Low Severity). The site is normal and legal website. Our question is the several website is needed to access by our employee due to the dailiy working. Please advice 
    Best Regards
    Yudi

    @yuibagan 
    ‎Thank you for using HP Support Forum. I have brought your issue to the appropriate team within HP. They will likely request information from you in order to look up your case details or product serial number. Please look for a private message from an identified HP contact. Additionally, keep in mind not to publicly post ( serial numbers and case details).
    If you are unfamiliar with the Forum's private messaging please click here to learn more.
    Thank you,
    Omar
    I Work for HP

  • TCP Hijack/TCP Segment Overwrite false positives?

    Hello all,
    I was just curious if anyone else has had many false positives with 3 signatures in particular: TCP Hijack (3250.0 - High), TCP Hijack Simplex Mode (3251.0 - High), and TCP Segment Overwrite (1300.0 - High). The reason I think they are false positives is because they occur everyday, and I've also seem them caused by internal network traffic that crosses an IPS sensor (that is, making the potentially dangerous assumption that the internal devices can be trusted). We usually see between a dozen and 3 dozen a day depending on the signature, and we have 8 IPS total deployed internally and on the perimeters.
    Has anyone else had similar experiences? If so, do you have any suggestions on how to decrease the number of false positives for these alerts?
    Thanks,
    Ryan

    I get TCP Hijack and TCP Segment Overwrite all the time. I opened a TAC case about it because it was getting out of hand, and the engineer said that TCP Hijack would be very very hard to execute and if it is getting fired a lot odds are it is a false positive.
    This was his response:
    5769 - Malformed HTTP Request
    This signature basically just looks for traffic destined to one of your web ports (defined by the WEBPORTS variable) and containing a valid HTTP request (i.e., GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT) but followed by malformed (i.e., not proper http protocol syntax) URI information. This type of malformed HTTP request can be used for a variety of exploits. Microsoft has malformed HTTP request vulnerabilities, another attack known as "http request smuggling" can be launched using malformed HTTP requests at a Squid web proxy, which may cause the web proxy and an upstream HTTP agent to disagree on the boundary between HTTP requests on a persistent connection. These are a couple of examples.
    If you open this signature in IDM and go to "Edit", you can see the regex it looks for within the http payload. Basically, it looks for a valid HTTP request followed by the hex code regex [\x20][\x21-\x7e]+[\x20]?[\x0d\x0a]. A properly formed HTTP request should not contain this hex code.
    It's possible that normal traffic could cause this, but unlikely. If you have further concerns about this signature firing, please capture the trigger packet context either by changing the signature action to 'produce verbose alert' or 'log attacker packet' for analysis. If you need assistance in analyzing these alerts, please contact TAC and open a case on this issue.
    3250 or 3251 - TCP Hijack and TCP Hijack Simplex Mode
    This signature detects attempts to insert packets into a TCP stream by an attacker in an effort to take over this session. However, if you're using inline ips mode, TCP Hijack attacks are impossible. Also, this type of attack is very rare and not easy to do, and is often a false positive. Types of things that can be used by network sniffers to detect that a TCP hijack may be happening is looking for repeated ARP updates, frames sent between client and server with different MAC addresses, or tcp ack storms.
    For these two hijack signatures, per MySDN information:
    "This signature fires upon detecting out of order ack packets. The most common network event that may trigger this signature is an idle telnet session. The TCP Hijack attack is a low-probability, high level-of-effort event."
    Thus, very likely to be false positives and unlikely to be a legitimate attack given the difficulties involved in doing this. However, it's worth checking out the source / destination of the attacks. Again though, if you are running inline mode, these attacks are impossible and you can ignore these signatures.
    About the TCP Segment Overwrite, mine is always fired for port 20 traffic from some sort of web cache server. Is that the same for you?

  • False positive KB2478662 after Server Cleanup Wizard

    This morning WSUS gave me false positives for several clients.  I've seen FPs before, but I've never discovered what causes them.  In fact, I'm finding it hard to even ask a useful question.
    On Friday I ran the WSUS Cleanup Wizard.  On Monday I found that our Server 2008 R2 box and all but two of our Windows 7 boxes report as needing .NET update KB2478662 - a long-superseded update from 2011.
    I ran "wmic qfe list" to learn that neither KB2478662 nor its two superseding patches (KB2633873 and KB2539635) were installed on any of the unhappy clients.  However, KB2972100 supersedes KB2633873 and KB2539635 (but not the earlier KB2478662),
    and is installed on all the clients involved.  KB2972100 is not listed as superseding KB2478662, the earliest in the chain, so it appears this sort of leapfrogging supersession may not be detected well by WSUS.
    However: KB2972100 was installed two months ago, and KB2478662 didn't show before Friday; according to the Microsoft Catalog, none of the update packages has been updated recently; and I'm not finding reports from other admins of the ghost of KB2478662 emerging
    from the shadows.  I can only assume that running the Cleanup Wizard Friday somehow left WSUS in a state where this false positive could result.
    Like I said, I can't decide what question to ask.  Am I likely correct in blaming the Cleanup Wizard?  If so, is there some way of cleaning up after the wizard?  Or of preventing this sort of false positive in the first place?  Or is there
    some other common cause for this sort of FP?
    I seem to get two or three of these FPs a year, and I always end up researching the chain of superseding updates, manually scanning clients until I'm sure the latest update is really in place - and then I decline the false positive.  But I'd love to know
    a better way to handle these, or to avoid them.

    so I don't have a years-long database of approved updates.
    That remains to be seen. It only takes one hour of overambitious update approvals to generate five years of content on a WSUS server. :-)
    KB2478662 has never appeared before
    KB2478662 is an update contained in MS11-039 and has existed since June, 2011. If your WSUS server is only a couple of months old, I'm pretty confident in stating that KB2478662 was part of your original synchronization. KB247862 (MS11-039) is not a superseded
    update.
    It's much more likely that you just did not notice it before.. but it's always been there.
    (as I noted, KB2972100 was broadly installed in October) and has never had any approvals at all.
    I can't speak to the question of approvals, but if it was broadly installed, then I'd guess that  happened before you deployed this WSUS server and those updates were installed as a result of Automatic Updates. Given that it was released on Oct 14th,
    that makes perfect sense.
    I've never had the opportunity to decline it, because it's never appeared as "needed".
    Those two statements are totally noncongruent. You don't decline an update because it is or is not needed, or was or was not ever reported as needed, you decline an update because it will **NEVER** be needed again at all.
    None of the four updates I mention came out since I installed WSUS.
    Correct, but not really relevant.
    KB2478662 (MS11-039, Jun 2011) - already explained. NOT superseded, except for ITANIUM systems, which was superseded by MS11-069.
    KB2539635 (MS11-069, Aug 2011) - SUPERSEDED by KB2633873 (MS12-016, Feb 2012), KB2604115 (MS12-035, May 2012), KB2729452 (MS12-074, Nov 2012), KB2742599 (MS13-004, Jan 2013), and KB2972100 (MS14-057, Oct 2014).
    KB2633873 (MS12-016, Feb 2012) - SUPERSEDED by KB2604115 (MS12-035, May 2012), KB2729452 (MS12-074, Nov 2012), KB2742599 (MS13-004, Jan 2013), and KB2972100 (MS14-057, Oct 2014).
    KB2972100 (MS14-057, Oct 2014) - The *CURRENT* update.
    So since they all came out before you installed WSUS that means that ALL of them were ON your server the day you installed it, and TWO of them were relevant from Day One. The other two should have been immediately declined if KB2972100 was reported as 100%
    NotApplicable.
    If WSUS thinks KB2478662 is superseded, I have no idea why the Cleanup Wizard hasn't already handled it.
    There's no "think" about it. Either the update is superseded, or it is not, and whether it's superseded and what supersedes it and what it supersedes is displayed in the Update Details in the WSUS console. One need only read the screen to get the
    facts. In this case KB2478662 is NOT superseded (unless you have an Itanium server), and nothing "thinks" that it is (except you).
    As for why the Server Cleanup Wizard hasn't dealt with it, one need only understand what the Server Cleanup Wizard DOES do with superseded updates. Superseded updates are declined *IF* (and only IF):
    The update is superseded and has not been approved for at least 30 days.
    The update is superseded and not needed by any client systems or downstream servers.
    The update is superseded and the superseding update is APPROVED.
    So... the ITANIUM instance of KB2478662 will not be handled by the Server Cleanup Wizard, because you have likely not approved any ITANIUM updates that supersede it. And the other instances of KB2478662 will not be handled by the Server Cleanup Wizard because
    they are not superseded.
    So, back to your original message.
    KB2478662 WILL be "Needed" on any system where it is NOT installed, because this update is NOT superseded. Your original premise that this update is superseded is the root of all confusion.
    Furthermore, neither KB2633873 nor KB2539635 superseded that package, but they are superseded by a newer update (KB2972100) which predates the existence of your WSUS server, so the presence of KB2972100 and the absence of BK2633873 and KB2539635 is 100%
    normal and expected.
    You were correct in noting that KB2972100 does not supersede KB2478662, but that's the point at which your logic broke down and asking yourself how 'D' supersedes 'C' and 'B', and 'C' and 'B' supersede 'A', but 'D' does not supersede 'A' might have led to
    a re-evaluation of your conclusions.
    Ergo... there are *NO* false positives. What is reported is FACTUAL.
    HINT: (I've written this over a hundred times in the past five years).... The question you should be asking in such situations is NOT "What's wrong with the update?", but rather "What's wrong with the client?" or "What's wrong with
    my analysis?" The WUA evaluates applicability based on a defined set of rules, and reports the update status to the WSUS server based on the evaluation of those rules. If the update is more than a week old.. I absolutely PROMISE you that there is *NOTHING*
    wrong with the detection logic in that update and you need to focus your investigation on things other than the updates.
    As for how to handle superseded updates and update approvals, you may find some benefit from this article:
    Removing unneeded update approvals
    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

  • Re-injecting messages into mail stream for delivery (false positives from /

    I'm looking for pointers on how to deal with false positives, messages that have been moved to the '/var/virusmails' directory by Amavisd-new.
    How do I complete the delivery of a message to the originally intended recipient.

    Gino,
    Yes, updating to 2.3.0 is a solution.
    However, in order to "release" a message you first need to know it was a false positive. The procedure would probably looks something like this:
    -User contacts you saying he didn't get an e-mail he was expecting
    -You ask who the sender was
    -You uncompress and "grep" the quarantine directory or browse mail.log to find out which file contains the message in question.
    -You "release" the message
    I believe using a mailbox for quarantining is probably more user friendly, but as you rightly said, amavisd-release will do.
    Upgrading amavisd is not very difficult. Just make sure you exchange your amavisd.conf file with the new one that comes with 2.4.x
    You also may have to modify amavisd and set $daemonize=0 so that it works properly on OS X.
    Alex

  • How can you distinguish a 'false positive'?

    The IPS generated an alert, SMB Remote Registry Access Attempt. How to investigate the alert? I ran a couple of spyware programs on the host and found some cookies-generaly clean. At what point is the alert resigned as a false positive?
    “Triggers when a client attempts to access the registry on the Windows server. Microsoft tools like REGEDIT provide the ability to access a servers registry over the network. There are several hacking tools that also provide similar capabilities. Every attempted access will cause an alarm to be sent. An attacker can cause serious damage to a computer system by changing the registry.”
    appInstanceId: 403
    signature: description=SMB Remote Registry Access Attempt id=5579 version=S264
    subsigId: 1
    marsCategory: Probe/Host/WinRegistry

    You should start by looking for documented benign triggers:
    https://intellishield.cisco.com/security/alertmanager/ipsSignature?signatureId=5579&signatureSubId=0
    In this case, the benign triggers should tell you what you need to know.

  • Persistent, chronic, false alarms for the past eight months

    We now have two installations that utilize a unified wireless (WLC or WiSM - AIR-LAP1131AG, AIR-LAP1231G, AIR-LAP1242AG access points) that have been exhibiting the following IDS false alarms:
    Disassoc Flood
    AP Impersonation
    We have TAC cases going back to October 2006 to address them and have upgraded to the latest/greatest version 4.0.206.0 in hopes of getting this solved.
    Version 4.0.206.0 was supposed to have fixed these problems, and it did reduce some of the other false alarms (not listed). However, the two mentioned above persist.
    Is anyone else out there experiencing this?
    - John

    Thank you for confirming this behavior.
    In answer to your question, upgrading to 4.0.206.0 did get rid of the "Generic Netstumbler" IDS alarm that turned out to be another false positive.
    As it turns out, there have been comments from Cisco that now indicate that .206 has stability issues (nice to know that now). However, we have not experienced any of these issues at the two installations where this version is operating.
    I also wanted to point out that we went ahead and opened TAC cases for each error at each customer site.
    Currently, most of them have reached a status of "Release Pending". (Now as to *WHICH* release....)
    If you have not opened a TAC case for these issues, taking the time to do so will help Cisco be aware of the extent to which this problem exists in the field and, hopefully, will help them prioritize the fix to this problem.
    John

  • Comparing documents and false positives

    Hello,
    I often have to send a proof of a book to a printer. The proof is a PDF. When they return a soft proof--another PDF that they will use to print--I need to quickly compare the two to make sure that there have been no changes in the text.
    The Compare Documents feature certainly beats a side-by-side eyeball scan. But I often get a lot of false positives, words are flagged that actually have not changed.
    It appears that my PDF, exported from InDesign has some hidden discretionary hyphens. In ID these are used to make sure a word breaks at the end of the line at the correct syllable. They are invisible when printed. In a PDF these are not necessary because the text ain't gonna reflow, right?
    But when I compare the soft proof to the original PDF, words with discretionary hyphens are flagged. Somehow the printer has stripped the discretionary hyphens. That's fine but what must I do to get rid of them in my PDF?
    Below is an example. The PDF shown is the one from the printer. The comment box shows the difference from the original PDF, though there is in fact no difference on the page.
    Any advice would be appreciated.
    Tom

    I like Acrobat's text comparisons, which have saved me from bad goofs several times -- mostly stray key-strokes, but once I caught an InDesign footnote numbering snafu.  However, the false positives have always been annoying even without flagging every single discretionary hyphen.
    I imagine you have tried the image method for comparisons, a modern version of the old trick of putting printouts of the old and new versions of a page on a light table to find differences.
    I don't recall seeing comments of the type "undefined", but does re-sorting comments by type at least isolate these so you can step through the rest?  I'm no scripter, but can a javascript mark or eliminate comments containing hyphens?
    More drastic, would it be worth trying to eliminate the discretionary hyphens?  For instance, you could apply Harb's "Freeze Composition" in InDesign, and then search-and-replace all discretionary hyphens.  (Read the comments on the In-Tools site, as well as those in the InDesignSecrets blog it links to because you might want to modify the way it handles hyphens.)
    Good luck!
    David

  • Possible false positive issue with SigID 3353

    Here is a packet captured by the IDS that triggered SigID 3353 - SMB Request Overflow
    evAlert: eventId=1075708170032493259 severity=high
    originator:
    hostId: cisco-ids-v4.1
    appName: sensorApp
    appInstanceId: 1134
    time: 2005/07/18 14:53:30 2005/07/18 14:53:30 UTC
    interfaceGroup: 0
    vlan: 0
    signature: sigId=3353 sigName=SMB Request Overflow subSigId=0 version=S180 Malformed SMB Request
    context:
    fromVictim:
    000000 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000010 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000020 01 00 00 00 00 00 00 00 00 00 00 68 FF 53 4D 42 ...........h.SMB
    000030 25 00 00 00 00 98 07 C8 00 00 00 00 00 00 00 00 %...............
    000040 00 00 00 00 00 50 78 07 01 90 81 0C 0A 00 00 30 .....Px........0
    000050 00 00 00 00 00 38 00 00 00 30 00 38 00 00 00 00 .....8...0.8....
    000060 00 31 00 2C 05 00 02 03 10 00 00 00 30 00 00 00 .1.,........0...
    000070 0A 00 00 00 18 00 00 00 00 00 00 00 00 00 00 00 ................
    000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    000090 00 00 00 00 00 00 00 68 FF 53 4D 42 25 00 00 00 .......h.SMB%...
    0000A0 00 98 07 C8 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0000B0 00 50 78 07 01 90 C1 0C 0A 00 00 30 00 00 00 00 .Px........0....
    0000C0 00 38 00 00 00 30 00 38 00 00 00 00 00 31 00 2C .8...0.8.....1.,
    0000D0 05 00 02 03 10 00 00 00 30 00 00 00 0B 00 00 00 ........0.......
    0000E0 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    fromAttacker:
    000000 00 00 00 00 00 54 00 2C 00 54 00 02 00 26 00 0F .....T.,.T...&..
    000010 70 3D 00 00 5C 00 50 00 49 00 50 00 45 00 5C 00 p=..\.P.I.P.E.\.
    000020 00 00 00 00 05 00 00 03 10 00 00 00 2C 00 00 00 ............,...
    000030 0A 00 00 00 14 00 00 00 00 00 01 00 00 00 00 00 ................
    000040 BB E2 9E 20 19 4C 0D 4B B7 17 DF 44 B9 00 52 40 ... .L.K...D..R@
    000050 00 00 00 80 FF 53 4D 42 25 00 00 00 00 18 07 C8 .....SMB%.......
    000060 00 00 00 00 00 00 00 00 00 00 00 00 00 50 78 07 .............Px.
    000070 01 90 C1 0C 10 00 00 2C 00 00 00 54 05 00 00 00 .......,...T....
    000080 00 00 00 00 00 00 00 00 00 54 00 2C 00 54 00 02 .........T.,.T..
    000090 00 26 00 0F 70 3D 00 00 5C 00 50 00 49 00 50 00 .&..p=..\.P.I.P.
    0000A0 45 00 5C 00 00 00 00 00 05 00 00 03 10 00 00 00 E.\.............
    0000B0 2C 00 00 00 0B 00 00 00 14 00 00 00 00 00 01 00 ,...............
    0000C0 00 00 00 00 15 FD E7 ED 7D DD E4 40 8A E9 7C 39 ........}..@..|9
    0000D0 30 15 BC C3 00 00 00 80 FF 53 4D 42 25 00 00 00 0........SMB%...
    0000E0 00 18 07 C8 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0000F0 00 50 F0 06 01 90 00 0D 10 00 00 2C 00 00 00 80 .P.........,....
    participants:
    attack:
    attacker: proxy=false
    addr: locality=IN 10.24.238.193
    port: 1071
    victim:
    addr: locality=IN 10.24.4.42
    port: 139
    alertDetails: Traffic Source: int0 ;
    As you can see, looks like a pretty normal SMB packet. This sensor is on an internal network, so Windows file and printer sharing is the norm.
    I think there is a false positive issue that was introduced with the signature’s tuning via the S180 update. As a result, I have two questions:
    1) Am I right, or is the signature working as it should?
    2) Is anyone else having this problem?
    Any and all feedback will be greatly appreciated,
    Alex Arndt

    The new version of this signature should be included in the S182 update. As a workaround if you are using 5.x you may to create 2 meta signatures using this signature and the no-op sled signatures (3328 for better coverage create a meta associated with each one and the existing sig). In your component list be sure to set 3353 prior to 3328. Set unique attackers to 1, meta interval to 2, and component list in order to true. This should eliminate all benign triggers.

  • Possible false positive issue with SigID 3334

    I have yet another possible false positive signature. This time it is SigID 3334 - Windows Workstation Service Overflow.
    Here's a capture from the EventStore on the sensor, again with the signature modified so that it captures the offending packet (CapturePacket=true):
    evAlert: eventId=1075708170032497693 severity=high
    originator:
    hostId: cisco_ids-v4.1
    appName: sensorApp
    appInstanceId: 1134
    time: 2005/07/19 17:08:44 2005/07/19 17:08:44 UTC
    interfaceGroup: 0
    vlan: 0
    signature: sigId=3353 sigName=SMB Request Overflow subSigId=0 version=S180 Malformed SMB Request
    context:
    fromVictim:
    000000 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000010 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000020 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000030 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000040 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000050 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000060 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000070 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000080 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    000090 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000A0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000B0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000C0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000D0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000E0 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 ................
    0000F0 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 ................
    fromAttacker:
    000000 00 2C 4C 00 00 46 1B 00 00 6A 38 00 00 5D 16 00 .,L..F...j8..]..
    000010 00 19 4E 00 00 F7 13 00 00 B6 54 00 00 25 31 00 ..N.......T..%1.
    000020 00 82 29 00 00 7B 3F 00 00 66 53 00 00 5B 3C 00 ..)..{?..fS..[<.
    000030 00 BB 40 00 00 BE 57 00 00 9F 4B 00 00 D9 06 00 [email protected].....
    000040 00 0C 0D 00 00 56 2C 00 00 D4 14 00 00 0B 13 00 .....V,.........
    000050 00 B4 57 00 00 F2 0B 00 00 F8 19 00 00 B9 4B 00 ..W...........K.
    000060 00 A6 3D 00 00 3F 1A 00 00 ED 1A 00 00 29 4E 00 ..=..?.......)N.
    000070 00 22 38 00 00 53 23 00 00 70 58 00 00 73 58 00 ."8..S#..pX..sX.
    000080 00 78 58 00 00 81 58 00 00 1C 1A 00 00 2D 59 00 .xX...X......-Y.
    000090 00 50 3A 00 00 00 00 00 3B FF 53 4D 42 2E 00 00 .P:.....;.SMB...
    0000A0 00 00 18 07 C8 00 00 00 00 00 00 00 00 00 00 00 ................
    0000B0 00 02 10 FF FE 00 18 80 60 0C FF 00 DE DE 08 18 ........`.......
    0000C0 00 00 00 00 88 0C 88 0C FF FF FF FF 88 0C 00 00 ................
    0000D0 00 00 00 00 00 00 00 80 FF 53 4D 42 25 00 00 00 .........SMB%...
    0000E0 00 18 07 C8 00 00 00 00 00 00 00 00 00 00 00 00 ................
    0000F0 02 10 94 06 00 18 C0 60 10 00 00 2C 00 00 00 88 .......`...,....
    participants:
    attack:
    attacker: proxy=false
    addr: locality=OUT 10.28.108.79
    port: 1046
    victim:
    addr: locality=IN 10.24.4.42
    port: 139
    alertDetails: Traffic Source: int0 ;
    Now if I understand this alarm correctly, it's looking at any SMB data that appears after the "\PIPE" in a packet, right? Given my dump, I don't think there's anything to get excited about... Is this another broken SMB-related signature?
    Alex Arndt

    It looks like you posted the wrong event log so I have no way to tell if this is a false positive.
    (I'm assuming your referring to signature 3334-0)
    If you are using the 4.x version of this signature there may be potential for a false positive, since we do not tie the regex to a uuid. If you are running 5.x I do not think it’s possible for this signature to false positive. To add fidelity we used 5.x’s engine meta and created a signature to ensure a hit on this signature as well as one for the msrpc bind request’s uuid. There is no way to improve the signature in 4.x without creating a risk for false negatives (if you don’t mind the risk just increase the allocation hint). That being said, the 4.x version of this signature does look for very specific things:
    3334-0 looks for an msrpc bind request using SMB_COM_Transaction utilizing the PIPE resource with an allocation hint >=1700, function 38 (base-10 for all these values), opcode 25 (base 10), set count of 2, and a word count of 16.
    Thanks,
    Craig Williams
    Cisco Systems

  • False Positives with GRC AC 5.2

    Hi,
    I actually have been working with GRC AC 5.2 (Compliance Calibrator) and we encountered several problems with false positives, working in the risk analysis.
    ¿do anyone knows how to solve this problem? ¿do you have documents or links to help?
    Thanks,
    Ricardo.

    Thank you Alpesh for response.
    In fact, i have several problem with false positives, but with transactional level. For example, i have a user with pfcg and su01 transaction. The configutation of profiles in SAP r/3 system do not allow to user involved in this, to execute both transactions in end-to-end process, i mean, the user have a transaction vía s_tcode object, have some other objects related with pfcg and su01 transactions, but he doesn´t have the values that allow to a transactions work properly. Then the Compliance Calibrator informs risks that it doesn´t exists.
    It seems that is a ruleset configuration problem in the CC, then my question is, ¿the standard ruleset detects properly these problems?
    Let my explain the reason that causes the problem.
    We have been working with personalized ruleset, for customer-request. For that reason we look the usobt_c table and we form the ruleset-->functions in CC so that this functions were equal to usobt_c table. We did that because the standard ruleset shows false positives, such as first example of this post.
    Thank you very much,
    RCL.
    Edited by: Ricardo  Carrasco on Jun 18, 2009 11:58 PM

  • LMS 4.2.2 DFM still not possible to disable Duplicate IP false positives?

    I found one discussion about Cisco Works 2.6 where it is pointed out that duplicate IP alerts cannot be disabled in LMS.
    Now I have a installation with 2 core switches, one has all VLAN Interfaces up, the second one the same interfaces with SAME IP addresses in shutdown state.
    DFM still recognizes these similar IP configuration on two boxes as duplicate ip situation, but it shouldn't because they are all shutdown.
    Is it possible to disable these false positives in DFM?
    Thanks for any hints!

    I found one discussion about Cisco Works 2.6 where it is pointed out that duplicate IP alerts cannot be disabled in LMS.
    Now I have a installation with 2 core switches, one has all VLAN Interfaces up, the second one the same interfaces with SAME IP addresses in shutdown state.
    DFM still recognizes these similar IP configuration on two boxes as duplicate ip situation, but it shouldn't because they are all shutdown.
    Is it possible to disable these false positives in DFM?
    Thanks for any hints!

Maybe you are looking for