Como restaurar acessos RootUser e permissões num router TG784n (10.2.1.L)

  • 20 Março 2015
  • 302 respostas
  • 60445 visualizações


Mostrar a primeira mensagem

302 respostas

Reputação 5
ner0 escreveu:

 


Efetivamente, se tiveres seguido o tutorial à risca, já terás desativado o acesso remoto com um simples clique e no preciso momento em que deixas de precisar do mesmo.



 


Sim, bem visto. Devido aos erros da consola, não estava seguro de que esse botão funcionasse correctamente e ignorei por completo. De qualquer forma, ficou o comando alternativo por telnet, para quem o preferir. Obrigado.


 


Atentamente,
Boa tarde,


 


Muito obrigado @@ner0


Informo que 


code:
:user config name=Debug password=NOVA_PASSWORD
saveall

funcionou na perfeição.


 


VaF
VaF escreveu:

Como se pode ver na página 4 deste tutorial

Tekhouls escreveu:

Nota, a este manual:


 


NOTA DE COMPATIBILIDADE (TG784n):
Se o router for o TG784n em vez do TG784n v3, então ignora o código acima e usa este para aceder ao router:


code:
var user = "nauser";
var hash2 = "f8700f3bb4e73cc4bb5229def20ce0d0";
var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit(); 

 Tambem é compativel com o TG799vn.


 


Muito obrigado pelo manual.



 





Testei no meu TG799vn e não deu, simplesmente não faz nada nem login nem erro, alguem sabe o código para fazer login num TG799vn ver. 10.2.1.L?

Sabem dizer se esta solução também funciona num TG799vn ver. 10.2.1.L?
Reputação 3

Provavelmente estás a tentar fazer login através da rede local, por isso não acontece nada nem dá erro.


O utilizador 'nauser' costuma ser "universal", e o membro que citaste confirmou que funciona para esse modelo.


Confirma se estás a seguir o tutorial à risca.


 


Na parte da ligação remota aconselho-te a optares pela opção a)


 


  • opção a) - Através de um proxy web, como este:
code:
http://proxy.piratenpartij.nl/TEU.ENDEREÇO.IP.INTERNET:1234/remote_admin.lp

 


Sim tentei através da LAN, pensei que o acesso remoto fosse uma opção e não um imperativo...

É ridiculo fazer toda aquela volta do acesso remoto se na realidade está logo ali.

Vou fazer os passos todos e depois confirmo se deu.


Obrigado pela atenção ner0
Reputação 2
Ao executar o primeiro comando: system ra instadd name=remoteaccess dá-me command not allowed.


 


Não há como resolver?
Reputação 3
fL0 escreveu:

Ao executar o primeiro comando: system ra instadd name=remoteaccess dá-me command not allowed.


 


Não há como resolver?



Para já penso que não, a MEO corrigiu a falha de segurança com uma atualização.
Reputação 2
MEO no seu melhor... é que o user sumeo é completamente ignorado lol "SuperUser"


 


Qualquer que seja o comando executado dá sempre not allowed.


 


Estive a ver se conseguia aceder via ftp mas tá doce.
Não da para fazer um downgrade algo do genero para conseguir desativar? :@


 
Reputação 3
Teoricamente, sim.
Uma das possibilidades é através do seguinte comando:


code:
:software switchover

Deverá ser possível reverter à versão do FW anterior, caso o utilizador tenha permissões para executar o comando acima.


 


Antes disso, convém confirmar se a versão passiva também é L (devido à migração para IPoE), através do seguinte comando:


code:
:software version

 


A alternativa é encontrar um ficheiro do FW anterior e fazer o download/upload através do computador, em modo BOOT-P, com o seguinte comando:


code:
:software upgrade

Também neste último caso, apenas se o utilizador tiver permissões para executar o comando acima.


 


NOTA: Em qualquer caso, poderá resultar na perca das definições ou na avaria do aparelho se o processo for executado indevidamente.
Alguem me pode ajudar? nao consigo excutar os comandos depois de fazer login por telnet, recebo sempre a mensagem "command not allowed"

 
Reputação 3
Como já foi mencionado numa das respostas anteriores, a MEO propagou algumas alterações aos routers que estão a impedir o funcionamento deste método. Dito isto, desconfio que estas alterações não são permanentes - apesar de não ter a certeza do nível de volatilidade das mesmas. Se for feito um reset para definições de fábrica, o utilizador SuperUser (sumeo) deverá recuperar a capacidade de ativar o acesso remoto. Se quiseres tentar, deverás fazer um reset ao router e voltar a tentar seguir o tutorial.


 


