Catégories
conférences

OWASP Appsec EU – J2

Hans Folmer ( CO Defence Cyber Command )

Comparaison entre les techniques de défense historiques avec la sécurité informatique. On connait tous la limite des analogies dans le domaine. De la maison romaine avec ses palissades à la sécurité des frontières. La défense en profondeur est venue à la 2ème guerre mondiale et pendant la guerre froide. Lors de la guerre en Afghanistan, l’ennemi était déjà là, et les attaques se faisait sur tout les éléments, tout comme les système informatique sont parfois déjà compromis.

Le ministère de la défense néerlandais (MoD) à 4 composantes « cyber », un CERT, Un service de renseignement (sous contrôle du parlement néerlandais), une police militaire en charge des crimes visant le MoD ou des soldats commettant des crimes, et un service d’opérations militaires « cyber ». Le MoD ne peut entrer en cyber-guerre qu’après une attaque informatique causant des dégats similaires aux dégats des armes conventionnelles (morts, dégâts aux infrastructures, etc…) et sur décision du parlement néerlandais. Les autorités néerlandaises appliquent une politique de « responsible disclosure » mais quand il s’agit du ministère de la défense, les choses sont gérés au cas par cas.

Les opérations militaires « cyber » peuvent viser les composants physiques, conceptuels (organisation, communication) ou encore le moral des troupes. Une « cyber » opération consiste à employer des moyens informatiques pour affecter ces composants. Exemple avec un soldat qui utilise un téléphone peut être démoralisé ou manipulé au travers de son téléphone (plus moyen de jouer à candy-crush ?).

Pour mettre au points ces capacités « cyber », il faut des hommes, des environnements de test et beaucoup beaucoup de renseignement pour viser le bon système (et pas celui d’un allié), et s’assurer qu’il s’agit d’un système militaire. Si les militaires utilisent des armes, ils doivent justifier l’emploi de leurs armes, et montrer qu’ils ont tout fait pour éviter les domages collatéraux, cette règle s’applique aussi aux opérations informatiques.

E-Banking transaction authorization

Un talk sur les erreurs d’implémentation et de mise en oeuvre de solutions de payement en ligne. L’authentification à 2 facteurs comme l’envoie d’un code par SMS n’est pas toujours très bien implémenté. Cette authentification à 2 facteurs peut aussi se faire via un lecteur de carte externe et non connecté qui génère un code unique à rentrer dans l’application web pour autoriser la transaction. On retrouve aussi les OTP, les claviers externes pour saisie d’un code PIN, voir des dongles USB connecté au PC. Toutes ces idés sont super, mais leur implémentation laisse parfois à désirer.  Ex: pour les SMS, le montant n’est parfois pas indiqué, ni la raison du SMS. Du coup un malware peut manipuler l’utilisateur, et on à aucun moyen de vérifier à quoi est destiné le code. Parfois, l’application demande le n° de téléphone pour envoyer le SMS… l’utilisation du même mécanisme d’authentification forte pour l’authentification et la validation d’une transaction permet à certains malware de simuler une erreur de saisie pour effectuer une transaction à l’insu de l’utilisateur.

Une CheatSheet et une extension à l’ASVS pour les transactions bancaires va être releasé !

WebRTC, Or How Secure Is P2P Browser Communication ?

WebRTC est une API de communication qui permet aux navigateurs d’établir des communications VoIP entre navigateurs. C’est un peu du skype dans le navigateur. La communication est splitté en deux, la signalisation, et les flux voix/image qui suivent un autre chemin. La signalisation est gérée par le serveur web qui fait l’intermédiation. Toutes ces opérations sont gérés par le navigateur au travers d’une API JavaScript. WebRTC accroit la surface d’attaque du navigateur, comme l’échange en direct d’informations et donc potentiellement d’attaques au travers de la connexion P2P. L’accès à la caméra et au micro se fait par autorisation utilisateur. Par contre la collectes d’informations ICE & réseau se fait sans le consentement de l’utilisateur. De même pour l’établissement d’un flux P2P entre navigateurs. De même on est pas informé si l’autorisation donnée pour l’accès caméra/micro est utilisée pour envoyer ces flux ou que ce soit. Une fois l’accès autorisé, l’utilisateur n’est pas notifié de l’envoi de ces flux. Le partage d’écran n’est pas toujours soumis à une autorisation utilisateur. La gestion de l’authentification au travers d’une délégation d’identification ne permet pas de choisir son « autorité d’identification ». Enfin, il n’y a aucun moyen d’authentifier les pairs dans l’établissement de la communication.

