WhiteHat's trustmark program as a game changer

I am a trustmark hater, I admit it; this should surprise no one.
I have labored long and hard over this post, but I believe it to be relevant and important.

WhiteHat Security, the genesis of Jeremiah Grossman's vision for web application security, has instituted a trustmark program.

Carefully branded a Security Certification Program, this offering seeks to raise the bar on the trustmark concept, a game changer if you will.
On one hand, this won't be hard to do.
As I have in the past, I could rail against the dime a dozen, pseudo-fraud programs that are nothing but conversion gimmicks designed to drive sales through falsely gained consumer confidence. They can all take their Nessus scanners and bugger off.

Instead, I'd like to describe why I think WhiteHat Security can shed new light and standards on this concept.
1) Reputation: WhiteHat Security has always been a premier brand in the realm of web application security. This is indisputable. Their scanning engine, their business model, their personnel are all geared to the cause; they are expert in this field.
2) Value of the service: I know first hand how much WhiteHat labored over the process of offering a Security Certification Program, i.e. how to do so without falling into the same lameness all the others so readily exhibit. This program is not about conversions first, security second. The certification is only offered to WhiteHat Sentinel customers. While there are no guarantees, if you are Sentinel customer, the statistical likelihood of your exposure to web application security flaws goes down exponentially should you choose to fix the flaws they discover. I know this not due to whitepapers or marketing claims, but from experience.
3) Lack of arrogance or false claims: A trustmark that reads "Website Security by WhiteHat Security" is not claiming to be Hacker Safe, Hacker Proof, or Hacker Free. Clicking the trustmark leads you to the following:
"This site employs WhiteHat Sentinel, WhiteHat Security's industry-leading website security solution. To help address concerns about safeguarding your confidential data from security breaches and hacker attacks, the "Website Security by WhiteHat Security" mark appears only on sites that use the WhiteHat Sentinel Service."
No BS, no hype, no false claims of grandure or impenetrability, just simple facts.
4) Jeremiah Grossman: Jeremiah knows this business better than anyone. As a business man he was driven to consider adding a Security Certification Program by customer demand. Whether we like it or not, customers like trustmarks seals, and benefit from them, no matter how lame a trustmark program may be. Customers using Whitehat Sentinel are paying for the privilege, this is not $250 a year scam with no value other than false confidence. Jeremiah's reputation is inherent to the success of this program. He is well aware of the pitfalls, and I know he has the integrity to ensure its value as a real security-first offering.

I expect WhiteHat Security to manage this program from the perspective of an industry standard-bearer, as their first customer has indicated.
Should the rest of the wannabes and posers in the trustmark game raise their standard to this level, I'd have less to talk about.
Good luck and godspeed, WhiteHat, the industry needs your continued integrity in this space.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Recommendations for trustmark providers

I've been slow in responding to Pete Lindstrom's (Spire Security) prompt for recommendations and solutions for trustmark (security badge) providers, beyond my typical griping about same.
I appreciate Pete's candor and perspective, and shall endeavor to make amends.
Having repetitively taken issue with trustmarks, with McAfee Secure\Hackersafe facing the brunt of it, I propose the following to ALL trustmark providers, as I did during the creation of the McAfee Secure Standard.

1) Check the arrogance and sales hype at the door.
We have no doubt that you're in business to drive conversions first and security second, so just be honest about it.
We also have no doubt that there will be vulnerabilities in your customer's sites, so cut out the "we guarantee their security" angle and opt for the "we do the best we can to contribute to the security and well being of our customers, and their customers" approach.

2) Practice transparency.
How do you scan (very specifically)? If you simply run Nessus, say so. If you make use of custom algorithms and signatures, say so.

3) Publish your standard, most importantly inclusive of your intentions on how to enforce it.
If a customer's site is not compliant, how and when, if at all, will you pull down the trustmark badge?
I can't believe I'm about to say this but McAfee Secure really has set the standard for establishing a standard. While I believe it to be lacking in areas, at least they have one.

4) Actually enforce.
So often I've found websites in flagrant violation of any feasible security standards, and yet they display a trustmark. This simply should not be. It is misleading, dishonest, and deceptive.

5) Offer resources.
As an alleged security provider, offer your customers resources. Not just the "use SSL and all is well" bunk. Real resources: OWASP, SANS Top 25, SDL, how-to, the list goes on.

6) Provide an immediately evident point of contact for your trustmark program; an abuse@, security@, and/or info@ alias to which we can report sites we determine to be vulnerable.
I have found it difficult in the past to disclose vulnerabilities; it shouldn't be.

