Websites, otherwise known as web applications, need no introduction. At the very least, web applications contain frontend HTML, JavaScript, a backend web server, an application server, and a database. As web applications progress, heavy reliance on frontend code such as JavaScript is utilized more often in order to take the computational load off of the backend infrastructure or device. Web applications on the greater internet are slightly different than the web applications that are served via embedded devices.
The web applications you are used to have many more dependencies including the separation of web servers, application servers, database servers, as well as micro services that run in the backend. Separating each server is due to performance and availability reasons. Traditionally, embedded web applications are designed to run in their own self-contained environment. In a broad sense, there is less of a focus on performance and availability for embedded web applications.
There are two different models of web applications being utilized within the IoT space today, such as the hybrid cloud model and the embedded server standalone model. The hybrid model is a mix of the vendor or manufacturer providing Software as a Service (SaaS) web application(s) and also connecting the embedded device's web application running off of the firmware. The data is then synced from the manufacturer's cloud with the embedded device on the device's local network. For some IoT devices, IoT cloud service provider SDKs are utilized, such as AWS' IoT SDK and Azure's IoT SDK, and are built into the device web application stack. Recognizing a hybrid model is important in order to stay within a company's terms of service as well as within the legal bounds of your region. Many IoT companies who do utilize a hybrid model often use a third-party software development firm or ODM to host their web application on behalf of the OEM. These ODMs' web applications are usually rebranded for the specific OEM product, which can go unnoticed without proxying the communication.
A hybrid cloud model with IoT devices that have internet capabilities may look like the following figure. A user accesses the device's interface, where web services between the vendor's cloud and the user's device makes changes or collects data behind the scenes:
Figure 1.2 Hybrid web model
Embedded device web applications are, as mentioned, running internally off the device's firmware utilizing an embedded web server such as lighttpd or nginx with no outside dependencies. You might be familiar with these standalone embedded web apps, which are known to be run on printers, VoIP phones, and home routers. Quite often, input is sent directly to the device firmware, and if the user input is not validated or sanitized, attackers can perform arbitrary command execution within the device's context. In some cases, embedded web applications are designed to operate only within the Local Area Network (LAN) to protect from outside attacks or for administrative purposes. This can be the case for home IoT, industrial, and commercial devices. Often, having devices only available locally to a LAN is for security purposes, but as we have learned, this is not a stopgap for mitigating attacks. Device makers who design products with this intent are learning that customers are knowingly or unknowingly putting their devices on the internet, posing a risk to customer networks.
The following diagram demonstrates a user connecting to an embedded standalone web application via a web browser without outside system dependencies:
Figure 1.3: Local embedded web application
The communication between browsers, embedded servers, and web application servers is typically done through a web service such as Simple Object Access Protocol (SOAP)/XML or an API which is based on Representational State Transfer (REST) over HTTP/HTTPS. SOAP requests consist of an envelope element, an xmlns:soap namespace, an encodingStyle attribute, and various elements such as the SOAP body element. Additional details on SOAP can be found by visiting the following link: https://www.w3schools.com/xml/xml_soap.asp.
An example of a HTTP SOAP request querying for an account balance is shown here:
POST http://example.com/soap/webservices HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Authorization: BasicYWRtaW46YWRtaW4=
Content-Length: 821
Content-Type: text/plain;charset=UTF-8
DNT: 1
Connection: keep-alive
Host: example.com
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://example.com/webservices/BillingAccountSummary/V1">
<soapenv:Header/>
<soapenv:Body>
<getAccountBalance>
<messageHeader>
<action>get</v1:action>
<scopeObject>AccountBalance</v1:scopeObject>
<revision>1.0</v1:revision>
<createdTimestamp>2017-01-13T09:15:01.469</v1:createdTimestamp>
<sourceInterface>WEB</v1:sourceInterface>
<messageIdentifier>00810187-101EDDA4</v1:messageIdentifier>
<functionName>getAccountBalance</v1:functionName>
</messageHeader>
<billingAccountIdentifier>1234566</v1:billingAccountIdentifier>
</getAccountBalance>
</soapenv:Body>
</soapenv:Envelope> REST style APIs utilize various HTTP methods that may not be standard in traditional web applications, such as the PUT method, to update resource values as well as DELETE methods to remove values within an API. REST requests can utilize parameter calls via the URL (not recommended for sensitive data) or via the HTTP body in JavaScript Object Notation (JSON).
An example REST request subscribing the [email protected] email address to an email distribution list is shown here:
POST /rest/email/subscribe HTTP/1.0
Host: example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/json
Content-Length: 160
Connection: close
{
"subscriberId":"12345",
"emailAdress":"[email protected]",
"confirmed":"Y"
} In order to view SOAP or REST requests, a man-in-the-middle proxy is required. Tools such as Burp Suite and/or OWASP ZAP are used as web proxies to view all requests being made from the browser and the mobile application to the application's web backend infrastructure. We will go through setting up the configuration to proxy the application traffic later on in Chapter 4, Exploitation of Embedded Web Applications.
As it pertains to IoT, web applications are a common way to control devices and are just one attack entry point from both the internal and external network perspective. In Chapter 4, Exploitation of Embedded Web Applications, we will learn how to identify common IoT web application flaws and exploits.