InfoSec News

Citrix patches 11 critical bugs

By

InfoSec News

Citrix patches 11 critical bugs

By William Knowles @c4i
Senior Editor
InfoSec News
July 8, 2020

In a breath of fresh air for this week, software vendor Citrix released patches for 11 vulnerabilities, quickly applying the lesson learned six months ago and not wanting a repeat with malicious hackers looking for ways to exploit the vulnerability.

Citrix Chief Information Security Officer, Fermin J. Serna released a bulletin on Tuesday, July 7, which covered a set of vulnerabilities in Citrix’s products— Citrix ADC, Citrix Gateway, and Citrix SD-WAN WANOP edition. Standard procedure for most software companies in advising customers of vulnerabilities is limited to the publication of the bulletin and related CVEs.

Serna took the opportunity to explain the following points as it relates to CTX276688.

  • The latest patches fully resolve all the issues.
  • Of the 11 vulnerabilities, there are six possible attack routes; five of those have barriers to exploitation.
  • We are not aware of any exploitation of these issues.
  • Citrix-managed Gateway service is not affected.
  • And finally, these vulnerabilities are not related to CVE-2019-19781.

Barriers to Exploitation

There are barriers to many of these attacks; in particular, for customers where there is no untrustworthy traffic on the management network, the remaining risk reduces to a denial-of-service attack. And in that case, only when Gateway or authentication virtual servers are being used. Other virtual servers, for example, load balancing and content switching virtual servers, are not affected by the issue.

Three of the six possible attacks in CTX276688 occur in the management interface of a vulnerable device. Systems deployed in line with Citrix recommendations will already have this interface separated from the network and protected by a firewall. That configuration greatly diminishes the risk.

Further, while I am not discounting the risk of privilege escalation, two of the remaining three possible attacks additionally require some form of existing access. That effectively means an external malicious actor would first need to gain unauthorized access to a vulnerable device to be able to conduct an attack.

While these barriers reduce the risk of these vulnerabilities, Citrix strongly recommends quick application of the supplied patches.

To help our customers and the industry understand these vulnerabilities, I have included a brief summary of the vulnerabilities, the affected products, and the attack vector in the table form below. The security bulletin and CVEs provide much greater detail and should be used for technical guidance.

CVE-2019-19781

There is no technical link between CVE-2019-19781 and CTX276688. Further, with CVE-2019-19781, we took the unusual step of publishing temporary mitigations in December, with subsequent permanent patches being available in January 2020. We took that step because of a high likelihood an exploit was “in the wild” and temporary mitigations gave our customers a chance to protect themselves. That is in stark contrast to the current situation: with the vulnerabilities in CTX276688, at the time of this publication, we know of no malicious exploits and have published patches that fully resolve the issues.

Citrix SD-WAN WANOP

Customers on Citrix SD-WAN WANOP should also pay heed to the advisory just released as ADC is a component within the SD-WAN WANOP deployment. Fixes are available at https://www.citrix.com/downloads/citrix-sd-wan/

Protecting Our Customers

We are limiting the public disclosure of many of the technical details of the vulnerabilities and the patches to further protect our customers. Across the industry, today’s sophisticated malicious actors are using the details and patches to reverse engineer exploits. As such, we are taking steps to advise and help our customers but also do what we can to shield intelligence from malicious actors.

Related, we have added staff to our technical support call centers and are prepared to assist our customers. We’ve built and tested our patches to high standards, both to ensure effectiveness but also with the ease of implementation in mind.

Bottom line: patches are available, and we encourage our customers to apply them to reduce risk.

You can use Citrix ADM Service for simplified and bulk upgrade of all your Citrix ADC instances. Please refer to this documentation to learn more. Citrix ADM Service is a SaaS solution available on Citrix Cloud to help manage, monitor, analyze, and troubleshoot your global hybrid multi-cloud application delivery infrastructure from a single touchpoint. It helps with faster time to value and brings in operational efficiency. Here is a video to help get you onboarded to Citrix ADM Service. You can also view our documentation here.

Also of note, we remain committed to incorporating feedback from our customers and adapting our communication and customer support offerings as needed.

