How Secure is Kali Out of the Box?

I often see people lable Kali as dangerous to dual boot and that you shouldn’t run Kali as a daily driver, and I often wonder how much truth there is to this. Personally, going into this, I don’t think there is much truth. Today we’re going to run an experiment to see just how safe Kali is OOTB.

Setup

For this test, we will be using Kali 2021.2 installed on a virtual machine. First we’ll issue an apt update && apt upgrade to update all installed packages on the distribution; this is a command that I believe your typical pentester would run fairly often.

There was a total of 20 packages that needed to be upgraded, for specific analysis, here’s the packages:

  apt apt-utils bash distro-info-data exploitdb firefox-esr firmware-sof-signed libapt-pkg6.0 libgnutls30 libhdf5-103-1 libhdf5-hl-100 libogdi4.1 libpfm4 libxnvctrl0 metasploit-framework mimikatz passing-the-hash rebind spooftooph voiphopper

To me, it seems like most of these packages would likely be upgraded for security purposes. Let’s move on. In terms of the specific Kernel/OS Version, let’s take a look:

Kernel

The kernel running is 5.10.40-1kali1 which is dated by about 6 months, however, on the next major release, we should expect another minor kernel upgrade. Traditionally, Offensive Security updates the Kali kernel on their quarterly releases. See here for what Kali Version has which kernel.

In terms of vulnerabilities for version 5.10 of the Linux Kernel, there’s about 7 or so, not all of which exist in the final version of the 5.10 of the Kernel.

https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/version_id-646877/Linux-Linux-Kernel-5.10.html - Release Candidate 1 https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/version_id-647836/Linux-Linux-Kernel-5.10.html - Release Candidate 2 https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/version_id-658135/Linux-Linux-Kernel-5.10.html - Release Candidate 4 https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/version_id-646876/Linux-Linux-Kernel-5.10.html - Full Release

None of these vulnerabilities pose a major risk that effect the Kali kernel, and to be honest, the only high severity vulnerability targeted for 5.10 is actually mislabeled and is meant for 5.9.3:

An issue was discovered in the Linux kernel before 5.9.3. io_uring takes a non-refcounted reference to the files_struct of the process that submitted a request, causing execve() to incorrectly optimize unshare_fd(), aka CID-0f2122045b94.

So in terms of Kernel exploits, very little exploits publicly exist.

Running Network Services

In terms of running network services, very little exist. The only recorded service running on my Kali device was DHCP which was communicating with my Router to prevent the DHCP lease from expiring.

This can be verified in Wireshark as well:

Privilege Escalation Scripts

We’re also going to use LinPEAS as quick way to audit potential vulnerabilities that will allow us to elevate privileges. The first major category here is Processes; no running root processes jump out to me. All standard stuff:

Next up is Cronjobs, a few interesting jobs exist, however, none of them have RWX permissions for any user other than root, so we’re all good on that front.

Next we’ve got SUID binaries:

Sudo is the interesting one here as recently the Sudoedit Bufferoverflow exploit came out, however, Kali 2021.2 is not vulnerable:

Versions 1.9.5.p1 and lower are vulnerable. The only other big thing that jumps out here is the Kismet binaries, which are advised to be configured as SUID binaries:

https://www.kismetwireless.net/docs/readme/suid/

So at first glance, there isn’t any huge vulnerabilities that you may be able to leverage to gain root access. The only minor thing is the user you create will be in the Sudoers group, so you should choose a strong password. If you would like to review the LinPEAS output, you can do so here

Remote Scanning

Pivoting over to my Kali machine that I use for daily ops, lets start with a couple nmap scans, we’ll do a Full TCP Connect, Syn Stealth, and a X-mas scan:

No scan seemed to matter here, moving onto UDP:

Edit: After I published this, the UDP scan was still running. If an attacker manages to find a vulnerability 2 hours into a UDP port scan, they can have it.

Nessus Essential

Next up, we’re going to run a remote scan on our 2021.2 Kali box. The next sections going to contain a number of screenshots that displays the Nessus Scan Config so anyone reading can replicate it.

Scan Type: Advanced Scan

Basic -> General

Discovery -> Host Discovery

Discovery -> Port Scanning

Discovery -> Service Discovery

Assessment -> General

Report

Now that the scan is setup, we can run the scan by pressing “Save” and clicking on the “Play” button.

In about 10 minutes, the scan will finish and you will likely recieve something pretty similar to what I did – No major vulnerabilities that Tenable advises you patch:

A grand total of 4 Informational level “Vulnerabilities” were identified:

1. Traceroute Information:

For your information, here is the traceroute from 10.10.10.100 to 10.10.10.234 : 
10.10.10.100
10.10.10.234

Hop Count: 1

2. Nessus Scan Information:

Information about this scan : 

Nessus version : 8.15.0
Nessus build : 20271
Plugin feed version : 202106260143
Scanner edition used : Nessus Home
Scanner OS : WINDOWS
Scanner distribution : win-x86-64
Scan type : Normal
Scan name : Kali-OOTB
Scan policy used : Advanced Scan
Scanner IP : 10.10.10.100
Port scanner(s) : nessus_syn_scanner 
Port range : all
Ping RTT : Unavailable
Thorough tests : yes
Experimental tests : no
Paranoia level : 2
Report verbosity : 2
Safe checks : yes
Optimize the test : yes
Credentialed checks : no
Patch management checks : None
Display superseded patches : yes (supersedence plugin launched)
CGI scanning : disabled
Web application tests : disabled
Max hosts : 5
Max checks : 5
Recv timeout : 5
Backports : None
Allow post-scan editing: Yes
Scan Start Date : 2021/6/26 16:37 Eastern Standard Time
Scan duration : 566 sec

3. IP Protocol Scans

The following IP protocols are accepted on this host:
1	ICMP
2	IGMP
6	TCP
17	UDP
103	PIM
136	UDPLite

4. ICMP Timestamp Request Remote Date Disclosure

The difference between the local and remote clocks is -20 seconds.

I wouldn’t quite qualify any of these as an actual vulnerability. Now lets try a low privileged internal scan by enabling SSH and giving Nessus a set of credentials. The user account will be named “banana” and will have the password of “banana”

In about 5 minutes, the scan should have finished and we’re ready to review the data returned.

There were a grand total of two major vulnerabilities found.

One of which is a misreport – According to this article (Referenced by Nessus) we can manually validate this finding as a privileged user by checking /sys/devices/system/cpu/vulnerabilities/mds

And we can see that our device is not vulnerable. This leaves us with one major vulnerability left; an outdated version of OpenSSH. The reason Nessus flags this as a vulnerability is because there is a social engineering attack within OpenSSH called “Double Free” which requires a user to connect to a malicious SSH server where an attacker has root privileges; the attacler can then send specially crafted data to gain code execution. This would not be an easy vulnerability for an attacker to exploit as no public Proof of Concepts exist meaning that if an adversary would like to exploit this vulnerability, they’ll be building it from the ground up.

Src: https://www.cybersecurity-help.cz/vulnerabilities/51444/

28 Other Informational Level vulnerabilities were found, most of the information reported was related to valid credentials, SSH Configuration, OS versions, etc.

Note: I also ran a credentialed scan against the root user account. The MDS vulnerability was no longer present, all of the same issues found in the original credentialed scan were also present. The CSV is avalible for download here

Conclusion

To me, the phrase “Kali is insecure” is a very uninformed statement. It’s like saying “Ubuntu Server is insecure”. Sure, in the real world you might take actions to harden Ubuntu Server, just like you might choose to install and deploy UFW on Kali.

Based on the tests preformed today, as long as you keep your Kali distribution up to date and ensure the Kernel and public facing services are all up to date, I see no reason why Kali could not run on bare metal.

As long as you, the user, is educated enough in System Administration to know what starting a new service or hosting an application on your Kali machine might introduce (vulnerability wise), there is absolutely no reason you need to worry about your Kali machine.

My professional advise is this: Use a strong password (Not Kali:Kali), don’t keep that password in any text files on your Kali machine, and don’t store any sensitive data (long term) on your Kali machine and you will be perfectly fine.

Happy Hacking everyone!