OWASP Montréal reçoit Mario Contestabile

développeurs - vous pouvez arrêter les pirates

View Slide

À propos de moi
• Je vous ai probablement déjà «hacké»
• Vous ne le savez possiblement pas
• Méfiez-vous des solutions miracles
• Tout ce que je vous montrerai aujourd’hui
provient d’un apprentissage de plusieurs années
de travail dans le domaine de la sécurité
• … et d’innombrables experts,
• … et de conférences, et
• de certifications.
• Je travaille chez =>
Company
Logo

View Slide

• Qui engagez-vous pour vos «pen tests»?
• Voici quelques recommandations générales :
– Détaillez vos besoins de cette façon
• Réseaux internes
• Réseaux externes
• Applications
• Forensics (fraude informatique)
• Phishing (hameçonnage)
• Wi-Fi

View Slide

– Sachez ce que vous voulez.
– Ne donnez pas de mandats trop large :
• Par exemple, demandez qu’on scanne 10 000 postes de
travail et qu’on vous fournisse un rapport. Vous
obtiendrez un énorme rapport duquel vous ne retirerez
probablement rien de valable.
• Demandez plutôt d’obtenir l’accès administrateur
contrôleur domaine de ces postes de travail.
• Un «pen test» n’est pas un audit;

View Slide

– Préparez-vous en conséquence
– C’est la partie la plus importante, pour la raison
suivante :
• Les mandats sont typiquement basés sur la durée. Plus
on passe de temps sur des éléments secondaires,
moins de temps est véritablement consacré à effectuer
le «pen test» en question.

View Slide

– Les choses à faire au préalable comprennent
• «Whitelistez» les adresses IP au préalable
• Assignez une ressource au projet qui aura les
connaissances techniques
• Créez les comptes à l’avance
– Si vous me faites attendre pour que toutes ces
choses soient faites, c’est vous qui en ferez les
frais

View Slide

– Une fois les choses en cours
• Attendez-vous à ce qu’il y ait du remous.
• Vous avez quelqu’un qui surveille un SIEM tel Qradar?
Avisez-le.
• Quelqu’un reçoit des courriels d’alerte Incapsula?
Avisez-le.
• Nous avons tous entendu des histoires d’horreur
– phishing tests (des tests d’hameçonnage) qui dérapent
– des systèmes qui tombent en panne inopinément

View Slide

• Pourquoi la segmentation?
– Certaines firmes excellent dans un domaine mais sont
complètement nulles dans un autre.
– Afin d’acquérir une bonne expérience de réseau
interne, les «pen testers» ont besoin d’être fortement
exposés à des situations réelles. Un environnement
Windows où ces connaissances sont indispensables
• NTLM (Pass the Hash, mimikatz)
• RDP (C&A for RDP MiTM)
• VLAN hopping (Protocoles Cisco et outils tels Yersinia,
voiphopper, Ettercap)

View Slide

• Pourquoi la segmentation?
– Informez-vous quand à la taille de l’équipe propre
à ce domaine,
• Combien êtes-vous dans l’équipe «forensics»?
• Quel équipement spécialisé utilisez-vous pour le Wi-Fi?
• Demandez à vos pairs. Domaine bancaire, jeux d’argent,
jeux vidéos, ils ont tous des différences, autant dans les
risques que dans les besoins.

View Slide

• Compliquez-moi la tâche
– Mon rôle est de vous informer des pires scénarios
(à l’intérieur de mon mandat) avant que vous ne
les découvriez par une source anonyme
– Pourquoi cela me donne parfois l’impression que
vous me tenez gentiment la main afin que je
trouve des vulnérabilités et que je les exploite?
Ne procédez pas de cette façon.
– Voici quelques trucs.

View Slide

• Compliquez-moi la tâche (devops)
– Ne me laissez pas exécuter n’importe quoi
n’importe où sans d’abord me faire travailler pour.
– Par exemple : pourquoi puis-je faire ceci?

