Overview - All GL.iNET IoT devices use the same default self-signed HTTPS cert, meaning the traffic can be decrypted or modified using a Man-in-the-Middle attack.
Description - HTTPS is a protocol that uses HTTP for web requests and responses, but with SSL/TLS encryption on top of it. The communication is encrypted through the use of a certificate with the private key being kept secret - knowledge of this private key allows any intercepted traffic to be decrypted or modified. This would allow an attacker maliciously placed on the network to intercept sensitive information, such as authentication tokens, which would allow them to run arbitrary commands on the device. This certificate is self-signed and a warning will show up on most browsers, but this is not because the HTTPS connection doesn’t encrypt the data. The traffic is still encrypted, however the certificate is not authorized by a trusted authority (and for good reason). Dynamically generating different self-signed certificates for each GL.iNET device would allow the traffic to be encrypted and prevent Man-in-the-Middle attacks.
Steps to reproduce - A list of publicly-available GL.iNET devices with the same SSL certificate can be found using this Shodan query. Note how the SHA 256 fingerprint is the same for each site, regardless of the model. The corresponding HTTPS private key can be extracted at the location /etc/lighttpd/server.pem from any GL.iNET device, and is also provided below.
SHA 256 fingerprint - 97 B6 C5 3F 60 45 8B BE 47 27 9B 87 B1 67 87 6F 49 D3 2C DC B6 A5 84 D8 E4 FC CA 9E AF 53 AC 24
Fix
This was not fixed in 3.216. In a follow-up with the company, they said “The router is supposed to be accessed locally and http is fine… The user can replace the certificate manually. If the user [does] not have knowledge/skills to do this, they should just use http and [not] access the router from [the] WAN side.”
Note - a request for a CVE has been made but I haven’t heard back yet. I’ll update this when I know