Black Ops Requests?

[TheCotMan]

Cat--

heh-heh, Hrm. I am Cot ;-)

Ah, the pain of the white hat...

Here, on the forums, I am not a white hat, grey hat, or black hat, and I usually avoid running RedHat, but I have been known to act like an asshat. 0:-)

just when you find a new toy, you go ahead and kill it...

Naw, I did not kill it-- Things like this generally don't die. They can take another direction. :-)

Many of your techniques could be used with HTTP and HTTPS to provide covert channels through RFC, and W3C compliant content. A combination of multiple protocols can be used to load balance virtual covert channels over multiple ports/services, and who cares about ordering if your tunnel relies upon TCP and windows (code reuse.) Combined with your DNS work, you could create a multi-headed beast that will use whatever services and protocols available to communicate in a covert channel-- and by spreading the load across multiple services, you avoid detection by some of the heuristics mentioned, and have something that is more fault tolerant and reliable. (Borrowing techniques from Radio: spread spectrum? (multiple ports load balancing), frequency hopping (randomization of port selection fo data.)

Maybe one hack would allow traffic out, and another would allow traffic in, split the IO.

You could even go further and use variations to the dual-window TCP item, and have special web servers provide two images (one which is the "normal" image, and the other which contains some steganographic information) in order to pass even more information in secondary or tertiary covert channels.

HTTP or HTTPS are *perfect* candidates for applying your techniques. Images and videos use up tons of throughput and make it easier to hide needles in haystacks. (Consider Server Push and Client Pull, and more.) DNS traffic is usually fairly low per desktop host unless you have users doing zone transfers or processing reports (like web logs) with rDNS. It is too easy for even a little traffic to provide a spike and draw attention. DNS is not a bad choice at all-- it is very good due to many of the reasons you have mentioned WRT filters.

I'm enjoying this collaboration greatly.

I am glad you chose to stop by again. This is a very good conversation. :-) There are people here who I respect for their knowledge, or how they act or how they are direct with their ideas.

You'll definitely be getting alpha code from me. Regarding topic selection -- I don't think I'm doing a single topic talk this year, so once again I'll be coding things up until the night before the Black Hat talk :)

Heh. Getting alpha code and having time to look at alpha code are two different things.
Thanks. :-)

[Effugas]

Cot(my apologies)--

Yes, I'm well aware that multitunnel code is very, very feasible. The video over DNS code basically abstracts out reliability from transport, so it's feasible to have some packets go over DNS, some over AOL, some over SMTP, and so on.

I don't think there's really a way to have an interactive tunnel that doesn't raise eyebrows, unless you get black-hat enough to have something like an internal botnet that, as a group, passively identifies potential channels across the entire infected base and piggybacks on whatever's already happening (so, for example, users with AIM would add an AOL transport to the group).

I may put together the multitunnel code, just because it's mostly already there. I don't plan to do this aggregative attack, though.

I stopped by here because I figured I'd find people who knew what kinda stuff I liked to play with. I was right.

--Dan

[hackajar]

I always thought 443 was a good port to use for outbound transmission. People expect it to be encrypted, so attention to it's contents are limit.

It also provides covert operation, because the traffic basline of that port is relitivly high.

It would be cute to accually use SSL CA's in a tool that sent data out, so the traffic would look ligit as well.

At this point in the game I don't think any network connected to the Internet would be immune to disolving of perimeters from the inside, especially with poorly implimented (or designed) protocols running the Internet. Who knows, maybe IPv6 and associated protocols may change this in the future.

[TheCotMan]

I've been thinking about this a bit more, and have some replies to these.

I always thought 443 was a good port to use for outbound transmission. People expect it to be encrypted, so attention to it's contents are limit.

It also provides covert operation, because the traffic basline of that port is relitivly high.

It would be cute to accually use SSL CA's in a tool that sent data out, so the traffic would look ligit as well.

Yes, port 443 would be good, but SSL can be identified as ssl vs. ssh through how the protocol initially works/starts. Though ssh over port 443 would probably be detected, use of stunnel over ssl could be more difficult to detect through SSL protocol violations/inconsistences.

Use of CA is also a problem, as heuristics could also be used. Anyone D/L-ing more than a few CA per day would seem out of the ordinary and trackable. Also, I'd need to check, but I think CA are generally not downloaded over 443, because they are sort-of-needed before the encrypted conversation is "trusted." Port 80 and a W3C HTML version compliant document could pass much more traffic, and images could also use steganography for heavier bandwidth requirements.

At this point in the game I don't think any network connected to the Internet would be immune to disolving of perimeters from the inside, especially with poorly implimented (or designed) protocols running the Internet. Who knows, maybe IPv6 and associated protocols may change this in the future.

I've thought about this more, and I suspect that so long as people inside a network have access to request data and send data on a machine they control, there will always be a way to hide outgoing and incoming data from the network admins.

The only question becomes one of how much data can be passed and still remain hidden.

Simple example? [This is only one example of how it could work, not necessarily how it has worked.]
[Assume a] CIA agent was recently convinced to work for our government. Their job is to find evidence we desire. Once they have the evidence, they are to let us know they are ready for extraction, but all communications are monitored and encryption raises alarms. The agent knows to visit a website with a URL like:
http://www.fakeCIAcompany.com/path/to/file
If that path is not published or linked and is even a 404, then all the company people need to do is look for any attempt to access that file in their logs. When it is accessed, [the company may assumethe agent has] the information needed pby the company] and extraction [of the agent] may begin.
Getting data to the client is also possible. If web browsing is allowed, the agent could have a single-use vernam-like datasheet that is easy to remember in order to pick out numbered words from a web text to read a secret message hidden in regular content.