NOTA: Como deves saber, fazer um reset ao router fará com que percas todas as definições do mesmo, incluíndo login da ligação Internet e, principalmente, configurações VoIP (caso o teu telefone fixo esteja configurado no router dessa forma). Se mesmo assim quiseres fazê-lo, inicialmente é aconselhável seguir o tutorial sem ligação à internet para que não corram os riscos de voltar a perder as permissões prematuramente. Caso consigam criar um novo RootUser, aconselho a desativarem o serviço CWMP através dos seguintes comandos:


 


code:
:cwmp config state=disabled
:service system modify name=CWMP-S state=disabled
:service system modify name=CWMP-C state=disabled
saveall

 


 


Ao contrário daquilo que pensava inicialmente, a atualização feita às permissões, que tornam este tutorial (quase) inútil, não foi uma atualização do firmware. Parece que utilizaram o servidor ACS para alterar as permissões em todos os routers, independentemente da versão de FW - visto que não só afeta a versão 10.2.1.L mas também a 10.2.1.D.


 


Aa duas alterações mais inconvenientes foram:


- Restringir o SuperUser ao nível dum mero "Administrator", agora um "SuperUser" tem praticamente as mesmas permissões que o utilizador "meo" ou "Administrador";


- Desabilitar a possibilidade de login remoto por HTTP por parte do utilizador "nauser".


 
Com o reset ja consigo correr os comandos o problema é quando ligo o router a net para poder aceder remotamente, perco os acessos novamente


 


Edit: quando faço o list aparce que o acesso remoto esta activo mas nao consigo aceder depois de ligar a net, e a seguir nem que queira ver se ainda continua a activo ja me da command not allowed


 
A hash das passwords, incluido a do Debug, têm ou não têm salt?
Aqui ? http://forum.meo.pt/t5/Tutoriais/Como-criar-um-RootUser-para-aceder-a-telnet-no-firmware-10-2-1-D/m-p/66460/highlight/true#M1803
Dizes que a hash da para crackear mas não sabemos se é muito grande e se tem salt? A hash do TG784n vi que o PTSec descobriu que era md5($user:Thomson Gateway:$password) muito mais que 8 caracteres. Confirmei que md5(sumeo:Thomson Gateway:bfd,10ng) = 094a55fcfbf4850f0f9eef4b5c1ff490, o que estava no .ini do meu antigo TG784n. Tentei ver se descobria o como era gerado o md5 do TG784n V3 (o meu)  de um superuser que tinha criado e não consegui. Continua a ser a "276da5030a939d29642637f279629770" a do TG784n V3 suponho.
Como descobrimos as outras passes btw? Alguém sabe? Suponho que para decobrir como é feito o md5 para o V3 tenha que andar a ver o ficheiro do firmware?

Quando tinha acesso com o firmware não tive interesse em criar um rootuser porque tentei uma vez e não consegui então fiquei me por criar um superuser visto que podia sempre usar o debug user quando quisesse... e agora já não da...

? tiveste sucesso em criar o root user apesar de depois perderes acesso a config do ra (remote acess) com o superuser(sumeo)?
? So para confirmar, se fizer reset como dizes consigo seguir o tutorial do 1º post? Ou seja passo a conseguir configurar o remote acess com superuser?
Queria so confirmar antes que perca as minhas settings, a mais importante, o randomports=disabled no nat.ini, é essencial para conseguir jogar online na wii u. Ou será k o valor default já é disabled? Se alguém poder confirmar ficarei agradecido.
Apenas uma sugestão... não seria prudente deixar esta discussão para outros fóruns/blogs/...? Isto de colocar instruções facilitadas a qualquer utilizador para adicionar um RootUser num fórum oficial... sinceramente nunca me pareceu uma boa ideia... é estar a "enfiar os dedos nos olhos" de alguém na própria casa desse alguém 😃 Até pela grande visibilidade (por clientes) que isto terá por aqui, inclusive por utilizadores que não precisam de facto do RootUser e que podem criar problemas desnecessários, etc... faz com que rapidamente alguém se mexa para bloquear os "buracos" que vão sendo descobertos... qualquer dia está tudo "tapado" de vez e vamos perdendendo cada vez mais funcionalidades que vão sendo desactivadas para "tapar buracos".


 


