Monografia SIP

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA
FACULDADE DE CINCIAS APLICADAS DE MINAS

Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000
BACHARELADO EM SISTEMAS DE INFORMAO

ANLISE DAS VULNERABILIDADES E ATAQUES AO
PROTOCOLO SIP

ANDERSON RODRIGUES SOUZA REZENDE

UBERLNDIA - MG
2006


PROTOCOLO SIP

Trabalho de Final de curso submetido
UNIMINAS como parte dos requisitos para
a obteno do grau de Bacharel em
Sistemas de Informao.

Orientador: Prof. Esp Flamaryon Guerin
Gomes Borges

UBERLNDIA - MG
2006


PROTOCOLO SIP

Trabalho de Final de curso submetido
UNIMINAS como parte dos requisitos para
a obteno do grau de Bacharel em
Sistemas de Informao.

Orientador: Prof. Esp Flamaryon Guerin
Gomes Borges

Banca Examinadora: sobre
Uberlndia, 16 de setembro de 2006.
Prof. Esp Flamaryon Guerin Gomes Borges (Orientador)

Prof. Esp. Carlos Henrique Barros

Prof. Dr. Mauro Hemerly Gazzani

UBERLNDIA - MG
2006

Pela emoo de me vem crescer, por acreditarem em mim, pelo grande amor que
me destinam, por sempre ensinarem aos seus filhos a verdadeira importncia da
honestidade e da tica. para meus pais, Paulo e Maria, que dedico este
trabalho, queles de especial significado pra mim, aos quais devo toda formao
que tenho e todo futuro que me fora entregue.

AGRADECIMENTOS
Ao professor e orientador Flamaryon Guerin Gomes Borges, que com
seu apoio e conhecimento, tornou possvel a elaborao deste trabalho. Muito
obrigado por confiar mim este tema.

professora Ktia Lopes Silva, por sua dedicao constante,
buscando sempre extrair todo nosso potencial. Com sua inteligncia e carisma
inigualveis, esteve sempre ao lado do aluno, ajudando em nossas dificuldades, e
partilhando das nossas superaes.

Aos grandes amigos, Arnaldo e Fernando, companheiros de estrada,
pessoas que aprendi a respeitar e confiar. queles que considero como irmos,
sempre presentes em minha vida acadmica, tanto nos momentos felizes, quanto
nas dificuldades. E juntos conquistamos mais uma etapa importante em nossas
vidas. Agradeo a vocs pela grande amizade, amizade esta, que prezo para que
seja por minha parte, retribuda altura.

A namorada Lvia, uma pessoa muito importante e especial em minha
vida. Uma mulher que maravilhosa acima de tudo. Que pode com um sorriso
provocar amor e felicidade. Uma pessoa que me encantou, e me encanta em todos
os seus gestos, e que compartilha comigo grandes realizaes. Meu grande amor.

Instituio UNIMINAS, e seus docentes, por sua excelente estrutura,
onde fora possvel a conquista desta vitria.

RESUMO

No cenrio atual, no h como ficar indiferente ao assunto de VoIP.
Discusses em torno do trfego de voz sobre o protocolo da Internet no do sinais
de cessar, por isso companhias apostam nesta tendncia, que segundo pesquisas,
promete confirmar-se numa grande exploso de consumo. Nesta evoluo das
comunicaes, destaca-se o protocolo SIP (Session Initiation Protocol), um
protocolo capaz de iniciar, alterar e finalizar sesses multimdia, garantindo a
convergncia em definitivo, da telefonia tradicional para telefonia IP. Porm apesar
das grandes vantagens trazidas pela convergncia, esta trouxe tambm uma nova
preocupao: a segurana das informaes, requisito que pode confirmar a
maturidade da tecnologia. Implementaes do protocolo SIP, so vulnerveis a
ataques comuns baseados em redes IP, bem como a ataques que so nicos ao
SIP. Este fato coloca em risco as Informaes das empresas que utilizam sistemas
de telefonia IP. Ataques que fazem uso das vulnerabilidades do protocolo SIP,
podem resultar na interrupo de aplicaes fundamentais ao negcio de
corporaes sustentadas em uma rede VoIP. Tal fato, dentro do contexto de
concorrncia global, tornar uma grande economia em srios prejuzos. A proposta
da pesquisa demonstrar as vulnerabilidades e os possveis ataques que fazem
uso das brechas em implementaes do Session Initiation Protocol, criando um
documento com tais informaes destinado a interessados e envolvidos com
sistemas de comunicao baseados no protocolo SIP.
Palavras-chave: SIP, vulnerabilidades, ataques, VoIP.

ABSTRACT
In the current scene, it does not have as to be indifferent to the subject
of VoIP. Quarrels around the traffic of voice on the protocol of the Internet do not
give signals to cease, therefore company bets in this trend, that according to
research, promises to confirm in a great consumption explosion. In this evolution of
the communications, protocol SIP (Session Initiation Protocol) is distinguished, a
protocol capable to initiate, to modify and to finish sessions multimedia, promising
the convergence in definitive, of the traditional telephony for telephony IP. However
although the great advantages brought for the convergence, this also brought a new
concern: the security of the information, requirement that can confirm the maturity of
the technology. Implementations of protocol SIP, are vulnerable the based common
attacks in nets IP, as well as the attacks that are only to the SIP. This fact at risk
places the Information of the companies who use systems of telephony IP. Attacks
that make use of the vulnerabilities of protocol SIP, can result in the interruption of
basic applications to the business of corporations supported in a VoIP net. Such
fact, inside of the context of global competition, will become a great economy in
serious damages. The proposal of the research is to demonstrate to the
vulnerabilities and the possible attacks that make use of the breaches in
implementations of the Session Initiation Protocol, creating a document with such
information destined the involved interested parties and with based systems of
communication in protocol SIP.
Key-words: SIP, vulnerabilities, attacks, VoIP.

LISTA DE FIGURAS
FIGURA 1 - ARQUITETURA CLIENTE/SERVIDOR...................................................................... 21
FIGURA 2 - ARQUITETURA DE PROTOCOLOS MULTIMDIA INTERNET................................ 22
FIGURA 3 - ARQUITETURA SIP ................................................................................................... 23
FIGURA 4 - EXEMPLOS DE UAS................................................................................................ 24
FIGURA 5 - FUNCIONAMENTO DO REDIRECT SERVER........................................................... 26
FIGURA 6 - REGISTRO DA LOCALIZAO EM UM REGISTRAR SERVER............................. 27
FIGURA 7 - GATEWAY SIP/PSTN E GATEWAY SIP/H323......................................................... 28
FIGURA 8 - ESTABELECIMENTO DE UMA SESSO SIP SIMPLES ......................................... 29
FIGURA 9 - CAMPOS DA MENSAGEM INVITE ........................................................................... 29
FIGURA 10 - CLCULO DO CAMPO CONTENT-LENGTH ........................................................... 31
FIGURA 11 - DESCRIO DOS CAMPOS SDP............................................................................. 32
FIGURA 12 - MTODOS DE REQUISIES SIP ........................................................................... 32
FIGURA 13 - MTODOS DE REQUISIES ESTENDIDAS DO SIP ............................................ 33
FIGURA 14 - CLASSES DE RESPOSTA SIP.................................................................................. 33
FIGURA 15 - ESTRUTURA DA MENSAGEM 180 RINGING.......................................................... 34
FIGURA 16 - ESTRUTURA DA MENSAGEM 200 OK .................................................................... 35
FIGURA 17 - ESTRUTURA DO ACK............................................................................................... 36
FIGURA 18 - ESTRUTURA DO BYE ............................................................................................... 37
FIGURA 19 - 200 OK CONFIRMAO DO BYE............................................................................. 37
FIGURA 20 - CHAMADA SIP COM PROXY SERVER.................................................................... 38
FIGURA 21 - INVITE REPASSADO AO PROXY............................................................................. 39
FIGURA 22 - INVITE REPASSADO PELO PROXY AO DESTINO................................................. 40
FIGURA 23 - MENSAGEM 180 RINGING ENVIADA AO PROXY .................................................. 40
FIGURA 24 - MENSAGEM DE RESPOSTA ENVIADA DO PROXY AO ORIGINADOR................ 41
FIGURA 25 - CONFIRMAO 200 OK REPASSADA DO PROXY AO ORIGINADOR................. 41
FIGURA 26 - REGISTER ENVIADO DIRETAMENTE PARA O SERVIDOR DE REGISTRO ........ 43
FIGURA 27 - REGISTRO DE UM AGENTE EM UM SERVIDOR DE REGISTRO VIA PROXY..... 43

FIGURA 28 - MENSAGEM INVITE ENVIADA PARA O REDIRECT SERVER............................... 44
FIGURA 29 - REPOSTA ENVIADA PELO REDIRECT SERVER ................................................... 45
FIGURA 30 - REDIRECIONAMENTO VIA SERVIDOR PROXY ..................................................... 46
FIGURA 31 - SIP X 323 .................................................................................................................... 48
FIGURA 32 - SINALIZAES SIP X H323...................................................................................... 48
FIGURA 33 - DIFERENAS NO STREAMMING SIP X H323......................................................... 49
FIGURA 34 - SIP INVITE PASSVEL DE SNIFFING E SPOOFFING ............................................. 51
FIGURA 35 - MENSAGEM DE REGISTRO VLIDA....................................................................... 56
FIGURA 36 - VERSO MODIFICADA DO REGISTRO................................................................... 57
FIGURA 37 - SPOOFING DO REGISTRO UTILIZANDO O SIVUS ................................................ 58
FIGURA 38 - ATAQUE DE REGISTRATION HIJACKING.............................................................. 59
FIGURA 39 - ATAQUE DE PROXY IMPERSONATION.................................................................. 61
FIGURA 40 - PASSOS PARA CAPTURAR A MDIA VOIP COM O ETHEREAL........................... 62
FIGURA 41 - ATAQUE DE ARP SPOOFING .................................................................................. 63
FIGURA 42 - A FERRAMENTA CAIN REALIZANDO O ATAQUE DE HOMEM-DO-MEIO........... 64
FIGURA 43 - ATAQUE DE MESSAGE TAMPERING ..................................................................... 64
FIGURA 44 - ATAQUE DE SESSION TEAR DOWN....................................................................... 65
FIGURA 45 - REMOO DO REGISTRO DO USURIO PELO ATACANTE ............................... 67
FIGURA 46 - FLUXO DO ATAQUE DE RE-INVITE......................................................................... 68
FIGURA 47 - ATAQUE DE BYE....................................................................................................... 69
FIGURA 48 - FLUXO DO ATAQUE DE UPDADE........................................................................... 70
FIGURA 49 - MENSAGEM SIP INVITE BEM FORMADA ............................................................... 72
FIGURA 50 - MENSAGEM SIP INVITE MAL FORMADA ............................................................... 73
FIGURA 51 - DESCOBRINDO AS CAPACIDADES COM A REQUISIO OPTIONS ................. 75
FIGURA 52 - FLUXO NORMAL DE REGISTRO ............................................................................. 76
FIGURA 53 - ATAQUE CONTRA UM REGISTRAR SERVER........................................................ 77
FIGURA 54 - ATAQUE DE CANCEL ............................................................................................... 78
FIGURA 55 - CDIGOS DE ERROS COMUNS .............................................................................. 79
FIGURA 56 - FLOODING DE INVITE............................................................................................... 82
FIGURA 57 - PRINCIPAIS MECANISMOS DE SEGURANA PARA O SIP.................................. 84

FIGURA 58 - CONFIRMAO DO INVITE PELO PROXY ............................................................. 85
FIGURA 59 - INVITE ORIGINAL COM A CONFIRMAO............................................................. 85
FIGURA 60 - TIPOS DE CONTEDO S/MIME................................................................................ 86
FIGURA 61 - NEGOCIAO COM SERVIDOR TLS ...................................................................... 88
FIGURA 62 - SOLUO PARA SEGURANA REAL-TIME MEDIA STREAMS........................... 90

LISTA DE ABREVIATURAS E SMBOLOS

ACK - Acknowledgment
AES - Advanced Encryption Standard
AH - Authentication Header
AOR - address of record
ARP - Address Resolution Protocol
ASCII - American Standard Code for Information Interchange
CCP - Connection Control Protocol
CR - Carrier Return
DDoS - Distributed Denial of Service
DES - Data Encryption Standard
DHCP - Dynamic Host Configuration Protocol
DNS - Domain Name Service
DoS - Denial of Service
ESP - Encapsulating Security Payload
FTP - File Transfer Protocol
HTML - Hyper Text Transfer Protocol
HTTP - Hyper Text Transfer Protocol
IETF - Internet Engineering Task Force
IKE - Hyper Text Markup Language
IP - Internet Protocol
IPSEC - Internet Protocol Security

IVS - INRIA Videoconferencing System
LF - Line Feed
MD5 - Message Digest Algoritm
MIME - Multi-purpose Internet Mail Extension
MITL - man-in-the-middle
MMCC - Multimdia Conference Control
NGN - Next Generations Network
OSI - Open System Interconnection
PC - Pesonal Computer
PCM - Pulse-code modulation
PDA - Personal Digital Assistant
PGP - Pretty Good Privacy
PKI - Public key infraestructure
PSK - Pre-shared keys
PSTN - Public Switched Telephone Network
QoS - Quality of Service
RAS - Registration Admission Status
RFC - Request For Comments
RTCP - Real-Time Control Protocol
RTP - Real Time Protocol
S/MIME - Security/Multi-purpose Internet Mail Extension
SCIP - Simple Conference Invitation Protocol
SDP - Session Description Protocol
SHA - Secure Hash Algorithm

SIP - Session Initiation Protocol
SMTP - Send Mail Transfer Protocol
SPIT - Spam over Internet Telephony
SRTP - Secure Real Time Protocol
SYN - Synchronous
TCP - Transmission Control Protocol
TCP/IP - Transmission Control Protocol/Internet Protocol
TLS - Transport Layer Security
UA - User Agent
UAC - User Agent Client
UAS - User Agent Server
UDP - User Datagram Protocol
URL - Uniform Resource Locators
VoIP - Voice over Internet Protocol

SUMRIO
1 INTRODUO......................................................................................................15
1.1 CENRIO ATUAL ............................................................................................15
1.2 OBJETIVOS ...................................................................................................17
1.3 IDENTIFICAO DO PROBLEMA ........................................................................17
1.4 JUSTIFICATIVA...............................................................................................18
1.5 ORGANIZAO DO TRABALHO .........................................................................18
2 FUNDAMENTOS DO PROTOCOLO SIP .............................................................19
2.1 SURGIMENTO DO SIP.....................................................................................19
2.2 INTRODUO.................................................................................................20
2.3 COMPONENTES DO SIP..................................................................................23
2.4 SINALIZAO SIP..........................................................................................28
2.5 SINALIZAO SIP COM SERVIDOR PROXY........................................................37
2.6 REGISTRO SIP..............................................................................................42
2.7 REDIRECIONAMENTO......................................................................................44
2.8 SIP X H.323.................................................................................................47
2.8.1 Diferenas na Sinalizao.......................................................................48
2.8.2 Diferenas no Streaming.........................................................................49
3 VULNERABILIDADES DOS SISTEMAS VOIP BASEADOS EM SIP..................50
3.1 INTRODUO.................................................................................................50
3.2 AMEAAS E ATAQUES AO SIP.........................................................................55
3.2.1 Registration Hijacking..............................................................................55
3.2.2 Proxy Impersonation................................................................................60
3.2.3 Eavesdropping (Espionando) ..................................................................62
3.2.4 Message Tampering................................................................................64
3.2.5 Session Tear Down .................................................................................65
3.2.6 Denial of Service .....................................................................................66
3.3 ATAQUES UTILIZANDO DE MENSAGENS SIP......................................................66
3.3.1 Ataques a sistemas sem a autenticao aplicada...................................66
3.3.1.1 Ataque de DoS utilizando mensagens de REGISTER SIP ..............66
3.3.1.2 Ataque de Re-INVITE ....................................................................67
3.3.1.3 Ataque de BYE ..............................................................................68
3.3.1.4 Ataque de UPDATE .......................................................................69
3.3.2 Ataques a sistemas com a autenticao aplicada (antes da autenticao)
70
3.3.2.1 Ataques de Parser .........................................................................71
3.3.2.2 Ataques de REGISTER .................................................................75
3.3.2.3 Ataques de CANCEL .....................................................................77
3.3.2.4 Fraudes em Respostas SIP..............................................................78
3.3.3 Ataques a sistemas com a autenticao aplicada (aps a autenticao)79
3.3.3.1 Ataque de Fora Bruta .....................................................................80
3.3.3.2 Unusable Destinations (Destinos Inteis).........................................81
3.3.3.3 Ataques de INVITE ........................................................................81
4 MECANISMOS DE SEGURANA........................................................................83

