Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC: Targeted link diversion attempts - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Targeted link diversion attempts

It's always hard to convince people of how easy well targeted attacks penetrate trough our defenses. Examples help in educating, but in the case of targeted attacks these aren't so easy to find and report on.

Imagine you're the webmaster of an unnamed educational institute (no it's not SANS, -unfortunately- as it would mean we would not need to obfuscate parts of the message) and you got this in your inbox this morning:

From: webmaster[at]umich.edu <webmaster[at]umich.edu>
To: [webmaster]
Subject: changing   domain

Dear webmaster

of the website http://[your website]/

We`re writing to you, because our web address http://www.umich.edu/

will be switched off in a couple of weeks.

We would be grateful if you could change the link on your site
[your page with a link to www.umich.edu]

to our new website http://www[dot]umich-edu[dot]com/

We wish to thank you for your help.

Yours faithfully

Peter Premhuber

So what's the goal of this, no self-respecting webmaster would fall for this I hear you think. Well... let's look at that target website: aside of an added white border, it looks like it's the real site out there.

In fact looking at the source code all that is there right now is :

<html>
<head>
</head>
<body>
<iframe src="http://www.umich.edu/index.html" width="100%" height="100%" frameborder="0" scrolling="auto"></iframe>
</body>
</html>

A "framed" version of the real site

What's the goal here:

To get enough incoming links to a website from authoritative sources so the hacker's site gets relevance in search engines. and well after that, your guess is as good as ours as to what they'll put in that iframe instead or in addition to the real website.

Looking at the .com domainname: it was registered on "05-feb-2009" and if hosted in Turkey ...

Building defenses so our people don't fall for targeted attempts like these is hard. It requires a tremendous amount of awareness to catch this on an individual and consistent basis.

Trying to make sure our websites don't fall prey to this low tech link hijacking isn't easy either as most of it happens well outside our perimeter, the best we can hope for is detection and then react to it.

Is this new, nah of course not, but it's easy enough to find tracks of these perps if you search for the name they used to sign the message with, you find they tried before to divert links pointing to:

  • http://Newcastle.edu.au/ to http://www[dot]Newcastle-edu[dot]com/ in October 2008
  • http://www.uga.edu/ to http://www[dot]uwa-edu[dot]com in November 2008

with virtually identical messages.

So what's on those two older domains today? Well, it seems it's a blog using wordpress as a CMS and using German text. I guess they're still waiting to get traffic and payload.

How well did this diverting of links actually work ?

  • http://www[dot]Newcastle-edu[dot]com/ had 7 incoming links in a Google link search
  • http://www[dot]uwa-edu[dot]com had one incoming link in a Googe link search

It's hard to tell how high their success rate is based on this, but it's also clearly not zero either. Esp. not if you look at source code like:

<a href="http://www[dot]newcastle-edu[dot]com">www.newcastle.edu.au</a>

--
Swa Frantzen -- Section 66

Swa

760 Posts
I found this in an FAQ. Would it work in this case?
-----
How I do stop my webpages appearing inside other people's frames?

The only way to stop your web pages appearing inside other people's frames is to use JavaScript. If your own site does not use frames then you can employ the following script in each of your pages.

<BODY onLoad="if (self != top) top.location = self.location">
Anonymous
Re: Ray

I don't think that technique works in modern browsers, because the JavaScript on your website would be disallowed access to 'top' (ie. the main browser pane which encompasses the IFRAME your site is running inside of), because they would be on different domains. If that restriction wasn't in place, there would be cross-site scripting risks, where a page in an IFRAME could use JS to change things on the parent page, to steal cookies or submitted passwords.
Steven C.

171 Posts

Sign Up for Free or Log In to start participating in the conversation!