This was originally published on Benscomputer.no-ip.org in 2009
I've been having a bit more of a play about with the adaptors, wondering what other weaknesses lay within. So far I haven't found a vast amount, but I have found a potential DoS attack that could be used by a local attacker.
First, a bit of information about what makes the adaptors tick, I got the trusty screwdriver out and opened one up. Some of this information is available on the net, but I only found it by searching for chip names/numbers to find out what each one does. So to get it all in one place;
The Adaptors are powered by an 'Aitana' Chipset, manufactured by DS2. To be more specific, the main processing is handled between a dss7800u chip and a dss9101u chip. Given the size of the latter, I would presume that it contains the main CPU.
More information on the Aitana system can be found here.
This is supported by an Etrontech em638165ts-6g chip, providing DRAM.
The Ethernet side of things is largely handled by an IC+ ip101a lf chip. This is purely a transceiver, so most of the processing must still take place within the Aitana system.
I had been hoping for some form of flash memory to play about with, but as the Aitana is a System on Chip (SoC) implementation, this angle of attack was narrowed down greatly.
Although I haven't yet played aroudn with it, the ethernet board interfaces with the Mains Network Transceiver using a 10 pin interface. At least two of these must provide power to the ethernet board, so it seems likely (in my mind at least) that the other 8 pins could simply be an internal version of a CAT 5 cable. Like I say, haven't actually checked it yet, so it's only speculation.
Now the management interface is provided via a HTTP server, so I figured it would be worth seeing if there were any known exploits for the server, unfortunately the server doesn't provide servertype in its headers, and if you try and fool it into releasing the information by causing a 400 error, it simply closes the connection.
Being unable to identify the server (it's possible that it's an inhouse solution) I tried crafting a buffer over-run exploit.
Whilst so far I've failed to run code on the remote machine, I have managed to force the adaptor to drop all packets for approx 20 seconds, before restarting itself. A attacker on the local network could run a script to execute this command every minute or so and effectively deny access to anyone beyond the adaptor.
It's also likely that if someone were to craft a 'network sniffer' for one of these devices, they could run a similar attack from 'Mains Side'.
This attack is likely to have little effect on a small home network, after all if an attacker has that kind of access, they could probably just hit the standby button. But if used on a corporate network (I imagine some small businesses may have considered their use) an employee with a grudge could use it, whilst the effect of such an attack on an adaptor connecting to one other adaptor should be reasonably limited, if the adaptor is acting as an AP for a one to many connection, it could disrupt a large number of nodes.
Similarly if the connection is one to one, if the adaptor attempting to connect to the targetted adaptor is conencted to a switch or a hub, the attack could quite effectively disrupt network comms for a large number of nodes.