IT Dribble

I have finished setting up a new tool for in browser AES256 encryption via the javaScrypt library. Included within the page is a tool to produce SHA1 / SHA224 / SHA256 / SHA384 / SHA512 hashes.

The idea was that I has a central place to encrypt and decrypt data any time, any place with no reliance on anything except a web browser. I wanted to use java script so that both mine and your data doesn’t leave the browser and stays confidential.
(Perhaps David Petraeus could have used something like this, the trail might have been even harder to follow had he left the ‘draft’ message encrypted)

I implemented the SHA hashing as a tool to strengthen poor passphrases. The idea being that you use your lame password as input, create the hash and encrypt your data with the 128 character key (SHA512). When you need to decode your data you just do the reverse. Now some valid points to think about are:

• If you were being targeted and an attacker knew that your password was a SHAx hash then, you would be susceptible to bruteforce attacks against the hash.
• Using a hash (lower case letters and numbers) will provide less entropy against a fully random password of equal length.
• I believe (my opinion) that if you can afford to trade the security of someone knowing your password is a hash vs a shorter more complicated password your better off hashing your actual password with SHA512 (128 characters a-z 0-9)
• Of course your better off with 128 character fully random key but how are you suppose to remember that?

Check it out here: http://www.cammckenzie.com/encrypt/

ssh into your vdi-in-a-box server as user kvm

# Make our temp working area

mkdir keystore
cd keystore

# Run the following command which will create a new keystore, new keypair, a self signed cert that will last 10 years.
# Change HOSTNAME to your public DNS name. eg, remote.acme.com

keytool --genkey --dname "CN=HOSTNAME, OU=VDI-in-a-Box, O=YOUR-BUSINESS,  
 L=YOUR-CITY, ST=YOUR-STATE, C=US" --alias HOSTNAME --keyalg RSA --keysize 2048 --validity 3650 
--keystore kmgr.keystore

# cd into /home/kvm/kvm/install/servlet_container/conf

cd /home/kvm/kvm/install/servlet_container/conf

# Backup the old keystore

mv .keystore .Original-keystore

# Backup the server.xml file

cp server.xml server.Original.xml

# edit the server.xml file
# Find the clientAuth line by searching/typing:
# /clientAuth=
# Verify the keystorePass=”password” entry does not already exist in entire Define a SSL HTTP/1.1 Connector on port 8443 section. Add the following line, # replacing “password” with your keystore password:

EG.

    <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
               ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, 
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
               keystoreFile="conf/.keystore"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"/>

Would look like:

    <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
               ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
               keystoreFile="conf/.keystore"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" URIEncoding="UTF-8"
                keystorePass="YOUR-KEYSTORE-PASSWORD"/>

# restart Tomcat

tc_start

Check your new self signed cert is shown in the browser!

Tool functionalities:

Once this tool is launched, it will join the IGMP group and listen on UDP 5355 port multicast.
This tool will also listen on TCP port 139, 445, 1433, 80 and UDP port 137, if you have any service running on these ports, you will need to stop them prior launching this tool.
The tool will write captured hashes to a file in the current folder for each poisoned host with the following syntax: [SMB/HTTP/SQL]-[NTLMv1/v2]-Client-IP.txt in a John Jumbo format.The SMB server supports Windows ranging from NT4 to Windows Server 2012 RC, Samba, Mac OsX Lion.

http://blog.spiderlabs.com/2012/10/introducing-responder-10.html

Apart from this package being rather old, it still works.
You need to install libxml2-devel dbus-devel and pmount

 yum install libxml2-devel dbus-devel pmount 

After the make and make install
Run:

pamusb-conf --add-device MyDevice 

Where you might receive the error:

 Unable to read /etc/pamusb.conf: not well-formed (invalid token): line 43, column 52 

The easiest fix is to delete the whole following example section from /etc/pamusb.conf

                <!-- Example:
                        Authenticate user scox using "MyDevice", and configure pamusb-agent
                        to automatically start/stop gnome-screensaver on key insertion and
                        removal:
                        <user id="scox">
                                <device>MyDevice</device>
                                <option name="quiet">true</option>
                                <agent event="lock">gnome-screensaver-command --lock</agent>
                                <agent event="unlock">gnome-screensaver-command --deactivate</agent>
                        </user>

                        Configure user root to authenticate using MyDevice, but update one
                        time pads at every login (default is 1 hour):
                        <user id="root">
                                <device>MyDevice</device>
                                <option name="pad_expiration">0</option>
                        </user>
                -->

That’s a good boy / girl delete the whole section as above.
Excellent after the rest of your progress you may notice on 64bit builds that it doesn’t work that’s because the build doesn’t care for 64 bit installs so move the pam module into the correct directory:

 mv /lib/security/pam_usb.so /lib64/security/pam_usb.so 

Follow the rest of the instructions and you should be good to go!

JtR now natively supports multi-threading through the OpenMPI interface. All the code is right there in the jumbo version of JtR all you need to do is install OpenMPI and un comment the lines of code in the makefile. Now you can crack SHA512crypt passwords with all cores.

Alright lets get started:

yum install openmpi
wget http://www.openwall.com/john/g/john-1.7.9-jumbo-6.tar.gz
tar -zxvf john-1.7.9-jumbo-6.tar.gz
cd john-1.7.9-jumbo-6/src

Now we need to edit Makefile and uncomment the ‘OpenMP’ lines.

vi Makefile

and uncomment the following line as per below:

OMPFLAGS =
# gcc with OpenMP
#OMPFLAGS = -fopenmp
OMPFLAGS = -fopenmp -msse2
# Sun Studio with OpenMP (set the OMP_NUM_THREADS env var at runtime)
#OMPFLAGS = -xopenmp
# icc with OpenMP (for make target linux-x86-64-icc)
#ICCOMPFLAGS = -openmp

now compile and run as per normal noticing that you now have 100% cpu usage!