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

Congratulations to the Open Security Foundation

I was thrilled when I read that the Open Security Foundation (OSF) was named as SC Magazine's 2009 Editor's Choice Award recipient.
I simply can't think of a more deserving bunch.
Congratulations and well done!
OSF is the parent organization for the OSVDB and the DataLossDB.
Their accolades reminded me that OSF is a a 501(c)3 nonprofit, public foundation and as such, benefits from donations. I've been a Network for Good user for a year or so, and it occurred to me that I'd rather have donations made to OSF via my badge than any other organization.
People occasionally try to pay me for helping them out via Holisticinfosec.org; I tell them I'm paid well enough at my day job and writing gigs, and that they should instead donate to my preferred organization.
OSF is that preferred organization, please donate via my badge or straight through OSVDB, if so motivated. I just did; I'd be honored if you'd do the same.
Again, congratulations OSF!

del.icio.us | digg | Submit to Slashdot

Cloud security commentary falling down on the job

This one made me quite angry in February, but I chose to let it go, with the exception of posting a comment.
Then, recently, I stumbled across it again on Network World and PCWorld and, given that they've taken to regurgitating such inanity, I simply couldn't pass it by again.
Here's the crux of it.
At IDC's Cloud Computing Forum, much mention was made of how much security concerns in the cloud are overblown.
Really?
Brilliant commentary such as follows seemed to be in abundance:
"I think a lot of security objections to the cloud are emotional in nature, it's reflexive," said Joseph Tobolski, director for cloud computing at Accenture. "Some people create a list of requirements for security in the cloud that they don't even have for their own data center."
Yes, Joseph, but here's a secret for you. In their data center at least they can be responsible for security flaws and mitigate accordingly. In the cloud they depend on someone else to address security problems, and if that provider is slow to respond, who knows what mayhem may ensue.
Data breach anyone? Loss of customer confidence?
Yeah, go ahead and blindly trust your reputation to the cloud, complete with everyone at the IDC forum singing its praises and throwing all the key buzzwords around.
It'll be OK...good luck with with that.
Statements from Accenture such as "security objections to the cloud are emotional in nature, it's reflexive" leave me shaking my head in wonder.
Seems like Accenture is really falling down on the job here.
Wait, they really are falling down on the job here. ;-)
This Accenture swf should only load whitelisted, known good Accenture Flash video files.
But it doesn't. It loads any FLV you like, such as this one.
As I said, falling down on the job. ;-)
So, before consuming the wisdom Accenture seems to be throwing about so freely, perhaps suggest that they pay attention to their own security before telling us that cloud security fears are overblown.

del.icio.us | digg | Submit to Slashdot

So long Zango, thanks for all the phish

Oh, the joy...trumpets on high, banners waving in the wind!
Zango has been declared dead.
Good riddance, bugger off, may the fleas of a thousand camels infest your...well, you get the point.
As I've been heckling Zango for years, it gives my real pleasure to fire a parting shot. Or two, perhaps three.
Zango, this is for you.
The rest, dear reader, are for your viewing pleasure.
You'll recall that Hotbar is a Zango "product"?

Enjoy...

Props to John Leyden of El Reg for the best title of the day, via a tidy IFRAME.
http://tinyurl.com/c22sxn

An end to SPAM, thanks to Zango and Hotbar...really, I mean it.
http://tinyurl.com/cxhm79

A nod to Maestro Grossman's excellent book via manipulated Hotbar Flash.
http://tinyurl.com/cg7uke

To quote the mighty Marcus Fenix, "Sucks to be them."

Cheers.

del.icio.us | digg | Submit to Slashdot

The IT Infrastructure Threat Modeling Guide

After reading a toolsmith article I'd written on PTA: Practical Threat Analysis, Frank Simorjay, a local ISSA chapter member, friend, and co-worker reached out to a peer team in the Microsoft Solutions Accelerators (SA) group and suggested the prospect of something similar to be added to the SA roster.
After meeting with the SA Security & Compliance team, and a couple months of excellent collaborative effort with the likes of SDL expert Adam Shostack, group PM Kelly Hengesteg, editor Steve Wacker, and contributor Jeff Sigman, I authored the IT Infrastructure Threat Modeling Guide, now released in beta on the Connect site.
Sign up for the beta program here, then bookmark this.

