SDL Episode88

From Paul's Security Weekly
Jump to: navigation, search

Secure Digital Life #88

Recorded on November 13, 2018 at G-Unit Studios in Rhode Island!

Episode Audio

Coming soon!

Hosts

  • Russell Beauchemin
    Cybersecurity & Network Security Program Advisor and Director of Instructional Support & Learning Innovation at Roger Williams University.
  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Announcements

    • If you are interested in quality over quantity and having meaningful conversations instead of just a badge scan, join us April 1-3, at Disney's Contemporary Resort for InfoSec World 2019 where you can connect and network with like-minded individuals in search of actionable information. Use the registration code OS19-SECWEEK for 15% off the Main Conference or World Pass.
    • Join us for our Webcast with Signal Sciences entitled Which way should you shift testing in the SDLC? This webcast will be held November 8th @3-4pm EST. Go to securityweekly.com/signalsciences to register now!

    Topic: Permissions and Privileges



    So, one of the main ways that hacking got started was through two main avenues, privilege escalation and file privilege exploitation. None of this is fancy stuff but it's still the way that so many things get hacked.

    First, let's talk about default users in systems. In the unix world, that user is now and has always been root. As in, root giveth and root taketh away. For as long as unix has been around, the root user has been the meta user of the system. Delete that account, you're done. So, it has to be there. Windows, does the same thing with Administrator. Basically, if you have access to this account, you can create permissions, change permissions, create and delete users, and even create new root users and administrators. So, this tree starts with these accounts. If root creates a new account called dwhite and either gives dwhite the root password (which all too often is toor), then dwhite can also be root in a kind of roundabout way. Same thing in windows with administrator. There is also a feature in linux called sudo which allows any user that has sudo privileges to execute commands as root just by typing "sudo" in front of the command. So, sudo is another avenue that will allow a user to take over the system. For instance sudo -i, that logs you in as root without the root password which would then allow you to change the root password and own the system. Oops.

    Another piece of this problem is the passwords themselves. If someone can guess, brute force, or dictionary attack the system, they may be able to get the password to get in (viz. toor). Most dictionary attack dictonaries have toor as one of the first tries if you can belive it. Likewise, all too often, the root password is shared among many users or written on a piece of paper tacked to the server room wall. When this is the case, it will be almost impossible to determine who logged. Again, same in windows just substitute administrator (although rotartsinimda is not as common, it's also on my dictionary list).

    So, just for starters, you need to carefully think about who is an administrator/root and who has sudo/administrator privileges on the system. Remember, in Windows you can create any user as an administrator and basically, that account has the root privilege on the system and just like root can giveth and taketh away. Thus, a chain is created where dwhite can escalate rbeauchemin and then rebeauchemin can escalate dredge, etc. Pretty soon, you don't know who can do what and end up having to revoke everyone. But even then, a script or an account may have created other accounts or even daemons that are running as root/admin. Is sysKerneldaemonCTL a real account or a fake? If I was creating fake root accounts on your system, they would definitely have names very similar to required system accounts so that you would be afraid to delete them. So, you really need to secure those accounts and restrict carefully who has access to them, even at home. Likewise, good password hygiene is critical to preventing someone from just attacking and brute forcing the password for root or administrator. And remember, that chain of creation can put you in a really bad spot.

    A second point of contact in this model is going to be privilege. If a script is running as root/administrator then it can do all the things root can do. So, a simple python script which creates user daemonKernelHost with root privilege is pretty easy to execute. All you have to do is get a user with root level access to run it. This was a common way to inject malware on systems. If you download starwarsgame.exe and run it with admin privilege (like 99% of all users on Windows) I can let you play the starwarsgame while my subroutine creates a user as an administrator, opens port 1138 (viz. thx 1138) and sends a single ping to my darknet system for documentation. I can come back later and login to your system while you are doing something else. So, how do you stop this? Well, in linux chroot is a command to run everything in a different shell then normal root (see chroot jail) and sudo was supposedly going to prevent this sort of thing. If you don't type sudo in front of everything you do, then you are running with normal level of privilege. Now, in windows, you don't have a lot of options but you can create accounts that are non administrator accounts and accounts that are administrator accounts and use those for different purposes. But, if you let everyone be an administrator, well, someone will abuse the system.

    NOTE: In administered systems in windows (these are systems where things like Active Directory are being used), you can control what people can do at a much more granular level and as such can prevent them from installing things, opening ports, etc. at a very fine level.
    • File/directory permissions.

    There are three permissions on windows and unix type systems:

    1. Read
    2. Write
    3. Execute



    - Read permission means you can simply see the file and it's contents but you can't change it.

    - Write permission means you can make a change and save it.

    - Execute permission means you can cause the script or executable to "run" and send commands out on it's own.

    Each of these things has it's own set of dangers. Remember, that someone who has root/admin can change permissions as well so basically, they can just set their permissions so it doesn't matter what it is originally set to at all.

    Let's make it worse:
    Every file, folder, and object in the system has an owner, a group membership, and a set of permissions that applies to the owner, the group, and everyone else. This is true in Win and Lin. How it specifically works is a bit different but it's basically the same concept.

    So, if an owner has rwx, a group called foo has rx, and everyone else has x. That would likely be some sort of button or something an anonymous user might use (like say in a webpage). There are thousands and thousands of these in various combinations on the system and if even one single file allows someone to do something, it may cause chaos. Example: When you built that website, you wanted visitors to be able to write something about themselves so you created a folder that had rwxrxx type permissions. But that didn't work. When they tried to save their comment, they needed w so you added rwxrwxrwx to that file. That is called a 777 or a globally writeable file. Ouch. What if they save, instead of a comment, an external link that executes and writes a piece of malware onto the system. Oh the joy of cross site scripting attacks. So, you need to develop a plan to audit things like this and the permission sets that are found on the systems or eventually someone (particularly in that www tree) will figure out a way to inject files and content into your server. Here's a different example: Same attack but now, it overwrites two things, 1 is the path (this is how the operating systems looks for things) so that /foo/ls is a file that supercedes the /bin/ls command that is supposed to be there and saves a file called foobar.py in the web tree. The next time you type ls the system runs the /bin/ls command as usual but also executes foobar.py which is malware. Ouch again.

    These permission trees get really complicated with the web servers that people are running (which is why webservers get attacked all the time and compromised all the time). If you set up a directory like c:\mywebsite\www and point the root directory to that ..\www section. The first thing you will find is that the owner of the file (you) needs rwx so you can actually save files. Now, if you have other people using it, then you create a group of people called "webadmins" and give them rwx as well so they can add pages. The webserver itself is likely the "other" category of permissions but the problem is, the definitely need r and if you have scripts, then they need x. But, the minute you start letting them add things, well, you get the idea. So, start thinking about what they can do and how you are going to prevent it.

    Side note on 777. In unix based systems, permissions can be managed using decimal numbers. In each of the three fields (owner, group, other) there is a total of 7 that can be obtained using the following formula r == 4; w == 2; and x == 1. By adding up the numbers, you can assign permissions using the chmod command where a 7 is everything. So, 777 became synonomous with "world writeable files" on web servers.

    So, when you run those tools that evaluate your system security, those tools are usually going to point out files that have problematic permissions, but there is still the problem of the privilege. Who needs to be able to write? A final example is, if your web server is running as root and owner of the whole tree, guess what, in order to operate, it is likely the owner is rwx and as such everyone using the system is rwx for that whole tree. All it will take is one single link into that tree structure from somewhere else, and a file can be injected into the system outside the tree. Very complex.

    So, you need to (even at home) be thinking about:

      • What is my privilege level and what happens when I run something?
      • Who else can see my files?
      • Who else can change my files?
      • Who else can execute files on my system?



    Certainly, antivirus, antimalware products watch for this very sort of thing, but if you have someone who is root/administrator it isn't going to matter much. I mean, the system doesn't stop you from installing and running things does it?