4.1 HTTP BASIC AUTHENTICATION.......................................................................83
4.2 HTTP DIGEST AUTHENTICATION.....................................................................84
4.3 PRETTY GOOD PRIVACY (PGP)......................................................................86
4.4 SECURE MIME (S/MIME)..............................................................................86
4.5 SIPS URI (TLS) ...........................................................................................88
4.6 IP SECURITY (IPSEC).....................................................................................89
4.7 SEGURANA SOBRE PROTOCOLOS DE TRANSPORTE EM TEMPO REAL .................89
4.7.1 Secure RTP (SRTP) ................................................................................90
4.7.2 IP Security (IPsec)...................................................................................90
5 CONCLUSES.....................................................................................................91
5.1 CONSIDERAES FINAIS ................................................................................91
5.2 PROPOSTAS PARA TRABALHOS FUTUROS ........................................................92
6 REFRNCIAS BIBLIOGRFICAS .......................................................................94

15
1 INTRODUO
1.1 Cenrio Atual
O envio de sinais de voz em pacotes digitais, conhecido como VoIP
(Voice over IP Voz sobre Protocolo de Internet), manifesta diversas vantagens em
relao as redes telefnicas tradicionais. Muitas dessas vantagens deve-se ao fato
de consolidar a transmisso de voz e dados sobre uma mesma infra-estrutura, e de
distribuir a inteligncia do sistema entre diversos elementos, deixando de concentr-
la apenas nas centrais telefnicas. Como resultado, tem-se no s a reduo
drstica dos custos como tambm a possibilidade de criao de sistemas globais de
comunicao. Com o amadurecimento da Internet e de seus protocolos de
comunicao, a convergncia de mltiplas mdias como voz, vdeo, dados e
servios como chat, Instant Messages, e Web, deixou de ser apenas uma
curiosidade, para tornar-se uma grande oportunidade. Neste contexto que surge a
telefonia IP (Internet Protocol). Telefonia IP uma modalidade de VoIP onde o
servio fornecido apresenta qualidade e funcionalidades no mnimo equivalentes
aos servios telefnicos convencionais. O usurio utiliza um telefone IP que um
telefone mais inteligente, ou um adaptador IP para um telefone convencional e uma
conexo IP de banda larga para conectar-se a rede de telefonia IP. Adicionalmente
pode-se acessar o servio utilizando um computador com um programa especial
para esse fim. Nesta evoluo das comunicaes, destaca-se o SIP (Session
Initiation Protocol Protocolo de iniciao de sesso), um protocolo desenvolvido
pelo IETF (Internet Engineering Task Force), que atua no nvel de aplicao, capaz
de estabelecer, gerenciar e terminar chamadas entre dois ou mais pontos de
comunicao. O SIP caracterizado por sua estrutura simples, fazendo uso dos
servios de outros protocolos para implementar sua arquitetura multimdia e desse
modo deve ser o protocolo padro nas comunicaes mundiais. o SIP visa trazer
algo semelhante ao que o IP trouxe para Internet no mundo, prometendo a
convergncia em definitivo, da telefonia tradicional para telefonia IP. Segundo
Lazarini (2006), a Telefonia IP associada a outras aplicaes como colaborao,
presena, e-mail, voice mail, fax, e outras limitadas somente pela nossa capacidade

16
de criao, sero a base da comunicao do futuro e mudar a maneira como
fazemos negcios.
Existem, porm, aspectos importantes a serem revistos nas
implementaes SIP, a mais crtica refere-se a segurana. De acordo com Collier
(2005), o sistema SIP vulnervel aos ataques comuns baseados em redes IP,
bem como a ataques que so nicos ao SIP. A disponibilidade do servio de VoIP
est ligada diretamente a disponibilidade da infra-estrutura IP, qualquer tipo de
ataque, pode acarretar um srio impacto nas comunicaes. Por ser um protocolo
baseado nos protocolos da pilha TCP/IP (Transmission Control Protocol/ Internet
Protocol), o SIP herdou destes suas to exploradas vulnerabilidades.
Hoje em dia o requisito mais importante para a VoIP a segurana, e
isso pode construir-se com componentes fiveis e bom planeamento
durante a colocao. As telecomunicaes sempre tiveram requisitos
altos de fiabilidade, mas devido s redes de telecomunicaes terem
estado sempre fechadas, a segurana nunca foi um requisito. As
coisas so diferentes para o VoIP. A preveno da fraude um dos
tpicos principais quando se coloca a VoIP.
A conectividade aberta tambm frequentemente exigida, e isso cria
um recreio para os hackers, expondo a rede de telecomunicaes a
ataques como vermes e vrus. A colocao inteligente requer um
conhecimento das ameaas, vulnerabilidades e ataques. O
desenvolvimento de produtos e sistemas de VoIP seguros possvel
com testes robustez, concentrando-se na eliminao das
vulnerabilidades em cada parte do conjunto. Conhecendo os
requisitos, e minimizando os riscos, permite-lhe construir um sistema
de VoIP seguro, fivel e robusto. (TAKANEN,2006, traduo nossa).
VoIP um assunto de grande importncia na evoluo dos servios de
telecomunicaes; necessrio rever algumas questes fundamentais como a
segurana das comunicaes e a harmonizao sobre a regulamentao aplicada;
o Session Initiation Protocol a base para o seu desenvolvimento e disseminao
no mercado. Sendo assim, a segurana em sistemas baseados no protocolo SIP,
torna-se um ponto importante a ser pesquisado, j que o mesmo promete ser o
protocolo universal que integrar a rede de voz e dados definitivamente.
[...]Ao fazer ligaes telefnicas pela internet, as empresas esto
economizando milhes. Mas esto expondo seus sistemas de voz a
todas as pragas que hoje atacam as redes de dados, como worms,
vrus, spam sobre telefonia internet (SPIT), ataques DoS e fraudes.
Alm disso, abrem mais portas para que outras reas da rede
tambm sejam atacadas, afetando a infra-estrutura das empresas e

17
seus sistemas.[...] (CIO REVISTA, 2004).
[...] Na sua forma bsica, o SIP trafega em texto puro, significando
que ele vulnervel aos softwares espies. Segundo os
especialistas fcil interceptar as chamadas VoIP no criptografadas
usando um iPod.[...](CIO REVISTA, 2004).
1.2 Objetivos
Este trabalho tem por objetivo demonstrar o funcionamento do
protocolo SIP, expondo suas vulnerabilidades e evidenciando ataques sua
arquitetura, bem como alguns mtodos de defesa tais ofensivas maliciosas. Com
isto, pretende-se fornecer subsdios de informaes referentes segurana no uso
de sistemas de comunicao baseados no protocolo SIP, oferecendo condies aos
ingressantes, de evoluir nesta rea. No foco deste trabalho, aprofundar em
mtodos de defesa, nem em outros protocolos de sinalizao, tais como o H323.
Deve-se notar que o mesmo no trata de QoS Quality of Service (Qualidade de
Servio) VoIP.
1.3 Identificao do problema
Devido ao grande interesse na reduo de gastos, convergncia e na
criao de novos servios de comunicao, a padronizao de um protocolo capaz
de gerir uma sesso multimdia torna-se inevitvel. O fato de ser um protocolo de
arquitetura simples e aberta faz do SIP um protocolo com grandes possibilidades de
se tornar o padro das comunicaes sobre as redes IP.
[...] Desenvolvedores de produtos VoIP, grandes e pequenos, esto
adotando o SIP. A Microsoft introduziu o protocolo SIP em seu
sistema operacional Windows XP, e baseou seu programa de
mensagens instantneas neste protocolo. A IBM reconheceu o SIP
como o futuro para todos os produtos de comunicao que utilizam
voz e vdeo[...]. (CHECK POINT SOFTWARE TECNOLOGIES LTD,
CA, 2004, p. 4, traduo nossa).

18
Contudo Implementaes do SIP, sem as devidas preocupaes com
a segurana podem acarretar em srios prejuzos ao negcio. Documentar e tornar
pblica as vulnerabilidades do SIP facilita a correo de problemas, servindo como
apoio tanto profissionais experientes em segurana da informao, quanto
interessados em ingressar na nova tendncia da comunicao multimdia sobre
redes IP.
1.4 Justificativa
A justificativa para elaborao de um documento de referncia sobre
as vulnerabilidades do protocolo SIP, explica-se pelo fato de ser um assunto pouco
divulgado. Sabe-se da grande capacidade do SIP nas comunicaes globais, porm
suas falhas ainda so pouco conhecidas. O trabalho torna-se interessante medida
que detalha os ataques que exploram as vulnerabilidades deste protocolo,
demonstrando como tais falhas podem abrir portas permitindo que pessoas mal
intencionadas estejam aptas a explor-las, e como conseqncia, gerar prejuzos
ao sistema de comunicao.
1.5 Organizao do trabalho
No Captulo 2, ser apresentado o protocolo SIP, enfatizando alm da
sua arquitetura, componentes e estrutura, o seu funcionamento. Este captulo ainda
apresenta uma breve comparao do SIP com o H323, outro protocolo de
sinalizao, que est sendo substitudo pelo Session Initiation Protocol. O Captulo
3 trata das vulnerabilidades do sistema de comunicao que fazem uso do SIP,
enfatizando os ataques e suas conseqncias. No Captulo 4, sero analisadas
algumas medidas de proteo, contudo, sem aprofundar nestas solues, apenas
expondo alguns procedimentos mais utilizados. E finalmente, o Capitulo 5, relatando
tanto as concluses obtidas pela pesquisa, quanto as dificuldades e limitaes no
estudo do tema.

19
2 FUNDAMENTOS DO PROTOCOLO SIP
2.1 Surgimento do SIP
Segundo, Camarillo (2001), embora a primeira transmisso de voz
sobre redes comutadoras de pacotes datam por volta de 1974, O primeiro sistema
de conferncia multimdia surgiu no inicio de 1990 desenvolvido por Terry Turletti.
Nomeado de INRIA Videoconferencing System (IVS). Tratava-se de um sistema de
transmisso de udio e vdeo sobre a Internet. Mais tarde, Eve Schooler
desenvolveu o Multimdia Conference Control (MMCC), um software capaz de
prover teleconferncias ponto-a-ponto e multiponto, com udio e vdeo. Para
conectar vrios usurios, o MMCC fazia uso do Connection Control Protocol (CCP),
um protocolo de controle orientado a transao. Uma transao consiste em um
podido de um usurio, e a resposta de outro usurio remoto. Para o transporte dos
pacotes o CCP utilizava o protocolo User Datagram Protocol (UDP), implementando
o time-out, e a retransmisso para garantia da entrega dos pacotes. Estes dois
primeiros sistemas de conferncia multimdia abriram caminho para o
desenvolvimento do Session Initiation Protocol (SIP). A primeira verso do SIP, o
SIPv1, criada por Mark Handley e Eve Schooler, foi avaliada pelo IETF, como um
modelo para Internet em vinte e dois de fevereiro de 1996. O SIPv1 era um
protocolo baseado em texto, e fazia uso do Session Description Protocol (SDP) para
descrever as sesses multimdia, e do UDP, para o transporte dos pacotes. O
SIPv1 apresentou o conceito de registro de endereo em servidores de conferncia
multimdia, promovendo certo nvel de mobilidade ao usurio, pois uma vez que
este registre sua localizao, um servidor de endereos capaz de enderear
convites ao prprio usurio. Sendo assim, se um usurio estivesse distante de sua
estao de trabalho, poderia escolher registrar-se em uma estao de trabalho
temporria e continuar recebendo convites multimdia. Neste primeiro momento, o
SIPv1 controlava apenas o estabelecimento e a finalizao da sesso. Tambm em
vinte e dois de fevereiro de 1996, Henning Schulzrinne, submeteu ao IETF um
modelo de protocolo para Internet, capaz de convidar usurios para conferncias
ponto-a-ponto ou multicast chamado de Simple Conference Invitation Protocol

20
(SCIP). Este protocolo era baseado no HTTP, e utilizava o Transmission Control
Protocol (TCP) para transporte dos pacotes. O SCIP fazia uso de endereos de e-
mail para identificar os usurios, e era capaz de alterar parmetros da sesso aps
seu estabelecimento. Ento no 35th IETF meeting, foram apresentados os
protocolos SIP e o SCIP. E durante este encontro, e se estendendo ao seguinte o
36th IETF meeting, Schooler e Schulzrinne decidiram ento unir as funcionalidades
dos dois protocolos, mantendo o nome SIP criando ento o SIPv2. Em dezembro de
1996, surgiu o novo SIP, baseado em HTTP, fazendo uso tanto do TCP, quanto
do UDP para transporte dos pacotes. A partir deste momento o SIP, adquiriu sua
verdadeira importncia pelo IETF, que despende esforos para o desenvolvimento
da maturidade deste protocolo que gradativamente esta se tornando o padro para
o estabelecimento, modificao e finalizao de sesses multimdia.
2.2 Introduo
Segundo as especificaes contidas no Request For Comment 3261
(RFC 3261), algumas aplicaes que utilizam a Internet necessitam do
estabelecimento e gerenciamento de sesses. O fato dos usurios moverem-se
entre terminais, estarem acessveis por diferentes nomes, comunicarem-se
utilizando diferentes mdias e s vezes simultaneamente, dificulta a implementao
destas aplicaes. Neste cenrio destaca-se o protocolo SIP. Definido e
implementado pelo Internet Engineering Task Force (IETF), trata-se de um
protocolo de controle referente camada de aplicao do Modelo de Referncia
OSI (Open System Interconnection), capaz de iniciar, modificar e terminar
comunicaes multimdia ou chamadas entre usurios, definindo como os
equipamentos (computadores, telefones fixos, celulares, etc.) trocaro informaes
entre si. As aplicaes atuais do SIP esto direcionadas para as sesses interativas
de multimdia, tais como chamadas telefnicas ou conferncias multimdia, mas o
SIP pode ser utilizado em sistemas de mensagens instantneas, notificao de
acontecimentos, ou na gesto de outros tipos de sesso como, por exemplo, jogos
distribudos. Em meio as suas funcionalidades tem-se o estabelecimento de
chamadas, a localizao de usurios, suporte a unicast e multicast, administrao
na participao de chamadas, negociao de recursos entre as partes e a

21
possibilidade de interoperabilidade com o protocolo H323, atravs de um gateway.
O SIP basea-se no modelo cliente/servidor, como demonstrado na figura 1, o cliente
faz a requisio e o servidor retorna as respostas referentes ao pedido.

Figura 1 - Arquitetura cliente/servidor

A sintaxe e semntica do SIP assemelham-se ao HTML com campos
explicitamente descritos, e herda do Hyper Text Transfer Protocol (HTTP) vrias
propriedades, uma delas: o suporte ao transporte de qualquer tipo de carga. E
assim como o HTTP propiciou um grande impacto na Internet, o SIP promete o
mesmo no que se refere comunicao em tempo real: com celulares, ou telefones
comuns, via mensagens instantneas, ou utilizando qualquer dispositivo
fundamentado em IP (Internet Protocol). De fato o potencial do SIP extrapola sua
simplicidade e flexibilidade. Com uma estrutura textual, o SIP possibilita a incluso
de novas caractersticas de forma fcil e compatvel com verses anteriores, o que
fundamental para um protocolo que pretende ter vida longa. Os endereos SIP
so URLs (Unifomr Resource Locators), possibilitando a implementao de
diferentes recursos, como permitir realizar uma chamada, apenas com o clique em

