Epic fail of the month: rsync as a "vector" to pull data

Initially, I just wanted to throw a link to some comments for the first branch of this article , as an example why pushing ports outside (for good reason) is not good.
Well, the answer has grown in the sheet in this article, and the comment will see one or two people (and so maybe someone will come in handy).

It is not about vulnerability in the literal sense of the word, but about how, by negligence (negligence or laziness), shoot a long line at once in the leg.

What actually happened

The UpGuard Cyber ​​Risk team found a "hole" where many documents, including secret ones, were littered (I won't find another word) in direct public access.
To assess the seriousness - among the companies covered by that "hole" divisions of VW, Chrysler, Ford, Toyota, GM, Tesla and ThyssenKrupp.

Data for all different types, degree of confidentiality and "neck" of secrecy, but ...

Where dragged off found

On publicly available servers belonging to the Level One Robotics group, "an engineering services provider specializing in automation and assembly for OEMs" ...
The list of actually affected manufacturing companies, see above.

what dragged off found

About 157GB of good, including assembly lines (for more than 10 years), location plans for factory premises, robotic configuration and documentation, request forms with employee IDs, VPN access access forms, non-disclosure agreements (laugh here), and t .d etc. This is what concerns almost all the above mentioned companies. In addition, personal data of employees (Level One and others), including scans of driver's licenses and passports, Level One business data (invoices, contracts and bank account details). But so for warm-up.

And finally probably to finish off the access level (permissions set) installed on the server at the time of opening the "hole" suddenly showed up as writable , i.e. anyone could potentially change the documents lying there, for example, by changing the bank account number in the accountant’s instruction for a direct transfer, could enlist a loved one in the staff, could plug in a malicious program, etc. joy

how dragged off logged in

And here (as I have already hinted above) everything is very simple - the server was (or suddenly once became) accessible via rsync . The rsync server was not limited by IP (not at the level of users, keys, etc.), i.e. All data could be written off by any rsync client connected to the rsync port.

Once again - rsync stupidly stuck open port out, without any additional verification.

Probably just the wrong setting (the effect of several cooks in the same kitchen, etc.).
I do not know (and UpGuard is silent) what was there specifically - whether ssh is open (which is unlikely), legacy rsh as the transport layer, direct unison or what other socket method, rdiff or csync over HTTP, etc. There are many options, but - the point is that in any case, the “attack vector” would be nullified by the simplest firewall rule that allows connections to only strictly defined ports from 127.0.0.1 , [::1] and another pair of “friends” addresses, aka white list.

What we have

Automation of production has changed the industry, but it has also created many new areas for risk, where the weakest link (including the human factor, by malicious intent, due to oversight, misconfiguration or stupidity) negates the entire corporate security system, which means that enterprises need to take more serious care of all the links involved in the organization’s digital ecosystem.

And on your VPS-ke (and maybe where else, where traffic can be forwarded with a tunnel tomorrow or somehow turned to "outside") close everything out of harm's place with a whitelisting, so that tomorrow some service will suddenly get access outside ( or a new attack vector that appeared) did not drop your safety below the baseboard.

Well, incite a familiar auditor to your "provider of engineering and other services" ...

Suddenly there too rsync ports sticking out - stigma in the cannon.