Threat modeling has been well applied during the software development process, but there has been a noteworthy, Internet-wide lack of documentation and guidance with regard to applying threat modeling methodology to infrastructure. While many people and organizations threat model infrastructure in some form or fashion, we believed it was time to create a unified process that anyone from a small, one person IT shop, to a major enterprise could follow, and thus improve their security posture.

The IT Infrastructure Threat Modeling Guide provides an easy-to-understand method that enables you to develop threat models for your environments and prioritize your investments in IT infrastructure security. This guide describes and considers the existing Microsoft Software Development Lifecycle (SDL) threat modeling process and uses it to establish a threat modeling process for IT infrastructure.

Please feel free to give it a close look and submit feedback, we really do welcome it.

It is the intent and hope of this guidance that the benefits of choosing to develop a threat model for your IT infrastructure will be many, and that a holistic state of security becomes commonplace for those who undertake the process.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Recession humor at Citibank's expense

It should come as no surprise that Citibank would turn up in the Online Finance Flaws series.
Given their active role as root cause participant in our current economic downturn, Citibank has managed to invoke the ire of more than one critic.
The lesson I'll offer here is a simple one, unrelated to economics.
If you outsource development, and fail to manage the process, including the security development lifecycle (SDL), or lack thereof, you put your enterprise at risk.
I admit I am assuming outsourcing in this scenario, but I believe given that the vulnerability was found in a Citibank Hungary offering, I don't think I'm off the mark.
Citibank ignored me entirely so I decided to pass the findings off to the Microsoft Vulnerability Research (MSVR) program and see if the team could make contact with the right folks. The MSVR program is both very young, and in a current state of transition, but they obviously had success as the following vulnerability has been repaired. Hopefully I'll be able to provide more detail on this program in the future.
Citibank Hungary suffered from a cross-site scripting (XSS) vulnerability at the from variable as submitted to the form.jsp script.

It afforded me ample opportunity to inject a little humor (pun intended).
Here's the video if you'd like the long version; please note all the "security" references I capture prior to finding the site to be in complete contradiction to those references.

The following screen shot captures the essence of the message.



Here's the string resulting in the above screen shot, to give you injection context.



All security implications apply here: phishing, PCI, damage to brand and reputation, risk to consumers, etc.
That said, it appear that just a few of the kabillions of bailout dollars bestowed upon Citibank might have gone to a web application protection mechanism applied globally to all Citibank sites.
I'd love to say it came on the heels of this vulnerability being disclosed to them, but alas, I'll likely never know.
As I poked about to see what sort of results the old vulnerabilities generated, as well as poking for any other lapses, I universally received this URL.
It shows a 404, but the implications are something WAF-like is nailing common Javascript strings, given that the URL declares /domain/spoof/intercept.
Makes me feel good to see my tax dollars hard at work. ;-)

Cheers.

del.icio.us | digg | Submit to Slashdot

A follow-up on SaaS & cloud risk

When I recently discussed SaaS & cloud risk, with particular regard to Baynote, it received some attention, both positive and negative.
Having made Dr. Deviant's list for “stating the bleedin’ obvious” ;-), I must say it's hard to disparage the man's view.
Yet, there is a key point that eludes those detractors of my view that SaaS and the cloud present enhanced risk.
Yes, lots of software, operating systems, browsers, wikis, yada yada yada, ad infinitum, exhibit flaws and put users at risk of compromise. But most often, those resources at risk are also under those user's near or immediate control.
Not so of SaaS or cloud offerings.
When you commit your enterprise to the cloud, you yield control, plain and simple.
To which I can only offer, ask the right questions before doing so.
A recent comment on the heels of El Reg's coverage of the Baynote flaw discussion was written as if from my own keyboard (I assure you it wasn't), and I will use it to close, with my compliments to Raife Edwards:
The difference is that... IF... you own, and run, your own servers, or systems/software... AND, a "common vulnerability" exists, and is exploited... You MAY be vulnerable... you MAY have a security issue... you MAY be targeted... you MAY not have adequately protected your system... you MAY be hit by the problem... you MAY have issues, and losses... possibly.
If, however, you are dependent upon any, EXTERNAL, single point-of-attack/vulnerable-point... then you WILL be hit... you WILL be affected... you WILL have losses... and you WILL be totally-dependent upon EXTERNAL-interests in "fixing", and recovering... based upon THEIR competence, and on THEIR time-table... and, to suit THEIR perception of THEIR interests.
In other words, ALL YOUR EGGS in [SOMEONE ELSES] basket.

Precisely.

del.icio.us | digg | Submit to Slashdot

Tamper Data: CSRF examined

I've been picking on web applications with CSRF vulnerabilities a great deal lately, and in so doing thought it timely to discuss one of my favorite tools for the task in a toolsmith article.
Tamper Data: CSRF Examined explores Adam Judson’s Tamper Data, the Firefox add-on, as one of the best tools for sniffing out CSRF holes. It allows you to quickly note the absence of token/formkey use, and uncover variables useful in crafting scripts to present vendors and vulnerability clearinghouses with proofs of concept.
Jeremiah Grossman referred to CSRF as the sleeping giant years ago but apparently no one's listened. ;-)
I can tell you, my research indicates that it remains a prevailing flaw. It's also difficult vulnerability to scan for, so most PCI ASVs miss it completely. If you have doubts about CSRF holes and PCI compliance (see PCI DSS 1.2 6.5.5) you need only read Mike Bailey's perspective over at skeptikal.org where he discussed the issue in cPanel almost a year ago and has since exposed the issue in Zen Cart, after a discussion we had regarding CSRF issues in osCommerce.
The following are all CSRF (and other vulnerabilities) discovered with Tamper Data, and disclosed via advisories employing responsible disclosure practices.
HIO-2008-1005 CompactCMS 1.1 XSS & CSRF
HIO-2008-1022-1 RateMe 1.3.3 XSS & CSRF
HIO-2009-0128 osCommerce CSRF
HIO-2009-0305 e107 Multiple e107_admin CSRF & XSS Vulnerabilities
HIO-2009-0308 dotProject 2.1.2 CSRF & multiple XSS
I also have many more similar vulnerabilities waiting in the pipeline for vendor repairs.

If you don't use it already, may I suggest installing Tamper Data at your earliest convenience?

del.icio.us | digg | Submit to Slashdot

Application Security Specialist: Don't Fall Behind

I've long supported certifications, in concert with experience, to be used as a measuring stick for the likely success of individuals in the information security field.
SANS, of course, offers significant value on this front,and what security professional is ever given due consideration without their CISSP?
When I was asked to participate in the Application Security Specialist pilot program, I jumped on the opportunity. And now, having become an ASS, my career has simply blossomed.
With the increased credibility it offers I've been able to demand more per hour for pen testing engagements.
I've even gained the respect of vendors and merchants alike; they're now less likely to blow me off when I tell them their apps are broken.
Given the pilot program I participated in, I can only say, now that its widely available, you should become a Certified ASS as soon as possible.
You can even join the LinkedIn group here.
Being an ASS is all it's cracked up to be!

Certified Application Security Specialist

The 100th post: Philosophy feeding action

As I was writing this I realized that this is my 100th post, and it therefore seemed somehow significant. With some interesting personal news to report it also provides me with the opportunity to declare a current philosophical mission statement:
No matter the activity, be it researching, advising, and disclosing ailing web applications, tracking malware attributes, or researching and documenting useful tools and methodology for incident responders and security professionals, I do it for one reason.
I simply believe it is our inherent responsibility to try to thwart miscreants in anyway possible. There are too many of them, and too few of us. Thus, the more we disclose and fix, the better we understand maliciousness, the stronger our implementations and investigations, the more secure we may become.

Two recent developments speak directly to this philosophy:
1) The Solutions Accelerators group at Microsoft, my employer, asked me to write the IT Infrastructure Threat Modeling Guide, born of an ISSA Journal toolsmith article I'd written on PTA (Practical Threat Analysis).
2) I was invited to join the APWG Internet Policy Committee, born of conversations with Dave Piscitello regarding the Anatomy of an XSS Attack.

First, with regard to the IT Infrastructure Threat Modeling Guide, this guide takes the SDL appproach to threat modeling and applies it specifically to infrastructure. When the beta goes this Friday, you can register and provide feedback here.
One can consider threats to IT infrastructure from four specific perspectives:

1) Re-architect and re-implement to eliminate them.
2) Apply well understood mitigations.
3) Invent new mitigations.
4) Accept the risk.

These are entirely viable perspectives, but the practice of threat modeling your infrastructure must precede these considerations.
To that end, the IT Infrastructure Threat Modeling Guide is designed to help IT professionals accomplish the following:

• Identify threats that could affect their organizations’ IT infrastructures
  
• Discover and mitigate design and implementation issues that could put IT. infrastructures at risk.
  
• Prioritize budget and planning efforts to address the most significant threats.
  
• Conduct security efforts for both new and existing IT infrastructure components in a more proactive and cost-effective manner.

Second, with regard to the APWG Internet Policy Committee, my intended focus here is to participate in guidance to help harden web services in defense against the dark arts...cybercrime, phishing, fraud, etc.
To get a better sense of what the APWG IPC is all about, see see Co-Chair Laura Mather's series on online fraud here.

As pertinent to either of these recent developments, I invite feedback and participation. Please feel free to contact me via comments here or email.
This work, this blog, my philosophy, my mission, are all carried out with you in mind, dear reader.
I thank you for your support and readership, and I look forward to the next 100 posts.

del.icio.us | digg | Submit to Slashdot

Why trust marks can't be trusted

Trustmarks & security badges don't provide security, just false confidence.

Hopefully,a month or so ago, you noticed the headlines and have read that Geeks.com, via its parent company Genica Corp, has settled with the FTC and will allow "allow federal regulators to monitor its website security for 10 years to settle charges it violated federal laws requiring it to adequately safeguard sensitive customer data."
I'd be remiss in my duties if I didn't remind you, dear reader, that Geeks.com was a Hacker Safe (now McAfee Secure) site.
I'm certain that if you've ever read my blog before you know I've taken McAfee Secure to task numerous times, and consider my point well established.
It's all really part of a larger discussion that should come as no surprise.
The only value of a trust mark/security badge is to the merchant wielding it, often under false pretenses. I've not met a trust mark yet amongst whose customers I couldn't find web application security flaws.
Forget what this means for PCI compliance. Every one of the examples I'm about to present is likely beholden to PCI in some form or fashion.
The reality is, they all display a trust mark, and aren't worthy of that trust. Consumers are at risk, plain and simple.
Let's explore, shall we?
There's WebSafe Shield's Hacker Free Site, or Comodo's HackerProof, perhaps Security Metrics Credit Card Safe(more on them in the near future), and my new favorite in security hilarity, Control Scan.
Remember former Hacker Safe fangirl, Cresta Pillsbury, she of "we go in like a super hacker" fame? When she jumped ship with jaded judiciousness, she placed herself squarely in Control Scan's camp carte blanche. Talk about the blind leading the blind.
In the interest of protecting customers and merchants (who've ignored disclosure notices), I'm going to provide screen shots a variety of vulnerabilities, without indicating who sufferers from it specifically. Rather, we'll focus only the trust marks displayed handsomely next to the realized vulnerability.

We'll begin with WebSafe Shield's Hacker Free Site. Here's an example IFRAMEd with a real trust mark innovator, Scanless PCI:



Here's a ControlScan customer, IFRAMEd with XSSed.com:



Finally, this one's my favorite. This is a Comodo Hacker Proof site (you'll have to trust me on this (pun intended)), helpfully barfing database schema for the world to read:



Need I remind you that any merchant receiving customer PII and credit card data that is vulnerable to XSS, CSRF, or SQLi is not Hacker Proof, or Hacker Free, or Hacker Safe?
They should simply be labeled Hacker Ready.

*sigh*...now I'm depressed.

Thanks to Joe Pierini for participating with me in this conversation for some time now.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: At least AIG got this one right

As our economic conditions worsen, and the gloom and doom chatter intensifies, much attention has been paid to AIG. The crux of the AIG dilemma, to hear Ben Bernanke say it, is that they're too big to let go under, but most observations indicate they deserve to.
"I share your concern, I share your anger," Bernanke told the Senate Budget Committee. "It's a terrible situation, but we're not doing this to bail out AIG or their shareholders. We're doing this to protect our financial system and to avoid a much more severe crisis in our global economy."
Add to that this past week's disclosure that AIG will pay out $170 million in tax payer dollars as bonuses, and today's news that the $170 billion at large is basically already all gone.
Thus, the list of big finance companies becoming fodder for verbal abuse and regulatory oversight just keeps growing.
That said, I am neither an economist or even remotely intelligent enough to speak on these issues with authority, but there's one issue I know relatively well.

As part of the ongoing Online Finance Flaws series, AIG suffered from a cross-site scripting vulnerability in their search script.

I apologize in advance, I couldn't resist a little political, current events humor at AIG's expense as I chose to drop in an IFRAME with a relevant news story.

AIG before:



AIG after:



I initially took note of this vulnerability on sla.ckers.org. It occurred to me that, in all likelihood, no one had bothered to tell AIG. After pinging my circle of industry folks with good contact lists, to no avail, I decided to try winging my disclosure and advisory effort to see what might come of it.
I sent email to abuse@, as well as two other aliases I found on the AIG site security page; specifically, corporatelegalcompliance@ and aig.iaig@.
I received an almost immediate automated response with a ticket number (a good thing), a call from an AIG information security resource the next day (a really good thing), and a week later the issue was fixed (a great thing).

So, as I sit here watching my 401k and investment portfolio fall in value by 75%. due in large part to one group at AIG, I can rest comfortable that another group at AIG (information security) is doing its job well. ;-)

del.icio.us | digg | Submit to Slashdot

asSaaSsinated: more on SaaS & cloud risk

As previously discussed, SaaS represents frightening scenarios for well intended enterprises seeking to offload cost and resource demands. The same motives are driving businesses into the cloud like lemmings off a cliff.
Yet, these businesses/enterprises may not conduct best effort diligence when it comes to ensuring their vendor of choice is managing their security properly.
Under such circumstances, their well being in the SaaS realm could well be at risk.
Consider previous examples such as Online finance flaw: one flaw to rule them all, or the discussion regarding Sage Live.
Enter Baynote, whose offerings include Social Search.
Following the principles of one flaw to rule them all, a single validation error in the q variable found in http://[Insert customer here].com/socialsearch/query?cn=[customer]&cc=us&q= led to numerous Baynote customers falling prey to cross-site scripting.

VIDEO

To their credit, Baynote was responsive and fixed the issue quickly (well done!) but the issue exemplifies ongoing risks to customers and consumers.
To that end, I've offered some common sense guidelines for businesses (in particular finance, but applicable to all) regarding questions to be asked of SaaS provides.
The article is available at SearchFinancialSecurity.com.
This is an issue we all need to pay close attention to. SaaS vendors take on an entirely new level of responsibility with each customer they add. If they treat the process in the same manner that Sage did, trouble awaits in abundance.
Ask the right questions and expect clear, thoughtful concise answers.

del.icio.us | digg | Submit to Slashdot

Why PCI DSS is in a continued state of fail

Data breaches abound, half a million sites fall to SQL injection in 2008…the headlines are horrific and leave me to wonder.
Where does the PCI DSS fit in all this, if at all?
According to the WHID report about the rampant SQL injections, 11% of the sites were finance oriented and another 11% were retailers. According to my mad math skillz, that indicates that it is possible that 22% of 500,000 sites that fell to SQL injection attacks last year were beholden to PCI DSS. That’s 110,000 PCI sites that apparently failed to meet a very basic standard.
With my ear to the tracks for ongoing indiscretions, a delightful tidbit hit my radar, courtesy of a cheeky fellow in the UK named Michael Kemp of clappymonkey, who, whilst recently bored, was exploring the PCI Security Standards Council (PCI SSC) website, when lo, what did he find?
Yep…a lovely XSS vulnerability, in all places, the PCI QSA search script.



Mike indicates a swift fix on the part of PCI SSC on his blog, but I must say, this finding lends itself to some serious questions. I simply couldn’t let something this rare pass by unfettered.
1) Why isn’t the PCI SSC applying its own standard to itself? Fortunately, given no apparent forms oriented to taking payment card information on https://www.pcisecuritystandards.org, they’re not beholden to their own standard. But it would seem that a WAF or a review of site code per PCI DSS 1.2 Section 6.6 to prevent cross-site scripting as indicated in PCI DSS 1.2 Section 6.5.1 would be in order, yes?
2) Are we to believe, if PCI SSC doesn’t adhere to its own standard, that anyone else will, except during the annual audit? As there is little to no enforcement of PCI violations, it seems unlikely that PCI DSS will continue to be any more than a self-congratulatory security check list method with which enterprise can meet minimalist requirements once a year.

Allow me further the point.

CSRF falls under PCI DSS 1.2 Section 6.5.5. As part of my ongoing effort to cure the world of ailing web apps I recently disclosed a CSRF vuln in osCommerce. In discussing that vuln with Mike Bailey, he immediately found and disclosed a similar issue with Zen Cart. A couple of quick Google searches yield extraordinary numbers.
“powered by oscommerce” and “powered by zen cart” returned a combined 11,630,000 results!
Now let’s say for argument’s sake that just half of those results point to a legitimate site running the software (probably a low estimate) for a total of 5,815,000. Let’s further assume, because that both these vulns were disclosed recently, that a large majority of these sites are still running vulnerable code. How about half again? We can therefore surmise that 2,907,500 sites might currently be running code vulnerable to CSRF attacks. For our final assumption, how many of those sites are likely required to meets PCI DSS 1.2 standards. By my calculations…ALL OF THEM. You run osCommerce and Zen Cart to take online orders, paid for by credit cards.

So what then are we to say of PCI DSS in its current state of lax enforcement, double standards, and ill begotten data losses? I say, “For shame." PCI DSS could provide so much more, and offer better protection for the many, from the devious few. A standard is only as good as the extent to which it's enforced. The fact that the PCI SSC site didn't even meet its own standard indicates a significant credibility gap. It is my hope that they'll be reviewing their site regularly in the hopes of avoiding embarrassing and preventable flaws like this.

del.icio.us | digg | Submit to Slashdot

toolsmith article on Adito SSL VPN now available

My toolsmith column in the March 2009 issue of the ISSA Journal is a comprehensive discussion on Adito, an open source, browser-based SSL VPN that, in essence, replaces SSL-Explorer.
It's a fantastic offering that is now enjoying enhanced development support and offers many of the feature you'd expect from a commercial SSL VPN solution.
Check it out at your earliest convenience.
Cheers.

del.icio.us | digg | Submit to Slashdot

New version of Audit Viewer enhances latest Memoryze

More good news for malware analysts and security practitioners alike.
Straight from Peter Silberman, further details on the new version of Audit Viewer, inclusive of lots of significant changes.
The new Audit Viewer, should be used in conjunction with the newly released Memoryze-1.3 (which offers Vista support (beta), dll injection detection, enumeration of PE imports/exports in memory, F-Response support, and a slew of bug fixes.

Pictured below is a screen shot of the newest feature, Memoryze Launcher. You can now control Memoryze from a GUI. You have all the options you normally would, but you don’t have to edit any XML! The launcher supports multiple jobs. After your jobs run, any XML will be auto-loaded into Audit Viewer for seamless integration. If you specify a MemoryDD, then the image file be auto set to the text box so you can go from acquisition to analysis.



But wait, there’s more! A process with an injected dll will now appear in red text:



You can view the imports/exports of the injected dll in the Memory Sections view (the red entries indicate that memory sections that contains a PE file):



Right click on the section:


Two new handle types are supported, specifically “Sections”, and “Semaphores.”

There is now also integrated Snort signature support in Audit Viewer.
If you convert MindSniffer-generated Snort signatures to python files you can match signatures to strings in any process audit. Peter spoke about this technique at Blackhat Federal.

If you haven't yet downloaded Memoryze, Audit Viewer, and MindSniffer, all I can say is "What are you waiting for?!"

Thanks for the update, Peter.

del.icio.us | digg | Submit to Slashdot

#8 of the Top Vulnerability Discoverers of 2008

When, towards the end of 2008, I noticed the total count of vulnerabilities I'd disclosed and posted climbing past 50, I didn't imagine the effort would merit ending up as 8th on the list of Top Vulnerability Discoverers of 2008, as determined by Gunter Ollmann of the IBM ISS Frequency X Blog.
I am both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.
1) While I appreciate being on this list I must say that the caveat offered as part of Gunter's post is valid: "cross-site scripting vulnerabilities in a commercial shrink-wrapped application count for the same as a remote root vulnerability on a default Windows service."
My work has focused entirely on vulnerable web apps to date, and truly qualifies as low hanging fruit when compared to the findings of the likes of Luigi Auriemma. I am reminded of Wayne and Garth...I'm not worthy. My hat is off to Luigi, as it has been for quite awhile.
2) Gunter has, in the past, stated that he "wants companies to stop acknowledging an alias or pseudonym for any researcher that discloses a vulnerability - even if they came to you directly. “Use real names only,” he adds." Amen. The use of stupid, h@x0r nicknames lacks credibility and flies in the face of what I believe our core mission should be: find, advise, and promote repair of vulnerable software on behalf of users and consumers who may fall victim to its exploit. Disguising this mission in some self-perceived leetness-by-nomenclature denigrates the essence of this work. Courage, my friends...be true to yourselves and the cause.
3) Gunter has further indicated that he wants "software vendors to stop acknowledging companies and researchers who buy and sell security vulnerabilities." I must agree entirely here as well. I'd no sooner sell a vulnerability for profit than I would exploit it for personal gain.
4) Finally, the fact that, with relative easy, I discovered and reported what the Frequency X report indicates is 53 unique web application vulnerabilities in 2008 is really testament to what a sad state of affairs the development process is for so many of these vendors (not all, but many).
My plan for 2009, in addition to continuing this effort in earnest, is the promotion of the use of the Security Development Lifecycle (SDL). I believe that weaving the SDL mindset into software development is essential to preventing the flaws we vulnerability researches enjoy pointing out.
More to come, to be certain.
Cheers, and thank you, Gunter.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Chase away flawed broker browser code

In my ongoing pursuit of flawed online finance offerings, I took advantage of a quick Google search to isolate some opportunities.
site:chase.com -www
The second result caught my eye immediately as it:
1) should likely be disallowed via robots.txt.
2) utilized SSL, indicating a certain "value".
3) indicates broker web access and thus must be "important".
At first glance the SunGard Broker Browser looks very 1997, and a quick review of source code yields references to Front Page 3.0 and Visual Studio 6.0.



A closer look quickly produced an immediate cross-site scripting flaw right at the user_ID parameter.
Making use of the indispensable Tamper Data add-on, I invoked the key question. How much risk to consumer and brand confidence do poorly coded or ancient apps represent?



The results answered the question aptly. Enhanced phishing opportunities, PCI violations, potential SOX considerations, possible data breach implications...the list is long.



JPMorgan Chase was immediately responsive, quick to repair the issue, and offered this:
"We welcome reports of potential security vulnerability because they help us in the crucial role of protecting our customer information. We quickly follow up on any reports, assess the situation and determine what action needs to be taken."

An excellent response to be sure, and I applaud it.
That said, I'd like to pose a few more questions, and if answered, I will post them here as an update or approve the comment if submitted that way.
1) Is this really how brokers gain access to JPMorgan Chase resources?
2) If so, will you be updating the application to bring in into this century?
3) May I humbly suggest a wee bit o' security through obscurity? Something as follows should suffice:
# Bugger off
User-agent: *
Disallow: /
4) There are indications of this being a test system. If so, does it really need to be exposed to the Internet?

As news of endless data breaches, economic collapse, failing consumer confidence, and inherent Wall Street greed prevail, an online finance flaw like this leaves me at a bit of a loss.
If access for brokers is broken and could lead to data compromise, what are the implications?
Many, I think, particularly under the premise of the above mentioned news.
I've read a recent well written argument that we haven't fully grasped the potential impact. From Laura Wilson's
Facing the Information Security Hole in 2009:
The unacknowledged threat to our homeland and financial security, consider the following.
"It is now widely acknowledged by security experts from the federal government on down that the problem of data security breaches will get worse as the financial debacle worsens and companies cut spending and workers."

My point is this. I discover online finance flaws, I report them, they get fixed. That's great, but what about those that remain undiscovered and are far more critical than the less concerning than the cross-site scripting examples I use to make my point (and stay out of jail ;-))?

We are faced with uncertain times. Better security for web applications and systems serving as financial industry resources can help mitigate some of that uncertainty.

del.icio.us | digg | Submit to Slashdot

Mandiant Memoryze is the 2008 Toolsmith Tool of the Year

Updated: 2/6/09 See update below.

I'm a tool geek, no doubt. You can't write a column like toolsmith and not be one.
I've been mighty excited about a number I've things I've written about in the last year, including PHP IDS, NetworkMiner, and the tools from the Integrity Project.
As much as I enjoy (even love) every tool I write about, they become like family ;-), I have reached a decision.
Mandiant Memoryze is the 2008 Toolsmith Tool of the Year.
The February 2009 toolsmith article on Mandiant Memoryze is here.
Incident handlers and malware analysts rejoice: Memoryze is simply indispensable.
Food, water, air, love, Memoryze...really.
I use it at least three times a week in my virtual analysis sandboxes and I know I haven't realized its full potential.
Here's an example without full specifics as it stems from a work related investigation.
Imagine a scenario where you've been given malicious software to analyze. Said software was purchased from a nefarious and anonymous source based on its ability to wreak havoc, and your mission is to see if there's any way to find out who the actual author is.
Solution: run the malicious software in your VM sandbox, fire up Memoryze as follows:
memoryze.exe -o -script AllAudits.Batch.xml -encoding none
Be sure strings is enabled in AllAudits.Batch.xml like this:
param name="strings"
value xsi:type="xsd:boolean" true
It'll write a mass of junk to your output directory, but there's gold to be found in there.
I scrubbed through the strings output from the malicious process under the assumption that maybe the wanker who developed it left something useful behind (they often do).
Sure enough, Visual Studio attributes and reference to his home (including his user name) directory on his Vista installation showed up in the memory extract.
I combined those findings with some trace identification elements from automated email received during the purchase to pull together the developers full name.

Put simply, as malware anaysis tools go, and incident handling tools for that matter, this is a must for your tool kit.

Keep an eye on the Mandiant blog and Peter Silberman's work and presentations, He wrote the above mentioned AllAudits.Batch.xml and discussed it on OpenRCE.

Update 2/6/09
Principal developer Jamie Butler will be teaching how to write your own memory analysis tool or at least know the right questions to ask before you buy one at Black Hat DC February 16-17 and will also be speaking with Peter at RSA in April about memory analysis and malware reversing.
Expect a new version of Audit Viewer to release in concert with their presentations at Black Hat DC.

Get to know Mandiant Memoryze, you will not be disappointed.

del.icio.us | digg | Submit to Slashdot

Moving holisticinfosec.org to a new hosting provider

Update 2/4/09: Holisticinfosec.org is up again, stable and comfortable in its new home.

A quick update regarding holisticinfosec.org.
I'm switching hosts from a nightmare situation to one I am hoping will bring the stability and security we all should be able to expect from a provider.
Stay tuned and thank you for your patience.
This blog will be unaffected by the process.
Russ