My computer continues to be attacked... and I continue to learn more about the problem/problems.
First, the latest attempt was trying to insert a virus which my system caught: “An incoming request to permit remote debugging connection was detected. A remote client can take complete control over your browser.”
The client endpoint: 127.0.0.1:53792
Then server endpoint: 127.0.0.1:53788
Coincident event tried to create a changed file: OnDemandConnectionRouteHelper.dll
Related problems include:
Second, Linux based systems have implemented recent updates that include Snap packages. The change is inherently insecure, as it outsources a decentralized control over packages with the control delegated to the originating sources giving them full control over the package content without independent verification. One bad actor in one software supplier can thus defeat the entire security structure in the entire linux distribution as that structure includes that corrupted source as a trusted distributor.
Third, Intel (and AMD) has a massive problem with the microcodes that, in theory, exist as firmware insertions on the chip which are intended to enable Intel in correcting discovered vulnerabilities that are inherent in the chip as “design flaws”... correcting for them by a firmware fix.
In practice, that means Intel (and AMD)products are “pre-hacked chips” with “flaws” that preexist. That requires only that a hacker know what the chip weaknesses are to exploit them, before a microcode fix is enabled. Or, otherwise, it requires only that a hacker gain control of the dynamic code that controls the microcode. Getting that control allows them them to open and control access to the design “flaws” in the chip. Whether there is a microcode “fix” available for the flaws that are discovered and made public or not, if a hacker can gain control over the files that control “the fix”... they can still control the chip.
See for instance:
How to actually disable Intel (and AMD) microcode updates...
http://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/
Changing microcodes screws with the users ability to control the overclocking of a processor... so the hackers found a workaround.
The linked article is focused on Windows systems, and names the relevant files that control the microcode... but similar files exist for all other operating systems.
To maintain control over your computer, you need to be able to maintain control over those files that control the microcode... so, you have to lock those files down to prevent them being changed...
But, the “flaws” in the chips obviously aren’t accidental flaws... they are designed backdoors... created to ensure those who do know what they are can circumvent your systems ability to exert real control over access. Hackers who can figure out what those backdoors are... can exploit them just as well as those who designed them...
And that, of course, is a reason to not design hacks into the chips in the first place...
Fourth, operating systems that automatically download “updates” are inherently insecure... because the “trusted providers” of the updates... truly CANNOT BE TRUSTED.
That includes, particularly, Microsoft... and at least Canonical (Ubuntu) among the linux OS providers, or at least its failed control over Snap installations of insecure software.
The best you can do... is exercise manual control over your essential systems... and “lock down” access to your basic files as much as possible, including, obviously, shutting down all remote access, open ports that provide backdoor comms, etc.
Re-arranged in time sequence...
My last post on the hacking problem was the end of November.
On December 8, 2020, cybersecurity company FireEye, Inc. announced that it had been attacked by a highly sophisticated cyber threat actor and was investigating the breach with the FBI. On December 13, 2020, FireEye announced that the “compromise is delivered through updates to a widely-used IT infrastructure management software – the Orion network monitoring product from SolarWinds.”
On December 14, 2020, SolarWinds Corp. (NYSE: SWI) announced that it had become “aware of a cyberattack that inserted a vulnerability within its Orion monitoring products which, if present and activated, could potentially allow an attacker to compromise the server on which the Orion products run.” On this news, SolarWinds’ shares plunged $3.93 per share, or around 17%.
Significantly, in the days leading up to this announcement and stock drop, SolarWinds insiders sold over $285 million worth of Company stock. Jacob S. Frenkel, a former senior counsel in the SEC’s Division of Enforcement, said “[o]f course the SEC is going to take a look at that . . . . Large trades in advance of a major announcement, then an announcement. That’s a formula for an insider trading investigation.”
https://finance.yahoo.com/news/shareholder-alert-solarwinds-corp-investigated-141900959.html
Thought it worth an update here, with another pat on the back for the crowd here who helped to crowd source awareness of the vulnerability, and generate exposure of the hack, that enabled (among others) the Solar Winds exploit.
One of the core vulnerabilities we identified in this thread is now being addressed, in some small part, at least: The assumption that anyone with status as an approved system software provider should be “trusted” is being revised... their former grant of access to all the files in your system, by default, is being altered to enable “trusted provider” access to their own files, only, and not others.
Here’s how they’re addressing that in Ubuntu version 21:
...”for new installations of Ubuntu 21.04, or for users created on a machine that has been upgraded to Ubuntu 21.04, home directories will be private by default.
“For a lot of systems that have only one primary user, this change may not appear to have a huge impact. However, whilst these machines may have only one human user, they likely have other user accounts already on them which are created by various system services. This change now means that in the future if an attacker were to exploit some previously unknown vulnerability in a given system service that is running as a separate user, they would then not be able to access the data of any other user (both human or system service) on the system. This provides a more secure out-of-the-box experience for users and system administrators.”
https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04
I assume others are making similar changes to restrict how much system level access is granted based on “trust by default” of every and all of the peripheral players. The knock on and network effects of making that change should dramatically alter the intrinsic risk profile and security of everyone and everything... for a while, at least.
Will be interesting to note changes in the environment that result... as the pace of development in new exploits slows in response... and a lot of undiscovered exploits are shutdown because of the change... as the change is implemented. Legacy systems won’t be effected... so the primary impact should become apparent in an enhanced stability apparent in newer OS installations and upgrades.
Legacy systems should be able to be upgraded too, with some fairly simple inputs... at least in the linux/unix related communities... but herding the cats to enable it without it breaking things in legacy-land might be harder.
Anyway... thanks again for helping to make the digital world a safer place.