Log4Shell Vulnerability - Details

What happened?

On December 9th, 2021, a zero-day exploit in the popular Java logging library “Log4J” (version 2) was discovered and widely publicized. The vulnerability can be used to execute code remotely, by tricking a system into logging a specific malicious string.

More technical details of this vulnerability can be found at this third-party resource

Who is impacted?​

Many, many services are vulnerable to this exploit. Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.

An extensive list of responses from impacted organizations has been compiled here.

Anybody using Apache Struts is likely vulnerable. We've seen similar vulnerabilities exploited before in breaches like the 2017 Equifax data breach.

Many Open Source projects like the Minecraft server, Paper, have already begun patching their usage of log4j2.

What is required of app developers?

Version 2.15.0 of the log4j library has been released, without the vulnerability. This release can be downloaded from Apache's official Log4j page, or from your language's package manager (Maven Central for example). App developers must immediately update any apps and integrations that use the Log4J Java library. Failure to do so may result in merchant data being compromised, and will put your application in violation

 
If upgrading is not possible, using the suggested temporary mitigation will also decrease the impact of the vulnerability. Common software solutions that may need patching or reconfiguration include Apache Solr, Apache Lucene, ElasticSearch, and other Java/JVM-based supporting applications

Remote desktop connection authentication error due to “CredSSP encryption oracle remediation” #GDPR

In March, Microsoft released a security update to address vulnerabilities for the Credential Security Support Provider protocol (CredSSP) used by Remote Desktop Protocol (RDP) connections for Windows clients and Windows Server.

Previously, you were able to connect remotely from the updated machine to machines without the update. However, with the latest update released this May, Microsoft hardened security, and you can no longer connect to machines without the update.These might came in due to #GDPR

You will face the CredSSP encryption oracle remediation error if you have applications or services such as the Remote Desktop Connection that use CredSSP on an updated machine. Authentication will not work and you will get this error message:

Here is error message that is seen after recent windows update

The workable solution I found is to edit client Windows’ local group policy (gpedit.msc):

Under Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Find setting “Encryption Oracle Remediation”. Its default value is “Not configured”. Just change it to “Enabled”, and set “Protection Level” as “Vulnerable”.

Now your remote desktop should be able to connect. Remember to revert the setting after you are done.

TLS 1.2 and .NET Support: How to Avoid Connection Errors

I recently ran into an interesting issue when developing we are connecting to a third-party Carrier API. When trying to connect to the API endpoint, I received the following error message:

“An error occurred while making the HTTP request to https://<API endpoint>. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.” Inner exception was “Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.”

With data security in place lot of API providers are ending TLS 1.0 support. This can be overcomed by adding a line of code in .NET by setting TLS 1.1 or above
The default System.Net.ServicePointManager.SecurityProtocol in both .NET 4.0/4.5 is SecurityProtocolType.Tls|SecurityProtocolType.Ssl3.

.NET 4.0 supports up to TLS 1.0 while .NET 4.5 supports up to TLS 1.2

However, an application targeting .NET 4.0 can still support up to TLS 1.2 if .NET 4.5 is installed in the same environment. .NET 4.5 installs on top of .NET 4.0, replacing System.dll

Adding below one line of code will help you to avoid above error.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |
(SecurityProtocolType)768 | (SecurityProtocolType)3072;

Reference:

namespace System.Net
{
    [System.Flags]
    public enum SecurityProtocolType
    {
       Ssl3 = 48,
       Tls = 192,
       Tls11 = 768,
       Tls12 = 3072,
    }
}

Under standing Local Service, Local System and Network Service?

The main difference between these Local Service, Local System and Network Service mainly relay on the security principals. I have website I need to configure remote connections. When we use SQL Server, so when allowing remote connections and you might think which Service account you should use to run SQL Server.

You should use Local non-system or Service account. If this SQL Server service require to access the network resources you can use a ordinary Domain account.

• Domain User Account
  If the service must interact with network services, access domain resources like file shares or if it uses linked server connections to other computers running SQL Server, you might use a minimally-privileged domain account. Many server-to-server activities can be performed only with a domain user account. This account should be pre-created by domain administration in your environment.
• Local User Account
  If the computer is not part of a domain, a local user account without Windows administrator permissions is recommended.

Following are NOT advised as it grant more privileges than required for running SQL Server Services

• Local System is a very high-privileged built-in account. It has extensive privileges on the local system and acts as the computer on the network. The actual name of the account is "NT AUTHORITY\SYSTEM".
• The Local Service account is a built-in account that has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard the system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session without credentials. Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services. The actual name of the account is "NT AUTHORITY\LOCAL SERVICE".
• The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITY\NETWORK SERVICE"

Please consider the below recommendations:

• Always run SQL Server services by using the lowest possible user rights.
• Use a specific low-privilege user account or domain account instead of a shared account for SQL Server services.
• Use separate accounts for different SQL Server services.
• Do not grant additional permissions to the SQL Server service account or the service groups