# uname -a - Mot-clé - hack

About ToBeHost : the last of my student's projects

Mathieu — Thu, 01 Oct 2015 23:55:00 +0200

Hello there, this is not your ordinary reading on this blog. This post is a sort of introduction for a series of posts about the making of a free web hosting provider, implementing a web panel from scratch using Drupal for front-end and Puppet as back-end.

But first, let me introduce you the reason why we started the project. I said “we” because I am not the only one in the boat, but it’s me who will make all the technical choices, and implement it. I am also the one who was saying “give up” to my colleague a few months ago, before going back with this new and exciting crazy idea.

Genesis

ToBeHost is a project we started around 2008~2009. Before that, I was an active member at a free hosting provider (“Chez Mémé .net”). When this hosting provider closed, due to the lack of time from its founders, me and a friend I met on this hosting provider stated that we had both the technical and time resources to make our own hosting provider. It was just loaning a dedicated server and configuring all the stuff you need to have your site working. We were not experts (yet), but be were confident in the fact that we had the capacities to learn, and to make it working. This is also the moment where I started hacking on GNU/Linux

We tried several web panels. Between love and hate, we finally choose VHFFS. VHFFS is a great piece of software. For the kiddie I was, it was the sort of “perfect-even-scary” piece of Linux engineering. Because mass web hosting involves dealing with a lot of “subsystems” to make it work, what VHFFS was doing was simply amazing to me. Using libnss and nscd to make system user from a database was for me the cleverest way to make system users without having to deal with system commands. Using unix permissions and system users and groups instead of hacky chroots, safe_mode, and open_basedir was definitely feeling right to me. I learned a lot about Linux and Debian, and my first (and actually unique) contributed patch made me feel so proud of me.

The long love (and hate) story

Dealing with a single server, on a student time, was not complicated. When something went wrong, I was looking for the answer by myself because I was (and I am still) afraid of what people can think or say to me on a public IRC channel. We had some downtimes, and a few fears while restoring backups, but things were globally going well.

Some things were a little bit cumbersome, but I was thinking that it was part of the job. Re-compiling PureFTPD ans MySQL package at each upgrade was not actually a problem, because I was eager to learn how to patch, compile, and hack into Debian. I even rewrote the SQL queries when we upgraded to Debian Lenny, which was using libnss2.

The years passed, I was growing and becoming older (hey, don’t laugh). My years at university was taking much and much time over my “internet time”, as I was getting involved in the students’ association and my final exams were approaching. Finally, the project was in an informal standby, we decided that we had to close it, because we were both very busy elsewhere.

We officially closed. We sent the mail to users, I was ready to backup my configuration files and delete the data. We didn’t do it. Because of our sloppy feelings, and the fact that “it worked”, without “touching anything”. It was such a pity to let it go.

The last breath (or not)

Some months ago, we realized it had been several years that the project was officially dead. I didn’t stop hacking Linux. I had left my full-time job because I was working too much on projects I didn’t like (and some other reasons), and was running a freelance activity. My colleague was running a successful IT company with his associates, and we were working together on some professional projects (we still are).

New tools and software have appeared since my last glance to ToBeHost, and I also learned how to use new tools. I asked my colleague to let the project go, but we finally paid another month for the server.

And then, I thought: web hosting is actually what I am into at that time. I know how to do it the right way, with the smallest administration effort. None of the alternative panels was fitting as well as VHFFS for the work we wanted. Let’s take all the VHFFS goods (strictly unix permissions, not be afraid of user access to shell, trust user isolation and quota), and add some bullshit (PHP panel, made on top of a CMS), with a little bit of magic (Puppet automation). Let’s put it together, and see what is coming from it.

Voilà. This is how this project started.

Addendum

The project started, and it is pratically ready for beta-test. I will try to write that series of posts and explain how we made it, in order to inspire other people, and to help me keep my ideas clear.

As you may think, it is and it will be highly experimental. I don’t know if the growing of Puppet objects will be sustainable in the long term. I don’t know if Drupal will drive me crazy to the point I would rage delete my code. I don’t know if the whole project will be clean enough to release it opensource. But we will try.

