Vulnerability in the kernel allows privilege escalation through directory manipulation

Recently Qualys security researchers (a cloud security, compliance and related services company) released details of a vulnerability what they detected and what they affect the Linux kernel.

CVE-2021-33909 affects the kernel and allows a local user to achieve code execution and escalate privileges by manipulating highly nested directories.

The vulnerability is due to the lack of validation of the result of converting size_t to type int before performing operations on the seq_file code, which creates files from a sequence of records. Lack of validation can result in writes to an area outside the buffer limits when creating, mounting, and dropping a directory structure with a very high level of nesting (path size greater than 1GB).

Any non-privileged user can gain root privileges on a vulnerable host by exploiting this vulnerability in a default configuration.

As a result, an attacker can get a 10-byte string “// deleted” with an offset of “- 2 GB – 10 bytes”, pointing to the area immediately before the allocated buffer.

The threat of vulnerability is compounded by the fact that researchers were able to prepare functional exploits on Ubuntu 20.04, Debian 11 and Fedora 34 in the default settings. It is noted that other distributions have not been tested, but theoretically, they are also susceptible to the problem and can be attacked.

Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host. Qualys security researchers have been able to independently verify the vulnerability, develop an exploit, and gain full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34 Workstation. Other Linux distributions are likely to be vulnerable and probably exploitable.

The work of the exploit boils down to creating a hierarchy of roughly a million directories nested via mkdir () call to achieve a file path size greater than 1GB.

This directory is bind-mount mounted in a separate user namespace, after which the rmdir () function is run to remove it. In parallel, a thread is created that loads a small eBPF program, which hangs at the stage after verifying the eBPF pseudocode, but before its JIT compilation.

In the unprivileged user ID namespace, the / proc / self / mountinfo file opens and reads the long directory path mounted with bind-mount, resulting in the line “// deleted” being written in the region before the start of the buffer. The position for writing the line is chosen in such a way that it overwrites the instruction in the already tested but not yet compiled eBPF program.

Furthermore, at the eBPF program level, uncontrolled writing out of the buffer is transformed into a read / write capability controlled in other kernel structures by manipulating the btf and map_push_elem structures.

The exploit then places the modprobe_path [] buffer in kernel memory and overwrites the path “/ sbin / modprobe” in it, allowing any executable file to be launched as root if a request_module () call is made, which is executed for example when creating a netlink socket ..

Researchers have provided several solutions that are effective only for a specific exploit, but they do not fix the problem itself.

As such it is recommended to set the parameter “/ proc / sys / kernel / unprivileged_userns_clone” to 0 to disable mounting of directories in a separate userid namespace and “/ proc sys / kernel / unprivileged_bpf_disabled” to 1 to disable the loading of eBPF programs into the kernel.

In addition to the fact that all users of a Linux distribution are also recommended to update their system to have the corresponding patch. The problem has been evident since July 2014 and it affects kernel versions since 3.16. The vulnerability patch was coordinated with the community and accepted in the kernel on July 19.

Finally, if you are interested in knowing more about it, you can consult the details in the following link.

GEOIP redirect with https in nginx

With the full Nginx Installation with MAP Module active You can redirect based on GEOIP.

You will need the geoip-database installed, on RedHat based system with YUM you will use the following:

yum install geoip geoip-devel

So once you have that installed you will need MaxMind’s City database which can be retrieved from MaxMind’s website.

  1. wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz -O /usr/share/GeoIP/GeoLiteCity.dat.gz
  2. gunzip /usr/share/GeoIP/GeoLiteCity.dat.gz

So now you have the setup out the way you are ready to configure NGINX, which is relatively straightforward.

The example configuration for your case would go something like the following:

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
  geoip_city /usr/share/GeoIP/GeoLiteCity.dat;

  map $geoip_city_country_code $nearest_server {
    default example.com;
    CA      example.ca;
  }

  server{
      listen 80;
      listen [::]:80;
      server_name example.com
                  example.ca;

      if ($nearest_server != $host) {
        rewrite ^ $scheme://$nearest_server$request_uri break;
      }

  }
}

