One-way and two-way SSL authentication

How One-Way SSL Works?
Below is the high level description of the steps involved in establishment of connection and transfer of data between a client and server in case of one-way SSL:

1. Client requests for some protected data from the server on HTTPS protocol. This initiates SSL/TLS handshake process.
2. Server returns its public certificate to the client along with server hello message.
3. Client validates/verifies the received certificate. Client verifies the certificate through certification authority (CA) for CA signed certificates.
4. SSL/TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server’s public key.
5. After agreeing on this secret key, client and server communicate further for actual data transfer by encrypting/decrypting data using this key.

How Two Way SSL Works?

In Two-Way SSL authentication, the client and server need to authenticate and validate each others identities. The authentication message exchange between client and server is called an SSL handshake, and it includes the following steps:

• A client requests access to a protected resource.
• The server presents its certificate to the client.
• The client verifies the server's certificate.
• If successful, the client sends its certificate to the server.
• The server verifies the client’s credentials.
• If successful, the server grants access to the protected resource requested by the client.

The above steps are elaborated below in more technical terms and how the communication is established in a practical scenario.

1. Client Hello from client to server
    a. Client version (List of all SSL/TLS protocols client supports)
    b. Client random (A 32 byte random number to be used for generating encryption key)
    c. Session ID (blank if a new session)
    d. Compression method (Compression method to be used if compression is needed for SSL packets)
    e. Cipher suites (List of all cipher suites supported by client. Preferred one is first in the list)
    
2. Server Hello from server to client
    a. Server version (List of all SSL/TLS protocols server selected from client's provided list)
    b. Server random (A 32 byte random number to be used for generating encryption key)
    c. Session ID (Client provided session ID or a new ID in case of a new session)
    d. Compression method (Selected compression method to be used from the list provided by the client)
    e. Cipher suites (Selected cipher suite from the client's provided list)
    
3. Server Certificate from the server to client
    Server sends its certificate to the client containing public key of the server. This certificate
    acts as an identity of the server. Clients validate this certificate to ensure that it is not
    expired, it is issued by a trusted CA, it's digital signature is valid.
    
4. Certificate Request from server to client
    From mutual (2 Way) authentication, server sends a certificate request to the client
    
5. Server Hello Done from Server to Client
    Server confirms to the client that the server Hello message is finished.
    
6. Client Certificate from Client to Server
    TO enable SSL/TLS communication with two-way ssl, client sends it signed certificate to the server
    
7. Client Key Exchange from Client to server
    Client creates a pre-master secret and sends it to the server by encrypting it with server's public key.
    After decrypting pre-master key successfully, client and server will generate master secret using client
    random and server random communicated earlier. This master secret will be used to create session key for
    encrypting /decrypting data fro the entire session.
    
8. Client change cipher spec from client to server
    At this point, the client is ready to switch to a secure, encrypted communication. The change cipher spec
    protocol is used to change the encryption. Any data sent by the client from now on will be encrypted using
    the shared symmetric key.
    
9. Client handshake finished from Client to server
    At this step, handshake is completed from the client side and this becomes the first encrypted message for
    the created session.
    
10. Server change cipher spec from server to client
    The server is also ready to switch to an encrypted communication. Any data sent by the server from now on
    will be encrypted using the symmetric shared key.
    
11. Server handshake finished.
    The server completes the handshake by sending this message encrypted with the shared secret key.

The . pfx file, which is in a PKCS#12 format, contains the SSL certificate (public keys) and the corresponding private keys. When setting up two-way ssl communication, if the requirement is to share .pfx key with the other party, they will get the private key also.

What does SSL certificate include?
An SSL certificate contains information of the owner/organization, its location public key, validity dates, etc. It is mandatory that a valid certificate authority (CA) has validated the certificate.

Does SSL certificate contain private key?
All TLS certificates require a private key to work. The private key is a separate file that’s used in the encryption/decryption of data sent between your server and the connecting clients.

The certificate authority (CA) providing your certificate (such as DigiCert) does not create or have your private key. A private key is created by us — the certificate owner — when we request SSL certificate with a Certificate Signing Request (CSR). It should be saved safely on the server where it is generated. Private key should not be sent to anyone, as that can compromise the security of your certificate.

If you are yet to install your certificate, then the most likely location of your private key is on the computer or server where you generated the key pair and CSR. When you generated the key pair, you saved two files: one that contains the public key and one that contains the private key.

On Windows servers, the OS manages your certificate files for you in a hidden folder, but you can retrieve the private key by exporting a “.pfx” file that contains the certificate(s) and private key. Open Microsoft Management Console (MMC). In the Console Root expand Certificates (Local Computer). Your server certificate will be located in the Personal or Web Server sub-folder. Locate and right-click the certificate, identified by the Common Name, select Export and follow the guided wizard.

Read More

Uninstall Windows Update with Command Prompt

Use of WUSA command tool to uninstaill

If you are unable to remove an update from the Settings app or Control Panel, you can also use the Windows Update Standalone Installer, or wusa.exe, command line program to uninstall Windows updates.

In order to use this tool, you will need to know the KB number of the Windows update. To uninstall an update, open an Elevated Command Prompt (admin) and then type the following command after replacing the KB ID with the one that you wish to uninstall: wusa /uninstall /kb:[id]

Ex: #wusa /uninstall /KB:4023057 

Use DISM command tool to repair

When Safe Mode, Last Known Working Config, Startup Repair, System Restore are not helpful, try Deployment Image Servicing and Management (DISM).

DISM command with RestoreHealth option

If there are problems with the system image, you can use DISM with the RestoreHealth option to scan and repair common issues automatically.

From the System Recovery Command Prompt run the following command:
# dism /online /get-packages

This will produce a list of installed updates and packages. They will look like this:
           Package Identity: Package_for_KB978262~31bf3856ad364e35~x86~~6.1.1.0
           State: Installed
           Release Type: Security Update
           Install Time: 2/11/2010 1:01 PM

Find the most recent one and then make a note of the package identity.
Then run the following command:
# dism /online /remove-package /PackageName:Package_for_KB978262~31bf3856ad364e35~x86~~6.1.1.0
           Note: Name of update is from previous step which may vary.

You will get a status of the removal until it is complete. Then reboot your PC.
You will want to start with the most recent and remove them one at a time to find the problem update.

Reference:
[1] https://www.windowscentral.com/how-use-dism-command-line-utility-repair-windows-10-image

Read More

Essential Event Log Configurations to be Corelated

Considering Windows audit event logging, there are plenty of guides available in the Internet to follow. Most of the event configurations would overlap. However, we have to consider the most optimal and practical implementation based on our business case, server capability, security requirements & experience.

    1) Microsoft audit policy recommendations
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations

    2) What event ID's to monitor for AD compromise (This is a good example to show that if we already collect these events, we would be able to monitor them in SIEM)
    https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor

    3) Collection of event log configurations (The site contains cheat sheets for other log functionalities such as Sysmon too. If we like to cover MITRE ATT&CK techniques, that is also possible)
    https://www.malwarearchaeology.com/cheat-sheets

