McKesson admits breach as ShinyHunters demands $55.2M:
Two major healthcare businesses, Boston Scientific and McKesson, disclosed more details over the weekend about separate cyberattacks that disrupted global operations and resulted in stolen patient data, respectively.
Medical-device maker Boston Scientific, whose IT systems were hacked by unknown intruders last week, said the cyberattack remains ongoing. It also noted that pacemakers and other heart devices implanted after the August 25 breach cannot provide remote monitoring and data transmission as intended.
"New remote monitoring communicators cannot be activated, thus available device data will NOT be transmitted to remote patient management systems until the communicator can be activated," the medtech firm said in a late Friday update.
This applies to all new cardiac rhythm management implants other than insertable cardiac monitors (ICM).
ICM devices must be activated using the Boston Scientific Clinic Assistant app to ensure the device correctly records patients' heart rhythms, the company added.
Because of the cyberattack, "new ICMs are unable to pair to the patient remote monitoring mobile phone, therefore available episode data recorded by the ICM will NOT be transmitted to the remote monitoring system until the ICM can be paired to the patient mobile app," according to the update.
The devices will still record any episodes, and patients can transmit these to the remote monitoring system by in-person transmission via the Clinic Assistant app. This is done by selecting the "interrogate" button, according to the company.
Once its IT systems are back up and running, and the heart devices can pair with home monitoring equipment, they will again transmit recorded data to the remote systems.
[...] Meanwhile, in another cybersecurity incident that has been very publicly claimed by the criminal perpetrator: pharmaceutical and medical supply giant McKesson over the weekend confirmed an intrusion after ShinyHunters on Friday told The Register it broke into the company's Snowflake and Salesforce instances and stole millions of patients' data.
"Based on our investigation thus far, including assessments by leading cybersecurity industry experts supporting our response, we've confirmed that the unauthorized access to certain third-party applications and the exfiltration of certain data was associated with a subset of customers within our Oncology & Multispecialty and Medical-Surgical business units," Francisco Fraga, McKesson executive VP, chief information officer and chief technology officer, said in a Saturday statement.
[...] The McKesson records, according to the ShinyHunters spokesperson, include patients' full names, home and email addresses, phone numbers, dates of birth, Social Security numbers, appointment dates and notes, and sensitive illness details including cancer locations on people's bodies. The group also claims to have swiped emails containing private information from doctors to patients.
The spokesperson told us they accessed the company's Snowflake and Salesforce instances by voice phishing "multiple employees." This is a tried-and-true method popularized by the data-theft-and-extortion gang, which has victimized other medical providers in recent months. These include pacemaker manufacturer Medtronic in April, and cancer diagnostics business Exact Sciences in July.
(Score: 1, Interesting) by Anonymous Coward on Sunday September 06, @12:49PM (4 children)
Why can't these companies just pool some resources together and track these fuckers down and terminate them with extreme prejudice. It clearly seems to be the same groups and people over and over again. If they can't secure their data and networks perhaps they should just solve their security problem some other way.
(Score: 3, Touché) by Tomahawk on Sunday September 06, @01:16PM (1 child)
Someone else will just fill that void. How much of the population do you wish to terminate? 'cos it'll be a much larger percentage then you expect.
(Score: 1) by khallow on Sunday September 06, @08:21PM
Is the entire populace budding medical hax0rz who just aren't bothering because these guys got there first? While I don't consider murder practical (especially since it could be a state-protected group with the state quite capable of murdering back), some degree of doxxing would be appropriate.
(Score: 5, Touché) by Bentonite on Sunday September 06, @01:39PM (1 child)
With which method do you propose to reliably track the perpetrators down?
You'll most likely end up killing the wrong people (such group can clearly do something as trivial as hijack someone else's computers and proxy their traffic via those computers).
Even if all the perpetrators were correctly located, another group would soon appear to replace them.
One cause of the issue seems to the terrible security of microsoft software and tracking devices.
But I guess one correct cause of action, that won't kill anyone innocent, would be to terminate microsoft and apple and google with extreme prejudice.
(Score: 1) by khallow on Sunday September 06, @08:22PM
I grant that if one were able to murder enough such groups and did so, then the universe would quickly run of replacements.
(Score: 5, Informative) by bzipitidoo on Sunday September 06, @01:28PM (8 children)
Here we go again. This story smells. Industries that develop products that depend on software, without software development being a core part of their business, make this mistake again and again. Seen it in healthcare, automotive, utilities, entertainment, banking and finance-- pretty much everywhere, though it varies. Finance obviously must be careful, and takes computer security more seriously. And healthcare? Worse than average, I'd say. I'd rank Big Media at the very bottom, for stubbornly refusing to admit that DRM doesn't work. Even professional software development businesses sometimes mess it up.
Industrialists always view software development as a cost, to be done as cheaply as possible. They often fail to understand that Security Through Obscurity is not real security. And that basic security, just using the available tools, without trying to defend against whatever exploits may exist in those tools, is not that hard to do. But they think it is hard, and therefore costly, and they don't want to pay. They also want to believe that the sort of people who took a few programming classes while majoring in English or Psychology or Art, then after graduation ended up in IT where they made a few web pages and maybe got a cert or two, can do software engineering well enough to serve their needs, and at half the cost. Such people may never have studied computer security and heard of such things as cryptographic hashing and salt, to protect passwords. Their idea of a strong password is the old "capital letter, lowercase letter, number, Special Character, and length at least 8." (While that's not totally wrong, it does represent a ducking of responsibility by shifting some to the users.) They don't really understand Public-Key Cryptography, and digital signatures. They sure don't understand vulnerabilities such as side channels.
(Score: 2) by Bentonite on Sunday September 06, @02:00PM (3 children)
Obscurity is the exact opposite of security.
Security consists of every detail of the system being available for public scrutiny, so the security flaws end up getting found and fixed.
If any part is obscure, then anyone who bothers to work out the obscurity can exploit the unfixed security flaws.
(An encryption key etc should not be kept obscure, hidden under a doormat - it should be kept secret instead - an encryption key that can be reset as needed, is the only thing that can be reliably kept secret anyway).
That is a totally wrong password rule - that causes 99% of people to either go for; Password1! or a weak password that is hard for humans to remember, but easy for computers to guess.
The issue is compounded with regular forced password changes - most humans can't remember a password that is changed every month, unless that password is; Password1! and is changed to Password2!.
The only rule should be 8+ characters, which would allow an actually secure password to be used, for example 6 random words, although even a measly 3 words (provided the dictionary is substantially larger than the diceware set), is likely to have more entropy than what humans can come up, that can be remembered, according to those rules.
(Score: 4, Insightful) by JoeMerchant on Sunday September 06, @02:52PM
>Obscurity is the exact opposite of security.
In extremis, this is true. Obscurity kicks the can down the road, makes people comfortable without security. Sometimes it "works" effectively forever:
Were the runic codes truly secure? Most of them were broken, one might say the keys were more obscure than secure - but some methods apparently were obscure enough...
The problem with true security is that it has unavoidable costs and complications which are very real, immediate, and at many times outweigh the value of the secrets being protected. Couple that with the lower costs and still somewhat practical effectiveness of obscurity methods and you hit the question: how long do you need this secret to remain secret? Will an obscurity method serve that need?
🌻🌻🌻🌻✌️ [google.com]
(Score: 2) by Dr Spin on Monday September 07, @08:49AM (1 child)
I have been a computer user since about 1973. I have 25 pages of passwords and am too old to remember any of them. They are kept in an encrypted file, with a backup on tape.
I have two tower PCs, a Mac Mini, two Android tablets and two phones. On some of them, there is a password manager that that mostly works.
Yes, it is a total bloody nuisance.
Passwords need to be fixed replaced NOW. Surely there is at least one clever person in the world!
My best guess is that all hardware should be compelled by law to have an integral RFID reader that can read my (previous) bus pass or one of my (out of date) debit cards that I can mark inactive and discard when I want to change my ID. And bleep like crazy if the ID is reported compromised.
Obviously, I should be able to register more than one card with each device, so as to have a fallback if the active card is compromised or lost.
--
However, if my ID here is compromised, I might not want my CURRENT back card blocked. I am not saying that the service provider should have say in which card is used,
although I would expect banks to insist. I think Soylent, and others like it should have NO SAY at all as to which cards I use. I should be free to register whatever card I like (possibly with my browser) and change it whenever I like - preferably without their knowing. As in, the browser should have a way to negotiate security, like HTTPS, that ensures, in a way not compromisable by the user, that depends on the ID read from the card.
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by Bentonite on Monday September 07, @10:06AM
No, RFID readers must not by required by law - a computer must not be required to have any sort of specific input device, as if such requirement exists, then that *will* be used for evil.
A requirement to bleep when an RFID tag is compromised, adds a surveillance requirement and also would likely end up with a bunch of the card-passwords being transmitted over HTTP to some ??? server (as that's what the typical proprietary software developer will do to implement the checking part of the requirement).
There are already plenty of hardware authentication devices that communicate via usb or bluetooth, but almost all of them are backdoored to hell with proprietary software.
Debit cards and bus cards use a bunch of different versions of RFID or NFC depending on the cards.
NFC is encumbered by patents until at least 2030 (patent expiry doesn't even save RFID, as what companies do is make a slight mathematical change to RFID and then patent that).
While it wouldn't be technologically infeasible to design a reader that can read most RFID and NFC tags, it wouldn't be commercially feasible to get such reader manufactured, due to the queue of rent seekers that will show up.
Anyone with the slightest bit of intelligence has realized that passwords as a concept are not broken and all so-called "replacements" to passwords are always insecure, without fail.
To use such cards as a password is a terrible idea as;
- The stored value on the card is likely to be of low entropy and easy to bruteforce.
- The producer of the card is storing the card value on some insecure database somewhere.
- Someone walking past you with a RFID/NFC antenna hidden in a backpack, will likely be able to scan the cards and therefore get your password (not that uncommon with credit cards - which is why RFID-blocking wallets exist - but the effectiveness of an ungrounded Faraday cage isn't great).
If you really want, you could implement such scheme yourself as a PAM module on GNU/Linux - on tapping the card, the user account will log in and you can also use it to unlock a password manager that uses PAM - but that would be less secure that just choosing a single decent password for PAM.
For forum sites like soylent, you may as well let a web browser store a random password for you, as it really doesn't matter if an attacker manages to post with your account does it?
(Score: 5, Interesting) by JoeMerchant on Sunday September 06, @02:45PM (3 children)
20-ish years ago I worked for a pacemaker-like company (made neurostimulators basically identical to pacemakers except they stimulated nerves instead of cardiac muscle).
The software in those devices was primitive, near trivial in what it did (timed delivery of a pulse train) - with a couple of kinds of I/O, a magnet activated reed switch that would trigger an early / elevated pulse output, and a low speed serial port with a physical layer of an air-core transformer - the serial port allowed configuration of the device.
By today's standards, the software being shipped 20 years ago was criminially negligent. The only real security was that access to the programmer wands was a little difficult, but anyone with $50 and access to Digikey could cobble one up. The protocol was trivial to reverse engineer, nothing resembling encryption or even attempts at obfuscation. The checksum was 8 bits. I don't doubt that similar software continued to ship for another 10 years, and there may be more than a few people with those outdated implant designs still walking around today. The next generation at least boosted the checksum to 16 bits, when I left the company in 2006 they hadn't even acknowledged encryption as "a thing" much less an option. The neurostimulator wasn't usually powerful enough to cause cardiac arrest, though it did in about 1/700 implantations at time of implant - this usually didn't happen later, but pacemakers definitely could cause cardiac complications and back in the day they all used similar protocols. When Dick Cheney got a pacemaker, they customized it somehow (security through obscurity) to try to prevent its use in an assasination.
At the time, it wasn't a lack of competent software engineers, it was a tradeoff: security vs device performance, and security basically always lost - to such an extent that the software engineers more or less forgot about it as a concern because every analysis ended in: "Yes, we could make it more secure, but that would result in direct negative impacts to the patient via X, Y and Z and the security just isn't worth the tradeoff." There were instances where that call was made wrong, security really should have won, but like the Space Shuttle engineer screaming "don't launch after the air has been under 32F!!!" management was deaf to the noise until after several deaths occurred. Strikes me as quite similar to highway / traffic control engineering in reality: when do you get a new traffic light? Usually after the 2nd fatal crash that could have been prevented...
🌻🌻🌻🌻✌️ [google.com]
(Score: 3, Informative) by HiThere on Sunday September 06, @07:35PM (2 children)
The key here is that you had to use a wand to reprogram them. You couldn't do it over the internet. That made it "sufficient" security.
What probably happened here (my guess) is that someone just took that kind of system and added a wifi link...and that's NOT good enough.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 4, Informative) by HiThere on Sunday September 06, @07:38PM
Looking over the summary again it looks like is was the offices that got targeted, not the devices. The argument is (pretty much) still valid, but it doesn't apply to this case.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Informative) by JoeMerchant on Sunday September 06, @08:29PM
Our "nightmare scenario" was an attacker with a big loop of wire - like the anti-theft portals at retail doors - such a device could be used to communicate with the implant at longer range and could simply spam out commands for things like 'reprogram to maximal (painful) near continuous output'.
They talked about an attacker reprogramming Cheney's pacemaker with a coil hidden in a chair or maybe a briefcase...
For the most part. There were other flaws in the implementation that should never have been present which made the potential mishaps much more serious than they needed to be, and when you have 100,000 people walking around with the same device in them "potential" isn't a "maybe this happens" it becomes a "how often does this happen?"
🌻🌻🌻🌻✌️ [google.com]
(Score: 5, Informative) by lonehighway on Sunday September 06, @03:39PM
At least in the case of McKesson the security failure was human.
“ The spokesperson told us they accessed the company's Snowflake and Salesforce instances by voice phishing "multiple employees." ”