Kali Linux 2021.2 Release (Kaboxer, Kali-Tweaks, Bleeding-Edge & Privileged Ports)

Reading Time: 2 Minutes

A quick summary of the changelog since the 2021.1 release from February 2021 is:

⦿ Releasing Kaboxer v1.0 – Introducing Kali Applications Boxer v1.0! Applications in containers

⦿ Releasing Kali-Tweaks v1.0 – Their way to make it easier to configure Kali Linux to your taste

⦿ Refreshed Bleeding-Edge branch – They did a complete make over for their backend that produces packages for the latest updates

⦿ Disabled privileged ports – Opening a listener on ports 1024/TCP-UDP and below no longer requires super-user access

⦿ New tools added – Ghidra & Visual Studio Code. Along with CloudBrute, Dirsearch, Feroxbuster, pacu, peirates, & Quark-Engine

⦿ Theme enhancements – They added a way to quickly swap between double & one-line terminal prompt and made Xfce4 Quick launch + file manager tweaks

⦿ Desktop wallpaper & login background updates – Default images have changed with more to choose from

⦿ Raspberry Pi images recharged – RPi 400 fully supported, built-in bluetooth working, & first-run wait time dramatically reduced

⦿ Kali NetHunter support for Android 11 – Android 11 support and various other improvements for their NetHunter platform

⦿ More Docker support – Now supporting ARM64 & ARM v7 (along with previous AMD64)

⦿ Parallels support – Kali is fully supported for Apple M1 users who have Parallels

⦿ Various bug fixes – Pkexec patched, Wireshark permissions, command-not-found issues, & more accessibility features are all resolved

See Also: Cyber attack hits JBS meat works in Australia, North America

Introducing Kaboxer v1.0 (Again)

In case you missed it, they have previously covered Kaboxer in it’s own dedicated blog post, which goes into a lot more detail of why they love it so! For developers, this is a great new tool in the arsenal. Users will, hopefully, not realise that they are using it, only noticing that previously problematic tools now work correctly!

Without repeating what has already been posted, this technology allows them to correctly package up programs that were previously difficult, with items such as complex dependencies or legacy programs & libraries (such as Python 2 or dated SSL/TLS).

With Kaboxer’s launch, they have released 3 packages using it:

⦿ Covenant – Daemon using server/client network model

⦿ Firefox (Developer Edition) – Big GUI desktop application

⦿ Zenmap – Legacy libraries (Python 2) application

If you want to read more, please see either their blog post covering it, or their documentation around it.

Kaboxer is still in its infancy, so please be nice & patient with it.

Releasing Kali-Tweaks v1.0

Announcing Kali-Tweaks! This is their little helping hand for Kali users, with the idea to help customize Kali to your own personal taste quickly, simply, and the correct way. This should help you to stop doing repetitive tasks.

Currently Kali-Tweaks will help out with:

⦿ Metapackages – Installing/removing groups of tools, which may not have been available while installing Kali if you did not use the installer image

⦿ Network Repositories – Enabling/disabling “bleeding-edge” & “experimental” branches

⦿ Shell & Prompt – Switch between two or one line prompt, enable/disable the extra line before the prompt, or configure Bash or ZSH as the default shell

⦿ Virtualization – Using Kali as a guest VM? Do a few actions to make the experience easier!

See Also: OSINT Tool: LinkedIn Scraper

Their philosophy is to always understand what you are running, before you run it. That way, it reduces the chances of any undesirable nasty surprises. Which is why they will always encourage anyone to do actions manually before automating it, so you get to understand what is happening under the hood. On the flip side, they also understand there is so much to remember. Then when you sprinkle in people’s bad habits, which often have long term implications and end up breaking Kali, there is room for improvement. So, they started developing Kali-Tweaks. Where possible, Kali-Tweaks will also display what commands are being executed to help educate users.

They do want to mention a few things:

⦿ kali-tweaks has been marked as “recommended” rather than “required”. As a result, if you are upgrading Kali, it may not be included. On the other hand, you can remove kali-tweaks without removing anything else

⦿ On the subject of upgrading; depending on how old your Kali installation is, you may need to reset your shell resource (e.g. .bashrc & .zshrc) before you can use the “configure prompt” section. This is because it will not have the necessary variables. Should you want to, make sure to backup, reset, and restore

⦿ The last thing to point out, when changing the default login shell; please log out and in again (either graphically or remote console) for it to have an effect

It is still early days with Kali-Tweaks, and they already have ideas of what to expand into, but they welcome any suggestions from you!

Kali-Tweaks is still in its infancy, so please be nice & patient with it.

Refreshed Bleeding-Edge Branch

Kali’s Bleeding-Edge branch has been around since March 2013, but they have recently completely restructured the backend.

For those not too familiar with Bleeding-Edge branch, here is a breakdown:

Kali by default opts to be stable where possible when packaging. This means some tools may appear to be “out-dated”

• They do this by looking to see when the tool author(s) signals “everything up to to this point is good”, by doing a “point release” (e.g. 1.0 or 2.1)
• Developers often use source-code version control, allowing them to track any changes
• How programmers use source-code version control depends on their work flow, experience, and team size
  • Developers can use a “tag” feature found in most source-code version control to signal when there is a new version (this is what Kali prefers)
  • However, some people may say if it makes it to “master” or “main” branch, then it is “production ready”
• There are times where it has been “a while” (months or even years) since doing a tag for a stable release (aka point release), and people get frustrated that there are no updates (e.g. hashcat or impacket).
  • In other cases, you want the latest code which may include an exploit 0day (e.g. Metasploit-framework, Empire, or Exploit-DB) so waiting for a tag release may not be an option