If we go through the above guides, we would understand that apart from the Security audit log, we can utilize several other default log files (RDP, Powershell, SMB) and external log files such as Sysmon logs, are helpful in covering the full picture.  Some of the event logs are more useful in a AD and some are more useful in a File server. Therefore, start with simple but proper security audit log configuration(e.g. CIS or Microsoft) first and get into the process. Then integrate other log files into the collection. Understand the practical issues in implementation such as log file size. Then look into the monitoring and visualization. SIEM may have a set of default use cases which is now useful after proper log configuration. If not, with your experience and business requirement, a new use case can be defined.

For Linux audit log
    1) Audit configuration rule compilation by Florian Roth. The rule set is commented and can be used as a guide to understand the required audit configurations.
    https://github.com/Neo23x0/auditd

For other Applications
    1) Consider logs such as Apache access log, MySQL or even email logs. Security team should go through the log and check whether the log is rich enough and have all the necessary data required in auditing perspective. If not, it should be improved before forwarding to the SIEM for monitoring and alert generation.

Read More

Event Log Retention Requirements as mandated by Major Compliance Regulations

On September 20th, 2016, Digital Edge released an article on Log Management Laws and Regulations. Below is a little "Cheat Sheet" on the Event Log Retention Requirements as mandated by major compliance regulations:

Regulation	Retention Requirement
HIPAA	7 years
PCI DSS	1 year
SOX	7 years
ISO 27001	3 years
FISMA	3 years
GPG 13	3+ months
NERC CIP	3 years
GLBA	6 years
DoDI 8500.2	5 years
NIST	3 years

Read More

Remove PostgreSQL in Ubuntu 18.04

Once I was using PostgreSQL and when I no longer need to keep the installation, I wanted to remove it completely. 

So I used the command listed below to remove the PostgreSQL.

#sudo apt-get --purge remove postgresql  

