# Exercícios MT1

Questões de exames antigos de Fundamentos de Segurança Informática, com resolução.

Página: https://resumos.rgo.pt/cadeiras/fsi/exercicios-mt1/

## Conceitos e princípios de segurança

Classificar ameaça, vulnerabilidade e exploit

Teste Intercalar, 2021/22

Atribua a cada um dos seguintes exemplos a classificação 1 (ameaça), 2 (vulnerabilidade) ou 3 (exploit):

*   ativista que discorda da política de uma empresa
*   mensagem que provoca leitura de memória out of bounds na heap
*   empresa concorrente
*   overflow de inteiros no cálculo do tamanho de um buffer
*   catástrofe natural
*   utilização de memória depois de libertada
*   JavaScript que faz heap spraying
*   esquecimento de realizar um update de segurança

Solução

Ameaças (1): ativista, empresa concorrente, catástrofe natural. Vulnerabilidades (2): mensagem com leitura out of bounds, overflow de inteiros, utilização de memória libertada, esquecimento do update. Exploit (3): JavaScript de heap spraying.

Uma ameaça é um agente ou evento com potencial para causar dano; uma vulnerabilidade é uma fraqueza do sistema explorável; um exploit é o código ou técnica que concretiza a exploração. O heap spraying é código do atacante, logo exploit; as restantes fraquezas são propriedades do sistema vulnerável.

Confere a tua resposta:

*   Classifica como ameaças (1) o ativista, a empresa concorrente e a catástrofe natural.
*   Classifica como vulnerabilidades (2) a leitura out of bounds, o overflow de inteiros, o use after free e o esquecimento do update.
*   Classifica como exploit (3) o JavaScript de heap spraying.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/principios-seguranca/#ativo-amea%C3%A7a-e-vulnerabilidade)

Zero-day vulnerability e valor de mercado

Teste Intercalar, 2021/22

Explique o conceito de zero-day vulnerability e indique uma razão pela qual poderá ter grande valor de mercado.

Solução

Uma zero-day é uma vulnerabilidade que ainda não é conhecida publicamente nem corrigida pelo fabricante. Tem grande valor de mercado porque não existe defesa ou assinatura de deteção disponível, pelo que um exploit pode comprometer sistemas antes de qualquer proteção ser aplicada.

O valor de uma zero-day advém da assimetria entre atacante e defensor: enquanto a falha não for conhecida, não há patch nem assinatura de antivírus, e o ataque tem taxa de sucesso elevada.

Confere a tua resposta:

*   A resposta define zero-day como uma vulnerabilidade ainda desconhecida do fabricante (e sem correção disponível).
*   A justificação do valor de mercado liga-se ao facto de não existir defesa conhecida, podendo ser usada contra muitos alvos antes de ser detetada.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/principios-seguranca/#ativo-amea%C3%A7a-e-vulnerabilidade)

Os três eixos da segurança (tríade CIA)

Teste 1, 2023/24

A segurança é frequentemente descrita em termos de três eixos amplos. Quais são esses três eixos?

Solução

Confidencialidade / Integridade / Disponibilidade.

Confidencialidade impede o acesso não autorizado, integridade garante que os dados não são alterados indevidamente e disponibilidade garante o acesso quando necessário.

*   **Segurança / Exposição / Usabilidade.** Estes são eixos de compromisso de usabilidade, não a tríade clássica.
*   **Confidencialidade / Integridade / Disponibilidade.** A tríade CIA (Confidentiality, Integrity, Availability) é a descrição clássica das propriedades de segurança.
*   **Confidencialidade / Integridade / Autenticação.** A autenticação é um mecanismo, não um dos três eixos da tríade.
*   **Confidencialidade / Funcionalidade / Usabilidade.** Funcionalidade e usabilidade não fazem parte da tríade.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/principios-seguranca/#ativo-amea%C3%A7a-e-vulnerabilidade)

Porque é devastador um ataque de zero-day

Teste 1, 2024/25

Um ataque de zero-day é devastador porque:

Solução

Explora uma vulnerabilidade desconhecida.

A definição de zero-day centra-se na ausência de conhecimento público: sem patch e sem assinatura de deteção, o ataque não encontra defesa conhecido no momento em que ocorre.

*   **Explora uma vulnerabilidade desconhecida..** Sem conhecimento público da falha, não há correção nem mecanismo de deteção disponível no momento do ataque.
*   **Explora uma vulnerabilidade recentemente publicada, mas ainda não corrigida..** Nesse caso já existe conhecimento público da falha, pelo que deixa de ser zero-day.
*   **Não requer qualquer intervenção do utilizador (zero-click)..** Zero-click descreve uma forma de explorar a falha, não a razão pela qual ela é devastadora.
*   **Explora problemas de calendário em anos bissextos..** Não existe qualquer relação com o conceito.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/principios-seguranca/#ativo-amea%C3%A7a-e-vulnerabilidade)

## Segurança de software

Overflow de inteiros no openSSH (nresp)

Teste Intercalar, 2021/22

Considere o seguinte código, que esteve na origem de uma vulnerabilidade de gravidade elevada no openSSH:

```c
nresp = packet_get_int();
if (nresp > 0) {
   response = xmalloc(nresp*sizeof(char*));
   for (i = 0; i < nresp; i++)
      response[i] = packet_get_string(NULL);
}
```

Explique de que forma um atacante que controla o valor de `nresp` pode provocar uma falha de gestão de memória na origem do problema.

Solução

Se `nresp` for suficientemente grande, o produto `nresp*sizeof(char*)` ultrapassa o valor máximo de um inteiro e volta a um valor pequeno. O `xmalloc` aloca então um bloco muito menor, mas o ciclo continua a escrever `nresp` apontadores, progresso o heap para lá do fim da zona alocada: heap buffer overflow.

A verificação `nresp > 0` não impede valores muito grandes. A multiplicação é feita em aritmética de inteiros e pode fazer wrap-around, pelo que a alocação fica inconsistente com o número de escritas efetuadas no ciclo.

Confere a tua resposta:

*   A resposta identifica que `nresp*sizeof(char*)` pode sofrer overflow de inteiro para um valor pequeno.
*   A resposta conclui que o `xmalloc` aloca um buffer inferior ao necessário e que o ciclo escreve `nresp` apontadores, causando heap buffer overflow.

Use after free e tomada de controlo

Teste Intercalar, 2021/22

Explique porque é que um erro de gestão de memória do tipo use after free pode expor uma vulnerabilidade que permite a um atacante concretizar uma tomada de controlo.

Solução

Num use after free, o programa continua a usar um apontador para memória já libertada. Essa memória pode ser realocada para outro objeto controlado pelo atacante; se aí ficar um apontador para função ou um vtable, o atacante pode fazer o programa saltar para código seu, conquistando a tomada de controlo.

A libertade não limpa o apontador antigo. Quando a zona é reutilizada, o objeto "fantasma" e o novo objeto partilham a mesma memória, e o atacante explora essa sobreposição para corromper dados sensíveis à execução.

Confere a tua resposta:

*   A resposta explica que, após libertada, a memória pode ser reutilizada por outro objeto, incluindo estruturas com apontadores de função.
*   A resposta conclui que o atacante pode controlar o conteúdo reutilizado e desviar o fluxo de execução, por exemplo sobrescrevendo um apontador para função.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/programacao-defensiva/#outros-erros-de-mem%C3%B3ria)

openSSH: overflow de inteiros seguido de heap overflow

Teste 1, 2023/24

Considere o código do openSSH em que um atacante controla a variável `nresp`:

```c
nresp = packet_get_int();
if (nresp > 0) {
   response = xmalloc(nresp*sizeof(char*));
   for (i = 0; i < nresp; i++)
      response[i] = packet_get_string(NULL);
}
```

O atacante pode provocar um problema de gestão de memória porque consegue despoletar:

Solução

Um overflow de inteiros e um subsequente heap buffer overflow.

Com `nresp` muito grande, `nresp*sizeof(char*)` excede a capacidade do inteiro e o resultado volta a um valor pequeno, pelo que o `xmalloc` aloca pouco espaço. O ciclo escreve depois `nresp` entradas nesse bloco pequeno da heap.