Wanna join ?

GetSimple: URL index/something returns 404

Mathieu — Mon, 03 Feb 2014 11:25:00 +0100

Problem

While using GetSimple with FancyURLs (Apache Rewrite), every menu item nested under the home page returned a 404.

The (rewritted) URL of the home page is /index

The sub-pages URLs are rendered as index/something, and triggered a 404 error.

Solution

Disable MultiViews.

MultiViews is an Apache mechanism for automatically switching wich document is sent to the user, based on the Accept header. Because the front controller is named index.php, MultiViews was trying to reach index.php/something instead of (as specified in RewriteRules) index.php?id=index/something.

How to do it

Open the GetSimple .htaccess file, and locate :

Options -Indexes

Change to :

Options -Indexes -MultiViews

Cinq étapes pour créer un cheval de troie sous GNU/Linux

Mathieu — Tue, 05 Nov 2013 23:41:00 +0100

Contrairement à ce qu'on dit, créer des logiciels malveillants sous Linux est d'une simplicité enfantine. La sécurité d'un système ne repose pas sur le nombre de barrière qu'il peut vous placer mais sur la capacité des utilisateurs à avoir du recul sur leur machine.

Voici donc les cinq étapes pour créer un petit cheval de troie sur Linux. Rien d'exceptionnel, beaucoup d'autres l'ont fait avant moi, cet article est entièrement à but pédagogique.

1. Installation

Source de l'image

C'est sans doute sur ce point que l'on pourrait imaginer les systèmes Linux plus fiables que les systèmes Windows : dans la plupart des cas les logiciels malveillant sous Linux sont installés par l'utilisateur, et non à son insu. Pas beaucoup de possibilités pour injecter dans des 0day présents sur des programmes Linux, ils sont rapidement patchés. Quoique.

Non, l'installation viendra certainement de l'utilisateur. On l'aidera un peu ceci dit. Le type d'installation déterminera le champ d'action et la capacité de dissimulation du trojan. Même si on ne peut pas vraiment parler de rootkit pour un programme lancé en zone utilisateur, on peut faire un excellent cheval de troie ou un keylogger sympa avec de simples privilèges utilisateur.

Que vous prêtiez votre session l'espace de dix minutes ou que vous cliquiez benoîtement sur un joli fichier-image-qui-en-est-pas-un, le résultat sera plus ou moins le même : le programme s'installera, première étape franchie.

Où il s'installera ? Ça dépend. S'il est root, le programme prendra ses aises dans les coin reculés de /proc ou /lib, là où vous n'irez pas le chercher. S'il est utilisateur, il se chargera quelque part dans un .machinchose, les fichiers cachés présents dans votre dossier utilisateur.

2. Démarrage

Avoir un fichier malveillant sur son ordinateur (à des fins purement scientifiques), ça arrive à tout le monde. Mais que celui-ci devienne létal en se lançant avec votre session, ça c'est une autre affaire. Comme sous Windows, il n'y a aucune difficulté à lancer un programme avec la session ou dans les services.

Pour les services, un petit patch dans /etc/rc.d/ ou /etc/rc.local et vous êtes partis pour la rigolade.

Pour les programmes utilisateur, une petite retouche dans .xsessionrc, le .login, ou le fichier de démarrage de votre environnement (gnome, kde, etc) fera amplement l'affaire.

3. Dissimulation

Un trojan, si on le trouve c'est pas drôle, alors il faut le cacher un peu. Les fichiers cachés c'est bien pour un utilisateur lambda, mais pour un administrateur système il faudra trouver mieux. Quoique.

Les programmes qui se dissimulent le mieux sont des programmes qui se sont installés en root. Forcément, pour ce genre de programme, patcher le noyau pour se rendre invisible, modifier la commande "top" ou recompiler et installer ses propres paquets patchés est l'enfance de l'art, mais un programme utilisateur peut lui aussi installer sa petite mécanique secrète.

