Caso QuadrigaCX se torna mais intrigante

Criptomoedas

Fonte da imagem: https://en.wikipedia.org/wiki/Cryptocurrency

O mundo das criptomoedas tem tido seus altos e baixos, com supervalorizações em certos períodos, desvalorizações recorde em outros, bem como notícias a respeito de violações de segurança em carteiras virtuais, entre outras, porém uma das histórias mais sinistras acaba de ficar mais intrigante, onde a notoriedade da QuadrigaCX atingiu escala mundial após a suposta morte de seu CEO, Gerald Cotten, no final do ano passado.

As informações iniciais, publicadas pela empresa canadense de negociação de moedas digitais, afirmavam que apenas Cotten possuia acesso às contas dos investidores, e que após a sua morte este acesso estava comprometido, já que o CEO era o único que sabia as credenciais de acesso às carteiras de clientes, que mantinham cerca de cento e noventa milhões em criptomoedas.

“Como assim somente o CEO tinha acesso?”, vocês perguntam, bem o que a empresa afirma é que estes valores eram mantidos em “cold wallets”, ou seja, carteiras digitais não acessíveis via Internet, aumentando a segurança contra tentativas de acesso indevidas, sendo transferidos para “hot wallets” no momento em que os clientes decidiam movimentá-los, o que pode até ser uma boa prática de segurança, porém o mesmo não pode ser dito sobre apenas uma pessoa ter acesso aos fundos depositados para a realização destas movimentações.

“Então lascou né? Tudo preso depois da morte do cara?”, isso também era como os clientes da empresa achavam que ficaria, depois da correria infrutífera para a retirada de fundos, e de ficarem sem resposta do suporte sobre o problema, até que o site ficasse offline por conta do pânico.

Agora as investigações devem assumir pelo menos mais uma linha de raciocínio devido às descobertas realizadas pela Ernst & Young, empresa que presta serviços de consultoria e auditoria também no Brasil.

Os auditores descobriram, através do acesso ao laptop pessoal do CEO, que as carteiras digitais começaram a ser esvaziadas em meados de 2017 e, por volta de abril de 2018, quase todas elas já estavam limpas, restando apenas uma, que se presume que assim era mantida para atender a necessidades de clientes que precisassem de transferências em um curto espaço de tempo.

Porém, mesmo esta foi esvaziada em 3 de dezembro de 2018, apenas alguns dias antes da alegada morte de Cotten ocorrer devido a complicações da doença de Crohn em um hospital na Índia, onde também alegadamente este estava realizando trabalho filantrôpico.

Parece suspeito para vocês? Também o é para grande parte dos clientes da QuadrigaCX, e até um deles ofereceu uma recompensa de cem mil dólares para quem oferecer informações a respeito do montante desaparecido.

Tudo isso nos faz lembrar da importância das políticas de segurança da informação, e de que estas contemplem boas práticas de segurança, como, neste caso, a separação de tarefas e a rotação de trabalho, onde seriam necessárias autorizações de pelo menos duas pessoas para a movimentação desses valores, após a validação da autenticidade da solicitação, bem como a possibilidade de se auditar o trabalho realizado, através da rotação de funcionários nestas funções.

Enquanto isso, os auditores da Ernst & Young continuam tentando rastrear o destino dos valores transferidos, porém isso é extremamente difícil de ser atingido, justamente pela natureza das moedas digitais.

Como não há legislação específica para amparar os investidores em moedas digitais, e nem mesmo a cobertura de seguro, teremos de aguardar os novos capítulos deste caso para saciar a curiosidade sobre como essa história terminará, porém as lições aprendidas já podem ser absorvidas, para que os avanços tecnológicos e legislativos possibilitem a proteção de investidores, bem como o amadurecimento do mundo das moedas digitais.

Para mais informações, acessem o artigo original em inglês na ExtremeTech.

Anúncios

K2 divulga solução para impedir a exploração de vulnerabilidades zero-day

zero-day-attack-1024x413

A K2 Cyber Security, empresa baseada nos Estados Unidos e que lida com segurança da informação, afirma ter desenvolvido uma tecnologia, capaz de impedir a exploração de falhas de segurança não divulgadas e ainda não corrigidas em aplicações, mais conhecidas como vulnerabilidades zero-day.

A solução utilizada pela empresa envolve o mapeamento do funcionamento da aplicação, através de uma única análise e, em seguida, realizar o monitoramento desta baseado no comportamento mapeado, o que alegadamente impediria a ocorrência de eventos falso positivos.

“Isso nunca foi feito antes”, afirmou Pravin Madhani, CEO e co-fundador da K2. “Por ser muito difícil de realizar. Somos capazes de criar um mapa de execução para cada aplicação em minutos, e depois monitorá-lo em tempo real. Não há falso positivos.”

A tecnologia empregada nesse tipo de situação é conhecida como Control Flow Integrity (CFI), cujo significado, em uma tradução livre, seria Controle de Integridade de Fluxo, o que atualmente é realizado através de abordagens tradicionais, identificando ações potencialmente maliciosas, que podem demandar a verificação de infinitas combinações de atividades, acarretando em erros nessa detecção gerados por falso positivos ou falso negativos. Esse tipo de abordagem também gera sobrecarga na performance dos sistemas, bem como podem demandar hardware adicional.

