"Instead, the malicious web pages can be stored in data URIs - uniform resource identifiers, not to be confused with URLs" -- Hhhhmmm, you know this is a tech news site right?
Firefox, Opera allow crooks to hide an entire phish site in a link
A shortcoming in browsers including Firefox and Opera allows crooks to easily hide an entire malicious web page in a clickable link - ideal for fooling victims into handing over passwords and other sensitive info. Usually, so-called "phishing attacks" rely on tricking marks into visiting websites designed by criminals to …
-
-
-
Monday 3rd September 2012 21:47 GMT Destroy All Monsters
It's also wrong
URIs are the same as URLs, or maybe URLs are a subset of URIs...
At http://www.w3.org/Addressing/ we read:
Uniform Resource Identifiers (URIs, aka URLs) are short strings that identify resources in the web: documents, images, downloadable files, services, electronic mailboxes, and other resources. They make resources available under a variety of naming schemes and access methods such as HTTP, FTP, and Internet mail addressable in the same simple way. They reduce the tedium of "log in to this server, then issue this magic command ..." down to a single click.
At RFC 3986, we read:
A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. (Syntax defined herein ....)
And in section 1.1.3. "URI, URL, and URN":
A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name. An individual scheme does not have to be classified as being just one of "name" or "locator". Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305].
-
-
-
This post has been deleted by its author
-
-
-
Monday 3rd September 2012 16:13 GMT Anonymous Coward
But, but, but ...
I get it up to the point of using a shortened URL. A shortened URL points to a resource on a web server ... the fact that the resource is a URL at the shortening service, or a plain-old phishing page hosted anywhere ... what''s the difference?
Anyway, it's About time browsers started distrusting these shortened URL services by default.
-
Monday 3rd September 2012 16:37 GMT Interested Party
Re: But, but, but ...
I believe what they're saying is that the URI itself contains the data for the 'web page' instead of linking you to somewhere else, it just loads the data contained within the link. So effectively, using the TinyURL example, TinyURL becomes the webhost because you click the small URL and it forwards you to the long URI containing the web page data which they store on their server.
To achieve anything useful I would imagine this URI would need to be extremely long (in the context of a URL), I wonder what the maximum character limit on URL shortening services is?
-
Tuesday 4th September 2012 00:30 GMT Shannon Jacobs
Re: But, but, but ...
Maybe you can chain the pieces together? My initial idea is vaguely like tail recursion. You get the last part of the fake website up to the limit of the link shortener, and you create that link. Then you take the next chunk saving enough characters for the link to the last part, and you create that link. Then you take the next chunk going backwards until you reach the beginning of your fake website. I'm sure it would be more complex like that, and there are probably some restrictions on where you can break the chunks of the website, plus escapes for special characters, etc., but I can imagine the mechanism where the entire URL would be unrolled into your browser in the form of a complete webpage, which would certainly appear to be a local reference to your browser...
Gee, I hope I haven't given the spammers a new idea... Sometimes I worry that I have a criminal mentality.
What I REALLY want is an anti-spammer website that would parse the heck out of spam email, going after ALL of the spammers' accomplices, shutting down ALL of the spammers' infrastructure, and helping and protecting ALL of the spammers' victims. Is that too much to ask for? Apparently.
-
-
Monday 3rd September 2012 16:44 GMT Ian McNee
Re: But, but, but ...
Because the crims can "legitimately" use a URL shortening service like bit.ly or tinyurl that need not be be compromised. The "link" on the shortening service doesn't actually go anywhere - it's a URI that is itself the attack site.
So effectively this vulnerability makes shortening services attack sites and therefore it wouldn't be unreasonable to expect them to sanitise the links that they accept. Maybe they even do this already, anyone?
-
-
Monday 3rd September 2012 20:02 GMT skeptical i
Thank you -- I too have avoided the shortened URLs since I first saw them ...
... and have actually been surprised (and at the same time not surprised) to see even more options -- bit.ly, youtu.be, and some custom jobs for a handful of newspapers. I don't wish ill on anyone, but jheez, anyone who clicks blindly on such things is walking into a crack-addict whorehouse without a condom.
To the list of potential disease I'd also add the URL's that are created by certain newsletter services to track clickthrough data for the newsletter hosts (I'm looking at you, ConstantContact, but you are far from alone). Once upon a time CC's URL's had a base URL, some hash number, and then the real URL at the end (so one could copy-paste the end into another browser window or tab, dehexify the non-alphanumerics, and surf relatively unimpeded). Now it's all a mess and having to go and track down the information independently in order to find a legitimate URL to forward on to colleagues is not at all convenient. Blame must be liberally spread on the newsletter authors, though (usually the marketing department) who lazily use the "create link" (or whatever it is) tool instead of including the real URL as text in the article ("oh, but those long URLs are so unsightly" -- yeesh).
Alas, I'm preaching to the saved and the perpetrators will just. not. get it.
-
-
-
Monday 3rd September 2012 22:48 GMT toadwarrior
Re: But, but, but ...
There isn't anything strictly wrong with them. I've wrote my own which also allows easy access to a preview page showing the real URL and a clickable link to it along with some other stats. If I ever allow anyone to use it and it takes off then anyone could script something to catch the links and redirect to the stat page for extra safety. You can do that with any other URL shortened with similar methods.
-
-
-
-
-
-
Tuesday 4th September 2012 09:43 GMT hklevjer
Re: Humph!
What Google Chrome doesn't support is the immediate rendering of a redirected (data URI stored) web page.
If you open a tinyURL pointing to a data URI in Chrome, an "unsafe redirect" error will show, but the URI presented at the address bar. This URI must be focused and reloaded (click the address + ENTER) and the page will load in Chrome.
HOWEVER, if no redirection service is used, Chrome has no problem showing data URIs.
Try copying this into the address field, or make your own anchor link to it: data:text/html;,<marquee>foo</marquee>
-
-
Tuesday 4th September 2012 09:35 GMT Anonymous Coward
Re: Humph!
> Wait, I guess I can still do this. Somehow using TinyURL takes the fun out of it though.
RequestPolicy comes up with a redirect warning to "data:text/html . . ." in firefox, allowing a chance to deny it. Probably not an ideal solution, but I don't see any realistic reason to whitelist URL shorteners.
-
-
-
-
Monday 3rd September 2012 19:57 GMT Synja
Re: And yet...
Irrelevant. I can stick an exploit into 26KB, with more than enough space left for a well designed page.
User input is *not* needed at this point. Even if we need to stick a payload onto a "hosted web site on a routable domain", that's difficult to detect and negate. I can run a few hundred free .tk domains on free hosting with a few thousand bit.ly's holding the URIs... and I won't get caught nearly as easily or quickly as I would if I had the landing page hosted on a traditional server.
Payloads are easy to hide, landing pages are not. What's even better, it's trivial to pull a quick double meta refresh on the shortened URL, thereby hiding traffic sources and making it harder to track things in any direction.
-
Tuesday 4th September 2012 09:49 GMT Russell Hancock
Re: And yet...
You don't need to host any web page - simply have the submit button trigger some javascript that reads the form fields and emails it to a free email account - GMail / Hotmail / etc, that way no backend servers, no traces to you...
Or as others have said simply embed a virus / trojan in the URI...
-
-
Monday 3rd September 2012 22:44 GMT Anonymous Coward
Shortcoming in Firefox, Opera browsers
> A shortcoming in browsers including Firefox and Opera allows crooks to easily hide an entire malicious web page in a clickable link ..
What OS do these malicious web pages run on, that will allow access to the underlying OS and can be leveraged for compromising the computers?
-
Monday 3rd September 2012 23:24 GMT Synja
Re: Shortcoming in Firefox, Opera browsers
>What OS do these malicious web pages run on, that will allow access to the underlying OS and can be leveraged for compromising the computers?
In most cases, only a generic exploit within a browser or plugin is needed. An effective compromise rarely requires root/admin/whatever access to the system. *Actively* stealing keystrokes requires fancy programming, AV evasion, and somewhat complete access to the underlying system; stealing stored passwords from a browser rarely requires any real effort once you have the ability to execute code in any way. The same can be said for botnet creation, you simply do not need complete access to the system for it to be useful.
-
-
Tuesday 4th September 2012 00:00 GMT Snafu 2
A couple of points ( apologies for not reading all comments so far)
>It negates the need to find somewhere to secrete your malicious page, and once shortened using a >service such as TinyURL, the URI can be reduced to a small URL perfect for passing around social >networks, online chats and email. Crooks would still need to set up a server to receive data from victims, however.
Does this affect TinyURL's 'Preview link' option? If so, it sounds like a genuine worry; if not, the 'preview' has ben available for a number of years, so les of a worry unless someone has come up with a genuinely new attack vector
>Google’s Chrome browser blocks redirection to data URIs, and other browsers have limits on the volume >of data that can be packed into URIs. Klevjer created a 26KB attack page that failed to load in Internet >Explorer, but worked on both Firefox and Opera.
WHICH VERSION(s)? El Reg should know better than to post a story like this without giving at least some essential details in the main blurb
Caveat: I've played with some code (including HTML) 15 or so years ago but I am not in any way a programmer, developer or web designer; those jobs I pass to someone who can do them properly (or at all)
-
Tuesday 4th September 2012 03:55 GMT Old Handle
TinyURL preview faithfully shows the URI. Of course not everyone knows how to turn that on, or would recognize that a bunch of base64 data there is suspect.
Still, I'm not overly worried about this as an attack vector. But I'm a little surprised the technique doens't see a little more use in general. You can use the same thing to embed images for instance, you'd think someone could find a good use for this. Custom smilies maybe?
-
-
Tuesday 4th September 2012 01:30 GMT Anonymous Coward
This has been known for a LONG time. See http://edgeguides.rubyonrails.org/security.html under heading 4.1.1 Self-contained XSS.
In this case it seems more of an exploit in the redirection services.
You could do something similar using just regular JS in pretty much any browser, example here - http://pastebin.com/9JJJNfpY
-
Tuesday 4th September 2012 09:41 GMT hklevjer
To clarify
As the author of the cited paper, I feel that I have to clarify a few issues here:
As well as Opera and Firefox, Chrome too "suffers" from the ability to host data URIs. It just distrusts being redirected to one. IE (it is said) has a size limit to data URIs of 32 KB. However, in my tests, a ~26 KB URI was tried, unsuccessfully.
The data URI phishing pages can be made in many ways, differing in how they use other data. One can make a true offline (or local) version of a web page if all linked content on the page is contained in the "root page" through yet another data URI.
If the data URI web pages are presented on a computer running a related trojan program, this program may handle the communication of the "secret information" (credit card #, passwords, etc.). This can be done P2P (as in botnets) thus no need for server infrastructure.
Another issue I'm discussing in my paper (http://klevjers.com/papers/phishing.pdf) is that of ownership to the data URI contents. I feel TinyURL unwittingly takes ownership of whatever content that is hosted there, as they store the entire (phishing) web page on their servers.
-
Tuesday 4th September 2012 09:44 GMT Steven Roper
There's another reason
to avoid URL shortening services; it's one reason why I've blocked more than 100 of them at my company's firewall, and continue to add others as I find them.
That reason is perhaps best explained by this ArsTechnica article.
In short, there are trolls who think it's funny to post shortened-URL links to law-enforcement-monitored child pornography honeypots. Click on that, and your IP address gets logged by a law enforcement agency, who then come looking for child porn at your home. Given today's witch-hunt mentality in this arena, what that amounts to, especially if you are male, is that Your. Life. Is. Fucked. Innocent or not.
So in order to protect my staff and our business from this kind of fuckery, in addition to the aforementioned possibility of attack vectors and phishing sites all too often linked to by these services, I've chosen to globally block every URL shortening service I can find at the firewall. There are occasional complaints here and there, but I think most of my team understand the reasons why I won't allow these services at work.
-
Tuesday 4th September 2012 15:24 GMT Anonymous Coward
So let's BREAK URI then...
except, everything I try fails.
I have two tests. one is a published version, the other a local version.
I been trying proxomotron, squid, Advanced Proxy, and URL filter.
Still the crap gets loaded. I don't compile a nightly firefox, even if I could find the part in it to BREAK URI's!
All I can figure is put the browser in a VM which resets after closing. Let it get hacked, nobody cares.
I've known about URI's for years, but I never thought of them as an attack vector until yesterday.
Fucking Genius hack.
Now it needs to be broken, perhaps a switch in about:config?
Unfiltered with Prompt | Filtered Local | Filtered Remote | filtered local and remote ya know what I mean here.
anyway.. it ain't the end of the world yet.