[RESOLVIDO]Invasão pelo framework Scriptcase devido a bibliotecas de terceiros

Boa noite,

Peço encarecidamente que sejam atualizadas as bibliotecas de terceiros como o jquery plugin file-upload.
Tive uma invasão no meu site publicado com scriptcase 8.1.
Recebi pelos logs do GNU/Linux.

xxxxxxx.xxxxxxxxx.com.br : Nov 9 10:01:37 : xxxx : user NOT in sudoers ; TTY=unknown ; PWD=xxxxxxxxx/_lib/prod/third/jquery_plugin/file-upload/server/php ; USER=root ; COMMAND=/usr/bin/whoami

xxxxxxx.xxxxxxx.com.br : Nov 9 10:01:49 : xxxx : user NOT in sudoers ; TTY=unknown ; PWD=xxxxxx/_lib/prod/third/jquery_plugin/file-upload/server/php ; USER=root ; COMMAND=/bin/ls

Como podem ver pelo printscreen abaixo foi criado um arquivo __lib.php .
O mesmo também se encontrava no _/lib/tmp.

Minha sorte é que meus serviços são enjaulados. Então o estrago foi somente na minha hospedagem.

A vulnerabilidade deste plugin já é conhecida desde 2015. Ele esta na versão 7.1.4 ou 8.9.1 no Scriptcase e no Github já estamos na versão 9.14
Vide sobre a vulnerabilidade: http://permita.me/?q=jquery+file+upload+vulnerability

Assim como este plugin esta desatualizado há outras bibliotecas de terceiros desatualizados no framework.
A exemplo: a biblioteca do calendário, o próprio jquery que esta na versão 1 e já temos a 3.

Sei que a netmake prima pela segurança e não irá nos deixar na mão.
Relatado no fórum, no grupo de usuários Scriptcase do whatsapp, bugs@netmake.com.br e feedback@netmake.com.br

Obrigado

Agora vamos esperar a resposta da Netmake.

Isso é sério ?

UP

Sério! O assunto é até tratado pelo desenvolvedor do plugin: https://github.com/blueimp/jQuery-File-Upload/wiki/Security

Esperemos que a Netmake veja isto com a maior rapidez!!! Pelo que percebo, a maioria dos plugins usados no Scriptcase estão defasados.

Estamos desprotegido

Mas a principio para o hacker usar esta vulnerabilidade no site, ele teria que ser aberto ao público em geral sem passar por senha de login ou a pessoa ser usuário do sistema com senha; e ainda ter no sistema uma app feita no com o link campo de upload no formulário que usa a jquery? correto?

O meu site era público, como a maioria dos projetos em Scriptcase que o pessoal tem na internet.
E os plugins vão no prod mesmo não usando upload nas apps.
Não! Não precisa de senha, login e etc para usar esta vulnerabilidade.
Quero deixar claro que não é algo exclusivo do Scriptcase.
Ela é usada também em outros software como joomla, magento, wordpress e etc.

Basta ser visível na internet e usar softwares defazados.
Agora vou me retirar para descansar e depois refazer meu site.
Sem mais comentários por hoje de minha parte.

Muito sério.

UP

Complicado,

Up !

@ Aproveito para registrar o excelente suporte prestado pelo Alexandre nas hospedagens!!!

Caso muito sério a ser resolvido pela NM.

Vamos aguardar a NETMAKE

Hoje lendo com calma a recomendação do desenvolvedor do plugin.
https://github.com/blueimp/jQuery-File-Upload/wiki/Security
Vi que:

  1. Implementação Node.js
    A implementação do Node.js serve arquivos carregados com um servidor de arquivos estático, que - como o nome indica - só serve arquivos estáticos e não interpreta scripts enviados (como o Apache faria, por exemplo, com scripts PHP com o módulo PHP instalado).
    A implementação do Node.js também restringe os arquivos carregados por padrão para arquivos de imagem (GIF, JPEG, PNG).
    Então, Sem problemas.

  2. implementação do PHP
    A implementação do PHP permite carregar todos os tipos de arquivos por padrão. Desde que você provavelmente não precisa essa funcionalidade, recomenda-se para ajustar a opção accept_file_types.