So, specifics: In the configuration above it does depend on your installation so you’ll need to ensure that the include, error_log and pid directory is correct to your installation and preference.

In respect of how it works, I believe it’s pretty self-explanatory however to delve into it a bit:

geoip_city /usr/share/GeoIP/GeoLiteCity.dat; > links the downloaded MaxMind GeoIP city data to NGINX.

  map $geoip_city_country_code $nearest_server {
    default example.com;
    CA      example.ca;
  }

The above section links your multiple hosts, and their respective country code, e.g. CA for Canada- you can add as many entries as you want.

  if ($nearest_server != $host) {
    rewrite ^ $scheme://$nearest_server$request_uri break;
  }

The above section decides what server based to use based on location, and passes on the request URI. Example http://example.com/store.php requested from a Canadian IP will redirect to http://example.ca/store.php

That is pretty much it, the main sections are the MAP section, and the IF statement within the server component (and fulfilment of the requirements)

A Brute Force Attack Definition & Look at How Brute Force Works – Hashed Out by The SSL Store

Brute force attacks describe specific methods cybercriminals use to gain unauthorized access to accounts and resources that rely on insecure or compromised credentials. We’ll break down what brute force is, how brute force attacks work, and why these attack methods are bad for business

Brute force attacks suck for businesses and users alike. Part of this is because people use crappy passwords — yes, I’m talking to you “Password123” and “qwerty” password users. But there are also other contributing factors as well (such as poor account security management on the part of businesses). Although a brute force attack isn’t the only cause of broken authentication, it’s a big enough issue that we’ve decided to dedicate an entire article to talking about it.

The most recent data from Verizon’s 2021 Data Breach Investigation Report (DBIR) doesn’t paint a pretty picture when it comes to the use of at-risk credentials and brute force attacks. In fact, SIEM data shows that these attacks are prevalent. Significant portions of the 2020 data breaches and cyber incidents they studied involved the use of insecure or stolen credentials:

  • 60% of ransomware cases they analyzed involved the use of stolen credentials or brute force.
  • 89% of hacking cases involving Desktop sharing involved stolen credentials or brute force.
  • 80% of based web app attacks involved compromised credentials (you guessed it — stolen creds or brute force. Seeing a pattern yet?)

Needless to say, brute force attacks are a big issue. But what is a brute force attack? How do different types of brute force attacks work? We’ll walk you through several brute force attack examples and explore what you can do to protect yourself and your organization against them.

Let’s hash it out.

What Is a Brute Force Attack? A Definition & Explanation

Let’s start by answering the question, “what is a brute force attack?” A brute force attack, or what’s also known simply as “brute force” or “brute forcing,” is both an overarching category of attacks as well as a specific attack method.

A brute force attack involves a threat actor attempting to log in to one or more accounts by trying out various credentials (i.e., username and password combinations), using known and guessed passwords and/or usernames until they find a winning combo. These attacks allow attackers to gain access to everything from blog user accounts to master admin accounts that provide total control over a company’s network.

These types of attacks, which mainly involve guessing passwords and/or usernames, are essentially massive processes of elimination. Cybercriminals can try hundreds, thousands, or even millions of combinations before they can successfully log in.

As the Juggernaut graphic above implies, the term “brute force” relates to the concept of brute strength, meaning strong-arming or using overwhelming force. Brute force attacks can be used in cryptography to guess a user’s private key, although it’s most commonly associated with password security attacks.

Brute Force Attacks Are Just One Type of Password Security Attack…

Brute force attacks aren’t the only types of cyber attacks bad guys use to fraudulently authenticate to access password-protected accounts. Other methods they use to solve the “I-don’t-know-your-credentials” problem include:

  • Using phishing and spear phishing attacks to trick users into handing over their credentials.
  • Deploying keyloggers and other types of malware that record your keystrokes and/or other data.
  • Cracking stored password hashes using hash tables and rainbow tables.
  • Stealing passwords in transit that use insecure (non-HTTPS) connections via man-in-the-middle (MitM) attacks.

Of course, there are ways to mitigate brute force and other password-related attacks, and we’ll speak about those later. But first, here’s a quick example of how an attacker uses brute force to their advantage.

A Brute Force Attack Example Targeting the Financial Services

