[♪ INTRO]
Nobody wants to get hacked.
Victims can have their identities stolen, their private photos leaked, or their computers
infected with malicious software, AKA malware.
Hackers can even block or quietly replace websites, software, and files.
Whatever Hollywood thinks, though, hacking doesn’t magically happen when you type really fast.
There has to be some security vulnerability,
some hole that lets the hackers do something they shouldn’t be able to do.
The most vulnerable component is usually the one sitting between the chair and the keyboard.
But often there are hidden flaws in the technology itself.
In 2017 alone, companies and researchers reported nearly
15,000 security vulnerabilities in tech products.
We’ve talked about a few of the more well-known security flaws before,
and most of the less famous ones are pretty minor.
But sometimes even devastating vulnerabilities don’t get much press.
So here are five more-obscure flaws from the
past few years that gave security pros cold sweats.
Your phone buzzes.
The lock screen says there’s a video message from an unknown number.
It’s probably just unsolicited pictures of genitals; you hit “delete” and forget about it.
Unbeknownst to you, that message, which you didn’t even open,
has turned your phone into a surveillance device.
Some hacker just gained the ability to monitor your camera and listen to every word you say.
This scenario was totally possible on nearly a billion Android devices in April 2015,
when a security researcher discovered the flaw that became known as Stagefright.
Stagefright was an especially alarming type of vulnerability:
remote code execution, or RCE.
RCE flaws let attackers run any program they please without even getting you to click on
that CHEAP_VIAGRA.EXE email attachment.
Stagefright was able to get your phone to run programs with a common technique
called buffer overflow, which entails stuffing more data into a program’s memory
than the program made room for.
In Stagefright’s case, the buffer overflow was caused by bugs in the Android component
that loads a type of video file called MPEG.
Each chunk of an MPEG file is preceded by a number specifying how many bytes are coming up.
Android would reserve a buffer, or memory block, as big as the chunk said it needed.
If not enough memory was available, you’d get an error...
unless, that is, the request was really large.
For a specific range around 4.3 billion, Android would instead reserve a tiny memory buffer.
The reason has to do with how computers represent numbers.
At the time, most Android devices stored each number in a format that used 32 ones and zeros,
giving a range from 0 to about 4.3 billion.
Here’s the catch: if you try to add 10 to the largest number a computer can handle,
it just wraps around to 0 and gives back 9.
It’s like when an old car odometer runs out of digits
and starts insisting you’ve driven 0 miles.
With Stagefright, hackers could trigger these wraparounds and trick
Android into giving them a small memory block.
All they had to do was craft a video file that claimed a huge upcoming chunk size,
followed by a big chunk of malware.
Your phone would reserve an undersized buffer, fill it up, and then just keep going,
copying the malware over whatever happened to be stored in the next block of memory.
No malicious Stagefright attacks have ever been confirmed,
but there were a few factors that made it so scary.
First, there was the attack method.
Android had a feature that would automatically preload video messages.
So your device could be compromised just via your phone number with no action on your part.
Second, Android’s media player has a lot of control over your phone.
On some versions, it can even install new apps or siphon off emails and contacts.
This means every form of security is shattered:
You lose confidentiality of the data from your camera, Bluetooth connections, and so on.
You lose integrity of data the phone can access, since it can be corrupted by malware.
And you lose availability of your phone if hackers lock you out.
Google did release patches.
But this highlights a third problem:
Android manufacturers don’t always distribute updates right away.
So tens of millions of devices might never get the fix.
Another buffer overflow flaw was behind one of last year’s biggest cybersecurity stories:
the WannaCry ransomware that caused billions of dollars in damage
by encrypting people’s hard drives and holding them ransom for Bitcoins.
The vulnerability itself was called EternalBlue, and like Stagefright,
it was a remote code execution flaw, but a much less straightforward one.
In fact, it took the US National Security Agency to
spot the three interacting bugs that enabled it.
By default, older versions of Windows would accept
connections from other computers to communicate about sharing files over the network.
Hackers could trick Windows into reserving a small memory buffer
next door to the settings for one of these open connections.
Then they’d send a big chunk of data for Windows to store in that buffer,
so big that it overwrote the settings.
By overwriting settings strategically,
the hackers could turn what used to be a file-sharing connection
into a conduit through which they could pipe malware anywhere into your computer’s memory.
Boom! Remote code execution.
EternalBlue was especially dangerous in combination with other exploits that allowed privilege escalation,
seizing full administrative control of the computer.
Once that happened, the attackers could corrupt your files or make
them unavailable, say, by encrypting them all.
And of course, their programs could also spy on everything the computer knows, so…
so much for confidentiality, too.
And all without any involvement on your part.
EternalBlue was sneaky, powerful, and widely used for wreaking havoc…
in other words, the very model of a modern major security bug.
What would you do if you discovered you could issue commands to
half the web servers on the internet?
That’s the position one software developer found himself in on a September morning in 2014.
He’d discovered a flaw in a program called Bash.
Bash is a shell, a text-based way to run commands on Linux, Mac, and similar operating systems.
It’s installed on most servers.
But the shell also had an obscure feature: when another program ran Bash, it could effectively
leave a little note with a miniature program in it, something like,
“Hey, if you’re supposed to run a routine called DRAW_A_COW, here’s what it looks like.”
The problem was that this note was itself code,
a small program saying, “Define the DRAW_A_COW routine as follows.”
But Bash didn’t know where to stop.
If the note said “Define DRAW_A_COW as ‘print “moo”’.
Also, delete every file in your directory,” Bash would say “yes, sir!” to both commands.
So that gave the developer who discovered it the
power to execute commands on roughly half the Internet.
Fortunately, he was one of the good guys.
He immediately reported the bug, later dubbed Shellshock, to software vendors,
giving them a chance to fix it before the news was leaked to the hackers.
Shellshock was terrifying in a different way than Stagefright and Eternalblue:
its main victim was Internet infrastructure.
Servers that weren’t patched were at risk of leaking usernames and passwords, having
webpages defaced, being enslaved into cybercrime,
or having their organizations’ private information released publicly.
In another sense, though, all three of these vulnerabilities were very similar:
the root cause was programmer error.
Specifically, in each case the software received some input that it didn’t check properly,
a video chunk size, or a command for transferring file information, or code left by another program.
Sometimes, though, the problems run even deeper than programming.
The Internet is orchestrated by dozens of protocols: a set of standards that dictate
how each type of back-and-forth between computers is supposed to look.
If there’s a design flaw in a protocol, programmers can implement it exactly the way
they’re supposed to and still leave users vulnerable.
That’s the type of flaw a security researcher discovered in 2008.
Specifically, he found a problem with the Domain Name System, or DNS.
DNS is the phone book of the Internet, the service your computer queries when it needs
to find out what numerical Internet address corresponds to scishow.com.
So imagine the fallout if you went to Gmail.com and got a webpage that looked exactly like
Google’s sign-in, but was actually running on a hacker’s computer.
This bug would let an attacker make that happen for everyone sharing an Internet service provider,
the company that you pay to get internet access.
It’s a nightmare for confidentiality: every bit of supposedly secure data could be intercepted.
The vulnerability stemmed from the way DNS servers pass queries to each other.
If your ISP isn’t sure where scishow.com lives, it asks the server in charge of all
.com addresses and waits for the first valid response.
If an attacker can guess that someone will soon be asking for scishow.com, they can flood
the ISP with fake responses claiming that the site lives on the hacker’s computer.
Normally, the ISP would ignore any responses not tagged with the query ID as the outstanding
question, which the attacker wouldn’t know.
But a flaw in the protocol made it too easy to predict what that query ID would be.
Worse yet, the attacker could tell the ISP to remember
and recirculate the forged entry for days.
Implementations have been updated to make query IDs less predictable,
but even now, an attacker could still get lucky.
The only real fix is an update to DNS with security baked in, which exists,
but even ten years later, it’s not fully rolled out.
The most mind-bending attacks go deeper still, down to the physical hardware.
It’s easy to forget that beneath the abstractions of numbers and bits,
all the magic of computers comes down to moving electrons around.
The cybersecurity world got a nasty reminder in 2014, when researchers at Intel and Carnegie
Mellon University managed to run a program that only had access to its own memory,
but was still able to modify other programs’ data.
Google researchers followed up the next year with a version that could target the operating
system’s records of which programs should have access to what.
Effectively, their program could grant itself full access to everything in memory.
Others soon pulled off the attack from within a webpage.
So an attacker wouldn’t even need to run a special program.
The trick was dubbed row hammer after its reliance on the physical layout of memory.
Typically, memory chips are laid out in “rows,”
which have been packed in ever-closer as chips have shrunk.
A row hammer attack activates a row of memory entries over and over again very quickly.
These entries are the ones the attacking program is supposed to have access to,
but the entries in adjacent rows may not be.
After enough of this “hammering,” electrical charges start to bleed through to other rows.
And if the hackers are extremely careful,
they can target those charges to strategically flip 0s to 1s and vice versa.
Of course, once you can modify memory, the game’s up:
you can insert malicious code, grab data, or anything else.
Fortunately, it’s been pretty difficult to engineer practical attacks
based on row hammer, since it relies on detailed knowledge of the memory layout.
Memory chip manufacturers have also rolled out mitigations
that refresh rows that look like they’re getting targeted.
But the potential for exploits is still widespread.
Vulnerabilities like these, whether at the level of programs, protocols, or hardware,
all drive home that bugs will inevitably slip through.
The good news is, lots of hackers are looking for those same flaws not to use them, but to fix them.
Most of the time bugs get patched pretty fast, and the people and websites who get attacked
are usually the ones who failed to update.
So apply those updates quickly, and use services that do the same!
That way, instead of suffering from these attacks,
you can sit back and marvel at the subtle genius it takes to exploit them.
Thanks for watching this episode of SciShow!
If you’re interested in more of the worst computer attacks of all time,
you might want to check out our episode on 5 of the worst viruses ever.
[♪ OUTRO]