This Standard facilitates interoperability of systems claiming conformance in a multi-vendor environment, but does not, by itself, guarantee interoperability.

(NEMA, DICOM PS3.1, section 1)

hi guys!! today we're gonna learn how to make a medical imaging lab for cybersecurity!!! it's easy, it's fun, and a nice instance to learn!!! ready?!?!?

step 1: get an email!! step 2: get a shodan account!! step 3: type a protocol name into the search box!! step 4:

step 4:

there's so many.

how.

100 terabytes?

the search box does not judge you

here's the thing they don't tell you in the tutorial. you don't need an exploit. you don't need a password. you don't need to be clever. medical imaging runs on DICOM, a protocol older than most of the patients in it, and a shocking number of the servers that speak it are sitting on the public internet with the front door not just unlocked but REMOVED.

SHEDDING SKIN, SUCCUMB DEFEAT. THIS MACHINE IS OBSOLETE.

you point a scan engine at the internet, shodan, zoomeye, censys, whatever, and you ask "who here speaks DICOM." and the internet answers. cheerfully. immediately. way, way too many times. and its usually very very bad. the last thing you want on the open internet is a million people's CT scans. but as it turns out. that might be what you get.

I'VE SEEN IT ALL, GAZE INTO THE CRYSTAL BALL! TELL ME MORE, I WANT TO KNOW!!

number fifteen: an open port is a rumor. a C-ECHO is a confession

a listening port doesn't prove anything, so you don't get to count it. you verify. you send the gentlest possible DICOM handshake, a C-ECHO, the protocol's version of politely knocking and saying "you up?", and you see if a real thing answers.

one rule: --connections-per-host=1. ONE socket per target, ever. these are LIVE hospital systems. we watched 20 parallel connections drain a real integration engine's database pool once. a stalled hospital engine can mean delayed patient care. you do not, under ANY circumstances, DoS a hospital to satisfy your curiosity. you knock once, you write down who answered, you leave.

though it only takes a packet, but that's for another day.

number fourteen: the honeypot swamp

then it gets funny, because half the internet is now FAKE hospitals. security people deploy DICOM honeypots (dicompot, medpot) to catch weirdos like us, and they're everywhere. good news: they're bad at it. a real DICOM server is legally required to send an Implementation Class UID. the honeypot forgets to. it also accepts EVERY presentation context you throw at it, all 252, radiotherapy and ophthalmology and print jobs all at once, which no real machine on earth would do.

so you fingerprint the fakes and subtract them. our "live" count went from 908 down to 582 the second we did. one third of the scary internet is cosplay. the other two thirds is not.

YOU'VE BEEN TELLING LIES THAT I CAN SEE.

number... ok. look. the numbers. (and foot lettuce)

once you know where and how to look, the data just falls into your bag.

• 222 medical imaging servers, open, no authentication of any kind.
• 109 of them holding real, human, clinical patient data.
• 1,355,724 patients.
• 2,282,205 studies.
• 120,008,710 medical images.
• 71.89 TB.
• 41 countries. every inhabited continent.
• one single misconfigured server in kenya: 21 million images. more than the entire united states by image count. from ONE box.
• largest single trove: 213,315 patients on one server.

and thats just human, fleshy data :) we have more on the veterinarian side, so not even your cat or my dog are safe.

then... there was pwnage.

one of those servers, a hospital archive, 178,991 patients, was already under active ransomware when we found it. someone else got there first. the door was open long enough that a criminal group walked in, locked it behind them, and started charging admission, and it was STILL answering the open internet when we knocked.

TEAR A HOLE EXQUISITE RED, FUCK THE REST AND STAB IT DEAD.

and one break-in is the optimistic reading. the same unlocked door we used to read the label is the door they used to take the whole cabinet, and there's no counter on it, no way to know we were the second ones in and not the tenth. a hospital archive held hostage isn't only a leak, either. it's the prior scan a doctor can't pull up while you're on the table, the baseline that decides whether the shadow on this year's image is new or old news. you never feel the breach. you feel the appointment that slips because the box holding your history is busy being someone's ransom.