22
um link em uma pgina web. O protocolo SIP faz parte de uma arquitetura de
protocolos de Conferncia Multimdia da Internet, em desenvolvimento no IETF. A
figura 2 apresenta a pilha de protocolos correspondente a esta arquitetura.

Figura 2 - Arquitetura de protocolos multimdia Internet

De acordo com a RFC 2543, que descreve as operaes do SIP, este
define algumas funcionalidades bsicas, tais como:
Estabelecimento, modificao e termino de sesses multimdia
O protocolo SIP, estabelece, modifica e termina sesses multimdia,
independente do tipo de sesso, seja ela uma vdeo conferncia, uma chamada
telefnica na Internet, um chat, ou at sesses de jogos entre participantes. O SIP
determina as capacidades do meio de transmisso entre os usurios e estabelece o
nvel mnimo de comunicao possvel entre dois pontos. Alm disso, permite que
os usurios determinem o tipo de informao que ser trocada e seus respectivos
parmetros. Possibilita a alterao dinmica das configuraes estabelecidas no
momento da conexo, por exemplo, a entrada de outros intervenientes na
conferncia, ou alteraes nas caractersticas em uma sesso j iniciada. O SIP
tambm detecta a transferncia de chamadas, estabelecendo uma conexo entre o
transmissor e o novo receptor, encerrando a conexo original. Se uma chamada
no pode ser estabelecida porque o destinatrio esta indisponvel, o SIP e capaz de
determinar o estado do mesmo, se este j est com outra chamada em curso, ou se
no atende num determinado tempo.
Mobilidade
O SIP no pode iniciar uma sesso com um potencial participante at

23
que este seja localizado. comum que um usurio se desloque entre estaes de
trabalho, podendo ser localizado em vrios lugares. O SIP determina a localizao
do destino da chamada atravs da resoluo de endereos, mapeamento de nomes
e redirecionamento de chamadas. Para que os usurios possam ser localizados,
estes registram-se em um servidor de localizao, isto torna-se necessrio para
que um determinado usurio que possui um nome qualquer, possa ser localizado
em algum momento da ligao. Os usurios em um ambiente SIP, so identificados
atravs do SIP Uniform Resource Locators, (URL), cuja sintaxe assemelha-se aos
endereos de correio eletrnico, geralmente constitudo por um nome de usurio e a
descrio do domnio, por exemplo: SIP:Arnaldo@empresa.com.
2.3 Componentes do SIP
O IETF define um conjunto de componentes na arquitetura do SIP,
operando em uma rede IP. Este conjunto de componentes definido como Rede
SIP, e apresentado na figura 3.

Figura 3 - Arquitetura SIP

24
SIP User Agent (UA)
o cliente da arquitetura, ou ponto final da comunicao multimdia,
que prov a interface de interao com o usurio. O User Agent possui dois
componentes: um User Agent Client (UAC), que responsvel por iniciar as
chamadas enviando as requisies, e um User Agent Server (UAS) responsvel por
responder as requisies do UAC. Um UA tem a capacidade de atuar como UAC e
UAS, porm de um modo a cada transao, dependendo de quem inicia o pedido.
Os SIP UAs so implementados em diversos tipos de sistemas. Estes podem, por
exemplo, operarem em um computador, atravs de uma aplicao, ou podem ser
implementados em dispositivos dedicados como um SIP phone. A figura 4, ilustra
alguns exemplos de UAs:

Figura 4 - Exemplos de UAs

SIP Proxy Server
So intermedirios em uma comunicao multimdia, um servidor de
redirecionamento de requisies e respostas. O SIP Proxy Server, recebe uma
requisio e atua como sinalizador da chamada, redirecionando-a para o prximo
servidor SIP da rede, como se fosse o requisitante. Assim que recebe a resposta,
encaminha ao real chamador. O SIP Proxy Server tambm disponibiliza servios

25
como: autenticao, autorizao, controle de acessos, roteamento, retransmisses
de pedidos e segurana. Tipicamente, o Proxy Server, acessa uma base ou um
servio de localizao para determinar o prximo hop (n da rede). Esta interface
entre proxy e servio de localizao no definida pelo SIP. As bases acessadas
pelo proxy, para determinar a localizao, pode conter: informaes de presena,
registros SIP, ou qualquer outro tipo de informao que auxilie na localizao do
usurio.
SIP Redirect Server
Responsvel por receber as requisies e Informar aos clientes o
caminho que a chamada deve tomar, de forma que o cliente entre diretamente em
contato com os prximos UAs. A funo primria do Redirect Server o roteamento
de chamadas, ou seja, a determinao do conjunto de servidores que ser utilizado
como rota para a comunicao. Para que sejam determinadas as rotas, tanto o SIP
Proxy Server quanto o SIP Redirect Server, podem utilizar meios tais como executar
programas de consulta a banco de dados. Alm disto, um servidor proxy tambm
pode duplicar a requisio, enviando copias destas para os prximos servidores.
Isto proporciona que uma requisio de inicio de chamada tente diferentes rotas, e
a primeira localizao que responder conectada com o cliente chamador. Em
resumo, o Redirect Server, faz o roteamento das requisies e respostas enviando
uma mensagem aos clientes com o endereo SIP procurado, e no fazendo o papel
de continuar a chamada. A Figura 5 ilustra o funcionamento do Redirect Server.
Nesta figura, Lvia pretende iniciar uma chamada para Rodrigo, utilizando uma
aplicao SIP em seu computador. Ao enviar o convite, o UA de Livia primeiramente
tenta localizar Rodrigo pelo seu endereo pblico, porm, no domnio empresa.com,
existe um SIP Redirect Server controlando os convites para inicio de sesso, que se
destinam a este domnio. O Redirect Server sabe que Rodrigo pode ser encontrado
tanto no endereo: SIP:Rodrigo.Souza@empresa.com, quanto no endereo: SIP:
Rodrigo@universidade.com, ento o Redirect Server informa Livia para que tente
localizar Rodrigo, nos endereos conhecidos. Alm disso, o servidor de
redirecionamento capaz de priorizar e informar para o UA de Livia que Rodrigo
ser localizado provavelmente no domnio empresa.com. Nota-se que neste
exemplo, o Redirect Server meramente retorna uma lista de possveis localidades
do destinatrio.

26

Figura 5 - Funcionamento do Redirect Server

A arquitetura SIP pode ainda apresentar os seguintes componentes:

SIP Registrars
So responsveis por processar os pedidos dos UAC, registrando sua
localizao, que armazenada em algum dos servidores de localizao da
arquitetura. O Registrar ou Register Server pode ser includo em um servidor proxy
ou em um Redirect Server. A figura 6 mostra Rodrigo registrando sua localizao
em um SIP Registrar:

27

Figura 6 - Registro da localizao em um Registrar Server

Servidor de Localizao
Sua funo armazenar e consultar registros de localizao de
usurios.
Gateway SIP
O Gateway e responsvel pela interoperabilidade entre redes SIP e
outras que utilizam diferentes protocolos de sinalizao, SIP H323 ou SIP PSTN
(Public Switched Telephone Network). A figura 7 ilustra esta interoperabilidade.

28

Figura 7 - Gateway SIP/PSTN e gateway SIP/H323

2.4 Sinalizao SIP
Na figura 8, v-se um exemplo do estabelecimento de uma sesso SIP
simples, entre dois dispositivos SIP. Estes dispositivos podem ser telefones SIP,
hand-helds, palmtops, telefones celulares, softwares para chamadas SIP, entre
outros. No exemplo ilustrado por Jonhston (2001), assume-se que ambos
dispositivos esto conectados em uma rede IP e cada um conhece o endereo IP
do outro.

29

Figura 8 - Estabelecimento de uma sesso SIP simples

Neste exemplo, o chamador Anderson inicia a troca de mensagens
enviando uma mensagem SIP INVITE para Livia. A mensagem de INVITE, contem
os detalhes do tipo de sesso que ser estabelecida. Esta sesso pode ser tanto
uma chamada com voz, uma conferncia com vdeo, ou at uma sesso para uma
partida de um jogo. Os campos da mensagem de INVITE so demonstrados na
figura 9.
INVITE sip:Livia@empresa.com.br SIP/2.0
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: Livia <sip:Livia@empresa.com.br>
From: Anderson <sip:Anderson@faculdade.com.br>;tag=76341
Call-ID: 123456789@laboratorio.faculdade.com.br
CSeq: 1 INVITE
Subject: Preciso de sua ajuda...
Contact: <sip:Anderson@laboratorio.faculdade.com.br>
Content-Type: application/sdp
Content-Length: 158
v=0
o=Anderson 2890844526 2890844526 IN IP4 laboratorio.faculdade.com.br
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figura 9 - Campos da mensagem INVITE

30
A linha de incio do INVITE SIP contm o tipo de pedido enviado pelo
cliente SIP, o endereo SIP do usurio destino e a verso SIP utilizada. De acordo
com Hersent (2001), o cabealho geral, comum tanto nos pedidos como nas
respostas, contm os seguintes campos:

Via:
Traz a verso SIP, o protocolo da camada de rede, o endereo IP do
usurio que faz a chamada e a porta utilizada.
Call-ID:
A primeira parte deste campo deve ser um padro nico dentro de
cada agente, e a ltima parte, o nome de domnio ou endereo IP. Um novo Call-
ID deve ser gerado para cada chamada.
From:
Este campo contm um nome que pode ser mostrado opcionalmente e
o endereo do originador da chamada. Deve estar presente tanto nas requisies
quanto nas respostas SIP. Nas respostas, o campo From simplesmente copiado a
partir do pedido e, portanto, no designa ser o originador da chamada.

To:
Este campo indica o destino da chamada, sendo obrigatrio em todas
as requisies e respostas SIP.
Cseq:
Este campo guarda um nmero escolhido aleatoriamente sem sinal,
que incrementado a cada novo pedido (com exceo dos pedidos do tipo ACK e
CANCEL, onde o nmero o mesmo da resposta recebida para o ACK; e o mesmo
do pedido cancelado para o CANCEL) juntamente com nome do mtodo, ou seja,
que identifica o tipo de pedido que est sendo enviado. No caso de mensagens do
tipo resposta, o servidor deve copiar o valor Cseq do pedido para as respostas
correspondentes. Em ambos os tipos de mensagens (requisies e respostas), o
campo Qseq obrigatrio. Alm dos campos de cabealho geral (utilizado por
requisies e respostas), uma requisio pode transportar campos com informaes

31
especficas dos pedidos no cabealho, tais como: o campo Accept que transporta
os tipos de mdias aceitveis na resposta, o campo Subject para transportar
informaes sobre a natureza da chamada. Os campos que terminam com CR
(Carrier Return) e LF (Line Feed) so utilizados para determinar o uso de uma linha
em branco entre os campos. O cabealho da entidade formado por campos de
que se aplicam diretamente ao corpo da mensagem, so eles:
Content-Type:
Informa o tipo de contedo da mensagem.
Content-Length:
Contm o nmero de octetos do corpo da mensagem.

Os campos Content-Type e Content-Length, indicam que o corpo da
mensagem, vista na figura 9, SDP (Session Description Protocol), contendo 169
octetos de dados. A demonstrao da contagem dos octetos ilustrada na figura
10. Uma linha em branco separa o corpo da mensagem dos campos de cabealho,
que termina com o campo Content-Length.
No exemplo da figura 9, pode-se observar sete linhas de informaes
SDP, que descrevem o tipo de mdia que o chamador Anderson prefere estabelecer
com Livia. A informao de mdia descrita necessria, pois o SIP no faz
suposio da mdia utilizada, ento o originador deve especificar exatamente seu
tipo. Os nomes dos campos SDP so listados na figura 11.
Linha Total
v=0 05
o=Anderson 2890844526 2890844526 IN IP4 laboratotio.faculdade.com.br 70
s=Phone Call 14
c=IN IP4 100.101.102.103 26
t=0 0 07
m=audio 49170 RTP/AVP 0 25
a=rtpmap:0 PCMU/8000 22
169
Figura 10 - Clculo do campo Content-Length

32
Parmetros SDP Descrio
v=0 Numero da verso
o=Anderson 2890844526 2890844526 IN IP4
laboratorio.faculdade.com.br
Nome do originador
s=Phone Call Assunto
c=IN IP4 100.101.102.103 Conexo
t=0 0 Tempo
m=audio 49170 RTP/AVP 0 Mdia
a=rtpmap:0 PCMU/8000 Atributos
Figura 11 - Descrio dos campos SDP

A figura 11 inclui:
O endereo de conexo IP 100.101.102.103.
O formato da Mdia udio.
O numero da porta utilizada 49170.
O protocolo de transporte de Mdia RTP (Real Time Protocol).
Codificao da Mdia - PCM u Law.
Taxa de amostragem 8000Hz.

O INVITE SIP, apenas um exemplo de requisio SIP. Segundo
especificaes na RFC 3261, existem ainda cinco outros tipos ou mtodos de
requisies SIP, e mais alguns em extenses desta RFC. As tabelas 12 e 13
apresentam os seis mtodos de requisies SIP e os mtodos estendidos
respectivamente.
Mtodo Funcionalidade
INVITE Convida pessoas para participar de uma sesso
ACK Confirma o recebimento de uma resposta final para um INVITE
BYE Solicita o trmino de uma sesso
CANCEL Solicita que uma sesso prvia seja cancelada, diferente do BYE
REGISTER Registra a informao de contato de um indivduo
OPTIONS Consulta servidores com respeito a suas capacidades
Figura 12 - Mtodos de requisies SIP

33
Mtodo RFC Funcionalidade
INFO 2976 Carrega informaes de controle geradas durante a sesso
MESSAGE 3428 Permite a transferncia de mensagens instantneas
NOTIFY 3265 Permite a notificao de eventos especficos
PRACK 3262 Confirma a recepo de uma mensagem de resposta
informativa
PUBLISH 3903 Publica o estado de um evento
REFER 3515 Solicita que o receptor faa contato com um terceiro
participante
SUBSCRIBE 3265 Permite se subscrever para um estado particular de um
recurso
UPDATE 3311 Permite a atualizao dos parmetros de uma sesso
Figura 13 - Mtodos de requisies estendidas do SIP

A prxima mensagem vista no fluxo da figura 8 a 180 Ringing,
enviada em resposta ao INVITE. Esta mensagem indica que a outra parte, no caso
Lvia recebeu o INVITE, e esta sendo alertada de que algum quer contat-la. O
alerta pode ser o toque do telefone, uma mensagem piscando no display, alerta
vibratrio, ou qualquer outra forma que indique a inteno da chamada. O 180
Ringing um tipo de mensagem SIP de resposta. As mensagens de resposta so
numricas e classificadas pelo primeiro dgito da seqncia. O 180 Ringing
qualificado como classe de informao, identificado pelo primeiro digito, o nmero 1.
Existem seis classes de respostas SIP, as primeiras cinco, foram herdadas do
HTTP verso 1.1, a sexta e ultima foi criada especificamente para o SIP. A figura 14
define cada classe de resposta SIP:
Classe Descrio Ao
1xx Informativo Indica o status da chamada antes que esta se
complete
2xx Sucesso A requisio foi recebida com sucesso
3xx Redirecionamento O servidor retornou possveis localidades. O cliente
deve reenviar a requisio para outros servidores
4xx Erro no Cliente A requisio falhou devido a um erro no cliente
5xx Falha no Servidor A requisio falhou devido a um erro no servidor
6xx Falha Global A requisio falhou. A requisio no deve ser
enviada a este ou outros servidores
Figura 14 - Classes de resposta SIP

34
A figura 15 demonstra a estrutura da mensagem 180 Ringing.
SIP/2.0 180 Ringing
;received=100.101.102.103
To: Livia <sip:livia@empresa.com.br>;tag=a53e42
CSeq: 1 INVITE
Contact: <sip:Livia@torre.empresa.com.br>
Content-Length: 0
Figura 15 - Estrutura da mensagem 180 Ringing

Esta mensagem composta pela cpia de alguns campos da
mensagem INVITE, como: Via, To, From, Call-ID e QSeq. Ento uma linha de inicio
adicionada a mensagem contendo a verso do SIP, o cdigo de resposta e a
frase que indica a razo: Ringing (tocando). O parmetro received adicionado ao
campo Via, que contem o endereo IP de quem o origina a chamada, que
tipicamente o mesmo endereo URI no campo Via, resolvido por um DNS
(laboratorio.faculdade.com.br). Nota-se que os campos To e From no se
inverteram, o que poderia se esperar, j que a mensagem partiu de Livia, porm o
SIP indica a direo da requisio, e no a direo da mensagem. Agora o campo
To, possui uma tag gerada por Lvia. Desde ento, todas as requisies e respostas
da sesso tero as tags geradas por ambos. A resposta tambm contm o campo
Contact, que descreve o endereo pelo qual Livia pode ser contatada diretamente
uma vez que a sesso tenha sido estabelecida. Quando a parte chamada aceita a
sesso, atendendo ao telefone, por exemplo, uma resposta de 200 OK enviada ao
originador da chamada, que tambm significa que o tipo de mdia proposta foi
aceito. A figura 16 ilustra a estrutura da mensagem 200 OK, enviada por Lvia.

35
SIP/2.0 200 OK
;received=100.101.102.103
To: Livia <sip:Livia@empresa.com.br>;tag=a53e42
CSeq: 1 INVITE
Contact: <sip:Livia@torre.empresa.com.br>
Content-Length: 155
v=0
o=Livia 2890844528 2890844528 IN IP4 torre.empresa.com.br
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
Figura 16 - Estrutura da mensagem 200 OK

A mensagem 200 OK estruturada da mesma forma que a 180
Ringing, contendo o mesmo tag do campo To, e o URI do contato. As capacidades
da mdia devem ser explicitadas no corpo da mensagem SDP adicionada na
resposta. No caso da figura 16, o corpo SDP contm:
Endereo do ponto final da comunicao 200.201.202.203.
Formato da mdia udio.
Nmero da porta 60000.
Protocolo de transporte de mdia RTP.
Codificao da mdia PCM u Law.
Taxa de amostragem 8000Hz.

A etapa final para confirmao e inicio da sesso, feita por uma
requisio de reconhecimento (acknowledgment). Este reconhecimento indica que o
originador da chamada, no caso Anderson, recebeu com sucesso, do destino, Livia,
uma resposta. Esta troca de informaes de mdia permite que a sesso seja
estabelecida usando outro protocolo, o RTP, por exemplo. A figura 17 mostra a
estrutura do acknowledgment (ACK).

36
ACK sip:Livia@torre.empresa.com.br SIP/2.0
Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hG4bK321g
Max-Forwards: 70
To: Livia <sip:livia@empresa.com.br>;tag=a53e42
CSeq: 1 ACK
Content-Length: 0
Figura 17 - Estrutura do ACK

O campo CSeq, tem o mesmo nmero do INVITE que originou a
sesso, porm o mtodo agora o ACK. Neste momento a sesso de mdia
iniciada, utilizando os parmetros estabelecidos na troca de mensagens SIP. A
comunicao acontece utilizando outro protocolo, tipicamente o RTP. O parmetro
branch contido no campo Via guarda um novo identificador da transao, isso
ocorre aps o reconhecimento de uma das partes da comunicao atravs do 200
OK, considerando uma nova transao. Estas mensagens trocadas, mostram que o
Session Initiation Protocol um protocolo de sinalizao fim-a-fim, ou seja, uma
rede SIP ou um Servidor SIP, no requerido para que o protocolo seja usado.
Dois end-points, utilizando a pilha de protocolo SIP e conhecendo o endereo IP um
do outro, podem fazer uso do SIP para configurar uma sesso entre eles. Quando o
chamador, Anderson, origina um INVITE, esta agindo como cliente, e quando Livia,
responde a esta requisio, esta agindo como servidor. Depois de estabelecida a
conexo, Livia envia uma requisio de BYE, agindo ento como um cliente, e
Anderson agora age como o servidor, quando responde a requisio. Este o
motivo pelo qual um ponto final da comunicao deve implementar tanto o software
cliente quanto o servidor. Jonhston (2001) ressalta ainda, que esta a diferena do
SIP em relao a outro protocolo cliente\servidor como o HTTP ou FTP. No HTTP,
por exemplo, o browser (navegador) age sempre como o cliente, e o Web Server
age sempre como o servidor, similar ao FTP. A figura 18 demonstra a requisio de
BYE, que indica que uma das partes, no caso Livia, deseja encerrar a sesso:

37
BYE sip:Anderson@laboratorio.faculdade.com.br SIP/2.0
Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hG4bK392kf
Max-Forwards: 70
To: Anderson <sip:Anderson@faculdade.com.br>;tag=76341
From: Livia <sip:Livia@empresa.com.br>;tag=a53e42
CSeq: 1 BYE
Content-Length: 0
Figura 18 - Estrutura do BYE

Pode-se observar na figura 18 que o campo Via do BYE possui o
endereo do host de Livia, e tambm um novo identificador de transao. Isso
ocorre pois o BYE considerado como uma nova transao, independente do
INVITE e do ACK. Os campos From e To mostram que a mensagem agora parte
de Livia. Assim Anderson consegue identificar a sesso pelo campo Call-ID, que o
mesmo do INVITE, e ento finalizar a sesso correta. A confirmao da resposta do
BYE o 200 OK, visto na figura 19, nota se que a resposta mantm o valor CSeq
da requisio de BYE.

SIP/2.0 200 OK
Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hG4bK392kf
;received=200.201.202.203
To: Anderson <sip:Anderson@faculdade.com.br>;tag=76341
From: Livia <sip:Livia@empresa.com.br>;tag=a53e42
CSeq: 1 BYE
Content-Length: 0
Figura 19 - 200 OK confirmao do BYE

2.5 Sinalizao SIP com Servidor Proxy
Jonhston (2001), explica ainda, que no exemplo ilustrado na figura 8, o
originador da chamada, Anderson, conhecia o endereo IP do destinatrio do
convite, possibilitando que a requisio de INVITE pudesse ser diretamente enviada
ao destino, o que no acontece em geral. Um endereo IP no pode ser utilizado
como um nmero de telefone, isto porque os endereos IPs so geralmente
dinmicos, obtidos pelo host quando este se conecta a um servidor DHCP, por
exemplo. Este endereo IP mantm-se fixo durante o tempo em que o host

38
permanece conectado, porm o endereo ser diferente a cada conexo com o
servidor. Com isto conclui-se que o endereo IP, no identifica unicamente um
usurio, e sim um host em uma rede particular. Contudo, existe um protocolo que
identifica o usurio atravs de um endereo, independente de onde este esteja, este
protocolo o SMTP (Send Mail Transfer Protocol). O SMTP entrega as mensagens
pelo endereo de e-mail, permitindo que o destinatrio seja alcanado,
independente de qual seja seu endereo IP, ou onde este esteja localizado. Sendo
a comunicao usurio-a-usurio e no dispositivo-a-dispositivo, o SIP utiliza um
esquema de endereamento semelhante ao de e-mail. Este endereamento parte
da famlia de endereos da Internet conhecidos como URI (Universal Resource
Identifier). O SIP URI um nome, que resolvido em endereo IP utilizando-se um
SIP Proxy Server e consultas a um DNS (Domain Name Server), no momento da
chamada, como visto na figura 20. Nesta figura, observa-se uma tpica chamada
SIP utilizando-se um Proxy Server.

Figura 20 - Chamada SIP com Proxy Server

39

O SIP Proxy Server, no configura ou termina a sesso, este age
apenas como intermedirio, situando-se entre as trocas de mensagens, apenas
recebendo as requisies e repassando-as. Na figura 20 v-se apenas um servidor
proxy, porm podem existir mltiplos servidores no caminho da sinalizao. O SIP
possui duas categorias de URIs: a primeira corresponde ao usurio, e a segunda
corresponde ao dispositivo ou ponto final da comunicao. As URI de usurio ou
user URI so conhecidas como address of record (AOR). Requisies destinadas a
AORs necessitam de buscas em bancos de dados de localizao, podendo resultar
no envio da requisio para um ou vrios dispositivos, j o URI de dispositivo,
conhecido como contato, no necessita de busca a banco de dados. O address of
record geralmente usado nos campos de cabealho: To e From, enquanto um URI
de dispositivo usado no campo de cabealho Contact. O mtodo que relaciona as
URIs de dispositivo com um address of record denominado REGISTER. Este
mtodo detalhado na sesso 2.6. Na demonstrao da figura 20, Anderson
desconhece a localizao de Rodrigo, ento o SIP Proxy Server usado para
repassar o INVITE. Primeiramente ocorre uma busca do URI SIP do domnio de
Rodrigo, que retorna o endereo IP do SIP Proxy Server deste domnio, ento o
INVITE repassado a este endereo. A figura 21 mostra a estrutura do INVITE.
INVITE sip:Rodrigo@escritorio.com.br SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
Max-Forwards: 70
To: Rodrigo <sip: Rodrigo@escritorio.com.br >
Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Subject: Onde voc est exatamente?
Contact: <sip:Anderson@pc33.faculdade.com.br>
Content-Length: 159
v=0
o=Anderson 2890844526 2890844526 IN IP4 100.101.102.103
s=Phone Call
t=0 0
c=IN IP4 100.101.102.103
Figura 21 - INVITE repassado ao Proxy

40
Aps receber o INVITE, o proxy examina o SIP URI requisitado, no
caso da figura 21: sip:Rodrigo@escritorio.com.br, localizando ento Rodrigo. O
proxy repassa o INVITE ao endereo IP do destinatrio, com a adio de um
segundo campo Via, como visto na figura 22, contendo o endereo do proxy. Pela
presena de dois campos Via, pode-se concluir que o INVITE passou por um Proxy
Server. Aps receber o INVITE, uma mensagem 180 Ringing enviada de Rodrigo
ao proxy. Esta mensagem detalhada na figura 23. Nota-se que o campo To, agora
possui uma tag, para identificar o dialogo em particular, alm disso, o campo
Contact, contm o URI do dispositivo de Rodrigo.

INVITE sip:Anderson@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.escritorio.com.br:5060;branch=z9hG4bK83842.1
Max-Forwards: 69
To: Rodrigo <sip:Rodrigo@escritorio.com.br>
Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Contact: <sip:Anderson@pc33.faculdade.com.br>
Content-Length: 159
v=0
o=Anderson 2890844526 2890844526 IN IP4 100.101.102.103
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
Figura 22 - INVITE repassado pelo proxy ao destino

SIP/2.0 180 Ringing
;received=100.101.102.105
To: Rodrigo <sip:Rodrigo@escritorio.com>;tag=314159
Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Contact: <sip:Rodrigo@200.201.202.203>
Content-Length: 0
Figura 23 - Mensagem 180 Ringing enviada ao proxy

41
O proxy recebe o 180 Ringing, e verifica que o primeiro campo Via
contm seu prprio endereo, ento o proxy remove o campo e repassa a resposta
ao endereo contido no prximo campo Via: 100.101.102.103, porta 5060. A
estrutura da resposta enviada a Anderson detalhada na figura 24.

SIP/2.0 180 Ringing
To: Rodrigo <sip:Rodrigo@escritorio.com.br>;tag=314159
Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Content-Length: 0
Figura 24 - Mensagem de resposta enviada do proxy ao originador

V-se que o campo Via, reduz a complexidade no encaminhamento da
mensagem, pois no requer buscas em banco de dados para localizao da rota, e
alm disso, a mensagem pode retornar pelos mesmos proxyes que a requisio. A
chamada aceita por Rodrigo que envia uma resposta 200 OK que repassada
pelo proxy a Anderson. A estrutura do 200 OK detalhada na figura 25.

SIP/2.0 200 OK
;received=100.101.102.105
To: Rodrigo <sip:Rodrigo@escritorio.com.br>;tag=314159
Call-ID: 10@100.101.102.103
CSeq: 1 INVITE
Content-Length: 159
v=0
o=Rodrigo 2890844526 2890844526 IN IP4 200.201.202.203
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
Figura 25 - Confirmao 200 OK repassada do proxy ao originador

Na figura 25, nota-se a presena do campo Contact, permitindo que a
mensagem de ACK seja encaminhada diretamente do originador ao destinatrio.

42
Por fim o BYE enviado diretamente ao ponto final da comunicao, que sinaliza
com um ACK, encerrando a sesso.
2.6 Registro SIP
Colcher (2005) explica que o primeiro passo para que um agente
possa ser conectado a um sistema de telefonia baseado no SIP, registrar-se em
um servidor de registro. Deste modo, as mensagens entrantes no sistema
destinadas a este usurio, podem ser encaminhadas corretamente para sua
localizao. Este processo pode ser feito diretamente entre o usurio e o servidor
de registro SIP, porm geralmente o registro feito atravs de um servidor proxy,
que utiliza algum processo de autenticao do usurio antes de encaminhar a
solicitao ao SIP Rregister Server. O registro do agente feito atravs de uma
requisio REGISTER, e alguns campos-chave no cabealho da mensagem. O
Campo From indica o endereo do indivduo que inicia o registro, e o campo To traz
o endereo de registro, ou seja, o endereo a ser associado ao usurio sendo
registrado. Caso o registro seja feito pelo prprio usurio, diretamente no servidor,
os campos To e From tero os mesmos valores. Entretanto, se o registro ocorrer de
forma indireta, ou seja, via servidor proxy, estes valores sero diferentes, indicando
que um individuo, no caso o proxy, esta realizando o registro em benefcio de outro,
o usurio. A mensagem de requisio de registro contm ainda o campo Contact,
que fornece a identificao do usurio e a localizao do seu agente, para onde
sero encaminhadas as futuras mensagens. Outro campo importante na requisio
de registro o campo Expire. Este campo contm um valor que indica o tempo
solicitado para o registro manter-se ativo no servidor de registro. Este tempo,
normalmente e indicado em segundos, e no pode ultrapassar o tempo limite
configurado no servidor, caso ocorra, adotado o tempo estabelecido no SIP
Register Server. Tal situao informada ao usurio na resposta enviada pelo
servidor, que indicar o tempo para expirao do registro no campo Expire do
cabealho da mensagem. O usurio precisa renovar o registro antes da expirao.
A figura 26, apresenta o contedo da mensagem REGISTER, enviada diretamente
de um agente localizado em m34.rio.com.br para o servidor de registro
registrar.rio.com.br.

43
REGISTER sip:registrar.rio.com.br SIP/2.0
Via: SIP/2.0/UDP m34.rio.com.br
From: <sip:Anderson@rio.com.br>
To: <sip:Anderson@rio.com.br>
Call-ID: 12345678@m34.rio.com.br
CSeq: 1 REGISTER
Contact: <sip:Anderson@rio.com.br>
Expire:3600
Content-Length: 0
Figura 26 - REGISTER enviado diretamente para o servidor de registro

O registro pode ser feito pelo usurio em mais de um agente, em
localizaes diferentes, e com o mesmo endereo de registro. Assim se uma
mensagem for destinada a este usurio, ser replicada em srie ou em paralelo
para os diversos agentes registrados para o individuo. O usurio pode remover seu
registro, enviando uma nova requisio REGISTER, indicando no campo To, o
endereo de registro, no campo Contact sua localizao e identificao, e o valor
zero no campo Expire. Caso queira remover todos os registros, basta utilizar o
caractere * (asterisco) como valor no campo Contact. A figura 27, apresenta o fluxo
de registro de um agente em um servidor de registro passando por um proxy.

Figura 27 - Registro de um agente em um servidor de registro via proxy

A seqncia do registro realizada da seguinte forma:
1 O usurio inicia o agente e uma requisio REGISTER enviada
ao proxy.

