Unquestioned Practices, Hidden Costs
Misconceptions and what not
Some days, I can prepare a hot beverage, curl up in front of my old HP computer, and start typing away at the idea that has been occupying my mind for the past couple of days.
Today, however, is not that day.
I lack the energy to delve deep into a single idea, examining it from various angles and extracting meaningful lessons. Frankly, I don't even want to. Instead, I will pepper this post with a series of short ideas that have been nagging at me this week. They warrant reflection, but I'll leave that task to the reader.
Let's dive in. My drink is getting cold.
Why do we still allow any user to log into any workstation?
Shared computers have become a thing of the past, particularly in the corporate world. In 90% of companies, users are assigned dedicated workstations to complete their tasks. So why do we still accept that Active Directory allows any user to log into any workstation?
One privilege escalation on a single machine translates to privilege escalation on all of them. A single compromised credential is all it takes to gain access almost everywhere...
Can we truly rely on locally enforced ACLs? History suggests otherwise. So why do we continue to allow this massive propagation factor to be the default?
Even worse are companies using Linux/Mac that blindly replicate this Active Directory SSO feature by setting up an LDAP server or an expensive MDM solution. The self-flagellation metaphor is painfully accurate.
Why do we have the same user directory for corporate and production assets?
In pentesting engagements, we began by phishing random employees, escalated privileges locally, then globally at the domain level, which we leveraged to access production servers and databases running accounting workloads.
We never paused to consider how absurd this was. Why are accounting servers, web apps, and other critical platform components tied to the same corporate directory as regular users? Pwning a web app shouldn't lead to reading the company's emails. Compromising a random workstation shouldn't provide a path to the accounting database. Using Active Directory to manage both workstations and servers was arguably Microsoft's greatest marketing coup, but it proved disastrous for many companies.
Admin-mode should not mean god-mode
I'm tired and frustrated with admin access being equated to having superpowers over the platform and all its components, with zero oversight. An SSO admin should not be able to impersonate any user. A Device Management admin should not have the power to execute arbitrary scripts on 10,000 workstations without review or approval. An Exchange/Gmail admin should not be able to read user emails without approval, and so on.
Admin privileges should be more granular than what we currently have. They should implement a delegation scheme (1, 2, or 3 approvals) for certain critical actions. A god-mode account may be necessary for initial setup, but it should be treated like a break-glass account, only accessible during emergencies with at least two approvals.
No single actor should be able to bring down a company.
Pentests are not to be treated like family vacations
You don't have to perform a pentest every year. Wait, hear me out.
Like any audit exercise, a pentest should be used to validate a set of hypotheses about your current setup. Maybe you want to find vulnerabilities in your new app, or perhaps you spent the last year hardening your internal network and want feedback on that work. Maybe you're acquiring a company and want assurances. These are all valid reasons. However, scheduling a pentest at the end of each year because some standard dictates it, or hastily ordering one in November because you have some budget left, is a waste of time and money. Pentests are an essential component of a comprehensive security strategy. They should be strategically placed on the chessboard to serve a specific purpose, as we've discussed above.
Randomly moving a piece at the last minute or because external forces demand it is not a sound strategy.
JavaScript and Mobile App Obfuscation
I am tired of sales pitches, regulators, and auditors insisting on obfuscating JavaScript and mobile apps. Sure, it might occasionally help block a bot scanner or deter a lazy script kiddie, but that's about it. Intercepting HTTP requests is a basic skill. So is instrumenting mobile apps. Deobfuscation tools are widely available, and byte code isn't that difficult to read.
You know what actually works? Stop storing credentials in the app. Front-end applications are in the hands of customers, which means they must be considered compromised. Anything coming from them is potentially harmful. Anything we put in there should be public. The backend must double-check and control every input. If we adhere to this principle, attackers can do whatever they want with the JavaScript, but they won't get far.
Obfuscation undermines this paradigm by placing importance on the front-end app, creating a false sense of security, and thus allowing developers to entertain the idea of storing secrets in the app if it helps them meet their deadline.
There are a couple more observations in this ecosystem that make my hair spike, but my drink is definitely cold at this point, so I guess it’s time to wrap up.
By the way, my next book “Bliztscaling security” will be released on the 8th of May, so grab a copy now!
