Skip to content

Kodachi Linux: A brief Security Review

I was recently made aware of Kodachi Linux, which according to it’s website has gotten critical acclaim. This is a superficial attemt to look at the distribution – if it’s even fair to call it that.

Off the bat, it doesn’t start well:

Confusing documentation

For best security results (Email – Banking – Cryptocurrency):

  • ISP > Host machine (XMR anonymous VPN) > Linux Kodachi VPN (Virtual machine – Vmware) with firewall forced VPN Traffic > Kodachi browser > Dnscrypt (Best model)
  • ISP > Linux Kodachi VPN with firewall forced VPN Traffic > Kodachi loaded browser > Dnscrypt
  • ISP > Linux Kodachi VPN with firewall forced VPN Traffic > Kodachi loaded browser > TOR DNS
  • ISP > Linux Kodachi VPN with firewall forced VPN Traffic > Kodachi lite browser > TOR DNS (Fast)
  • ISP > Linux Kodachi VPN with firewall forced VPN Traffic > TOR browser > Dnscrypt
  • ISP > Linux Kodachi VPN with firewall forced VPN Traffic > TOR browser > TOR DNS

This confuses security and anonymity. While the majority of such sites today employ TLS (https), sending traffic through unknown VPN’s and Tor may potentially send your traffic to an attacker. You have no knowledge of the motivations of people running tor exit relays, and while they may provide anonymity, they are not meant to provide security.

Furthermore, Warith Al Maawali, the author of Kodachi, openly admits to transferring a hardware hash by default, upon boot:

I pay monthly rent to run the VPS nodes and utilize them for VPN which is provided to you, I do not collect ANY data or store ANY information (Logs) that belongs to the user except the hardware ID (hash) and connected IP address (VPN IP) that has to be sent automatically when your PC establishes a connection to the VPN

How on earth did he conclude that it was a good idea to transmit a hardware hash on boot, for a security and anonymity focused distribution? I could accept it, if it only occurred after the user choosing to use his VPN. As it is, it automatically transmits it upon boot.

What is Kodachi

Kodachi is not what I’d call a distro. The repositories are simply the default Ubuntu repositories. It’s simply Ubuntu – with a theme and some shell scripts to manage the extra security features. This should be acknowledged more prominently in my opinion, especially given the somewhat dubious license he publishes. His code is not the OS; it’s a few shell scripts.

Networking disaster

For IPv4, Kodachi at least manages to configure things correctly. A tracepath -4 vg.no indicates that yes, it does indeed go through VPN and possibly Tor:

But for IPv6 it falls apart! IPv6 is enabled and functions. Note that I redacted first two hops as they’re inside my own network – but the third hop is the Hurricane Electric termination point for my IPv6 tunnel…

This is a devastating fault in a distribution attempting to provide anonymity! Unaware users may be trivially trackable through IPv6 – beliving the system uses the VPN’s they told it to use. Some packages that are included, such as youtube-dl will happily use IPv6 where available.

While I’m usually speaking warmly in favour of IPv6, at this point in time it probably makes more sense to just disable it totally, if your goal is anonymity. It’s a risk in this scenario, because the tools that work on IPv4 often is unaware of IPv6.

Furthermore, he seems to confuse dnscrypt and VPN. The desktop shows ISP->VPN->DNScrypt – which is… unclear. DNSCrypt is for ensuring DNS lookups, not network traffic in general!

Installed software

This section can be described as everything including the kitchen sink. It includes:

  • Audacity
  • Remmina
  • LibreOffice
  • OpenSSH server
  • GCC
  • Postfix (which is even enabled and listening!)
  • And much, much more.

This probably stems from the fact that this is a Ubuntu Live Image, with minimal modifications. But more software means a bigger attack surface. That’s probably not a good thing in a system focused on maintaining anonymity. Software such as popularity-contest is installed, although disabled. There’s no sane reason for this being installed!

Heck, even avahi is installed. Why would you want a piece of software made for announcing your presence on such an installation anyway? It simply doesn’t make sense. Removing it would make the system work as fine, and remove one potential problem.

This is the general problem here; everything is installed, and available. This allows the user to make mistakes without realizing their mistakes. Limiting options reduces the likelihood of such mistakes, and reduces the attack surface.

