3 Hypothetical Security Hacks and Discussion

Ryan Palo - Sep 23 '19 - - Dev Community

For my Security Essentials class that I'm in, one small assignment was to come up with three hypothetical hacks and discuss how they might happen and how they could have been prevented or mitigated. When I got done, I was pretty happy with how they turned out, so I thought I'd share them here. They're not comprehensive, because it's a teeny tiny assignment, but I think there are some good talking points touched on.

Hope you like it!


Scenario 1: Darn it, Jerry!

The attacker is Jerry, a disgruntled employee who was fired for personal hygiene issues and laziness. He used to be associated with the company SecureURStuff, Inc. Before he was fired. Now he’s on his own.

He was fired and he believes it to be a wrongful termination. He insists he was just “going through some things” for the several months that he
didn’t complete any of his tasks on time.

A week after he was fired, he realized that his login credentials still worked for the VPN and main business server. He logged in remotely and deleted a bunch of very important documents. He also updated the website to read, “Jerry Rulez.”

The attack could be prevented by implementing a user account policy on termination that backed up his data and revoked all of his access. Also, he probably didn’t need access to both important business documents and live website files. They could mitigate his effects by following the principle of least permissions, only giving him as much permission as he needed to do his job. Finally, they really should be keeping backups of their server, all important documents, and their website so that they could quickly roll back and retrieve the deleted/defaced files.

Scenario 2: Highway to the...

The attacker is only known by their hacker alias “D@ngerZ0NE.” D@ngerZ0NE works with several privacy-focused hacker groups including Anonymous. They believe that big tech companies, including Amazon, are too prevalent and getting too much of our data in one place.

As an attempt to severely cripple Amazon, by way of its shipping infrastructure, they hacked into the FAA’s traffic control database and scrambled everything. To avoid any damage or fatalities, the FAA grounded all planes immediately costing airlines, businesses, and others huge amounts of money. But no one was injured.

Unfortunately, the director of the FAA used the name of his dog (Shmoopsie) as his master password, and, because his Facebook timeline is literally nothing but Shmoopsie all the time, D@ngerZ0NE was able to guess his password.

The main fix would be implementing secure password policies, especially for people who have access to very sensitive data. Especially, especially if that data is super sensitive and potentially life-threatening. Mandatory password minimum lengths, symbols, upper and lowercase letters, and numbers, and new, unused passwords every 90 days or better. Preferably with 2-factor or better authentication. Maybe even biometric components.

Scenario 3: Tech Nina

The attacker is a 12-year-old named Nina. She’s in 6th grade, but no hacker group other than that. She’s super interested in computers, and when she noticed a vulnerability in her school’s website, she followed some tutorials because she wanted to see if she could do it.

When she noticed that her school website had a maximum password length--a sure sign that they were storing passwords in plain text--she wondered how many other vulnerabilities there were. As it turns out, they had a SQL injection vulnerability on the sign-in page that allowed her to dump the entire user table. And they were using an out-of-date version of WordPress. When she told her principal, he didn’t believe her. So she pwned them, and then met with him again to talk about how much extra credit she could get for helping them fix it.

They needed to keep their software versions for WordPress and any other libraries updated, hash and salt their passwords to protect their users in case of more Ninas, and make sure they’re sanitizing their form inputs before using them to query the database in order to avoid SQL injections. Even more important, they need to take all security reports and disclosures seriously and fully investigate anything reported to them. And they need to take another look at their personal biases. Great work Nina!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .