AppRiver: SaaS security provider sets standard for rapid response

On July 28th I was happily catching up on my RSS feeds before getting ready to head of to Las Vegas for DEFCON when a Dark Reading headline caught my eye.
Tim Wilson's piece, After Years Of Struggle, SaaS Security Market Finally Catches Fire, drew me in for two reasons.
I'm a fan of certain SaaS Security products (SecureWorks), but I also like to pick on SaaS/cloud offerings for not shoring up their security as much as they should.
The second page of Tim's article described AppRiver, the "Messaging Experts" as one of some smaller service providers who have created a dizzying array of offerings to choose from.
That was more than enough impetus to go sniffing about, and sure enough, your basic, run-of-the-mill XSS vulnerabilities popped up almost immediately.

Before...


After...


Not likely an issue a SaaS security provider wants to leave unresolved, and here's where the story brightens up in an extraordinarily refreshing way.
If I tried, in my wildest imagination, I couldn't realize a better disclosure response than what follows as conducted by AppRiver AND SmarterTools.
Simply stunning.

Let me provide the exact time line for you:
1) July 28, 9:49pm: Received automated response from support at appriver.com after disclosing vulnerability via their online form.

2) July 28, 9:55pm: Received a human response from support team lead Nicky F. seeking more information "so we can look into this".
(SIX MINUTES AFTER MY DISCLOSURE)

3) July 28, 10:27pm: Received a phone call from Scott at AppRiver to make sure they clearly understand the issue for proper escalation.
(NOW SHAKING MY HEAD IN AMAZEMENT)

4) July 29, 6:35am: Received an email from Scottie, an AppRiver server engineer, seeking yet more details.

5) July 29, 8:51 & 8:59am: Received a voicemail and email from Scottie to let me know that one of the vulnerabilities I'd discovered was part of 3rd party (SmarterTools) code AppRiver was using to track support requests.
(MORE ON THIS IN A BIT)

6) July 29, 2:08pm: Received email from Steve M., AppRiver software architect, who stated that:
a) "We deployed anti-XSS code today as a fix and are using scanning tools and tests to analyze our other web applications to ensure nothing else has slipped through the cracks. We do employ secure coding practices in our development department and take these matters seriously. We appreciate your help and are going to use this as an opportunity to focus our development teams on the necessity and best practices of secure coding."
b) "Regarding XSS vulnerabilities you detected in the SmarterTrack application (the above mentioned 3rd party tracking app) from SmarterTools, one of our lead Engineers and myself called them this morning explaining the vulnerability and requesting an update to fix the problem. We also relayed to them that a security professional had discovered the vulnerability and would be contacting them to discuss it further."
(I AM NOW SPEECHLESS WATCHING APPRIVER HANDLE THIS DISCLOSURE)

NOTE: Less than 24 hours after my initial report, the vulnerabilities that AppRiver had direct ownership of were repaired.

7) July 29, 4:17pm: Received an email from Andrew W at SmarterTools (3rd party tracking app vendor) who stated "thank you for pointing this out to us... we will be releasing a build within the next week to resolve these issues."
(CLEARLY STATED INTENTIONS)

8) August 4, 8:02am: Received another email from Andrew W at SmarterTools who stated "we plan to release our next build tomrrow morning. (Wednesday GMT + 7) I will let you know as soon as it becomes available for download on our site."
(CLARIFYING EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

9) August 5, 9:37am: Received another email from Andrew W at SmarterTools stating that "a new version of SmarterTrack is now available via our website. (v 4.0.3504) This version includes a fix to the security issues you reported."
(DID EXACTLY WHAT THEY SAID THEY WERE GOING TO DO)

10) The resulting SmarterTools SmarterTrack vulnerability advisory was released yesterday on my Research pages: HIO-2009-0728

I must reiterate.
This is quite simply the new bar for response to vulnerability disclosures.
It is further amazing that such a process was followed by not one, but two vendors.
I am not a customer of either of these vendors but can clearly state this: if I required services offered by AppRiver and SmarterTools, I would sign up without hesitation.

AppRiver and SmarterTools, yours is the standard to be met by others. Should other vendors utilize even a modicum of your response and engagement process, the Internet at large would be a safer place.
Well done to you both.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

steekR security steenkS

My RSS reader continues to provide me subject matter for analysis, and the recent F-Secure purchase of steekR, “Your Secured Online Space”, was no exception.
The purchase was described by El Reg as follows:

F-Secure grabs online storage firm in cloud security push
Steek's technology is designed to allow users to upload data from either PCs or mobile phones. Bordeaux-based Steek already partners with mobile telcos (including Virgin Media, SFR in France and SingTel), a factor which F-Secure hopes will increase its ability to sell Software as a Service (SaaS) technology packages through operators.

Oh boy, here we go again.
I want to create a new line of Bobbleheads for Cloud and SaaS. They’ll talk as well, bobbling and blathering the latest buzz words:
“We’ll give you the best ROI in the cloud!”
“Our SaaS offering relieves you of any responsibility, we’ll do it all!”
I digress.
I understand the business model, and F-Secure’s motives for the purchase; it’s hard to find fault there.
But as I’ve indicated time and time again, when you purchase or integrate another vendor’s offerings, you immediately inherit their shortcomings as well.

I propose a blamestorming session. I’d like to start with steekR.
steekR suffers from persistent cross-site scripting (XSS) flaws.
They further suffer from a complete inability to respond to responsible disclosures (multiple attempts over two weeks).
Thus, I struggle with their “Your Secured Online Space” claim. As in…not so much.
Imagine this scenario:
1) An attacker creates a steekR account.
2) The attacker embeds malicious JavaScript.
3) The attacker then shares steekR content in a manner that exposes it to any victim who errantly clicks through.
4) You receive email notification of the share and given your use of steekR (you and 2,405,935 other customers), you click the URL.
5) Your browser is directed to a steekR share with a malware-laden IFRAME embedded.
6) You’re pwned.

I'll walk you through it.

Here's the email...


Here's the URL in the email (no, I'm not trying to pwn you):
http://www.steekr.com/n/50-2/share/LNK32784a66232b7baaf/
Click My Documents in the left pane and you'll see the IFRAME in the right pane when you mouse over the folder.

Here's the result when you click said URL...


That IFRAME could easily be something nasty.
Similar scenarios can easily lead to data breach, account compromise; pick your poison.
Lest you forget, persistent XSS issues are far uglier than their reflected kin.

Lesson for companies like F-Secure on the venture integration path:
Review the acquisitions security-related practices, or lack thereof, and conduct a thorough assessment of the product driving the decision to purchase them.

Lesson for users of SaaS offerings:
Assume no privacy, and no guarantee of security. A trusted resource may not be trustworthy.

Steek and you might stumble. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ColdFusion, SaaS, and negligence

Recent headlines have described news pertinent to ColdFusion-related vulnerabilities and hacks specifically targeting the FCKEditor text editing tool, and the CKFinder file management tool. There have been further indications of attackers uploading a ColdFusion web shell as often seen on vulnerable PHP platforms.

These discussions reminded me of two significant pet peeves.
1) ColdFusion error verbosity and how useful it is to attackers.
2) Negligent vendors who do absolutely nothing about security vulnerabilities they've been advised of; worse still, when the vendor is a SaaS provider.

Case in point: WebPublish CMS

I communicated with these folks at multiple intervals via email and telephone from February 20, 2009 until April 23, 2009. It took multiple efforts just to get through as my messages were manually interpreted as "potential SPAM". Trust me, my security advisory language does not trip SPAM filters and is most often easily and well received. Yet, after finally making a connection, I received the classic "we don't have the time and resources to address this issue any time soon." To which I replied with useful resources for mitigation and remediation. My last received communication stated "I will have a look and see if I can incorporate as much as I can." That was two and half months ago.
I think we can agree the tenets of responsible disclosure were followed, yes?
Thus, a seemingly capable, growing SaaS provider quite simply blew me off.

So be it. Here's my favorite example of something they should immediately fix: A cross-site scripting (XSS) vulnerability exhibited in the ColdFusion error page leading to significant information disclosure (ID) while indicating possible SQL injection (SQLi) vulnerabilities. Wow, really?

A screen shot complete with a wee bit 'o appsec humor courtesy of an IFRAME insertion:


Now take this absurdity to the next level.
As many a vendor is prone to doing, WebPublish CMS sites clearly state that "This site is powered by WebPublish".
How helpful.
Try intext:"powered by WebPublish" via Google.
Just a few results, yes?
We'll use a few for further analysis. What do they all have in common?
kellyprecision.ie
multiples.ie
netcommunications.ie
snapprinting.ie
webpublishcms.com
Yep, all the same IP, as in all on the same server.

Core application vulnerabilities in a primary service offering (SaaS) from one vendor, on one server, affecting hundreds if not thousands of clients.
See the problem?
Negligence, plain and simple.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

eWeek hypes "secure" SaaS without checking the facts

In an article called SaaS Proof Points, eWeek put on the blinders and jumped on the bandwagon declaring such SaaS wisdom as "not only have modern SAAS applications assuaged security concerns, but the SAAS model itself is seen by some as the most secure approach to handling data".
What!? Wow.
Add to that the well-intended declaration of SaaS neophyte Kimberly Rogers of Santander Consumer USA, while detailing her company's use of Service-now.com. Rogers, who had never worked with a SaaS-based application before, added that "security can be as tight as you want it to be." Noting such blind faith from a Service-now.com user I was motivated to take a closer look at the provider.
Kimberly, respectfully, you are making a dangerous assumption.
Putting on my bad guy hat for a second, if I can entice you to click a link in a targeted, specially crafted email (phishing), that in turn executes JavaScript in the context of Service-now.com (cross-site scripting) and returns the cookie you use for authentication to Service-now.com (credential theft), is it still reasonable to assume that "security can be as tight as you want it to be"?
I think not.
Service-now.com suffered from a cross-site scripting (XSS) vulnerability that allowed cookie theft and other XSS fun such as frame defacement.

Before XSS:


After XSS:


Please note that Service-now.com responded to my advisory and made repairs in a reasonable amount of time, all the while communicating admirably.
That said, if SaaS providers don't ratchet down hard on their basic web application security, silly yet valuable data spills such as described above will continue to prevail unabated.
If trade publications continue to publish hype rather than balanced facts I must assume that data breaches and provider shortcomings will continue to be commonplace as said providers won't be held to a higher standard.

When StrongWebmail fell so readily to an XSS vulnerability this past week (well done Lance, Mike, and Aviv), I simply shook my head in dismay. Are service providers so blind as to not consider the holistic security view before putting 10k on the line?
That was a rhetorical question.
Answer? Obviously.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Cloud security commentary falling down on the job

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

del.icio.us | digg | Submit to Slashdot

A follow-up on SaaS & cloud risk

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

Precisely.

del.icio.us | digg | Submit to Slashdot

asSaaSsinated: more on SaaS & cloud risk

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

VIDEO

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

del.icio.us | digg | Submit to Slashdot

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

SaaS Snake Oil Top Ten, with video

As I was happily sniffing about for more annoying vendor fodder a few nights ago, I found a true gem. I was actually investigating ControlScan's practices and came across some poor hapless site owner that had been manipulated into buying both the ControlScan service and McAfee Secure / Hacker Safe by not one, but two snake oil salesmen.
This site was bound to be secure, right? Wrong!
Here's a new video to detail the inadequacies of both these services, at the same time.
But, as my disdain for these con artists grew yet stronger, it occurred to me (with the suggestion of an unnamed accomplice) that we needed a Letterman-like Top Ten list.
In this case SaaS will denote scanning as a service, rather than software or security, as security is the last thing these daft gits offer. These are all real statements, claims or quotes from these so called services.

Top Ten 10 signs the SaaS sales guy in front of you if offering up snake oil.

10. We first scan for open ports.
9. If you're interested in increasing your conversions, I'd suggest you sign up for WebSafe Shield.
8. Al Gore is on our board.
7. We held a hacker contest to break our security, and no one did.
6. We want to be the trusted partner who’s at your side, day by day, year to year,to help your business grow.
5. Increase your conversion rate or double your money back!
4. Our Web-based PCI Compliance 1-2-3 solution includes everything you need.
3. The "Verified Secure" mark appears only when a web site's security meets the highest security scanning standards of the U.S. government.
2. Unfortunately, the automated scanning technology we use doesn’t have this XSS scanning.
1. We go in like a super hacker.

There will be no rest for their souls in the afterlife; the web app security gods have a special in hell for salesmen and companies like this. ;-)

del.icio.us | digg