Cron-apt – Otimizando a atualização dos servidores Debian
March 4, 2010 by alexos · 2 Comments
A atualização dos servidores pode tornar-se uma tarefa chata quando você tem repetir está mesma ação diversas vezes. Para automatizar está tarefa uso o script cron-apt. Como o nome já diz ele agenda a execução do apt-get ou aptitude para atualizar os pacotes de seu sistema
Segue aqui um pequeno how-to para implantação desta ferramenta que tem sido uma mão na roda no meu dia a dia.
NOTA: A atualização automatizada dos pacotes não é recomendada para as versões testing e unstable do Debian. Mesmo na versão stable use por sua conta e risco.
Instale o pacote cron-apt
sudo aptitude install cron-apt
Edite o arquivo /etc/cron-apt/config descomentando as seguintes linhas:
APTCOMMAND=/usr/bin/aptitude
MAIL=”/var/log/cron-apt/mail”
Agora descomente e edite as seguintes linhas deste mesmo arquivo
MAILTO=”INFORME SEU EMAIL AQUI”
De
MAILON=”error”Para
MAILON=”always”
De
SYSLOGON=”upgrade”Para
SYSLOGON=”always”
De
DEBUG=”output”Para
DEBUG=”always”
Por padrão ele apenas baixa os pacotes sem instalá-los usando a opção dist-upgrade. Aqui mostro como mudar está ação que não é muito interessante para servidores pois a opção dist-upgrade pode apagar pacotes importantes.
Edite o arquivo /etc/cron-apt/actions.d/3-download alterando a seguinte linha
De
dist-upgrade -d -y -o APT::Get::Show-Upgraded=truePara
safe-upgrade -y -o APT::Get::Show-Upgraded=true
O cron-apt está agendado para ser executado às 04 da manhã todos os dias. Para mudar este agendamento edite a seguinte linha no arquivo /etc/cron.d/cron-apt
0 4 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
Eu por exemplo agendo as minhas atualizações para as 23 horas. Então minha configuração fica da seguinte forma:
0 23 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
Como informei anteriormente tenha muito cuidado ao usar ferramentas automatizas na gestão dos seus sistemas. Por isso recomendo fortemente a configuração do envio de emails, assim você poderá acompanhar de forma segura todas as ações realizadas por está ferramenta.
Infraestrutura para Aplicações Web Seguras parte 3 – Aplicação (Cont.)
March 3, 2010 by alexos · Leave a Comment
Para completar o post anterior eu não poderia deixar de lado os nossos amigos e companheiros de luta – OS DESENVOLVEDORES. Sim esses abnegados amigos que defendem com unhas e dentes seus sistemas desenvolvidos seguindo padrões de qualidade criados por eles próprios.
Eu não sou expert no assunto muito porque como desenvolvedor eu sou um bom cozinheiro. Por isso indico o site do grande Wagner Elias.
Referências – Desenvolvimento Seguro
* PHP Security
* Hardened-PHP Project
* OWASP – Open Web Application Security Project
* OWASP Development Guide
* OWASP Code Review Project
* Software Assurance Maturity Model
* OWASP Enterprise Security API
* OWASP Ruby on Rails Security Guide V2
* Hackers.org Web Application Security
As referências acima ajudarão os desenvolvedores compreenderem como desenvolver aplicações de forma segura. Sabemos que nunca estaremos 100% seguros, porém o mais importante e o mais gratificante é saber que ao tentar detectar/explorar uma falha numa aplicação ou em um sistema o atacante viu que as portas foram bem fechadas e com o aumento da complexidade a grande maioria desiste.
E para finalizar com chave de ouro indico a leitura de um texto muito engraçado e totalmente verdadeiro feito pelo meu amigo Licio Fonseca – Desenvolvedores: O que o seu SysAdmin gostaria que você soubesse
Infraestrutura para Aplicações Web Seguras parte 3 – Aplicação
Finalizando nossa trilogia farei algumas recomendações para fortalecer o Apache2 e algumas referências sobre boas práticas de segurança no desenvolvimento de aplicações.
Apache2 Seguro
1 – Atualização
É chato falar sempre a mesma ladainha mas atualização é o item número 1 de qualquer cheklist de pós instalação. Sobre isso comentei na 1a. parte.
2 – Escolha o módulo do Apache que melhor atenda suas necessidades
Isso mesmo. Existe um módulo do Apache para cada necessidade vejamos:
Ele implementa um non-threaded web server que processa os pedidos de maneira similar ao Apache 1.3, sendo o melhor MPM para isolar cada requisição, assim um problema com uma única requisição não afetará as outras.
Ele é auto ajustável tornando muito rara a necessidade de ajustar as suas diretivas de configuração.O mais importante é que a diretiva MaxClients possua um valor suficientemente grande para lidar com tantas solicitações simultâneas, mas pequena o suficiente para assegurar que haja bastante RAM física para todos os processos.
Para instalar o Apache MPM Prefork execute
aptitude install apache2-mpm-prefork
Ele implementa um multi-threaded server hibrido. Usando threads para tratar as requisições. Ele atende a apliações que neessitam atender muitas requisições usando poucos recursos do sistema, entretando ele retém a estabilidade do servidor porque mantem muitos processos abertos onde cada um desse processos rodam várias threads.
As diretivas mais importantes no uso deste módulo são: ThreadsPerChild e MaxClients
Para instalar o Apache MPM Worker execute
aptitude install apache2-mpm-worker
Apache Hardening
Este assunto já foi tratado anteriomente porém quero atualizar alguns itens:
* Edite os seguintes parâmetros do arquivo /etc/apache2/conf.d/security
De
ServerTokens FullPara
ServerTokens Prod
De
ServerSignature OnPara
ServerSignature Off
De
TraceEnable OnPara
TraceEnable Off
* Protega o acesso aos arquivos
Edite os arquivos existentes no diretório /etc/apache/sites-available . Altere os parâmetros diretiva Directory / deixando da seguinte forma:
Order Deny,Allow
Deny from all
Habilite o mod_security
Se você possuir um espírito aventureiro e gostar de fortes emoções recomendo o uso do mod_security. Ele bloqueia o monitoramento de requisições e respostas HTTP tanto quanto a negação de pacotes suspeitos.
Se você possui as caracteristicas acima então siga meu post com o passo a passo para habilitá-lo.
Links Recomendados
* Apache Performance Tunning
* Apache Security Tips
Auditoria – Ferramentas
Nikto
O Nikto Webserver Scanner é uma excelente ferramenta de auditoria para servidores Web. Escrito em perl e mantido pelo CIRT se tornou parte integrante do Nessus.
Muito cuidado com os reports gerados por ele, o ideal é estudar e testar cada alerta gerado pois alguns deles são falsos positivos, isso não tira de forma alguma o brilho desta ferramenta.
W3af
O W3af é um completo framework para ataque e auditoria de servidores Web. Ele faz o serviço completo ( barba, cabelo e bigode ) sendo capaz de fazer uma simples auditoria de vulnerabilidades ao ataque propriamente dito.
Diferentemente do Nikto ele é um devorador de recursos e pode levar dias para concluir uma auditoria de acordo com os plugins habilitados, principalmente se habilitar todos os plugins do módulo Discovery.
Para um relatório efetivo de como anda a segurança do seu Webserver recomendo o trabalho em conjunto do Nessus, Nikto e o W3af.
Estamos de mudança
March 2, 2010 by alexos · Leave a Comment
Após alguns meses de aluguel resolvi tomar vergonha na cara e oganizei um lar definitivo para o Alexos Core Labs. Meu grande amigo/irmão Ricardo Cropalato cedeu um espaço em seu webhost mas vi a possibilidade de manter meu próprio servidor, coisa que não estava afim de fazer tempos atrás.
Estou muito satisfeito com a infra-estrutura de VPS que estamos usando na Colivre, estamos mantendo nossos serviços tanto no Slicehost quanto no Linode. Escolhi um VPS no Linode para ser a nova casa deste blog.
Aproveitando registrei os dominios alexos.org e alexos.net. Vi que os leitores da lingua inglesa estavam reclamando do Google Translate então resolvi montar a versão em inglês usando o dominio alexos.org.
Muitas novidades estão por vir em breve. Estou trabalhando duro para manter um blog de qualidade e sempre atualizado.
Aguardem….
Infraestrutura para Aplicações Web Seguras parte 2 – SGBDs ( Updated )
O SGBD é ao mesmo tempo o bom e o mau elemento deste processo. Se bem configurado e mantido será um aliado poderoso, infelizmente isto nem sempre ocorre sendo bastante otimista.
As últimas noticias revelam que as boas práticas não estão sendo obedecidas. A técnica de ataque mais utilizada atualmente é o SQL Injection que é injectar código malicioso permitindo desde a criação de um simples usuário até a total indisponibilidade do serviço.
99.99% dos sites comprometidos ( defacements ) diariamente estão vulneráveis a este de ataque.Esta falha não está somente ligada ao SGBD, um código mau escrito abre esta e outras vulnerabilidades na aplicação como veremos na 3a. parte do nosso artigo.
Os SGBDs mais utilizados numa infraestrutura baseada em software livre são o MySQL e o Postgresql. Cada um destes sistemas possuem características que atendem a várias demandas de performance, produtividade, escalabilidade e segurança.
A implementação de uma infraestrutura segura para banco de dados inicia-se na modelagem do banco, uma modelagem bem feita permitirá que sua base de dados expanda mantendo a total integridade, escalabilidade e segurança. Evitando brechas de segurança e evitando as sempre presentes “gambiarras”.
Como definimos anteriormente o sistema de arquivos* e o tipo de redundância dos discos** serão itens criticos na performance e segurança na manipulação dos dados.
* Recomendo o uso do sistema de arquivos XFS
** Recomendo o uso do RAID 0+1
SGBD MySQL Seguro
1 – Amplie a segurança local
Desabilite o uso do comando LOAD DATA LOCAL INFILE prevenindo contra ataques que permitem a leitura dos arquivos locais. Isso é importante caso haja ataque de SQL Injection através de uma vulnerabilidade no código PHP.
Adicione o seguinte parâmetro na seção [mysqld] do arquivo /chroot/mysql/etc/my.cnf:
set-variable=local-infile=0
2 – Altere a senha do usuário root do banco
mysqladmin -u root password ‘NOVA_SENHA’ -p
3 – Remova usuários e bases padrões
mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host=”localhost” and user=”root”);
mysql> flush privileges;
4 – Renomeie a conta do admin ( root )
mysql> update user set user=”mydbadmin” where user=”root”;
mysql> flush privileges;
5 – Crie contas de usuários separadas para cada aplicação
mysql -u mydbadmin -p
mysql> CREATE DATABASE blog;
mysql> CREATE DATABASE guestbook;mysql> CREATE USER ‘blgu’@'localhost’ IDENTIFIED BY ‘SENHA’;
mysql> CREATE USER ‘gbu’@'localhost’ IDENTIFIED BY ‘OUTRASENHA’;mysql> GRANT ALL PRIVILEGES ON blog.* TO ‘blgu’@'localhost’ WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON guestbook.* TO ‘gbu’@'localhost’ WITH GRANT OPTION;mysql> FLUSH PRIVILEGES;
MySQL Tunning
Para fazer o tunning do MyQSL recomendo o uso do seguinte script:
MySQL Performance Tuning Primer Script
O uso desta ferrramenta é recomendado após 48 horas de uso do banco permitindo que o script detecte os valores corretos para o tunning do banco.
Links Recomendados:
* Making MySQL Secure Against Attackers
* Six steps to secure sensitive data in MySQL
SGBD Postgresql Seguro
No caso do Postgresql recomendo a leitura do material do Fernando Ike aka Fike, o cara é uma sumidade no assunto. Nesta apesentação ele aborda o tunning de performance e segurança do Postgresql
* Performance Tuning para banco de dados PostgreSQL
Links Recomendados:
* Securing your PostgreSQL Database
* PostgreSQL – Security
Auditoria – Ferramentas
* OWASP SQLiX Project
* Security Database
* SQL Injection Tools
* SQL Injection Vulnerability Online Test
* SQL Inject Me – Firefox Addon
Outros Links
* SQL Injection Prevention Cheat Sheet
* Database Security
* Blind SQL Injection
Infraestrutura para Aplicações Web Seguras parte 1 – Sistema ( Updated )
February 25, 2010 by alexos · Leave a Comment
Neste artigo abordarei como montar/manter um servidor seguro. Uso o Debian GNU/Linux como sistema base mas todas as ferramentas e procedimentos listados servem para qualquer Unix-like.
Um dos grandes inimigos na implementação de qualquer solução é o tempo. Tudo tem que ser feito no menor tempo possível, com o menor gasto possível e com 0% de falha. Para respeitamos todas essas premissas as orientações apresentadas serão de rápida implementação e fácil manutenção.
Hardening
Trocando em miúdos o hardening é o fortalecimento de um sistema, serviço ou aplicação com o objetivo de minimizar ou dificultar a ação de hackers e crackers.
Iniciamos o hardening antes da instalação do sistema. Neste momento planejamos:
1 – Daemons/serviços que serão disponibilizados;
2 – Particionamento;
1 – Como o foco do nosso artigo são aplicações Web já sabemos que vamos trabalhar com o Quarteto Fantástico – Linux, Apache, PHP e MySQL ou Postgresql. De antemão já temos definidos os serviços que serão disponibilizados.
2 – Com isso definido recomendo que o diretório /var permaneca numa partição separada, lá ficarão os arquivos do site no /var/www e os arquivos do banco em /var/lib/mysql.
Dependendo da aplicação é possivel que o BD cresca rapidamente então recomendo separar a maior parte do disco para está partição e também recomendo a utilzação do sistema de arquivos XFS.
Quer saber porque recomendo o uso deste sistema de arquivos? CLIQUE AQUI
Feito todo o planejamento e com o S.O. instalado iniciaremos os procedimentos de pós-instalação:
1 – Atualizar todo o sistema. No caso do Debian recomendo antes de tudo ajustar o arquivo sources.list removendo todo o conteúdo e adicionado os seguintes repositórios:
deb http://ftp.us.debian.org/debian stable main contrib
deb http://security.debian.org/ stable/updates main contrib
Feito isso use o velho e bom aptitude update && aptitude safe-upgrade
2 – Remova todos os serviços desnecessários:
Recomendo a instalação do Nmap, assim de forma fácil e rápida descobriremos as portas abertas e os serviços em execução.
Exemplo:
nmap localhost
Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-25 00:53 BRT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000021s latency).
Hostname localhost resolves to 2 IPs. Only scanned 127.0.0.1
Not shown: 996 closed ports
PORT STATE SERVICE
xx/tcp open xxx
xxx/tcp open xxxx
xxx/tcp open xxx
xxx/tcp open xxxxxNmap done: 1 IP address (1 host up) scanned in 0.22 seconds
Você poderá remover a aplicação indesejada usando o comando aptitude remove [aplicação] ou apenas impedir que ela seja executada durante o boot, como por exemplo o MTA exim usando o comando update-rc.d -f exim remove. Dessa forma o exim permanecerá instalado, por ser dependência para outras aplicações, mas não será executado durante o boot.
3 – Use o sudo
Evite logar no sistema usando o usuário root e não deixe que membros da equipe façam o mesmo, assim é possivel fortalecer a auditoria de autenticação, instalação e remoção de pacotes e ações que podem danificar o sistema.
4 – Bloqueie o usuário root
Use o comando usermod -L root para bloquear o login usando o usuário root.
5 – Mude a porta padrão do ssh e bloqueie o login do usuário root
Segurança por obscuridade é uma das técnicas utilizadas para dificultar o footprinting, e o port scanning do seu sistema.
Para fazer estas modificações acesse o arquivo /etc/ssh/sshd_config e altere as seguintes linhas:
Port 22
para por exemplo
Port 3000
PermitRootLogin yes
para
PermitRootLogin no
Refinando o processo de Hardening
Algumas ferramentas podem ser utilizadas para ajudar no processo de hardening do sistema. Recomendo fortemente o uso das seguintes ferramentas:
Hntool
Este é um novo projeto do meu amigo sergipano Hugo Doria que vem crescendo bem rápido e vem contando com novas contribuições diariamente.
O objetivo desta ferramenta é facilitar a vida do Sysadmin informando as melhorias necessárias para fortalecer os serviços e o próprio sistema.
Como ele é totalmente modular fica muito fácil contribuir. Se você quer aprender a programar em Python essa é hora.
Contribua com o desenvolvimento do Hntool. A comunidade de brasileira de segurança da informação agradece.
Bastille
O Bastille protege o sistema operacional, configurando o sistema de maneira pro-ativa para aumentar sua segurança e reduzir as chances de comprometimento. Ele também pode ser usado para assessorar no processo de Hardening do sistema, reportando e detalhando cada configuração de segurança usada pelo programa.
Ele auxilia o usuário/administrador do sistema a escolher exatamente como fortalece-lo. No modo de operação/hardening padrão, ele interage com o usuário fazendo perguntas , explicando cada tópico para, então, criar uma política baseada nas respostas do usuário. Logo em seguida, aplica-se as políticas no sistema. No modo de auditoria, ele cria um relatório para ensinar o usuário sobre as configurações de segurança disponíveis, além de informar quais configurações foram definidas/ajustadas.
Para ajudar na instalação e configuração disponibilizo o capitulo referente ao Bastille que criei para minha aula na Pós em Segurança da Informação da Unijorge.
Monitoramento Seguro
Após todos os ajustes necessários é hora de monitorar e manter o ambiente sempre disponível e seguro. Para isso recomendo a instalação das seguintes ferramentas:
Ossec HIDS
O OSSEC é um escalável, multi-plataforma, e open source HIDS. Ele integra análise de log, checagem de integridade de arquivos, politica centralizada, detecção de rootkit, alerta em tempo real e resposta automática.
Para facilitar a implentação postei 03 artigos com a instalação do Ossec Server, o Agente e a Interface Web.
Lenbrando que existe a opção da instalação local ( standalone ) permitindo que você seja alertado através do email.
Munin
O Munin é uma ferramenta de gerência de desempenho muito simples de instalar e configurar. Ela permite que você obtenha informações em tempo real de como anda o seu sistema.
Veja o post que disponibilizei sobre está excelente ferramenta.
Apticron
O Apticron é um script que alerta via email diariamente sobre novas atualizações no seu servidor, no alerta você encontra a lista de pacotes que precisam ser atualizados e todo o changelog.
Acesse os links 1 ou 2 para obter informações de como instalar e configurar está ferramenta bastante útil.
Conclusão
Finalizo aqui a 1a. parte da nossa saga. Peço desculpas aos leitores que querem mais informações técnicas sobre os assuntos abordados, só que o objetivo destes artigos é trazer recomendações e referências rápidas. Prometo trazer informações mais técnicas sobre os assuntos abordados em breve.
Infraestrutura para Aplicações Web Seguras – Motivação
February 25, 2010 by alexos · Leave a Comment
A Web é a porta de entrada de todas as empresas. Quando você deseja obter informações sobre uma cooporação ou um produto, intuitivamente você acessa o Google e busca o site da empresa/produto desejado.
Quem não disponibiliza informações sobre seus produtos/serviços na Internet está fadado ao fracasso, isso significa que a cada dia mais e mais administradores estão montando suas infra-estruturas com o único objetivo.
DISPONIBILIZAR INFORMAÇÕES NA INTERNET.
Para confirmar a observação acima leia a entrevista feita pela Information Week com o CIO da Casas Bahia Frederico Wanderley.
O grande questão é E A SEGURANÇA? Será que ao pensar em disponibilizar suas informações na internet estas cooporações se preocupam se elas estão disponíveis, integras e confidenciais?
Será que o administrador da rede está preocupado em fortalecer o sistema operacional e os serviços? Será que o desenvolvedor do site está preocupado que sua aplicação seja escrita obdecendo criterios básicos de segurança?
Vocês poderiam me responder antes de clicar nos links abaixo. Qual a relação existente entre Google, Microsoft, HSBC e Sony?
Resposta: Todas elas sofreram defacement. Todas elas tiveram suas portas de entrada invadidas e usavam Linux.
Antes que venham uma avalache de trolls, isso não significa que o Linux é inseguro pois todas as aplicações foram atacadas através SQL Injection .
Nesta série de 3 artigos quero ajudar meus irmãos SysAdmins passando uma série de referências de como manter uma infraestrutura para aplicações Web segura. Só que o SysAdmin não é nenhum mestre dos magos pois se o sistema estiver todo reforçado e a aplicação for desenvolvida “nas coxas” seu trabalho foi jogado no lixo.
Na 1a parte abordaremos como preparar o sistema básico ( S.O. ) seguindo boas práticas simples e efetivas. Na 2a. parte abordaremos como montar e manter um SGBD de forma segura e para finalizar abordaremos como desenvolver e testar aplicações web com foco em segurança.
OBS: O objetivo dessa série de artigos não é virar um tratado de segurança de aplicações web. A intenção é compartilhar minha experiência e aprender com a experiência dos leitores. Como não sou DBA, nem desenvolvedor posso me enganar em alguns destes assuntos e peço a toda a comunidade que contribua tornando estes artigos os mais completos possíveis.
Efeito Redmond: Trojan Zeus infecta 74.000 hosts espalhados pelo globo
February 22, 2010 by alexos · 5 Comments
2.500 organizações espalhadas pelo globo, cerca de mais de 74.000 máquinas, estão envolvidas em uma botnet global devido a infestação do trojan Zeus permitindo que várias senhas bancárias, contas de email e dados confidencias sejam roubados.
Este trojan é enviado em um e-mail bastante convincente que simula uma mensagem da NSA, a Agência Nacional de Segurança do governo americano. O email pede que a vitima faça o download do relatório “2020 Project.” outra variante mascara o remetente nobody@sh16.ruskyhost.ru com a conta de email admin@intelink.gov.
Como característica básica de um trojan horse ele pode ser usado para pesquisar e roubar arquivos em vários computadores, fazer o download e a instalação de vários programas e permite o controle remoto do computador infectado.
Somente 16 dos 39 anti-virus usados pelo Virustotal.com detectaram o arquivo infectado.
Alguns alvos destes ataques são empresas como Merck, Cardinal Health, Paramount Pictures, e Juniper Networks. Existem algumas especulações que os criminosos responsáveis pelos ataques estão localizados no Leste Europeu usando um servidor localizado na Alemanha.
Mais de 75 Gig de dados já foram roubados 68.000 logins de acesso a emails, contas bancárias, redes sociais, Yahoo, Hotmail e cerca de 2.000 certificados digitias ( SSL ) e dados individuais. Os computadores atacados também estão infectados pelo malware Waledac. As maiores vitimas destes ataques estão localizadas no Egito, Arábia Saudita, Turquia e Estados Unidos dentre os 200 países que possuem hosts infectados.
Como ocorreu anteriormente com o plugin Sothink Web Video Downloader do Firefox somente os usuários do sistema operacional de Redmond estão fadados a sofrer esse mal irremediável.
Este não será o 1o. nem o último ataque global aos usuários deste sistema. Culpa somente de tio Bill e os seus comparsas? Acredito que não. Acredito que boa parte culpa venha dos usuários pelas seguintes razões:
1o. Usar Windows
2o. Usar Windows
3o. Não possuir o mínimo discernimento do valor das informações contidas em suas máquinas
4o. Não se proteger usando ferramentas de segurança além do já batido e cada vez mais ultrapassado AV.
5o. Clicar em qualquer maluquice que surge em sua tela.
6o. Não verificar a procedência das mensagens que surgem em suas caixas de email
7o. Vou parar aqui senão a lista não acaba.
Posso facilmente listar alguns worms e malwares que acabaram com metade do globo na última decada:
Quer a lista completa desde 1970? Clique AQUI
Para ajudar este intrépidos usuários disponibilizo o LINK de uma ferramenta para remoção do Zeus.
Infelizmente não posso garantir a eficácia da ferramenta porque sou um feliz e seguro usuário do GNU/Linux desde 1997, inclusive fiquei um pouco desatualizado sobre o assunto vírus por causa desta escolha.
Fonte
-
Enable MSA ( submission) in Postfix
I understand that I am posting the solution is a bit late, since the controversy generated over this issue began in January.
submission inet n – n – – smtpd
Enable the Postfix MSA ( Mail Submission Agent ) is very easy just uncomment the line below
submission inet n – n – – smtpd
invoke-rc.d postfix restart
Restart the Postfix:
invoke-rc.d postfix restart
telnet localhost 587
Test
telnet localhost 587
I recommend reading the following RFCs, thus infuse comments.
RFC 4409 – Message Submission for Mail
RFC 5068 – Email Submission Operations: Access and Accountability Requirements
Experts descobrem como quebrar proteção de cartões de crédito com chip
February 13, 2010 by alexos · Leave a Comment
Um grupo de pesquisadores desobriu uma falha significativa no sistema de segurança chip-e-PIN (senha) usado por companhias de cartão de crédito no mundo todo. A falha permite que um atacante use o cartão sem o PIN associado a ele.
Em uma operação normal, utilizando o chip e o PIN do sistema, o portador precisa digitar uma senha para autenticar a si mesmo. Mas os pesquisadores descobriram uma maneira de usar o cartão ao digitar qualquer código PIN, tornando o sistema de autenticação inútil. E de fato, devido à forma como o sistema funciona, a operação ficaria completamente legítima para o banco, o que demonstraria que a senha correta foi usada.
A falha é que quando você coloca um cartão em um terminal, uma negociação ocorre sobre como o titular do cartão deve ser autenticado: usando um PIN, uma assinatura ou nada. Esta subprotocolo em particular não é autenticado, assim você fazer o cartão “pensar” que está fazendo uma transação de chip-e-assinatura, enquanto o terminal pensa que é chip-e-PIN. O resultado é que você pode comprar coisas usando um cartão roubado e um PIN de 0000 (ou qualquer coisa que você quiser). Fizemos isso, filmando, usando cartões de vários jornalistas. As operações funcionaram e os recibos vieram com impresso “Verifcado por senha”.
O ataque foi desenvolvido por um grupo de pesquisadores da Universidade de Cambridge, incluindo Ross Anderson, Steven J. Murdoch, Drimer Saar e Mike Bond. O grupo descobriu que eles eram capazes de usar o ataque online com sucesso, bem como nas operações do mundo real.
Então, o que deu errado? Em essência, existe um buraco nas especificações que criam o sistema “Chip-e-PIN”. Essas especificações consistem no quadro do protocolo EMV, o sistema regras de cada cartão (Visa, MasterCard), as regras nacionais de pagamento, e os documentos produzidos por cada emissor individual descrevendo suas próprias personalizações. Cada especificação define os critérios de segurança, opções de ajustes e conjuntos de regras – mas nenhuma assume a responsabilidade por listar os controles no terminal. Como resultado, centenas de emitentes independentemente fazem a coisa errada, com a falsa garantia de que todas as bases estão cobertas a partir das especificações comuns. A especificação EMV está quebrada, e precisa de conserto.
O sistema chip-e-PIN sistema é o regime de segurança para transações de cartão de crédito dominante em vários países, e os pesquisadores disseram que precisa ser totalmente reformulado.
“Nos últimos cinco anos, milhares de usuários de cartões foram roubados e tiveram seus cartões usados por criminosos. Os bancos muitas vezes dizem a eles que a senha foi usada, então a culpa é dos clientes. Entanto, nós mostramos que é fácil de usar um cartão sem conhecer a senha – e o recibo diz que a operação foi “verificada pelo PIN”, mesmo que não tenha sido “, disse Anderson, em comunicado.
Referência: http://threatpost.com/pt_br/
Languages
English- Portuguese
Banners
-