Mon Talk pour DevoXXFR 2018

UPDATE : Talk accepté !!!! OWASP Top10 2017 – Nouveauté ou continuité

J’ai soumis l’élément suivant pour DevoxxFR2018. Si certains JUG/Groupe User de développeurs  sont intéressés, merci de me faire signe. On pourra l’adapter a votre langage.

PS: de plus si vous souhaitez que je donne une session de formation sur ce sujet a vos développeurs, n’oubliez pas le formulaire de contact, je vous recontacte ASAP 

 

Titre:  OWASP Top10 2017 – Nouveautés ou continuité ?

Résumé : 

Qui ne connait pas l’OWASP Top10 ? (a priori lors de la dernière session DevoxxFR2017 beaucoup ne le connaissait pas vraiment, et cela se vérifie a chaque fois).
Le 20/11/2017, une nouvelle version majeure du Top10 OWASP est sortie, avec l’introduction de différents points importants :

  • A4:2017-XML External Entities (XXE)
  • A7:2017-Insecure Deserialization
  • A10:2017-Insufficent monitoring

Avec l’avènement de plus en plus important des réglementations orienté Secure Coding (Qui a parlé du GDPR, du PCI-DSS, du RGS, …. ? ) nous devons en tant que développeur comprendre notre implication et la bonne manière de pouvoir correctement éviter qu’après un audit on vienne nous redemander des comptes.

Lors de cette session, nous insisterons donc sur ces 3 nouveautés importantes qui nous permettrons de bien comprendre d’ou vient le problème et comment le régler.

Retour sur la vulnérabilité Serialization de Java

Nous allons ici essayé de faire un retour sur cette vulnérabilité qui n’a pas fait surement assez de bruit. Elle a donné quand meme donné lui à un CVE de la part d’Oracle (CVE-2015-4852). Quand on connait Oracle et la sécurité, on peut se dire que cela doit être grave 🙂

Avant d’aborder la vulnérabilité en détail, il est nécessaire de se mettre bien au clair sur certains éléments.

Qu’est-ce que la sérialisation d’objet en Java ?

C’est un mécanisme introduit quasiment au début de Java (JDK 1.1) permettant d’écrire des données présentes en mémoire (un objet par exemple) dans un format de données binaires permettant alors de rendre persistants l’élément via un stockage disque, une transmission réseau ou autre.  Java, fourni un certain nombre d’outils permettant de sérialiser/désérialiser de manière transparente et indépendant du système :

  • L’interface Serializable; cette interface permet d’identifier les classes sérialisable. Il est nécessaire que votre classe implémenter cette interface ou hérite d’une classe sérialisable.
  • La classe ObjectOutputStream ; permet de sérialiser un objet. Elle dispose de la méthode writeObject() permettant d’effectuer cela.
  • La classe ObjectInputStream ; permet de désérialiser un objet. Elle dispose de la méthode readObject() pour cela.
  • Le mot clef transient permettant d’éviter de sérialisé un élément.
  • L’interface Externalizable permettant de gérer différemment  les  sérialisation et désérialisations.

Pour pouvoir correctement sérialiser un objet, il est nécessaire qu’il dispose de plusieurs éléments

  1. l’implémentation de l’interface Serializable
  2. Un numéro de série ;  le serialVersionUID qui permet lors d’une désérialisation que les classes sont concordantes. Il s’agit d’un static long final qui n’est pas obligatoire, java en calculant alors un automatiquement, mais il est recommandé de l’affecter soi-même (exemple : private static long serialVersionUID  = 42424242L)
Exemple :
public class User  implements Serializable {

private static final long serialVersionUID = 424242424242L;
private String nom, prenom ;
private String login;
transient String password;

public User(String nom, String prenom, String login, String password) {
this.nom = nom ;
this.prenom = prenom ;
this.login = login;
this.password = password;
}
}


 

public class Main  {
    static public void Main (String ...args) throws ClassNotFoundException  {
        File fichier = new File("tmp/test.ser");
        try {

ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(fichier));
//Sérialisation
User oout = new User(« Ford », « Escord », « fescord », « fortytwo »);
oos.writeObject(oout);
oos.close();

ObjectInputStream ois = new ObjectInputStream(new FileInputStream(fichier));
// désérialization de l’objet
User oin = (User) ois.readObject();
System.out.println(oin);
ois.close();
} catch (IOException ioException) {
System.err.println(« IOException »);
}
}
}

 
Ici nous avons donc une classe qui va permettre d’écrire dans le fichier test.ser les données d’un utilisateur en dehors du champ password.
Si vous souhaitez effectuer une sérialisation différente de ce que propose Java, il faut donc implémenter l’interface Externalizable.  ou tout simplement  surcharger les méthodes writeObject() et readObject(). Cela permet alors de créer un fichier avec la représentation que vous souhaitez par exemple. 