7) Offer incentives.
People often do well with incentive. A reward system for strong security practices demonstrated by your customers will reap benefits, and adversely, so too will a punishment system for non-performers.

Note: Keep a close eye on Skeptikal.org. Mike's of the same mindset, and has applied this spirit of thinking to PCI ASVs who themselves have missed the mark on security, while holding others to the embattled PCI DSS. Look for some interesting content next week.

Finally, dear trustmark provider, think integrity. Operating from that position should lead you down the right path.

del.icio.us | digg | Submit to Slashdot

The McAfee Secure Standard has been published

McAfee has alerted me that the McAfee Secure Standard has been published on the McAfee Secure (formerly ScanAlert Hacker Safe) website.
The McAfee SECURE Standard
Joe Pierini and Kirk Lawrence started this process with me prior to their departure from McAfee, and work continued in their absence, largely at the hands of Will M., who's been communicative and inclusive in their stead.
I applaud McAfee for staying true to their commitment to publish the McAfee Secure Standard.
While I may not agree with everything in it, a standard is better than no standard.
That said, my concerns with the Standard as discussed earlier remain unaddressed.
First, you will find that remediation of what McAfee deftly refers to as Client Side Vulnerabilities is Optional. The Client Side Vulnerabilities category includes the entire family of script insertions.
Clarified, this means that merchants displaying the McAfee Secure trustmark are under no obligation to repair such vulnerabilities; the trustmark will remain displayed unabated by the truth.
My position here is clear.
If a website declaring itself secure via a McAfee Secure trustmark is vulnerable to cross-site scripting (XSS), I believe that declaration to be false and misleading. Further elaborated, the McAfee Secure Standard's Client Side Vulnerability category includes cross-site request forgery (CSRF).
While I choose not to out any site in particular at this time, I can assure you with all professional certainty that there are sites displaying a McAfee Secure trustmark that are vulnerable to CSRF. In the case of sites using one particular application, the CSRF vulnerability is so severe, an attacker can escalate privilege in short order.
This is a vulnerability that I've discovered and disclosed responsibly, so I won't discuss it further at this time.
But I ask you, should a site vulnerable to such an attack be labeled as McAfee Secure, per their freshly published Standard?
I think not.
Also Optional on the McAfee Secure Standard: SSL Encryption.
Should a website that conducts financial transactions, yet does not choose to encrypt transaction traffic, be allowed to display a McAfee Secure trustmark?
I think not.
Ironically, the McAfee Secure Standard directly compares itself to PCI DSS. None of the vulnerabilities listed as Optional, per the McAfee Secure Standard, are acceptable for PCI certification.
While the McAfee Secure Standard careful delineates the difference between the Secure trustmark program and their PCI Compliance program, it's not as black and white as they may think. McAfee is a PCI approved scanning vendor (ASV), and a provider of a popular PCI compliance service.
Should they really hold one set of customers to a different standard than the other?
I think not.
Again, I applaud McAfee for publishing the McAfee Secure Standard.
I never imagined we'd get this far, so I humbly ask McAfee to consider the following.
1) Don't bury the Standard. Announce it. Publicize it. Embrace discussion about it. Provide a link to it from the McAfee Secure website. While we may have differences over some of its content, the McAfee Secure Standard is a bold step. Let people know.
2) Disguising script insertions (XSS and CSRF) in the Client Side Vulnerabilities category is a disservice to your customers, and their customers. The "clients" in Client Side Vulnerabilities are consumers using these sites. I believe you are beholden to these consumers as much as you are your own.
Extend the timetable for merchant repair of these vulnerabilities if you must, but said repair should not be Optional.
3) A McAfee Secure site, with a McAfee Secure trustmark, without an SSL certificate is unfathomable. While many a vulnerability can be exploited under the umbrella of SSL protection, SSL encryption is nonetheless an industry standard that should not be Optional.
These things I ask of McAfee in the name of common sense and consumer well-being.
To quote the McAfee Secure website:
"When you display the McAfee Secure certification mark, you not only increase sales by increasing shopper confidence, you build your brand with the security seal seen on more top sites than any other."
Is "increasing confidence" at the expense of industry standards, and real web security a violation of good faith and the very trust you seek to build?
I think so.

As always, I welcome constructive and thoughtful comments and feedback.

del.icio.us | digg | Submit to Slashdot

The McAfee Secure Double Standard

