Hervé Godquin

Bonjour à toutes et à tous,

Je laisse tomber les listes de diffusion (trop ancien en soit) et je passe sur le mastodon des paranoiac-thoughts.

Donc pour suivre mes posts CTI/Cyber/Géopolitiques/Sciences:

• @netpsycho@social.paranoiac-thoughts.com
• @the_netpsycho sur twitter

Have fun !

Une petite vidéo d'introduction, ou de rappel selon les cas, à l'OWASP ASVS : Application security verification standard: https://www.youtube.com/watch?v=K0HPYyODaRs

Salut tout le monde,

Voilà, depuis quelques temps je cherchais à relancer une communauté, et au final ce n'est pas si facile. Donc du coup quelqu'un, salut à toi si tu passes par là, m'a conseillé de lancer des mailing lists pour partager ce que je n'arrête pas de lui envoyer via WhatsApp :). Enfin à l'origine je devais en lancer une mais finalement j'ai subdivisé par sujet.

Donc vous trouverez les listes de diffusion ici.

En liste publique il y a donc à ce moment:

• Crypto: liste dédiée à la cryptographie, donc bon cela ne sera pas forcément la plus active de toutes
• Cyber: dédiée aux news de cybersécurité et au cyber-threat intelligence, celle-ci déjà y aura normalement quelques postes par jours
• Geopol: dédiée à la géopolitique et aux conflis/risques de conflits ... malheureusement aussi il risque d'y avoir quelques postes par jours aussi
• IoC: pour le partage d'IoC
• Vulns: pour parler de vulnérabilités et d'exploits d'un point de vue technique

Bien sûr je vais m'astreindre à poster régulièrement mais n'hésitez pas vous non plus à partager des choses :).

En ce qui concerne les inscriptions, ce sont des listes de diffusion donc si vous voulez vous inscrire à toutes, il faut le faire une par une, pas moyen de faire ça en grouper, ça peut être un peu long désolé. Pour le processus: une fois inscrit un mail permettant de confirmer votre adresse mail vous sera envoyé, puis un administrateur/modérateur devra confirmer votre adhésion. Pour la vie privée: vous pouvez vous désinscrire librement bien sûr, les archives sont uniquement accessible aux abonnés et la liste des abonnés ne peut être vue que par l'administrateur de la liste (moi pour toutes quoi :)). Après ça marche plutôt pas mal, cela peut prendre du temps (des mails quoi) et sur certaines boites (surtout gmail) pensez à vérifier vos spams et à déclarer la liste comme n'étant pas du spam si besoin.

Voilà, en espérant que cela vous plaira !

Have fun !

Petit test d'un réseau social qui respecte la vie privée et offre pas mal de liberté en ce moment. C'est ici.

J'ai mis en ligne la deuxième vidéo concernant l'introduction au chiffrement. Ce coup-ci on parle de chiffrement symétrique !

Have fun !

Bonjour à toutes et à tous,

Certains ont peut-être vu cette alerte : CERTFR-2020-AVI-107.

En soit sur PHP ce genre de message : "De multiples vulnérabilités ont été découvertes dans PHP. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur." me surprant toujours. En regardant rapidement, mais alors très rapidement, on peut voir que :

Concernant la CVE-2020-7063 : il s'agit d'une vulnérabilité dans Phar : (en gros c'est pour faire une archive d'une application PHP dans un fichier unique) qui semble-il ne garde pas les permissions lorsque l'on créé un tar. C'est assez emmerdant, mais cela reste un cas particulier. Source ici.

La CVE-2020-7061 : un heap-overflow sur Phar sur ... Windows ... Sérieusement qui fait ça ? genre du WAMP quoi ? Bon bref.

La CVE-2020-7062 : Null Pointer Dereference si dans votre php.ini il y a session.upload_progress.cleanup=0 ... source : ici.

Donc en gros : quqleus risques de crash, voir DoS donc, on ne peut pas exclure du RCE dans certains cas mais bon ... les droits concernant les archives ça peut être emmerdant. Enfin quoi qu'il en soit il faut patcher de toute façon :D.

Et sérieusement qui fait du PHP sous Windows ????

