Pular para o conteúdo principal
BlogLinodeRetrospectiva da Investigação de Segurança

Retrospectiva da Investigação de Segurança

blog-generic-triangles

Em 5 de janeiro de 2016, nós emitiu uma senha de redefinição para todos os clientes da Linode durante nossa investigação sobre o acesso não autorizado de três contas de clientes. Temos trabalhado com as autoridades federais sobre estes assuntos e suas investigações criminais estão em andamento. Hoje estamos compartilhando nossas descobertas e as da empresa de segurança terceirizada que contratamos para nos auxiliar nesta investigação.

Antes de mergulhar, gostaríamos de lhe assegurar que as informações de sua conta estão seguras. Encontramos apenas três clientes afetados por este incidente e resolvemos estas questões diretamente com eles.

O que aconteceu

Esta é uma retrospectiva complexa de duas investigações separadas, uma em julho e outra em dezembro. Embora os casos compartilhem semelhanças, não temos evidências que sustentem o fato de que as duas estão relacionadas. No entanto, aqui está um cronograma completo dos eventos, tal como chegamos a entendê-los.

Em 9 de julho, um cliente nos notificou sobre o acesso não autorizado à sua conta Linode. O cliente soube que um intruso havia obtido acesso à sua conta após receber uma notificação por e-mail confirmando a redefinição de uma senha de root para um de seus Linodes. Nossa investigação inicial mostrou que o login não autorizado foi bem sucedido na primeira tentativa e se assemelhava a uma atividade normal.

Em 12 de julho, em antecipação ao envolvimento da aplicação da lei, o cliente deu seguimento a um pedido de preservação de um Linode correspondente a um endereço IP que se acredita estar envolvido no acesso não autorizado. Honramos o pedido e pedimos ao cliente que nos fornecesse qualquer prova adicional (por exemplo, arquivos de log) que suportassem que a Linode fosse a fonte de atividade maliciosa. Nem o cliente nem as autoridades policiais deram seguimento e, como não examinamos os dados do cliente sem causa provável, não analisamos a imagem preservada.

No mesmo dia, o cliente informou que o usuário cuja conta foi acessada havia perdido um dispositivo móvel várias semanas antes contendo as credenciais 2FA necessárias para acessar a conta, e explicou que o proprietário tentou limpar o dispositivo remotamente algum tempo depois. Além disso, este usuário empregou uma senha fraca. À luz destas informações, e sem nenhuma prova de que as credenciais foram obtidas da Linode, não investigamos mais.

Em 9 de dezembro, um pesquisador de segurança independente entrou em contato conosco. O pesquisador alegou estar rastreando um indivíduo que havia roubado credenciais de vários outros prestadores de serviços. O pesquisador queria nos informar que o indivíduo poderia ter feito tentativas de usar essas credenciais roubadas para entrar em algumas contas de nossos clientes.

Nossa investigação inicial concluiu que os IPs fornecidos tinham, de fato, sido utilizados para entrar em três contas na primeira tentativa. Em outras palavras, o usuário chegou à página de login do Linode Manager com as credenciais necessárias para fazer o login, assim como qualquer usuário regular faria. Nesse mesmo dia contatamos os clientes e recebemos confirmação de cada um deles de que as atividades eram suspeitas. Também confirmamos que nenhuma dessas contas tinha autenticação multi-fator habilitada e todas tinham empregado senhas fracas.

Em 13 de dezembro iniciamos a manutenção necessária de toda a frota Xen Security Advisory (XSA), reiniciando servidores em suas horas noturnas locais 24 horas por dia. Embora não relacionado à investigação, isto continuou até 18 de dezembro e foi uma restrição significativa de recursos.

Em 14 de dezembro, embora não tivéssemos descoberto nenhuma evidência de intrusão em nossa infra-estrutura, começamos a entrevistar empresas de segurança terceirizadas e contatamos várias agências de aplicação da lei. Também dedicamos todos os recursos internos disponíveis ao esforço e começamos a examinar nosso ambiente para identificar qualquer evidência de abuso ou mau uso.

Em 17 de dezembro, devido às semelhanças entre este caso e o de julho, reabrimos o caso de julho e concluímos que agora tínhamos razões suficientes para examinar a imagem retida daquela investigação.

Linode utiliza TOTP para fornecer autenticação de dois fatores. Este é um algoritmo que utiliza uma chave secreta armazenada e compartilhada entre nosso servidor e o aplicativo de autenticação de dois fatores do cliente (como o Google Authenticator). O algoritmo gera um código sensível ao tempo que o usuário fornece durante o login como um componente adicional de autenticação. Encriptamos estas chaves secretas quando as armazenamos em nosso banco de dados.