44
2 O servidor proxy recebe a mensagem REGISTER e envia a
resposta 100 Trying para o agente, indicando que a requisio fora recebida, no
sendo necessria a retransmisso.
3 Como o esquema de autenticao neste caso simplificado, o
servidor proxy encaminha a requisio REGISTER para o servidor de registro.
4 O servidor de registro ento envia uma resposta 200 OK para o
proxy. A operao de registro no utiliza a mensagem ACK.
5 O proxy encaminha a mensagem ao agente, notificando o registro
no sistema.
2.7 Redirecionamento
Em um sistema de telefonia baseado em SIP, pode ser necessria a
localizao de seus participantes, afirma Colcher (2005). Este processo realizado
utilizando-se as funcionalidades do servidor de redirecionamento. Para que seja
solicitado o servio de redirecionamento, uma mensagem INVITE deve ser
encaminhada para o servidor de redirecionamento, ou Redirect Server. O campo
From desta mensagem indica o endereo do usurio que solicita o mapeamento, e
no campo To o endereo do indivduo a ser localizado. A figura 28 apresenta o
contedo de uma mensagem INVITE, enviada por Anderson (anderson@rio.com.br)
para o servidor de redirecionamento (redirect.rio.com.br) solicitando a localizao
do usurio Rodrigo (rodrigo@rio.com.br).

INVITE sip:Rodrigo@redirect.rio.com.br SIP/2.0
From: Anderson <sip:Anderson@rio.com.br>
To: Rodrigo <sip:Rodrigo@rio.com.br>
CSeq: 1 INVITE
Subject: Proposta de Venda de Produto
Content-Length:256
Figura 28 - Mensagem INVITE enviada para o Redirect Server

Para realizar a localizao de participantes o Redirect Server age
como um cliente de um servio de localizao, este representado por um servio de

45
banco de dados que mantm o mapeamento entre uma nica URI e um conjunto
de localizaes possveis para o elemento referenciado na URI. A lista de uma ou
mais localizaes possveis so registradas no campo Contact da mensagem de
resposta de classe 3xx enviada pelo Redirect Server. A figura 29 apresenta o
contedo da mensagem de resposta 302 Moved Temporarily, enviada pelo Redirect
Server para o usurio Anderson, em resposta a mensagem da figura 28.

SIP/2.0 302 Moved Temporarily
From: Anderson <sip:Anderson@rio.com.br>
To: Rodrigo <sip:Rodrigo@rio.com.br>
CSeq: 1 INVITE
Contact: <sip:Rodrigo@minas.com.br>
Expire: 3600
Content-Length:0
Figura 29 - Reposta enviada pelo Redirect Server

Ao receber a mensagem de redirecionamento o originador da
chamada envia uma requisio ACK para o Redirect Server, e em seguida envia
uma nova requisio com base na URI ou URIs recebidas do Servidor de
redirecionamento. Estas URIs, no necessariamente so limitadas a URIs SIP,
podendo ser URIs de telefones, fax, irc, ou at de mailto:. A figura 30, apresenta o
processo de redirecionamento para efetivar a comunicao entre dois agentes
registrados atravs de servidores proxy.

46

Figura 30 - Redirecionamento via servidor proxy

O fluxo de mensagens realizado da seguinte forma:
1 O agente A envia uma requisio INVITE para que o proxy A
encaminhe ao agente B.
2 O proxy A recebe o INVITE e notifica o Agente A com a resposta
100 Trying.
3 Sendo o esquema de autenticao simplificado, o proxy no troca
demais mensagens com o agente A. E simplesmente encaminha o INVITE ao
servidor de redirecionamento.
4- O servidor de redirecionamento envia a resposta 302 Moved

47
Temporarily, com o mapeamento obtido atravs do servio de localizao.
5 O proxy A encaminha um ACK para o servidor de
redirecionamento completando o three-way-handshake (aperto de mo em trs
vias).
6 O proxy A utiliza a informao de mapeamento e gera um novo
INVITE, enviado ao proxy B.
2.8 SIP X H.323

O SIP e H.323 foram desenvolvidos para enderear e sinalizar
sesses multimdia em arquiteturas distribudas de controle de chamadas. Ambos
permitem comunicaes com dois ou mais participantes, utilizando computadores
ou telefones como pontos terminais, admitem negociaes de parmetros,
criptografia e utilizam os protocolos RTP e RTCP para transporte e controle,
respectivamente. O protocolo H.323 constitudo por mltiplos protocolos incluindo,
Q.931 para a sinalizao, H.245 para a negociao e o RAS (Registration
Admission Status) para controle de sesses. Este protocolo considerado por
muitos, um protocolo grande, pesado, complexo e rgido, tpico das empresas de
telecomunicaes, difcil de adaptar a solues futuras. Ao contrrio, o SIP um
protocolo tpico da Internet e funciona trocando mensagens simples de texto ASCII.
O SIP um protocolo com boa inter-operao com os outros protocolos da Internet,
mas no muito bom com os protocolos de sinalizao do sistema telefnico
existente. Por ser um protocolo altamente modular e flexvel, (modelo VoIP IETF),
pode ser facilmente adaptado a novas aplicaes. Prometendo ser o centro no
controle das NGN (Next Generation Network). Segundo David (2005) o H.323
significa o Mundo Antigo das redes telefnicas PSTN, por ser complexo,
determinstico e vertical. Ao ser focalizado em aplicaes multimdia, preocupa-se
em especificar todos os parmetros da comunicao, centralizando a complexidade
no servidor. Ao contrrio, o SIP significa o Novo Mundo das telecomunicaes
sobre redes IP, tratando-se de um protocolo da famlia dos protocolos Internet,
simples, aberto e horizontal. O SIP um protocolo de transao genrico que
delega a complexidade nos clientes. A figura 31 resume algumas diferenas entre

48
estes protocolos. Conclui-se nesta figura que o SIP mais simples e mais orientado
para a Internet, suportando inclusive funcionalidades como instant messaging.
Aspectos H.323 SIP
Negociao

H.245 SDP
Codecs

Todos Todos
Comunicao

RTP/RTCP RTP/RTCP
Codificao das
Mensagens

Binrio ASCII
Transporte UDP e maioritariamente
TCP
TCP e maioritariamente
UDP
Instant Messaging

- RFC 3428
Figura 31 - SIP X 323
2.8.1 Diferenas na Sinalizao
As mensagens de sinalizao e de controle podem ser trocadas
diretamente entre os terminais ou atravs de um servidor. A sinalizao SIP mais
simples, permitindo adicionar funcionalidades e servios sem se perder a
compatibilidade com os terminais antigos, algo que no possvel no H.323. A
figura 32, compara as sinalizaes SIP e H323.
H.323 SIP

Usa o H245 como protocolo de controle
para comunicaes multimdia.

Sinalizao em binrio ASN.1.

Possveis atrasos.

Utiliza funes RAS (Registration,
Admission and Status) para o registro
dos terminais e resoluo de endereos.

Sinalizao textual muito semelhante ao
HTTP ou SMTP;

Atrasos mnimos devido a sinalizao
simplificada.
Figura 32 - Sinalizaes SIP X H323

49
2.8.2 Diferenas no Streaming
O streaming o envio da informao entre os terminais. A forma como
feito diferente dependendo dos protocolos. Embora tanto o H323, quanto o SIP
utilizem pacotes RTP/RTCP, o interior dos pacotes muito diferente. A figura 33
demonstra as diferenas no streamming.

H.323 SIP

O H.245 usado para negociar a
capacidade dos terminais e criar canais
de mdia

Usa RTSP que um protocolo para
controle de sistemas de streamming.

O RTSP tem mdia unidirecional.

Usa o controle de chamadas SDP que
um descritor de mdia baseado em texto.

O SDP pode ser transportado nas
mensagens SIP.

Os URIs so semelhantes ao e-mail.

Geralmente inicia sesses bidirecionais.

Figura 33 - Diferenas no streamming SIP X H323

50
3 VULNERABILIDADES DOS SISTEMAS VOIP BASEADOS EM SIP
3.1 Introduo
Est claro que a tecnologia VoIP a grande tendncia emergente no
panorama das telecomunicaes, porm, apesar de todas as oportunidades
apresentadas, o servio de voz sobre redes IP introduziu novos riscos referentes a
segurana da informao. A converso para o sistema de telefonia IP sem os
devidos cuidados com a segurana, pode acarretar srios danos ao negcio,
transformando a soluo em problemas. Se por um lado as empresas economizam
ao fazerem ligaes telefnicas pela internet, por outro, esto expondo seus
sistemas de voz a todas as pragas que hoje atacam as redes de dados, como
worms, vrus, spam sobre telefonia Internet (SPIT), ataques DoS, DDoS e fraudes,
comprometendo toda infra-estrutura VoIP. A utilizao de redes privadas de
operadoras, no elimina os riscos de segurana. Ameaas de origem interna, como
ataques e fraudes continuam existindo. Segurana em ambientes VoIP so
exigidas, embora promove-la na Internet seja mais complexo do que em redes
PSTN. Mensagens SIP trocadas para o estabelecimento de sesses, podem conter
informaes privadas, que o usurio ou o servidor queiram manter em sigilo. Um
exemplo so os cabealhos SIP, estes podem revelar informaes sobre a
comunicao entre as partes. O mesmo ocorre com o corpo das mensagens, que
podem conter dados que no devem ser expostos, como: endereos, nmeros de
telefone, etc. A natureza aberta dos protocolos VoIP em conjunto com o grande
nmero de sub-sistemas existentes na telefonia sobre a Internet, torna o desafio de
estabelecer-se uma comunicao segura, muito mais complexo. O acesso fcil ao
canal de comunicao a ameaa mais ativa em um sistema VoIP. A captura e
analise do trafego da internet, facilitada pela estrutura textual do SIP, faz com que
seja simples a tarefa de espionagem. Assim, o protocolo SIP, oferece oportunidades
para ataques do tipo spoofing (falsificao), hijacking (seqestro), e message
tampering (adulterao de mensagens). A figura 34 ilustra uma mensagem SIP
INVITE, assinalando alguns campos passiveis de falsificao.

51
INVITE sip:Livia@empresa.com.br SIP/2.0
Max-Forwards: 70
To: Livia <sip:Livia@empresa.com.br>
From: Anderson <sip:Anderson@lfaculdade.com.br>;tag=76341
CSeq: 1 INVITE
Subject: Preciso de sua ajuda...
Contact: <sip:Anderson@laboratorio.faculdade.com.br>
Content-Length: 158
v=0
o=Anderson 2890844526 2890844526 IN IP4 laboratorio.faculdade.com.br
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP /AVP 0
Figura 34 - SIP INVITE passvel de sniffing e spooffing

A utilizao de mensagens SIP maliciosas pode causar desde o
acesso no autorizado ao sistema, at o estado crtico de negao de servio
(Denial of Service - DoS). Ataques de DoS so um grande problema para o SIP. Um
atacante pode, por exemplo, inserir um cdigo malicioso em uma requisio
REGISTER, induzindo a modificao do banco de dados de registro, fazendo com
que toda requisio de INVITE destinada a um usurio seja distribuda para vrios
agentes pelo proxy, amplificando o trfego, ou ainda enviada a um nico agente,
tornando este indisponvel. Por utilizar os protocolos TCP e UDP para o transporte,
e sendo estes protocolos vulnerveis a ataques como SYN flood, session hijacking,
o SIP tambm ser vulnervel a ataques similares. Alm disso, a interoperabilidade
do SIP permite a interconexo com redes PSTN, introduzindo novos pontos de
falha, como os gateways, que so susceptveis a ataques de DoS e message
tampering. Os bugs (falhas) de software so outras fontes para problemas de
segurana do protocolo SIP, podendo causar o acesso no autorizado ou o DoS,
quando implementados em telefones. Por outro lado, se implementados em Smart
Phones, so vulnerveis a pragas como vrus.

52
...Stevens assinalou ainda que com os sistemas de voz sobre IP o
problema tende a piorar. Um exemplo pode ser o da operadora - que
no teve o nome revelado - e que perdeu cerca de 76 mil dlares em
um nico dia com a invaso de seu sistema de VoIP. Recentemente,
a Telecom New Zealand, principal operadora de telefonia fixa e
mvel da Nova Zelndia, enfrentou uma vulnerabilidade que permitiu
que hackers acessassem correios de voz de seus clientes. Utilizando
um software que permitia fazer ligaes de voz sobre IP, um
adolescente acessou correios de voz de vrias personalidades do
pas, at mesmo do prefeito de Auckland, a maior cidade do pas. (
STEVENS , 2005)
Aspectos como vulnerabilidades em equipamentos que utilizam
protocolos para telefonia IP, so ressalvas importantes a serem consideradas, a fim
de impedir o comprometimento da rede e da utilizao fraudulenta do servio. Os
protocolos da pilha TCP/IP, atentam-se a funcionalidade e portabilidade no tendo a
segurana como prioridade.
TCP/IP e a maioria dos seus protocolos no foram desenvolvidos
com a segurana como prioridade. Eles foram projetados para
funcionalidade e portabilidade. (WILLIAN, 2003 apud YOSHIOKA,
2003, traduo nossa).
A maioria dos desenvolvimentos em SIP so focados em
interoperabilidade, com pouca ateno para segurana. Um sistema
SIP vulnervel aos ataques IP e VoIP, bem como a ataques que
so nicos ao SIP. fundamental que tal fato seja entendido e que
sejam tomadas as medidas apropriadas de segurana (COLLIER,
2005 , traduo nossa).
Segundo Yoshioka (2003), existem alguns desafios a serem
considerados em relao a segurana em telefonia IP:
a) Confidencialidade: As informaes armazenadas e transmitidas
so acessveis somente aos autorizados.
b) Autenticidade: Assegurar a correta identificao da origem
mensagem.
c) Integridade: Garantir que as mensagens no sejam apagadas ou
alteradas de forma no autorizada.

53
d) Disponibilidade: As informaes e servios devem estar
disponveis 99,999%(five nines) para os autorizados.

e) No Repdio: Garantir que originador e o receptor da mensagem
no possam negar a autoria e recebimento respectivamente.

f) Controle de Acesso: O acesso s informaes e recursos devem
ser controlados por autorizados.

Como visto as redes VoIP esto propensas aos mais diversos tipos de
ameaas. Um atacante pode invadir servidores ganhando o acesso informao
vital de uma organizao, ou ainda empregar de forma maliciosa os servios de
voz, atravs do acesso no autorizado, beneficiando-se das vulnerabilidades do
sistema. Segundo Dhamankar (2004), falhas existentes nestes sistemas so
definidas da seguinte forma:
a) Vulnerabilidades dos Sistemas Operacionais implementados
nos dispositivos VoIP: Os dispositivos VoIP, tais como: IP
Phones, Call Manager, Gateways, e Proxy Servers, herdam as
mesmas vulnerabilidades dos Sistemas Operacionais ou firmware,
implementados nos mesmos. Estes dispositivos so tipicamente
desenvolvidos com os Sistemas Windows ou Linux, estes com
diversas vulnerabilidades j exploradas. Portanto, no importa o
quo uma aplicao VoIP seja ser segura, se o Sistema
operacional estiver comprometido, seu servio de telefonia IP
estar em risco.

b) Configurao inadequada dos dispositivos VoIP: Em sua
configurao padro, muitos dispositivos de VoIP, expem
diversas portas UDP e TCP. Estas portas podem ser vulnerveis
a ataques do tipo DoS, Buffer overflow, e ainda permitir que
senhas fracas sejam facilmente capturadas.

54
c) Vulnerabilidades da infra-estrutura IP: O servio de VoIP
depende diretamente da disponibilidade da infra-estrutura IP em
que este esteja implementado. Utilizando-se dos protocolos UDP
e TCP, como meio de transporte, o servio de VoIP, est
suscetvel as diversas ameaas tais como ataques de DDoS, SYN
flood, que podem gerar indisponibilidade do servio, ou ainda,
ataques de hijaking no caso do TCP, e a fragmentao maliciosa,
como o ping-da-morte (ping-of-death), no caso do UDP.

