Slashdot Mirror


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

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.

11 of 49 comments (clear)

  1. If a single port misconfiguration... by Anonymous Coward · · Score: 2, Interesting

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

    1. Re:If a single port misconfiguration... by _Sharp'r_ · · Score: 4, Insightful

      They setup a server with a service configured to allow connecting on a default port and giving unencrypted/passwordless access to the entire file system.

      Yes, this is the definition of "doing it wrong".

      Any even minimal attempt to secure the server and service via OS hardening and/or taking the 2 minutes to configure rsync/rsyncd to use ssh as a transport would've prevented this issue. As rsyncd has used ssh by default for a while now, either they deliberately turned off all safeguards, or else they are running a _really_ old version of *nix which they haven't kept updated.

      --
      The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
    2. Re:If a single port misconfiguration... by _Sharp'r_ · · Score: 4, Interesting

      At the risk of replying to myself, I just went and looked and rsync has had using ssh as the default config for 13 years now...

      --
      The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
    3. Re:If a single port misconfiguration... by bravecanadian · · Score: 2

      You can say that about practically any security breach.

      Mistakes happen and the issue is that you'll never be 100%, particularly in a big, complex organization.

      If you're on defense, you lose. Therefore it is important to treat security as risk mitigation and assume you're going to fail so that you can detect and react to breaches.. hopefully before you lose your 200GB of data.

      Unfortunately, most companies don't treat security as an important function and under fund and undermine it.

    4. Re:If a single port misconfiguration... by sjames · · Score: 3, Funny

      All to frequently it starts when some upper manager who was once trapped in a room for 3 hours because he was baffled by the door knob is unable to access a perfectly standard resource. So, in order to avoid further confusing him, all security has to be removed...

  2. Pen testing is good by steveo777 · · Score: 3, Interesting

    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.

    --
    This sig isn't original enough, it's time to come up with something witty...
  3. Seems like a good reason to... by Gravis+Zero · · Score: 2

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

    --
    Anons need not reply. Questions end with a question mark.
  4. Re:Why not use DFS for windows shares? by Anonymous Coward · · Score: 2, Insightful

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

  5. Just doing it vs. doing it right by ErichTheRed · · Score: 3, Insightful

    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.

  6. Re:SCIF by Mr+D+from+63 · · Score: 2

    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.

  7. Rsync without SSH? by Trogre · · Score: 2

    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?

    --
    "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife