Announcement

Collapse
No announcement yet.

Malicious commands you shouldn't run.

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by SeanBond View Post
    Stop tempting me, im going make a VM and do them now lol
    lol. I have........... several times. XD
    Desktop: Intel i5-4690K | 16GB DDR3 | Gigabyte Z97N-WIFI | EVGA GTX 660 3GB | Windows 10
    Server 0: Gen8 HP Microserver | Proxmox Hypervisor Server 1: Gen8 HP Microserver | FreeNAS

    Comment


    • #17
      Can we add the following please:
      Code:
      chmod -R 777 /
      A few muppets from work have managed to break Solaris servers thanks to this gem <_<

      Originally posted by marsey99 View Post
      linux stuff this i think
      it was after reading up on things like this i stopped using unbuntu.
      Not just Linux, but *nix in general.

      Also Windows is more susceptible to attacks like these than Linux is.
      At the end of the day, if you're silly enough to run commands as root/administrator without first checking what they do, then no computer / OS is safe.

      Comment


      • #18
        Originally posted by Plan9 View Post
        Can we add the following please:
        Code:
        chmod -R 777 /
        A few muppets from work have managed to break Solaris servers thanks to this gem <_<
        Done. I have done something similar myself a while ago. Tried to 700 everything in my home folder recursively and forgot I was in the root dir and logged in as root.
        Desktop: Intel i5-4690K | 16GB DDR3 | Gigabyte Z97N-WIFI | EVGA GTX 660 3GB | Windows 10
        Server 0: Gen8 HP Microserver | Proxmox Hypervisor Server 1: Gen8 HP Microserver | FreeNAS

        Comment


        • #19
          -R being revoke?

          ouch yes. much badness there...
          Ryzen 5 1600:: GA-AB350-Gaming 3:: <some other stuff>
          [STILL BEING BUILT!!!]

          Comment


          • #20
            Originally posted by Mr. Grapes View Post
            -R being revoke?

            ouch yes. much badness there...
            Recursive .

            Comment


            • #21
              ah ok, so just insecure then, not revoking all permissions form everything everywhere.

              so in that case, you'd also not want to ever run
              Code:
              chmod -R 000 /
              Ryzen 5 1600:: GA-AB350-Gaming 3:: <some other stuff>
              [STILL BEING BUILT!!!]

              Comment


              • #22
                Originally posted by Mr. Grapes View Post
                ah ok, so just insecure then, not revoking all permissions form everything everywhere.

                so in that case, you'd also not want to ever run
                Code:
                chmod -R 000 /
                Its not that its just insecure. It breaks things. Certain things such as sudo etc... NEED certain permissions or they fail to work. It may even make some boxes fail to boot.
                Desktop: Intel i5-4690K | 16GB DDR3 | Gigabyte Z97N-WIFI | EVGA GTX 660 3GB | Windows 10
                Server 0: Gen8 HP Microserver | Proxmox Hypervisor Server 1: Gen8 HP Microserver | FreeNAS

                Comment


                • #23
                  Originally posted by Lorem-Ipsum View Post
                  Its not that its just insecure. It breaks things. Certain things such as sudo etc... NEED certain permissions or they fail to work. It may even make some boxes fail to boot.
                  Yeah, the /etc/passwd is one such file that's expected to have specific permissions (700 IIRC) otherwise log in managers refuse to work. And if you can't log in, then you've basically bricked your install (I say that, but I think you can still force your way in on many *nixes if you drop into single user mode)

                  Comment


                  • #24
                    Originally posted by Plan9 View Post
                    Yeah, the /etc/passwd is one such file that's expected to have specific permissions (700 IIRC) otherwise log in managers refuse to work. And if you can't log in, then you've basically bricked your install (I say that, but I think you can still force your way in on many *nixes if you drop into single user mode)
                    If you've got physical access then normally you can just boot from a liveCD and reset your password to an empty string by editing /etc/password (and /etc/shadow if needed). Done that plenty of times in the past (though not very recently I'll admit - there may be some reason why this wouldn't work nowadays?). Obviously encrypted file systems etc would cause problems .

                    Comment


                    • #25
                      Originally posted by andyn View Post
                      If you've got physical access then normally you can just boot from a liveCD and reset your password to an empty string by editing /etc/password (and /etc/shadow if needed). Done that plenty of times in the past (though not very recently I'll admit - there may be some reason why this wouldn't work nowadays?). Obviously encrypted file systems etc would cause problems .
                      That wouldn't fix the chmod -R 777 / issue I was referring to though as even a blank password would still need to be recorded in /etc/passwd. The problem isn't the password itself, it the permissions on the key config files.

                      You could use the live CD to chmod the /etc/passwd back to the correct permissions, but if your system supports single user mode log ins then it would be easier to sign in that way. Particularly in server rooms where boxes don't always have CD ROMs hooked up nor KVMs, or the datacentre it remotely located so physical access isn't practical. In those situations you need a fix that would work via the out-of-band management.

                      Comment


                      • #26
                        Originally posted by Plan9 View Post
                        That wouldn't fix the chmod -R 777 / issue I was referring to though as even a blank password would still need to be recorded in /etc/passwd. The problem isn't the password itself, it the permissions on the key config files.

                        You could use the live CD to chmod the /etc/passwd back to the correct permissions, but if your system supports single user mode log ins then it would be easier to sign in that way. Particularly in server rooms where boxes don't always have CD ROMs hooked up nor KVMs, or the datacentre it remotely located so physical access isn't practical. In those situations you need a fix that would work via the out-of-band management.
                        Oh, yeah, I see what you mean. TBH if you've globally reset the permissions on your entire file system your best bet is to revert from a backup, as even if you hacked it back to a usable state there could be security issues further down the line. It's a pretty catastrophic mistake .

                        Comment


                        • #27
                          Old sticky bump, but I'm bored so thought I'd add a couple:

                          Since you have a section on forkbombs, it seems fitting to include one of the most infamous Bourne shell ones:
                          Code:
                          :(){ :|:& };:
                          Also, there's this one which many of the younger Linux users wouldn't be familiar with:
                          Code:
                          init 0
                          All it does is shut the Linux / UNIX box down to maintenance mode. Which isn't a problem on desktops as you can just reboot the thing. However it's more of an issue of you're remotely administrating a Linux dedicated box as you'll lose all network connectivity to it and will need to wait for the datacenter operator to walk over to your rack to power cycle it.

                          Comment


                          • #28
                            Originally posted by Plan9 View Post
                            Old sticky bump, but I'm bored so thought I'd add a couple:

                            Since you have a section on forkbombs, it seems fitting to include one of the most infamous Bourne shell ones:
                            Code:
                            :(){ :|:& };:
                            Also, there's this one which many of the younger Linux users wouldn't be familiar with:
                            Code:
                            init 0
                            All it does is shut the Linux / UNIX box down to maintenance mode. Which isn't a problem on desktops as you can just reboot the thing. However it's more of an issue of you're remotely administrating a Linux dedicated box as you'll lose all network connectivity to it and will need to wait for the datacenter operator to walk over to your rack to power cycle it.
                            Doesn't
                            Code:
                            init 6
                            Do a restart as well?
                            Originally posted by omega
                            He's trying to lick the inside of his brain though, doesn't that count for something??

                            |EVGA GTX 780 Hydro Copper SLI|Intel Core i7 5820K |Gigabyte X99-UD4P|8GB 2133Mhz Hyper X Fury DDR4|2x 120GB Samsung 850 Evo Raid0|3.0TB WD Green|Corsair 650W|LG 29UB65-P|
                            All bundled in a Enthoo Primo under Water.

                            Comment


                            • #29
                              Do a restart as well?
                              Yup, 0 for system halt, 1 for single user mode, 6 for reboot, I think those are pretty much universal across all unixen. The others vary quite a lot though.

                              Comment


                              • #30
                                Originally posted by andyn View Post
                                Yup, 0 for system halt, 1 for single user mode, 6 for reboot, I think those are pretty much universal across all unixen. The others vary quite a lot though.
                                Ah yes. I was getting 0 and 1 mixed up in my post. (though the end result is effectively the same in the context of a data centre dedi)

                                Comment

                                Working...
                                X