Espero não ser mal interpretado, é apenas a minha opinião, para bem de todos nós.


 
A minha opinião não vale muito porque so li umas vezes este forum mas acho que a discussão ser secreta não faz sentido porque seria necessário ser um circulo muito fechado. Isto é, temos que saber se cada um que seria informado é da meo ou não, dificil estar a verificar toda a gente, logo poucas pessoas usufruirem do exploit. Os que trabalham para tapar isto terão mais interesse em saber que alguns de nos so para  fazer umas modificaçõeszitas no router, logo acho que seria muito dificil partilhar essa informação sem passar pela meo. Os que percebem devem decidir entre guardar um exploit que pode ser corrigido em poucas semanas num update ou revelar para o publico e partilhar para entretanto as pessoas usufruirem.


 


tl;dr Mesmo se discutissemos noutro forum eles teriam tanto acesso como nos porque em principio têm mais interesse que um user qualquer.

Um bocado offtopic mas algém percebe o que a meo ganha em bloquear o acesso? Não vejo de que maneira incomoda, está alguma coisa no .ini que eles não querem que nos vejamos porque de qualquer maneira causa prejuizo?
Atenção que eu não sugeri que a discussão sobre o assunto fosse secreta/fechada, apenas acho que este não é o sitio certo para ela... não porque quem trabalha para tapar isto não possa ver noutro fórum/blog/etc... claro que poderia... mas terá certamente uma visibilidade bem menor para clientes e talvez não sintam tanta necessidade/urgência em tapar... ou mesmo de andar pela net à procura... é apenas uma ideia.
Reputação 3
Fredgido escreveu:

A hash das passwords, incluido a do Debug, têm ou não têm salt?
Aqui @tiagofcp tiveste sucesso em criar o root user apesar de depois perderes acesso a config do ra (remote acess) com o superuser(sumeo)?
@ner0 So para confirmar, se fizer reset como dizes consigo seguir o tutorial do 1º post? Ou seja passo a conseguir configurar o remote acess com superuser?
Queria so confirmar antes que perca as minhas settings, a mais importante, o randomports=disabled no nat.ini, é essencial para conseguir jogar online na wii u. Ou será k o valor default já é disabled? Se alguém poder confirmar ficarei agradecido.



 


? A palavra-passe do Debug será mais comprida que 8 caracteres, o tempo de brute-force aumenta exponêncialmente.


Nestes routers o salt é praticamente o mesmo, Technicolor Gateway em vez de Thomson Gateway, o resto do hashing é idêntico.


Suponho que as passwords anteriores tenham sido crackadas dado que o comprimento da maior delas (sumeo) é de 8 caracteres o que é razoavelmente "crackavel" através de brute-force, ou então terão sido divulgadas por funcionários da MEO com conhecimento das mesmas.


 


Aquilo que eu adientei, e que o ? confirmou, foi que, de facto, as restrições são aplicadas via servidor ACS.


O que isto significa é que a MEO, tal como outras operadoras (VF), tem um servidor (acs.iptv.telecom.pt) onde são alojadas definições complementares para os routers. Assim que o teu router se liga à internet, este descarrega as definições e aplica as restrições.


Eu próprio não fiz os testes, mas o relato do nosso amigo é que este tutorial funciona até à Parte 2 (inclusive). O problema é que no momento de te ligares remotamente precisas de ligar o router à internet e assim que o fazes o router descarrega as atualizações que restringem o acesso do "nauser", impedindo-te de conseguires fazer o login remoto mesmo que ele ainda esteja ativo.


Surgem várias ideias de como ultrapassar este problema, mas teria que testá-las e fazer vários resets, algo que não deverá ser para breve. Em relação à questão sobre o randomports, não consigo confirmar, apesar de que uma breve pesquisa no Google indica que por defeito essa definição estará ativ, ou seja, randomports=enabled por defeito.


Já sobre o que motiva os engenheiros da MEO a bloquearem os acessos cada vez, existem várias razões plausivéis, entre elas:


- Impedir desbloqueio do equipamento a qualquer operadora;


- Impedir descobrir as credenciais VoIP;


- Impedir desativação unilateral do MEO-WiFi;


- Impedir manipulação do ficheiro de configurações (user.ini);


- Proteger os routers de ataques cibernéticos;


- Meter nojo.


 


? É uma questão interessante, e é possível que exista alguma verdade no que dizes, mas não me parece que faça muita diferença.


O "exploit" do utilizador Debug já era conhecido há vários anos e dúvido que não fosse do pleno conhecimento dos engenheiros da MEO, tanto que incluíram a restrição do login numa atualização de F/W. Se o simples facto desta informação constar do fórum da MEO é que os motiva a bloquear ainda mais o router, então a única razão plausível para isso é mesmo a última que listei no parágrafo anterior.


 


Em suma, a MEO pode bloquear aquilo que bem entender porque o router é deles... ou pelo menos é nisso que eles acreditam.


