“Know thy Linux” – The Satori Suite

I present you Satori (悟り). A tool for snapshoting and comparing Linux Directory Trees.

   ▄████████    ▄████████     ███      ▄██████▄     ▄████████  ▄█  
  ███    ███   ███    ███ ▀█████████▄ ███    ███   ███    ███ ███  
  ███    █▀    ███    ███    ▀███▀▀██ ███    ███   ███    ███ ███▌ 
  ███          ███    ███     ███   ▀ ███    ███  ▄███▄▄▄▄██▀ ███▌ 
▀███████████ ▀███████████     ███     ███    ███ ▀▀███▀▀▀▀▀   ███▌ 
         ███   ███    ███     ███     ███    ███ ▀███████████ ███  
   ▄█    ███   ███    ███     ███     ███    ███   ███    ███ ███  
 ▄████████▀    ███    █▀     ▄████▀    ▀██████▀    ███    ███ █▀   
                                                   ███    ███ 

First of all, you can find it here: Link (github repo) and it is under the well-known beerware license.

Now, let’s get started:

As in the README.md from the repo:

"Satori" is a Japanese Buddhist term for awakening, "comprehension;
understanding" [...] enlightment. en.wikipedia.org/wiki/Satori

So the tool is named after the spontaneous feeling of absolute knowledge, the spontaneous mindblow, a researcher feels when he/she finally understands what exactly is happening in a system or network!

I first heard that term (more like read it) in Tom Robbins’ book: “Tibetan Peach Pie: A True Account of an Imaginative Life“, where he (the author) felt the Satori while watching the movie : “Shoot the Piano Player“.

The rest of the tool (that is: all except the name) was inspired by the SPSE course I attended this year (and haven’t arranged the exams yet – the “Never do now what you can do later” syndrome).

<Typical paragraph about the course>

I believe it is a great course, and if you are on “Offensive” python and can spare the price (it hurts a bit), just buy it and get the cert. It’s gonna teach you many more things than python. For me, its title should have been “How to be MacGyver using only a PC and Python“. Movin’ on…

</Typical paragraph about the course>

 

The Satori’s Reason of Existence

I like CTFs. The day I found out that there is something called “Vulnhub” I cried out of joy and got lost in my bedroom for days. Must have lost some weight too. But Ι finally found a general pattern…

Every boot2root VM has a way to get the limited shell and then there is the Privilege Escalation part. There aren’t really many ways to get that limited shell though. Most of the time there is a web page with a glaring (or not so much) exploit or misconfiguration. There are some exception to this (/dev/random: Sleepy) is a great one – no spoils.

So assuming that we have a limited shell, the real game starts. The privesc part is really the heart of it all. Getting other users and the root is a matter of how well someone knows Linux fundamentals, reversing and the whole BOF bandwagon, service defaults, and other details. Most of the time a binary exploit (from exploit-db) does the thing, as the systems are heavily unpatched (as they are outdated) but this is what I name “cheating”, as those VMs are made for educational purposes and apart from cross-compiling binaries there aren’t many things to learn from auto-root exploits.

So how to get root? There is a different scenario every time. But generally there is a misconfiguration that can be exploited badly. A great example of this is the SickOS 1.1 VM. There is something there that can be misused. So where is it?

There is a way to find that little thing that will give you the # prompt. There are tools and cheatsheets that will highlight you some places to look first. An example is rebootuser’s Enumeration cheatsheet. They really do a good job, but they need your prior knowledge of how things “should be” for you to examine how “they are” and what is the exploitable difference.

An example here can be the find command for SUID executables. That is:

find / -perm -4000 2>/dev/null  # the famous "2>/dev/null" omits error output

and the output is :

/usr/bin/mount
/usr/bin/chage
/usr/bin/gpasswd
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/su
/usr/bin/chsh
/usr/bin/umount
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/crontab
/usr/bin/passwd
/usr/sbin/unix_chkpwd
/usr/sbin/usernetctl

This is the kind of answer expected from such cheatsheet commands. They return you raw data. Which execs are SUIDs? Here! Those are. Do whatever pleases you with them. You can’t know if su has a backdoor. Or if they are really old (exploitable?) versions (looking at you sudo). Are those the standards? Is there something that shouldn’t be there?

These are the question that Satori tries to answer. Generally speaking, the author of the VM has planted a misconfiguration in the Linux system, that wasn’t there by default. And the only way to find it is to be sure about what IS there and what ISN’T in the original distro installation. This needs some serious experience and knowledge of distro specifications. So if you haven’t been a Linux admin by now (say you are just 20 years old) how possibly can you get this knowledge? Can’t all that knowledge be extracted and used ?

Yes! It can! That’s what Satori does.

 

How?

Satori has 3-ish tools. It is more like a suite than a single tool. It is under heavy development (so many things can be done better) and is considered 30% alpha / 70% beta, but it works just fine now. It started as a Proof of Concept tool-chain, and now that it really works it needs some major rewrites. The developer’s sweet hell…

The tools are an “Imager”, a “Browser” and a “Differ”. There is also a “Remote” module that is nothing more than a module that runs the “Imager” tool to a remote system.

So, please welcome the stars of the show:

Satori-Imager

The Satori Imager crawls the whole file system and collects metadata in the whole directory structure. It excludes some directories by default but this is configurable. It finally packs all this data in a tree-structured dedicated format for use with the other Satori tools. The dedicated format is nothing more than serialized (pickled or json’ed) Python dicts compressed with gzip.

The information that gets collected is generally everything a file has except timestamps and inode info. So privilege bits, owner, group, size even a SHA2 hash are included. Optionally the output of file command and even its actual content (for text files) can be collected as well. The Satori images also contain metadata about the system such as user that did the image dump, date of the image dump, system ‘uname -a‘ and more.

Satori-Browser

Satori Browser is a tool that loads those image files and spawns a custom UNIX-like shell in the underlying File System. The user can freely ‘ls‘, ‘cd‘ and ‘stat‘ all files in the FileSystem image.

The shell’s capabilities depend on the choices made when creating the image, for example: if Satori Imager was configured to dump text content of files then, also, a ‘cat‘ command would be available.

{Satori} sickos@SickOs / $ 
{Satori} sickos@SickOs / $ 
{Satori} sickos@SickOs / $ ls
tmp    bin    sbin    lib    selinux    opt    mnt    etc    vmlinuz    srv    usr    var    lost+found    initrd.img
{Satori} sickos@SickOs / $ cd /etc
{Satori} sickos@SickOs /etc $ stat passwd
    SHA2 : N/A
    group : 0
    privileges : 0100644
    filename : passwd
    owner : 0
    path : /etc
    type : N/A
    size : 1103
{Satori} sickos@SickOs /etc $

and finally :

 

Satori-Differ

This tool needs 2 Satori images and finds the differences file by file. It outputs both a log with every changed file and the field that has been changed and a tree that visualizes those changes. The logs are created to be “greppable” (printed to stdout, contain keywords) while the tree is colored to indicate the type of change in every file (and printed to stderr to be unaffected by grep).

 

Ok, so let’s use it. Let’s root a machine with Satori.

We are gonna use the SickOS 1.1 Vulnhub VM for example of privesc with Satori. It is considered an easy VM, doesn’t need a debugger or sophisticated methods, but it demonstrates perfectly the “out of place” concept that Satori tries to tackle.

Here we go (screenshot mode: ON)

Screenshot from 2016-08-14 20-06-06

We do some magic to get to the SSH shell (this article is not a walkthrough, we need the shell to do the demonstration, walkthroughs are available in Vulnhub).

So hocus pocus SSH shell:

Screenshot from 2016-08-14 20-13-32.png

So this is the time for Satori-Imager through SSH. I present you Satori-Remote:

Screenshot from 2016-08-14 20-25-39.png

It uses the classic user@host argument for the SSH connection, prompts for a password, uses the standard -[q|v|d] verbosity flags and passes everything in the –argument flag to the real Satori-Imager, which will be to also collect all hashes from the remote filesystem. It also prints the remotely executed Satori-Imager’s output in a grey font color.

Screenshot from 2016-08-14 20-29-45.png

We got the Satori Image file! Did I mention how small these files are, comparing to the information they contain?

Ready for the diffing!

Wait… We don’t have any original Satori Image for Ubuntu 12.04 server! A bummer…

Luckily, I have created a repo in Github where I upload Images for heavily used Linux Distros. You can have it all: satori-images. They will be outdated soon, but they work. Configuration files do not change very often.

It just so happens that “satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz” is available.

Now we are ready:

Screenshot from 2016-08-14 20-30-13.png

