Just a quick post on passwords saved in the browser. After my post on credentials stored in the Windows 7 Vault, I started to think about browser passwords and the risks that lurk there. Chris Gates had a similar thought which he posted about yesterday, and Larry Pesce wrote up a detailed analysis last September.

I personally disable this feature in Firefox but a strong master password would certainly be advisable if you do save passwords within Firefox. While I do not use this feature, I do use a lot of Firefox add-on's. Gmail Notifier, Xmarks Bookmarks, and Echofon Twitter add-on's to name a few. So I naturally turned my attention to those.

I pondered where these add-on's were storing saved credentials. The answer is in same place Firefox stores them. What a more ironic way to verify this than to use a Firefox add-on (SQLLite Manager) to query the signons.sqlite database.


As previously covered by Gates and Pesce, conversion of the encrypted passwords is trivial as long as you also have access to the key3.db and there is no master password configured. If you are interested in the details of this, I suggest checking out the documentation here and tool available here.

While this may have been obvious to others, it was not to me. That is one of the many reasons I love this field.


Update August 09, 2010: Jeremiah Grossman presented his work entitled Breaking Browsers: Hacking Auto-Complete at Black Hat last week. The presentation included examples of using XSS to steal saved credentials in the Firefox and Chrome password managers.

A while back, I was intrigued by the then-impending release of Gregory Evans’ book, How To Become the World’s No. 1 Hacker. I realized that, even as a self-published book, it would get a lot of attention from people getting started in security, if for no other reason than it’s “extreme” (and promising!) title. I put in a request for a review copy so that I could give some sort of recommendation one way or the other to students taking security classes here, and others that might stumble across this blog.

The review copy arrived, and I immediately got the same feeling as I got when I took a careful look at the original revision of Dissecting the Hack: that the listed authors of the book did not create the content they were presenting as their own. Googling random samples of the text throughout the book confirmed my suspicions. I switched gears and began documenting all the instances of plagiarism, much as I did for Dissecting.

A few chapters in, I was rescued from this drudgery (and no small amount of drama) by Ben Rothke, who wrote a short series of excellent posts exposing the plagiarism in Gregory’s book. He did a great job of documenting it, and hopefully it will inform potential purchasers/readers.

Ben has now done it again with a review of Ali Jahangiri’s The Security Policy Cookbook: A Guide for IT and Security Professionals.  His post is titled Is 2010 the year of the plagiarized security book?, and Ben not only exposes the large amount of unattributed material in this book, but also explains the problems with copy-and-paste security policy design.

With three books in the past year having a significant amount of plagiarism, I figured this would be a good time to share a little bit of my own commentary on the situation. This is a collection of thoughts, observations, and opinions that I’ve expressed in other formats (Twitter, email, in person) with various members of the security community, gathered up into this one post.

What is plagiarism?

Plagiarism is the act of representing another’s work as your own, without attribution to the original source. This sounds very simple, but once one accuses the other of it, the excuses and arguments get twisted very quickly. The litmus test should be: would a reader be reasonable in assuming that the listed author wrote this material? The only place where this gets sticky is in the case of legitimate (and more importantly, willing) ghost writers, which is not really an issue in any of these security books (though it was claimed for one).

Plagiarism is, on the surface, related to legal issues of copyright, intellectual property, and fair use. It is, however, a different issue. One may be within the boundaries of the law in the case of public domain and other very-loosely-licensed material, and yet still be deceptive and dishonest towards the readers who shell out money and time on a book.

This is not a matter of “standing on the shoulders of giants”, basing your work off of others’ and expanding upon it with your own commentary and research. This is about the wholesale copying, pasting, and laying claim to others’ work.

Why is this a problem?

I touched on this a bit in the previous question. The victims of plagiarism are the readers, who are being deceived by the plagiarists, and the original content creators, who get no credit for their original work.

