Covert Channels
A brain.
?+++++++++++++++++++++++++++++++++++++++++++++++?
]|[ [-=- SOLDIERX.COM Presents -=-] ]|[
+++++++++++++++?+++_________________________________________+++?+++++++++++++++
\\//////////////// Covert Channels \\\\\\\\\\\\\\\\//
\\\\\\\\\\\\\\\\\_________________________________________/////////////////
\\:::::::::::::::::::::::::::::::: by ::::::::::::::::::::::::::::::::://
\\xxxxxxxxxxxxxxxxxxxxxxxx?-=-][-Kayin-][-=-?xxxxxxxxxxxxxxxxxxxxxxxx//
\\:::::::::::::::::::::::::::::: of ::::::::::::::::::::::::::::::://
\\ SOLDIERX.COM //
\\ October, 2008 //
\\ NOBODY CAN STOP INFORMATION INSEMINATION //
?=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++=?
**********************************************************************
| The author hereby grants permission to reproduce, redistribute, |
| or include this file in your file section, electronic or print |
| newletter, or any other form of transmission that you choose, as |
| long as it is kept intact and whole, with no ommissions, delet- |
| ions, or changes. (C)2008 SOLDIERX.COM - http://www.soldierx.com |
| E-mail [email protected] |
**********************************************************************
Introduction
------------
Security. We all know what "security" entails. But to design a "secure" system,
whether that be an application, a process, a phone line, or even a door locking
system, is a huge resource consuming task that is inevitably doomed from the
beginning.
Security these days is even measured in an ambiguous "better than the other
choice" manner. It's sad really, there's no scale, no proofs, indeed nothing
definite or concrete about it. We simply accept that a this "thing" is secure.
I mean who would want to read my boring e-mail anyway right?
When I read things like the above, I tend to laugh. Sometimes "good enough"
is really "good enough". It's easy to say my server won't get owned when it's
a locked down, minimal app, OpenBSD box with a 28 character user password that
spans 3 character alphabets, sitting behind a firewall that denys all but a
single VPN connection inbound. Isn't it?
Well, today I'm going to describe a method that is often forgotten, ignored,
or just plain never realized by a vast majority of admins that could completely
bypass the security described above depending on your purpose.
They're called covert channels.
What is a Covert Channel?
--------------------------
Imagine you're a scout for an army back in the late 1300s. You've been captured
by the enemy and taken to their great fortress rumored to be impenetrable. There
you've been tossed into a dungeon with no conceivable way of escape. During your
imprisonment, your army shows up and blockades the fortress. You know that any
attempt to siege the fortress is suicide and that your only chance for escape is
the victory of your army. You have one hope - on your trip into the fortress you
noticed a weakness in the fortress, a weakness that if exploited could lead to
victory for your army.
You can't communicate this weakness to the outside. You can't communicate with
anyone. You're locked down with no permissions. What do you do?
Lets say for the sake of argument that your cell has a window and you have the
means to make fire. You could send smoke signals to your army. If the window was
facing the army and the sun, you could use reflective material to reflect a
medieval equivalent of morse code. If you had a big stick and your cell had
iron bars you could strike the iron hard enough to echo a sound pattern to the
army. All of these methods are known as covert channels.
Formally speaking, a covert channel is nothing more than a shared medium of at
least 2 parties that can be used to transmit information.
They represent the true essence of hacking. Use a tool or a mechanism in a way
that has not been thought of to access information that you may not normally
be able to. It requires the use of your mind. It's pure, it's elegant, and
it's damn near unstoppable.
Shared Mediums
-------------
All communication, whether it be a human talking to a computer, two humans
talking, a human an alien and a computer, or just two computers, is done using
some common medium.
Two phones communicate through a phone line. Two people talk through sight or
sound. Two computers normally communicate through network medium like wireless
or ethernet. Two processes on a computer can talk through a socket or a pipe.
Covert channels are simply shared mediums that allow two parties to communicate
when they're normally not supposed to.
If you think about it, there are hundreds of these in computers. Some of them
can pose major security threats if exploited properly. Consider the following:
- CPU is shared by all processes assuming there is only 1 of them in the
system.
- Network Bandwidth / Connection
- Physical Memory
- Files
- Printer or any other peripheral.
Really any shared resource can be used as a shred medium in a computer.
Exploit Scenarios
-----------------
So how do we use any of this?
Consider a typical annoyance in the computer world. You're a user and you want
to print something for a meeting in 10 minutes. 15 minutes roll by and you
still don't have your document because some jackass graphic designer is printing
a 20' Sponge Bob poster for his son and he's doing it one 8" page at a time.
This is known as "starvation" in computer terms, more specifically, when one
process hogs the processor and effectively starves the other process out being
able to work. In the office, this is known as "being a dick".
Basic Printer Scenario
----------------------
Let's turn this into a covert channel. I'm going to write a "sender" program
that is going to send the message "Hello" to a "receiver" one bit at a time by
hogging the printer resource. Assume for argument's sake that the printer has
no buffer.
Assume hogging the printer for 1 second is a 1, and not hogging the printer at
all is a 0.
The receiver program simply needs to print test pages in a uniform manner. Let's
say consecutively with no breaks.
The sender program will print a page when it wants to send a 1, and not print a
page when it wants to send a 0.
Now all that's left is synchronization. Well we have existing network protocols
that can synchronize 2 processes. I won't go into detail on those, see the RFCs
if you want that information.
The sender will begin by requesting a print 1 microsecond before the receiver.
The receiver will then try to print and realize it can't. It will log that as a 1.
etc...
What if an actual person legitimately tries to use the printer? Well this is the
same scenario as packet conflict over a network. We have error checking protocols
for network communication already. Sticking a CRC Checksum on the end of the
message is not difficult to ensure the message is correct.
You can begin to see how simple these are to program. The printer example may
not be a good medium to communicate over because it is used frequently. This is
no different than a busy ethernet link or a wireless connection that experiences
a lot of interference. A CPU may be used more efficiently due to the fact that
you can do a lot, much faster, over a shorter period of time on them.
Footprinting - Determine OS Scenario
------------------------------------
Covert channels are used quite often but rarely understood that they are in
fact covert channels. This is common in footprinting - the process of gathering
information about a computer.
Take the TCP Handshake for example.
Client Server SYN -> <- SYN / ACK ACK ->
This communication, by protocol definition, uses sequence numbers to ensure
that packets are sent and received properly. I'm not going to get into where
sequence numbers originate, but everyone uses them.
In the TCP Handshake it looks kind of like this:
Client: SYN (seq#A) ->
<-SYN/ACK (seq#A +1, seq#B) : Server
Client: ACK (seq#B +1, seq#A +1)
Certain Operating systems would use the same sequence numbers on SYN/ACK of
the handshake. You could use this information to determine which OS the server
is running. OS often is very useful information to have.
(Note: To solve this problem, OS's started randomizing their sequence numbers)
Conclusion
----------
You may have started to notice that covert channels are not "exploit in a can".
They half require some kind of administrative access. It's important to remember
that covert channels are just channels of communication. They're useful when you
have something already in a sensitive area and want to communicate with it
secretly.
They can be used to bypass communication restrictions, talk secretly when being
monitored, and - if created very carefully - listen to information being
transmitted accidentally.
It is theoretically possible to determine what a processor is processing based
on how long it takes to compute something and how it affects its memory. Although
actually writing something to do this would be extraordinarily difficult.
The major advantage to covert channels is that nobody thinks about shared resources
when creating "secure" systems. This is in inherent vulnerability.
Another good example
--------------------
If I have a trojan or rootkit on your system, I could still give it commands
regardless if you restricted it using a firewall. I could build it to listen to
bandwidth levels and then just DOS you in a set pattern that the server
understands.
Your own creativity is really the only limitation with these. Use your
imagination. Have fun. Break something (that you're allowed to break). Play with
your balls a little and see what you come up with. You'll do fine.
Rough Proof of Concept Code
---------------------------
Below is something I coded up quick a few months ago to prove to myself that it
was possible to communicate through the processor.
This code assumes only 1 core. I tested it on a quad core by simply running 4
instances and it did work, though messy.
Note: This is written in C.
Client
-------------------------------------------------------------------------------
#include <stdio.h>
#include <sys/types.h>
#include <time.h>
/* Prototypes for functions to use the covert channel */
int getBit(int ref);
int getRefTime();
int main(int argc, char *argv[]) {
/* We need to get a reference time. */
/* Multiply by 1.25 to prevent accidental 1s.*/
int refTime = getRefTime() * 1.25;
/* Just read constantly, this will fight for the processor*/
while(1) {
fprintf(stdout, "%d\n", getBit(refTime));
}
return 0;
}
/* Getting a bit is simple, run a long loop and see how long it took to process
in processor time. No its not exact but this is just a proof of concept */
int getBit(int ref) {
int start, end, i;
start = clock();
for(i=0; i<1000000000; i++){}
end = clock();
if( (end-start) > ref)
return 1;
else
return 0;
}
/* This will get a reference time so we can determine busy or slow */
int getRefTime() {
int start, end, i;
start = clock();
for(i = 0; i<1000000000; i++){}
end = clock();
return end-start;
}
Server
-------------------------------------------------------------------------------
#include <stdio.h>
#include <sys/types.h>
#include <time.h>
#include <unistd.h>
/* Prototypes for functions to use the covert channel */
void send1Bit();
void send0Bit();
int main(int argc, char *argv[]) {
/* Just send every other bit */
while(1) {
send1Bit();
send0Bit();
}
return 0;
}
/* Send a 1 bit by doing math in a long loop */
void send1Bit() {
int x = 1;
int i;
//This takes approximately 3 seconds to run, depending on processor
for(i=0; i<2000000000; i++) {
x += x * 3;
}
}
/* Send a 0 bit by doing nothing for 3 seconds */
void send0Bit() {
sleep(3);
}
-K
_____________________________________________________________________
?=------------------------------]-?-[------------------------------=?
\\ THIS FILE WAS A SOLDIERX PRODUCTION //
\\ http://www.soldierx.com //
\\ NOBODY CAN STOP INFORMATION INSEMINATION //
?=+++++++++++++++++++++++++++++++++++++++++++++++++++++++++=?