Password cracking GUI
Motivation
Equipped with lists of password hashes from previous steps in the penetration testing process, testers face the challenge of finding a minimum of one password. In cases where many penetration testers share one resource (e.g. one workstation with high performance GPUs), job scheduling becomes a challenge when using the command line tool hashcat. There are different hashcat-based open source tools that provide job scheduling as well as a graphical user interfaces to monitor the jobs states. A list of these tools include
- CrackLord
- WebHashcat
- WaveCrack
- Hashtopolis
Besides checking if there are more open source password-cracking tools with job scheduling, the named tools should be benchmarked using one or two Nvidia GTX 980 graphic cards. An evaluation of the provided functions should help choosing a tool for real world cases.
Setting up a test system
All tools should be benchmarked using the same operating system. Some of the tested tools could be tested on multiple systems. A first research found out, that the tools require these operating systems.
| CrackLord | WebHashCat | WaveCrack | Hashtopolis | |
|---|---|---|---|---|
| Operating system |
|
|
|
|
The test system is setup with Kali with the hope that all tools will work with this OS.
Main setup problems (Hardware)
- With GTX 980 boot menu can not be displayed
- With HDMI boot menu can not be displayed
- Keyboard needs to be plugged into USB 3.0 port to display boot menu but within boot menu, only USB 2.0 works
- 4 GB USB Stick is not sufficient for a installation (size: 3.1 GB)
Main setup problems (Software)
Sources, to download packages from, were missing. Everything in sources.list was commented out. This is how the file should look like (I added the lines with no #).
deb http://http.kali.org/kali kali-rolling main contrib non-free
deb-src http://http.kali.org/kali kali-rolling main non-free contrib
# deb cdrom:[Debian GNU/Linux 2019.3 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 20190>
#deb cdrom:[Debian GNU/Linux 2019.3 _Kali-rolling_ - Official Snapshot amd64 LIVE/INSTALL Binary 201908>
# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.
GPU drivers were missing. When trying to start hashcat, it resulted in an error.
hashcat -I
* Device #1: Not a native Intel OpenCL runtime. Expect massive speed loss.
You can use --force to override, but do not report related errors.
No devices found/left.The error popped up, because the drivers were missing. The following line could have solved the problem of the missing drivers easily if Kali could have got all needed dependencies.
sudo apt install -y ocl-icd-libopencl1 nvidia-driver nvidia-cuda-toolkit
Some packages could be installed manually with no further effort by just typing
apt-get install <packagename>
Unfortunately, nvidia-cuda-toolkit needed the package nvidia-dev which needed libcublas10 in another version. libcublas10.2 was installed but v 10.1 was needed. To install a package in a specific version, first uninstall the current version and then specify your version with the syntax <packagename>=<versionname>
apt-get remove libcublas10
apt-get install libcublas10=10.1.105-3+b1
When hashcat was finally ready to do it's job, it looked like this
hashcat -I
root@alice:~# hashcat -I
hashcat (v5.1.0) starting...
OpenCL Info:
Platform ID #1
Vendor : NVIDIA Corporation
Name : NVIDIA CUDA
Version : OpenCL 1.2 CUDA 10.1.120
Device ID #1
Type : GPU
Vendor ID : 32
Vendor : NVIDIA Corporation
Name : GeForce GTX 980
Version : OpenCL 1.2 CUDA
Processor(s) : 16
Clock : 1240
Memory : 1010/4043 MB allocatable
OpenCL Version : OpenCL C 1.2
Driver Version : 430.50
Platform ID #2
Vendor : The pocl project
Name : Portable Computing Language
Version : OpenCL 1.2 pocl 1.3 None+Asserts, LLVM 7.0.1, SLEEF, DISTRO, POCL_DEBUG
Device ID #2
Type : CPU
Vendor ID : 128
Vendor : GenuineIntel
Name : pthread-Intel(R) Xeon(R) CPU E5-1650 0 @ 3.20GHz
Version : OpenCL 1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-sandybridge
Processor(s) : 12
Clock : 3800
Memory : 16384/62385 MB allocatable
OpenCL Version : OpenCL C 1.2 pocl
Driver Version : 1.3
Installing the tools
The order of the tools to install did not follow any rule as it was planned to install all tools.
Cracklord
Cracklord is using two subsystems. There is one "client" (named queued) with which the user interacts and one "server" (named resourced) which manages the resources (the CPUs and GPUs). Both need to run at the same time, either on different hosts or on the same.
https://sarwiki.informatik.hu-berlin.de/File:Kali_is_not_supported.png The project owner says: "For now only Ubuntu is supported and unless someone has some expertise in package building it will likely stay that way. I will continue to try and update the build documentation so people can build it from source on various Linux/Unix/Windows systems." (Nov 6, 2016)
Download the queued and the resourced file from here https://packagecloud.io/emperorcow/cracklord
Install both deb files that you downloaded with dpkg:
dpkg -i Downloads/cracklord-queued_1.0-beta-98-ge2bd792_amd64.deb
dpkg -i Downloads/cracklord-resourced_1.0-beta-98-ge2bd792_amd64.deb
As both files won't work out of the box, in the next step, we change some files.
apt-get install mc
Midnight-Commander will help you browse and adapt the files within the .deb files
Finally, the queue instance as well as the resource instance are able to start. Though the GUI says, jobs run and finish with done, hashcat is actually not cracking passwords. This is how to make it work and why it is not functioning:
Cracklord is basically calling Hashcat with the parameters, the user provides in the GUI. It is starting hashcat as the user "Cracklord" which normally has no home directory. A quick hack for this is to provide Cracklord a home directory
mkdir /home/cracklord
chown -r cracklord:cracklord
At first glance, enabled potfiles prevented hashcat from working correctly but this idea went out to be wrong. There is no need to adapt the default settings about potfiles. (A potfile is an hashcat specific file where it saves its progress.)
Other difficulties rose with these configuration settings:
- the location of hashcat...
WebHashcat
Installing WebHashcat worked well using this guide https://github.com/hegusung/WebHashcat. While installing, some dependencies must be added manually. For some of them, apt did not work but pip3 did. The default certificates did not work. We supposed the problem could be, that there was no alias set. With a config file and two lines of bash code, we were able to define aliases for all possible names.
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = DE
ST = B
L = Berlin
O = HUB
OU = Itsec
CN = localhost
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = alice
DNS.3 = 127.0.0.127
DNS.4 = 0.0.0.0
#cmds:
#generate:
#openssl req -x509 -nodes -days 365 -newkey rsa:4096 -keyout server.key -out server.crt -config localhost.conf -extensions 'v3_req'
#view:
#openssl x509 -in server.crt -noout -text
Using the tools
[only for the specific setup on the used machine]
Cracklord
Starting the queued system:
usr/bin/cracklord-queued --conf=/etc/cracklord/queued.conf
The queued server runs on port 443 and can be accessed using a secure connection. Firefox ESR displays https://localhost:443 well, other browsers were not tested.
Starting the resourced system:
./start_cracklord-resourced.sh
The resourced system runs on port 9443 and is not meant to be accessed via any browser.
Login Accessing the queued server on port 443, login is possible with the credentials from CONTENTS/queued.conf Admins credentials are: username admin, password changeme
Performance
Cracklord was configured to use hashcat as the underlying tool so the performance hardly depends on hashcats efficiency. The queue is updated every 30s by default, so jobs may wait 15s in average unregistered. Working with huge lists, this time can be ignored.