Announcement

Collapse
No announcement yet.

Current Exploits

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

  • Current Exploits

    If you can't tell by the number of posts next to my name, I'm new to the defcon forums. I was just wondering if this was an appropriate forum for discussing unpatched exploits?

  • #2
    Originally posted by Mr. Peabody
    If you can't tell by the number of posts next to my name, I'm new to the defcon forums. I was just wondering if this was an appropriate forum for discussing unpatched exploits?

    How are you discussing them? In what context?

    Comment


    • #3
      Originally posted by Mr. Peabody
      If you can't tell by the number of posts next to my name, I'm new to the defcon forums. I was just wondering if this was an appropriate forum for discussing unpatched exploits?

      If you mean how you are dealing with them from a security standpoint then yes. If you mean, and judging from you other few posts I doubt this, "1 @m 50 1337 l00k a7 my ub3r 1337 z3r0 daz3" then no.
      perl -e 'print pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'

      Comment


      • #4
        Originally posted by Chris
        If you mean how you are dealing with them from a security standpoint then yes. If you mean, and judging from you other few posts I doubt this, "1 @m 50 1337 l00k a7 my ub3r 1337 z3r0 daz3" then no.
        I can barely even read what you typed there. I meant in more of a context of, is this a good forum to discuss the effect and remedy of the latest exploits, like the recently growing trend in kernel module exploitation available in linux and bsd flavors as well. Also, discussing "rumors" of new exploits that remain unaddressed by CERT, such as a third RPC exploit for Windows that was supposedly introduced back in December.
        Last edited by Mr. Peabody; February 4, 2004, 00:08.

        Comment


        • #5
          naw, we're all pretty dumb here.

          I return whatever i wish . Its called FREEDOWM OF RANDOMNESS IN A HECK . CLUSTERED DEFEATED CORn FORUM . Welcome to me

          Comment


          • #6
            It seems to be a fairly taboo subject to mention exploits that the public may not be aware of. Just wondering how welcome the exploit conversation is. It seems I have a good enough answer at this point, thanks Chris. Congrats on your 666th post noid. Glad I could help.

            Comment


            • #7
              I just noticed that..sweet..wait..i just fucked it up..

              I return whatever i wish . Its called FREEDOWM OF RANDOMNESS IN A HECK . CLUSTERED DEFEATED CORn FORUM . Welcome to me

              Comment


              • #8
                Originally posted by Mr. Peabody
                ...like the recently growing trend in kernel module exploitation available in linux and bsd flavors as well.
                What trend? Neither Linux nor *BSD has had a module loading vulnerability in recent history...
                45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
                45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
                [ redacted ]

                Comment


                • #9
                  Originally posted by bascule
                  What trend? Neither Linux nor *BSD has had a module loading vulnerability in recent history...
                  (Cut from december's security focus)

                  > > Such kind of kernel backdoors (e.g. loadable kernel modules) are also present for Solaris, *BSD and Windows systems. If you are unsure whether someone has compromised your system, don't trust the system's kernel!


                  /***********************************************
                  *
                  * Linux Kernel Module Loader Local R00t Exploit
                  * Up to 2.4.20
                  * By anonymous KuRaK
                  *
                  ************************************************

                  You sure this doesn't exist?

                  Comment


                  • #10
                    Oh, the ptrace vulnerabilities. I wasn't aware there was module loading involved as a part of the exploitation vector.

                    Well, what particularly did you want to discuss about them?
                    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B0
                    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B1
                    [ redacted ]

                    Comment


                    • #11
                      Originally posted by bascule
                      Oh, the ptrace vulnerabilities. I wasn't aware there was module loading involved as a part of the exploitation vector.

                      Well, what particularly did you want to discuss about them?
                      Nothing really, I was using familiar concepts to get an understanding of the ground rules and such. They were merely used as an example.

                      Comment


                      • #12
                        Originally posted by Mr. Peabody
                        Nothing really, I was using familiar concepts to get an understanding of the ground rules and such. They were merely used as an example.
                        I ran across an interesting article while surfing, on YIM vulnerabilities.

                        "...A number of significant potential security deficits remain undisclosed in advisories concerning YM is the distinct absence of encryption. Users may send sensitive data via messages or file transfers, both of which are routed across the Internet. This lack of encryption coupled with a lack of a secure layer within the YM protocol stack could be used by a third party to access supposedly secure communications. As already highlighted file transfers in YM reveal a users IP Address. If an attacker is able to persuade an unsuspecting user to send or receive a file, with a quick look in netstat the IP Address is revealed. Should the unsuspecting user be making use of a fixed IP, this could be very bad news indeed (either through direct hacking attempts, harassment or DoS attacks). Because YM sessions are based on clear text it is possible for a malicious user to perform a TCP hijack on an active/idle connection. Using this method it is possible for a suitably skilled computer user to impersonate a legitimate YM user to obtain sensitive data."

                        I read the article at www.hackwire.com
                        The author listed his source as www.iss.net
                        Last edited by Floydr47; February 8, 2004, 20:08.
                        I enjoy talking to myself...it's usually the only intelligent conversations I get to have.

                        Comment


                        • #13
                          Originally posted by Floydr47
                          I ran across an interesting article while surfing, on YIM vulnerabilities.

                          "...A number of significant potential security deficits remain undisclosed in advisories concerning YM is the distinct absence of encryption. Users may send sensitive data via messages or file transfers, both of which are routed across the Internet. This lack of encryption coupled with a lack of a secure layer within the YM protocol stack could be used by a third party to access supposedly secure communications. As already highlighted file transfers in YM reveal a users IP Address. If an attacker is able to persuade an unsuspecting user to send or receive a file, with a quick look in netstat the IP Address is revealed. Should the unsuspecting user be making use of a fixed IP, this could be very bad news indeed (either through direct hacking attempts, harassment or DoS attacks). Because YM sessions are based on clear text it is possible for a malicious user to perform a TCP hijack on an active/idle connection. Using this method it is possible for a suitably skilled computer user to impersonate a legitimate YM user to obtain sensitive data."

                          I read the article at www.hackwire.com
                          The author listed his source as www.iss.net

                          I really don't see how that is an exploit any more than sniffing telnet or ftp sessions are exploits. It's a clear text service...so is http, so is smtp. If you are sending anything sensitive without understanding that you need encryption you pretty much deserve what you get.
                          perl -e 'print pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'

                          Comment


                          • #14
                            i think that's going a little too far.
                            an end user who doesn't know email passwords are sent in clear text does not, i think, deserve to get his or her password intercepted and exploited.
                            - fhqwhgads

                            Comment


                            • #15
                              Originally posted by LiteHedded
                              i think that's going a little too far.
                              an end user who doesn't know email passwords are sent in clear text does not, i think, deserve to get his or her password intercepted and exploited.

                              And why don't they know?

                              Comment

                              Working...
                              X