Após examinar a imagem de nossa investigação de julho, descobrimos um software capaz de gerar códigos TOTP se fosse fornecida uma chave TOTP. Encontramos um software implementando o método de descriptografia que usamos para proteger as chaves TOTP, juntamente com a chave secreta que usamos para criptografá-las. Também encontramos comandos no histórico bash que geraram com sucesso um código único. Embora as credenciais encontradas não estivessem relacionadas a nenhum dos logins não autorizados do Linode Manager feitos em dezembro, a descoberta dessas informações mudou significativamente a seriedade de nossa investigação.

Em 21 de dezembro, nosso parceiro de segurança terceirizado se juntou à investigação. Esta equipe procedeu a uma análise forense para identificar qualquer atividade não autorizada ao nível do sistema que possa ter permitido a um intruso acessar as credenciais de clientes contidas em nosso banco de dados. A equipe também buscou evidências de uso indevido de aplicações web que teriam fornecido movimento lateral de uma conta do Linode Manager para outra. Além disso, a equipe iniciou uma avaliação de vulnerabilidade direcionada com o objetivo de identificar um possível vetor de ataque para obter acesso ao banco de dados da Linode.

Em 25 de dezembro Os ataques DDoS contra nossa infra-estrutura começaram. Embora não tenhamos nenhuma evidência que sustente que estes ataques estejam relacionados com os incidentes de acesso não autorizado, os ataques necessitaram de recursos para serem afastados de nossa investigação. Isto, combinado com a ausência de funcionários durante as férias, criou desafios adicionais para nossas equipes de apoio e operações.

Em 5 de janeiro, nosso parceiro de segurança concluiu sua investigação e nós emitimos a senha de redefinição. Nossa equipe de segurança interna continuou a rever nossa infra-estrutura durante as próximas semanas e desenvolveu um plano detalhado para melhorar nossa segurança geral.

Conclusões

As conclusões da investigação de nosso parceiro de segurança concluíram não haver evidência de abuso ou má utilização da infra-estrutura da Linode que teria resultado na divulgação de credenciais de clientes. Além disso, a avaliação do parceiro de segurança sobre nossa infra-estrutura e aplicações não produziu um vetor que teria proporcionado este nível de acesso.

A equipe de segurança da Linode descobriu uma vulnerabilidade no gateway SSH da Lish que poderia ter sido usada para obter informações descobertas em 17 de dezembro, embora não tenhamos evidências que sustentem esta suposição. Corrigimos imediatamente a vulnerabilidade.

Outras teorias consideradas que poderiam explicar o acesso não autorizado incluem um compromisso externo, como as senhas fracas mencionadas anteriormente sendo usadas com outros serviços online, ou ataques de phishing contra esses usuários.

O que estamos fazendo sobre isso

Estamos usando o que aprendemos para fazer melhorias abrangentes em nossa infra-estrutura, incluindo áreas não relacionadas ao incidente. Aqui estão algumas das coisas para as quais temos trabalhado:

Micro-serviço de autenticação: Várias de nossas aplicações (como o Linode Manager e a Lish) realizam a autenticação do usuário. Anteriormente, estas aplicações realizavam esta função tendo acesso às informações de credenciais diretamente dentro de nosso banco de dados, e depois realizavam as próprias comparações. Desenvolvemos uma nova abordagem que envolve um microserviço cuidadosamente protegido e monitorado que mantém a propriedade de todas as credenciais dos clientes. Sob este método, quando uma aplicação requer autenticação de usuário, o microserviço é capaz de validar as credenciais devolvendo um simples "sim" ou "não". Os aplicativos não terão acesso às informações das credenciais. De fato, os bancos de dados que alimentam nossa infra-estrutura não conterão nenhuma informação credencial quando a implantação deste microserviço estiver completa. Além disso, senhas de clientes, previamente armazenadas como hashes SHA-256 salgados com milhares de rodadas, serão armazenadas usando bcrypt e serão atualizadas sem problemas em um login subseqüente.

Notificações do Linode Manager: Estaremos trabalhando para melhorar as notificações que nossos clientes recebem sobre suas respectivas atividades de conta, incluindo alertas de tentativas de login a partir de novos endereços IP e logins falhados.

Tokenização CC: Apesar de nossa investigação não ter produzido nenhuma evidência de acesso às informações de cartão de crédito, estamos aproveitando o recurso de tokenização de nosso processador de pagamento para remover o risco associado ao armazenamento de informações de cartão de crédito.

Política: Temos desenvolvido múltiplas políticas derivadas da estrutura do NIST sobre tópicos que vão desde clean-desk a padrões de senha. Uma nova política significativa é a criação de "zonas de segurança" para elementos sensíveis da infra-estrutura, como nosso banco de dados e servidores de autenticação. Os resultados desses esforços reduziram muito o número de funcionários que têm acesso a sistemas e dados sensíveis.

