Chapter 41 - Security & Exploitation #

I’m going to assume at least some prior knowledge here, if you want a quick intro, I recommend going through ./missing-semester-Security so that we can all be on the same page.

Most books on hacking or security start out either painfully formal talking about how to secure a system or jump straight into breaking into a system.

Neither of these are probably your biggest concern.

Instead, you should be thinking “How do I write code that isn’t horribly fucked for security?” then wrap back around to getting a deeper understanding so that you can know how to actually know how to make some of the more complex decisions, and why they matter.

Let’s start with an example:

1
2
3
4
5
6
7
8

#include <stdio.h>
void main(int argc, char **argv){
    int i = 0;
    printf(argv[1], &i);
    if(i == 1){
        printf("OWO\n");
    }
}

Save as ploit1.c, compile and run with gcc ploit1.c -o ploit

Here, we’ve got 8 lines of code, if run it normally, it just echos the input.

1
2
3

╭─vega@lyrae ~  
╰─➤  ./ploit "test"
test%

But hang on, the printf isn’t doing any checking on the input, what if we put an interger substitution character in there?

1
2
3

╭─vega@lyrae ~  
╰─➤  ./ploit "%d"  
1875151412%

hmmm, alright, can we print a stack pointer?

1
2
3

╭─vega@lyrae ~  
╰─➤  ./ploit "%p"
0x7ffdaa912034%

neat, alright, well there’s an interesting printf sequence, %n, which ouputs the number of characters in the string

1
2

╭─vega@lyrae ~  
╰─➤  ./ploit "%n"

There’s no output… but that should tip you off to what’s about to happen

1
2
3

╭─vega@lyrae ~  
╰─➤  ./ploit "a%n"
aOWO

Got it. By making the string one character (not including the %n itself) %n’s character count output is stored into the interger i, and we trigger the if, printing the string.

Hopefully you see that this is a big problem. The user was able to change code flow on a print statement. With a little more work the input could be crafted to access arbitary memory of the program, potentially getting the print to divuldge something in memory you’d really rather keep private- maybe a password?

This video from Live Overflow explains this much more in depth in just 10 minutes. Give it a watch.

See These Lecture notes on Format String Vulnerabilities from Syracuse University and Intoduction to Format String Exploits from Code Arcana for even more.

The main thing I want you to take away from this example is this:

Seriously, it’s nuts how many exploits are caused by inputs not being checked, allowing for injection attacks. SQL injection letting somebody either read or delete your database? Yep. Cross Site Scripting (XSS). Yep. File Upload attacks? You Bet. Input isn’t just text either. It’s anything a user can, well, input. Don’t be stupid.

Also note, input includes anything the program reads. There’s nothing stopping a user from diving into the programs files and changing some config file or loading in a different .dll/.so library file. Of course, this technically extends all the way to modifying the binary of the executable itself, but at that point the threat modeling is entirely different.

DO NOT #

DO NOT use random crypto libraries or write your own #

I would hope I don’t have to justify this. If the library isn’t common, hasn’t been audited, and you’re not super confident that it’s safe: DO NOT use it.

Similarly, crypto is hard, unless you want to go into it (which is cool, go for it, just be prepared for a lot of math) and understand what you’re getting yourself into, don’t try to write crypto code yourself.

Hell, even just using random() without knowing better is a good way to screw up: see How to Predict Random Numbers (PwnFunction, YouTube)

DO NOT use algorithms that are broken #

I would seriously hope this is a ‘No Shit’. Unfortunately, it seems it’s not. So, allow me:

DO NOT USE: MD5, DES (Including Tripple DES), SHA-1*, AES-EBC, AES-CBC without a MAC

Alright, so what should you use? Well, the answer is obviously “It depends on what you want”, but in general the recommendations from Cryptographic Right Answers are probably a good place to start.

[TODO]

https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/

Building a Curve25519 Hardware Accelerator (BunnieStudios)

DO NOT think encryption is a magic bullet #

