A lot of people know the situation: You get a new and fast Internet connection. But your provider is a support nightmare. He hands you a practically black boxed router that automatically gets its connection data from the Internet and you have no chance of ever getting this data. After all.. why would you.. isn’t it much easier this way? Well.. let me tell you a little secret the providers don’t like to be advertised that much: Not only do they push the configuration to your new router, but they can also change it ANYTIME they want. If you have a regular setup like most people it looks like this:

(Given, not everyone has a NAS at home. But they become more and more common as the devices become more simple and the data people want to store (like e.g. Audio and Video Data) needs to be shared between devices in the network. So for the sake of this article lets assume the regular user has some kind of network capable storage. Technically even a smartphone or a wifi enabled HiFi system is a network attached data storage but lets keep it simple). In this kind of setup that we see in the above picture, the Router that you use is the only barrier between your data (or device that holds your data) and the Internet. Suddenly a device you though just “provides you with internet access” becomes the only thing between your privacy and total disclosure of your private data to the world! Worse yet: even if you are as naive as to assume you provider will never do you harm, will never be hacked and never be forced by the government to give them access to your data, there is hardly a month were security groups in the Internet and from companies don’t find horrific bugs in common router firmware. With the providers being the only ones who can update your router, you have to put total trust in them to do so in a timely manner. Sadly they usually are way behind when it comes to updating the devices. So obviously this is a setup that is not acceptable. A possible solution would look like this:

Its possible but it has a few rather bad downsides:

• You waste power for a device you practically don’t use (the provider router).
• The provider (or someone who hacked it) can still do stuff to the other router and close ports or mess with connections.
• You still need to use the provider router for the SIP connection because you don’t have the login data for that.
• Your connection speed might drop from having two firewalls and 2 NAT systems behind each other.
• In worst case scenarios you can’t open ANY Ports towards your network because your provider doesn’t want it.

Its obvious that the best solution would be to have your own router (for me this is my Gentoo server) and telephone system (Asterisk in my setup) running that you can maintain and implement your own security plan as needed. When I switched my Internet provider this week (for a lot more speed) I had exactly this problem. They just give you a router (FritzBox) and nothing else. For me it was clear from the beginning that I was going to use my own solution as I have been for the last 4 years. This is the story of how I managed to do just that.

My first idea (that I had before I even had the thing in my hands) was to hack the router right after it had downloaded the configuration from my provider. I knew from articles in the Internet that there was a slim chance of getting a telnet daemon running on the FritzBox and connecting to that. However when the device was done downloading the data, it became clear pretty fast that this door was slammed shut by my provider. In fact there was no getting into that router from any angle. It took me the better part of a day to realize that this idea was a dead end.

I needed a new plan… and I had one. I knew from experience, that most companies don’t take security that seriously. So I though to myself: “Why should that router send all the login data encrypted over my DS Line?”. After all who really has the capabilities to sniff a very high frequency modulated signal in a cable that is mostly under ground (yes the government has, but they can just get that data if they want to). Fortunately the FritzBox has a sniffing program integrated for all Interfaces designed for customer support problems (horrifying I know but in that moment.. pure gold!). It records all packets send over a specified interface in the wireshark format. No sooner said than done I had a neat amount of PPPOE packages on my hard drive recorded during the login procedure via DSL. It didn’t take me to long to find the data that I was looking for. 3 different PPPOE connections. One for the Internet line, one for the voice channel and a third one for the TR-096 channel (provider remote access for touter configuration)! It was unencrypted as I though and the passwords and usernames where plaintext *Place facepalm and happy dance here*.

The last thing that was missing, was the username and password for the sip connection to my provider. And here I hit another dead end again. While PPP login using unencrypted PAP authentication is not that unusual, the SIP protocol has per standard an encrypted HTTP Digest challenge as login procedure. Though I could easily get the username (it was unencrypted of course :-/) it proved impossible to get the password this way (Technically it wasn’t impossible, but I would have had to put an immense amount of CPU/GPU time and energy into reverse calculating that has to a password password. Considering it turned out to be 8 characters long, that might have taken month, if not more, of a permanently running cracking program). But I was not about to give up that easily. After all as Jean-Luc Piccard once said: “Things are always impossible until they’re not!”. I needed yet another plan.

I remembered that though I did not know that password, neither did my router when I first unpacked it. I started digging into the TR-096 protocol. And there I found the weak link I was looking for. Although TR-096 uses HTTP as means of transport it is recommended to use HTTPS for obvious security reasons. My provider of course did not. When I saw the CPE management URI starting with http:// I knew I was onto the solution. I set my router back to its original state and disconnected the DSL cable. After rebooting the box, I immediately started the sniffer on the Internet line.

At first I was only getting rather useless PPPOE session data (PADI;PADO;PADR,PADS) or chunks of TCP data that wasn’t readable. I already became somewhat frustrated when the sniffer hit gold.A series of HTTP packages! I quickly put them together (they where fragmented) and the result looked something like this:

POST /live/CPEManager/CPEs/Auth_Basic/avm/ HTTP/1.1
Host: ***.***.***.***:80
Content-Length: 2776
Content-Type: text/xml; charset=”utf-8″
SOAPAction: “cwmp:Inform”

<soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:soap-enc=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:cwmp=”urn:dslforum-org:cwmp-1-0″>
<soap:Header>
<cwmp:ID soap:mustUnderstand=”1″>100</cwmp:ID></soap:Header>
<soap:Body>
<cwmp:Inform>
<DeviceId>
<Manufacturer>AVM</Manufacturer>
<OUI>00040E</OUI>
<ProductClass>FRITZ!Box</ProductClass>
<SerialNumber>************</SerialNumber></DeviceId>
<Event soap-enc:arrayType=”cwmp:EventStruct[4]”>
<EventStruct>
<EventCode>7 TRANSFER COMPLETE</EventCode>
<CommandKey></CommandKey></EventStruct>
<EventStruct>
<EventCode>M Download</EventCode>
<CommandKey>*************</CommandKey></EventStruct>
<EventStruct>
<EventCode>4 VALUE CHANGE</EventCode>
<CommandKey></CommandKey></EventStruct>
<EventStruct>
<EventCode>1 BOOT</EventCode>
<CommandKey></CommandKey></EventStruct></Event>
<MaxEnvelopes>1</MaxEnvelopes>
<CurrentTime>0001-01-01T00:02:00</CurrentTime>
<RetryCount>1</RetryCount>
<ParameterList soap-enc:arrayType=”cwmp:ParameterValueStruct[8]”>
<ParameterValueStruct>
<Name>InternetGatewayDevice.DeviceSummary</Name>
<Value xsi:type=”xsd:string”>InternetGatewayDevice:1.4[](Baseline:2, EthernetLAN:1, ADSLWAN:1,ADSL2WAN:1, Time:2, IPPing:1, WiFiLAN:2, DeviceAssociation:1), VoiceService:1.0[1](SIPEndpoint:1, Endpoint:1, TAEndpoint:1), StorageService:1.0[1](Baseline:1, FTPServer:1, NetServer:1, HTTPServer:1, UserAccess:1, VolumeConfig:1)</Value></ParameterValueStruct>
<ParameterValueStruct>
<Name>InternetGatewayDevice.DeviceInfo.HardwareVersion</Name>
<Value xsi:type=”xsd:string”>*********************</Value></ParameterValueStruct>
<ParameterValueStruct>
<Name>InternetGatewayDevice.DeviceInfo.SoftwareVersion</Name>
<Value xsi:type=”xsd:string”>************</Value></ParameterValueStruct>
<ParameterValueStruct>
<Name>InternetGatewayDevice.DeviceInfo.SpecVersion</Name>
<Value xsi:type=”xsd:string”>1.0</Value></ParameterValueStruct>
<ParameterValueStruct>
<Name>InternetGatewayDevice.DeviceInfo.ProvisioningCode</Name>
<Value xsi:type=”xsd:string”>*****</Value></ParameterValueStruct>
<ParameterValueStruct>

….

Of course there was real data in there. I just put the stars in to cover up sensitive information. Somewhere in this chunk of data (apart from all the config data that I already had from my other sniffing attempts) if found two junks that where like the second coming for me on this day:

<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthUserName</Name>
<Value xsi:type=”xsd:string”>*************</Value>

<Name>InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.SIP.AuthPassword</Name>
<Value xsi:type=”xsd:string”>*************</Value>

Bingo! The last puzzle pieces to my odyssey! As a last measure of verification, I flashed my router with a de-branded firmware and entered the data that I had collected in the appropriate interfaces (to make sure that there was no other special stuff in that old firmware that was needed to make the connections). And it worked like a charm. Even though it might not seem like such a big deal for some.. for me those two days of hacking to get my own data (after all I pay for that connection) was quite an experience in itself. Especially since I was successful! Another win for free choice and against oppression :-P.

And the moral of the story? Thank god most ISP’s are to lazy to implement real security. If all those connections would’ve been encrypted, it would’ve been nearly impossible to get all that data. Crazy and scary at the same time :-P.