RFC 3261 SIP: Session Initiation Protocol Junho 2002
O campo-cabeçalho From de uma requisição do SIP, contudo, pode ser modificado arbitrariamente pelo dono de um UA, e isso abre as portas para registros maliciosos. Um atacante que, com sucesso, se faz passar por uma parte autorizada a mudar contatos associados a um endereço-de-registro poderia, por exemplo, desregistrar todos os contatos existentes para um URI e então registrar seu próprio dispositivo como o endereço de contato apropriado, e assim, direcionar todas as requisições do usuário afetado para o dispositivo do atacante.
Essa ameaça pertence a uma família de ameaças que depende da ausência de garantia criptográfica do originador de uma requisição. Qualquer UAS do SIP que representa um serviço importante (um gateway que interopera requisições SIP com chamadas telefônicas tradicionais, por exemplo) pode querer controlar acesso aos seus recursos ao autenticar requisições que ele recebe. Mesmo os UA's finais, por exemplo, telefones SIP, têm interesses em certificar as identidades dos originadores de requisições.
Essa ameaça demonstra a necessidade por serviços de segurança que permite a entidades SIP autenticar os originadores de requisições.
26.1.2 Passando-se por um Servidor
O domínio ao qual uma requisição é destinada é geralmente especificado no Request-URI. UA's comumente contatam um servidor nesse domínio diretamente a fim de entregar uma requisição. Entretanto, há sempre uma possibilidade de que um atacante possa se passar pelo servidor remoto, e que a requisição do UA possa ser interceptada por algum outra parte.
Por exemplo, considere um caso em que um servidor redirect em um domínio, chicago.com, faz-se passar por um servidor redirect em outro domínio, biloxi.com. Um agente-usuário envia uma requisição para biloxi.com, mas o servidor redirect em chicago.com responde com uma resposta forjada que tem campos-cabeçalhos do SIP apropriados para uma resposta de biloxi.com. Os endereços de contato forjados na resposta de redirecionamento poderia direcionar o UA originador para recursos inadequados ou inseguros, ou simplesmente evitar requisições para biloxi.com de serem bem sucedidas.
Essa família de ameaças tem uma vasta associação, muitos dos quais são críticos. Como uma conversa à ameaça de seqüestro de registro, considere o caso em que um registro enviado ao biloxi.com é interceptado por chicago.com, que responde ao registo interceptado com uma resposta forjada 301 (Moved Permanently). Essa resposta pode parecer vir de biloxi.com ainda designa chicago.com como o registrador apropriado. Todas as requisições REGISTER futuras do UA originador, então, seguem para chicago.com.
A previnição dessa ameaça exige uma forma pela qual UA's possam se autenticar nos servidores para quem eles enviam requisições.
Rosenberg, et. al. Standards Track [Página 234]
Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:
User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.
Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:
MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO,
NECESSITAR, É MANDATÓRIO.
MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.
SHOULD:
DEVE, É RECOMENDADO.
SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.
MAY:
PODE, É OPCIONAL.
Nenhum comentário:
Postar um comentário