Snort mailing list archives
Re: PROTOCOL-DNS DNS query amplification attempt (1:28556)
From: Mustaque Ahmad <mustaque.ahmad () nuemera com>
Date: Thu, 7 May 2015 12:14:44 +0800
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 () yahoo fr> 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 () 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!
Current thread:
- PROTOCOL-DNS DNS query amplification attempt (1:28556) Mustaque (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Al Lewis (allewi) (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Geoffrey Serrao (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) rmkml (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) rmkml (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Mustaque Ahmad (May 07)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Jamie Riden (May 07)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Mustaque (May 12)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) rmkml (May 04)
- Re: PROTOCOL-DNS DNS query amplification attempt (1:28556) Al Lewis (allewi) (May 04)