Show HN: AppCanary – Keep vulnerable software off your servers | Hacker News Reader

Show HN: AppCanary – Keep vulnerable software off your servers

appcanary.com

108 pointsphillmv59 comments

You may want to rethink the pricing. I have several server variants that I effectively clone in different datacenters across my deployment. Since the base images are static I would really only need to run the agent on n servers (where n is the number of server variants that I have) to ensure that my entire deployment is protected.

I'm not sure if you would consider this unethical. I would probably feel differently about the pricing if it were tiered levels related to the entire size of the deployment (e.g.: 1-50 servers: $x/mo, 50-250 servers: $y/mo, 250+ servers: $z/mo).

>I would probably feel differently about the pricing if it were tiered levels (e.g.: 1-50 servers: $x/mo, 50-250 servers: $y/mo, 250+ servers: $z/mo).

Ya, that's fair and a good suggestion. I think we may very well end up doing something like that. We're still trying to figure out what kind of model best suits the server fleets people have.

We'll be keeping the first server free, and probably have a not for profit tier.

As an added note, $9 per server doesn't seem excessive when I think of our large bare metal servers, but it starts looking _really_ pricy if I look at our $50/mo m3.mediums in AWS.

Sampling like this is precisely what a lot of folks do with New Relic as well. It would be extremely dubious if they disallowed that.

Hey everyone!

appCanary monitors the software on your servers and notifies you when you have to take action. In a previous life, we spent a lot of time worrying about what needs to be updated where and so we built this.

We currently let you know about Ruby vulns deployed on any linux, and vulnerable packages if you run Ubuntu. Support for Docker and other vuln sources is just around the corner.

We'd love to hear your feedback!

How can you figure out whether a software is vulnerable? Parsing public CVEs and matching with version number?

Unless they're watching updates from repos, it'd be very hard to automate this. CVEs are very far from reliable.

This looks interesting. I have been looking for a solution to this problem without any clear conclusions so far. Nessus and Qualys have new agent-based scanners now, but I have not tested them because they both only support Red Hat-based Linux distros.

It sounds like for most software you are using the Ubuntu package management system to check for vulnerable versions. Is that correct? And are you planning to add detection for binaries that live outside of the distro package manager? I am thinking of stuff like custom-compiled Nginx binaries for example. I realize it would be non-trivial to implement this but would consider it highly useful at least for a certain set of common software components.

>And are you planning to add detection for binaries that live outside of the distro package manager?

It's on the roadmap! Others have mentioned that before. First we need to get really good at knowing about CVEs :).

If you can solve this people will throw boatloads of money at you.

Unfortunately it's not easy -- even writing scripts to detect running processes across all our servers to identify Java, Apache, Tomcat, etc etc has proven difficult to get right. Sometimes you can get enough info from extended process list info, sometimes not.

Sucks.

What advantage do I gain from this over periodically running various distro tools that compile CVEs and security advisories into a flat file database and search on top of that, e.g. pkg audit on FreeBSD and glsa-check on Gentoo?

We only show you stuff that affects you, we automate the process, we light up your call tree and we'll be providing metrics and audit logs.

It's definitely a leg up over just being spammed by pkg audit.

Further, we also cover your app dependencies :).

Any way of cheaper pricing for VMs? We have a bunch of VMs that run on not-our-host-node, so it would be effectively $9 for a 256MB RAM instance.

We're still getting started, so - give it a spin, and we won't charge you until it's worth your while.

At my day job I am stuck on a Windows IIS stack.

Any plans for windows servers? I'd honestly prioritize this after application dependencies checking for Java/Node etc, but just thought I'd ask.

Check out Mike Taber's¹ cross-platform work-in-progress: https://www.auditshark.com/

It is targeted more at OS-level vulnerabilities (including IIS) rather than application dependency vulnerabilities, but may provide the solution you're looking for.

¹ https://news.ycombinator.com/item?id=9492839

Competing solutions include SCCM, Applocker, and Application Whitelisting.

How does this work? Do I need to run your software on my servers? A software calling home to some third party seems to be a problem for many use cases.

It's very small and written in golang and up on github https://github.com/appcanary/agent/

We understand how some people might have problems / have plans to improve upon it - maybe we run a proxy or some kind of enterprise edition.

But we think the main pain relief comes from knowing what you have deployed is now fixed.

So you're cataloging the software installed and then monitoring for CVEs?

There's a stunning amount of elbow grease involved in that.

If you're a random company, you have an engineer sitting around whose job involves reading a dozen mailing lists - and we want to save everyone from that redundancy.

