samedi 26 juin 2010

KitRap0d élève les privilèges! Hum...à voir

Afin de supporter les routines du service BIOS dans les applications “16 bits”, Windows NT supporte encore les appels BIOS en mode Virtuel-8086.

Et KitRap0d s’appuie sur cette fonctionnalité pour transformer un simple utilisateur sans privilèges en un administrateur tout puissant.

Selon l'auteur, les versions 32-bits suivantes de Windows NT sont concernées:

  • Windows 2000Windows XP
  • Windows Server 2003
  • Windows Vista
  • Windows Server 2008
  • Windows 7

J’ai personnellement testé avec succés KitRap0d sur Windows XP SP3 mais avec les patches de sécurité non mis à jour. Ce qui limite la portée de l'attaque. D'où, une fois encore, la nécessité de prendre en compte les mises à jour de Microsoft rapidement. Par contre sur un Windows 7 Ultimate de base, KitRap0d ne semble pas fonctionner.

Pour information mon antivirus AVG Free détecte KitRap0d dans sa version initiale (ce qui n'est pas le cas d'un autre antivirus pourtant bien connu dont je tairais le nom). Mais AVG Free ne le détecte plus une fois modifié et recompilé comme toujours.

Une fois n'est pas coutume, voici un lien vers un vidéo très bien réalisé décrivant le déroulement de l'attaque (et il n’y a rien à ajouter ou presque!) par Pieter Danhieux:














L'intérêt de cette exploit réside dans le fait que nous disposons du code source et que nous pouvons l'étudier, le modifier et le compiler à volonté. Vous pouvez télécharger l’exploit et le code via le lien suivant:

KitRap0d

Comme toujours il est possible d’embarquer l’exécutable de l’exploit dans une clef USB ou un DVD (soit dans un vrai programme corrompu i.e. jeux ou utilitaires, soit en utilisant l’autorun), et d’automatiser la procédure en utilisant AutoIt si nécessaire (cf l’article Je veux et j’exige les droits “administrateurs”!).

Une petite vérification de vos OS ne coûte pas grand chose!

Note: l’exploit est aussi disponible sous Metasploit

Source: Pieter Danhieux

Tags:
BuzzNet Tags: ,,,,
Technorati Tags: ,,,,
del.icio.us Tags: ,,,,

samedi 19 juin 2010

Je veux et j’exige les droits “administrateurs”!

Comme la plupart des développeurs j’ai besoin des droits “administrateurs” sur mon PC. Sinon, c’est bien simple, je ne peux pas travailler dans de bonnes conditions. En tout cas c’est que j’affirme haut et fort à qui veut l’entendre !

Le choix d’avoir les droits administrateur sur son poste de travail présente effectivement de nombreux avantages mais aussi quelques dangers.

Dans ce qui suit nous allons montrer une des nombreuses actions offensives qu’il est possible de réaliser avec quelques lignes de code sans beaucoup de complexité.

Au lieu d’essayer de cracker le mot de passe “administrateur” de notre développeur imprudent, nous allons simplement ajouter notre propre utilisateur “local” avec les droits “administrateurs” en profitant des privilèges locaux.

Dans ce qui suit nous faisons l’hypothèse que l’attaquant est en contact direct avec la cible. Il va ainsi pouvoir exécuter le code malicieux permettant de créer notre compte utilisateur “pirate”.

Les moyens à la disposition du pirate peuvent s’appuyer sur une clef USB, un CD ou un DVD (si l’autorun n’est pas désactivé sur le poste de la cible) ou sur le partage d’une application embarquant notre code malicieux (un jeu, un utilitaire,…) via une clef USB, un CD ou un DVD (cf l’article La clef USB: le maillon faible ?).

Vous trouverez ci-dessous le code nécessaire:

ScreenShot008

Ce code permet de:

  • désactiver momentanément le son du PC cible
  • ajouter les utilisateurs en fonction des informations stockées dans le fichier “myusers.txt”
  • donner le droit de “Interactive Logon” à l’utilisateur hacker1. Cette commande n’est pas nécessaire dans notre contexte car les membres du groupe “Administrators” possède déjà ce droit (elle peut cependant être utile dans d’autres cas).

Vous trouverez ci-dessous le contenu du fichier “myusers.txt”

ScreenShot007

Ce fichier permet de:

  • créer 2 utilisateurs: hacker1, hacker2
  • donner les droits administrateurs à hacker1 et hacker2

Ce code a été testé avec succès sous Windows XP SP3 et Windows 7 (avec la fonction UAC, User Access Control, désactivée cependant).

Est-il vraiment nécessaire de conclure ?

Tags:

BuzzNet Tags: ,
Technorati Tags: ,
del.icio.us Tags: ,

samedi 15 mai 2010

Un bug dans Webgoat 5.2? Non! Pas un mais deux…

Eh bien oui, il faut le voir pour le croire mais il y a bien quelques bugs dans la version 5.2 de Webgoat. Webgoat ne fait pas exception à la règle! Dans les développements de sites web il y a des bugs qui parfois échappent à la validation et qui peuvent devenir des vulnérabilités exploitables par des personnes mal intentionnées. Mais heureusement nous ne sommes pas dans ce cadre, Webgoat est fait pour être faillible! Ouf! L’honneur est sauf!

L'objectif de cet article est simplement de vous montrer qu'il est possible de modifier le code de Webgoat. Vous avez toujours la possibilité de récupérer Webgoat 5.3 si vous le souhaitez.

On peut trouver tous les bugs de Webgoat à l’URL suivante: http://code.google.com/p/webgoat/issues/list

Mais puisque nous disposons du code source et d’Eclipse (voir “Modifier le code source de Webgoat, c’est possible!”), nous n’allons pas nous priver du plaisir de faire les corrections.

Bug 1 dans la leçon DOM injection de Ajax Security(référence 28)

Dans le code source de la page, on trouve:

<input name='key' value='' type='TEXT' onkeyup='validate();' >

Or plus loin on trouve:

var keyField = document.getElementById('key');

Il n’y a pas de paramètre “id” avec la valeur ‘key’ mais un paramètre “name”, il est donc nécessaire d’ajouter le paramètre “id” et de lui donner la valeur ‘key’

Dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java), on ajoute donc la ligne ci-dessous qui permet d’ajouter un tag “id” et de lui donner la valeur ‘key’:

Input input1 = new Input(Input.TEXT, KEY, "");
input1.addAttribute("onkeyup", "validate();");

// Fix
input1.setID(KEY);

tr.addElement(new TD(input1));
t1.addElement(tr);

Bug 2 dans la leçon DOM injection de Ajax Security(référence 32)

Dans le code source de la page on trouve:

var result = req.responseXML.getElementsByTagName('reward');

Mais la valeur req.responseXML est nulle lors de l’exécution avec Firebug

Par ailleurs on peut observer que la variable result n’est pas utilisée.

Pour résoudre notre problème on peut donc simplement commenter la ligne dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java)

Environnement de développement

Lorsque vous sauvegardez une modification dans Eclipse, le “build” est automatiquement lancé et le serveur est mis à jour (cf. Project/Build automatically).

Il ne reste alors qu’à recharger la page dans le browser et votre correction est immédiatement prise en compte.

Etonnant non!

Tags:

- Technorati Tags: ,


- del.icio.us Tags: ,


- BuzzNet Tags: ,

samedi 8 mai 2010

Modifier le source de Webgoat, oui c’est possible!

Si comme moi vous avez eu le besoin ou l’envie de modifier le code de Webgoat, soit pour y ajouter votre propre leçon, soit pour corriger un bug (eh oui il y en a parfois!), alors vous allez être ravi. Oui, l’OWASP permet aux utilisateurs de Webgoat de modifier le code source.


Tout d’abord un petit rappel sur les principales versions de Webgoat actuellement disponibles:

  • Webgoat 5.3 est disponible en RC1 (première Release Candidate de cette nouvelle version) depuis le 10 novembre 2009

  • Webgoat 5.2 est disponible en version finale depuis le 12 juillet 2008

Contrairement à la version 5.2, la récente version 5.3 ne propose pas encore une version incluant le code source. C’est pourquoi nous allons nous intéresser à Webgoat 5.2.


Dans cet article nous allons voir comment installer Webgoat 5.2 fournit avec le code source et l’éditeur Eclipse. Puis dans un prochain article, nous essaierons de corriger un petit bug de la version 5.2.



Installation de Webgoat 5.2 avec le code source

Sur http://sourceforge.net/projects/owasp/files/WebGoat/ choisir le répertoire Webgoat 5.2 et télécharger le fichier WebGoat-OWASP_Developer-5.2.zip

Extraire le fichier sous “C:”. Vous devez alors trouver dans “C:\WebGoat-5.2”, le fichier “Eclipse-Workspace.zip”

Extraire ce zip dans ce répertoire. Vous devez alors avoir le nouveau répertoire suivant: “C:\WebGoat-5.2\eclipse”

Lancer alors “C:\WebGoat-5.2\eclipse.bat”. Vous avez alors accès au projet Webgoat.


ScreenShot052


Sélectionner “Window/Open perspective/Java” ou “Window/Open perspective/Other/Java” et vérifier que les projets “Servers2” et “Webgoat” sont bien présents dans l’onglet “Project Explorer”. Vous pouvez faire un clique droit sur “Servers2” et sélectionner “Refresh” (idem pour le projet “Webgoat”).


ScreenShot050


Lancer Webgoat via Eclipse. Pour cela sélectionner “Window/Open perspective/Resource” ou “Window/Open perspective/Other/Resource” et dans l’onglet “Servers” séléctionner la ligne “Webgoat Tomcat v5.5 server at localhost”, faites un clique droit et sélectionner “Start”. L’état de ce serveur doit alors passer à “Started”


ScreenShot048


Enfin dans votre browser préféré, vous pouvez entrer l’URL: http://localhost/WebGoat/attack


ScreenShot051




Tags:

- Technorati Tags: ,

- del.icio.us Tags: ,

- BuzzNet Tags: ,

Partager avec...