Depois que as notícias foram publicadas há alguns dias, não ouvi muito - e nenhuma declaração oficial - sobre a mais nova vulnerabilidade. A Sucuri diz que é possível receber informações do cartão de crédito ou mesmo todos os $_POSTdados, incluindo senhas de administrador e similares.
Ainda não tive um caso em que um cliente foi invadido, mas não quero esperar até que isso aconteça. Alguém já viu um patch?
security
magento-ce
simonthesorcerer
fonte
fonte
Respostas:
Que tipo de patch ou declaração oficial você espera? A postagem do blog diz apenas que um aplicativo Web pode ser comprometido quando o invasor tiver acesso ao código. Isso se aplica a todo e qualquer aplicativo da web. O termo Magento é completamente intercambiável por lá. Atualmente, eles não têm idéia de como o host afetado foi comprometido. A porta aberta nos exemplos dados pode ser tudo, variando de problemas do servidor à "camada 8".
Contanto que permaneçam vagas e não apresentem informações valiosas, tudo isso significa marketing, como divulgar o nome da empresa, fazer ondas, posicionar-se como especialistas em segurança etc. Combinar palavras-chave como "roubar" "cartão de crédito" " Magento "faz uma boa história obviamente.
O que ainda podemos aprender com este post:
Atualização: Há uma declaração oficial de Ben Marks agora.
fonte
Desde que a sua versão do Magento esteja atualizada, você instalou todos os patches mais recentes e o servidor atende às práticas recomendadas em relação à instalação (permissões de arquivo, não outro software / site em execução, firewall etc.), é tudo o que você pode fazer por enquanto .
Eu acho importante mencionar que ainda não existe um vetor de ataque específico:
Editar:
Como mencionado no meu comentário acima, você também pode conferir a resposta detalhada de Ben Lessani para outra pergunta relacionada que fornece algumas informações básicas: /magento//a/72697/231
fonte
Não (apenas) Magento
Eu já vi muitos outros sites invadidos dessa maneira, inserindo código malicioso na base de código, e não apenas no Magento. E existem muitas variantes: scripts que roubam dados POST, scripts que adicionam XSS, scripts que tentam roubar senhas de raiz, scripts que permitem chamadas recebidas para processar dados (para mineração de Bitcoin, para enviar e-mails de spam desse servidor), etc.
Em alguns casos, a causa foi roubada credenciais de FTP (por vírus / malware) de um computador cliente; em outros casos, ela utilizou uma exploração no aplicativo.
Existem muitos outros aplicativos que podem fornecer acesso ao servidor através de explorações, por exemplo, WordPress.
Há apenas um caso em que o Magento seria o culpado e uma ação do Magento é esperada, ou seja: se o aplicativo explorado fosse o Magento da versão mais recente e totalmente corrigido.
Portanto, há apenas uma pequena chance de que este caso destacado tenha sido causado por uma falha no Magento em primeiro lugar. É por isso que você não ouve nada do Magento.
A novidade aqui é que o código inserido está visando especificamente o Magento e usando a arquitetura e os princípios do código do Magento.
O que fazer
Agora, para dar uma resposta à sua pergunta "O que fazer contra isso?"
Nunca execute dois aplicativos diferentes na mesma instância do servidor,
como o WordPress + Magento. Às vezes, você vê o WordPress rodando como em www.magentoshop.com/blog/ ou o Magento em www.wordpresswebsite.com/shop/. Não faça isso. Explorações no WordPress podem dar ao invasor acesso aos seus dados Magento.
Use um sistema de controle de versão
Estou usando o GIT e também o tenho no servidor (acesso somente leitura) para implantar o site. Isso também me fornece uma visão rápida das alterações no sistema executando
git status.Nunca use FTP, apenas SFTP, nunca armazene senhas
que mencionei acima que as senhas de FTP foram roubadas de um computador cliente. O uso do FTP também não é seguro, pois envia dados não criptografados pela Internet. Portanto, use SFTP e nunca armazene suas senhas em seu aplicativo FTP, apenas não seja preguiçoso e digite-as sempre que se conectar ao seu servidor.
fonte