First goes the Image filename that should be considered “Original“, next the “Dirty” one and finally the full path of the directory that should be diffed. Generally a “/” will do, but the difference tree will be huge (consider system updates, apt’s package folder, all those system files that change silently), so we need to specify a directory that contains most valuable info. “/etc/” that is! We also use quiet mode to omit the banner and “2>/dev/null” to omit the printed tree (for now). We have something like:

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null

Go:

Screenshot from 2016-08-14 20-57-36.png

A mess! What were we thinking? We asked for ALL changes in /etc/ folder. Here we are. We got them… The output is almost 3 pages. The screenshot contains only the last one.

Now let’s start filtering out useless log lines, so we will eventually find the useful info.

We can see many files in  /etc/ssl/certs that are not in the original Image. That is acceptable, no misconfiguration here. So let’s Unix Kung Fu through the results. (Actually just “grepminusVing” keywords).

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null  | grep -v "/ssl/certs"

Screenshot from 2016-08-14 21-06-25.png

2 Pages! What are all those font files? They have been installed afterwards. Maybe apache did that. Generally there are many apache conf files, while our Original image has no apache installed. So let’s omit all lines with “fonts” and “apache” in them. Also “mysql“, “squid“, and “php” fall under the same category.

./satori-differ.py ../satori-images/ubuntu_server/Linux-3.13.0-32-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz /etc/ -q 2>/dev/null  | grep -v "/ssl/certs" | grep -v "fonts" | grep -v "apache" | grep -v "mysql" | grep -v "squid" | grep -v "php"

And we get this output (with bold all changes that are considered bogus) :