We’ll use financial services as an example since Varonis reports that the average employee within that industry has access to nearly 11 million files starting the first day on the job! (Not to sound negative, but that’s insane and poses a huge data exposure risk if something goes wrong.)

Imagine you’re a bad guy who wants to gain access to a financial company’s sensitive customer data. To do this, you need to gain access to their databases or servers. You try scanning for any exposed databases but don’t find any. You have a list of employees’ email addresses but, unfortunately for you, you don’t have time to carry out a targeted spear phishing campaign to get their credentials. So, what can you do?

  • Use lists of breached or otherwise compromised usernames and/or passwords. These lists of usernames, passwords, or combinations of both are readily available online (both for free and for a price).
  • Create or download lists of common words from the dictionary. Yup, you can pair lists of common words with those email addresses to try to find a match.
  • Use lists of common password variations. Massive lists with tens of thousands or even millions of common passwords can easily be found online on sites like GitHub.

You can also generate wordlists for password-guessing tools like Crunch or CeWL.

And if the company doesn’t follow access control best practices, or if the company hands out access to sensitive files and IT systems like candy on Halloween, then all you might need to find is just one user account that has uses a password that’s on one of your lists.

Why Cybercriminals Love Using Password Attacks

Cybercriminals love easy targets and quick wins. They commonly use compromised or otherwise insecure passwords as an attack vector because:

  • Gaining access to legitimate accounts is easier than hacking. Although TV shows and movies typically make hacking look fast and easy, it’s really not. Why should a bad guy spend hours, days, or weeks poking around to find holes in your cyber defenses when they can just walk through the front door using legitimate credentials?
  • Usernames and passwords are easy and inexpensive to get. As we touched on earlier, cybercriminals have an arsenal of tools and tactics at their disposal.
  • People rely on insecure passwords and love to recycle passwords. People love to use shoddy and insecure passwords to secure their accounts. Oh, yeah, and Google survey data shows a combined 65% of users reuse their passwords across multiple or all accounts. Need we say more?
  • They can use automation and scripts to their advantage. Oh, yes. Bad guys love to use scripts and automation to gain unauthorized access to your accounts. They can just set it and forget it, letting their scripts do their dirty work while they go binge Netflix.

Do attackers want to spend all day manually typing in one password after the next? No, that would be a huge waste of time with little to no return on their investment. This is why many cybercriminals love to make bots and zombies do their dirty work.

Many Brute Force Attackers Use Botnets to Their Advantage

Bots and zombies are infected devices that are controlled without the consent or knowledge of their owners. They’re forced to operate as components of a larger network or connected devices. This network, known as a botnet, is essentially an army of devices that do the attacker’s bidding. Botnets are commonly used to carry out distributed denial of service (DDoS) attacks against target servers and various types of brute force attacks.

The following graphic provides a simplified example of how a brute force attack works using a botnet:

A Brute Force Attack Definition & Look at How Brute Force Works

A basic example of a botnet-powered brute force attack. In this scenario, a bad guy controls an army of hijacked, infected devices that does the attacker’s bidding.

Do brute force attempts occur one right after the other? Not always. Data from Verizon’s 2021 DBIR shows that these attacks frequently occur at irregular intervals.

Let’s take a look at the specific types of brute force attacks and explore how they work.

Breaking Down the Types of Brute Force Attacks & How They Work

As we mentioned earlier, brute force attacks refer to both a category of different attack methods as well as a specific attack. Often, they’ll rely on botnets to carry out their attacks at scale. But just what are the different types of brute force methods? The answer depends on whom you ask — organizations categorize brute force techniques differently.

For example, MITRE divides brute force into four main categories:

  1. Password guessing
  2. Password cracking
  3. Password spraying
  4. Credential stuffing

IBM’s Security Network Intrusion Prevention System resource doc (version 4.6.2) categorizes brute force attacks as:

  1. Dictionary attacks,
  2. Search attacks, and
  3. Rule-based search attacks

Kaspersky, on the other hand, identifies brute force attack types as:

  • Simple brute force attacks
  • Reverse brute force attacks
  • Dictionary attacks
  • Hybrid brute force attacks
  • Credential stuffing

It’s easy to see why this can get a bit confusing. For the purpose of this article, we’re going to go with Kaspersky’s categorization. Describing brute force attacks work varies from one attack method to the next. With this in mind, let’s explore each brute force attack method individually more in-depth to see how it works.

Traditional (Simple) Brute Force Attacks

Alright, let’s start with the namesake method. This type of basic brute force attack boils down to an attacker targeting a specific list of usernames by making a lot of password guesses. They do this over and over again until they find a combination that matches.

For example, you could take the username “admin” and test out a litany of different password guesses. Here, we’ll show an example using randomly generated or guessed passwords and usernames:

Username Password Attempt Status
admin a1234567 Failed
admin aa123456 Failed
admin aaa12345 Failed
admin aaaa1234 Failed
admin aaaaa123 Success

Cybercriminals use scripts and automation to enter the different username and password combinations repeatedly. Here’s a basic graphic that illustrates how this process looks:
brute-force-attack-example

A basic illustration of a brute force attack.

Reverse Brute Force Attacks (AKA Password Spraying)

Brute force attack naming conventions are generally pretty straightforward in the sense that they describe the attack process. In a reverse brute force attack, which is also known as a password spraying attack, the attacker takes an approach that’s basically the opposite of the simple technique we just talked about.

A password spraying attack involves an attacker using a targeted list of common secrets (passwords) while guessing a large list of potential usernames. Basically, they “spray” the pre-determined list of passwords while rotating through their massive list of usernames to see what sticks.

Microsoft does a nice job differentiating password spraying attacks and basic brute force attacks:

“Brute force is targeted. The hacker goes after specific users and cycles through as many passwords as possible using either a full dictionary or one that’s edited to common passwords. […] Password spray is the opposite. Adversaries acquire a list of accounts and attempt to sign into all of them using a small subset of the most popular, or most likely, passwords. Until they get a hit.”

Here’s a quick example of how this would look (I’m using the most common password from NordPass’s 2020 list of the top 200 most common passwords for the sake of convenience):

Username Password Attempt Status
admin 123456 Failed
admin_ 123456 Failed
administrator 123456 Failed
ITadmin 123456 Failed
ITadministrator 123456 Success

Password spraying attacks can be a real horror fest for companies whose users don’t use secure logins. Wondering what this type of attack would look like in action? Here’s a simplified illustration of how a password spraying attack could look if it was targeting some well-known horror movie villains:

how-password-spraying-works
A simplified illustration that demonstrates how a password spraying attack works.

Dictionary Attacks

The name should tell you all you need to know about this type of brute force. Basically, it involves using enormous predefined lists of common phrases or words that you can find in a dictionary (hence the name). In this way, it’s more specific than a simple brute force attack.

Bad guys frequently use password cracking software and wordlist generators to come up with all possible permutations of words or character sets. Here’s a quick example of how a dictionary attack looks in terms of targeting specific accounts:

Username Password Attempt Status
User1 password Failed
User1 password1 Failed
User1 password2 Success
User2 password Failed
User2 password1 Failed
User2 password2 Failed
User3 password Failed
User3 password1 Failed
User3 password2 Success

In more targeted dictionary attacks, they may even research individual users online (looking at their websites, social media accounts, etc.) to determine their interests and if there are any words or phrases that stand out. They can then incorporate these words or phrases into their dictionary lists.

Here’s a simple illustration of how a dictionary attack works:

A simplified illustration that demonstrates how a dictionary attack works.

Hybrid Brute Force Attacks

This type of password attack is the unwanted lovechild of two types of brute force methods. For example, you could combine a dictionary attack with a basic brute force attack. This process would involve taking common words from the dictionary and adding random values or characters to them.

The idea here is that this combo method is more efficient than using either of the individual methods on their own. For example, you could take the word like “mustang” and add random numbers to the end (such as popular car model years like 1965, 1976, 2021, etc.).

Username Password Attempt Status
admin mustang1962 Failed
admin mustang1963 Failed
admin mustang1964 Failed
admin mustang1965 Failed
admin mustang1966 Success

Here’s a quick brute force attack example that illustrates how the hybrid technique works:

