Comment Matasano a-t-il été piraté?

à partir de: http://seclists.org/fulldisclosure/2009/Jul/0388.html

Si je comprends mieux les messages de: http://news.ycombinator.com/item?id=723798, les gars de Matasano ont laissé sshd internet accessible - des solutions proposées pour cela (du point de vue de la programmation)?

Comment Matasano a-t-il été piraté?

Il est impossible de répondre des informations contenues dans le message à la divulgation complète. Cependant, il est toujours intéressant de spéculer, car ils donnent quelques informations -

# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Connexion à 69.61.87.163:22 ..
[/] Recherche d'un utilisateur non root valide .. adam
******** R3D4CT3D h4h4h4h4 ********

Ils exécutent leur " th3_f1n41_s01ut10n" binaire sur le serveur de Matasano, qui se connecte au port ssh. Il trouve un utilisateur non root valide par des moyens inconnus, et le reste de la sortie est caviardé.

# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Écouteur Connectback sur 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 octobre 2007] 

Le binaire est à nouveau exécuté en utilisant le nom d'utilisateur trouvé, qui se connecte et se reconnecte à leur serveur sur le port 3338 (espérons que ce n'est pas enregistré à leur nom ...).

adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP dim. 4 mars 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****

Ils pourraient laisser entendre qu'ils ont un 0-day contre ce noyau, ce qui est assez ancien si l'on considère le stock de cette société.

adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow 

Oups - tout d'un coup, l'utilisateur est maintenant root. Ils ont un exploit d'escalade de privilèges local dans / tmp qui pourrait être le jour 0 auquel ils ont fait référence.

Il y a donc au moins deux exploits en cours ici - l'exploit OpenSSH pour obtenir un utilisateur non root valide sur le système et se connecter en tant qu'utilisateur, puis l'escalade de privilèges locale.

Considérant que OpenSSH a quelques problèmes de sécurité connus depuis la version 4.5:

Depuis la page de sécurité d'OpenSSH :

• OpenSSH avant la version 5.2 est vulnérable à la faiblesse du protocole décrite dans CPNI-957037 "Plaintext Recovery Attack Against SSH". Cependant, sur la base des informations limitées disponibles, il apparaît que cette attaque décrite est irréalisable dans la plupart des circonstances. Pour plus d'informations, veuillez consulter l'avis cbc.adv et les notes de version d'OpenSSH 5.2.
• OpenSSH 4.9 et les ~/.ssh/rcversions ultérieures ne s'exécutent pas pour les sessions dont la commande a été remplacée par une directive ForceCommand sshd_config (5). Il s'agit d'un comportement documenté mais dangereux (décrit dans les notes de publication d'OpenSSH 4.9).
• OpenSSH 4.7 et les versions plus récentes ne recourent pas à la création de cookies d'authentification X11 fiables lorsque la génération de cookies non fiables échoue (par exemple en raison de l'épuisement délibéré des ressources), comme décrit dans les notes de publication d'OpenSSH 4.7.

Je suppose que ce noyau Linux plus ancien et le démon SSH plus ancien l'ont fait pour eux. De plus, il fonctionnait sur leur serveur www, qui est disponible sur Internet, ce qui est à mon avis une chose assez sûre. Les personnes qui ont fait irruption ont manifestement voulu les embarrasser.

Comment empêcher ces attaques?

Cela aurait pu être évité par une administration proactive - en veillant à ce que tous les services accessibles sur Internet soient corrigés, et en limitant le nombre de personnes qui peuvent se connecter plutôt que de permettre aux personnes de se connecter de n'importe où. Cet épisode ajoute à la leçon que l'administration système sécurisée est difficile et nécessite un dévouement de la part de l'entreprise pour donner le temps au service informatique de maintenir les correctifs - en réalité, ce n'est pas quelque chose qui se passe facilement, du moins dans les petites entreprises.

Il est préférable d'utiliser une approche par ceinture et accolades - utiliser l'authentification par clé publique, la liste blanche sur le démon ssh, l'authentification à deux facteurs, les restrictions IP et / ou tout mettre derrière le VPN sont des voies possibles pour le verrouiller.

Je pense que je sais ce que je ferai au travail demain. :)

Les gens adorent créer du FUD par-dessus, mais il semble qu'ils savaient que l'utilisateur adam était déjà là et connaissait également son mot de passe (peut-être par la force brute ou d'autres méthodes). Cependant, ils veulent avoir l'air cool et créer cette histoire partout.

Une autre chose intéressante à noter est que l'utilisateur adam ne s'est pas connecté à cette boîte depuis plus d'un an:

(sortie de lastlog)

 adam             pts/1    ool-4350ab48.dyn Sat Jul 26 20:45:18 -0400 2008

Il a donc probablement gardé ce mot de passe (peut-être un mauvais) pendant un certain temps.

* S'ils avaient vraiment un outil pour découvrir les noms d'utilisateurs via SSH, ils auraient pu utiliser tous les autres utilisateurs pour accéder à distance, mais ils ont utilisé le nom d'utilisateur le plus courant dans cette boîte (facile à deviner).

Pourquoi voudriez-vous essayer de résoudre ce problème du point de vue de la programmation?

Vous devriez plutôt le résoudre du point de vue d'un administrateur de serveur intelligent. Il y a quelques bonnes suggestions dans les commentaires des liens que vous avez publiés, comme l'utilisation d'une liste blanche.

Je voudrais également ajouter que, parce que vous demandez ici, vous n'êtes probablement pas un expert en sécurité, et tout ce que vous pourriez penser écrire ne ferait qu'ajouter plus de trous. Ce n'est vraiment pas du tout une question de programmation.

Protégez votre logiciel contre les attaques de 0 jour ... ce qui est impossible.

Peut-être qu'une bonne approche est de prétendre que votre logiciel est inébranlable, ce qui amènera les whitehats à l'essayer et à tout divulguer, laissant moins de trous. Oracle 10 avait cette réclamation, puis le lendemain, comme 9 nouveaux trous ont été trouvés. C'est assez sécurisé maintenant.

Très probablement, le pirate informatique a abusé de la configuration d'un logiciel parfaitement bon

ça me fait penser qu'ils avaient tant d'utilisateurs avec des obus sur cette machine. c'est comme ça qu'ils ont été acquis à coup sûr, tout le reste est du hareng rouge destiné à distraire. l'un d'eux a eu son client ssh détourné sur une autre machine shell très probablement, puis c'était la fin du jeu. donner à tous des comptes shell et rendre le monde sshd accessible est juste paresseux et stupide.