Readers purchase books with the intention of getting the author’s take, or presentation, of a subject.  A reader might decide that it’s okay to buy a book that contains material from another book (legit example: No Tech Hacking), or that contains material that’s freely available online.   If your book presents its material as being created by the listed author, but it wasn’t, then you’ve robbed the reader of being able to make that decision.

The purpose of a book is not only to provide information and/or entertainment to the reader, but also to serve as a testament to the author’s expertise, ability to communicate, and respect in their chosen field. Even those who don’t read the books will be able to verify that an individual is at least well-versed enough on a subject to have written a book on it. This helps a lot with self-promotion and recognition. It’s easy to see that book authors are held in high esteem in the security community. A plagiarist cheats their way into this position by assuming the title of “author” without putting in the effort normally needed to create the content. At the same time, the original author of the content is not seeing this esteem or status that would normally be associated with having their work in print.

Is this a serious problem with security books?

Good question. The three examples discussed above are the only ones that I am aware of. They’re huge, egregious examples, but it’s possible that smaller instances exist and haven’t been noticed. Has anyone else noticed more?

The motive is there. Name recognition is very important/sought-after in the security community. It’s tempting to take the shortcut.

Opportunity? Two out of the three above examples are self-published, in which case: who’s going to stop them from trying. Dissecting was from an actual publisher, Syngress, though it revealed a failure in the editing process that is unlikely to happen again, now that they have been burned once.

After the community’s negative reaction to Gregory Evans’ book, it would seem that most would think twice about pulling the same stunt. Then again, many that would are likely new to security or not connected to the community of twitterers, bloggers, conference attendees, etc. While Evans was on some folk’s radar prior to these events, he wasn’t as widely known before as he is now. It may be the case that some people underestimate the ability of the community to identify and react to misrepresentation. As with Evans, this appears to be the case with Ali Jahangiri.

Who is Responsible?

In at least two of the prior cases of plagiarism in security books, blame was passed along to other people responsible for the content.  Regardless of who committed the act, those who have their name on the book and see/approve it before it goes to print or the shelves are ultimately the ones who are responsible for the content.  The editors and publishers (if there are any) are also responsible.

Conclusion

As a reader, keep a critical and skeptical eye when reading a book if it seems suspicious. Investigate and document what you find. Expose what you feel is not right. If you want to avoid getting duped, try to find reviews from sources you trust before buying.

As an content creator, do what you can, or at least can afford, to protect your material. Legal action may be expensive in both time and money, but you can at least request that your material be pulled or attributed (and document that correspondence). It will also deflate the plagiarist’s excuses if you come forward and publicly state that you never consented to that use of your material.

I’m not sure how much of a problem it will be going forward, but it’s definitely something to keep an eye on.

Updated: New Date! Registration and  Schedule is live!

 I was at SecurityBSides Boston talking to Bill Brenner and his two sons about Lego's when Chris Hoff shared a brilliant idea on twitter. A hacking/security conference for kids and their parents. Soon after Hackid was born and the dates for the first conference were set. 
So put aside the weekend of October 9-10, 2010. The first conference will be held at the Microsoft New England Research & Development (NERD) Center in Cambridge, MA. The community driven content has been posted and registration is live. It is the hope of the organizers that this will become the template that can be used at other locations and dates.I think I share a lot of others sentiment when I say this is going to rock!

I have been poking around with the updated version of Credential Manager in Windows 7 which has been commonly referred to as "Stored User Names and Passwords" in previous version of Windows. Much like its predecessors, the current version of Credential Manager still uses Data Protection API (DPAPI), but Windows 7 now stores saved credentials within the Windows Vault. Such credentials can include; user names and passwords used to log on to network shares, websites that use Windows Integrated Authentication, Terminal Services, and many third party applications such as Google Talk .


Credential Manager and DPAPI has been under scrutiny in the past. Cain & Able has had a decoder for some time. More recently, researchers from Standford University presented at Black Hat DC 2010 about their DPAPI research.

