Slackware Linux – Atualizações de segurança. Outubro, 2016.

Slackware logo

Olá! Ontem o time de desenvolvimento da Slackware Linux liberou atualizações de segurança importantes, incluindo a que disponibiliza um novo kernel, agora em versão 4.4.29, eliminando de vez a possibilidade de exploração da vulnerabilidade divulgada recentemente, e nomeada como Dirty Cow, portanto se você não fez a atualização manual do kernel, agora já dispõe dos pacotes oficiais oferecidos pela equipe de desenvolvedores da distribuição. Além da atualização do kernel Linux, outras correções importantes estão disponíveis: PHP 5.6.27, MariaDB 10.0.28 e bibliotecas libX.

É recomendável que faça a atualização de todas os sistemas sob sua administração o quanto antes, evitando possíveis explorações às falhas relatadas, além da programação de parada para a devida reinicialização dos mesmos, possibilitando que estes passem a utilizar o novo kernel.

Anúncios

Falhas de segurança encontradas na versão 1.18 do VeraCrypt

System

Uma auditoria realizada pela Quarkslab, empresa francesa de segurança cibernética, descobriu falhas críticas de segurança no software de código aberto VeraCrypt, utilizado para a encriptação de discos ou a criação de compartimentos criptografados nestes.

O trabalho foi realizado sob encomenda do Open Source Technology Improvement Fund, e possibilitou que fossem encontradas oito vulnerabilidades críticas, três de risco médio, além de quinze outras de baixo impacto.

Algumas destas falhas já foram corrigidas e liberadas junto à versão 1.19 do VeraCrypt, portanto se você utiliza versões anteriores a esta é recomendável que realize a atualização do aplicativo. Outras permanecem em aberto devido a complexidade envolvida na correção, e que poderiam causar problemas de retrocompatibilidade.

Uma das mudanças mais significativas, foi a remoção do padrão russo de criptografia GOST 28147-89, que foi considerado inseguro pelos especialistas. Usuários que utilizaram anteriormente este padrão ainda serão capazes de acessar e manipular compartimentos ou discos, porém a criação de novos não estrá mais disponível.

Outras correções foram aplicadas ao gerenciador de inicialização, voltadas a computadores e sistemas operacionais com recursos UEFI, e corrigem falhas encontradas. As bibliotecas XZip e XUnzip também continham falhas e foram substituídas pela mais moderna e segura libzip.

Para acessar o relatório técnico da auditoria, em formato PDF, basta clicar neste link. Para ver o anúncio oficial por parte da OSTIF clique aqui.

Shellshock: Como proteger seus servidores Unix, Linux e Mac

System

Este artigo, escrito por Steven J. Vaughan-Nichols para a ZDNet, nos trás informações relevantes a respeito da recente falha de segurança encontrada no interpretador de comandos Bash, incluso na grande maioria das distribuições GNU/Linux mas também podendo afetar os sistemas operacionais Unix e MacOS. Por isso resolvi escrever uma tradução livre dos pontos principais deste artigo, para que administradores de sistemas aqui no Brasil, e em outros países que falem a língua portuguesa, possam tentar contornar este problema, e manter seu parque de servidores o mais seguro possível com relação a esta vulnerabilidade.

O escritor já inicia seu artigo informando que, embora a falha de segurança seja uma séria ameaça aos sistemas operacionais supracitados, nem sempre um servidor que esteja executando o Bash estará vulnerável, a não ser sob determinadas condições. Primeiramente, o atacante precisa encontrar não apenas um sistema que esteja executando a versão deste interpretador de comandos sem as primeiras correções disponíveis, mas que também este sistema permita o acesso remoto a este shell. Portanto, caso você esteja executando um sistema que não contemple o ssh, rlogin, ou outro programa de desktop remoto, você provavelmente está seguro o suficiente.

Steven também nos alerta a respeito de um problema sério, com relação a dispositivos que trazem Linux embutido, como roteadores, switches ou appliances, e recomenda que, caso esteja utilizando equipamentos antigos e sem suporte, o que torna a correção do problema virtualmente impossível, então o melhor será substituí-los o mais brevemente possível.

Ele afirma também que, atualmente, o perigo maior quanto ao Shellshock é relacionado aos servidores pois, de acordo com o National Institute of Standards and Technology, a vulnerabilidade recebe a mais alta pontuação nos quesitos de impacto potencial e nível de explorabilidade. A Red Hat apresentou um relatório com os vetores de ataque mais comuns, que foram os seguintes:

Httpd ( servidor web ): Scripts CGI ( Common Gateway Interface ) são geralmente afetados pela vulnerabilidade. Quando um script CGI é executado pelo servidor web, ele utiliza variáveis de ambiente para passar dados ao script. Essas variáveis de ambiente podem ser controladas pelo atacante. Se o script CGI chamar o Bash, o script poderia executar código arbitrário como se fosse o usuário httpd. Mod_php, mod_perl e mod_python não utilizam varáveis de ambiente, portanto acredita-se que não sejam afetados.