Du coup si je devais faire un pari vite fait je dirais :

CVE-2020-7061 : CVSS 3.1 score : 6.4 (enfin je mettrais 10 moi si vous mettez du PHP sur Windows sérieusement !!!)

CVE-2020-7062 : 7.5

CVE-2020-7063 : 6.6 aussi.

Voilà un article pas sérieux, écrit en 10 minutes sur un coin de table, mais juste pour dire que si on veut des informations sur des vulnérabilités PHP on peut les trouver facilement (bon après je sais que le CERT-FR a autre chose à faire ;)).

Have fun !

Bonjour,

Pour une fois je ne parlerais pas de vulnérabilités mais de ... jeux vidéos, histoire de changer un peu.

Il fut un temps ou je jouais pas mal : d'abord sur PC à la bonne époque des LAN puis sur Xbox 360 beaucoup en multijoueur et pas mal sur Call Of MW/MW2/AW ... Je me démerdais pas mal, mais depuis, je joue beaucoup moins et du coup le niveau à grave baissé : en gros : je me prends une misère.

Du coup j'ai décidé de m’entraîner un peu histoire de pas trop passer pour un débile à chaque fois.

Alors je me suis fait une petite séance avec des bots en difficulté "Mixte" avec au programme :

• Mêlée Générale standard;
• Mêlée Générale : Réalisme + tir à la tête : autant dire que là : gros échec;
• Match à mort par équipe Hardcore x 2.

Déjà je tiens à vous souhaiter à toutes et à tous une excellente année 2020. Maintenant que ceci est dit passons au sujet qui nous intéresse : la description d'une petite vulnérabilité intéressante.

Aujourd'hui j'ai choisi la CVE-2019-19844 touchant Django. Cette vulnérabilité touche le formulaire de reset de mot de passe dont le code source (vulnérable) est disponible ici : https://github.com/django/django/blob/4cec3cc82a09b1a60a72e5437a7f0e9e0c7d203c/django/contrib/auth/forms.py

Voici les fonctions posant problèmes :

    def get_users(self, email):
        """Given an email, return matching user(s) who should receive a reset.
        This allows subclasses to more easily customize the default policies
        that prevent inactive users and users with unusable passwords from
        resetting their password.
        """
        active_users = UserModel._default_manager.filter(**{
            '%s__iexact' % UserModel.get_email_field_name(): email,
            'is_active': True,
        })
        return (u for u in active_users if u.has_usable_password())
    
    def save(self, domain_override=None,
             subject_template_name='registration/password_reset_subject.txt',
             email_template_name='registration/password_reset_email.html',
             use_https=False, token_generator=default_token_generator,
             from_email=None, request=None, html_email_template_name=None,
             extra_email_context=None):
        """
        Generate a one-use only link for resetting password and send it to the
        user.
        """
        email = self.cleaned_data["email"]
        if not domain_override:
            current_site = get_current_site(request)
            site_name = current_site.name
            domain = current_site.domain
        else:
            site_name = domain = domain_override
        for user in self.get_users(email):
            context = {
                'email': email,
                'domain': domain,
                'site_name': site_name,
                'uid': urlsafe_base64_encode(force_bytes(user.pk)),
                'user': user,
                'token': token_generator.make_token(user),
                'protocol': 'https' if use_https else 'http',
                **(extra_email_context or {}),
            }
            self.send_mail(
                subject_template_name, email_template_name, context, from_email,
                email, html_email_template_name=html_email_template_name,
            )
On peut avouer que comme ça la vulnérabilité n'est pas forcément très facile à détecter. En effet le problème est assez particulier, et montre que certains points de bonnes pratiques peuvent avoir des implications sécuritaires pouvant être importantes.

Les gros problèmes sont là : '%s__iexact' % UserModel.get_email_field_name(): email, et ici : return (u for u in active_users if u.has_usable_password()). J'avoue même comme cela ça ne saute pas aux yeux :). Du coup je vous invite à lire ceci : http://unicode.org/reports/tr36/#Recommendations_General.

Oui il s'agit bel et bien d'un problème d'encodage de caractères, en soit les petits curieux qui ont été voir la description de la CVE avaient sans doute trouvés :

Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. (One mitigation in the new releases is to send password reset tokens only to the registered user email address.)

Je vous laisse découvrir le patch par vous même : https://github.com/django/django/commit/5b1fbcef7a8bec991ebe7b2a18b5d5a95d72cb70?diff=unified

Alors qu'est-ce que tout cela peut nous apprendre au final (à part qu'il faut patcheer son django). En soit ça vous donne de nouvelles idées de tests pour vos pentests / bug-bounties, mais surtout si vous faîtes de la revue de code cela est assez intéressant.

Premièrement car normalement ces fonctions devraient être revue "en profondeur" si on en croit l'OWASP :

"Are all the untrusted inputs validated? Input data is constrained and validated for type, length, format, and range."

Mais un peu plus que cela, car en effet en soit, tout est bon : ce qu'il manque c'est juste un respect des bonnes pratiques Unicode. Dites à votre avis, combien de développeurs, même voir d'auditeurs les connaissent ? Lors d'un audit de type revue de code au planning serré, cela est-il toujours contrôlé ? De même lors de pentest d'ailleurs ?

Donc voilà ce que cela nous apprends : Je suis sûr qu'il y a bien d'autres cas comme cela, alors à vos git pour les contrôles :).

J'avoue que je commence gentiment pour ce premier post de l'année, mais en regardant les dernières vulnérabilités dans le monde du libre, je n'avais pas trop l'inspiration, c'était soit Django, soit OpenSSL avec la CVE-2019-1551 qui je l'avoue ne m'a pas inspiré. Je vous laisse observer ce magnifique fichier PERL : https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=419102400a2811582a7a3d4a4e317d72e5ce0a8f (y avait aussi un XSS dans wordpress mais bon ...).

Je vais tenter de préparer un nouvel article pour la semaine prochaine, sur une vulnérabilité un peu plus "costaud" ça sera sympatique.

Have fun !

P.S : comme toujours si vous voulez proposer des améliorations, corriger des fautes, passez par le gitlab des paranoiac-thoughts : https://www.paranoiac-thoughts.com/netpsycho/blog_post/blob/master/20200114_django

Récemment quelques vulnérabilités ont été découvertes dans PHP.

Toutes concernent le traitement des images, j'ai néanmoins choisi de montrer l'une d'entre elle car c'est comment dire ... un classique au final.

Voici le code vulnérable :

                                                       if (*(p1 + 1) == '=') {

                                                                ++p1;

                                                                --str_left;

                                                        }

 

                                                        err = _php_iconv_appendl(pretval, encoded_word, (size_t)((p1 + 1) - encoded_word), cd_pl);

On voit tout de suite le problème ... que se passe-t-il si str_left = 0 ? ... forcément quelque chose de pas très bien, on le devine aisément.

Le problème est que str_left est un unsigned integer. Et ce vulnérabilité est comprise dans une boucle for qui en fin de boucle refait un str_left-- ... nous avons donc un énorme entier par la suite.

Et quand dans cette boucle nous avons des opérations de lecture nous nous retrouvons donc bien face à un : "Out-of-bounds read due to integer overflow".

La correction est assez simple :

                                                        * we can do at this point. */

                                                        if (*(p1 + 1) == '=') {

                                                                ++p1;

-                                                               --str_left;

+                                                               if (str_left > 1) {

+                                                                       --str_left;

+                                                               }

                                                        }

 

                                                        err = _php_iconv_appendl(pretval, encoded_word, (size_t)((p1 + 1) - encoded_word), cd_pl);

Pour plus d'informations : https://bugs.php.net/bug.php?id=78069

Concernant les autres vulnérabilités dans PHP : 

https://bugs.php.net/bug.php?id=77950

https://bugs.php.net/bug.php?id=77988

https://bugs.php.net/bug.php?id=78222

https://bugs.php.net/bug.php?id=78256

A vos patchs !

Ca rappelle le bon vieux temps :) Il semblerait qu'il soit possible de faire un DoS sur des kernels 5.0.x avec des paquets UDP avec des payloads null.

Sur le sujet : https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=4dd2b82d5adfbe0b1587ccad7a8f76d826120f37

Have fun !