The report said that last month’s most exploited vulnerabilities were SQL Injection, OpenSSL TLS DTLS Heartbeat Information Disclosure …
Tag: Cryptographic protocols
Cisco Firepower Threat Defense Software File Policy Bypass Vulnerability
A vulnerability in the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocol inspection engine of Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to bypass the configured file policies on an affected system.
The vulnerability is due to errors when handling specific SSL/TLS messages. An attacker could exploit this vulnerability by sending crafted HTTP packets that would flow through an affected system. A successful exploit could allow the attacker to bypass the configured file policies and deliver a malicious payload to the protected 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-20190807-ftd-bypass
Security Impact Rating: Medium
CVE: CVE-2019-1970
Related:
Cisco Industrial Network Director Web Services Management Agent Unauthorized Information Disclosure Vulnerability
A vulnerability in the Web Services Management Agent (WSMA) feature of Cisco Industrial Network Director (IND) could allow an unauthenticated, remote attacker to gain unauthorized read access to sensitive data using an invalid X.509 certificate.
The vulnerability is due to insufficient X.509 certificate validation when establishing a WSMA connection. An attacker could exploit this vulnerability by supplying a crafted X.509 certificate during the WSMA connection setup phase. A successful exploit could allow the attacker to conduct man-in-the-middle attacks to decrypt confidential information on WSMA connections to the affected software.
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-20190717-wsma-info
Security Impact Rating: Medium
CVE: CVE-2019-1940
Related:
Cisco ASA and FTD Software Cryptographic TLS and SSL Driver Denial of Service Vulnerability
A vulnerability in the cryptographic driver for Cisco Adaptive Security Appliance Software (ASA) and Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause the device to reboot unexpectedly.
The vulnerability is due to incomplete input validation of a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) ingress packet header. An attacker could exploit this vulnerability by sending a crafted TLS/SSL packet to an interface on the targeted device. An exploit could allow the attacker to cause the device to reload, which will result in a denial of service (DoS) condition.
Note: Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed and transparent firewall mode and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic. A valid SSL or TLS session is required to exploit this vulnerability.
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-20190710-asa-ftd-dos
Security Impact Rating: High
CVE: CVE-2019-1873
Related:
Intermittent Slowness SSL sites and RDP
I do not need a solution (just sharing information)
Hi all,
Recently encountered a weird slowness on one of the subnets at a customer site, https and rdp appear to be extremely slow. Sometimes reporting that certificate revocation information is not available. RDP sessions after initial password prompt also take between 30-60 seconds to connect. SSL and RDP are fine at other sites / subnets. All go to two proxySG’s upstream (set via wpad file). Feels like the slowness is due to some form of security / certificate checking going on, it’s strange that we only see this issue on one subnet as there are lots of others all going to the same ProxySG devices. Haven’t ruled out other area’s of investigation (e.g. group policy, firewall, switches etc.) but we have seen if disabling the certificate revocation checks speed is hugely improved (sometimes a reboot has been needed to kick this in). However it’s not something I’m overly comfortable leaving disabled.
Does anyone have any suggestions on what this could possibly be or how best to troubleshoot? Seen a couple KB’s related to OCSP and CRL but nothing thats a match for intermittent symptoms we’re seeing. We’re upgrading the devices next week (approxy 10 months out of date) and if no better logging a case with Symantec to see if they could help.
Thanks
0
Related:
Browser Content Redirection: whitelisting websites
Browser Content Redirection is a technology built around a URL whitelisting mechanism. Two policies are exposed in Studio for that purpose:
i. Browser content redirection Access Control List (ACL) policy settings (a.k.a the ACL policy)
ii. Browser content redirection authentication sites (a.k.a the authentication sites policy)
While the description in edocs tries to cover the general cases, there are some websites using intrinsic redirection mechanisms that make the whitelisting process more difficult.
[Note: websites that rely on Integrated Windows Authentication, or that require a pop-up Windows Security message box are not handled correctly by BCR. This is because our overlay browser (HdxBrowser.exe or HdxBrowsercef.exe) cannot display that window, hence the user is stuck on a blank page. See CTX230052 (current limitations section)].
As an example of BCR redirections, we will look into Microsoft Teams.
It is essential that the Developer Tools is used to understand the website’s behavior before configuring any policy.
The ‘Preserve Log’ check-box should be ticked, otherwise entries are cleared automatically.
Microsoft Teams
A user typing http://teams.microsoft.com will get an HTTP 307 response from the webserver, repointing the browser to https://teams.microsoft.com
(Hence it is critical that the right syntax is used when whitelisting a website, like http or https, with or without www, etc – otherwise redirection might fail).
From that URL, the resource https://teams.microsoft.com/auth/prelogin is contacted by the browser, which eventually ends up being redirected to:
| https://login.microsoftonline.com/common/oauth2/authorize?response_type=id_token&client_id=xxxxxxxxxxxxxxxxxxxxxxxxx&redirect_uri=https%3A%2F%2Fteams.microsoft.com%2Fgo&state=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&&client-request-id=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&x-client-SKU=Js&x-client-Ver=1.0.9&nonce=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1&domain_hint= |
Once the browser loads this page, it ‘rests’ and waits for user input. These redirections occured very fast, and the HdxVideo.js javascript that the Browser Content Redirection Chrome Extension needs to inject is not done in time.
In this case, the url https://login.microsoftonline.com/* needs to be whitelisted in the ACL policy in Studio.
Since the Admin might not want to redirect the entire domain, better granularity can be achieved by leveraging a common parameter in OAuth 2.0 (redirect_uri, where the App name is embedded in the URL).
So whitelisting the following URL in the BCR ACL policy in Studio will achieve the objective, thanks to wildcards:
https://login.microsoftonline.com/*teams*
The Chrome Extension will now be able to inject HdxVideo.js, and the first redirection happens. The user will end up being redirected to an Office 365 Authentication website that is linked to Teams (see screenshot above), but this time the website will be running locally on the endpoint’s overlay browser that is part of Workspace app (HdxBrowserCef.exe).
Important: Please note that any IdP/SSO websites your organization deployed to authenticate users in O365 will also need to be added to the Authentication Sites policy (e.g. https://mycompany.okta.com)
Please also note that Teams will require to add https://login.microsoftonline.com/login* to the Authentication Sites.
After a successful authentication, the overlay browser HdxBrowserCef.exe is pointed back to https://teams.microsoft.com
This URL (https://teams.microsoft.com/*) should now be whitelisted also in the ‘Authentication Sites’ policy in Studio.
Note: This might be somehow counter intuitive as the Authentication site is login.microsoftonline.com, not teams.microsoft.com – yet the problem in Teams is that the Chrome Extension is not loaded fast enough by the Browser and therefore injection fails on teams.microsoft.com.
Browser Content Redirection treats websites whitelisted under the Authentication sites policy as child websites that must remain redirected if the parent website was in the ACL whitelist policy. In the Teams case then, teams.microsoft.com is the child website of the parent login.microsoftonline.com
Note: Peer-to-Peer Video conferencing is currently not available with Teams and Chrome, so it will not work with BCR either. Once Microsoft officially supports Chrome browser for peer to peer video, BCR will support it automatically.
Joining a conference call with video is supported in BCR.
GoToMeeting
First thing to notice is that navigating to https://gotomeet.me/mymeetingID redirects to https://www.gotomeet.me/mymeetingID
Whitelisting without the ‘www’ will result in failure. So whitelisting https://www.gotomeet.me/* is the solution (in the ACL policy).
Note the use of the wildcard ‘*’ – this allows you to whitelist any path for that URL.
After the webpage is redirected, the user can click ‘Join meeting in browser’, which points to:
https://app.gotomeeting.com/index.html?meetingId=xxxxxxxxxx
Note that this is a different FQDN. So if the user clicks on that link, he will fall back to server-side.
The solution is to whitelist https://app.gotomeeting.com/*
You can either add this to the ACL policy or to the Authentication Sites policy (or both).
The difference is that if you add it only to the ACL policy, if the user clicks on the link it will trigger a re-processing of the URL by the VDA (look up of that URL in the ACL entries), resulting in a few extra redirection steps.
If you add it to the Authentication Sites policy, then since the parent website is https://www.gotomeet.me/* and that is already whitelisted in the ACL policy, a re-processing of the URL by the VDA is not required and the experience is smoother (see last paragraph under the Teams section).
Of course there could be a scenario where the user types https://app.gotomeeting.com/index.html?meetingId=xxxxxxxxxx directly as the first URL in Chrome’s navigation bar. Browser Content Redirection will only kick-in if that URL is on the ACL policy (that is because the Authentication Sites policy is only processed after an ACL match). So in order to prevent this exact scenario from failing, you can add the URL to the ACL and Authentication Sites policies (and hence the reference to ‘both’ in the paragraph above).
Microsoft Stream
Microsoft’s corporate video-sharing platform runs as an Office 365 service.
The URL https://stream.microsoft.com/* needs to be whitelisted in the ACL policy.
That is because whitelisting https://web.microsoftstream.comwill not work, since that page redirects to login.microsoftonline.comusing HTTP response status code 302 Found, and that page in turn redirects to https://stream.microsoft.com.
Once the browser lands on that website, clicking on Sign In will redirect to https://login.microsoftonline.com/common/oauth2/*microsoftstream*
where the user finally will insert his credentials.
Hence the site https://login.microsoftonline.com/*microsoftstream* needs to be added to Authentication Sites.
(This is different from the behavior in Teams).
If you are using SSO solutions like OKTA, or ADFS, the URLs will need to be added under Authentication Sites also.
Finally, also add https://web.microsoftstream.com/* to the Authentication Sites.
Google Meet and Google Hangouts
Add https://meet.google.com/* to the ACL policy.
Add https://hangouts.google.com/* to the ACL policy.
Important: Add https://accounts.google.com/* to the Authentication Sites policy.
Any other website used for SSO (e.g. Okta) must be added to the Authentication Sites policy (it could be more than one).
These websites require WebRTC support, hence you must use Citrix Workspace app 1809 for Windows or higher.
Currently, outgoing screensharing is not supported when using BCR.
Cisco Webex Teams
Add https://teams.webex.com/* to the ACL policy.
Add https://idbroker.webex.com/* to the Authentication Sites policy. This entry might vary depending on your Organization’s SSO configuration and IdP providers. Any website used for SSO must be added to the Authentication Sites policy (it could be more than one).
Cisco Webex Meetings
Currently not supported since this website uses Content Security Policy (CSP). See CTX230052.
Citrix and Cisco are collaborating on this and are aiming to have a solution ready.
Related:
Secure Mail iOS 19.3.5 and Secure Mail Android 19.6.5 Not Able to Create Account or Connection Error
Before users can create an account in Secure Mail for iOS version 19.3.5 or Secure Mail Android 19.6.5, you must do the following:
1. On Citrix ADC, the following cipher suite value must be added in the SSL Ciphers option: – ECDHE-RSA-AES256-GCM-SHA384.
Note: If the ciphers are already bound, go to step 2.
2. Bind Enable Elliptical Curve Cryptography (ECC).
For details, see ECDSA cipher suites support in the Citrix ADC 12.1 documentation https://docs.citrix.com/en-us/citrix-adc/12-1/ssl/ciphers-available-on-the-citrix-ADC-appliances/ecdhe-ciphers.html.
For FIPS enabled environments, verify that the RSA key size for identity certificate (i.e. server certificate), intermediate certificates, and your root certificate are 2048 or 3072 bits. We do not currently support an RSA key size of 4096 bits in a FIPS-enabled environment . The new crypto library checks for key size and will reject the connection.
For configuration information see the following Citrix support article: https://support.citrix.com/article/CTX205289
Related:
Organizations urged to patch for BlueKeep as latest malware charts are revealed
SQL Injection tops the list, followed by Web Server Exposed Git Repository Information Disclosure, and OpenSSL TLS DTLS Heartbeat Information …
Related:
Offline Cryptographic Attacks Targeting the Wi-Fi Protected Access 2 Protocol
On August 4, 2018, Jens Steube from the Hashcat project published an article introducing a new method to obtain cryptographic information from wireless traffic that can then be used by an attacker to attempt the offline recovery of the preshared key (PSK) used to secure a Wi-Fi network.
Both the Wi-Fi Protected Access (WPA) and the Wi-Fi Protected Access 2 (WPA2) protocols are known to be susceptible to offline cryptographic attacks when a PSK is used as an authentication mechanism. This is not a new vulnerability or a new attack against these protocols. This is a new vector that allows an attacker to obtain the information required to attempt an offline attack against the PSK.
This new method is different from the existing attacks against the PSK because it does not require an attacker to wait for an Extensible Authentication Protocol over LAN (EAPOL) authentication exchange, capture it, and proceed to attempt an offline PSK recovery. This new vector allows an attacker to extract the required information from a single wireless frame transmitted during a roaming event. The following conditions for this capture apply:
- The frame contains a Robust Security Network-Pairwise Master Key Identification (RSN-PMKID) option
- The wireless infrastructure is configured to use WPA2 with a PSK mode of authentication
- The wireless infrastructure supports the Proactive Key Caching (PKC) fast roaming option (PMKID roaming)
The wireless frame can be acquired by passively listening to traffic from the wireless network during the roaming.
It is important to note that this method does not make it easier or faster to recover the PSK for a Wi-Fi network. Instead, it is easier for an attacker to collect the information required to conduct a subsequent offline cryptographic attack. The likelihood of a successful recovery of the PSK is highly dependent on the complexity of the PSK in use.
This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180809-wpa2
Security Impact Rating: Informational
Related:
Invalid certificate
I need a solution
Hello guys,
The client request to the google.com then client and server weren’t complete communication with google certificate. The problem is if client request to any website then using bluecoat certificate and the browser couldn’t verify that certificate. In ssl client configuriation include custom keyring and support for TLSv1.2, TLSv1.1, TLSv1, SSLv3* ssl protocols.
Thank you guys!
0