Comme les utilisateurs n’aiment pas avoir une tonne de popup pour gérer ces autorisations, il n’y a pour l’instant aucun moyen de gérer les actions WebRTC finement pour l’utilisateur. Une fois l’accès caméra/micro fait, on ne peut plus contrôler le reste des actions du navigateurs durant la session. (il va falloir trouver un noscript like pour WebRTC :/ ).

WebRTC autorise l’exécution de code JavaScript tiers en provenance d’un site différent de celui qui gère la signalisation. Il est aussi possible d’obtenir l’IP locale du pc via JavaScript, ce qui impacte grandement la vie privée, mais est requis pour le bon fonctionnement de l’établissement d’une connexion p2p. Lors de l’établissement des connexions, Un navigateur peut re-diriger le flux d’information, ce qui permet l’établissement d’attaques MitM sur le flux RTC via une XSS. L’utilisation d’Identity Provider permet d’éviter ce MitM grâce au mécanisme de délégation de signature, car les signatures ne colleront pas à l’établissement de la communication. Ce travail d’identification et de vérification de signature est à la charge du site web qui génère l’établissement de la communication. Mais comme WebRTC est en developpement, des solutions commencent à arriver pour éviter ce problème, en fournissant la signalisation et l’ « identity provider » sur le même serveur.

Il faut donc retenir que WebRTC augmente la surface d’attaque et ses capacités de communication. Son modèle de permissions est très grossier, et l’utilisateur n’a que peu de contrôle sur les actions du navigateur. Il faut donc se méfier des codes JavaScript tiers. Il va falloir composer avec ce nouvel ensemble de capacités et les problèmes qui vont avec.

So you want to use WebView ?

Une présentation sur les WebView Android. WebView c’est un composant android qui permet d’afficher du HTML dans une application Android. Les versions avant « kit-kat » étaient basé sur WebKtt, les nouvelles versions sont basé sur Chrome.Les webview contiennent une API pour appeller du code Java depuis le code JavaScript. Ce mapping se fait via addJavascriptInterface. Mais ce mécanisme ne gère pas la SOP. En 2012, c’était un point d’accès à l’ensemble des méthodes de l’application, permettant l’exécution de code avec les privilèges de l’application android. Google à fournis un patch avec un mécanisme d’annotation. Mais s’il n’y a pas de mapping via JavaScriptInterface, l’application est-elle vulnérable ?  Oui, via « javascript reflexion attack« .

Il est possible de faire du MitM sur les ressources récupérés par la WebView, et la chaine de certification n’est pas toujours vérifiée comme il faut. Pour prévenir ça, le « certificate pinning » doit être employé, mais dans une WebView, c’est très complexe, et c’est parfois mal fait. De même les urls spéciales d’android peuvent être injectés au travers d’une WebView et déclencher des Intent, il faut donc en être conscient.

Secure the Internet of Things

Les guides de sécurisation et autres conseils sont une réponse à des menaces découvertes au fil de l’eau, les applications, les sites web, la crypto contre les écoutes, etc… et maintenant c’est le tour des objets connectés. On trouve des gadgets connectés très débiles, qui mesurent des trucs bizares et inutiles mais profite d’une bulle d’investissement. Comme par exemple, une bouilloire électrique sans bouton qu’on peut allumer que via un smartphone. Ou un smart-glass qui mesure ce que vous buvez et en quelle quantité, ou des chaussettes intelligentes, avec une technologie d’appairage unique au monde… Bon l’internet des objets, ce n’est pas que des gadgets débiles. Gestion d’énergie, périphériques médicaux, smart-tv, systèmes avioniques, on trouve tout ces petits smart-devices partout. Les usages sont vastes, mais les technologies employés sont très spécifiques:  Des senseurs, un objet contenant le cpu et collectant les infos des senseurs et une capacité réseau (wifi ou bluetooth), une application mobile et/ou web, et un accès au cloud parceque c’est « économique », et un backend de collecte de donnée qui permet de revendre ces donnés.

