back to article 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 …

COMMENTS

This topic is closed for new posts.
  1. Miek
    Trollface

    "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?

    1. JDX Gold badge

      Techie != programmer. And loads of developers never work on web stuff.

      1. Destroy All Monsters Silver badge
        Headmaster

        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].

    2. Anonymous Coward
      Anonymous Coward

      Of course I do...

      ..just like you know what rtp payloads 0, 8, 18 are better known as; after all it is a techie site.

      1. This post has been deleted by its author

  2. Anonymous Coward
    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.

    1. NozeDive
      Pint

      Re: But, but, but ...

      Took the words right out of my mouth.

      Cheers.

      1. Pat 11

        Re: But, but, but ...

        Doesn't need to host a webpage on a server, just a backend. Less, and unconspicuous, traffic I guess. Pretty clever, the example in the pdf works but it made a lump of my screen go black fro some reason!

    2. 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?

      1. Shannon Jacobs
        Holmes

        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.

    3. Ian McNee
      Boffin

      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?

      1. Steve Knox
        Holmes

        Re: But, but, but ...

        So effectively this vulnerability makes shortening services attack sites ...

        NEWSFLASH: Obfuscation can be used for attack purposes.

        I've been steering clear of such shortening services since I heard of them for this very reason. Same goes for those stupid QR codes.

        1. skeptical i
          Meh

          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.

      2. Anonymous Coward
        Anonymous Coward

        Re: But, but, but ...

        Thanks, your explanation makes sense.

        Ouch.

    4. mistergrantham

      Re: But, but, but ...

      stop your blithering man!

    5. diodesign (Written by Reg staff) Silver badge

      Re: But, but, but ...

      No, the shortened URL redirects to the data URI that the shortener has stored against the hashed short URL.

      C.

    6. 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.

  3. Old Handle
    Trollface

    Humph!

    I am very disappointed that El Reg's comment section does not support data URIs! Please correct this as soon as possible.

    1. Old Handle

      Re: Humph!

      Wait, I guess I can still do this. Somehow using TinyURL takes the fun out of it though.

      1. Anonymous Coward
        Thumb Up

        Re: Humph!

        clever. good example. well done

      2. Gordon Lawrie
        Thumb Up

        Re: Humph!

        Genius!

      3. nuked
        Trollface

        Re: Humph!

        I clicked it. Am I now infected with this URI (not to be confused with the other virus, URL) ?

        1. Field Marshal Von Krakenfart
          Joke

          Re: Humph!

          nuked wrote:

          I clicked it. Am I now infected with this URI (not to be confused with the other virus, URL) ?

          Just be glad it's not an UTI you're infected with

          Hmmmm, decisions, decisions, Paris or Joke icon

      4. David Webb

        Re: Humph!

        I'm guessing Googles fixed chrome already, clicking the link brings:

        Error 311 (net::ERR_UNSAFE_REDIRECT): Unknown error.

        Clicking refresh brings out what you had desired which is pretty damn sweet.

        1. Anonymous Coward
          Anonymous Coward

          Re: Humph!

          I wonder if ANY of you guys read the story. He's not a genius, he did exactly what the article describes, putting the data into a redirection service.

          Secondly as the article states, it affects Firefox and Opera, not Chrome.

          1. Old Handle

            Re: Humph!

            Also apparently not IE, amazingly enough.

            And while don't deny being a genius, I readily admit this did not demonstrate it. I'm a little pleased with myself for being the first one to do it though.

          2. 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>

      5. Dan 55 Silver badge
        Happy

        Re: Humph!

        It's a pity you didn't include a form and allow it to be submitted, I'm pretty sure there's someone out there would have filled it in.

      6. Anonymous Coward
        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.

  4. Matt Bradley
    FAIL

    And yet...

    And yet the final destination for any user input still has to be a hosted web site on a routable domain.

    Thus, this technique achieves precisely NOTHING in its supposed aim of avoiding the need for a hosted component to the attack.

    1. 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.

    2. Anonymous Coward
      Anonymous Coward

      Re: And yet...

      Why? You got them to click one link. You can get them to click a second one. In your first one, simply write to a local file. Use the second one to get the data out.

    3. 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...

  5. Anonymous Coward
    Linux

    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?

    1. 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.

    2. Anonymous Coward
      Anonymous Coward

      Re: Shortcoming in Firefox, Opera browsers

      As pointed out, more likely for a phising scam, so OS is irrelevant.

  6. Anonymous Coward
    Anonymous Coward

    NoScript

    NoScript disables javascript:// and data:// URLs by default since forever.

  7. Roger 11
    FAIL

    I blame Twitter

    That is all.

  8. 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)

    1. 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?

  9. Anonymous Coward
    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

  10. Anonymous Coward
    Anonymous Coward

    I am never clicking tiny URLs

    i just can't trust it.

  11. Bodestone

    I want

    Right click, view in http://longurl.org/

    Also for tinyurl and bit.ly to disallow using data URIs

    1. TRT Silver badge

      Re: I want

      There's a plug-in for Safari that does that...

  12. 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.

  13. Steven Roper
    Childcatcher

    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.

  14. Anonymous Coward
    Anonymous Coward

    "Klevjer created a 26KB attack page that failed to load in Internet Explorer, but worked on both Firefox and Opera"

    So remember children, Firefox and Opera have no vulnerabilities, and we must all switch to them now!!!

  15. Anonymous Coward
    Anonymous Coward

    Yeah and Firefox is open source, so all those users who are affected by this can simply dive into the code and fix the security hole themselves. Simples innit !!

  16. Anonymous Coward
    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.

This topic is closed for new posts.

Other stories you might like