Secure Shell ( ssh ): Não é incomum a restrição de comandos remotos que um usuário pode executar via ssh, como rsync ou git. Nessas instâncias, essa vulnerabilidade pode ser utilizada para executar qualquer comando, não apenas um comando restrito.

Dhclient: O Dynamic Host Configuration Protocol Client é utilizado para obter automaticamente informações de configuração de rede via DHCP. Este cliente utiliza diversas variáveis de ambiente e utiliza o Bash para configurar a interface de rede. Conectar a um servidor DHCP malicioso poderia permitir ao atacante executar código arbitrário na máquina cliente.

CUPS ( servidor de impressão para Linux, Unix e Mac OS ): Acredita-se que o CUPS seja afetado por esta vulnerabilidade. Diversos valores fornecidos pelos usuários são armazenados em variáveis de ambiente quando os filtros do CUPS são executados.

Sudo: Comandos executados com o sudo não são afetados por essa vulnerabilidade. Ele procura especificamente por variáveis de ambiente que também são funções. Ainda seria possível para o comando em execução definir uma variável de ambiente que levaria a um processo filho do Bash a executar código arbitrário.

Firefox: Acredita-se que não seja possível que o Firefox seja forçado a definir variáveis de ambiente de uma forma que poderia permitir que o Bash executasse comandos de código arbitrário. Mesmo assim é recomendável realizar a atualização do Bash já que é comum a instalação de diversos plug-ins e extensões que poderiam permitir esse comportamento.

Postfix ( servidor de e-mail ): Este servidor vai substituir vários caracteres por um ponto de interrogação (?). Mesmo o Postfix executando chamadas ao Bash de diversas formas, acredita-se que não seja possível que ele configure variáveis de ambiente arbitrárias. Entretanto, é possível que um filtro possa configurar variáveis de ambiente.

Destes, o ataque aos servidores web parecem ser os mais comuns até o momento, sendo executados contra sistemas executando tanto Linux quanto Mac OS X. James Blasco, diretor de laboratórios na AlienVault, executou um honeypot a procura de atacantes e verificou diversas máquinas tentando explorar a vulnerabilidade do Bash. A maioria delas somente verificando se os sistemas estavam vulneráveis, mas também encontraram dois worms que estavam ativamente explorando a falha de segurança e instalando partes de malware no sistema. Outros pesquisadores descobriram que os atacantes tentam plantar IRC bots de ataques de negação de serviço, ao mesmo tempo que buscam por logins de usuários e senhas fracas, como ‘root’, ‘admin’, ‘user’ e ‘123456’.

James mostra então como verificar se o seu sistema está vulnerável, e para isso recomenda a execução do seguinte comando através do Bash:

env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”

Se como resultado você obtiver:

vulnarable this is a test

Sinto muito, mas isso são más notícias pois seu sistema está vulnerável e você precisa tomar providências quanto a aplicação de correções o mais breve possível.

Se, como resultado, você obtiver:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

Então você está tão seguro quanto é possível estar no momento, pois essa versão provavelmente já tem alguma correção aplicada.

Embora a grande maioria das distribuições tenham liberado correções que impedem a maioria dos ataques, foi descoberto que as correções liberadas para essa vulnerabilidade são incompletas. Um atacante pode prover variáveis de ambiente com comandos arbitrários especialmente construídos e que serão executados em sistemas vulneráveis acessados, sob certas condições.

Enquanto ainda é incerto de que esses ataques possam ser utilizados para hackear o sistema, é bem claro que eles podem ser usados para travá-lo, graças a uma exceção de ponteiro nulo.

Neste meio tempo, recomenda-se que as correções disponíveis sejam aplicadas o mais rápido possível, e que se acompanhe o lançamento das novas correções, que já estão em desenvolvimento para cobrir a vulnerabilidade ainda existente no Bash.

Caso você tenha um servidor web Apache em execução, aqui vão algumas regras para o Mod_Security, compiladas pela Red Hat, que podem interromper tentativas de exploração do seu interpretador de comandos:

SecRule REQUEST_HEADERS “^\(\) {”

“phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

SERVER_PROTOCOL values:
SecRule REQUEST_LINE “\(\) {” “phase:1,deny,id:1000001,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST names:
SecRule ARGS_NAMES “^\(\) {” “phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

GET/POST values:
SecRule ARGS “^\(\) {” “phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

File names for uploads:
SecRule FILES_NAMES “^\(\) {” “phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:’CVE-2014-6271 – Bash Attack'”

O escritor ainda lembra ser vital a aplicação das correções já disponíveis, mesmo que estas ainda estejam incompletas, além de se certificar de que dispõe de defesas em torno de seus servidores web, evitando surpresas desagradáveis.