Slashdot Mirror

← Back to Stories (view on slashdot.org)

Pastejacking Attack Appends Malicious Terminal Commands To Your Clipboard (softpedia.com)

Posted by BeauHD on from the look-behind-you dept.

An anonymous reader writes: "It has been possible for a long time for developers to use CSS to append malicious content to the clipboard without a user noticing and thus fool them into executing unwanted terminal commands," writes Softpedia. "This type of attack is known as clipboard hijacking, and in most scenarios, is useless, except when the user copies something inside their terminal." Security researcher Dylan Ayrey published a new version of this attack last week, which uses only JavaScript as the attack medium, giving the attack more versatility and making it now easier to carry out. The attack is called Pastejacking and it uses Javascript to theoretically allow attackers to add their malicious code to the entire page to run commands behind a user's back when they paste anything inside the console. "The attack can be deadly if combined with tech support or phishing emails," writes Softpedia. "Users might think they're copying innocent text into their console, but in fact, they're running the crook's exploit for them."

45 of 89 comments (clear)

  1. Misfeature by vux984 · · Score: 5, Informative

    This was *always* a mis-feature and it should simply be disabled at the browser level to permanently ignore.
     

    1. Re:Misfeature by fustakrakich · · Score: 3, Informative

      Advertisers have been doing this for years with all sorts of their stuff attached to the paste. Is there an extension that can disable it?

      And don't people read what they pasted into the terminal before hitting the Enter key?

      --
      “He’s not deformed, he’s just drunk!”
    2. Re:Misfeature by fisted · · Score: 4, Informative

      I'd venture a guess that the paste ships with the newline already...

      --
      CLI paste? paste.pr0.tips!
    3. Re:Misfeature by Anonymous Coward · · Score: 3, Interesting

      What is ‘this’ in your sentence? CSS? Copying in general? All the page does is use some CSS to move part of the text off-screen where it cannot be seen.
      Detecting what is and isn't visible when copying text is a non-trivial task, as is defining what visibility means: obviously when you press Ctrl+A, Ctrl+Ins you want the entire document, even those parts for which you'd need the scrollbar to read them. But what if text is placed in such a way that it's always inside the scrollable region, but outside the visible window client area?
      And so far there have been no successful attacks based on this mechanism. It is hard to exploit, it requires the victims to paste console commands (that reduces your audience quite a lot, most people never use the console), it likely requires specific environments, it requires the console to execute it immediately rather than show it, and it's really obvious to victim that something is up, even when, especially when, it doesn't work.
      So, a very difficult and low-priority feature then.
      And one might wonder if it's really the browsers which need to fix this. I think it would help a great deal if terminals detected if the text likely came from the web (this can be checked since when you copy from a browser, HTML gets put on the clipboard as well as a plain text version). One of the most dangerous aspects of this attack is that the BR-tag must translate to a newline, and terminals execute commands when they encounter newlines. If the terminal would simply show these newlines on the prompt and only execute stuff when the user actually presses enter, most of the attack surface would be gone.

    4. Re:Misfeature by fustakrakich · · Score: 1

      Yeah, you gotta be careful not to copy that. I only had to get burned once.

      --
      “He’s not deformed, he’s just drunk!”
    5. Re:Misfeature by Anonymous Coward · · Score: 1

      It is pretty clear that the people over reacting to this are those who don't understand the markup/stylesheets.

      This isn't a issue that should be dealt with on the browser end. Pretty clear this is a PEBKAC error.

      Users should clearly inspect any commands before they copy and paste them to their terminal.

      If I ever paste anything into terminal I always paste it into a text editor first.

    6. Re:Misfeature by Snotnose · · Score: 1

      How do I disable it at the browser level?

    7. Re: Misfeature by Anonymous Coward · · Score: 1

      I understand the markup/stylesheets are a hotbed of vulnerabilities stacked a mile deep. I understand that ctrl+c should copy the visibile highlighted text only, not some backend hidden obscure bullshit. I understand that this shit should be disabled at the browser level, and ideally at the fucking spec.

    8. Re:Misfeature by viperidaenz · · Score: 4, Informative

      Disable Javascript and CSS, or don't copy and paste web content in to your terminal.

      The CSS method puts an inline span in the middle of what you're supposed to copy and gives it an absolute position so it's out of the visible area. Being inline, the browser doesn't care it's been re-positioned and adds it to the selected content.

      The Javascript method, I assume listens for the selection events and insert inline content into the selection at a place on screen you can't see.

    9. Re:Misfeature by skids · · Score: 1

      Newlines are one thing. but browsers should not be allowing escape sequences to get into the paste buffer. Which, by the way, is why you cannot use most text editors to check what the clipboard contains without taking special measures.

      ("xclip -o > file.txt" and "xclip -selection prmary -o > file.txt" are your friend.)

      --
      Someone had to do it.
    10. Re:Misfeature by Zeroko · · Score: 1

      I just tried pasting ESC [ A (with character 27 in place of ESC & without the spaces) into a terminal, & it switched to the last history entry (& kept going back with more pastes). That may be the sort of escape sequence that was meant. So keyboard commands for terminal-based applications (someone mentioned there is an example exploit for vi) should work.

    11. Re:Misfeature by Anonymous Coward · · Score: 1

      Just my opinion, but seems to be more of a problem to be handled on the terminal application level than in the browser.

      Check out this link regarding bracketed paste mode.

    12. Re:Misfeature by johannesg · · Score: 3, Insightful

      Disable javascript and CSS. Then disable the clipboard and the graphical environment. Then format your harddisk, take apart your PC, and throw every part into a fire. It will hurt as they burn, but at least you will be still alive.

      Seriously, what sort of shitty advise is "disable javascript and CSS"? Might as well tell people to only ever browse with Lynx. Which basically means 'giving up on the world wide web as a whole'. That seems a rather drastic solution for working around a very, very minor problem in the first place. For one thing, if you run Windows none of this is a problem, so 99% of the worlds' population is already safe by default...

    13. Re:Misfeature by operagost · · Score: 1

      Actually, this is still a problem with Windows because you could paste this crap into a cmd or Powershell window just fine.

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    14. Re:Misfeature by Hylandr · · Score: 1

      I always paste into Notepad to remove the extra junk anyways. I too would love to see that extra copy BS die in a napalm fire.

      --
      ~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
    15. Re:Misfeature by vux984 · · Score: 1

      Actually the browsers need to be updated to fix this.

      The Javascript oncopy event maybe shouldn't even be fired by default on untrusted sites.

      The default copy to clipboard action should ignore hidden divs, inline spans to offscreen locations, etc.

      The default copy to clipboard action should perhaps ignore html/css entirely and just copy selected plaintext. Because I can see other vectors for attack, not just the terminal.

    16. Re:Misfeature by tlhIngan · · Score: 1

      What is âthisâ(TM) in your sentence? CSS? Copying in general? All the page does is use some CSS to move part of the text off-screen where it cannot be seen.
      Detecting what is and isn't visible when copying text is a non-trivial task, as is defining what visibility means: obviously when you press Ctrl+A, Ctrl+Ins you want the entire document, even those parts for which you'd need the scrollbar to read them. But what if text is placed in such a way that it's always inside the scrollable region, but outside the visible window client area?

      You forgot about Unicode, where one visible character you see can easily consist of 4-5 or more codepoints that get copied as well. There are a few deadly sequences that can screw up your terminal if it's Unicode aware.

    17. Re:Misfeature by vux984 · · Score: 1

      That seems a rather drastic solution for working around a very, very minor problem in the first place.

      Clipboard attacks could do all sorts of nastiness. What if they used javascript to dynamically attach a media container with a malicious file, knowing that you are pasting it into word or excel or something which will activate that container outside of the browser sandbox.

      For one thing, if you run Windows none of this is a problem, so 99% of the worlds' population is already safe by default...

      Because there is no command prompt in windows? And there aren't any sites on the web where you might be instructed to open a command prompt and copy/paste a bit of script... to clean up a virus infection, or disable telemetry, or whatever.

      There's aren't any sites on the web where admins are given snippets of powershell to copy and paste ... to setup some feature of hyper-v server; configure some firewall rules, or whatever.

      There aren't any sites on the web where programmers are copy and pasting bits of script and code to tools like R Studio? Or an interactive shell for ruby, python, javascript.

      Not to mention the ability to craft malicious content and tack it onto to the clipboard that can crash office suites, etc. (sneak in a deliberately corrupt embedded image, or media container...)

    18. Re:Misfeature by skids · · Score: 1

      In answer to GGP, you may not have been born early enough to have reason to know that "escape sequences" also is used to refer to in-band signalling on TTYs (which, yes, there are some in the other direction than what is covered in that article). As far as this post I mean specifically ascii character 0x1b (U+001B), which browsers will happily allow to be stuffed in the clipboard and which is what makes exploits of pastes into certain text editors possible. A strong argument could be made for certain of the other control characters which are generally only used as hotkeys on terminal apps. Of course you don't want to mess with things actually commonly used as whitespace like tabs.

      To your point, it could also be handled by the desktop clipboard services. Getting sundry terminals and apps to ignore 0x1b from clipboards (we'll call this plan C) is probably harder than (plan A) not putting it in there in the first place or (plan B) banning their presence in the OS/desktop clipboard services. The terminal-based ecosystem does not have this problem internally, because they chose plan A by making certain dangerous characters generate harmless representations on output, which prevents them from getting cut into clipboards (U+001B shows up as two characters "^[" and if you cut and paste it, you paste those two characters, even if the terminal app knows they are just one escape character). It is likely the best choice -- no garbage allowed in, hence no garbage out.

      There is probably little good use for having an 0x1b or several other control characters stored in the desktop clipboard, but there may be some obscure places where that might be handy, and choosing B or C would interfere with that. Plan C also involves going into lots of forks of lots of very old code and making changes, unless you try to use only new shiny terminal applications. Personally I cannot, because all the new shiny ones broke or just failed to implement important must-have features when they were implemented (I'm glaring at you, libvte.)

      --
      Someone had to do it.
    19. Re:Misfeature by vux984 · · Score: 1

      Read your post again.

      Your argument fails for the same reason ActiveX was an atrocity. As long as everybody ELSE does their job properly activeX was fine. But reality doesn't work like that and ActiveX was a horrible security mess as a result.

      The operating system and the browser need to take ownership of the problem and ensure the clipboard is safe.

      The web should be assumed hostile by default. The browser runs in a sandbox by default, and everything coming out of it needs to be carefully screened and sanitized at the point it comes out of the browser. That means the copy from the browser INTO the clipboard needs to be as sane as possible.

      Yes, it can't catch everything; but it should be designed to minimize the possibility of anything unwanted coming out of the browser.

      Yes you are right, that every application that accepts input should sanitize it. But its not realistic, and its not responsible.

    20. Re:Misfeature by vux984 · · Score: 1

      For one thing, they'd need a time machine to travel into the future to the moment when the text is pasted to see which application is on the receiving end so the copying application and the operating can do their filtering job, and secondly there is no way that any application writer can foresee all possible troublesome situations

      I don't care that it can't foresee all possible troublesome situations, you are raising the bar to absurd levels.

      The browser should be responsible for sanitizing what goes into the clipboard to the best of its ability.

      I also note that so far you have given no concrete suggestions on how to go about your solution.

      Except I did exactly that. Numerous times in numerous posts now.

      1) Plaintext only from the browser to the clipboard by default. If the destination app can be tripped up by plaintext that's on the destination app - we can't solve everything unless we unplug the computer and take the battery out. But we can eliminate a lot of attack vectors by only supporting plaintext by default.

      2) What is selected by the user only to the clipboard, to within its best ability -- so no firing a copy event to allow javascript to append shit to the selection. And make a browser best effort to exclude that which cannot be seen -- if the 'selection' can't be scrolled to and isn't visibly rendered, then it doesn't go. There are some issues. By default -- err on the side of caution.

      3) If the user wants to copy and image, they have to use the copy image right click menu or a 'snipping tool' by default.

      Scenario 1... Scenario 2...

      4) At the OS level when pasting things FROM an the browser, a preview should be displayed that has to be approved before it's passed to the destination app. So the user can see and even edit the plaintext they are about to paste regardless of what app it goes to.

      Make this customizable; make it intelligent. I've got a dozen ideas-- whitelisting apps, greylisting apps -- pasting plaintext to Word is safe... to cmd.com; terminal.app; RStudio.exe etc ... is not safe. etc. Yes you won't know about every app ... etc. But defaulting to 'unsafe - requires preview' and whitelisting the 1000 most common apps that are safe out of the box would make it pretty innocuous. Users could whitelist apps as needed... it could be managed online "antivirus style" where the default clipboard handler for apps are subscribed to...

      I read your post, and i see a defeatist attitude. IF you can't easily do it perfectly then throw your hands up and walk away. Mitigated in nearly all cases is easily achievable. There simply aren't THAT many command/terminal applications in common usage. Get the most common 100 and its probably mitigated to the point of being worthless to even try to exploit.

      Perfect is the enemy of good.

  2. We expect better effort next time. by downright · · Score: 3, Insightful

    Millennial hackers just don't try very hard.

  3. Bracketed Paste Mode by Anonymous Coward · · Score: 5, Informative

    Terminals/shells that support bracketed paste mode don't have this problem.

    When you paste something, it won't execute until you press enter. This helps avoid issues with mistake pastes, and also issues wherein one accidentally copies a newline with the desired text (in this case, you can hit backspace to delete the newline, continue editing the command, and hit enter only when you're done).

    There's a ZSH plugin that adds this functionality:

    https://cirw.in/blog/bracketed-paste

    I love zsh.

    1. Re:Bracketed Paste Mode by peragrin · · Score: 1

      wait which shell automatically executes pasted commands?

      I know bash and powershell(yes I use MSFT powershell) do not.

      --
      i thought once I was found, but it was only a dream.
    2. Re:Bracketed Paste Mode by Anonymous Coward · · Score: 1

      They do if the paste contains a newline at the end (or in the middle).

    3. Re:Bracketed Paste Mode by Anonymous Coward · · Score: 1

      Most shells CAN execute pasted code automatically, because they don't distinguish between user input (i.e. from the keyboard) and the pasted contents. So if the pasted contents have a newline in them, generally the shell will execute the pasted command immediately. For example, if the copied string was "ls\n", the shell would just think the user typed: [l] [s] [enter]

      Most modern terminals will surround the pasted text with escape sequences, which can signal a supporting app (i.e. a shell or an editor) that the input is from a paste, and not directly from the user. However, the shell has to support these escape sequences, and bash does not. ZSH can, with the plugin I mentioned in the OP.

      It's worth noting that this attack has been thoroughly explored (even in a web context, using css and no javascript) at least as far back as 2008 -- probably earlier.

    4. Re:Bracketed Paste Mode by Anonymous Coward · · Score: 3, Informative

      Try again with a newline at the end of the command. That will automatically execute the command as part os pasting it. A malicious script would put a newline at the end so it would run before you had a chance to catch the error.

      Terminal + bash on Mac will execute. As will both Powershell and cmd.exe on Win.

    5. Re:Bracketed Paste Mode by DarkOx · · Score: 2

      are you sure, what happens if you have a \n character embed in the paste text. bash sure executes it in my terminal emulator.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    6. Re:Bracketed Paste Mode by jouassou · · Score: 1

      Now *that* is cool. Definitely gonna check out the vim-bracketed-paste plugin linked at the same page too, I'm also one of those who always forget to :set paste before copy-pasting stuff in, and the autoindent is then really annoying...

    7. Re:Bracketed Paste Mode by Jahta · · Score: 2

      Terminals/shells that support bracketed paste mode don't have this problem.

      When you paste something, it won't execute until you press enter. This helps avoid issues with mistake pastes, and also issues wherein one accidentally copies a newline with the desired text (in this case, you can hit backspace to delete the newline, continue editing the command, and hit enter only when you're done).

      There's a ZSH plugin that adds this functionality:

      https://cirw.in/blog/bracketed-paste

      I love zsh.

      On Windows, if you use ConEmu to manage your shell sessions it will block execution of pastes that contain a Return character (regardless of which shell you are running; works with both cmd.exe and bash) and will warn you about the embedded Return.

  4. I'm wishing for help from terminal programs by John+Marter · · Score: 2

    I know I shouldn't copy and paste into a terminal, but it is so convenient. I don't even need a malicious website to get myself into trouble. I just forget that I copied hundreds of lines right after I copied that filename that I wanted to use. And then boom!, lots of commands entered that who knows what will happen with.

    I've occasionally looked, but never found a terminal to help with this. Probably because they shouldn't encourage my bad habit. But if it would just give me a pop up showing what I am about to paste that would help a bunch.

    1. Re:I'm wishing for help from terminal programs by Fwipp · · Score: 1

      On Mac, iTerm2 will warn you "You're about to paste [1] lines ending in a newline. Are you sure?" Or sometimes "408 lines."

  5. Re:document.execCommand by Anonymous Coward · · Score: 1

    It does work in Chrome on Linux.

  6. Open source unix virus by 140Mandak262Jamuna · · Score: 3, Funny
    Clip board and command line? Wasn't there already a unix virus like that?

    Subject: Unix virus

    You have been attacked by the unix virus. Please forward this mail to everyone in your .mailrc and delete a bunch of files from $home

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:Open source unix virus by BlackPignouf · · Score: 4, Funny

      My favorite is still writing

      echo "sleep 1" >> ~/.profile

      inside the .profile of my colleagues when they leave their terminal open.
      A few weeks after, I complain that my Windows desktop seems to be always booting slower and slower, but that hopefully, it's never been a problem with Linux.

  7. Ye old unix hacks by sg_oneill · · Score: 1

    Reminds me a bit of a hack we used to do in the late 80s/early 90s on the old terminals at uni. For a few seconds during login on the old unix machines, your terminal was world writable. There was an escape sequence that let you bind key sequences to keys (like macros I guess). So we'd sit there watching for that login and blap the terminal with macros, and then take control from there.

    Fortunately it was a more innocent time, so we'd just use it to spam academics with frank zappa lyrics and stupid shit like that, although one guy did write a sort of shell virus that got out of hand *very* quickly.

    --
    Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
  8. Pastejacking? by Ol+Olsoc · · Score: 2

    I remember a kid in second grade who was caught pastejacking in second grade. Sent him away, and never came back. The school had to buy all new paste too.

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    1. Re:Pastejacking? by orledrat · · Score: 1

      I stole a spaghetti once because I was low on dough. Yep. Thank god I didn't grab one of those RFID tagliatelli, like my mate did.. the coroner report says he simply pastaway but he was covered in boils and had that terrible strained look in his eyes :-(

  9. An exploit for your text editor by tepples · · Score: 3, Interesting

    If I ever paste anything into terminal I always paste it into a text editor first.

    Then gosh help you if what you paste contains an exploit for your text editor. There's a vi exploit in one of the examples.

    1. Re:An exploit for your text editor by AmiMoJo · · Score: 1

      That's more of an argument against using vi for handling unsanitized input. Most editors require you to press un-pasteable modifier keys to do anything dangerous or irreversible, but vi's modal design makes it vulnerable.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    2. Re:An exploit for your text editor by tepples · · Score: 1

      I think the idea is to leave insert mode to paste using a dedicated paste command rather than using your terminal's keypress simulation.

  10. Re:document.execCommand by viperidaenz · · Score: 1

    According to https://developer.mozilla.org/... document.execCommand('copy') works on Chrome 42+, Firefox 41+, IE9+ and Opera 29+

  11. Re:Copy all commands into a file first by mugurel · · Score: 2
    cat - > /tmp/emptyfile.txt (then do the paste, and then Ctrl-D)

    This is robust at least against the demo attacks given in the article.

  12. Insecure Terminals are the problem. by Qbertino · · Score: 1

    Terminals/shells that support bracketed paste mode don't have this problem.

    Which should be the default behaviour for all Terminals.

    --
    We suffer more in our imagination than in reality. - Seneca
  13. Re:Copy all commands into a file first by mattventura · · Score: 1

    That could be foiled by putting a ^D in the copied text. The most effective way is to paste the text via the editor itself rather than the terminal ("+p in vim) or via a program like xclip.