How to prevent the next Microsoft Exchange hack

Defenders must protect all possible entry points, while attackers only need to find a single weakness to get in.

ProtonMail says it uses zero-access-encryption but people who use the free service because they don’t need anything more are still vulnerable (somewhat) … contacts are not encrypted and neither is the subject line if you force plain-text-mode with PGP-MIME.

actually i’m at odds here. my contacts in ProtonMail are shown to be encrypted with an RSA 2048 bit key (and that’s as high as it goes) as opposed to my other keys used for encrypting ONLY the message-body and the subject-line for PGP-Inline mode. i might be mistaken here since this is memory after-all but heck i would prefer it if they would have made everything to be one CAKE instead of so many different rules for this and that.

what do i mean by one CAKE ? have one RSA 4096 bit key that covers everything and not a bunch of crap that you need to be wary of. i mean there’s the mobile aspect to consider but still …

http(s) gives a lil bit more protection for the ‘naked’ bits but that’s about it …


Don’t use Microsoft Exchange ?


Both Microsoft and hackers are like birds of a feather flock together.

While this is undoubtedly the best option :slight_smile: another option is to outsource your Microsoft Exchange to Microsoft. Microsoft’s own servers (for use with outsourcing to customers) had already been patched, I believe. (As this is a paid-for service, it isn’t necessarily the case that your content is being monetised and clearly companies would be very reluctant to use an outsourced mail service where the business model included monetising the content of emails - exactly as ProtonMail claims for themselves.)

Apart from that, some general observations in the article, or otherwise:

  • security is hard
  • actively monitor for intrusion attempts
  • assume that a successful intrusion is ‘when’, not ‘if’
  • design accordingly so that you can limit what can be stolen when an intrusion inevitably occurs - encryption is part of that but not the only direction to go in
1 Like

what if your intruder is the same one you use to store all you encrypted data on ?
that would be the firmware of the storage unit … since that firmware is responsible for managing data blocks it’s also probably able to do some stuff to the encryption …

i believe PM has stated that they had to move out of or expand from the old ‘abandoned’ military base under the mountain. not that that matters at the micro-level …

If your disk firmware is compromised then fairly obviously you can be the victim of a denial-of-service attack i.e. all your data disappears.

I guess I should add a bullet point

  • design a backup regime accordingly

However it isn’t really possible to guarantee that your backup regime works if the disk firmware is compromised.

Part of designing a backup regime is testing the backup regime e.g. routinely access the backup on an isolated system (a computer other than the one where the backup was made) in order to perform some kind of sanity check on the utility of the backup.

Any self-respecting free software advocate would not use encryption at the disk level and would instead require the operating system to perform the encryption. So there is no loss of confidentiality if your disk firmware is compromised. (However in theory the disk will be able to gather some metadata e.g. what areas of the file system are most active / least active / when accessed / what data volumes).

i was talking about black-box storage-unit firmware in general not only about the device you are backing-up but the one you store the back-ups on and then the one that stores the back-up of the back-up and so on …
you get the point i hope :wink:

and when i say libre-firmware or free-software i mean 100% no blobs at any level unlike others who aren’t talking in such specific terms.

1 Like

“FBI hacks vulnerable US computers to fix malicious malware”:

Re: backdoor implaced by Chinese hackers into MS exchange.

FBI uses that backdoor to get in and remove that vulnerability.

What I mean is, can a Purism computer be hacked by Chinese hackers? And if so, will the FBI be allowed get into a Purism computer to fix it? Why the FBI? Does Microsoft not know how to do that themselves, by using an update that applies the same fix? Or does the FBI have IT, that Microsoft does not? Is the FBI the only one with such IT, and then that can mean that Purism also does not have such IT. Then what will Purism do with its “canary”?

As an individual that has had to try to work with Microsoft on DFIR related activities, I would like to note that breaches happen with O365 and good luck getting access to logs. Unless the client is willing to pay a significant amount of money per user, the retention is only 90 days:

Transfer of risk isn’t a bad strategy but one should be mindful of one’s compliance requirements before making a decision to move their email. And no, I am not a fan of Exchange and we do not use it at our place of work.


100%. The suggestion that if you are going to run Microsoft Exchange anyway then letting Microsoft run Microsoft Exchange on your behalf on their servers … assumes that that is even close to acceptable from the perspective of both external and internal compliance requirements. If you are security agency then very probably “NO”. If your company bakes bread then very probably “yes”.

Yes. The assumption is that their IT capability exceeds yours - so the likelihood of a security incident decreases if the baker outsources the email service to Microsoft - but if there is a security incident, it will all be outside your control.

The decision may not be a simple one but for “How to prevent the next MS Exchange hack”, outsourcing should be an option that is on the table.

As far as 90 day log retention goes, the company would need to look at its threat model. If your threat model is foreign security agencies then 90 days is woefully inadequate. Foreign security agencies play a long game. If your threat model is ransomware criminals then 90 days may be enough.