[Snort-sigs] PROTOCOL-DNS DNS query amplification attempt (1:28556)

Jamie Riden jamie.riden at ...2420...
Fri May 8 02:53:41 EDT 2015


Hi Mustaque,

Yes - you should probably disable SSLv3 and RC4-based ciphers.
However, this is not a Sourcefire (now Cisco I guess?) support forum,
so we probably can't help out much.

This list is for discussion of the actual signatures, and many of us
do not even have a Sourcefire appliance. Having said that, do take a
quick look through the settings and it might just be a checkbox.

You might do better here possibly?  https://community.sourcefire.com/

thanks,
 Jamie


On 7 May 2015 at 05:14, Mustaque Ahmad <mustaque.ahmad at ...4030...> wrote:
> Hi RMKML,
>
> Recently I performed VA against our sourcefire IDS/IPS appliance and
> identified below listed vulnerabilities. Could you provide the instructions
> and steps to close these vulnerability also would there be any impact if
> make changes on the production? Thanks
>
> Vulnerability Name Synopsis Description Solution SSL Version 2 and 3
> Protocol Detection The remote service encrypts traffic using a protocol with
> known
> weaknesses. The remote service accepts connections encrypted using SSL 2.0
> and/or
> SSL 3.0. These versions of SSL reportedly suffer from several
> cryptographic flaws. An attacker may be able to exploit these flaws to
> conduct man-in-the-middle attacks or to decrypt communications between
> the affected service and clients.
>
> NIST has determined that SSL 3.0 is no longer acceptable for secure
> communications. As of the date of enforcement found in PCI DSS v3.1,
> any version of SSL will not meet the PCI SSC'S definition of 'strong
> cryptography'. Consult the application's documentation to disable SSL 2.0
> and 3.0.
> Use TLS 1.0 or higher instead. SSL RC4 Cipher Suites Supported The remote
> service supports the use of the RC4 cipher. The remote host supports the use
> of RC4 in one or more cipher suites.
> The RC4 cipher is flawed in its generation of a pseudo-random stream
> of bytes so that a wide variety of small biases are introduced into
> the stream, decreasing its randomness.
>
> If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an
> attacker is able to obtain many (i.e., tens of millions) ciphertexts,
> the attacker may be able to derive the plaintext. Reconfigure the affected
> application, if possible, to avoid use of RC4
> ciphers. Consider using TLS 1.2 with AES-GCM suites subject to browser
> and web server support. SSL RC4 Cipher Suites Supported The remote service
> supports the use of the RC4 cipher. The remote host supports the use of RC4
> in one or more cipher suites.
> The RC4 cipher is flawed in its generation of a pseudo-random stream
> of bytes so that a wide variety of small biases are introduced into
> the stream, decreasing its randomness.
>
> If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an
> attacker is able to obtain many (i.e., tens of millions) ciphertexts,
> the attacker may be able to derive the plaintext. Reconfigure the affected
> application, if possible, to avoid use of RC4
> ciphers. Consider using TLS 1.2 with AES-GCM suites subject to browser
> and web server support. SSLv3 Padding Oracle On Downgraded Legacy Encryption
> Vulnerability (POODLE) It is possible to obtain sensitive information from
> the remote host
> with SSL/TLS-enabled services. The remote host is affected by a
> man-in-the-middle (MitM) information
> disclosure vulnerability known as POODLE. The vulnerability is due to
> the way SSL 3.0 handles padding bytes when decrypting messages
> encrypted using block ciphers in cipher block chaining (CBC) mode.
> MitM attackers can decrypt a selected byte of a cipher text in as few
> as 256 tries if they are able to force a victim application to
> repeatedly send the same data over newly created SSL 3.0 connections.
>
> As long as a client and service both support SSLv3, a connection can
> be 'rolled back' to SSLv3, even if TLSv1 or newer is supported by the
> client and service.
>
> The TLS Fallback SCSV mechanism prevents 'version rollback' attacks
> without impacting legacy clients; however, it can only protect
> connections when the client and service support the mechanism. Sites
> that cannot disable SSLv3 immediately should enable this mechanism.
>
> This is a vulnerability in the SSLv3 specification, not in any
> particular SSL implementation. Disabling SSLv3 is the only way to
> completely mitigate the vulnerability. Disable SSLv3.
>
> Services that must support SSLv3 should enable the TLS Fallback SCSV
> mechanism until SSLv3 can be disabled.
>
> On Tue, May 5, 2015 at 3:43 AM, rmkml <rmkml at ...174...> wrote:
>>
>> and this rule is a recommended policy drop "security-ips", if trigger,
>> please share or send to VRT/Talos.
>>
>> Regards
>> @Rmkml
>>
>>
>>
>> On Mon, 4 May 2015, rmkml wrote:
>>
>>> Hello Mustaque,
>>>
>>> Could you have checked the reference on this sig please ?
>>>
>>> https://www.us-cert.gov/ncas/alerts/TA13-088A
>>>
>>> Regards
>>> @Rmkml
>>>
>>>
>>> On Mon, 4 May 2015, Mustaque wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I cant see the packet information to investigate the integrity of this
>>>> rule. And what this rule does? Need more info.
>>>>
>>>>
>>>>
>>>> Thanks and Regards
>>>>
>>>> Mustaque
>>>>
>>>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
> http://www.snort.org
>
>
> Please visit http://blog.snort.org for the latest news about Snort!



-- 
Jamie Riden / jamie at ...3509... / jamie.riden at ...2420...
http://uk.linkedin.com/in/jamieriden




More information about the Snort-sigs mailing list