Today we have a guest contribution from Dave Goldberg. Dave is a embedded software engineer based in Boston, Ma. He enjoys the problem solving, the mentoring of junior engineers and preaches the importance of quality and security. You can find Dave on LinkedIn.
In this article we will examine how a certain Wi-Fi connection sensor (in this case a radon sensor) communicates with “The Cloud” and how we can use this knowledge to reduce our dependence on third-party servers. There are two reasons why we might want to do this: (1) to get programmatic access to the data if the manufacturer does not provide any APIand (2) the use of the device continues to be when the company runs out of business or decides to close its servers.
Table of contents:
- Who does the sensor speak to and how?
- What is DNS?
- What is TLS?
- Replace your server with our own
- Do something with the data
- Pack up
Who does the sensor speak to and how?
I started to record and analyze the data traffic between the device and server. I connected the device with a Wi-Fi access point (AP) where I could run tcpdump This is how you capture the entire network traffic. Here is an interesting section of the recording, as shown in Wireshark.
First there is a DNS query (Domain Name System) for the server address and then an answer to the query.
Next comes a TLS handbeat between the device (client) and server to set an encrypted data session.
Finally we see the TLS encrypted application data.
If the data was sent to plain text, we could simply monitor the traffic of the device and pull off what we want. Since it is encrypted, we have to try something else.
First, we will examine the two types of the network traffic we identify, DNS and TLS and then try to find a susceptibility to security that we can take advantage of.
What is DNS?
DNS server (Domain Name System System) Translate Domainname IP Addresses. The complete DNS ecosystem is complex. Fortunately, we just have to look at what happens to a DNS request before you get to a “real” DNS server. Some devices explicitly set their DNS server address (popular examples are 1.1.1.1 or 8.8.8.8). Devices will often query the gateway of your local network, which will then forward the query. For this reason, in our example we see the device (192.168.8.133) the AP (192.168.8.1). Gateways can be configured in such a way that a DNS server is used to choose the administrator. However, a typical home network uses the standard that is provided either by the bought router or the purchase router ISP. A DNS query and answer in a simple network looks like this:
A popular method for blocking ads is the use of a local DNS server such as PI-Hole, Adguard Home or Blocky. These servers use block lists to prevent queries from serving for known advertising for advertising, while forwarding enabled inquiries to “real” DNS servers. This prevents the display from being loaded. By configuring your gateway so that you use your local ad-blocking DNS server, each device uses your local server in your network, unless this device is explicitly configured.
This is how DNS queries look in my home network:
What is TLS?
Most website traffic traffic are encrypted nowadays via TLS (Transport Layer Security). TLS is involved when you have URLs that start with “HTTPS” and see the small blocking symbol next to the address bar of your web browser. Safe communication with a server begins with a TLS handhake. The hand shake certainly changes a secret key with which data can be encrypted between the client and the server.
The Handshake also offers the server the opportunity to present its “certificate”. The should to be used to determine the confidence of the server to ensure that the server is asserted and checked by a mutually trustworthy entity. However, maintaining the corresponding chains of trust on a embedded device is difficult. Certificates expire and require a safe exchange and work with TLS during development hinder Debug. Developers often take abbreviations to make life easier.
Replace your server with our own
What if this device does not check the server certificate correctly? Could we pretend to be “the cloud” and let the device speak to our own server instead?
In order to test this hypothesis, we need a web server and a way to answer the DNS query for the server -URL. The device tries to speak to the IP address of our custom server.
For the web server I asked Chatgpt to create a simple web application python That would deal with TLS connections. AI is imperfect, so after some processing I have this very simple web application that shows us how the device tries to send data.
import http.server
import ssl
# Define an empty request handler
class SimpleHandler(http.server.SimpleHTTPRequestHandler):
pass
# Set up the server
server_address = ('0.0.0.0', 443)
httpd = http.server.HTTPServer(server_address, SimpleHandler)
# Create SSL context and load the certificate
context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain(certfile="server.pem")
# Wrap the server's socket with SSL
httpd.socket = context.wrap_socket(httpd.socket, server_side=True)
# Start the server
print("Serving...")
httpd.serve_forever()
Next we have to generate a certificate for the server. The following command creates a “self -signed” certificate. This certificate would not trust a rational actor, but we hope that the device will not take care of it!
openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodesAfter all, we have to control how the server url is fixed. I use Blocky in my network as an ad blocker. Blocky supports a custom DNS mapping so that we can find that a DNS query for a specific URL is fixed for the IP address of our selection. In this case we say blocky that we should answer a question for a question api.cloud.ecosense.io With the IP of the server in the local network.
After the DNS query is answered with the IP of our local server, we receive data traffic from the device to our local web server!
Serving...
192.168.8.133 - - (03/Oct/2024 16:36:10) code 501, message Unsupported method ('PUT')
192.168.8.133 - - (03/Oct/2024 16:36:10) "PUT /api/v2/radon HTTP/1.1" 501 -
In the server edition we see that the device makes a put requirement. If the device were validated by the server certificate, it would not bring it that far so that our certificate was accepted. Let us add a handler to the PUT request and print out all the data received from us.
# Define a basic request handler
class SimpleHandler(http.server.SimpleHTTPRequestHandler):
def do_PUT(self):
content_length = int(self.headers('Content-Length'))
body = self.rfile.read(content_length)
print(body)
self.send_response(200)
The next put request shows a comprehensive data dump:
{
"serial_number":"XXXXXXXXXX",
"d_type":0,
"p_time":17180,
"d_status":2,
"radon_level":61,
"radon_dou":28,
"d_debug":{
"FW_MODE":0,
"PUT_CNT":1832,
"PUT_ERR":13,
"PUT_STS":4,
"PUT_T":10,
"D_RE":1,
"F_RE":0,
"OTA_CHK":"0000",
"W_RECONN":0,
"IP_L_CNT":0,
"SEND_S_TS":1031103719,
"SEND_E_TS":1031105887,
"ERR_7004_LEN":125,
"ERR_7004_1":0,
"ERR_7004_2":0,
"ERRORS":(
{
"cmd":"00ca",
"sts":9,
"ts":3625523641
},
{
"cmd":"00ca",
"sts":9,
"ts":126702
}
)
},
"c_factor":1.13,
"fw_version":"1.09.A"
}
Do something with the data
Fortunately, the most important data is clearly marked and we can ignore the more nebulous elements. The interpretation of the data is up to us, but we can often use logic to derive the corresponding units. For example based on what I expect to see in my room, the prisoners have radon_level is reported in Becquerels per cubic meter (BQ/m)3).
The next step is to put this data into a suitable logging/reporting system, but this is a project for another day.
Pack up
We have achieved our goal to reduce our confidence in the “cloud”. We also learned a few lessons about security:
- Every step is important!
- The encryption of traffic is great, but communication can still be insecure if it is sent to a place other than the expected recipient. Especially with embedded devices for resource -related limitation, the correctness of security is demanding and it is tempting to make abbreviations.
- DNS can be a data protection problem!
- Your network administrator, your ISP, your VPN provider -everyone can see your DNS data traffic, which means that he can monitor and log the websites you have visited. The encryption of DNS data traffic is possible with DNS via TLS (DOT) or DNS via HTTPS (DOH), although these methods are often not activated by default.