Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Results 1 to 7 of 7
  1. #1

    EAP115-Wall multiple vulnerabilities found

    Model : EAP115-Wal

    Hardware Version :

    Firmware Version : 1.0.0 Build 20161117 Rel 57879(4555)

    ISP : [/COLOR]

    Just purchased EAP115-Wall, Firmware 1.0.0 Build 20161117 Rel 57879(4555). Acording to your website this is the latest firware available for this device.
    I set it up and run a security scan on this box. Results are shocking (see attached pdf report) 4 High and 5 Medium vulnerabilities identified! . Needles to say this thing is going back.
    Are there any plans of fixing this?
    Attached Images
    Last edited by alfwro13; 10-25-2017 at 08:15.

  2. #2
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,127
    Please can you describe the high risks in greater detail if you:

    - don't expose the EAP's web UI to the Internet,
    - don't run online banking services or shop systems with credit card processing directly on the EAP,
    - use the EAPs in an isolated, secured intranet only,
    - establish usual security measures for management of EAPs?

    Im really curious to what extend the well-known weakness of HTTPS for a device's web UI can pose risks over standard HTTP.

  3. #3
    Well if you don't mind that someone might be snooping on you/your users then you are good (i.e. OpenSSL CCS Man in the Middle Security Bypass Vulnerability)
    Read: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

  4. #4
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,127
    I know what MITM attacks are. If "someone" is able to snoop on my users using a MITM attack, then I really have a much bigger problem then just HTTPS/SSL weakness. This would mean that this "someone" has already broken into my intranet.

    Again my question:

    What are the exact "huge risks" in an isolated intranet if using a weak HTTPS/SSL instead of an unsecured HTTP for a web UI of an EAP?

    Or let me ask this way:

    Are you really applying criteria for mission-critical, fully exposed Internet (!) server systems carrying sensitive data such as credit card numbers to a web user interface of an EAP in an isolated intranet?

    If so, I guess you don't apply security measures in your intranet when exposing certain uncritical services in a WiFi network, do you? If you deploy business WiFi solutions (remember: this is the business forum, not just some home user's corner) and you don't take measures to deny any access - be it public or private to the company - to the mgmt infrastructure of your network devices, then yes, you should indeed be concerned about weak SSL ciphers.

    But even if strong ciphers will be used for the EAP's mgmt interface, I would never ever expose this mgmt infrastructure to regular WiFi users and I would not count on a dumb AP to secure its web UI by just using (currently) strong ciphers which might become weak as early as next month as history of SSL did show many times.
    Last edited by R1D2; 10-25-2017 at 17:44.

  5. #5
    Is that how you justify yourself for using insecure products? I bet that is why the product is insecure because of this kind of approach to security by "professionals". Sure all those threats can be easily mitigated but that is not the point

  6. #6
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,127
    Quote Originally Posted by alfwro13 View Post
    Is that how you justify yourself for using insecure products?
    You are completely missing the point.

    You claim that the SSL weakness of an AP's web UI would enable "someone to snoop on [other] users" of that AP. That's horribly wrong.

    No-one can "snoop on users" using a MitM to the web UI of an AP. Someone could exploit the SSL weakness to snoop on users only if the user's devices use weak SSL ciphers or the servers visited by those users use weak ciphers. And yes, those SSL versions need to be up-to-date since they are exposed to the Internet.

    But back to the AP: this "someone" can't even snoop on the admin user connecting to the EAP unless this someone already gained access to the internal network or the admin exposes the web UI to the public, which is a no-go. So someone can't break into the EAP unless he already has broken into the internal network. That's my point.

    There are certain superior security measurements which need to be in place to secure administrative access. So, if you expose the admin UI to the Internet, then you're at risk and then I would call it a "huge security risk". But since it is insane to expose internal networks to the Internet, I would call it a minor issue in terms of security wether the web UI is safeguarded with strong, with weak or with no SSL security at all. In fact, I even don't use SSL in my administrative network only because there are much stronger security measures in place such as an isolated mgmt VLAN (isolated subnet inside an isolated intranet, double secured and supported by every EAP), which makes it impossible for anyone outside to gain access to any internal device's web UI using a MitM, even not employees with approved access to the company's regular network.
    Last edited by R1D2; 10-27-2017 at 18:58.

  7. #7
    A false sense of security is worse than no security at all. If your visitors/guests/users/ne'er-do-wells can access the management interface of the access point in the first place, I'd say you're doing it wrong.

    The proper approach, as R1D2 alluded to, is to ensure that the access point isn't reachable in the first place, rather than relying on in-built security measures that will inevitably become obsolete. His particular setup has multi-layer access control:
    1. His intranet is isolated from the internet; this limits attack vectors to those who can gain access to the intranet in the first place
    2. Within his intranet, the access points are only accessible from the management VLAN. If you're using the right switches, users can't modify their own VLAN tags to jump into this isolated VLAN, and thus you can logically and/or physically restrict access.
    3. At the very end, even if someone gets themselves tagged to the management VLAN, actually executing a MITM will be difficult because properly configured switches won't be sending traffic between a legitimate admin and the EAP management interface to any port other than those two devices, so the connection can't be spoofed, eavesdropped, or otherwise compromised unless the bad actor manages to compromise the access point itself and gain root access to it.


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Copyright 1996-2017 TP-LINK Technologies Co., Ltd. All rights reserved.