Fwd: Important Hetzner Online Client Information
Bonjour, voilà un joli mail de Hetzner, qui concerne une faille de sécu non-répertorié dans Nagios et donc qui potentiellement concerne un certains nombre d'entre nous.... Si quelqu'un a des infos, je suis preneur. Greg -------- Message original -------- Sujet: Important Hetzner Online Client Information Date : Thu, 06 Jun 2013 18:12:45 +0200 De : security-mailing@hetzner.de Répondre à : security-mailing@hetzner.de Dear Client At the end of last week, Hetzner technicians discovered a "backdoor" in one of our internal monitoring systems (Nagios). An investigation was launched immediately and showed that the administration interface for dedicated root servers (Robot) had also been affected. Current findings would suggest that fragments of our client database had been copied externally. As a result, we currently have to consider the client data stored in our Robot as compromised. To our knowledge, the malicious program that we have discovered is as yet unknown and has never appeared before. The malicious code used in the "backdoor" exclusively infects the RAM. First analysis suggests that the malicious code directly infiltrates running Apache and sshd processes. Here, the infection neither modifies the binaries of the service which has been compromised, nor does it restart the service which has been affected. The standard techniques used for analysis such as the examination of checksum or tools such as "rkhunter" are therefore not able to track down the malicious code. We have commissioned an external security company with a detailed analysis of the incident to support our in-house administrators. At this stage, analysis of the incident has not yet been completed. The access passwords for your Robot client account are stored in our database as Hash (SHA256) with salt. As a precaution, we recommend that you change your client passwords in the Robot. With credit cards, only the last three digits of the card number, the card type and the expiry date are saved in our systems. All other card data is saved solely by our payment service provider and referenced via a pseudo card number. Therefore, as far as we are aware, credit card data has not been compromised. Hetzner technicians are permanently working on localising and preventing possible security vulnerabilities as well as ensuring that our systems and infrastructure are kept as safe as possible. Data security is a very high priority for us. To expedite clarification further, we have reported this incident to the data security authority concerned. Furthermore, we are in contact with the Federal Criminal Police Office (BKA) in regard to this incident. Naturally, we shall inform you of new developments immediately. We very much regret this incident and thank you for your understanding and trust in us. A special FAQs page has been set up at http://wiki.hetzner.de/index.php/Security_Issue/en to assist you with further enquiries. Kind regards Martin Hetzner Hetzner Online AG Stuttgarter Str. 1 91710 Gunzenhausen / Germany Tel: +49 (9831) 61006-1 Fax: +49 (9831) 61006-2 security-mailing@hetzner.de http://www.hetzner.com Register Court: Registergericht Ansbach, HRB 3204 Management Board: Dipl. Ing. (FH) Martin Hetzner Chairwoman of the Supervisory Board: Diana Rothhan
Le jeudi 06 juin 2013 à 18:21, Gregory Duchatelet écrivait:
Bonjour, Plopation et gazouillis Greg
voilà un joli mail de Hetzner, qui concerne une faille de sécu non-répertorié dans Nagios et donc qui potentiellement concerne un certains nombre d'entre nous.... Si quelqu'un a des infos, je suis preneur.
D'apres ce que je comprends, c'est plus apache et ssh qui sont cibles. Je ne connais pas l'infra d'Hetzner, mais "Robot" et "Nagios" semblent être des services hetzner plus que des processes. Par contre, si la backdoor est en RAM, c'est assez fun, et donc forcement pas detectable pas chkrootkit, rkhunter et consorts. ça ressemble a une bugouille dans le kernel ou assimile si l'espace memoire est compromis Si t'as la suite des comm' d'hetzner, je suis preneur ;p C'est surtout le vecteur d'infection qui va être important Snarf -- "On est reçu selon l'habit, reconduit selon l'esprit" --Proverbe Russe
Bonsoir, Le 06/06/2013 18:21, Gregory Duchatelet a écrit :
Bonjour,
voilà un joli mail de Hetzner, qui concerne une faille de sécu non-répertorié dans Nagios et donc qui potentiellement concerne un certains nombre d'entre nous.... Si quelqu'un a des infos, je suis preneur.
Il aurait fallu attendre demain pour un sujet pareil. Si j'étais un black hat, c'est dans Nagios et cie que je chercherais une faille... Une des raisons pour laquelle on n'a pas déployé ça chez nous. Cordialement, Christophe
Pas forcément un backhat, un grey suffit. Sinon une magnifique merveille en faille c'est plesk, le nombre de fois ou j'ai été obligé de supprimer des rootkits ... Le 6 juin 2013 18:53, Christophe Baegert <c.baegert-listes@lixium.fr> a écrit :
Bonsoir,
Le 06/06/2013 18:21, Gregory Duchatelet a écrit :
Bonjour,
voilà un joli mail de Hetzner, qui concerne une faille de sécu non-répertorié dans Nagios et donc qui potentiellement concerne un certains nombre d'entre nous.... Si quelqu'un a des infos, je suis preneur.
Il aurait fallu attendre demain pour un sujet pareil.
Si j'étais un black hat, c'est dans Nagios et cie que je chercherais une faille... Une des raisons pour laquelle on n'a pas déployé ça chez nous.
Cordialement,
Christophe _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- *********************************************************************************************** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. ***********************************************************************************************
2013/6/6 Sébastien Mureau <sebastien.mureau@gmail.com>
Le 6 juin 2013 18:53, Christophe Baegert <c.baegert-listes@lixium.fr> a écrit :
Bonsoir,
Le 06/06/2013 18:21, Gregory Duchatelet a écrit :
Bonjour,
voilà un joli mail de Hetzner, qui concerne une faille de sécu non-répertorié dans Nagios et donc qui potentiellement concerne un certains nombre d'entre nous.... Si quelqu'un a des infos, je suis preneur.
Il aurait fallu attendre demain pour un sujet pareil.
Si j'étais un black hat, c'est dans Nagios et cie que je chercherais une faille... Une des raisons pour laquelle on n'a pas déployé ça chez nous.
Cordialement,
Christophe _______________________________________________
De mémoire il y a eu il y a quelques mois une alerte sur les CGI Nagios (partie history), mais personne n'avait réussi à l'exploitée. Bon ça se trouve quelqu'un a finalement trouvé :) Jean
De ce qu'ils disent c'est pas Nagios qui est en cause, c'est la machine qui héberge le Nagios mais surtour leur Robot (manager des serveurs chez eux). Ce qui est logique puisque attaquer un hosteur n'a de sens que si tu peux prendre la main sur la facturation, la conf des machines / réseaux, récupérer le fichier client. Je n'ai rien vu bouger du côté Nagios. Pour ma part ma confiance en Nagios reste entière et puis si vos supervisions sont bien faites, personne ne peut y accéder de l'extérieur, au minima vous avez tous mis du SSL avec authentification, un peu mieux du SSL avec certificat client ou encore mieux SSL client sur un réseau vpn. Donc soit il y a une faille côté Apache / ssh / whatelse ouvert sur cette machine soit c'est une attaque de l'intérieur ... c'est sans doute le plus probable quand c'est aussi ciblé.
Question bête, avez vous OSSEC installé dessus, ça aide bien. Le 7 juin 2013 17:17, Wallace <wallace@morkitu.org> a écrit :
De ce qu'ils disent c'est pas Nagios qui est en cause, c'est la machine qui héberge le Nagios mais surtour leur Robot (manager des serveurs chez eux). Ce qui est logique puisque attaquer un hosteur n'a de sens que si tu peux prendre la main sur la facturation, la conf des machines / réseaux, récupérer le fichier client.
Je n'ai rien vu bouger du côté Nagios.
Pour ma part ma confiance en Nagios reste entière et puis si vos supervisions sont bien faites, personne ne peut y accéder de l'extérieur, au minima vous avez tous mis du SSL avec authentification, un peu mieux du SSL avec certificat client ou encore mieux SSL client sur un réseau vpn.
Donc soit il y a une faille côté Apache / ssh / whatelse ouvert sur cette machine soit c'est une attaque de l'intérieur ... c'est sans doute le plus probable quand c'est aussi ciblé.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- *********************************************************************************************** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. ***********************************************************************************************
Le dernier (disclosure 02-2013 quand même) CVE Nagios, http://osvdb.org/90582 Cordialement, Le 07/06/2013 18:03, Sébastien Mureau a écrit :
Question bête, avez vous OSSEC installé dessus, ça aide bien.
Le 7 juin 2013 17:17, Wallace <wallace@morkitu.org <mailto:wallace@morkitu.org>> a écrit :
De ce qu'ils disent c'est pas Nagios qui est en cause, c'est la machine qui héberge le Nagios mais surtour leur Robot (manager des serveurs chez eux). Ce qui est logique puisque attaquer un hosteur n'a de sens que si tu peux prendre la main sur la facturation, la conf des machines / réseaux, récupérer le fichier client.
Je n'ai rien vu bouger du côté Nagios.
Pour ma part ma confiance en Nagios reste entière et puis si vos supervisions sont bien faites, personne ne peut y accéder de l'extérieur, au minima vous avez tous mis du SSL avec authentification, un peu mieux du SSL avec certificat client ou encore mieux SSL client sur un réseau vpn.
Donc soit il y a une faille côté Apache / ssh / whatelse ouvert sur cette machine soit c'est une attaque de l'intérieur ... c'est sans doute le plus probable quand c'est aussi ciblé.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
--
*********************************************************************************************** This message and any attachments are confidential and intended for the named addressee(s) only. If you have received this message in error, please notify immediately the sender, then delete the message. Any unauthorized modification, edition, use or dissemination is prohibited. The sender shall not be liable for this message if it has been modified, altered, falsified, infected by a virus or even edited or disseminated without authorization. ***********************************************************************************************
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le vendredi 14 juin 2013 à 12:22, Leslie-Alexandre DENIS - DCforDATA écrivait:
Le dernier (disclosure 02-2013 quand même) CVE Nagios, http://osvdb.org/90582
cool un CVE pour nrpe. Techniquement, ce n'est pas nagios, mais un des trouzemille outils utlisables pour recuperer de l'info sur un serveur. Apres si tu arrives à passer le $() de la muerte à nrpe, c'est que ta requete provient d'un serveur connu du nrpe (le traitement du plugin se fait apres i la validation de l'ip source). Par ailleurs, nrpe (et autre) ne sont pas des services qu'une personne normale va exposer à la face du monde. Snarf -- Apéro : les verres de contact. -- Antoine Blondin
2013/6/14 Snarf <snarf@dahwa.fr>
Le vendredi 14 juin 2013 à 12:22, Leslie-Alexandre DENIS - DCforDATA écrivait:
Le dernier (disclosure 02-2013 quand même) CVE Nagios, http://osvdb.org/90582
cool un CVE pour nrpe. Techniquement, ce n'est pas nagios, mais un des trouzemille outils utlisables pour recuperer de l'info sur un serveur.
Apres si tu arrives à passer le $() de la muerte à nrpe, c'est que ta requete provient d'un serveur connu du nrpe (le traitement du plugin se fait apres i la validation de l'ip source).
Par ailleurs, nrpe (et autre) ne sont pas des services qu'une personne normale va exposer à la face du monde.
Il faut en plus que les arguments soient autorisés à lui être passés, or le paramètre est juste en dessous d'un gros commentaire qui déconseille fortement de le faire, justement pour éviter ce genre de soucis... Jean
Le vendredi 14 juin 2013 à 16:17, nap écrivait: [SNIP]
Il faut en plus que les arguments soient autorisés à lui être passés, or le paramètre est juste en dessous d'un gros commentaire qui déconseille fortement de le faire, justement pour éviter ce genre de soucis...
et faut que ce soit bash qui execute le plugin et que la version de nrpe soit la n-1. (le CVE est pour la 2.13, la 2.14 qui n'est pas vuln est sortie deux mois avant) Snarf -- Dis, tu as fini avec le lit, là ? Oui ? Bon, ben moi je me couche, à ce soir. -- Mon chat
Sinon dans le genre constructif, la disclosure date ne correspond pas au 0day qu'on peut exploiter, d'où le nom 0day en fait... Le 14/06/2013 16:22, Snarf a écrit :
Le vendredi 14 juin 2013 à 16:17, nap écrivait: [SNIP]
Il faut en plus que les arguments soient autorisés à lui être passés, or le paramètre est juste en dessous d'un gros commentaire qui déconseille fortement de le faire, justement pour éviter ce genre de soucis... et faut que ce soit bash qui execute le plugin et que la version de nrpe soit la n-1. (le CVE est pour la 2.13, la 2.14 qui n'est pas vuln est sortie deux mois avant)
Snarf
Le Fri, Jun 14, 2013 at 04:17:32PM +0200, nap claviotta :
2013/6/14 Snarf <snarf@dahwa.fr>
Le vendredi 14 juin 2013 à 12:22, Leslie-Alexandre DENIS - DCforDATA écrivait:
Le dernier (disclosure 02-2013 quand même) CVE Nagios, http://osvdb.org/90582
cool un CVE pour nrpe. Techniquement, ce n'est pas nagios, mais un des trouzemille outils utlisables pour recuperer de l'info sur un serveur.
Apres si tu arrives à passer le $() de la muerte à nrpe, c'est que ta requete provient d'un serveur connu du nrpe (le traitement du plugin se fait apres i la validation de l'ip source).
Par ailleurs, nrpe (et autre) ne sont pas des services qu'une personne normale va exposer à la face du monde.
Il faut en plus que les arguments soient autorisés à lui être passés, or le paramètre est juste en dessous d'un gros commentaire qui déconseille fortement de le faire, justement pour éviter ce genre de soucis...
Et sinon, nrpe ça se patche, justement pour éviter ce genre de soucis en filtrant un peu plus ce qui est autorisé dans les arguments. Parceque les arguments, une fois sécurisés, c'est quand même bien pratique pour centraliser les valeurs au niveau de la conf shinken (ou nagios) :) -- Guillaume Subiron Mail - maethor@subiron.org GPG - C7C4 455C Jabber - maethor@im.subiron.org IRC - maethor@(freenode|geeknode)
participants (8)
-
Christophe Baegert -
Gregory Duchatelet -
Guillaume Subiron -
Leslie-Alexandre DENIS - DCforDATA -
nap -
Snarf -
Sébastien Mureau -
Wallace