While breaking the crypto associated with this feature might be useful (i.e. if credentials are re-used elsewhere), it is not always necessary. The purpose of the Credential Manager is to pass saved credentials to resources commonly accessed by the user. Once you have gained access to a host as the unprivileged user  (take you pick of code execution bugs, Adobe pdf's seem to be popular these days), then you can certainly leverage this feature to pivot to resources referenced within the Windows Vault. Keeping a low forensics profile would be preferred, so I attempted to find existing command line tools that were already available on the host. After poking at Windows 7 for a while, I found an undocumented utility called vaultcmd.exe in the System32 folder that appeared useful. The following is the output of the supported switches for vaultcmd;


The /list switch allows us to view all Windows Vaults available on the host for the current authenticated user.


It appears in this example, the two default Vaults are the only ones that exist on this host. Also note that since the user is already authenticated, the vaults are in an unlocked state. Running the /listproperties switch against each vault lists some more details, including the number of credentials saved in each location.


Finally, the /listcreds switch gives us our newly found targets.


It appears, our unprivileged user has stored domain administrator credentials for two domain controllers. While this is certainly more secure than running as domain administrator locally, DPAPI adds no added security in this scenario since local access to this host has been gained. Now that we have completed our reconnaissance, we can pivot and access the servers by simply using the installed tools at our disposal. In the following example, I use psexec and the SET command to verify I have domain administrator access to DC-01 without having to specify a user name and password.


I was also able to access the the domain controller's Admin shares via the NET USE command using stored credentials within the Windows Vault.

net use P: \\dc-01\C$

In addition, since the Windows Server Administrator tools were also already installed on the host, I also verified that the Windows Vault was passing these credentials to Active Directory Users and Computers and the Remote Desktops Client.

I attempted to change some of the default settings for the vault using the /setproperties switch. For Example; it appears that vaultcmd has the ability to set a password on a vault;

vaultcmd  /setproperties:"Windows Vault" /set:AddProtection /value:Password
vaultcmd  /setproperties:"Windows Vault" /set:DefaultProtection /value:Password

But any attempt I made was met with the error; "The request is not supported.". So I would be interested to see if anyone can find additional documentation on this utility or the Windows Vault. I have not been successful in finding anything to date.

Some have suggested that any password management tool that hooks into the browser or operating system is more of a risk than a stand alone application that requires additional authentication mechanisms. While I generally agree with this, the emerging capabilities of attack and forensic tools that acquire volatile memory from a host (and consequently decrypted credentials), only require a bit more patience. Of course such tools, must be loaded on the compromised host increasing the forensic footprint the intruder leaves behind.

Happy Hunting!

These are my links for June 30th through August 5th:

• Programatically Setting Password Policies | Krypted – Mac OS X, like many operating systems has a robust password policy engine. One that is not leveraged by default on either Mac OS X client or on Mac OS X Server. In Mac OS X Server, when using Open Directory, you can easily click on Open Directory in the SERVERS sidebar list of Server Admin and then click on the Settings icon in the Server Admin toolbar. Here, if you click on Policies you’ll see the available Policies for Open Directory accounts.
• BlindElephant Web Application Fingerprinter – The BlindElephant Web Application Fingerprinter attempts to discover the version of a (known) web application by comparing static files at known locations against precomputed hashes for versions of those files in all all available releases. The technique is fast, low-bandwidth, non-invasive, generic, and highly automatable.
• DEF CON® Hacking Conference – Speaker’s Corner – Among the first questions you hear when teaching anyone to pick a lock is some variant of "What is this pick for?" I've heard it a dozen ways, "Which one should I use for this lock?", "Which one will open it fastest?" and "How does this one work?" I know that answering this question in print won't keep me from having to answer it a million more times, but at the very least it will help me collect my thoughts and hopefully serve as a primer to new pickers who come across it.
• Adam Muntner’s Weblog: Updated Web Application Security Testing Collection for Firefox –
• grand stream dreams: Sexy USB Boots (Win PE style) –
• Vulnerability Assessment Testing Automation Part I, (Tue, Jun 29th) – described how and why to automate parts of the security testing process.
• Demonstrating XSS with BeEF – Cross-site scripting (XSS) is a type of web application vulnerability that enables malicious attackers to inject client-side script into web pages viewed by other users. The idea is that in a vulnerable page, you can include your own code that runs in other people’s browsers. The non-persistent, or reflected, cross-site scripting vulnerability is the most common and easily detected type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user without properly sanitizing the response.

Related posts:

1. Bookmarks for August 30th through September 5th
2. Bookmarks for June 24th through August 11th
3. Bookmarks for June 5th through June 22nd

Last year, I reviewed Jayson Street’s Dissecting The Hack: The F0rb1dd3n Network, uncovering a massive amount of plagiarism that resulted in the book getting pulled, pending a revision.  Here are the posts that chronicle those events:

• The original review – …before I realized the extent of the plagiarism.  To summarize: I enjoyed the book’s fictional section, despite some flaws.  I had far more complaints with the “Security Threats Are Real” (STAR) section, which seemed very disjointed and unfocused.
• Amending My F0rb1dd3n Network Review – …upon a closer look, it became apparent that readers (and reviewers) were misled.  The vast majority of the STAR section (comprising of all but 120 pages of the book’s total of 400) turned out to be plagiarized from various sources (primarily Wikipedia).  I documented it and made this post to warn potential readers.  The authors responded, pointing to the technical editor as the cause.
• Syngress Response to Plagiarism in Dissecting the Hack: The F0rb1dd3n Network – Syngress released a statement confirming the authors’ take on what happened, and announced that there would be a revised release of the book.

On July 15th, a revised edition was released, and I requested a review copy so that I could see what had changed, and provide this new review.

What do you get?

The book has the same basic appearance as the previous version, with the addition of a third author, Brian Baskin, on the cover.  On the title page, Marcus Carey is added (in a smaller font) as an author, and Dustin D. Trammell is listed as the new technical editor.  Apart from “Revised Edition”, there is no discussion or acknowledgment of the book’s past.

The book has gone on a bit of a diet, roughly 70 pages.  This is a good thing, however, as the old STAR section was mostly irrelevant filler.  The fiction remains, virtually untouched from the previous version, at about 120 pages of the book’s 330 page.  The new STAR section is original content now, which is, of course, a dramatic improvement.

The Fiction

My comments from my first review mostly stand here.  The fictional F0rb1dd3n Network story was always an original creation of Jayson and Kent’s.  I am a big fan of the concept of “hacker fiction”, the likes of which you’ll find in another Syngress series, Stealing the Network.  I am definitely supportive of any attempts at writing new material in this genre.

As a story, I enjoyed this section of the book, but found it to be very short.  The plot is very much what one would expect out of a techno-thriller TV show (perhaps an episode of Leverage) and you get about the same degree of character development.  Unlike the Stealing The Network series, explanations of the attacks are saved for the STAR section, rather than given in-character in the story.  While I can see that this helps moves the story along, I think it makes the fiction seem quite short.  When it ends, you’re left wondering about some things that probably could have been wrapped up within this story, particularly an incident of “dark-grey-hat” hacking the protagonists vow to atone for, but that is never revisited.  It may be something that’s saved for a sequel, but it reads like the authors simply forgot about it by the end of the story.

I’m being critical here, but I really did like the story, as a whole, and I hope that there is an opportunity for the authors to continue it.  If you liked Stealing the Network, you’ll definitely enjoy it.  It ranks right up there with the best writing in that series.

(As an aside, if you want some awesome hacker fiction, check out Daniel Suarez’ Daemon and its sequel Freedom(TM))

While one of the selling points of the book is that all of the attacks discussed in the fiction are real and documented in greater detail in STAR, there are some minor quibbles with that.  There are times in the story where it seems as though the authors have hit the limits of their own experience with attacks, on more difficult topics like reverse engineering and exploit development.  In the handful of times this comes up, artistic license is taken, hands are waved, meaningless phrases are thrown around (“pop the sled on that buffer”) and the story moves on without one of those STAR references.  Only once does a technical error directly impact the story, and honestly it’s not something even most security professionals would have caught.  These are small issues, though I would have liked it if some outside help would have been brought in to lend some authenticity to those points and document them in STAR.

The “Security Threats Are Real” (STAR) section

The STAR section is greatly improved.  Gone are the page-chewing screenshots of blogs and descriptions of unrelated tools.  There is a greater focus on describing the attacks that are in the story than in the previous edition.  Overall, it reads as being much more professional.

It’s a good first-read for people interested in computer security.  There are some technical issues and organizational issues (some topics don’t really fit with the phase of attack they’re classified in), but it’s good for someone who’s gauging their potential interest in security.  Experienced readers might be slightly disappointed.  There is a lot of material on hacker culture that is heavily skewed to the authors’ experiences with various events, people, and conferences, which the uninitiated might take as gospel for the entire scene.  I think that a lot of this could have been trimmed down (perhaps placed on the website) to give a more in-depth and complete coverage of the attacks in the fiction section.

Should you buy it?

I believe that most of the regular readers of this site are the more technical members of the security community: penetration testers, folk who do forensics and incident response.  Readers in these are similar areas that are already “in” security will get a fun read out of this book (and it’s worth it for that, especially if you’re pining for more Stealing the Network) but are not likely to pick up any new skills.

If you’re new to this stuff, or if you’re testing the waters to see if security even catches your interest in the first place, this book might be an entertaining way to learn some basic concepts.  You’ll pick up a few simple skills, and you’ll have some points at which you can start researching something that interests you.  While I don’t see this book as keeping the attention of non-technical people that wish to stay non-technical, if you’re a motivated learner, it’s a decent place to start.

Overall:  It’s a great book for the audience it should be marketed to.  Good work and congratulations to Jayson, Kent, Brian, Marcus, and Dustin Trammell for fixing up the book and seeing it through to the end.

A few weeks back Larry Pesce from PaulDotCom posed the following question on Twitter:

"Hmm. If you had to deploy ONE security technology in your organization, what would it be? What is the risk reduction vs, total effort?"

Many people quickly replied. Some answers included: a comprehensive patch management solution (my pick), Security Information Management (SIM) system, network based firewall, Intrusion Prevention System (IPS), incident response plan, and my personal favorite "a very large dog..." . Larry quickly followed up asking what would the second technology be and why?

I struggled with that question. After all it is a "no win" situation. A proper incident response plan would certainly be needed but is reactive. Network defenses would be beneficial but do not take in account a mobile workforce. I finally settled on some sort of central system that would facilitate the system hardening of the end nodes. The reasoning for my answer is the result of experiences I had early in my information systems career.

During my time as a desktop support tech, I spent most days putting out fires. The lack of centralized patch management, host based firewalls, build procedures, and asset management was the source of chaos for the desktop and systems administration teams. Worm outbreaks, improper configuration, and end users running with local administrator rights were the norm not the exception. Consequently, the team was too busy chasing their tail around to be proactive. Those experiences resonated heavily with me and ever since I have insisted in being proactive whenever possible.

Would have proper incident response or a SIM solution have helped my former employer? Maybe. Incident Response procedures and SIM's are important parts of any defense infrastructure but they are reactive, not preventative. Consequently, I would certainly place them in my top five but only after implementing the basics of defense.

While Larry's hypothetical situation is enough to give any security practitioner nightmares, I found it to be a great source of self reflection. Larry discusses the replies in more detail during Episode 172 of PaulDotCom Security Weekly, so check it out when you get a chance. I'm interested to know what you would choose and how fast you would update your resume if you found yourself in the same situation.