No final dos anos 1990, um vírus de computador conhecido como CIH começou a infectar alguns computadores. Sua carga útil, quando acionada, sobrescreveu as informações do sistema e destruiu o BIOS do computador, basicamente bloqueando qualquer computador que infectasse. Um vírus que afeta os sistemas operacionais modernos (como o Windows 10) pode destruir o BIOS de um computador moderno e essencialmente bloqueá-lo da mesma maneira forma, ou agora é impossível para um vírus obter acesso à BIOS de um computador moderno?
Comentários
- sim, mas da perspectiva do invasor é um desperdício ou recursos … Mais informações sobre um rootkit para UEFI como exemplo no artigo abaixo … welivesecurity.com/wp-content/uploads/2018/ 09 / ESET-LoJax.pdf
- Os comentários não são para discussões extensas; esta conversa foi movida para o chat .
- Algumas (ou a maioria?) placas-mãe de desktop têm uma ROM usada para recuperar o BIOS de alguma forma de mídia (antigamente, disquetes, hoje em dia, pen drives, talvez cd-rom). A ROM não pode ‘ ser modificada; no entanto, a recuperação geralmente requer a abertura da caixa e a movimentação de um jumper para inicializar no modo de recuperação do BIOS. Eu não ‘ não sei como laptops lidam com isso.
- Relacionado: security.stackexchange.com/q / 13105/165253
Resposta
Os computadores modernos não têm BIOS, eles têm a UEFI . Atualizar o firmware UEFI do sistema operacional em execução é um procedimento padrão, portanto, qualquer malware que conseguir ser executado no sistema operacional com privilégios suficientes pode tentar fazer o mesmo. No entanto, a maioria dos UEFIs não aceitará uma atualização que não seja assinada digitalmente pelo fabricante. Isso significa que não deve ser possível sobrescrevê-lo com código arbitrário.
Isso, no entanto, assume que:
- os fabricantes da placa-mãe conseguem manter suas chaves privadas em segredo
- a UEFI não tem nenhuma vulnerabilidade de segurança não intencional que permita sobrescrevê-la com código arbitrário ou que possa ser explorada para causar danos.
E essas duas suposições não são necessariamente válidas .
Com relação às chaves vazadas: se uma chave de assinatura UEFI se tornasse conhecida do público em geral, então você pode supor que haveria muitas reportagens na mídia e correções histéricas acontecendo. Se você seguir algumas Notícias de TI, você provavelmente verá muitas manchetes alarmistas “Se você tiver uma placa-mãe [de marca] ATUALIZE SUA UEFI AGORA !!! 1111oneone” . Mas outra possibilidade é assinar chaves vazadas secretamente para atores estatais. Portanto, se seu trabalho pode ser interessante para espionagem industrial, isso também pode ser uma ameaça confiável para você.
Em relação a bugs: ganho de UEFIs mais e mais funcionalidade que tem mais e mais possibilidades para bugs ocultos. Eles também não possuem a maioria dos recursos de segurança interna que você tem depois de inicializar um sistema operacional “real”.
Comentários
- Os comentários não são estendidos discussão; esta conversa foi movida para bate-papo .
Resposta
Sim, é definitivamente possível.
Hoje em dia, com a UEFI se espalhando, é ainda mais preocupante: a UEFI tem uma superfície de ataque muito maior do que o BIOS tradicional e uma (potencial) falha na UEFI poderia ser usada para obter acesso à máquina sem precisar qualquer tipo de acesso físico ( conforme demonstrado pelo povo de Eclypsium no chapéu preto no ano passado ).
Resposta
Na prática, um vírus é um software, então pode fazer qualquer coisa que qualquer outro software pode fazer.
Então, da maneira mais simples responder a esta pergunta, e todas as outras da classe “Os vírus podem fazer X?” é perguntar “O software atualmente faz X?”
Essas perguntas podem incluir “um vírus pode levar meu cachorro para passear?” (não sem um robô passeador de cachorro); “Um vírus pode me trazer pizza?” (sim: infelizmente, este não é o foco principal da maioria dos autores de vírus).
As BIOS (UEFI) são atualizadas usando software? A resposta é, sim, eles são. O meu foi atualizado ontem à noite, quando reiniciei.
E então a resposta é sim.
Pela mesma lógica, os vírus também podem causar (e têm causado historicamente) danos físicos à CPU, discos rígidos e impressoras.
Sistemas de automação residencial e veículos sem motorista também são possíveis alvos de danos físicos, mas não conheço nenhum vírus que tenha feito isso.
Comentários
- Eu não ‘ me importaria muito se minhas informações pessoais fossem usadas por desenvolvedores de malware para pedir pizza grátis e nada mais. (+1 para um raciocínio útil)
- @Marc.2377, eu não me importaria muito se suas informações pessoais fossem usadas para pedir pizza grátis para mim … 🙂
- Os vírus modernos terão uma tempo causando danos físicos. No máximo, eles poderiam desgastar um pouco o hardware executando a CPU muito quente, o que encurta a vida útil, mas ‘ não é comum ser capaz de causar danos . No passado, isso não ‘ era o caso. Veja ” o golpe da morte “.
- @forest Aren ‘ o software dos ventiladores e sistemas de refrigeração controlados atualmente? Eu ‘ Não tenho certeza, mas aposto que você poderia de alguma forma corromper o ventilador da CPU ou GPU com o software. A Rússia destruiu os geradores remotamente, ligando e desligando-os em uma frequência ressonante – aposto que há truques semelhantes que podem matar seu monitor muito rapidamente. Os discos rígidos platter podem definitivamente ser destruídos ao girá-los para cima e para baixo repetidamente, os drives de estado sólido são vulneráveis a ciclos repetidos de leitura / gravação. Aposto que um hacker motivado pode fazer muitas coisas.
- Acho que ‘ precisaríamos definir o escopo de ” causar danos físicos ” antes de decidirmos se era possível / plausível. Se você restringir a definição a literalmente danificar o computador que está executando o código, isso ‘ é muito restrito e acho que @forest está certo. Se você incluir o dano físico em um sentido mais geral, é ‘ muito mais fácil imaginar cenários em que um computador infectado ‘ está controlando algo outros (usina de energia, semáforos, sistema de transporte em massa, estação de tratamento de água, etc.) podem facilmente causar grandes danos físicos.
Resposta
Sim, é definitivamente possível.
Aqui está um exemplo de uma atualização de sistema operacional de malware fraudulentamente assinada com a chave privada do fabricante: https://www.theregister.co.uk/2019/03/25/asus_software_update_utility_backdoor/
De acordo com a Kaspersky Labs, cerca de um milhão de laptops Asus foram infectados por Shadowhammer, com uma atualização que parecia estar assinada corretamente. Não está claro se isso alterou o firmware, mas certamente poderia ter feito.
Resposta
Sua pergunta sugere um assunto mais profundo que é anéis e permissões de código em um sistema operacional. No MS DOS, o código pode fazer o que quiser. Se o código quisesse gravar todos os 0x00 “s em um disco rígido, poderia, se quisesse enviar uma saída estranha para uma peça de hardware, também não havia nada que impedisse o código do usuário. Em um sistema operacional moderno, existe um conceito de anéis (isso é reforçado pela CPU). O kernel roda no anel zero e pode fazer o que quiser. O código do usuário, por outro lado, não pode. Ele roda em algo chamado anel 3 e recebe seu próprio pequeno pedaço de memória e dentro dessa memória pode fazer o que quiser, mas não pode falar diretamente com o hardware . Se o código do usuário tentar se comunicar com o hardware, o kernel imediatamente mata o programa. Isso significa que é altamente improvável que um vírus comum possa matar o hardware porque não pode se comunicar diretamente com ele.
Se o kernel é hackeado e o jogo basicamente acabou. O kernel pode fazer o que quiser e uma série de coisas ruins podem acontecer, como overclock da CPU a um ponto onde o hardware fica instável, apagando os discos rígidos (preenchendo o com zeros por exemplo), ou qualquer outro ataque plausível.
Comentários
- ” Se o código do usuário ‘ tentar falar com o hardware, o kernel imediatamente mata o programa ” – Sério? Você pode fornecer uma citação para isso? Achei que a instrução protegida simplesmente falharia e ‘ cabe ao programa lidar com isso razoavelmente ou travar.
- @Marc .2377 Está correto. Se o usuário ‘ s código tenta executar uma instrução em CPL3 que requer privilégios CPL0, ele lançará
#GP(0)(falha de proteção geral ou GPF). Isso faz com que o código salte para o kernel para ver qual manipulador de sinais foi configurado para aquele evento. Por padrão, o kernel irá matar o processo, embora seja ‘ tecnicamente possível para o processo configurar um manipulador de sinal para SIGSEGV, caso em que o kernel retoma a execução do processo em a localização do manipulador de sinal. No entanto, ‘ geralmente não é uma boa ideia porque um processo é considerado em um … - … estado indefinido de acordo com POSIX se a execução for retomada depois de gerado um SIGSEGV que não ‘ veio de
raise(). Ele irá retomar a execução na instrução com falha que apenas será executada novamente e fará com que o processo seja bloqueado se o sinal for ignorado.Portanto, pode ser responsabilidade do programa lidar com isso, se configurar um manipulador de sinal para SIGSEGV, mas há ‘ s praticamente nunca qualquer situação em que isso seria feito (embora eu ache que o emulador Dolphin captura segfaults para algum tipo de otimização de hacky, então não ‘ precisa emular algum comportamento estranho e pode contar com o MMU). - Veja isto para um (raro) exemplo de quando é até o programa. Ou apenas leia PoC || GTFO 6: 3.
Resposta
Potencialmente. No entanto, seria difícil de fazer, já que provavelmente teria que se disfarçar como uma atualização legítima do BIOS em algum momento. O método para fazer isso mudará dependendo da sua mobo, mas é provável que envolva o vazamento de chaves privadas ou de hardware ou outros segredos.
Resposta
Sim. É específico do hardware, mas aqui está um caso de um usuário quebrando acidentalmente o firmware da placa-mãe no nível do sistema operacional https://github.com/systemd/systemd/issues/2402
Um bug no firmware de um laptop MSI significava que limpar as variáveis efi tornava o laptop inutilizável. Porque essas variáveis foram expostas ao sistema operacional e montadas como um arquivo, excluindo todos os arquivos do nível do sistema operacional causou o problema que poderia ser explorado por um vírus para atingir especificamente essas variáveis.
Resposta
Existem muitas maneiras, e algumas deles são perturbadores. Por exemplo, Computrace parece ser uma porta dos fundos permanente que pode ignorar não apenas o sistema operacional, mas até mesmo o BIOS. E, de forma mais geral, o Intel Management Engine tem controle total sobre o seu computador e pode ser explorado. Eles podem modificar sua BIOS, mas nem mesmo precisam. Apenas em 2017, pesquisadores de segurança descobriram o ut como explorar o Intel IME via USB para executar código não assinado .
A questão é que mesmo se você tiver um sistema operacional totalmente seguro e você nunca baixa nenhum software inseguro ou malicioso, ainda há uma possibilidade não desprezível de ser afetado por um malware que contorna tudo isso, explorando uma vulnerabilidade de segurança em seu hardware (mesmo quando seu computador está supostamente desligado).
Resposta
Algo que não vi aqui:
Se o invasor obtiver permissão suficiente para instalar até mesmo um oficial Firmware UEFI, corretamente assinado pelo fabricante do sistema, eles ainda podem deixar o computador em um estado não inicializável, desligando-o à força em um momento oportuno durante o processo.
O código de atualização em firmwares modernos geralmente tenta minimizar a quantidade de tempo que o computador passa em um estado em que uma falha de energia pode causar a corrupção do firmware, e alguns firmwares têm até um modo de recuperação que será ativado nesse caso.
No entanto, muitos desses sistemas não são totalmente à prova de balas. Embora eles ofereçam boa proteção contra falhas de energia aleatórias, um desligamento oportuno ainda pode derrubá-lo se o firmware não tiver um recurso de recuperação automática robusto.
Além disso, talvez nem seja necessário atacar o firmware do sistema principal. Praticamente todo dispositivo em um PC moderno tem algum tipo de firmware, e muitos deles podem ser atualizados via software. Esses dispositivos também são menos seguros. Eles podem aceitar firmwares não assinados inteiramente, ou pelo menos ser menos resilientes contra desligamentos maliciosos durante o processo de atualização.
Se você destruir o firmware no controlador de energia, controlador de armazenamento, dispositivo de armazenamento, dispositivo de vídeo ou controlador de entrada, o sistema pode se tornar tão inutilizável quanto se você tivesse atacou a UEFI.