As noted in this blog, we recently updated our vulnerability processes, and we published those updates on the Citrix Trust Center website.  These updates include enhancements in our processes around international standard ISO/IEC 29147:2018; an opportunity to apply for pre-notification of security bulletins; and the Hall of Fame honoring those third parties that work collaboratively and responsibly with us to improve the security of our products.

CVE ID Vulnerability Type Affected Products Attacker Privileges Pre-conditions
CVE-2019-18177 Information disclosure Citrix ADC, Citrix Gateway Authenticated VPN user Requires a configured SSL VPN endpoint
CVE-2020-8187 Denial of service Citrix ADC, Citrix Gateway 12.0 and 11.1 only Unauthenticated remote user Requires a configured SSL VPN or AAA endpoint
CVE-2020-8190 Local elevation of privileges Citrix ADC, Citrix Gateway Authenticated user on the NSIP This issue cannot be exploited directly. An attacker must first obtain nobody privileges using another exploit
CVE-2020-8191 Reflected Cross Site Scripting (XSS) Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Unauthenticated remote user Requires a victim who must open an attacker-controlled link in the browser while being on a network with connectivity to the NSIP
CVE-2020-8193 Authorization bypass Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Unauthenticated user with access to the NSIP Attacker must be able to access the NSIP
CVE-2020-8194 Code Injection Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Unauthenticated remote user Requires a victim who must download and execute a malicious binary from the NSIP
CVE-2020-8195 Information disclosure Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Authenticated user on the NSIP –
CVE-2020-8196 Information disclosure Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Authenticated user on the NSIP –
CVE-2020-8197 Elevation of privileges Citrix ADC, Citrix Gateway Authenticated user on the NSIP –
CVE-2020-8198 Stored Cross Site Scripting (XSS) Citrix ADC, Citrix Gateway, Citrix SDWAN WANOP Unauthenticated remote user Requires a victim who must be logged in as an administrator (nsroot) on the NSIP
CVE-2020-8199 Local elevation of privileges Citrix Gateway Plug-in for Linux Local user on the Linux computer running Citrix Gateway Plug-in A pre-installed version of Citrix Gateway Plug-in for Linux must be running

USCYBERCOM urgently recommends F5 customers to patch CVE-2020-5902 and 5903 NOW

By

InfoSec News

By William Knowles @c4i
Senior Editor
InfoSec News
July 6, 2020

Just in case you accidentally had your work phone and duty pager in a Faraday bag all July 4th holiday weekend long, you have one heckuva surprise waiting for you!

As F5 reminds everyone that 48 of Fortune 50 companies are F5 customers, F5 has published a security advisory warning to their customers to patch a critical flaw in their BIG-IP product and proof-of-concept attacks are already starting to show up on Twitter.

The Traffic Management User Interface (TMUI), also referred to as the Configuration utility, has a Remote Code Execution (RCE) vulnerability in undisclosed pages. (CVE-2020-5902)

Impact

This vulnerability allows for unauthenticated attackers, or authenticated users, with network access to the TMUI, through the BIG-IP management port and/or Self IPs, to execute arbitrary system commands, create or delete files, disable services, and/or execute arbitrary Java code. This vulnerability may result in complete system compromise. The BIG-IP system in Appliance mode is also vulnerable. This issue is not exposed on the data plane; only the control plane is affected.

Security Advisory Status

F5 Product Development has assigned IDs 895525, 900757, 895981, and 895993 (BIG-IP) to this vulnerability. To determine if your product and version have been evaluated for this vulnerability, refer to the Applies to (see versions) box. To determine if your release is known to be vulnerable, the components or features that are affected by the vulnerability, and for information about releases, point releases, or hotfixes that address the vulnerability, refer to the following table. For more information about security advisory versioning, refer to K51812227: Understanding Security Advisory versioning.

