Des failles impactant SPIP sont sorties hier soir. Pour les
sites supportant les forums, la sanction est sans appel : affichage du mot
de passe d'admin, utilisation de OUTFILE pour exécuter du code PHP, ...
http://www.zone-h.org/en/advisories/read/id=8650/
Et vu que *beaucoup* de sites francophones (même parmi ceux de l'Etat)
tournent sous ce framework, cela risque de causer des problèmes. Donc,
patchez, et faites patchez ...
2) Pishing Crédit Lyonnais
Une tentative de pishing visant le site interactif.creditlyonnais.com est
en cours, avec un nom de domaine "proche" (interactlf.credltlyonnals.com),
càd avec des L minuscules à la place des I. Les IP pointées par ce nom
changent constamment, sont situées aux USA sur des Windows connectés à
l'ADSL, avec une bannière identique et apparemment fausse :
Apache/2.0.55 (Debian) PHP/4.4.0-4
3) Nmap
La version 4.0 est sortie. Au menu, gain en performances, diminution des
ressources utilisées, ... :
http://www.insecure.org/nmap/download.html
4) Boulot
Je cherche actuellement du boulot dans le domaine de la sécurité,
principalement du côté offensif (pentests, audits, recherche de
vulnérabilités). CV disponible sur demande ...
3) Nmap La version 4.0 est sortie. Au menu, gain en performances, diminution des ressources utilisées, ... : http://www.insecure.org/nmap/download.html
C'est ce que Fyodor dit, mais ce n'est pas ce que j'ai constaté. Il y a peut-être eu un petit gain entre la 3.93 et la 3.95, mais il y a eu une franche dégradation entre la 3.50 et la 3.93.
Pour la consommation mémoire, voir : http://ma75.blogspot.com/2006_02_01_ma75_archive.html En gros, ça varie entre 50 et 250 Mo, et dans certains cas pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Pour les temps de scans, je n'ai pas encore fait de mesures précises, mais Nmap 4 me semble assez lent.
On Wed Feb 01 2006 at 12:45, Nicob wrote:
3) Nmap
La version 4.0 est sortie. Au menu, gain en performances, diminution des
ressources utilisées, ... :
http://www.insecure.org/nmap/download.html
C'est ce que Fyodor dit, mais ce n'est pas ce que j'ai constaté.
Il y a peut-être eu un petit gain entre la 3.93 et la 3.95, mais il y
a eu une franche dégradation entre la 3.50 et la 3.93.
Pour la consommation mémoire, voir :
http://ma75.blogspot.com/2006_02_01_ma75_archive.html
En gros, ça varie entre 50 et 250 Mo, et dans certains cas
pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Pour les temps de scans, je n'ai pas encore fait de mesures précises,
mais Nmap 4 me semble assez lent.
3) Nmap La version 4.0 est sortie. Au menu, gain en performances, diminution des ressources utilisées, ... : http://www.insecure.org/nmap/download.html
C'est ce que Fyodor dit, mais ce n'est pas ce que j'ai constaté. Il y a peut-être eu un petit gain entre la 3.93 et la 3.95, mais il y a eu une franche dégradation entre la 3.50 et la 3.93.
Pour la consommation mémoire, voir : http://ma75.blogspot.com/2006_02_01_ma75_archive.html En gros, ça varie entre 50 et 250 Mo, et dans certains cas pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Pour les temps de scans, je n'ai pas encore fait de mesures précises, mais Nmap 4 me semble assez lent.
Nicob
On Wed, 01 Feb 2006 14:23:40 +0000, Michel Arboi wrote:
En gros, ça varie entre 50 et 250 Mo, et dans certains cas pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Vur sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30 Mo suite à la correction d'une memory leak dans la v3.95. Je viens de vérifier, le bug est aussi présent dans la v4.00 ...
==================================================================== o Fixed an important memory leak in the raw ethernet sending system. Thanks to Ganga Bhavani (GBhavani(a)everdreamcorp.com) for identifying the bug and sending a patch. ===================================================================== Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ?
On Wed, 01 Feb 2006 14:23:40 +0000, Michel Arboi wrote:
En gros, ça varie entre 50 et 250 Mo, et dans certains cas
pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Vur sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30
Mo suite à la correction d'une memory leak dans la v3.95. Je viens de
vérifier, le bug est aussi présent dans la v4.00 ...
==================================================================== o Fixed an important memory leak in the raw ethernet sending system.
Thanks to Ganga Bhavani (GBhavani(a)everdreamcorp.com) for
identifying the bug and sending a patch.
=====================================================================
Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ?
On Wed, 01 Feb 2006 14:23:40 +0000, Michel Arboi wrote:
En gros, ça varie entre 50 et 250 Mo, et dans certains cas pathologiques, on peut le faire enfler démesurément (1,5 Go...).
Vur sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30 Mo suite à la correction d'une memory leak dans la v3.95. Je viens de vérifier, le bug est aussi présent dans la v4.00 ...
==================================================================== o Fixed an important memory leak in the raw ethernet sending system. Thanks to Ganga Bhavani (GBhavani(a)everdreamcorp.com) for identifying the bug and sending a patch. ===================================================================== Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ?
Vu sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30 Mo suite à la correction d'une memory leak dans la v3.95. Je viens de vérifier, le bug est aussi présent dans la v4.00 ...
Quelle fonction est concernée ? Je pense en avoir vu un dans la reconnaissance de services, mais il est possible que j'en ai raté un autre.
Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ? http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0109.html
Je peux essayer.
En ce moment, je suis en train de scanner à travers Internet une classe B méchamment firewallée. nmap --noninteractive --min-hostgroup 32 --max_rtt_timeout 500 -v -T 4 -oN /tmp/xxx.nmap -p- -sS -sV -v xxx.xxx.0.0/16 Ça tourne depuis 11 heures, et ça n'a pas encore fini le premier groupe de 256 IP. La dernière fois qu'il a causé, il a annoncé 58 heures pour terminer (le groupe, je suppose). Si c'est exact et si j'ai bien interprété ses messages, il faudra 2 ans pour le scan complet. Voilà pour la "rapidité".
Je me suis amusé à lancer hping --scan 1-65535 -S x.x.x.x sur _une_ des machines du réseau. tcpdump révèle que hping envoie plus de paquets sur une seule IP que nmap sur tout le groupe. Voilà pour le "parallèlisme".
Vu sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30
Mo suite à la correction d'une memory leak dans la v3.95. Je viens de
vérifier, le bug est aussi présent dans la v4.00 ...
Quelle fonction est concernée ? Je pense en avoir vu un dans la
reconnaissance de services, mais il est possible que j'en ai raté un
autre.
Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ?
http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0109.html
Je peux essayer.
En ce moment, je suis en train de scanner à travers Internet une
classe B méchamment firewallée.
nmap --noninteractive --min-hostgroup 32 --max_rtt_timeout 500 -v
-T 4 -oN /tmp/xxx.nmap -p- -sS -sV -v xxx.xxx.0.0/16
Ça tourne depuis 11 heures, et ça n'a pas encore fini le premier
groupe de 256 IP. La dernière fois qu'il a causé, il a annoncé 58
heures pour terminer (le groupe, je suppose).
Si c'est exact et si j'ai bien interprété ses messages, il faudra 2
ans pour le scan complet.
Voilà pour la "rapidité".
Je me suis amusé à lancer hping --scan 1-65535 -S x.x.x.x sur _une_
des machines du réseau. tcpdump révèle que hping envoie plus de
paquets sur une seule IP que nmap sur tout le groupe.
Voilà pour le "parallèlisme".
Vu sur la liste de diffusion de Nmap : le passage de 80+ Mo de RAM à 30 Mo suite à la correction d'une memory leak dans la v3.95. Je viens de vérifier, le bug est aussi présent dans la v4.00 ...
Quelle fonction est concernée ? Je pense en avoir vu un dans la reconnaissance de services, mais il est possible que j'en ai raté un autre.
Michel, ça vaudrait le coup de refaire tests avec le patch appliqué, non ? http://seclists.org/lists/nmap-dev/2006/Jan-Mar/0109.html
Je peux essayer.
En ce moment, je suis en train de scanner à travers Internet une classe B méchamment firewallée. nmap --noninteractive --min-hostgroup 32 --max_rtt_timeout 500 -v -T 4 -oN /tmp/xxx.nmap -p- -sS -sV -v xxx.xxx.0.0/16 Ça tourne depuis 11 heures, et ça n'a pas encore fini le premier groupe de 256 IP. La dernière fois qu'il a causé, il a annoncé 58 heures pour terminer (le groupe, je suppose). Si c'est exact et si j'ai bien interprété ses messages, il faudra 2 ans pour le scan complet. Voilà pour la "rapidité".
Je me suis amusé à lancer hping --scan 1-65535 -S x.x.x.x sur _une_ des machines du réseau. tcpdump révèle que hping envoie plus de paquets sur une seule IP que nmap sur tout le groupe. Voilà pour le "parallèlisme".
On Thu, 02 Feb 2006 16:02:30 +0000, Michel Arboi wrote:
Quelle fonction est concernée ? Je pense en avoir vu un dans la reconnaissance de services, mais il est possible que j'en ai raté un autre.
Apparemment, c'est le code de base d'envoi de paquets :
/* Send a pre-built IPv4 packet */ int send_ip_packet() { ... }
Si c'est exact et si j'ai bien interprété ses messages, il faudra 2 ans pour le scan complet. Voilà pour la "rapidité".
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la scanrand me semble de toute façon être l'outil le mieux adapté. Balayer un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de paquets à envoyer pour un SYN scan sans réémission. Quite à ensuite utiliser ensuite nmap sur les ports trouvés, afin d'identifier les services et la pile IP.
Nicob
On Thu, 02 Feb 2006 16:02:30 +0000, Michel Arboi wrote:
Quelle fonction est concernée ? Je pense en avoir vu un dans la
reconnaissance de services, mais il est possible que j'en ai raté un
autre.
Apparemment, c'est le code de base d'envoi de paquets :
/* Send a pre-built IPv4 packet */
int send_ip_packet() { ... }
Si c'est exact et si j'ai bien interprété ses
messages, il faudra 2 ans pour le scan complet.
Voilà pour la "rapidité".
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la
scanrand me semble de toute façon être l'outil le mieux adapté. Balayer
un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de
paquets à envoyer pour un SYN scan sans réémission. Quite à ensuite
utiliser ensuite nmap sur les ports trouvés, afin d'identifier les
services et la pile IP.
On Thu, 02 Feb 2006 16:02:30 +0000, Michel Arboi wrote:
Quelle fonction est concernée ? Je pense en avoir vu un dans la reconnaissance de services, mais il est possible que j'en ai raté un autre.
Apparemment, c'est le code de base d'envoi de paquets :
/* Send a pre-built IPv4 packet */ int send_ip_packet() { ... }
Si c'est exact et si j'ai bien interprété ses messages, il faudra 2 ans pour le scan complet. Voilà pour la "rapidité".
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la scanrand me semble de toute façon être l'outil le mieux adapté. Balayer un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de paquets à envoyer pour un SYN scan sans réémission. Quite à ensuite utiliser ensuite nmap sur les ports trouvés, afin d'identifier les services et la pile IP.
Nicob
Michel Arboi
On Fri Feb 03 2006 at 05:31, Nicob wrote:
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la scanrand me semble de toute façon être l'outil le mieux adapté. Balayer un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de paquets à envoyer pour un SYN scan sans réémission.
Nmap ne se déchaîne que sur les IP "vivantes" (je n'ai pas mis -P0) et il n'y en a pas 65535.
On Fri Feb 03 2006 at 05:31, Nicob wrote:
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la
scanrand me semble de toute façon être l'outil le mieux adapté. Balayer
un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de
paquets à envoyer pour un SYN scan sans réémission.
Nmap ne se déchaîne que sur les IP "vivantes" (je n'ai pas mis -P0) et
il n'y en a pas 65535.
Mouais ... Sur les plages sévèrement filtrées, le scan asynchrone à la scanrand me semble de toute façon être l'outil le mieux adapté. Balayer un /16 sur tous les ports TCP, ça fait quand même plus de 4 milliards de paquets à envoyer pour un SYN scan sans réémission.
Nmap ne se déchaîne que sur les IP "vivantes" (je n'ai pas mis -P0) et il n'y en a pas 65535.
Michel Arboi
On Fri Feb 03 2006 at 05:31, Nicob wrote:
Quite à ensuite utiliser ensuite nmap sur les ports trouvés, afin d'identifier les services et la pile IP.
La reconnaissance de services de Nmap est médiocre. Le terme de "fingerprinting" est trompeur, car il se fie aux bannières quand il y en a.
Exemple :
Interesting ports on casserole : PORT STATE SERVICE VERSION 25/tcp open smtp Sendmail 8.11.6/8.11.6 Service Info: Host: arboi.homeip.net; OS: Unix 8899/tcp open http Apache httpd 2.0.34
Mais :
nasl -t casserole smtpscan.nasl [...] This server could be fingerprinted as being Postfix
nasl -t casserole www_fingerprint_hmap.nasl [...] This web server was fingerprinted as: thttpd/2.25b 29dec2003 which is not consistent with the displayed banner: Apache/2.0.34 [...]
J'avais ajouté mail_name dans /etc/postfix/main.cf et recompilé un thttpd après voir modifié version.h. Suis-je vicieux...
Quite à ensuite utiliser ensuite nmap sur les ports trouvés, afin
d'identifier les services et la pile IP.
La reconnaissance de services de Nmap est médiocre. Le terme de
"fingerprinting" est trompeur, car il se fie aux bannières quand il y
en a.
Exemple :
Interesting ports on casserole :
PORT STATE SERVICE VERSION
25/tcp open smtp Sendmail 8.11.6/8.11.6
Service Info: Host: arboi.homeip.net; OS: Unix
8899/tcp open http Apache httpd 2.0.34
Mais :
nasl -t casserole smtpscan.nasl
[...]
This server could be fingerprinted as being Postfix
nasl -t casserole www_fingerprint_hmap.nasl
[...]
This web server was fingerprinted as: thttpd/2.25b 29dec2003
which is not consistent with the displayed banner: Apache/2.0.34
[...]
J'avais ajouté mail_name dans /etc/postfix/main.cf et recompilé un
thttpd après voir modifié version.h. Suis-je vicieux...
Quite à ensuite utiliser ensuite nmap sur les ports trouvés, afin d'identifier les services et la pile IP.
La reconnaissance de services de Nmap est médiocre. Le terme de "fingerprinting" est trompeur, car il se fie aux bannières quand il y en a.
Exemple :
Interesting ports on casserole : PORT STATE SERVICE VERSION 25/tcp open smtp Sendmail 8.11.6/8.11.6 Service Info: Host: arboi.homeip.net; OS: Unix 8899/tcp open http Apache httpd 2.0.34
Mais :
nasl -t casserole smtpscan.nasl [...] This server could be fingerprinted as being Postfix
nasl -t casserole www_fingerprint_hmap.nasl [...] This web server was fingerprinted as: thttpd/2.25b 29dec2003 which is not consistent with the displayed banner: Apache/2.0.34 [...]
J'avais ajouté mail_name dans /etc/postfix/main.cf et recompilé un thttpd après voir modifié version.h. Suis-je vicieux...
Officiellement corrigée dans la version 1.8.2.8 (dernière version stable) http://listes.rezo.net/archives/spip-ann/2006-02/msg00000.html http://listes.rezo.net/archives/spip-ann/2006-02/msg00001.html
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un audit de sécurité (sans parler d'audit de performance http, html, javascript et autres car ce n'est pas en-charte) ?
La liste de diffusion pour les annonces de sécurité ( http://listes.rezo.net/archives/spip-ann/ ) est elle suffisament indiquée lors du téléchargement, installation ou utilisation de SPIP (et dans le site web officiel http://www.spip.net/ ) ? Quelle est la visibilité habituelle pour ce type de source dans les autres logiciels ?
Nicob écrivit dans l'article
news:pan.2006.02.01.09.48.50.998103@I.hate.spammers.com
1) Faille SPIP
Officiellement corrigée dans la version 1.8.2.8 (dernière version stable)
http://listes.rezo.net/archives/spip-ann/2006-02/msg00000.html
http://listes.rezo.net/archives/spip-ann/2006-02/msg00001.html
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un
audit de sécurité (sans parler d'audit de performance http, html,
javascript et autres car ce n'est pas en-charte) ?
La liste de diffusion pour les annonces de sécurité ( spip-ann@rezo.net
http://listes.rezo.net/archives/spip-ann/ ) est elle suffisament indiquée
lors du téléchargement, installation ou utilisation de SPIP (et dans le
site web officiel http://www.spip.net/ ) ? Quelle est la visibilité
habituelle pour ce type de source dans les autres logiciels ?
Officiellement corrigée dans la version 1.8.2.8 (dernière version stable) http://listes.rezo.net/archives/spip-ann/2006-02/msg00000.html http://listes.rezo.net/archives/spip-ann/2006-02/msg00001.html
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un audit de sécurité (sans parler d'audit de performance http, html, javascript et autres car ce n'est pas en-charte) ?
La liste de diffusion pour les annonces de sécurité ( http://listes.rezo.net/archives/spip-ann/ ) est elle suffisament indiquée lors du téléchargement, installation ou utilisation de SPIP (et dans le site web officiel http://www.spip.net/ ) ? Quelle est la visibilité habituelle pour ce type de source dans les autres logiciels ?
Benjamin Pineau
Le 06 Feb 2006 09:54:05 GMT, Nicolas Krebs écrivait:
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un audit de sécurité (sans parler d'audit de performance http, html, javascript et autres car ce n'est pas en-charte) ?
Je ne sait pas si vous avez déjà jetté un oeil dans le code de SPIP, mais c'est vraiment monstrueux (voir préhistorique). D'autant que l'essentiel a été conçu a une époque où les paradigmes élémentaires de programation (sécurité, conception, ...) en php étaient encore peu connus.
Bref ce n'est vraiment pas une tache gratifiante (et il s'agit tout de même de 130 000 lignes de php); tant qu'à faire je préfèrerai auditer un CMS plus moderne. Mais lequel ? SPIP-agora (dont le code semble, à première vue, un poil plus propre) ? Connaissez vous des CMS dont les developpeur ont considéré les problématiques sécurité dès le départ ?
Le 06 Feb 2006 09:54:05 GMT,
Nicolas Krebs <nicolas1.krebs3@netcourrier.com> écrivait:
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un
audit de sécurité (sans parler d'audit de performance http, html,
javascript et autres car ce n'est pas en-charte) ?
Je ne sait pas si vous avez déjà jetté un oeil dans le code de SPIP, mais
c'est vraiment monstrueux (voir préhistorique). D'autant que l'essentiel
a été conçu a une époque où les paradigmes élémentaires de programation
(sécurité, conception, ...) en php étaient encore peu connus.
Bref ce n'est vraiment pas une tache gratifiante (et il s'agit tout de même
de 130 000 lignes de php); tant qu'à faire je préfèrerai auditer un CMS plus
moderne. Mais lequel ? SPIP-agora (dont le code semble, à première vue,
un poil plus propre) ? Connaissez vous des CMS dont les developpeur ont
considéré les problématiques sécurité dès le départ ?
Le 06 Feb 2006 09:54:05 GMT, Nicolas Krebs écrivait:
Un volontaire pour tester dans SPIP l'absence de faille, pour faire un audit de sécurité (sans parler d'audit de performance http, html, javascript et autres car ce n'est pas en-charte) ?
Je ne sait pas si vous avez déjà jetté un oeil dans le code de SPIP, mais c'est vraiment monstrueux (voir préhistorique). D'autant que l'essentiel a été conçu a une époque où les paradigmes élémentaires de programation (sécurité, conception, ...) en php étaient encore peu connus.
Bref ce n'est vraiment pas une tache gratifiante (et il s'agit tout de même de 130 000 lignes de php); tant qu'à faire je préfèrerai auditer un CMS plus moderne. Mais lequel ? SPIP-agora (dont le code semble, à première vue, un poil plus propre) ? Connaissez vous des CMS dont les developpeur ont considéré les problématiques sécurité dès le départ ?