Even though the un-installation was successful, when I go to login there's still a "PostgreSQL" user. I tried running sudo deluser PostgreSQL but all I get is

/usr/sbin/deluser: The user `PostgreSQL' does not exist.

In order to verify the existence of the user, I checked the passwd file.

cat /etc/passwd | grep -i postgre
postgres:x:1001:1001:PostgreSQL:/opt/ManageEngine/OpManager/pgsql:/bin/sh

Then only I realized that the Login Name and User Name are not the same. So I tried removing the user "postgres" using the command below and it was successful. 

sudo deluser postgres

 

 

 

Read More

Why / Why Not Virtual Patching

 While the goal of many organizations is to maintain operating systems and other business application software are always up to date with latest security patches, realities impede the progress in being able to quickly address a vulnerability before a malicious adversary can be taken advantage.

There are many factors that complicate the ability to mitigate a given vulnerability once it has been identified. These factors include:

• Obsolete/legacy applications being used by the organization.
• Application dependencies that can caused the functional errors when being patched. Therefore, proper testing is required before applying a patch to the software or operating system in a application system and to address issues that can be introduced by the patch.
• Operational delays due to lack of resources and expertise within the organization to allocate for vulnerability management.

Therefore, the patch response time vary greatly due to the above given circumstances.

In a situations where traditional patches are not feasible, a virtual patch can be utilized to reduce the likelihood of a successful cyber attack. It helps to mitigate vulnerabilities in a separate layer, where you get to fix problems in applications without making alteration to the application directly. A virtual patch deals with the process or method of fixing problems by altering or eliminating vulnerabilities by controlling the inputs and outputs to and from the applications.

The virtual patching solution helps organizations to:

• Mitigates the risk of an exploit quickly, until an effective, permanent patch can be tested and released by the application vendor for vulnerabilities in operating systems and business applications.
• Maintain normal patching cycle without interrupting operations, if a vulnerability arises midway between scheduled patch releases.
• Reduces or eliminates time and money spent performing emergency patching.
• In certain cases, before the original patch is released virtual patching could have the risk mitigation.
• While virtual patching offers many advantages to the organization, it also has limitations such as:
• Virtual patching will not be able to address all possible ways, or all of the possible locations, in which an exploit can occur as a result of a particular vulnerability.
• Development of countering exploitation for each security issue due to rapidly discovered new vulnerabilities
• While virtual patching serving as a compensating control to delay the patch cycle, the organization always need to fix vulnerabilities to prevent the associated risks.
• While a virtual patch can avert an immediate crisis, the virtual patch cannot eliminate inherent defects in an application program that is poorly developed.
  

Hence, a successful implementation of a virtual patching solution provides an additional layer of security to the organization's IT infrastructure which helps to reduce the risk of many critical security vulnerabilities that cannot be resolved due to various dependencies.

Read More

Is Microsoft Windows User Account Control (UAC) a Security Feature?

User Account Control (UAC) helps mitigate the impact of malware.

Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.

Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels.

A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows 10 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy.

Policy setting "User Account Control: Admin Approval Mode for the Built-in Administrator account" controls the behavior of Admin Approval Mode for the built-in Administrator account.

• Enabled The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
• Disabled (Default) The built-in Administrator account runs all applications with full administrative privilege.

Refer the reference [2] for more information on policy settings.

The UAC User Experience

When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows 10 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.

Is UAC secure?

UAC is not a security feature. It’s a convenience feature that acts as a forcing function to get software developers to get their act together [4].

There’s a control panel that lets you specify how often you want to be prompted by UAC. You can set any of four levels:

1. Always notify
2. Notify only when apps try to change settings, use the secure desktop
3. Notify only when apps try to change settings, don’t use the secure desktop
4. Never notify

Although it looks like there are four settings, in a theoretical sense, there really are only two settings.

1. Always notify
2. Never notify

The reason why all the other options collapse into Meh is that the Notify only when apps try to change settings option can be subverted by any app simply by injecting a thread into Explorer and doing its dirty work there. Since Explorer is a program that the setting allows to elevate silently, this lets you perform a silent elevation from any thread that has thread injection rights into Explorer (which is pretty much any program running at medium integrity level or higher) [5].

UACMe [3]

UACMe [3] helps defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor. Relying on UAC on Windows 7 and Windows 10, however, is not enough. Attackers can use tools such as UACMe to gain access to a system.

Reference:
[1] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works
[2] https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings
[3] https://github.com/hfiref0x/UACME
[4] https://channel9.msdn.com/
[5] https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105

Read More