Os fundos estão #SAFU: Com várias tentativas e ângulos de ataque, o Kraken Security Labs falhou em roubar a semente.
Deteção de manipulação ineficaz: Não explorável e não afeta a segurança da carteira.
Ataque de degradação: Não explorável, corrigido.
Agora vamos analisar as questões apresentadas pelo Kraken Security Labs no relatório.
1. Deteção de Manipulação Ineficaz
No relatório, o Kraken Security Labs afirma ter contornado o mecanismo de autodestruição removendo o escudo de RF e reconectando um único pino. No entanto, esse design não está relacionado à lógica de segurança central do dispositivo. Em vez disso, o escudo de RF é um requisito para o padrão EMC (Compatibilidade Eletromagnética). Contornar essa configuração não criará uma ameaça real à segurança da carteira de hardware. E isso foi comprovado pela falta de progresso substancial do Kraken Security Labs nesse cenário de ataque. O mecanismo de autodestruição e de apagamento de dados está incorporado em muitos detalhes no SafePal S1 em nível de hardware e software. É inadequado afirmar que o mecanismo é ineficaz simplesmente porque nenhuma outra armadilha foi acionada.
2. Violações de Licenciamento de Código Aberto
O SafePal é uma carteira descentralizada que visa construir soluções de gerenciamento de ativos seguras e amigáveis para as massas cripto. No momento, ainda não é de código aberto.
Não ser de código aberto não significa que os produtos SafePal não sejam seguros para uso. Como Tagore escreveu em Stray Birds: "O melhor não vem sozinho. Ele vem com a companhia de todos", o código aberto também tem suas vantagens e desvantagens.
Por um lado, tornar um produto de código aberto permite que todos revisem e verifiquem se há códigos maliciosos incorporados nos produtos, ajudando a construir confiança e transparência. Também ajuda o produto a melhorar e evoluir com o suporte das comunidades de desenvolvedores. Os desenvolvedores podem revisar os códigos e localizar possíveis vulnerabilidades, aumentando assim a segurança do produto.
Por outro lado, a maioria das pessoas sem formação técnica pode não ser capaz de auditar verdadeiramente os códigos de código aberto e verificar se são seguros, enquanto o código aberto na verdade facilita para os hackers explorarem vulnerabilidades potenciais e prejudicarem os usuários. Portanto, do ponto de vista dos usuários, é difícil dizer se o código aberto traz mais benefícios do que riscos.
Além disso, como o desenvolvimento de software é um processo complicado, mesmo que um produto seja de código aberto, é muito provável que os usuários não consigam dizer se os códigos nos produtos atuais que estão usando são realmente consistentes e compilados a partir dos códigos de código aberto.
Em geral, o SafePal ainda não é de código aberto. Mas o código aberto sempre esteve em nossa consideração. No futuro, também podemos optar por abrir parte dos códigos com base na situação real, assim como a Apple e a Microsoft fizeram.
3. Ataque de Degradação
No relatório, o Kraken Security Labs removeu o flash da placa principal e usou um programador de flash especial para reverter o firmware do SafePal S1 para uma versão oficial anterior. O relatório aponta os riscos potenciais que esse fenômeno poderia causar quando um atacante experiente inicia um ataque de degradação usando uma versão de firmware vulnerável anterior (se houver).
O SafePal S1 adotou uma tecnologia de cadeia de inicialização segura (para evitar quaisquer tentativas maliciosas durante a operação do firmware) e a tecnologia de troca de chaves Elliptic Curve Diffie - Hellman (para garantir a segurança da comunicação entre o Processador de Aplicação e o Elemento Seguro). Esta estrutura central foi implementada desde o primeiro dia. No relatório, o Kraken Security Labs não fez progressos substanciais na penetração do mecanismo de segurança central, o que prova, de outro lado, o nível de segurança da arquitetura central do SafePal S1.
O SafePal lançou o firmware V1.0.24 para adicionar novos recursos e corrigir a limitação de degradação. As diretrizes de atualização podem ser encontradas aqui.
4. Possível Fraqueza de Comunicação Entre os Processadores de Aplicação e o Elemento Seguro
O Kraken Security Labs mencionou no relatório que os processadores de aplicação que se comunicam com o elemento seguro são consistentemente o ponto fraco nas carteiras de hardware de criptomoedas. Aqui está nossa divulgação técnica adicional sobre este item:
Desde o primeiro dia em que o firmware do SafePal S1 foi lançado, o dispositivo adotou a tecnologia Elliptic Curve Diffie - Hellman. Sempre que o SafePal S1 é ligado, os processadores de aplicação negociarão com o Elemento Seguro uma nova chave para criptografar as comunicações. Um atacante não pode facilmente extrair e criptografar o conteúdo da comunicação mesmo que fisicamente obtenha o dispositivo, force bruta e monitore as comunicações. Mesmo que o atacante falsifique uma transação para o Elemento Seguro, ela falhará na verificação de uma senha especial gerada a partir do código PIN do dispositivo e dos IDs exclusivos dos chips. Após 5 tentativas, a chave privada será apagada. Isso pode proteger efetivamente o dispositivo de tentativas maliciosas visando o mecanismo de comunicação.5. Outras Tentativas e Análises1) Tentativas de Modificação de Flash
O Kraken Security Labs tentou várias modificações de firmware, cada vez levando ao mau funcionamento do dispositivo. Nenhum progresso substancial foi feito.
Isso está dentro de nossas expectativas. O SafePal S1 adota a tecnologia de cadeia de inicialização segura que verifica cada etapa para frente e para trás durante o processo de inicialização. Uma vez que qualquer etapa falhe na verificação, o sistema será encerrado.
2) Tentativa de Atualização de Firmware
O Kraken Security Labs tentou manipular o arquivo upgrade.bin, o que levou a uma falha na atualização.
Isso está dentro de nossas expectativas. O arquivo upgrade.bin foi criptografado desde o primeiro firmware lançado. Antes de uma atualização de firmware, o dispositivo validará a assinatura no arquivo upgrade.bin. Uma vez que o upgrade.bin seja manipulado, a validação falhará, e o atacante não poderá entrar no processo de atualização de firmware e inserir conteúdo ilegal.
3) Tentativa de Manipulação de Banco de Dados
O Kraken Security Labs tentou alterar os dados sensíveis da carteira no banco de dados S1, como Endereços e Transações. Após fazer isso, ocorreu um mau funcionamento.
Isso está dentro de nossas expectativas. Todos os dados sensíveis no banco de dados S1 são totalmente criptografados via AES. A chave criptografada é gerada a partir dos IDs exclusivos de vários chips com base em um algoritmo especial. Qualquer tentativa de alterar ou falsificar os dados e componentes do dispositivo levará a um mau funcionamento do dispositivo.
4) Análise de Configuração e Banco de Dados
O wallet.cfg inclui informações como tempo de inatividade, idioma padrão, nome da carteira, etc. Não são dados sensíveis, pois podem ser visualizados instantaneamente ao ligar o dispositivo sem tentativas adicionais. Mesmo que os atacantes adotem tentativas semelhantes às do Kraken Security Labs para abrir o dispositivo, remover o flash e alterar o nome da carteira por meio de um processo complexo com um programador de flash, os usuários notarão a mudança no nome da carteira ao abrir o dispositivo. Alterar o wallet.cfg não afetará a segurança de nenhuma chave privada. A partir do firmware V1.0.24, o arquivo wallet.cfg foi abandonado.
Créditos
Esses ataques e tentativas compartilhados no relatório foram concluídos sem notificação antecipada ao SafePal. O relatório apresenta totalmente o profissionalismo e o know-how do Kraken Security Labs. Gostaríamos de agradecer aos pesquisadores do Kraken Security Labs por relatarem as descobertas em grande detalhe e por terem a boa vontade de proteger os usuários de quaisquer ataques maliciosos.