Works with nearly any media/protocol if the user has access to send or receive.

[Such systems are even easier to hide if they are included as media/acces that is part of the normal activity of the user-- even heuristics can fail to detect such things per user, or in one user vs. a whole group.]

Again, once it is shown to be possible, it is only a matter of throughput.

[hackajar]

CIA agent was recently convinced to work for our government. Their job is to find evidence we desire. Once they have the evidence, they are to let us know they are ready for extraction, but all communications are monitored and encryption raises alarms. The agent knows to visit a website with a URL like:
http://www.fakeCIAcompany.com/path/to/file
If that path is not published or linked and is even a 404, then all the company people need to do is look for any attempt to access that file in their logs. When it is accessed, they have the information they need from the agent and extraction may begin.

holy shitbags! I never really concidered that! Way to go gringo!

I was at SANSFire all last week, and covert channels was all the rage. The end result of all conversations was "Just try your hardest to mitigate all the obvious vectors, and path un-obviouse ones as they arise (aka, come to your attention, tool created to mitigate, etc)"

This is some pretty havy stuff, if I may say so myself

[Effugas]

There's a quote in the intelligence world, "You can always send a bit." There's just too much entropy in the real world for single bits not to be transmittable. For instance, you can send bits of data by the number of seconds between Google queries.

The game gets interesting dealing with high bandwidth channels, which was why I built the video over DNS code.

[hackajar]

The game gets interesting dealing with high bandwidth channels, which was why I built the video over DNS code.

has this been released yet?

[TheCotMan]

holy shitbags!

Heh. I can't take credit for it; it is not a new idea. "One if by land, two if by sea." Another? Consider the fires used to pass signals in China and the roman empire to send just a single bit of data, "we are under attack" or "war has begun".

The only thing that is different is the media. :-)

There's just too much entropy in the real world for single bits not to be transmittable.

Yep. Retransmission of previously accepted packets in a TCP window with purposeful errors included to allow XOR with good packet previously received in order to pull out information.
Timing is another one that you mention.
Cyclic and predictable behavior with skipping. Agent always visits a certain site each morning, when they stop, they are dead, or captured, or something else.
Sending two e-mails instead of one.
Playing the role of a spammer in a "free country" and sending spam to many targets in addition to your insider. (What better place to hide data than something that looks like spam?)

Many ways to hide data.

Attacker has the advantage so long as there is enough time an no need to be too "bursty" with traffic.

[Effugas]

Apparently the SPAM channel you describe is actually used to release lists of proxy servers. There was a talk at BH last year that actually traced some SPAM Stego back to the filipino high school crew it was originating from.

That's an interesting point you bring up -- two completely random datasets can be emitted, with no preshared key save for the alignment strategy (XOR, one is the aes key for the other, etc). Hmm.

Paper that'll mess with your head: http://www.cs.may.ie/~tnaughton/pubs...to/NJ2004p.pdf

Code is being rewritten for BH2K5. Present version stuck on a hard drive a few thousand miles away...damn elbow break...

[TheCotMan]

Paper that'll mess with your head: http://www.cs.may.ie/~tnaughton/pubs...to/NJ2004p.pdf

I'll check it out later.
...

Code is being rewritten for BH2K5. Present version stuck on a hard drive a few thousand miles away...damn elbow break...

How did you break your elbow? Primary arm/hand? (left if left handed, etc,)
Surgery required? Cast? Time for removal?

[Effugas]

Figured I'd go for a quick jog before coding all weekend. Made it about five feet at the door before my left foot flew out from under me. Four point shatter in my non-dominant elbow...its killed about ten dev days pre defcon. So annoying, though I do get to make "Black Ops Of One Hand" jokes ;)

[hackajar]

So annoying, though I do get to make "Black Ops Of One Hand" jokes ;)

Ummm...Black Ops...One hand....I won't touch that with a 10...no 20ft pole....Or did I already?

[TheCotMan]

Figured I'd go for a quick jog before coding all weekend. Made it about five feet at the door before my left foot flew out from under me. Four point shatter in my non-dominant elbow...its killed about ten dev days pre defcon. So annoying, though I do get to make "Black Ops Of One Hand" jokes ;)

You could speak on the part of the TCP protocol that includes the Sliding Foot protocol and how dropping packets to the floor too quickly can cause a DoS in a host.
(Sorry, this is bad. Hopefully as bad as Hackajar's comment above, but in a different way.)

Seriously, hope you are not in pain, or are at least able to be functional with pain medication, and that you get healed up real soon.

Ummm...Black Ops...One hand....I won't touch that with a 10...no 20ft pole....Or did I already?

I'm wondering if a certain someone will join this conversation now... (heh-heh)

[hackajar]

You could speak on the part of the TCP protocol that includes the Sliding Foot protocol and how dropping packets to the floor too quickly can cause a DoS in a host.

Or make for a really great intro and excuse for the elbow. Hope your felling OK after the spill though D.

Do you suppose dropping packets too fast might be a ligitimate cause for at least slowing down a box (swapping memory) and really failing? That would be a wild concept I suppose. Image being on the receving end of an OC-48 with nothing more then a linksys SOHO router! That might do the trick!

[Effugas]

Sliding Foot protocol. That is so very wrong.

I'm OK. Sling comes off tommorow, I can type again, not *too* much swelling, etc. Finally able to code again, which just kicks ass.

Only embedded gear *really* gets flooded to death. Other things just flush queues, generally. But you know, there's some weird 802.3 extensions for flow control and such...should look into these.