The PPS "Techno-Blog"

The Pitfalls of Demo Accounts for Web Applications: Seller Beware!

Email Article |  digg it |  reddit |  delicious |  StumbleUpon |  LinkedIn 

Authored by Robert Gorski, Sr. Security Consultant at Pivot Point Security.

Do you provide a demo login account to your web application product?  You may be exposing your customers' data to anyone who wanders in.

It is often the case that when a demo account for a web application is created, it is created in the same fashion as a normal user account.  The only difference might be that a scheduled job of some sort occasionally deletes any new information created in the account, and resets any settings back to some default.

On a recent engagement, we were tasked with evaluating a web application that allows our client's customers to manage communication with their contact lists.  The contact functionality allows the user to create a mail-merge document including any of the saved fields for their contact.  During the creation of one of these mail-merge documents, it is possible to preview the finished product with real contact information.

While examining this particular piece of the software, we discovered an Insecure Direct Object Reference vulnerability.  In this case, changing a key value in the URL changed the data in the mail-merge preview.  It did not take long to notice that we were getting real information from some of the random identifiers we were trying, including full names, email addresses, mobile phone numbers, and physical addresses.

Our client's demo site used the same data store as the production site, and the one error we found in their application was putting the personal information of potentially thousands of people at risk.  Anyone could have created that mail-merge document and started harvesting contact information.

Maintaining a data store for your demo site that is completely separate from your production data is a key factor in maintaining the overall security of your customers' data.  Even if you have a third-party attestation to the security of your product, you might have a well-coded and secure application today, but new vulnerabilities are found all the time, and the person who finds yours tomorrow might not be an ethical hacker!

Even Techs Dread Calling Tech Support – But Sometimes. You Gotta Believe!

Email Article |  digg it |  reddit |  delicious |  StumbleUpon |  LinkedIn 

Authored by Michael Gargiullo, Sr. Security Consultant at Pivot Point Security. 

Admit it, you hate calling tech support.  Everyone does.  I don't know a single person who wakes up in the morning hoping for a data center catastrophe that requires opening a ticket with a vendor support system.

Why is that?  It's not that you dread finding out you did something stupid to cause the problem... well maybe, but it's really the expectation of what's to come.  For me, it usually goes something like this:

The system is down.

Can we fix it? 

No.

Why?

The critical error just says "It's Broken, call support"

Did you reboot it? ...

So we call the support line, press 1 for English, and then wait.  We finally get through to a minimum wage employee that reads from a script.  If your error isn't in the index of the script, they tell you to reboot.  I once had a fortune 500 vendor support person tell me that I had a "Packet Jam" in their low end router product.  Now, I've been working in the tech industry for about 15 years, and the only packet jam I know of is the little packets the bodega gives you with your buttered bagel...usually grape flavored.

Back to my point; this week while assisting a customer troubleshooting a product, we came across a new critical error message that there was no documentation for.  I offered to call support to see if we could get this decoded and the issue resolved.  The gentleman who answered, (I'll call him "M"), asked a few basic questions about the error, then said "Wow, I've never seen that error before.  Hang on; let me get one of the backline engineers".  Honestly, at this point I really liked this guy.  M was either completely new at the tech support game, or he actually cared about what the customer needed.

Within minutes, there was a backline engineer on the phone with us as we tried to diagnose the issue further.  The three of us worked on it for about 2 hours.  As 5pm neared, I prepped myself for the system being down over night as the techs told me they'd have to examine the logs and the engineer was about to leave for the day.  I shipped them a copy of all of the logs and was promised a call back first thing in the morning.

I had just finished an email to the customer explaining the situation when the engineer called me on my cell phone.  He said he had spoken with the developers just after we had hung up.  They had told him this was a known bug to be fixed in the next service pack.  Expecting the normal "the service pack will be released in a week, etc", he surprised me once again by offering the service pack to us now.  I was floored and thankful that the service pack was release level code.  The engineer emailed me the fix when he got home, we installed it and were back up in no time.

I bring this to you as a story of hope.  Yes, calling tech support is usually not a great experience, but this time... these techs...   went beyond my expectations.  They listened to the issue and really tried to solve the problem.  So by the time the engineer asked if we'd be willing to run the yet to be released service pack, I trusted him enough to allow it. Yes, ‘tis the season - you gotta believe!

How Spaghetti Sauce Can Improve a Security Audit – Part Two

Email Article |  digg it |  reddit |  delicious |  StumbleUpon |  LinkedIn 

Authored by Mosi Platt, Senior Audit Consultant, Pivot Point Security 

At the TED2004 conference, Malcolm Gladwell explained how a psychophysicist named Howard Moskowitz showed us how we can be happier with his work on spaghetti sauce and coffee.  At the GovCERT Symposium in the Netherlands this year, David Rice applied Gladwell's story to information security in his plenary speech, "Extra Chunky CyberSecurity."  I think both speeches hold three important lessons for information security auditors and their clients:

• 1) Clients can't explain what assurance they want;
• 2) There is no perfect security assurance - even if you call it "reasonable and appropriate"; and
• 3) Auditors fail their clients when they don't embrace variability.

Part One of this article described how information security auditors can provide more value to their clients by learning the first lesson from spaghetti sauce - clients can't explain what they want.  Part Two will describe the second and third lessons.

There Is No Perfect Security Assurance

