« first day (3313 days earlier)      last day (1567 days later) » 

4:08 AM
I posted my answer, I would be happy if someone can verify the grammar :D
 
 
2 hours later…
6:08 AM
is there any way this can be exploited? Sensitive information like secretPassword and flag are included via an external file, which is the bug here (i think),
 
 
1 hour later…
7:21 AM
All, I would be keen to get your thoughts on the ability for malware to infect encrypted drives. If a drive is encrypted and a device is booted using a LiveCD, I am assuming that if malware is downloaded, it wouldn't be able to infect the drive. It may be able to damage it but that would be the extent of its impact. Would this be a fair assumption or am I way off?
 
 
4 hours later…
11:50 AM
How much do you think you (an average person) spends using counterfeit/laundered cash in a week/month/year?
 
@ConorMancone Oh man, I forgot to save it
But I can give you the ad-hoc version here if you want
@JohnZhau Next to nothing
Well, laundered perhaps more, but next to no counterfeit money
 
 
1 hour later…
1:08 PM
@Ryan unfortunately you are way off. Drive encryption does nothing to protect from ransomware, because if you can use a drive as a user, so can ransomware running as you
 
 
3 hours later…
4:06 PM
@RoryAlsop He was asking about an encrypted drive when booting off of a live CD. So unless the encrypted drive has been mounted and decrypted, it would presumably be immune to ransomware.
Obviously if you booted from a live CD and then properly mounted the decrypted drive, all bets would be off. In that case of course, I don't know how you'd get ransomware running anyway...
 
How to explain to traditional people why they should upgrade their old Windows XP device? Ugh; story continues... Now I'm asked if I can make her computer able to watch youtube videos again. (YT displays messages about out of date software and does not show videos) Rrgh what do I do.......
 
4:50 PM
@ConorMancone yeah, that was kind of my point
 
 
1 hour later…
6:07 PM
@ConorMancone Thanks. So as long as the drive isn't mounted and decrypted, there is no way that ransomware could affect the drive? I imagine if the malware is designed to wipe the drive, it wouldn't be able to do so either unless it was executed on the host once the drive had been decrypted and mounted. Would that be correct?
@RoryAlsop Yes, I was assessing it from the point of view that the drive isn't mounted.
As a follow-up, does full disk encryption leave any space that is open to be written outside it? For example, if I boot a device using a LiveCD and do not mount the drive, is there malware could write to an empty unencrypted portion of the drive? I am assuming that full disk encryption does not have any unencrypted blocks.
 
 
1 hour later…
7:11 PM
@RoryAlsop Posted a question on the topic on the information security channel - security.stackexchange.com/questions/224039/…
 
@Ryan Malware could still find the unmounted drive and delete data. Unless it knows or guesses the password, then it obviously couldn't read the contents. However, whether or not there is any malware out there that tries to find new, unmounted drives to destroy is another question (it wouldn't be high on my list of concerns)
@Ryan I'm 90% sure that FDE technically operates at the partition level - not at the disk level. This means that if you partitioned your drive and left some unallocated space, and then encrypted the partitions, there would still be unallocated space on the drive.
However, the encryption "accounts for" the full partition contents. So if you had an encrypted partition that was only half full, there would be no way to tell that is the case without unencrypting the partition first (although I'm guessing a little bit more on that last point)
 
@ConorMancone If all partitions were encrypted, I am assuming that there is no unallocated space. Can you elaborate on " So if you had an encrypted partition that was only half full, there would be no way to tell that is the case without unencrypting the partition first (although I'm guessing a little bit more on that last point)"?
@ConorMancone What is the likelihood of malware that would wipe a drive if the device were booted with a LiveCD?
 
8:08 PM
@Ryan 100% if the malware was designed to do it. 0% otherwise
@Ryan You don't have to allocate 100% of hard drive space to all partitions. Of course it's rare to leave unallocated space, but if you did then you would still have space on the drive, even if you encrypted everything
 
8:32 PM
@ConorMancone Interesting. If I use the example of Veracrypt, there isn't the option for me to select a partition if I elect full disk encryption. This suggests (happy to be told otherwise) that there is no unallocated space.
@ConorMancone I am assuming that there have to be predicates for malware to execute and I am imagining that the likelihood of these conditions being present on a LiveCD reduce the risk dramatically. If I am making bold/wild assumptions, please let me know.
 
8:50 PM
@Ryan I don't know for sure how it works. Some portion of the disk must be unencrypted for it to be bootable in the first place. I always imagined that there is a separate boot partition that is unencrypted.
However I'm not 100% sure about the details, so I could be wrong.
 
@ConorMancone That makes sense since the BIOS would have to handover the process to the boot loader. Good point. I imagine that the if the boot loader is tampered with, it would corrupt it resulting in the inability to boot.
 
@Ryan Certainly! I personally wouldn't worry about malware when booting from a live CD. Although I suppose that a supply chain attack may result in malware on a live CD, which could be a convenient way to compromise new systems...
@Ryan having corrupted a few boot loaders in my day, absolutely :)
 
@ConorMancone Yes, supply chain is the new attack vector. Would you know if malware writing to the boot loader would result in corruption or are they sophisticated enough that it would continue to load?
@ConorMancone It has only happened once or twice to me :-)
 

« first day (3313 days earlier)      last day (1567 days later) »