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

Mustaque Ahmad mustaque.ahmad at ...4030...
Thu May 7 00:14:44 EDT 2015


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
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20150507/4bc6afe3/attachment.html>


More information about the Snort-sigs mailing list