View Slide

– Résultats Acunetix avec RailsGoat [7267 requêtes;
30 minutes,
6,79 % complété]
– « Point n Click
Hacking »

View Slide

– Résultats Acunetix avec RailsGoat lorsque vous me
rendez la tâche difficile [12625 requêtes; 10
minutes,
100 % complété]
– Rien de plus facile

View Slide

– Règles Ngnix pour bloquer les requêtes avec
mauvaises en-têtes HTTP
if ($http_user_agent ~ (sqlmap|Nikto|Nmap|mysqloit)) {
return 403;
}
– Cela ne m’arrêtera pas, mais…
• Prendra de mon temps
• Empêchera probablement plus d’attaques qu’on pourrait le
penser
– Sur Nginx, si vous êtes à l’aise avec les «regex» et vous
avez beaucoup de temps à y consacrer, voir
https://github.com/nbs-system/naxsi

View Slide

– Règles Apache pour bloquer les requêtes avec mauvaises
en-têtes HTTP
SetEnvIfNoCase User-Agent "^sqlmap" hacker_dude
SetEnvIfNoCase User-Agent "^Nikto" hacker_dude
SetEnvIfNoCase User-Agent "^Nmap" hacker_dude
SetEnvIfNoCase User-Agent "^mysqloit" hacker_dude

Order Allow,Deny
Allow from all
Deny from env=hacker_dude

– Cela ne m’arrêtera pas, mais…
• Prendra de mon temps
• Empêchera probablement plus d’attaques qu’on pourrait le penser

View Slide

• Facilitez-moi la tâche (hacker)
– Pour l’autre moitié des gens dans cette salle, voici ce que
vous devez faire avec Burp pour contourner ces règles.
– Dans Proxy-Options, ajoutez la règle match/replace:
Ou utilisez l’outil spécifiquement:
• Sqlmap --random-agent
• Nmap --script-args http.useragent="foo"

View Slide

• Compliquez-moi la tâche (développeurs)
– Nous avons vu qu’en développement de logiciels il
est possible de faire de petites choses qui feront
en sorte que je travaillerai plus fort, mais qu’en
est-il des développeurs d’application?
– Oui vous le pouvez! Voici comment:

View Slide

– Pourquoi ne pas vous arrêter, réfléchir à la surface
d’attaque de votre application, réfléchir à
l’utilisation normale de votre application, et si
vous détectez des anomalies, réagissez!
– Voici quelques mesures que vous pouvez prendre
dès aujourd’hui, des mesures simples mais
efficaces qui me compliqueront la tâche:

View Slide

• Compliquez-moi la tâche (développeurs) [requête
inattendue]
– Est-ce que la requête se trouve dans une section
seulement accessible après avoir visité une autre
section? Si oui, ai-je visité cette autre section au
préalable? Si je ne l’ai pas fait, déconnectez-moi!
– Exemple concret :
• Requête JSon pour une description de produit après s’être
connecté, sans avoir regardé les produits. Quel utilisateur
normal se connecte, démarre dans son browser le «network
analyzer tool», et décide d’élaborer des commandes «curl»
manuellement… plutôt que de cliquer avec la souris?

View Slide

[requête inattendue]
– Réponse: personne. Si une requête est reçue sans
avoir précédemment regardé le catalogue de
produits, déconnectez-moi!

View Slide

[requête perdue]
– Est-ce que la requête est dans une section qui
n’est même pas indexée?
– Exemple concret:
• Rappelez-vous de notre capture d’écran précédente.
Imaginez que le hacker ait été suffisamment rusé pour
cacher l’empreinte Acunetix. Pouvez-vous quand même
me rendre cela compliqué? Certainement. Voici
comment:

View Slide