Credential Stuffing Attacks

As the name implies, a credential stuffing attack involves a cybercriminal repeatedly “stuffing” known credentials into various websites’ login form fields. This process involves testing known credentials (ie., those that have been stolen or otherwise compromised) on multiple websites. The idea here is that an attacker will eventually get lucky and find one or more of the target websites where someone has an account that uses those credentials.

But there seem to be differing opinions throughout the industry about whether credential stuffing is a type of brute force attack. Some experts say yes while others vehemently argue it’s not. For example, one OWASP article on credential stuffing describes it as a subset of brute force attacks while another OWASP article says the opposite.

Regardless of how you choose to classify it, here’s a quick visual example of how credential stuffing works:

An illustration demonstrating how a credential stuffing attack works when a user has the same password for multiple accounts.

In this example, a hacker targets a user whose username and password were exposed in the 2014 Yahoo data breach. The user, who never bothers to change their password, uses the same password for all of their different accounts. This means the bad guy can use the breached password to log in to the user’s other accounts.

Credential stuffing attacks also can use botnets to use the lists or databases of compromised credentials against one or more websites to try to login to all of them simultaneously.

Considering that the Google survey we mentioned earlier shows that users reuse passwords across multiple (52%) or all (13%) of their accounts, it’s no surprise that these attacks are often highly effective. In their 2021 Credential Stuffing Report, F5 indicates that credential spills (i.e., cyber incidents involving compromised usernames and/or email addresses and passwords) aren’t going anywhere:

Data source: F5 Labs’ 2021 Credential Stuffing Report.

Wrap Up: 7 Quick Tips to Prevent Brute Force Attacks

This brings us to the end of this article on brute force attacks and how they work. It’s obvious to see why these types of password attacks are such an issue for businesses and consumers alike. Thankfully, there are several things you can do to protect your business’s accounts against brute force attacks:

  1. Require your users to employ strong passwords or, as the FBI recommends, passphrases. These passphrases should be no fewer than 15 characters and consist of multiple words. Passphrases are longer than traditional passwords and are easier to remember, which makes them more secure and something you’d be less likely to write down. You’re also less likely to be one of the 65% of users who will choose to use the same password to secure multiple accounts.
  2. Change the login URLs for web apps and services. We’ve been here ourselves. After multiple brute force attempts several months ago, we had to change the admin login page address for Hashed Out. This isn’t a surefire method, but it stops lazy hackers from bombarding your site with automated brute force attempts.
  3. Never store user passwords on public-facing servers. Even encrypted passwords and password hash values, when stored online, are at risk to password attack methods like rainbow tables. This is why you should only store salted password hashes for simplified user authentication.
  4. Set up account controls and follow access management best practices. This helps you ensure that authorized users can access your organization’s IT systems and allows only legitimate users individuals to log in. (They first must provide identifying information that proves their identities.)
  5. Set an account use policy that limits the number of failed login attempts.Whether it’s three or 10, be sure to set the number of incorrect or failed login attempts a single user profile can make within a set time period. You can also set progressive delays that increase the lock-out time after each new failed login attempt. This increases the amount of time that must pass before someone can try to log in again.
  6. Setup MFA for sensitive accounts. This way, even if a hacker manages to guess your password, they’ll have one more security layer they have to get past.
  7. User certificate-based authentication where possible. It’s nearly impossible to brute force certificate-based authentication due to the key size, and certificate-based authentication isn’t vulnerable to phishing or data breaches.

The Ultimate Guide to Code Signing Best Practices

The Top 11 Code Signing Best Practices to Protect Your Customers and Keep Your Software Tamper-Free

Want to protect your home from thieves? A security system is a popular option. However, it’s not very effective if you don’t install it properly, fail to activate it when you aren’t home, or use “123456” as the security code. The same applies to code signing certificates. They’re the best way to protect the integrity of your software and prevent tampering by hostile third parties, but only if code signing best practices are followed. Otherwise, you might as well not even bother.

If you still need convincing, just look at the recent SolarWinds breach. Sloppy code signing practices left the door wide open for hackers, and they were able to inject malicious code into legitimate software updates without anyone noticing. As Mike Nelson, DigiCert’s VP of IoT Security, explains:

