Penetration testing for the masses with Kali – Part 2

Penetration testing for the masses with Kali – Part 2

Kali Linux – Pentesting for the masses?

My previous blog post looked at the changing face of the Backtrack / Kali rebirth and how the Offensive Security team, along with Rapid7, are looking at progressing into the Enterprise space. In this post I will be looking a bit closer at the Kali distribution itself and getting to the bottom of some of the changes and reasoning behind the move.

Progression to a more standardised approach

At its core, it’s a move to Debian Wheezy as a base and it’s intended to be a more standardised, stable and simpler way of doing what Backtrack did. The majority of packages are taken from the Debian repos (hosted in Kali repositories as an official derivative) and included is support for ARM Little Endian (EL) and ARM Hard Float (HF) architectures. [Time to buy another SD card for the pi then!] The intention is that the Kali development team will be able to submit feature improvements and bug fixes upstream for incorporation into the Debian repos subject to licence compliance, thus giving back to the Debian community at large – which is a notable commitment.

At a user level, probably the biggest noteworthy finding for users moving from the Ubuntu-based BT5 is that the ever present and dependable /pentest folder is gone! I’m pretty sure that this is the most noticeableimportant irritating change which existing Backtrack users will flag up when getting used to it. It is undoubtedly a big swing away from a single tool folder approach which, in my experience, a lot of pen testers will be used to. I am no different and, personally, have a tools directory on my base build where all my sources are stored. I tend to try and install tools to a bin folder in my homedir on Linux distros, and in Windows I like to keep all in a tools directory in or near the systemroot. In this case, the categorisation is gone and arbitrarily poking around the various folders looking for new tools was a regular pastime of mine. I am sure this will be a big talking point for existing Backtrack users who, by now, will be entrenched in the usual command line navigation to the pentest folder as a starting point when the system boots! I know I have found this a transition which I wasn’t expecting. There are ways to ease the pain, though.

There is good reason for this change, however. Applications now, by design, find their new home in /usr/share. The majority of tools are to be found here and, obviously, are uncategorised unlike the previous configuration. This move is good for a number of reasons:

  • It allows all binaries to be executed from any location on the system irrespective of your current session context as all binaries will be in your $PATH
  • There is no ambiguity about where a tool should live. Ever gone looking for a tool in the db folder, only to find it’s in the web directory? No more!
  • It adheres to the FHS standard. Annoying it may be if you are used to the original design; however, sticking to a standardised approach means that any Joe or Jane with the appropriate coding skills can (and will) write tools for inclusion in the distro which will behave as expected when introduced to the Kali repos and subsequently upstream to the Debian repos
  • All packages have been subject to a vetting process and signed by developers with GPG keys for package integrity.

As much as it will feel like pain at the moment, getting used to this standardised way of working will benefit the entire user and developer base in the long run. Finding tools can be a pain but as long as your short term memory isn’t completely shot, I’m sure we will all pick it up with some use.

Perhaps one annoying thing is that scripts that you found and used previously may be called something slightly different. By and large, script names are slightly different – is now plain old nikto, isapache-users. You get the gist. These are the only two I’ve noticed so far but there are more.

There are, of course, easy ways for you to find that tool you’re looking for. Using updatdb and then locate is lightning fast on my build. However, if you want to get the whole story about a package there is a simple means to do so using dpkg. This is how I went about finding out information about Nikto and its config file:

root@finkali:~# dpkg -l |grep nikto
ii nikto 1:2.1.4-2		all 		web server security scanner

Resulting packages which match your search are then returned and you can identify the one you are looking for; in this case, the package was in fact called nikto. Now, running dpkg –L <package> will list files installed to your system from the specified package name. The following edited output shows the conf file I was looking for:

root@finkali:~# dpkg -L nikto

So whilst some things have moved, the moving on is simple. The majority of config files you may have been hunting for are in the /etc/ folder somewhere. Two examples are the trusty John the Ripper conf [/etc/john/john.conf] and nikto as detailed above [/etc/nikto/config.txt]

One important note: the wordlist directory is in /usr/share/wordlists/ – in default state it has rockyou.txt.gz only – zipped and lonely.

It’s noticeably faster and its sleeker

I am unfortunately forced to run a Windows 7 base due to licensing and encryption requirements and slow moves from Symantec to support PGP on recent Linux distributions. I would love to run Kali as my native build, primarily because I could use the nVidia card on my Dell laptop for some password cracking joy […as long as it didn’t vaporise due to overheating…]. The upshot is, I have to run my Kali instance as a virtual machine. My only statement on this is… it feels much faster than its Ubuntu-based predecessor, and I have found that Debian, although sometimes a little less forgiving, is a lot less bloated and feels much slicker. I’m using VMware Player but it works just was well with Oracle VirtualBox.

One Ubuntu to Debian change, and, like a lot of my observations, not Kali specific, is running dhclient eth0 gives me less feedback than I’m used to! Add a -v to see what you’ve been used previously.

What’s missing…

  • It’s Firefox but not as we know it! Debian doesn’t include “pure” Firefox. Iceweasel is the alternative but it doesn’t include the non-free bits [support for plugins], so if you want the full Firefox, you will need to remove Iceweasel and install Firefox from the repos or from source
  • Arimtage – the Metasploit GUI is not installed but now available in the repos. Some people are reporting problems with the install but it worked for me without issues using apt
  • It doesn’t have gedit! It’s available in the repos though
  • It doesn’t have tsclient – no longer maintained or supported for wheezy. Back to rdesktop.

What’s new…. well, not entirely sure yet – apart from the obvious.

There are new packages being ported to the Kali distribution all the time and the Kali development team are working hard to port new tools to the repos constantly. So, not all of the available tools are going to be installed in your manila build or downloaded VM image. To get them, some but not all of the new packages are added to the kali-linux and kali-linux-full meta-packages as they are committed. Therefore, an apt-get update && apt-get upgrade will install any new packages which your distro doesn’t have as they are added to the meta-packages. However, this isn’t always the approach and if you want to keep abreast with all of the latest additions, add the Kali git address to your bookmarks:

The following bits are new and noteworthy:

  • The Metasploit Framework has been integrated into the repos. This has been a major change and makes life generally easier when managing your Metasploit instance. Less pain!
  • The popular and ever useful iKat suite of tools has been integrated and is part of the build. Great addition to the distro and should update nicely via apt when changes are made. A new Professional version of iKat is soon to be available – see info here:

In conclusion

It’s an excellent move in the right direction and offers everything that a pen test build should. Downloading and using this distribution means that a user gets a pre-configured and security-honed ready-to-roll build. With a custom kernel for improved native wireless support and pre-tested tools which will do exactly what it says on the tin, it offers something back to the Debian development community at large whilst being sleek and stable. It’s a positive and progressive development [until I find some stuff which is different from what I’m expecting].

Part 1 of the Kali review post can be found here.

KALI LINUX™ is a trademark of Offensive Security


Related Content

PRCON 2011

PRCON 2011

Whilst we are ardent supporters of maintaining a healthy balance between work and life and well awar...

Welcome to the Perspective Risk Blog

Welcome to the Perspective Risk Blog

The Perspective Risk blog has been created to provide information security resources to the penetrat...