Par exemple, il peut modifier le PATH de l'utilisateur pour remplacer les programmes systèmes par les siens (genre ps, top, ou les outils de diagnostique réseau), trafiquant alors les sorties des programmes légitimes pour se rendre invisible.

4. Collecte d'informations

Là on pourrait penser que le système le plus sécurisé du monde empêche les application illégitimes de collecter des informations. En fait non.

Si vous êtes root, vous avez de toute façon accès à toutes les entrées et sorties que vous voulez.

Si vous êtes un programme utilisateur, vous avez accès aux informations que l'utilisateur soumet, ce qui et déjà largement suffisant pour lui voler ses mots de passe. Outre aller farfouiller dans les .config et les .mozilla, le gentil programme peut aussi profiter du mécanisme vieillissant fourni par le serveur graphique X, et capturer n'importe quelle frappe de touche en silence (si, si...).

5. Communication avec l'extérieur

Créer un tunnel réseau sous Linux est enfantin en utilisant un langage de haut niveau comme Python. Pour les autres, quelques read avec des socket fera amplement l'affaire. Le point délicat ici est le chiffrement. C'est toujours délicat d'implémenter une couche SSL sur les programmes. Une alternative est l'alternance entre un masque jetable et un décalage de bits, chacun d'une taille suffisante pour tromper le newbie qui snifferait des trames réseau à la recherche de ce qui fuite.

Conclusion

La création de programmes malveillant sous GNU/Linux est accessible à un élève de seconde année de licence Informatique, c'est à dire pratiquement n'importe qui. N'oubliez pas que ce que vous pouvez faire sur votre ordinateur, n'importe quel programme qui s'exécute avec vos droits d’utilisateur peut lui aussi le faire (skype ?).

Touche pas à mon shell !

Mathieu — Wed, 23 Mar 2011 13:17:00 +0100

Il y a quelque chose qui m’a énervé dès le début de l’année sur les machines qu’on utilise en TP, et ça a continué en pire jusqu’à aujourd’hui. Ce court billet va donc expliquer pourquoi j’ai été amené à compiler mon propre shell, et comment le faire.

Petit rappel des faits : au début de l’année une ligne dans notre .bashrc personnel lançait le navigateur à chaque nouveau terminal, oui vous avez bien entendu, à chaque nouveau terminal le navigateur se lançait. Ceci pour rappeler les règles élémentaires de respect des salles, etc.

Ceci dit, lancer un programme graphique en même temps qu’un terminal, c’est stupide, surtout quand comme moi on lance plusieurs terminaux et qu’on se retrouve avec plusieurs firefox d’ouverts par la même occasion, ça devient profondément pénible. Une petite modification du bashrc plus tard, cette fonctionnalité ubuesque avait disparue.

Mais, il y a quelques jours l’administrateur système a placé la ligne en question dans le bashrc global (/etc/bash.bashrc), ce qui signifie qu’il n’était plus possible de le désactiver, à moins de recompiler le bash. C’est donc ce que j’ai fait.

Pour recompiler le bash, il vous faut :

La libc standard
yacc ou bison
Le code source de bash : http://ftp.gnu.org/gnu/bash/

Ensuite c’est comme d’habitude : ./configure && make et puis voilà.

Les plus attentifs auront remarqué que je n’indique pas de modification de code source à réaliser pour désactiver l’appel au bashrc global, ce qui était le but de la manoeuvre. Ceci tout simplement parce que cet appel est désactivé par défaut dans le code fournit par GNU, le paquet Debian étant donc une version légèrement différente de l’originale au niveau du code source, en fait ils ont juste décommenté la ligne contenant #define SYS_BASHRC "/etc/bash.bashrc" du fichier config-top.h.

Enfin, une petite formalité, il faut expliquer à gnome-terimnal de lancer notre shell plutôt que le shell par défaut, cela se fait simplement en appelant gnome-terminal avec l’argument -e : gnome-terminal -e chemin_vers_le_bash.

Enjoy !