New Microsoft Exchange zero-days allow RCE, data theft attacks
bleepingcomputer.com
bleepingcomputer.com
I thought this was for on premise exchange installs that are directly facing the internet, which is an extremely rare setup these days.
Most companies use hosted exchange or if exchange is on premise, it sits behind a firewall of some kind.
Exchange is actually still fairly prevalent, even among smaller companies. Although many of the smaller orgs that still have on-prem Exchange tend to have a migration plan to M365.
and I hope they do. most of these smaller companies are sometimes sitting on really really old versions. "it works" is mostly the argument. updating exchange sometimes can be painful. most of the time everything works, but sometimes things just break.
There are vanishingly few circumstances where it makes sense for an organization to be funding deep expertise for the direct management of an Exchange environment. This has been clear for nearly a decade.
The capex to refresh that hardware is a ridiculous waste, so yeah, it wouldn’t surprise me if the people still running those setups have very aged installations (e.g. WinSrvr 2008-12), which are as great a risk as the Exchange Server software they’re running.
The gating factor is often the expertise to plan and execute a migration with minimal disruption and loss. It’s not simple, and it’s nothing like an exchange upgrade project. It’s a downright UGLY project if a company has been abusing their mail system for years (e.g. using their mail system as a document management platform since ‘99, allowing distributed PSTs, etc.). Seen it.
Give Microsoft money and receive Teams for free?
Yes. As opposed to giving Microsoft the same money and then also giving Slack some money too.
The only signal I would conclude from CVE data by itself, is that I bias towards a preference for companies that regularly publish CVEs. The ones that don't publish CVEs regularly are hiding, ignorant, or actually secure (and the first two are more likely).
You can't look at CVE in isolation.
Possibly if a product consistently has high cves over a long period of time that might tell you something about poor security practices over that period (or before it). It might also mean that their security is now quite good!
You have to interpret the data I'm afraid. I can't think of any useful statistical measures you could use to compare aggregate data across multiple products.
It is logical - 9x% of large cyber-attacks are done digitally, not with physical proximity to the target.
Yet, we often focus on the vulnerability (zero-day, misconfiguration, business logic gap, etc.), rather than the exploit method (the network). Almost implicitly taking it for granted that the server (e.g. Exchange) needs to be exposed to the network in order to do its job.
Given the impact, shouldn't we double down on methods which enable servers to do their job without 'listening' to the network?
> It is logical - 9x% of large cyber-attacks are done digitally, not with physical proximity to the target.
A remote vulnerability means without access to run local code on the machine. It does not have anything to do with having physical access to the machine.
Seems a good design and very few problems given its age.
Postfix seems next best by design.
How many parts of least privilege is message acceptance to mailbox in exchange? I suspect one program image.
UUCP exists, but generally, people prefer their business communications to be a bit more immediate.
To keep the metaphor going, "Listening" for a server just means that a client gets to say the first word to start the conversation - it is not otherwise special. The problem is the malicious conversation that follows, not who started it.
You can do things to control who talks to what, but an employee laptop can be compromised abused to perform the attack from a "trusted" client so that is no good.
Think of it like trying to protect your loved ones from misinformation and crypto scams - you don't want to shut them out of the world, telling them to only trust specific sources backfires if those people sell out or end up hosting scam ads, and teaching them to never be misled by anything might be impossible.
and, agree, the clients can be compromised - loved ones can be scammed as you said - but your loved ones are a far smaller attack surface than being exposed to any attack on the internet (which too often can find its way into the dmz until day two security and L7 authorization tries to identify and terminate the rogue L3 connections).
For example, if you have a vulnerable service and allow employees access to it through the perimeter, you fail - the employee might have gone rogue or have a compromised machine.
absolutely perimeter security based on weak auth (being 'on' the WAN) is insufficient.
but improving internal security doesn't address all internet-based attacks - which are the vast majority. in those cases, auth before connect is a good practice - but the auth (authentication and authorization) itself needs to be strong, and part of a multi-layered approach (the WAF etc are actually able to be simplified and do their job better when they don't need to filter the entire internet).
In other words, any kind of proper defense require the internal services to be fully battle-hardened to withstand arbitrary attacks anyway as the perimeter is breached, or you set yourself up for a catastrophic security breach. In this case, the perimeter added nothing but cost, inconvenience and a false sense of security.
If you are afraid of exposing such services without a perimeter, you should not be running those services at all.
and don't you make that 'battle hardening' simpler and more effective by reducing the attack surface? e.g. by taking your servers off the internet (meaning your inbound firewall rules become deny all inbound (even 443)). so enforce (strong) auth outside your dmz, before allowing sessions on your network (or overlay network), even for APIs, B2B etc (otherwise your fw has exceptions).
and, yes, when that gets compromised, the attacker now needs to deal with the next set of 'battle hardened' layers.
meaning, shouldn't reducing attack surface and battle hardened services be an 'and', not an 'or'?
Attack surface is defined by the service, not by which malicious actors you expose it to.
Of course you can reduce attack surfaces by having things be tunneled and/or proxied, to have close-to-minimal network access to some appliance, but that won't fully save you from this sort of problem. In my opinion, the only obvious way out is to go category-by-category and eliminate each type of flaw by-design. I think even in an ideal world you could never accomplish this 100% of the way, or at least we're not close to a world where you could right now, but you can combine this with a layered approach to security, trying to eliminate single points of failure, adding hardening anywhere you can, and making tampering both as apparent and as unreproducible as possible (i.e.: ASLR harder and more often, randomize the order of things, don't expose internal IDs, etc.)
In my opinion there's a huge conflict of interest between Microsoft and Azure as a cloud hosting service offering o365 integrations.
Well that is an egregious display of bullhockey and an almost criminal level of negligence. RCE is basically a game over level exploit.
Shouldn't have to be stated but at any given time, any company regardless of security measures should assume there is at least one compromised host and stolen credential.
That part plays like how Red Beard described needing a crew for your ship dividing opinion: everyone else says you do, I say you don't!
there are tools so that you do not need it, but well its not supported. in recent updates there is a new supported scenario, you can remove the exchange but you need to keep the schema and powershell modules and than you do everything with powershell
Would Microsoft have any interest in pushing users to monthly cloud based subscription services….?
Microsoft has no problem sunsetting services and giving users a deadline to switch to its replacement.
1. It was a megabitch to install and configure correctly and securely to work with Outlook, web, mobile, PDA, and other Microsoft products, and apply patch Tuesday updates depending on HA to work correctly to prevent downtime and data loss. (Blackberry BES was the sort-of answer to some crunchy mobile problems for a while because the idea of mobile apps hadn't fully materialized, so an E2EE solution seemed like the best path at the time.)
2. It was a continual attack surface, making the ops support or managed ops support far more costly than licensing. This was during the era of massive malware worms attacking the disastrous poor security of Microsoft products.
Fool me once shame on you, ...* I don't have much empathy for doing the same thing and expecting a different result other than breaches and loss of data and service.
Edge on Windows Server 2022 will happily load a bunch of MSN ad garbage now by default, after Microsoft had IE run in a restricted mode on servers for the previous twenty years.
If you do that incentive wrong, they might go full denial
But yes they've been cajoled to improve their reactitivity. Their customers have very high tolerance of security flaws still, partly due to self-selection.
Now the whole industry could much better, and liabilities can't come soon enough for everyone.
Microsoft Comes Under Blistering Criticism for 'Grossly Irresponsible' Security
https://cacm.acm.org/news/275239-microsoft-comes-under-blist...
HN discussion: https://news.ycombinator.com/item?id=36979532
https://www.politico.eu/article/data-at-risk-amazon-security...
Which isn’t to say Azure doesn't have some failings. The recent signing key issue shows that even at the largest hyperscalers there are places where the basics are missing.
These aren't nearly as bad as many of the CVEs that other vendors patch every week.
It's hard to say what kind of files an authenticated user can read on fhr exchange server without the details on the vulnerabilities.
Qubes or containers with X11