Oh yeah I know, I think there's value in what you're trying to do. I would pay 9/m if it also covered application dependencies. I was just curious how it works. What's the time between CVE release and getting a notification from your service?

Well, fortunately, it does!

We currently support Ruby, and in the next three months we'll have Javaland and Python and Node.

Right now most of our data is oriented around patch releases, so it can vary, but in near future we'll be reducing that distance.

+1 for Python. You're probably aware of a company called Sonatype that does something like this during the dev process. Their business is growing fast. As far as I know nobody is doing this in production. I think you've found a nice niche that has a lot of potential. Good luck.

And that's why there are Linux distributions with security teams doing that work for everybody.

How is this service different?

1. They all do a great job! But there's this last mile problem with managing the information they do put out.

If you can handle the downtime, unattended-upgrades will work just dandy. If your postgres restarting in the middle of the night gives you pause, our service can help you choose how to roll out your security upgrades.

2. We cover app dependencies as well! For now just Ruby, but others as well pretty soon.

I'm one of the maintainers of the Ruby Advisory Database https://github.com/rubysec/ruby-advisory-db/ - and we know all about the effort involved.

Currently, there is no straightforward way of checking Ubuntu package versions against CVEs. Debian provides this through debsecan[1], but this tool is pretty much broken on Ubuntu[2].

[1] http://www.enyo.de/fw/software/debsecan/ [2] https://bugs.launchpad.net/ubuntu/+source/debsecan/+bug/9592...

Correct, but if this will reduce the 0-day / 1-day time then it's very useful if your server does anything important. The difference between responding to Shellshock in 15 mins vs 2 hours could be exploitation.

"just" , there are very well paid full-time people working in big name companies doing pretty much this. Auditing is a real big pain, and this is certainly not the first company trying to address this.

Won't a database of vulnerable servers be something of interest for hackers?

Are you confident in your own infrastructure?

Maybe a PGP key instead of a javascript form for submitting a secret to setup the account?

This is a problem everyone in the security space faces.

We used to work as security consultants, so we're more experienced than most, and we're working hard to be transparent and above board.

As we grow, we'll definitely be conducting regular audits of our infrastructure.

I had that exact idea a while ago and filed it into my "ideas that might be fun and might be successful" list. Time to cross it off. Good luck with this, it's a great idea!

I put together a basic chef cookbook to configure this today:

  https://github.com/bitmonk/chef-appcanary

CentOS / RH / Fedora support isn't in, yet, and for kitchen to pass, you have to edit .kitchen.yml to set your api key.

Tomorrow or this evening I'll finish that up and show its' use in a wrapper cookbook.

Apologies if I'm misunderstanding as I only skimmed the source code but..

Why are you sending the full file contents from the agent to the client?

https://github.com/appcanary/agent/blob/master/agent/agent.g... agent.client.SendFile(file.Path, file.Kind, contents)

Extremely insecure design with a ton of unnecessary overhead. What if those files are configuration files with sensitive data embedded?

>Why are you sending the full file contents from the agent to the client?

1. We only send files you tell us to send in the configuration, and you're not going to be storing any sensitive information in your Gemfile.locks or package.jsons.

It's not functionally any different from us parsing it client side - but allows us to support new platforms without having to update the agent.

>CRC is not a hashing algorithm.

2. You're absolutely correct! Which is why we're not using it as a cryptographic hash, i.e. as part of an HMAC.

We're only using CRCs to determine if a file has changed, which is the purpose of CRCs :).

Do you have any other concerns? We've spent a lot of time being paranoid, and we know it's a hard communication problem.

So is the idea here that you're just monitoring the libraries my web application is using? So for example:

1. I have library X version 1.2.3 in package.json.

2. My package.json file gets sent to you

3. You parse this file, and tell me library X version 1.2.3 has a vulnerability, and that I should upgrade

AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?

>AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?

It does! So long as you've installed it via the package manager. Right now we support Ubuntu, and Debian will be out soon and RHEL systems in the very near future.

In the near future we'll add the ability to scan hand-compiled binaries, but that's a technical challenge that depends on solving the first part of the equation (knowing what's vulnerable) really well.

"You're not going to be storing any sensitive information in your Gemfile.locks"

That's not accurate. When using private gems hosted on github one of the common approaches is to use this in your Gemfile (which shows up in the lock):

gem 'my_private_gem', :git => 'https://github_user:cool_password@github.com/organization/my...

Right. I should've been prepared for this response. I can't confirm whether that shows up in your Gemfile.lock but I can say that you really shouldn't be doing this and switch to keys.

We'll likely add a check to beg you to change this in the near future should it show up.

I agree with you there but to this point at least, I haven't seen another good way to handle this with something like Heroku. It does show in the Gemfile.lock though (just verified).

Looking around I did just find a buildpack that tries to solve the problem. That doesn't really apply when using your service on my own servers though.

https://github.com/siassaj/heroku-buildpack-git-deploy-keys

I guess the bigger question is simply, are you going to limit your audience only to people already following best practices?

An SSL when transferring over these files, just based on the rest of the responses in this thread, would seem to make a lot of people feel better about the service.

>I guess the bigger question is simply, are you going to limit your audience only to people already following best practices?

No, of course not! We desperately want to bring people into best practices.

Most people are simply unaware of what they're doing wrong - or have no good means of knowing what to improve.

It's our great hope we can improve everybody's security.

>An SSL when transferring over these files

Yup! All communication happens over SSL :D.

We have elaborate plans to even add certificate pinning to the agent but that's on pause until we sort out larger infrastructure architecture.

Thanks for pointing that out as well. I've noted this elsewhere, but communicating how much effort we've poured into this is hard!

I like the idea but most of the servers we manage have out going firewalls to block them from talking to the internet. We produce installed package lists during deployment (as much as possible we run immutable pre-built images and replace the image rather than upgrade in place) which could be sent to a service like this but wouldn't want to start punching holes and adding routes for it. To work as is we'd need to add duplicate canary servers in an isolate environment to talk to the service.

> $9 per server

How does this affect containers?

Docker shall be addressed soon!

We'll probably end up sitting on your host and taking a peek inside your container filesystems.

@phillmv - +1 for the Docker+supervisord version !

Would strongly recommend an "in-container" version, so that I can bake your agent into my Docker VMs. Remember that if I run my Docker VM on CoreOS, then it is very hard to install something on the host.

It could be a separate docker container with a volume mount to the docker sock. That's probably the best option, a bit better than baking it into all of your images.

i was wondering if there's an interactive version of this I could run in CI (e.g. test-kitchen), so that I can fail CI when the results of a fresh CM build is vulnerable.

Sounds interesting! Is the vulnerability scanner of Gemfile based on bundler-audit[1]? Do you add other value to this part?

[1] https://github.com/rubysec/bundler-audit

A couple of years ago there was a similar startup called SourceNinja. They used a different method to get the dependency/library info though. It turned out to be not as profitable as they hoped...

"Hey Hacker News! Try out our pilot program." Just sign here.

It's another wannabe startup that asks people to sign up before disclosing terms, or, in this case, anything at all. And they want access to your server. Right.

No business address on the site. A low-rent "domain control only validated" SSL cert. Anonymous domain registration. They do show up as a Delaware corporation, all of two months old:

    CANARY COMPUTER CORPORATION
    File Number:  	5749511
    Filing State:  	Delaware (DE)
    Filing Status:      Unknown
    Filing Date:  	May 18, 2015

They're not known to Dun and Bradstreet, so you can't do a background check on them. Those are all scumbag flags.

I also hate it when there's a total void of info.

But! We're not yet launched, and I'm pretty easy to google :).

Well, I for one can vouch for the technical co-founder as I know him personally and worked with him before. But I'm just another HN lurker with barely any karma.

Thanks, that's very kind!

Just one correction, we're both technical co-founders :)

In fact, I'm the one wearing the sales bizdev hat today.

- Max, one of the two technical co-founders of appCanary

In that case I can vouch for Max because of personal knowledge and for you to a lesser extent by association :-)

I think "scumbag flags" is an extremely inflammatory conclusion to jump to. How about these are all signs for "just getting started"?

Sure, if you don't want to do business with a brand new startup, just wait a bit for them to mature. But no need to sound the snake oil alarm.

That being said, putting ToS and privacy policy links on the signup and main page would be a good idea.

That's not enough. This unknown, anonymous outfit wants you to trust them to collect info about security vulnerabilities on your site. That's asking a lot.

Remember, in B2B you're selling to the main in the chair[1]:

    I don’t know who you are.
    I don’t know your company.
    I don’t know your company’s product.
    I don’t know what your company stands for.
    I don’t know your company’s customers.
    I don’t know your company’s record.
    I don’t know company’s reputation.
    Now—what was it you wanted to sell me?

Now see the modern version of this: [2]

[1] http://rhodescomm.com/_blog/Observations/post/Why_You_Should...

[2] https://www.youtube.com/watch?v=nXG7zYWKHGU

$9/server? lol.

Reply on news.ycombinator.com