eEye Digital Security

 I have a lot of these false positives. This means the system was not admin, or is there another possible problem? Thx.

 Issue seems to be Vista related and likely fixed by observing the following notes:

http://www.eeye.com/html/consumer/support/kb/view.html?id=KB000760&product=Retina&category=*&searchfor=auto,start&using=Any&searchtype=&order=Hits&page=1

 No Vista over here and I got alot of the Null Sessions false positives.

Whats the audit ID?

 163 Does it tie in with ID # 2913?

 163 is different thand 2913. One is Null Session and one is Anonymous Registry Access.

 Thanks... it just seemed odd thaqt Audit ID did not come until the recent upgrade. And not across the board on my network. No biggie. Gonna look around for any other false positives. I like the product, but seems interesting findings increased on this upgrade.

Wedge:

I like the product ...

Retina in Blink 4.4.1?

 I have 163 for the Null Session.

This one seems to be related to case sensitivity in the registry.  Even if the settings are correct it is a finding unless the registry entries are in the proper (per Retina) CamelCasing.  All lower case and it's a false positive.

Is there any way to turn off case sensitivity in Retina?

SPD

Retina uses Windows APIs so its simply based on the case sensitivity of Windows, which typically there is no case sensitivity.

I'm not sure why SPD mentions this.

I mentioned it because (oddly enough) if the registry entry is in all lower case its a finding. If I re-enter the registry entries using mixed case its not.  Sorry if I wasn't clear.  Could there be a setting in Windows that has been incorrectly configured and if so how do I correct that?

Thanks for the help,

SPD

Microsoft has 3 registry entries for this particular item, please post the correct capitalization (per the Retina scanner) to eliminate this finding.

Thanks

 This is in response to the false positives for audit 163, NULL sessions. Audit 2913 is totally unrelated.

Audit 163 (NULL session connections expose sensitive info via Windows Net??? API calls) and 2091 (limited NULL session exposure through the SRVSVC and/or SAMR named pipes) deal with NULL session vulnerabilities.

Funny that I just spent 11 hours today figuring out why we sometimes report false positives on 2003/XP and greater systems. Unlike 2000, NULL session connections are always allowed on 2003/XP which in conjunction with certain combinations of registry values result in false findings. The audits have been fixed and will be availble in late November or early December.

I will be preparing a KB article tomorrow explaining the quirks in the 2003/XP MS solution to NULL session restrictions and the criteria we now use to report findings. Instructions on how to resolve the issue will also be updated with more detail.

Craig

 Craig,

Thanks for the response on audit 163. Is the KB article you referenced available?

Thanks