[EXISTENCE] File '//etc/lvm' exists in the original but not in the given image!
[EXISTENCE] File '//etc/nologin' exists in the original but not in the given image!
[EXISTENCE] File '/etc/alternatives/cc' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c89' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c99' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c89.1.gz' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/c99.1.gz' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/cpp' is not existent in the original image.
[EXISTENCE] File '/etc/alternatives/cc.1.gz' is not existent in the original image.
[ALTERATION] File '/etc/group' size differs. Original is of size 667 bytes and given is 712 !
[ALTERATION] File '/etc/group' has different hash !
[ALTERATION] File '/etc/popularity-contest.conf' has different hash !
[ALTERATION] File '/etc/init/network-interface.conf' size differs. Original is of size 1069 bytes and given is 803 !
[ALTERATION] File '/etc/init/network-interface.conf' has different hash !
[ALTERATION] File '/etc/console-setup/cached.kmap.gz' has different hash !
[ALTERATION] File '/etc/localtime' size differs. Original is of size 3519 bytes and given is 265 !
[ALTERATION] File '/etc/localtime' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_rsa_key' size differs. Original is of size 1679 bytes and given is 1675 !
[ALTERATION] File '/etc/ssh/ssh_host_dsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_ecdsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_rsa_key.pub' has different hash !
[ALTERATION] File '/etc/ssh/ssh_host_dsa_key' size differs. Original is of size 668 bytes and given is 672 !
[ALTERATION] File '/etc/shadow' size differs. Original is of size 774 bytes and given is 900 !
[ALTERATION] File '/etc/hosts' has different hash !
[EXISTENCE] File '/etc/update-motd.d/95-hwe-eol' exists in the original but not in the given image!
[ALTERATION] File '/etc/group-' size differs. Original is of size 663 bytes and given is 699 !
[ALTERATION] File '/etc/mailcap' size differs. Original is of size 2226 bytes and given is 2293 !
[ALTERATION] File '/etc/mailcap' has different hash !
[ALTERATION] File '/etc/issue' has different hash !
[ALTERATION] File '/etc/passwd-' size differs. Original is of size 1034 bytes and given is 1088 !
[ALTERATION] File '/etc/issue.net' has different hash !
[ALTERATION] File '/etc/fstab' size differs. Original is of size 690 bytes and given is 739 !
[ALTERATION] File '/etc/fstab' has different hash !
[ALTERATION] File '/etc/apt/sources.list' size differs. Original is of size 3357 bytes and given is 3353 !
[ALTERATION] File '/etc/apt/sources.list' has different hash !
[ALTERATION] File '/etc/apt/apt.conf.d/01autoremove-kernels' has different hash !
[ALTERATION] File '/etc/lsb-release' has different hash !
[ALTERATION] File '/etc/gshadow-' size differs. Original is of size 551 bytes and given is 584 !
[ALTERATION] File '/etc/rc.local' size differs. Original is of size 306 bytes and given is 343 !
[ALTERATION] File '/etc/rc.local' has different hash !
[ALTERATION] File '/etc/init.d/sudo' size differs. Original is of size 690 bytes and given is 700 !
[ALTERATION] File '/etc/init.d/sudo' has different hash !
[ALTERATION] File '/etc/apparmor.d/cache/.features' size differs. Original is of size 1332 bytes and given is 1095 !
[ALTERATION] File '/etc/apparmor.d/cache/.features' has different hash !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-cd.rules' size differs. Original is of size 535 bytes and given is 803 !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-cd.rules' has different hash !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-net.rules' size differs. Original is of size 471 bytes and given is 659 !
[ALTERATION] File '/etc/udev/rules.d/70-persistent-net.rules' has different hash !
[CHMOD-ED] File '/etc/ssl/private' has different privileges! Originals are 040700 and given are 040710 !
[CHOWN-ED] File '/etc/ssl/private' has different group! Original group is 0 and the file's group is 113 !
[ALTERATION] File '/etc/default/grub' size differs. Original is of size 1225 bytes and given is 1224 !
[ALTERATION] File '/etc/default/grub' has different hash !
[ALTERATION] File '/etc/default/locale' size differs. Original is of size 19 bytes and given is 33 !
[ALTERATION] File '/etc/default/locale' has different hash !
[ALTERATION] File '/etc/gshadow' size differs. Original is of size 555 bytes and given is 594 !
[EXISTENCE] File '/etc/resolvconf/update-libc.d' is not existent in the original image.
[ALTERATION] File '/etc/resolvconf/resolv.conf.d/original' size differs. Original is of size 44 bytes and given is 23 !
[ALTERATION] File '/etc/resolvconf/resolv.conf.d/original' has different hash !
[ALTERATION] File '/etc/shadow-' size differs. Original is of size 677 bytes and given is 900 !
[ALTERATION] File '/etc/ca-certificates.conf' size differs. Original is of size 7464 bytes and given is 6961 !
[ALTERATION] File '/etc/ca-certificates.conf' has different hash !
[ALTERATION] File '/etc/timezone' size differs. Original is of size 17 bytes and given is 14 !
[ALTERATION] File '/etc/timezone' has different hash !
[EXISTENCE] File '/etc/logcheck/ignore.d.paranoid' is not existent in the original image.
[EXISTENCE] File '/etc/logcheck/ignore.d.workstation' is not existent in the original image.
[ALTERATION] File '/etc/hostname' has different hash !
[ALTERATION] File '/etc/os-release' has different hash !
[ALTERATION] File '/etc/initramfs-tools/conf.d/resume' has different hash !
[ALTERATION] File '/etc/passwd' size differs. Original is of size 1037 bytes and given is 1103 !
[ALTERATION] File '/etc/passwd' has different hash !
[ALTERATION] File '/etc/mtab' size differs. Original is of size 556 bytes and given is 510 !
[ALTERATION] File '/etc/mtab' has different hash !
[ALTERATION] File '/etc/ld.so.cache' size differs. Original is of size 15807 bytes and given is 18695 !
[ALTERATION] File '/etc/ld.so.cache' has different hash !
[EXISTENCE] File '/etc/cron.d/automate' is not existent in the original image.

The “rc.local” has changed! This means that a command runs at reboot. As we have SSH let’s read it!

Screenshot from 2016-08-14 21-33-02.png

It loads iptables firewall rules. We couldn’t care less. We are in now!

And what is this “automate“?

Screenshot from 2016-08-14 21-34-11.png

Boom! This python file will run as root once every minute… If only it is world-writable…

We could see that via the SSH shell, but let’s do it with Satori-Browser, just for the hell of it. Just like:

./satori-browser.py Linux-3.11.0-15-generic-i686-with-Ubuntu-12.04-precise_HASH.jsn.gz

Screenshot from 2016-08-14 21-42-49.pngThe beloved 777. The number of the beast plus 111… Consider the box pwned…

Plenty of possibilities here… Copy a SUID dash in /tmp, create another UID 0 user, change root passwd (generally bad idea). We will be Captain Obvious and get a reverse shell. A python one will do.

We ‘ll use oneliner-sh, a bash script that returns wildcard-ed reverse-shell oneliners (both Windows and Linux flavored), mainly from pentestmonkey, Nishang and other sources that I can’t remember right now but are referred from pentestmonkey website.

