@dvandal @strlcat @davidgerard

Wayland and systemd are both symptoms of the same behaviour, as was PulseAudio:

• Observe that an existing system has flaws.
• Don't engage with users to identify use cases.
• Throw up some half-finished code (with incomplete or nonexistent backwards compatibility) that solves some of the problems of the old system but doesn't address all of its use cases and introduces more problems for other people.
• Declare that the old thing is deprecated and everyone needs to move to the new thing.
• Create a load of work in the rest of the ecosystem that other people have to do.
• Silence all criticism by pointing out that the old thing was imperfect.

And that's the kind of thing that you can only get away with if you're able to act as a monopoly, by employing maintainers at key points across the ecosystem.

The biggest problem with Microsoft was not that their monopoly allowed them to be evil, it was that it allowed them to be stupid. A lot of things in the MS ecosystem are actually bad for Microsoft, but they're pushed out because no one inside MS cares enough to do the right thing and no one outside is able to fix the problems. I, personally, don't want the F/OSS OS ecosystem to end up like that.

Analysis

This is not a complete failure analysis. This are only my observations. A full detailed analysis is most likely to be even more shocking.

Failures:

• The PC with that kind information should never have been "internet facing" (architecture mistake)
• The informations do not belong on any file share (organisational mistake)
• Shares should never allow unauthenticated access (configuration mistake)
• The information should never have been stored unencrypted (lack of data security)
• Incoming SMB traffic should never be allowed to such a network (firewall policy mistake).
• Any such network should include a monitoring of the external attack surface that could easily identify such a leak (lack of posture management, lack of attack surface management).
• It was out of scope for our involvement, but is very likely that the systems could have been used to compromise any attached network
• SUMMARY: A complete and utter failure of IT-Security on the technical and organisational level for that lab

Impact

It can be safely assumed (due to duration and easiness to discover) that all data on those shares is now in the hands of inttelligence services with non-friendly attitude towards the United States of America (e.g. Russia, China)

3/4

Timeline

• May 14th 2025: Scanner of Security Researcher flags a public SMB share for inspection (leak open at latest at this date)
  • IP addresses involved: 216.220.10.217 and 216.220.10.222
• June 5th 2025: Security Researcher analyses the SMB share and discovers phone dumpy created with Graykey. Some data is mere hours old, therefore this is a live leak.
• In between: File names show that some investigations are tied to child abuse as directories contain "CSAM" as part of the directory names.
  • Remark: Usually investigations are identified by three parameters in thge file name: type of crime, location and some keyword (optional). In case of major crimes, using those identifiers one could easily identify those crime through press reports.
  • One directory name seemed to indicate the dump to be done from a police officers phone who comitted suicide.
• June 12th 2025: As the Security Researcher could not identify a clear owner and previous contacts to CISA and FBI didn't produce any reply, he contacts me and asks for support. I receive as supporting material:
  • One extraction report by Graykey for "Policy Violation" investigation
  • List of file names in the leak
• June 12th 2025 06:42 UTC: Asking friends in my environment for contacts in the U.S. to help with this leak.
• June 12th 2025 ~19:00 UTC: Start discussing the leak with journalists in the U.S. Due to the CSAM topic, there is great reluctance to engage.
• June 13th 2025, 19:20 UTC: From the extraction report I assume that this investigation is done by the Cascade County Police Department. I attempt to contact Sheriff Jesse Slaughter him by: mobile (spoke on his voice box), text message (iMessage) and email. As of today there is no answer.
• June 17th 2025, 07:22 UTC: A second security researcher informs the Bozeman PD about one of their investigations to be in the leak
• June 17th 2025: Second security researcher also reaches out to the former Attorney General and former Governor of Montana Steve Bullock via LinkedIn to help with the leak. As of today there is no answer.
• June 17th 2025, 08:47 UTC: Bozeman PD reaches out to the second security researcher
• June 17th 2025, 09:10 UTC: My initial post on Mastodon (https://infosec.exchange/@masek/114697924639525296) asking for help
• June 17th 2025, 11:36 UTC: On recommendation received, I contacted the Attorney General of Montana by Email. As of today there is no answer.
• June 17th 2025 12:46 UTC: Former FBI employee offers to create a contact.
• June 17th 2025, 16:20 UTC: Contact with employees of the software vendor (came through the SM post above). I provide them with serial# from the extraction report and additional information in the next 30min. They say they identified the owner of the license and will attempt to contact them.
• June 17th 2025, 17:21 UTC: On recommendation received, I contacted the County Attorney of Lewis and Clark Counry. As of today there is no answer.
• June 17th 2025, ~20:00 UTC: Initial two-way contact with FBI
• June 17th 2025, ~20:00 UTC: Leak is closed (according to my information the communication chain through the vendor and Bozeman PD reached the lab at pretty the same time)
• June 18th 2025 between 08:42 and 16:11 UTC: Further communication with the FBI