Contratação: Além das mudanças descritas acima, estamos contratação de um especialista em segurança de nível sênior para juntar-se à nossa empresa e liderar uma equipe maior de engenheiros focada em tempo integral na segurança. Esta equipe não apenas garantirá que estamos seguindo as melhores práticas atuais, mas também expandirá nossas políticas escritas, formalizará nossos procedimentos de provisionamento e fundamentalmente garantirá que nossas políticas sejam apoiadas por processo e responsabilidade.

Um novo Linode API: Nossa estratégia mais importante a longo prazo é uma reescrita de nossa base de códigos legada ColdFusion que nos dá a oportunidade para um novo começo e para aplicar as lições que aprendemos ao longo dos últimos 13 anos. Para isso, estamos construindo um novo Linode API que é sem Estado, RESTful, e implementado em Python. Estamos trabalhando nisto há muitos meses e anunciaremos um alfa público do novo API nas próximas semanas.

Gerente de Código Aberto Linode: Este novo API será a base para todas as coisas que virão no futuro, incluindo um Linode Manager de Código Aberto que substituirá o atual gerente.

Olhando em Frente

Reconhecemos que temos espaço para melhorias quando se trata de comunicação e transparência. XSAs e ataques persistentes de DDoS ao longo de dezembro, apesar disso, deveríamos ter comunicado a natureza e a extensão dos ataques DDoS e este incidente de segurança a nossos clientes mais cedo. Dizer que estávamos com os recursos limitados na época seria uma avaliação justa. Ainda assim, poderíamos ter feito melhor e desde então fizemos mudanças processuais para garantir a nomeação de um membro da equipe para eventos importantes como estes no futuro para facilitar a comunicação frequente e transparente com nossos clientes.

Somos incrivelmente gratos aos clientes que nos apoiaram ao longo destes eventos. Ouvimos suas recomendações e sentimos o apoio que você nos deu durante os últimos meses. Saiba que continuamos ouvindo e agindo de acordo com seu feedback.

Concluiremos dizendo o quanto lamentamos se o decepcionamos. Valorizamos a confiança que você depositou em nós como seu provedor de hospedagem e estamos comprometidos em ganhar essa confiança todos os dias. Esperamos que os detalhes fornecidos aqui esclareçam algumas informações errôneas e demonstrem nossa disposição para abordar as oportunidades de melhoria, fazer o que está certo e aumentar a comunicação e a transparência com vocês, nossos clientes.


