Atreva-se a participar em Latch Plugins Contest com hacks como Paper Key

sábado, 26 de novembro de 2016

A Elevenpaths tem uma boa tradição cujo objetivo é desenvolver a inovação e treinar a capacidade de concluir as coisas. Vocês já sabem que, na área de desenvolvimento, muitas vezes, os projetos têm tempos de conclusão “assintóticos”.

A cada seis meses permitem-nos desenvolver uma ideia por 24 horas seguidas, levá-la à prática e, depois, apresentá-la ao público. Pode ser o que for, mas o importante é que funcione. Chamamos isso de Equinox.

No Equinox de Outono de 2016, um grupo de colegas (Jorge Rivera, Pedro Martínez, Alberto Sánchez e Félix Gómez) decidiu unir o abstrato, a segurança lógica, e o concreto, algo que fosse tangível. E pensamos que também poderíamos utilizar a tecnologia do Latch e a nova API desenvolvida este ano (as “instâncias de operação”- SDK do Latch).

Foi assim que surgiu o projeto Paper Key, com o qual queríamos unir diversas peças tecnológicas, priorizando a segurança de todo o processo e abstraindo a tecnologia, para que o uso fosse simples e intuitivo.

A ideia é poder emitir um token que dê acesso a um serviço ou dispositivo. Nós imprimimos esse token em papel (algo que eu tenho) e ele só é válido quando o Emissor do token autoriza o uso no aplicativo Latch (segundo fator de autorização). 



No nosso exemplo real, uma pessoa pode imprimir um ticket com uma quantidade de dinheiro associada a ele e, depois de autorizar a operação no Latch por meio do celular, uma segunda pessoa troca o ticket em um porta-moedas automático, que entregará a quantidade indicada de moedas.

Somente duas pessoas (o Emissor e o Destinatário) e quatro blocos de tecnologia participam do processo: o aplicativo Web, a impressora de tickets, o servidor API Python e o leitor de tickets+porta-moedas.

O Emissor, por meio de um aplicativo Web, gera um ticket com um identificador de operação e uma quantidade de dinheiro. A operação fica associada à conta do Latch do Emissor e o ticket é enviado ao Destinatário por meios físicos, ou porque a impressora está em seu ambiente.



Quando o Destinatário quer consumir o ticket (neste caso, obter uma quantidade de euros de um porta-moedas automático), ele se aproxima de um leitor de tickets, que comprovará o estado da autorização no Latch. Se o Emissor do ticket não autorizar a operação, o serviço não poderá ser acessado nem consumido e, além disso, será enviada uma notificação ao app do Latch, dizendo que há uma tentativa de utilização do ticket (que é o comportamento padrão).

