Completely valid concern, however let’s take a risk based approach to this security concern.
For an attacker to exploit this, they would need to reasonably:
Know that there is an AirGradient device in a specific location
Know how to compromise the AirGradient device with malicious firmware (software update)
Have the motive and time to carry out the attack.
Have access to the power infrastructure to be able to trigger the power outage for the hotspot to open for 120 seconds.
So whilst it’s a valid concern, I’d suggest the likelihood of the risk occurring is quite low. There’s a lot of factors here that need to align in the Swiss Cheese Model (Swiss cheese model - Wikipedia) and within reason, if any one factor isn’t achievable the risk is reasonably mitigated.
The impact of it occurring though could be considerable, given that a compromised device could be a gateway into the network for an attacker to leverage for future attacks.
There are mitigation strategies that could be implemented if the risk is deemed unacceptable. For example, we have the AirGradient joined to a separate Wi-Fi network (i.e. A ‘Guest Wi-Fi’ or ‘IoT’ network) that does not have access to the rest of our devices. This means that if the AG then re-joins our Wi-Fi with hacked and malicious firmware, it has access to our internet, and other devices on that ‘separate network’ (which might be a Robot Vac etc), but doesn’t have the ability to communicate with our laptops/computers etc.
In cyber security it usually makes sense to apply a risk-based approach so that we spend the money and effort building the security where it needs to be (i.e. higher castle walls where it’s more likely the attackers will put a ladder against it) instead of trying to put security everywhere and diluting that effort.
Please understand I’m not dismissing the concern you’ve raised - it is absolutely valid and entirely possible. And it’s actually nice to see people increasingly aware of these sort of cyber threats!
Just for fun, I have another straw man to throw at your well reasoned risk approach. Students.
A popular or intended use case for these meters is to monitor air quality in school settings. Meters deployed in classrooms provides physical access to the meter and it’s power supply. That solves the first and last points. Being a curious student automatically solves the third point and provides the means to solve the second point. There are plenty of holes in my argument, however my intended point still stands, don’t underestimate the tenacity and creativity of students. Implementing the above scenario does not necessarily need to be malicious. It could be the start to a prosperous technology career path.
One approach was already mentioned: put the device on a separate (isolated) network. This way it won’t have access to your other devices even if compromised. But there could be issues even with this approach. If the device gets compromised, it could be used as part of a botnet (as it still - presumably - has access to the internet). This could cause the owner issues with the ISP (if the ISP is detecting an attack pattern coming from within the owner’s network). So the problem would only be partially solved with this approach.
The above option doesn’t require any changes on the device’s hardware or software. So let’s think about what could be done with the actual device.
On the hardware level, one could make sure that the device is properly protected (no physical access to the device itself and the outlet where it’s drawing power from). Also, ideally, it would run off of an UPS. This should provide some level of protection.
On the software level, one thing that could be done is to ship the devices with a password-protected AP. Of course, each device should have a different, randomly-generated password. The customer would get this when making the purchase. And at this point additional questions should be asked. Do you send this password via mail? Is that considered secure? Do you print it and put it in the box? Is that considered secure? What happens when not-so-technical customers start flooding the support lines with questions about resetting the password because they lost/forgot it?
Being worried about this is legitimate. But the thing is the code running on the device is open. Those tech-savvy enough could have a look, patch the code and run it on their own devices (I’m not a programmer, not sure how difficult that would be). Would I want AG to implement this and then hire additional support staff to deal with the outcome (and therefore transfer the cost of said additional staff into future products)? No way! Would it make sense to mention this issuesituation somewhere in the docs and say
If you are worried about this, here is how you can patch the code. Unfortunately, we cannot provide assistance if you forget your password or brick your device flashing the firmware.
(or something along those lines)? Yeah, maybe.
I’d be curious if OP has actually had a look at the code and maybe tried to patch it to obtain a password-protected AP instead of an open one.
I think the easiest and most common sense solution would be to only create the hotspot if the device has never had saved Wifi credentials. The standard situation would be when you get a new device, but would also apply if you manually flash a new firmware and choose to Erase the device as part of the process.
If the device is just normally rebooted and it has saved credentials, I don’t see the reason to ever automatically enable the hotspot. If a user is wanting to move it to a new network, then require them to use the button on the back of the device to do a Factory Reset, which indicates they have physical access to the device, and therefore “own” it.
I just had a situation where my power was flickering and as part of that, my ISP’s service was interrupted. So the thought that someone could discover my device as it came back online before my Internet access, and modify the wifi credentials is concerning.
I think this is the simplest solution. From a user experience perspective, it also eliminates vagueness regarding changing the access point.
Thank you for your detailed response, but I think this assessment ignores the reality of cybersecurity landscape.
To drive the point home, let me reframe the situation differently: Currently, the air-gradient creates an open network which invites anyone to control it, at random, non deterministic times (power outage, network disconnection, router reset due to firmware update, etc). Anyone curious who notices this random Access Point popping up, can lookup what an air gradient is (derived from the access point name), its default password, how to reconfigure it via the API and read its sensors. They might even figure out they can easily flash it, with readily available code that can be recompiled even if they only understand it partially.
Furthermore, it only takes one motivated and skilled individual to prepare a user-friendly exploit that anyone else can use, and then you’re dealing with a swiss cheese that is even more absurdly thin; Automated or manual vulnerability scans may be able to detect the presence of the device and the vulnerability in various ways (hostname, MAC address, physical knowledge of the person, etc), even in the hands of less skilled individual who doesn’t even know what an Airgradient is. You don’t even need access to the power infrastructure if you time this right. Some automated tools may even be able to wait for the right moment automatically. A tool like Metasploit can mix in existing payloads with exploits, meaning one may be able to inject sophisticated attack payloads without writing it all from scratch. (I haven’t checked the feasibility for this. But again, only ONE person needs to do the hard work).
In fact, this is one of the easiest vulnerabilities I’ve ever came across. It’s literally a matter of time for an attack to succeed, unless the victim has a perfect, never disconnecting network and power grid.
Ideally, you DON’T want a vulnerable device on an isolated network. Sure, maybe you protected your laptop. But what about your other IOT devices? What if an attack can be chained to some of them? What if your device participates in a botnet and hurts other websites? What if it is used as a proxy for malicious traffic that would trace back to your own IP and may legally entangle you? What if someone figures out you’re not at home for the night because CO2 has been consistent and not rising, and decides it’s safe to break into your house? What if your router firmware is out of date and abandoned by the company that sold it (very common) and the attacker find a way to exploit it, reaching your other net?
There is a consensus among the cybersecurity community that the defaults should be secure, because most users will not change the defaults. When security is opt-in, there is practically no security for most people. Security shouldn’t be reserved for tech-savvy people who have the time and energy and knowledge to patch the firmware.
To elaborate further for people less involved in security: There are various tools that automatically scan for vulnerabilities, based on a database of various devices and their security issues. The person running the tool does not need to have personal knowledge of all the various devices the tool is able to take advantage of. It only takes one skilled individual to add Airgradient to such a tool and then all users of said tool would have the power, even the less tech savvy among them.
Secure by defaults is a valid point, but I really don’t think you’re applying a risk based approach here. We’re talking about airgradient IoT devices, not computers running Windows.
The chances of someone randomly finding an “Airgradient-xxxx” WiFi network, and within 120 seconds, joining it, and compromising it, with pre-prepared malicious firmware…I mean it’s possible, but incredibly unlikely. Almost infinitely small chance.
There is always a balance between cyber security and user experience. Airgradient users are not cyber security experts. Neither are Xiomi robot vac owners.
And if you’re using an AG device in a corporate environment you should already have it on an IoT vlan separate from other assets on your network.
Because just as we should be using a risk based approach, we also need to assume compromise and design for that.
I think you might have skipped through my reply because I have literally mentioned the option of a botnet. I didn’t say a guest network was the best solution, but it was a way to provide some level of protection for the internal network (which is better than no level of protection).
You are looking at this exclusively from a technical point of view and make it sound like there’s an army of hackers waiting for the first router restart to take over the all AG devices. Things are not always so black and white and security and usability (and other things) need to be balanced.
To be clear, I’m not saying it’s a good idea that the AG devices (or any other IoT devices for that matter) present an open AP when they lose connectivity to the network. I’m saying other things (that I mentioned) need to be considered as well when changing this behaviour. And I think the approach suggested by @MallocArray makes a lot of sense and would be a good way to mitigate this issue.
You’re assuming a human manually doing it all. If there’s an automatic vulnerability scanner in your vicinity, running long term, the chances of it picking it up the Airgradient goes up to 100% the longer it’s running.
The user experience impact of mandating a factory reset to change wifi is virtually the same. In fact I’d argue it’s clearer, as some users are clearly confused by the behavior.
This is in fact a good assumption to work upon from a security standpoint. The ideology of “security through hackers’ disinterest” is the reason so many IOT devices are extremely weak, and as soon as any hacker is interested in the device, it’s cracked instantly.
In this particular case, the fix suggested by malloc is rather trivial and doesn’t involve compromising user experience.
Here’s a possible variant: Once you hold the reset button for 10 seconds and release it, the airgradient monitor says: “Will factory reset in 60 seconds. Press the reset button one more time to reset WIFI only and preserve the settings”, or something along those lines.
I’d like to demonstrate my concern differently. If we squint, I think it’s easy to see that the 4 factors mentioned above are in fact co-dependent and can be kinda rewritten as two factors:
A hacker is interested in an Airgradient.
A hacker finds an Airgradient.
This is a very low security bar.
To illustrate:
A hacker might locate an Airgradient using the sensor map plus some deduction.
If they’re impatient, they can then use a portable wifi jammer to cut it off from the WiFi. This is actually very easy to do nowadays, even for novice hackers. Off the shelf wifi adapters connected to laptops can be used as jammers.
The Airgradient opens a WiFi access point and is PWNed
There are so many variants to this. An Airgradient situated outside might come to the attention of the hacker through visually seeing it. They might then look up what this IOT device is.
@derek also mentioned students. Many students will tick those two factors.
Yes, there is a risk. There’s also a risk that I get struck by lightening or that the building I’m in spontaneously collapses.
Just because there is a risk, doesn’t mean it will happen.
ABSOLUTE RUBBISH.
‘Automatic Vulnerability Scanner in your vicinity’ - where are you?? In the middle of a red-team hackathon? I mean seriously, suggesting that the risk of an AG device being compromised goes “up to 100%” - which means compromise is GUARANTEED - is just absolute hyperbole.
Using l33t-h4ck3r terms like PWNed does not add credibility. Neither do Wikipedia links.
Your assertion that someone is going to go out of their way to hunt down an AG device that they can use a Wi-Fi jammer to kick off the network to compromise using pre-prepared firmware…I mean seriously, yes, it’s possible, but this mythical hacker could have also commandeered control of the SpaceX shuttle, and I know which is a better pay-off. Portable Wi-Fi jammers, yo.
This is the most sensible suggestion. I often move one of my AG devices around, and the fact that it boots up and can’t find the previous Wi-Fi network is convenient - it means I can re-configure it for the new temporary network. Having to manually reset it does impact the user experience, but isn’t terribly inconvenient, and will achieve the same outcome which sufficiently addresses your concerns, however infinitely unlikely.
An identified risk does not mean an inevitabile risk. This is the crux of a risk-based approach, as it involves identifying both the risk, and the likelihood of that risk occurring. Your 100%-guaranteed assertion is manifestly incorrect.
I think the only consensus in Cyber is there is very little consensus in Cyber, and ‘secure’ is subjective.
But if there’s one thing this exam taught me - CISSP Exam Outline - it’s subjectivity and perspective.
I do not appreciate the ad-hominim or the argument from authority. I would appreciate if you only talk about the technical discussion.
It is trivial to hack this device once you know it’s there. The arguments brought up are security through obscurity, security through unpopularity, or security through “who would do it”, and these are irrelevant to the fact that the device opens up completely if one asks it to.
It is trivial to kick a device off wifi (See airmon-ng).
A third fact is that far more complicated to execute vulnerabilities are often assigned very high CVE levels and are exploited in the wild.
You have put words in my mouth here. If someone is logging Access Point names in your vicinity, it is only a matter of time until the Airgradient is discovered. Unless your network connectivity is perfect for eternity.
TLDR; You’re right and your wrong, but you are worrying about the wrong thing.
I was in charge of the infrastructure for a large K12 district with 20,000 students for over 5years. I think this entire conversation rather misses the point. The actual solution to this problem is to use ethernet. I don’t think @Achim_AirGradient should dedicate resources to changing the wifi behavior at all. A POE version is would I would advocate for, as many orthers have as well.
In an enterprise environment, I would not use AirGradient because I would never rely on WiFi for critical environmental monitoring. WiFi is inherently insecure and it inherently sucks. I think @hot-air-balloon you are assuming that things on the WiFi can be secure. They cannot. You should proceed with proper network design and assume nothing on the WiFi is secure. Proper network design will get you alot further than complaining about this or that vendors insecure wifi implementation. There is an infinite quantity of IOT devices that have poor security practices, and you’ll be making an infinite quantity of posts like this if you rely on WiFi.
As an aside, I also would never use DHCP in an enterprise environment, and the AirGradient firmware doesn’t easily support configuring static IPs. I love mine at home and just ordered a second.
I have larger concerns about the Airgradient device behaving…properly…after a power outage or a WiFi outage…or another less broad connetivity outage. I have not tested, but I can see some scenarios where the AirGradient might not recover/reconnect properly and I would have to send technicians out to reset them…which would be annoying and a waste of resources.
The security implications of this design exist, sure. But they really don’t matter, not any more than any other random printer or IOT device. This design is common practice.
I also don’t see much security “risk” here. If someone hacks into an Airgradient, they know the…air quality lol. That’s not going to get them much in the way of lateral movement across the network. The larger problem, in my opinion, is that as @derek mentions, students are…creative. In my experience they are also agents of Chaos. If a student has physical access to the air gradient, all bets are off, no matter what software security measures are taken. Physical security trumps any amount of additional software layers. I would advocate for a locking mount of sorts which could help prevent someone accessing the power input, as an example. This would be far more valuable a security tool than any software “fix”. It also directly addresses the vector of attack mentioned.
And that’s the problem - you can’t approach this purely from a technical point of view. Yes, it’s hackable. No, it’s not likely in the real world, when considered with other risks
I’m going to leave the discussion here because I don’t feel it’s being constructive.
Proper network design will get you alot further than complaining about this or that vendors insecure wifi implementation. There is an infinite quantity of IOT devices that have poor security practices, and you’ll be making an infinite quantity of posts like this if you rely on WiFi.