that's the stakes!!! not the terabytes, not the flex, and deffffinetely not the countdown lol. behind every one of those 120 million images is a person who had a bad day at a scanner!!! and what happened!! they trusted that the picture of the inside of their body would stay between them and their doctor. a name, a birthday, a diagnosis, a tumor, a broken kid's arm! none of them did anything to deserve being a row in my csv :) but they did. never ever open the drawer >:3 unless you want the cops at ya door lmao.

we read the label, never the files

every number up there came from the server's OWN metadata. orthanc, the most common of these, has two endpoints that'll tell you patient count / study count / image count / disk size without authentication. that's it. that's all we touched. we read the label on the filing cabinet. we did not open the cabinet. we never viewed, downloaded, or stored a single image, and there is not one byte of patient data anywhere in this research. the horror is entirely in the counts.

and then we told someone :)

this is the part every "look what i found" post skips, and it's the only part that actually matters. finding a million exposed patients is worthless if the door stays open. so we wrote it up and shipped it: 124 disclosable hosts, 43 coordinated notices, routed to national CERTs or, when the CERT was unreachable, straight to the hosting provider's abuse desk. never to the victim org directly. every single host got a working disclosure channel.

then we watched the world's incident-response system respond, and the spread is its own finding:

• hostinger suspended an exposed host (51,000+ patients) in 22 HOURS, unprompted, before the operator lifted a finger. the provider fixed it FOR them. a happy ending exists!!!
• france replied by citing article 47 of their good-faith-researcher law instead of a status, a lovely reminder that disclosure is a legal act, not just a technical one. then action!
• and the majority: silence. notice sent, no reply, no ticket, no way to know if anyone read it. patient data just... sitting there, in the open, indefinitely, while the one backstop left (the regional registry that handed out the IPs) shrugs and says not my problem.

so. that's how you make a medical lab for cybersecurity. step one, get an email. step forty, realize the lab was already built, it's global, it has 71.89 terabytes in it, and nobody's guarding the door.

we did create a tool, massrep, for you guessed it: mass reporting. it eats the census and spits out one coordinated-disclosure email per country, every host tagged PHI or veterinary or empty-but-wide-open, routed to the national CERT or, when a country doesn't have one, straight to the hosting provider's abuse desk. it logs every message it sends so it physically CANNOT double-notify anyone, which is, i'll note, more care than the standard we're reporting has ever taken with your insides.

oh nema.

read the quote from the beginning on the post. that's not a fabrication, its taken straight from the standard that is supposed to handle your images. the standard that's supposed to CARE about your images. the standard that's supposed to PROTECT your images.

do they care? do they not? they're still making "recommendations" or "suggested" security profiles; take into consideration the following: the base profile is plaintext over an unauth socket. so, when the standard tells the developer "eh, dont even mind about encrypting comms, or putting auth. it's a suggestion, but not MANDATORY".

i'll ask again: do they care? wrong question. read the acronym: NEMA is the National Electrical MANUFACTURERS Association. the standard that handles your images is written by the people who SELL the boxes. (yes, technically the DICOM committee sits under MITA, a NEMA division. same vendors, same table.) so of course auth is a "suggestion" and TLS is "left up to the application." why would the manufacturers mandate a MUST that eats their margin and pins the liability on them? a MUST is a warranty. RECOMMENDED is a shrug they can invoice. the fox didn't forget the lock. the fox drafted the spec :)

when security is a suggestion, assume it to be off. RFC 2119: MUST, SHALL, mean that the definition is an absolute requirement of the specification. RECOMMENDED, as in you should, but eh, don't care. MAY, completely optional.

when something as simple and MUNDANE as TLS is:

DICOM does not specify how a secure transport connection is established, or the significance of any certificates exchanged during peer entity authentication. These issues are left up to the application, which is assumed to be following some security policy. Once the application has established a secure Transport Connection, then an Upper Layer Association can use that secure channel.

PS3.8, Chapter 9, Note 3.

it'll get worse. i'll make it worse :)

we have a lot, and i mean a lot of research we can't yet publish. i mean we can. but, believe it or not, i have ETHICS!!

nesting is a BITCH.

A WITCH WILL OPEN THE DOOR, FOLLOW ME AND MEET OUR HIGH PRIESTESS. COME, COME, INTO MY COVEN! AND BECOME LUCIFER'S CHILD!