File encryption

File encryption appears to be provided by a custom Python 2.x script named lock.py, with a shell script wrapper named lock. lock.py appears to be a Python script written by Joe Linoff, although the creator of Kodachi gives zero references to using this piece of software, nor that he is not the creator. The script is released under a MIT License from what I could find. As far as I can tell, Warith Al Maawali, the creator of Kodachi, does not include this license – thus not abiding by the terms of distribution for lock.py.

This is likely the reason why he writes the following in his changelog:

I tried to move to Ubuntu 20.04 but Python deprecation was a hassle for me to continue so I continued with 18.04.6 for now bare in mind that 18.04 support is still valid for Ubuntu and it should reach end of life by April 2023.

This changelog is by the way worth reading. It contains a few WTF’s.

The bash scripts

The software that actually is Kodachi appears to be a collection of bash scripts in ~/.kbase/. The quality of these scripts makes me wonder. Some of the scripts contains a bash tutorial in the top of the scripts:

Let me show the snippet that generates the hardware hash:

function getID()
{

    a=$(sudo dmidecode -s system-uuid);
    b=$(sudo dmidecode -s system-serial-number);
    c=$(sudo dmidecode |grep -w ID:|head -n1);
    d=$a.$b.$c;
    f=$(md5sum <<<$d| tr -d -|tr -d ' ');
    g=$(echo $f | cut -d ' ' -f 1);
    e=$g;
    writeToJason "$e" "kodachihwid";  
}

First of all, this is unforgivable. This is data that uniquely identifies a computer, and he transmits that. If the computer is used for anonymity, this hash allows anyone controlling the end point to check if a user corresponds to a physical computer. And Al Maawali transmits this to his own server! Stay away from Kodachi, except as a exercise of how to not do things!

Second, this snippet indicates someone who doesn’t entirely know what they’re doing, with constructs such as g=[...], followed by e=$g for no obvious reason. The poor variable naming makes mistakes more likely, and reduces readability, which is important in security related software.

But the flipside is also that it doesn’t do what the author believes it does; it’s trivial to edit the script and replace this function with the following, which will return a random, unique hash each time, thereby removing his ability to block people:

function getID()
{
    writeToJason echo "$(head -n 1 /dev/urandom | md5sum | cut -d " " -f 1)" "kodachiwid"
}

It gets even better. Let’s look at how he handles networking:

    IP=$(cat $Jason_web_file_name| jq -r '.ServerFeed6[].Netcheckdomain1'|xargs);
    # Validate jsons here           
    if [[ ! -n "$IP" ]]
    then
        netIP="mail.com";
        print_error "Failed to get json variable IP setting it to: $IP";
    fi  
    echo "Switching domain to $IP";
    echo "Dhcclient the smart way"; 
    for i in $( nmcli device status | awk '{print $1}' );
    do
        if [[ $i != "DEVICE" ]]
        then
            echo "Dhcp for:$i";
            sudo timeout 60 sudo dhclient $i;

        fi
    done
fi

First of all, the messages printed doesn’t make sense. Switching domain to $IP? And no, dhclient ain’t the smart way. The system uses NetworkManager. He ignores this, and runs dhclient directly. In addition, he runs it for every interface. Including lo, the loopback interface. And for good measure, he uses sudo timeout 60 sudo[...]? Why the double sudo?

This in fact leads me to the fact that this distro has enabled passwordless sudo for the default user. Why? This reduces security in my opinion. Sure, it’s more convenient, but in a security and privacy focused distribution, the author should not make such choices for the user – and the author should not make the system depend on passwordless sudo.

In addition, there’s blatant abuse of sudo where it’s clearly not needed. There’s lines such as VPN_IP=$(sudo curl -s -m 30 $randomdomain ), where sudo serves no purpose. Is the author simply used to slapping on sudo in front of commands to make sure they work, without understanding what sudo does…?

The ban function…

So he can ban users using his VPN if he considers them abusive. How does he accomplish that? Surely it has to be server side, right?

Nope. Just kidding! It’s handled client side.

function banAction()
{

    SERVICE='openvpn';
    if (ps ax | grep -v grep | grep $SERVICE > /dev/null)
    then
        sudo killall -SIGINT openvpn;

    fi

    SERVICE='tor-service';
    if (ps ax | grep -v grep | grep $SERVICE > /dev/null)        
    then
        sudo killall tor; 
    fi

So… he sends the HWID to the server, and if the server replies banned, the client politely kills all VPN connections. But it’s a bash script; it’s not exactly hard to comment out a few lines here and there.

This is a illustration of the level of brokenness in Al Maalawi’s security thinking – he doesn’t understand that you can’t trust the client in such a scenario. Would you seriously trust this guy to handle your security?

Utter lack of firewall!

One of the biggest problems is that there’s no firewall configured. Nil, zip, nada. Heck, it has postfix installed and listening!

$ nc 10.0.3.153 25
220 Live-OS.localdomain ESMTP Postfix (Ubuntu)

500 5.5.2 Error: bad syntax

This is from a different computer on the same subnet. What possible rationale does this decision have? It’s a security risk. There’s no meaningful scenario where this is wanted on a computer used to anonymously connect to the Internet. It’s only ever relevant on an e-mail server.

In addition, Kodachi doesn’t block traffic before the VPN services is up. It should! A firewall dropping incoming packages would also increase safety in case something listens by mistake – think defense in depth. A configured firewall would mitigate the by-default listening Postfix – although I’d expect the author to have better control over configured services than he shows.

The security score

Kodachi gives you a 0-100 score, supposedly to inform you how secure you are. The problem is, of course, that it doesn’t really tell you anything! Consider the following:

SERVICE='tor-service';
  if (ps ax | grep -v grep | grep $SERVICE > /dev/null)
    then
    theModel="ISP->VPN->Tor";
    securityScore=$((securityScore+30))

Kodachi doesn’t test if tor is actually in use; it’s enough that it’s running. Or how about firewall?

if(sudo ufw status |grep tun0 > /dev/null)
    then
          securityScore=$((securityScore+2));
fi

Too bad if the interface gets renamed to tun1. It also doesn’t check if the rules is sensible; just that some rule contains tun0 somewhere. A allow any from any with tun0 as comment will bump the score.

As it is, this number is largely meaningless. A secure system can score 0, and a secure system can score 100. At the best it’s not useful. At the worst, it’s actively harmful because a user may be mislead by a good score.

Apparmour

As it’s based off Ubuntu, Kodachi comes with Apparmour. Sadly, it only uses the default profile available in Ubuntu, with no adaptations. Apparmour could be a valuable piece of Defense in Depth, ensuring that a problem in a browser can’t compromise the entire system, by e.g. restricting the browser to read and write to a defined set of directories. This is, sadly, not done.

Discord is the point of contact.

The guy hangs out in a discord chat. The more privacy conscious people I know won’t touch discord with a 10 feet pole. Not having a IRC channel seems like a strange choice – although it doesn’t affect the security of the distribution, it’s indicative of the mindset of the author. In addition, it’s obviously a single author, not a community or group of people.

Summary

This is what I found in a couple of hours of looking. Some of the findings are serious, some merely indicate carelessness from the creator of the system – indicating that he doesn’t have good knowledge in security. The bash scripts indicates someone who has no programming background, and no Linux administration background, with strange constructs such as using NetworkManager to fetch a list of devices – but does not use NetworkManager to configure them, calls dhclient for loopback interface, and so forth.

Many of the choices won’t affect a security conscious user, but they will allow a novice to configure the system in a insecure state. More choices available essentially means that people can make more mistakes. Tails has recognized this, and provides a secure baseline, that’s not easy to break apart. Where tails allows for insecure configuration, the documentation clearly warns about this. The documentation for Kodachi is severely lacking, both in content and in warnings.

I could probably find more problems if I spend more time looking, but it’s simply not worth it. What I’ve found removes all trust in the author, and the advice is simply to stay far, far away from this piece of software. It’s not secure, and the author doesn’t know how to secure a system.

In short: Do not use Kodachi. There’s other that’s better:

They differ somewhat in scope and functionality. Read the documentation, and find the one that suits you. All of them have active communities. But stay away from Kodachi.

Post a Comment

Your email is never published nor shared. Required fields are marked *