Cisco Prime Infrastructure Certificate Validation Vulnerability

A vulnerability in the Identity Services Engine (ISE) integration feature of Cisco Prime Infrastructure (PI) could allow an unauthenticated, remote attacker to perform a man-in-the-middle attack against the Secure Sockets Layer (SSL) tunnel established between ISE and PI.

The vulnerability is due to improper validation of the server SSL certificate when establishing the SSL tunnel with ISE. An attacker could exploit this vulnerability by using a crafted SSL certificate and could then intercept communications between the ISE and PI. A successful exploit could allow the attacker to view and alter potentially sensitive information that the ISE maintains about clients that are connected to the network.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190220-prime-validation

Security Impact Rating: High

CVE: CVE-2019-1659

Related:

  • No Related Posts

Cisco SPA112, SPA525, and SPA5x5 Series IP Phones Certificate Validation Vulnerability

A vulnerability in the certificate handling component of the Cisco SPA112, SPA525, and SPA5X5 Series IP Phones could allow an unauthenticated, remote attacker to listen to or control some aspects of a Transport Level Security (TLS)-encrypted Session Initiation Protocol (SIP) conversation.

The vulnerability is due to the improper validation of server certificates. An attacker could exploit this vulnerability by crafting a malicious server certificate to present to the client. An exploit could allow an attacker to eavesdrop on TLS-encrypted traffic and potentially route or redirect calls initiated by an affected device.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190220-ipphone-certs

Security Impact Rating: Medium

CVE: CVE-2019-1683

Related:

  • No Related Posts

Cisco Firepower Threat Defense Software SSL or TLS Denial of Service Vulnerability

A vulnerability in the detection engine of Cisco Firepower Threat Defense Software could allow an unauthenticated, remote attacker to cause the unexpected restart of the SNORT detection engine, resulting in a denial of service (DoS) condition.

The vulnerability is due to the incomplete error handling of the SSL or TLS packet header during the connection establishment. An attacker could exploit this vulnerability by sending a crafted SSL or TLS packet during the connection handshake. An exploit could allow the attacker to cause the SNORT detection engine to unexpectedly restart, resulting in a partial DoS condition while the detection engine restarts.

There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190220-fpwr-ssltls-dos

Security Impact Rating: Medium

CVE: CVE-2019-1691

Related:

  • No Related Posts

Error: “The underlying connection was closed: An unexpected error occurred on a send.” when querying Monitoring Service’s OData endpoint

To fix this issue, enforce use of TLS 1.2 on the client machine. Add the following registry entries, so the clients such as MS Excel, PowerShell, LinqPad use TLS 1.2 by default.

Please follow the below mentioned steps depending on your platform.

Windows Server Version 1709 / Windows 2016 / Windows 10 (for IIS Manager and Web Deploy)

Set the SchUseStrongCrypto registry key by saving the below code to enableTLS12.reg and running it:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]"SchUseStrongCrypto"=dword:00000001[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]"SchUseStrongCrypto"=dword:00000001

Windows 2012 R2 / 2012 / Windows 8.1 / Windows 8 (for IIS Manager and Web Deploy)

Set the SchUseStrongCrypto registry key by saving the below code to enableTLS12.reg and running it:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]"SchUseStrongCrypto"=dword:00000001[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]"SchUseStrongCrypto"=dword:00000001

Alternatively, install one of the following updates:

Windows 2012 R2, Windows 8.1: https://support.microsoft.com/en-us/kb/2898850

Windows 2012, Windows 8: https://support.microsoft.com/en-us/kb/2898849

Windows 2008 R2 / Windows 7 (for Web Deploy with NetFX 4.5.2 installed)

Follow the steps mentioned under Windows Server 2012 R2/Windows Server 2012 to enable SchUseStrongCrypto either through the registry or by installing the update in the applicable KB article.

Additionally, you must set the following registry keys, as Windows 2008 R2 and Windows 7 do not enable TLS 1.1 or TLS 1.2 by default. Save below code to enableTLS12.reg and run it:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]"DisabledByDefault"=dword:00000000

