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

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

Adeona Article in Linux Magazine

I'm pleased to announce that an article I've written regarding the open source laptop tracking and recovery offering Adeona is available in Issue 100 (March 2009) of Linux Magazine.

Adeona is the private, reliable, open source system for tracking the location of your lost or stolen laptop. With no dependency on a proprietary, central service, Adeona only needs to be installed on your laptop to help increase your sense of mobile device safekeeping.



del.icio.us | digg | Submit to Slashdot

PHPIDS: Attack Me, Please!

Of the many projects I've had the pleasure of reviewing for toolsmith over the past few years, one of my absolute favorites is PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application.
The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to.
More specifically, PHPIDS enables you to see who is attacking your site and how, and all without the tedious trawling of logfiles or searching hacker forums for your domain.
PHPIDS is subject to minor releases every few months, and the release of 0.5.4 (the last minor release before 0.6) just before Christmas reminded me to invite you, dear reader, to kick the crap out of it.
Give it all you've got, beat on it. Really. That's the idea.
The PHPIDS Demo Smoketest will test how 1337 your mad web app testing skills are and give you a grade for overall impact, just like in school...the school of XSS, the school of leetness, the interlocutor of insertion.
So enjoy, and see what you've got in the way of evasive techniques and pwnage prowess.
I can see it now...I pass and receive an overall impact rating of 54. "Wow!", I say. "That's got to be as good as something Gareth Heyes might utilize to circumvent the centrifuge!"
To which David Ross says "Hah! I know Gareth Heyes, and you sir, are no Gareth Heyes!"
*sigh* I feel so inadequate. Life as a white hat script kiddie is teh sux0r.

Enjoy. ;-)
http://attackmeplease.holisticinfosec.org/
Should you wish to read my article on PHPIDS, from the July 2008 ISSA Journal, it's here.

Most importantly: PHP web app developers and site operators one and all: give PHPIDS a close look and consider utilizing it to improve your offering's security. I promise you, you'll quickly learn where your code passes muster and where it doesn't.

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

Online finance flaw: Merrill Lynch not bullish on XSS & CSRF vulnerabilies

Updated: 1/16/09 See update below.

Perhaps, now that they're a Bank of America property, better web site security is in store for Merrill Lynch. In the meantime...here's where the trouble begins.
Prompted by headlines from December 21st stating that $1.6B Of Bank Bailout Went To Execs, I thought I'd take a look at the most egregious amongst those receiving a bailout courtesy of taxpayers.
I'd also like to explore what web app vulns mean to Sarbanes-Oxley (SOX) compliance; I've posed some questions below.

Here's all you really need to know:
John A. Thain, chief executive officer of Merrill Lynch, topped all corporate bank bosses with $83 million in earnings last year. Thain, a former chief operating officer for Goldman Sachs, took the reins of the company in December 2007, avoiding the blame for a year in which Merrill lost $7.8 billion. Since he began work late in the year, he earned $57,692 in salary, a $15 million signing bonus and an additional $68 million in stock options.
Like Goldman, Merrill Lynch received $10 billion from taxpayers on Oct. 28.

Too bad Merrill Lynch didn't spend just a wee small percentage of excessive salaries focusing on improving web application security on behalf of the customers paying for the extravagant lifestyles of their top execs.
But, that said, enough frustrated social commentary.

The Merrill Lynch OnLine Login page is vulnerable to cross-site scripting (XSS) and cross-site request forgery (CSRF), leaving customers at risk for financial compromise via phishing or credential theft.

As always, I followed my terms of engagement, sending no less than three emails over a period of no less than two weeks, even allowing a couple of extra days for the holidays.
To date I have not received a single response, automated or otherwise.

The point is best driven home via video, but the details are simple enough.
A properly formed IFRAME fits neatly, front and center, on Merrill Lynch's OnLine login, embedding Morgan Stanley's ClientServ login page, just to prove the point.

Merrill Lynch OnLine before:



Merrill Lynch OnLine after:



Web application vulnerabilities and SOX compliance