Gladwell said Howard discovered that taste does not exist in a hierarchy but on a horizontal plane.  Rice said the same principle applies to security - there is no perfect security (e.g. best practice XYZ or standard ABC), there are only different kinds of security that suit different kinds of people.  It may appear that auditors have already solved this problem because they always preach the phrase "reasonable and appropriate," but in this case auditors don't often practice what they preach.  An organization's security is not perfect/imperfect because it's compliant/non-compliant with a security standard that may/may not align with its own requirements.  What's "reasonable and appropriate" in a zero-sum game of compliance or non-compliance?  PCI tried to address this with different compliance requirements for different levels of merchants, but that does nothing for the merchant concerned with their security instead of their compliance.  We need to democratize the way we think about security assurance.  Instead of being prescriptive, perhaps we need to be more descriptive and leave assurance in the eye of the beholder.  OSSTMM and the Shared Assessment Program's Agreed-Upon Procedures are steps in that direction because they objectively describe the level of coverage provided by an organization's security controls and leave it to the party seeking assurance to determine whether they feel the security provided is adequate instead of relying on an auditor's opinion.

Auditors Fail Their Clients When They Don't Embrace Variability

Gladwell used coffee to illustrate that the pursuit of a Platonic notion (e.g. perfect spaghetti sauce or perfect security) is not only erroneous but does everyone a massive disservice by giving them something they will accept (i.e. a dark, rich, hearty roast) instead of something that will make them deliriously happy (i.e. milky, weak coffee).  Rice said the most powerful revelations for security will come when we start giving people what they want (i.e. secure, reliable systems) and not just what we think they need (i.e. perfect compliance or protection from the latest vulnerability).

When auditors pursue this Platonic notion of security assurance based on compliance or non-compliance, then they fail their clients the way Heartland Payment Systems' CEO feels his auditors failed him.  Look at the contrast between Brian Snow's definition of assurance and the Platonic notion of security assurance practiced today.

Audit methodologies like OSSTMM and the Shared Assessment Program's Agreed-Upon Procedures can give auditors the chance to embrace their clients' uniqueness and variability while providing the security assurance they want.  Regardless of the methodology, if auditors remember who their clients are and take time to identify what they want; democratize security assurance with more description than prescription; and embrace truly reasonable and appropriate security assurance over compliance then perhaps people will enjoy their security audits as much as some people enjoy extra chunky spaghetti sauce.

How Spaghetti Sauce Can Improve a Security Audit – Part One

Email Article |  digg it |  reddit |  delicious |  StumbleUpon |  LinkedIn 

At the TED2004 conference, Malcolm Gladwell explained how a psychophysicist named Howard Moskowitz showed us how we can be happier with his work on spaghetti sauce and coffee.  At the GovCERT Symposium in the Netherlands this year, David Rice applied Gladwell's story to information security in his plenary speech, "Extra Chunky CyberSecurity."  I think both speeches hold three important lessons for information security auditors and their clients:

• 1) Clients can't explain what assurance they want;
• 2) There is no perfect security assurance - even if you call it "reasonable and appropriate"; and
• 3) Auditors fail their clients when they don't embrace variability.

Clients Can't Explain What Assurance They Want

Gladwell explained that when Howard was researching spaghetti sauce he discovered that 1 out of 3 people preferred extra chunky spaghetti sauce.  However, it was not being sold in any supermarket because in 20-30 years of asking focus groups what they wanted, no one ever said they wanted extra chunky spaghetti sauce.  Rice said the same phenomenon happens in the information security industry because the professionals don't know who their clients are and they need to ask better questions.

The same thing happens with an information security audit.  For example, is the PCI auditor providing assurance to the payment card brands that issued the security standard or the merchant that hired them to assess the security of their credit card data?  The CEO of Heartland Payment Systems thought the auditors they hired were providing the latter when they were actually providing the former.  It wasn't until after a massive data breach that the CEO explained what assurance they really wanted.  As auditors, we need to ask better questions to resolve these types of issues BEFORE a client's security is compromised.  Typically, if a client says, "I want to know how secure this environment is," then the auditor asks, "What security best practices are in place for the environment?"  But not every client needs assurance they're compliant with a checklist of best practices to have confidence in their security.  Perhaps Heartland Payment Systems needed assurance about their operational security and not their operational security compliance.

There is a simple way to determine whether an auditor is asking the right questions about security assurance.  According to Brian Snow, the Technical Director of Information Assurance at the NSA, the purpose of security assurance is to build confidence in system security by demonstrating that:

• 1) The system's security policy is internally consistent and reflects the requirements of the organization,
• 2) There are sufficient security functions to support the security policy,
• 3) The system functions meet a desired set of properties and only those properties,
• 4) The functions are implemented correctly, and
• 5) The assurances hold up through the manufacturing, delivery, and life cycle of the system.

If the auditor isn't discussing the following topics with their client, then they need to ask better questions:

• 1) The organization's business requirements (not just compliance requirements) and criteria for evaluating the security policy's consistency.
• 2) How to determine the sufficiency of security functions that support the security policy. Will the auditor just use some set of best practices that may or may not be appropriate for the client's organization?
• 3) How to identify the desired set of properties that system functions should be meeting. Will a generic set of security standards be used that may not be appropriate for the specific system(s)?
• 4) Criteria for evaluating the implementation of functions. Again, will the auditor just use some generic set of best practices that may not be appropriate for the specific implementation?

Part Two will explain two other key lessons information security auditors can learn from spaghetti sauce:

•2)      There is no perfect security assurance - even if you call it "reasonable and appropriate"; and

•3)      Auditors fail their clients when they don't embrace variability.