oneliner -i 192.168.56.1 -A lin -r

Screenshot from 2016-08-14 21-53-02.png

So now we are changing that python file while waiting for our shell:

Screenshot from 2016-08-14 22-04-36.png

It can arrive any minute…

Screenshot from 2016-08-14 22-05-47.png

Mission Accomplished!

(screenshot mode: OFF)

So this is Satori.

Ohh, almost forgot… The diff tree view I am so proud of!

(screenshot mode: ON again)

and as you can see, the “automate” file is marked green (added after the original) in the last page, in front of our eyes the whole time…

 

Afterthoughts: Satori’s whole philosophy of “Attack

Using this tool is a non-intrusive method of attack. It almost eliminates the interaction with the remote box by maximizing the Information Gathering phase and doing the Vulnerability Scanning completely offline. If you think of it we had no bash history left behind apart from the actual modification of the “connect.py” Python file and the read of the “automate” cronjob (which could be done locally too, if we used the Imager to also collect text files).

I don’t say, in any way, that this technique is forensically safe, considering that the Remote module just copies the whole Satori Suite to the target’s hard drive, runs it (talking about things that can get better!) and then wipes it. But it is a different approach to CTFs than firing up random exploits, googling service names and metasploiting. It is more educational and silent. We knew the vulnerability before we even logged in with SSH to get a machine prompt and actually DO something.

I don’t know if this is the best way, or the most effective one. I doubt it to be honest. But this is my approach to CTFing and maybe pentesting, as this is my approach to life! And as a tool I wrote, I poured some soul and my mindset in it. It wasn’t designed to be an autopwner.

 

Things that would be cool to happen in the future

  • Create a Satori-Remote module that will work with reverse/bind shells! SSH is great but not that usual.
  • HTMLify the results of the Remote-Differ. Maybe apache them to the local network for the whole CTF team to watch and check. Only better thing than a good pair of eyes is multiple pairs of eyes. Especially in privesc!
  • Include kernel config files and maybe build hashes. A badly configured recompiled kernel could be a major source of exploits!

 

 

 

Advertisements

Dating as a form of Penetration Testing

People as (vulnerable) infrastructures

Interesting things can be deduced if we consider a human being, a person, as a system, an infrastructure. It is really a generalization that seems too far-fetched while talking about people behaviors but kind of applies… People have there own “policies” (they sometimes are called ethics), responses to stimulus, protocols, a list of other systems that are influential to them and finally vulnerabilities.

 

Exploiting people and anatomy of an exploit

People have vulnerabilities, just like infrastructures. Those little (or bigger) things that give you a special handle on a person. You surely have seen one being exploited, or you have done that yourself, sometime in your life! This sneaky: “Oh, come on dad, I ‘ll be a good girl, just give me the car keys for an hour“, or the “I ‘ll buy you the Game Boy Color if you pass your English exams with A” (yes, family is a common place for manipulation) is an exploitation. A way to make someone do something that wasn’t supposed to happen. And as an exploitation it resembles anatomically exactly a “Computer Hack”.

For Example, in the above exploit-phrase we can clearly see the Exploit and the Payload :

I ‘ll buy you the Game Boy Color if you pass your English exams with A.

And it is a serious one! The poor little kid, would do anything for a Game Boy, so his mother will make him do something completely irrelevant. It is a Remote Command Execution I tell you!

 

Application to Dating

Now that I have convinced you that people have vulnerabilities that can be exploited, just like computers, let’s move on to the main topic. Dating, of course!

So, for over a year now, I have the strange feeling, that dating resembles Pentesting a lot. Not offensively, at the bottom line, a white pentest is performed to make an infrastructure better. But in its “phases”, and general ways. Let me explain:

Pentest in a nutshell, in another nutshell

A pentest generally can be broken in 3 phases:

  1. Reconnaissance and general information gathering
  2. Vulnerability Scanning
  3. Exploitation of the target

(Reporting is a nightmare, I won’t mention reporting)

At first we have the target. We know nothing about it, we gather info. Hence “phase 1”. Secondly, we try to deduct possible vulnerabilities from the gathered information, while also searching for ways to use them. Thats “phase 2”. At last, we use our knowledge of the target to exploit it and make it do things for us, if we are blackhats, or report the vulnerabilities, if we are whitehats, so they can be acknowledged and hopefully fixed…

