Secure your toolset and stop hack attacks

To control this, use your network and machine firewalls, limit which network interfaces services listen on, and consider totally separating internal-only networks from externally connected ones. Trust your own tools’ security as little as possible: isolate everything sensitive from the rest of your internal infrastructure to limit the damage when something is eventually exploited. If on any site using PHP 5.3.7 a user is   created, logins to that account using any password are all successful. Having your own set of integration tests, testing security-critical processes including the unhappy path, enables you to quickly spot regressions like this before you upgrade in your live environment. Sadly, nobody ran them before publishing the release. Developing secure software is about more than writing secure code. Read these! However, it’s experienced more than a few security hiccups along the way. Rails is a web framework, running atop Ruby, which makes it very easy to quickly build web applications. Let’s take a look at some of the security failures that have hit popular tools recently, and see how you can protect yourself from such flaws in the future. Reduce external access
Firewalling or disconnecting your components from the external internet increases every component’s security.This is a great example of how increasing your external attack surface can threaten the security of your entire system. Like PHP, through, it’s had troubles. It’s easy to keep your code safe. This holds true for YAML, but also for popular formats like XML (for example, consider the   Billion Laughs attack). In its most spectacular recent vulnerability, it was discovered that if you connect to a Postgres server and request a database which has a name that begins with a dash, then the name is interpreted instead as a command-line argument on the server, even if you fail to authenticate. This highlights a critical point for security in general: ensure you’re sanitising user input as much as possible, and reject anything even slightly dubious immediately. There’s rarely any need to expose your database instances, or other internal components. Your code is only a small part of the ‘attack surface’ (the accessible parts of the system that an attacker might exploit) of your application, and it’s the part of the system an attacker will have least knowledge of. This article first appeared in net magazine issue 257. This vulnerability was in the commonly-used serialize attribute. This is extraordinarily dangerous. All sorts of data formats and components have unpredictable complexities that can make your site unexpectedly vulnerable to attack. Thorough testing is particularly worthwhile, and makes it easier to remain confident of your system’s basic security as you   change it. In February 2013, Rails 3.2.12 was released, fixing one of a series of critical security vulnerabilities. It’s occassionally had some security holes of its own, but more interesting was the fallout of the   substantial search improvements it rolled out in   January last year. To exploit this with the standard psql client, you connect with:

psql – –dbname=”-r /var/lib/postgresql/data/db”
With that,’s log output is appended to the contents of its database, corrupting it and totally breaking the site. Simple, well publicised YAML documents exist which run arbitrary code when parsed with the standard Ruby libraries, and using that in this case makes it surprisingly easy for an attacker to take over your server. Keep secret data isolated
Secret data for your deployed site (API and encryption keys, usernames, passwords) should be   stored somewhere separate from your codebase, and securely isolated from everything else possible too. Follow good development practices for security processes, and look for tools that follow these processes too. In a system that allows users to add blog posts, marking each post with a list of tags, a vulnerable class might look like this:

class Post ActiveRecord::Base
serialize :tags
This simple class represents a blog post with a tags property, that should be serialised in YAML format when the post is saved. When it’s loaded, it then appears to be previously safely-serialised YAML, and Rails happily tries to deserialise it. This tells Active Record (the Rails ORM) to serialise or deserialise a property to or from a YAML string when persisting to the database. Even having your secrets stored in a private repository has dangers. Meanwhile, huge databases of exploits for common components already exist, and can be used to quickly sweep swathes of the internet looking for unlucky vulnerable sites from which they   can steal valuable secrets. It’s harder to ensure your tooling has done the same. It was very challenging for many cloud services. This painful series of issues required repeated, urgent upgrades to almost every Rails server deployment on the net, leaving Rails developers not best pleased. Good luck! This exposes them to attacks like this in any individual component. Additions to your Git repository stay in your history permanently, and there’s enough risk around the possible brief exposure of your Git repo (the next vulnerability in GitHub, your CI server, or anybody’s development machine) that it’s not worth the massive damage that’ll be caused by the exposure of   your secure data. GitHub
Lastly, we look to GitHub, the popular Git hosting site. Secret data for your deployed site should be stored separately from your codebase

Even now, searches for Amazon Web Services keys   on GitHub turn up nearly 10,000 results. It’s much harder to ensure every part of your infrastructure and tooling has done the same. YAML is a powerful data format, and can request that Ruby classes be instantiated and configured as part of parsing. For version 5.3.7, a tiny change was made to the crypt() function – the recommended function (at the time) for salting and hashing passwords. Take a look at ZooKeeper, Chef Vault   , Git-encrypt   and dotenv. Words by: Tim Perry
Tim Perry is an expert in JavaScript, security, Polyglot Persistence and Automated Testing. Popular solutions to this include storing these secrets as environmental variables in your deployment environments, keeping the secrets in   Git-ignored local config files, or in encrypted config files that can be committed, while keeping the   encryption key safe elsewhere. PHP
PHP is the most popular programming language in   the world for websites, powering huge players like Facebook, Wikipedia and WordPress. Unfortunately for this example, if tags is already a   string of YAML, then it’s not further serialised, and is saved raw to the database. More interestingly, this bug was actually reported before the release went out – and on top of that PHP has unit tests for this, which would have detected the bug immediately. Despite many warnings from Amazon itself, it’s easy to find reports of AWS users with crippling bills after accidentally making their keys public like this. Look for anything suspicious
Many open source projects publicise the status of their tests and other metrics in their current codebase, using tools like Travis CIBugs like this are scary: reasonable code made vulnerable by problems in the tools used. It’s also worth noting that your data formats may be more than just simple structures for data, and naïve uses of the wrong ones make for easy avenues of attack. Patching quickly would have been important to protect against attackers that had gained access to internal networks – but that should be a rare occurence in itself. Whoops. This introduced a bug: hashing and salting any string with crypt always returned the same value (the raw salt), regardless of the string to be hashed. Thus, if a web application accepts user input anywhere to a   serialisable field, users can provide arbitrary YAML for deserialisation. Build-in safe development practices
There are many morals to this story, but it’s particularly striking to consider how important project development practices were in this security issue. It’s also particularly worth looking for projects with well publicised security reporting mechanisms, preferably with published encryption keys, to allow exploit reporters encrypt the reported details for the maintainer’s eyes only. At the time, many services – including Heroku and EnterpriseDB – were attacked, and had to rush out fixes to avoid disaster. This wasn’t the first time a YAML bug had hit Rails. Curious users quickly discovered that many repositories included private information, including users’ SSH keys (giving write access to their GitHub), various usernames and passwords, and a selection of API keys for services –   both free and paid-for. It’s   also worth considering the security practices of your potential tools when evaluating them. In fact it’s possible to control the logged output too, and by directing the logging to an executable file likely to be run later, and appending code of your choice, you can run arbitrary code on the server (eventually, when the executable is later run). Publicly visible (and passing) build statuses are a   good sign, and consideration of testing and design are great too. It’s worth checking what components you currently allow external access to, and whether these   can be reduced.

Updated: 23.12.2014 — 06:20