[requête perdue]
– Si nous regardons de plus près les requêtes
effectuées, ce sont les suivantes:
• /xmlrpc.aspx
• /xmlrpc.jsp
• /xmlrpc.asp
• /xmlrpc/soap.php
• /xmlrpc/soapserver.php
• Vous savez désormais assurément 2 choses
1. Cet utilisateur est un outil
2. Cet outil est Acunetix
Déconnectez-moi!

View Slide

[Cookies]
– Qu’est-ce que je viens d’envoyer au juste?
– Un exemple. Votre application utilise de un à quatre
cookies lors d’une utilisation normale.
– Les «pen testers» adorent les cookies; ils en ajoutent,
enlèvent ceux qui sont existants, les renomment, les
dupliquent...
– Vous êtes le développeur, vous savez que l’application
requiert ces cookies, et sous quelle forme

View Slide

[Cookies]
– Si le nombre de cookies < que ce qu’il devrait
• Déconnectez-moi
– Si le cookie est < que la longueur minimale prévue OU
si le cookie est > que la longueur maximale prévue
• Déconnectez-moi
– Par exemple, si votre cookie est encodé en
hexadécimal MD5, déconnectez-moi s’il n’est pas
d’une longueur de 32!

View Slide

[Paramètres]
– Ce que je préfère. Vous avez remarqué combien
vous, l’expert de l’application, en savez plus sur ce
qui est attendu ou ce qu’est un comportement
«normal».
– Personnellement, lorsque je vois ceci dans BURP
j’ouvre grand les yeux.

View Slide

• Compliquez-moi la tâche (développeurs)[Paramètres]

View Slide

• Dans cet exemple, c’est assez évident, je vais enlever le CSRF token, le fait qu’il soit là ne signifie pas que vous avez
ajouté la directive dans tout le code!

value="KmnLsfsJnIm6jRRxE05jrmtMEbD8v/63ex7peHAeJ+nSb0Fpb6OXNaclLEJ8yEex4qNAUoelcLSek/es
WSU5xg==" />

value="James will demonstrate awesomeness" />
value="06/14/2016 - 06/14/2016" />

• Pen testers, assurez-vous d’enlever les jetons CSRF, on ne sait jamais!

View Slide

[Paramètres]
• Qu’est-ce qui rend les paramètes si attrayants?
– Cela nous donne à nous les hackers une façon
d’accéder au coeur de votre application. Nous
savons que ces paramètres seront traités dans
votre application, alors nous souhaitons que
certains seront traités incorrectement.
– Y en a-t-il des plus attrayants que d’autres? Oui!

View Slide

[Paramètres]
• N’aidez pas les hackers en utilisant des noms
communs (rappelez-vous notre temps est
limité)
• debug=false
• localDriveName=/mnt/foo
– Cookies avec un format évident IP:date:user

View Slide

– Pourquoi je vous recommande de me
déconnecter?
– Parce que c’est pénible!
– Vous invalidez ainsi toutes mes sessions
– Vous interrompez tous mes scans en cours qui
utilisent la session
– Je dois réauthentifier et possiblement changer
certaines valeurs de cookie dans divers outils

View Slide

[choix d’architecture]
– Authentification / Login
– Conception interne – Vous cherchez le trouble
– Choisissez judicieusement – Des firmes qui avaient
opté pour OpenID ont fait marche arrière
– Considérez les authentifications
fédérées telles que Facebook Login,
Google Sign-in, Microsoft, Twitter, etc.
– Voici pourquoi:

View Slide

– L’authentification est une zone de votre
application qui sera longuement analysée par des
«pen testers». La raison étant que les logins
«custom» sont rarement un succès. Ils sont d’une
difficulté élevée a implémenter correctement.
– Voici quelques exemples de ce que vous devez
vous assurer qui soit parfaitement implémenté si
vous le faites vous-même: (bonne chance)

View Slide

– User farming lors de la création d’un compte
– User farming dans l’option mot de passe oublié
– Session farming au login
– Mot de passe faible lors de la création d’un compte
– Mot de passe faible dans l’option mot de passe oublié
– Nom d’usager commun lors de la création d’un
compte

View Slide

– Attack force brute sur un compte
– Attack force brute sur plusieurs comptes
– Login multiples d’endroits différents
– Login depuis node Tor
– Jeton de session faible
– Jeton de session sans drapeaux de sécurité

View Slide

– Durée de vie d’une session
– Login pas chiffré (http)
– Captchas
– 2FA (Two factor authentification)
– Messages d’erreur mauvais tel que («password incorrect»,
«username not found»)
– Recouvrement du mot de passe (qu’est-ce qu’il y a dans le
courriel)
– Mot de passe oublié (est-ce que vous envoyez un
courriel?)

View Slide

• Éviter toutes ces embûches n’est pas évident
• Si vous pouvez vous permettre de laisser les
meilleurs ingénieurs au monde s’en occuper,
laissez-les faire
• Si je regarde des rapports antérieurs, je vois
chacun de ces problèmes, mais aucune
vulnérabilité avec ces sites qui utilisaient un
gestionnaire d’identification comme moyen
d’authentification

View Slide

– Au lieu de toutes ces tâches, vous pouvez simplement ajouter ceci à
votre site:

Pour une authentification avec Google Sign-in, et
Sign out
 function signOut() { var auth2 = gapi.auth2.getAuthInstance(); auth2.signOut().then(function () { console.log('User signed out.'); }); } 
pour le logout.
– Il y a FB, Twitter, Microsoft et GitHub comme fournisseurs d’identité.

View Slide

• Si vous devez le faire vous-même, faites un checklist
avec chaque item que j’ai énuméré; demandez-vous
comment est-ce que mon application réagirait dans
chacun des cas?
• Si vous écrivez votre code pour que celui-ci utilise un
captcha, nécessite un mot de passe sécuritaire, les
sauvegarde de facon sécuritaire avec un salted hash
(ex: LinkedIn), en utilisant toujours une connexion TLS,
et utilise un reset de mot de passe sécuritaire (ex:
Sarah Palin proof), n’affiche pas de messages d’erreurs
trop détaillés, cela nécessitera tout de même un «pen
test» régulier des systèmes.

View Slide

• Assumons que c’est ce que nous voulons faire.
On est une gang de sécurité, comment
pouvons-nous nous assurer de l’aspect
sécurité de notre application?
1. Ne laissez pas d’exception se propager. Faites
des catch partout, les messages génériques
sont souvent trop détaillés.

View Slide

2. Quand vous traitez les paramètres d’un
formulaire Web, faites une validation avant
de les traiter! Par exemple

Si vous recevez:
“OR 1=1—”
Clairement ce n’est pas un usager normal. Il
faudrait que le browser soit corrompu pour que
ça arrive. Il y a 9 caractères! Déconnectez-moi!

View Slide

• Et ceci

Dans votre code, typiquement vous ferez ceci:
If not digit(val):
return null;
Mais ça ne sera jamais le cas! Et si ça arrive, eh bien
vous êtes sous attaque! Soyez proactif et protégez-
vous. Par exemple:
If not digit(val):
log_out();
return null;

View Slide

• Prenez cet exemple d’un formulaire avec:

Et par magie vous recevez ceci
foo=bar&country=Norway OR mario==mario
Ça ne fait pas de sens. Déconnectez-moi. Votre
application vous remerciera, sinon elle sera
soumise à beaucoup de stress. Et soyez sans
crainte, vous ne pouvez pas accidentellement
recevoir une valeur autre que «Canada».

View Slide

3. Enregistrez tout ce qui est sérieux
• Tel que, de la fonctionnalité active seulement
lorsqu’un cookie est présent (admin=true).
• Fonctionnalités reliées à l’authentification.
Ajoutez du logging intelligent qui démontre
clairement ce qui se passe. Par exemple, si vous
pouvez voir «James» a changé le mot de passe
d’«Alice», c’est clair.
• Toutes tâches administratives. Par exemple,
«James» a supprimé le compte «Alice».

