I remember using and understanding a terminal for the first time: That feeling when you realize that you are able to reach every file, run every pr...
For further actions, you may consider blocking this person and/or reporting abuse
This is awesome 😂 Thanks for sharing!
Great to see these explained. You might put a warning at the top, though:
...just for the readers who might not have caught how evil "evil" really is.
Thank you for this suggestions, I put that warning in! ⚠✔
Oh my... This is like a BOFH toolkit! (If you don't know what BOFH is, Google it. IT entertainment from the early to mid-90s).
Well, yes you can see it this way 😅 but this post was completely meant for self protection not for making it easy for attackers... So I hope there are no BOFHs here... 🙊
A few of these scared me most in how easy it would be to make that mistake.
Yes same here. That was one of the reasons to write this post. However I read that some of these depend on the Linux distribution, but I wouldn't count on that. I was really surprised to see, that
chmodandchownboth have a--preserve-rootand--no-preserve-rootflag to prevent misuse, but the default argument is--no-preserve-root! So if you run a command without a "preserve" option, it will default to "no preserve" mode and hence change permissions on a lot of files that shouldn't be changed.I was thinking the same thing. Right up there with etherkillers.
If you don't know what an etherkiller is Google it. Basically an etherkiller is a modified ethernet cable that is hooked directly to a 110/220 power cord there are variations of that theme.
Wikipedia: The Bastard Operator From Hell (BOFH) is a fictional rogue computer operator who takes out his anger on users and others who pester him with their computer problems, uses his expertise against his enemies and manipulates his employer.
Hope this saves someone a couple of keystrokes.
The idea of googling it was for people to find the jokes, not the definition. ;)
It is better to use /dev/urandom
It is a PRNG and thus faster. /dev/random needs enough entropy otherwise it'll block.
I see, thanks for your suggestions! I updated the post accordingly ☑
4) on steroids (much much faster than dev/urandom):
WARNING: THIS COMMAND WILL DELETE YOUR ENTIRE HARD DRIVE
we are using AES cipher of openssl in parallel mode to encrypt a stream of plain zeros with some random pw. this will look like random data. then we write to sda
"How to prevent possible damage"
Alias - prepend the command with a \
Presuming
alias ls='ls --color=auto'lswill show directories in colour\lswill not.Recursion - don't be root. Have user accounts limited in what resources they can use (CPU, disk space etc.)
dd- again, don't be root. Don't be in thediskgroup either.chmod- don't be root.How is this supposed to be for self protection? This is like writing an article with step-by-step instructions on how to buy illegal goods and saying, "I'm telling you this for your own self-protection so that you don't buy illegal goods."
Like the fork bomb - nobody is going to accidentally run that, so there's no "protection" element to this knowledge. However, some irresponsible kid or disgruntled employee out there will probably use this for evil purposes....
Thank you for posting your concerns. Let me explain, why your comparison doesn't work here. The bash is basically a very good thing (illegal goods are not) that gives you great power over your system. With that power comes great responsibility and I wanted to show, how a typo or copied code (like the fork bomb) can easily harm your system and lead to data loss, if you don't really understand what you're doing.
Yes, bash is good but this is not an article in how to do good things with bash with a disclaimer to be careful. This is a collection of ready-to-use recipes for attacks.
With my comparison, I'm not saying the internet is evil and is only used for buying illegal goods. I'm saying that the internet CAN be used for evil purposes just like shells can be used for evil purposes. This article doesn't help understand how to properly use bash and in some cases it's not even specific to bash. All this article does is explain how to perform attacks.
Thank you for your answer. I think we just have two different perspectives on this article here. My intention was to draw attention to how simple it is to make something wrong in bash. I can't change the fact that it's that simple. But I can spread awareness to help people don't make these mistakes. And given the positive comments on this article, I'm glad that it's seen this way.
And yes indeed, an evil person could use these commands to perform attacks. But it will always be the case that things with great impact are misused. How is it possible to spread awareness when you're not allowed to talk about it because somebody could misuse this information?
Evil people probably won't bother to leave positive comments, so I wouldn't judge the impact of your article based on a few positive comments.
Articles that are truly designed for positive security impact usually focus on mitigation and prevention. Here you have almost none of that info. It's more like a "look at all the ways I know how to mess up a system - you can copy and paste these!"
It's great to discuss security risks, but if you don't talk about techniques for prevention, then it's really just a cookbook of evil recipes.
Thanks again for your explanation. I agree with your last point, so I added a 🛡 section for each point explaining some ideas of prevention for the corresponding bash command.
I KNEW I'd see rm -rf on here, but the alias was a fun twist.
And you managed dd ♥️
Backstory: I see more than a few of these, but they'll show rimraf and skip over dd. This one... Yes. These are evil. You've earned your 🦄 lol
Thanks 😊
Yes I thought
rm -rfis very well known and therefore too boring 😅Ah. So
rm -iis often seen as a solid protection, but it's really not.rmasks in some cases anyway, particularly cases such as where you own the directory bu not the files within it. Those are outstanding cases, and using-imeans these no longer stand out.Secondly, I find it encourages people to use
-fa lot, which is just bad behaviour outside of scripts.-freally shouldn't be used in an interactive shell - exceptional cases will no longer be asked about, and errors are lost.Thirdly, try this, probably in an isolated environment like a docker container:
I'll leave how to safely delete that
-ffile as an exercise for the reader...Wow, I didn't know that it's working like that! Thank you for pointing out, that
-iis no solid protection.This is not really safe... you still can call :
Thank you for pointing out, I agree that
ddcan still be executed this way. Do you have another suggestion for a complete deactivation of this command?Good question, my point was about learning dangerous command to use them with caution more than trying to avoid them with aliases and stuff like that... dd is a useful command if you know how to use it :)
That's exactly what I was trying to show in this article. Most of the commands are very useful, it's just very easy to damage your system by mistake, so I tried to give some ideas of how to protect yourself from making these mistakes.
Thank you for sharing horrible commands we should take care of...
About N5 if you have a good IDE like vscode you can get back to it and there is a way like ctrl+z.
However it will become so much difficult if there were lots of changes.
You're welcome!
Yes you're right, with the help of external tools it might be possible to recover the data. I did this a few times with Sublime Text...
I wonder if 7. is actually that bad. If everyone can do everything everywhere, you (being a user among everyone) should have write access to everything as well, in particular all access properties, so you can set everything back to what it's supposed to be, although admittably you'll be busy for a while. The only risk is if you have some background process that messes with everything it gets access to, which is unlikely on a Linux and not sure if the command works under WSL.
For 8, I don't really see how it would hurt if root owns everything. Isn't that even a common pattern on certain server types?
I'm surprised that 9 is a thing, would've expected fsck to be smart enough to keep encryption apart from an actual mess (although arguably, it can be considered such in case of a ransomware attack, but that's nothing that can be fixed automatically anyway).
just tried 1 command yesterday I'm commenting today to say that this post is savage hahaha
😅 Which command did you try?
You're very welcome. Thanks for sharing this repo, didn't know about this! There are even a lot more evil commands!
Nice post, the cd alias was a evil trick, some debate and experiences here: twitter.com/co7wt/status/120465628...
Thank you!
You should cover the move command too. Applied to root makes a good damage!
For this to work sysrq doesn't have to be enabled via sysctl. The "o" command does an immediate power off. Very useful when you have an angry office mate who can't stop complaining about the memory usage of his/her linux workstation. This will definitely fix it. Works on servers and VMs a well. You can lure your most hated co-worker into adding this into cron.
rm -rf /sys/firmware/efi/efivarsactually works on some systems with poorly implemented UEFI, and that command is something that even an attempted reinstallation won’t fix on the systems affected, since in those cases it bricks the motherboard.A coworker did an:
rm -rf /etc once...
Luckily we had an exact server with same config in the other rack an we restore it without service disruption
I wish a had a camera!
Thank you for sharing this story. This emphasizes again how important backups are (in whatever form)!
What about messing the order of filters and actions with the find command? Consider for example:
instead of
This article enforced my desire to deconstruct all commands I find on any help page when trying to fix or set up something new on my recently installed Linux home server! XD
Interesting! Thanks for sharing!
You're very welcome. I'm glad if it's useful for you!
did not know the forkbomb :)
nice and entertaining article :)
I'm glad you liked it!
Great article! The fork bomb is very funny.
I think you can still comeback from number 5 using git reflog, but it won't be funny :p
Thank you 😊
I don't think it's possible to recover uncommitted changes with
git reflog. This would only help people who actually had committed something.But I read that if lost changes are in files that were earlier added to the index (with
git add) it might be possible to recover the data withgit fsck --lost-found.GG, ty for share
Nice!
You can also use shellfirm plugin, which can prompt you a double verification on some risky pattern
github.com/kaplanelad/shellfirm
I had the experience with 7., it was not funny, I lost my project files and had to do a complete reinstall.
Thank you for sharing this
Nice post
Thank You 😊
Your article was translated and reprinted on qiita.com .
Bashの邪悪なコマンド9選
qiita.com/rana_kualu/items/be32f83...
Thank You for this information - I already knew that 😇. ラナ・クアール asked me on Twitter for permission to do that.
alias cd='rm -rf'
Who the hell would be dumb enough to do that? Especially with a standard command that's probably used 10 million times a day world wide.
Once I was fixing something for my coworker at his keyboard. After firing "chown - R user:group ./" I asked: "umm... What path are you in?" He was in /var. We ended up restoring the whole filesystem
I agree with Jason C. McDonald - That title should've contained a Warning. I never would have made a post like that for non-experienced users to read.
Thank you for posting your concerns. I think the title and the introduction make it more than clear, that the bash commands presented in this article should be handled with care. Those who don't read properly and execute sth they don't understand and just copy-pasted - sorry but maybe they have to learn the hard way at least once.
It's a bad idea to post this article IMO. It just allows script kiddies and numbskulls with access to be destructive. The best security is not telling anyone.
Thank you for your comment. I disagree with your last sentence, I think it's essential to discuss security issues and possibilities for prevention. So I added a 🛡 section for each point explaining some ideas of prevention for the corresponding bash command.
I got goosebumps through 1-4. This is really scary.
I've experienced number 7. 🤦🏽♂️
Darn you apache2!
Indeed it is!
I'm sorry to hear that, did you manage to restore the system?
Not at all. Thanks to git and Dropbox, my stuff was safe. I had to do a fresh install right after
Backups ftw! 💪🏻
doas is the root of all evil