Note: I am trying something new and recording posts in MP3 format for those of you on the go. The audio quality is just me and my phone - not studio quality, but maybe you’ll like it. You can get the MP3 here, and subscribe to the podcast RSS feed as well.
I ran across this gem yesterday - some enterprising researcher folks used electrical tape to alter the number 3 on a 35 MPH speed sign and then pointed a few Teslas at it. Predictably, the Teslas read the sign wrong and accelerated past the speed limit. But is that a hack? A human can also be fooled by a creative sign modification, too. Granted, this sign’s particular modification would be unlikely to fool a human, but artificial intelligence is weak and new and stupid still, so it’s a really attractive target for bad guys. Where do we draw the line between a “hack” and crappy software? One is a crime, the other is the modern standard way of delivering service over the internet.
When I read the headline, I assumed that the researchers had used the tape to close off the 3 to make it look like an 8. That would be the most obvious thing to do and, as I stated, could also fool a human. But that is not what happened. You can see from the sign above that the 3 is very clearly still very much a 3. There would be no obvious reason why the Tesla brain would read that as an 8 so that falls squarely into the bug category for me, and not a hack.
There is a long-standing tradition on the internet to stipulate that the words hack and hackers are misnomers that vilify legitimate researchers. That audience would prefer that the bad hackers are called crackers, and the good guys retain the handle hacker. That battle has been lost soundly and I’m really only mentioning it to fend off the “Well, actchually…” comments that writing about hacking to a technical audience sometimes generate. I see you, GNU/Linux guy. Just accept the language isn’t under your control and move on.
What is a hack?
Good question. It’s hard to say what a hack is, but it is pretty easy to identify what a hack is not.
A hack is not a denial of service attack. It is not a brute force login attack. It is not downloading data from an insecure S3 bucket. While we may not like it when those things happen, they occur by design.
A network card should drop traffic when it becomes saturated. A website should permit a login when presented with a correct credential set. An unsecured S3 bucket should allow anyone to download the data in it.
I contend that there aren’t really many hacks in the world. Most of what we call hacks are mistakes or bugs. How far can we take this train of thought until it no longer makes sense? When is the line crossed and a system operating as designed considered hacked? Let’s look at a few with that framework.
SQL injection
Let’s look at a SQL injection attack. The basic idea here is to issue a query against the database that returns unintended data. Consider this example from OWASP:
SELECT * FROM items WHERE owner = AND itemname = ; ...the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string “name’ OR ‘a’=’a” for itemName, then the query becomes the following:
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';The ‘a=a’ bit is the magic here. That statement will always evaluate to true and because it is preceded with an OR statement, any other statements in the WHERE clause don’t matter. Therefore this query will return every record from the items table. Probably not what the developer intended. But the database is operating as designed. It was given a syntactically correct query so it executes it as asked. You can probably see how an injection attack like this would progress through the first few steps of the Kill Chain:
Recon: Run this query through every form on a site and see what you get back. If it works anywhere…
Weaponization: Craft a more useful query that will expose more valuable data, or possibly a stored procedure in the database…
Delivery: Execute the query…
Exploitation: Take that data and use it to log in to this site, credential stuff other sites, or execute the stored procedure…
This is neither a hack nor a bug. It is one human making a mistake by not sanitizing input code and another human taking advantage of that. It’s just a mistake.
Shell Shock
The BASH Shell Shock revelation in 2014 was a Very Big Deal. The basic requirement for a successful Shell Shock exploit is a web server running a CGI program written in BASH, or written in some other language but shelling out to BASH to call system executables. That is an extremely large number of servers on the public internet and it caused widespread panic. But, how does Shell Shock work?
BASH is a widely used Linux shell, perhaps the most commonly used. It has the ability to declare functions in the environment for later execution. The syntax used to do this is (from Fedora Magazine):
$ yayfedora() { echo "Fedora is awesome."; }This creates a function named yayafedora in the shell environment that can be called later. So far, no big deal.
$ yayfedora Fedora is awesome.The trick to exploiting Shell Shock is to send a BASH function within a request to a web server by embedded this function in a web server variable. Internet users don’t have direct access to web server variables, but they do have the ability to craft arbitrary HTTP headers and when a web server encounters an HTTP header, it copies it into an internal web server variable in case it needs to examine it later. So, something like this will embed the BASH code to print out the passwd file into the `user-agent` variable of the target web server (from opsxcq):
curl -H "user-agent: () { :; }; echo; echo; /bin/bash -c 'cat /etc/passwd'" http://somesiteHaving this code in a web server variable isn’t dangerous by itself because it’s just sitting around in memory. It is not being executed. In order for this code to execute it has to be passed to a vulnerable CGI program. If the web application uses a vulnerable CGI program, then it will execute this code when the HTTP user-agent variable is passed to it.
The final step is the execution of this code. If you’ve been paying attention you will see that the code sent to the webserver continues past the first semi-colon which should indicate the end of the command in BASH. This is the crux of the exploit: BASH loads the harmless function into memory but it does not stop reading there. It continues reading past the semi-colon and ends up executing the code following it.
This was a bug in BASH and not a hack. It was a mistake by a human developer that was exploited by another person who stumbled across it.
Specter
In 2018 the world became aware of a very broad problem with Intel CPUs that are in extremely wide use in every industry. Every generation of CPU is faster than the last and a lot of that speed comes from hardware changes to the chips. Faster hardware can process more data at once, thus the server generally becomes faster all around. However, CPU microcode also plays a part in these speed increases. For years, CPUs have been utilizing code that predicts what the CPU will be asked to do next and runs that code in advance. It then stores the results of that execution in the cache so it can provide the results quickly to the calling process when it finally asks for it. This is called speculative execution and when a CPU mis-predicts, it discards the results of that execution.
Specter is a wide and open-ended class of attacks that can make use of this discarded data and that data can contain sensitive information, even decryption keys. It is made worse by the fact that it is possible to predict what data will be in the cache, or even force desired data into the cache in order to retrieve it. One possible attack scenario looks like this.
First, it shows that branch prediction logic in modern processors can be trained to reliably hit or miss based on the internal workings of a malicious program.
It then goes on to show that the subsequent difference between cache hits and misses can be reliably timed so that what should have been a simple non-functional difference can, in fact, be subverted into a covert channel which extracts information from an unrelated process's inner workings.
Thirdly, the paper synthesizes the results with return-oriented programming exploits and other principles with a simple example program and a JavaScript snippet run under a sandboxing browser; in both cases, the entire address space of the victim process (i.e. the contents of a running program) is shown to be readable by simply exploiting speculative execution of conditional branches in code generated by a stock compiler or the JavaScript machinery present in an existing browser. The basic idea is to search existing code for places where speculation touches upon otherwise inaccessible data, manipulate the processor into a state where speculative execution has to touch that data, and then time the side effect of the processor being faster, if its by-now-prepared prefetch machinery indeed did load a cache line.
Finally, the paper concludes by generalizing the attack to any non-functional state of the victim process. It briefly discusses even such highly non-obvious non-functional effects as bus arbitration latency.
This exploit falls into the same bucket as the SQL injection. It is a CPU operating as designed. The CPU was designed to predict future requests, run them in advance, and store the results in the cache. It is the design that has the problems, but those problems are not bugs. A human who wrote this code did not predict that its output could be used this way and another human picked up on it.
Is anything a hack?
The takeaway from this post is, hopefully, that the term “hack” has been stripped of all meaning. The vast majority of people do not have the necessary level of technical knowledge to asses how any given attack can occur, so it just gets lumped into the shoulder-shrugging bucket of “hacks”.
The problem with this is that it lends an air of unreliability to computers and technology. We become distrustful of technology because it is always being “hacked”. The reality is that these machines are almost always doing exactly what they’ve been configured to do. The fault lies with the humans who write code and configure systems. It is those people who allow the hacks to occur, not the machines.
The state of internet security is so poor that it barely constitutes security at all. Most code and most systems are not developed or configured by people trained in security and therefore most of it is not secure at all. The level of security competence among developers and system administrators is appalling so we can expect to see this trend continue for the foreseeable future.
To bring this back to the start, we have an industry that can’t even reliably secure an S3 bucket now developing autonomous cars. The more prudent path forward is to create a generation of security-oriented technology workers first, then build the important disruptive technologies properly.
There Are No Hacks