[vox-tech] OT: one of the most pernicious spams i've ever seen.

[Rob Rogers]

On Thu, Sep 25, 2003 at 20:00:51PM -0700, Mitch Patenaude wrote:
> On Thursday, Sep 25, 2003, at 11:23 US/Pacific, Rob Rogers wrote:
> >I see a couple other problems with this idea too. First, this is the
> >first phishing scheme I've seen that loaded the actual homepage. Most
> >just steal their logos.
> 
> Yes.. that was actually what got me thinking.. when image files
> are loaded with a referrer that isn't "local" maybe they should be
> replaced with fraud warnings. It's not 100% effective, and if it became
> widespread then it would relatively easy to circumvent, but it would
> probably prevent a few ID thefts.  While referrer is optional, it's
> controlled by the browser, and the people most likely to fall for these
> schemes are going to be running stock browsers without things like
> privacy screening proxies that strip them out.

Which is quite easy to do, is done frequently via .htaccess, and doesn't
work in 99.9% of these cases because they're being served off of the
fake webserver, not linked directly from the real one.

> > Secondly, I'm almost potitive that your browser
> >wouldn't send encoded characters in the referer. Your browser would
> >have
> >already decoded them, and it would send them unencoded.
>
> Why would your browser decode them?  The browser usually does nothing
> with a URL except pass it unmodified to the server.  When I write log
> processing scripts.. I have to decode them if I want to get consistent
> results.

Sorry. I was thinking back to my earlier email where I was discussing
encoding a domain name to look innocuous. Here was my example:

http://www.citibank.com%2e%61%33%6b%73%64%2e%50%69%53%65%4d%2e%4e%65%54

which unencoded becomes http://www.citibank.com.a3ksd.PiSeM.NeT
(using the actual base domain from the original email)

This much your browser would have to decode to do a DNS lookup, and I've
never seen a browser show it encoded. Whether or not it sends it encoded
in the referer, I can't speak with any authority, but I highly doubt it
does. As for anything after the servername and/or port #, I realize it
does send that encoded. I appologize for not making myself clear at
first.

> >As for usernames, I don't think your browser would EVER send that as
> >part of the referer.
> 
> Yet they are..  Along with the CGI arguments,  This was used a while
> back to steal hotmail/webmail accounts.  Send somebody HTML email with
> an <img> tag which gets fetched from a server you have access to, and
> the referrer (used to) give you a fully functional URL into their
> mailbox.  This has been fixed with almost all web-based email clients
> now.
> 
> > That would be a MAJOR security flaw.
> 
> And it has been exploited...

Again, I still had my previous emails in my head, and was continuing
from there, making assumptions about things without specifying them.
I believe we're talking about two very different things here. The
only Hotmail exploits I've seen have had to do with a username as an
argument at the end of a URL. for instance
http://www.hotmail.com/cgi-bin/login?lang=EN&country=US&login=user1

In that case, your browser has no idea what/where your username is, or
even if there is one there. There is really no way to tell (assuming
"login" could be replaced by anything). What I was talking about was a
URL formated in the form we saw in the original email:
http://username:password@www.example.com/

If you can show a case where a browser was passing on that whole URL,
including the username and password, I'd be interested in seeing it. I'm
not saying it hasn't happened, but I'd be surprised. That is what I was
refering to as a "MAJOR security flaw." Actually, I take that back. I
wouldn't be surprised to see that it has happened. I would be surprised
to see one of the major browsers that still has such a security hole in
it.