I have to say, I wasn’t quite sure what to expect when I received a review copy, as there seems to be a glut of “Securing Web Apps” books out there, and from what I have seen, not that many great ones.  However, Zalewski is well-known within the security industry, so I had higher than normal expectations.

Zalewski starts out with his take on Information Security Management, and this small section probably deserves its own blog post entirely, but suffice to say that Zalewski is a pragmatist in this area–indeed, his 3 principles that he prescribes are:

1) Learning from (preferably other people’s) mistakes

2) Developing tools to detect and correct problems

3) Planning to have everything compromised.

Though I would agree with all three, the third principle resonates the strongest with me,  as this is one of Richard Bejitlich’s favorite things to say, and I have taken it to heart.

With the intro to Information Security out of the way, Zalewski takes the reader through a brief history of the web, and the evolution of the threat.  This was one of my favorite sections of the book, as it gave the much needed context to the issue of web security.

Being very young when the first browser wars started (1995ish), I have never understood why it mattered for web security…. Understanding the Wild Wild West-esqueness of those early days, and how each browser tried to one-up each other on web features, brings much clarity to why the security landscape of the web is so pockmarked with half-forgotten/half-thought out features that can be exploited for much gain.

Zalewski then moves from history to an anatomy of the web, picking apart the very structure of the web: URLs, HTTP, HTML, CSS, Scripting, etc…  This is great reference material for a theoretical and practical understanding of what makes up the web from a technical standpoint–Zalewski continually points out differences in how different browsers implement specific features.

The rest of the book delves into web and browser-specific security issues, starting with a great treatise on one of the foundational security principles of the Web, Same-Origin Policy.

I will most likely be writing a couple other blog posts on some of the specific security issues that are dealt with here.

The book finishes with some time dedicated to looking forward to future security mechanisms that are on the horizon, along with the pros and cons of them.

All in all, a fantastic book on the current state of affairs for web security, and one which I cannot help but classify as 5 stars.

A couple closing thoughts:

-The security engineering cheat sheets at the end of each chapter is a great way to keep it practical…. I am thinking about finding a way to pull all of the cheat sheets together for a small booklet to refer back to.

-This was the first epub book I have read on my iPad, and I throughly enjoyed it…. Thanks to No Starch for providing epubs and not just pdfs!

-Josh

1) There were a number of tools that had been discussed in the class… There were a number of questions on the exam about these tools–Not “In what situation would you use this tool?” questions, but “What syntax would you use to get this output?” type questions. Most of the syntactical answers were esoteric switches that were neither mentioned in class, nor in my study books, which was why it was very frustrating to find it on the exam. I flagged these questions for review by GIAC, as I don’t think that they were legitimate.

2) The other reason why this exam was more difficult, was that a number of the questions requried a bit of actual work & calculation, instead of just looking up the right answer–Though this made the exam much more difficult, I thought it was a great change from my previous GIAC exams, as it took it one step closer to real life experience, rather than just “multiple-guess.”

I will be working on my GCIA Gold next.

-Josh

I was hoping for something a bit more in-depth, but I would have to say that this book is directed to audiences that do not know much of the fundamentals of networking, much less Wireshark. With that in mind, I did breeze through the book: 
The first couple chapters are a primer on networking, and then installing Wireshark. The rest of the book goes through common protocols that you will find when sniffing, and then troubleshooting some real-world problems using Wireshark. (“Slow” network, security issues, etc) 

(Disclaimer: The publisher sent me a free copy of this book to review.)

-Josh

“Driven primarily by the end user, iOS devices continue to inundate businesses at an ever-increasing rate.  Because these devices are housing sensitive organizational data, it is imperative that it is understood what risks to the organization are involved in allowing users to utilize these devices for business.  Ascertaining what the risks are, and what the compensating controls would be, should be a critical component of any business risk assessment. The security features of the device itself, how applications are utilized on the device, and the actual usage of the device needs to be evaluated. Beyond the aforementioned areas, a major consideration that needs to be taken into account is whether the device is personally owned or business owned, as well as how it is managed, as these will be the primary factors by which controls are evaluated to manage the incurred risk.  Finally, users need to be made aware of the risks, and trained in what their responsibility is to reduce the risk to an acceptable level.”

