New hijacking - Done via via good old-fashioned Identity Theft
[[ Note: There are three more apparently hijacked blocks that are related to the 75 specific blocks I am reporting on herein. I'll be reporting on those other three blocks later on, but right now I just want to keep it simple and report on just the ones relating to directnet.net. ]] So anyway, presented below, as Rod Serling would have said, "... for your approval..." you will find a collection of 75 separate IP blocks, all of which appear to have been hijacked in one big gulp. One /21, plus seventy four /24s. This case was done, quite neatly, the good old fashioned way.... apparently by trivial identity theft. (And I should say that no fault whatsoever accrues in any way to ARIN in this case. They were not even involved in the slightest, since all of the relevant WHOIS records have remained utterly unchanged throughout this entire hijacking.) The identity theft: A company that was responsible for one /21 block and 74 separate /24 blocks (all of the latter of which had been originally allocated for various U.S. elementary schools, middle schools, and high schools) apparently went out of business. In due time, the company's domain name (directnet.net) came up for sale. It was purchased for $4,000, sometime between May 31, 2010 and June 13, 2010: http://www.dnjournal.com/archive/domainsales/2010/20100623.htm Subsequently, the domain name was transferred to an anonymizing registrar in the Cayman Islands. Sometime before or after that purchase, whoever had purchased the directnet.net domain convinced the fine folks at Reliance Globalcom Services, Inc., (AS6517) to announce routes to 100% of this rather cleverly hijacked IP space. (See complete IP block list attached below.) Sometime after that, the IP blocks in question began to fill up with snowshoe name servers and snowshoe spam domains. The entire set of relevant ARIN WHOIS records for the hijacked IP blocks, along with the new WHOIS record for the newly re-registered directnet.net domain, and also a listing of the snowshoe domains and name servers that have been created in, or moved into these hijacked IP blocks are all avaliable here: http://www.47-usc-230c2.org/hijacked-schools/ Although it is impossible to be absolutely certain who engineered this clever hijacking, some of the evidence available to me at this time suggests that a particular company listed on Spamhaus' ROKSO list may possibly have either either had a hand in engineeering the hijacking, or else may possibly have benefitted from it, after the fact, i.e. obtaining IP space which they could then sub-lease to their space-hungry customers. Certainly, fine folks at Reliance Globalcom Services, Inc. could tell us who is paying them to connect these hijacked blocks to their network, but I rather doubt that they are actually going to come clean and do that. Regards, rfg Hijacked blocks: 204.194.184.0/21 205.196.1.0/24 205.196.14.0/24 205.196.28.0/24 205.196.29.0/24 205.196.30.0/24 205.196.31.0/24 205.196.32.0/24 205.196.33.0/24 205.196.34.0/24 205.196.35.0/24 205.196.36.0/24 205.196.37.0/24 205.196.38.0/24 205.196.40.0/24 205.196.41.0/24 205.196.42.0/24 205.196.43.0/24 205.196.44.0/24 205.196.45.0/24 205.196.46.0/24 205.196.47.0/24 205.196.49.0/24 205.196.51.0/24 205.196.52.0/24 205.196.53.0/24 205.196.54.0/24 205.196.55.0/24 205.196.56.0/24 205.196.57.0/24 205.196.58.0/24 205.196.59.0/24 205.196.60.0/24 205.196.61.0/24 205.196.62.0/24 205.196.67.0/24 205.196.68.0/24 205.196.69.0/24 205.196.71.0/24 205.196.72.0/24 205.196.73.0/24 205.196.75.0/24 205.196.76.0/24 205.196.96.0/24 205.196.97.0/24 205.196.99.0/24 205.196.100.0/24 205.196.101.0/24 205.196.102.0/24 205.196.103.0/24 205.196.104.0/24 205.196.105.0/24 205.196.106.0/24 205.196.107.0/24 205.196.108.0/24 205.196.109.0/24 205.196.111.0/24 205.196.112.0/24 205.196.113.0/24 205.196.114.0/24 205.196.115.0/24 205.196.116.0/24 205.196.161.0/24 205.196.162.0/24 205.196.163.0/24 205.196.164.0/24 205.196.165.0/24 205.196.192.0/24 205.196.193.0/24 205.196.194.0/24 205.196.196.0/24 205.196.197.0/24 205.196.198.0/24 205.196.199.0/24 205.196.200.0/24
Certainly, fine folks at Reliance Globalcom Services, Inc. could tell us who is paying them to connect these hijacked blocks to their network, but I rather doubt that they are actually going to come clean and do that.
Ron, I haven't been following this anti-spam stuff much since it went political with ARIN but I do have a few quick questions (relating to US law and spam). 1) Is spamming from within the US criminal activity? What constitutes spam in that case? 2) If you could justify the incoming spam as a DOS, is that criminal activity? Could you justify it as a DOS? 3) Is providing ARIN with bogus information just to get around their processes criminal activity? 4) Is obtaining disused IP space / AS allocations from assigned entity, and not updating ARIN criminal activity? 5) Is advertising Prefixes or AS number assigned to another entity criminal activity? 6) If any of the above could be classed as criminal activity, are Reliance Globalcom (in this case) legally obligated to cut them off?, or just help by switching on a packet capture (new law coming into effect i think??) Cheers Heath
In message <AANLkTi=rH=kXm6ksK1gkyfu=nh4oazW=c+66Meo5HL+H@mail.gmail.com>, Heath Jones <hj1980@gmail.com> wrote:
Certainly, fine folks at Reliance Globalcom Services, Inc. could tell us who is paying them to connect these hijacked blocks to their network, but I rather doubt that they are actually going to come clean and do that.
Ron, I haven't been following this anti-spam stuff much since it went political with ARIN but I do have a few quick questions (relating to US law and spam).
1) Is spamming from within the US criminal activity?
Sadly, it appears not. In many cases it is however actionable. (And in other cases involving actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and related activity in connection with computers', it may, I think, be considered as an aggravating factor in determining punishments.)
What constitutes spam in that case?
Are you asking what I think? Or what the majority of netizens think? Or are you asking what U.S. courts think? Those are three different answers.
2) If you could justify the incoming spam as a DOS, is that criminal activity? Could you justify it as a DOS?
Yes. No.
3) Is providing ARIN with bogus information just to get around their processes criminal activity?
In this case, nobody provided ARIN with *any* bogus information, ever. (So your question is utterly irrelevant to this particular case.)
4) Is obtaining disused IP space / AS allocations from assigned entity, and not updating ARIN criminal activity?
In this particular case, nobody appears to have ``obtained'' IP space from the various High Schools, Middle Schools, and Elementary schools involved, other than via deceit, trickery, and fraud. Were the various schools involved here ripped off? I would say yes. Does the fraud in this case rise to the level of being either criminal or actionable? I am not a lawyer, but my guess is that the answer is probably yes to both... *IF* anybody cared enough to persue it. I base that opinion stictly and only on the definition of the English language word `fraud' as given at www.merriam-webster.com. As regards to updating ARIN, or the lack thereof, the _absence_ of such ``updating'', in this case... i.e. the absence of any notice to ARIN that these blocks were being glomed onto... is part of the overall pattern of fraud in this case which, as I have said, I believe to be potentially both criminal and actionable... if anybody cared enough to persue it. But that's just my opinion, and I am not a lawyer.
5) Is advertising Prefixes or AS number assigned to another entity criminal activity?
If it constitutes criminal fraud which deprives some party of some property, or some right, or the full enjoyment of some property or some right, to which they are otherwise entitled, under law, then yes, although I am not a lawyer, my limited understanding of the law in these United States indicates to me that yes, most probably such activity may well be considered criminal, in at least some circumstances, perhaps including the ones being discussed in this thread.
6) If any of the above could be classed as criminal activity, are Reliance Globalcom (in this case) legally obligated to cut them off?,
The answer to that depends, I think, upon whether they are _knowing_ participants in the fraud. If they merely got duped... which is indeed what is suggested by that fact that somebody paid $4,000 to get a specific domain name so that they could then dupe _somebody_ (where that somebody who was to be duped, in this case was clearly _not_ ARIN)... then in that case, Reliance Globalcom is just another one of the victims, and not one of the perpetrators. Hypothetically, if, once they have been duly informed that this particular fraud is ongoing, they do nothing, and continue announcing the routes even after allowing them a reasonable amount of time to properly investigate what is going on here, then at that point I think that yes, then they might in fact be criminally liable, civilly liable, or both.
or just help by switching on a packet capture
What would be the point of that?? I can already tell you what the blocks in question are most probably being used for, and have done so already, I think. Regards, rfg
- Exactly when and where did RIR whois databases gain any legal status as an authoritive source of information, rather than just an internal tool for network operators? (as far as i see, the rirs are legally nothing more than a collective of network operators, not an authority in any way). - Exactly when and where did RIR whois entries, or rather the lack thereof prohibit any other use of those ranges (as in: blatantly announcing them, not having a registered AS number or someone elses AS number). - Exactly since when and where did IP addresses become property? (Ok, there are some court verdicts identifying them as "personal details" (although they identify a node on a network, not a person ;) - If they are indeed personal details, they are not allowed to be in public whois in the first place without the consent of the end-end-end user (privacy laws) And furthermore, if you want to stop spam on that shitty old SMTP protocol, i suggest you stop wasting time on blacklisting ips, and start working on a standard to issue all your "buddies" with a unique password so your mailserver accepts their mail and nobody elses. EVERY MODERN PROTOCOL (skype, msn) does it -that- way, and -that- works. for which it is required that: 1: a standard header is created thats discared on forwards "Password: " 2: mailinglists, online shops, etc, anyone who does not have your businesscard with a unique password on it, add a field for this. (keep in mind, each sender gets a unique password from the receiver, this can be stored in the address book along with the email address itself). - <FLAME> You "Spam fighters" have effectively KILLED smtp by: - blacklists - your anti open relay crap - motivating eyeball isps to block port 25 - graylisting makes it so damn slow nobody wants to use it anymore anyway all of this has resulted in: SMTP no longer being used on the actual workstations Therefore not operating in a p2p and real-time fashion and did you manage to stop spam? -> NO, you just managed to make it completely un workable and unreliable. did you manage to make people choose other protocols such as Skype and MSN: yes! (if email was still used in a p2p fashion people would not -need- instant messengers in the first place, as their wintendo computer would just talk smtp and store directly to the inbox) Imap, pop2, pop3 and all that other crap could have been skipped. </FLAME> -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 6 Oct 2010, Ronald F. Guilmette wrote:
In message <AANLkTi=rH=kXm6ksK1gkyfu=nh4oazW=c+66Meo5HL+H@mail.gmail.com>, Heath Jones <hj1980@gmail.com> wrote:
Certainly, fine folks at Reliance Globalcom Services, Inc. could tell us who is paying them to connect these hijacked blocks to their network, but I rather doubt that they are actually going to come clean and do that.
Ron, I haven't been following this anti-spam stuff much since it went political with ARIN but I do have a few quick questions (relating to US law and spam).
1) Is spamming from within the US criminal activity?
Sadly, it appears not.
In many cases it is however actionable. (And in other cases involving actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and related activity in connection with computers', it may, I think, be considered as an aggravating factor in determining punishments.)
What constitutes spam in that case?
Are you asking what I think? Or what the majority of netizens think? Or are you asking what U.S. courts think?
Those are three different answers.
2) If you could justify the incoming spam as a DOS, is that criminal activity? Could you justify it as a DOS?
Yes. No.
3) Is providing ARIN with bogus information just to get around their processes criminal activity?
In this case, nobody provided ARIN with *any* bogus information, ever. (So your question is utterly irrelevant to this particular case.)
4) Is obtaining disused IP space / AS allocations from assigned entity, and not updating ARIN criminal activity?
In this particular case, nobody appears to have ``obtained'' IP space from the various High Schools, Middle Schools, and Elementary schools involved, other than via deceit, trickery, and fraud. Were the various schools involved here ripped off? I would say yes. Does the fraud in this case rise to the level of being either criminal or actionable? I am not a lawyer, but my guess is that the answer is probably yes to both... *IF* anybody cared enough to persue it. I base that opinion stictly and only on the definition of the English language word `fraud' as given at www.merriam-webster.com.
As regards to updating ARIN, or the lack thereof, the _absence_ of such ``updating'', in this case... i.e. the absence of any notice to ARIN that these blocks were being glomed onto... is part of the overall pattern of fraud in this case which, as I have said, I believe to be potentially both criminal and actionable... if anybody cared enough to persue it.
But that's just my opinion, and I am not a lawyer.
5) Is advertising Prefixes or AS number assigned to another entity criminal activity?
If it constitutes criminal fraud which deprives some party of some property, or some right, or the full enjoyment of some property or some right, to which they are otherwise entitled, under law, then yes, although I am not a lawyer, my limited understanding of the law in these United States indicates to me that yes, most probably such activity may well be considered criminal, in at least some circumstances, perhaps including the ones being discussed in this thread.
6) If any of the above could be classed as criminal activity, are Reliance Globalcom (in this case) legally obligated to cut them off?,
The answer to that depends, I think, upon whether they are _knowing_ participants in the fraud. If they merely got duped... which is indeed what is suggested by that fact that somebody paid $4,000 to get a specific domain name so that they could then dupe _somebody_ (where that somebody who was to be duped, in this case was clearly _not_ ARIN)... then in that case, Reliance Globalcom is just another one of the victims, and not one of the perpetrators.
Hypothetically, if, once they have been duly informed that this particular fraud is ongoing, they do nothing, and continue announcing the routes even after allowing them a reasonable amount of time to properly investigate what is going on here, then at that point I think that yes, then they might in fact be criminally liable, civilly liable, or both.
or just help by switching on a packet capture
What would be the point of that??
I can already tell you what the blocks in question are most probably being used for, and have done so already, I think.
Regards, rfg
On Wed, Oct 06, 2010 at 10:14:27PM +0000, Sven Olaf Kamphuis wrote:
(keep in mind, each sender gets a unique password from the receiver, this can be stored in the address book along with the email address itself).
I'd like to see the I-D which explains how this is going to work, with particular attention to (a) how the passwords will be exchanged without using email (b) how it's going to handle the O(N^2) scaling and (c) how it's going to work in an environment with at least a hundred million compromised systems -- that is, systems that are now owned by the enemy, who thus also owns the contents of all the address books stored on them...including all the passwords. I think once these issues are addressed it will be only a small matter of implementation to convince everyone to swiftly move to a different protocol for mail. ---rsk
we have run a simular system for a while, the problem is still with mailinglists and online shops (by lack of a standardised field the password was put anywhere in the email, all email not containing a password was rejected with a message to call sales) a) you print unique passwords on each businesscard, and simply give them to your clients through other means (sales telephone number, etc) b) there is no O(N^2) scaling. you currently have an email address, and maybe a name for everyone you want to email in your address book, or your database, all thats required is another field with the password they gave you. c) totally fine, with us, it stopped 100% of all undesired email (normally 1500 a day just for me alone ;) If what you're asking under point c is "what happens if a system that contains such a password for your email address gets compromised" the answer is simple, you remove that specific password from your approved passwords list (note that on the receiver side, the password is not linked to the source email address, senders can use any source email address they want, as long as one of the currently active/accepted passwords is in the email) remaining problems with this system are: by lack of a standard header for Password: which should be supported by all clients, address books, online shops, mailinglists, we put the password in the email, which means, that on Cc:'s and forwards etc the password got forwarded along with the email, potentially giving other people the password too. Now, this is -100%- spam stopping, smtp can be as open relay and you want, the internet can be full of compromised windows boxes chunking out tons of crap, but you won't get any spam, just mail from people YOU choose to deal with, by actively -giving- them a password yourself, which you can also -revoke-. (the initial contact, the equivalent of "accept contact" in skype simply needs to be done through other channels, but really, people that don't know you have no business mailing you anyway ;) We have been watching these so-called "spam fighters" for a while now, and all they managed to do over the past 20 years or so is completely fuck up the smtp protocol itself, first they fucked up the concept of open relays, then it was stupid and unnessesary delays (graylisting), then there were all kinds of blacklists run by arrogant fools that gladly blacklisted all of level 3 because of one spammer, etc, and you still got spammed, and still get spammed today. If i have to wait for 20 minutes for an email, i've started skype already.. You know what, why don't we simply turn the smtp servers -off- and use skype and msn for everything... saves electricity :P It may be a bit too late to fix the protocol itself to be real-time and peer-to-peer again, but this time without spam ofcourse, as the market has been flooded with better protocols already anyway (the problem with these however is that they're propriatory and vendor dependant). -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 6 Oct 2010, Rich Kulawiec wrote:
On Wed, Oct 06, 2010 at 10:14:27PM +0000, Sven Olaf Kamphuis wrote:
(keep in mind, each sender gets a unique password from the receiver, this can be stored in the address book along with the email address itself).
I'd like to see the I-D which explains how this is going to work, with particular attention to (a) how the passwords will be exchanged without using email (b) how it's going to handle the O(N^2) scaling and (c) how it's going to work in an environment with at least a hundred million compromised systems -- that is, systems that are now owned by the enemy, who thus also owns the contents of all the address books stored on them...including all the passwords. I think once these issues are addressed it will be only a small matter of implementation to convince everyone to swiftly move to a different protocol for mail.
---rsk
On Thu, 07 Oct 2010 12:10:37 -0000, Sven Olaf Kamphuis said:
If what you're asking under point c is "what happens if a system that contains such a password for your email address gets compromised" the answer is simple, you remove that specific password from your approved passwords list
140 million or so compromised systems. You may be spending a lot of time removing compromised passwords from your list - and even more problematic, notifying everybody of the *new* password(s) they should use to e-mail to you. So far this month, I've seen 4,964 mails from 1,090 different From: lines (mostly due to a subscription to the linux-kernel list, which is a true fire hose), and some 250 different SMTP MAIL FROM: sources.
(note that on the receiver side, the password is not linked to the source email address, senders can use any source email address they want, as long as one of the currently active/accepted passwords is in the email)
We'll overlook the fact that if the password isn't linked to the source address, then *any* sender can use any source they want, as long as as it's known that *some* sender used '97%-chicken-teriyaki' as a password. And with 140 million compromised boxes, there's a basically never-ending supply of credentials to be stolen and used.
remaining problems with this system are: by lack of a standard header for Password: which should be supported by all clients, address books, online shops, mailinglists, we put the password in the email, which means, that on Cc:'s and forwards etc the password got forwarded along with the email, potentially giving other people the password too.
And you recognize that your scheme leaks said passwords, but that's not a fatal problem.
Now, this is -100%- spam stopping, smtp can be as open relay and you want, the internet can be full of compromised windows boxes chunking out tons of crap, but you won't get any spam, just mail from people YOU choose to deal with, by actively -giving- them a password yourself, which you can also -revoke-.
So explain to me in *detail* - you're in the To: line of this mail. I don't believe I've sent to you in the past. I acquire a password valid to send you this e-mail, how, exactly? After all, I can't e-mail you and ask for one... After that, explain how a Hotmail user migrates to GMail (or vice versa) and retains their ability to contact everybody they used to contact. You might want to look at this: http://www.rhyolite.com/anti-spam/you-might-be.html and see how many of the entries in the list apply to your proposal. (Nothing personal - I don't think *any* realistic anti-spam proposal can get much traction unless they've at least *thought* about every single bullet point on that list). Further discussion is probably best on SPAM-L.
you just give contacts for the passwords with which you have received a new one. each potential person that can send email to your email address, gets a unique password from you. sending person/maillist 1 gets password abcdefg to send to bla@example.com (no matter from which email address) sending person/maillist 2 gets password 123545 to send to bla@example.com (no matter from which email address) email clients should be modified to include the password: field both in the email itself and in the header entry field (to: from: subjecT: or just store them together with the destination address in the address book mailservers (the maildrop part) should be modified to parse the Password: header, compare it to the list of currently allowed passwords for the destination email address and then either drop to the mailbox, or bounce. (we did this in our test setup by simply parsing the entire email, so the password could be -anywhere- in the email :P ofcourse the Password: line should be only sent to the recipient, not to other Cc: or Bcc: target addresses of the same email, the first stmp server in the chain should solve this bit. actually, durign our tests, we turned off all the header verifications, RBL's, etc on our smtpds, and the only spam that got through were emails that accidentially contained the password string in a binary attachment (as we parsed the entire email .. we should not do that, just teh Password: line in the final version :P and stuff where we gave, for example, nanog, the password "nanog" and then nanog is cc'ed in a spam both of which cases can be solved with the standardization of the Password: field once this is in place, all smtpds can go open relay again, port 25 can be opened again on eyeball networks, RBLs and graylisting can remain at home, and the SMTP email system will be 100% spam free and reliable and real-time. (there are several other features which have been removed from most smtpds to "stop spam" such as accepting ip addresses rather than domain names in the target email address, which can then return) all the other stuff never stopped spam, it just made smtp email unreliable slow and no longer an option for 99% of the things where email was used for before, and skype, msn and facebook are used for today. this system -does- stop spam, but the disadvantage to this system is that by implementing it, smtp email is no longer suitable for "initial contact" (well you could ofcourse place passwords in whois and on your website for your hostmaster/sales box so random people can still make initial contact over smtp, or simply accept all passwords on those boxes, on which then there WILL be spam.. ;) i'd say, smtp no longer being "open for any random idiot to mail any other random idiot without knowing each other first" is less of a disadvantage than taking the whole thing slowly die by making it less and less attractive as a means of communications (slow, unreliable and not real-time, and still with spam coming in by the 1000s, which it is due to "conventional" attempts to stop spam) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Thu, 7 Oct 2010, Valdis.Kletnieks@vt.edu wrote:
On Thu, 07 Oct 2010 12:10:37 -0000, Sven Olaf Kamphuis said:
If what you're asking under point c is "what happens if a system that contains such a password for your email address gets compromised" the answer is simple, you remove that specific password from your approved passwords list
140 million or so compromised systems. You may be spending a lot of time removing compromised passwords from your list - and even more problematic, notifying everybody of the *new* password(s) they should use to e-mail to you. So far this month, I've seen 4,964 mails from 1,090 different From: lines (mostly due to a subscription to the linux-kernel list, which is a true fire hose), and some 250 different SMTP MAIL FROM: sources.
(note that on the receiver side, the password is not linked to the source email address, senders can use any source email address they want, as long as one of the currently active/accepted passwords is in the email)
We'll overlook the fact that if the password isn't linked to the source address, then *any* sender can use any source they want, as long as as it's known that *some* sender used '97%-chicken-teriyaki' as a password. And with 140 million compromised boxes, there's a basically never-ending supply of credentials to be stolen and used.
remaining problems with this system are: by lack of a standard header for Password: which should be supported by all clients, address books, online shops, mailinglists, we put the password in the email, which means, that on Cc:'s and forwards etc the password got forwarded along with the email, potentially giving other people the password too.
And you recognize that your scheme leaks said passwords, but that's not a fatal problem.
Now, this is -100%- spam stopping, smtp can be as open relay and you want, the internet can be full of compromised windows boxes chunking out tons of crap, but you won't get any spam, just mail from people YOU choose to deal with, by actively -giving- them a password yourself, which you can also -revoke-.
So explain to me in *detail* - you're in the To: line of this mail. I don't believe I've sent to you in the past. I acquire a password valid to send you this e-mail, how, exactly? After all, I can't e-mail you and ask for one...
After that, explain how a Hotmail user migrates to GMail (or vice versa) and retains their ability to contact everybody they used to contact.
You might want to look at this:
http://www.rhyolite.com/anti-spam/you-might-be.html
and see how many of the entries in the list apply to your proposal. (Nothing personal - I don't think *any* realistic anti-spam proposal can get much traction unless they've at least *thought* about every single bullet point on that list).
Further discussion is probably best on SPAM-L.
On Thu, 07 Oct 2010 14:16:00 -0000, Sven Olaf Kamphuis said:
you just give contacts for the passwords with which you have received a new one.
each potential person that can send email to your email address, gets a unique password from you.
You missed the point. How does person37@gmail.com ask me for a password, if I don't accept his e-mail without one? (Hold this thought, we'll be back to this)
sending person/maillist 1 gets password abcdefg to send to bla@example.com (no matter from which email address)
sending person/maillist 2 gets password 123545 to send to bla@example.com (no matter from which email address)
And if I've assigned 123545 to duct-tape-2010@yahoo.com, but he's since moved to clawhammer101@gmail.com, how do I securely notify him of the new password, keeping in mind that I'm probably changing the password *because the enemy already has access to the old password*? "Hey Joe - somebody has enough access to your system to get 123545 - so use fuzzy-wombat instead". What's wrong with this picture? With 140 million compromised boxes where sending the new password is basically e-mailing to the enemy, and the scheme leaking new passwords to boot, "revoke and issue a new credential" simply doesn't scale. In other words, the only sane response is "revoke and don't bother setting new one". At which point the person has to contact me and ask for a new password. "Hey, this is duct-tape-2010, my password doesn't work, give me a new one". Given that his old password doesn't work because I revoked it when a spammer got hold of it, how do I know that I'm not giving the new password directly to the spammer and the esteemed Mr Tape has no idea any of this happened? Further discussion probably belongs on SPAM-L.
On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
you just give contacts for the passwords with which you have received a new one.
Hi Sven/others, This very much sounds like TMDA: http://tmda.net/ http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent Where by each person that needs to contact you, you give a unique e-mail address. So you give out key1@domain.tld to user1 and key2@domain.tld to user2. That way when you registered at that webshop or mailinglist and that e-mail address gets used for spam, you just delete that one unique key (and maybe, if you still want to communicate with them, a new unique key). There are 2 variants if I remember correctly: key@domain.tld for when you have a personal domain key-user@domain.tld for when you have a server which understand address extensions While there is software for that, I've been doing something similair to this by hand for a long time for a lot of contacts. The good thing about using a unique e-mail address instead of a password is that you can block at the SMTP-level, without even receiving an e-mail body. Have a nice day, Leen.
each potential person that can send email to your email address, gets a unique password from you.
sending person/maillist 1 gets password abcdefg to send to bla@example.com (no matter from which email address)
sending person/maillist 2 gets password 123545 to send to bla@example.com (no matter from which email address)
email clients should be modified to include the password: field both in the email itself and in the header entry field (to: from: subjecT: or just store them together with the destination address in the address book
mailservers (the maildrop part) should be modified to parse the Password: header, compare it to the list of currently allowed passwords for the destination email address and then either drop to the mailbox, or bounce. (we did this in our test setup by simply parsing the entire email, so the password could be -anywhere- in the email :P
ofcourse the Password: line should be only sent to the recipient, not to other Cc: or Bcc: target addresses of the same email, the first stmp server in the chain should solve this bit.
actually, durign our tests, we turned off all the header verifications, RBL's, etc on our smtpds, and the only spam that got through were emails that accidentially contained the password string in a binary attachment (as we parsed the entire email .. we should not do that, just teh Password: line in the final version :P and stuff where we gave, for example, nanog, the password "nanog" and then nanog is cc'ed in a spam both of which cases can be solved with the standardization of the Password: field
once this is in place, all smtpds can go open relay again, port 25 can be opened again on eyeball networks, RBLs and graylisting can remain at home, and the SMTP email system will be 100% spam free and reliable and real-time. (there are several other features which have been removed from most smtpds to "stop spam" such as accepting ip addresses rather than domain names in the target email address, which can then return)
all the other stuff never stopped spam, it just made smtp email unreliable slow and no longer an option for 99% of the things where email was used for before, and skype, msn and facebook are used for today.
this system -does- stop spam, but the disadvantage to this system is that by implementing it, smtp email is no longer suitable for "initial contact"
(well you could ofcourse place passwords in whois and on your website for your hostmaster/sales box so random people can still make initial contact over smtp, or simply accept all passwords on those boxes, on which then there WILL be spam.. ;)
i'd say, smtp no longer being "open for any random idiot to mail any other random idiot without knowing each other first" is less of a disadvantage than taking the whole thing slowly die by making it less and less attractive as a means of communications (slow, unreliable and not real-time, and still with spam coming in by the 1000s, which it is due to "conventional" attempts to stop spam)
On 8/10/10 10:00 AM, Leen Besselink wrote:
key@domain.tld for when you have a personal domain key-user@domain.tld for when you have a server which understand address extensions
Actually I think it's user+key@domain.tld for the second one. At least that's what I've seen for Postfix. Not so sure about other MTAs. Regards, Ben
On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
you just give contacts for the passwords with which you have received a new one.
Hi Sven/others,
This very much sounds like TMDA:
http://tmda.net/ http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent
Where by each person that needs to contact you, you give a unique e-mail address.
So you give out key1@domain.tld to user1 and key2@domain.tld to user2.
That's a good start, but for general use, if I'm handing out an address like "sven@jgreco.net" to Sven, and "leen@jgreco.net" to Leen, the real problem here is predictability. If Sven is a bad guy, he can cause trouble by guessing that I'd use "leen@jgreco.net" for Leen and proceed to pass that address out to spammers, making Leen look like a bad guy. That particular problem is reduced by generating random tokens for the LHS, however, doing so introduces new problems, such as the fact that "23ycs7ia877oij@jgreco.net" is no longer obviously associated with Sven. I've been very successfully using a much better tagging system here. Take a user-specified identifier, such as, say, "sven". You run this through a one-way crypto function, such as MD5: md5=`echo "${1}/SomeMagicSecret" | md5` f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"` echo "${1}@${f8}.demo.jgreco.net" This results in something like nanog@e6ecd2ea.demo.jgreco.net Now this has a bunch of interesting properties. 1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to your actual mailbox address. If and when a problematic address is issued, you can add at the DNS level an MX (or whatever nasty you prefer) for the particular domain name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net to NS from 127.0.0.1. Never even touches the mail server. Of course MTA or procmail deny works too. 2) By using a separate zone, it makes it trivial to configure your mail system so that these addresses blow completely by any normal spam filtering; the problem of false positives for things like transactional e-mail that spam filters often find "spammy" vanishes completely. 3) You need not keep a database of valid tokens; you can simply re-validate the LHS in Procmail. This means that you can do things like write a mobile app or web app that doesn't have to have access to your mail server's innards. The primary downside is that you need some way to compute the crypto-signed bit. 4) You can keep a database of issued tokens along with when and why they were issued. 5) If you make it a habit of using a LHS that's descriptive, it's hard for a sender to argue that the tag was not assigned to them. It's particularly entertaining for things like e-pending because it will reveal which companies you will no longer choose to do business with. This turns out to be very powerful and very flexible. It can be extended to include functionality such as single-use addresses or limited-age addresses, etc. The big trick is to leverage the e-mail address field itself rather than trying to add a password or something like that in the body. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
no, not the email address is the key, rather a unique string issued by the receiver to each potentuial sender. the email address does not stop spam originating from lets say, hacked windows boxes. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven@cb3rob.net ========================================================================= <penpen> C3P0, der elektrische Westerwelle ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 8 Oct 2010, Joe Greco wrote:
On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote:
you just give contacts for the passwords with which you have received a new one.
Hi Sven/others,
This very much sounds like TMDA:
http://tmda.net/ http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent
Where by each person that needs to contact you, you give a unique e-mail address.
So you give out key1@domain.tld to user1 and key2@domain.tld to user2.
That's a good start, but for general use, if I'm handing out an address like "sven@jgreco.net" to Sven, and "leen@jgreco.net" to Leen, the real problem here is predictability. If Sven is a bad guy, he can cause trouble by guessing that I'd use "leen@jgreco.net" for Leen and proceed to pass that address out to spammers, making Leen look like a bad guy.
That particular problem is reduced by generating random tokens for the LHS, however, doing so introduces new problems, such as the fact that "23ycs7ia877oij@jgreco.net" is no longer obviously associated with Sven.
I've been very successfully using a much better tagging system here.
Take a user-specified identifier, such as, say, "sven".
You run this through a one-way crypto function, such as MD5:
md5=`echo "${1}/SomeMagicSecret" | md5` f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"` echo "${1}@${f8}.demo.jgreco.net"
This results in something like
nanog@e6ecd2ea.demo.jgreco.net
Now this has a bunch of interesting properties.
1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to your actual mailbox address.
If and when a problematic address is issued, you can add at the DNS level an MX (or whatever nasty you prefer) for the particular domain name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net to NS from 127.0.0.1. Never even touches the mail server. Of course MTA or procmail deny works too.
2) By using a separate zone, it makes it trivial to configure your mail system so that these addresses blow completely by any normal spam filtering; the problem of false positives for things like transactional e-mail that spam filters often find "spammy" vanishes completely.
3) You need not keep a database of valid tokens; you can simply re-validate the LHS in Procmail. This means that you can do things like write a mobile app or web app that doesn't have to have access to your mail server's innards. The primary downside is that you need some way to compute the crypto-signed bit.
4) You can keep a database of issued tokens along with when and why they were issued.
5) If you make it a habit of using a LHS that's descriptive, it's hard for a sender to argue that the tag was not assigned to them. It's particularly entertaining for things like e-pending because it will reveal which companies you will no longer choose to do business with.
This turns out to be very powerful and very flexible. It can be extended to include functionality such as single-use addresses or limited-age addresses, etc. The big trick is to leverage the e-mail address field itself rather than trying to add a password or something like that in the body.
... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
no, not the email address is the key, rather a unique string issued by the receiver to each potentuial sender.
In the system I describe, the email address *is* "a unique string issued by the receiver to each potent[u]ial sender." This has the charming property of working very well with the existing e-mail system and without having to have each correspondent manage a directory of "key" words for each person they want to correspond with, updates to that directory, etc.
the email address does not stop spam originating from lets say, hacked windows boxes.
No system does. The point is to be able to tell who leaked/abused/etc it, and more importantly, to be able to trivially terminate the sender's ability to use the address, making that entry on their list completely useless, or better yet, annoying them by clogging up their mail server, if you do sufficiently BOFHish things. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
1) Is spamming from within the US criminal activity?
Sadly, it appears not.
In many cases it is however actionable. (And in other cases involving actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and related activity in connection with computers', it may, I think, be considered as an aggravating factor in determining punishments.)
Wouldn't it have to be illegal before punishments could be determined? Isn't this kind of key to the whole issue of fighting spam?? (Is there even a point if you cant nail them for it?)
What constitutes spam in that case?
Are you asking what I think? Or what the majority of netizens think? Or are you asking what U.S. courts think?
Those are three different answers.
With regards to US court.
2) If you could justify the incoming spam as a DOS, is that criminal activity? Could you justify it as a DOS?
Yes. No.
Ok.
3) Is providing ARIN with bogus information just to get around their processes criminal activity?
In this case, nobody provided ARIN with *any* bogus information, ever. (So your question is utterly irrelevant to this particular case.)
Not at all irrelevant, I'm talking generically here (not specific to this case). Trying to cover all bases.
4) Is obtaining disused IP space / AS allocations from assigned entity, and not updating ARIN criminal activity?
In this particular case, nobody appears to have ``obtained'' IP space from the various High Schools, Middle Schools, and Elementary schools involved, other than via deceit, trickery, and fraud. Were the various schools involved here ripped off? I would say yes. Does the fraud in this case rise to the level of being either criminal or actionable? I am not a lawyer, but my guess is that the answer is probably yes to both... *IF* anybody cared enough to persue it. I base that opinion stictly and only on the definition of the English language word `fraud' as given at www.merriam-webster.com.
As regards to updating ARIN, or the lack thereof, the _absence_ of such ``updating'', in this case... i.e. the absence of any notice to ARIN that these blocks were being glomed onto... is part of the overall pattern of fraud in this case which, as I have said, I believe to be potentially both criminal and actionable... if anybody cared enough to persue it.
But that's just my opinion, and I am not a lawyer.
Perhaps there is a method of class action, as opposed to individual companies trying to sue?
5) Is advertising Prefixes or AS number assigned to another entity criminal activity?
If it constitutes criminal fraud which deprives some party of some property, or some right, or the full enjoyment of some property or some right, to which they are otherwise entitled, under law, then yes, although I am not a lawyer, my limited understanding of the law in these United States indicates to me that yes, most probably such activity may well be considered criminal, in at least some circumstances, perhaps including the ones being discussed in this thread.
Well that might possibly be a start of a legal avenue..?
6) If any of the above could be classed as criminal activity, are Reliance Globalcom (in this case) legally obligated to cut them off?,
The answer to that depends, I think, upon whether they are _knowing_ participants in the fraud. If they merely got duped... which is indeed what is suggested by that fact that somebody paid $4,000 to get a specific domain name so that they could then dupe _somebody_ (where that somebody who was to be duped, in this case was clearly _not_ ARIN)... then in that case, Reliance Globalcom is just another one of the victims, and not one of the perpetrators.
Hypothetically, if, once they have been duly informed that this particular fraud is ongoing, they do nothing, and continue announcing the routes even after allowing them a reasonable amount of time to properly investigate what is going on here, then at that point I think that yes, then they might in fact be criminally liable, civilly liable, or both.
Might be worth pointing that out to them? Most companies don't like risk..
or just help by switching on a packet capture
What would be the point of that??
I can already tell you what the blocks in question are most probably being used for, and have done so already, I think.
I was referring to new legislation coming into effect that gives the FBI? the power to say 'flick the switch on now' and they then can log traffic.. All in all, it just seems pretty pointless trying to fight spam if the law isnt backing you. Filtering yes, fighting no.. Perhaps the law is what needs to be worked on? (As a general comment to all) Cheers Heath
-----Original Message----- From: Heath Jones Sent: Wednesday, October 06, 2010 3:24 PM To: nanog@nanog.org Subject: Re: New hijacking - Done via via good old-fashioned Identity Theft
Wouldn't it have to be illegal before punishments could be determined? Isn't this kind of key to the whole issue of fighting spam?? (Is there even a point if you cant nail them for it?)
This conversation isn't really about spam. It is about being able to obtain the number resources of a defunct organization by masquerading as that organization by registering an identical business entity or operating name. So foo.com has legitimately obtained number resources. Foo.com goes broke and those resources are no longer in use. Joe Blow registers an operation he calls foo.com and claims the right to use those number resources. I don't care if those resources are being used for spam or giving away free money to the needy, that is beside the point. The issue as I see it is to raise awareness that just because foo.com wants to announce resources and just because that WHOIS says those resources belong to foo.com, it doesn't mean that the two are the same foo.com Having an organization come to you wanting to announce a /18 of network space (that was allocated 10 years ago) and their domain was only created a week ago might be a clue. G
so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"? Eric
On 7/10/10 12:08 AM, Eric Brunner-Williams wrote:
so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"?
Interesting idea, but how do you apply it to ccTLD domains with widely varying policies. All it takes is whois records being legitimately updated to use domain contacts using a ccTLD domain to circumvent. Sounds like more of a stop-gap measure. Regards, Ben
On Oct 6, 2010, at 6:35 AM, Ben McGinnes wrote:
On 7/10/10 12:08 AM, Eric Brunner-Williams wrote:
so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"?
Interesting idea, but how do you apply it to ccTLD domains with widely varying policies. All it takes is whois records being legitimately updated to use domain contacts using a ccTLD domain to circumvent. Sounds like more of a stop-gap measure.
Regards, Ben
Number resources are not and should not be associated with domain resources at the policy level. This would make absolutely no sense whatsoever. Owen
On 10/6/10 10:34 AM, Owen DeLong wrote:
On Oct 6, 2010, at 6:35 AM, Ben McGinnes wrote:
On 7/10/10 12:08 AM, Eric Brunner-Williams wrote:
so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"?
Interesting idea, but how do you apply it to ccTLD domains with widely varying policies. All it takes is whois records being legitimately updated to use domain contacts using a ccTLD domain to circumvent. Sounds like more of a stop-gap measure.
Regards, Ben
Number resources are not and should not be associated with domain resources at the policy level. This would make absolutely no sense whatsoever.
hmm. ... "are not" ... so the event complained of ... didn't happen?
On 7/10/10 6:28 AM, Eric Brunner-Williams wrote:
On 10/6/10 10:34 AM, Owen DeLong wrote:
Number resources are not and should not be associated with domain resources at the policy level. This would make absolutely no sense whatsoever.
hmm. ... "are not" ... so the event complained of ... didn't happen?
The key issue here is more the "should not" aspect, which I agree with, but that these records are frequently used by netops to verify a request. There really needs to be a greater standardised level of due diligence regarding advertisement requests that checks more than whether a request is coming from a seemingly legitimate email address. Regards, Ben
participants (12)
-
Ben McGinnes -
Eric Brunner-Williams -
George Bonser -
Heath Jones -
Joe Greco -
Leen Besselink -
Nick Hilliard -
Owen DeLong -
Rich Kulawiec -
Ronald F. Guilmette -
Sven Olaf Kamphuis -
Valdis.Kletnieks＠vt.edu