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.
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.
And you better inspect and execute a downloaded copy, because a malicious actor can serve a different file for curl/wget than to your browser
They can even serve a different file for curl vs curl|bash
Does curl send a different useragent when it’s piped?
Searching for those words just vomits ‘hOW to SeT cUrL’s UseRaGenT’ blog spam.
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.
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.
Yeah that do, I remember that the demo was pretty impressive ten fifteen years ago!
Hit the nail on the head. Download the file, inspect, then run that local copy.
Yep! That’s what the post shows.
I created a live demo file, too, so that you can actually see the difference based on how you request the file.