New hijacking - Done via via good old-fashioned Identity Theft

Joe Greco jgreco at ns.sol.net
Fri Oct 8 13:00:30 UTC 2010


> 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 at domain.tld to user1 and key2 at domain.tld to user2.

That's a good start, but for general use, if I'm handing out an
address like "sven at jgreco.net" to Sven, and "leen at 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 at 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 at 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 at 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.




More information about the NANOG mailing list