Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Technology IT

How a Port Misconfiguration Exposed Critical Infrastructure Data (helpnetsecurity.com) 49

An anonymous reader writes: Attacks hitting companies' electrical systems are possible, especially when information that provides insight into those systems' weak points is freely accessible online. If you think that such a thing is unlikely, you probably haven't yet heard about the most recent discovery made by UpGuard researchers: an open port used for rsync server synchronization has left the network of Power Quality Engineering (PQE) wide open to malicious attackers. They managed to access and exfiltrate 205 GB of data from PQE's servers, up until the moment when the company secured its systems two days later after being notified of the problem.
This discussion has been archived. No new comments can be posted.

How a Port Misconfiguration Exposed Critical Infrastructure Data

Comments Filter:
  • Why not use DFS for windows shares?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      You can configure DFS to provide unencrypted, unauthenticated access, so it meets all of PQE's requirements.

  • by Anonymous Coward

    If a single port misconfiguration puts your data security at risk, you are doing it wrong. That's all folks!

  • After exposing the Sensitive Compartmented Information Facility (SCIF) plans, I'm betting that's the last government contract they work on.
    • After exposing the Sensitive Compartmented Information Facility (SCIF) plans, I'm betting that's the last government contract they work on.

      It seems to only show a black box room location from one facility. This is not necessarily info that is required to be secured. In reading the article, most of the information is pretty useless for any kind of attacker on the actual power systems, some of it is business sensitive. Its a security hole they need to plug in general, and certainly a good example of carelessness, but the article makes this out to be a much more significant breach that it is.

      • We are in the same field as them; we have contracts for non-disclosure that would ruin us if disclosed. While much of the information is quite mundane, the timing of access to information could have a few of our clients suing us quite quickly.

        While I get things being mis-configured in a small shop, it amazes me how lazy of a solution many companies have. (That reminds me... I should get a pen-test audit done...)

        • Thanks for the insight. Some companies do have a lazy solution, some have more robust ones yet overlook something simple or don't stay on top of change.
  • Pen testing is good (Score:4, Interesting)

    by steveo777 ( 183629 ) on Wednesday August 09, 2017 @10:01AM (#54974633) Homepage Journal

    Pay someone to do even a light check of your network. You never know.

    Something very similar happened at an old employer. We did network and voice support for an auto dealer. Every month their long distance and international bills were unjustifiably enormous, but they didn't tell US about it, preferring to bitch at the phone company directly (company was horribly run, really). At some point or another they finally got fed up and told us they didn't want international calls to go out (this was the first thing we heard about the problem) and I turned it off for all but a select set of phone numbers. Over the next few months we get requests to turn off LD on all these extensions and back on. The boss is getting paid so when I get a bit angry about all the stupid switching around he doesn't want me to ask. We started looking into it anyways, and it turned out that one of their headless phone numbers was basically an open relay. The system had been set up by engineers that were long gone, so we just closed off the relay.

    However, someone noticed this and used the relay to call around... for about a year. Got thousands of dollars in free calling.

  • A comedy of stupidity.

    Did they even have a firewall?

    Who does the reviews and port scans for security changes?

    Who reviews the security postures of applications and services on the internal network.

    Power Quality Engineering, well one out of three, maybe.

    Here's a hint for configuring your security posture. Start with denying any connectivity in either direction. Adjust as needed.

    • A decade ago we did have "remote access" via ssh/sftp to the file server. We were caught off guard with one employee needing to work at a client site for a couple months. Terrible practice, but we only had ~8 people at the time and were saving up for the real firewall...

      We did at least use certificate login though, I guess. Not much of a salvation.

      But, anything in the last 5-8 years is really, really stupid. I understand how it happens, but it is still stupid as hell.

  • by Gravis Zero ( 934156 ) on Wednesday August 09, 2017 @10:15AM (#54974803)

    move as many systems as possible off the power grid. Blackouts need not cripple our civilizations.

    • move as many systems as possible off the power grid. Blackouts need not cripple our civilizations.

      This wasn't a grid system. This was a business LAN. Of course the headline is crafted in such a way as to hope someone is confused and assumes actual electrical equipment/systems were involved.

  • I'm sorry for being blunt but "a port misconfiguration" should not even be theoretically possible on mission critical devices. They should not be accessible directly (and indirectly as well) from the world wide net.
    • I'm sorry for being blunt but "a port misconfiguration" should not even be theoretically possible on mission critical devices. They should not be accessible directly (and indirectly as well) from the world wide net.

      This was a business LAN folder access, not a mission critical device or system.

      • by PPH ( 736903 )

        This was a business LAN folder access, not a mission critical device or system.

        This

        But utilities and industrial businesses are notoriously paranoid about 'terrorists' (a.k.a. the general public) gaining access to configuration details of their systems. A good part of this is due to to the Dept of Homeland Security throwing money and resources around after 9/11 at poorly understood problems. Never mind that you can discover pretty much everything you need to know about a power grid using Google Maps imagery. Or just driving around, looking at power lines.

  • by ErichTheRed ( 39327 ) on Wednesday August 09, 2017 @10:51AM (#54975149)

    Mistakes happen, and this was a BIG one, but I'm of the opinion that the pendulum is too far over in the "get it done now" realm and needs to swing a little back toward the middle. I'm in systems integration/engineering, and there is a relentless push for even established companies to be fully buzzword compliant, move towards DevOps, and basically remove any barrier whatsoever to putting stuff out there the second a developer checks in a code change. A lot of this is good, but unless your developers are accomplished system admins who actually know how things work under their layer of code, the Ops people do need to work with them to ensure they're not doing anything crazy or taking shortcuts.

    The whole pendulum-swing thing is being driven by web startups and the ever-raging battle beyond Devs creating Apps! and Ops people maintaining all that LUDDITE infrastructure. When the Ops people were allowed to fully drift over to being the Department of No, the Apps! developers just walked around them and built their Apps! in the public cloud with a credit card. At the same time, all the web startups were starting up with zero legacy anything, so everything was built to that cloud model and it's felt that Devs don't need to know about infrastructure anymore.

    I have one foot in both worlds (agile cloudy stuff and infrastructure-centered stuff) and I feel that items like this are going to pop up more often given the constant push to move move move or else. Stuff like putting confidential customer data on a public S3 bucket, leaving a key system fully exposed to the Internet because your cloud's IaaS platform doesn't stop you, etc. Once the Second Dotcom Bubble pops, I'm hoping we take the good stuff that DevOps gives us and apply a sane schedule to it, letting people who actually understand the nuts and bolts of infrastructure, ports and protocols weigh in also.

    • You're right. "Get it done now" This is why we have defective cars catching fire. Buildings with no sprinklers killing people. And no low center or gravity, multi chamber, thicker metal, train cars that carry oil. The tragic oil spill in the Gulf of Mexico that killed those people on the platform because they didn't want to take time to put a safety valve on.. etc.
  • I am surprised the researcher wasn't arrested as this is what corporations typically do these days according to what I read here

    •     "Researcher".... downloaded 205GB of data? Agreed, they should be arrested. I can see downloading 1 or 2 files and getting a listing or something, but 205GB is well beyond documenting a vulnerability.

      • by mysidia ( 191772 )

        I don't agree.... Researcher finds some Open public Rsync server publishing files on the internet. Initiates a bulk download to fetch everything being made available so they can take a look at what this is. 205GB is a drop in the bucket these days --- it's an insignificant amount of space assuming a decently fast Gigabit+ network connection and relatively modern PC (My new PC has two 4000GB hard drives in it, so 205 GB would be about 3% of my storage).

  • Isn't it more like a service misconfiguration ?

    Either the port should be closed in the firewall or if needed should be left open like it was, using an IP whitelist (which could be implemented at the firewall). Rsync should have been set up to use authentication in any scenario.

  • by Trogre ( 513942 ) on Wednesday August 09, 2017 @07:48PM (#54980205) Homepage

    I just don't understand how anyone in 2017 could use rsync without going through an SSH channel, preferably with keys if it's an automated process.

    Anyone care to explain?

  • by fnj ( 64210 )

    Bwahaha, these monkeys set up rsyncd naked on port 873? And all these stupid commenters are bleating about firewalls when using rsync with ssh is perfectly secure.

A motion to adjourn is always in order.

Working...