Intercepting HTTP(S) traffic and acting as a man in the middle is very easy with network security tools such as Ettercap and Pineapple. We include HTTPS as "hackable" since many secure embedded web server enabled products ship with a non trusted certificate and acting as a man in the middle is just as easy as with HTTP when the certificate is not trusted. We will dive more into this further down.
A man in the middle can easily extract credentials from the embedded web server as we will show later in this tutorial, but an adversary can do so much more by injecting, for example, the Browser Exploitation Framework and potentially get into other sites such as the users bank account or other sensitive sites the user may currently be logged into. In other words, a non secure web server, including non trusted HTTPS web servers, opens the user to an array of attacks not limited to the embedded web server.
The following video, produced by Troy Hunt, a Microsoft Director, shows how important it is to HTTPS enable any web server in order to protect the user from cross-site scripting via, for example, the Browser Exploitation Framework. We recommend viewing the video in full as it is very informative.
Towards the end of the above video, Troy shows how HTTPS protects the site with a warning appearing in the browser when a man in the middle intercepts the HTTPS traffic. Most TLS enabled products ship with a non trusted certificate. TLS is rendered useless when the certificate is not trusted and when the user is forced to bypass the browser security in order to access the server. The user cannot differentiate between a man in the middle and the non trusted server's certificate. We will later show examples that simplify and automate the certificate management.
Most products with an embedded web server are deployed within private networks and most users would think a private network is secure, but what if an adversary gets into your building or your customer's building and uses a computer he finds in any cubicle to form his attack? All he would need is a USB stick and a custom Linux version. The adversary would not even need to enter the building if the private network is WiFi enabled and if he cracks the WiFi password. The Pineapple has built in Aircrack-ng and can be used to potentially crack your customer's WiFi network.
One of the easiest man in the middle attacks is to poison the ARP cache by using Ettercap. In short, ARP poisoning is the act of hijacking the address of a machine on your network. The basic principle behind ARP poisoning/spoofing is to exploit the lack of authentication in the ARP protocol by sending spoofed ARP messages onto the LAN. ARP poisoning is pretty easy to perform as the following video shows:
The obvious choice is to TLS enable the embedded web server product, but as explained above, most TLS enabled products ship with a self signed certificate, making the product no more secure than a product without TLS. A TLS enabled web server is only secure when the browser trusts the server certificate since a browser user cannot see the difference between a man-in-the-middle machine and the actual device if the certificate is not trusted.
In short, a certificate is trusted if:
The signer of the certificate is a so called Certificate Authority (CA) and this certificate must be pre-installed in the browser's certificate store. See the Certificate Management for Embedded Systems tutorial for a general introduction to Public Key Infrastructure (PKI) and Chain of Trust.
If your customers are PKI experts, they may opt to operate as their own CA, by for example using the Certificate Management Tool, and create a complete chain of trust for the embedded web server enabled products they have deployed on their local network. However, PKI is fairly complicated so make sure to check out the article Automatic Certificate Management for Devices, which presents two solutions for enabling configuration-less installation of trusted Let's Encrypt signed certificates.
We all love unicorns and rainbows, right?
Disclaimer: the above can be prevented by setting a "script-src" content security policy directive in the server's HTTP response.