Announcement

Collapse
No announcement yet.

Black Ops Requests?

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

  • Black Ops Requests?

    Heh all, this is Dan Kaminsky. I'm working on the 2005 material right now, and while I'm neck-deep in API stuff...any requests? In general, I always get really cool feedback from you guys after my talks, so it'd be kinda neat if I got some interesting suggestions that led directly to amusing code. Stuff I'm working on now...umm, lesse...graphical scanrand, reliable / non-network-overloading scanning, much (much) better DNS code, MD5 stunts...but feel free to suggest anything.

  • #2
    Change the digital marquee on the Hard Rock?
    Nonnumquam cupido magnas partes Interretis vincendi me corripit

    Comment


    • #3
      Originally posted by erehwon
      Change the digital marquee on the Hard Rock?
      Even better.. Freemont St.
      Happiness is a belt-fed weapon.

      Comment


      • #4
        Originally posted by Effugas
        feel free to suggest anything.
        New techniques on blind sequence guessing and effectiveness per OS (?)
        Advanced network attacks to cause automatic filter rules to impose remote self-DoS (?)
        Multiple TCP windows (supported on both ends) with overlapping sequence/acknoledgement numbers in the same window and how effective they are at hiding true, desired session content from modern [stateful] filters and user profiling devices (?)
        Any new "tricks" with packet fragmentation and IPv4 (?)

        Comment


        • #5
          Originally posted by TheCotMan
          Multiple TCP windows (supported on both ends) with overlapping sequence/acknoledgement numbers in the same window and how effective they are at hiding true, desired session content from modern [stateful] filters and user profiling devices (?)
          I'm just curious where you came up with that. I'm not entirely sure what you are getting at, but that doesn't seem possible with TCP...

          I was going to suggest something mundane (sniffing packets through a switch) since it seems right up Dan's alley and the subject has always fascinated me. However, this is a well-studied problem, and I don't think it likely that we are going to see any more breakthroughs.

          Comment


          • #6
            Originally posted by Voltage Spike
            I'm just curious where you came up with that. I'm not entirely sure what you are getting at, but that doesn't seem possible with TCP...
            It is a violation of the RFC, and this is why support would be needed on each end supporting such a session. It is not my idea, and has been discussed as a method to avoid session capture by some devices that capture only the first TCP packet in a session with a sequence number, but not successive ones (even if the payload and checksum changes.) The idea of overlapping sequence ranges in the same window is just a ++ to the original concept, and this too is not my idea.

            This, as a technique was "known" a few years back, but I did not hear much on its development, or countermeasures in COTS devices for user profiling (like seeing what pictures are being FTPed from a server.) (First time I heard about it was at DefCon in a conversation with someone.)

            It is also "insecurity by obscurity" and could technically be checked as well.;the question is, "is it being checked and how well?"

            I was going to suggest something mundane (sniffing packets through a switch) since it seems right up Dan's alley and the subject has always fascinated me. However, this is a well-studied problem, and I don't think it likely that we are going to see any more breakthroughs.
            Sniffing packets with a layer 2 switch is covered in a number of docs and howto on using various sniffing tools. It could also be a good presentation too.
            The most reliable? Set a switch port to "monitor" or "admin" or "mirror" (or other names that differ by vendor) for the purpose of hooking up a packet analyzer. ]:>
            Active attack methods for sniffing "not-your" traffic on a layer 2 switch exist, and there are countermeasures for many of these on some switches.

            Anyway, all of the ideas suggested are meant to encourage other ideas, and maybe cause some people to create new ones as suggestions.

            Comment


            • #7
              Arp-poisoing and the huge scary problem of insecurity of switches I think is largely unknown by many, even people claming to know some network 'security', while bringing this to the surface in a scary and very public way might help the security of some networks and admins out there.... its already been there and done that.
              (although not on a "kaminsky" level).

              I guess my vote would be first of all... protocol level stuff is fun.
              Second, as cool as it would be to have 'old dogs learn new tricks' and knowing you blew the top off DNS.... repeating that I can imagine is very hard. You've gotta think of something that nobody's thought of before, something in SMTP, or SNMP maybe...
              I guess try to take something we all use so much.... and take it to a "kaminsky" level. (I remember last year there was a good talk "When the tables turn" by somebody with an S and his friend... where they tricked a traceroute, sent back false data that made it look like they were tracing to the 'white house'... that kinda stuff I guess, that was an excellent talk, as are yours. )

              (Ps. I'd rather see no GUI on scanrand , just more paketto(ish) stuff and better options control).

              (and for my third wish.... I wish for more wishes!)
              The only constant in the universe is change itself

              Comment


              • #8
                Interesting stuff...glad I put out the request. Lets see what I can say about what we've got so far:

                1) Sniffing on a switch -- last I checked, overflowing the CAM table (port/MAC mapping) causes most devices to have to flood frames out to each port. Sometimes the device will stay in flood mode until the CAM entries expire, but generally they'll populate the CAM table FIFO style meaning that the moment the legitimate port replies to the flooded unicast packet, future packets won't get flooded. As an attacker, though, you now discover MAC and IP information for whatever network you're on, since you pick up at least one packet per neighbor.

                I think Ettercap has this domain pretty well sealed up, though...

                2) Actually implementing Auto-DoS. That's interesting...what can we do to cause IPS's to go nuclear? That's a really neat idea.

                3) TCP Windows -- turns out there's at least one trojan in the wild that send their payloads out-of-window piggybacked on existing sessions. This is done because such packets are by their nature specified to escape the corporate firewall, while most such boxes don't pay too close attention to windows. Hmm. There's actually some interesting stuff that can be done here...

                4) Packet fragmentation -- hmmm...maybe some new evasion mechanisms? Got anything else in mind?

                One thing I'm definitely doing is exploring just how responsive the backbone, and your average corporate network, remains to LSRR and IP Timestamps. IP Options are fun :)

                Keep up the ideas. :)

                Comment


                • #9
                  Different kind of graphical scanrand
                  You hit the nail on the head -- nothing quite as wide open as DNS...the bar's getting raised, but I've never been one to step away from the bar...
                  Last edited by AlxRogan; June 3, 2005, 15:03.

                  Comment


                  • #10
                    Originally posted by Effugas

                    overflowing the CAM table causes most devices to have to flood frames out to each port.
                    Most devices? Maybe a while ago, but I tried this on a home netgear switch, and cisco switch, both survived massive CAM table flooding... (i don't remember the tool). Maybe because they have a limit on the amout of MAC's per port per x time?
                    Originally posted by Effugas
                    2) Actually implementing Auto-DoS. That's interesting...what can we do to cause IPS's to go nuclear? That's a really neat idea.
                    Seems to me that you could adapt some current methods of DoS attacks on IDS systems to an IPS... but the trick would be to do this, without the device 'preventing' you. An attack like snortsnarf would probably not work, so its an intresting challenge.
                    Hopefully most people have bluelisted the good stuff.... (ie, spoof something usefull to the IPS and let it block itself). You'd have to look at the methods of blocking, and application security... (kinda like ethereal protocol disector X11 vulns, or rumored snort vulns by viewing a special packet)....
                    Seems intresting and vaild enough for some investigation...

                    http://www.doxpara.com/lfl_v1/ Now I understand..... Looks great! Does that use the same QVIS or whatever 3d plotting program like phentropy? What is your goal for the graphcial aspect?
                    The only constant in the universe is change itself

                    Comment


                    • #11
                      There was this crazy idea of "storing data in bandwidth" where data gets "bounced" back and forth in backbone tunnels as a means of storage.

                      It would be interesting to use this theory to create backpressure/buffer of data, and when enough "rouge stored packets" are in this buffer, send a signal to release them on one host, this would assist greatly in a DoS attack, and help preserve anonymity if done right just a thought...
                      "Never Underestimate the Power of Stupid People in Large Groups"

                      Comment


                      • #12
                        Originally posted by dYn4mic
                        Seems to me that you could adapt some current methods of DoS attacks on IDS systems to an IPS... but the trick would be to do this, without the device 'preventing' you. An attack like snortsnarf would probably not work, so its an intresting challenge.
                        Hopefully most people have bluelisted the good stuff.... (ie, spoof something usefull to the IPS and let it block itself). You'd have to look at the methods of blocking, and application security... (kinda like ethereal protocol disector X11 vulns, or rumored snort vulns by viewing a special packet)....
                        Seems intresting and vaild enough for some investigation...
                        Snort (older versions) has a vul to malformed TCP packets, where you set to oposite flags (I think it was push/rst combo) and send to known host on other side of snort. This would kill snort if running in background mode. Google "angledust" for more precise details.

                        If you really want to DoS or take out an IDS/IPS the best thing to look at is libPCap and libNIDS. These are the foundation lib's for 90% of OpenSource (and not) devices out there. If you could find exploits here, you "Would have one ring to rule them all" - OK cheese, but you get the idea.
                        "Never Underestimate the Power of Stupid People in Large Groups"

                        Comment


                        • #13
                          Originally posted by Effugas
                          Different kind of graphical scanrand

                          You hit the nail on the head -- nothing quite as wide open as DNS...the bar's getting raised, but I've never been one to step away from the bar...
                          I see the DNS issue as something that might have a solution for many networks: Block all incoming/outgoing UDP/53 except from your own DNS Servers. Have those DNS Servers provide full resolution for all queries and give back to the client requesting the final answer.

                          Second, profiling of port use per user to find excessive traffic for DNS is available to identify potential abusers who have set up "special" DNS outside the network.

                          You see any countermeasures to these two when used together? If so, another suggestion for a topic. :-) If not, how long before these two become the new standard?

                          4) Packet fragmentation -- hmmm...maybe some new evasion mechanisms? Got anything else in mind?
                          As a variation on the duplicated sequence number for passing data, or for other purposes which may be new. (I have not been keeping up with this lately.) Consider the "ancient" rash of attacks as DoS that used oversized/invalid/undersized packets after defragmentation on the receiving host, and poorly written TCP/IP stacks.

                          Comment


                          • #14
                            Originally posted by TheCotMan
                            I see the DNS issue as something that might have a solution for many networks: Block all incoming/outgoing UDP/53 except from your own DNS Servers. Have those DNS Servers provide full resolution for all queries and give back to the client requesting the final answer.
                            This will still not protect against OzyMan

                            I'll give you a hint: DNS TXT records are supposedly deprecated, so they really should not show up on your network.
                            "Never Underestimate the Power of Stupid People in Large Groups"

                            Comment


                            • #15
                              Originally posted by hackajar
                              Snort (older versions) has a vul to malformed TCP packets, where you set to oposite flags (I think it was push/rst combo) and send to known host on other side of snort. This would kill snort if running in background mode. Google "angledust" for more precise details.

                              If you really want to DoS or take out an IDS/IPS the best thing to look at is libPCap and libNIDS. These are the foundation lib's for 90% of OpenSource (and not) devices out there. If you could find exploits here, you "Would have one ring to rule them all" - OK cheese, but you get the idea.
                              Thanks for the info, somehow I knew there would be an answer here. heh.
                              But I'm not looking to DoS anything, if need be, hopefully its seen as a last resort, or most effective if your not looking for a challenge. (or one of these so called 'cyberterrorists' heh).But I've gotta give some 'props' to Libpcap, it has so much potential, and use today... (Maybe a talk on lib's like these (pcap, nids, dnet, etc) and their limitations/strenghts someday?)
                              The only constant in the universe is change itself

                              Comment

                              Working...
                              X