Com a melhoria promovida pela K2 no CFI, um mapa de execução da aplicação é criado, como se fosse um baseline de seu funcionamento, permitindo a partir daí que a mesma seja monitorada e interromper a sua operação caso sejam detectadas tentativas de alteração nesse fluxo. A otimização também é aplicável a microserviços utilizados em nuvens privadas e públicas.

A empresa submeteu sete patentes para a proteção da propriedade intelectual envolvida na melhoria promovida junto ao CFI, que é oferecida através de dois módulos distintos: um nomeado como Prevent, algo como Prevenção em uma tradução livre, que detecção em tempo real de ataques zero-day, e outro chamado Segment, que tem o sentido de segmentação, e que isola as cargas de trabalho na nuvem, atribuindo identidades criptográficas exclusivas para cada uma delas antes que estas possam se comunicar. Isso impede o movimento lateral de malwares em ambientes de TI.

Para acessar o artigo original, dirijam-se ao site ZDNet.

Slackware Linux 14.2 – Reinstalando o VirtualBox 6.0.4 após upgrade do kernel

Slackware logo

Olá pessoal! Passando para compartilhar uma solução de contorno, que visa reparar a instalação do VirtualBox junto a Slackware Linux, após a recente atualização de segurança disponibilizada para o kernel Linux, junto a versão 14.2 da distribuição.

Após a instalação dos pacotes atualizados e tentativa de reinstalação do VirtualBox, a partir do binário disponibilizado pela Oracle junto ao site da aplicação, o mesmo afirma que a instalação foi realizada, porém apresentando erros que devem ser consultados através do arquivo de log.

Ao verificar o conteúdo do arquivo /var/log/vbox-setup.log, encontrei os seguintes erros:

$ tail -n 50 /var/log/vbox-setup.log

scripts/Makefile.build:277: recipe for target ‘/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o’ failed
make[2]: *** [/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o] Error 1
make[2]: *** Waiting for unfinished jobs….
if [ “-pg” = “-pg” ]; then if [ /tmp/vbox.0/r0drv/linux/memuserkernel-r0drv-linux.o != “scripts/mod/empty.o” ]; then ./scripts/recordmcount “/tmp/vbox.0/r0drv/linux/memuserkernel-r0drv-linux.o”; fi; fi;
if [ “-pg” = “-pg” ]; then if [ /tmp/vbox.0/r0drv/linux/assert-r0drv-linux.o != “scripts/mod/empty.o” ]; then ./scripts/recordmcount “/tmp/vbox.0/r0drv/linux/assert-r0drv-linux.o”; fi; fi;
if [ “-pg” = “-pg” ]; then if [ /tmp/vbox.0/r0drv/linux/alloc-r0drv-linux.o != “scripts/mod/empty.o” ]; then ./scripts/recordmcount “/tmp/vbox.0/r0drv/linux/alloc-r0drv-linux.o”; fi; fi;
if [ “-pg” = “-pg” ]; then if [ /tmp/vbox.0/linux/SUPDrv-linux.o != “scripts/mod/empty.o” ]; then ./scripts/recordmcount “/tmp/vbox.0/linux/SUPDrv-linux.o”; fi; fi;
if [ “-pg” = “-pg” ]; then if [ /tmp/vbox.0/r0drv/linux/mp-r0drv-linux.o != “scripts/mod/empty.o” ]; then ./scripts/recordmcount “/tmp/vbox.0/r0drv/linux/mp-r0drv-linux.o”; fi; fi;
Makefile:1436: recipe for target ‘_module_/tmp/vbox.0’ failed
make[1]: *** [_module_/tmp/vbox.0] Error 2
/tmp/vbox.0/Makefile.include.footer:106: recipe for target ‘vboxdrv’ failed
make: *** [vboxdrv] Error 2

As linhas que nos interessam são justamente as que aparecem mais acima, no log:

scripts/Makefile.build:277: recipe for target ‘/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o’ failed
make[2]: *** [/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o] Error 1
make[2]: *** Waiting for unfinished jobs….

Com base nesse erro, busquei por informações na Internet, e encontrei uma postagem em um blog, cujo autor já havia enfrentado o mesmo problema, postando a solução de contorno para o mesmo.

Para corrigir o erro, precisamos editar o arquivo referenciado, alterando a versão do kernel disponível no script:

$ vi /usr/src/vboxhost-6.0.4/vboxdrv/r0drv/linux/memobj-r0drv-linux.c

Substitua a versão destacada em vermelho, em três locais diferentes no arquivo:

if GET_USER_PAGES_API >= KERNEL_VERSION(4, 9, 0)

fWrite ? FOLL_WRITE | /* Write to memory. */

FOLL_FORCE /* force write access. */

: 0, /* Write to memory. */

Deixando com esta versão:

if GET_USER_PAGES_API >= KERNEL_VERSION(4, 4, 168)

fWrite ? FOLL_WRITE | /* Write to memory. *

/ FOLL_FORCE /* force write access. */

: 0, /* Write to memory. */

Agora basta executar o comando para configurar o VirtualBox novamente, e este compilará sem erros:

# /sbin/vboxconfig

Para acessar o artigo original, siga o link para o SlackBlogs – Unofficial Blog for Slackware Linux.