Announcement

Collapse
No announcement yet.

Current Exploits

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

  • Zhym
    replied
    Sure, the Internet is a mess 'o plaintext. But ftp, telnet, and (to an extent) HTTP were all designed back in the Good Old Days when the Internet was just a bunch of universities that all knew each other, and security wasn't even an afterthought.

    Instant messaging doesn't get to use that excuse. Since, oh, 1998 or so it's inexcusable to design any Internet app without adequate security. Instead of asking why users don't know YIM is sent in the clear, I'd ask why YIM is so poorly designed that users would need to know this.

    Leave a comment:


  • bascule
    replied
    Originally posted by Mr. Peabody
    The problem is that everything installs itself without SSL support and too many people are idiots to install it all right.
    Most POP3 and IMAP daemons no longer support plaintext authentication by default, most notably UW IMAP, Dovecot, and Courier.

    Leave a comment:


  • Mr. Peabody
    replied
    The internet is a big wad of plain text. Email, Web, FTP... how many sites do you know that use SSL or even Secure Password Authentication? The problem is that everything installs itself without SSL support and too many people are idiots to install it all right. Public mail delivery server, private user mailbox server, SSL sessions... how hard is this? I didn't even have to setup a VPN!

    Sure encrypted communication is a bit slower, but I think we could all bear the slowdown if the web suddenly became a REAL private and secure place.


    -------------
    EVERYTHING SSL

    Leave a comment:


  • bascule
    replied
    Originally posted by highwizard
    And why don't they know?
    MUAs do a really lousy job of informing the user whether or not the authorization mechanism is *ugh* plaintext or rather one of the many cryptographically secure authorization mechanisms such as HMAC-MD5 or HMAC-SHA1 is being used. Nor do MUAs make it particularly easy to disable plaintext authorization.

    Of course the easiest way to ensure security is configure the entire session to operate over SSL...

    Leave a comment:


  • Floydr47
    replied
    Originally posted by highwizard
    And why don't they know?
    Because they haven't been taught and don't know the questions to ask. Computer Security is a relatively new field, not understood by all. Myself, I feel fortunate to have stumbled upon this forum by chance. I have learned, and continue to learn, things here that I would never learn from textbooks. With the recent viral attacks, (myDoom.A and B.), Odessa College computers were down for 2 days, because of the information that Qu|rk provided me, my pc at home has managed to elude any such problems. In short, people don't know because they haven't been provided the information. "Real world" is a constant learning experience.

    Q: How do you get the cat out?
    A: Send in the Pit Bull.

    ;)

    Leave a comment:


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

    Not big on understanding hyperbole huh?

    Leave a comment:


  • Qu|rk
    replied
    Originally posted by Floydr47
    "...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.
    There is not "distinct absence" as you state. Although the encryption is *very weak* (XOR'd), it does exist in some format.(If you're talking about the message archive locally, unless you run the corporate version of YIM, which is SSL based.) This problem is easily solved if you do not trust those with access to your computer, disable message archiving and there is no .dat file stored with said messages. You being the only one with the power to re-enable it keeps things decent from a local perspective until you have one fluent in registry modifications, or you add a packet sniffer in the mix, but that can sometimes do relatively no good or add headache to the sniffing due to the YMSG protocol being MD5 CRYPT, comparable to many UNIX variants.


    Quirk-

    Leave a comment:


  • highwizard
    Guest replied
    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?

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • Mr. Peabody
    replied
    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.

    Leave a comment:


  • bascule
    replied
    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?

    Leave a comment:


  • Mr. Peabody
    replied
    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?

    Leave a comment:


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

    Leave a comment:

Working...
X