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.
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:
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:
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
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.
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
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.
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
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!