View Slide

4. Sauvegardez vos données de façon à ce que
quand je les volerai, elles seront illisibles.
– J’ai extrait des numéros de cartes de crédit en
clair, des numéros d’assurance sociale en clair,
ainsi que des mots de passe. Non pas de sites
«mom and pop» mais d’un magasin en ligne,
d’une université et d’un CMS. Ceci ne devrait
jamais arriver, le pire c’est que je partirais avec des
données illisibles.

View Slide

5. Utilisez les fonctionnalités des browsers.
– Il y en a et elles sont supportées de plus en plus. Laissez
simplement votre application mettre en marche ces
fonctionnalités de sécurité! Pourquoi ne pas le faire?
– Assurez-vous que vos connexions sont chiffrées avec TLS
• Strict-Transport-Security:
– Fichier téléchargé et visible des autres usagers du site?
• X-Content-Type-Options: nosniff
– Vous ne voulez pas votre contenu sur d’autre sites?
• X-Frame-Options: deny
– Cross-site Scripting
• X-XSS-Protection: mode=block

View Slide

6. Utilisez un fournisseur d’identité pour votre
login
– Laissez-les s’occuper du reset de mot de passe, de
la politique de mot de passe, des attaques par
force brute, des comptes volés et de la sauvegarde
sécuritaire.
– Économisez sur vos coûts de développement
– Économisez sur la maintenance et aussi payez
pour que vos «pen tests» se concentrent sur la
vraie fonctionnalité de votre application

View Slide

7. Whitelist
• Qu’est-ce qu’on devrait whitelister? On se fait
dire que ceux-ci ne sont pas bons.
• Pensez à toutes ces vulnérabilités parce que
vous n’avez pas envisagé la possibilité que la
valeur soit hors contexte. Par exemple:
– export=filename.excel becomes export=/etc/pswd
– uploadfile=foo.txt becomes uploadfile=/etc/pswd
– downloadfile=image.jpg becomes downloadfile=/stc/paswd

View Slide

• Validez selon le gros bon sens, et sauver des
heures de frustration.
– Si le fichier a télécharger n’a pas l’extension «jpg»,
enregistrez l’erreur et déconnectez-moi.
– Si le fichier a télécharger est plus grand que 200k,
enregistrez l’erreur et déconnectez-moi.
– Et pourquoi ne pas verifier si le fichier a exporter
est bel et bien un «.excel»? Et que celui-ci
provient du répertoire «/export» avant de
l’envoyer?

View Slide

• Suivez ces sept règles et optimisez vos chances de
survie sur le net
1. Attention aux exceptions
2. Vérifiez vos paramètres
3. Enregistrez les opérations intéressantes
4. Utilisez les browsers à leur plein potentiel
5. Le login est un monstre, pensez-y
6. Un «whitelist» peut prévenir des surprises
quand on envoie des informations aux clients

View Slide

• Choses pour lesquelles les «pen tests» ne sont
pas super efficaces
– Code review
• C’est compliqué
• Ça prend beaucoup de temps
• C’est spécifique au langage
– Firewall rules review
• C’est très dépendant du réseau en place
• Ça prend un gars réseau Cisco

View Slide

• Applications très «Domain specific» dans le
genre médical ou finances où des opérations
ne devraient pas être permises mais elles le
sont.
– Un «pen tester» ne peut pas savoir que c’est un
cas invalide pour ce domaine
• Service Web complexe à la SOAP
– Ça nécessite souvent des appareils ou des clients
software, en plus de la doc complète, pour
comprendre le protocole, et après l’exploiter

View Slide

OWASP Montréal reçoit Mario Contestabile

OWASP Montréal reçoit Mario Contestabile

OWASP Montréal

More Decks by OWASP Montréal

Other Decks in Technology

Featured

Transcript