Background
I recently purchased a new air filter from costco, and its actually a
pretty nice unit: 
Only one problem. For some ungodly reason, its an internet of shit
device. It has built in wifi and an android app that both kinda
seriously sucks and provides functionality not readily accessible
through the physical controls on the air filter. This is unacceptable
for a number of reasons.
- My goddamn air filter is an internet connected device
- It has some kind of air quality sensor, and lets you view
information from it within the app, but the information provided in
the app has been massaged to the point of uselessness.
- I have no control over the software currently running on the device
- The device could potentially be monitoring my network and sending
data back.
- I can not (at least in a way I have figured out yet) turn off the
ozone generator without using the app. Moving the filter to a
different spot and getting it back to the settings I want is an
ordeal that requires fumbling through a shitty app and hoping it
works.
In this series of posts, I will explore the (ongoing) process of reverse
engineering my air filter, and hopefully figuring out how to pop a
custom firmware on it.
Without Cracking It Open
First, I want to explore what we can learn without cracking it open.
Packet Capture
Thankfully, my router runs OpenWrt, so I can do a little bit of packet
capture by looking up the air filter's DHCP lease, and pulling one of
these boys:
ssh root@router tcpdump -i wlan1 -U -s0 -w - 'not port 22' | sudo wireshark -k -i -
Filtering by the air filter's IP (in this case, 10.0.0.170) in
wireshark, then gives me the ability to inspect all of it's traffic:
Findings
Curiously enough, the air filter seems to be making repeated dns querys
for www.google.com at a set interval. Playing around with the air
filter and leaving the packet capture running for long periods of time
have lead me to a few conclusions:
- This dns query for
www.google.com is the only dns query the device
makes
- It never attempts to connect to the IP it receives in the response.
- The devices behavior does not change if I blackhole
www.google.com
in my dns server (change the dns server to respond with 0.0.0.0)
- The device does not make any DNS queries for that would correspond
to the
34.193.163.206 IP that the device is communicating with
- Aside from the DNS probe, the device does not appear to communicate
with any IPs other than this
34.193.163.206
Based on this information, my belief is that the device is using the DNS
query as some sort of janky probe for internet connectivity, and that it
doesn't care what the response is, just that it gets one. I also
believe the 34.193.163.206 IP to be hard coded into the device's
firmware (boo). This leads me to believe that this is probably an
incredibly simple device, and my be using a bare microcontroller rather
than the typical embedded linux.
On the bright side, the device is actually using TLSv1.2 for its
communication, though this hinders my RE efforts.
34.193.163.206
This IP belongs to amazon, and the rdns record for it points to
ec2-34-193-163-206.compute-1.amazonaws.com, which doesn't give us
much to go off of, other than the fact that data is flowing into an
amazon EC2 instance.
Port Scanning
My next stop is to throw nmap with OS fingerprinting turned on at it:
$ sudo nmap 10.0.0.170 -O
Starting Nmap 7.80 ( https://nmap.org ) at 2020-04-16 17:02 EDT
Nmap scan report for 10.0.0.170
Host is up (0.015s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
8088/tcp open radan-http
MAC Address: 84:72:07:32:3F:50 (I&C Technology)
Device type: specialized|general purpose|VoIP phone
Running (JUST GUESSING): NodeMCU embedded (98%), lwIP 1.4.X (98%), Espressif embedded (97%), Philips embedded (91%), Cognex embedded (90%), Ocean Signal embedded (89%), Grandstream embedded (89%), Rigol Technologies embedded (89%)
OS CPE: cpe:/o:nodemcu:nodemcu cpe:/a:lwip_project:lwip cpe:/h:philips:hue_bridge cpe:/a:lwip_project:lwip:1.4 cpe:/h:grandstream:gxp1105 cpe:/h:rigol_technologies:dsg3060
Aggressive OS guesses: NodeMCU firmware (lwIP stack) (98%), Espressif esp8266 firmware (lwIP stack) (97%), ESPEasy OS (lwIP stack) (92%), Philips Hue Bridge (lwIP stack v1.4.0) (91%), Cognex DataMan 200 ID reader (lwIP TCP/IP stack) (90%), Ocean Signal E101V emergency beacon (FreeRTOS/lwIP) (89%), Grandstream GXP1105 VoIP phone (89%), lwIP 1.4.0 lightweight TCP/IP stack (89%), Rigol DSG3060 signal generator (89%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.85 seconds
This doesn't give us too much to go off of, only one port open and nmap
left making an absolute crapshoot at what OS is running on it.
Pulling up a connection to this service on 8088 in a web browser reveals
two things, a service gated by http basic auth, and the headers from the
response reveal that it is, at least, using lwIP (also this device has
no concept of time):
HTTP/1.0 401 Authorization Required
WWW-Authenticate: Basic
Server: lwIP/1.4.1 (http://savannah.nongnu.org/projects/lwip)
Content-type: text/html
Expires: Fri, 10 Apr 2008 14:00:00 GMT
Pragma: no-cache
The standard username/password combos haven't worked, and trying a list
of 10 common usernames with 1000 common passwords also failed. I am
currently in the process of running a longer brute force attempt, as
this thing's only rate limiting is how slow its CPU seems to be, but
that's going to take the rest of the day, and I have my doubts that it
will work.
Today's Conclusion
I strongly suspect that there is some commodity microcontroller running
the show in there, most likely running NodeMCU, but unless I make a
breakthrough with the http basic auth on that port 8088 service, I've
hit a wall for how far I can go without cracking it open.
Join me next time as I crack it open!