Só que afinal não, o router da MEO não é o Vaticano; mi casa no es tu casa.


 
Reputação 5
ner0 escreveu:

 Se o simples facto desta informação constar do fórum da MEO é que os motiva a bloquear ainda mais o router, então a única razão plausível para isso é mesmo a última que listei no parágrafo anterior.

 


Em suma, a MEO pode bloquear aquilo que bem entender porque o router é deles... ou pelo menos é nisso que eles acreditam.


Só que afinal não, o router da MEO não é o Vaticano; mi casa no es tu casa.


 



 


? , ? , ? e outros...


 


A questão fulcral aqui, é que ao preocupar-se em demasia com a "abelhudice", corre-se o risco de servir mal alguns clientes, e não é fácil encontrar um meio termo, neste âmbito (acessos e restrições dos equipamentos). Obviamente que esse pessoal é instruído, desde cedo, sobretudo para aniquilar qualquer hipótese de um cliente se tornar "abelhudo", após se ter sentido mal servido. Isto deriva tudo de politicas das operadoras e, da forma como se aplicam essas mesmas politicas. O cliente supostamente assina um contrato e concorda com essas politicas, contrato em que a operadora assume claramente um ponto de vista linear e superficial, em relação ao propósito final dos seus produtos (por necessidade?) e, quase sempre a inevitável e fraca presunção de que todos os clientes são o típico andróide frenético da sociedade digital, e se estão borrifando para detalhes como portas de entrada exclusivas, pools de IP dinâmicas, gestão de hosts DNS, ACL por MAC em Wi-fi, etc... Detalhes que, teoricamente, afectam não mais que a forma como a rede de área local funciona, no nosso ambiente doméstico e, cuja manipulação inócua e moderada, revela-se bastante útil para alguns de nós. Se algo mudará, futuramente, nessas politicas e a esse respeito, não me parece. Até porque somos uma "minoria" e, a operadora (para se salvaguardar?) "entende" que esses detalhes terão sempre, obrigatoriamente, de passar pelo "filtro" das mãos, dos seus técnicos honorários, mas fica a ideia (se realmente, alguém de direito, estiver a dar importância a este tópico, o que não creio)...


 


Quanto ao problema das actualizações ao router, que muito me desilude o facto de as terem tornado constantes - algo que resulta claramente dum patch incluído no boot script do 10.2.1.L, fora do alcançe do user.ini e, aparentemente, activado silenciosamente através do comando "set var=STS_Security_Fix value=Enabled", acrescentado às variáveis de ambiente, nesse feed update - e que, felizmente, para mim foi indiferente, pois já me tinha adiantado na criação do rootuser no TG784n V3, penso que é facilmente ultrapassado usando um router adicional, ligado antes do router MEO e duas LAN distintas, ou então criando uma VPN local, visto que a única condicionante para que este tutorial resulte se resume agora a obter acesso de uma rede exterior à qual o router MEO está incluido. No fim de criado o rootuser e removido o feed do update, resta ligar o router MEO de novo à WAN e reconfigurar o que falta.


 


É irónico e ridículo, pois a politica de uma operadora "impõe" o uso do equipamento exclusivo deles e, no entanto, derivado aos muitos inconvenientes que daí se provam, quase tudo neste forum nos aponta e aconselha para o uso de outro equipamento que não o deles. No fim, ninguém parece "viver" verdadeiramente mal com esta realidade...


 


Atentamente.
Reputação 3
Concordo @@NeoPT, muito bem resumido.


 


Em relação à atualização das permissões, o F/W anterior (10.2.1.D) também foi afetado.


Não tenho ideia que tenha sido feito o que quer que seja de forma permanente, nem que esteja fora do alcance do user.ini - pelo menos parcialmente não. Os routers desde sempre que se ligam ao servidor ACS, mas é curioso porque nunca foi usado em circumstâncias como a do utilizador Debug (pré v10.2.1.L), nunca barraram o seu uso mais que divulgado e agora vieram bloquear este pequeno "truque".


 


O que propões para simular um login exterior (WAN) não deverá funcionar duma forma tão simples uma vez que a porta WAN (ou ethif5) estará à espera dum handshake PPPoE (ou IPoE). Uma VPN local também não resultaria uma vez que é local, ou seja, navega em qualquer uma das interfaces ethernet ou wifi mas nunca pela porta que é preciso: wan
Qualquer que seja a alternativa, complica bastante... mas continua a ser possível. Por exemplo, usando um 2º router para estabelecer a ligação à internet e alterando a resolução DNS do endereço acs.iptv.telecom.pt para qualquer outro bloco deverá impedir que o router aplique as restrições quando ligado à internet (via o primeiro router).


 


