Shell – Prevent a script exhausing system resources and crashing entire system

• Virtual machine can give you highest security without reboot, but lowest performance.

• Another option, for even higher security than a virtual machine: boot a "live" CD/DVD/pendrive without access to the hard drive (temporarily disable the HDD in BIOS; if you can't, at least do not mount the drive / unmount it, if mounted automatically - but this is much less secure)

• A docker container is a bit less secure alternative to a full virtual machine. Probably the crucial difference (in terms of security) between these two is that systems running in docker actually use the kernel of your host system.

• There are programs such as isolate that will create a special, secured environment - this is generally called a sandbox - those are typically chroot-based, with additional supervision - find one that fits you.

• A simple chroot will be least secure (esp. in regards to executing programs), though maybe a little faster, but... You'll need to build/copy a whole separate root tree and use bind mounts for /dev etc. (see Note 1 below!). So in general, this approach cannot be recommended, especially if you can use a more secure, and often easier to set up, sandbox environment.

Note 0: To the aspect of a "special user", like the nobody account: This gives hardly any security, much less than even a simple chroot. A nobody user can still access files and programs that have read and execute permissions set for other. You can test it with su -s /bin/sh -c 'some command' nobody. And if you have any configuration/history/cache file accessible to anybody (by a mistake or minor security hole), a program running with nobody's permissions can access it, grep for confidential data (like "pass=" etc.) and in many ways send it over the net or whatever.

Note 1: As Gilles pointed in a comment below, a simple chroot environment will give very little security against exploits aiming at privilege escalation. A sole chroot makes sense security-wise, only if the environment is minimal, consisting of security-confirmed programs only (but there still remains the risk of exploiting potential kernel-level vulnerabilities), and all the untrusted programs running in the chroot are running as a user who does not run any process outside the chroot. What chroot does prevent against (with the restrictions mentioned here), is direct system penetration without privilege escalation. However, as Gilles noted in another comment, even that level of security might get circumvented, allowing a program to break out of the chroot.

Improvement #1 - Loops

Your looping structure seems completely unnecessary if you use brace expansions instead, it can be condensed like so:

$ more pass.bash 
#!/bin/bash

for str in $(echo {a..z}{a..z}{a..z}); do
  pass=$(openssl passwd -salt $1 $str)
  if [[ "$pass" == "$2" ]]; then
    echo "Password: $str"
    exit;
  fi
done

# vim: set nolist ts=2 :

I'm showing 4 characters just to make it run faster, simply add additional {a..z} braces for additional characters for password length.

Example runs

4 characters

$ openssl passwd -salt ab hhhh
abBYJnOuV8dUA

$ time ./pass.bash ab abBYJnOuV8dUA
Password: hhhh

real    18m3.304s
user    6m58.204s
sys     9m34.468s

So it completed in 18 minutes.

5 characters

$ openssl passwd -salt ab ccccc
abZwsITAI6uwM

$ time ./pass.bash ab abZwsITAI6uwM
Password: ccccc

real    426m37.234s
user    16m34.444s
sys     398m20.399s

This took ~426 minutes. I actually Ctrl+C this, so it hadn't finished, but I didn't want to wait any more than this!

NOTE: Both these runs were on this CPU:

brand = "Intel(R) Core(TM) i5 CPU       M 560  @ 2.67GHz

Improvement #2 - Using nice?

The next logical step would be to nice the above runs so that they can consume more resources.

 $ nice -n -20 ./pass.bash ab hhhhh

But this will only get you so far. One of the "flaws" in your approach is the calling of openssl repeatedly. With {a..z}^5 you're calling openssl 26^5 = 11881376 times.

One major improvement would be to generate the patterns of {a..z}.... and save them to a file, and then pass this as a single item to openssl one time. Thankfully openssl has 2 key features that we can exploit to get what we want.

Improvement #3 - our call structure to openssl

The command line tool openssl provides the switches -stdin and -table which we can make use of here to have a single invoke of openssl irregardless of how many passwords we want to pass to it. This is single modification will remove all the overhead of having to invoke openssl, do work, and then exit it, instead we keep a single instance of it open indefinitely, feeding it as many passwords as we want.

The -table switch is also crucial since it tells openssl to include the original password along side the ciphers version, so we can make fairly quick work of looking for our match.

Here's an example using just 3 characters to show what we're changing:

$ openssl passwd -salt ab abc
abFZSxKKdq5s6

$ printf "%s\n" {a..z}{a..z}{a..z} | \
    openssl passwd -stdin -table -crypt -salt ab | grep -m1 abFZSxKKdq5s6
abc abFZSxKKdq5s6

So now we can really revamp our original pass.bash script like so:

$ cat pass2.bash 
#!/bin/bash

pass=$(printf "%s\n" {a..z}{a..z}{a..z}{a..z}{a..z} | \
  openssl passwd -stdin -table -crypt -salt $1 | grep -m1 $2)

if [[ "$pass" =~ "$2" ]]; then
  echo "Password: $pass"
fi

# vim: set nolist ts=2 :

Now when we run it:

$ time ./pass2.bash ab aboznNh9QV/Q2
Password: hhhhh aboznNh9QV/Q2

real    1m11.194s
user    1m13.515s
sys     0m7.786s

This is a massive improvement! This same search that was taking more than 426 minutes is now done in ~1 minute! If we search through to say "nnnnn" that's roughly in the middle of the {a..z}^5 character set space. {a..n} is 14 characters, and we're taking 5 of them.

$ echo "14^5" | bc 
537824

$ openssl passwd -salt ab nnnnn
abRRCp5N3WN32

$ time ./pass2.bash ab abRRCp5N3WN32
Password: nnnnn abRRCp5N3WN32

real    1m10.865s
user    1m12.842s
sys     0m8.530s

This search took ~1.1 minutes. NOTE: We can search the entire space of 5 character passwords in ~1 minute too.

$ time ./pass2.bash ab abBQdT5EcUvYA
Password: zzzzz abBQdT5EcUvYA

real    1m10.783s
user    1m13.556s
sys     0m8.251s

Conclusions

So with a restructuring we're running much faster. This approach scales much better too as we add a 6th, 7th, etc. character to the overall length of the password.

Be warned though that we're using a smallish character set, mainly only the lowercase alphabet characters. If you mix in all the number, both cases, and special characters you can typically get ~96 characters per position. This may not seem like a big deal but this increase your pool tremendously:

$ echo 26^5 | bc
11881376
$ echo 96^5 | bc
8153726976

Adding all those characters just increased by 2 orders of magnitude our search space. If we go up to roughly 10-12 characters of length to the password, it really puts a brute force hacking methodology out of reach.

Using proper a salt as well as additional NONCE's throughout the construction of a hashed password can add still more stumbling blocks.

What else?

You've mentioned using John (John the Ripper) or other cracking tools. Probably the state of the art currently would be HashCat.

Where John is a tighter version of the approach you're attempting to use, HashCat takes it to another level by enlisting the use of GPUs (up to 128) to really make your hacking attempts fly.

You can even make use of CloudCrack, which is a hosted version, and for a mere $17 US you can pay to have a password crack attempted.

References

• Real World Uses For OpenSSL