La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
OVHcloud => Discussion démarrée par: lancelot77 le 22 juillet 2013 à 18:31:59
-
OVH : Un hacker s’empare de la base de données clients
Bonjour,
Il y a quelques jours, nous avons découvert que la sécurité de notre réseau interne dans nos bureaux à Roubaix a été compromise. Après les investigations en interne, il s'avère qu'un hackeur a réussi à obtenir les accès sur un compte email d'un de nos administrateurs système. Grâce à cet accès email, il a obtenu l'accès sur le VPN interne d'un autre employé. Puis grâce à cet accès VPN, il a fini par compromettre les accès
de l'un des administrateurs système qui s'occupe du backoffice interne.
Jusque là, la sécurité interne se basait sur 2 niveaux de vérification:
- géographique: l'obligation d'être au bureau ou utiliser le VPN, l'ip source
- personnel: le mot de passe
Les mesures prises suite à cet incident
---------------------------------------
Immédiatement suite à ce hack, nous avons modifié les règles de sécurité en interne:
- les mots de passe de tous les employés ont été régénérés sur tous les types d'accès.
- nous avons mis en place un nouveau VPN dans une salle sécurisée PCI-DSS avec accès très restreints
- la consultation des emails internes n'est désormais possible qu'à partir du bureau/VPN
- tous les salariés passent sur 3 niveaux de vérification:
- l'ip source
- le mot de passe
- le token hardware personnel (YubiKey)
Constat
-------
Après nos investigations internes, nous supposons que le hackeur a exploité ces accès pour parvenir à 2 objectifs:
- récupérer la base de données de nos clients Europe
- gagner l'accès sur le système d'installation de serveurs au Canada
La base de données de clients Europe comporte les informations personnelles de clients: le nom, le prénom, le nic, l'adresse, la ville, le pays, le téléphone, le fax et le mot de passe chiffré.
Le chiffrement du mot de passe est "salé" et basé sur SHA512, afin d'éviter le bruteforce. Il faut beaucoup de moyens technique pour retrouver le mot de passe en clair. Mais c'est possible. C'est pourquoi nous vous conseillons de changer le mot de passe de votre identifiant. Un email sera envoyé aujourd'hui à tous nos clients expliquant ces mesures de sécurité et les invitant à changer le mot de passe.
Aucune information sur les cartes bancaires n'est stockée chez Ovh. Les informations sur les cartes bancaires n'ont ni été consultées ni copiées.
Quant au système de livraison de serveurs au Canada, le risque que nous avons identifié est que si le client n'avait pas retiré notre clé SSH du serveur, le hackeur aurait pu se connecter à partir de notre système pour récupérer le mot de passe enregistré dans le fichier. La clé SSH n'est pas utilisable à partir d'un autre serveur, uniquement de notre backoffice au Canada. Et donc dans la mesure où le client n'a pas enlevé notre clé SSH et n'a pas changé de mot de passe root, nous avons immédiatement changé le mot de passe de son serveurs dans le DC à BHS, afin d'annuler ce risque là. Un email sera envoyé aujourd'hui avec le nouveau mot de passe. La clé SSH sera désormais effacé de manière systématique à la fin de la livraison du serveur aussi bien au Canada qu'en Europe. Si le client a besoin d'Ovh pour le support il devra réinstaller une nouvelle clé SSH.
De manière globale, le backoffice passera dans les prochains mois sous la norme PCI-DSS qui nous permettra de garantir que le cas d'incident lié à un hack précis sur les personnes précises il n'y ait pas d'impact sur nos bases de données.
En un mot, nous n'avons pas été assez parano et on passe désormais en mode parano supérieur. Le but est de garantir vos données et se prémunir contre l'espionnage industriel qui viserait les personnes travaillant chez Ovh.
Nous déposons aussi une plainte pénale auprès des autorités judiciaires. Afin de ne pas perturber le travail des enquêteurs, nous n'allons pas donner d'autres détails avant d'avoir les conclusions finales.
Veuillez accepter nos sincères excuses pour cet incident. Merci pour votre compréhension.
Amicalement
Octave
Source : OVH (http://travaux.ovh.net/?do=details&id=8998)
-
tous les salariés passent sur 3 niveaux de vérification ».
Normalement, le 3eme niveau de sécurité passera par un token physique personnel.
-
Token YubiKey.
-
Le chiffrement du mot de passe est "salé" et basé sur SHA512, afin d’éviter le bruteforce.
chiffrement -> hachage
Le hachage du mot de passe est "salé" et basé sur SHA512, afin d’éviter le bruteforce.
Pardon?
En quoi une méthode de hachage cryptographique évite l'attaque par force brute?
C'est n'importe quoi! Celui a écrit/conçu ça est totalement incompétent et ignorant des bonnes pratiques minimum qui ont cours pour un problème identifié au moins depuis la fin des années 70.
Je suis consterné.
-
Je comprends ta consternation mon cher corrector, mais pourrais-tu expliquer le soucis pour le néophyte que je suis ?
-
Imagine que je marque le code PIN (d'une SIM Free Mobile ou d'une CB) sur l'appareil, tu vois le problème?
Imagine que je marque le MD5(code) à la place, est-ce que c'est mieux?
-
Imagine que je marque le MD5(code) à la place, est-ce que c'est mieux?
Dépends - à mes yeux - de la facilité à passer du MD5 au code PIN. Si ils utilisent du gros sel ça ne limite pas très fortement le bruteforce (et les rainbow ?) ?
-
Il doit être Hash avec une clé, ce qui rend le brute force encore plus difficile, vu que ce n'est pas le mot de passe directement qui est hash.
J'ai déjà vu une méthode qui hash le mot de passe, ensuite on rajoute une clé, puis on rehash.
D'après moi, c'est très compliqué de revenir à la source, mais je ne suis pas un pro, en protection ;D
-
Dépends - à mes yeux - de la facilité à passer du MD5 au code PIN.
Retrouver x à partir de MD5(x)?
Il n'y a aucune méthode efficace connue.
Si ils utilisent du gros sel ça ne limite pas très fortement le bruteforce (et les rainbow ?) ?
Du genre :
MD5(PIN || salt)
|| est la concaténation
-
Il doit être Hash avec une clé, ce qui rend le brute force encore plus difficile, vu que ce n'est pas le mot de passe directement qui est hash.
J'ai déjà vu une méthode qui hash le mot de passe, ensuite on rajoute une clé, puis on rehash.
Quelque chose comme ça
hpw = H(H(pw) || s)
pw = mot de passe
hpw = mot de passe haché
s = graine = nombre aléatoire stocké avec hpw
H pouvant être MD5, SHA1...
Encore une fois, on ne connait aucune méthode générale de retrouver x à partir de H(x) pour H = MD5 ou SHA1 ou SHA512
Mais si tu utilises ça avec ton code PIN de SIM Free Mobile, tu crois avoir la moindre sécurité?
On suppose que l'on dispose d'une bête de course comme le Macintosh Classic (Motorola 68000 à 3 MHz) afin de casser ce code.
-
Je vais faire exprès de pas changer mon mot de passe pou voir :)
-
chiffrement -> hachage
Pardon?
En quoi une méthode de hachage cryptographique évite l'attaque par force brute?
C'est n'importe quoi! Celui a écrit/conçu ça est totalement incompétent et ignorant des bonnes pratiques minimum qui ont cours pour un problème identifié au moins depuis la fin des années 70.
Je suis consterné.
L'affirmation se base à mon avis sur le fait que SHA512 rend assez lente une attaque par bruteforce.
Faudrait vérifier la vitesse avec une carte Gfx.
-
Bonjour tout le monde,
n'ayant pas grand chose à faire ce matin j'ai lancé un petit benchmark bruteforce GPU sur 2 ATI HD7950 histoire de donner une idée de vitesse (config coûteuse pour quelqu'un qui désire uniquement du bruteforce => 500-600 Euros) :
Résultats :
md5($pass) : 14.5 GHashs/s
md5($salt.$pass) : 14.5 GHashs/s
sha512($pass) : 51.2 MHashs/s
sha512($salt.$pass) : 51.2 MHashs/s
Du coup on constate que si le $salt est concat au $pass avant d'appliquer la fonction => pas de dégradation de la vitesse de bruteforce.
Du coup, il serait intéréssant de tester : sha512($salt.sha512($pass)) pour voir la facon dont la vitesse de calcul se trouve réduite.
Néanmoins de base, un hash sha512 est environ 283 fois plus lent à calculer que un en md5.
Infos complèmentaires :
Outil utilisé : oclHashcatlite
OS : Ubuntu server
Drivers : AMD catalyst 12.8
En espérant que cela serve comme le demandait l'ancien post ;)
Désolé si cet article possède certaines inepsies ou utilisation de termes mal appropriés.
Bonne journée à tous.
-
Pour un néophyte comme moi, ca prend combien de seconde pour cracker un mdp de 8 caractères alphanumériques ?
8^36 soit environ 5 jours ?
Avec une machine pour miner les bitcoins ça devrait prendre beaucoup moins de temps ?
-
@K-net :
Quand tu parles de machine pour miner les bitcoins ce sont celles à base d'ASIC ? Pour celle-ci je crois que l'algo est spécifique au bitcoin et est écrit en dur dedans, nan ? Du coup tu pensais le modifier pour la transformer en machine à bruteforce ? Pour l'ASIC du coup je pense ce n'est pas possible.
Après si tu parles de ré-utiliser les machines bitcoins à base de FPGA, une personne a rendu publique le code vérilog prenant en charge le bruteforce md5 et sha-1 pour les autres algos j'en ai aucune idée. Plus d'informations ici :
http://nsa.unaligned.org/ (http://nsa.unaligned.org/)
Pour les bitcoins miners à base de CG, l'outil que j'ai utilisé convient amplement pour du bruteforce GPU et sa compatibilité avec les CG est large que ce soit chez Nvidia ou ATI.
Concernant ton autre interrogation, je dis peut-être une bétise mais du coup le calcul ne se fait pas de facon inverse dans ton cas ? J'aurais pensé à 36^8 pour obtenir le nombre de combinaisons maximums à tester. De plus le temps nécéssaire dépendra de la fonction de hashage utilisée
J'essaye d'illustrer mes propos :
Cas n° 1 :
Si ton mdp est composé de [a-z][0-9] => 26 + 10 = 36 caractères
[a-z][0-9] => 36^8 = 2,82111E+12 combinaisons possibles à tester
Cas n° 2 :
Si ton mdp est composé de [a-z][A-Z][0-9] => 26+26+10 = 62 caractères
[a-z][A-Z][0-9] => 62^8 = 2,1834E+14 combinaisons possibles à tester
Exemples : (je récupère les vitesses de bruteforce de mon post précédent)
Temps nécéssaire pour du md5($mot_de_passe) :
Prenons une vitesse de 14.5 GHashs/s
Bruteforce [a-z][0-9] = (2,82111E+12) / (14.5*10^9) = 195 secondes => environ 3 minutes
Bruteforce [a-z][A-Z][0-9] = (2,1834E+14) / (14.5*10^9) = 15057 secondes = 250 minutes => environ 4h12min
Temps nécéssaire pour du sha512($mot_de_passe):
Prenons une vitesse de 51.2 MHashs/s
Bruteforce [a-z][0-9] = (2,82111E+12) / (51.2*10^6) = 55099 secondes => environ 918 minutes => 15 heures 20 minutes
Bruteforce [a-z][A-Z][0-9] = (2,1834E+14) / (51.2*10^6) = 4264455,187 secondes => environ 1184h30min => environ 50 jours
Quelqu'un peut-il confirmer ces calculs car le soleil, les apéros de l'été et les barbecues ne contribuent pas à mon efficacité intellectuelle en ce moment.
Bonne journée à tous :)
EDIT : les chiffres calculés sont corrects si l'on sait à l'on cherche à bruteforcer un mdp d'une longueur précise de 8 caractères.
-
punaise un mot de passe de 32 caractère se pète en max 15h??? (avec le chiffrement qui va bien sinon c'est la cata)
et si on rajoute les caractères spéciaux dans l'équation (genre $!@: )
ça donne quoi?
-
@butler_fr :
les simulations faites ci-dessus sont pour un mdp d'une longueur de 8 caractères. Désolé si le post n'est pas claire je vais l'éditer dans l'heure qui suit.
-
ahhhhh....
déjà ça me va mieux ;)
-
pour moi on pourrait résumé sous forme mathématique:
soit X le nombres de caractères
Y le nombres de possibilités
Z le nombres de combinaisons testées / secondes
avec:
Y1 = [a-z] = 26 combinaisons
Y2 = [a-z][0-9] = 36
Y3 = [a-z][A-Z][0-9] = 62
Y4 = [a-z][A-Z][0-9][CS] = 106
CS = caractères spéciaux = !?_-,.;:$€£%@()[]=+'µ*#/\|{}"<>°^~ = environ 34 caractères (j'ai du en zapper)
on a donc :
(X ^ Y) / Z
ici:
Z(sha512) = 51,2*10^6
Z(md5)= 14,5*10^9
ça semble cohérent comme calcul!
par contre la on parle bien d'une durée maximale possible, selon la méthode de calcul (commencer par le début ou la fin,.....) le mot de passe peu très bien être retrouvé avant!
-
L'approche mathématique semble effectivement plus allégée et plus claire que mes explications certainement :D
Du coup je suis en train de définir mes charsets pour mon outil de bruteforce donc je vérifierais ce soir par la pratique mes résultats annoncés théoriquement.
Néanmoins, je constate que les temps que j'ai calculés ci-dessus s'avèrent faussés car on sait à l'avance que le mdp fait 8 caractères de longueur mais du coup j'aurais du procéder de la sorte (avec charset [a-z][A-Z][0-9]) :
Temps de bruteforce total = temps pour bruteforce 62^1 combinaisons + temps pour bruteforce 62^2 combinaisons + ...+ temps pour bruteforce 62^8 combinaisons.
De cette facon, en plus de toutes les combinaisons longues de 8 caractères, on génère aussi les combinaisons inférieures possibles, c'est à dire l'ensemble des mots de passe d'une longueur comprise entre 1 et 7 caractères.
C'est du bruteforce bourrin et incrèmental je le reconnais.
Par ailleurs cela s'optimise et un très bonne article se trouve sur le wiki de OclHashcat concernant ce que l'on appelle le maskprocessor.s
Si butler_fr tu ressens le courage de généraliser cela sous la forme d'une formule mathématiques :P
-
Je plussoie la méthode GPU avec hashcat et le calcul.
-
punaise un mot de passe de 32 caractère
ne se pète pas du tout, même si tu n'utilises que des chiffres dans le mot passe; le calcul à la main est facile :
10^32 > 8^32 = (2^3)^32 = 2^96
2^96 combinaisons ce n'est pas faisable, même pour simplement faire une opération triviale.
Autrement dit, même si le "hachage" du mdp est l'identité et que tu veux néanmoins l'attaquer en force brute, ce n'est pas faisable.
-
Y1 = [a-z] = 26 combinaisons
Y2 = [a-z][0-9] = 36
Y3 = [a-z][A-Z][0-9] = 62
Y4 = [a-z][A-Z][0-9][CS] = 106
CS = caractères spéciaux = !?_-,.;:$€£%@()[]=+'µ*#/\|{}"<>°^~ = environ 34 caractères (j'ai du en zapper)
Tu as essayé de mémoriser une suite aléatoire ainsi composée? ;)
-
Temps de bruteforce total = temps pour bruteforce 62^1 combinaisons + temps pour bruteforce 62^2 combinaisons + ...+ temps pour bruteforce 62^8 combinaisons.
De cette facon, en plus de toutes les combinaisons longues de 8 caractères, on génère aussi les combinaisons inférieures possibles, c'est à dire l'ensemble des mots de passe d'une longueur comprise entre 1 et 7 caractères.
Oui bien sûr, mais comme ce qu'on cherche est l'ordre de grandeur de la difficulté et non une valeur exacte qui n'a aucun intérêt de toute façon (elle dépend du matos utilisé, c'est un maximum d'où on peut déduire une moyenne, etc.).
On sait qu'on va arrondir le résultat de toute façon, donc une erreur de l'ordre de 2 % n'a pas d'importance.
Bien sûr, dans un exercice de math, on demanderait le résultat exact, en terme de combinatoire (un nombre entier). Aucune tolérance en cas d'oubli des mots de passe plus courts dans ce cas. Mais le résultat "physique" en temps de craquage n'est pas un résultat de combinatoire, c'est un calcul d’ingénierie "à la louche".
Note : tu considères donc que le mdp vide n'est pas accepté par le système!
-
Bonjour,
quelle réflexion bien matinale ;D
Merci pour tes éclaircissements et cet apport en complèments théoriques qui me manquaient.
Par ailleurs, j'ai pu tester hier soir plusieurs simulations et je confirme le temps nécassaire tester toutes les combinaisons de 8 caractères avec un charset de 62 caractères et en hash md5. J'ai mis 4h24 à faire le test (Attention à bien gérer température des CG :) )
Si jamais un autre passionné décide de faire des tests chez lui, qu'il n'hésites pas à me contacter pour échanger infos et astuces sur la config, etc...
En tout cas même si sujet à l'origine sur OVH sort légèrement de son cadre, la conversation reste plus qu'intéréssante.
-
@corrector
Vive les mots de passe composé d'une phrase
"Le 27.07.2013, nous faitions les 37 ans de Frank"
48 caractères alphanumériques avec majuscules et caractères spéciaux facile à retenir.
-
Oui!
Avec une faute pour piéger les logiciels de cassage très évolués qui fabriquent des phrases.
-
(https://lafibre.info/images/bistro/201308_password_strength.png)
-
@jack :
Roooh mince, moi qui m'amusait à apprendre des clés WEP128 bits (hexa) par coeur pour faire office de mdp :D :D
Je comprends mieux maintenant ce qui m'a grillé le cerveau...
-
Le choix des mots de passe, c'est simple : si vous prenez comme mdp :
correct horse battery staple
vous ne risquez rien.
J'ai bon?