Accidental backdoor by ISP [updated x2]

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 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:

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_removed role=TechnicalSupport hash2=removed defremadmin=enabled
add name=BeTech password=_CYP_removed role=TechnicalSupport hash2=removed
add name=bebox password=_CYP_removed role=root hash2=removed

A short time later I had the password of the BeTech account to be [removed] (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:[removed] 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 x.y.z.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 scanned a much larger number of users; nmap -oG bewhole.txt -vv -sS -p23 -P0 x.y.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 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:

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:
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.

UPDATE: After talking to my ISP I have removed the IPs and the passwords from this post and all comments to this post. I have yet to conclude the talks with them but I hope to update this post back to its original form after a short while (a week or two).

UPDATE: virus has posted a perl script to automatically patch your box (even remotely). Though it is unconfirmed.

  • devloop

    removed = removed
    (Thanks )

  • CCC

    Wow that is cool, I wonder if they (ISP) can change this using some kind of remote update mechanism or not, I know that some ISP routinely send updates to the routers used by their customers.

  • Denis

    Does the EULA allows you to close that access ?

  • Sid

    devloop: thanks but, kuza55 had actually submitted the hashes to and the results were:


    The other 2 accounts have the same access as BeTech as far as I know.

    CCC: They can supply new firmware and yes, I’m pretty sure you can upload it to the router by FTP and then load it using telnet, though I doubt my ISP would do that.

  • devloop

    Thanks for the link, I didn’t know this database :)

  • Sid

    Denis, great question. With a law student sitting next to me in an only slightly impaired state (but to the effect where he can not be held liable to any of our actions (his words)):

    This is from
    You are responsible for ensuring that any member ID and/or password selected by you remain confidential so that the network cannot be used by any unauthorised person.

    The member ID and/or password referred to include, but are not limited to, those controlling access to (a) any computer hardware systems or networks; (b) any computer software or applications; or (c) any other services accessed by you in the use of either of the above.

  • Cd-MaN

    Hmm, what exactly was the point of this post? To put the consumers of that ISP at risk or to prove your 1337 nmap skills? I’m all for full disclosure when it helps in fixing or mitigating the flaw, but who exactly do you think you helped by publishing exact details like the ISPs name or the subnet address? Did you raise the issue with the ISP? Did they respond to you trying to deny the facts? Or what exactly prompted this post? The post could have been written very generically (with some ISP and leaving out the IP addresses) and it still would have been a good read. But no, you had to include them and write things like “Exploiting others” and “Feel free to try to finish what he started”. You do realize that not only was what you’ve done unethical, but also very probably illegal, given that you are in the UK, where laws are very strict about this!

  • Aviram

    Hi Cd-MaN,

    We will not get into the “Full Disclosure pros and cons” discussion every time a new post about a vulnerability comes out. We believe in Full Disclosure. Period. Not just because the alternatives are much worse, but because information will be free one way or another. You might as well hear it from an organized site from a fluent writer like SID than try to piece together incoherent comments on some message boards somewhere.

    If you want to debate on whether or not it’s ethical, I suggest you do it on the Full Disclosure mailing list. On this web site the debate is already settled.

    - Aviram

  • Sid

    By “Feel free to try to finish what he started.” I meant seeing how many people are vulnerable, not that you mess them over. Sorry if that wasn’t clear.

    I guess I could indeed have hidden my ISP’s name and the IP ranges it uses, but others (on various IRC servers and forums) know this stuff already and I don’t want to write something that is FD to some people and just an interesting read to others.

    Thanks also Aviram :)

    Lastly; I still think they are a great ISP and I’m still a customer with them.

    Update: I’ve been in contact with BeThere and I’ve removed the IP addresses that were scanned in order to protect the victims. They also “recognise this is a serious matter and will deal with it accordingly”.

  • virus

    Here’s a quick perl script I put together to automatically patch the hole.

    die “usage ./ ip\n” unless $ARGV[0];
    use Net::Telnet;
    my $telnet = new Net::Telnet(Timeout=>5, Errmode=>’die’);
    print “connected to $ARGV[0]\n”;
    $telnet->waitfor(‘/username : $/i’);
    $telnet->waitfor(‘/password : $/i’);
    print “logged in\npatching\n”;
    $telnet->print(“service system ifdelete name=FTP group=wan”);
    $telnet->print(“service system ifdelete name=TELNET group=wan\nconfig save filename=user.ini”);
    print “done\n”;

  • Sid

    Thanks a lot for that code virus. I’ve been forced (coerced actually) to remove the password from the code by my ISP, but if you run this router here’s what you do:
    Grab the settings file like I said in the post. Find the section I mentioned in the post. Find the hash to the account BeTech and run it through Insert that password into the code where I removed it.

    Also note that the patch is unconfirmed, but given how easy it is to check if it did work you may as well try it.

  • sunshine

    Erm, the broadband ISP world from the user router perspective is divided to two:
    1. Heavily exploitable (bring on your botnets).
    2. Run as a bridge.

  • Cd-MaN

    I’m happy that you’ve done the right thing and sanitized the article a little. I too believe in full disclosure – as a negotiation tool. But the first and foremost goal of every ethical security researcher should be: do no harm! I state my point again: who exactly were you helping by publicizing this information – as far as I can see no one. Who were you hurting – possibly many people.

  • Sid

    If I hadn’t originally published the passwords people like virus may never have bothered to create the script to fix the issue, though as it turned out I had to strip the password out of his fix too, making it harder for people to patch the issue themselves. Now instead they may have to wait for the ISP certified solution.

  • Cd-MaN

    Hello. I know that you don’t wish to turn this into a full disclosure debate (plus I think we agree on more things than you realize), I just wanted to let you know that I welcome any comments on my blog ( ) and will respond to them as soon as possible. The comments there are moderated only as a spam prevention measure and I will publish all (non-spam) comments in maximum 48 hours (but usually in a much shorter time).

  • Kanedaaa

    Start Test date:
    Sat Feb 23 14:09:27 CET 2007

    [about 16384]

    Open 23 port [count]:

    Open 23 port with backdoor default BeTech username and password [count]:

    They should fix it IMHO.

    Btw: Iam aware when someone put some new IE 0day bug and redirect DNS on routers to his site [some,, redirectors]

  • Sid

    That’s impressive numbers there Kanedaa. You’re saying that you were vulnerable to this and the flaw was maliciously exploited?

    Thanks for the numbers.

  • Aviram

    One thing that’s important to mention is that we got a call and an email from beThere just a few hours after the post was up. The message was polite and requested to remove the sensitive information while assuring us they are taking this issue seriously.

    If I were a beThere customer I’d be happy to know my ISP takes these things seriously; anybody can screw up, so it’s important how you fix your mistakes.

  • Sid

    I had no idea about that call and email. I hope to get a repy from them on Monday when they get back to work regarding virus’ perl solution, or at least what they’re up to. We’ll see how it goes.

  • prdelka

    I have a be* internet account, investigation of this issue revealed a few other sucky things about the FTP service. You can grab info on them from my blog – and the passwords for anyone who still needs.

    i will also be moving my provider promptly. i suggest anyone else does the same.

  • Pingback: Techmonkey

  • Sid

    For those of you keeping up on this. My ISP haven’t yet done anything about this (besides telling me they’re on it).

  • Neil

    They have now mate, and I for one am disgusted.

  • Simon

    Its probably a good idea to remove the HTTPs service on the wan interface too, so you cant remotely access the router’s web admin interface using the hidden accounts…

    ifadd name=HTTPs group=wan

  • Eddie

    Wow! Front page of TheRegister D:

    Great information.

  • Sid

    Thanks. and yes, I know I’m on TheRegister, I was in contact with Dan Goodin (who wrote the theregister article) extensively while he was writing it.

  • Owen

    while i think it would have been better form to leave out the passwords until giving the isp reasonable time to respond (say 30 days), i support full
    disclosure, and, the isps after-actions are unacceptable.

    as to sunshine’s comment, i’m willing to suggest that my dsl routers are neither
    highly exploitable, nor, running in bridge mode.


  • martin

    maybe you should have told the isp about the vunrability and see what they said before publishing the information and maybe you should have left the password blank so as to not allow people to exploit the vunrability as for the ip subnet well publishing that is just plain stupid

  • Werther de Goeth

    The way you wrote your orginal post lead the ISP to urgently write a new firmware and dispatch it without having the time to fully test it.
    By just informing the ISP without giving away details, you would have give your ISP more time to beta test. Now several thousand users are at risk because of your showing off attitude. I hope you will learn a lesson from that.
    Now, since you reversed engineer the user.ini without a “out-of-jail” card…

  • Jim

    Werther de Goeth, on April 18th, 2007 at 12:26 pm Said:

    The way you wrote your orginal post lead the ISP to urgently write a new firmware and dispatch it without having the time to fully test it.

    Excuse me, but what the hell is any sensible ISP doing putting backdoors on subscriber’s routers in the first place. They get no sympathy from me, if they hadn’t done something so bloody stupid in the first place they wouldn’t have to rush to fix it now.

  • Dan Harris

    Be were notified of this problem on the 15th March 2006 by email – I still have a copy of the email.

    Frankly given today’s libellous statement by Dana Pressman their MD I am surprised you are not suing Be.

  • Jason DePriest

    Dan Harris’ experience shows that if you politely inform the ISP without giving away critical information, they pay lip service and eventually forget about it.

    What Sid did, right or wrong, should not have been the catalyst to prompt the ISP to fix the issue.

    They had a whole year to work on a fix before the issue was publicly exposed via Sid’s full disclosure.

    They didn’t have to rush it through Q&A if they started when they were first notified.

  • AntiHero

    Sid was absolutely right in what he did. Apparently, if he had not published the exploit, they would have never gotten the bug fixed. They’ve had a year and done nothing. It was time to go full disclosure, and I hope somebody took the info from this site and fucks them up to show them what happens when you’re lazy about online security. Ethical hacking is here to prevent malicious hackers from getting the chance to do damage for long periods of time, but when a company does not respond to bug reports, the black-hats should be handed the details, and told to do as they will.

  • ed

    Is this fixed yet or what? I see funky looking settings in user.ini which suggest that logins using the backdoor accounts are limited to certain subnets now (I think):

    [ servmgr.ini ]

    ipadd name=HTTPs ip=
    ipadd name=HTTPs ip=
    ipadd name=HTTPs ip=192.168.1.[1-254]
    ipadd name=HTTPs ip=212.39.68.[249-254]
    ipadd name=HTTPs ip=192.168.0.[1-254]
    ipadd name=FTP ip=
    ipadd name=FTP ip=
    ipadd name=FTP ip=192.168.1.[1-254]
    ipadd name=FTP ip=192.168.0.[1-254]
    ipadd name=TELNET ip=
    ipadd name=TELNET ip=
    ipadd name=TELNET ip=192.168.1.[1-254]
    ipadd name=TELNET ip=212.39.68.[249-254]
    ipadd name=TELNET ip=192.168.0.[1-254]

  • Sid

    They may well have been fixed. Just earlier today I read this:
    Seems they did something

    Why did they have the daemons listen on .0.x and .1.x? If you change the router to issue IPs in the .123.x region, will those settings change to match that?

    I’d certainly like to know more about this fix they issued, of course I don’t have the fixed firmware myself, so I can’t test it myself. Ed: could you please email me the new config file? sakaru at gmail dot com.

  • Dave Matthews

    Very very interesting. I noticed this flaw back in January when I did a standard risk assessment. I simply killed off the ftp port, redirected the telnet port to a non-existant IP and I was protected.

    I was very surprized that I could not go to the config page of the router and turn it off made me suspicious.

    Everybody knows that telnet is bad. Anything providing a telnet port listening is asking for trouble. Why does one use SSH nowadays? This is what gave me the signal that someone obviously doesn’t take security seriously at BeThere!

  • Dave Matthews

    Just a note before I say something, don’t use the spell checker – it crashed my browser!

    I noticed during installing my server back in January that telnet and ftp was running on the BeThere Broadband router and was concerned. I managed to disable the FTP service running, but could not disable the Telnet service and was forced to map the port to a nonexistant IP address.

    The fact that the telnet port was open and listening is a signal that BeThere does not take security seriously and does not have any person in there department that is actually got a CCNA!

    Cheap…is not always best.

  • bt

    i got that stupid box running in bridge mode from day 1.

  • Mat

    I am in total agreement about the need for full disclosure, really encouraged by this post, but sick of hearing people whining about how the first instinct of a security engineer is to “protect the victims” – well, yes it is, but one does this by catalysing change, eloquently and courteously rather than covering up the detail – which frankly could be found out by ANYONE with an inquisitive mind – then politely requesting an organisation to sit up and listen.

    Experience tells us commercial organisations rarely listen until media take note – but in this case, they were given the chance and didn’t respond!

    Thanks for a great read.

  • gft

    Just came across this.

    Found my BeBox happily listening on telnet and ftp on the wan port. Looked at my user.ini file and found the hashes for one of the hidden users EXACTLY THE SAME as those I found posted on other web sites in early 2007. Looked deeper and found decrypted version of the (embarrassingly weak) password. Successfully logged into my BeBox as that user and changed the passwords to the hidden accounts, then disabled telnet and ftp on the WAN port.

    Get the feeling security is not very high on Be’s list of priorities – wonder if it even makes the top 10?

    …they are fast though.

  • nivr

    nixe work and fuck you people saying ur breaking the law its just helpfull info ; D