Em último recurso, penso que existe uma outra possibilidade (infalível e offline); mas mesmo assim requer condições específicas e hardware apropriado. Após fazer um reset ao router o utilizador sumeo reganha as permissões anteriores que permitem ativar o acesso remoto. A ativação do acesso remoto em si não é o que é interessante mas sim o facto desse comando também poder atribuír uma palavra-passe aleatória a qualquer utilizador (Debug?). Ainda mais interessante é o facto da palavra-passe aleatória ser sempre composta por 8 caracteres, e cuja combinação está limitada a letras minúsculas e números. Tendo em conta que o comprimento e composição são conhecidos, e que se encontra ao alcance de uma operação brute-force, deverá então obter-se o hash2 da palavra-passe aleatória do utilizador Debug e proceder-se a uma operação de brute-force sobre o mesmo. O tempo de recuperação da palavra-passe dependerá do hardware... com hardware razoável, entre 1 a 2 horas deverá ser suficiente. Depois é fazer login por telnet e blá, blá, blá. Isto é apenas uma ideia instantânea, nem sequer sei se o sumeo consegue fazer um dump à configuração após um reset, o que seria necessário para obter o hash MD5. Se alguém quiser testar fazer um reset ao router e um dump ao hash, posso "ceder" até 2 horas de computação do meu hardware para colocar a teoria em prática.
Ao usar isto para fazer login:


 


code:
var user = "nauser";
var hash2 = "d3eff9622e6e8efe7d8c059c596f075f";
var HA2 = MD5("GET" + ":" + uri);
document.getElementById("user").value = user;
document.getElementById("hidepw").value = MD5(hash2 + ":" + nonce +":" + "00000001" + ":" + "xyz" + ":" + qop + ":" + HA2);
document.authform.submit(); 

 


não aparece aquele erro a dizer que os dados estão incorretos, apenas um pequeno flash e fica ali no login mas ao efetuar de seguida um login com um outro utilizador dá para ver que foi realmente feito um login com o nauser.


 


http://i.imgur.com/oFh4FGu.png


 


Isto leva-me a crer que o problema está nas restrições que foram aplicadas ao acesso via HTTP para este grupo de utilizadores (mlp role). 
Reputação 3
? Se leres a página anterior, verás que estão mencionadas algumas das alterações; entre as quais:


ner0 escreveu:

As duas alterações mais inconvenientes foram:


- Restringir o SuperUser ao nível dum mero "Administrator", agora um "SuperUser" tem praticamente as mesmas permissões que o utilizador "meo" ou "Administrador";


- Desabilitar a possibilidade de login remoto por HTTP por parte do utilizador "nauser".



 
Reputação 5
ner0 escreveu:

 


...O que propões para simular um login exterior (WAN) não deverá funcionar duma forma tão simples uma vez que a porta WAN (ou ethif5) estará à espera dum handshake PPPoE (ou IPoE). Uma VPN local também não resultaria uma vez que é local, ou seja, navega em qualquer uma das interfaces ethernet ou wifi mas nunca pela porta que é preciso: wan...



Olá ?


 


Exacto, bem visto. Como o meu TG784n V3, já se conecta por IPoE descartei completamente essa hipotese. Teoricamente, seria possivel simular tambem um servidor PPPoE, num PC exterior ao router MEO, ou até mesmo reconfigurar as Interfaces do router MEO, fazendo o routing  necessário ao gateway. Mas estes procedimentos seriam bastante mais penosos e, depois há o "pequeno", grande pormenor de, até que o acesso rootuser não esteja livre, nada disto é viável... Bem, parece mesmo que não restam muitas alternativas.


 


Atentamente,
Olá,

 

Estou a tentar criar o acesso rootuser mas não consigo passar do passo 2.

 

Consigo criar o acesso através de telnet (telnet 192.168.1.254), introduzo o user name e password (sumeo) e quando digito o comando "system ra" dá-me a informação que o comando não é permitido (command is not allowed).

 

Os meus conhecimentos de informática a este nível são básicos e não consigo passar do passo 2.

 

Alguém consegue dar-me uma ajuda?

 

Já alguém configurou um WD mycloud através do router  TG784n v3?

 

Cumprimentos
Se me derem ideias, eu posso tentar dar reset e ver se conseguimos uma solução para ter acesso remotamente ao router, ja tentei incluisve com outro router 4G a fornecer a net e com o da meo ligado a este mas nao conta como acesso exterior.


 


Alguem tem sugestões?

Responder