La Sérialisation permet donc de :

  • Sauvegarder des objets/éléments Java
  • Echanger des objets entre JVM  (par des Streams…dont des NetworkStream)
  • Créer une copie intégrale d’un objet
  • Rentre persistents des objets dans des fichiers…

Revenons maintenant à notre vulnérabilité, maintenant que globalement nous pouvons comprendre à quoi sert la Serialisation en Java.

C’est quoi cette vulnérabilité de Sérialisation Java?

En Janvier 2015 a la conférence AppSec Californie Chris Frohoff et Gabriel Lawrence  présentent leur travaux et des outils autour d’une exploitation des mécanismes de serialisation et leurs utiliisation de manière malveillante.

Il faut attendre le 6 Novembre 2015 pour que Stephen Breen , via un article de Blog , informe qu’un certain nombre de bibliothèques Java sont chargées par défaut par les serveurs Applicatifs (WebSphere, Jboss, WebLogic, ….) et que parmi ces bibliothèques, une importante Apache Commons est vulnérable a des attaques par désérialisation. Je cite :

NewImage

Ce qu’il faut comprendre c’est que cette librairie est l’une des plus utilisées. En particulier quasiment tous les serveurs applicatifs la charge au démarrage. C’est une bilbiothèque très pratique car comportant énormément de classes intéressante (les commons.io, commons.lang, commons.log pour ne citer que les plus connues ).

Les travaux de Chris Frohoff et Gabriel Lawrence ayant montré comment il est simple d’executer une commande système depuis le CLASSPATH, il est alors simple de voir le potentiel impact de la vulnérabilité présente dans les Apache commons. En effet, si le serveur applicatif utilise cette derniere, et donc la charge au démarrage,il est potentiellement possible d’injecter une commande système via par exemple la classe Runtime.

Stephen Breen a démontré que via cette vulnérabilité certains serveurs pouvaient exécuter du code via différents protocoles (T3 ppour WebLogic, JMX pour JBOSS) .

Comment m’en protéger si je suis utilisateur d’un serveur Java?

C’est bien la chose la plus importante a avoir en tete. Il faut deja se souvenir de plusieurs choses si vous utilisez ces serveurs et bibliothèques (mais rien ne dis que d’autres bibliothèques Java standard ne seraient pas touchées….)

  1. Filtrez les ports pour ne laisser que les protocoles nécessaires, il est rare d’avoir besoin depuis Internet de laisser entrer du JMX, T3, …
  2. Gardez a jour vos applications ; suivre les listes des éditeurs et mettre les patchs correctement. La Fondation Apache a réagi très vite
  3. Gardez a jour vos bibliothèques (par exemple utilisez l’outil OWASP-DepencyCheck pour avoir une vue sur ces dernières)

Et si je développe du code ?

Dans le cas du développement de code, il existe une bonne pratique pour vos différentes classes a ajouter comme template de votre éditeur pour éviter des problèmes liés à la sérialisation. Il suffit de surcharger les méthodes writeObject() et readObject() et de leur faire remonter une exception dans le corps du code. Exemple  :

    private void writeObject(ObjectOutputStream out)  throws IOException
    {
        throw new NotSerializableException();
    }

private Object readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException
{
throw new NotSerializableException();

}

et puis à suivre les bonnes pratiques de SecureCoding Java et de la cheat Sheet OWASP

OWASP Top10 2017 -RC1

Bonjour,

comme certains ont déja pu le voir, l’OWASP Top10 2017 est en release Candidate 1 .  Comme son nom l’indique, c’est une version préliminaire (enfin très proche de la version finale), a des fins de commentaires.  Pour cela, il ne faut pas hésiter à remonter (en anglais ou via un de vos leaders OWASP) ce qui vous interloque sur cette nouvelle version.

Alors que dire sur cette nouvelle version :

  1. Oui il y aura une traduction francaise. C’est une obligation vu la diffusion auprès des développeurs de ce document important
  2. Il n’y a pas de « gros changements »
  3. Mais il va falloir quand meme mettre a jour les reporting et autres outils de vos chaines 😉
  4. Que  comme indiqué a la page 22, il n’y a pas que ces éléments a prendre en compte mais aussi les éléments suivants  :

 