*   **Um overflow de inteiros e um subsequente stack buffer overflow..** A escrita ocorre na heap (zona alocada por xmalloc), não na stack.
*   **Um overflow de inteiros e um subsequente use after free..** O problema não é usar memória libertada, mas escrever para lá do fim da zona alocada.
*   **Um overflow de inteiros e um subsequente heap buffer overflow..** A multiplicação `nresp*sizeof(char*)` faz wrap-around, a alocação fica pequena e o ciclo escreve para lá do fim do bloco na heap.
*   **Um heap overflow e um subsequente integer buffer overflow..** A ordem está invertida: primeiro ocorre o overflow do inteiro, depois o heap overflow.

Função dos NOP (0x90) no shellcode

Teste 1, 2023/24

Num ataque de buffer overflow, parte do payload foi preenchida com 0x90, o código da instrução NOP. O seu objetivo é gastar ciclos de CPU enquanto:

Solução

Aumenta o contador de programa sem alterar memória ou registos.

Uma sequência de NOP (NOP sled) torna o ataque robusto: mesmo que o endereço de salto não aponte exatamente para o início do shellcode, a execução desliza pelos NOP até lá.

*   **Limpa o registo %ebp..** NOP não altera nenhum registo.
*   **Conta quantas vezes o NOP foi executado e guarda o valor num registo..** NOP não atualiza contadores nem registos.
*   **Aumenta o contador de programa sem alterar memória ou registos..** NOP (no operation) apenas avança o contador de programa, criando um colchão de instruções que conduz a execução até ao shellcode.
*   **Nenhuma das outras opções..** A terceira opção descreve corretamente o NOP.

Canário de stack e stack smashing

Teste 1, 2024/25

Um canário procura impedir a modificação da stack. É impossível fazer "smash the stack":

Solução

Se o valor do canário tiver mudado ao saltar para o endereço de retorno.

O canário é colocado entre as variáveis locais e o endereço de retorno. Um overflow que tente sobrescrever o endereço de retorno tem de passar pelo canário, alterando o seu valor; a verificação no regresso deteta a adulteração e aborta o programa.

*   **Sem adivinhar a posição do canário..** A posição do canário não é o segredo; o valor é que tem de permanecer intacto.
*   **Sem ler o valor do canário..** O ataque pode ler o valor; o que não pode é alterá-lo sem ser detetado.
*   **Se o valor do canário tiver mudado ao saltar para o endereço de retorno..** Antes de usar o endereço de retorno, o programa compara o canário com o valor original; se mudou, o programa termina em vez de seguir o endereço corrompido.
*   **Ao chamar a função seguinte..** A verificação ocorre no regresso da função, não na chamada seguinte.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/programacao-defensiva/#can%C3%A1rios-o-que-est%C3%A1-a-ser-verificado)

## Segurança de sistemas e controlo de acessos

Princípio do desenho aberto

Teste Intercalar, 2021/22

Dos princípios de segurança de sistemas (economia nos mecanismos, proteção por omissão, desenho aberto, defesa em profundidade, privilégio mínimo, separação de privilégios e mediação completa), enuncie o princípio do desenho aberto e apresente uma motivação para a sua utilização.

Solução

O princípio do desenho aberto (open design) diz que a segurança de um sistema não deve depender do segredo do seu desenho ou implementação, mas sim das chaves ou palavras-passe. A motivação é que os mecanismos ocultos acabam por ser descobertos e explorados. Um desenho público pode ser revisto por muitos especialistas, que encuentran e corrigem falhas antes dos atacantes.

A "segurança por obscuridade" falha porque não escala com o número de atacantes. Pelo contrário, mecanismos abertos beneficiam do escrutínio alargado da comunidade, como acontece com os protocolos e código aberto revistos publicamente.

Confere a tua resposta:

*   O enunciado indica que a segurança não deve depender do segredo do desenho ou da implementação.
*   A motivação liga-se a que o segredo acaba por ser descoberto e a que o escrutínio público permite encontrar e corrigir falhas.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/sistemas-seguros/#princ%C3%ADpios-de-constru%C3%A7%C3%A3o)

Effective user id e privilégio mínimo

Teste Intercalar, 2021/22

Apresente uma situação em que um processo altera o seu effective user id em tempo de execução de acordo com o princípio do privilégio mínimo.

Solução

Um programa setuid root que só precisa de ler um ficheiro protegido pode chamar `seteuid` para o utilizador normal logo após abrir o ficheiro, ou voltar a `seteuid(0)` apenas quando precisa de novo de privilégios. Assim, a maior parte do tempo o processo corre sem privilégios de root, minimizando o dano de uma eventual vulnerabilidade.

O privilégio mínimo manda que cada componente use apenas os privilégios estritamente necessários à tarefa em curso. Alterar o EUID em tempo de execução permite reduzir a janela em que o processo corre com privilégios elevados.

Confere a tua resposta:

*   A resposta apresenta um exemplo concreto (por exemplo um programa setuid que larga os privilégios de root depois de abrir o ficheiro necessário).
*   A justificação usa o princípio do privilégio mínimo: manter apenas os privilégios estritamente necessários em cada momento.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/controlo-acessos/#permiss%C3%B5es-unix)

UID de um processo lançado

Teste 1, 2023/24

Um detalhe importante das permissões de ficheiros UNIX é o User ID (UID) de um processo. Um processo é lançado com o UID:

Solução

Do dono do ficheiro, se o bit setuid estiver a 1 (nos restantes casos, do utilizador que lançou o processo).

O bit setuid faz com que o effective user id do processo seja o do proprietário do ficheiro executável em vez do utilizador que o invocou, permitindo programas como o `passwd` aceder a ficheiros restritos de forma controlada.

*   **Do utilizador que o lançou, a menos que o bit setuid esteja a 1..** Por omissão o UID é o do utilizador, mas com o bit setuid ativo o processo corre com o UID do dono do ficheiro.
*   **Do dono do ficheiro, a menos que o bit setuid esteja a 1..** Sem setuid, o processo fica com o UID de quem o lançou; com o bit setuid a 1, o EUID passa a ser o do dono do executável.
*   **Do dono do ficheiro, a menos que esse utilizador seja root..** O facto de o dono ser root não anula o efeito do bit setuid.
*   **Do utilizador root, se o bit setuid estiver a 1..** O setuid dá o UID do dono do ficheiro, que só é root se o ficheiro pertencer a root.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/controlo-acessos/#permiss%C3%B5es-unix)

setuid e seteuid: alteração permanente vs temporária

Teste 1, 2024/25

Os privilégios de um processo podem ser ajustados em tempo de execução por chamadas de sistema que manipulam o Effective User ID (EUID), o Saved User ID (SUID) e o Real User ID (RUID). Qual destas afirmações é verdadeira?

Solução

seteuid altera temporariamente os privilégios, modificando o EUID mas não o RUID nem o SUID.

setuid altera permanentemente os três identificadores quando invocado por root. seteuid altera apenas o EUID, permitindo que um processo setuid baixe e recupere privilégios conforme necessário, de acordo com o privilégio mínimo.

*   **seteuid altera permanentemente os privilégios, modificando EUID, RUID e SUID..** seteuid altera apenas o EUID e de forma temporária; o RUID e o SUID não são alterados.
*   **setuid altera temporariamente os privilégios, modificando EUID e SUID, mas não o RUID..** setuid (quando chamado por root) altera permanentemente EUID, RUID e SUID; não é temporário.
*   **setuid altera permanentemente os privilégios, modificando EUID e RUID mas não o SUID..** Quando chamado por root, setuid modifica os três identificadores.
*   **seteuid altera temporariamente os privilégios, modificando o EUID mas não o RUID nem o SUID..** seteuid muda apenas o EUID e pode voltar atrás usando o SUID, sendo a forma recomendada de alternar privilégios temporariamente.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/controlo-acessos/#permiss%C3%B5es-unix)

## Segurança Web

Gestão de sessões mais segura

Teste 1, 2023/24

Qual é a forma mais segura de gestão de sessões em aplicações web?

Solução

O servidor guarda todo o estado do cliente, associado a um token aleatório em cada cookie de sessão.

Se o estado fica no servidor e o cookie carrega apenas um token aleatório imprevisível, o cliente não pode manipular os seus próprios privilégios; a revogação no servidor também é imediata.