Quite straightforward. Moving on…

 

 But this is exactly like Dating!

And by “dating” I mean the whole process from single to couple. And it is engaged both sides.

At first we need a target: “That waitress at the cafe. She looked at me, the other day, like… like I don’t know… I like her…”. Mission accomplished! Phase 0 passed!

Phase 1, Information Gathering

  • “So you work here!” (well, duh!)
  • “Aha, a student job, just to pay the rent” (See lives alone, I ‘m gonna cry out of joy!)
  • “So, what’s your name?” (that’s uncommon, see must be from a village or something…)
  • “You chose to study the queen of all sciences!” (Studying maths? see must be a weirdo!)
  • “A quote from Shakespeare was that?” (She is a weirdo for sure!)
  • “And you came in this town to study?” (cross checked, she isn’t from here)
  • “Oh, do you go to this bar a lot? I used to like this place too!” (Now I know where I could find her alone and off her duty…)
  • “You are planning Master Degree on Cryptology? Really?” (Fine, you really got me now! End of conversation, we have a winner)

This is it! We know she is a student, she lives in town, away from parents and home. She mentioned nothing about “friends” or “boyfriends” that is a good sign too. She likes literature and maths. Specifically crypto.

We’ ll see if we can impress her with Information Security geek stuff. Say, the Turing Completeness of the “Ret to LibC” Buffer Overflow or something… Or she could finally explain to me how this fucking AES works… If she knows… Now that I am thinking of it, no person I know can explain this algorithm. Is anybody in the world capable of explaining how this mess works? Sometimes I believe that none is really sure about it. Maybe AES is a big -more like huge- scam. We can’t even tell. Who knows… Lost in my thoughts again! Moving on…

 

Phase 2, Vulnerability Scanning

*lounge music plays*

Phase 2 is the first date! Discovering each other “Achilles heels” and such happy stuff.

  • “I was with that guy who told me that he didn’t like my hair color, after 2 years. But I had the same hair all along, how did he notice that after 2 years?”
  • “My father left us when I was 8. He moved to Australia and I haven’t seen him since.”
  • “My dog died last week. He was really old, it is alright. But he reminded me that I am gonna die sometime too…”
  • “I caught him with my best friend […] felt so stupid.”

Here are some sample phrases of first date conversations. And conversation is another word for “Active vulnerability scanning” in this case!

Oh, and to be fair: All of this is happening with no evil intentions. Just plain conversation brings up bad situations we have lived, that we want to share, because we want to get the other person to know us better. We want to get closer, and this is the way. Two people talking about their lives. And 2 daemon correlation engine processes running like crazy with nice -20

 

Phase 3 …

Now we are ready for the exploitation! We know the other’s holes. We just need to fill them. Because this is what relations are all about. IMHO at least. Filling holes, outcasting fears. Patching vulnerabilities. And here is were this theory really shines!

This phase is different for whitehats and blackhats. And the difference is that blackhats will use the vulnerabilities for their purposes, while whitehats will use them to explore further and find as many of them as possible for fixing. For making the system overally better.

And there are blackhat people…

Let’s use the example with the ‘hair color’, quoted above, just for a Proof of Concept! It is obvious that the woman that said that has trouble with it. We can be sure that she doesn’t want to happen again. She maybe tries to avoid it. (We could be talking about this girl in the movie with Jim Carrey…). What would be more valuable to her than just a remark like “Your hair is great!, Don’t touch them again! Love them, no bullshit!”? She could do a lot of things to hear that remark. Did you catch it? Did it slip away? Here goes again:

She could do a lot of things to hear that remark.

Boom! We got a PoC exploit… It is an old CVE though… “Woman appearance” vulnerabilities are old as dust… They are like SQL injections or something… Common at best. And source of all evil…

So blackhats can manipulate this person in a way, make it chase its tail for some sweet words. Again, there are such people.

But what would whitehats do?

Whitehats get there and give away the vulnerability. They don’t care to “have access” to the system afterwards. Nor any way of “Simon says” backdoor. They have no way to fix those issues (the system owner is responsible for the patching), but they are useful on finding them. Their purpose ends on that. And it is really fun doing it too. It is solely based on human communication, maybe the best thing on earth!

 

Over and out.

maybe next time I ‘ll parallelize a break-up with an Incident Response. I’ll sleep on it…