21–30 of 64 posts
Second - and any incident response team will tell you this - patching and removing the backdoor is not enough. You have to wipe that machine.
It's not uncommon for an attacker to leave multiple backdoors. Even if you don't think they got root, you have to wipe it completely.
Wow, all three customers?
Obviously you can also take the opinion that this should have never happened and question their competence and security. I personally weigh their response and transparency more than the issue itself, but it may seem easier since the impact to overall customers was relatively small.
Their response seems to have been handled well and may even generate some positive PR. That may change if it turns out to have been one of the recent Rails security flaws.
From the perspective of a complete server administrator novice, are all of the mainstream "hacks" due to the complexity of these applications? For example, if I were to setup a basic, updated Ubuntu Server LAMP stack with a MySQL database, is this system vulnerable? I understand how to protect against XSS and SQL injection and how to hash and salt passwords properly, but where can I begin to learn about implementing…
Excellent question. The answer really is, if you are running a "web app" with any kind of sensitive information, you need to have a security expert configure and administer your systems, or become one yourself, and you need to stay on top of every update.
Now, there are basic things you can do that will eliminate most of the casual script kiddie attackers. Firewalls. Defense in depth. Keeping up with patches. Google or any good book on computer security will provide this information. But the sad truth is, if a smart, determined attacker has you in his sights, you will most likely lose. And even the automated tools are getting better and better.
I think we are starting to see a tipping point in the web. More and more high profile sites are getting compromised. We have learned that China has been inside US government, utility, and industrial systems for years. Right now I would not trust any sensitive, personal information to any website or cloud service. I think we are going to see some major, consequential attacks on government, banks, and other commercial entities in the coming years. At some point I believe we are going to need to rethink the cost/benefit equation of having everything connected to everything.
Earlier quoted context omitted.
The big picture here is that three customers' data was compromised -- customers in this context means entire platforms using Zendesk for support, not users. If the customers were, say, WePay, Box.net and OpenTable (random companies taken from their portfolio), this is potentially hundreds of thousands of users. Also, it is a big deal because (as a former support person I know this), users often send in sensitive info…
The customers were Twitter, Tumblr and Pinterest. Wow, three of the biggest customers they have probably. And two, the body of the emails was not exposed, only the subject line. People typically don't but their SSN in the subject line...
http://www.wired.com/threatlevel/2013/02/twitter-tumblr-pint...
If you have a mid-sized Rails app, with say 2-3 developers working on it, a full time security engineer would probably be overkill. Anyone have any recommendations of services/consultancies to be able to tell "oh, someone is hacking us right now" or "our page which has stripe.js on it has been compromised"? I'm hoping for automated tools, services to install on our servers, or security auditors who have an out of the…
We don't do code analysis, but we think it's a useful service.
For the last 2.5 years, we've used a popular service called Zendesk to store, organize, and answer emails to Tumblr Support. We've learned that a security breach at Zendesk has affected Tumblr and two other companies. We are sending this notification to all email addresses that we believe may have been affected by this breach.
This has potentially exposed records of subject lines and, in some cases, email addresses of messages sent to Tumblr Support. While much of this information is innocuous, please take some time today to consider the following:
The subject lines of your emails to Tumblr Support may have included the address of your blog which could potentially allow your blog to be unwillingly associated with your email address. Any other information included in the subject lines of emails you’ve sent to Tumblr Support may be exposed. We recommend you review any correspondence you've addressed to support@tumblr.com, abuse@tumblr.com, dmca@tumblr.com, legal@tumblr.com, enquiries@tumblr.com, or lawenforcement@tumblr.com. Tumblr will never ask you for your password by email. Emails are easy to fake, and you should be suspicious of unexpected emails you receive.
Your safety is our highest priority. We're working with law enforcement and Zendesk to better understand this attack. Please monitor your email and Tumblr accounts for suspicious behavior, and notify us immediately if you have any concerns.
If you have a mid-sized Rails app, with say 2-3 developers working on it, a full time security engineer would probably be overkill. Anyone have any recommendations of services/consultancies to be able to tell "oh, someone is hacking us right now" or "our page which has stripe.js on it has been compromised"? I'm hoping for automated tools, services to install on our servers, or security auditors who have an out of the…
They are in beta.