“Code signing works. Poorly implemented code signing puts your business at greater risk. In the case of SolarWinds, they were using a code signing certificate to sign the files. The problem wasn’t the code signing certificate, the problem was the way they were practicing code signing.”

Those SolarWinds updates got pushed to nearly 18,000 customers, including Microsoft, Nvidia, Intel, and Cisco, who were suddenly left exposed via a backdoor hidden within the SolarWinds software. It’s nothing new – a similar situation occurred with Asus in 2019 – and attackers will continue to attempt code tampering as long as companies are lax with their processes.

So, what is code signing exactly? Why is it such an important part of the software development cycle? And, most importantly, what are the code signing best practices that your organization should always follow?

Let’s hash it out.

What is Code Signing?

First, let’s take a step back and review what code signing is and how it works. Code signing certificates help to:

  • Protect your code as it’s distributed online
  • Verify that you are the author of the file
  • Signal if the software has been tampered with
  • Provide a permanent, irreversible timestamp that allows for verification after certificate expiration or revocation

Code signing uses public key infrastructure (PKI) to apply a digital signature as proof of legitimacy and integrity. Extended Validation (EV) code signing certificates go a step further. A more vigorous verification process is carried out before certificate issuance, and the certificate itself is stored on a physical USB device as an additional layer of security. EV code signing also gets rid of Microsoft SmartScreen and other browser/operating system (OS) warnings thanks to the higher level of identity verification that’s initially required.

Without code signing, Windows generates the warning message on the left prior to installation. The warning goes away when a signed application is detected, as seen on the right.

Code signing is widely performed across all software platforms, device types, and application categories. In fact, some platforms actually make code signing a requirement for publishing.

Why is Code Signing Important?

Users want to be confident when downloading a file, and if there is any doubt in their mind then they will tend to reject the software altogether. Code signing acts as a sort of “digital shrink wrap” that tells the user that not only is the file coming from a verified source, but also that it hasn’t been tampered with in the meantime.

Code signing provides peace of mind and builds trust with end users, making them much more likely to install your application on their machine. It leads to more downloads, more users, and an improved reputation and brand image.

How Does Code Signing Work?

As we touched on earlier, code signing certificates are similar to other types of digital certificates in that they’re built on PKI. Their implementation and use depends on whether we’re talking about the developer or the consumer. We’ll start with the developer.

Code Signing and Developers

The general code signing process that’s carried out during the software development cycle is typically as follows:

  1. The developer generates a certificate signing request (CSR) and private-public key pair.
  2. The CSR (which includes the public key) is sent to the Certificate Authority (CA), who verifies the identity of the developer and issues the code signing certificate.
  3. The developer hashes their code. This must be performed prior to signing. Basically, a hashing algorithm is used (most commonly SHA-256 nowadays) to convert the code into an arbitrary, fixed value (and is a one-way process). The result of the hashing is called a digest.
  4. The code signing certificate is used to create a signature block. The signature block is attached/included with the software file.
  5. The software has now been code-signed and is ready for distribution.

Code Signing and Consumers

Code signing more straightforward for users. Most operating systems will check for a code signing certificate prior to software installation. When a code signing signature is detected in the application, the OS will:

  1. Verify the legitimacy of the certificate.
  2. Use the public key from the CA to decrypt the digest.
  3. Use the same hash function to generate a new digest from the code.
  4. Compare the new digest with the original that was generated by the developer.
  5. If they match, then it confirms that they code hasn’t been tampered with.
  6. The OS proceeds with installation.

Viewing the properties of a code signing certificate.

The Top 11 Code Signing Best Practices

Now that we know all about how code signing works and why it’s so beneficial, let’s get into the code signing best practices. These should always be used by your organization in order to maximize the effectiveness of your code signing certificates.

1. Limit Key Access

  • Restrict access to private keys based on roles
  • Minimize the number of machines that store code signing keys
  • Minimize the number of staff members that can access the keys
  • Employ physical security controls in order to minimize key access such as key card-protected doors and locked drawers/cabinets
  • Always keep the private key behind lock-and-key

2. Maximize Key Security

  • Protect private keys with secure vaults and Hardware Security Modules (HSMs), which are special cryptographic processors solely designed for safeguarding keys

    An example of a Hardware Security Module (HSM).

  • Key-protection products should be at least FIPS-140 Level 2 certified
  • For transportation of private keys, use hardware that is protected with a strong password of at least 16 characters and contains uppercase and lowercase letters, numbers, and special characters
  • Ensure that private keys are never (for any reason) added to easily accessible places like GitHub, PasteBin, publicly accessible servers, etc.

3. Perform Time-Stamping

  • Time-stamps allow for verification of code even after the original code signing certificate has expired or was revoked
  • Time-stamp certificates can be used to validate for up to 11 years after issuance

4. Use Test-Signing Only When Appropriate

  • Test-signing certificates are either self-signed or come from an internal, private CA and should therefore only be used in a secure test environment
  • Test-signing certificates don’t require the same level of security as production code signing certificates
  • Test-signing certificates cannot chain to the same root as your production certificates
  • The test-signing infrastructure should be completely separate from the production infrastructure

5. Review Code Prior to Signing

  • Code should be thoroughly reviewed and authenticated prior to signing
  • A code signing submission and approval process should be created and used to avoid the signing of unapproved and/or malicious code
  • All code signing activities should be logged in case of future audits or security incidents

6. Scan First

  • It’s important to remember that code signing doesn’t ensure the safety of what’s inside – you can code sign a virus or malware if you really wanted to
  • Be extra careful when incorporating open-source code from external sources
  • Perform virus and malware scanning prior to code signing
  • Malware scanners can’t detect everything, so ensure that each code/component change has been manually vetted

7. Don’t Rely on One Certificate

  • Using multiple certificates helps to distribute risks
  • Multiple certificates can help make it easier to track any issues that may arise

8. Don’t Hesitate to Revoke

  • Any compromised certificates should be immediately revoked and reported to the certificate authority
  • “Compromised” means any suspicion that the private key may have gotten into the hands of an unauthorized user, or that the certificate was used to sign an application containing malware or other malicious code
  • Use time stamps to determine the latest possible revocation date that can be used in order to minimize the impact on safe code

9. Centralize Certificate Management

  • Certificate management platforms, such as DigiCert’s CertCentral or Sectigo Certificate Manager, use automation to simplify the certificate management process, reduce errors, and improve security of keys
  • Continuously monitor the status of your code signing certificates, another area where certificate management platforms help – they give you visibility and can provide alerts for possible issues
  • Regularly audit key usage to ensure policies are accurate

How a user requests a code signing certificate within DigiCert’s CertCentral certificate management platform.

10. Keep Up to Date

  • Stay informed regarding any new cryptographic algorithms or industry practices to ensure you have the best available protection
  • Immediately respond if any new security flaws or vulnerabilities are discovered

11. Create Organizational Policies and Procedures

  • Create a written policy document that everyone in the organization should follow – it should be a “living document” that adapts to any internal or external changes
  • Your code signing policy should address:
    • Who can sign code
    • What code signing tools are approved for use
    • Which kind of certificates are permitted
    • Who is the approver of code signing requests
    • How/where private keys are stored & protected
      • Train your staff on these best practices once per year

      All Signs Point to Best Practices

      As with any security measure, code signing is only as effective as its implementation and use. No company intends to fall victim to software tampering and end up like SolarWinds or Asus, but it only takes one mistake to leave yourself exposed. As Nelson of DigiCert says:

      “For those of you who may be down the road with some of these bad practices — stop. Get control of what you’re doing and minimize the risk for your business. SolarWinds isn’t the only organization with bad code signing practices — let’s use this compromise to improve the way we operate and keep our businesses safe.”

      The human element in the code signing process is most often the weak link, but technical mistakes can doom you as well. By following the best practices that we’ve outlined, you can minimize risk and educate your staff about how to sign code as effectively as possible. That way, you can consistently protect your software, your customers, and the brand that you’ve worked so hard to build.

      Article source : https://www.thesslstore.com/blog/the-ultimate-guide-to-code-signing-best-practices/