*   **O servidor guarda todo o estado do cliente, associado a um token aleatório em cada cookie de sessão..** Com o estado no servidor e apenas um identificador aleatório no cliente, o atacante não consegue forjar ou alterar o estado da sessão.
*   **O servidor gere todo o estado do cliente, guardado num cookie de sessão cifrado e assinado com MAC..** Guardar estado no cookie (stateful client-side) expõe os dados ao cliente e aumenta a superfície de ataque.
*   **O cliente gere todo o seu estado no seu cookie de sessão, que é guardado pelo servidor..** Esta descrição é inconsistente e coloca dados controláveis pelo cliente no fluxo de autenticação.
*   **O servidor guarda todo o estado do cliente, associado ao mesmo identificador para todos os cookies de um cliente..** Reutilizar o mesmo identificador para vários cookies permite ataques de fixation e rastreio entre sessões.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/seguranca-web/#sess%C3%B5es-e-cookies)

CSRF e cabeçalhos Fetch Metadata

Teste 1, 2023/24

Cross-Site Request Forgery (CSRF) é um ataque clássico à web que muitas propostas procuram mitigar. Qual destas afirmações é verdadeira?

Solução

Os cabeçalhos Fetch Metadata permitem ao servidor web decidir que pedidos de clientes aceitar com base na origem.

Numa CSRF, o navegador do utilizador autenticado envia o pedido forjado com os cookies válidos. Os Fetch Metadata (`Sec-Fetch-Site`, `Sec-Fetch-Mode`, etc.) informam o servidor de que o pedido é cross-site, permitindo rejeitá-lo.

*   **Os tokens CSRF permitem ao servidor web receber uma lista branca de origens confiáveis..** Os tokens CSRF provam que o pedido veio de uma página legítima do próprio site, não uma lista de origens.
*   **Os cabeçalhos Fetch Metadata permitem ao servidor web receber uma lista branca de origens confiáveis..** Os Fetch Metadata não são uma lista branca; são cabeçalhos que descrevem a origem e o contexto do pedido.
*   **Os cabeçalhos Fetch Metadata permitem ao servidor web decidir que pedidos de clientes aceitar com base na origem..** O servidor pode inspecionar `Sec-Fetch-Site` e rejeitar pedidos cross-site não legítimos, mitigando CSRF sem tokens adicionais.
*   **Os cookies SameSite=Strict permitem ao servidor web decidir que pedidos de clientes aceitar com base na origem..** SameSite é uma política do navegador sobre o envio do cookie, não uma decisão do servidor.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/seguranca-web/#csrf)

Deteção de sessão com imagem: XS-Leaks

Teste 1, 2024/25

Uma página maliciosa contém o seguinte código. Se o utilizador estiver autenticado, o URL redireciona para a imagem do logótipo do Medium; caso contrário, redireciona para a página de login do Medium, que não é uma imagem e provoca um erro. Este ataque pode ser catalogado como:

```html
<img src="https://medium.com/m/login-redirect?redirectUrl=https%3A%2F%2Fmedium.com%2Ffavicon.ico"
  onerror="alert('Not logged in')" onload="alert('logged in')">
```

Solução

Cross-Site Leaks (XS-Leaks).

O evento `onload`/`onerror` da imagem funciona como um oráculo: o atacante não vê a resposta, mas consegue distinguir o estado de autenticação da vítima através do recurso que carregou com sucesso, fugando informação entre sites.

*   **Cross-Frame Scripting (XFS)..** XFS envolve frames, não a fuga de informação de estado de sessão.
*   **Cross-Site Request Forgery (CSRF)..** CSRF força o utilizador a executar uma ação; aqui o atacante apenas lê informação de estado.
*   **Cross-Site Leaks (XS-Leaks)..** O atacante usa o sucesso ou insucesso do carregamento de um recurso cross-site (onload/onerror) para inferir se o utilizador está autenticado.
*   **Cross-Site Scripting (XSS)..** Não há injeção de script na página da vítima; o script corre na página do atacante.

[Voltar à explicação](https://resumos.rgo.pt/cadeiras/fsi/seguranca-web/#observa%C3%A7%C3%A3o-e-falsifica%C3%A7%C3%A3o)