d) Vulnerabilidades em implementaes de protocolos para
VoIP: Os protocolos escritos para VoIP no tem como prioridade
a segurana, e sim a interoperabilidade. Muitas vulnerabilidades
encontradas em implementaes destes protocolos, como o SIP,
so resultado de pesquisas de grupos especializados que
geralmente disponibilizam suas ferramentas para teste das
vulnerabilidades nas implementaes dos protocolos.

e) Vulnerabilidades na camada de aplicao VoIP: Nesta camada
existem uma variedade de ataques especficos ao VoIP. Includo:
Denial of Service (DoS)
Call Hijacking
Resource Exhaustion
Evearsdropping
Message Integrity
Toll Fraud

O protocolo SIP possui os as mesmas vulnerabilidades do protocolo IP
e da camada de aplicao, este fato explicado por alguns fatores:
Maturidade: as Implementaes SIP so relativamente novas.

Codificao: o SIP utiliza mensagens de texto nas suas sinalizaes,
que so fceis de serem lidas, utilizando um sniffer.

55

Extensvel: O SIP suporta extenses, que so novas e geralmente
frgeis do ponto de vista da segurana.

O SIP, oferece uma segurana embutida limitada, de acordo com a
RFC 3261, alguns itens classificados como recomendado, esto faltando em
algumas implementaes. Alm disto, o SIP promete interoperabilidade, permitindo
a aquisio de componentes de diversos fornecedores, isto tornar-se um problema,
pois todos os componentes devem suportar os mesmos padres, caso contrrio,
apenas as capacidades comuns sero utilizadas, fato grave do ponto de vista da
segurana. O SIP utiliza o protocolo UDP, para o transporte das mensagens, que
protocolo no orientado conexo, e no confivel. Nele no ocorre a
retransmisso dos pacotes, nem a ordenao dos mesmos, facilitando os ataques
de spoofing.
Softwares SIP de alguns fabricantes podem deixar os dispositivos
SIP como: IP Phones, PBX, e clientes instat messaging, vulnerveis
a ataques de DoS. (CERT CORDINATION CENTER 2003 Apud
HOCHMUTH, 2003, traduo nossa).
3.2 Ameaas e Ataques ao SIP
Esta sesso descreve possveis falhas de segurana em sistemas
baseados no protocolo SIP, bem como ataques que fazem uso destas brechas,
colocando em risco a disponibilidade do servio.
3.2.1 Registration Hijacking
O ataque de hijacking ou seqestro uma forma de se obter o controle
de uma conexo iniciada por um UA legtimo, impedindo o mesmo de fazer uso do
sistema e tomando seu lugar. O registration Hijacking (Seqestro do Registro)
ocorre quando um atacante falsifica um UA vlido para um SIP Register, alterando a

56
inscrio legtima para seu prprio endereo. Assim todas as chamadas so
enviadas para o UA registrado pelo atacante. A figura 35 ilustra uma mensagem de
registro vlida, que como explicado anteriormente, usada para anunciar o ponto
de contato de um usurio. O registro do usurio indica que este est apto a receber
chamadas.

Figura 35 - Mensagem de registro vlida

A requisio de REGISTER, possui o cabealho Contact:, que indica o
endereo IP do dispositivo do usurio (tanto para um software VoIP, quanto para
um telefone IP). Quando o proxy recebe a requisio de INVITE, ele far uma busca
para identificar onde o usurio ao qual se destina a chamada se encontra. No caso
da Figura 35, o usurio com o numero 201-853-0102 pode ser encontrado no
endereo IP 192.168.94.70. O proxy ir repassar a requisio de invite para aquele
endereo IP. O cabealho da mensagem informa que a porta a ser utilizada 5061.

57
A Figura 36 mostra uma verso modificada do REGISTER, que pode ser lanada
por um atacante.

Figura 36 - Verso modificada do registro

Nesta requisio, todos os cabealhos e os parmetros mantm-se
inalterados, exceto os parmetros no cabealho Contact. Este, alterado para o
endereo: 192.168.1.3, apontando para o dispositivo do atacante, por exemplo.
Utilizando ferramentas como o SiVuS, muito fcil gerar mensagens forjadas, como
demonstrado na figura 37.

58

Figura 37 - Spoofing do registro utilizando o SiVuS

O ataque de Registration Hijacking pode seguir os seguintes passos:

1. Desabilitar o registro legitimo da vitima, que pode ser feito das
seguintes maneiras:
Executando um ataque de DoS no dispositivo do alvo.
Executando um ataque no Registrar Server, removendo o
registro da vitima.
Gerando disputa de mensagens de registro, onde o atacante
envia repetidamente mensagens de REGISTER num perodo
curto de tempo, com isso o atacante tenta sobrescrever o
registro do usurio legtimo.

59
2. Enviar a requisio de REGISTER alterando o endereo IP de
localizao do usurio legtimo, para o dispositivo do atacante. A
figura 38 demonstra o fluxo do ataque.

Figura 38 - Ataque de Registration Hijacking

O registro normalmente feito com a utilizao do protocolo UDP,
tornando fcil o spoofing das requisies. Frequentemente a autenticao no

60
requerida, e se presente, na maioria das vezes fraca, exigindo apenas um usurio
e uma senha. De acordo com a RFC 3261, os dispositivos de registro SIP, so
recomendados a comprovar a autenticidade das solicitaes. Muitos destes
dispositivos ou no fazem, ou simplesmente exigem um nome do usurio e uma
senha, que podem facilmente serem descobertos atravs de um ataque de
dicionrio, onde o atacante possui um dos nomes de usurio e tenta descobrir a
senha atravs de uma lista de possibilidades baseadas no conhecimento da
corporao. Um atacante externo pode tambm criar um diretrio de usurios,
atravs de um scanning dos endereos dos UAs. Algumas empresas utilizam
senhas compartilhadas, fracas, ou geradas mecanicamente. Neste caso, um
atacante que aprende uma das senhas, estar apto a aprender todas as outras.
Tentativas falhas de registro, no so armazenadas em arquivos de log, e o proxy
SIP, normalmente, no detecta tentativas de scanning e registration hijacking. O
ataque de registration hijacking, resulta na perda de chamadas ao UA legtimo, que
pode ser um usurio, telefone ou recurso crtico. Alm disto, o atacante capaz de
coletar a autenticao ou outra informao sobre a chave de sinalizao, podendo
tambm realizar o ataque de man-in-the-middle (MITL), onde este posiciona-se de
forma transparente entre o UA chamandor e o UA chamado, possibilitando a coleta
e a modificao tanto da sinalizao quanto da mdia. O Registration Hijacking
pode ser lanado tanto contra empresas quanto contra usurios domsticos. Uma
rede domstica, por exemplo, que utiliza uma rede wireless mal configurada pode
ser comprometida por um atacante, que pode interceptar e encaminhar requisies
de registro. No caso de sucesso no registro, o atacante pode executar diversos
ataques, como chamadas fraudulentas, ou redirecionamento da comunicao, que
podem ser executados tambm em empresas.
3.2.2 Proxy Impersonation
O ataque de proxy Impersonation ou personificao de proxy, ocorre
quando um atacante engana um dos SIP UAs ou proxy do sistema de comunicao
com um falso proxy. Se o atacante obtiver sucesso no ataque, este ter acesso
todas as mensagens SIP, e tambm ao controle total da chamada. A figura 39
ilustra o ataque de proxy impersonation.

61

Figura 39 - Ataque de proxy Impersonation

Os Uas e proxy, normalmente se comunicam utilizando o UDP, sendo
assim, um falso proxy pode, portanto, inserir-se no sistema de sinalizao atravs
de diversos meios, incluindo DNS (Domain Name Service) spoofing, ARP (Address
Resolution Protocol) cache spoofing, ou simplesmente mudando o endereo proxy
para um telefone SIP. Um proxy disfarado tem o controle total das chamadas e
pode executar os mesmos tipos de ataques descritos no ataque de registration
hijacking. Se o DNS spoofing for usado para redirecionar chamadas de sada para
um domnio particular, todo o curso da comunicao para aquele destino pode ser
interceptado, manipulado, bloqueado, assistido, ou gravado. O ARP cache spoofing
um ataque contra um switch de rede, que pode enganar um UA comunicando-se
com o falso proxy na rede interna. Se bem sucedido, este ataque faz com que todas
as chamadas originadas do UA, possam ser interceptadas, manipuladas,
bloqueadas, assistidas e gravadas.

62
3.2.3 Eavesdropping (Espionando)
A espionagem em VoIP difere-se da espionagem das redes
tradicionais de dados, porm o conceito segue a mesma linha. O Eavesdropping em
redes VoIP requer a interceptao da sinalizao e do respectivo fluxo de mdia da
conversao. As mensagens de sinalizao utilizam protocolos como UDP e TCP e
o fluxo da mdia tipicamente so transportadas sobre UDP utilizando o protocolo
RTP. Com o uso de ferramentas como o Ethereal ou Cain & Abel, que so, entre
outras, ferramentas de sniffing de rede, possvel capturar a mdia transportada,
como demonstrado na figura 40.

Figura 40 - Passos para capturar a mdia VoIP com o Ethereal

O ataque de Eavesdropping pode seguir os seguintes passos:

1. Capturar e decodificar os pacotes RTP utilizando um sniffer.
2. Analisar a sesso, extrado a mdia a ser remontada.

63
3. Extrair o arquivo contendo o udio da conversao capturado.

A utilizao de switches que restringem o trfego de broadcast no
impossibilitam o ataque, pois o ARP Spoofing pode ser utilizado para lanar um
ataque de homem-do-meio permitindo a espionagem. A figura 41 resume o ataque
de ARP Spoofing.

Figura 41 - Ataque de ARP Spoofing

A Figura 42 demonstra a utilizao da ferramenta Cain, promovendo a
habilidade de realizar o ataque de homem-do-meio, capturando o trfego VoIP.

64

Figura 42 - A ferramenta Cain realizando o ataque de homem-do-meio
3.2.4 Message Tampering
O ataque de Message Tampering ou adulterao de mensagens
ocorre quando o atacante intercepta e modifica pacotes trocados entre
componentes SIP. Este ataque pode acontecer atravs de Registration Hijacking,
Proxy Impersonation, ou ataque a um componente SIP com direitos de processar
mensagens, tais como proxy, media gateway, ou firewall. A figura 43 ilustra o
message tampering.

Figura 43 - Ataque de Message Tampering

As mensagens SIP no tm nenhum meio embutido para assegurar a
integridade. Manipulando estas mensagens, um atacante pode executar os mesmos
tipos de ataques descritos para Registration Hijacking e Proxy Impersonation.

65
3.2.5 Session Tear Down
Session tear down ocorre quando o atacante observa a sinalizao da
chamada, e ento envia um falso SIP BYE ou um re-INVITE para os UAs
participantes. A maioria dos UAs, no requerem uma forma de autenticao forte, o
que permite ao atacante enviar o SIP BYE para encerrar a chamada, ou um re-
INVITE para altera-la. A figura 44 ilustra o Session Tear Down.

Figura 44 - Ataque de session tear down

Se um UA no confere a validade do pacote, o atacante nem mesmo
necessita de observar a sinalizao da chamada. Se o atacante conhece o
endereo de um UA continuamente ativo, como o Media Gateway, ele pode fazer
com que estes UAs ativos enviem as mensagens de do tipo BYE causando a
finalizao das chamadas. Um outro exemplo de tear down, praticar um ataque de
flooding no firewall, inundando este com mensagens SIP BYE, fazendo com que
sejam derrubadas as portas UDP abertas por chamadas legtimas. O DoS o efeito
primrio do session tear down. O SIP re-INVITE, utilizado para modificar a mdia, se
direcionados a endereos de broadcast pode tambm causar o DoS.

66
3.2.6 Denial of Service
Denial of Service (DoS), ou Negao de servio, pode ocorrer por
quaisquer meios descritos nos outros ataques, ou por um ataque de DoS especifico.
Por ser raramente usada uma autenticao forte, componentes SIP podem
processar mensagens de atacantes. Pesquisas demonstraram que muitas
implementaes do SIP so altamente vulnerveis a este tipo de ataque. O DoS
pode ser especialmente prejudicial se o alvo for um recurso chave do sistema como
o Media Gateway, podendo, por exemplo gerar um enorme nmero de chamadas
para servios de informao, polcia, bombeiros, etc, ou ainda utilizar de uma rede
para lanar ataques a outra empresa.

3.3 Ataques utilizando de Mensagens SIP
Certos ataques arquitetura SIP podem ser evitados utilizando-se um
esquema de autenticao apropriado. Porm mesmo com a autenticao aplicada,
alguns ataques ainda so possveis. Nesta sesso sero apresentados ataques a
arquitetura, utilizando mensagens SIP, tanto em ambientes sem autenticao
aplicada, quanto em ambientes que fazem uso da autenticao.
3.3.1 Ataques a sistemas sem a autenticao aplicada
3.3.1.1 Ataque de DoS utilizando mensagens de REGISTER SIP

Dagiuklas (2005) explica que um atacante pode remover o registro de
todos os contatos existentes para uma URI, e registrar-se no lugar dos contatos
vlidos, fazendo com que todas as mensagens destinadas a estes usurios sejam
direcionadas ao seu dispositivo. Alm disso, possvel lanar um ataque de DoS

67
modificando uma requisio de registro que contenha mais de um endereo de
contato e que utilize valores q para classificar a prioridade correspondente a estes
endereos. Se este campo for alterado para o valor 0 (zero), possvel que o
usurio no receba mensagens de SIP INVITE. O mesmo ocorre para o valor do
campo Expire, ilustrado na figura 45, a modificao maliciosa deste valor para 0
(zero), indica a remoo do registro do usurio. Alm disso, o atacante pode no
somente modificar os valores q, mas tambm adicionar seu endereo, fazendo
com que este receba todas as mensagens entrantes no sistema.

Figura 45 - Remoo do registro do usurio pelo atacante

3.3.1.2 Ataque de Re-INVITE

Uma vez iniciada uma sesso por uma mensagem inicial, mensagens
subseqentes de requisies podem ser enviadas com o propsito de alterar o
status da sesso. Entretanto, modificaes no-autorizadas da sesso atravs de
re-INVITE forjados por um potencial atacante, podem causar o DoS. A figura 46
ilustra o fluxo do ataque.

68

Figura 46 - Fluxo do Ataque de re-INVITE

3.3.1.3 Ataque de BYE

O objetivo do ataque de BYE encerrar uma sesso j estabelecida.
Para que seja possvel a execuo deste ataque necessrio que o atacante
conhea os parmetros da sesso tais como: Session-ID, RTP Port, etc. Para isto, o
atacante realiza um sniffing da rede, ou realiza um ataque de man-in-the-midlle. O
sucesso deste ataque depende da falta de mecanismos de autenticao
apropriados, e claro, da capacidade do atacante de descobrir os parmetros da
sesso. A figura 47 ilustra o fluxo do ataque de BYE.

69

Figura 47 - Ataque de BYE

3.3.1.4 Ataque de UPDATE
O mtodo de UPDATE SIP proporciona aos usurios finais as diversas
capacidades da sesso, como por exemplo, a identificao dos parmetros de QoS
e a negociao para outros atributos da sesso. A diferena entre o re-INVITE e o
UPDATE no que diz respeito negociao da sesso, e que o re-INVITE s pode
ser utilizado aps o estabelecimento da sesso, enquanto que o mtodo UPDATE
pode ser lanado antes da resposta para o convite inicial. Utilizando-se destas
funcionalidades, um atacante pode enviar mensagens de UPDATE forjadas para
modificar os parmetros iniciais da sesso com o intuito de degradar a qualidade do
servio, impedindo a comunicao entre participantes. A figura 48 ilustra o fluxo do

70
ataque de UPDATE.

Figura 48 - Fluxo do ataque de UPDADE

3.3.2 Ataques a sistemas com a autenticao aplicada (antes da autenticao)
Mesmo com a aplicao de servios de autenticao, ameaas a
arquitetura no deixam de existir. Ataques como o de parsing, so lanados mesmo
antes da autenticao. Esta sesso descreve alguns ataques deste tipo.

71
3.3.2.1 Ataques de Parser

Complexidade da anlise gramatical SIP

Uma mensagem SIP pode ser tanto uma requisio quanto um
reconhecimento a esta requisio, constituda de campos de cabealho e corpo,
baseadas em texto com um grande grau de liberdade. Sendo assim, uma analise
gramatical eficiente da mensagem requerida para avaliar a estrutura da mesma
considerando apenas a informao necessria. Esta anlise gramatical conhecida
como parse. Entretanto, mesmo mensagens SIP vlidas podem ser construdas
para impedir sua anlise gramatical (parsing). De acordo com Dagiuklas (2005), um
atacante pode criar mensagens longas, com mltiplos cabealhos e com um
extenso corpo, pois todas as mensagens permitem a adio do corpo, mesmo que
este no seja necessrio. Com isso, alm de aumentar o processamento do agente,
as mensagens longas aumentam o trfego da rede. Outro problema a incluso do
mesmo campo de cabealho, mltiplas vezes na mesma mensagem, onde estes
esto distribudos, tornando complexa a anlise gramatical. Alm disso, alguns
campos de cabealho SIP permitem outros tipos de URIs, tal fato tambm prejudica
o processo de parsing. Mesmo que um analisador gramatical bem aprimorado
pudesse impedir o ataque de parsing, o processamento necessrio para tal, poderia
dificultar a execuo de outras tarefas, prejudicando o desempenho.

Mensagens SIP Mal-Formadas

Por sua codificao ASCII, o SIP torna-se mais atrativo para atacantes
do que seu concorrente da ITU o protocolo H.323, este com uma codificao mais
complexa. Atacantes podem fazer uso de qualquer mtodo SIP, includo suas
extenses para lanar um ataque utilizando mensagens mal formadas. A figura 49
apresenta uma mensagem SIP INVITE bem formada, conforme especificao na
RFC 3261. Porm, devido a erros de implementao, em certos casos, levando em
considerao a complexidade do analisador gramatical SIP, mesmo mensagens
bem formadas podem gerar falhas em servidores. Alm de erros de implementao,

72
o atacante tentar diversas combinaes de mensagens SIP mal formadas a fim de
descobrir possveis falhas no sistema SIP da vitima. A figura 50 uma mensagem
invlida, e no pode ser gerada pelo padro de sintaxe do protocolo SIP.

Figura 49 - Mensagem SIP INVITE bem formada

73

Figura 50 - Mensagem SIP INVITE mal formada

Na figura 50, falta o REQUEST-URI, que deve seguir o mtodo
INVITE. Segundo Dagiuklas (2005), quaisquer mensagens no conforme com as
especificaes do protocolo SIP, podem causar falhas em sistemas que utilizam o
Session Initiation Protocol. E, alm disso, altamente complexa a distino entre
mensagens legais e ilegais.

Montando o Ataque de Mensagens Mal Formadas

Dagiuklas (2005) diz que um atacante no possui um mtodo padro
para atacar, e de certo modo o procedimento para realizar este ataque
imprevisvel. Isto tambm, torna-se verdade para os ataques SIP utilizando
mensagens mal formadas. O atacante pode, por exemplo, utilizar o mtodo de
fora-bruta e tentar exaustivamente combinaes de mensagens SIP.
Alternativamente este atacante pode seguir procedimentos gerais, executando
passos algortmicos repetidamente como:

74
1 Descobrir as capacidades do alvo
2 Construir a mensagem mal-formada
3 Testar as possveis combinaes contra o alvo

A vantagem de tal tentativa, que esta no pode ser facilmente
identificada nas suas primeiras fases, pois normalmente, mecanismos de defesa
no esto preparados para tal.

Descobrindo as capacidades do alvo

Antes de lanar o ataque, torna-se necessrio descobrir as
capacidades de um sistema SIP particular. Mensagens de REGISTER e respostas
OPTIONS, so capazes de fornecer informaes sobre qualquer capacidade de um
User Agent. Esta informao includa no cabealho Contact do REGISTER e no
cabealho Alow das respostas s requisies OPTIONS. Em todo caso, estas
mensagens podem ser utilizadas pelo atacante de duas diferentes formas.Na
primeira, o atacante pode simplesmente realizar um sniffing das requisies de
REGISTER no momento da sua realizao. A outra forma, demonstrada no fluxo da
figura 51, simplesmente utilizar a Mensagem de OPTIONS, enviando-a para
vitima, que em resposta, revela ao atacante as capacidades dos mtodos e
mensagens implementadas em seu agente. Estas capacidades reveladas podem
ser, entre outras coisas, o fabricante e a verso implementada no produto da vtima,
expondo as vulnerabilidades existentes.

75

Figura 51 - Descobrindo as capacidades com a requisio OPTIONS

Construindo a Mensagem Mal Formada

O prximo passo a construo da mensagem mal formada, a figura
50 ilustra um exemplo deste tipo de mensagem. A existncia de aplicativos para
testes em sistemas SIP como o PROTOS, que capaz de gerar diferentes tipos de
mensagens mal formadas, torna fcil esta tarefa. Alm disso provvel que o
atacante envie mensagens no implementadas (invalidas ou fora do padro) para
dispositivo da vitima, provocando uma eventual falha crtica. Mensagens de
REGISTER, BYE, CANCEL e outras, tambm podem ser empregadas no ataque.

3.3.2.2 Ataques de REGISTER
Conforme especificao na RFC 3261, a requisio de REGISTER,
pode adicionar ou remover registros de localizaes, ou ainda criar associaes
entre address-of-record e um ou mais endereos de contato. A figura 52 ilustra um
processo de registro onde o Register Server exige a autenticao para todas as
requisies de registro entrantes. Nesta figura, o usurio primeiramente tenta o

76
registro sem as credenciais, e no autorizado pelo Register Server. O Servidor
envia ao User Agent uma resposta contendo a mensagem de no autorizado e um
nmero aleatrio, que deve ser usado pelo UA para gerar a credencial.
Posteriormente o User Agent refaz a requisio de REGISTER, porm, com as
devidas credenciais, obtendo sucesso na sua ao.

Figura 52 - Fluxo normal de registro

Dagiuklas (2005), afirma que um atacante que pretende lanar um
ataque a um servidor Registrar, utilizando mensagens de REGISTER, possui uma
ou mais das seguintes metas:
1 Descobrir a senha de um usurio legitimo.
2 Causar um DoS no servidor.
3 Remover o registro de um usurio legitimo.
A figura 53 ilustra o ataque contra um Registrar Server, onde o
atacante tenta adivinhar a senha do usurio legitimo, ou causar o DoS. Igualmente
o atacante pode tentar remover o registro do usurio, para isto basta fixar o valor do
campo Expires para zero. A execuo distribuda deste ataque tambm possvel,

77
onde mltiplos atacantes tentam descobrir a senha do usurio legitimo.

Figura 53 - Ataque contra um Registrar Server

3.3.2.3 Ataques de CANCEL
A Requisio de CANCEL, utilizada para encerrar o processamento
de um pedido prvio enviado por um cliente. Um atacante pode utilizar a mensagem
de CANCEL para interromper o processamento de um pedido INVITE, encaminhado
por um usurio legitimo, como demonstrado na figura 54. O CANCEL encerra
apenas requisies de INVITE, gerando uma mensagem apropriada de erro se for
enviada para o cancelamento de outro tipo de requisio. Alm disso, pedidos de

78
cancelamento no so processados caso o INVITE inicial tenha obtido uma
resposta final.

Figura 54 - Ataque de CANCEL

3.3.2.4 Fraudes em Respostas SIP
Diversos tipos de ataque de DoS podem ser lanados se o atacante
utilizar as mensagens de resposta SIP. O atacante pode por exemplo, utilizar estas
mensagens agindo como homem-no-meio (man-in-the-middle), ou ainda
personificar um proxy, causando a negao de servio s requisies SIP dos user
agents. A figura 55, resume algumas mensagens de erro utilizadas para lanar o
ataque de DoS.

79
Cdigo Descrio
3xx A resposta pode conter um ou mais campos Contact com endereos
onde o destinatrio pode ser encontrado
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
4xx Respostas de falha do servidor
400 Bad Request
401 Unauthorized
403 Forbidden
405 Method Not Allowed
406 Not Acceptable
408 Request Timeout
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
420 Bad Extension
480 Temporarily Unavailable
404 Not Found
5xx Falha no Servidor
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
6xx Falhas Globais
600 Busy Everywhere
606 Not Acceptable
Figura 55 - Cdigos de erros comuns
3.3.3 Ataques a sistemas com a autenticao aplicada (aps a autenticao)
A infra-estrutura VoIP, baseada no protocolo SIP, prov servios
similares ao e-mail. Assim, muitos provedores de servio, podem permitir o livre
registro, sem a checagem de credenciais. Isso facilita a ao dos atacantes, pois
estes podem registrar-se como usurios regulares, permitindo que os ataques

80
possam ser originados de dentro do sistema. Outra possibilidade para atacante
inserir-se na base de usurios regulares para realizar ataques, assumir um SIP
Registrar, ou configurar um ou mais novos servidores, com usurios utilizados
apenas para ataques. A primeira possibilidade torna-se complicada se o Servidor
possuir mecanismos de segurana adicionais, a segunda opo menos complexa.
Porm, a provedora do servio, pode bloquear qualquer tipo de origem
desconhecida, assim estas possibilidades seriam descartadas. Mesmo existindo
grandes barreiras para o atacante conseguir uma base de usurios registrada e
lanar o ataque de dentro da rede, este ainda possvel. Estando dentro da rede, o
atacante tem grandes possibilidades de obter sucesso com o ataque.

3.3.3.1 Ataque de Fora Bruta

Dentro da estrutura SIP, ataques de Bruta podem ser lanados atravs
de mensagens com o contedo no reconhecido, requisitando uma extenso
extica ou contendo tipos desconhecidos no corpo da mensagem. A entidade SIP
tem que processar estas mensagens e responder com mensagens de erro,
consumindo os recursos de processamento. O atacante pode tambm modificar o
valor do campo Route que identifica o host alvo, e ento enviar a mensagem forjada
para vrios elementos da SIP da rede, na inteno de gerar um DoS flood traffic, ou
negao de servio por inundao de trfego. Outro exemplo o ataque de Relay,
que pode ser lanado criando-se falsos pedidos, onde o IP de origem e o Valor do
campo Via so falsificados, identificando o alvo como real originador da requisio.
E ento esta requisio, enviada para um grande nmero de elementos da rede
como telefones SIP.

81
3.3.3.2 Unusable Destinations (Destinos Inteis)

A adio maliciosa de endereos insolveis ou no correspondentes
em mensagens SIP, foram o proxy a repassar esta mensagem a um endereo que
no pode ser resolvido. Administradores dos servidores SIP, devem estar atentos
ao impacto das operaes do servidor de DNS. As tentativas pelos UACs de
resolverem um grande fluxo de endereos insolveis podem degradar o
desempenho do servidor, resultando no DoS. O proxy gera requisies continuas ao
DNS, na tentativa de resolver o nome inexistente. Normalmente o atacante produz
grandes quantidades de nomes insolveis ou falsos INVITES. O objetivo do
atacante sobrecarregar a rede com mensagens do DNS, provocando srios
problemas ao servio VoIP.

3.3.3.3 Ataques de INVITE

Dagiuklas (2005) explica que um elemento SIP torna-se mais
vulnervel se este necessitar de manter seu estado por certo perodo, como o
caso do processo de INVITE. Um exemplo quando um UAC precisa retransmitir
um INVITE, caso este no obtenha resposta at no mximo em 32s. Durante este
perodo, o UAC mantm seu estado de INVITE, necessitando manter este estado
para outros 32s aps o encaminhamento das respostas de 3xx e 6xx. A figura 56
demonstra o fluxo de um ataque usando mensagens de INVITE, onde o atacante
constri as mensagens sem receber nenhuma resposta, realizando um flooding de
INVITE. Como resultado final desta inundao de requisies tem-se o DoS.

82

Figura 56 - flooding de INVITE

83
4 MECANISMOS DE SEGURANA

Como a troca das mensagens SIP herdou o modelo de requisio e
resposta do HTTP, todos os mecanismos de segurana disponveis para o HTTP
podem ser aplicados s sesses SIP. Por outro lado, a utilizao de container MIME
dentro das mensagens SIP, sugere o potencial uso de mecanismos de segurana
de e-mail, como PGP ou S/MIME. E claro, similar ao https: URI, o correspondente
sips: URI tentar construir um tnel seguro na camada de transporte usando TLS. E
no menos importante o IP Security (IPsec), que pode ser usado como mecanismo
de encriptao de toda comunicao baseada em IP na camada de rede. Os
principais mecanismos de segurana destinados ao SIP esto relacionados na
figura 57. Estes mecanismos coincidem com lista de recomendaes de segurana
da verso 1 do SIP. Enquanto isto, dois dos mtodos: HTTP basic Authentication, e
PGP foram descartados pela verso 2 do Session Initialization Protocol. Segundo a
RFC 3329, definida uma nova funcionalidade de negociao para mecanismos de
segurana entre um agente usurio SIP e o prximo hop SIP. Esta funcionalidade
complementa outras j existentes para o SIP. So criados 3 novos campos de
cabealho SIP: Security-Client, Security-Server e Security Verify; e tambm definida
uma lista de mecanismos de segurana suportados:
tls para TLS
digest para http Digest
ipsec-ike para IPsec com IKE
ipsec-man para IPsec sem IKE.
4.1 HTTP Basic Authentication
HTTP basic authentication requer a transmisso do nome de usurio e
a senha embutida no cabealho do pedido HTTP. Includo nos pedidos SIP, este
nome de usurio pode ser usado por um SIP proxy Server ou um User Agent para
autenticar um cliente SIP ou um "SIP hop", na cadeia de proxy. Sendo a senha um

84
texto puro, que pode ser facilmente capturada por um sniffer, torna-se um risco a
segurana, por isso o uso do HTTP basic authentication foi descartado na verso 2
do SIP (SIPv2).
Mtodos de autenticao:

PSK Pre-shared keys
(chaves pre-definidas)

PKI Public key infraestructure
(infra-estrutura de chave pblica)
A
u
t
e
n
t
i
c
a
o

I
n
t
e
g
r
i
d
a
d
e

d
o
s

d
a
d
o
s

C
o
n
f
i
d
e
n
c
i
a
l
i
d
a
d
e

Descrio
HTTP 1.0 Basic Authentication PSK - -
Desaconselhado pelo
SIPv2 - insegurana na
transmisso da senha.
HTTP 1.1 Digest Authentication PSK

Hash da senha baseado
em no mtodo MD5.
Pretty Good Privacy (PGP) PKI

Desaconselhado pelo
SIPv2.
Secure MIME (S/MIME) PKI

Para encriptao a chave
pblica do UA deve ser
conhecida.
SIPS URI (TLS) PKI

Aplicaes SIP e proxy
devem usar TLS.
IP Security (IPsec) PKI

Integrao com a
aplicao SIP no
requerida, mas proxies
devem ser confiveis.
Figura 57 - Principais mecanismos de segurana para o SIP
4.2 HTTP Digest Authentication
O HTTP Digest Authentication corrige as deficincias do HTTP Basic
Authentication, transmitindo um hash MD5 ou SHA-1 da senha secreta e de uma
string aleatria, no lugar onde iria apenas a senha vulnervel. Apesar de este
mtodo garantir a identidade do usurio sem a necessidade da transmisso da
senha pura, o procedimento ainda pode ser vulnervel a ataques de dicionrio,
baseados em valores hash interceptados, sendo facilitado se as senhas utilizadas
forem fracas. Outra grande desvantagem, e a falta de um mecanismo para prover a
confidencialidade, e alem disso, esta tcnica no garante a integridade das
mensagens SIP. As figuras 58 e 59 mostram como uma requisio SIP INVITE

85
originada do usurio Alice autenticada pelo proxy usando o HTTP Digest
Authentication.
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>;tag=3b6c2a3f
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 1 INVITE
Proxy-Authenticate: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch"
Content-Length: 0
Figura 58 - Confirmao do INVITE pelo proxy