Our mysterious hero ran from the evil forces, carrying his trusty cyberdeck with all the information the resistance needed to win, but if it fell into the wrong hands it would all be over. Unfortunately, there were to many- He was surrounded! He feared not though, for his disk was encrypted by AES-4096! While the resistance may not get the data, the evil forces wouldn’t have it either! He taunted his captors, “You’ll never get that data!”

They took his cyberdeck from his bag, and wiggled the mouse to find it had only been asleep, the disks still accessible.

Full disk encryption probably doesn’t do you any good. - https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

DO NOT assume the crypto algo ‘Just Works’ #

YOU have to know how to apply it

[TODO]

https://soatok.blog/2021/01/20/please-stop-encrypting-with-rsa-directly/

DO NOT assume the hardware is secure #

This is one of many side channel attacks on hardware directly. My point here is simple: it’s turtles compromised all the way down.

Along with this, you also shouldn’t make to many assumptions that your code is running in a ‘real’ environment. The code may well be running in a virtual machine or in a container.

Similarly, don’t assume the hardware or gadgets your connecting themselves aren’t malicious. We all know not to plug in random flash drives, but what about USB Plasma globes?

DO NOT assume that things won’t break #

Overflow #

Stack Smashing #

Active Tampering #

DO NOT manage your own memory #

Okay, so, this is weird advice. Obviously, sometimes, you literally have to play around with pointers, there’s nothing you can do about it. The thing is 70 percent of all security bugs are memory safety issues. So, this is a big fucking problem.

To some extent, you can mitigate this by using a higher level language, but that then requires you actually know what you’re doing anyway, and the abstraction can actually bite you in the ass even harder. To prove this point, let’s look at python.

1
2
3
4
5
6
7
8

>>> x = 1
>>> y = 1
>>> x is y
True
>>> x = 257
>>> y = 257
>>> x is y
False

so 1 is 1, but 1001 is not 1001? Well, yes and no

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

>>> x = 1
>>> y = 1
>>> id(x)
140514241382704
>>> id(y)
140514241382704
>>> x = 257
>>> y = 257
>>> id(x)
140514228628624
>>> id(y)
140514228628496

The reference (pointer) for values below 256 are the same, in the documentation

The current implementation keeps an array of integer objects for all integers between -5 and 256, when you create an int in that range you actually just get back a reference to the existing object.

So, the problem her is that instead of x is y this comparison should have been x == y

1
2
3
4

>>> x = 257
>>> y = 257
>>> x == y
True

The point being, memory management is really, really fucking hard to get right and full of gotcha’s, even in something as high level as Python.

There is no silver bullet here. What can help is, first of all, not using C if you can. Rust, C++, whatever. While I’m not a huge fan of object orientation, It does at least, when used correctly, help avoid some of these fuckups. Rust’s forced compile-time check’s do a great job of ensuring safety too. You should also put your program though valgrind and probably some sort of source code analysis tools like splint (C), flawfinder, bandit (Py), or CPPcheck. Still, don’t expect the tools to catch everything. Memory leaks may still sneak by, you may somehow still manage to do a use-after-free, or have some corner case that can segfault.

Assert statements help too, forcing things to break when conditions aren’t met.

1
2
3
4
5

>>> x = 2
>>> assert x == 1, "x should be 1"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError: x should be 1

DO NOT assume that you know who is on the other side #

I’m not trying to be ᏕᎮᎧᎧᏦᎩ, I mean that the server, human, client, whatever that you think you’re talking to, may not actually be who you are talking to. By this I generally mean one of two things:

Either you have a Man In The Middle (MITM) or somebody is being a sneaky douchebag and pretending to be someone else.

For MITM, it’s more or less what it sounds like. If Alice (A) is trying to talk to Bob (B), it would normally look like A⇄B, but for a MITM, there’s someone (let’s call them Mallory (M)) receiving and forwarding all the traffic bidirectionally, that is A⇄M⇄B, yet to both Alice and Bob, this is transparent, that is both Alice and Bob only see A⇄B despite it actually being A⇄M⇄B. M could only be eavesdropping, not changing the content at all, could be changing only the data necessary to see the conversation (hijacking the key exchange and message signatures), or change the messages outright.

It could also be the case that M is just a sneaky douchebag (that’s a technical term), and is just pretending to be B outright, B isn’t even part of the connection.

Some things you should consider:

• Neither side needs to be a machine. It’s very possible that the deceit is that somebody is simply lying about who they are on a call.
• It’s not just that you need to trust the other side is who they say they are, you need to know they wont listen to someone that pretends to be you.
  • This exact problem leads to people being able to carry out a SIM swap scam (Wikipedia)
• While verification of identity is important, so is looking up that identity in the first place. If you always call the wrong number, always connect to the wrong URL, etc. You’re asking for someone to come along and fill that role.

There’s also just a point about not assuming an adress will always point to the same place, like when a bunch of news websites found that they were suddenly showing pron videos (The Verge).

DO NOT claim ‘unhackability’ #

If you do, and you get hacked, it goes from being tragic to funny, and it’s a huge welcome sign to bored hackers that will find a way in.

DO NOT think that code=binary #

The code you write is not the code that will run.

1
2
3
4
5
6
7

int main(){
    int result = 0;
    for(int i=0; i < 999; i++){
            result = result + i;
    }
    return(result%255);
}

main: # @main
  mov eax, 231
  ret

Notice it’s not actually doing any math? It’s just storing the result as a constant in the program. The compiler did some magic, realized the programmer was being lazy and not doing math ahead of time, so did the math once. This is normal. Don’t make the assumption that the code you write will necessarily be the code the machine runs.

DO NOT assume that your users give a half a shit about security… #

They don’t. Maybe a small fraction do. Maybe a few will even have fancy USB authentication keys, be generating random 64 character long passwords filled with symbols. The majority though? The majority will be using some standard password they use everywhere else that has already been compromised, which they’d know if they bothered to check https://haveibeenpwned.com

Also don’t think that even halfway decent password requirements will stop users from using shit passwords or just frustrate the hell out of them. Instead, let them know there’s a minimum length, that passphrases like CorrectHorseBatteryStaple work well, and that any password that’s common will be denied - check if the hash of their password matches the hash of any of the passwords in some common password dictionary like this list of the top 10 million passwords.

Similarly, unless you know you’re audience is already technical, don’t assume that your users will have the even the slightest clue about what an HTTPS certificate is, how to use a public/private key pair, or anything else related to crypto.

There’s a reason torrent clients verify the hash automatically, that browsers show a little lock, and that telegram lets users check their keys with emoji.

Also don’t make your users change passwords on a schedule. We all hate it, It’s not even recomended anymore, and it’s just a royal PITA.

…Or that they have a single clue about privacy #

[TODO]

https://0l.wtf/blog/4_visual_browser_fingerprinting.html

From @MalwareJake on Twitter

[TODO] The Hitchhiker’s Guide to Online Anonymity

Are the top websites using WebGL for fingerprinting?

What about on the job or at school? #

DO NOT think that Old ≠ Good & New ≠ Good #

… Middleaged doesn’t mean good either I guess.

Basically, just because something is new and shiny and claims to be 200% as fast and 4x as secure, doesn’t mean it’s safe. Similarly, just because something is old and well vetted, doesn’t mean it is perfect either. Code that’s been living in the Linux Kernel for decades or even in the sudo binary can have bugs.

Basically, what I’m saying is you should be careful when choosing what to use, patch shit when vulnerabilities are found, and despite how handy using some new kid on the block library looks, you might wanna avoid it if you’re handling sensitive data.

DO NOT get over confident #

You should expect something to fail. Data will leak. You will have an ‘oh shit’ moment. The shit will, in fact, hit the fan, splatter all over the room, and seep into the carpet.

The best you can do is have a plan for when this happens and do your best to make sure that when it does the damage- both short and long term- is minimal.

Basically this comes down to two things: Backups and maintaining uptime. For backups:

The 3-2-1 rule can aid in the backup process. It states that there should be at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite, in a remote location

For uptime, well, that’s more complicated. If you’re trying to keep 99.99%+ uptime, you’ll have to get creative with automatic failovers, software defined networking/storage, etc.

