<![CDATA[[SecurityRatty] tag: cms]]> http://securityratty.com/tag/cms Thu, 20 Dec 2007 09:15:59 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[ColdFusion: Hack Me or Help Me]]> http://securityratty.com/article/9fb9073abbbbfc649c8feeed2afceb21 http://securityratty.com/article/9fb9073abbbbfc649c8feeed2afceb21 Front and center: ColdFusion.
I've been picking on ColdFusion-built apps again a bit lately, and one of my observations has been that consistently, if mismanaged, the verbose error reporting features in ColdFusion can be really problematic.

HIO-2008-0713 JOBBEX JobSite SQLi & XSS
HIO-2008-0729 BookMine SQLi & XSS

Recently, I stumbled on an example of way too much information disclosure in a few sites running a ColdFusion-built CMS. The error reporting was so verbose it included the base path, data source name, database username, and yes, the database password.
I've cleaned it up for the protection of all involved, but here's a screen shot of only 1/4 of the details this site coughed up when I tweaked the input to a calendar date variable.



When I reached out to the developers of this app (always and immediately responsive), they assured me that this was not due to a flaw in the app, but that the "information should be protected, and is by default for our installations" and that the client disabled the security check and turned debugging on. I accept this explanation entirely, but it leads to the classic debate around the dangers of mismanaged debugging features, be they developer added or ColdFusion feature driven. Stupid user tricks are always an issue, but how much rope should they be given to hang themselves? Does error reporting really need to include the database username and password?

Allow me to present a few different perspectives.
First, rvdh's take on Attacking ColdFusion. Developers can learn a lot from this post, if only in that it precisely points out attack vectors. Ronald sums up my concerns aptly:
"As we know, error messages are important. Especially error messages generated by database software we want to inject. This, is useful for obtaining information about table structures that can be a real time-saver for attackers. If the right information is available, attackers do not have to guess database tables and fields anymore, nor having to brute force them. I have never seen so much information regarding the site's structure, used database, table names, drivers, server setup and other information useful for attackers that those of ColdFusion. It almost says: Please Hack Me!"
As I can't presume to improve on this stance, I won't. Well said.

Next, a developer's take on the issue from Joshua Cyr, who has declared it Check Your Error Output Day. Joshua highlights two key points:
1) Do NOT enable the robust errors setting in CF Administrator.
2) Don't forget to remove debugging dump code.
Heed this advice, ColdFusion fans!

One destination that all "secure" ColdFusion paths should lead to is the use of cfqueryparam. Ronald spells it out well mid way through his discussion, and so do the following resources:
coldfusionjedi
Coldfusion Muse

Further excellent resources for ColdFusion security issues:
SQL Injection Part II (Make Sure You Are Sitting Down)
12Robots.com

In closing, security and convenience needn't always be at odds, but often allowing for both requires a higher state of awareness for developers and end-users. Let common sense prevail; perhaps it'll give me less to do in the way of research. ;-)

del.icio.us | digg]]> Thu, 28 Aug 2008 06:13:00 +0000 coldfusion coldfusion paths coldfusion fans coldfusion security issues error database database username error messages coldfusion feature ColdFusion: Hack Me or Help Me <![CDATA[Sikhs Can Carry Knives on Airplanes in India]]> http://securityratty.com/article/1cce8b18c160bf8003ab9f0c9abdc224 http://securityratty.com/article/1cce8b18c160bf8003ab9f0c9abdc224 That's what the rules say:

Sikh passengers are allowed to carry Kirpan with them on board domestic flights. The total length of the 'Kirpan' should not exceed 22.86 CMs (9 inches) and the length of the blade should not exceed 15.24 CMs. (6 inches). It is being reiterated that these instructions should be fully implemented by concerned security personnel so that religious sentiments of the Sikh passengers are not hurt.

How airport security is supposed to recognize a Sikh passenger is not explained.

]]> Tue, 10 Jun 2008 02:27:16 +0000 sikh passengers kirpan board domestic flights length carry kirpan total length religious sentiments inches cms Sikhs Can Carry Knives on Airplanes in India <![CDATA[Blue River's stance on Sava security stands out]]> http://securityratty.com/article/057ed0d1ba0eb036e642100e6c2b081e http://securityratty.com/article/057ed0d1ba0eb036e642100e6c2b081e Sava CMS from the Blue River Interactive Group.
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!

Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS

del.icio.us | digg]]> Fri, 23 May 2008 16:02:00 +0000 sava blue river blue river team sava cms blue river interactive sava fits issue sava users sqli issue Blue River's stance on Sava security stands out <![CDATA[We can't write secure code]]> http://securityratty.com/article/79c47a2e1084bd1deba73b2fa9ab33e1 http://securityratty.com/article/79c47a2e1084bd1deba73b2fa9ab33e1 David Lacey makes the important point that writing secure software is "not just about cutting secure code or developing better testing tools. We need to get things right much earlier in the development process." It's a subject I've been harping on about for some time, with many references to excellent resources such as OWASP, and great leaders on the subject such as Mark Curphey. Over the last few years I've heard many solutions proposed to fix the problem of insecure software, ranging from sacking the developers to improving the software development lifecycle so that security requirements are stated from outset and followed through into production and beyond. The evidence is that none of it works. OK, the folk at Microsoft, for example, will say that security is now embedded in their culture, and they've certainly generated a nice new stream of revenue for themselves out of all the books, tools and journals on the subject. But they are still releasing security patches with a frequency and schedule that the I wish the rail company I use each day could achieve with their trains. And other vendors are coming up with clangers at an alarming rate. For example, this latest one from leading CMS vendor RedDot. An SQL Injection vulnerability in an enterprise level CMS system - what were they playing at with their quality control?! So, here's the thing. We can't write secure code. It's true. Can you show me any decent commercial, consumer focused product (that people actually want to use - not just techies who haven't seen daylight in 12 years and live on a diet of digestive biscuits) that is secure from the off as soon as it's exposed to the Internet and where 12 months later it hasn't required a patch of some sort? Systems are simply too complicated with too many lines of code for anyone to expect that they can be released without containing bugs and security holes. That doesn't mean that we shouldn't try, it just means that we should take a different approach. That approach, in my opinion, is to take a leaf out of the new edition of the PCI standards and stick a ruddy great application firewall in front of everything. That doesn't make the code secure, it's a sticking plaster over a wound. But - to continue the analogy - a plaster stops the bleeding, prevents germs getting in, and while it's not a cure, it's good enough. I'm not knocking OWASP et al. It's the first resource I recommend developers go to and will remain so. Just that the business expects more functionality, cheaper costs, more complexity, better performance, and a more rapid deployment for its products. Chucking in security with all that lot is like rubbing your belly and patting your head at the same time, while riding a motorbike. So, let's make it easy on ourselves. Application firewalls! ]]> Fri, 16 May 2008 03:00:00 +0000 code secure code secure secure code secure software security security holes security requirements security patches We can't write secure code <![CDATA[Defending the Caveman - Are blogs newsworthy?]]> http://securityratty.com/article/4e3d13b699d77f6e54f6fca2e0371900 http://securityratty.com/article/4e3d13b699d77f6e54f6fca2e0371900

news·wor·thy /ˈnuzˌwɜrði, ˈnyuz-/ Pronunciation Key - Show Spelled Pronunciation[nooz-wur-thee, nyooz-]

–adjective - of sufficient interest to the public or a special audience to warrant press attention or coverage.

Caveman I wanted to come back and touch on something that someone wrote in a comment yesterday.  This has nothing to do with whether or not a government or service has a right to filter out content, they do.  So does just about any employer on their own network and machines.  For me the bigger issue was the comment "... and frankly blogs aren't newsworthy, the majority of them are just random points of view that wouldn't be cited, with any validity".  To me this is a clear sign of someone who has not spent a lot of time out among the rest of us lately.  What cave has this person been living in?  Whether we are talking about politics, science, music or technology, it takes some kind of special cretin to make and believe this argument about whether blogs are newsworthy. Part and parcel with this attitude seems to be the attitude that people who read blogs are bandwidth slurping slackers, who have nothing to do all day but avoid doing anything productive at work and read these extreme waste of times.

Do people really believe this?  Evidently so.  My view is this: blogs have become a major source of news and influence. They have revolutionized the media industry in a similar fashion to what the desktop publishing software market did to the the print industry. They have given voice to millions and put the common man on par with the hereinbefore omnipotent media reporter.  But really folks, is there really even a doubt in your minds on this?  If there is, here are some links that may help settle that question:

http://www.foreignpolicy.com/story/cms.php?story_id=2707&popup_delayed=1

Every day, millions of online diarists, or “bloggers,” share their opinions with a global audience. Drawing upon the content of the international media and the World Wide Web, they weave together an elaborate network with agenda-setting power on issues ranging from human rights in China to the U.S. occupation of Iraq. What began as a hobby is evolving into a new medium that is changing the landscape for journalists and policymakers alike.

http://news.bbc.co.uk/1/hi/technology/4976276.stm

The impact of blogging has reached a tipping point, argues Julian Smith, senior analyst at Jupiter Research.

This week's We Media forum was covered by the blogs

Anyone studying the media over the last few months might have noticed a sudden increase in concern about the growth of consumer-created content and the impact of blogging on business.

There are a lot more similar types of reports from "valid news sources" that I can show that proves this point, but I suspect for the majority of you that would be dulling the point.  But lets not forget the valuable lesson here.  There are people out there who blinded by their own beliefs do not see the forest as being made up of trees, but see something else entirely. 

But to the person who left this comment I ask: if blogs are not newsworthy and worth reading, what were you doing reading mine and wasting your time with a comment?  I think the answer to that will go a long way towards coming to grips with reality.

]]> Fri, 29 Feb 2008 12:18:25 +0000 blogs newsworthy frankly blogs media media forum newsworthy nuzwr valid news sources international media comment yesterday Defending the Caveman - Are blogs newsworthy? <![CDATA[CMS HIPAA Compliance Review Checklist]]> http://securityratty.com/article/3de2d1a85ecbace42822f0b9c4622c43 http://securityratty.com/article/3de2d1a85ecbace42822f0b9c4622c43 Tue, 26 Feb 2008 10:25:35 +0000 hipaa compliance review health care industry cms meicaid services pdf document potential interviewees lists artifacts centers CMS HIPAA Compliance Review Checklist <![CDATA[Links for 2008-01-22 [del.icio.us]]]> http://securityratty.com/article/6435d313b2851e2653165f9426050242 http://securityratty.com/article/6435d313b2851e2653165f9426050242
  • TaoSecurity: Is This For Real?
  • 7 myths about security metrics
  • CMS to check hospitals for HIPAA security compliance
  • One year later: Five takeaways from the TJX breach
  • Riskbloggers - Security Wisdom ahead of the curve
  • Q1 Labs Signs OEM Agreement with Juniper Networks
  • ArcSight plans to raise about $52M in IPO - Silicon Valley / San Jose Business Journal:
    In an amended filing with the Securities and Exchange Commission, when, Cupertino-based ArcSight said it plans to sell 6 million shares, while stockholders will sell an additional 861,919 shares. Based on the expected price range, the company would have a
    • ]]>     Tue, 22 Jan 2008 21:00:00 +0000 arcsight plans arcsight shares hipaa security compliance plans million shares security wisdom ahead juniper networks security metrics Links for 2008-01-22 [del.icio.us]     <![CDATA[HIPAA Growing Teeth, Round II?]]> http://securityratty.com/article/c741622d99f09f7c1917f9d7959599a6 http://securityratty.com/article/c741622d99f09f7c1917f9d7959599a6 HIPAA Growing Teeth" we proudly give you: round deux :-)

    Specifially, "CMS to check hospitals for HIPAA security compliance" paper claims that "The Centers for Medicare and Medicaid Services (CMS) will begin on-site reviews of hospitals’ compliance with security rules mandated by the Health Insurance Portability and Accountability Act of 1996. "

    Can these guys kick (eeeeh, "bite," not "kick," since we are talking about "growing teeth" :-)) some insecure healthcare ass? Only time will tell, but HIPAA won't be another PCI DSS (for many reasons)
    About me: http://www.chuvakin.org
    ]]>     Tue, 22 Jan 2008 10:44:00 +0000 hipaa round hipaa security compliance teeth kick health insurance portability round deux insecure healthcare ass guys kick HIPAA Growing Teeth, Round II?     <![CDATA[TRICARE breach affects 4,700 households]]> http://securityratty.com/article/15bfaf273b2fdbbbdf76168fa62115ad http://securityratty.com/article/15bfaf273b2fdbbbdf76168fa62115ad Security Breach

    Date Reported:
    12/07/07

    Organization:
    TRICARE

    Contractor/Consultant/Branch:
    TRICARE Area Office Europe (TAO-Europe)
    Department of Defense TRICARE Management Activity (TMA)
    Electronic Data Systems (EDS)

    Victims:
    TRICARE beneficiaries located in Europe between the years 2004 and 2007

    Number Affected:
    4,700 households

    Types of Data:
    Full or partial Social Security Numbers, and for one or more members of the affected household, their name, date of birth, and a medical diagnosis code associated with a health benefits claim submitted to TMA

    Breach Description:
    On November 7th, 2007 Electronic Data Systems (EDS) reported to TRICARE that they had discovered a potential compromise of sensitive personally identifiable information belonging to beneficiaries located in Europe.  EDS is an IT contractor for TRICARE and "had not appropriately secured a part of the system" they support.

    Reference URL:
    TRICARE TMA Website Announcement
    Air Force Times Story

    Report Credit:
    TRICARE

    Response:
    From the online sources cited above:

    A potential compromise of personally identifiable information belonging to approximately 4,700 TRICARE beneficiaries located in Europe occurred recently due to a problem with a claims Web site managed by Electronic Data Systems (EDS).

    The incident was reported to TRICARE on November 7, 2007. The information that was potentially compromised, however, existed between the years 2004 and 2007.

    The compromised information may include your full or partial Social Security Number, and for one or more members of your household, their name, date of birth, and a medical diagnosis code associated with a health benefits claim submitted to TRICARE Management Activity.

    Although the assessment yields that external entities did in fact, access the system for purposes that do not appear malicious, at this time we have no indication that any of your personal information has been misused.
    [Evan] This statement is a little confusing to me.  Are the "external entities" authorized or not?  If they were not authorized to use the system, and they had in fact accessed the system, then I would say that the access was probably malicious in nature.

    It is possible that an unauthorized person could have accessed your personal information, but the Department of Defense is taking proactive steps to keep you informed.
    [Evan] I don't like the word "proactive" when using it in reference to a reaction.  The notification is a reaction to a lack of proactivity.  You dig?

    Those who may have been potentially affected by this compromise will receive a notification letter

    The data was held on a Web application server that allowed external entities an unauthorized level of access without going through the required authentication process if the Web address was known.

    That situation has since been remedied.

    Practices such as Public Key Infrastructure (PKI) requirements and authentication verification cookies have fixed all known vulnerabilities associated with this incident. In addition, the CMS application has since been taken off-line. EDS has completed the forensics analysis of the server and is performing a by-line code review to ensure there are no further critical vulnerabilities present in the code.
    [Evan] Should EDS be the ones conducting the vulnerability assessment and code review?  If it were me, I would feel more comfortable with a third-party review.

    EDS is offering beneficiaries put at risk a free, one-year subscription to a credit monitoring and protection service.

    Additionally, those affected will receive up to $20,000 identity theft protection coverage with no deductible as it relates to this matter.

    Affected beneficiaries with questions or concerns may contact the EDS Incident Response Center at 1-800-556-3195.

    Those located outside the United States must dial the country’s AT&T USADirect access number first.

    Commentary:
    I am trying to determine with some certainty what led to this breach. 
    Was it poorly written code?  (check out OWASP)
    Was it a mis-configuration of the web server?
    Was encryption not required, i.e. a user could use http or https to access the application?
    Was it a combination of factors?  I will assume it was a combination of factors.

    On the one hand, I commend EDS for disclosing the breach to TRICARE, but on the other hand I am concerned about how long this problem may have gone un-noticed.  Web applications acquiring, processing, accessing, storing or interacting with sensitive information in any manner require regular security reviews commensurate with the risk to the such information (unauthorized disclosure, alteration or destruction).  This seems to be a case where you have an IT contractor in charge of design, implementation and maintenance of an application (typically with functionality as a driving factor) but also in charge of maintaining it's security.  Information security really is a "stand-alone" function that should not be lumped into the same IT contract and warrants a "stand-alone" contract with a company that specializes in information security.  My $.02.

    Past Breaches:
    Unknown



    ]]>     Thu, 20 Dec 2007 09:15:59 +0000 tricare information personal information code review by-line code review information security tricare beneficiaries beneficiaries breach TRICARE breach affects 4,700 households