Open TCB13 opened 4 years ago
Tentei fazer o que descrevi e para além de ser possível interceptar o tráfego do Thomson com o Wireshark de nada serve. Infelizmente o protocolo SIP faz um hash da password do VOIP. Se quiserem saber detalhadamente como funciona está aqui: https://nickvsnetworking.com/reverse-md5-on-sip-auth/
Confirmei com o meu Thomson e existe um pedido REGISTER
que é recusado (401) e que apenas serve para que o servidor responda com um header WWW-Authenticate
que contem um Nonce
utilizado de seguida pelo router para calcular o response
a ser incluído no próximo pedido REGISTER
.
Primeiro pedido com o header:
Frame 5: 526 bytes on wire (4208 bits), 526 bytes captured (4208 bits) on interface \Device\NPF_{CCA4E935-BE95-###################}, id 0
Ethernet II, Src: TiMetraN_00:###### (00:###########), Dst: Technico_######## (10:############)
Internet Protocol Version 4, Src: 213.xxx.xxx.xxx, Dst: 85.xxx.xxx.xxx
User Datagram Protocol, Src Port: 5070, Dst Port: 5060
Session Initiation Protocol (401)
Status-Line: SIP/2.0 401 Unauthorized 010300337
Message Header
From: <sip:+35121--------@sip.sapo.pt:5060>;tag=14e9660-55f3aa8f-13c4-##########
SIP from address: sip:+35121--------@sip.sapo.pt:5060
SIP from tag: 14e9660-55f3aa8f-13c4-##########
To: <sip:+35121--------@sip.sapo.pt:5060>;tag=0879afb############
SIP to address: sip:+35121--------@sip.sapo.pt:5060
SIP to tag: 0879afb############
Call-ID: 14f2fd0-55f3aa8f-#############
[Generated Call-ID: 14f2fd0-55f3aa8f-#############]
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 85.xxx.xxx.xxx:5060;branch=z9hG4bK-#########
Content-Length: 0
WWW-Authenticate: Digest nonce="FF900000000000000000000000000000",realm="ims.telecom.pt",algorithm=MD5,qop="auth"
Authentication Scheme: Digest
Nonce Value: "FF900000000000000000000000000000"
Realm: "ims.telecom.pt"
Algorithm: MD5
QOP: "auth"
Segundo pedido de autenticação com o response
baseado no nonce
anterior:
Frame 6: 828 bytes on wire (6624 bits), 828 bytes captured (6624 bits) on interface \Device\NPF_{CCA4E935-BE95-###################}, id 0
Ethernet II, Src: Technico_19 (10:############), Dst: TiMetraN_00:###### (00:###########)
Internet Protocol Version 4, Src: 85.xxx.xxx.xxx, Dst: 213.xxx.xxx.xxx
User Datagram Protocol, Src Port: 5060, Dst Port: 5070
Session Initiation Protocol (REGISTER)
Request-Line: REGISTER sip:sip.sapo.pt:5060;transport=UDP SIP/2.0
Message Header
From: <sip:+35121--------@sip.sapo.pt:5060>;tag=14e9660-55f3aa8f-13c4-##########
SIP from address: sip:+35121--------@sip.sapo.pt:5060
SIP from tag: 14e9660-55f3aa8f-13c4-##########
To: <sip:+35121--------@sip.sapo.pt:5060>
SIP to address: sip:+35121--------@sip.sapo.pt:5060
Call-ID: 14f2fd0-55f3aa8f-#############
[Generated Call-ID: 14f2fd0-55f3aa8f-#############]
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 85.xxx.xxx.xxx:5060;branch=z9hG4bK-61-10000-#######
Max-Forwards: 70
Supported: replaces,100rel
User-Agent: Technicolor TG784n v3 Build 10.2.1.O
Expires: 3600
[truncated]Authorization: Digest username="+35121--------",realm="ims.telecom.pt",nonce="FF900000000000000000000000000000",uri="sip:sip.sapo.pt:5060;transport=UDP",response="5ae00000000000000000000000000000",algorithm=MD5,cnonce="10000",q
Authentication Scheme: Digest
Username: "+35121--------"
Realm: "ims.telecom.pt"
Nonce Value: "FF900000000000000000000000000000"
Authentication URI: "sip:sip.sapo.pt:5060;transport=UDP"
Digest Authentication Response: "5ae00000000000000000000000000000"
Algorithm: MD5
CNonce Value: "10000"
QOP: auth
Nonce Count: 00000001
Contact: <sip:+35121--------@85.xxx.xxx.xxx:5060>
Contact URI: sip:+35121--------@85.xxx.xxx.xxx:5060
X-Serialnumber: CP1650SATLQ
[Expert Info (Note/Undecoded): Unrecognised SIP header (x-serialnumber)]
[Unrecognised SIP header (x-serialnumber)]
[Severity level: Note]
[Group: Undecoded]
Content-Length: 0
Pronto é isto, se alguém tiver ideias de como crakear isso são bem vindas.
Aproveito para mais uma vez referir a questão de "nivelamento de conhecimento" recorrente em Portugal. Os comentários que se leem em foruns como o zwame quando alguém tenta fazer alguma coisa são uma simples demonstração da mentalidade tuga. Se não sabem como as coisas funcionam, se não querem ajudar etc fiquem calados. O mesmo se aplica aos moderadores que apagam publicações com justificações de algibeira...
Solução: Fazer reset ao router enquanto se intercepta o tráfego com o Wireshark. Eventualmente o router irá receber um XML com a configuração do VOIP.
Frame 22232: 527 bytes on wire (4216 bits), 527 bytes captured (4216 bits) on interface \Device\NPF_{CCA4E935-xxxxxxxxxxxxxxx}, id 0
Ethernet II, Src: TiMetraN_00:00:01 (00:03:xxxxxxxx), Dst: Technico_19:81:2c (10:13:xxxxxxxxxxx)
Internet Protocol Version 4, Src: 213.xxxxxxxx, Dst: 85.xxxxxxxx
Transmission Control Protocol, Src Port: 17013, Dst Port: 4159, Seq: 3813, Ack: 3823, Len: 473
[3 Reassembled TCP Segments (3393 bytes): #22230(1460), #22231(1460), #22232(473)]
Hypertext Transfer Protocol
eXtensible Markup Language
<soapenv:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:cwmp="urn:dslforum-org:cwmp-1-0"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<cwmp:ID
soapenv:mustUnderstand="1">
100000000
</cwmp:ID>
</soapenv:Header>
<soapenv:Body>
<cwmp:SetParameterValues>
<ParameterList
soap:arrayType="cwmp:ParameterValueStruct[10]">
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxy
</Name>
<Value
xsi:type="xsd:string">
proxy.ims.iptv.telecom.pt
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxyPort
</Name>
<Value
xsi:type="xsd:unsignedInt">
5070
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServer
</Name>
<Value
xsi:type="xsd:string">
sip.sapo.pt
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServerPort
</Name>
<Value
xsi:type="xsd:unsignedInt">
5060
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Name
</Name>
<Value
xsi:type="xsd:string">
proxy.ims.iptv.telecom.pt
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrationPeriod
</Name>
<Value
xsi:type="xsd:unsignedInt">
3600
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName
</Name>
<Value
xsi:type="xsd:string">
+35121xxxxxxxx
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword
</Name>
<Value
xsi:type="xsd:string">
XXXXXXXXX
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.URI
</Name>
<Value
xsi:type="xsd:string">
+35121xxxxxxxx
</Value>
</ParameterValueStruct>
<ParameterValueStruct>
<Name>
InternetGatewayDevice.Time.LocalTimeZoneName
</Name>
<Value
xsi:type="xsd:string">
(UTC)
</Value>
</ParameterValueStruct>
</ParameterList>
<ParameterKey>
100000000
</ParameterKey>
</cwmp:SetParameterValues>
</soapenv:Body>
</soapenv:Envelope>
Como podem ver no XML é enviado o SIP.AuthUserName
e o SIP.AuthPassword
que são os vossos dados de acesso.
Depois podem configurar no MicroSIP da seguinte forma:
Chamo especialmente à atenção para o valor do Register Refresh
que convém ser igual ao que a MEO envia no XML. Já o Publish Presence
só deverá ser ligado se não tiverem telefone físico porque interfere com o mesmo (deixa de tocar).
Boas tardes.
Excelente artigo. estou a analisar nos routers da nos, será que é idêntico o processo?
Entretanto há novos desenvolvimentos acerca deste topico?
Desde já, muito obrigado
Solução: Fazer reset ao router enquanto se intercepta o tráfego com o Wireshark. Eventualmente o router irá receber um XML com a configuração do VOIP.
Frame 22232: 527 bytes on wire (4216 bits), 527 bytes captured (4216 bits) on interface \Device\NPF_{CCA4E935-xxxxxxxxxxxxxxx}, id 0 Ethernet II, Src: TiMetraN_00:00:01 (00:03:xxxxxxxx), Dst: Technico_19:81:2c (10:13:xxxxxxxxxxx) Internet Protocol Version 4, Src: 213.xxxxxxxx, Dst: 85.xxxxxxxx Transmission Control Protocol, Src Port: 17013, Dst Port: 4159, Seq: 3813, Ack: 3823, Len: 473 [3 Reassembled TCP Segments (3393 bytes): #22230(1460), #22231(1460), #22232(473)] Hypertext Transfer Protocol eXtensible Markup Language <soapenv:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header> <cwmp:ID soapenv:mustUnderstand="1"> 100000000 </cwmp:ID> </soapenv:Header> <soapenv:Body> <cwmp:SetParameterValues> <ParameterList soap:arrayType="cwmp:ParameterValueStruct[10]"> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxy </Name> <Value xsi:type="xsd:string"> proxy.ims.iptv.telecom.pt </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.OutboundProxyPort </Name> <Value xsi:type="xsd:unsignedInt"> 5070 </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServer </Name> <Value xsi:type="xsd:string"> sip.sapo.pt </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrarServerPort </Name> <Value xsi:type="xsd:unsignedInt"> 5060 </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Name </Name> <Value xsi:type="xsd:string"> proxy.ims.iptv.telecom.pt </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.RegistrationPeriod </Name> <Value xsi:type="xsd:unsignedInt"> 3600 </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName </Name> <Value xsi:type="xsd:string"> +35121xxxxxxxx </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword </Name> <Value xsi:type="xsd:string"> XXXXXXXXX </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.URI </Name> <Value xsi:type="xsd:string"> +35121xxxxxxxx </Value> </ParameterValueStruct> <ParameterValueStruct> <Name> InternetGatewayDevice.Time.LocalTimeZoneName </Name> <Value xsi:type="xsd:string"> (UTC) </Value> </ParameterValueStruct> </ParameterList> <ParameterKey> 100000000 </ParameterKey> </cwmp:SetParameterValues> </soapenv:Body> </soapenv:Envelope>
Como podem ver no XML é enviado o
SIP.AuthUserName
e oSIP.AuthPassword
que são os vossos dados de acesso.Depois podem configurar no MicroSIP da seguinte forma:
Chamo especialmente à atenção para o valor do
Register Refresh
que convém ser igual ao que a MEO envia no XML. Já oPublish Presence
só deverá ser ligado se não tiverem telefone físico porque interfere com o mesmo (deixa de tocar).
Boas. Sei que já passaram quase 3 anos desde o post inicial, mas não tens porventura mais informação sobre a forma como o Thomson pede a configuração ao operador? Pelos vistos parece-me uma simples request HTTP onde deve ir algum tipo de identificação do cliente, e depois o servidor responde com um XML com as configurações do router associadas a esse cliente. Se se descobrir o servidor para o qual o router envia essa request HTTP, seria possível obter o tal XML com as configurações de forma muito mais simples (sem sniffar tráfego, nem sequer ter de ligar o Thomson).
Cumps, JSilva
não tens porventura mais informação sobre a forma como o Thomson pede a configuração ao operador? (...) Pelos vistos parece-me uma simples request HTTP (...) Se se descobrir o servidor para o qual o router envia essa request HTTP, seria possível obter o tal XML com as configurações de forma muito mais simples
A configuração é entregue/feita por TR-069 que para além de ser HTTP requer um processo de negociação em várias chamadas que poderá ter "efeitos secundários".
Podes tentar analisar o trafego todo que ele fez e repetir isso, chamar os endpoints certos com os pedidos mas suspeito que do lado deles sejam geradas certas chaves que depois inviabilizam a configuração instalada no Thomson. Experimenta e partilha :)
Boas noites, alguem sabe se isto ainda funciona e se é possivel nos routers mais recentes, neste caso o Fibergateway que já tem o ONT embutido? As passwords sao coisas random ou será alguma combinação de certos dados de cliente? Nao sei s isto é da vossa autoria https://tadeubento.com/2020/meo-voip-telefone-fixo-no-computador/ mas creio que é o mesmo metodo\tutorial (mas apenas para o Thomson)
Boas noites, alguem sabe se isto ainda funciona e se é possivel nos routers mais recentes, neste caso o Fibergateway que já tem o ONT embutido? Nao sei s isto é da vossa autoria https://tadeubento.com/2020/meo-voip-telefone-fixo-no-computador/ mas creio que é o mesmo metodo\tutorial (mas apenas para o Thomson)
É da minha autoria e como disse logo no início do artigo é outros já disseram não é possível no Fibergateway.
As passwords sao coisas random ou será alguma combinação de certos dados de cliente?
A password continua a ser random, o processo de configuração do Fibergateway continua a ser por TR-069 tal como o Thomson, a diferença é que não tens como interceptar o tráfego porque é all in one.
Boas, Obrigado pela tua partilha, é deveras interessante.
Há uns anos fiz algo parecido quando era possível aceder ao configfile do technicolor v3.
A pass do voip aparecia no configfile embora cifrada. O que fiz foi nas configs de dns dinâmico, criar uma configuração genérica manualmente em que mandava registar o dns num ip meu a correr apache e um logger. As autenticações em servers de dns dinâmico são feitas por norma em plain text, então depois de ter o dns dinâmico criado, editei o config file e copiei a hash da pass do voip para a do dns dinâmico que tinha criado.
O router ao tentar registar o ip no dns dinâmico tentou autenticar com o username que lá defini e com a pass do voip em plain text. Desse modo fiquei a sabê-la, visto que a tentativa de autenticação ficou guardada no logger.
Ainda hoje uso a mesma pass e a razão de estar aqui a postar é porque há muito pouca gente a fazer isto que nós estamos a fazer, pelo menos na meo devido a não ser muito simples conseguir a pass do voip ims deles.
Eu uso router draytek a gerir tudo há mais de 10 anos, sensivelmente desde que eles passaram para single edge e meteram tudo a trabalhar por dentro da mesma vlan.
Acontece que, não sei bem porquê, há uns meses para cá (praí desde abril ou maio.. ou sensivelmente desde que eles acabaram com os voip nomadas (3020xxx)), deixei de receber a informação com a identificação do caller ID.
Todas as chamadas que recebo aparece-me nos telefones "Null" e nos registos do router "null@null".
As configs sempre foram as mesmas e não alterei absolutamente nada. Presumo que eles tenham alterado algo na string onde enviam essa informação, ou que por bug, na minha conta, não estejam a enviar nenhuma informação. Por descargo de consciência até atualizei o firm o router, mas o problema mantém-se.
Contactei o suporte deles, mas foi o mesmo que nada! Ficaram de passar o assunto a uma equipa especialista, que ficou de entrar em contacto comigo e nada. Uns dias depois o status da reclamação passou para resolvido!
Estás a receber corretamente as informações de caller ID? Tens alguma ideia de onde possa vir o problema?
Obrigado!
Boas,
O router ao tentar registar o ip no dns dinâmico tentou autenticar com o username que lá defini e com a pass do voip em plain text. Desse modo fiquei a sabê-la, visto que a tentativa de autenticação ficou guardada no logger.
Criativo foste tu... porém mais recentemente, por exemplo na data do meu artigo, isso já não iria funcionar. A autenticação deve ter sido melhorada porque requer agora um nonce que é usado no hash. Além disso é MD5, não é impossível de crakear mas iria demorar na mesma.
Acontece que, não sei bem porquê, há uns meses para cá (praí desde abril ou maio.. ou sensivelmente desde que eles acabaram com os voip nomadas (3020xxx)), deixei de receber a informação com a identificação do caller ID.
Eu também tinha dados de login funcionais até descontinuarem os nómadas. Não percebi mto bem, mas no meu caso parece que mudaram a password ou agora os dados de acesso a VOIP são diferentes, para todos os efeitos deixei de me conseguir autenticar com os dados que tinha. Na altura suspeitei do endereço do proxy, mas se tu dizes que continuas a conseguir o mais provável é mesmo terem mudado a minha pass por alguma razão.
Já tentaste autenticar com o microsip e ver o que faz? Só por despiste, pode ter sido algum update no teu router?
Atualmente meio que desisti do assunto, já me mudaram o router para um fibergateway também.
Oi,
Finalmente alguém publica alguma coisa interessante sobre o assunto e uma abordagem sólida. Agora algumas questões:
1) Que servidor de VOIP pode ser usado? Diria Asterisk? Tiveste algum sucesso aqui? 2) Que configuração podemos usar no servidor? 3) Atualmente já não é possível obter (facilmente) o root user dos Thomson o que dificulta as coisas.
Acredito que tal como o VOIP dos número nómadas este VOIP no router não utilize TLS ou qualquer outra forma de proteger o tráfego. Posto isto, podemos usar um Switch (ou https://hackaday.com/2008/09/14/passive-networking-tap/), interceptar o tráfego que o Router faz para a MEO e com o Wireshark ver a password.
Outra possibilidade seria montar um servidor de VOIP e um de DHCP completo num PC e lidar-lhe o router. O router iria pedir um IP ao PC e de seguida deveria tentar resolver o IP do servidor VOIP o que seria fácil de interceptar e alterar para o nosso servidor local...