"New Universal Man-in-the-Middle Phishing Kit" ?

http://www.rsasecurity.com/press_rel...sp?doc_id=7667

....snip...
How it works

Using the Universal Man-in-the-Middle Phishing Kit, the fraudster creates a fraudulent URL via a simple and
user-friendly online interface. This URL communicates with the legitimate website of the targeted organization in
real-time - whether it is the online banking site of a financial institution, the order tunnel of an ecommerce company,
or any other such business transacting with its users online. The victim receives a "standard" phishing email, and when
clicking on the link s/he is directed to the fraudulent URL. The victim then interacts with genuine content from the
legitimate website - which has been "imported" by the attack into the phishing URL - thus allowing the fraudster
seamless, invisible and immediate access to the victim's personal information.

....snip...
how does an URL communicate with anything?
and why wouldn't my browser complain about an invalid certificate for my banks site?

any ideas?
M

In article <1169034925.898099@nntpcache01.si.eunet.at>,
mak <mak@nospam.com> wrote:

> http://www.rsasecurity.com/press_rel...sp?doc_id=7667
>
> ...snip...
> How it works
>
> Using the Universal Man-in-the-Middle Phishing Kit, the fraudster creates a
> fraudulent URL via a simple and
> user-friendly online interface. This URL communicates with the legitimate
> website of the targeted organization in
> real-time - whether it is the online banking site of a financial institution,
> the order tunnel of an ecommerce company,
> or any other such business transacting with its users online. The victim
> receives a "standard" phishing email, and when
> clicking on the link s/he is directed to the fraudulent URL. The victim then
> interacts with genuine content from the
> legitimate website - which has been "imported" by the attack into the
> phishing URL - thus allowing the fraudster
> seamless, invisible and immediate access to the victim's personal
> information.
>
> ...snip...
> how does an URL communicate with anything?

They mean "the server accessed via the URL".

> and why wouldn't my browser complain about an invalid certificate for my
> banks site?

You're not going to your bank's site, your going to the phisher's site
because you clicked on the fraudulent URL he sent you. The phisher has
a valid certificate for his own site, of course, so there's nothing for
your browser to complain about (it has no way of knowing where you
*think* you're going).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin wrote:
>
>> ...snip...
>> how does an URL communicate with anything?
>
> They mean "the server accessed via the URL".
that's what i thought,

>> and why wouldn't my browser complain about an invalid certificate for my
>> banks site?
>
> You're not going to your bank's site, your going to the phisher's site
> because you clicked on the fraudulent URL he sent you. The phisher has
> a valid certificate for his own site, of course, so there's nothing for
> your browser to complain about (it has no way of knowing where you
> *think* you're going).
>

ok,
but then I will see the bogus URL
as in:

http://www.mybank.com.onlineid397995...s/customer.htm

in my browser, right?

M

In article <5188ruF1j33roU1@mid.dfncis.de>,
Sebastian Gottschalk <seppi@seppig.de> wrote:

> Barry Margolin wrote:
>
> >> and why wouldn't my browser complain about an invalid certificate for my
> >> banks site?
> >
> > You're not going to your bank's site, your going to the phisher's site
> > because you clicked on the fraudulent URL he sent you. The phisher has
> > a valid certificate for his own site, of course, so there's nothing for
> > your browser to complain about (it has no way of knowing where you
> > *think* you're going).
>
> As long as CAs like VeriSlime are in business, it might happen that the
> phisher might even aqquire a valid certificate for the original banking
> site and involves DNS cache poisoning to impersonate it.

True, but that's not the "man in the middle" type of attack that the
original article was asking about.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article <1169106344.216078@nntpcache01.si.eunet.at>,
mak <mak@nospam.com> wrote:

> Barry Margolin wrote:
> >
> >> ...snip...
> >> how does an URL communicate with anything?
> >
> > They mean "the server accessed via the URL".
> that's what i thought,
>
> >> and why wouldn't my browser complain about an invalid certificate for my
> >> banks site?
> >
> > You're not going to your bank's site, your going to the phisher's site
> > because you clicked on the fraudulent URL he sent you. The phisher has
> > a valid certificate for his own site, of course, so there's nothing for
> > your browser to complain about (it has no way of knowing where you
> > *think* you're going).
> >
>
> ok,
> but then I will see the bogus URL
> as in:
>
> http://www.mybank.com.onlineid397995...s/customer.htm
>
> in my browser, right?

Maybe. But that's true of traditional phishing sites, it's nothing new
in this case. The MitM attack simply adds the ability of the site to
display things on the page that supposedly only the real site can
display (such as your last ATM transaction).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Barry Margolin <barmar@alum.mit.edu> writes:
> Maybe. But that's true of traditional phishing sites, it's nothing new
> in this case. The MitM attack simply adds the ability of the site to
> display things on the page that supposedly only the real site can
> display (such as your last ATM transaction).

or supposedly the latest online banking countermeasures for fraudulent
website (phishing) imposters ... recent discussion in another n.g.
http://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
http://www.garlic.com/~lynn/2007b.html#54 Forbidding Special characters in passwords
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007