Mary Ferguson, VP of Engineering at Stack Overflow, announced on May 16 that hackers gained access to the website’s production server as early as May 11.
Now, after further investigation, Ferguson has announced today that the attack originated on May 5. Stack Overflow’s VP of Engineering described the exploit as an escalation of privilege that originated from a bug that was pushed from a build to their Stack Overflow’s development tier. The attacker then was able to access the production server after exploiting the bug.
It was on May 11 that the attacker decided to access production by making changes to the system that gave him such access. Stack Overflow’s investigators assume that the gap was used to explore potential paths of attack. Despite this long gap, the attacker was immediately identified once they escalated privileges.
Why? Because Stack Overflow employed one of the best methods of mitigating the impact of horizontal and vertical privilege escalation: the principle of least privilege. You’re always going to have vulnerability that can be exploited. The point is to create a system that acts like Kevlar against such attacks.
This system is really what good coding/dev practice is all about. Programmers are taught, when creating objects, to make them loosely coupled. In this way, you create code that scales. The same applies to large systems, except that loose coupling in this case creates a secure system by only allowing, say a client, access to essential functions and nothing more.
Once privileges have been segregated, you can then employ a permission checking system that denies permission to certain users by default, like the system used for OS’s. Though, permission checking becomes useless if the user has gained access to a a high level permission by exploiting a vulnerability. Like in the case of the Windows vulnerability where there was a problem in the access check system for certain kernel drives that may have allowed malicious actors to escalate privileges. You can also have human error in the storage of permissions and in the configuration itself. With all that said, checking permissions, if done correctly, can put a stop to potential attacks. The attacker would then have to hope to hit the proverbial jackpot if they want a certain permission level.
In the end, one of the best ways to replicate Stack Overflow’s successful detection is to create a nearly bulletproof network detection system. When referring to the suspicion action the attacker took, Ferguson said, “This change was quickly identified and we revoked their access network-wide, began investigating the intrusion, and began taking steps to remediate the intrusion. ”
Stack Overflow claims that their database was not compromised. The attacker was able to make requests for IP addresses, names, and emails from “some” Stack Exchange users. Ferguson doesn’t give any numbers, but if you take into account that Stack Exchange incorporates millions of registered users, some can mean hundreds of users, if not thousands.
Stack Overflow continues to take the steps required to sanitize the breach–re-configuring passwords, involving third party forensics, etc.