Monday, March 29, 2010
New Leatherman tools
I've always like the Skeletool CX by Leatherman, though I've never actually gotten one. I keep a pair of wire snips, four different screwdrivers, pliers, and tweezers in my laptop bag. Having a good set of tools comes in handy all the time. However, a post on Wired's Gadget Lab shows what appears to be even smaller versions of of the Skeletool. On the left is the Style CS, and the right the Style. Heck, I just noticed that they have a Freestyle CX, which is between the Skeletool and the Style.
image from the Wired post.
Saturday, March 27, 2010
Using Foremost to recover files from a dead hard drive
A client gave me a 250 gig hard drive that wouldn't boot any more. I was hoping it was a problem with Windows, such that I could image it and move on. However, when I tried imaging the drive, it would fail after 145 gigs of imaging. I tried this a couple of times and was able to repeat the fail at the 145 gig mark. Without a physical image, I wasn't able to pull out the logical partition. However, the client was asking what word documents I could pull off the machine.
So, with an image (as complete as I could make it) I decided to carve out what I could find. I edited the foremost.conf file to uncomment the "doc" file type. Following that, I ran foremost:
foremost -o /path/to/foremost/output -c /path/to/formost.conf /path/to/image
This bombed right away. I shouldn't say that it bombed, rather it brought back many files, and most of them were huge files, quite obviously not Word documents. Taking a look at the documentation, I decided to add the -q switch, which starts the search of files on sector boundaries. This produced more files, but all of them were gibberish...at least, I couldn't read anything meaningful from them. I took another look at the foremost.conf file and some postings on the internet and found that the ole type has automatic extration. And, I would not need the config file. My final command was:
foremost -q -t ole -o /path/to/foremost/output /path/to/image
This carved out plenty of Word files for me. I'm going to try carving jpgs in a few minutes. One spec I haven't found is Word 2007 files (docx) or excel files. If you have a config that can be used in a foremost.conf file for those formats, I'd appreciate it. Just leave a comment.
So, with an image (as complete as I could make it) I decided to carve out what I could find. I edited the foremost.conf file to uncomment the "doc" file type. Following that, I ran foremost:
foremost -o /path/to/foremost/output -c /path/to/formost.conf /path/to/image
This bombed right away. I shouldn't say that it bombed, rather it brought back many files, and most of them were huge files, quite obviously not Word documents. Taking a look at the documentation, I decided to add the -q switch, which starts the search of files on sector boundaries. This produced more files, but all of them were gibberish...at least, I couldn't read anything meaningful from them. I took another look at the foremost.conf file and some postings on the internet and found that the ole type has automatic extration. And, I would not need the config file. My final command was:
foremost -q -t ole -o /path/to/foremost/output /path/to/image
This carved out plenty of Word files for me. I'm going to try carving jpgs in a few minutes. One spec I haven't found is Word 2007 files (docx) or excel files. If you have a config that can be used in a foremost.conf file for those formats, I'd appreciate it. Just leave a comment.
Tuesday, March 23, 2010
Security quote
I flipped the page in my planner the other day, and at the top was the following quote:
Security can only be achieved through constant change, through discarding old ideas that have outlived their usefulness and adapting others to current facts.The quote is appropriate given what we do. User education is critically important. And, as threats evolve, we need to evolve with them; and pass that knowledge on. We've seen that viruses are not necessarily the major threat like they once were; when viruses wrecked havoc and were a nuisance. Now, there are concerted efforts by malware writers at hiding their intentions while attempting to get the user to give up valuable information. As the bad guys have adapted to make use of more advanced tactics, so have the warriors. The cat and mouse game will continue for as long as technology moves forward.
- William O. Douglas
Monday, March 15, 2010
Script to help find unknown or rogue sql servers
When I'm auditing a lan/enclave/data center, one of my test script producesa "netstat -naob" of the machine. (I do this by running "netstat -naob > [machinename]_netstat.txt. machinename gets populated from an environment variable.) Sure, I understand it is a point in time snapshot of the machine, but it gives me a good idea of what is running. And it's nice to have the output in a file in order to review later.
I like to check for sql servers because they traditionally get installed by a user as part of an application. Sure, many times it is the "lite" version of sql server. But that is not always the case. And, we all know how vulnerable a sql server could be; and their need for extra care and feeding.
Typically, I'll collect all of my netstat files in one directory. Then, I run following script:
for /R "c:\documents and settings\me\desktop\NetstatFiles" %f in (*_netstat.txt) do findstr /M "sqlservr.exe" "%f" >> sqlseeker.txt
Each of my netstat files is prefaced by the machine name of the machine being tested. sqlseeker.txt is a file that contains a list of all netstat files that contained a netstat line where a SQL server was found to be listening.
I'm sure there could be a false positive or two, but it gives me someplace else to look for rouge or unknown sql servers.
I like to check for sql servers because they traditionally get installed by a user as part of an application. Sure, many times it is the "lite" version of sql server. But that is not always the case. And, we all know how vulnerable a sql server could be; and their need for extra care and feeding.
Typically, I'll collect all of my netstat files in one directory. Then, I run following script:
for /R "c:\documents and settings\me\desktop\NetstatFiles" %f in (*_netstat.txt) do findstr /M "sqlservr.exe" "%f" >> sqlseeker.txt
Each of my netstat files is prefaced by the machine name of the machine being tested. sqlseeker.txt is a file that contains a list of all netstat files that contained a netstat line where a SQL server was found to be listening.
I'm sure there could be a false positive or two, but it gives me someplace else to look for rouge or unknown sql servers.
Sunday, March 14, 2010
Corrupted registry entries
I received a laptop the other day that was horked beyond belief. I was only able to run the anti-virus once before the machine died. And try as I might, I was unable to boot the machine back up. Using a linux live-CD, I was able to verify that the drive was physically good and in working order, no bad blocks or sectors. However, upon booting, the BIOS screen displayed, then nothing. Blackness. If I tried safe-mode, I could see a bunch of dlls loading, but the machine continually hung on on dll.
I went to a faithful standby, Trinity Rescue Kit. I ran all of the tools (that were appropriate,) and still nothing. Most of the errors seemed to be "illegal access" errors, or logic not supported.
Finally, I decided to use an old version of the registry. I followed the directions on this Microsoft page, and BINGO. I was able to reboot the machine. Fortunately, I copied the Documents and Settings folder of the user. So, I was able to put the files back.
Some software will probably have to be re-installed. And the machine is not the most stable. But it is a real old XP (Media Center) laptop, and could probably stand to be updated to Windows 7.
I went to a faithful standby, Trinity Rescue Kit. I ran all of the tools (that were appropriate,) and still nothing. Most of the errors seemed to be "illegal access" errors, or logic not supported.
Finally, I decided to use an old version of the registry. I followed the directions on this Microsoft page, and BINGO. I was able to reboot the machine. Fortunately, I copied the Documents and Settings folder of the user. So, I was able to put the files back.
Some software will probably have to be re-installed. And the machine is not the most stable. But it is a real old XP (Media Center) laptop, and could probably stand to be updated to Windows 7.
Saturday, March 13, 2010
Peach Fuzz training
This past week I received two days of Peach Fuzz training by the author Michael Eddington. This is a great fuzzing tool that is extremely powerful, yet extremely extensible and flexible. Michael did a great job in teaching the class; it probably helps that he's the author of the program. For those of you doing pen testing or research into application bugs, this program is for you. We used it in class to find (known) bugs in a few applications. But the possibilities are endless.
However, as an DoD auditor, I just don't see the use. I won't have time while on a client site to get this up and running as there is so much more for me to do on site. We are usually cramped for time with many different technologies and platforms to test. And really, contractually, I don't believe we are authorized to pen-test. We run web application scanners, but we can not exploit the vulnerabilities we find.
Awesome tool, though. And I'm glad I was given the opportunity to attend the class.
However, as an DoD auditor, I just don't see the use. I won't have time while on a client site to get this up and running as there is so much more for me to do on site. We are usually cramped for time with many different technologies and platforms to test. And really, contractually, I don't believe we are authorized to pen-test. We run web application scanners, but we can not exploit the vulnerabilities we find.
Awesome tool, though. And I'm glad I was given the opportunity to attend the class.
Thursday, March 4, 2010
Helping the crooks to your valuables
I was out west at my last testing engagement. We finished early, and I was able to visit with family and relax. We were taking a hike in a park when we unexpectedly reached a parking lot. The sign in the parking lot was so unbelievable I had to take a picture. I was using my Droid, so the picture didn't come out the best.
The sign said: "Notice! For our protection, secure your valuables in trunk." I think the "y" was removed. Either way....why don't you just leave the key?
The sign said: "Notice! For our protection, secure your valuables in trunk." I think the "y" was removed. Either way....why don't you just leave the key?
Subscribe to:
Posts (Atom)