Product Branch Versions known to be vulnerable Fixes introduced in Severity CVSSv3 score1 Vulnerable component or feature
BIG-IP (LTM, AAM, AFM, Analytics, APM, ASM, DNS, FPS, GTM, Link Controller, PEM) 15.x 15.1.0 15.1.0.4 Critical 10.0 TMUI/Configuration utility
15.0.0 None
14.x 14.1.0 – 14.1.2 14.1.2.6
13.x 13.1.0 – 13.1.3 13.1.3.4
12.x 12.1.0 – 12.1.5 12.1.5.2
11.x 11.6.1 – 11.6.5 11.6.5.2
BIG-IQ Centralized Management 7.x None Not applicable Not vulnerable None None
6.x None Not applicable
5.x None Not applicable
Traffix SDC 5.x None Not applicable Not vulnerable None None

1The CVSSv3 score link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge.

Security Advisory Recommended Actions

If you are running a version listed in the Versions known to be vulnerable column, you can eliminate this vulnerability by upgrading to a version listed in the Fixes introduced in column. If the table lists only an older version than what you are currently running, or does not list a non-vulnerable version, then no upgrade candidate currently exists. Mitigation F5 recommends upgrading to a fixed software version to fully mitigate this vulnerability. If you are leveraging public cloud marketplaces (AWS, Azure, GCP, and Alibaba) to deploy BIG-IP Virtual Edition (VE), F5 recommends upgrading to the latest releases of BIG-IP versions listed in the Fixes introduced in column subject to their availability on those marketplaces. If it is not possible to upgrade at this time, you can use the following sections as temporary mitigations:

All network interfaces To eliminate the ability for unauthenticated attackers to exploit this vulnerability, add a LocationMatch configuration element to httpd. To do so perform the following procedure: Note: Authenticated users will still be able to exploit the vulnerability, independent of their privilege level. Impact of workaround: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the TMOS Shell (tmsh) by entering the following command:tmsh
  2. Edit the httpd properties by entering the following command:edit /sys httpd all-properties
  3. Locate the include section and add the following:include ‘ <LocationMatch “.*\.\.;.*”> Redirect 404 / </LocationMatch> ‘
  4. Write and save the changes to the configuration file by entering the following commands:Esc :wq!
  5. Save the configuration by entering the following command:save /sys config
  6. Restart the httpd service by entering the following command:restart sys service httpd

Self IPs Block all access to the TMUI of your BIG-IP system via Self IPs. To do so, you can change the Port Lockdown setting to Allow None for each Self IP in the system. If you must open any ports, you should use Allow Custom, taking care to disallow access to TMUI. By default, TMUI listens on TCP port 443; however, beginning in BIG-IP 13.0.0, Single-NIC BIG-IP VE deployments use TCP port 8443. Alternatively, a custom port may be configured. Note: This prevents all access to the TMUI/Configuration utility via the Self IP. These changes may also impact other services. Before making changes to the configuration of your Self IPs, refer to the following:

Management interface To mitigate this vulnerability for affected F5 products, you should only permit management access to F5 products over a secure network. For more information about securing access to BIG-IP systems, refer to K13309: Restricting access to the Configuration utility by source IP address (11.x – 15.x) and K13092: Overview of securing access to the BIG-IP system. Note: Authenticated users accessing TMUI will always be able to exploit this vulnerability until a fixed release is installed.

Acknowledgements

F5 would like to acknowledge Mikhail Klyuchnikov of Positive Technologies for bringing this issue to our attention and for following the highest standards of coordinated disclosure.

Supplemental Information

 

National Security Agency releases Securing IPsec Virtual Private Networks

By

InfoSec News

By William Knowles @c4i
Senior Editor
InfoSec News
July 3, 2020

On the heels of the tweet from USCYBERCOM earlier in the week advising users of Palo Alto Networks to patch all devices affected by CVE-2020-2021 immediately, especially if SAML is in use. On Thursday, the National Security Agency released Securing IPsec Virtual Private Networks.

Many organizations currently utilize IP Security (IPsec) Virtual Private Networks (VPNs) to connect remote sites and enable telework capabilities. These connections use cryptography to protect sensitive information that traverses untrusted networks. To protect this traffic and ensure data confidentiality, it is critical that these VPNs use strong cryptography.

