I talked to a software developer once that had used ECB because it was the only way they could think of to allow an arbitrary block of ciphertext to be decrypted without decrypting the prior blocks (i.e. they needed random access as opposed to decrypting the entire ciphertext every time).[1] A lot of the older cryptography libraries I know of only supported ECB and CBC, and a lot of older programming examples only discussed those too, so that dev may not have ever heard of counter-based modes even though those have been around since 1979. Not sure if that's anything like what happened here, but if this feature has been around for awhile maybe it was a similar case?
[1] I've talked to a lot of software developers about the dangers of using ECB over the years. The discussion I'm referring to was the only time I've really been surprised. Usually it's been because the library they were using defaulted to it.
To be more clear for those less familiar with the operation modes of block ciphers, the CTR mode allows encryption or decryption at arbitrary positions in a text, in a random order, exactly like the ECB mode.
Moreover, the implementation of the CTR mode is trivial when an ECB function is available from a library, a CTR encryption or decryption is done by invoking ECB on some non-repeating value, e.g. the value of a counter incremented after each encrypted block, and computing the sum modulo 2 (a.k.a. XOR) with the plaintext (for encryption) or ciphertext (for decryption).
For random access, an appropriate offset is added to the counter.
When the threat model for a SSD or HDD is only that it might be stolen, the CTR mode is a perfectly secure method to encrypt the SSD or HDD, using the sector number as the counter value.
The slower and more complex encryption modes that have been standardized for full disk encryption, and which are used in most full disk encryption programs, are conceived for the use against a much more powerful opponent, who is not just a thief but who is someone able to access the SSD or HDD frequently, for many weeks or months, without the knowledge of the owner, and who will be able to frequently make snapshots of the SSD/HDD as it evolves during that time, to be analyzed for values that change in time, which can reveal differences between the corresponding plaintexts, which might allow the plaintexts to be guessed (i.e. if a text file is edited frequently, the content of the parts that change between versions might be guessed by the opponent who watches the SSD).
This threat model is valid only for someone who is a person of interest for the surveillance by some TLA.
It does not take a state-level adversary to watch changes in a disk over time. It's a pretty basic cryptanalytic setting to operate in. You're talking about XTS vs. CTR; the problem with XTS is that it leaks in way that somewhat rhymes with what ECB does, and of course the much larger problem is that none of XTS, ECB, or CTR are authenticated --- an adversary with durable access to your disk won't bother trying to cryptanalyze it, because it's easier to compromise one of the executable binaries running on it by manipulating the ciphertext.
All of these are reasons why you want to avoid using full disk encryption outside of the narrow problem of your laptop getting stolen out of the back of your car or something.
I agree that full-disk encryption (i.e. encryption inserted in the block device driver) is not the right solution for storage encryption, and also the encryption at the file level is not a solution.
The right place where storage encryption must be inserted is in the file system implementation, where it is possible to implement a completely secure form of authenticated encryption. This is especially easy to do in the so-called copy-on-write file systems or log-structured file systems.
However, file system implementations are much more complex than block device drivers, so modifying them to insert encryption in the right way requires a lot of work, which nobody has done for any of the popular file systems.
While there are some commercial solutions that claim to be secure I have not seen anyone that manages the secret keys correctly (no secret keys should be stored in the encrypted device itself, regardless if they are encrypted with a password, because encryption based on a password is much weaker than with a long random key).
If you just prepend a counter you can very easily sidestep the issue. Be sure to lookup though the behavior of the encryption algorithm if a part is known, predictable or chosen by an attacker.
> it was the only way they could think of to allow an arbitrary block of ciphertext to be decrypted without decrypting the prior blocks (i.e. they needed random access as opposed to decrypting the entire ciphertext every time).
CBC mode does support that, though (decryption is parallelizable, but not encryption).
[1] I've talked to a lot of software developers about the dangers of using ECB over the years. The discussion I'm referring to was the only time I've really been surprised. Usually it's been because the library they were using defaulted to it.