Wednesday 13th, March 2013, 10 years ago, Kali Linux v1.0 was first released. Today we want to celebrate Kali’s 10th anniversary!
Time has flown. And gosh, a lot has changed since then!
They grow up so fast!
This is the story of how Kali came to be, and some of the challenges along the way.
Yesterday is History: The Past
How did we get to where we are today? There is a quick answer, and a not so quick answer.
history lesson
Knoppix - Initial two weeks work
Whoppix (White-Hat and knOPPIX) came about as the founder, @Muts, was doing an in-person air-gap network penetration test lasting for two weeks in 2004. It was a government contract, and he was not allowed to bring in his own laptop nor allowed to install any software on their machines. So every day, he was only allowed to take in software on a CD-ROM, before it was destroyed at the end of each day. At the time, Live CDs were the “in thing”. They would allow you to run a Linux OS completely off a disk, using RAM as a temporary HDD, without leaving a trace behind. Knoppix was chosen as the base OS which is Debian-based.
He created one for this assessment and pre-loaded it with various tools that he believed he would need for the job. Each night, he would go back, tweak it by adding more tools or bug fixes. After the assessment was over, he cleaned it up and shared it online on a forum in August 2004.
He then left for a vacation. Upon getting back he checked the logs to see the download numbers, and could not believe that it was so popular! He started to get requests from people, asking for tools to included as well as bug reports.
Merging into BackTrack
At the same time, there was a similar project happening over at remote-exploit, Auditor Security Collection (based on Knoppix), which first started in 2005. Auditor and WHAX had similar goals, but different strengths. At the time, cooperation on “Open-Source projects” was very different to what it is today, as it was “I made this thing, I’m sharing it.” It was more a few large players contributed, rather being able to accept work from lots of smaller submissions. After a bit of discussion between the authors, it made sense rather than both projects tackling the same problems, for the projects to merge together. This created BackTrack in May 2006. Initially, it was still based on Slax, but moved to Ubuntu later on.
Editors note: We cannot say for certain, where the name “BackTrack” originated from. At the time, when internally debugging problems, the phrase “Back tracking though the logs” got said frequency. We cannot say which came first, the phrase or the name.
, was created. Training from the people who made the tools. Who else would know it better?!
USB - Live-Boot & Persistent
BackTrack now had a stable, mature Live-CD project and it was exactly what was needed for the problem which was air-gap networks at the time. Whilst these Live-CDs had was the answer for some scenarios, the team wanted to expand into more areas. The cost of USB flash drives/sticks had came down dramatically, as a result were more freely available. There was then a shift to “Live-Boot” (either CDSs or USBs). The next item to solve would be getting their data to be “persistent” rather than losing it when powered off. Enter BackTrack 3 in June 2008.
System Updates
A few months later, the team was once again at Black Hat USA & DEF CON, and were really excited by how many people were using their creation, and got to see first hand how people were using it. DEF CON was also aware, as they were tracking user’s user-agents in web requests!
Times were different to how it is now. It was common for big exploits to make an appearance around these security conferences. 2008 was no exception.
Walking about, the team could see first hand how many people were vulnerable, and they were helpless as they had no way of pushing out a patch.
A drawback with Live-Boot is that in order to update to the latest release, you need to replace the whole OS. A complete re-install. Even with persistence for USBs, it is more for user data, rather than packages. Even if you installed BackTrack, there was not an update mechanism as the infrastructure was not in place to support it. You could not get the latest version. You would have to do a complete re-install.
The team knew what their next problem was to solve: system updates.
As the project needs changed, the team had started hitting technical limitations of using Slax as the base, and started to look for an alternative underlying OS. They needed a way for end-users to easily update their system, without doing a complete re-install.
Ubuntu was making a lot of positive noise, was gaining a lot of traction as it was popular with end-users, and had good development tools. It allowed for package updates to easily be applied to people systems. In February 2009, at Shmoocon, BackTrack 4 “Beta” was released using Ubuntu.
This change signals the start of BackTrack becoming a “real OS” - a traditional fully feature distribution.
Previously when there was a major change, there would be a new name for the project. However, because BackTrack was getting to be known, it had grown legs, started appearing in the media, it was becoming ingrained in pop culture, they wanted to keep the momentum going.
Installer
In various releases prior, there was an installer included, which got carried over from the underlying base OS (Slax). However, it was not straight forward to use, and it was expected that certain commands were ran prior to execution. This, plus not allowing for any customization meant it was dropped in later releases.
System Upgrades
When the team started work switching from Slax to Ubuntu, they grabbed the latest release at the time (8.10 - Intrepid Ibex). As this was not a “Long-Term Support” (LTS) release, upstream would only support it until April 2010 - one year & six months.
This means, towards the end of this version, updates became fewer, packaging became harder, and workload increased. Things were not as stable as when it was first released.
It was not until May 2011 that the next major version of BackTrack got released, which also happens to be the last, BackTrack 5. This time, it was based on Ubuntu 10.04 (Lucid Lynx) LTS. This gave three years of support from upstream.
, as well as
Kali 1.0 (Moto) and was based on Debian 7. With the new infrastructure in place, building and publishing images became more automated and simplified. As a result, there were multiple revisions made to address bug fixes and even a minor update. This gave a better experience for users, as they were not having to wait months for an updated image.
&
Moving to Rolling
Overall, the feedback received for Kali 2.0 was positive, and it was a success. One of the reasons it was so well received was because of the updated versions of most packages.
In information security (infosec) there is the need to be on the latest version. This is often because:
- Being a developer, you may need the latest feature which has just been added.
- Being a system administrator, a patch could contain a security update to stop a vulnerability.
Writing exploits or developing infosec tools is no exception, they often need to have access to the latest libraries.
Debian is stable, and that is because they only update their stable release about every two years, in order for packages to then be the latest tested version. They will manually “backport” updates to patch any security vulnerabilities for older versions in order to fix that version of the package
As two years is a very long time in infosec to wait to get an update, users were following bad practices in order to attempt to get the latest version. At times, they would break their setup in the process.
The team had their new challenge to try and overcome!
To help understand why, it may take up to two years to get a package updated in stable. However, that does not mean its not ready before then as there is a whole workflow behind it. There is a branch called “testing”, which is for packages that are ready to into stable, but only when the time is ready for every package. A package will start in “unstable”, and once it passes Debian’s strict package testing process will it make it into testing. There are numerous packages upgrades in testing that never make it into stable, which would be in a stable state to release.
This felt like a good balance of being stable and up-to-date for Kali team.
As soon as Kali 2.0 was out of the door, the Kali team knew what they had to do. Move from “Debian stable” to “Debian testing”.
5 months later, January 2016 Kali become a rolling distribution with Kali 2016.1.
Believe it or not, there is even more to the story where can go into more detail. If this is something you would like, let us know!
Dragon Logo
Throughout the projects, one item has been constant. The logo. The dragon. To the point that the logo is potentially better known than the project itself!
What originally started out to be a competition, originating on the Whoppix forum, the idea was “best graphic will be the next wallpaper”. The first submission that was awarded the winner, was the dragon. We liked it so much, we never re-opened the competition for the next version!
What we did not know at the time, was that the submission was plagiarized. It was taken from deviantart without the authors permission. We tracked down the rightful author and bought out the rights to it for Kali Linux.
The design of the dragon has been slightly tweaked over the years, by altering here and there such as making it thinner in places (put on a diet!), curving the tail a little more etc. But we have always been careful to protect the iconic image as it is one of the most recognizable logos in this space. And to answer the question, we have no plans to ever replace the dragon logo.
BackTrack 6?
Rather than releasing BackTrack 6, Kali 1.0 (Moto) came out instead. But why? With BackTrack 3 -> 4 (Slax to Ubuntu), why not with BackTrack 5 -> 6 (Ubuntu -> Debian)?
Why was there such a fresh start and not keep the momentum going?
Well, a few new problems had started to arise, some technical, others not, and the team knew that one day they would need to find for solutions, such as:
Upstream origin
Ubuntu worked well for a number of years, however the team were increasingly finding that they were running into technical issues, causing limitations. At the time, if someone found an issue with a package on BackTrack, if it was not something custom to BackTrack, it would need to go “upstream” to Ubuntu. As Ubuntu uses Debian as its base, if they have not forked the package, it would need to then go to Debian to solve it. Then when a patch is created, it would need to be pushed into Debian, to be pulled into Ubuntu, to be pulled into BackTrack. This was a lengthy procedure. Otherwise, the team would have to fork a package, thus taking on ownership and responsibility of maintenance, to include a patch.
With more packages requiring forks, more time was spent maintaining the OS rather than security focused aspects, which took the fun out of the team as it became more of a nightmare.
The decision was made to cut out the middle layer, to use Debian as the base, rather than Ubuntu.
Upstream direction
By also using another OS as your base, you often follow their direction for their project. You can alter, but it does add additional complexity when synchronizing (think git rebase). This takes time and focus away from what makes BackTrack, BackTrack! Ubuntu had announced a major desktop environment change. Going from GNOME as their default to something they had created, Unity (and Mir). At the time, it had caused a bit of controversy. We also knew that certain tools would not be compatible.
Editors note: Whoppix & Whax both used KDE as the default Desktop Environment, and we switched to GNOME when using Ubuntu.
We also did not know just how difficult it ended up being to fully customise Ubuntu. At the time the Ubuntu developers had put various restrictions in place to stop things which we needed to-do. We believe this was because they were trying to make a OS that was user-friendly for people first starting out, rather than for people who were experience with Linux, who would be trying to-do a penetration test.
Stability
If we were going to be using Debian, it is best to follow their rules. Therefore we needed to follow “the correct Debian standard for packaging”. This meant we had to abide by Linux’s Filesystem Hierarchy Standard (FHS). This was introduced right back in the start with Whoppix so people had gotten used to /pentest directory, and liked it. However, it was a reason why the project had stability issues, thus users may have issues upgrading. It was not the best way to manage or maintain packages. The upside is, programs got added to $PATH, allowing you to call a program from any location!
The lack of FHS was hurting us in many different ways. Because of packages not being in the expected Linux location, we had to manually create links for libraries. This was of course a dependency nightmare. As you then expected, it was painful to update packages due to the amount of work, thus tools became outdated.
This was also a reason why you should not have added BackTrack’s network repository to another OS! Plus if you started to try an install things outside of BackTrack’s network repository, it was only too easy to have a knock on effect breaking something else. It was not right to be so worry to perform an update, as simple updates may break installs.
Package maintenance
Because of Debian’s standards, for end users, it helped to make packages more stable as well has having defined path for updates and upgrades. For us developers, maintaining a package also became easier. As a result, we can:
- Look at a package’s metadata, so we know where the code upstream is (where it lives)
- Have alerts when there has been an updated release out upstream
- Use tools that are design to download and updated code
- Import the update code
- Update any necessary metadata, keeping it up-to-date and relevant
- And include the original archive (in another git branch)
So all we have to do is build the package locally, test it to make sure it works. Then sign off on it, by adding our digital signatures to the packages (so it came from us and not tampered/altered by any malicious party), before uploading the package source to the build bots, which will re-compile it for every supported architecture. Simple!
This mature workflow helps prevent all the odd weird edge cases that were causing users machines to break by doing simple updates. This helps make the system more robust.
Customization
The above talks about packages, but another item to call out is the images. We could then be used to bootstrap builds, allowing for custom images to be generated, such as giving the flexibility for switching between desktop environments creation (GNOME? KDE? Xfce? Something else? Go for it!). Plus, it would support pre-seed answer files during setup, allowing to do unattended fully automate installs.
This is more of a correct way of doing things, rather than a hacky job e.g. generate the files, rather than relying on post-install scripts to modify afterwards.
ARM - multi architecture
Since BackTrack 4, the option was there for ARM support. We then experimented and released ARM support with BackTrack 5. At this point, we knew this was something we wanted to explore more going forwards. At the time, there was a lot of manual work involved, creating chroots for each device (started with Motorola Xoom). With BackTrack, we were forced to build the image, on the device itself, which does not scale well at wanting to support more device. Debian would not only allow for us to do that, but streamlined the process. At this point, we were able to treat ARM as a first-class citizen going forwards. This has been accelerated with and taken it to the next level. The team was growing, and we needed to start to scale, rather than having a few bottlenecks points. Another upside of this was to allow people to get source code of packages.
The team had really never used Ubuntu before, as a result, took multiple attempts to get a functioning eco-system (may not stretch as far as saying working systems!). This time, we did not want to make this mistake again, so we consulted the guy who literally wrote the Debian handbook to get his advice and guidance to understand Debian’s way of doing things correctly from day 1.
We also setup dedicated build boxes, on various different architecture (as we wanted to support ARM). This allowed us for “CI/CD” for packages being built automatically, as well as nightly testing of images and system upgrades. We also setup unit testing for packages, allowing for testing to happen when importing from Debian.
Setup
We knew how important it was to have a functioning setup process, and it needs to be able to cover a lot of different scenarios. With the switch to Debian, we were able to add:
- Full language support - Kali is not limited to English!
- Accessibility support - We were contacted by multiple blind penetration testers
- Straight to setup - We could now install straight from grub without having to boot into a live environment first
Summary
Debian was picked as its one of the largest Linux distributions, community driven (thus open-source), and supports many different architectures & hardware. Rather than using an OS which is forked from Debian, thus adds another layer of complexity of who is “upstream,” it makes sense to go straight to the source. Then following Debian standards & polices had huge advantages for us.
The downside would mean a complete redesign & restructure. And we mean a complete re-do over. Everything from our infrastructure (package & image build bots, network mirror handling etc), the base operating system, our packages. Complete re-write. We stop focusing on BackTrack to focus secretly working away on Kali which took over a year.
Needless to say, it was a LOT of work, but it was completely worth doing it. Both from development team, streamlining so many aspects to giving a greater improvement to user experience.
If you want even more, you can look at at the original blog posts, as well as watch some
Why Kali?
Why “Kali Linux”?
“Kali” was already a part of a team members vocabulary, and when it was put forwards internally, everyone liked it. There are various incorrect claims online of why we picked it (such as it standing for something) but really, we just liked it. Yes, it also means “strong” in Swahili, and is also a Hindu goddess. We. Just. Liked it.
Where did the name come from?
When coming up with the name, we knew we needed something that was cool, catchy, and unique. We did not want to step on any other projects toes in infosec realm, or even IT in general.
One evening at a Black Hat USA, the team was sitting around and trying to come up with a new name. They started coming up with initials of phrases, or merging abbreviations and even looked at coming up with a completely new word. Without any success, one of the team members instinctively went to what they do when naming a new pet; Pantheon names.
After making a list of of various Deities from as many mythologies, the team started looking up to see which had not yet been used in the Industry. Whilst there was a few terms the team really like, they were already in use by other projects. After looking up over 70 suggestions, only one really stood out, “Kali”. Kali is a Hindu Goddess of “Destruction and Rebirth”. It could not have been any better fitting; with one project ending, a new one starting. One of the team members ears twitched when they heard it as a suggestion, as they spoke Swahili, where “Kali” means “Strong”. After a little bit more understanding of the word, there is also a martial art also called “Kali”. Its style? All offense, no defense.
It felt like it was a sign, everything was pointing to “Kali”. It was the only name which came up strong, and there was not a reason not to use it. The team stopped the hunt for a name. The word Kali has a lot of meaning to many different people. Everyone is right, as it means something different to everyone. We. Just. Liked it.
Today: The Present
And today, we have some presents to share with you! We are celebrating 10 years, with various different items.
. We managed to release exactly on the 10 year anniversary date!
We try and not publicly give release dates, as there are many moving parts (outside of our control). This release was no exception, with multiple things breaking daily (Debian installer when trying to build the final RC image, Hugo image altering in our CI pipeline, and fall out from Python 3.11).
, .
Online Puzzle
We also have an online event in the form of a Jeopardy Capture The Flag (CTF) happening over at . Enjoy and hope it keeps you busy for a while!
This challenge will only be “online” for two weeks, but we will offer it up afterwards to be able to download and run offline. Check back on ,
In case you
Sneakers
Kali is now going sneakernet! No, really! We have Kali on sneakers.
This is a very unique and a collectors item.
These are Jordans, with Italian Nubuck and genuine Python (not Python 3.11, but the real thing!).
As these are for a limited time, as well as being handmade item, do expect the price tag to match it.
Please note: we are not on commission, we are not getting a cut of any sales price. 100% is going to the shoe maker.
You can put your
PEN-200/PWK Refresh
From an OffSec side of things, they have had a trick up their sleeve and launched the refreshed to a new format style of lab machines, but still keeping OSCP certificate.
For more information, please see about it, and session, we also did a in the release cycle to make this happen. Package maintainers are trying to make sure they have the latest version in, and as bug free as possible. Python is such a core part of an OS as so many scripts and packages rely on it, it is included in their first freeze. Python 3.11 has been “rushed” to make it into the upcoming stable release, as there are real improved performance. This then has a knock on-effect, as not everything may be compatible, either in Debian or Kali. After the updated Python was accepted, packages then get updated, pushed and tested against. There is a lot, and it does not happen all at once, but rather as each package then gets updated afterwards. As a result, bugs may trickle in as things change.
We also like to try and keep as close to Debian as possible, expect for where it makes sense to benefit us and our users. This means we can put more time into doing things that make Kali… Kali!
With technology, trends change. Live-CD were once “the in thing”, then persistent USB was “it”, which moved onto VMs, which gave way to containers, and currently “cloud” is in. Who knows what’s next!
In infosec, trends change as technology changes, software stacks change, attack surface changes, and defenses improve. As a result, we need to be able to adapt. At one stage, Wireless hacking “was the thing”, so we needed to support injection on as many cards as possible. Today, it is more “Command and Control”, “Cloud”, “Living off the Land”, and “Endpoint Detection and Response”.
We do not know what tomorrow will bring, but we need to be ready to react to it.
We have built up various internal technical debt, that we need to pay off. Luckily nothing is more than 10 years old!
An item which we are able to talk about, is switching out our mirror redirector to a newer solution. We have had this since the start of Kali, and whilst it does work, it is becoming more feature limiting and unable to integrate with newer stacks.
Refreshing our CI solution we are using for our image building is another item which is long overdue. This will help detect build issues with our images and platforms quicker.
Once we have reduced as much of the debt as we can, we will be in a much stronger position to be able to push forwards, and quicker than if we were to do any future items now. We are aiming then to ride on the development momentum, to build excitement up in the community.
Like Kali Purple, Kali is going defensive. This is a new area for Kali, currently we have only scratched the surface. We want to go deeper and break into more infosec areas as well!
We are looking for ideas and suggestions to please come and get involved with what you would like to see Kali Purple turn into.
Kali is an Open-Source project. Previously we have been doing things behind closed doors, but we have been doing more in the public eye. But we can do more. We want to do even more in the open as possible. We are wanting to feed and help community contributions grow.
…One thing that is certain however, we do not plan on changing the projects name. Kali is here to stay!
Screenshot Tour
They say “a picture is worth a thousand words”, so here is a trip down memory lane that’s worth £59,000:
- Whoppix 2.x (, , , , , , , , )
- BackTrack 3 (, , , , , )
- Kali 1.0.x ()
- Kali 1.1.x ()
- Kali 2.x (, , , , , , , , )
- Kali 2023.1 (, , )
Timelines
Over the years there has been some activity in different areas. Below we have pieced together some things which may be of interest to some of you.
Talks
Over the years, the team has given various different talks about the projects. They could be more of a deep dive of a certain platform or feature, but below are ones more of a higher level overview:
- 2013-07-17: @ Debconf 16
Trailer Videos
Over the years, we have done videos to show off the project. Here is a collection:
- 2011-05-05:
- 2015-07-01:
Hacked
We know everyone is a target, but also being apart of the industry we paint ourselves as a bigger target. From time-to-time we have made slip ups. Lucky, as far as we know, it never has been anything major, critical or user-facing:
2010-12-25: “Happy Ninja” low privileged shell by compromising another vHost on the same machine via an outdated vBulletin plug-in
- Their eZine: advisory
- Really, it was WICD privilege escalation, BackTrack was already running as root, and it was more of a PR stunt.
2013-05-01: OffSec launches Bug Bounty program, covering Kali Linux
2014-04-30: “The GreaT TeAm (TGT)"’s defacement of
lists.kali.org(via Heartbleed/CVE-2014-0160)
- Low traffic, rarely used 3rd party hosted public mailing list
2016-03-31: “Team Bad Dream” gained moderation privileges on
forums.kali.org(socially engineered), which lead to failed defacement onbugs.kali.org(suspect re-used credentials).
- Also suspect impersonating user on IRC (failed attempt at requesting additional access to new services)
- Limited only to community support portals
2021-12-08: “0x0 keeper” used CVE-2021-43798 Grafana directory traversal (via OffSec’s bug bounty program)
- Used for system monitoring and alerts
April Fools
We like a bit of fun, and have been known to pull pranks over the years:
- 2010-04-01:
- 2022-04-01: put out by a government agency that .
With how much it was being used, it was shortened to “Kali For Kids”. So we figured, - 2014-09-24:
- 2015-08-05:
- 2016-03-24:
- 2016-08-31:
- 2017-07-29:
- 2018-08-11:
- 2018-03-21:
- 2015-02-26:
↗ Original-Artikel auf kali.org lesenVollständiger Original-BerichtAusführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf kali.org.- Their eZine: advisory
SOCIAL SHARE CARD GENERATOR