These include vulnerabilities in specific libraries, inadequate TLS/SSL certificate validation, SQL Injection, File-based Cross-Site Scripting, Cross-App …
Tag: Transport Layer Security
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:
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:
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:
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:
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:
The Citrix License Server certificate is not in the Delivery Controller's trusted root store
To resolve this issue, add the License Server certificate to the trusted root store on the Delivery Controller.
For instructions, see [Adding certificates to the Trusted Root Certification Authorities store for a local computer] on the Microsoft web site.
For more information, see Citrix Documentation – Licensing.
Related:
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.
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.
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:
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:
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