Sleeper Shells: Attackers Are Planting Dormant Backdoors in Ivanti EPMM
defusedcyber.com
defusedcyber.com
Isn't most off-the-shelf software effectively always supplied without any kind of warranty? What grounds would the lawsuit have?
Actual cybersecurity isn't something you can just buy off-the-shelf and requires skill and making every single person in the org to give a shit about it, which is already hard to achieve, and even more so when you've tried for years to pay them as little as you can get away with.
I can almost guarantee you that your ordinary feature developer working on a deadline is not thinking about that. They're thinking about how they can ship on time with the features that the salesguy has promised the client. Inverting that - and thinking about what "features" you're shipping that you haven't promised the client - costs a lot of money that isn't necessary for making the sale.
So when the reinsurance company mandates a checklist, they get a checklist, with all the boxes dutifully checked off. Any suitably diligent attacker will still be able to get in, but now there's a very strong incentive to not report data breaches and have your insurance premiums go up or government regulation come down. The ecosystem settles into an equilibrium of parasites (hackers, who have silently pwned a wide variety of computer systems and can use that to setup systems for their advantage) and blowhards (executives who claim their software has security guarantees that it doesn't really).
Not very long ago actual security existed basically nowhere (except air-gapping, most of the time ;)). And today it still mostly doesn't because we can't properly isolate software and system resources (and we're very far away from routinely proving actual security). Mobile is much better by default, but limited in other ways.
Heck, I could be infected with something nasty and never know about it: the surface to surveil is far too large and constantly changing. Gave up configuring SELinux years ago because it was too time-consuming.
I'll admit that much has changed since then and I want to give it a go again, maybe with a simpler solution to start with (e.g. never grant full filesystem access and network for anything).
We must gain sufficiently powerful (and comfortable...) tools for this. The script in question should never have had the kind of access it did.
Is it not possible to have secure software components that only work when assembled in secure ways? Why not?
Conversely, what security claims about a component can one rely upon, without verifying it oneself?
How would a non-professional verify claims of security professionals, who have a strong interest in people depending upon their work and not challenging its utility?
I do not think we're at that stage of maturity. I think it would be hubris to imitate the practices of that stage of maturity, enshrining those practices in the eyes of insurance underwriters.
Phishing for example requires no security vulnerabilities, and is one of the primary initial attack vectors into a company.
You need proper training and the right incentives for people to actually care and think before they act.
I would argue the opposite is true. Insurance doesn’t pay out if you don’t self-report in time. Big data breaches usually get discovered when the hacker tries to peddle off the data in a darknet marketplace so not reporting is gambling that this won’t happen.
I can assure you that insurers don’t work like that.
If underwriting was as sloppy as you think it is insurance as a business model wouldn’t work.
Note, that is not to say that cybersecurity insurance if fundamentally impossible, just that the current cost structure and risk mitigation structure is untenable and should not be pointed at as evidence of function.
I've taken this even further. You cannot do security with a checklist. Trying to do so will inevitably lead to bad outcomes.
Couple of years back I finally figured out how to dress this in a suitably snarky soundbite: doing security with a spreadsheet is like trying to estimate the health of a leper colony by their number of remaining limbs.
Or just loads of other stuff that really only applies to large Fortune 500 size companies. My small startups certainly don’t have a network engineer on staff who has created a network topology graph and various policies pertaining to it, etc etc. the list goes on, I could name 100s of absurd requirements these insurance companies want that don’t actually add any level of security to the organization, and absolutely do not apply to small scale shops.
I also like to put everything behind a VPN (again no SSO). But the bigger the company gets, sooner or later this will come to an end. Because it's not "best practice" to not be phishable. Apparently what is needed are layers and layers of BS "security" products that can be tricked by a kid that has heard of JS. https://browser.security
Adding the security feature(s) you need is just a +$100/m checkbox, and they generally have sane defaults or templates that will position you better than some 3rd party vendor with confusing documentation and infrequent updates that require downtime windows to apply.
"Hey it says we need to do mobile management and can't just let people manage their own phones. Looks like we'll buy Avanti mobile manager". Same conversation I've seen play out with generally secure routers being replaced with Fortigates that have major vulnerabilities every week because the checklist says you must be doing SSL interception.
It's fine to say "Look this is bad, don't do" and "A patch was issued for this, you are responsible" but when some set of circumstances arises that has not been thought about before that cause a problem, then there's nothing that could have been done to stop it.
Note that the entire QA industry is explicitly geared to try and look at software being produced in a way that nobody else has thought to, in order to find if that software still behaves "correctly", and <some colour of hat> hackers are an extension of that - people looking at software in a way that developers and QA did not think of.. etc
This is why I also think “zero trust” and internet-accessible SaaS has done so much damage to the industry. Before, if your version control server has a vuln, the attackers still need to get on your VPN to even be able to scan for that vuln. Now, your version control server is on the internet and/or is an SaaS and all it takes is an exploit or a set of phished credentials for anyone anywhere in the world to get in.
Absolutely agree, and that's why instant security in a can (just add water!) cannot work (as you have been saying)
“We are aware” and “very limited” are likely (in our opinion, this is probably not fact, etc, etc) to be doing a significant amount of lifting.
For avoidance of doubt, the following versions of Ivanti EPMM are patched:
None
----
Ah, this company is a security joke as most software security companies are.
You pay them a million per year, and fire them when a breach happens.
Way cheaper than improving security.
1. https://labs.watchtowr.com/someone-knows-bash-far-too-well-a...
https://hub.ivanti.com/s/article/Security-Advisory-Ivanti-En...
Ivanti doesn't explain how this happened or what mistake led to this exploit being created.
Ivanti is a US company. But if you have never heard of them, the dragon-resembling creature in the illustration (representing the dormant backdoor?) makes it look like the incident is somehow related to China.
Anyway, the image is just the end result of plugging the title into nano banana. You ought to address your complaints to Google :)
Semi-related: with the recent much-touted cybersecurity improvements of AI models (as well as the general recent increase in tensions and conflicts worldwide) I wonder just how much the pace of attacks will increase, and whether it’ll prove to be a benefit or a disadvantage over time. Government sponsored teams were already combing through every random weekend project and library that somehow ended in node or became moderately popular, but soon any dick and tom will be able to do it at scale for a few bucks. On the other hand, what’s being exploited tends to get patched in time - but this can take quite a while, especially when the target is some random side project on github last updated 4 years ago.
My gut feeling is that there will be a lot more exploitation everywhere, and not much upside for the end consumer (who didn’t care about state level actors anyway). Probably a good idea to firewall aggressively and minimize the surface area that can be attacked in the first place. The era of running any random vscode extension and trust-me-bro chrome extension is likely at an end. I’m also looking forward to being pwned by wifi enabled will-never-be-updated smart appliances that seem to multiply by the year.
That's the gap with point-in-time security and checkbox compliance. You run your scan, get a clean report, move on. Meanwhile something like this sits in memory waiting for a buyer. The checklist says "run vulnerability scans quarterly" not "detect dormant in-memory class loaders planted by initial access brokers." Continuous monitoring that baselines normal behavior and flags deviations, even subtle ones like a new JSP file in a path that shouldn't change, is the only way to catch this. But most orgs aren't doing it because their compliance framework doesn't require it.
If you ask me... both these companies should be treated similarly to misbehaving banks: banned from acquiring new customers, an external overseer installed, and only when the products do not pose a threat to the general public any more, they can acquire new customers again.
This product was MobileIron, which was actually a pretty decent MDM platform, except like most acquisitions like this I'm sure they purged anyone with a clue. Unlike something like Pulse VPN, MDM is a sticky product and difficult/time-consuming to transition from.