Voice of the DBA

Tag: security

  • The Command Shell

    Security holes are all around. Are there any in xp_cmdshell?
    Security holes are all around. Are there any in xp_cmdshell?

    Recently I heard a few people arguing over the use of xp_cmdshell in a particular situation. One person was adamant that there was a security risk in using this feature. Many of you probably feel the same way, and even the SQL Server platform has recognized there could be dangers with this feature and has it disabled by default, as part of the secure by default installation.

    However the security around this procedure has been improved over the years. Non system administrators cannot execute xp_cmdshell by default. Administrators can open up access using a proxy account, but this requires specific configuration changes by administrators. This means that a lot of the danger of using xp_cmdshell for administrative tasks has been removed.

    Or has it? This Friday I wanted to poll you and find out what you think. Many of you are creative in how you use SQL Server and will think of possibilities that many of us would not consider.

    Is there a security risk in allowing xp_cmdshell to be used by members of the sysadmin role?

    I’m not looking for potential issues if a proxy account exists. Instead I’m asking if there are real dangers in allowing administrators to use this tool? I assume you trust your administrators and they will not maliciously use this tool to cause issues in your SQL Server. Let us know how you feel this week.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • A Good Security Response

    I'm glad Evernote acted quickly and decisively with this incident.
    I’m glad Evernote acted quickly and decisively with this incident.

    Security will become more and more important in the future, at least in my mind. As we become more interconnected and dependent on digital services, if the level of fraud and security failures do not fall, many people will hesitate to use these services. I think certificates will be the future of digital security, but until we get better support for managing them built into all our OSes, I’m not sure we’ll move beyond passwords. I do think we need to move past passwords, but we’re stuck with them for now.

    Recently Evernote had a security breach and they forced all users to reset their passwords. It was slightly annoying, but it was a comforting response for me. Two week after the incident I had to change the password on my iPad, which I rarely use. It was ironic since I was working on this particular piece when I reset my password.

    I wasn’t the only one that thought this was a good response. In this article from Enterprise Security, a number of security professionals praised the way Evernote handled this incident. They note that Evernote had implemented good security practices (from what we know) and notified people immediately. I certainly appreciate Evernote moving quickly on this and am glad I had to deal with the annoying password change. I don’t use the same password on other sites, and this was a good reminder to me that I shouldn’t. It also served as a reminder to tell my family to do the same thing.

    I’m not sure any company I’ve worked for would handle things this way. I haven’t had many security incidents at my previous employers, but I know in one case we were told not to disclose anything and fix issues. I’d like to think that most companies would disclose this, and I do think they should, but most wouldn’t. These things happen, just like break-ins happen in physical buildings. Companies should accept that, diagnose the issues, repair them, and move on. Customers will understand the problem and remediation steps. What customers don’t understand, or accept, is a company failing to inform them. Or failing to improve security when they know there are issues.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Algorithm Secrecy is not Security

    Should we disclose this information on websites?
    Should we disclose this information on websites?

    I find the field of cryptography and encryption to be fascinating. I present a talk on encryption and  constantly find people that don’t realize the security of an encryption algorithm doesn’t depend on what the algorithm is or knowing how it works. I can tell you that I’m using an AES or RSA algorithm and that doesn’t make it any easier to decipher the plaintext.

    This week Troy Hunt wrote a piece where he called for disclosure by websites (and really all applications) of the password storage mechanism. The badge above is an example of what he’d like to see posted on all websites. His explanation of what this might change in terms of Internet security is great, and while this might not actually make applications more secure, I’m not sure that many companies would want to be forced to disclose they are storing passwords in plain text. Consumers are becoming more savvy and realize this is a poor way of managing systems. I suspect that people will quickly learn what are strong and no-so-strong algorithms.
    Real security still requires developers to not only implement strong algorithms in their applications but also make these algorithms upgradeable. We used to use MD5 everywhere (now a bad idea), and in SQL Server 2008 R2, we are limited to SHA1. This algorithm is known to have problems and SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. You can write your own implementation, and if you have high security requirements, I’d encourage you to do so.
    Key security is important, and this is to systems what password security is to individuals. Protecting your keys (and passwords) is ultimately the way in which we can dramatically increase the level of security in applications. This is the hardest part of managing encryption in your application, and I’d encourage you to seek out someone with experience to help you understand how to best handle  this.
    Ultimately a lot of security depends on layers, with some secrecy in place, but the secrets you keep should be the exact design and implementation of your entire infrastructure, not the algorithms used. If you build encryption into your systems, please do not design your own algorithm. On a regular basis the vendors and developers who think they’ve implemented strong encryption by hiding the details of their algorithm are usually unaware of how flawed this approach is. Please use well known, public algorithms for encryption, which have been tested and probed by mathematicians in a public forum.
    Steve Jones

  • Data We Don’t Want

    Filldisk.com might do this to your hard drive.
    Filldisk.com might do this to your hard drive.

    Don’t visit the FillDisk.com site, which I ran across a link to froman Arts Technica article that talks about a flaw in web browsers. It’s possible a security flaw, possibly an availability flaw as well. Apparently the new HTML specification allows for sites to use the Web Storage Standard to keep data on your hard disk. There is a limit in most browsers for how much data you can store per domain, but the FillDisk site uses sub domains to put random junk on your drive. The author of the site built this as a proof of concept and was able to add 1GB of data to an SSD on a laptop every 16 seconds.

    That’s a denial of service type attack that I hadn’t expected, but it is an interesting attack vector. I wouldn’t expect this to impact servers, but if servers are consuming web services, and using controls based on browsers, there is the possibility this type of attack might affect them. I’d hope this were limited to web servers and not impact database servers, but it’s certainly a concern if you have processes running on your database server that might retrieve data from a remote source.

    This makes me want to re-architect the way we build data driven application in the future, to prevent this type of vandalism. Maybe building an application level firewall that proxies all access to a database server. The idea of application servers was very popular a decade ago, but it seems few systems actually implemented this type of architecture. Perhaps this is because the web server/database server pairing is such an easy paradigm to build for most developers.

    Frameworks that allowed separation of the application through a middle layer could allow for caching of data in addition to more security. That could increase performance and scalability as the database wouldn’t be the single bottleneck for all requests.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.