A sneaky demonstration of the dangers of curl | bash - k3can blog
blog.k3can.us

I set up a quick demonstration to show risks of curl|bash and how a bad-actor could potentially hide a malicious script that appears safe.

It’s nothing new or groundbreaking, but I figure it never hurts to have another reminder.

    • deadbeef79000@lemmy.nzEnglish
      4·
      12 hours ago

      Does curl send a different useragent when it’s piped?

      Searching for those words just vomits ‘hOW to SeT cUrL’s UseRaGenT’ blog spam.

      • Flipper@feddit.orgEnglish
        11·
        11 hours ago

        Its timing based. Ehen piped a script, bash executes Dach line completly before taking the next line from the input. Curl has a limited output buffer.

        1. Operation that takes a long time. Like a sleep, or if zou want it less obvious. A download, an unzip operation, apt update, etc.
        2. Fill the buffer with more bash commands.
        3. Measure on the server if at some point curl stops downloading the script.
        4. Serve a malicious payload.
      • qupada@fedia.io
        3·
        12 hours ago

        Not that I know of, which means I can only assume it’ll be a timing-based attack.

        With strategic use of sleep statements in the script you should stand a pretty good chance of detecting the HTTP download blocking while the script execution is paused.

        If you were already shipping the kind of script that unpacks a binary payload from the tail end of the file and executes it, it’s well within the realm of possibility to swap it for a different one.