Here is a link to the paper.

-Josh

—

Working for a client, in the last 6 months, I have rolled out Websense Web Security to 3 remote sites, all pointing to the Websense Policy Broker (think mothership) at the central location.  (Websense Web Security 7.5.1 on Server 2008 SP2 Hyper-V VM)

One of the interesting issues I ran into at the remote sites was that no matter what I did, the installs would error out if I pointed the install to connect back to the central location.

the following components have failed to install correctly;

package deployment failed; wbsn.policyserver

The error message seemed to indicate that it was a firewall or network communication error.  Unfortunately, tech support was not being very helpful, so I started doing some googling, and came across this interesting thread.

“it took a lot of time but this usually happens when the latency time is larger than 30 ms it’s what we noticed anyway… it’s not a lot but if you ping the remote site and the ping time is 30ms> there is a good chance you’ll get this error. everywhere we had 30ms>  we got this error.”

Come to find out, this was the issue, which is pretty bizzare, as 30ms latency is really not that bad….  All I had to do was following these instructions:

Install only the policy server, even when it fails it gets installed, so go look under services to see if you have policy server.

Once you have policy server installed you can install all the other components.

-Josh

Being the first time I have done something like this, I thought it was pretty good opportunity to get a feel for what it was like to review a pre-published technical book like this.  I was a little surprised at how much input I had, as I felt like my comments were well-received, and that I actually did have a hand in shaping parts of the book,

Well, the long and short of it, is that I enjoyed the experience, and I would recommend the pfSense 2 Cookbook to anyone looking for a practical guide to configuring pfSense 2.

-Josh

You would have thought this would have been a simple look-it-up-in-the-logs, but looking at the ISA logs was very frustrating, as I could never find the right variable to filter on to find out where the attempts were coming from.

Well, I eventually figured out how to do it, so I wrote up a quick procedure, for posterity:

From beginning to end:

1) Find which Domain Controller is being used to authenticate the credentials (look for event 539 or 4625), and look at the logs to see which ISA server the authentication attempts are coming from.

2) Filter the target ISA logs on the following parameter:

HTTP Status Code = 1909

This is the HTTP status code that is generated when an account cannot be logged on because it is locked out. (Attempting to logon to OWA for this specific case)

3) Cross-reference the time stamps on the previous ISA lockout logs to the DC’s logs to make sure you have the right lockout logs

4) After verifying, look at the ISA lockout logs for the source IP from where the authentication attempts are coming from.

5) Nuke IP from Orbit.

-Josh

I also host a number of WordPress blogs. All of them, as well as the installed plugins, are all up to date to the most recent release.

Over the last couple years of keeping Joomla! & WordPress installs updated, I have gotten to the point where I was about to stop hosting Joomla! installs, as I still have to manually upload & update both the core files & the extensions. WordPress has had this feature since December 2008! (Since version 2.7)

With the ever-increasing mass hacks made possible by vulnerable, out of date Joomla! plugins + absent ability to easily keep those plugins updated, I was about to toss in the towel for Joomla!, and declare it too much of a risk to run on my server, when I noticed that the recently released Joomla! 1.6 finally adds this much needed feature of automagically finding core & plugin updates & installing them–The catch of course is that the plugin developers have to setup their plugin to allow this.

So yes, there is hope for all you Joomla! fans out there, though the fact that it took them so long to add this feature is quite disconcerting to say the least…

-Josh

In the aftermath of this whole saga, Anonymous has made public ~72,000 emails from top HBGary leaders (Founder, CEO, etc), including Greg Hoglund, of rootkit.com & “Rootkits: Subverting the Windows Kernel” fame.

Using the emails as a source, Ars Technica did a great review of some of the more interesting emails, including a couple discussing “Juicy Fruit.”  From Ars Technica:

“HBGary kept a stockpile of 0-day exploits. A slide from one of the company’s internal presentations showed that the company had 0-day exploits for which no patch yet existed—but these 0-day exploits had not yet even been published. No one knew about them.

One of the unpublished Windows 2000 exploits, for instance, can deliver a “payload” of any size onto the target machine using a heap exploit. “The payload has virtually no restrictions” on what it can do, a document notes, because the exploit secures SYSTEM level access to the operating system, “the highest user-mode operating system defined level” available.”

Though this is all interesting, the pertinent detail I wanted to point out can be found in one of the emails, found here.  As you can see, one of the 0-days is ESX & ESXi.  The email is dated Dec 6, 2009, so just over a year ago.

Though we do not know what kind of access would have been able to gained, (“Even with unique access to the innermost workings of a security firm, much remains opaque; the real conversations took place face-to-face or on secure phone lines, not through e-mail, so the glimpses we have here are fragmentary at best. This care taken to avoid sending sensitive information via unencrypted e-mail stands in stark contrast with the careless approach to security that enabled the hacks in the first place.”), we can see from other emails that we are not talking about some kind of script kiddie-level exploit.

The salient point that I want to hammer home is thus:  HBGary is a small private sector security company that did some contracting work for the industrial defense space–If HBGary has access to these types of 0-days, it is not hard to imagine what state-sponsored attackers might have access to–Both homeland and overseas.

Are we ready?

-Josh

I was recently given a Knox-IT to try out.  After using both of them for a while now, I wanted to write down some thoughts I have on both of them.

Ironkey

When you think of secure encrypted flash drives, you think of Ironkey.  Ironkey is the current industry leader.  They are FIPS 140-2 Level 3 compliant, and are well known for pioneering the whole “after X failed password attempts the device will self-destruct.”

When I first received my Ironkey, the first thing I noticed about it was it’s overall design–The packaging (no photos sorry!) made it seem like I was unwrapping prized jewelry.  The smooth, finished feel to the flash drive itself, and the (surprisely) heavy weight gave me the impression that this was a quality product.

When you plug the Ironkey in the first time, a proprietary autorun application launches and runs you through a wizard that sets up the Ironkey.  Easy to use, no qualms here.  A nice touch is that I can specify contact information that will display on every autorun, in case the Ironkey is lost.

Normal use is pretty straightforward–Plug in the flash drive, type in your password in the autorun app, and you get access to your sensitive data.

I have kept it in my pocket for the last year, and the only wear and tear that I see is some nicks here and there.

Knox-IT / Lok-IT

(Knox-IT is the name of the previous version of the Lok-IT)

My first impression with the Knox-IT was quite the opposite of Ironkey.  The packaging was the cheap plastic that is really hard to open.  The grey lightweight (plastic) material that makes up the Knox-IT screams Chinese knockoff all over it.  Fortunately, it gets better from here.

The key differential between the Ironkey & Knox-IT is that Knox-IT uses 5 hardware buttons for your passcode, instead of a autorun app (software solution) from Ironkey. So you put in your passcode, the green light illuminates, and you plugin the flash drive and you use it like any other flash drive.  It will automatically lock/encrypt the flash drive when you disconnect it.

Using the included docs, it was a very simple process to setup the passcode.  Testing it out, I didn’t run into any issues unlocking and locking it back again.

According to their website, a FIPS 140-2 Level 3 compliant Lock-IT is slated to be released Q2 2011.

Conclusions

I really like the build quality of Ironkey better than Knox-IT, but I really like the concept of KnoxIT–Using hardware buttons to unlock the flash drive means that the Knox-IT is completely invulnerable to one of Ironkey’s primary weaknesses: Keystroke Logging.  Yes, Ironkey does have an on-screen keyboard that can be used to mitigate this threat, but it is clumsy to use, and do you really know anybody that is actually using the on-screen keyboard? I don’t.

The only other issue that I would point out about Knox-IT is that with only 5 hardware buttons, the attack space for guessing the passcode is quite small, but the mitigating control for that is that you only have 10 tries to unlock it before it self-destructs.  As a side note, the new version of Knox-IT (Lok-IT) now has a full complement of 10 hardware buttons–This fact plus the 10 tries & self destruct mechanism effectively disables a passcode guessing attack.

One final note that I have to mention.  As I was researching for this post, when I went to Knox-IT’s website, I got soft-blocked by my organization’s content filter, because the site was categorize as “Malicious.”  I thought that the content filter must have miscategorized the website, and so I continued anyway.

Here is the result.

LOK-IT.net Serving Up Malware

Pretty ironic, huh?

-Josh