Quer realizar o exame LPIC – 304 de graça?

LPIC3

Sim, sim, você leu corretamente, exame LPIC – 304 ( Virtualização e Alta Disponibilidade ) de graça! Ao ajudar no processo de desenvolvimento do exame, que está sendo organizado pelo Linux Professional Institute, junto aos seus afiliados em todo o mundo, de agora até o dia 15 de novembro, você realiza o exame inteiramente grátis, exclusivamente por teste escrito, contribuindo para a definição da nova versão do exame, o que representa uma economia de U$ 165,00 ( cento e sessenta e cinco dólares americanos ).

Portanto, se você é detentor de um certificado LPIC – 2 ou LPIC – 3 e está interessado em realizar o exame LPIC – 304, precisa enviar um email para o endereço info@lpi.org informando a sua Cidade, Estado e País de residência. Eventos para a realização de testes beta podem não estar disponíveis em todas as localidades, porém o próprio Instituto informou que tentará realizá-los no maior número de locais possíveis, então não deixe de se inscrever.

Para participar é preciso cumprir os seguintes requisitos:

  • Possuir um LPI ID válido;
  • Recomendável possuir um certificado LPIC – 2 ou LPIC – 3;
  • Responder ao teste escrito, que será enviado de volta para correção ( demorando em torno de 1 a 2 meses para obtenção dos resultados );
  • Responder a uma pesquisa, que também faz parte do processo de desenvolvimento do exame.

Caso seja aprovado, você recebe os créditos pelo exame e também a certificação LPIC – 3 Virtualização e Alta disponibilidade. Caso não seja aprovado, você pode solicitar que o exame seja removido dos registros do Instituto. Para verificar os objetivos que irão constar no exame, acessem o wiki com a lista dos mesmos em LPIC – 3 Wiki.

Para verificar esta notícia em seu idioma original, acessem o blog do Instituto. Boa sorte!

Correções disponíveis para as recentes falhas do Bash

HTML code

Já estão disponíveis as correções para as falhas conhecidas pela denominação de Shellshock, que afetam diversas versões do interpretador de comandos Bash, e que receberam bastante atenção da mídia mundial nas últimas semanas, por permitirem ataques aos sistemas operacionais Unix, GNU/Linux e Mac OS.

Desde a descoberta da falha original no dia 24 de setembro (CVE – 2014 – 6271), outras cinco falhas relacionadas foram divulgadas ( CVE – 2014 – 7169, CVE – 2014 – 7186, CVE – 2014 – 7187, CVE – 2014 – 6277 e CVE – 2014 – 6278), e os esforços para a correção destas foram incessantes por parte de desenvolvedores e pesquisadores.

Graças ao trabalho destes voluntários, e a possibilidade de acesso ao código fonte do Bash pelos mesmos, já que este é um software livre, regido pela licença GNU GPL versão 3, foi possível o desenvolvimento de soluções que corrigissem as falhas encontradas de forma razoavelmente rápida.

Claro que não antes de várias ferramentas terem sido desenvolvidas para identificar sistemas que contemplassem essas vulnerabilidades, e tentassem explorá-las de alguma forma, buscando comprometer a integridade dos servidores e desktops que executavam estas versões.

Porém agora as correções já foram disponibilizadas para o público em geral, tanto através do site do projeto, quanto pela grande maioria das distribuições GNU/Linux, além da Apple. Portanto, se você ainda não aplicou as correções disponíveis, recomendo fortemente que utilize os mecanismos de atualização integrantes de seu sistema, e atualize-os o mais rápido possível, evitando o comprometimento da segurança.

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.