It's obvious that vulnerabilities such as that described above indicate a clear break from PCI compliance.
But what about SOX? HP (formerly SPI Dynamics) offers an interesting perspective in an effort to promote product:
Sarbanes-Oxley Act compliance can be difficult because it was not written specifically with information technology or information security in mind; however, there are various sections within the act that directly affect these functions in today’s corporations. This includes how information is accessed, what leaves the corporate network and what information needs to be protected and retained over time. You should conduct web application security assessments for an initial SOX compliance risk assessment to understand your various internal controls.
Such a web application security assessment would certainly require that a company like Merrill Lynch "validate that web application inputs are properly validated and not vulnerable to command injection or cross-site scripting attacks."
If SOX Section 404: Assessment of internal control indicates that an enterprise must "evaluate controls designed to prevent or detect fraud", shouldn't web application vulnerabilities that lend greatly to phishing or credential theft (fraud to be sure) fall under established controls?
So, my compliance an auditor friends, who wants to take this one on?
Comments welcome.

Can a failed enterprise like Merrill Lynch, who received $10 billion in bailout funds, and compensated a top exec in extraordinary fashion, be called in to question with regard to SOX compliance for issues as described above?
I'm not certain, but it seems worthy of consideration and debate.
I look forward to your feedback.

Update 1/16/09
The Merrill Lynch security team has responded in force and has conveyed that they "take security very seriously and now that we know about this are acting quickly."
As of 1/16/09 Merrill Lynch has indicated that the necessary fixes have been applied to their production environment.
They've also asked that, should anyone discover issues in the future, that they report them to abuse at ml.com.

del.icio.us | digg | Submit to Slashdot

Adito: open source, browser-based SSL VPN replaces SSL-Explorer

Update 2/6/09:
The March 2009 issue of toolsmith in the ISSA Journal will feature a complete review of Adito, including installation and usage. Expect the article to go live around 3/1/09.

In February 2006 I discussed SSL-Explorer, a project that is no longer supported.
It does however have new life in a project called Adito.
Much as SSL-Explorer was described, Adito is an open-source, browser-based SSL VPN solution. It's a remote access solution that provides users and businesses alike with a means of securely accessing network resources from outside the network perimeter using only a standard web browser.

Further:
Adito was forked from SSL-Explorer 1.0.0-rc17 for several reasons:
- To keep the already robust and functional open source codebase from decaying
- To reform SSL-Explorer (now Adito) from one company's product and a brand into a true community project
- To add new, exciting functionality
- To integrate existing functionality (e.g. sslexplorer-pam) into the program without the need to maintain it out of the source tree

This project shows updates as recently as December 19, 2008, and is in need of a developer so I'm hopeful maintenance and project enhancement will continue in earnest.
Give Adito a good look and let me know what you think; I may cover it in toolsmith.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: Visa responds quickly to reported vulnerabilities

The American Express online flaw I discussed last week led to two interesting sidebars.
First, a rather strong media response resulted with coverage in The Register, BetaNews, and Dark Reading, amongst others.
Second, aside from all the variant hunters, I received a number of interesting finds from friend-of-the-cause Mike Bailey over at skeptikal.org.
He'd been inspired by the fact that the PoC I issued for the AmEx bug included an IFRAME insertion pointing to Visa.com. Inspiration led to discovery (and whole lot less work for me) and immediate issues were noted in a few Visa sites.
To be fair, http://usa.visa.com itself appears to be sound; both Mike and I gave it a cursory glance and nothing popped up (XSS pun).
The same could not be said for http://empresarial.visa.com.
No need to rehash all the problems XSS issues in major credit card company sites might cause (PCI compliance, phishing, customer abuse, etc.); earlier posts speak for themselves.
As always, I reported the vulns per my terms of engagement.
Here's where the rather unexpected occurred.
I first reported the issues on December 17th at 1322 hours PST.
They were fixed no later than December 18th at 1916 hours PST.
In essence, Visa executed a 24 hour turn around for mitigation and repair.
Now, I have no doubt variant hunters will likely go digging about for other vulnerabilities, and if Visa hasn't issued global repairs, they might find some.
But, what's key here is how quickly Visa responded. I must admit, after the debacle born of the AmEx issue, I wondered if I'd be asked to report the vulns through Visa's PR department, a method recommended by AmEx to report vulns to them. ;-)
Not only was my disclosure responded to in a very timely fashion, I received the following feedback:
"We appreciate you bringing this situation to our attention. Visa takes security matters very seriously. All impacted pages have been taken down while we remediate the XSS coding. As always, feel free to report any future abuses to: abuse@visa.com."
Hard to argue with that.
My impression (unsubstantiated) is that the vulnerable sites were the product of a 3rd party development team, serving Spanish speaking customers, given the fact that the vulnerable code was PHP, not typical of English language Visa properties.
For posterity's sake one of the vulns appeared as follows. There were other similar issues with different variables, different sub-domains, and partner sites, but you get the point.

XSS in empresarial.visa.com/por/glossario.php:



I'd like to issue a "well done" to Visa and those who responded so quickly.
I can only hope that pending disclosures to all the other credit card vendors, banks, and brokerages in the Online Finance Flaws pipeline are handled as quickly and openly.
Thanks again to Mike Bailey (mckt) for his contributions to the cause. You'll see more of his work in future posts.

del.icio.us | digg | Submit to Slashdot

So...you can hack a server with XSS?

It's been awhile since I've updated you, dear reader, regarding matters concerning McAfee Secure.
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.

Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.

Russ,

As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.

In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.

The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.

First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.

It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.

Best Regards,
--
Joseph Pierini | CISSP, CISM

Best regards indeed. Thank you, Joe.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: American Express XSS

Updated again 12/19/08 (see end of post)

Our third entrant in the Online Finance Flaws series is one that truly perturbs me.
American Express came to my attention when setting up an online access account I was prompted to REDUCE the amount of characters in my password to eight or less. What?!
Luckily, my partner in alerting you to the absurd, Rafal Los, covered this issue nicely in May.
Of course, prompted by my irritation, I challenged myself to see what other truly inane security "features" American Express might be offering.
Here's where the trouble begins.
I kid you not, thirty seconds later, I found a new cross-site scripting (XSS) vulnerability right off the American Express primary search script (not one of three already posted on XSSed.com).
Three minutes later , in the TMI department, I discovered a most informative 500 error page exception indicating that American Express uses the Vignette CMS product via Apache and IBM's WebSphere.
Before I validate these findings please allow me to point you to the American Express data security page.
Key language includes:
"American Express is proud to be a founding member of the PCI Security Standards Council. The Council is designed to manage the ongoing evolution of the PCI Data Security Standard and to foster its broad adoption industry-wide. Through our participation with the Council, American Express continues our commitment to diligently pursue all aspects of data security."
Let me spell this out for you.
A founding member of the PCI Security Standards Council is itself in violation of PCI DSS 6.5.4.
This does little for my faith in American Express "data security", or the PCI Security Standards Council for that matter.
Finally, as always, I followed my terms of engagement in reporting these findings to American Express and was ignored by everyone including a director in their information security organization.

A video of both issues is here.

Should you prefer screen shots...an American Express XSS cookie grab:



Or the phishing warning:



Finally, my favorite, an IFRAME insertion of the VISA web site. Oops!



Oh yes, the 500 error, if you're still with me:



Is it wrong of me to expect more of credit card companies with claims to founding the PCI Security Standards Council? I think not.

Please contact American Express and register your own complaint. This is simply unacceptable.

Update 1100 hours 12/17/08:
American Express has made repairs regarding the XSS vulnerability, and has replied to Dan at The Register.
Additionally, this Computerworld article is just too silly and timely to not share in the context of our discussion. May the irony amuse you as much as it did me.

Update 2015 hours 12/19/08:
Repairs as indicated 12/17 now proven to be "repair" as variants galore arise.
Dan G. at The Register exposes research from at least two sources proving once again that one-off repairs are worthless when compared to a global approach.
Makes me wonder what this means for AmEx's stock.
Well done, fellow researchers. Well done.

del.icio.us | digg | Submit to Slashdot

Online finance flaw: U.S. Bank & National City Bank XSS and more

Updated 12/24/08 (see end of post)

In this, our second entry in the series Online Finance Flaws, I call to your attention a report from Javelin Strategy & Research, the Banking Identity Safety Scorecard.
According to the MarketWatch writeup on the report, it "measures 25 leading U.S. financial institutions' customer-facing identity fraud capabilities. The Javelin model measures Prevention, Detection and Resolution(TM) features to track performance throughout the fraud cycle."
While I don't have the $1500 handy to purchase rights to read the complete report, it appears to be a comprehensive, well intended, ongoing effort.
Key questions asked by Javelin include:
1) Which financial institutions rank highest against Javelin’s customer-facing Prevention, Detection and Resolution™ criteria?
2) What type of account protection capabilities should banks and credit unions implement now to increase customer safety through Prevention, Detection and Resolution™?
3) Which customer safety features will most differentiate financial institutions in the future?
In answer to #1, the report lists its Top 5 indicating that Bank of America once again earned top overall honors, demonstrating excellence in its efforts to partner with customers against a crime that uniquely targets both the financial institution and the consumer. National City Bank (acquired by PNC) and Wells Fargo shared second position with equivalent scores followed closely by US Bank and Wachovia.
I'll answer #2 & #3 below.
I'll ask some further questions first, however.
Do we agree that web application security should and does play a critical role in what Javelin refers to as Prevention, Detection and Resolution™?
Do we agree that cross-site scripting (XSS), cross-site request forgery (CSRF), information disclosure, and SQL injection (SQLi) are all flaws that should not exist in a bank site on Javelin's Top 5?
Do we agree that XSS issues make for golden phishing opportunities for the inherently malicious, and again, should not exist in bank sites on Javelin's Top 5 with regard to a Banking Identity Safety Scorecard?
Before I discuss the flaws, be aware that I followed my terms of engagement with both of the following banks, and was largely ignored with either no reply or very vague, inconclusive brush-offs.
It is my hope that you, dear reader, will contact the following institutions, as I have, on behalf of the consumers they are obligated to protect, in the hope that they will make timely repairs.
And here, as I am prone to saying, is where the trouble begins.

U.S. Bank is vulnerable to XSS at their logon page.

National City Bank is vulnerable to XSS and information disclosure, as well as potential CSRF and potential SQLi, in a Cold Fusion (gasp!) app that runs a subdomain; specifically insights.nationalcity.com.

While the potential National City Bank vulns don't necessarily give a malicious attacker a ton to work with, given that it's an isolated app running a subdomain, the XSS issue is still useful in obvious ways.
I am particularly saddened by the XSS issue on the U.S. Bank site given the history of exploitation of just opportunities. See what I call the Italian Bank Job, and the article I wrote, Anatomy of an XSS Attack, inspired by the Italian caper.



Note that, as indicated in the Netcraft article on the Italian bank issue, SSL "security" is a moot point. Any script execution in the context of the U.S. Bank site occurs "protected" by SSL. As Netcraft says, "any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine."

The National City Bank issues appear as follows.

XSS:


Information disclosure and potential SQLi both appear in the grossly verbose, overly helpful Cold Fusion error:


As a technical evangelist for online consumer well-being, and an information security practitioner, I'm here to tell you: these vulnerablities are indicative of behavior unbecoming of secure online banking; particularly as applied to two of the five "top-ranked banks who partner with customers to protect against identity fraud."

To answer #2 and #3 from above: build secure web applications.

U.S. Bank and National City Bank, I ask you to resolve these issues soon, on behalf of customers in your care.

Update 12/24/08:
U.S. Bank has notified me that they've repaired the vulnerable login code. Additionally, they've asked that I remove the video PoC, a request I choose to honor in deference to their open communication during the remediation period.

I've heard nothing from National City Bank. That said, while the initially reported issues appear to have been resolved, the resulting error message is still sloppy and overly informative (typical of Cold Fusion left unchecked).

del.icio.us | digg | Submit to Slashdot

Online Finance Flaw: TIAA-CREF XSS & Potential CSRF

Update 12/4/08: TIAA-CREF has made appropriate repairs, and is no longer vulnerable to common XSS in the search.jsp script. I applaud their responsiveness.

Before discussing a TIAA-CREF security flaw, allow me to clarify my "terms of engagement".
Prior to offering analysis of any security flaws in online financial services, be assured I have engaged the service provider and offered what I believe to a reasonable amount of time to remedy this issue. Specifically, a minimum of two weeks and three unique contact attempts are made. Should the vendor offer a timeline in which the issue will be resolved, so long as it is not months or years, I will wait until they are ready to deploy the fix, then discuss the vulnerability. If I am not in receipt of a reply other than generic customer service replies, I will follow the two week standard, then discuss the issue.

TIAA-CREF, or the Teachers Insurance and Annuity Association - College Retirement Equities Fund, is a respected, widely utilized provider of numerous financial products and services. The TIAA-CREF site is ranked 26,148 on Alexa.com at the time of this writing.

I'll first direct you to the TIAA-CREF Security page, where they discuss the expected elements like identity theft, spoofing, tips, and my favorite, phishing.
Here's where the trouble begins. Obviously, most phishing occurs when some miscreant creates a fake page and attempts to lure victims via email.
The severity of phishing risks are greatly increased by the introduction of a cross-site scripting (XSS) vulnerability in a site that is of high value to phishing attackers.
With such a vulnerability available, the prospect of success for a phisher are much higher given that the malicious URL they would craft could include the actual target domain, rather than a faked misrepresentation. A simple script insertion at the vulnerable variable would then allow the attacker to redirect victims to a maliciously crafted logon page in the context of the vulnerable site.
Sad side note: when you search security at the TIAA-CREF site, the above mentioned Security page is not returned in the results as I write this.
However, the resulting search URL serves as the starting point for our discussion of the flaw:
http://www.tiaa-cref.org/explore/portlets/search.jsp?query=security&strtfrm=1&totpresults=75&srchtype=4&sc=1&frmsite=0
The vast majority of non-search input variables on the TIAA-CREF site offer reasonable XSS protections, likely a blacklist method that redirects you to the following language when common XSS strings are noted, particularly where it counts at logon pages.
Due to the presence of characters known to be used in Cross Site Scripting attacks, access is forbidden. This web site does not allow Urls which might include embedded HTML tags.
Unfortunately, this methodology was not deployed globally, and thus the following online finance flaw.
All input variables used in TIAA-CREF's search.jsp script are vulnerable to XSS.
Utilized by an attacker, this could have a much more significant impact on TIAA-CREF customers who fall victim to a now more convincing social engineering effort.
Here's the site before script insertion:



Here's the site after script insertion:



Further, certain parts of the site, including the Trust Company logon page, show potential signs of cross-site request forgery (CSRF) in that they accept updates via GET or allow submittal with the referrer stripped.

Lessons learned:
1) Don't assume all is well even though a site may offer examples of how attentive they are to security.
2) Never log on to an online financial service offering (or anything else for that matter) via a link sent to you in an email. Period.
3) Take all steps at your disposal to ensure you are logging in to and transacting with the actual site you intended to utilize. Don't depend on security badges and SSL certificates as your sole means of confirmation.
4) If you note something of concern at a site you utilize, advise them immediately and demand repair or clarification until you're satisfied.

Please feel free to send feedback to TIAA-CREF as I have per my "terms of engagement" above. Hopefully they'll resolve this issue soon, on behalf of customers in their care.

Up next in our series, two of the top five banks mentioned in Javelin Strategy & Research's Banking Identity Safety Scorecard are vulnerable to similar issues.

del.icio.us | digg | Submit to Slashdot

Actns/Swif.T virus found in YouTube videos

TOOLS FOR FLASH ANALYSIS

Update 13:35 PDT: False positive finding from CA triggering on System.security.allowDomain("*").
Regardless, these two sites are indispensable for their quick analytic capability.
Seeing System.security.allowDomain("*") as problematic in not necessarily wrong as it often indicates malicious content.

Breaking news regarding malicious Flash popping up from YouTube is starting to break all over the Internet.
CrunchGear has a bit of a write-up on it.
Rather than sound off about what will become old news quickly, I'd like to point you to resources I use to analyze (or have the analysis done for me, to be more concise) malicious Flash or JavaScript.
I grabbed the evil .swf in question from the URL below via command-line on my trusty Ubuntu box:
wget hxxp://www.youtube.com/v/O7tB1pYSNuE&rel=1
I then fed l.swf to Adops Tools and Wepawet.
The results from each analysis are below for your review.
Note System.security.allowDomain("*").
Not good. ;-)
Adops Tools Results
Wepawet Results
Use in good faith, but always be careful grabbing the evil .swf.

del.icio.us | digg | Submit to Slashdot

Safe Keeping: Article on TrueCrypt in Information Security

My article, Safe Keeping, regarding TrueCrypt, is now available in Information Security magazine.
TrueCrypt is an open source laptop encryption alternative for your organization.
This article also includes a sidebar on Adeona, an open source system for tracking the location of your lost or stolen laptop that does not rely on a proprietary, central service.

I humbly suggest that you consider using both should you lack commercial solutions.
Cheers.

del.icio.us | digg | Submit to Slashdot