Comentários (17)

  1. Author Photo

    *”…we are incredibly grateful for the customers who have supported us throughout these events… [we] felt the support you’ve provided over the past few months… We value the trust you’ve placed in us…”*

    Nice sentiments, but words are cheap. You could have shown your appreciation by giving people some money off their bill for the period in question

  2. Author Photo

    If there is to be a new Linode Manager, please please PLEASE do not try and “modernize” or “streamline” the interface like Namecheap did. I like my utilitarian and functional Manager.

  3. Author Photo

    “We found software implementing the decryption method we use to secure TOTP keys, along with the secret key we use to encrypt them. We also found commands in the bash history that successfully generated a one-time code.”

    How do you explain the presence of software using the decryption method you use to secure TOTP keys, along with the secret key you use to encrypt them?

  4. Author Photo

    There are always some bumps on the road, sometimes these are big and hard to pass thru, but I think that you’re on the right track.

    Keep up the good work 🙂

  5. Author Photo

    The most significant take away for me is that Linode is becoming more transparent. Please continue down this path.

  6. Author Photo

    Good news for the new Linode manager, is there any ETA?

  7. Author Photo

    Long-term customer here. I appreciate all the effort made during the difficult time over the holidays. However, I have asked for 2FA by SMS rather than google authenticator (or in addition to), and was told it will not be happening. It seems that this breach could have been avoided at least in part if 2FA by SMS had been used. The user who lost his phone would have moved his phone number to his new phone as soon as it was replaced. The entire compromise of the TOTP algorithm would not have been possible. So my request, and recommendation still stands; give us 2FA by SMS if we want it.

  8. Author Photo

    I know how difficult these situations can be and wish you all the best in your continued growth and improvements. Unfortunately, I’ll be switching to another provider after reading this. I stuck around waiting for an explanation that I hoped would satisfy my concerns and this certainly doesn’t do that… There is reasonable evidence that your story regarding the cell phone is incorrect. In my opinion you should have had a senior security director years ago. Given the nature of the July incident, that image going unexamined is mind boggling and no explanation is given about how the 2FA crypto keys could have ended up on that system. It sounds entirely plausible your infrastructure got breached in July or earlier by a skilled attacker and the evidence is simply not there months later.

    It sounds like you’re moving in the right direction, but those are some seriously poor decisions by those in charge and I’ve lost confidence that further mistakes won’t be made.

  9. Author Photo

    I like the current Linode manager. It’s simple and fast and clean. Please don’t change it too much. (Don’t go all Namecheap on us)

  10. Author Photo

    I’m a longtime Linode customer as well. After reading up on this latest incident I am seriously considering moving my infrastructure to another provider. I’ve been through a number of these cases with Linode and so far have been unaffected and given them the benefit of the doubt. I completely understand that threats are uncovered and exploited and that’s a risk you take with any provider. This isn’t about me taking a knee jerk reaction. I’m fully aware that other providers have been exploited as well but Linode have had multiple exploits and that is reason for concern.

    In this post you state that you found software on a client’s VPS generating login credentials using a very private piece of your data and a piece of data that can be used to decrypt other customers data and you have no idea how it arrived on a clients machine and you don’t really seem bothered by that or at the very least you gloss over it. Have you audited every other instance to ensure they’re not also capable of generating keys/decrypting data? From my knowledge of this, the client in question was PagerDuty who alerted you after their own intrusion detection system picked up on the login. By your own account the initial illegal access looked like a legitimate login to your systems and didn’t raise any alarms. You also state that you don’t inspect customers instances without probable cause. So we have to assume that there might be other malicious software running in your infrastructure that you are not aware of and it’s allowing access that isn’t raising alerts.

    You say that only three customers were accessed under suspicious circumstances. On that face of it that looks like a small number, considering you have a large client base. However, from what I can gather these were large and notable customers PagerDuty and WPEngine, I believe. That, to me sounds less like a percentage risk and more like plucking high value targets. I’m only a small customer so it’s probably more out of luck that I haven’t been affected rather than my details not actually being available.

    Linode has offered a product that’s very valuable to me and my business. It’s provided reliable hosting and features. I chose them because I felt they would be able to support any application that I need to grow without the fuss of moving providers. I no longer have that confidence. The previous attack against Linode resulted in credit card loss and it’s only now that you are looking at tokenizing credit cards and moving to bcrypt for hashing?

    I do appreciate that resources get stretched and trying to pick out relevant data and act on it is really difficult in a growing business. But the lack of security awareness at Linode has got to a point not where I feel I can’t trust it with my business which is sad because my experience with them has been positive, well if you put aside data breaches, credit card loss and their private keys ending up on clients’ VPSs and inability to communicate.

  11. Author Photo

    “We also found commands in the bash history that successfully generated a one-time code”

    I don’t get how you saw this and the investigation concluded that “the security partner’s assessment of our infrastructure and applications did not yield a vector that would have provided this level of access.”

    I mean, I don’t understand why someone have a bash on your systems, how he achieved that and what changed so he can’t do it in the future

  12. Author Photo

    Just FYI, I’ve been forced to spend considerable ongoing time and money investigating other services and finally choosing a viable non-Linode. This is money that could have been spent on better things, even if it had just been more Linode servers. Outside 3-4 work weeks redirected, my computing budget doubled even after whittling down my 4 Linodes to two.

    You might consider joining forces with a cooperative and reputable industry counterpart in an effort to provide more viable business recovery scenarios for your mutual customers. In my case, now I have both a dedicated server vendor and Linode, a solution that is not neither pleasant nor economical. Each has complementary benefits.

    I hope that your security efforts prove successful and I concur with the comments that should you change the inside workings of the Linode manager, it should remain simple and shun any feature that is only cosmetic.

  13. Author Photo

    I agree with the poster above that Linode appears to be going down a path of greater transparency. I’m extremely happy to see this.

    I also believe that full disclosure and admitting fault where necessary is a very honorable thing, and you are to be commended for what you’ve said here.

  14. Author Photo

    Odd, all this transparency is making some people think there is a lack of security knowledge at Linode. Guys, you’d have this or worse at practically any other company.

    Sounds like almost this entire thing boiled down to a few customers who have no clue about security to begin with. Weak passwords and a mobile device that doesn’t have a screen code to lock the phone. Sigh, sorry Linode had to go through all of that because of a few lazy people, but it does look like they’ve learned a lot and are improving and moving forward.

    Kneejerk reacting will only put you with someone else, that probably isn’t doing the same thing as Linode.

    Keep up the great works guys and I’m glad to see the improvements.

  15. Author Photo
  16. Author Photo

    If you are going to update the Linode Manager API, *please, please, please* give us the ability to do programmatic snapshots.

    Thank you.

  17. Author Photo

    I greatly appreciate the explanation and transparency. So very different than other companies. This is the kind of thing that creates customer loyalty.

Deixe uma resposta

Seu endereço de e-mail não será publicado. Os campos obrigatórios estão marcados com *