La société propose des comptes email gratuits et payants depuis de nombreuses années. Au début de la semaine, elle a été victime d'une attaque dévastatrice, et c'est peu de le dire.
« L'attaquant a formaté tous les disques de chaque serveur. Toutes les machines virtuelles sont perdues. Tous les serveurs de fichiers et de sauvegarde sont perdus », explique la société sur Twitter.
La société affirme avoir « surpris » l'attaquant « en plein formatage du serveur de sauvegarde ». La société doit maintenant se rendre dans le datacenter pour voir si des données peuvent encore être récupérées. « Si c'est possible, nous pouvons restaurer le courrier, mais la plus grande partie de l'infrastructure est perdue ».
Seule bonne nouvelle : les sauvegardes aux Pays-Bas semblent intactes et le service devrait y fonctionner correctement. VFemail craint par contre que « toutes les données basées aux États-Unis ne soient perdues ».
« Étrangement, toutes les machines virtuelles ne partageaient pas la même méthode d'authentification, mais toutes ont été détruites. C'est plus qu'une attaque ssh avec plusieurs mots de passe ». La société ajoute qu'il n'y a pas eu de demande de rançon : « juste une attaque et une destruction ».
Sur son site, VFemail indique que la réception des emails est de nouveau opérationnelle, comme le webmail. Il s'agit par contre de nouvelles boîtes de réception, sans dossier ni filtre. Les clients gratuits ne peuvent pas envoyer d'email, mais ceux qui ont un compte payant oui.
Enfin, dernière recommandation : si vous avez un client de messagerie avec vos messages, ne le synchronisez surtout pas avec les serveurs de VFemail : « Si vous reconnectez votre client à votre nouvelle boîte aux lettres, tous vos messages locaux seront perdus ».
On attend maintenant de connaître le ou les auteurs.
Commentaires (35)
#1
si je peux me permettre une petite virée dans le complotisme, je dirais que quelqu’un avait intérêt a faire disparaître quelques mails et a voulu caché en effaçant la totalité des serveurs.
#2
Quelle boucherie… ça me semble absolument incroyable que quelqu’un puisse faire ça. Seul un administrateur très haut placé devrait pouvoir faire un truc pareil, et même là c’est un gros problème de sécurité s’il peut faire ça seul. Alors si c’est un externe… il semble y avoir d’énormes lacunes dans la sécurité !
#3
Bon courage à eux, moi c’est mon pire cauchemar ce genre d’attaque.
#4
Les serveurs de sauvegardes étaient accessibles depuis Internet ou bien c’est du a une personne interne à la société ?
Ça sent quand même le gros manquement en terme de sécurité des données …
#5
J’aime bien la phrase “surpris le hacker pendant qu’il formatait les disque de sauvegarde” je suis néophite dans le domaine mais formater un disque doit prendre un peu de temps non ? Alors formater TOUS les disques de TOUTES les machines y compris les serveurs de sauvegarde ne dois pas se faire en 10 minutes ?
C’était l’heure de la pause café des informaticiens ?
#6
Je viens d’aller voir leur site et j’ai bien ri, leur slogan étant : making email safe for the masses.
#7
#8
Un simple effacage par desindexation c’est rapide mais les données sont “facilement” récupérable. Un véritable effacement et un peu plus long normalement.
#9
#10
En effet une supervision classique alerte souvent quand un seuil d’utilisation d’espace est dépassé, pas quand il y a des baisses subites…
Pour la question “à qui profite le crime ?”… ça serait intéressant de voir ce que l’enquête révèle.
#11
Vu le temps de détection des attaques sans supervision c’est plus que possible. On avoisine facilement plusieurs heures.
#12
#13
Nan mais ça c’est sous Windows en FAT que l’effacement d’un fichier c’est simplement mettre le premier octet du nom à 0. Sous Linux en ext4, un effacement de fichier ça écrase complètement le inode, il n’y a pas de undelete possible. Pour ceux qui ont déjà essayé, un rm -rf * va relativement vite, surtout en SSD.
#14
#15
Lu sur ArsTechnica: c’est des commandes dd qui ont été lancées via ssh depuis une VM externe qui a sûrement servi à masquer la localisation de l’assaillant
#16
Papa noël, Jésus, Bouddha, Bob l’éponge, qui que tu sois aux cieux ou en dehors de la matrice, pitié, fais que ça arrive bientôt à Google. S’teuplé, s’teuplé, st’euplééééééééééé.
#17
J’ai eu un jour à récupérer un disque ext3 dont la structure de répertoire était fichue. J’avais trouvé un utilitaire (sous Windows… la version Linux ayant déclaré forfait 
" /> ) qui m’a récupéré la majorité des fichiers, mais pas leur nom. Ca avait mis des jours.
#18
En SSD oui, ça peut aller vite de faire une réécriture complète, mais sur un disque à plateau, réécrire >1 To avec un débit de l’ordre de 100Mo/s, ça prends un temps assez conséquent. Ça fait longtemps que j’ai pas utilisé de disque à plateau, mais je crois que les débits ont pas beaucoup changé, donc je pense que ça compte en heures la réécriture complète.
Pour l’effacement d’inode, je suis aller voir ce qu’est exactement un inode, mais je vois pas bien la différence entre effacer un inode sur Linux, ou supprimer la référence dans la FAT (table d’allocation des fichiers) côté Windows.
Si c’est juste l’inode qui est touché, mais pas le vrai fichier, ça veut dire qu’il est perdu et qu’il faut scanner le disque entier pour le retrouver, mais il est pas effacé pour autant, donc avec suffisamment de temps et d’effort on peut retrouver le fichier.
#19
Quand tu effaces l’inode, tu perds la structure du fichier. Certes, les données sont toujours là, dans l’espace libre, mais tu as en vrac des blocs de 4Ko qu’il te faut réassembler, sans savoir dans quel ordre ils étaient ni à quel fichier ils appartenaient. Tout est mélangé. C’est un peu comme vouloir recoller un document passé dans un broyeur.
#20
Les sauvegardes c’est bien, mais il doit être accompagné d’un stockage (sur bande ou à la limite NAS mis offline après les actions de récupération).
Ils utilisaient des machines virtuelles, je suis curieux de savoir si l’attaquant est remonté jusqu’à l’hyperviseur à partir d’une de ces machines virtuelles.
Vive le cloud !
#21
Pour l’ext4, avec le journal on arrive à récupérer des trucs, j’ai déjà récupéré 250 Gio de données supprimées, en 3 heures. Y’avais quelques ratés sur certains fichiers, mais rien d’important.
D’ailleurs, je vous conseille les SSHD : vous aurez quasiment aucun gain de perfs au quotidien, mais un
rm -rf ~/.cachemalencontreux (il manquait le.cacheà la fin…), sur 250 Gio de disque, c’est instantané, là, par contre…#22
#23
Manuel d’ext4magic (que j’ai utilisé) :
DESCRIPTION
The deletion of files in ext3/4 filesystems can not be easily
reversed. Zero out of the block references in the Inodes
makes that impossible. Experience with other programs have
proved, it is often possible, to restore sufficient informa‐
tion for a recover of many data files, directly from the
filesystem Journal. ext4magic can extract the information from
the Journal, and can restore files in entire directory trees,
provided that the information in the Journal are sufficient.
This tool can recover the most file types, can recover large
and sparse files, recovered files with orginal filename, with
the orginal owner an group, the orginal file mode bits, and
also the old atime/mtime stamp.
The filesystem Journal has a very different purpose, and it
will not be possible to recover any file at any time. Many
factors affects which data and how long the data store in the
Journal. Read the ext4magic documentation for more extensive
information about the filesytem Journal.
Visiblement il utilise le journal, je suis pas fou quand même.
J’avais ainsi récupéré une grande partie de mes données, avec une arborescence et des noms de fichiers corrects. J’avais perdu certains fichiers téléchargés en torrent, et quelques vidéos, donc rien de grave. Tous mes fichiers de conf, mes documents, mes images, mes musiques ont été restaurés sans pertes aucune. Un bête rsync du dossier où ont été restaurées les données (parce qu’il faut pas monter la partoche, du coup ça lisait la partoche supprimée en écrivant sur une autre patoche) vers la partition d’origine a suffit à tout remettre comme il faut.
#24
Ben c’est safe, en l’occurrence y’a plus rien sur leurs serveurs.
La sécurité par le vide ;)
#25
Une attaque aussi violente sur un prestataire pas ultra connu qui a clairement pour but de les mettre a terre, c’est pas un pirate qui veut faire ses preuves c’est clairement ciblé sur la société en question.
Ancien employé très mécontent ? Ca expliquerait le fait qu’il connaisse les différents serveur et les différents login de connection.
Ou concurrence ? Moins probable mais a mon avis mais ca reste un scénario possible.
#26
Ça je veux bien, mais je vois pas en quoi ça fait une différence majeure avec Windows.
La table d’allocation en FAT fait à peu près la même chose : pointer vers les blocs qui contiennent le fichier.
Si tu efface la table d’allocation, tu te retrouves dans la même situation, avec des blocs de 4ko éparpillés sur le disque, sans trop savoir à qui ils appartiennent et comment les réassembler.
#27
#28
#29
Si vous avez un client de messagerie avec vos messages « Débranchez votre connection internet et patientez ».
#30
Encore un coup d’employés de Microsoft pour refourguer du Office 365/Outlook/Exchange…
" />
#31
#32
pas forcement besoin d’être administrateur pour faire ça, juste besoin de trouver le bug qui permet une élévation des droits.
Si on regarde les patchs pour Windows, ils corrigent souvent ce genre de trou
#33
C’est ultra méchant comme méthode de piratage…
#34
Pas de sauvegarde froide, aucune excuse
#35
Concernant les backups, ils sont “normalement mis sur un réseau à part inaccessible depuis les VMs.
Le réseau d’administration des Hyperviseurs est normalement également séparé du réseau des VMs.
Il est normalement impossible de piloter les Hyperviseurs ou les baies de stockage depuis l’extérieur sauf si on possède un accès au réseau (VPN par exemple).
Autre point, imaginons que l’attaquant ait accès au réseau, il lui reste a trouver les mots de passes des différents équipement avec des droits suffisants.
Cette attaque montre surtout que les règles basiques de sécurités n’était pas respectée