GRUB2 Protection

Single user mode, or maintenance mode, is a mode in which a multi-user computer OS  boots into a single superuser. This mode is commonly know as runlevel 1  or rescue.target (rescue mode) in systems that implement Sys-V or Systemd style initialization respectively.

The single user mode allows administrators direct access to the root filesystem without a password in order to carry out system maintenance, such as

• Resetting root password ( with rescue mode)
  
• Repairing file system corruption error ( with emergency mode) 

Here, I'm using Ubuntu as sample configuration.

Set GRUB Password

In order to secure your system’s single user mode, you need to set the grub password. In this case we are going to generate hashed password for GRUB by running the command below.

# grub2-mkpasswd-pbkdf2
Enter password: <STRONG_PASSWORD>
Reenter password: <STRONG_PASSWORD>
PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.2E76F....5334

Now, your GRUB hashed password has been generated:
grub.pbkdf2.sha512.10000.2E76F....5334 [283 bytes long ]

Enable GRUB Password Protection

To enable grub password protection, you have to identify grub menu items to protect, users authorized to access the GRUB and their passwords. The users and their passwords are manually added /etc/grub.d/00_header file.

To edit the /etc/grub.d/00_header, run the command below;
# vim /etc/grub.d/00_header

 

Define Superuser and Password

Once you have opened the above file for editing, enter the superuser and its password at the end of the file in the following format.

cat << EOF
set superusers="superuser"
password_pbkdf2 superuser <STRONG_PASSWORD>
EOF

This should finally look like;

cat << EOF
set superusers="sysadm"
password_pbkdf2 sysadm grub.pbkdf2.sha512.10000.2E76F....5334 [283 bytes long]
EOF

Once you are done editing, save the file and update grub by running the following command.

# update-grub2
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-36-generic
Found initrd image: /boot/initrd.img-4.15.0-36-generic
done

When grub is updated, the user/password information is automatically added to the GRUB 2 menu configuration file, grub.cfg.

Now your grub is password protected. To verify this, reboot your system and try to boot to rescue mode or emergency mode.

Note that if you lost you both your grub password and the root password, the only way to get to the shell is by booting your system with LiveCD, mount the root partition in rw mode and remove the password in the grub configuration file.

 

Enable Password Protection for all but Default Menu Entries

Before rebooting the system, I usually would like to make an additional configuration here. I don't want to enter additional password every time my system is reboot or turn on. I can protect the GRUB with password for any actions, except booting existing menu entries without changing them.

Now, let's define default menu entries as --unrestricted, allowing to use them without password. Linux menu entries are defined in file /etc/grub.d/10_linux. The simpliest way to change all entries is to modify CLASS variable in the beginning of the file:

CLASS="--class gnu-linux --class gnu --class os --unrestricted"

Now to update actual /boot/grub/grub.cfg you should run update-grub2 (for Debian-based OS, like Ubuntu) or grub-mkconfig -o <path to grub.cfg> for others.

Boot into Rescue Rescue Mode

1. Reboot the system and goto GRUB bootloader screen.
2. Press 'ESC' key to go to bootloader screen during the boot process.
3. Choose the first option "Ubuntu" and press 'e' key to edit.
4. Append the string “systemd.unit=rescue.target” to the line which starts with ‘linux’ word.
5. Press ‘CTRL-x’ or F10 to boot the system in rescue or single user mode.
6. Start your troubleshooting steps, such as recover the root password (passwd root).
7. Once you are done with troubleshooting steps, use ‘systemctl reboot’ command to restart the system.

Boot into Emergency Mode

In emergency mode, all the files system of a Linux system are mounted in read-only mode. This mode is generally used in the situations where we can’t boot the system in rescue mode, may be due to some file system corruptions. Refer below steps to boot Ubuntu 20.04 in emergency mode:

1. Reboot Your system and go to GRUB bootloader screen
2. Press 'ESC' key to go to bootloader screen during the boot process.
3. Choose the first option "Ubuntu" and press 'e' key to edit.
4. Append string “systemd.unit=emergency.target” to the line which starts with ‘linux’ word.
5. Press “Ctrl-x” or F10 to enter into emergency mode.
6. Start your troubleshooting steps, such as repairing the file system.
7. If you want to mount / (slash root) in read-write mode then issue the following command, # mount -o remount,rw /
8. Once you are done with troubleshooting steps, use ‘systemctl reboot’ command to restart the system.

Links:

• https://www.linuxtechi.com/boot-ubuntu-20-04-rescue-emergency-mode/
• https://selivan.github.io/2017/12/21/grub2-password-for-all-but-default-menu-entries.html
• https://kifarunix.com/how-to-protect-single-user-mode-with-password-in-ubuntu-18-04/

Personal Diary with Notepad

This is a simple and yet useful (hidden) feature in Notepad that I learned recently. 

1. Create a new text file, with any name. 
2. Type ".LOG" (all uppercase ) at the first line.
3. Save (and close) as regular text file.
4. Every time we double-click to open the file, it will show the date/time, and we can just write any text below it. (good for keeping as forensic logbook)

TLS/SSL Server Supports The Use of Static Key Ciphers

Today, I have a colleague that asks me about a vulnerability called "TLS/SSL Server Supports The Use of Static Key Ciphers " (ssl-static-key-ciphers).

This vulnerability has CVSS 2.6 (rated by Rapid7). According to Rapid7:

The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted.

Here're the questions to me:

• What kind of vulnerability is this?
• Since this vulnerability has low (<4) CVSS rating, can we skip the remediation?
• Why the vulnerability still exist even I have follow the PCI compliance by only allowing TLS 1.1 and TLS 1.2?

My answers:

• To me, this is a kind of mis-configuration, rather than a (missing) patching issue.
• To me, this is not an urgent but it is an important vulnerability. With advanced cracking using GPU, we are not sure if anyone will finally able to crack a session key and lead to full compromise of encrypted channel given some amount of time.
  
• Yes, even if you have only TLS 1.2 enabled, your system may still vulnerable to static key cipher attack.Referring to the post on Static Key Cipher Vs Perfect Forward Secrecy, by disable all the weak cipher suites (SSLv2/SSLv3/TLS1.0) and only allowing recommended cipher suites (TLS1.1/TLS1.2), does not guarantee forward secrecy is always used.
  

Work From Home

Start to WFH......

List Users and Roles in Kenna

Last month, I created a ruby script to list all users in Kenna. And I found that I need to list all the roles besides the user list.

Then, I notice I'm not a good ruby developer.

I just re-write a script in python to list all users (including myself) and all roles in Kenna.

kenna-users.py -h