broadband routers security issues

Fri Feb 23 19:26:39 UTC 2007

gadi,

thanks for raising this issue.

i am aware of numerous similar problems.  so are the spammers, click
fraud artists, and other parasites who have written tools to take over
customer and ISP bandwidth and ip addresses (to the maximum extent possible
without killing their host).

so let me summarize the problems in this case (to save you same reading):

1. default admin account and password for use by customer (provided by manufacturer of device?).
2a.  secret logins for use by ISP (not disclosed to customer)
2b.  secret logins for use by ISP use passwords for authentication and telnet for connectivity
2c.  secret ftp access for use by ISP
3. customer-end equipment contains accessible authenticators (passwords) which can be cracked 
easily using reverse engineering plus dictionary or brute force.
and a few others (not pointed out by sid)
4. no tamper evidence for remote access or configuration of the device (should someone unauthorized 
get to it) means the customer is unaware of tampering.
5. the ability for a bad guy to upload sniffing software to these devices and capture traffic
on the inside network.

some proposed solutions:
1 should be illegal.  there should be no default enabled remote access 
to security devices which allows uncontrolled alteration of the device's 
configuration or behavior.
2a. should be illegal.  there should be no undisclosed backdoors in
devices, particularly in security devices.  there should be explicit 
understanding of who gets to administer a customer-end device, and 
if the device is owned by the customer, the ISP should need explicit 
authorization to manage it, absent other clear understandings.

on a larger scale, my belief is if we had product liability for back
doors they would be much less common.  my understanding is this is
common in that docsis (and successors) devices often have some sort of
ISP remote access built in, but others can chime in on that if they
want.  (in countries where there is a practice of social control of
communication or surveillance of domestic comms, this disclosure is
even more important as the possibility of govt or "patriotic hacker"
abuse is significant.)

item 2b and 2c. could have been rendered less of a problem by using 
1. ssh/scp instead of telnet/ftp
2. secret logins with customized passwords which are a function
of some shared secret (e.g. a keyed hash of the mac address is common)
or an ssh certificate.    (note that if remote access is enabled by default
and leaks the shared secret better to use PK crypto where the client end 
only has public information).
3. limiting access to such protocols to particular ip addresses.  this
would require competent provisioning (or post-provisioning) on the
part of the isp.

(if these measures were revealed to the customer, they could decide
the extent to which they trust their ISP to log in, but at least
they'd expect this would be limited to their ISP).

item 3, 4 and 5 are difficult or expensive to prevent in that they
require something like a TPM or other fips140 hardware.  so this is
unlikely to be practical for a device with a retail cost of $20.
(and that reverse engineering was possible made knowing about this flaw 
possible.  kudos to sid.)

just to speculate on some cheap ways to prevent software updates: 
1. require a special state (e.g. button to be pushed) to update the
firmware (difficult given that code and configurations are probably
both in the same store).
2. require software updates to be customized by signing them for the device 
incorporating something in the hardware

and i suppose remote access or config changes could be made more
visible (through logging, external logging, or even a flashing LED 
that would need to be reset manually along with tools for diffing
against known images).

i admit these are likely to be practical for most end-users, but ISPs
should be able to easily detect alteration of the devices they are 
authorized to manage.

On Thu, Feb 22, 2007 at 01:35:36PM -0600, Gadi Evron wrote:
> 
> Hi guys. A guy named Sid recently wrote on securiteam (where I write
> as well) on an accidental discovery he made on the security of his home
> broadband router with its default settings.
> 
> Apparently, he started by discovering he had port 23 open (which was
> telnet for the router rather than for him - we have all been there
> before).
> 
> He researched it a bit further and came up with a disturbing analysis on
> how these routers can be easily compromised and a rough number on how many
> of these exist at his ISP.
> 
> The subject of broadband routers/modems security has been bothering some
> of us for a while, as they'd make scary botnets, not to mention in some
> cases, as had been noted also here before, open recursive name servers.
> 
> Public discussion of this has been limited up to now, but with the recent
> releases of exploits for such home routers and several public advisories
> on the issue, I figure it is time for us to see if we can start working to
> a change in how we do things in coming years (at least with new devices we
> give out).
> 
> Here is his text. You can also find it and the discussion on it at:
> http://blogs.securiteam.com/index.php/archives/826
> 
> Accidental backdoor by ISP
> 
> February 22nd, 2007 by Sid, Filed under: Privacy, Full Disclosure,
> Corporate Security
> 
> I.ve been a happy customer of my ISP BeThere for a few months now. Overall
> they.re great, they are quick to sort you out with your connection, their
> emails and other communications are very humerous and actually make good
> reading (I remember the routers documentation CD has a warning label
> reading something like .warning: geeky content inside.). When I signed up
> I managed to get the username root, this pleased me no end and I thought
> I.d finally found an ISP I want to stay with forever.
> 
> Finding the hole
> Recently though a friend of mine was extremely bored and decided to nmap
> my IP address. He found, and told me, that I seemed to be listening on
> port 23, telnet. I was extremely puzzled by this, I haven.t port forwarded
> port 23, I would never use a telnet daemon for anything. It occured to me
> that it must be the router itself running the daemon. I telnetted to
> 192.168.1.254 and lo and behold it asked me to log in. I log in with
> default credentials (yes, I had never gotten around to changing those),
> which are Administrator:null
> 
> I get welcomed by some neat looking ASCII art and command line access to
> my router. I didn.t even know my router had telnet access but I quickly
> log out and set a password via the web interface. Now I should be
> secure. Wondering if others could telnet to my router from a remote
> location I ssh to a remote machine I have access to then telnet back to my
> router from there and try logging in. I.m reassuringly told that this
> account can not log in through the WAN interface (so thankfully I can only
> log in from within my LAN).
> I log back in to the telnet daemon from my LAN to see what.s there, I find
> this:
> 
>     {Administrator}[user]=>list
>     User Flags Role
>     .- .. .-
>     Administrator U Administrator
>     tech R TechnicalSupport
>     BeTech TechnicalSupport
>     bebox root
> 
> Keep in mind that according to the web interface only the Administrator
> account even exists. What the hell are all these other accounts? Thinking
> back to the error I got when trying to log in from a remote location I
> wonder if any of these accounts are capable of logging in from remote
> locations. I try logging in as BeTech from the remote connection (guessing
> it to have a blank password), it gives me an incorrect password error. How
> can I find the password to these 3 anomalous accounts?
> 
> Time to look through the configuration. Like most routers it.s possible to
> back up the settings file, in the case of this router you ftp to the
> router, browse to /dl/ and download user.ini. This file has all the
> settings in it. I copy that file to my home directory and search for the
> word BeTech of it. Here.s the output:
> 
>     [ mlpuser.ini ]
>     add name=Administrator password=_CYP_removed role=Administrator
> hash2=removed defuser=enabled
>     add name=tech password=_CYP_bde1d7887b5852ff5c3c853c0ffbc413
> role=TechnicalSupport hash2=bb80a4cf4f721b0fe42f24581479bebe
> defremadmin=enabled
>     add name=BeTech password=_CYP_d8b5399c8b961eca15a56b659c2ee622
> role=TechnicalSupport hash2=cd4f202f8e92f7c11f40bc86fe66443a
>     add name=bebox password=_CYP_0fbd2e7e6dc947c44def9053fb79e8c8
> role=root hash2=90960596e9eec3d017b31f6efb8892ea
> 
> A short time later I had the password of the BeTech account to be RemAcc
> (for some reason I didn.t bother looking at the other accounts). I don.t
> know what the hash2 value stands for, wasn.t interested. I try logging in
> with BeTech:RemAcc from my remote connection and lo and behold it works. I
> figuratively crap myself. First things first; I look for ways to change
> this. Sure I could change the password but there.s got to be a way to stop
> the telnet daemon from listening on the WAN. Sure enough, I find the line
> ifadd name=TELNET group=wan
> I simply remove the line. Slightly below I see
> ifadd name=FTP group=wan
> I remove that too. I upload the user.ini file replacing the existing one
> and reboot the router. I.m safe.
> 
> Exploiting others
> 
> Time to see if I can log in to others. routers using this. I run nmap -p
> T:23 87.194.204.0/24. This gives me a list of people who are probably
> running the same router. I FTP to those IPs and grab /dl/user.ini.
> Most of these people have changed their Administrator password, but my
> money says none of them knew about the other accounts. Now I have full
> access to FTP in to their routers even if they have changed their
> passwords, I have full read and write access to things from DNS details to
> DMZ settings, from Wifi passwords to VPN keys. I can then upload the new
> file back to their router, log into it.s telnet daemon and load the new
> settings file.
> 
> >From the account name I.m going to guess that it was made as a technical
> support account by my ISP so if I call them up saying I have connectivity
> problems and all the normal stuff is ruled out they can connect straight
> to my router themselves and peek around. In a way it makes sense for them
> not to use SSH as that of course requries more stuff, and it may just be
> that stuff which is broken. There are better ways to do this though, one
> would be to have an ID printed on the router which I would give to their
> tech support which they use to calculate the BeTech account.s
> password. Alternatively let us easily turn off this setting and if we need
> tech support and we can.t enable it we.d just hit the reset to factory
> settings button.
> 
> Pretty much all the customers of my ISP are now vulnerable to this. The
> only ones who aren.t are people who.ve fixed this, people who have port
> forwarded port 23 and 21 (as port forwarded ports take priority over
> daemons) and of course people who don.t use the router the ISP supplies.
> 
> Kuza55 of sla.ckers.org scanned a much larger number of users; nmap -oG
> bewhole.txt -vv -sS -p23 -P0 87.194.0.0/16
> He got 14716 potentially vulnerable routers but he couldn.t reliably check
> which were actually vulnerable and so dropped his research. Feel free to
> try to finish what he started.
> Securing yourself
> 
> Incase you are running the router BeThere supplied, here.s how to fix
> it. FTP to 192.168.1.254/dl/ and download user.ini. That is the default
> IP, I assume you know how to find the IP if that.s not what it is. If
> user.ini isn.t there, telnet to the router (same IP). Type:
> 
> config
> save
> It.ll ask for the username, type user.ini and hit return
> FTP to the router as I said earlier and grab the file.
> 
> Back up your user.ini file just incase, then open it. Find the heading [
> servmgr.ini ] which is around line 771 (though it won.t be exactly there
> for you). Scroll down another few lines and you.ll find four lines:
> 
>     ifadd name=FTP group=lan
>     ifadd name=FTP group=wan
>     ifadd name=TELNET group=lan
>     ifadd name=TELNET group=wan
> 
> Remove the two ending in wan. Connect again with your FTP client and
> upload this new user.ini file replacing the old one. Either reboot your
> router through it.s web interface or log back into the telnet daemon and
> type:
> config
> load
> The telnet connection will die, that.s fine, in 30 seconds or so you.ll be
> online again with a safe router. Check with nmap-online that you.re still
> not listening on FTP or Telnet. 