This guidance identifies common VPN misconfigurations and vulnerabilities.

Maintaining a secure VPN tunnel can be complex and requires regular maintenance. To maintain a secure VPN, network
administrators should perform the following tasks on a regular basis:

  • Reduce the VPN gateway attack surface
  • Verify that cryptographic algorithms are Committee on National Security Systems Policy (CNSSP) 15-compliant
  • Avoid using default VPN settings
  • Remove unused or non-compliant cryptography suites
  • Apply vendor-provided updates (i.e. patches) for VPN gateways and clients

Reduce the VPN gateway attack surface

VPN gateways tend to be directly accessible from the Internet and are prone to network scanning, brute force attacks, and zero-day vulnerabilities. To mitigate many of these vulnerabilities, network administrators should implement strict traffic filtering rules to limit the ports, protocols, and IP addresses of network traffic to VPN devices. If traffic cannot be filtered to a specific IP address, NSA recommends an Intrusion Prevention System (IPS) in front of the VPN gateway to monitor for undesired IPsec traffic and inspect IPsec session negotiations.

Verify only CNSSP 15-compliant algorithms are in use

All IPsec VPN configurations require at least two items: (1) the Internet Security Association and Key Management Protocol (ISAKMP) or Internet Key Exchange (IKE) policy; and (2) the IPsec policy. If the cryptography on either of these policies is configured to allow obsolete cryptographic algorithms, the entire VPN is at risk and data confidentiality may be lost. Annex B of CNSSP 15 provides guidance on using strong cryptography [1]. As the computing environment evolves and new weaknesses in algorithms are identified, administrators should prepare for cryptographic agility: periodically check CNSSP and NIST guidance for the latest cryptographic requirements, standards, and recommendations.

When configuring ISAKMP/IKE, many vendors support having several possible ISAKMP/IKE policies. The device then chooses the strongest matching policy between the remote and local ends of the VPN. Some vendors do this through priority numbers and others through explicit selection. NSA recommends configuring only those policies that meet the minimum level of security and removing any legacy policies. Also, if priority numbers are used, the strongest ISAKMP/IKE policy should be the highest priority. Many vendors also support configuring multiple IPsec policies; however, these policies are normally explicitly configured for a specific VPN. NSA recommends utilizing the strongest cryptography suites supported by the network device.

The best way to verify that existing VPN configurations are using approved cryptographic algorithms is to review the current ISAKMP/IKE and IPsec security associations (SAs). NSA recommends using this approach when reviewing ISAKMP/IKE and IPsec configurations because it displays the exact cryptography settings that were negotiated. Otherwise, administrators may miss connections where a device is selecting a non-compliant algorithm that was a device default or left over from a previous VPN configuration. If SAs are identified with non-compliant algorithms, administrators should immediately investigate why the VPN negotiated a lower cryptography standard and make appropriate configuration changes. Also, if utilizing pre-shared keys for VPN, NSA recommends that all keys be replaced as they may be compromised.

Avoid using default VPN settings

Due to the complexity of establishing a VPN, many vendors provide default configurations, automated configuration scripts, or graphical user interface wizards to aid in the deployment of VPNs. These tools take care of setting up the various aspects of a VPN to include ISAKMP/IKE and IPsec policies. However, many will configure a wide range of cryptography suites to ensure compatibility with the remote side of a VPN. NSA recommends avoiding these tools as they may allow undesired cryptography suites. If these tools are used, evaluate all configuration settings that the tool deployed. Administrators should then remove any non-compliant ISAKMP/IKE and IPsec policies. As a best practice, administrators should not utilize any default settings and ensure that all ISAKMP/IKE and IPsec policies are explicitly configured for the CNSSP 15-compliant algorithms.

Remove unused or non-compliant cryptography suites

