Security

by

How to disable vulnerable ciphers and encryption modes in Rocky Linux 8 to mitigate Terrapin Attack (CVE-2023-48795)

For more information on the Terrapin Attack (CVE-2023-48795), do take a look at Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted.

As mentioned, in the blog entry, Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted, the attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

The mitigation is similar to How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8 except that you have to remove the “chacha20-poly1305@openssh.com” besides the CBC Mode Ciphers.

Step 1: Edit /etc/sysconfig/sshd and uncomment CRYPTO_POLICY line:

CRYPTO_POLICY=

Edit /etc/ssh/sshd_config file. Add Ciphers, MACs and KexAlgorithms have been added

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

After making changes to the configuration file, you may want to do a sanity check on the configuration file

# sshd -t

Restart sshd services

# systemctl restart sshd

To test if weak CBC Ciphers and  ChaCha20-Poly1305 are enabled

$ ssh -vv -oCiphers=chacha20-poly1305@openssh.com,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc IP-Address-of-your-Server

You should receive a similar message

Unable to negotiate with 172.21.33.11 port 22: no matching cipher found. Their offer: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

To verify that the Terrapin Attack Vulnerability is mitigated, take a look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have an output like this.

References:

  1. Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted
  2. Terrapin Attack
  3. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  4. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know
by

Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted

What is Terrapin Attack (CVE-2023-48795)?

Researchers from Ruhr University announced the discovery of new vulnerabilities impacting the SSH Protocol. Detailed Information of the Terrapin Attack can be found at Terrapin Attack.

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

Terrapin is a man-in-the-middle attack; the flaw allows an attacker to corrupt data being transmitted. This can result in a loss of information or bypass critical security controls such as keystroke timing protections or SHA-2 cryptographic hash requirements, allowing the threat actor to downgrade to SHA-1. Doing so opens up the possibility of other attacks on downstream applications, components, or environments that use SSH. ​​These associated vulnerabilities have been assigned CVE-2023-46445 (Rogue Extension Negotiation Attack in AsyncSSH) and CVE-2023-46446 (Rogue Session Attack in AsyncSSH).

Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

How do I know that I am vulnerable?

The attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

How do I mitigate the attack?

To mitigate the attack, either you upgrade OpenSSH to their latest version 9.6 or disable the affected ciphers and encryption modes.

Vulnerability Impacts

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol, their assessment of the Attack are:

  • Limited Impacts: Terrapin can delete consecutive portions of encrypted messages, which in isolation will typically result in a stuck connection. Some of the most serious impacts identified are in downstream applications implementing SSH, such as AsyncSSH. An attacker may be able to disable certain keylogging obfuscation features, enabling them to conduct a keylogging attack; or, worst case, a threat actor can sign a victim’s client into another account without the victim noticing, enabling phishing attacks.
  • Difficult to Expliot: An active man-in-the-middle attacker and specific encryption modes are prerequisites for the exploit. Intercepting SSH traffic requires a detailed understanding of a target’s environment, limiting real-world applicability.

How do I check?

You may want to explore the vulnerablilty tool published by the Ruhr University Researchers:

For more information, do take look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

Usage is very simple, after downloading the relevant binary, just use the command

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have a output something like this.

If you are vulnerable, the scanner will flag as expected.

References:

  1. Terrapin Attack
  2. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  3. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know
by

Using the Host’s FirewallD as the Main Firewall to Secure Docker

Found a rare article How to Secure a Docker Host Using Firewalld that teaches how to address the issue when that docker bypasses the FirewallD rules.

According to the Article, the goal of the Configuration is to

  • The firewall rules should count for whole host system – so including Docker containers with port mappings
  • A Docker container should be accessible from the internet if and only if the host port used in Docker container port mapping is allowed in the firewall
  • The approach should not break container networking

Do read up and you will be glad that this article was written for Administrators like us. Another Reference you may want to consider reading is Why Docker and Firewall don’t get along with each other!

by

Microsoft leaks 38TB of private data via unsecured Azure storage

According to the Article “Microsoft leaks 38TB of private data via unsecured Azure storage“

The Microsoft AI research division accidentally leaked dozens of terabytes of sensitive data starting in July 2020 while contributing open-source AI learning models to a public GitHub repository.

Almost three years later, this was discovered by cloud security firm Wiz whose security researchers found that a Microsoft employee inadvertently shared the URL for a misconfigured Azure Blob storage bucket containing the leaked information.

Microsoft linked the data exposure to using an excessively permissive Shared Access Signature (SAS) token, which allowed full control over the shared files. This Azure feature enables data sharing in a manner described by Wiz researchers as challenging to monitor and revoke.

Microsoft leaks 28TB of private data via unsecure Azure storage

by

Azure looks like a house of cards collapsing under the weight of exploits and vulnerabilities

Taken from Microsoft comes under blistering criticism for “grossly irresponsible” security – ars Technica

Microsoft has once again come under blistering criticism for the security practices of Azure and its other cloud offerings, with the CEO of security firm Tenable saying Microsoft is “grossly irresponsible” and mired in a “culture of toxic obfuscation.”

The comments from Amit Yoran, chairman and CEO of Tenable, come six days after Sen. Ron Wyden (D-Ore.) blasted Microsoft for what he said were “negligent cybersecurity practices” that enabled hackers backed by the Chinese government to steal hundreds of thousands of emails from cloud customers………. 

