Microsoft Says Attackers Are Hacking Energy Grids By Exploiting Decades-Old Software (techcrunch.com) 60
An anonymous reader quotes a report from TechCrunch: Microsoft has warned that malicious hackers are exploiting a discontinued web server found in common Internet of Things (IoT) devices to target organizations in the energy sector. In an analysis published on Tuesday, Microsoft researchers said they had discovered a vulnerable open-source component in the Boa web server, which is still widely used in a range of routers and security cameras, as well as popular software development kits (SDKs), despite the software's retirement in 2005. The technology giant identified the component while investigating a suspected Indian electric grid intrusion first detailed by Recorded Future in April, where Chinese state-sponsored attackers used IoT devices to gain a foothold on operational technology (OT) networks, used to monitor and control physical industrial systems.
Microsoft said it has identified one million internet-exposed Boa server components globally over the span of a one-week period, warning that the vulnerable component poses a "supply chain risk that may affect millions of organizations and devices." The company added that it continues to see attackers attempting to exploit Boa flaws, which include a high-severity information disclosure bug (CVE-2021-33558) and another arbitrary file access flaw (CVE-2017-9833). "The known [vulnerabilities] impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials," Microsoft said, adding that this can allow the attackers to have a "much greater impact" once the attack is initiated. "The company has warned that mitigating these Boa flaws is difficult due to both the continued popularity of the now-defunct web server and the complex nature of how it is built into the IoT device supply chain," reports TechCrunch. "Microsoft recommends that organizations and network operators patch vulnerable devices where possible, identify devices with vulnerable components, and to configure detection rules to identify malicious activity."
Microsoft said it has identified one million internet-exposed Boa server components globally over the span of a one-week period, warning that the vulnerable component poses a "supply chain risk that may affect millions of organizations and devices." The company added that it continues to see attackers attempting to exploit Boa flaws, which include a high-severity information disclosure bug (CVE-2021-33558) and another arbitrary file access flaw (CVE-2017-9833). "The known [vulnerabilities] impacting such components can allow an attacker to collect information about network assets before initiating attacks, and to gain access to a network undetected by obtaining valid credentials," Microsoft said, adding that this can allow the attackers to have a "much greater impact" once the attack is initiated. "The company has warned that mitigating these Boa flaws is difficult due to both the continued popularity of the now-defunct web server and the complex nature of how it is built into the IoT device supply chain," reports TechCrunch. "Microsoft recommends that organizations and network operators patch vulnerable devices where possible, identify devices with vulnerable components, and to configure detection rules to identify malicious activity."
Firewalls (Score:5, Insightful)
I seem to recall there was a network transit device, whose sole purpose was to place a virtual barrier between potentially sensitive devices and potentially dangerous networks like the Internet.
Oh yea. Those were called FIREWALLS.
You can try to blame IoT software supply chains all you like, and you won't necessarily be wrong, but the shit show network security policies of inexperienced, ignorant, negligent, and weak necked CISOs make this sort of crap even possible.
There's only one firewall ruleset that actually works: The draconian firewall ruleset. Block EVERYTHING by default, permit only what you explicitly need, peer to peer, port by port, service by service, and layer an application firewall engine and IDS/IPS on top for good measure. Things are bound to their walled garden, and if shit goes oddly pear shaped, the system automatically terminates the traffic flow.
Are you running a knitting club social website, or a power station? Oh, a power station? Well shit dude, you have no reason to be lax in your security, your customers pay you for UPTIME, not speed to deliver UI features.
Re:Firewalls (Score:5, Funny)
Firewalls don’t matter when the boss says he wants his phone to have access and he isn’t messing with that VPN bullshit. Oh and make the password 12345 like all the rest of his.
Re: (Score:3, Insightful)
Firewalls don’t matter when the boss says he wants his phone to have access and he isn’t messing with that VPN bullshit. Oh and make the password 12345 like all the rest of his.
Tales from the Dot-Bomb, Episode 7
(CEO) "I want my password to be 'gone'."
(IT) "Uh, Sir we have a *minimum* of 8 characters for the password, using a combination of..."
(CEO) "You didn't understand me. Gone. Nada. Zilch. I want to login without having to type it."
(Narrator) *And that was the day, the CEO destroyed the Windows NT domain password security...*
Re: (Score:1)
(Narrator) *And that was the day, the CEO destroyed the Windows NT domain password security...*
What there was of it anyway.
I used to run a shop where root didn't have a password, by design. Because when you need to log in as root things have gotten bad enough faffing about with passwords isn't going to help a thing.
Access was either through the console, for which the security was a physical key outside the normal system, or through su, which respected the wheel bit. (And yeah, that wasn't on linux. Stupid RMS.)
Which turned out to be more effective than what the brass did: Leave their ground floor
Re: Firewalls (Score:2)
Re: (Score:2)
Your CEO/bossman isn't trying to log in to the SCADA network, dude. He wants c-level access to c-level stuff -- which these days means he wants his email and google drive (or whatever your biz equivalent might be). If that person demands access to manufacturing networks, you tell him, (in a stern parental'ish voice) "NO!".
This is why they hired you.
YOU are the expert.
They are but children playing in the sandbox, and they have tasks YOU will controlling the boundaries of that sandbox, so that they can conti
Re:Firewalls (Score:4, Informative)
nah, those are called "don't connect your power grid control systems to the internet".
Re: (Score:3)
The only port that should be open is a single VPN port.
Re: (Score:1)
Re: (Score:2)
Doesn't WireGuard use UDP?
Re: (Score:2)
You obviously missed the first tenant of the Draconian Firewall Policy, so I will repeat it here with more emphasis -- I hope that this helps.
--> ALL TRAFFIC IS BLOCKED BY DEFAULT. Period. (and yes, that means egress too) <--
If the traffic isn't strictly relevant to the function of the thingie, it gets blocked. If it needs to talk to some external provider, sure, allow it (after a sanity review of the purpose/function, of course), but you put the most restrictive fence around that hardware that you ca
Re: Firewalls (Score:2)
I agree with what you write, but I'd place a few more safeguards in there if you're going to deal with mission-critical hardware in a power station. Ie: Trust but verify.
Any traffic that is allowed should not be able to see the internal network arrangement, even through a VPN. Everything should connect via a proxy or maybe NAT, possibly in the DMZ.
(You want to avoid direct access where at all possible. Complex software can have complex security holes.)
Any traffic that gets to the inside network should be in
Re:Firewalls (Score:4, Informative)
These attacks aren't coming from protected ports. A lot of these are IoT and remote service ports. The attacks are coming through the known port that is supposed to be open so that the device can do it's job. Your recommendation is like trying to secure a web server by firewalling port 80. I mean, I guess so but then is it really doing it's job?
The thing is this stuff has to be kept up to date. Like literally any infrastructure, you have to maintain it. These exploits are usually years old and a lot of our infrastructure has to deal with deferred maintenance. And it's a complex set of reasons why it's in the shape that it is in. But mostly, we don't want to pay engineers on site, we don't want to in-house certain parts, and we don't want to have employees on payroll. So all of this stuff gets outsourced and those people can only maintain it from a central command if the ports are open.
So yeah sure, toss a firewall somewhere in there. It won't do the job you think it will do. The point is, this equipment has to be kept up to date. We're not going to solve the issue of why we have remote workers into critical infrastructure. I mean if you figure out how to get the top dogs to NOT care about how much profit they stuff into their pocket, then maybe you'll solve the underlying issue. But until you find a cure for greed, those ports have to stay open for the things to do their job. And if you solve that, then yeah fine, we'll go with your idea.
Re: Firewalls (Score:3)
Network cameras should be on a VLAN which can only reach a VPN server and whatever server records the video. Remote service over the open Internet is silly.
Re: (Score:3)
Yes, that is how cameras *should* work, but many do not work that way. Ubiquiti as an example advertised their system as being entirely on your local network... but to check the cameras on an iPhone or iPad you have to use their application which requires cloud access even when you are using a VPN. You can kludge together access via generic RSTP apps, but the performance is miserable.
Similar problems arise with other IoT devices, especially wireless 2.5GHz ones. You get to a point where you need to segment
Re: (Score:2)
No, my cameras are all wired. It is the home automation stuff mainly and sadly things like weather stations.
Re: (Score:2)
Remote service over the open Internet is silly
I mean I'm not disagreeing with you. But... (gestures broadly towards everything).
Re: (Score:2)
Sorry mate, but either someone lied to you in your recent past (and you believed it) or you're a solid fool.
IoT devices are the enemy hardware that your company elected to install directly into their own network. As a proper network engineer, your job is to take these (obviously stupid) implementation plans and ensure they include callouts for treating these 3rd-party devices like the potentially hostile entry points that they are.
I know, it's sometimes hard to tell your boss (and their boss, and the CTO)
Re: Firewalls (Score:2)
This can be made to work with Active NIDS.
If NIDS detects that the port isn't being used in an authorised manner, it simply closes the port for a bit then reopens it.
Ok, it won't detect all types of attack, only types you've set it to look for, but it's better than nothing. And it does need a firewall there to work.
Re: (Score:3)
Block EVERYTHING by default, permit only what you explicitly need, peer to peer, port by port, service by service, and layer an application firewall engine and IDS/IPS on top for good measure.
It's a bad idea to allow any incoming connections. Maybe respond to pings, if you are sure that they can't be used for a DDOS.
Instead you run a VPN server that each devices connects to, i.e. a single outgoing connection only.
Re: (Score:2)
Hi. You're either wrong, or your statement isn't complete.
1. "VPN" is not a magic solution for creating real network security, it's just an encrypted traffic tunnel between two network locations.
2. Artificially aggregating device connections into a central proxy point does not inherently increase the security of that traffic. Unless you have some manner of per-device traffic inspection, and logging in place at the aggregate layer, and are still enforcing individual traffic rules accordingly, you are simply
Re: (Score:2)
I seem to recall there was a network transit device, whose sole purpose was to place a virtual barrier between potentially sensitive devices and potentially dangerous networks like the Internet.
Oh yea. Those were called FIREWALLS.
You can try to blame IoT software supply chains all you like, and you won't necessarily be wrong, but the shit show network security policies of inexperienced, ignorant, negligent, and weak necked CISOs make this sort of crap even possible.
There's only one firewall ruleset that actually works: The draconian firewall ruleset. Block EVERYTHING by default, permit only what you explicitly need, peer to peer, port by port, service by service, and layer an application firewall engine and IDS/IPS on top for good measure...
At the end of an uneventful quarter when the bills to properly monitor and report on all that started adding up, they weighed the costs and determined blaming you was the good measure they needed to take.
Customers paying for uptime is fine, but executive bonuses paying for security FUD? Don't let the door hit too hard on the way out.
Re: (Score:2)
The problem is that filtering at layer 3 (IP) or 4 (ports) doesn't help you if the server application has vulnerabilities at layer 7 (application) which is certainly the case here. When the attacker can compromise the web server application on port 80 or 443, the layer 3+4 firewall rules cannot distinguish between legitimate traffic and malicious traffic. So the attacker gets in, sets up a reverse shell, pivots, and you are pwned. Default Deny cannot help you with that.
Application (layer 7) firewalls exist
Re: Firewalls (Score:3)
Baseball Bat To The Face (Score:2)
The only way these agencies in the US are going to update their software and hardware, is if someone takes a proverbial baseball bat and whacks them in the face with it.
Such as a US government agency exploiting their way in and wreaking absolute havoc on a select few sites as an example to the others. Overspeed a few SCADA controllers, snap off the valves on a few floodgates, cause a few small town power generation stations to burn up the turbines?
The walk across the street to Congress and say, "Yes. We
Re: (Score:2)
It isn't the agencies that are the problem. The problem is insecure software and lack of Congressional appropriations to change out the infrastructure. The former Congress can do little about except maybe pass some laws making company management personally responsible, which won't go anywhere because the Supreme Court won't allow it. The latter gets mired in politics with the R's whining about government overreach and wish to turn government over to those nice corporations that fund their re-election. The D
Does Slashdot use Boa? (Score:3, Interesting)
Re: (Score:2)
Damn, I guess the Chinese can read Slashdot now. They won't stop at anything.
Boa squeezes YOU! (Score:4, Funny)
Typical snakey tactics by the Chinese. Use of Boa should be constricted.
Sorry, I'll just slither off...
Re: (Score:2)
Obviously it should be re-written in Python.
Its probably Microsofts own developers/hackers (Score:2)
S in IoT stands for "Security" (Score:4, Insightful)
Re:S in IoT stands for "Security" (Score:4, Insightful)
S in IoT stands for "Security"
This is the first time I've seen this saying, and I have to say, it's poignant and I like it. I'm stealing this. Thanks.
This is still a problem in 2022? (Score:1)
ISC was posting about how Boa was getting exploited by 2009 era CVEs... back in 2016! [sans.edu]
How can there still be new devices shipping out the door with this stuff?
Decades old (Score:2)
I wonder how long it will be before we have headlines like, "Hackers are exploiting century old software."
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
I seem to remember a couple decade old exploit in Windows attacking the way Windows processes some old bitmap fonts, but I couldn't find it because Microsoft keeps getting exploits in their bitmaps and fonts, and that one gets lost in all the noise.
Re: (Score:2)
Maybe some people are still communicating via enigma machines?
Re: (Score:2)
That's a good one.
Not a proprietary blob (Score:2)
Unlike a proprietary blob from a vendor like Microsoft, Boa does not have to go unmaintained just because the original developers have lost interest in it. It is open source and if it is popular new developers can and should create a compatible fork if not arrange to take over the project as is. It should go without saying that there is no excuse for shipping software with serious vulnerabilities, especially when maintenance is feasible.
Re:Not a proprietary blob (Score:4, Insightful)
Re: (Score:2)
No Easy or Supported means of update. There is always a means to update it, just varying levels of pain to do so.
Re: (Score:2)
Re: (Score:2)
It should be considered engineering malpractice to put anything as complex as a web server on a device with firmware that cannot be updated. What are users supposed to do - replace everything whenever a serious security vulnerability is discovered? With something else that is likely to have serious but unknown defects the day it is shipped?
Security in Training (Score:3)
Pot kettle blackout .. (Score:3)
GOOD. (Score:3)
If a company is lax with security like this then they have earned the right to be hacked. It's not easy to keep such outdated systems running, so they have put a lot of hard work into ensuring hackers could hack them.
Exposure tests and firewalls (Score:2)
The first thing any kind of competently done exposure analysis is looking for things like this. And then the recommendation is to switch them off or isolate them using a firewall. Anybody that gets hacked via this vector is grossly negligent and no excuses. Time to make the fuckups responsible for this pay personally.
Sorry to ask... (Score:1)