$upload_handler = new UploadHandler(array(
‘accept_file_types’ => ‘/.(gif|jpe?g|png)$/i’
));

Por favor, note que a opção accept_file_types não se destina a impedir os atacantes de upload e execução de scripts PHP. Isso é feito com uma diretiva .htaccess (ou através de configuração Nginx) como explicado nos parágrafos seguintes.

A implementação do PHP armazena arquivos carregados no diretório pré-definido “ex: files”. Esta pasta contém um .htaccess arquivo que é absolutamente necessário, já que contém diretrizes para o Apache para impor restrições de segurança:

“Aqui podem ver no prod que existe o arquivo .htacess referido no diretório files (prod\third\jquery_plugin\file-upload\server\php\files) mas a Netmake não faz uso deste arquivo”

ForceType application/octet-stream
Header set Content-Disposition attachment
<FilesMatch “(?i).(gif|jpe?g|png)$”>
ForceType none
Header unset Content-Disposition

Header set X-Content-Type-Options nosniff

O ForceType diretiva “application / octet-stream” impõe ao Apache para servir todos os arquivos com um cabeçalho do anexo para forçar uma caixa de diálogo de download. Mais importante ainda, impede que o Apache execute qualquer um dos arquivos carregados através de um intérprete como o PHP, mesmo que a extensão do arquivo seja “.php”.

Nginx

Exemplo de configuração do nginx para servir de forma segura os arquivos enviados (ajuste “/ jQuery-File-Upload / server / php / files” para o caminho do seu diretório de upload):

location ^~ /jQuery-File-Upload/server/php/files {
root html;
default_type application/octet-stream;
types {
image/gif gif;
image/jpeg jpg;
image/png png;
}
add_header X-Content-Type-Options ‘nosniff’;
if ($request_filename ~ /(((?!.(jpg)|(png)|(gif)$)[^/])+$)) {
add_header Content-Disposition ‘attachment; filename="$1"’;
# Add X-Content-Type-Options again, as using add_header in a new context
# dismisses all previous add_header calls:
add_header X-Content-Type-Options ‘nosniff’;
}
}

  1. Autenticação básica HTTP

Embora autenticação básica HTTP (por exemplo, via .htaccess) é um meio simples de adicionar proteção por senha, é aconselhável usar a autenticação baseada em cookies em vez disso, uma vez que o IE não parecem ter problemas com HTTP autenticação básica e iframes invisíveis, que são utilizados para o transporte Iframe .
Ver também Problema # 1264 .

[size=12pt]Logo, temos as seguintes alternativas para aumentar a segurança deste plugin:[/size]

  1. Alterar o arquivo prod\third\jquery_plugin\file-upload\server\php\index.php de:

error_reporting(E_ALL | E_STRICT);
require(‘UploadHandler.php’);
$upload_handler = new UploadHandler();

Para:

error_reporting(E_ALL | E_STRICT);
require(‘UploadHandler.php’);
$upload_handler = new UploadHandler(array(
‘accept_file_types’ => ‘/.(gif|jpe?g|png)$/i’
));

Onde a linha accept_file_types’ => '/.(gif|jpe?g|png)$/i deve conter os tipos de arquivo que você deseja permitir o download.

O lado ruim é que todas vez que a netmake tiver atualização sua modificação já era

  1. Copiar o arquivo .htaccess presente em prod\third\jquery_plugin\file-upload\server\php\files
    para todo lugar onde é feito upload de arquivos ou no raiz da sua hospedagem.
    Exemplo: _lib/tmp e etc.
    [size=12pt]Observação: por padrão as subpastas no apache herdam o conteúdo de um .htaccess no diretório pai.
    Tem que testar os efeitos de ter este .htaccess no raiz.
    Antes de copiar para o raiz veja se já não existe um .htaccess no raiz.
    Se tiver não apague o .htaccess do raiz mas copie o conteúdo para dentro dele.
    E lembre-se de acresentar na linha <FilesMatch “(?i).(gif|jpe?g|png)$”> todos os tipos de arquivos permitidos[/size].

  2. Usar proteção com .htaccess por senha.
    Acho a opção mais segura. Mas tem que ver o impacto no usuário final de ter que digitar mais uma senha.
    Já para pessoas que como eu querem usar uma blank ou outra coisa num site??? Difícil né!!!