It is very common for vendors to include extra ISAKMP/IKE and IPsec policies by default. These extra policies may include non-compliant cryptographic algorithms. Leaving extra ISAKMP/IKE and IPsec policies as acceptable policies creates a vulnerability to downgrade attacks. In downgrade attacks, a malicious user or Man-in-the-Middle offers only obsolete cryptography suites and forces the VPN endpoints to negotiate non-compliant cryptography suites. In doing so, it leaves the encrypted VPN vulnerable to decryption. Verifying that only compliant ISAKMP/IKE and IPsec policies are configured and all unused or non-compliant policies are explicitly removed from the configuration mitigates this risk. NSA also recommends periodically validating that only compliant policies are configured as the use of automated tools, graphical interfaces, or user error could reintroduce these non-compliant policies.

Apply vendor-provided updates

After ensuring that all configuration settings are using compliant cryptography suites and removing all non-compliant suites, implement a robust patch management procedure. Over the past several years, multiple vulnerabilities have been released related to IPsec VPNs. Many of these vulnerabilities are only mitigated by routinely applying vendor-provided patches to VPN gateways and clients. Many network equipment vendors allow customers to sign up for notification emails for new security alerts. These notifications are an excellent way to stay up-to-date on relevant out-of-cycle patches.

Protect the essential

VPNs are essential for enabling remote access and securely connecting remote sites, but without proper configuration, patch management, and hardening, VPNs are vulnerable to attack. To ensure that the confidentiality and integrity of a VPN is protected, reduce the VPN gateway attack surface, always use CNSSP 15-compliant cryptography suites, avoid using vendor defaults, disable all other cryptography suites, and apply patches in a timely manner.

Works Cited

[1] “Use of Public Standards for Secure Information Sharing.” Committee on National Security Systems, 20 October 2016. [Online] Available at https://www.cnss.gov/CNSS/issuances/Policies.cfm

Related Guidance

Appendix A: Reducing VPN Gateway Attack Surface Examples

New Zealand CERT issues advisory on ransomware campaign

By

InfoSec News

New Zealand CERT issues advisory on ransomware campaign

By William Knowles
Senior Editor
InfoSec News
June 18, 2020

The New Zealand Computer Emergency Response Team (CERT NZ) has released an advisory on a ransomware campaign leveraging remote access technologies.

Unknown malicious cyber bad actors are targeting organizations’ networks through remote access tools, such as Remote Desktop Protocol and virtual private networks, to exploit unpatched vulnerabilities and weak authentication.

After gaining access, these cyber bad actors use various tools including mimikatz, PsExec, Cobalt Strike, and Nefilim ransomware for privilege escalation, lateral movement, persistence, and data exfiltration and encryption. The issue cannot be resolved by simply restoring data from backup due to the level of access gained before deploying ransomware.

Active ransomware campaign leveraging remote access technologies

We are aware of attackers accessing organizations’ networks through remote access systems such as remote desktop protocol (RDP) and virtual private networks (VPN), as a way to create ransomware attack opportunities. They are gaining access through weak passwords, organizations not using multi-factor authentication as an extra layer of security, or a remote access system that isn’t patched.

The current attacks are believed to be sophisticated and well crafted. These attacks can have severe impacts on business operations, including data being stolen and sold. Recovery from these attacks requires significant investment to fully investigate and remediate the network compromised, and restore encrypted files from backup.

What’s happening

Systems affected

Attackers access an organization’s network through vulnerable remote access technologies. This could be by:

  • unpatched software,
  • weak authentication, or
  • lack of multi-factor authentication (MFA).

From there, any system on the network may be affected. Citrix remote access technologies have been reported as a common way for attackers to gain access.

What this means

Once an attacker gains a foothold through the remote access system, they use tools such as mimikatz, psexec, and Cobalt Strike to elevate privileges, move laterally across a network, and establish persistence on the network.

The attacker identifies and extracts sensitive information from the network and encrypts files. Nefilim ransomware has commonly been used, but other ransomware can also be used. Once the attacker has the information, they want they attempt to sell or publicly release the information.

Due to the level of access gained before deploying ransomware, merely restoring data from a backup won’t resolve the issue. Remediation will require an in-depth investigation of all compromised or potentially compromised systems to fully eradicate the attacker and to identify the security improvements necessary to prevent another attack.

What to look for

How to tell if you’re at risk

Any network that has does not have appropriately secure remote access is at risk.

How to tell if you’re affected

