Using OSSEC to monitor ModSecurity and Wordpress

As the October ISSA Journal begins to make the rounds, readers will note OSSEC as the topic of my toolsmith column.
The topic was chosen by Doug Burks of Security Onion as part of the Pick a Toolsmith Topic contest (we'll do it again).
As a result Doug won Zero Day Threat: The Shocking Truth of How Banks and Credit Bureaus Help Cyber Crooks Steal Your Money and Identity. Thanks again, Doug.
The article is available for all readers here.

While I discussed OSSEC as it pertains to Snort logs, PCI compliance, application (misuse) monitoring and auditing, as well as malware behavioral analysis, I spent very little time discussing the use of OSSEC with ModSecurity or Wordpress.
So here's where I magically tie it all together. ;-)
Given the title of the book Doug won, what's one way we might help prevent cyber crooks from stealing our money and identity?
Monitor our web applications, of course! With OSSEC. See how I did that?

OSSEC and mod_security

As an example, on an Ubuntu server running Apache generating mod_security audit logs, include the following in ossec.conf (var/ossec/etc):



OSSEC will then alert on mod_security events.
You'll need to tune and filter; you may receive quite a few alerts, but once optimized the results will be quite useful.



OSSEC and Wordpress

Using OSSEC HIDS with Wordpress is already nicely documented.

Highlights from OSSEC pages:
WPsyslog2 is a global log plugin for Wordpress that keeps track of all system events and writes them to syslog. It tracks events such as new posts, new profiles, new users, failed logins, logins, logouts, etc.
It also tracks the latest vulnerabilities and alerts if any of them are triggered, becoming very useful when integrated with a log analysis tool, such as OSSEC HIDS.



No matter what you wish to monitor, even if it's simple server well being, you'll find OSSEC indispensable. Making use of it as part of your web application security arsenal is a giant step in the right direction.

Feedback welcome, as always, via comments or email.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

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

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

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

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

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

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

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: 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

Hype Alert: Internet Shopping Carts Are Secure

My blog reader fed me a nugget today that set off my hype monitor, specifically a post entitled Internet Shopping Carts are Secure.
OMG...really?
To be fair, I realize the author is speaking from the eCommerce perspective, rather than that of an information security practitioner, but here's where the trouble begins:
"Shopping cart service providers have developed secure ecommerce shopping cart solutions for any business owner looking to enhance their current online store, or create a new one. Some ecommerce shopping cart solution providers are even receiving PABP (Payment Application Best Practice) certification which supports PCI compliance requirements for all businesses accepting credit card payments online."
This may be true in part, but it is by no means an all-inclusive claim. Shopping carts continue to be sieve-like, even when apparently reviewed per PCI standards.
Allow me to elaborate.
We'll kick off our hype eliminating effort with a simple Google dork: inurl:"cart.cfm" (picking on ColdFusion again, but man, they make it easy)
GM Parts Direct: Your Shopping Cart jumped right out at me for a number of reasons.
First, I sensed XSS vulns lurking like a Geiger counter senses radiation. Sound effect for edification. :-)
Second, the page contained one of the growing number of aforementioned conversion-driving website security seals.



Tick, tick, click...the Gieger counter is getting louder.
Trustwave claims that the site operator "is enrolled in Trustwave's Trusted Commerce™ program to validate compliance with the Payment Card Industry Data Security Standard (PCI DSS) mandated by all the major credit card associations including: American Express, Diners Club, Discover, JCB, MasterCard Worldwide, Visa, Inc. and Visa Europe."
Methinks that Trustwave's Trusted Commerce program is missing a few fundamental security checks. Remember, XSS in PCI regulated sites, according to the PCI DSS, indicates that a site is not compliant (see section 6.5.4) if vulnerable to XSS.
Uh-oh.

All it takes is a fake login page, as opposed to our friends at XSSED.com, and...well, you get the point.
Simply, this is one of an endless number of shopping cart not secure, and not PCI compliant. For shame. You need only browse the Holisticinfosec.org Advisories page to find multiple ecommerce platforms and shopping carts that are missing the mark. Trust me, these are a fraction of the problem.
ecommerce<>security
ecommerce<>SDL
ecommerce<>PCI
website security seal<>security
russ=frustrated
Sigh.

del.icio.us | digg

XSS Comedy at McAfee Secure's Expense

In celebration of the deadline for PCI Requirement 6.6 compliance as of June 30, 2008, I thought I'd share a little web app sec comedy at McAfee Secure's expense.
As well you should know by know, the existence of XSS vulnerabilities in a site that is required to meet PCI DSS standards means that the site IS NOT PCI COMPLIANT. Very simple, right?
Let's consider the McAfee Secure/Hacker Safe-branded site for Organize-It.
A seemingly handy site, perfect for your HGTV types, likely with healthy credit card limits. Uh-oh, here it comes. Oh yes, Organize-It handles credit cards and is thus beholden to PCI DSS.
Organize-It is also proudly displaying a current McAfee Secure badge, indicating that it's tested daily.
Given the focus of many a recent discussion it shouldn't shock you that Organize-It is vulnerable to XSS.
What's funny is what Organize-It does with regard to "handling" malformed requests.
Where a typical test string for XSS might be " script payload /script (characters removed or Blogger will let me XSS myself), you won't get much use from such a string via either direct form submittal or URL encoding. But when the site barfed up '; // LEAVE THIS VALUE var sli_cId = 90;, while under investigation, my ruh-roh meter went off.
I decided to play with my trusty marquee test and found interesting results. The actual search form field is limited to 41 characters (er?). So my complete string of " marquee message /marquee didn't fit for direct submittal BUT THE MARQUEE RENDERED ANYWAY! Basically, half the test string worked: " marquee h1 This_site_is_NOT_McAfee_S
Forget the marquee tag on the blacklist, did we?
But here's the real icing on the cake. The uber-intuitive search index reinterpreted my message with what I can only imagine are index keywords. Thus "This site is NOT McAfee Secure" scrolls across the Organize-It site as "this sit is not coffee secure".
OMG! My daily quad shot Americano has been pwn3d to the core!
Here's the URL if you don't believe me, or the video if you prefer.
Forget PCI compliance, bring on the Gong Show hook, Chuck!
Cheers.

del.icio.us | digg

Why PCI DSS is doomed.

Too much fun in the news to pass up on today.
First, the press release from McAfee indicating the obvious re-branding of McAfee Hacker Safe to McAfee Secure for Web Sites. Oh yes, dear friends, McAfee delivers the secure internet. The profound and deeply flawed arrogance continues, with a new name.
Rafal Los has already torn into this one, so I'll let you get the goods there, but after reading further I saw this gem:

Yep, full steam ahead. Now your credit cards are really going to be safe.


As you may know the previously vague PCI DSS 6.6 language has been made even more elusive with such useful language as:
"Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats."
Such strong assertions: possible, may, could. We wouldn't want to actually commit, would we?
As if all of this wasn't enough, along comes the PCI mastery of the PCI Blog - Compliance Demystified, from pcianswers.com.
You'll get a 404 now, but here's the cached page.
Yep, a QSA actually debating the merits of ScanlessPCI.
"From what we can ascertain, ScanlessPCI.com is just a scam."
Really? We weren't sure.
"The larger concern is the fact that they require you to insert code into your Web site to get a copy of their certificate. Since you are inserting code into your Web page for a GIF, it is anyone’s guess as to whether or not they are hacking your site at the same time they are supposedly protecting it."
Oh, scary. Common, guys. I think you should insert this picture on your website. Then your customers can feel truly confident in your services. Man, my ribs still hurt from laughing.


del.icio.us | digg

Still not Hacker Safe, roll the video

Accuse me of beating a dead horse, but this really ticks me off. While preparing content for my monthly column, as well as presentation content for the ISSA NW Regional Security Conference, I found yet another bunch of McAfee Hacker Safe branded sites that are completely vulnerable to cross-site scripting (XSS), as well as other issues. The video I took points out only reflected, non-persistent vulnerabilities...no sites were harmed in the making of the video, and all sites have been advised. Nonetheless, let me make my point yet one more time.
1) Sites that are vulnerable to XSS are not PCI compliant. All of the sites in this video take CC payments and store customer information.
2) The sites in this video have been vulnerable for months. Additionally, some have been advised multiple times and have simply ignored my notices. Their McAfee Hacker Safe branding is active and has not been removed at any time.
3) The McAfee Hacker Safe service claims XSS as part of its vulnerability checks; sites that are vulnerable to it should not be showing the McAfee Hacker Safe label in perpetuity.
THEY ARE NOT HACKER SAFE AND CONSUMERS ARE AT RISK.
Please join me in protest by adding a comment to my open letter to Ken Leonard, CEO of Scan Alert. Send them email, ask the sites to fix the issues.
Unknowing consumers deserve far more than false claims of security and empty assurances designed to grow McAfee/ScanAlert revenues.
As I am not the only person greatly concerned over this issue, please visit Rafal Los' fine blog for additional findings.
Enjoy the video.

del.icio.us | digg

Scan Alert's Hacker Safe now obsolete

The industry has spoken, and McAfee Hacker Safe branding is now obsolete! Everyone can be PCI certified at no cost, with no effort. It's as easy as this:

PCI Certified by Scanless PCI

Now everyone can take credit cards to the satisfaction of PCI DSS.
I'm so excited! Thanks to Jeremiah for pointing out scanlesspci.com.
Internet commerce is now safe for everyone. Priceless.
del.icio.us | digg

An Open Letter to Ken Leonard, CEO, ScanAlert

Dear Mr. Leonard,

As well you are aware; the Hacker Safe brand has long been viewed by those in the information security field with varying levels of skepticism, if not vehement disdain. As there are a plethora of blogs, articles, and exposed vulnerabilities available for you to review, I will not waste your time with excerpts validating our position. Suffice it say, the community at large shares certain doubt about the service offering ScanAlert arrogantly calls Hacker Safe.
It is our view that this is a marketing position only. Nothing, I repeat, nothing, is truly "hacker safe". You claim that websites are free of vulnerabilities when they are clearly not. This is disingenuous and is at the root of what angers information security professionals. If a site is vulnerable while under the auspicious care of ScanAlert's Hacker Safe program should it not lose its Hacker Safe credential until such a time as the vulnerability is remediated? If I take this down to a fundamentally simple premise, saying a site is Hacker Safe while vulnerable to SQL injection, XSS, CSRF, etc. is, in essence, a misrepresentation. If a consumer commits a transaction on a site that is vulnerable, are they not at risk due to vulnerabilities your service claims to scan for? While we understand that you are in the business of growing revenue by indicating websites as “hacker safe”, we believe you are also beholden to the consumers using those sites.
We ask of you this: if a site is found to be vulnerable during your scans, or as reported by third parties, then enforce the findings and suspend their certification. Strive to improve your scan engine where possible. It is your responsibility to NOT label a site “Hacker Safe” when it is not. Then, at least, you are telling the truth, and a consumer can make an informed choice as to how confident they feel about the site's security practices.
There are, at the time of this writing, sites still vulnerable to XSS, yet branded Hacker Safe, that were identified as vulnerable MORE THAN A YEAR AGO. These sites should not be reported as Hacker Safe, period.
Please don't insult us with more of Joseph Pierini’s pearls of wisdom like “XSS vulnerabilities aren't material to a site's certification”. Adopting a view like this is ridiculous and blatantly ignorant given the risks to consumers. You scan for XSS and clearly denote it in your How We Scan section. Therefore, if a site is vulnerable to XSS it is not “Hacker Safe”.
This is far from the first round, credit sla.ckers.org with driving this point home in 2006, only to be shrugged off by Pierini then too. I think there may be a job opening for him over at Zango. Perhaps he could change his mantra from “XSS is not our problem” to “We don’t make spyware.”
What about the PCI argument? If a site is vulnerable to XSS, it’s simply not compliant. See this post for details. It all adds up to consumers at risk. ScanAlert should remember, above all, that safety for the consumer is paramount. Why not live up to your marketing hype and offer a service that truly, honestly, and with integrity, lives up to even a fraction of its namesake.
"What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so. - Mark Twain"

Sincerely,

Russ McRee

Those information security professionals wishing to lend your name to this plea, please add your name as a comment.

del.icio.us | digg

XSS and PCI: Not compliant, or Hacker Safe

As a follow up to the last post on sites vulnerable to XSS that are certified McAfee Hacker Safe, there is more to this story.
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks

So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?

del.icio.us | digg