That said, trying to get umpteen 9’s of uptime is a bit crazy for most things anyway.

DO NOT trust humans #

Customer support exists to bypass security. Users exist to find bugs you wouldn’t think possible. Hackers exist to show you that you suck at programming. humans in general exist to do things that to other humans seems totally illogical.

Don’t trust humans. They’re Made Out of Meat.

‘SMS is just the worst, but I’m having trouble convincing people to adopt my preferred system, TLS IRC with a local server and a patched DOSBox gateway running in my mobile browser.’

xkcd #2365

Before we go any further, I want to get something out of the way:

Security is important, and should be taken seriously. But it’s also a field of people who are tired of your shit, Karen. We don’t wear suits and we won’t do something just to look ‘professional’.

If I want to curse, if I want to put furry art on these pages, I will do as I fucking please.

Real ‘Security Professionals’ own the word hacker, and real hackers don’t give a shit about what society tells them to do. Hacking is about finding how systems can do something far outside of what the original desigener ever even considered, about finding solutions so elegant they’re art, about breaking boundries. If you want to keep with professionalism or tradition you’re in the wrong place.

As Soatok put it:

If people who are sharing great content–be it on Twitter or on their personal blog–do something that prevents you from sharing their content with your coworkers, the problem isn’t us.

No, the real problem is your coworkers and bosses, and the unquestioned culture of anal-retentive diversity-choking bullshit that pervades business everywhere.

[TODO] https://paragonie.com/blog/2015/08/gentle-introduction-application-security

Authentication & Authorization #

Authentication != Identity

https://permission.site

https://www.osohq.com/post/why-authorization-is-hard

https://alexolivier.me/posts/the-never-ending-product-requirements-of-user-authorization

https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

https://github.com/kdeldycke/awesome-iam

Cryptography #

How To Learn Cryptography as a Programmer (Soatok)

A furry writes about Cryptography but trust me you should actually read this (Soatok)

Hashing #

Note there’s general two ‘classes’ of hashing- hashing for cryptographic security (Passwords) and for just general usage, the cryptographic ones typically are significantly more computationally intensive to make it harder to brute force all possible keys. Also most cryptographic hashing algorithms go to much greater lengths to avoid collisions. Also, salting is relevant here: Salting (Wikipedia)

If you want to dive into the math of hashing, going through this repo to make SHA-256 yourself will teach you a lot. Of course, don’t ever use one you wrote yourself. Just like encryption, leave it to the battle tested libraries.

Note, that some hashing algorithms are known to be broken at this point, like MD5 and SHA1. Don’t use them.

The GitHub page for xxHash has a nice table showing the speed of quite a few common algorithms.

Security Policies #

Metadata can bite you in the ass

Threat Modeling #

Network Security #

Types of exploits #

[TODO] - where to put return oriented programming, super old hardware/software - ’the home router’,

Otherwise known as hacking, exploitation of software is always alluring, though in reality like many things it is much less glamorous than the news or tv make it out to be. Before I get into it I want to plug ‘The Art of Exploitation’ by Jon Erickson again, as it truly is a masterpiece that describes exploiting in a way that just makes sense

[TODO]

passive V active attacks - monitoriring/obtaining contents of message V Tampering, Dos, Replay, Faking ID

Software #

strings

Injection - SQL

breaking hashes

Heap/buffer overflow

dangling pointers

code-injection

places you don’t expect to have code like PDFs

clock attacks

Race conditions

Path traversal

format string

pseudo-random

Fuzzing

Hardware #

Intro to Hardware Reversing: Finding a UART and getting a shell (YouTube)

Talk about CPU bugs

Power side channel

Timing attacks

pseudo-random (hardware side)

Hardware trust (HID injection)

replay attacks

radio, rfid, etc

rowhammer, Heartbleed

https://github.com/ggerganov/kbd-audio/discussions/31

Social Engineering #

Phishing

spoofing (email, phone)

UTF-8 v ASCII

click jacking

expired certificate

default passwords

honey pots