You may then end up skipping the Kali package and compiling your favorite tool’s source-code. This might then conflict with Kali’s packaging, and it is your responsibility to maintain the program. This is where bleeding-edge branch comes in.

See Also: Jeff Moss, aka Dark Tangent, the person who founded DEF CON and Black Hat

Since moving over to GitLab, they have been able to create Kali-Bot to help with heavy lifting and automation

• Automatically package tag’d releases to kali-experimental branch
• Automatically package the last commit to kali-bleeding-edge branch

This is a fully automated procedure, as a result, the testing that goes into their packaging is automated as well (unlike anything that is in kali-rolling branch which has manual testing involved). If there has not been a unit test created, its not going to be tested for. This means there is a chance packages will be broken, and more trust goes into the tool author having correctly developed the tool.

If you want to give it a try, have a look at their kali-bleeding-edge documentation to learn how to enable the repository and how to tell apt to select a package from this repository. Once the repository has been enabled, it looks like this:

kali@kali:~$ dpkg -l \
  | grep ffuf
ii  ffuf             1.3.1-0kali1                        amd64        Fast web fuzzer written in Go (program)
kali@kali:~$
kali@kali:~$ sudo apt install -y ffuf/kali-bleeding-edge
...
kali@kali:~$
kali@kali:~$ dpkg -l \
  | grep ffuf
ii  ffuf             1.3.1+git20210505.1.f032167-0kali1~jan+nus1 amd64        Fast web fuzzer written in Go (program)
kali@kali:~$

Not every tool has made it to the new system yet as there are still many limitations to overcome, but to see what is supported and also how many:

kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-bleeding-edge/main/binary-amd64/Packages' \
  | awk -F ': ' '/^Package: /{print $2}'
...
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-bleeding-edge/main/binary-amd64/Packages' \
  | awk -F ': ' '/^Package: /{print $2}' \
  | wc -l
78
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-experimental/main/binary-amd64/Packages' \
  | awk -F ': ' '/^Package: /{print $2}' \
  | wc -l
192
kali@kali:~$
kali@kali:~$ curl -s -L 'http://http.kali.org/kali/dists/kali-rolling/main/binary-amd64/Packages' \
  | awk -F ': ' '/^Package: /{print $2}' \
  | wc -l
59518
kali@kali:~$

The numbers will only grow bigger and better as time goes on, with less bugs in the code and more unit tests in place!

If you are a tool author and want to get your software on the list, please chat to them, and they can show how to enable webhooks!

Disabled Privileged Ports

They have patched their kernel to remove the restriction of requiring privilege permission in order to use TCP & UDP ports under 1024 (meaning 0/TCP-UDP <= 1023/TCP-UDP). This was done because:

• They see Kali as a desktop OS, rather than a server
• This “well-known” privileged port range is reserved for server services (e.g. 80/TCP HTTP, 443/TCP HTTPS)
• With the switch from Kali’s root to non-root user by default, rather than doing a port forward from outside the privilege ports to a restricted port, people were just running the program with super-user permissions instead
  • They get it. It’s quicker to run: $ sudo <program>,
  • Rather than remembering something like: $ sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8888
  • It also can get complex and confusing with a lot of redirects setup in place
  • Alternatively people were using authbind to allow certain users to use certain ports
• This defeats the point of switching to non-root user!
  • Let’s reduce any possible attack surface!

Now, this change won’t appear in all instances as some flavors of Kali operate without their kernel. This depends on which platform you use (such as Cloud instances, Docker or WSL). If you are on a platform that does not use their customized Kernel, this change will not be applied. For example, the top one uses Kali’s kernel on a bare metal install, and below uses Kali in a docker container, so its using the host’s kernel:

kali@kali:~$ uname -r
5.10.0-kali7-amd64
kali@kali:~$

...vs...

$ docker run --rm --interactive --tty kalilinux/kali:latest uname -r
5.10.25-linuxkit
$

New Tools in Kali

It would not be a Kali release if there were not any new tools added! A quick run down of what’s been added (to Kali’s archive and network repositories):

• CloudBrute – Find a company infrastructure, files, and apps on the top cloud providers
• Dirsearch – Brute force directories and files in web servers
• Feroxbuster – Simple, fast, recursive content discovery
• Ghidra – Reverse engineering framework
• Pacu – AWS exploitation framework
• Peirates – Kubernetes penetration
• Quark-Engine – Android malware scoring system
• VSCode a.k.a. Visual Studio Code Open Source (“Code-OSS”) – Code editor

Ghidra and VSCode have been included into the kali-linux-large metapackage, so they are included on the installer image for people doing a fresh install. Otherwise you will need to upgrade Kali (if you already have the kali-linux-large install) or manually install them (if you want them!):

kali@kali:~$ sudo apt update && sudo apt install -y ghidra code-oss

A few notes about code-oss (aka VSCode):

• They are compiling this from source, rather than using the pre-built binaries
  • The upside to this is that telemetry data is disabled by default
  • The downside is that some aspects of the marketplace may not work. If you find these limitations a problem, you may wish to uninstall the Kali package and switch to the VSCode pre-built binaries
• You also may question why it was named code-oss, rather than code
  • Code-OSS is what the source-code calls itself, which is used as the base before the configurations are applied for the pre-compiled binaries that gets distributed as “code”
  • As they are using the source-code, we used the variables defined by it
  • The two different names help to distinguish the differences between them (also prevents any clashes and conflicts!)
  • They also included various aliases in their package to help bridge between the two different versions. Meaning, calling vscode and code will use their package, code-oss, with a friendly notice (when installed)
• If you already have the pre-compiled version installed, upgrading Kali will not replace it
  • However, when manually installing code-oss, it will then replace it!

Click the link below to view the full article:
https://www.kali.org/blog/kali-linux-2021-2-release/

Source: www.kali.org

(Click Link)