WhatsApp Isn't Fully Deleting Its 'Deleted' Chats (theverge.com) 60
Facebook-owned messaging app WhatsApp retains and stores chat logs even after those messages have been deleted, according to iOS researcher Jonathan Zdziarski. The Verge reports: Examining disk images taken from the most recent version of the app, Zdziarski found that the software retains and stores a forensic trace of the chat logs even after the chats have been deleted, creating a potential treasure trove of information for anyone with physical access to the device. The same data could also be recoverable through any remote backup systems in place. In most cases, the data is marked as deleted by the app itself -- but because it has not been overwritten, it is still recoverable through forensic tools. Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. WhatsApp was applauded by many privacy advocates for switching to default end-to-end encryption through the Signal protocol, a process that completed this April. But that system only protects data in transit, preventing carriers and other intermediaries from spying on conversations as they travel across the network.
Not a SQLite problem (Score:5, Insightful)
...Zdziarski attributed the problem to the SQLite library used in coding the app, which does not overwrite by default. ...
That's not the root cause.
The root cause is the programmer who used SQLite and did not know that SQLite did not fully delete, or did know but did not care.
SQLite will only do what it is told to do by the programmer.
Re: (Score:3)
...Bottom line, what makes your "root cause" more valid than the one that TFS mentioned?...
If the requirement of the app is to properly and fully delete messages, it is the responsibility of the programmer who implements that requirement to assure the requirement is satisfied. It is not the responsibility of the tool to assure it is being properly used to meet the requirements of the app.
Re: (Score:2)
If the requirement of the app is to properly and fully delete messages, it is the responsibility of the programmer who implements that requirement to assure the requirement is satisfied.
Ergo, the requirement was to keep the messages while telling the user they were deleted. Who would have thought?
Re: (Score:2)
Re:Not a SQLite problem (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
The concern goes deeper than just disk I/O. On flash, there's a limited number of writes per flash erasure block, and using it in a mode that continuously overwrites everything you delete significantly increa
Re: (Score:2)
One way or the other, it is most unlikely the reason is some deliberate action by WhatsApp or evidence of its collaboration with police.
Interestingly, DBase and Clipper weren't deleting records in DBF-files [wikipedia.org] either — only marking them as deleted... But, hey, every new generation of programmers thinks, those before them were mostly morons and never encountered the "unique" problems they are facing.
Re: (Score:2)
Or you could just issue the PACK command, but raw disk reads will st
Re: (Score:2)
And telling "SQLite does not really delete" is like telling "Your filesystem does not really delete". So what? If you want secure deletion, use secure deletion. If you want to kill sqlite, use the "delete app data" button and import a backup (Whatsapp, not Titaniumbackup) afterwards.
Re: (Score:1)
I'll have what he's having.
Normal (Score:3)
This is pretty much normal of almost all modern systems, not sure why a single application is being targeted here? Look at ANY Copy-On-Write based file system, and you'll see this "doesn't erase" same practice. Of course the same will hold true for a Copy-On-Write database as well.
Fail is another 4 letter word (Score:5, Insightful)
How can a company declare a product "secure" when obviously no security audit was done?
If WhatsApp merely stated that in transit is encrypted, but data on your phone is open to discovery, even if deleted, at least they would have been honest.
Re: (Score:1)
How can a company declare a product "secure" when obviously no security audit was done?
"Secure" is the IT equivalent of "Organic".
Re: (Score:2)
Well, yeah.
"Secure" is a relative term. Obviously, when communicating there is no such thing as 100% security.
Anyway, given the lengths to which WhatsApp has gone to implement the Signal protocol, it is not hard to imagine that this small loophole will be closed soon enough.
Still, whether the hole is closed or not, loss of physical access to a communication device should always be considered a breach of your security. You have to assume if someone has physical access to your device that the information cont
Re: (Score:1)
It's end to end encryption, but at the ends it's not encrypted. That's why you use full disk encryption.
Working as designed (Score:1)
If you are counting on a app or service to really "delete" you are going to be suprised.
Alternate Headline (Score:5, Insightful)
A better headline would be "WhatsApp Isn't Securely Deleting Its 'Deleted' Chats"
Most file systems don't overwrite deleted data until the space is needed again. This is expected behavior.
Of course, this is a flaw that should be fixed- especially that any backups would be able to see everything- but this doesn't look to be a "backdoor" or anything nefarious in WhatsApp.
Re: (Score:3)
What's worse is that with flash-based storage, you can't ever be guaranteed that you've overwritten an individual file even if the OS thinks it has overwritten it 100 times with random data.
SSDs and other flash-based storage have wear leveling and over-provisioning which result in your writes not going to any guaranteed physical place.
The only ways to securely overwrite a file on a flash-based device are to:
1) Issue the ATA Secure Erase command and hope the drive actually does its job.
2) Use a tool provi
Re: (Score:2)
Your first problem is your journalling filesystem. The SSD will at least not give you the content of the deleted sectors without tricks. A disk image of your journalling filesystem will.
Re: (Score:2)
The SSD operates below the filesystem. It doesn't matter what filesystem you use. The SSD decides where to put data and where to say data has been put. They won't match up.
Re: (Score:2)
His point was that there's no way through the normal filesystem interface to recover deleted data on an SSD - you'd have to pull the chips and write your own firmware to explore them. With a journaling filesystem you may be able to "undelete" the file without nearly so much effort. And obviously if you have backups of any kind, that's even easier. Worrying about the SSD seems pretty far down the list.
Re: (Score:2)
You don't need to pull the chips, though that's not very hard.
You can send a national security letter to Samsung.
You can hack your own firmware together and flash it to the drive and have the drive dump out the contents of every flash chip.
For backups, everything should be stored encrypted (with a key you control).
For generic filesystem issues, use a better filesystem? Or at least one that provides a way to truly delete/overwrite space marked as free?
Re: (Score:2)
Strange, somehow it still sounds easier to dump the blockdevice, search for "From: Some Name" string inside the Dump and then cut a big block around it and recover the deleted e-mail instead of sending NSLs to Samsung to create a new firmware.
Re: (Score:2)
SSDs frequently encrypt everything on the drive. If you want to ensure everything is gone, destroy the key. Granted, if someone can restore the key, they can decrypt everything, but that's the tradeoff they took.
I suspect the same though was had for WhatsApp's use of SQLite. The messages (I assume) are encrypted at rest. So, an unlinked DB record (deleted but not zero'd out) is just a random binary blob that's only useful if you have the encryption key.
Even if WhatsApp DID zero out the SQLite record, if it'
Re: (Score:2)
A lot of SSDs even get that part wrong, storing the key in an easy-to-get area, not really deleting it and creating a new one, etc.
But even when it works, you can't delete "MySecretFile.txt" without also deleting everything else on the drive.
Re: (Score:2)
Not only are the established methods for secure erasure ineffective, but they also eat up valuable write cycles on flash chips for no tangible benefit - every write to a flash memory device is in effect a small amount of damage to the device, which when taken cumulatively over a long period of time, will eventually lead to the catastrophic failure of that device.
Worse yet is no ordinary software forensic toolset can even see that this data exists - the device consistently maps even the lowest level APIs aro
Re: (Score:2)
With HDDs you could access individual sectors and zap em as appropriate. With SSDs that's not the case. Everything is logically mapped by a controller and you have to trust it to do a secure erase properly - either resetting the encryption key or filling every block (even the ones used for over-provisioning) with 0s.
It's been a long, long time since you could do that. All modern HDDs do sector remapping behind the scenes, whatever written to a sector the disk later identifies as wonky and remaps is untouchable. Only secure erase will overwrite every sector, it predates SSDs by many years.
Re: (Score:1)
Yes, deleted files are (sometimes) recoverable (Score:4, Insightful)
In most cases, the data is marked as deleted by the app itself -- but because it has not been overwritten, it is still recoverable through forensic tools.
For the record, this is exactly what happens when you "delete" any file. The file system just goes to its little index of disk locations in use, and marks the ones the file's data is sitting in as available. Quick and easy. The data is all still there until the filesystem happens to give those locations away to a new file some day. There's nothing at all special about WhatsApp here. This is just how filesystems work.
Security professionals (eg: when I was working COMSEC jobs for the DoD) know to "zeroize" old data you really want to be non-recoverable. When last I checked, that's a matter of writing patterns of 1's and 0's repeatedly to the disk enough that the old data patterns are no longer recoverable. But typical OS's don't have that as a native operation, and it would be fairly unreasonable (not to mention dangerous) to expect a simple social media phone app to be jumping around the OS to do things like that itself.
Re: (Score:3)
writing once is enough. It's an urban myth that you have to do it more than once to obliterate the data. Manybe with old 10megabyte RLL and MFM drives you could easily recover information as the head was miles wide and the slop from the track move was insane enough that you cna easily see it. bot for the past 10 years a single wipe of zeros will make it impossible for the worlds best hackers to read the data on a modern hard drive.
Re: (Score:2)
There actually is a way, but it involves creating a file that's as big as the rema
Flash! (Score:5, Interesting)
At some stage you need to balance convenience and security.
Re: (Score:2)
Talking about other
Re: (Score:2)
Unless GP sp
In other news (Score:2)
Deleted? Yeah right. (Score:2)
If it is on the server, I am always going to assume that they keep them on backups and stuff even if I deleted them. :(