Facebook changes to make

Facebook made changes, yet again, to the privacy and data restriction usage.  You might want to check your settings to see what's new, and what's being shared.

Here's a good link to helping "reset" some of the changes Facebook made to your account.

I suspect my older post here, is now outdated.  I think some of the main ideas may still be relevant, just implementing them will take more steps.

Web form incident

I received a call today for an interesting incident. Bear in mind that the customer doesn't have an incident response policy, but I think that is going to change.  It seems a staff member received an "anonymous" email that, while technically not threatening, was certainly personal, mean and inappropriate.

The staff member forwarded me the email, with all relevant headers.  Even though there was a "from" address on the email, I realized that email addresses can be spoofed.  However, digging through the headers, I found an "admin"@company.subdomain email address.  Thinking the website might have been tampered with, I perused the web sites directory.  The site only has 20 or so static pages with one contact form.  Thinking contact form, I contacted the webmaster to see how the sub-domain actually worked.  After some digging, I learned that there is one script on the sub-domain that processes the contact form.  Bingo.  Looking at the contact form, email address is not required.  So, I tested sending the form without entering an email address; and I was able to replicate the incident.

I am now working with them to fix two issues:  1) There needs to be a documented incident response policy, such that the client is protected.  2) The website needs to address how to handle submissions without an email address.

The security ball is rolling, so hopefully good things can come of the incident.

And, while we may be able to get the IP of the person that submitted the form, I'm not sure what that will buy us.

Book Review: Seven Deadliest Web Applications by Mke Shema

I have been doing more and more testing of applications, and most of those applications have been web applications.  I think it is the nature of the beast.  Sure, sites have servers to manage their client workspace, and they handle mail.  But, if they have a web server and/or database server there's a good chance that they are hosting a web application.  Whether the organization "knows" it or not.

Last year I worked on the big application project where we had to test north of 80 applications in a very short time period.  My eyes were really opened during that project.  Since then, more and more, the sites we are going to have web applications.  I've taken it upon myself to improve my application (and by extension, web application) testing.  While the DoD has the Application Security and Development Checklist to guide them, actually testing the controls is not the easiest.  So, I've been trying to delve deeper into App testing.

I picked some books to start going through, and some of them are listed on my reading list.  The first one I've gotten to is Seven Deadliest Web Application Attacks by Mike Shema.  One of the reasons I picked this book is because the book just came out, literally, last week.  So, the book is current.  Mike is not a stranger to security or web applications and has a couple of books on web application security.

I have to say that I really liked the book.  Mike's style is easy to read and he's able to convey the knowledge and the points in each chapter concisely and in a matter that facilitates remembering the facts and putting them to use.  There are seven chapters that Mike focuses on:  Cross-site Scripting (XSS), Cross-site Request Forgery, Structured Query Language (SQL) Injection, Server Misconfiguration and Predictable Pages, Breaking Authentication Schemes, Logic Attacks, and Web of Distrust.

Each chapter goes into detail about the specific attack.  There are many good examples, code snippets, and current stories about relevant attacks in the real world.  Many of the attacks have analogies to reinforce the concept using non-technical language to put the attack in a different frame of mind.  The big three (XSS, CSRF, and SQLi) make up the first three chapters.  I admit, I come from more of a DBA background (from before my security days) so I didn't focus on SQLi as much.  However, I still picked up knowledge from the SQLi chapter.  We test for XSS a lot, and I was familiar with the information; but of the big three, I learned the most from the CSRF chapter.  Server Misconfiguration delves into attacks that are based on applications and servers that are not as hardened as they should be.  Breaking authentication discusses different methods to subvert and get around authentication.  I liked the chapter on logic attacks because it employed the use of thinking outside the box.  These attacks were not the result of fundamental coding errors; they were errors in the way the application was designed.  Finally, the last chapter (Web of Distrust) compiled a bunch of different attacks.  Malware, scareware, referer attacks, html, and DNS all were given sections.

Each chapter starts out by defining the specific attack; what it is composed of, how it works, and how to employ it.  The chapter also devotes a section to employing countermeasures and how to mitigate the specific attacks.  Finally, a summary puts it all together.  I really liked the small sections titled "Epic Fail" where a specific attack is given a real-world example.  Also, there are many URLs given for tools that are discussed and for points for further information.  There are a couple of tools that I'm actively researching and looking to use that I learned about from the book.

The book is not a cookbook or a how-to on performing the attacks.  While lines of code are given as examples, there are not step-by-step instructions on how to successfully exploit the attack.  And that was fine for me; that wasn't my goal.  There are other books out there; in fact, there are whole books devoted to some of the chapters.  So, if you are looking for step-by-step instructions, this book is not for you.

I rate the book very highly and would recommend it to anyone wanting a good overview and jumping off point for the seven major web application attacks.  I've brought the book into my office and hope others will get as much out of it as I have.  You will not go wrong in reading the book if you want to learn what the major attacks are, how they work, and some mitigations to lessening the threat of these attacks.

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.

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.

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.
- William O. Douglas

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.

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.

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.

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.

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?