Information Security Basics - Attack & Defense

Overview

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.

Attacking: the process

A complete intrusion attempt follows this process:

pentesting-phases.jpg

Figure 1: Pentesting phases

  • 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.

Enumeration, or: Finding a way in

nmap5-samplescan.png

Figure 2: nmap scan

nessus-scan.png

Figure 3: Nessus scan

Weak credentials

weak-password.jpg

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.

Code injection attacks

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)

shellshock.jpeg

Bash 1st release: 1989

Shellshock public disclosure: 2014

Eval: the root of all evil

good-eval.png

Figure 6: eval is evil (?)

Almost every hacking attempt will involve some variation of the following:

  1. Send malicious input data
  2. Find a way to execute the data in the remote computer
  3. Use the above to execute commands remotely

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.

XSS

reflected-xss.png

Figure 7: XSS attack

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):

beef-actions.png

Figure 8: Beef Framework

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

LFI / RFI

lfi-example.png

Figure 9: Local file inclusion example

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:

Even though PHP is the butt of security jokes, make no mistake, other languages are vulnerable to this sort of issue as well:

SQL injection

what-is-sql-injection.png

Figure 10: What is SQLi?

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.

nosqli.jpeg

Figure 11: NoSQLi

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

Other attacks

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).

Privilege escalation

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.

Programs running as root

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.

SUID/SGID executables

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.

Kernel exploits

kernel-exploit.png

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.

Demo: MrRobot

mr-robot.png

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.

More information

Books

Web app security:

Basic reversing/memory corruption (buffer overflows + format string bugs):

Other books I just wanted to mention:

Online

CTFs, wargames and the like:

Interesting YouTube channels:

  • LiveOverflow (very humble guy, and my favorite)
  • Derek Rook (HackTheBox walkthroughs and other CTFs)
  • scanlime (Micah Elizabeth Scott - lady who does electronics and hardware reversing)

Questions?

hack-in-progress.gif