McAfee Secure claims to be McAfee Secure while not McAfee Secure

It's been a rough week for our McAfee Secure friends.
First, an XSS, Iframe injections, and XMLHTTP outing provided by XSSed.com, followed quickly by a CSRF browbeating from The Skeptikal One, Mike Bailey.
While these findings should not come as a surprise, I have no doubt McAfee moved as quickly as possible to resolve the issues.

What sadly should also not come as a surprise is that the entire time these numerous vulnerabilities were live, so too was the McAfee Secure trustmark.

I realize the odds of McAfee Secure removing the McAfee Secure trustmark when they are not McAfee Secure is highly unlikely, it nonetheless exemplifies a double standard.
The key question is this.
If the McAfee Secure customer portal is vulnerable to CSRF for 4-5 weeks while the portal code is under repair, should it declare itself McAfee Secure?

To further my point, language from the McAfee Secure Standard:
In the event that McAfee discovers a vulnerability that prevents a merchant’s website from complying with the McAfee SECURE standard, the merchant will have a 72-hour remediation window. In instances where McAfee believes confidential customer data is at immediate risk, or in those cases where McAfee has evidence of prior compromise, the McAfee SECURE trustmark may be removed before expiration of this 72-hour window.

While the McAfee Secure Standard does not indicate that CSRF by itself is worthy of pulling a trustmark, the fact remains that because Mike had demonstrated what could be done with this paricular vulnerability, such as a live weaponized attack script, McAfee was treating it like a high-priority critical issue.
I can therefore only hope that a McAfee Secure customer under the same circumstances would NOT have been displaying a McAfee Secure trustmark.

So there it, plain and simple, for your consideration.
A double standard?
You decide...comments welcome.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: one flaw to rule them all

Flaws in SAAS offerings and the inherent risks

What if dozens (even hundreds) of banks all used one vendor's solution to provide online banking services?
What if that solution had a security flaw thus affecting all users of said solution? A finding of considerable concern, yes?

I must preface this discussion with the fact that the vendor in question has proven to be trustworthy, capable, reputable, responsible, and responsive.
Precision Computer Systems, a FISERV company, provides outsourced online banking solutions to a plethora of banks.
My desire to discuss the vulnerability with Precision Computer Systems (PCS) was forwarded to FISERV for consideration, and the reply came directly from the Vice President | Head of Security.
"As you might imagine, no higher priority exists for our organization than the protection of our client’s information, and that of their customers. To that end, we’ll always welcome constructive feedback such as yours with enthusiasm."
As responses to reported vulnerabilities go, PCS/FISERV handled the process in ideal fashion and are to be applauded for doing so.
While flaws in web applications are a dime a dozen, and nearly every web app yields a vulnerability at some point, the more important piece is how the vendor responds when said vulnerability is disclosed to them.
For this software as as service (SAAS) offering, while each bank's web site is unique, when the user decides to login to the Online Banking service, they're redirected to https://ibank.pcs-sd.net/onlinebanking8/login.r?t-bank=bank id.
Thus, all banks utilizing PCS for this particular feature all take advantage of this specific application to handle logins, amongst other things.
The login form, in particular, suffered from a cross-site scripting (XSS) vulnerability; as discussed in earlier posts, the potential risks to consumers are obvious.


This graphic has specific bank information redacted, and the specifics of the vulnerability are unnecessary. My preference is to treat this discussion as a learning opportunity, rather than nitpick needlessly.

At the risk of overstating the point, the one flawed variable affected all PCS customers utilizing the service.
Again, PCS/FISERV, as indicated above, handled this vulnerability quickly and admirably; they immediately assigned a PM and development resources to repair and release a fix to production.

The lessons here are many.
1) Other online finance vendors, particularly those falling in the SAAS category, take note: this is how to respond to reported vulnerabilities.
2) SAAS customers, take note: ensure that the vendor you contract with for service is very clear about their secure development practices. Don't be afraid to ask very pointed questions such as:
"How quickly will you respond if a vulnerability is disclosed to you?"
"Do you employ a Secure Development Lifecycle standard?"
"How often, and by whom, is the security posture of your product reviewed, preferably with the appropriate compliance frameworks (PCI, SOX) in mind as well as the given web application security standards (input validation, sanitize output, etc.)?"
3) Customers and vendors alike: trust no trustmark (security badge) provider to actually provide you any actual security value...conversions yes, security not so much. At least one bank on the PCS customer list utilize the likes of Control Scan. You'd think Control Scan might have found or reported this vulnerability to the bank or PCS, yes? I think not. SSL-related trustmarks are also nice but no encryption in the world will help you under these circumstances.

The responsibility bestowed upon SAAS providers is of a magnitude at least similar to that of typical application product providers, if not more.
Where a single "boxed" product falls under the scrutiny of vulnerability managers such as CVE and OSVDB, no such scrutiny exists for SAAS offerings.
As more enterprises take advantage of SAAS and cloud-based offerings, they do so for obvious cost and efficiency reasons, but may not have assessed the changing dynamic of their risk posture.

As we consider the premise of one flaw to rule them all, vendor response will be paramount. May the PCS/FISERV standard become commonplace.

del.icio.us | digg | Submit to Slashdot

toolsmith: SpiderFoot

Prerequisites/dependencies

Python 2.7 if running on *nix as well as M2Crypto, CherryPy, netaddr, dnspython, and Mako modules

Windows version comes as a pre-packaged executable, no dependencies

Introduction

All good penetration tests and threat assessments should be initiated with what you’ve seen referred to in toolsmith as OSINT, or open source intelligence gathering. This practice contributes greatly to collecting a useful list of targets of opportunity. One key element to remember though, the bad guys are conducting this same activity against you and your Internet-facing assets too. It’s probably best then that you develop your own OSINT practice so you can find the information you may not wish to, or even know, you are exposing. Steve Micallef’s SpiderFoot is another tool in the arsenal specific to this cause. You may already be aware that the four phases of a web application security assessment, as defined using the SamuraiWTF distribution, are recon, mapping, discovery, and exploitation. The SANS GIAC Certified Web Application Penetration Tester (GWAPT) curriculum follows suit given that Secure Idea’s Kevin Johnson contributed heavily (developed) to both. SpiderFoot nicely blends both recon and mapping as part of its feature set. As we consider legal, privacy, and ethics issues for the March ISSA Journal, OSINT and reconnaissance become interesting and related topics. I have, on more than one occasion, discovered very damaging data via OSINT tactics that, if in the wrong hands, could have been very damaging. When you consider findings of this nature with regard to ethics and the legality you may find yourself in an immediate quandary. Are you obligated to report findings that you know could cause harm to the target if left unmitigated? What if during your analysis you come into possession of classified or proprietary information that having in your possession could create legal challenges for you? Imagine findings of this caliber and it becomes easy to recognize why you should always conduct intelligence gathering and footprinting on your own interests before the wrong people do it for you. SpiderFoot, as a tool for just such purposes, allows you to understand “as much as possible about a given target in order to perform a more complete security penetration test.” For large networks, this can be a daunting task, and SpiderFoot automates this process significantly, allowing penetration testers to focus their efforts on security testing itself.

Steve provided us with some SpiderFoot history as well as insight on what he finds useful and interesting. He originally wrote SpiderFoot as a C# .NET application in 2005, purely as an exercise to learn C#, having been inspired by BiDiBLAH’s developers from Sensepost (who went on to create Maltego), thinking he could make a lighter open source version. For seven years that was Steve’s first and only release until he decided to resume development again in 2012. His work on next generation versions have led SpiderFoot to be cross platform (Python), far more extensible, functional, with a much nicer user interface (UI).

Steve’s current challenge with SpiderFoot is deciding what cool functionality to implement next, his to-do list is ever growing and there are a numerous features he’d love to extend it to include. He typically balances his time between UI/analysis functionality versus new checks to identify more items to aid the penetration tester. The aforementioned OSINT (Open Source Intelligence) community also continues to produce new sources which in turn inspire Steve to build new SpiderFoot checks.

He finds it interesting testing out a new module, and actually finding insightful items out there on the Internet simply during the development process. Steve’s favorite functionality at the moment is identifying owned netblocks, and co-hosted sites. Owned Netblocks indicates entire IP ranges that an organization owns, which enables penetration testers to more completely scan the perimeter of a target. Co-hosted Sites shows you any websites on the same server as the target, which can also be revealing. If your target is hosted on the same server as sites identified as being malicious by the malicious site checker, or the blacklist checker plug-in it could potentially indicate that your target is hosted on a compromised server.

As you read this it’s likely that the following planned enhancements are available in SpiderFoot or will be soon:

·         2.1.2 (early March)

o   SOCKS proxy support

o   Real-time scan progress viewer

o   Identify scan quality impacting issue

o   Autoshun (www.autoshun.org) lookup as part of malicious checks

o   SANS (isc.sans.edu) lookup as part of malicious checks (queue the Austin Powers voice: “Yeah, baby!”)

o   Update GeoIP checker

·         2.1.3 (mid April)

o   VirusTotal, SHODAN, Facebook, Xing, Pastebin and GitHub plug-ins

Note that when you pull SpiderFoot from GitHub, you are downloading a beta version of the next release, as Steve commits new functionality there periodically in preparation for the next version. For instance, SOCKS functionality is in the GitHub repository right now but not in the packaged released version (2.1.1.).

SpiderFoot is a great project with a strong development roadmap, so let’s get down to business and explore.

Quick installation notes

Windows installation is an absolute no brainer; download the package, unpack it, execute sf.exe, and browse to http://127.0.0.1:5001. All dependencies are met including a standalone Python interpreter, so you may find this option optimal.

Linux (I installed it on SamuraiWTF) users need to settle a few dependencies easily solved with the following few steps that assume pip is already installed:

sudo apt-get install swig

sudo pip install mako cherrypy netaddr M2Crypto dnspython

git clone https://github.com/smicallef/spiderfoot.git

cd spiderfoot/

sudo python ./sf.py 0.0.0.0:9999

The last line indicates that you’d like SpiderFoot to bind to all addresses (including localhost) and listen on port 9999. You can define your preferred port or just accept default if undefined (5001). Steve reminds us on his installation page to be cautious regarding exposing SpiderFoot to hostile networks (Intranet, security conference wireless) given that there is currently no authentication scheme.

SpiderFoot unleashed

The SpiderFoot UI is, how shall I say, incredibly simple, intuitive, and obvious even. To start a scan…wait for it…select New Scan. Figure 1 represents a scan being kicked off on my domain (don’t do it) as defined by the By Module view.

FIGURE 1: Kicking off a new scan with SpiderFoot

If you wish to more granularly define your scans, select the By Required Data view (default) then pick and choose your preferred data points including elements such as malicious affiliations, IP data, URL analysis, SSL certificate information, affiliate details, and many other record. You should then be treated to a success message. Scans results are stored in a SQLite DB so over time you’ll likely build up a collection if you don’t purge. Under the Scans tab as seen in Figure 2 you can click the scan in the Name column of the table view and review results. You’ll also note status here and can also halt the scan if need be. I imagine the real-time scan progress viewer will show itself here in the near future as well.

FIGURE 2: SpiderFoot Scans view

If need be (default settings work quite well), you can tune the actual scan configuration as well via Settings, with attention to how you’d like to tune storage, search engines, port scanning, spidering, TLD searches (see Figure 3), amongst others.

FIGURE 3: SpiderFoot Settings view

When my scan completed, with default settings and all checks enabled, the results included 11360 elements. For you data miners, metrics minions, and hosting harvesters, you can export the results to CSV (see Figure 4) and filter by findings type and module, or your preferred data pivot.

FIGURE 4: SpiderFoot results and export functionality

As I navigated all the results, I was intrigued to find a hit for URL (Uses Flash) simply because I didn’t recall any Flash features on my site. I immediately chuckled when I reviewed the result as it was specific to a Flash video I’d created for the 2008 ISSA Northwest Regional Conference wherein I ripped on the now defunct Hacker Safe trustmark for indicating that their customer’s sites were “hacker safe” when, in fact, they were not. Oh, the good old days.

Want to visualize your results? No problem, you can choose from a bubble view of data elements or the discovery path. Figure 5 represents the discovery path for Social Media Presence findings. Hover over each entity for details specific to initial target type, the source module, and the related result.

FIGURE 5: SpiderFoot visualizes a discovery path

SpiderFoot will absolutely uncover nuggets you may have long forgotten about and may want to remove as they are potentially vulnerable (outdated plugins, modules, etc.) or unnecessarily/unintentionally exposed. I found an old dashboard I’d built by hand eons ago with long dead extenal JavaScript calls that had no business still being available. “Be gone!”, I said. That is what SpiderFoot is all about. Add it to the tool collection for penetration tests and OSINT expeditions; you won’t be disappointed.

In Conclusion

Steve Micallef’s SpiderFoot is functionally simple but feature rich and getting better all the time as it is well built and maintained. Follow @binarypool on Twitter and keep an eye out for timely and regular releases.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter @holisticinfosec.

Cheers…until next month.

Acknowledgements

Steve Micallef (@binarypool), Spiderfoot author