Popular DNA Sequencer Left Vulnerable By 7-Year-Old Firmware, Unfixed Security Flaws (arstechnica.com) 37
A widely used DNA sequencer lacks crucial firmware security protections, potentially exposing genetic research facilities to cyberattacks, security researchers said on Tuesday. The Illumina iSeq 100, deployed at 23andMe and thousands of laboratories worldwide, runs on outdated BIOS firmware from 2018 that doesn't enforce Secure Boot protection against malware infections, ArsTechnica reported today, citing researchers from Eclypsium.
The device's manufacturer, IEI Integration Corp, supplies motherboards to numerous medical equipment makers, suggesting similar vulnerabilities could affect other devices, Eclypsium said. Illumina said the issues were "not high-risk" and would notify customers if mitigations were needed.
The device's manufacturer, IEI Integration Corp, supplies motherboards to numerous medical equipment makers, suggesting similar vulnerabilities could affect other devices, Eclypsium said. Illumina said the issues were "not high-risk" and would notify customers if mitigations were needed.
Stop using windows (Score:2)
Secure boot is a joke. TPM is a joke. All the malware attacking these devices over an 18 year old flaw is a joke.
STOP USING WINDOWS.
and item.
Re: (Score:2)
Re:Stop using windows (Score:4, Interesting)
Most of this stuff is 'just a pc' the type threat actor who can obtain physical access to the device, long enough to tamper with the BIOS or the boot media can probably just swap the entire system board out! If what we are worried about isn't persistence on the device but the data already on the device you hardly need 'secure boot' to implement disk encryption.
Let's not pretend for a second all the other legacy systems handling your medical records all implement secure boot either or that a insider threat (compromised sys-op) can't do bad stuff.
I am not saying secure boot is completely worthless but don't for a second believe its use on desktop PCs in 90% cases and Microsoft's insistence upon it have anything to do with security, at least not security of the systems owner. There are cases with mobile equipment and things which maybe more frequently left unattended where secure boot could be important but pretending not having it some some bit of stationary laboratory equipment posses some unique threat is just laughable.
Heck if I wanted to steal your medical records, there probably server-side-cross-site-scripting attack that is going to get me become a provider in the patient communications systems without leaving my basement. No need to B&E the lab a start tampering with equipment.
Re: (Score:2)
It's also completely irrelevant whether you have DRM Boot enabled or not when you're loading Windows with it. It's like complaining that you're not using an armoured van to take a letter from someone who lives under a bridge to someone who sleeps on a park bench.
And... it's an obscure piece of medical equipment which will be locked up in a lab somewhere. Who's going to bother attacking it, and why?
Does Eclypsium have another VC funding round about to come up or something?
Re: (Score:2)
Errr yeah they can. Systemd even supports TPM2 as a key store for systemd-cryptenroll which you can use for FDE of your system drive out of the box. That's before you consider there are other programs out there that offer the feature too.
Re: Stop using windows (Score:2)
Re: Stop using windows (Score:2)
Judging by what buggy mess Windows 11 is right now, I feel immensely relieved that what you wrote must be a joke. Else I would leave the IT and become a plumber or something.
The TPM thingy doesn't magically turn Windows secure, dude. TPM on Windows is not unlike a lipstick on a pig. It's still a pig.
Re: Stop using windows (Score:2)
Re: (Score:2)
Re:Stop using windows (Score:4)
Guys who work at big commercial ISVs that can afford to be part of Microsoft's little key signing cartel support standards that effectively lock out others! You don't say.
Sorry if Tim Burke is out there supporting Secure boot in its current form. That makes him a shill!
Re: Stop using windows (Score:2)
When RMS endorses Secure Boot, I will turn it on. Or when it becomes impossible to turn off, whatever comes first.
Lab hardware (Score:5, Informative)
Design requirements (Score:5, Insightful)
This is pretty universal for lab and hospital hardware and software, for certain classes of equipment there isn't anything for sale that runs on anything newer than WinXP and the expectation is you aren't going to put it on an unsecured network or give it internet access. I'm not saying it is a good thing, but it isn't really unique to sequencers.
This is largely due to regulatory design requirements.
The process for getting a product to market involves design certification with the relevant regulatory agency, the FDA in this case. The entire process is long and involved and expensive, and the result is a product that's "fixed" in time and technology and can't be changed in any meaningful way.
As a corollary, "can't be changed in any meaningful way" is also "can't be upgraded to use newer technology".
I've worked on a few medical (and many aviation) projects. For reference, we estimated at the outset that the certification process takes between 8x and 15x the cost of the actual design. For example, a "largely software" project took 8x the number of hours that it took me to actually write the software. Add some hardware design and the cost goes up to almost 15x. (There's some dependence on criticality here: heart/lung machines need more regulation than ultrasound machines, for obvious reasons.)
To make any meaningful change requires that you go through the entire design process a second time.
If there's an *error*, a fault that can be corrected by a small change (such as a one-line software fix), you can squeek that through on the original design requirements, but it still requires a fair bit of checking and sign-off from lots of people.
Now, to be fair, this all started with the Therac machine [wikipedia.org], an X-ray system that would circle the patient and irradiate their cancers. A software flaw put the machine into calibration mode, which enabled the X-ray generator at maximum power, which killed patients. After that incident, the FDA started looking more closely at software quality.
Or alternately, this all started with thalidomide [wikipedia.org], a sedative thought to be safe, but was found to cause birth defects during pregnancy. It was only because of the misgivings of one FDA reviewer [wikipedia.org] that this drug never made it into the US.
So there's a case to be made for strong scrutiny of medical things, both pharmacological, hardware, and software.
A drug that for a disease that only affects 200 people in the US is unmarketable. We have cures for such diseases (source: direct conversation with a doctor at Berman Gund laboratories), but there's no regulatory way to test them, or deploy them. The regulation process would be too expensive.
Or a recent cure for migraine headaches: a device that looks like a short hockey stick, when you feel a migraine coming on you hook the stick over the back of your head and press a button, it generates a magnetic field pulse, and the migraine stops. The inventors claim that the device works, but they also claimed that there is no way to get the device to market because of regulatory burden.
So there's also a case to be made that such strong scrutiny slows down innovation and prevents progress.
So apropos the problems mentioned in the article, note that old firmware isn't fixed or upgraded, security upgrades to Windows 10 is about to stop, and no one can upgrade firmware or hardware without an expensive complete recertification.
I hate it when someone puts out a single "gotcha" phrasing of an issue, and then says "discuss".
But... here's an overview of the situation.
Now, discuss.
Re: (Score:3)
Don't believe everything you hear.
The main reason is if it ain't broke, don't fix it. Most medical and lab equipment that can be connected to a network is designed to be run on a secure network. You don't want to be responsible for making sure your doohickey isn't hacked, and you really don't want to be responsible for trying to hound a thousand hospital IT departments into installing and testing your updates.
Drugs for very rare conditions have appropriately modified trial requirements. They may be "unmarke
Re: (Score:2)
As with everything, you need to compare cost vs. benefit. An xray machine that could kill a patient needs ways to be sure it can't don't that. (Maybe not by fixing the software - I can imagine other ways).
A DNS sequencer? A device that in the worst case can't hurt anybody? Don't bother. You'd be making things worse by slowing down medical progress.
The real problem is the one-size-fits-all and gotta-cover-regulator's-ass attitude of the FDA.
Re: (Score:2)
Just because it can't harm a human directly doesn't mean it should be given a free pass by regulators. If your DNA sequencer has a bug that causes it to output an incorrect result, that could cause problems. Maybe it will incorrectly detect that a patient doesn't have a certain gene that increases their risk for xyz when they do. Maybe it will incorrectly determine that a sample from a suspect isn't a match to a sample from a crime scene.
Re: (Score:2)
A DNS sequencer? A device that in the worst case can't hurt anybody?
Disagree. Pharmacogenomic interventions come to mind as just one counterexample. The presence of a particular genomic variant might indicate: "This patient doesn't effectively metabolize XYZ drug. Double the dose.". If the sequencer incorrectly identifies that variant, that's a direct contributor to a patient getting the incorrect dose of a medication and all of the potential harms that come with it.
Re: (Score:2)
Pretty much everything that is remotely critical needs to be on an air-gapped network, or rely on perimeter security.
There are 5 key problems:
1. If the network is air gapped, how does a vendor deploy updates?
2. If the application is remotely specialized, how do you know the update won't break something?
3. The cost to test and deploy an update can be massive. Essentially, deploying an update means taking down a critical piece of equipment, trying a change, seeing if it affects anything, fixing the probl
Is it networked? (Score:4, Insightful)
Are these devices even networked? This is just a fearmongering article, secure boot introduces just as many problems that it solves.
Re: (Score:3)
Probably, you have got to get the results off somehow and well a network is as good as anything else.
Re: (Score:2)
Re: (Score:2)
Actually, probably not. You want bulk data transfer from a sequencer once every three days, since that's how long a run takes. It would be quicker and easier to sneakernet an SSD drive with the data.
You also have to remember that the sequencers need to be in an ultra-sterile Clean Room environment. You can't go drilling holes in walls afterwards and you can't put CAT6 in an autoclave and gave it be usable.
OMG! (Score:2)
Re: (Score:2)
How? The sequencer just does the sequencing, it doesn't retain a database of sequences, that'll be done on a different machine. Further, there's no point in having a sequencer on the Internet and nobody uses them that way. They're all on secured networks that are wholly independent.
Some organisations go further. FTDNA keeps data storage in a totally different organizational unit, and uses an internal pseudo anonymous code to identify samples, so even if soneone broke into the lab, nobody could know who the
No Secure Boot? (Score:2)
This makes me wonder how much of an issue no Secure Boot really is. On one hand, it will protect against a NotPetYa style of attack where a program overwrites the MBR and boot sector... but if a program can get that much access to a machine that it writes code to the raw disk, it likely can do a lot of damage in other places. The exception is if physical attacks are expected, where Secure Boot can be one of the few active mitigations, especially combined with BitLocker.
For a device that is on an isolated
Re: (Score:2)
It just moves the problem. The PC in the library. I could just swap the entire system board out with my own, if secure boot is really my impediment and I can get unattended access to the device for a long enough period of time.
The real issues is key management, and who controls them. If it was about anything other than control and vendor lock it you'd be able to easily sign your own copy of the windows kernel / drivers / bootloader etc. By easily I don't mean in the point-and-click sense I mean in the you
I've been in labs with devices like these (Score:2)
and they are mostly on private networks. Many of the networks are not connected to the internet. Unless you were a hacker directly targeting a lab, you won't see one of these get hacked. Another problem is if you are hacking something you'll target a consumer device that have millions of endpoints, not a device that is only made in the handfuls.
Internet diode (Score:2)
Seems as though a need for an internet diode invention to only allow one way traffic from an embedded device and only an OK handshake back from the internet.
Re: (Score:3)
Diode is pretty geeky. You need to change the name to something that sounds cooler. "Internet Condom?" Not bad, but people get weird about sex. How about "Internet Wall?" Mmm. No pizazz. Hey, "Internet Firewall!" Or just "Firewall." Yeah, now that sounds cool!
They exist, sort of (Score:1)
It's not TCP/IP, so it's not "Internet" as such, but devices that only send out status/alarms and only read low-speed data from another device (e.g. "START SENDING/STOP SENDING/RESEND") have existed from before the moon landing.
Sometimes, like with visual or audible statuses or alarms, there is (or can be) a "man in the loop" who can either take direct action (powering off the system in an emergency) or pass the information upstream (make a phone call to a supervisor, or type the status or alarm data into a
Re: (Score:2)
Something like an easy setting of what's allowed to go out from the device and what's allowed to go into the device.
Could be serial ports RTS/CTS handshaking, could be TCP/IP, could be others.
Some software systems have an admin console only mode for applying updates for just this reason.
That is actually rather irrelevant (Score:2)
...and in some ways even good.
First of all, to abuse those holes you need to have physical access. If you have that there are far more lucrative things you can do than "install malware". Second "Secure Boot" does not secure against malware. Malware typically doesn't care about the boot process.
Then there is the whole set of advantages. Without "Secure Boot" it's probably easier to clone a harddisk before the old one dies. It makes it easier to run the device without a support contract. (though there are oth
Secure Boot is worthless. (Score:2)
I wouldn't worry about a lack of Secure Boot, frankly. There's probably other BIOS bugs that are far higher priority, and we know there are firmware attacks that can escape all antivirus detection.
Having said that, nobody but nobody runs a scanner like that directly on the Internet.
Translation: (Score:2)
Eclypsium are Microsoft shills.
Lacking secure boot is not a vulnerability, folks.
You're worried about that? (Score:2)
Popular DNA Sequencer Left Vulnerable By 7-YearOld (Score:2)