Then, restart the computer.

Windows 2008 R2 / Windows 7

Install the NetFX update (KB3154518) that enables TLS 1.2 in .NET Framework 3.5.1: https://support.microsoft.com/en-us/kb/3154518

Then, set the following registry key by saving the below code to enableTLS12.reg and running it:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]"SystemDefaultTlsVersions"=dword:00000001[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv2.0.50727]"SystemDefaultTlsVersions"=dword:00000001

Additionally, you must set the following registry keys because Windows 2008 R2 and Windows 7 do not enable TLS 1.1/1.2 by default. below code to forceTLS1.2.reg and run it:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2][HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]"DisabledByDefault"=dword:00000000

Restart the computer.

Related:

  • No Related Posts

Cisco Web Security Appliance Decryption Policy Bypass Vulnerability

A vulnerability in the Decryption Policy Default Action functionality of the Cisco Web Security Appliance (WSA) could allow an unauthenticated, remote attacker to bypass a configured drop policy and allow traffic onto the network that should have been denied.

The vulnerability is due to the incorrect handling of SSL-encrypted traffic when Decrypt for End-User Notification is disabled in the configuration. An attacker could exploit this vulnerability by sending a SSL connection through the affected device. A successful exploit could allow the attacker to bypass a configured drop policy to block specific SSL connections.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190206-wsa-bypass

Security Impact Rating: Medium

CVE: CVE-2019-1672

Related:

  • No Related Posts

Error: “1015: The secure connection could not be established (2)”

  • Expand SSL, click Certificates to view the certificates.

    In this example, TestCertificate is bound to the Access Gateway virtual server and the certificate is Expired.

    User-added image

    The Secure Access Client is able to connect successfully with a valid SSL server Certificate. In this example, TestCertificate is bound to the Access Gateway virtual server and the certificate is Valid.

    User-added image

    Note: If your certificate is Valid and the same error message is displayed, check if there are any intermediates linked to the server certificate. It is recommended to have proper Intermediate Certificate linked to the server certificate.

  • Related:

    • No Related Posts

    VPLEX: Health-check –full reports Call Home “Error” state post NDU[1]

    Article Number: 523118 Article Version: 3 Article Type: Break Fix



    VPLEX GeoSynchrony,VPLEX Local,VPLEX Metro,VPLEX Series,VPLEX VS2,VPLEX VS6

    An Error is reporting in the commandhealth-check –full post upgrade but the Call Home functions properly.

    • Pre NDU Health-check –full doesn’t report an error.

    • Post NDUHealth-check –full reports “Checking Call Home Status” as Error.

    • ConnectEMC_config.xml file looks the same as pre NDU as post NDU.

    • No issues seen in connectemc related logs.

    • The SMTP service is reachable and non-blocked.

    • Call-Home works right, for every triggered call-home test.

    • SYR / CLM system determine call home alerts have being correctly received. Hence, confirming Connecthome is received.

    Comparing PRE & POST Non-Disruptive Upgrade (NDU)

    PRE NDU

    VPlexcli:/> health-check –full

    Configuration (CONF):

    Checking VPlexCli connectivity to directors……………….. OK

    Checking Directors Commission……………………………. OK

    Checking Directors Communication Status…………………… OK

    Checking Directors Operation Status………………………. OK

    Checking Inter-director management connectivity……………. OK

    Checking ports status…………………………………… OK

    Checking Call Home……………………………………… OK

    Checking Connectivity…………………………………… OK

    POST NDU

    VPlexcli:/> health-check –full

    Configuration (CONF):

    Checking VPlexCli connectivity to directors……………….. OK

    Checking Directors Commission……………………………. OK

    Checking Directors Communication Status…………………… OK

    Checking Directors Operation Status………………………. OK

    Checking Inter-director management connectivity……………. OK

    Checking ports status…………………………………… OK

    Checking Call Home Status……………………………….. Error

    service@vplexMM:/var/log/VPlex/cli> more health_check_full_scan.log

    Configuration (CONF):

    Checking VPlexCli connectivity to directors……………….. OK

    Checking Directors Commission……………………………. OK

    Checking Directors Communication Status…………………… OK

    Checking Directors Operation Status………………………. OK

    Checking Inter-director management connectivity……………. OK

    Checking ports status…………………………………… OK

    Checking Call Home Status……………………………….. Error

    Email Server under Notification type: ‘onSuccess/onFailure’ is either

    Not reachable or invalid.

    Check if Email Server IP address: ‘10.1.111.100’ is reachable and valid.

    Email Server under Notification type: ‘Primary’ and ‘Failover’ are either

    Not reachable or invalid.

    Check if Email Server IP address: ‘10.1.111.100’ and ‘10.1.111.100’ are

    Reachable and valid.

    service@vplexMM:/opt/emc/connectemc> cat ConnectEMC_config.xml

    <?xml version=”1.0″ encoding=”UTF-8″ standalone=”no” ?>

    <ConnectEMCConfig SchemaVersion=”1.1.0″>

    <ConnectConfig Type=”Email”>

    <Retries>7</Retries>

    <Notification>Primary</Notification>

    <Timeout>700</Timeout>

    <Description></Description>

    <BsafeEncrypt>no</BsafeEncrypt>

    <IPProtocol>IPV4</IPProtocol>

    <EmailServer>10.1.111.100</EmailServer>

    <EmailAddress>emailalert@EMC.com</EmailAddress>

    <EmailSender>VPlex_CKM00000000999@EMC.com</EmailSender>

    <EmailFormat>ASCII</EmailFormat>

    <EmailSubject>Call Home</EmailSubject>

    <STARTTLS>no</STARTTLS>

    <IncludeCallHomeData>no</IncludeCallHomeData>

    <InsertBefore></InsertBefore>

    <PreProcess></PreProcess>

    <PostProcess></PostProcess>

    <HeloParameter></HeloParameter>

    </ConnectConfig>

    <ConnectConfig Type=”Email”>

    <Retries>7</Retries>

    <Notification>Failover</Notification>

    <Timeout>700</Timeout>

    <Description></Description>

    <BsafeEncrypt>no</BsafeEncrypt>

    <IPProtocol>IPV4</IPProtocol>

    <EmailServer>10.1.111.100</EmailServer>

    <EmailAddress>emailalert@EMC.com</EmailAddress>

    <EmailSender> VPlex_CKM00000000999@EMC.com</EmailSender>

    <EmailFormat>ASCII</EmailFormat>

    <EmailSubject>Call Home</EmailSubject>

    <STARTTLS>no</STARTTLS>

    <IncludeCallHomeData>no</IncludeCallHomeData>

    <InsertBefore></InsertBefore>

    <PreProcess></PreProcess>

    <PostProcess></PostProcess>

    <HeloParameter></HeloParameter>

    </ConnectConfig>

    <ConnectConfig Type=”Email”>

    <Retries>7</Retries>

    <Notification>onSuccess/onFailure</Notification>

    <Timeout>700</Timeout>

    <Description></Description>

    <BsafeEncrypt>no</BsafeEncrypt>

    <IPProtocol>IPV4</IPProtocol>

    <EmailServer>10.1.111.100</EmailServer>

    <EmailAddress>customer@genericemailaddress.com</EmailAddress>

    <EmailSender>VPlex_CKM00000000999@EMC.com</EmailSender>

    <EmailFormat>ASCII</EmailFormat>

    <EmailSubject>Call Home</EmailSubject>

    <STARTTLS>no</STARTTLS>

    <IncludeCallHomeData>yes</IncludeCallHomeData>

    <InsertBefore></InsertBefore>

    <PreProcess></PreProcess>

    <PostProcess></PostProcess>

    <HeloParameter></HeloParameter>

    </ConnectConfig>

    </ConnectEMCConfig>

    service@vplexMM:/var/log/ConnectEMC/logs> ping 10.1.111.100

    PING 10.1.111.100 (10.1.111.100) 56(84) bytes of data.

    — 10.1.111.100 ping statistics —

    6 packets transmitted, 0 received, 100% packet loss, time 5010ms

    service@vplexMM:~> telnet 10.1.111.100 25

    Trying 10.1.111.100…

    Connected to 10.1.111.100

    Escape character is ‘^]’.

    220 emc.com

    helo localhost

    250 emc.com

    mail from: VPlex_CKM00000000999@EMC.com

    250 2.1.0 Ok

    rcpt to:customer@genericemailaddress.com

    250 2.1.0 Ok

    VPlexcli:/notifications/call-home> test

    call-home test was successful.


    As per the above information, this means that the customer is allowing the SMTP service on port “25” only and not the ICMP “ping”.

    This error is expected and can be ignored once you verify that the test call home is working and appearing under /opt/emc/connectemc/archive

    service@vplexMM:/opt/emc/connectemc/archive> ll

    -rw-r—– 1 service users 2814 Jun 25 13:17 RSC_CKM00000000999_062518_011656000.xml

    -rw-r—– 1 service users 2814 Jun 25 10:54 RSC_CKM00000000999_062518_105401000.xml

    -rw-r—– 1 service users 2814 Jun 25 11:11 RSC_CKM00000000999_062518_111102000.xml

    -rw-r—– 1 service users 2814 Jun 25 11:48 RSC_CKM00000000999_062518_114834000.xml

    Checking call home status is part of the health-check — full script which does the following:

    1- Check the email server for each notification type in /opt/emc/connectemc/ConnectEMC_config.xml

    2- Ping the server. If the server is not pingable for any reason (not reachable via network, server is shutdown, ICMP service is blocked via firewall, the <EmailServer> is a DNS name instead of the name in the ConnectEMC_config.xml file).

    As a result, the commandhealth-check –full script will fail and will show the following error:

    Checking Call Home Status……………………………….. Error

    The current healthcheck script checks if call home is enabled and generates a “Warning” state if it’s disabled.

    The healthcheck script also checks if call home has been functioning properly with several verifications such as: checking call homes have been generated; the call home emails have been sent successfully sent; or if SMTP server ping is alive.

    If any of these verifications fail, the script’s result will be flagged with an error as shown:

    Checking Call Home Status……………………………….. Error

    After enabling the ICMP protocol on the firewall level between the VPLEX management server and their selected email server used (ESRS, customer’s email server), the Call Home “Error” status is now clean:

    VPlexcli:/> health-check –full

    Configuration (CONF):

    Checking VPlexCli connectivity to directors……………….. OK

    Checking Directors Commission……………………………. OK

    Checking Directors Communication Status…………………… OK

    Checking Directors Operation Status………………………. OK

    Checking Inter-director management connectivity……………. OK

    Checking ports status…………………………………… OK

    Checking Call Home Status……………………………….. OK

    Checking Connectivity…………………………………… OK

    Checking COM Port Power Level……………………………. OK

    Checking Meta Data Backup……………………………….. OK

    Checking Meta Data Slot Usage……………………………. OK

    Related:

    • No Related Posts

    Can ProxySG ‘uplevel’ a TLS connection to an internet website?

    I need a solution

    I have a legacy client on my network that needs to connect to an internet website that is disabling support for TLS 1.0 and 1.1.  This client is not capable of making connections higher than TLS 1.0, though.  It uses the ProxySG explicitly with a CONNECT, but I can route the traffic to get it there transparently as well if needed.  Is there a way in the ProxySG to cause the Proxy -> OCS connection to be TLS 1.2 even though the Client -> Proxy connection is TLS 1.0?

    I found one knowledge entry that looks like it’s specific to making the reverse happen, but I think this is more of a source/dst/action rule (https://support.symantec.com/en_US/article.TECH248…).  I tried it anyway with the client.negotiated.ssl.version set to TLSV1 and it resulted in a ‘n/a’ in a policy trace.

    Anyone know if there’s a way to do this?

    0

    Related:

    • No Related Posts