Check your remote access systems for any sign of unauthorized access. If any unauthorized access is detected, further investigation will be required to determine any lateral movement across the network.

If an attack has progressed to the ransomware phase, Nefilim ransomware may leave the following indicators of compromise (IOCs):

  • files with a .NEFILIM extension
  • a file called NEFILIM-DECRYPT.txt may be placed on affected systems
  • batch files created in C:\Windows\Temp

The following public reporting includes IOCs specific to Nefilim ransomware:

What to do

Prevention

Ensure that all remote access systems are:

  • up-to-date with security patches
  • strictly enforcing strong authentication (strong passwords and MFA).

Mitigation

CERT NZ Critical Controls such as network segmentation and application whitelisting can mitigate the impact of such an attack, by making it harder for an attacker to move around your network. Well-configured backups are essential to recovery from any ransomware attack.

More information

Advisory: exploitation of Citrix remote access systems

CERT NZ critical controls

If you require more information or further support, submit a report on our website.

Report an incident to CERT NZ

Defense Contractor Compromised with MAZE Ransomware

By

InfoSec News

Westech MAZE Ransomware Compromise; InfoSec News asks an Expert About the Fallout

By William Knowles @c4i
Senior Editor
InfoSec News
June 8, 2020

Troubling Cybersecurity/National Security news via Sky News, which is reporting that criminal hackers have stolen confidential information from Westech International. Westech serves as a U.S. military contractor for a number of Washington D.C. based companies such as Northrop Grumman, Booz Allen Hamilton, General Dynamics Information Technology (GDIT), and Science Applications International Corporation.

Westech International provides U.S. government and military clients a wide of services like Testing and Evaluation for the Army Intelligence Electronic Warfare Test Directorate, Mission Systems Support (T&E MSS) to The Joint Interoperability Test Command (JITC), Cybersecurity and unsecured and secured network support for Intelligence Electronic Warfare Test Directorate at Fort Huachuca, AZ and supports the ICBM Ground Subsystem Support Contract (GSSC) for the Minuteman III ICBM project.

A spokesperson for Westech told Sky News that Westech International has confirmed that it been breached and that its computers have been encrypted. “We recently experienced a ransomware incident, which affected some of our systems and encrypted some of our files,” Westech said in a media statement.

A number of news outlets are saying Westech International’s computers were encrypted with the MAZE ransomware, I asked Dan Wolfford, Co-founder & CTO of Dyrwolf, which is the first and only ransomware prevention & recovery platform to help organizations of all sizes protect their data, on his impressions of the MAZE ransomware.

“We believe the group behind MAZE is a ransomware merchant with a strong record of success and a good reputation of keeping up their end of the deal. They also have an interesting revenue sharing strategy, where they pay affiliates a commission for attracting potential customers with their software. We started tracking them in our threat database last year, after researching FALLOUT and SPELEVO exploit kits.”

What is the likelihood of a payload being added to MAZE to jump networks within the organization as has been reported lately?

“This merchant and their affiliates have proven to be creative and adaptive, using malicious ads, traffic redirection, exploit kits, email campaigns, fake websites, fake cryptocurrency apps, browser exploits, impersonation, data exfiltration, and leak extortion. Based on past performance, we believe it is highly likely they will continue to innovate in this space, adding new tactics and techniques to maximize profits.”

Does Westech International have a SIPRNet network connection?

“Most likely yes, because the Defense Information Systems Agency (DISA) Secret IP Router Network (SIPRNet) is available to mission partners and according to Shawn Purvis (Vice President and General Manager, Cyber Division, Northrop Grumman Information Systems), Northrop Grumman is proud to be DISA’s trusted partner.”

InfoSec News has reached out to Westech for further details and comments about the cyberattack including the timeline of the attack, attack vector(s), which cyber-security frameworks they use, and whether or not Westech International paid the ransom. If the attackers or malware they are using has the capability to move laterally, it is conceivable that it could reach a system connected to SIPRNet.

Westech International is a Woman-owned small business founded in 1995 by Dr. Betty Chao and based in Albuquerque, New Mexico.