Announcement

Collapse
No announcement yet.

Black Ops Requests?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • HighDr3Drifter
    replied
    Originally posted by 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.
    dan you ever figure out exactly what you would be going over?

    dre

    Leave a comment:


  • Effugas
    replied
    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.

    Leave a comment:


  • hackajar
    replied
    Originally posted by TheCotMan
    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!

    Leave a comment:


  • TheCotMan
    replied
    Originally posted by 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 ;)
    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.

    Originally posted by hackajar
    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)

    Leave a comment:


  • hackajar
    replied
    Originally posted by Effugas
    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?

    Leave a comment:


  • Effugas
    replied
    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 ;)

    Leave a comment:


  • TheCotMan
    replied
    Originally posted by Effugas
    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?

    Leave a comment:


  • Effugas
    replied
    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...

    Leave a comment:


  • TheCotMan
    replied
    Originally posted by hackajar
    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.

    Leave a comment:


  • hackajar
    replied
    Originally posted by Effugas
    The game gets interesting dealing with high bandwidth channels, which was why I built the video over DNS code.
    has this been released yet?

    Leave a comment:


  • Effugas
    replied
    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.

    Leave a comment:


  • hackajar
    replied
    Originally posted by TheCotMan
    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

    Leave a comment:


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

    Originally posted by 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.
    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.
    Last edited by TheCotMan; June 21, 2005, 01:07. Reason: fix typos and brain-farts, added content in []

    Leave a comment:


  • hackajar
    replied
    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.

    Leave a comment:


  • Effugas
    replied
    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

    Leave a comment:

Working...
X