Ótima notícia!

Olá Sr. Alexandre,

Tentamos a sugestão que o senhor deu de atualizar o plugin, mas não solucionou o problema.
Nossa equipe de desenvolvimento corrigiu o problema internamente, nas próximas atualizações o problema não ocorrerá.
Por hora, o senhor pode remover o diretório /jquery_plugin em seu servidor de produção que não irá surtir nenhum efeito na publicação.

Agradecemos a colaboração, ótimo dia.

Atenciosamente,
Bugs Tracker Team
Netmake - Soluções em Informática

Ticket Details
Ticket ID: XKV-820-58943
Department: Bugs
Type: Bug
Status: Answered
Priority: Normal

Helpdesk: https://suporte.scriptcase.com.br/index.php?

Show!!!

Alexandre bom dia. Caso possa nos ajudar, mais ainda do que já tem nos ajudado, gostaria de saber, pela sua experiência nesse assunto, se essa implementação da NM realmente surtirá o efeito satisfatório, ou é bom também implementar suas medidas de proteção? Há como testarmos essa vulnerabilidade após eles processarem tal correção? Desde já agradeço.

Joni,
Boa tarde,

Vamos dar nome ao boi.
Neste caso ele se chama segurança da informação.

Segundo a Wikipédia:

A segurança da informação está diretamente relacionada com proteção de um conjunto de informações, no sentido de preservar o valor que possuem para um indivíduo ou uma organização. São características básicas da segurança da informação os atributos de confidencialidade, integridade, disponibilidade e autenticidade, não estando esta segurança restrita somente a sistemas computacionais, informações eletrônicas ou sistemas de armazenamento. O conceito se aplica a todos os aspectos de proteção de informações e dados. O conceito de Segurança Informática ou Segurança de Computadores está intimamente relacionado com o de Segurança da Informação, incluindo não apenas a segurança dos dados/informação, mas também a dos sistemas em si.

Então agora que sabemos o que é segurança da informação.
Podemos dizer que eu divido em três partes o que coloca a segurança da informação por água abaixo:

1) Engenharia social.

Segundo a Wikipédia:

A engenharia social, no contexto de segurança da informação, refere-se à manipulação psicológica de pessoas para a execução de ações ou divulgar informações confidenciais. Este é um termo que descreve um tipo psicotécnico de intrusão que depende fortemente de interação humana e envolve enganar outras pessoas para quebrar procedimentos de segurança. Um ataque clássico na engenharia social é quando uma pessoa se passa por um alto nível profissional dentro das organizações e diz que o mesmo possui problemas urgentes de acesso ao sistema, conseguindo assim o acesso a locais restritos

É a forma mais comum de ataque. O termo engenharia social ficou mais conhecido em 1990, através do famoso hacker Kevin Mitnick.
Não adianta ter a plataforma mais segura do mundo se o fator humano falha.
Para mim, e eu não me baseio em dados para afirmar, este tipo de ataque corresponde a mais de 80% dos ocorridos.

a) Quem nunca viu numa empresa colegas compartilharem senhas de acesso, apesar de instrução contrária ao compartilhamento.
b) Deixar terminais logados enquanto saem para um voltinha
c) Caem em phishing (https://pt.wikipedia.org/wiki/Phishing) por telefone, e-mail e etc.

Falando claramente: A Netamake e você irão se esforçar para ter o sistema mais seguro do mundo e o seu cliente irá jogar este esforço na lama.

2) Falhas na sua programação ou de terceiros. Softwares com brecha de segurança.

Foi que ocorreu neste caso do plugin.
Você é do tipo de pessoa que vai numa loja e compra tudo o que o vendedor diz porque ele falou que era um excelente produto.
Logo, Quando for programar você também irá criar ou acreditar no super código que é totalmente protegido.
Porque a sua mente criou ou acredita na propaganda do vendedor. Este vendedor poderá ser você mesmo ou outros desenvolvedores.