O primeiro proxy recebe o SIP INVITE de Alice e imediatamente
responde com uma confirmao, mostrada na figura 58. A confirmao contm um
nonce aleatrio e define o algoritimo hash a ser utilizado, (geralmente MD5 ou SHA-
1), bem como o domnio o qual o usurio deve fornecer a autenticao. Assim que
recebe a confirmao, Alice reenvia o INVITE original, porm insere no cabealho
da resposta a confirmao, como mostrado na figura 59.
INVITE sip:bob@zhwin.ch SIP/2.0
Via: SIP/2.0/UDP 160.85.170.139:5060;branch=z9hG4bK4129d28b8904
To: Bob <sip:bob@zhwin.ch>
From: Alice <sip:alice@zhwin.ch>;tag=daa21162
Call-ID: 392c3f2b568e92a8eb37d448886edd1a@160.85.170.139
CSeq: 2 INVITE
Proxy-Authorization: Digest algorithm=MD5,
nonce="1058800787",
realm="zhwin.ch",
response="142311a910a4d57ba49afdbe5646768c",
uri="sip:bob@zhwin.ch",
username="alice"
Max-Forwards: 70
Contact: <sip:alice@dskt6816.zhwin.ch:5060>
Content-Length: 239

Figura 59 - INVITE original com a confirmao

O valor da resposta consiste na compilao MD5 do nome do usurio,
da senha secreta, do valor contido no nonce, do mtodo SIP e do URI requisitado.
Assim a senha clara no transmitida, mas deve ser conhecida pelo servidor proxy
afim de poder verificar a autenticao.

86
4.3 Pretty Good Privacy (PGP)
O PGP pode ser potencialmente usado para autenticar e
opcionalmente, encriptar MIME payloads, contidos nas mensagens SIP. Porm a
verso 2 do SIP desaprova o uso do PGP em favor do S/MIME.
4.4 Secure MIME (S/MIME)
Mensagens SIP carregam estruturas MIME, e padres MIME incluem
mecanismos para segurana de seu contedo, assegurando tanto a integridade
quanto a confidencialidade. O objetivo do S/MIME a interoperabilidade de
mensagens seguras, obtida pela criptografia e assinatura digital. A segurana
fornecida apenas no cliente S/MIME, os servidores no precisam ser modificados. O
S/MIME o resultado da integrao de trs padres j estabelecidos:
MIME - Multi-purpose Internet Mail Extension, especificado na RFC 1521;
Criptographic Message Syntax Standard (PKCS#7);
Certification Request Syntax Standard (PKCS#10).
O S/MIME aceita os tipos de contedo PKCS#7 listados na Figura 60.
Nota: Todas as funes de criptografia exigem que o cliente/servidor tenham, pelo
menos, um certificado vlido.
Tipo de Contedo Descrio
Dados Contedo trabalhado com algum tipo de segurana
Dados Assinados
Uma mensagem MIME assinada digitalmente, um
certificado ou uma informao de revogao (CRL)
Dados Assinados e
Envelopados
Mensagem MIME assinada e criptografada. Requer
acesso a chave pblica da entidade de origem
Dados Envelopados
Mensagem MIME criptografada. Requer acesso a
chave pblica da entidade de origem
Figura 60 - Tipos de Contedo S/MIME

O S/MIME aceita os seguintes algoritmos de criptografia, modos e
tamanhos de chave:
Triple DES, modo CBC com chave de 168 bits;
RC2, modo CBC com chave de 128 bits;

87
DES, modo CBC com chave de 56 bits;
RC2, modo CBC com chave de 64 bits;
RC2, modo CBC com chave de 40 bits.

O S/MIME tambm compatvel com os seguintes algoritmos de hash:
MD5
SHA-1
Os retardos introduzidos pelos processos de segurana no so
significativos. Uma mensagem assinada requer apenas que a entidade de origem
tenha um certificado vlido. A entidade de destino recebe o certificado da origem
como parte da mensagem e, se implementar o S/MIME, utiliza a chave pblica para
reconhecer a assinatura. O certificado armazenado no receptor para possibilitar a
privacidade (criptografia) das prximas mensagens. O processo de privacidade e
integridade de mensagens obedece aos seguintes passos na entidade de origem:
1. Calcular uma amostra (hash) do contedo da mensagem
2. Criptografar o hash com a sua chave privada para criar uma
assinatura digital
3. Criptografar o contedo da mensagem e a assinatura digital com uma
chave simtrica randmica
4. Criptografar a chave simtrica com a chave pblica da entidade de
destino
5. Remeter o resultado dos passos 3 e 4 usando um meio de transporte
A entidade receptora deve executar os seguintes procedimentos:
1. Receber a mensagem utilizando um meio de transporte tradicional.
2. Decriptar, com a chave simtrica, o contedo da mensagem e a
assinatura digital
3. Decriptar o hash recebido usando a chave pblica do remetente
4. Validar a assinatura digital calculando o hash da mensagem e
comparando com recebido

88
5. Validar o certificado do remetente
Se a entidade de origem utilizou um certificado incorreto, a mensagem
no pode ser recuperada pelo destino.
4.5 SIPS URI (TLS)
O TLS (Transport Layer Security), definido pela RFC 2246, prove uma
camada de transporte seguro sobre TCP. O uso de URI SIP sobre a forma de
sips:bob.biloxy.com em uma mensagem de INVITE, requer o uso de TLS em todo o
caminho ate o destino. Desde que cada hop possa adicionar informaes de rota ao
cabealho da mensagem SIP, a proteo TLS deve ser realizada hop-by-hop (em
cada salto) do caminho. O uso do TLS requer o TCP como o protocolo de transporte
(TCP/SIP) e necessita de uma infra-estrutura de chave pblica. A figura 61 ilustra a
negociao com um servidor TLS.

Figura 61 - Negociao com servidor TLS

89
4.6 IP Security (IPsec)
O IPsec um mecanismo de propsito geral que pode ser usado para
proteger mensagens SIP na camada de rede. Devido exigncia de que cada
servidor proxy deve ter acesso de leitura e escrita ao cabealho SIP, IPsec ESP
(Encapsulating Security Payload) ou AH (Authentication Header) no modo de
transporte, deve ser aplicado hop-by-hop (em cada salto). O protocolo Internet Key
Exchange (IKE), suporta tanto autenticaes baseadas em Pre-Shared Key (PSK)
quanto Public Key (PKI). Pelo fato dos endereos IPs dos SIP UAs serem
principalmente dinmicos, e levando-se em conta de que o modo principal IKE
neste caso no trabalha com chaves Pre-Shared e o modo agressivo IKE possui
problemas de segurana que possibilitam a ataques como: man-in-the-middle e off-
line dictionary sobre PSK, a autenticao baseada em chave pblica deve ser o
mtodo utilizado, isto significa que o estabelecimento da confiana global no
certificado X.509 torna-se problemtico.

4.7 Segurana sobre protocolos de transporte em tempo real
O Fluxo de pacotes multimdia transportado utilizando o protocolo de
transporte em tempo real RTP (Real Time Transport Protocol) baseado em UDP.
Para que possa haver alguma avaliao em relao qualidade do fluxo de pacote
recebido, periodicamente enviado de volta um relatrio usando o RTCP (Real-
Time Control Protocol). Sendo a conexo de udio e o vdeo em tempo real muito
sensvel a atrasos e variaes deste atraso (jitter), qualquer algoritmo de
encriptao e autenticao no devem influenciar significativamente estes
parmetros. Devido a tais restries, o pr-requisito fundado para transmisses em
tempo real que esta seja sobre UDP. Apenas dois mecanismos de segurana,
listados na figura 62, esto atualmente disponveis.

90
Mtodos de autenticao:

PSK Pre-shared keys
(chaves pre-definidas)

PKI Public key infraestructure
(infra-estrutura de chave pblica)
A
u
t
e
n
t
i
c
a
o

I
n
t
e
g
r
i
d
a
d
e

d
o
s

d
a
d
o
s

C
o
n
f
i
d
e
n
c
i
a
l
i
d
a
d
e

Descrio
Secure RTP (SRTP) PSK

As chaves de
usurios devem ser
distribudas por
outros meios.
IP Security (IPsec) PKI

Integrao com o SIP
no requerida, mas
o peer deve ser
confivel.
Figura 62 - Soluo para segurana Real-Time Media Streams

4.7.1 Secure RTP (SRTP)
O SRTP (Secure Real-time Transport Protocol), uma extenso do
RTP, e disponibiliza confidencialidade, autenticao da mensagem e proteo
contra replay de trfego RTP e RTCP. O uso da criptografia AES cipher, sendo
executada em modo de cifra de fluxo (stream cipher mode), garante uma forte
segurana e no incrementa o tamanho do pacote encriptado. A tag de
autenticao, adiciona 10 bytes para cada pacote RTP/RTCP, mas pode ser
reduzido para 4 bytes, se a banda utilizada para comunicao for estreita.
4.7.2 IP Security (IPsec)
Como uma alternativa, os real-time payloads, podem ser protegidos na
camada de rede pelo IPsec, usando a mesma associao de segurana j
negociada para proteger as mensagens SIP entre os UAs. Uma grande
desvantagem desta tcnica o grande overhead introduzido pela encapsulao
ESP, podendo chegar a 37bytes por pacote IPsec para a encriptao 3DES,
aumentando para 53 bytes se a encriptao for a AES.

91
5 CONCLUSES
Este captulo trata das concluses obtidas a partir da pesquisa
realizada, e finalmente oferece propostas e sugestes de trabalhos futuros que
transpareceram-se no decorrer do desenvolvimento deste documento.

5.1 Consideraes Finais

A pesquisa realizada demonstrou a importncia do protocolo SIP no
cenrio atual das comunicaes mundiais, em especial a sua utilizao no servio
de VoIP, bem como os desafios a serem superados no que diz respeito a segurana
em sistemas que fazem uso do protocolo SIP. Neste trabalho faz-se uma
abordagem das vulnerabilidades existentes em implementaes do SIP,
vulnerabilidades estas, que coloca em risco os sistemas de comunicao baseados
neste protocolo.
Foi demonstrado o funcionamento do SIP, enfatizando o fluxo de
mensagens da sua sinalizao, detalhando com exemplos, seus vrios mtodos de
requisies e respectivas respostas. Alem disso, demonstrou-se a arquitetura SIP, e
o papel desempenhado por cada componente dentro desta arquitetura.
Abordou-se, tambm, algumas diferenas entre o SIP e o H.323, um
outro protocolo utilizado para sinalizao, que aos poucos cede espao para o
Session Initiation Protocol.
O Capitulo 3 detalha as vulnerabilidades do SIP, falhas que
comprometem a continuidade do negcio, afetando os pilares da segurana. Neste
captulo exemplificado alguns dos possveis ataques a componentes da
arquitetura, e seus resultados.
Por fim, so mencionados alguns mtodos utilizados para promover a
segurana no protocolo SIP.
Estima-se um grande investimento e crescimento na convergncia

92
para a tecnologia de VoIP, devido as suas grandes vantagens, a principal no que
diz respeito a economia. Porm mais do que a significativa reduo dos custos
interessante discutir a questo da segurana da informao, e assim confirmar a
grande tendncia: a maturidade da Voz sobre IP.
Em geral a opo pelo servio de VoIP, so focadas em fatores
ligados a economia e eficincia, como disponibilidade, latncia e QoS,
negligenciando a proteo do sistema.
No centro desta convergncia encontra se o protocolo SIP,
responsvel por gerir as sesses multimdias, como a de VoIP.O SIP, um protocolo
emergente, de arquitetura simples, aberta, e que aos poucos torna-se maduro o
suficiente para atrair as atenes e afirmar-se como o protocolo padro das
comunicaes mundiais. Porem, por basear-se em redes IP, o SIP herda destas
suas j exploradas vulnerabilidades e tambm, expem novas especficas de sua
arquitetura. A divulgao, documentao e estudo destas vulnerabilidades torna-se
importante para evoluo dos mtodos de segurana aplicados a esta nova
tendncia das comunicaes.
Enfim, toda nova aplicao exige uma fase cuidadosa de anlise de
riscos, qualquer tecnologia adicionada, traz novas vulnerabilidades alm dos
benefcios. essencial tornar a segurana um dos pr-requisitos para as adoo
de qualquer tecnologia, e no fazer da segurana, um empecilho para evoluo de
tais avanos.
5.2 Propostas para Trabalhos Futuros
Implementao e teste de uma tecnologia ou metodologia para garantir a
segurana ou reduzir os riscos de ataques a sistemas que utilizam
sinalizaes do protocolo SIP.
Criao de um documento de implementao de um PBX IP baseado no
software livre ASTERISK.

93
Implementao de segurana em PBX IP ASTERISK.
Continuidade do documento produzido, demonstrando novas vulnerabilidades
ataques a arquitetura SIP.

94
6 REFRNCIAS BIBLIOGRFICAS
CAMARILLO, Gonzalo. SIP Demytified. Finlndia: McGraw-Hill Inc, 2001. 320 p.
CHECK POINT SOFTWARE AND TECHNOLOGIES. Security IP Telephony For The
Enterprise, 2004, 17 p.
CIO REVISTA. Disque VoIP para Vulnerabilidades, 2004. Disponvel em:
http://ciomagazine.uol.com.br/revista/2006/01/30/idgnoticia.2006-01-
30.1195711369/IDGNoticia_view. Acesso em: 23 abr. 2006.
COLCHER, Sergio. et al. VOIP: Voz Sobre IP. 1.ed. Rio de Janeiro: Campus, 2005.
300p.
COOLIER, Mark. Basic Vulnerabilities Issues for SIP Security. San Antonio, Texas,
Secure Logix Corporation, 2005. 9 p. Apostila.
DAGIUKLAS, Tasos. et al. Low Cost Tools for Secure and Highly Available VoIP
Communication Services. SNOCER (2005) 74p.

DAVID, Joo P.; PEREIRA, Silva G. Voz Sobre IP. Lisboa, Universidade de Lisboa,
2005, 136p.
DHAMANKAR, Rohit. Intrusion Prevention: The Future of VoIP Security. Tipping
Point Technologies (2004), 12p.
HERSENT, Oliver; GURLE, David; PETIT, Jean-Pierre. Telefonia IP:
Comunicao,multimdia baseada em pacotes. So Paulo: Makron Books, 2001. 451
p.
HOCHMUTH, Phil. SIP weakness could expose VoIP gear to attacks, 2003,
Disponvel em: http://www.networkworld.com/news/2003/0224sip.html?page=1.
Acesso em: 31 jul. 2006.
JOHNSTON, Alan B. SIP: Understanding the Session Initiation Protocol. 2.ed. s.l.:
Artech House, 2003, 283p.
LAZARINI, Otvio. (2006) SIP Ganhando Fora. In ALICE RAMOS.COM, 2006,
Disponvel em: http://www.aliceramos.com/view.asp?materia=995. Acesso em: 23
abr. 2006.
STEVENS, David. Ataque hacker de telefonia cresce na Austrlia, 2005, Disponvel
em:
http://worldtelecom.uol.com.br/AdPortalv5/adCmsDocumentShow.aspx?GUID=EC5A
D31B-1038-4FAC-A356-260F4844F2A3&ChannelID=4. Acesso em:31 jul. 2006.
TAKAKEN, Ari. Ameaas, Vulnerabilidades e Ataques na Voice over IP. In: IP VOICE
MEETING, 2006, Lisboa. : IP VOICE MEETING 2006: Disponvel em:
http://www.ipvoice2006.com/. Acesso em: 15 abr. 2006.

95
YOSHIOKA, Sergio. Aspectos de Segurana para Telefonia IP utilizando o Protocolo
SIP. Campinas: UNICAMP, 2003, 75p.

Monografia SIP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monografia SIP

Uploaded by

Copyright:

Available Formats

UNIO EDUCACIONAL MINAS GERAIS S/C LTDA

FACULDADE DE CINCIAS APLICADAS DE MINAS

You might also like