Security

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/