Vou contar uma história velha, ou pelo menos do que me lembro dela.

Tinha um amigo que na faculdade tinha que criar a super tela de login.
Após um árduo trabalho e horas de dedicação.
Estava pronto. Impenetrável. Trabalho de mestre.
Era hora de testar.
Ele escolheu alguém que era próximo.
Após alguns minutos a tela de login foi burlada.
A pessoa que testava simplesmente deu um ESC.
O super sistema de proteção não prévia um ESC.

Por mais que a propaganda diga que é seguro. Nada é 100% seguro.
Lembre-se você trabalha em média de 8 a 12 horas por dia para deixar seu sistema seguro.
Um hacker e suas modalidades: Cracker, Deface, Banker, etc e até o mais singelo Newbie ou Lammer ira trabalhar as 24 horas para invadi-lo.

Então instalou ou usou um software no seu desenvolvimento atualize sempre que sair correções.
Mesmo que não seja para desenvolvimento. Atualize!
Você é daqueles que instalou o Wordpress em 2012 e em 2016 vem dizer? – Fui invadido! Não sei o que aconteceu!
Ou: Meu Windows pegou um vírus que explorar a vulnerabilidade de rede. O Windows é uma porcaria! Mas nunca rodou o windows update para correção desta vulnerabilidade.
A mesma coisa vale para seu conjunto pessoal de funções, framework e etc. Tem! Usa! atualize!
Já coloque o custo da atualização nas suas vendas.
Dúvida que após está correção ainda terá pessoas usando a versão 8.1.048 correndo o risco de ser invadido?

3) Falhas nos serviços e no ambiente operacional

Aqui entram o pessoal que instala o Windows, Gnu/Linux ou seja lá oque for e não atualiza por medo de quebrar sua instalação.
E acaba quebrando as pernas por invasores.

Entenda todo serviço seja http, mx, ssh, ftp e etc no fundo são softwares. E todo ambiente operacional também é um software o que entra na situação citada 02.
Eles terão vulnerabilidades, backdoor e etc. Estes fatores somente sofrem correção com atualizações.

E ainda tem aquele que instala o serviço no básico e tá pronto para usar: “-- Tô protegido”

Enfim! Não lê os manuais, não vê as dicas de segurança, não vê o que pode ser melhorado, não atualiza, não revê seus conceitos.
É difícil fazer isto? É sim!
Temos tempo para isto? Não!
O que aconteceu então com o: https://github.com/blueimp/jQuery-File-Upload/wiki/Security
Fui invadido e você também pode. Até que alguém teve tempo de ler. E aplicar a correção.
Não seria melhor ler antes de ser invadido e transmitir está insegurança para todos os seus clientes?
Então Joni! Você estará seguro com a correção, mas não totalmente.
Seja por parte da Netmake ou da sua!

Joni,
Pensei muito e não vou dizer como testar.
Se colocar aqui tenho certeza que poderá se usado naqueles que ficam com versões antigas.
Mas posso testar no meu servidor e colocar aqui o resultado.

Sim, sim. E acho que todos concordamos plenamente. 100% de segurança é utopia. Mas o questionamento é sempre no sentido de mitigar o que se pode em relação ao tema. Eu particularmente levo ao pé da letra a lei de Edward Aloysius Murphy nesse quesito e procuro sempre me atentar ao máximo naquilo que pode vir a ser um problema (entendendo problema como o impacto direto ao cliente e principalmente as questões jurídicas advindas disso). O meu intuito é tentar plotar o que de alternativas posso implementar nos meus planos de contingências já estando certo que o problema ocorrerá. Então, minimizar tais impactos negativos, aperfeiçoando e agilizando os processos alternativos.

Portanto, sabemos que temos que trabalhar ao máximo em relação aos itens 1 e 2 da sua explanação. Tentar prever o máximo das possibilidades em relação aos usuários; tomar o maior cuidado nos mínimos detalhes, mas ainda assim acredito, segundo Murphy, que passará algum detalhe. Porém, meu caro, o que tentei inferir na minha pergunta é o quanto podemos esperar das “administradoras” de host, já que terceirizo essa parte. Para somar às implementações que tenho a obrigação de realizar, no que concerne ao desenvolvimento, formando, então, a última (ou a primeira) barreira as hostilidades desse mundo ingrato!

E concluindo, sim seria muito interessante se pudéssemos contar com os resultados dos seus testes sobre a atualização da NM a esse respeito, não só para conclusões em relação ao SC, mas também para uma análise comparativa de administração de hosts, para uma eventual tomadas de decisão na troca desse serviço. Não possuo vinculo contigo, mas acompanho seu trabalho e dedicação para com a comunidade. Disso dar para se ter uma ideia do seu profissionalismo.

Obrigado.

Joni,
Neste ponto: “Porém, meu caro, o que tentei inferir na minha pergunta é o quanto podemos esperar das “administradoras” de host, já que terceirizo essa parte.”
É interessante ver o contrato dos provedores de serviço. E conversar com o SYSDAMIN ou suporte do provedor para ver as medidas que são tomadas e o que se pode esperar da prestação de serviço realizada por eles.

No quesito backup.

Na minha experiência e até onde procurei, o primeiro detalhe é que mais de 90% dos provedores de hospedagem compartilhada faz backup mas não se responsabiliza no caso de perda de dados.
O período de backup pode variar de 24 horas a 48 horas. E difícil os que mantém backup de 7 dias por exemplo.
Já para hospedagem dedicada o backup é por sua conta.
Mesmo que eles vendam serviço de backup. É você que tem que programar e ver se está correndo corretamente.
É como se houvesse o aluguel do software de backup e o espaço em disco para isto.

No quesito software de segurança

Em hospedagem dedicada é você o responsável por implantar tudo.
Na hospedagem compartilhada cada host faz uso de um sistema de proteção. Por isto é importante conversar com o suporte ou SYSADMIN.

No quesito contrato

Em todas as hospedagem compartilhadas podemos prever situações como estas:

DAS OBRIGAÇÕES DA CONTRATADA.

Cláusula 5ª Viabilizar a conexão dos Servidores à Internet como maneira de
operacionalizar a exibição do Conteúdo da CONTRATANTE, administrando,
inclusive, o ambiente em que este estiver alojado.

a) Zelar pela eficiência e efetividade de suas redes, adotando todas as medidas
para evitar mau funcionamento das mesmas.
b) A CONTRATADA manterá o serviço de hospedagem de sites sempre à
disposição da CONTRATANTE, podendo, eventualmente, sofrer interrupções
devido a:

(1) manutenções técnicas e/ou operacionais que exijam o desligamento
temporário do sistema ou impossibilitem o acesso;
(2) casos fortuitos ou força maior;
b ações de terceiros que impeçam a prestação dos serviços (como por
exemplo, ataques de hackers);[/b]
(4) falta de fornecimento de energia elétrica;
(5) interrupção ou suspensão dos serviços prestados pelas prestadoras de
serviços de telecomunicações;
(6) ocorrências de falhas no sistema de transmissão e/ou roteamento no
acesso à Internet.
c) A CONTRATADA não será responsável por quaisquer danos e ou prejuízos
decorrentes de interrupções relacionadas aos eventos previstos na cláusula 5ª
item “b” , ou daqueles em que não tenha concorrido exclusivamente para a
verificação do dano e ou prejuízo.

d) A CONTRATADA compromete-se a localizar eventuais problemas de
interrupção na transmissão de dados entre o Servidor que alojar o Conteúdo
da CONTRATANTE e a Internet.
e) A CONTRATADA compromete-se a realizar todos os esforços para bloquear
os acessos indevidos e lesivos ao Servidor em que estiverem inseridos os
Conteúdos da CONTRATANTE, sem contudo, responsabilizar-se por eventuais
danos ou prejuízos decorrentes da transposição do site do cliente através da
Internet.