Microsoft comes under blistering criticism for “grossly irresponsible” security
by

Massive Ransomware Campaign Targeting Unpatched Vmware ESXi Servers

From SINGCERT (https://www.csa.gov.sg/singcert/Alerts/AL-2023-015) dated 04 Feb 2023

There are reports of an ongoing ransomware campaign actively exploiting a vulnerability (CVE-2021-21974) in unpatched VMware ESXi servers.

Successful exploitation of the vulnerability could allow an attacker to perform remote code execution by triggering the heap-overflow issue in OpenSLP service.

The following versions of the products are affected by the aforementioned vulnerability:

•             ESXi versions 7.x earlier than ESXi70U1c-17325551

•             ESXi versions 6.7.x earlier than ESXi670-202102401-SG

•             ESXi versions 6.5.x earlier than ESXi650-202102101-SG

Users and administrators of affected product versions are advised to upgrade to the latest versions immediately. As a precaution, a full system scan should also be performed to detect any signs of compromise. Users and administrators are also advised to assess if the ransomware campaign-targeted port 427 can be disabled without disrupting operations.

Users and administrators may also wish to configure their firewall rules to block any connections to the following IP addresses purportedly carrying out the attacks:

  • 104.152.52[.]55
  • 193.163.125[.]138
  • 43.130.10[.]173
  • 104.152.52[.]0/24

More information can be found at

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2023-ALE-015/

https://www.csa.gov.sg/singcert/Advisories/ad-2021-009/

by

How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8

This writeup is reference from The Geek Diary

Edit /etc/sysconfig/sshd and uncomment CRYPTO_POLICY line:

CRYPTO_POLICY=

Edit /etc/ssh/sshd_config file. Add Ciphers, MACs and KexAlgorithms have been added

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

After making changes to the configuration file, you may want to do a sanity check on the configuration file

# sshd -t

Restart sshd services

# systemctl restart sshd

To test if weak CBC Ciphers are enabled

$ ssh -vv -oCiphers=3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc [youruserid@IP of your Server]

You should receive a aimilar message message 

Unable to negotiate with 172.21.33.13 port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

References:

by

Using SSLScan to determine supported cipers

SSLScan queries SSL services to determine the ciphers that are supported. This is a very useful tool if you wish to

SSLScan is designed to be easy, lean and fast. The output includes preferred ciphers of the SSL service, and the certificate and is in text and XML formats.

The Project Site and Installation can be found at https://github.com/rbsec/sslscan

I was checking my Windows Server,

$ sslscan --rdp x.x.x.x
Version: 2.0.15-static
OpenSSL 1.1.1t-dev  xx XXX xxxx

Connected to x.x.x.x

Testing SSL server x.x.x.x on port 3389 using SNI name x.x.x.x

SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
.....
.....

You may want to scan by port level

$ sslscan x.x.x.x:8444
by

High-Severity Zero-Day Bug in Google Chrome

This article is taken from Singapore Computer Emergency Response Team (SINGCERT) titled High-Severity Zero-Day Bug in Google Chrome

Google has released Chrome 99.0.4844.84 for Windows, Mac, Linux and Chrome 99.0.4844.88 for Android users to address a high-severity zero-day bug (CVE-2022-1096). The vulnerability is a Type Confusion in V8 JavaScript engine exploit, and is reported to exist in the wild. V8 is Chrome’s component that is responsible for processing JavaScript code.

Type confusion refers to coding bugs during which an application initialises data execution operations using input of a specific “type” but is tricked into treating the input as a different “type”. This leads to logical errors in the application’s memory, which may allow an attacker to run unrestricted malicious codes inside an application.

No further technical details about the bug have been published by Google.

Google Chrome users on Windows, Mac and Linux are advised to upgrade to Chrome 99.0.4844.84 immediately by going into Chrome menu > Help > About Google Chrome, while Android users may refer to the Google Play Store for Chrome 99 (99.0.4844.88) version.

High-Severity Zero-Day Bug in Google Chrome
by

Apache Log4j Zero-Day Vulnerability

Taken from https://www.lunasec.io/docs/blog/log4j-zero-day/

What is Apache Log4j Zero-Day Vulnerability?

Apache Log4j has a serious unauthenticated Remote Code Execution (RCE) vulnerability which was just disclosed. The exploit code for this has also been released, and the vulnerability is actively exploited in the wild. By crafting a special string that is passed to the application/service log via Log4j, attackers can execute arbitrary code loaded from remote servers. This can potentially lead to a complete compromise of the server.

What versions are vulnerable?

Any software using Apache Log4j (as a component) version between 2.0 and 2.14.1, inclusive.

What do I need to do?

A. Servers running custom Java application/services

  1. If your Log4j version is vulnerable, install the latest patched version log4j-2.15.0-rc2 available on GitHub at https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2.

B. Servers running Commercial off-the-shelf (COTS) products

  1. Plese refer to https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 for a list of advisories from the major vendors and follow the advisory.

How can I check if I have been hacked/compromised?

Check your applications’ log files for strings resembling “jndi:ldap”.

For more information

See https://www.lunasec.io/docs/blog/log4j-zero-day/