Claro Zte Router Password

[Assunta Gergely]

Haveyou tried logging in as user telecomadmin and pass admintelecom? It's a default hardcoded user // pass for Huawei HG8245/HG8245T and as far as I know it's not possible to even change this user's password (at least not from the web UI), which is quite ridiculous!

I have found the source code for the tool aescrypt2_huawei that is provided and a walk-through provided on a blog called TheZedt. It seems the Huawei uses the same configuration encryption key hex:13395537D2730554A176799F6D56A239 on all of its devices and the only thing special about the binary version of the tool is the fact it adds an 8-byte header to the file. You can see the source code link for a more detailed explanation.

As the walkthrough and @Blz mentions you can modify the UserLevel to 0 and reupload it to the router, but... I strongly recommend you add a new user rather than modify an existing account. You'll need to generate a new password hash using the formula SHA256(MD5(new password)). Test to make sure you can generate the same hash as the root account in the file by testing with 'admin'.

There is a way to get admin access. Login to web interface as root/admin. Download existing configuration (System tools -> Configuration file and click on Download configuration file). Open downloaded file with text editor. It depends on you firmware version whether configuration file will be encrypted or not. If your text editor shows XML data then just search for root or X_HW_WebUserInfo and modify existing records or add a new one.

You can change the password for telecomadmin that is the default admin account for Huawei HG8245 by updating the routers configuration file. You can even make the root account an administrator account and even add new ones.

Antes de ingresar, ten en cuenta que por poltica de Claro no te brindan esta informacin ya que es posible que por una mala configuracin se dae el router, as que toda manipulacin es bajo tu responsabilidad.

Yo tengo el mismo problema y se niegan a darme la clave. Por lo cual pienso tomar accin por medios legales, esto se debe a que el equipo es comprado y no es alquilado como sucede con el internet fijo.

Alguien ha llamado a claro para cambiar su clave y te piden algn dato? como por ejemplo: tu nmero de serie de tu router, o tu Mac, o tu IMEI, O ALGO ASI? a lo mejor por ah podemos descifrar la clave de nuestros routers.

Al escribir la URL http: // 192. 168. 1. 1 se redirecciona automticamente a la URL anterior y muestra una Web con el logotipo de CLARO, lo que indica directamente que el Mdem fue manipulado internamente por CLARO y que est restringido el acceso al dueo del mdem.

NETGEAR has patched all five vulnerabilities uncovered by Team82, three of which were high-severity vulnerabilities that enable pre-authentication remote code execution, command injection, or authentication bypasses.

An attacker could also use these vulnerabilities to access and control networked smart devices (security cameras, thermostats, smart locks), change router settings including credentials or DNS settings, or use a compromised network to launch attacks against other devices or networks.

The Internet of Things (IoT) has become an increasingly popular target for cyber attacks in recent years because these devices are often poorly secured and can be easily compromised. To highlight the vulnerabilities of IoT devices and encourage better security practices from manufacturers, the Zero Day Initiative (ZDI) organized a Pwn2Own competition last fall in Toronto that focused on hacking into IoT devices such as printers, network-attached storage (NAS) devices, routers, and smart speakers. This competition brought together experienced hackers to demonstrate their skills in finding and exploiting vulnerabilities in these devices. Here, we will explore the research we conducted on the Netgear RAX30 router, below, for the Pwn2Own competition.

When conducting research for a Pwn2Own competition, it is not uncommon to discover multiple vulnerabilities in the targeted device or software. In fact, right at the beginning of our research, we identified several vulnerabilities that were trivially exploitable. However, since the competition reduces points for duplicate issues, we knew that simply reporting these vulnerabilities would not be enough. Instead, we decided to dig deeper and uncover more complex and novel vulnerabilities that would provide us with a competitive advantage.

The vulnerability we found was a stack-based buffer overflow. This class of vulnerabilities is usually trivial to exploit when there are no stack protections. However, it turned out that a few versions back, Netgear decided to recompile all the binaries in the RAX30 router with stack canaries making the exploitation much harder.

Eventually we had to find and exploit five vulnerabilities in a cool chain that earned us five points in the Pwn2Own competition, where Team82 had success in a number of categories in addition to targeting routers. This exploit chain can be leveraged by an attacker to gain pre-authentication remote code execution on affected devices.

Successful exploits could allow attackers to monitor users' internet activity, highjack internet connections and redirect traffic to malicious websites or inject malware into network traffic. An attacker could also use these vulnerabilities to access and control networked smart devices (security cameras, thermostats, smart locks), change router settings including credentials or DNS settings, or use a compromised network to launch attacks against other devices or networks.

We will focus on the third option: logically bypassing the canary. While this is something that is thrown around every time bypassing canaries is brought up, there aren't that many real world examples where this technique is used.

The exposed API allows users to query the device and change its configuration. The server is mainly used by the NETGEAR Nighthawk App for iOS and Android. There are more than 180 actions exposed by the server and they are sorted by the following categories:

As we can see in the calls to memset, each parameter (method, path, protocol) is expected to be no more than 0x7FC bytes long. The server does not check the length of the method, path, and protocol fields meaning we can overflow them and overwrite data on the stack.

Unfortunately the HTTP receive function over TCP port 5000 limits the size of the HTTP header, thus limiting the amount of data we can overflow. In order to avoid that limitation we used something a bit different.

We can use this vulnerability to write long buffers on the stack while bypassing the overall buffer-size limit. If we use SSL to send the SOAP message, we are not limited in size (due to the stack overflow mentioned above) meaning we can overwrite as much data as we want.

Now that we understand the sscanf vulnerability and can trigger it without any limitations on how much data we can overwrite, we are left with only one issue: the stack canneries. Once we overwrite data from the stack and right before the function that handles HTTP requests returns, the stack canary is checked and crashes the program.

In recent versions on the RAX30 router, NETGEAR started to compile the soap_soerverd binary with stack protections. These protections make it much harder to exploit the stack overflow in the traditional way. Our approach to bypassing the stack canary was to try to (somewhat) logically bypass it.

Stack canaries are set at the beginning of functions that have the potential for an overflow, but are checked only at the end of the frame. This means that by using the sscanf overflow, we can overwrite the canary, finish the request handling and response flow and only then get to the end of the function where the canary is checked.

The first thing the server checks when authenticating users is whether the request came from 127.0.0.1 (localhost). Requests coming from localhost do not require authentication. Luckily we discovered that the socket source IP is stored on the stack in an offset we can overwrite with our stack overflow.

This vulnerability by itself is not enough because usually we are limited to 0x800 (2048), and so we chained it with the previous vulnerability over TCP port 5043 (SSL), which allowed us to write more data on the stack. The final payload we constructed was:

When setting up the router, users are required to enter a new, unique password and provide security questions and answers that will allow them to restore the password if they forget it. The answers to these questions are stored in plain-text (base64) in the device configuration. In order to reset the device password, users need the serial number of the router and the answers to the security questions. Therefore, by getting the raw configuration using the three vulns above, an attacker will be able to reset the admin password, below.

After sending the magic packet, the device will run a telnet server and open port 23 TCP for new connections. However, now we face a new problem: the telnet interface is restricted to specific commands. We were jailed.

So, we had to look for another vulnerability, a command injection. We discovered that the TFTP command is not filtered before it is executed (CVE-2023-27370), which means that we can run any command using that interface.

After changing the password we can send a magic packet to enable a restricted telnet server on the device. Using CVE-2023-27367 (Restricted shell escape), we get root access remote code execution on the device

These five CVEs can be chained together to compromised affected RAX30 routers, the most severe of which enable pre-authentication remote code execution on the device. NETGEAR recommends users update these devices immediately.

3a8082e126