Si on le regarde un peu dans le détail ;

  1. on voit bien que les plaies sont toujours présentes :
    • Injections ; de tout type et pas juste le SQL….
    • XSS ; toujours en bonne position, même si personnellement je le remonterai bien en A2 voir en A1.
  2. Par contre certains points ne me paraissent pas justifiés encore une fois,;  A8 vu le nombre de serveurs actuellement incluant le mécanisme de protection, je trouve cela un peu bizarre (mais je n’ai pas regarder les statistiques qui concourent à la création de ce Top10)
  3. le A10 de 2010 (redirect et forwards) est ENFIN supprimé….il était temps vu la polémique qu’il avait entrainé…. Son remplaçant me parait quand meme sous évalué, vu le nombre d’API que nous rencontrons dorénavant.
  4. le A4 2017 me parait quant a lui justifié.

 

Je vous souhaite une bonne lecture, et n’hésitez pas à commenter (cela sera modérer bien sur :)) et a bientot pour de nouvelles explications (en particulier sur les différents éléments et vulnérabilités associées.

 

 

 

 

Le développeur nouvelle génération ?

Ce matin je suis tombé sur un lien intéressant parlant de copier/coller dans un terminal.

Ce lien m a inspiré le billet que voilà. Tout développeur normalement constitué connait bien le fameux site :stackoverflow et pastebin. En effet ces deux sites sont régulièrement utilisés pour résoudre des problèmes que vous avez.

J avais effectué il y a deux ans une petite étude rapide sur une phrase dans Google « se connecter à une base SQL en java » et le retour avait indiqué que 8 réponses sur 10 menaient à des techniques permettant d’effectuer des injections SQL…Dont un lien vers stackoverflow avec une très grande popularité sur la solution (non je vous le copierai pas…).

Lors des différents audits de code, dojo de correction, formations sécurité du développement, je pose régulièrement des questions pièges(et aussi pour tester le niveau de connaissance) aux personnes présentes (souvent des développeurs et architectes) et je suis (à prendre au second degré…) parfois amusé de voir leur réponse..

Je vous donne le processus utilisé :

  1. Rechercher dans Google
  2. Cliquer sur le premier lien parlant (soit un site connu, soit sinon le premier résultat en français, soit un site qui semble bien.)
  3. Reprendre mot pour mot ce qui est écrit

Et on s’aperçoit que c’est le processus standard utilisé par les équipes de développement avant de se plonger vers le wiki interne

Ce processus est réellement risqué. En plus de ne pas correctement augmenter la connaissance, il peut faire peser sur le projet certains risques que le développeur ne voit pas :

  1. Le risque juridique et légal : lorsque l’on copie-colle du code, c’est un vol  de propriété intellectuelle ; le code produit et copié à été produit pour un projet précis et l’inclure dans son propre code comme cela n’est pas forcément autorisé.
  2. Le risque de failles de sécurité ; en effet vu que l’on ne connait pas le framework/outil/éléments, et que l’on est sous pression on s’occupe pas de savoir si c’est une faille ou non, on copie-colle, on teste, si ça marche on commit.
  3. Le risque d’appauvrissement :  Faites attention a ce dernier point ami développeur, regarder la quantité de code disponible sur google.com/github.com et qui ont peut être été entrés dans un Watson….Si vous ne savez pas comment fonctionne ce que vous utilisez, vous pourrez bientôt être remplacés par des machines…

 

 

Sur ce, bon week-end

 

CSRF demystifié et enfin réglé !

Dans le numéro 200 de LinuxMag, vous trouverez un article a la fin sur le CSRF et comment enfin régler le sujet sur l’ensemble de vos plateformes; que cela soit via l’infrastructure ou dans le code.

A force de voir lors de pentests/audit de code ce type de vulnérabilité qui ressort et qui est parfois si simple a corriger, j’ai décidé d’écrire cet article de manière pratique et agnostique.

Au sommaire :

  1. CSRF Késako ?
    1. CSRF OK, mais pourquoi cela fonctionne ?
  2. Quelles sont les solutions à notre disposition ?
    1. Les solutions dans la partie infrastructure (serveurs Web, Serveur applicatif)
      1. Sur Apache
      2. La configuration des filtres de TOMCAT
  3. Les solutions dans la partie code…
    1. Aidons Duke avec la libellule… => Java

      1. Bien sûr, avec des frameworks on arrive aussi à se protéger facilement
    2. Pour les éléPHPants, cela peut être simple, ou pas…
      1. Ciel, je n’ai pas de framework PHP!!!!
    3. Moi le perfectionniste par contre, c’est simple => Python
    4. Mettons notre code à l’abri du CSRF sur de bons rails => Ruby On Rails

 

J’espere que cet article vous sera utile, en tout cas, si cela l’est ou ne l’est pas, n’hesitez pas à me contacter, car il y en a d’autres sur d’autres sujets en préparation, et au plus vite je peux améliorer….