stalkerware (Should this be moved?)

Looking up documents - see Coke Freestyle Manual

Physical security #

Lock picking as a last resort

Law School for Lockpickers [YouTube, DEF CON 28]

data destruction

Malware #

Section here about not being a dick

Viruses

polymorphic

boot-record/rootkit

trojan

logic/compression bomb

logic/time bombs

ransomware

adware/spyware

Tools of the trade #

Many tools in common with debugging (gdb - gef, hex editors, logic analzer)

and testing (fuzzing)

decompilers, dissassembly, analysis

https://github.com/plasma-disassembler/plasma

Wireshark

Cheatengine

dynamic linking

Sandboxing

Responsible Disclosure #

https://adamcaudill.com/2015/11/19/responsible-disclosure-is-wrong/

IOT #

Infrastructure #

Elections #

Game Hacking #

https://gamehacking.academy/GameHackingAcademy.pdf

Getting some practice #

https://gtfobins.github.io

A 64 bit bind shell ELF binary in 172 bytes. (GitHub Gist)

CTF-Time #

PWNie Island #

Let’s Play/Hack - Pwn Adventure 3: Pwnie Island (YouTube, LiveOverflow) (Here he’s playing a game where you have to exploit it to win)

How To Learn Something New? - Game Devlog #1 (YouTube, LiveOverflow) (Here he’s making a game where you’re supposed to exploit it)

Where to learn even more: #

Live Overflow, Youtube: https://www.youtube.com/channel/UClcE-kVhqyiHCcjYwcpfj9w/playlists

Phrack : http://www.phrack.org/

Defcon Media Server : https://media.defcon.org/

As mentioned above in Chapter 17- Compilers and Assemblers At this point I highly recommend ‘The Art of Exploitation’ by Jon Erickson

https://microcorruption.com/ , https://ctftime.org/ ,

CTF time,

https://nagarrosecurity.com/blog/interactive-buffer-overflow-exploitation

Writehat (GitHub) - “A pentest reporting tool written in Python. Free yourself from Microsoft Word.”

https://opensecuritytraining.info

Modern Binary Exploitation from Rensselaer Polytechnic Institute in Spring 2015

Some Hacking Community Fun #

Bash injection without letters or numbers (YouTube, LiveOverflow)

Pwned By The Owner: What Happens When You Steal A Hacker’s Computer (YouTube, Defcon)

How a Hacker Convinced Motorola to Send Him Source Code

Diabetics Are Hacking Their Own Insulin Pumps

Beg Bounties (Troy Hunt from haveibeenpwned)

https://learn.sparkfun.com/tutorials/gas-pump-skimmers

Does register selection matter to performance on x86 CPUs?

Leap Day Bugs

DEF CON 18 - Zoz - Pwned By The Owner: What Happens When You Steal A Hacker’s Computer (YouTube)

Diabetics Are Hacking Their Own Insulin Pumps (YouTube)

Big List of Naughty Strings (GitHub)

Widevine L3 Decryptor

αcτµαlly pδrταblε εxεcµταblε

Sacred texts of hacking: #

From https://wiki.xxiivv.com/#development:

The Four Essential Freedoms: The freedom to run the program as you wish, for any purpose. The freedom to study how the program works, and change it. The freedom to redistribute copies so you can help others. The freedom to distribute copies of your modified versions to others.

The hacker and information freedom community has multiple ‘sacred texts’ if you will, which I think do a good job of outlining some of the ideologies of the communities. Probably the most famous is the Guerrilla Open Access Manifesto written by Aaron Swartz, an amazing man that, according to Wikipedia “was involved in the development of the web feed format RSS and the Markdown publishing format, the organization Creative Commons, and the website framework web.py, and was a co-founder of the social news site Reddit”. Due to his extensive work in online politics his Wikipedia page almost acts like a hub of sorts for relevant information: https://en.wikipedia.org/wiki/Aaron_Swartz. His most famous text though is probably the Guerrilla Open Access Manifesto.

Another one that you should read is The Conscience of a Hacker written by ‘The Mentor’ in ‘86: