Upgrading HP BIOS with Linux

It never fails that vendors update firmware on systems but neglect to provide an easy way for anyone outside of Windows an easy way to apply the updates. HP tends to be one of my favorite vendors as they tend to support the open-source community when possible but recently a laptop needed a UEFI (BIOS) update. This happens on a fairly regular basis and each time I always think to myself that I should document how to do this since I always have to fight with the update to get it to install without needing FreeDOS or booting Windows on the laptop.The laptop in question today was an HP Elitebook that had a BIOS update available but no means to install via a Linux distribution. Not to worry though as it is still possible to this update without Windows or FreeDOS.

In order to perform this update process a Linux system and a USB drive will be needed. The Linux system in this scenario is again an HP Elitebook. The USB drive doesn't need to be a large USB drive, the device only needs about 32 MB of space but it is crucial that the device not contain any important files! This USB drive will be formatted and all data will be lost. The next thing to do is to download the BIOS update from HP's site. Many times in order to get the update from HP's site, one will need to act as though the computer is running Windows. Accomplishing this is as simple as visiting the HP support site and selecting Windows as the operating system.

By selecting Windows as the OS, the HP site will continue on to the software updates. Selecting the All drivers followed by BIOS category will show the most recent BIOS update. Simply click the download button to obtain the executable; don't worry that it is an exe.

Now open a terminal, plug in the USB drive, and let's prepare the USB drive. The first step is to locate the device name of the USB drive and then format it properly. In order to accomplish this, the user will require sudo or root rights on the system the USB drive is plugged into. To find the device name of the USB device, the 'lsblk' tool will be leveraged. As seen in the figure below, the USB drive that will be used in this article is /dev/sdc and is highlighted in green. WARNING: Triple check the device name before continuing as permanent data loss may follow!

With the proper USB drive name, the drive can now be prepared by partioning and creating a filesystem on the device. The 'fdisk' utility can be leveraged to quickly create a new partition on the located USB drive. WARNING: Make absolutely sure that the proper device is picked for the fdisk command! Command used echo -e 'n\np\n1\n\n1048576\nw\n' | fdisk /dev/sdc

Now the 'mkfs.fat' utility can be used to format the newly created partition; /dev/sdc1 on this system. WARNING: Make sure to confirm the partition name before continuing! Command used mkfs.fat -F 16 /dev/sdc1. Once the device has been formatted, it will need to be mounted to the Linux system where the BIOS update was downloaded and then a specific folder structure created in preparation for the update files. Commands used: mount /dev/sdc1 /mnt && mkdir -p /mnt/Hewlett-Packard/{BIOS/New,BIOSUPDATE}.

Now that the USB drive is prepared, let's extract the necessary files from the HP update downloaded previously. In a terminal window, navigate to the folder where the file was downloaded. Leveraging the '7z' tool, the contents of the update can be extracted. Command used: 7z e sp146435.exe

With the files extracted, the BIOS binary update file should be copied to the USB drive. The BIOS binary file will be the file ending in .bin and it should be moved to /mnt/Hewlett-Packard/BIOS/New/ folder. Command used: cp *.bin /mnt/Hewlett-Packard/BIOS/New/

Once the files are moved, make sure to sync the device and properly eject the USB drive from the system. Command used: sync;sync; umount /mnt && eject /dev/sdc.

Now remove the USB drive and plug it into the HP laptop that the BIOS update was intended. Note that the laptop will need to have a charged battery as well as be running with the AC adapter connected! With the USB drive plugged into the laptop, turn the machine on and press the escape (esc) key when the HP logo is seen. The startup menu will load and towards the bottom of the menu will be an option to update the system's BIOS. Use the arrow keys or mouse to highlight that option and select it.

The next screen will prompt for confirmation to install the new BIOS firmware. Simply click on the button that says Update BIOS - X.XX.

This will start the update process which might take some time. Simply wait for the process to complete. There will likely be multiple reboots in order for the process to complete. Remain patient!

This particular HP laptop rebooted on its own and continued the BIOS installation process. Again this is normal. Do not remove the USB drive or the AC power supply!

After another reboot, the laptop booted back into my normal Linux distribution and a quick look at the BIOS version with dmidecode showed that the laptop was now reporting the new version of the BIOS software from HP! Hopefully this is helpful for other Linux users out there wishing to keep their BIOS versions updated.

TLSv1 and Pentesting Woes

While testing a system today I ran into a webserver that was shockingly still requesting/supporting TLSv1. While TLSv1 has been around for a long time, most browsers/clients will be configured to not attempt to negotiate TLSv1 or TLSv1.1. For end-users, this is great from a security standpoint but from a pentesting stand point, we may still need to interact with that system! 

The system today caused errors with everything from OWASP ZAP to Nikto to even the CuRL utility! Luckily Parrot OS (and most other Linux systems) support configuration changes to allow the system and tools to still communicate with an old system running a TLSv1/TLSv1.1 webserver. 

First off here were some of the errors I was getting while trying to interact with the system.

• ZAP - The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]
• CuRL - error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
• Nikto - No web server found on X.X.X.X:443 (This one was odd as the error was not particularly indicative of the underlying error)
• nmap - No clear error messages but nmap failed to really be able to determine anything about the website/webserver
  

Now before beginning; Obligatory disclaimer. WARNING: Following the next steps will lower the security of the system! It is HIGHLY recommended that these steps not be performed on a system that is used for sensitive operations such as logging into email, bank accounts, credit card providers, etc. These steps are meant to enable a dedicated penetration testing station to access older crypto systems. I take zero responsibility for any damages that come from following this guide!

Disclaimer out of the way, let's walk through how to configure OpenSSL to allow older TLS versions system wide first. On many Linux systems, the system wide OpenSSL configurations are usually stored in the openssl configuration file ( /etc/ssl/openssl.cnf on ParrotOS and many other Debian systems). Within this file, there is a section labeled '[system_default_sect]'. On the current version of Parrot OS, the systems settings will look like this:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

To allow the system to connect to order TLS modes, the settings can be changed to the following:

[system_default_sect]
MinProtocol = TLSv1
CipherString = DEFAULT

Save the changes and it should be noted that many command line tools are likely to start communicating with TLSv1 systems. Take a look at the difference in CuRL with the change versus after the change in the below screenshot (Top error is MinProtocol set to TLSv1.2 and the bottom is TLSv1; The self-signed cert is a completely different issue).

The above solved the issue for many of the command line and other system tools but firing up ZAP later presented the same issue even though other tools were working just fine. Turns out that ZAP, since it relies on JAVA, had it's own configuration parameters that take priority over the system level configuration. Getting ZAP to ignore TLSv1 was a two step process. The first step is changing JAVA's security configuration as well as enabling ZAP to use TLSv1.

Let's first set JAVA's security to support TLSv1. In Parrot, and many other Debian based systems, the JAVA security settings are configured in the file /etc/java-11-openjdk/security.java.security. Within this file, locate the configuration option labeled jdk.tls.disabledAlgorithms. One will notice that TLSv1 and TLSv1.1 are disabled by default.

To enable JAVA's support for TLSv1 and TLSv1.1, simply remove those two options from the line and save the changes. NOTE: Remember this will affect all applications that use JAVA on the system!

Now to get ZAP to scan a site utilizing TLSv1/TLSv1.1. With the JAVA changes saved, launch ZAP. Once ZAP launches, navigate to Tools -> Options.

Once the menu loads, scroll to the 'Network' section and then click on the 'Connection' option. Within this menu area, there will be a number of security protocols that can be selected. Notice that TLS 1 and TLS 1.1 won't currently be checked but can be selected by clicking the check box next to them.

Click okay and then begin scanning the TLSv1 enabled website! 

 

As a final reminder, following these instructions will lower the security of a system. Penetration testing systems like Parrot and Kali shouldn't be used for normal daily tasks and the changes made in these instructions should be reverted once the need has passed!

CeWL and Parrot OS

Back with another learning moment. This time CeWL and Parrot OS are the culprits. Normally CeWL can be installed through most package managers. Sadly with the current version of Parrot (v5.1.2 Electro Ara) CeWL has a dependency problem and attempting to install it with apt will result in the error: 

ruby-mini-portile2 : Breaks: ruby-nokogiri (< 1.13.2) but 1.13.1+dfsg-2parrot1 is to be installed

Not a fan of getting too crazy on daily use systems but after a little bit of research into Ruby and reviewing CeWL's git page, a reasonable solution was discovered. I was hoping that Ruby had something similar to Python's virtualenv, which it appears Ruby does, but getting it setup/configured is apparently a headache. The alternative solution is both interesting and functional. Hopefully, Parrot's devs will have CeWL's dependencies fixes soon as well and this article will be obsolete!

Installation

The first step is to make sure git and bundler are installed on the system. Parrot should already have git but just in case it doesn't make sure to install it with apt. Bundler is likely not already installed but can be installed with 

apt install bundler

Next, create a directory where CeWL's repo should be downloaded. I tend to make a 'repos' folder on in my home directory on testing systems in order to centralize all the extra tools I place onto my testing systems.

Now with the source of CeWL obtained, the Gem tool can be use to install the dependencies for CeWL without changing the system-wide Ruby installation. To do this, create a folder called 'gems' in the CeWL folder. Then a special environment variable will be set in order to install the required Gems into the newly created folder in CeWL's source.

Assuming the above environment variable, associated folder have been created, and the current directory is the CeWL directory, the bundler command can be used to install the required Gems for CeWL. Note: that exiftool is required and there will be a warning message after Bundler completes. In Parrot, libimage-exiftool-perl, can be installed to meet this requirement.

If there weren't any errors, CeWL should run without errors. Note that since this folder is unlikely to be part of the PATH environment variable, CeWL will have to be launched from this folder currently.

Victory! There are some drawbacks to this setup but if you completely understand all the shortcomings of this band-aid fix, the feel free to crawl on your merry way (terrible pun intended!).

Caveats

As mentioned above there are some shortcomings of this fix in its current state. 

1. The GEM_HOME env will have to always be set before invoking CeWL
2. CeWL has to be run by specifying the path to the Ruby file (cewl.rb) due to this directory not being in the PATH environment variable

Most Linux user's will have their own preference on how to solve this issue but here's how I approached the situation while leaving as much of the rest of the system unchanged as possible. Leveraging the .bash_aliases file, I created a function that sets GEM_HOME, runs CeWL, and then unsets GEM_HOME. The benefit of this approach is the system defaults for Ruby are only modified when necessary but I can still run CeWL as though it were installed system-wide! 

This method, as shown, is bash specific and relies on ~/.bashrc sourcing ~/.bash_aliases so the fix is user specific but is easy to add to other user's configurations as necessary. CeWL also never needs root privileges from what I can tell so this is likely sufficient for any non-root user.

Breaking the contents of ~/.bash_aliases a bit.

1. The first line declares a BASH function called 'cewl' 
2. Sets the GEM_HOME env variable to the Gems folder where the dependencies for CeWL were installed earlier
3. Runs CeWL and passes all the command line args to the cewl.rb script
4. unsets the GEM_HOME variable so that any system-wide changes can still be made by the package manger as needed

• Note: Make sure the file paths in 2 and 3 are corrected to match the system this function is being created on!
  

Make sure that ~/.bashrc, ~/.profile, or the system-wide equivilants contains the following lines as well.

After the changes have been made to the proper files, open a new terminal and see if the new 'cewl' function is working (it is important to open a new terminal as this is a quick way to source the new changes in bash_aliases or source them in the current terminal).

Notice that GEM_HOME is blank before and after the invocation of the cewl tool. The final test is to make sure that arguments are being passed properly.

Note: There's still the slightest potential for a hiccup should the user ctrl+c while cewl is running though so the solution isn't perfect. In the event that cewl.rb is stopped early, GEM_HOME may stay set until cewl is allowed to complete or the terminal is closed. I'll continue working on this to find a better solution for traps.

Regardless, success! While not as nice as apt installing something, this process acts as a good one of for tools that have odd dependencies! Hope this can be of use to others out there.