VU#290915: F5 BIG-IP contains multiple vulnerabilities including unauthenticated remote command execution
F5 BIG-IP provides a Traffic Management User Interface (TMUI), also referred to as the Configuration utility, that has multiple vulnerabilities including a remotely exploitable command injection vulnerability that can be used to execute arbitrary commands and subsequently take control of a vulnerable system.Description
F5 BIG-IP devices provide load-balancing capability to application services such as HTTP and DNS. The F5 BIG-IP TMUI management web interface improperly neutralizes untrusted user input and can be abused by unauthenticated remote attackers to perform malicious activities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and command injection CWE-74. F5 has also announced that BIG-IP devices do not properly enforce access controls to sensitive configuration files that be read and overwritten by an authenticated user via Secure Copy (SCP). The vulnerability identified by CVE-2020-0592 can be abused to achieve arbitrary code execution on the target device with root privileges.
Underlying causes and factors in these vulnerabilities include:
- Certain components of the TMUI, such as tmshCmd.jsp, operate with high privileges
- The TMUI fails to enforce proper authentication and authorization, see OWASP Recommendations
- The TMUI web interface does not normalize user's input to prevent both XSS and CSRF, allowing a "Deadly Combinations of XSS and CSRF"
- Lack of role-based access checks allows for for unexpected file access, see Role-Based Access Control Models
F5 recommends that the TMUI web interface should be accessible only from a secure or an out-of-band network and not directly from the Internet (K13092). However, many installations, as observed by Bad Packets, do not seem to follow this recommendation.Impact
An unauthenticated attacker with network access to the TMUI may be able to execute arbitrary system commands, create or delete files, disable services, and subsequently execute arbitrary code with high privileges such as root. An authenticated user is also be able to perform unexpected activities such as changing configuration files on a vulnerable device.Solution Apply updates
F5 has provided updated software for the several impacted versions of BIG-IP devices. Note that BIG-IP appliances as well as virtual instances are also vulnerable as identified by F5 advisories. It is highly recommended that you upgrade to the latest secure and stable software provided by F5. These updates are essential to your device's security, even if the TMUI is not accessible over the Internet. The upgrade reduces the risk to your device being compromised using CSRF or XSS attacks.Workarounds
In many cases, an attack against BIG-IP's recent vulnerabilities require access to TMUI. Blocking or disabling access to TMUI from untrusted networks is highly recommended. F5 has also provided multiple temporary workaround options in their advisory.Acknowledgements
Several of these vulnerabilities were reported by Mikhail Klyuchnikov of Positive Technologies, who worked with F5 on a coordinated disclosure.
This document was written by Vijay Sarvepalli.
Multiple Netgear devices contain a stack buffer overflow in the httpd web server's handling of upgrade_check.cgi, which may allow for unauthenticated remote code execution with root privileges.Description
Many Netgear devices contain an embedded web server, which is provided by the httpd process, to provide administrative capabilities. On multiple Netgear devices, this code fails to properly validate the header size provided to the upgrade_check.cgi handler. Despite copying the header to a fixed-size buffer on the stack, the vulnerable code copies an attacker-provided count of bytes from attacker-provided data. This allows for remote code execution by way of stack buffer overflow. This vulnerability is exacerbated by a number of issues:
- The httpd process runs with root privileges.
- Stack cookies, which can help prevent exploitation of stack buffer overflows, are not universally used in Netgear devices.
- Authentication is not required to reach the vulnerable code.
- The vulnerability occurs before Cross-Site Request Forgery (CSRF) token checking occurs.
- Target device fingerprinting can occur by visiting the /currentsetting.htm page on an affected device.
Exploit code that targets 79 different Netgear devices is publicly available.Impact
By convincing a user to visit a malicious or compromised website, a remote, unauthenticated attacker may be able to execute arbitrary code on a vulnerable device with root privileges.Solution Apply an update
Netgear has provided updates for several vulnerable devices. Note that Netgear does not indicate when devices have reached an end of life (EOL) state. This may be difficult to determine if a vulnerable device may receive an update in the future.
The CERT/CC has made a spreadsheet to more clearly indicate which devices have updates, and which devices may either be receiving an update in the future, or may possibly be unsupported.
As outlined in the blog post It's Time to Retire Your Unsupported Things, you should factor the vendor's support life span into purchasing decisions. Vendors that indicate how long products will be supported should be preferred over those that do not clearly indicate how long a device will be supported. Similarly, vendors that clearly indicate when a product has reached EOL state should be preferred over vendors that do not.Acknowledgements
This vulnerability was publicly disclosed by ZDI, who in turn credit d4rkn3ss from VNPT ISC. Additional analysis was provided by GRIMM.
This document was written by Will Dormann.
Treck IP stack implementations for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by JSOF, who calls them Ripple20.Description
Treck IP network stack software is designed for and used in a variety of embedded systems. The software can be licensed and integrated in various ways, including compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library. Treck IP software contains multiple vulnerabilities, most of which are caused by memory management bugs. For more details on the vulnerabilities introduced by these bugs, see Treck's Vulnerability Response Information and JSOF's Ripple20 advisory.
Historically-related KASAGO TCP/IP middleware from Zuken Elmic (formerly Elmic Systems) is also affected by some of these vulnerabilities.
These vulnerabilities likely affect industrial control systems and medical devices. Please see ICS-CERT Advisory ICSA-20-168-01 for more information.Impact
The impact of these vulnerabilities will vary due to the combination of build and runtime options used while developing different embedded systems. This diversity of implementations and the lack of supply chain visibility has exasperated the problem of accurately assessing the impact of these vulnerabilities. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or execute arbitrary code.Solution Apply updates
Update to the latest stable version of Treck IP stack software (184.108.40.206 or later). Please contact Treck at firstname.lastname@example.org. Downstream users of embedded systems that incorporate Treck IP stacks should contact their embbeded system vendor.Block anomalous IP traffic
Consider blocking network attacks via deep packet inspection. In some cases, modern switches, routers, and firewalls will drop malformed packets with no additional configuration. It is recommended that such security features are not disabled. Below is a list of possible mitigations that can be applied as appropriate to your network environment.
- Normalize or reject IP fragmented packets (IP Fragments) if not supported in your environment
- Disable or block IP tunneling, both IPv6-in-IPv4 or IP-in-IP tunneling if not required
- Block IP source routing and any IPv6 deprecated features like routing headers (see also VU#267289)
- Enforce TCP inspection and reject malformed TCP packets
- Block unused ICMP control messages such MTU Update and Address Mask updates
- Normalize DNS through a secure recursive server or application layer firewall
- Ensure that you are using reliable OSI layer 2 equipment (Ethernet)
- Provide DHCP/DHCPv6 security with feature like DHCP snooping
- Disable or block IPv6 multicast if not used in switching infrastructure
Further recommendations are available here.Detect anomalous IP traffic
Suricata IDS has built-in decoder-event rules that can be customized to detect attempts to exploit these vulnerabilities. See the rule below for an example. A larger set of selected vu-257161.rules are available from the CERT/CC Github repository.
#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896, CVE-2020-11900 Fragments inside IP-in-IP tunnel https://kb.cert.org/vuls/id/257161"; ip_proto:4; fragbits:M; sid:1367257161; rev:1;)
Moshe Kol and Shlomi Oberman of JSOF https://jsof-tech.com researched and reported these vulnerabilities. Treck worked closely with us and other stakeholders to coordinate the disclosure of these vulnerabilities.
This document was written by Vijay Sarvepalli.
pppd (Point to Point Protocol Daemon) versions 2.4.2 through 2.4.8 are vulnerable to buffer overflow due to a flaw in Extensible Authentication Protocol (EAP) packet processing in eap_request and eap_response subroutines.Description
PPP is the protocol used for establishing internet links over dial-up modems, DSL connections, and many other types of point-to-point links including Virtual Private Networks (VPN) such as Point to Point Tunneling Protocol (PPTP). The pppd software can also authenticate a network connected peer and/or supply authentication information to the peer using multiple authentication protocols including EAP.
Due to a flaw in the Extensible Authentication Protocol (EAP) packet processing in the Point-to-Point Protocol Daemon (pppd), an unauthenticated remote attacker may be able to cause a stack buffer overflow, which may allow arbitrary code execution on the target system. This vulnerability is due to an error in validating the size of the input before copying the supplied data into memory. As the validation of the data size is incorrect, arbitrary data can be copied into memory and cause memory corruption possibly leading to execution of unwanted code.
The vulnerability is in the logic of the eap parsing code, specifically in the eap_request() and eap_response() functions in eap.c that are called by a network input handler. These functions take a pointer and length as input using the the first byte as a type. If the type is EAPT_MD5CHAP(4), it looks at an embedded 1-byte length field. The logic in this code is intended to makes sure that embedded length is smaller than the whole packet length. After this verification, it tries to copy provided data (hostname) that is located after the embedded length field into a local stack buffer. This bounds check is incorrect and allows for memory copy to happen with an arbitrary length of data.
An additional logic flaw causes the eap_input() function to not check if EAP has been negotiated during the Link Control Protocol (LCP) phase. This allows an unauthenticated attacker to send an EAP packet even if ppp refused the authentication negotiation due to lack of support for EAP or due to mismatch of an agreed pre-shared passphrase in the LCP phase. The vulnerable pppd code in eap_input will still process the EAP packet and trigger the stack buffer overflow. This unverified data with an unknown size can be used to corrupt memory of the target system. The pppd often runs with high privileges (system or root) and works in conjunction with kernel drivers. This makes it possible for an attacker to potentially execute arbitrary code with system or root level privileges.
The pppd software is also adopted into lwIP (lightweight IP) project to provide pppd capabilities for small devices. The default installer and packages of lwIP are not vulnerable to this buffer overflow. However if you have used the lwIP source code and configured specifically to enable EAP at compile time, your software is likely vulnerable to the buffer overflow. The recommended update is available from Git repoistory http://git.savannah.nongnu.org/cgit/lwip.git.
This type of weakness is commonly associated in Common Weakness Enumeration (CWE) with CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'). A Proof-of-Concept exploit for PPTP VPN Servers with additional tools are available in the by CERT/CC PoC repository.
By sending an unsolicited EAP packet to a vulnerable ppp client or server, an unauthenticated remote attacker could cause memory corruption in the pppd process, which may allow for arbitrary code execution.Solution Apply updates
Update your software with the latest available patches provided by your software vendor. It is incorrect to assume that pppd is not vulnerable if EAP is not enabled or EAP has not been negotiated by a remote peer using a secret or passphrase. This is due to the fact that an authenticated attacker may still be able to send unsolicited EAP packet to trigger the buffer overflow.
If your software is packaged and created from the ppp source code, please obtain the latest software from github pppd repository.
Patch referenced :
In case of lwIP package that is compiled from source with EAP enabled at compile time, obtain the latest software from github
Note: the latest software also includes ignoring out-of-order or unsolicited EAP packets from being processed as an additional precautionary measure. It is recommended that you use the latest available software from the appropriate Git repository that includes this fix.
A proof-of-concept for testing if a PPTP server is vulnerable to cve-2020-8597 is available in the CERT/CC PoC respositoryDetection Signature (IDS)
A Snort/Surricata IDS rule to detect cve-2020-8597 buffer overflow attempts against PPTP servers is also available in the CERT/CC PoC respository.Workaround
There is no viable work around except to patch the software with updated software made available by the software vendors.Acknowledgements
Thanks to Ilja Van Sprundel from IOActive for reporting this vulnerability.
This document was written by Vijay Sarvepalli.
Microsoft SMBv3 contains a vulnerability in the handling of compression, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. This vulnerability is being referred to as "SMBGhost and CoronaBlue."Description
Microsoft Server Message Block 3.1.1 (SMBv3) contains a vulnerability in the way that it handles connections that use compression. This vulnerability may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. It has been reported that this vulnerability is "wormable."Impact
By connecting to a vulnerable Windows machine using SMBv3, or by causing a vulnerable Windows system to initiate a client connection to a SMBv3 server, a remote, unauthenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.Solution
Apply an update
This issue has been addressed in the Microsoft update for CVE-2020-0796. Please also consider the following workarounds:
Disable SMBv3 compression
According to Microsoft Security Advisory ADV200005 :
You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force
1. No reboot is needed after making the change.
2. This workaround does not prevent exploitation of SMB clients.
You can disable the workaround with the PowerShell command below.
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force
Block inbound and outbound SMB
Consider blocking outbound SMB connections (TCP port 445 for SMBv3) from the local network to the WAN. Also ensure that SMB connections from the internet are not allowed to connect inbound to an enterprise LAN. Acknowledgements
This document was written by Will Dormann.