It was back in February 2016 and I was writing my master thesis. Evidently, I was rather busy and the timing of the Tele2 ADSL-modem to crash every hour couldn’t be much worse. I rang Tele2 to explain the defect of the device and that I wanted to request a new one. They weren’t willing to provide a new modem without running their diagnostics first for a couple of days. Nor were they willing to provide me with the ADSL connection credentials that would allow me to install my own modem. I was not okay with the situation.
So, after I finished my day of studying I set out to retrieve my ADSL connection details. With the modem, a very limited user account is provided that allows the end user to change the most basic settings, such as SSID and WPA keys. Useless. So, I leveraged the greatest hacking tool of all time: Google. I was in luck because other people already figured out the admin credentials for the webinterface
username: AF16KywB!
password: AF22hywLGB!
With these credentials I was able to enable terminal access to the device (from the notes that I kept it must have been ssh with 3des cypher) and ended up in a limited (Busybox) shell. Nice. But I still didn’t had full access to the device. I tried a bunch of commands to escape this sandbox environment such as sh, su and a bunch of other command but the execution of all those command was blocked by Busybox. That simple approach didn’t work. Maybe Busybox could be fooled if I combined an allowed command with with a blocked command using the semicolon ; or the logical AND operator &&. Unfortunately, that didn’t work either. What else? Maybe I could leverage the logical OR operator ||. So I ran one of the commands that I was allowed to execute with invalid syntax (so it would exit with an error code and combined that with || sh (so it would instead execute that). Bingo. I had obtained myself root access to the device.
In no time I had found the ADSL connection details but I was only just getting excited. So I installed my own modem and decided to continue exploring this newly discovered world inside the CT-6373. Unfortunately it was already getting late and I had to focus on my thesis the next day again, so I had to wait until the next evening.
The next day I evidently couldn’t wait until I had time to play with the CT-6373 again. Having so little problems getting root access, I was wondering whether it would be equally easy to figure out the algorithm that calculates the default SSID and password. Again, a little Googling revealed that Comtrend used to use rather simple algorithms to calculate the default wireless password. Would they be so silly to use the same salt again? No. They weren’t that silly. But maybe they applied the same principle with a different salt? Let’s find out.
The CT-6373 is a somewhat limited device. It has very very little persistent memory and hence a number of standard tools have been removed, such as ls, grep and find. That of course makes life a little but more difficult. First I was playing with the idea to create a little partition inside the RAM, install a TFTP client on the free space and transfer all files to my client running. Creating the ramdrive wasn’t the problem but I couldn’t find a way to get files on my CT-6373, so also no TFTP client. So, time for an alternative approach. It’s a bit ugly but it did the job: figure out the filetree with a shell loop and echo and cat the contents of all files to my computer. Here’s what the filesystem looks like (it may not be 100% complete):
So, there’s evidently a couple of files that immediately grabbed my interest: /bin/pwd, /var/md5result, /var/passwd /var/passwd.ct, /etc/psk.txt, /etc/passwd.
In the passwd file there were the login credentials (the one I already knew as well as another admin account) and /var/md5result contained the wireless WPA2 key. So how does that file gets there? Maybe running the command strings over /bin/* and grepping for md5results would teach me something:
md5sum /var/md5encode > /var/md5result
Ha! that seems familiar. Apparently Comtrent is using md5 again to calculate the password. And it is calculated from /var/md5encode. But that file doesn’t exist and likely get erased either on reboot or first boot. But how does /var/md5encode gets there in the first place? Repeat the previous step with md5encode and let’s see:
echo -n %s > /var/md5encode
md5sum /var/md5encode > /var/md5result
rm /var/md5encode
It indeed gets erased and it’s simple made by echoing a string to a file. Can I find out a little more about this string? Let’s try the most obvious and grep md5encode -A 3 -B 3:
/var/hwaddr
HWaddr
tele2-%c%c%c%ctceolmet2rend%02x%02x%02x%02x%02x%02x%s
echo -n %s > /var/md5encode
md5sum /var/md5encode > /var/md5result
rm /var/md5encode
wlctl -i wl%d country list %c > /var/wl%dclist
%[^ %1[
So what do we see here? It seems like the default SSID is being ‘made’: tele2-%c%c%c%c (%c meaning print 4 charcters). And probably the password too: tceolmet2rend%02x%02x%02x%02x%02x%02x%s. This seems like there’s the salt followed by 6 times 2 hexadecimal numbers and a string. Anyone seeing what I see when looking at tceolmet2rend? The creativity of Tele2 and Comtrend is absolutely through the roof: tele2 + comtrend = tceolmet2rend. Anyway. Six times 2 hexadecimal characters is surely a MAC address, and we have seen that before. But was is that string? Could that be a MAC address too as was disclosed in 2010 by seguridadwireless.net?
Because it is easy to obtain the two MAC addresses using Wireshark I was really really hoping that that string represented a MAC address. But Unfortunately, calculating the md5sum over the ‘salt’, the gateway MAC address and the wireless MAC address didn’t do the job. So, what is that string? I tried many things, over and over. I wrote a script to calculate the md5 sum over truncated versions of the MAC addresses, put the salt behind it too, but never got a result that contained the wireless password. I felt so close yet I was out of ideas and thought ‘This is it, I can’t get any further without reverse engineering (which I don’t know how to do). I am beaten’. Then I reread the post I found earlier and realized that Comtrend used lowercase and uppercase conversions. I just tried all four possible combinations with the two MAC addresses and bingo! There it was: the md5has that contained the wifi password.
echo -n tceolmet2rend3872c031de78001A2BA57A21 | md5sum
00982ea6877dcad6850692ab1e9fcd4e
I could not believe that this was so easy. What I mainly couldn’t believe is that they used virtually the same method of calculating the hash as was leaked out 6 years before! I was so stunned by this that I simply couldn’t believe it and I kept searching and searching the internet for proof that no one had found this before. And then I stumbled upon the presentation called ‘Scrutinizing WPA2 Password Generating Algorithms in Wireless Routers‘ by Novella, Meijer and Verdult. (2015). This was presented at WOOT on August 11th 2015. This presentation doesn’t have any references to Tele2 or this specific type of Comtrend router – and all the interesting stuff is in screenshots in the presentation, which is probably why I hadn’t found it before. Yet, I was 100% sure that they were talking about the same router because the salt tceolmet2rend is on one if the screenshots in their presentation (did they not realize this was a pointer to Tele2?)
So what now? Tele2 was already made aware of the problem more than half a year ago by Novella, Meijer and Verdult. What was wrong with those people? Why was the issue not solved yet? I contacted Tele2 and told them about my findings, including how I discovered it and that Novella, Meijer and Verdult’s presentation reveals that it is about Tele2 (due to tceolmet2rend). They told me they were aware of the problem but not of the details I shared with them. I believe they were surprised that I did this without extracting the firmware because after I explained it they asked ‘How did you obtain the firmware?’. On May the 25th of 2016 I finally got an email from Tele2 that they were about to roll out a new firmware that fixed the issue and they gave me a finders fee too – very nice!
So why did I wait so long with this post? Because I do not believe the problem was ever truly fixed. And now, 5 years later, I consider it likely that this device is no longer in use and it is safe to publish. Why do I not believe that the problem was fixed? Because the algorithm and salt are already out there and routers always broadcast these MAC addresses. So, whatever you change in the firmware, as long as it doesn’t change the WiFi password, it’s not solving the problem. What would solve the problem? Sending a letter to all affected users with a new WiFi password, and change the algorithm. Even better: swap all affected modems, store the password in U-Boot variables or something alike and don’t save the algorithm on the device at all. So what would one at least need to do when changing the SSID? Telling the users that the password will change. And I never heard of any Tele2 user who received such a letter, and hence I do not think the problem was ever truly solved – but who knows they did?
n.b. my findings were only made possible by the earlier work on Comtrend modems published on seguridadwireless.net in 2010 and the publication of the login credentials posted at tele2.gebruikers.eu. With the work they have done, I just had to puzzle the pieces together.
Leave a Reply