Monthly Archives: July 2012

Safaricom Domain Hosting & why not to use it.

So some time last week Safaricom finally sorted me out…I was having a problem affecting a domain transfer from Kenya Web hosting to them. Something as simple as getting an EPP code from KWH   emailing this to them and in turn transferring ownership to them took me forever to get sorted. In the middle I think I was told by both parties (Saf and KWH ) to contact their registrar (Enom) and ask what was wrong with the EPP I was getting….as if they would listen to me. Any way this is not a post about that…its more about a flaw I discovered in Safaricom’s   Web hosting  service. A flaw that may seem small to the rookie user but a goldmine to a skilled hacker. A flaw that I have contacted them about but I have been kindly called back (Using that weird 0722000000 number ) and told to write a detailed report of the said exploit ni kama mimi nafanya kazi huko…..

To begin I will first walk you through a little Comp stuff kiasi. Safaricom’s web server(s) …sijui ni ngapi…run on Linux. One common theme among all UNIX variants of operating system is the security model of the file system, based on users, groups, ownership and permissions. UNIX variants and Linux basically have users, each one belonging to one or several groups. Each file and directory on the file system is owned by one and only one user and group. The owning user doesn’t necessarily belong to the owning group, which allows for flexibility. The system knows who is permitted to do what on each directory and file by means of permissions. Permissions are usually written down as three digit octal numbers. (777,644…etc) The first number tells the system what the owning user can do, the second one tells it what the owning group can do and the third number tells it what everybody else (the rest of the “world”) can do. The commonly used numbers are 4 (read only), 5 (read and execute), 6 (read and write) and 7 (read, write and execute). The execute bit has a special meaning on directories: it means “browse”, i.e. allow someone to produce a list of the directory’s contents. This is different than “read”, which simply means allowing the user to read files from that directory if and only if he knows their name. Each program you run is owned by a user and a group. Apache is also a program. It runs “under” a user and group.

So, there you have it. The operating system knows who asks for access based on the user and group of the program which requests the access. It also knows what kind of access you request (read, write or execute/browse). When it finds the file or directory it can look up its owning user and group, as well as its permissions. It will first check if the owning and running user match. If they do, it will use the first number of the permissions to decide what to do. If not, it will check if the owning and running groups match and use the second number of the permissions to decide what to do. If all else fails, it will use the third number of the permissions (the “world” permissions) to decide. This is an elegant and effective system, until someone tries to use it unintelligently. Enter Safaricom.

Their Servers are configured to run PHP as an Apache module (a.k.a. mod_php). This means that your PHP files run under the same user and group as your web server. Usually, these are called “nobody”.

Normally when you upload you’re site with FTP, the FTP server runs under the user you used for logging in. Let’s say that your user name is “websitenoma” and you belong to a group named “users”. You now have all the directories and files you uploaded with FTP owned by websitenoma: users and run under nobody: nogroup This means that under the usual default directory and file permissions of 644 your PHP files can’t write to files on your site, or even list the contents of your own site’s directories!.So you start panicking…this is what happened to me, so I emailed the Guru Himself @iddsalim and he suggested I do the following to solve the problem:

chown -Rf yourloginname:www-data /home/websitename/public_html/avatar

chown a-rwx /home/ websitename /public_html/avatar

chmod ug+rwx /home/ websitename/public_html/avatar

Also, make sure /tmp is 777.

This in effect is correct, but the guys at Safaricom had already offered a “solution” to my problem

They had suggested(based on other sites that they helped prop) I set all the folders to 777 and the files to 644… which also was working…PHP files can now write to files. However, it actually works a bit too well for your site’s well-being the website would in effect be saying “Am open for hacking…please hack me….” Aje sasa Jaymo?? Let me explain

You see, on a shared host kama za Safaricom, you are not the only user. Other sites also have a user on the same system. To make things worse, the exact path (a.k.a. absolute file system path) to each site’s root is very predictable, usually in the format /home/ websitename/public_html. If someone wants to hack your site, all he has to do is create an account on the same server and try to write to one of your site’s files. With the 777 permissions, HE CAN DO THAT EVEN THOUGH HE DOESN’T HAVE YOUR USER NAME AND PASSWORD! Adding insult to injury, a clever hacker doesn’t even have to create an account on the same server. Your server runs a lot of software, such as a web server, an FTP server, a DNS server, an SSH server, a mail server and so on. If one of them is vulnerable, he can exploit them to write to your site’s files. Even if you lock everything down, shared hosts pose a wonderful opportunity to screw you without even knowing about it. Even though you have taken all measures to avoid exploits being able to run on your site, another site hosted on the same server might not be so keen on security.

But this is not something new….and it has been around for miaka mob sana..many people know about this,so there should ba a solution…and indeed there is. The server should ideally  run on suPHP. suPHP is a very clever workaround to the permissions problem. Instead of running PHP under the web server’s user and group, it runs PHP under the owning user and group of the PHP file. This means that only the first number of the permissions is important, while the second and third ones can be set to 4 (just read) or 5 (read, browse) for directories. Don’t use 0, as you’ll be denying access to non-PHP content, such as images, Javascript and CSS files. In this case, the perfect permissions are 0644 for files and 0755 for directories.But does Safaricom use this?? The answer is NO!!!

Safaricom does not- to my best Knowledge- use suPHP. In order for them to be able to cram ,1 – 1,000 sites on a single server. suPHP comes with a performance hit, so they don’t use it in order to be able to overcrowd their servers without bringing them to a screeching halt. So I was In a dilemma again….the second solution offered would have been a dedicated Server.

When you have a heavily trafficked web site you need to run it on a dedicated server. Since it’s a dedicated server, it implies that there is only going to be one site running on it. However, you want to put every CPU cycle to good use, therefore you can’t use suPHP due to its overhead and incompatibility with performance tuning tricks.This is all good and sweet, until you decide to install ISPConfig, au cPanel or any other pre-packaged server environment manager (SEM) on the server.

Why? Because the moment you do that, you enter “fuck me mode”. Your accepting  the settings “imposed” to you by the SEM. More specifically, all SEMs suppose that you are setting up a shared host and configure Apache to use a different user than the owning user of the one and only site you’ll be hosting. As a result – and because you can’t use the FTP layer due to the huge performance impact – you start giving 777 permissions.

Hacking pap!!!! !Lakini I would be be hosting just one site, therefore a hacker would have to penetrate this site’s security to hack your me. Or not. He could use one of the various system servers (FTP, mail, SSH, DNS, etc) as an attack vector .A way for him to perform a clever hack.  The 777 permissions give him the right to do so.

Stuck again. I call up my boy Jaws…the number one server guy I know. And he reminds me that  if I am using a dedicated server I would be the sys admin. And as such can edit Apache’s configuration file and do something magical. Configure Apache to run under the same user as the owning user of the one and only site am hosting. That’s right. It’s that simple. From that point, I  simply set 0700 permissions for directories and 0600 permissions for files….kazi kwisha…..


Posted by on July 22, 2012 in code, hack