8 ms·
Microsoft Office 365 Message Encryption Insecure Mode of Operation
- PaulHoule 4y agoWould you expect anything less?
- blibble 4y agothe famous picture of tux being encrypted using ECB was featured in my computer science lectures >20 years ago https://commons.wikimedia.org/wiki/File:Tux_ecb.jpg https://commons.wikimedia.org/wiki/File:Tux_ecb.jpg I guess next we'll find out MS are still using DES or RC4
- cendyne 4y agoI love the adaptation for the season. ECB in halloween candy! The horror! https://twitter.com/FiloSottile/status/1578783337442938882 https://twitter.com/FiloSottile/status/1578783337442938882
- mirages 4y agoWhy does a diagonal pattern appears when doing that kind of encryption ?
- rhn_mk1 4y agoI'm guessing that the block size is a power of 2, but it's not divisible by 3, meanwhile the pixel size (and so the line width) is divisible by 3. Misalignments in a line will cause diagonal patterns.
- woodruffw 4y agoCorrect: at least for the recreated version[1], the blocksize is 128 but the pixels are uncompressed 24-bit RGB values. So you end up with 5.33 (repeating) pixels per block, which makes running spans of of the same color transform into runs of a different color with a little bit of "noise" (always the same) at the end. Do that enough and wrap it around at the width, and you end up with a diagonal/houndstooth-like pattern. [1]: https://words.filippo.io/the-ecb-penguin/ https://words.filippo.io/the-ecb-penguin/
- woodruffw 4y agoThey're almost certainly using 3DES in some products, since it's still a standard choice for PCI encryption.
- deleted 4y ago[deleted]
- tkhattra 4y agoironically, it was Microsoft cryptographer Marsh Ray who said "Everybody knows ECB mode is bad because we can see the penguin." [1] [1] Serious Cryptography, Jean-Philippe Aumasson
- c0l0 4y agoDoesn't really matter - the pre-sales checkbox mumbling something about "encrpytion" was ticked, so Compliance, Legal, and SecOps are OK with it. Nothing to see here, move along :-)
- pwarner 4y agoI think most of O365 is check boxes, except for the desktop apps (Excel, Outlook, PowerPoint). OK Exchange Online seems OK too.
- judge2020 4y agoSame goes for IPv6 in Azure: https://news.ycombinator.com/item?id=29327773 https://news.ycombinator.com/item?id=29327773
- nijave 4y agoThat article doesn't even mention they release new services without IPv6 support. Azure Flexible Postgres can't be ran in a virtual network with IPv6 enabled (let alone support IPv6 operating mode/addressing)
- jiggawatts 4y agoI realise I’m replying to a link to my own comment… In the context being discussed here it should be more clear that big vendors implement features like encryption or IPv6 purely to tick a compliance checkbox. These types of features are not supposed to be used. They’re there just to exist and enable sales to government institutions where someone who who’ll never use the product directly is ticking things off on a checklist. Another classic example is Android encryption. The marketing materials literally look like this: Encryption: Yes I didn’t realise how much of a farce this was until I saw a presentation at an Apple developer conference where they outlined the four different “rings” of encryption they do. For example, when an iPhone boots up from cold most of it remains encrypted and requires the pin to decrypt. Even if you take it apart physically before the pin entry, you can’t get at the user data! Android unlocks everything on boot, because its encryption support is “yes”. (This may have changed since then)
- deleted 4y ago
- adrian_b 4y agoIt is hard to imagine that anyone knowing anything about cryptography can make such a mistake as using the ECB mode of operation for the encryption of a text message. The ECB mode of operation is strictly intended for the encryption of random or pseudo-random numbers that have a negligible chance of repetition, for example for the encryption of secret keys. Any other application for ECB is a serious error that cannot be justified in any way. If this was some kind of attempt of implementing a weak encryption method for export purposes, then it is much more stupid than limiting the length of the secret keys to 40 bit, like it was done in the Internet browsers many decades ago.
- dunham 4y agoMaybe it was B team? There was an issue that slipped into the iOS backup a while back, where some engineer had added a bare sha1 hash of your password (it's been a while, but I think they were trying to add encryption of the metadata in addition to the existing file encryption). The existing encryption was GCM, AES keywrap, and pbkdf2, so those things were done by teams of widely varying skills. I probably could have gotten another CVE from that, but I wasn't sure I was supposed to be poking around in that stuff in beta. Somebody else did report it and it was fixed.
- blincoln 4y agoI 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.
- 4y ago
- ThaDood 4y agoWowza. I would ask a sort of rhetorical question about how could Microsoft let this happen. Then quickly realize that is Microsoft and I'm not all that surprised. The icing on the cake? "The report was not considered meeting the bar for security servicing, nor is it considered a breach. No code change was made and so no CVE was issued for this report." So basically, they know about it and don't seem to give a shit.
- deleted 4y ago[deleted]
- gw99 4y agoYour last line is the current operating position for Microsoft. They hide this under marketing blogs.
- hbn 4y agoDidn't you hear? They <3 open source!!!
- ealexhudson 4y agoOME is also accepted/compatible with Gmail, Yahoo!, etc. Would be interesting to know whether they suffer the same issue, or those implementations chose a proper encryption mode..
- meken 4y agoUnsecure *
- connordoner 4y agoEither works.
- victor106 4y agoI just don’t get how careless Microsoft is when it comes to security and reliability. Yet enterprises annd governments are throwing $$$ at them. Maybe that’s why they don’t care.
- tptacek 4y agoMicrosoft is one of the least careless companies about security in the entire industry, and particularly so when it comes to cryptography. It's just a very big company, and they don't (or didn't, last I checked) have a cryptography review board the way Google does, to make sure people like Niels Ferguson get their eyes on all their crypto-bearing features.
- siggen 4y agoThey do.
- victor106 4y ago> don't (or didn't, last I checked) have a cryptography review board the way Google does, Exactly my point. Every company follows standard security policies. But for a company like Microsoft, given the responsibility it has and the profits it makes and the amount of money it’s executives make is it unreasonable to expect more?
- throwoutway 4y agoThis is seriously concerning and requires a response from Microsoft. People use O365 for healthcare/HIPAA data and Microsoft signs a BAA for this use
- tptacek 4y agoI seriously doubt this will cause HIPAA problems.
- throwoutway 4y ago> Since Micosoft has no plans to fix this vulnerability the only migiration is to avoid using Microsoft Office 365 Message Encryption. Should clinicians just ignore this or should they demand a response?
- tptacek 4y agoClinicians will certainly just ignore this.
- throwoutway 4y agoOf course they will, but I said “should” not “would” for a reason
- infamouscow 4y agoHaving worked in healthcare tech for over a decade, it's extremely common for healthcare facilities to send medical records over fax. HIPAA and BAAs are for lawyers to argue about after your medical records has been exposed, and if attempts to remedy the situation deteriorate.
- ealexhudson 4y agoYou're allowed to assume the phone network is not being eavesdropped, you're not allowed to assume that for Internet transmission. Whether that's true or not, that's the accepted position. If this encryption genuinely allows structural data retrieval - eg common invoice templates or medical reports - then this is absolutely a HIPAA problem, and once a facility is made aware of it they would need to respond. FWIW, this message encryption is also accepted by UK NHS, in fact it's virtually the standard. The mitigating factor is that typically the user is fully authenticated before being allowed to access the encrypted data...
- JJ2022901 4y agoDoes this issue apply to their AME feature? https://learn.microsoft.com/en-us/microsoft-365/compliance/ome-advanced-message-encryption?view=o365-worldwide https://learn.microsoft.com/en-us/microsoft-365/compliance/o...
- kemotep 4y agoI am seeing they claim the issue is with Microsoft Office 365 Message Encryption. Does this factor in if people have Azure Information Protection services/licensing? This is quite the vulnerability if Azure Information Protection is unable to fully secure email communication.
- grammers 4y agoProblem is: If it says encryption, people think it's safe. Only if you're into tech, you know to look for the details. Personally, I'm always looking for 'end-to-end' and 'open source', like Tutanota does it, for instance, of Proton.
- ccouzens 4y agoMy understanding of this issue is that it could also affect badly done end to end encryption. Open source is also a good start but it is certainly no guarantee as not all code is audited even when open.
- dhx 4y ago[MS-OXORMMS] reuses cryptography from [MS-RMPR] as the offending 15 year old specification that allows ECB to be used (as well as padded and unpadded CBC) for encrypting the content blob within the message.rpmsg attachment to "protected e-mails". As the original article states, Microsoft have kept using ECB for backwards compatibility with their 13 year old product Office 2010 that reached end of life 2 years ago (Oct 2020)[1]. Despite all the talk about "Purview Advanced Message Encryption" replacing whatever came before it, a recent demonstration[2] shows attachments labelled "message_v4.rpmsg"[3] and "message_v3.rpmsg"[4] being sent to an external Gmail recipient so it appears [MS-OXORMMS]/[MS-RMPR] are still being relied upon but perhaps the server part of [MS-RMPR] is now only implemented by Azure and has no on-premises implementation? In one of the examples[4], the "Purview Advanced Message Encryption" feature allows "message_v3.rpmsg" to be sent as an attachment to an external recipient that then doesn't have permission to view the e-mail. Why send an encrypted message to someone that is meant to have no means to decrypt it? [MS-OXORMMS] https://interoperability.blob.core.windows.net/files/MS-OXORMMS/%5BMS-OXORMMS%5D.pdf#page=23 https://interoperability.blob.core.windows.net/files/MS-OXOR... [MS-RMPR] https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-RMPR/[MS-RMPR].pdf#page=35 https://winprotocoldoc.blob.core.windows.net/productionwindo... [1] https://support.microsoft.com/en-us/office/end-of-support-for-office-2010-3a3e45de-51ac-4944-b2ba-c2e415432789 https://support.microsoft.com/en-us/office/end-of-support-fo... [2] https://youtu.be/9NydrGVG_mI?t=164 https://youtu.be/9NydrGVG_mI?t=164 [3] https://youtu.be/9NydrGVG_mI?t=273 https://youtu.be/9NydrGVG_mI?t=273 [4] https://youtu.be/9NydrGVG_mI?t=452 https://youtu.be/9NydrGVG_mI?t=452
- karambyt 4y agoWait til you find out there are people with VK accounts supporting the war in Ukraine working for Microsoft's top-level management for security and compliance.
- deleted 4y ago[deleted]
- upofadown 4y agoThe ECB mode in question is depreciated and has been such for a long time. So normally you would expect the issue would arise only if you had an old version of the software. So is the article claiming that new versions of the software are using the depreciated mode in error? It isn't clear to me how to get access to any more definite discussion (MSRC VULN-060517?). We need a definite list of exactly what software is generating ECB messages.
- mike_hock 4y ago> depreciated deprecated
- LinAGKar 4y agoI'm sure it's both
- denton-scratch 4y agoDeprecated == disapproved-of. Depreciated == reduced in value.
- chairmanwow1 4y agoIf you are wondering why this is a big deal, then I encourage you to complete Set 2 of Cryptopals [0], because it guides you through quite a few (easy) attacks you can create against AES-128 in ECB mode. [0] https://cryptopals.com/sets/2 https://cryptopals.com/sets/2
- tptacek 4y agoNot that I want to talk down the importance of not using the block cipher default mode, using it in this setting is a bug Microsoft should urgently fix, but those attacks are mostly relevant in interactive settings, not against data at rest. Here, the probably mostly in fact is that you can see penguins through the encryption.
- excalibur 4y agoI don't know why more people haven't picked up on this, but this only applies to OME, which is the old Microsoft 365 encryption. Their new version with Microsoft Purview doesn't support legacy Office or ECB.
- ThePowerOfFuet 4y ago>Micosoft has no plans to fix this vulnerability the only migiration is to avoid using Microsoft Office 365 Message Encryption. Microsoft. Mitigation. Even basic spell check would have caught these, which make the whole work look sloppy.