A arquitetura utilizada neste teste de conceito poderia ser otimizada, mas, como tínhamos que realizar todos os desenvolvimentos em 24 horas, era necessário que dividíssemos o trabalho entre os quatro. (Essa aproximação também permite que o servidor, a impressora e o leitor de tickets possam ficar em diferentes locais, já que se comunicam entre si por meio da Internet.

Levando em conta as premissas do Equinox (24 horas, que funcione e que possa ser explicado!), descrevemos os diversos componentes com mais detalhes.

O aplicativo web (WebApp)
É um aplicativo simples em PHP com uma interface em HTML líquido que permite adaptar os formulários a vários tamanhos ou orientações de tela dos celulares.


O aplicativo é executado em um servidor WAMP e comunica-se com uma API em Python para fazer a interface com a impressora e o leitor de tickets.

Trata-se de um aplicativo em PHP padrão, no qual os usuários são autenticados por meio de usuário e senha contra um MySQL, gerando-se um token de sessão. Vocês podem encontrar na Web uma grande quantidade de exemplos sobre como fazer isso.

O WebApp permite ao usuário Emissor navegar e, depois da validação, selecionar uma quantidade de dinheiro e escrever um texto livre para identificar a transação. Essas informações são enviadas por meio de um POST a um servidor em Python, que gerará uma solicitação para a impressora.


A resposta do servidor com a API em Python é um JSON que analisamos no servidor PHP para devolver a resposta ao WebApp:
{
status: [Ok/NOK]
money: [quantidade de dinheiro – para informar ao WebApp]
id: [Identificador devolvido pelo servidor – para o WebApp]
}


Na resposta do POST, recebemos o status da operação e o ID gerado para apresentá-lo na tela do telefone do Emissor.

A impressora de tickets
Este subsistema é composto por uma Raspberry Pi e uma impressora térmica de tickets. A impressora (Brother QL-570) foi emprestada com carinho pela equipe de Secretaria, e conseguimos a Raspberry do laboratório de Segurança IoT, que tem muitos hardwares para brincar.


A Raspberry conecta-se à Internet por WiFi e aguarda em uma porta uma solicitação REST com o conteúdo a ser impresso (operação “generateID”).

{
instanceId: [ID de instância Latch]
money: [quantidade de dinheiro em Euros]
}


É gerado um código QR bidimensional com a livraria libqrencode e, por meio das livrarias do Image Magic, sobrepõe-se a um fundo preestabelecido com o logotipo “Equinox”.

Em seguida, o texto é adicionado à solicitação; neste caso, o valor do ticket gerado.


O ticket final será impresso pela Raspberry PI graças ao pseudo-driver de impressão dessa impressora, disponível no Git-Hub.

O código QR é um identificador de operação codificado em Base32 e permitirá ao leitor de códigos QR comprovar o estado de autorização da operação antes de liberar o dinheiro (1 Internet Point, para quem nos perguntar por que tivemos que usar Base32 em vez de Base64).

O servidor API Python
Neste servidor, encontram-se a API em Python para o Latch (interface entre o WebApp, a impressora, o leitor de tickets e o servidor do Latch) e o servidor WAMP.

O servidor é invocado pelo WebApp por meio de um POST à porta 1338, com os campos:
{
money: [quantidade de dinheiro em euros]
text: [string de texto que aparecerá no aplicativo Latch]
}


Então, duas operações são executadas em sequência:
1. O servidor cria uma solicitação por meio da API para solicitar a “instância de operação” ao sistema Latch da Elevenpaths, sendo que, no app Latch associado ao usuário, aparecerá uma nova linha com o texto identificador da operação. Portanto, essa operação está agora sujeita à autorização do usuário, está “latcheada”.


E, na interface do app do telefone … aparecerá, dentro do serviço PaperKey, uma nova “instância de operação” com o texto inserido “Equinox Demo 2016”.


2. O servidor invoca a impressora de tickets (IP e porta da Raspberry associada à impressora) de modo que o ticket é impresso com o código QR associado à operação.

Nesse momento, o Emissor gerou uma operação no Latch, além de ter impresso um ticket em papel com um código QR que identifica essa operação.

Se o Destinatário da operação (a pessoa que pega o ticket fisicamente) quiser utilizá-lo, deverá aguardar até que o Emissor autorize essa operação.

Leitor de tickets+cofre
Este sistema é composto por outra Raspberry Pi (na caixa de papelão), um leitor laser de códigos QR, como os dos supermercados, e um dispensador de moedas colorido (nós já dissemos que eles têm muitos brinquedos.


O leitor laser apresenta-se por USB como um teclado padrão HID, de modo que, para transmitir informações ao sistema operacional, ele simula teclas pressionadas correspondentes ao código digitalizado (dígitos ou caracteres).

Isso apresentavam um problema interessante com o terminal. Para poder realizar a captura de teclas pressionadas sem contar com o STDIN do processo, já que este estaria em seu console, não estando disponível por meio de um processo lançado em um pseudo terminal, utilizamos um wrapper programado em C que intercepta os eventos do dispositivo que apresenta o kernel do Linux no espaço do usuário /dev/input/event5.


E isso gerou um segundo problema, já que o identificador de operação que utilizamos tem caracteres alfanuméricos com maiúsculas e minúsculas. E a emulação de teclado do scanner é sempre de caracteres que não precisam ser pressionados simultaneamente (por exemplo, [SHIFT] + Letra). Por isso, foi preciso realizar uma conversão de código para Base32 (que colateralmente aumenta o tamanho do string, sendo, portanto, necessário incrementar a densidade do código QR). Se você leu isso, não merece mais um Internet Point.
Depois de todas as curvas e buracos, temos um identificador de operação. Por meio da Raspberry, construímos e lançamos uma solicitação JSON contra o servidor API Python, como uma operação “checkID”.

{
Id: [Identificador de operação]
}


O servidor realizará uma consulta ao Latch, proporcionando o ID de operação associado ao usuário. Se a operação estiver “latcheada” (“Latch ON”), o sistema devolverá um erro.

Se a operação tiver sido de-latcheada (“Latch OFF”), o sistema considerará a operação como autorizada e liberará a quantidade de dinheiro indicada no porta-moedas automático.  O porta-moedas conecta-se à Raspberry Pi por USB e recebe a quantidade de moedas a ser dispensada com um código de 4 dígitos.

Latch Plugin Contest. Lembre-se!
O Paper Key, como teste de conceito, permitiu-nos demonstrar que é simples (fizemos isso em 23,5 horas!) integrar diferentes tecnologias para obter um sistema fácil de utilizar, seguro e com vários casos de uso, conforme a imaginação de cada um.

Por exemplo, seria possível utilizar bilheterias que contêm um produto proporcionado pelo Emissor e que só podem ser abertas pelo Destinatário quando o Emissor confirmar, por meio do seu Latch, que recebeu o pagamento.

Ou poderiam ser emitidos tickets para uma barra livre: só quando o responsável (por pagar) decidir isso por meio do seu Latch, os tickets começam a poder ser validados em troca de bebidas.

Também posso dar acesso de um só uso (OTA) a certas instalações, por exemplo, dar dias de teste grátis de acesso às instalações de um ginásio.

Como podem ver, muitas coisas podem ser feitas com integrações relativamente simples.

Vamos aproveitar para dizer-lhes que, há algumas semanas, a ElevenPaths convocou uma nova edição do concurso Latch Plugins Contest. Nesse concurso, você pode ganhar até 5.000 dólares. Lembre-se de que os critérios de premiação são a imaginação, o talento, a criatividade e a solução apresentada.

Se quiserem conhecer todos os passos que devem seguir para fazer sua inscrição no concurso, visite a nossa Comunidade, na qual explicamos como participar e onde você pode encontrar dicas e conselhos, e na qual você também pode participar da conversa sobre o Latch Plugins Contest. Além disso, se quiserem conhecer todo o mecanismo do concurso, lá vocês podem consultar o regulamento.

Lembre-se de que o prazo para inscrever-se no concurso vai até o dia 12 de dezembro de 2016. Mostre o seu lado mais hacker e participe agora!



ElevenPaths e Etisalat Digital anunciam parceria para Pesquisa e Desenvolvimento em Segurança Móvel

segunda-feira, 21 de novembro de 2016


Madri, 21 de novembro de 2016.- A ElevenPaths, Unidade de Segurança Virtual da Telefónica, e a Etisalat Digital, duas dais maiores prestadoras mundiais de serviços e soluções de comunicação, anunciaram hoje uma parceria na área de Pesquisa e Desenvolvimento (R&D, na sigla em inglês) em Segurança Móvel, para conduzirem extensas pesquisas sobre monitoramento e análise de ameaças a aplicativos e dispositivos. A colaboração foi anunciada na Conferência RSA 2016, realizada em Abu Dhabi. Trata-se de uma ampliação da parceria entre as empresas, ultrapassando seu atual portfólio compartilhado de Serviços de Segurança Gerenciada e Segurança Virtual. O acordo sobre Serviços de Segurança faz parte de uma cooperação mais ampla entre as empresas em diversas áreas, no marco do Contrato de Parceria Estratégica assinado, originalmente, em junho de 2011.

Francisco Salcedo, Vice-Presidente Sênior da Etisalat Digital afirmou que "o anúncio de hoje é importante porque a mobilidade ultrapassou os limites dos dispositivos, aplicativos e transações, transformando-se em um ecossistema conectado. Esta transformação tornou as plataformas móveis vulneráveis e alvos fáceis para criminosos virtuais. A colaboração e o desenvolvimento nos Centros Operacionais de Segurança Virtual da Etisalat Digital permitirão que ambas as partes ofereçam soluções para que empresas controlem atividades fraudulentas com impacto direto sobre seus serviços, sua marca ou sua reputação".

As ferramentas e o conhecimento usados na prevenção de malwares para PCs são completamente diferentes dos usados para malwares de dispositivos móveis. Um ecossistema móvel é extremamente dinâmico e os criminosos virtuais estão sempre aperfeiçoando as ferramentas e técnicas usadas neste tipo de atividade. Eles buscam modelos de negócios sustentáveis e escaláveis que gerem renda por meio de fraudes, enquanto driblam as otimizações introduzidas regularmente pelo mercado de aplicativos móveis.

As duas empresas trabalharão com o Tacyt, uma ferramenta de inteligência virtual para segurança de dispositivos móveis, desenvolvida pela Elevenpaths para monitoramento e análise de ameaças a dispositivos móveis. Tacyt usa uma abordagem de big data para pesquisa sobre o ambiente de aplicativos móveis e serviços empresariais para conduzir investigações completas, incluindo a classificação, atribuição, categorização e o monitoramento de malwares de dispositivos móveis, além de uma análise profunda sobre as diversas abordagens do malware:

  • O ecossistema de dispositivos móveis é extremamente dinâmico e os criminosos virtuais buscam modelos de negócios sustentáveis e escaláveis que gerem renda por meio de fraudes, enquanto driblam as otimizações introduzidas pelos mercados de aplicativos móveis.
  • A atribuição e categorização de famílias de malware revela tendências na comunidade de criminosos virtuais.
  • A categorização do risco do malware é vital para a defesa contra ameaças a dispositivos móveis na implantação de BYOD (Bring Your Own Device - traga seu próprio dispositivo). Se um funcionário instala um adware agressivo em um dispositivo, isso, por si só, seria suficiente para bloquear o acesso ao e-mail corporativo? E se o adware se espalhar e criar uma backdoor? A categorização é útil nesse tipo de implantação.

Nas palavras de Pedro Pablo Pérez, CEO da ElevenPaths e Diretor Executivo da Telefónica Global Security: "É uma honra colaborar com a Etisalat Digital na condução dessas pesquisas e análises em profundidade sobre ameaças a dispositivos móveis. Analistas virtuais podem usar a Tacyt para pesquisas manuais ou automatizadas, correspondências e investigação de diferentes parâmetros (metadados) dentro de aplicativos iOS e Android. Isto permite a identificação de potenciais 'singularidades', um conceito que se refere a qualquer coisa que um dado (datas, tamanho, imagens, certificados digitais) - técnico ou circunstancial - faça para tornar o aplicativo ou seu desenvolvedor - como indivíduo - singular ou único em relação aos demais".


ElevenPaths Talks: O Protocolo de criptografia para web HSTS

terça-feira, 8 de novembro de 2016



Na próxima quinta-feira, 10 de novembro nosso companheiro em Cyber segurança Diego Espitia dará uma palestra na qual se comentará sobre o Protocolo de criptografia para web HSTS, Este protocolo surgiu com o objetivo de garantir que os servidores não sofram “downgrade attacks” ou “cookie hijacking”. Una-se ao webcast e conhecerá um pouco mais a origem do HSTS, seu funcionamento, vantagens e desvantagens.

A duração da palestra do Diego Espitia será de aproximadamente 30 minutos, divididos entre 20 e 25 minutos de exposição e de 5 a 10 minutos de perguntas e respostas. A palestra esta programada para às 15.30h (Madrid) e estará disponível em nosso canal no YouTube. A apresentação será realizada pelo Hangouts e será ministrada em castelhano.

Se você quiser para saber mais sobre, sinta-se livre para parar por nossa Comunidade, onde os nossos colegas falar sobre este e outros temas de interesse no mundo da segurança. Você pode verificar o cronograma de palestras para ver os webcasts que serão apresentados. Lembre-se, você tem um compromisso no próximo dia 10 de novembro as 12:30. Para se inscrever você deve usar o seguinte formulários ElevenPaths Talks.

Mais informações: talks.elevenpaths.com