I think you hit the nail on it's head. Think about it: some countries where these mandates are/were introduced would describe themselves as liberal democracies. We have all these laws that limit the power of government. Forcibly injecting people with the vaccine is obviously not compatible with anything calling itself "liberal".
The ideological weakness is self evident. We can't go door to door with police to give everyone the jab, so we wishy-washy try to force people with other measures. Who can respect an authority that lies and betrays one of its core principles? How can one respect a government that truly tried to outlaw natural human behavior? Talk about heavy handed.
And, after some countries are now on their 4th boosters (Edit: shot, not booster), and my country being about halfway done with their third round, are we slowly stamping out the virus?
Personally I feel lied to and misled, the messaging from the government where I am from was far from what one would call nuanced and informed. The short story is that they promised: "If you take your shots, then we'll get out of this mess". Even now, a propaganda ad that states: "We don't want you to take a booster to make things impossible, we want you to take your booster to make things possible again". Even though it's abundantly clear that people are getting reinfected and spreading Omicron, booster or no booster.
From my perspective we're kidding ourselves that we can get a handle on this disease without permanently going in and out of lockdowns. In my county we stamped out the virus at least twice before (stamped out going to < 20 cases per day, some cities without for months). And then it comes back. Well I'm done locking down, and I think this is a consistent, fair standpoint to take. I don't want to have to identify myself and my status to enter the store or public life. People get sick, people die, everyone will get omicron, or something similar, eventually.
https://zerodium.com/, the going rate for a full exploit there (and I assume, one that works quickly & leaves little trace, i.e. a high quality exploit, never dealt with them before) is 80k.
Under the old rules that's already 4x as much as MS, but the warm fuzzies made up for that I suppose. Under the new rules, 40x as much, and no warm fuzzies are worth that imo.
"Microsoft Bug Bounty Program's (MSRC) response was poor: Initially, they misjudged and dismissed the issue entirely."
I recently ran into a similar issue with MSRC. I reported two exactly similar(near perfect) heap overflows exploitable from a local perspective with some time in between. The first report was awarded the maximum payout, and patched as 'Important'.
Meanwhile, MSRC changed its rules related local exploitation. Now, to obtain that, one needs to show the exploit working in the most hardened sandbox processes on the system. From my perspective this is quite unfair, both bugs are reported with the same severity to Microsoft's own customers. Both breach about 3 defined security boundaries (process, session and user). So, my communication stayed the same (all technical details), Microsoft's communication with _their_ customers stayed the same (important severity issue, 7.8 cvss), the only thing changed was my reward...(reason: ohh, it's not a sandboxed process, to we don't care.).
The only way to obtain the maximum payout is this even more stringent, and new, requirement of 'sandboxed process' -> 'other user' boundary. As if there are not a hundred thousand organizations sharing machines between users using Citrix and terminal and other similar technologies...
In any case, given that it takes close to a year, with hundreds of hours invested to uncover such a bug... I'm going to take my submissions elsewhere...
This the result of the two party systems. Bi-paetisan compromise is rare, and even then is often backdoored with legislation not actually discussed.
This leads to the two parties only ever being in an adversarial relationship.
In other systems, sometime you get to make a majority government with other parties. This differi means that in mutti-party systems the "party line" is "these guys are ok, and reasonable" every once in a while.
Not so in the two party system, where the winner-takes-all perpetual adversarial relationship generates a constant steam of "the others suck, are dumb, evil and want to destroy the country"
> shaming and/or implying that people like myself are anti-vax.
I'm in a low risk bracket. My country saw an uptick in people canceling vaccination appointments. 40% of 60+ people here are now 'unsure' of taking the vaccine.
I've done nothing but work and follow the rules since this whole thing began. Young people without partners, or young people in general, that are active, have a social life did a complete 180* in their "allowed lifestyles".
I've paid with money, time, a year of my otherwise busy life, for people in risky age brackets, at _little_ benefit to myself. *
But I'm so done, don't tell me you're asking people like me to be stuck in our anti-social and unhealthy living arrangements, while there's a solution that's _safer_ than going to a covid shower?
People like me are done paying, I'm not going to wait around another year, you take the vaccine or you take covid for all I care.
Well, not literally. But it is meant to be the system that is used to gain root access to your domain controller to perform administrative tasks there. Install updates, fix issues, that type of thing.
So, although it does not literally house all passwords/keys/whatever to your network, it has access to a system that indirectly does.
Normal jump hosts should not have your private keys I guess, but I thought it was the closest analogy.
Just put it this way: if an attacker gets on that system, it's complete game over.
They don't directly translate due to the inherent differences in between the two systems.
In short, pass-the-hash is a technique by which it is possible to authenticate to a windows system using the hash of a password, instead of the password itself. The NTLM hash is the secret, and does not need decrypting to authenticate.
NTLM authentication over the network can be redirected to other machines if they don't have traffic signing enabled (default only for domain controllers). So this gives rise to 'spreading' over the network in two ways:
* Steal the hash out memory of a system where you've got root access (called SYSTEM in windows terminology).
* Trick an administrator's system by connecting to your system somehow, and redirect the authentication to another system to take control. There are various techniques to do this, which I won't explain in this answer.
Given this known weakness, TAM/PAM/PAWs are all procedures/and a tiering architecture to prevent those secrets from being compromised.
A PAW, privileged access workstation, can be seen as an equivalent to a linux sysadmin's bastion host, roughly. It contains all private keys to all systems, but is well segmented, audited, and protected. This is the system that you use to perform administrative tasks that can't be done with any lower level of privilege. Say, the system that has the root account to all your production servers, for example.
PAM is the set the set of policies around logging when highly privileged accounts are used, which systems they can access with what privilege, etc, who can use them, how to approve actions by them, etc.
In short, they are the frameworks and policies used to combat the security weakness of these legacy protocol designs, and the reality of running big networks with guaranteed attacker activity in it.
I regularly perform tests like these. Overall there's a flat 10% 'critical failure' rate across organizations. You send a phishing e-mail pretending to be from the IT department, with some instructions to install the 'anti-virus scanner' or whatever, and 1 out of 10 people will open the e-mail, click the link, give their credentials, follow all instructions, click through all warnings and infect their machines.
If your organization is above a certain size, remote code execution in your network is a given. There's several technical measures you can take to make is _much_ harder to perform these attacks on Windows in general:
* Disable unsigned Office macro execution (if on windows with office)
* Disable mshta.exe or remove the .hta file association
If you can get away with it, productivity wise, enable whitelisting for all software.
Attackers can often times still find weak points in your organization. It's not always the marketing or HR department with Windows that gets phished. I once observed a colleague phish a webdev on a macbook with a recruitment 'challenge'.
I like to comment DevOps from a security perspective, a trend I noticed in my day job.
Windows is/was often bashed for being insecure. Lots of that stems from the decades of development related to centralized management solutions. A default windows workstation in a domain setting will open a bunch of ports, a bunch of which can be used for command execution. The attack surface for this system includes, but is not limited to:
- Remote access with local admin users via tools such as SMBExec, wmiExec, DCOM, Psexec, Powershell remoting
- Remote access domain admin users access via the same
- Local/domain admin access via RDP
- Remote domain admin access via group policy
All these have had their own associated vulnerabilities over the years. Examples are SMB relay attacks, which enabled an attacker to abuse flaws in NetNTLM and obtain access to machines by relaying other people's credentials. And then we're not even talking about the 'real' exploits, Eternal Blue, Eternal Romance, Blue Keep, MS14-068, MS08-067, and on and on.
Pentesters, researchers and Microsoft have been hammering away the kinks for years now. The 'fixes' and root causes for each individual issue are well understood and each new domain functional level increases the security of a default windows Domain by leaps and bounds.
When you look at the Unix/Linux side you'd see that no such attack surface ever existed. You manage your systems over SSH, and this can still be bad, an easily guessable root password shared between Dev, testing and production is still a death sentence. But by default there were no tier0 systems in your network, apart from those of sysadmins.
But now with DevOps things are changing on that side. With Ansible, Puppet, Terraform, your various container management systems, the CI pipeline, jenkins and numerous development teams able to push both to infra repositories and your actual products this has changed:
You use an automated CI pipeline? Any system in the chain is a tier0 system.
Your developers are maintainer status or higher in your source repositories? Then they are domain admin or equivalent. They can disable protected branches, push a backdoor, and watch their attack propagate through the pipeline.
Did you make it inconvenient for your developers to access various build systems? Then they are sharing credentials to these systems over your company chat.
It seems, from what I've seen so far, that while the 'architecture' of modern mass centralized IT management and development is more secure. You can't relay an SSH key for example, like you can in NetNTLM. But the institutional knowledge isn't there yet. New attack surface has opened up, and infosec people have not yet completely caught up with the new 'eggs' in the basket, even if they are aware.
You may have some (mild) form of dyslexia. You triggered me with your remedial classes to improve it, but no improvement.