Just a quick little password generator, since I’ve had a couple people ask. It will generate 12 character passwords using a-z, A-Z. 0-9 and various symbols such as _ and -
tr -dc a-zA-Z0-9_- < /dev/urandom | head -c 12 | xargs
Thats it, short and simple but effective.
Hack.me is a free community project where people can build, share & host vulnerable web apps to learn and experiment. Each app is sandboxed for you so you are somewhat safe (as safe as you can be on a site with people uploading strange things for security people to break anyway). You can also upload private images for self use. It looks liek a handy tool for anyone interested in learning more about security and penetration testing.
This is a quick tip on getting backtrack 5 to automatically login as root and startx which will run the graphical interface. There is a disclaimer though as this method does work but isn’t exactly secure. Then again, if you are using Backtrack, you probably know that already :)
First step is to install rungetty
aptitude install rungetty
Next we have to edit /etc/init/tty1.conf
use the arrow keys to move down to the last line and add a “#” before the line “exec /sbin/getty -8 38400 tty1” so it looks like so
#exec /sbin/getty -8 38400 tty1
Once that is done, add the following line which will automatically login as root
exec /sbin/rungetty tty1 --autologin root
Press CTRL+X an enter to save and close nano
Next, you need to set the .bash_profile for the root user to automatically run startx which starts your graphical interface
Add the following to this file
CTRL+X to save and close
Reboot your BT5 install and there you go. Obviously, going back to the above warning, this isn’t recommended for any machines that could fall into the wrong hands or if you store data on your BT5 install. Personally, I have a proxmox cluster that runs BT5 and this makes it easier to get to the console without logging in constantly, I have just have to start the VM and then vnc to the console.
A somewhat scary bit of research has been done by Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson. They found that the current methods for clearing
hard drives of their data (ie: removing of sensitive material or just clearing it for selling or handing down to someone else for example) doesn’t work for SSD (solid state drives), which are very commonly found as USB Thumb drives and more commonly shipping or being put into new systems in place of standard hard drives.
While sanitizing entire disks and individual files is well-understood for hard drives, flash-based solid state disks have a very different internal architecture, so it is unclear whether hard drive techniques will work for SSDs as well.
We empirically evaluate the effectiveness of hard drive-oriented techniques and of the SSDs’ built-in sanitization commands by extracting raw data from the SSD’s flash chips after applying these techniques and commands. Our results lead to three conclusions: First, built-in commands are effective, but manufacturers sometimes implement them incorrectly. Second, overwriting the entire visible address space of an SSD twice is usually, but not always, sufficient to sanitize the drive. Third, none of the existing hard drive-oriented techniques for individual file sanitization are effective on SSDs.
This third conclusion leads us to develop flash translation layer extensions that exploit the details of flash memory’s behavior to efficiently support file sanitization. Overall, we find that reliable SSD sanitization requires built-in, verifiable sanitize operations.
More information can be found as a Video,
PDF or also a summary article at TheRegister