From the talk they are doing about this at AppSecUSA (http://sched.co/3VgM):

    The only information which gets accessed and transmitted are listed below:

        1. Application Name
        2. Application Package Name
        3. Application Version Number
        4. Application Version Name
        5. SecureMe – Droid Search Depth setting (1-5 only)
        6. SecureMe – Droid Vulnerability Details settings (1 or 0)

You aren't sending anyone your APKs. The application exists to make searching Mitre's CVE database more convenient and automagic.

The developers are security consultants at Security Compass. The application is hosted in Montreal, Canada. (I work there as well, and can ask them to add an FAQ about this this stuff.)

Any chance of opening up the code for the client app? Given that the database is basically your golden egg, and given that this is security software, it would make sense to open it up.

I am member of the team behind SecureMe Droid. Right now we don't plan on open sourcing the Android code. But I would like to mention that the source code is not obfuscated.

We started the project back in 2012. It's an open source version of Campfire. :)

Our actual job is working on SD Elements (http://securitycompass.com/sdelements/). Let's Chat is just a side project, but it's also something we use internally everyday. The features you wish were there we also wish were there, no doubt. Lots of the developers here like working on it. I expect there will be updates from us for the foreseeable future. Hopefully we'll start getting more external pull requests as well.

I doubt we are going to pivot to a free chat client company any time soon.

That sounds good my friend!

We should add that we are using Gravatar to our Wiki. It's not obvious for people who aren't already using Gravatar what's going on.

It sounds like they listen on localhost by default (http://docs.mongodb.org/manual/reference/mongod/#options), though i'm not sure if that's always been the case. It's also possible installers change the default behaviour. (i.e. when you install via apt, yum, homebrew, etc.)

Good point, it might have changed recently and last I installed it on Ubuntu it listened on 0.0.0.0. It certainly would make a lot more sense to listen to localhost by default, which is what most daemons do.

I suspect a lot of people are using MongoDB as the database backend to their web applications or services, so they are probably being indirectly exposed to the Internet. (Just like your Postgres or MySQL database.)

I've never exposed a Postgres or MySQL database directly to the internet, either. They're always listening to localhost connections only, and the only code that gets to make direct calls into them is my code, which means input sanitization prevents attacks like this.

The same goes for my use of MongoDB.

Though I am curious if anything similar exists for CouchDB, as they seem to be encouraging dangerous configurations like that.

Same. I was trying to suggest the attack vector most people would encounter is the web application MongoDB is servicing.

Where does the post suggest Rails is the only framework with bugs like this? The article opens with: "The latest Rails security flaw is example of a common anti-pattern. ... a similar issue may also exist in Python’s YAML parser ... I am reminded of similar flaws in other frameworks and libraries." I don't think the goal here was to pick on Rails, but to highlight that its recent security woes might be a sign of a bigger common issue.

I'm responding to the comment above, not the post.

I don't read the comment in question as picking on Rails either ("... frameworks like Rails", it says).

Please see my comment downthread.

"Frameworks like every framework" seems like an unintended but accurate generalization that was worth pointing out.

You can use it to listen to music you like, or find new music. I'm using it right now to listen to the same stuff my coworkers are listening to in our office while I work from home. Does that help?

It wouldn't be a ponzi scheme if the value didn't go up, at least for a little while.