Episódio 1
Venho pelo presente informar sobre o site [nome do site] que:
Esse site [nome do sistema] foi invadido por terem sido deixadas vulnerabilidades, o material que estava lá foi totalmente contaminado com scripts perigosos- retornei o backup que eu tinha mas se vcs tiverem um backup que não esteja infectado basta subir de novo mas atenção estava totalmente aberto e o material lá não pode ser usado tem que ser do backup antigo - antes de ser invadido senão vai cair de novo em pouquíssimo tempo!
-----------------
Episódio 2
Complementando por gentileza acesse os links abaixo para conhecer algo sobre as falhas de segurança e vulnerabilidades do [nome do sistema].
Como foi mencionado anteriormente nossos registros comprovam que a entrada foi feita através de vulnerabilidades do próprio [nome do sistema] ou através do uso do login e senha corretos ou seja não foi uma entrada forçada.
Por esse motivo não podemos concordar com a alegação de que:
“Quanto à questão das vulnerabilidades, nossos sites são desenvolvidos sempre no mesmo padrão, utilizando a plataforma [nome do sistema] que é bem estável no mercado. Não tivemos problemas em nenhum outro sistema ou site, a questão de invasão ou vulnerabilidades no servidor de hospedagem não nos cabe.
Adicionalmente:
“se assim for, e pelo que ocorreu na sua esfera de atuação - hospedagem do site, preciso que você como técnico entre em contato com o fornecedor/desenvolvedor do site, pois na associação não temos nenhum técnico que trabalhe nesta área. Entre vocês, técnicos e prestadores de serviços, é preciso que se alinhe estes pormenores, para que os problemas não voltem a ocorrer e para que o site atual (e não o antigo) esteja ativo assim que possível.”
Quanto a esse parágrafo só podemos esclarecer que conforme os links anexos que mostram que esses tipo de vulnerabilidade é mais que conhecida devo mencionar apenas que exatamente pelo fato de as vulnerabilidades serem do soft usado, não temos como controlar isso pois se o site tivesse sido invadido através de vulnerabilidades do servidor a responsabilidade seria exclusivamente nossa mas como foi invadido por vulnerabilidades do soft usado pelo desenvolvedor não podemos controlar uma vez que ele usou o que escolheu entre as ferramentas disponíveis e não fomos consultados sobre o aspecto segurança nesse caso.
Atenciosamente,
-----------------
Episódio 3
Boa tarde T., o que acontece é o seguinte, o [nome do sistema] como outros softs do tipo são aplicativos usados por milhões de pessoas, empresas e organizações no mundo todo por ser uma ferramenta de baixo custo pois é open source (código aberto tipo Linux). Acontece que exatamente por isso é alvo de muitos hackers e crackers que sabendo os caminhos conseguem entrar em quase qualquer sistema, até na NASA, de modo que quando um deles descobre uma brecha ele acaba tendo um potencial de invasão muito maior pois pode invadir milhões de usuários em vez de um só. Além disso o [nome do sistema] como os outros softs similares aceita módulos adicionais que são feitos por desenvolvedores independentes ao redor do mundo e distribuídos via internet. Esses módulos adicionais complementam as funções do sistema principal mas por serem feitos independentemente podem ter vulnerabilidades maiores pois o nível e a intenção dos desenvolvedores não é sempre o mesmo, multiplicando o risco. A solução nesses casos é a empresa que desenvolve o site manter sempre uma atualização contínua pois sempre que são identificadas falhas de segurança elas são espalhadas na internet para os dois lados, bandidos e mocinhos e então são também distribuídos pacotes de correção e atualização. É por isso que todos os sistemas , Windows, IOs, Linux, Android e outros softs em geral estão sempre sendo atualizados pelo fabricante, pois esse é um processo dinâmico mesmo, a oposição não dorme. Porém não podemos deixar de considerar a possibilidade de invasão por uma máquina da rede.
Se uma máquina que tem o login e senha de acesso ao seu sistema salvo em qualquer local ou forma não criptografada for invadida o hacker pode usar todas as senhas inclusive essa para entrar e fazer o que quiser de modo que nesse caso não adianta cerca elétrica por que o bandido tem a chave da porta. Em relação ao sistema de hospedagem não há nada que precise ser alterado pois o servidor aceitou um usuário que acessou o sistema por meios admitidos pelo software que está instalado ou seja ou ele usou um login, ou ele usou um script que envia instruções que foram aceitas pelo [nome do sistema] ou por um de seus acessórios e que permitiram o acesso e controle total do site.
Como já havia mencionado quando um problema desse tipo é detectado rapidamente e um trabalho defensivo e corretivo é feito a tempo, sempre podemos ter um backup relativamente seguro. Relativamente por que essa invasão pode ter várias fontes - por exemplo se sua máquina estiver sendo monitorada não adianta mudar senhas pois você entrega as senhas novas assim que as utiliza. Ou então pode ser um script que estava instalado há tempos e então foi ativado em uma data - por exemplo no seu caso foi usado o final de ano exatamente para atrasar a descoberta do problema como no caso de sexta-feira treze e outros virais que já ocorreram. Nesse caso pode estar há meses e portanto estar dormente no backup.
Por tudo isso o correto é usar uma cópia que esteja com o desenvolvedor pois assim sai do original mas mesmo assim é importante conferir se ela não incorpora falhas de segurança descobertas mais recentemente pois se isso ocorrer você estará livre do atual invasor mas vai arrumar outro rapidamente. Esse é o motivo do lançamento constante de atualizações por parte das softhouses e o mesmo ocorre no caso do [nome do sistema] e afins, e também uma das razões por que as empresas acabam muitas vezes investindo mais e usando software desenvolvido exclusivamente para elas pois isso elimina as falhas de segurança mais comuns que acontecem nos produtos de massa, mas isso realmente é uma solução mais cara do que o uso de plataformas gratuitas.
Temos backups permanentes mas como expliquei para a Majida, nesse caso depois de mais de uma semana da invasão as cópias que estão arquivadas estão todas iguais ou seja invadidas e destruídas pois já foram feitas em cima de um original contaminado. Se o problema fosse descoberto no dia pegaríamos algo de uma semana atrás mas mesmo assim como expliquei não seria exatamente uma garantia, teriam que ser procuradas anomalias nos arquivos - geralmente confrontando e comparando com os originais do desenvolvedor, e inseridas as correções de segurança que se fizerem necessárias. O motivo por não haver tocado nenhum alarme em nosso sistema em relação a esse problema foi que não houve tentativa de invasão do servidor nem ocorreram tráfegos suspeitos o que acontece quando o invasor tenta usar o seu sistema para o envio de emails em massa (SPAM).
Precisando de algo mais em que possamos ajudar por gentileza entre em contato.
Atenciosamente,
-----------------
A., ou O Cliente
Venho pelo presente informar sobre o site [nome do site] que:
Esse site [nome do sistema] foi invadido por terem sido deixadas vulnerabilidades, o material que estava lá foi totalmente contaminado com scripts perigosos- retornei o backup que eu tinha mas se vcs tiverem um backup que não esteja infectado basta subir de novo mas atenção estava totalmente aberto e o material lá não pode ser usado tem que ser do backup antigo - antes de ser invadido senão vai cair de novo em pouquíssimo tempo!
-----------------
Episódio 2
Complementando por gentileza acesse os links abaixo para conhecer algo sobre as falhas de segurança e vulnerabilidades do [nome do sistema].
Como foi mencionado anteriormente nossos registros comprovam que a entrada foi feita através de vulnerabilidades do próprio [nome do sistema] ou através do uso do login e senha corretos ou seja não foi uma entrada forçada.
Por esse motivo não podemos concordar com a alegação de que:
“Quanto à questão das vulnerabilidades, nossos sites são desenvolvidos sempre no mesmo padrão, utilizando a plataforma [nome do sistema] que é bem estável no mercado. Não tivemos problemas em nenhum outro sistema ou site, a questão de invasão ou vulnerabilidades no servidor de hospedagem não nos cabe.
Adicionalmente:
“se assim for, e pelo que ocorreu na sua esfera de atuação - hospedagem do site, preciso que você como técnico entre em contato com o fornecedor/desenvolvedor do site, pois na associação não temos nenhum técnico que trabalhe nesta área. Entre vocês, técnicos e prestadores de serviços, é preciso que se alinhe estes pormenores, para que os problemas não voltem a ocorrer e para que o site atual (e não o antigo) esteja ativo assim que possível.”
Quanto a esse parágrafo só podemos esclarecer que conforme os links anexos que mostram que esses tipo de vulnerabilidade é mais que conhecida devo mencionar apenas que exatamente pelo fato de as vulnerabilidades serem do soft usado, não temos como controlar isso pois se o site tivesse sido invadido através de vulnerabilidades do servidor a responsabilidade seria exclusivamente nossa mas como foi invadido por vulnerabilidades do soft usado pelo desenvolvedor não podemos controlar uma vez que ele usou o que escolheu entre as ferramentas disponíveis e não fomos consultados sobre o aspecto segurança nesse caso.
Atenciosamente,
-----------------
Episódio 3
Boa tarde T., o que acontece é o seguinte, o [nome do sistema] como outros softs do tipo são aplicativos usados por milhões de pessoas, empresas e organizações no mundo todo por ser uma ferramenta de baixo custo pois é open source (código aberto tipo Linux). Acontece que exatamente por isso é alvo de muitos hackers e crackers que sabendo os caminhos conseguem entrar em quase qualquer sistema, até na NASA, de modo que quando um deles descobre uma brecha ele acaba tendo um potencial de invasão muito maior pois pode invadir milhões de usuários em vez de um só. Além disso o [nome do sistema] como os outros softs similares aceita módulos adicionais que são feitos por desenvolvedores independentes ao redor do mundo e distribuídos via internet. Esses módulos adicionais complementam as funções do sistema principal mas por serem feitos independentemente podem ter vulnerabilidades maiores pois o nível e a intenção dos desenvolvedores não é sempre o mesmo, multiplicando o risco. A solução nesses casos é a empresa que desenvolve o site manter sempre uma atualização contínua pois sempre que são identificadas falhas de segurança elas são espalhadas na internet para os dois lados, bandidos e mocinhos e então são também distribuídos pacotes de correção e atualização. É por isso que todos os sistemas , Windows, IOs, Linux, Android e outros softs em geral estão sempre sendo atualizados pelo fabricante, pois esse é um processo dinâmico mesmo, a oposição não dorme. Porém não podemos deixar de considerar a possibilidade de invasão por uma máquina da rede.
Se uma máquina que tem o login e senha de acesso ao seu sistema salvo em qualquer local ou forma não criptografada for invadida o hacker pode usar todas as senhas inclusive essa para entrar e fazer o que quiser de modo que nesse caso não adianta cerca elétrica por que o bandido tem a chave da porta. Em relação ao sistema de hospedagem não há nada que precise ser alterado pois o servidor aceitou um usuário que acessou o sistema por meios admitidos pelo software que está instalado ou seja ou ele usou um login, ou ele usou um script que envia instruções que foram aceitas pelo [nome do sistema] ou por um de seus acessórios e que permitiram o acesso e controle total do site.
Como já havia mencionado quando um problema desse tipo é detectado rapidamente e um trabalho defensivo e corretivo é feito a tempo, sempre podemos ter um backup relativamente seguro. Relativamente por que essa invasão pode ter várias fontes - por exemplo se sua máquina estiver sendo monitorada não adianta mudar senhas pois você entrega as senhas novas assim que as utiliza. Ou então pode ser um script que estava instalado há tempos e então foi ativado em uma data - por exemplo no seu caso foi usado o final de ano exatamente para atrasar a descoberta do problema como no caso de sexta-feira treze e outros virais que já ocorreram. Nesse caso pode estar há meses e portanto estar dormente no backup.
Por tudo isso o correto é usar uma cópia que esteja com o desenvolvedor pois assim sai do original mas mesmo assim é importante conferir se ela não incorpora falhas de segurança descobertas mais recentemente pois se isso ocorrer você estará livre do atual invasor mas vai arrumar outro rapidamente. Esse é o motivo do lançamento constante de atualizações por parte das softhouses e o mesmo ocorre no caso do [nome do sistema] e afins, e também uma das razões por que as empresas acabam muitas vezes investindo mais e usando software desenvolvido exclusivamente para elas pois isso elimina as falhas de segurança mais comuns que acontecem nos produtos de massa, mas isso realmente é uma solução mais cara do que o uso de plataformas gratuitas.
Temos backups permanentes mas como expliquei para a Majida, nesse caso depois de mais de uma semana da invasão as cópias que estão arquivadas estão todas iguais ou seja invadidas e destruídas pois já foram feitas em cima de um original contaminado. Se o problema fosse descoberto no dia pegaríamos algo de uma semana atrás mas mesmo assim como expliquei não seria exatamente uma garantia, teriam que ser procuradas anomalias nos arquivos - geralmente confrontando e comparando com os originais do desenvolvedor, e inseridas as correções de segurança que se fizerem necessárias. O motivo por não haver tocado nenhum alarme em nosso sistema em relação a esse problema foi que não houve tentativa de invasão do servidor nem ocorreram tráfegos suspeitos o que acontece quando o invasor tenta usar o seu sistema para o envio de emails em massa (SPAM).
Precisando de algo mais em que possamos ajudar por gentileza entre em contato.
Atenciosamente,
-----------------
A., ou O Cliente