Les senseurs peuvent fournir des données pas forcément dans les paramètres attendus, il faut donc les vérifier. L’objet en lui même n’est pas toujours suffisamment performant pour embarquer les mécanismes de sécurité employés usuellement.  La sécurité du cloud derrière peut avoir de l’importance, ces données peuvent un jour être récupéré par des tiers. Imaginez votre assurance santé récupérant des stats d’activité physique pour adjuster le prix de votre couverture maladie ?

L’application web de gestion de l’objet connecté peut se reposer sur l’ASVS. Lorsqu’il s’agit de données de santé très sensibles, on pourrais imaginer l’employer jusqu’au niveau 3 (le plus drastique, et le plus élevé). Le backend de gestion peut lui aussi être accédé, et compromis, entrainant le vol des données collectés sur l’ensemble des smart-devices. Le financement du service associé à l’objet nécessite un financement, qui s’obtient souvent par la revente des données collectés par les objets connectés.

L’OWASP à un Top10 pour les objets connectés et nombre d’objets connectés présentent tous un certain nombre des problèmes identifiés dans ce Top10. Mais certain des éléments du Top10 vont à l’encontre de l’utilisabilité de l’objet ou de l’application associée dont le paradigme se veut simple voir simpliste. Il n’est pas garanti que si l’utilisateur à la possibilité de configurer l’objet de façon sécurisé il le fasse correctement. La mise en œuvre de mécanismes cryptographiques pour protéger l’échange d’information avec l’objet ou son accès se heurte à la faible puissance des micro-contrôleurs et de leur prix.

Il va falloir que le Top10 IoT se place du coté de l’intérêt des utilisateurs, tienne compte de l’impact des recommandations sur l’utilisabilité, promeuve l’ouverture des architectures de ces objets connectés pour qu’ils puissent être bidouillé et amélioré par la communauté. Seule cette ouverture permettra de s’assurer que les intérêts des utilisateurs sont préservés.

Finding bad needles on a worldwide scale

Recherche de XSS réfléchis à très grande échelle. Les XSS pour yahoo sont une source régulière d’incidents de sécurité, et les plus remontés dans le BugBounty de yahoo. Lorsqu’on fait des tests à large échelle, il faut à tout prix éviter les faux positifs, sous peine d’avoir un mauvais ratio signal/bruit. Pour valider le fonctionnement d’un scanner de XSS réfléchis, il vous faut un bon environnement de test, c’est ce que yahoo à fait avec WebsecLab, sous la forme d’un ensemble de scripts implémentant des cas de vulnérabilités XSS. Leur environnement de test contiens aussi un grand nombre de faux positifs.

Scanmus est un outil de scann de XSS réfléchis de yahoo. Avec un mécanisme de détection du succès de l’injection à base d’expressions régulières (mouai hein… ). Du fait de ce design, et de son modèle de fonctionnement, ce scanner produit un grand nombre de faux positifs (et probablement pas mal de faux négatifs). Du coup pour améliorer ça, Yahoo utilise d’autres outils et consolide les résultats en faisant aussi tourner Arachni, Skipfish et Tainted PhantomJS.(ça ressemble à ce que font les gars d’OWTF). Mais un grand nombre de faux positifs sont remonté malgrès tout. Il a donc fallu trouver un moyen d’analyser plus finement les résultats. Souvents ces problèmes de détections sont lié à une mauvaise prise en compte du contexte de l’injection. Pour se faire, il faut donc employer un vrai parseur. L’orateur à donc utilisé le parseur HTML5 de go, et un interpreteur JS en go pour construire un analyseur de contexte, et vérifier s’il s’agit d’un faux positif. 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *