<div dir="ltr"><div>Hi RMKML,<br><br></div>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<br><br>
 
 
 
 
 
  
 
 
 
 
 
  Vulnerability
  Name
  Synopsis
  Description
  Solution
 
 
  SSL Version 2 and 3 Protocol Detection
  The
  remote service encrypts traffic using a protocol with known<br>
    weaknesses.
  The
  remote service accepts connections encrypted using SSL 2.0 and/or<br>
    SSL 3.0. These versions of SSL reportedly suffer from several<br>
    cryptographic flaws. An attacker may be able to exploit these flaws
  to<br>
    conduct man-in-the-middle attacks or to decrypt communications
  between<br>
    the affected service and clients.<br>
    <br>
    NIST has determined that SSL 3.0 is no longer acceptable for secure<br>
    communications. As of the date of enforcement found in PCI DSS v3.1,<br>
    any version of SSL will not meet the PCI SSC'S definition of 'strong<br>
    cryptography'.
  Consult
  the application's documentation to disable SSL 2.0 and 3.0.<br>
    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.<br>
    The RC4 cipher is flawed in its generation of a pseudo-random stream<br>
    of bytes so that a wide variety of small biases are introduced into<br>
    the stream, decreasing its randomness.<br>
    <br>
    If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an<br>
    attacker is able to obtain many (i.e., tens of millions) ciphertexts,<br>
    the attacker may be able to derive the plaintext.
  Reconfigure
  the affected application, if possible, to avoid use of RC4<br>
    ciphers. Consider using TLS 1.2 with AES-GCM suites subject to
  browser<br>
    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.<br>
    The RC4 cipher is flawed in its generation of a pseudo-random stream<br>
    of bytes so that a wide variety of small biases are introduced into<br>
    the stream, decreasing its randomness.<br>
    <br>
    If plaintext is repeatedly encrypted (e.g., HTTP cookies), and an<br>
    attacker is able to obtain many (i.e., tens of millions) ciphertexts,<br>
    the attacker may be able to derive the plaintext.
  Reconfigure
  the affected application, if possible, to avoid use of RC4<br>
    ciphers. Consider using TLS 1.2 with AES-GCM suites subject to
  browser<br>
    and web server support.
 
 
  SSLv3 Padding Oracle On Downgraded Legacy Encryption
  Vulnerability (POODLE)
  It
  is possible to obtain sensitive information from the remote host<br>
    with SSL/TLS-enabled services.
  The
  remote host is affected by a man-in-the-middle (MitM) information<br>
    disclosure vulnerability known as POODLE. The vulnerability is due to<br>
    the way SSL 3.0 handles padding bytes when decrypting messages<br>
    encrypted using block ciphers in cipher block chaining (CBC) mode.<br>
    MitM attackers can decrypt a selected byte of a cipher text in as few<br>
    as 256 tries if they are able to force a victim application to<br>
    repeatedly send the same data over newly created SSL 3.0 connections.<br>
    <br>
    As long as a client and service both support SSLv3, a connection can<br>
    be 'rolled back' to SSLv3, even if TLSv1 or newer is supported by the<br>
    client and service.<br>
    <br>
    The TLS Fallback SCSV mechanism prevents 'version rollback' attacks<br>
    without impacting legacy clients; however, it can only protect<br>
    connections when the client and service support the mechanism. Sites<br>
    that cannot disable SSLv3 immediately should enable this mechanism.<br>
    <br>
    This is a vulnerability in the SSLv3 specification, not in any<br>
    particular SSL implementation. Disabling SSLv3 is the only way to<br>
    completely mitigate the vulnerability.
  Disable
  SSLv3.<br>
    <br>
    Services that must support SSLv3 should enable the TLS Fallback SCSV<br>
    mechanism until SSLv3 can be disabled.
 
</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 5, 2015 at 3:43 AM, rmkml <span dir="ltr"><<a href="mailto:rmkml@...202....174..." target="_blank">rmkml@...174...</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and this rule is a recommended policy drop "security-ips", if trigger, please share or send to VRT/Talos.<br>
<br>
Regards<span class="HOEnZb"><font color="#888888"><br>
@Rmkml</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Mon, 4 May 2015, rmkml wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Mustaque,<br>
<br>
Could you have checked the reference on this sig please ?<br>
<br>
<a href="https://www.us-cert.gov/ncas/alerts/TA13-088A" target="_blank">https://www.us-cert.gov/ncas/alerts/TA13-088A</a><br>
<br>
Regards<br>
@Rmkml<br>
<br>
<br>
On Mon, 4 May 2015, Mustaque wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hi,<br>
<br>
 <br>
<br>
I cant see the packet information to investigate the integrity of this rule. And what this rule does? Need more info.<br>
<br>
 <br>
<br>
Thanks and Regards<br>
<br>
Mustaque<br>
<br>
<br>
</blockquote>
</blockquote>
</div></div></blockquote></div><br></div>