It had only been a few days since Nat Shere, our Technical Services Director, submitted the critical vulnerability report and the developers were already asking him to retest it.
We were impressed.
The team had analyzed his findings, shuffled their priorities, and implemented a fix for the issue in very short order.
Nat pulled his notes and testing environment with an optimistic, happy mood and when he resubmitted his original exploit string, it was indeed blocked as expected.
Always wanting to be thorough, Nat modified the exploit request slightly and sent it again, already drafting his “good job” email to the team in his head while the request processed. But this request wasn't blocked. The exploit worked.
Confused, he tried a few more variations and found that they weren't blocked either. His optimism slowly fading, he messaged one of the developers on the team to ask about it and the developer showed him the code changes that they had made.
To resolve the vulnerability, they had added one line of code: a simple statement to check the incoming data for the exact string that Nat put in the initial report. The exact string.
As Nat later discussed with the team, this was a mistake of focusing on the single issue at hand instead of the larger security fundamentals.
Because when you don't focus on the fundamentals (in this case, the lack of input data filtering), then you find yourself constantly chasing fires. Every new issue causes a red alert where blacklists need to be updated, firewall rules need to be changed, code needs to be patched, etc. Priorities constantly swing from focus to focus as the news cycle refreshes and the latest issues appear.
A recent 0-day announcement is an excellent example of this concept.
Microsoft published a 0-day vulnerability in their Outlook program that allows a remote, unauthenticated attacker to steal password hashes without any user interaction whatsoever. Proof of concept exploit code is already proliferating and Dark Reading is predicting this could be the new Log4Shell. Microsoft has released a patch but the easiest solution is actually to just block outbound traffic on port 445.
For security teams that practice the fundamentals, they already blocked outbound traffic on all unnecessary ports (which should include port 445). So, this issue gets casually integrated into general patch management and no panic ensues.
Security teams that weren't focused on fundamentals though will find themselves suddenly scrambling.
That is why fundamentals are, after all, fundamental.
So, don't just focus on the one exploit string - focus on sanitizing user inputs to expected formats and values. Don't just block outbound traffic on port 445 because of this one issue - block outbound traffic on all unnecessary ports to avoid all issues.
That way, you are proactively preventing fires, instead of constantly chasing them.
Comments