espion sur reseau college

On Sat, 15 Jan 2005 14:15:01 +0000, Dominique Blas wrote:

Sur un réseau switché et en l'absence d'accès administratif aux dits
switches le sniffer ne sert pas à grand chose.

Faux ! Pour les TP, voir arp-sk (http://www.arp-sk.org/) Il n'y a que que
dans quelques rares cas très difficiles à maintenir (association en dur)
que les switchs peuvent lutter contre le snif.

Sur un réseau non switché le sniffer a son intérêt mais ne permettra
pas non plus de récupérer des mots de passe de réseaux Microsoft

On ne récupèrera pas les mots de passe en clair (sauf cas extrèmes, cf.
clé de registre "EnablePlainTextPassword"), mais on pourra tout de même
intercepter les hashs (avec par exemple l0phtcrack ou dnsiff) et les
craquer par la suite (avec par exemple John The Ripper).

[...] exploitation du registre du contrôleur de domaine [...] passe
forcément par un accès physique à la machine.

Non. Il suffit des droits Administrateur ou supérieur. Et étant
donné les possibilités d'obtention des droits SYSTEM en local :
http://www.eeye.com/html/research/advisories/AD20041012.html

Et pwdump4 peut servir à récupérer la SAM d'une machine joignable par le
réseau, pourvu que l'on possède (comme pour une attaque locale) les
droits nécessaires. Mais c'est vrai qu'un accès physique et un CD
bootable (Linux ou Windows) font très bien l'affaire, à condition qu'on
puisse rebooter le contrôleur de domaine sans se faire lever ...


Nicob

Le Mon, 17 Jan 2005 03:01:35 +0000, Benoit Leraillez a écrit :

OK. Mais ne peut-on pas, ou plutôt ne doit-on pas, interdire à un
utilisateur d'ajouter et de lancer des applications « personnelles » ?
Je sais que Mac OS X propose ce genre de configurations en limitant les
autorisations d'un utilisateur à ne lancer que certaines applications.

C'est effectivement une bonne idée si on peut le faire. Ceci dit, autant
ça doit être possible sous Unix (et encore)... Simplement monter les
point d'écriture en noexec ne suffit pas. On peut passer par le loader
dynamiquer, par un shell (/bin/sh ./monscript), par un interpréteur
divers, etc. Et si on n'a pas les droits en écriture, on écrit dand
/tmp...
En outre, une fois que le binaire est lancé, on peut l'enrichir en le
patchant directement en mémoire plutôt qu'en écrivant sur le disque.
Tout ça pour dire que si on veut contourner...

Je n'ai ni testé, ni cherché à contourner cette protection mais on
peut partir du principe qu'un utilisateur qui casse les règles
pré-établies et qui se retrouve avec des problèmes ne peut s'en
prendre qu'à lui-même ; non ?

Complètement, mais le problème, c'est qu'en général, ces règles sont
là pour assurer la pérennité du système dans son ensemble...

Sinon, un admin qui se log sur une machine pense-t-il à quitter tous
les process de l'utilisateur lambda avant de taper son mot de passe ? ;-)

Un user ne peut pas écouter ce que font les processes qui ne lui
appartiennent pas. Ce que je voulais mettre en avant précédemment, c'est
que pour voler des frappes clavier, il suffit d'injecter du code dans les
applis de l'utilisateur et de surcharger certaines fonctions pour
récupérer ce que l'utilisateur tape. Sous Windows, on pourra utiliser
l'API hooking, sous Unix injecter un shellcode en ptrace. Et dans la
mesure où un poste est souvent utilisé par le même user, qu'on peut
laisser des provesses en exec après qu'il soit délogué, c'est une
méthode assez efficace quand elle cible des applications précises, comme
le browser par exemple.


--
Fichtre, j'en ai posté tellement, de tellement d'auteurs, et y
compris des à moi toute seule, que si je ne le relis pas, je suis dans
l'incapacité de m'en souvenir.
-+- CJ in GNU : Pas le temps de lire "mes" posts alors les votres -+-

Eric Razny wrote:

Dominique Blas wrote:

Laurent wrote:

si quelqu'un utilise un sniffer, comment peut on le savoir simplement
(je ne suis pas expert)

Sur un réseau switché et en l'absence d'accès administratif aux dits
switches le sniffer ne sert pas à grand chose.

Ah bon, l'ARP spoofing et l'ARP cache poisoning c'est fait pour les
chiens?
Mouais ... c'est vrai. Mais dans ce cas là, sois sympa, va jusqu'au bout de

la démarche : parle également des attaques 802.1q sur l'étiquette, des
attaques d'encapsulation 802.1q ou encore des attaques sur VLAN privé.

J'ignore quel est l'âge des équipements d'interconnexion et encore moins
s'il s'agit de commutateurs dans ce collège mais les switches pro
et relativement récents ont de quoi empêcher ce type d'attaque de ARP
poisoning (ARP Inspection chez Cisco ou Port security de manière générale).
Pour ce qui est du MAC flooding et également le poisoning il plutôt simple
de mettre en place des VLAN non ?

Pour en revenir au mots de passe, on peut discuter de l'usage du workgroup,
de l'usage d'une
ancienne version de Lan Manager à une époque où le défi/réponse n'existait
pas, de l'usage, peut-être, de terminaux X non SSHisés auquel cas
effectivement le mot de passe circule en clair ou encore, sait-on jamais,
ce collège est peut-être sous Citrix ou autre TSE. Enfin, comme on ne sait
rien, ce collège utilise tout bêtement des VT320 ou des Questar ou encore
des Infowindow.

Sans compter qu'il existe souvent encore des Windows 9x dans ce type de
structures et qu'on peut même dans ce cas faire mumuse contre des
associations "statiques" :)

Bref c'est chiant d'entendre sans arrêt la rengaine "pas de sniffing,
mon réseau est switché" :-(
Ben oui mais c'est chiant également de constater que cette rumeur reste

répandue alors qu'il est simple d'y remédier soit avec des switches récents
(et professionnels) soit avec des VLAN ou les 2. :-)

(...)

On n'a pas lu le post de la même façon. Pour moi son problème semble
être les mots de passe au sens larges (banques etc) récupérable par
keylogger ou analyse du traffic et plus largement tout traffic "sensible".
Peut-être ...

passe par une
exploitation du registre du contrôleur de domaine au travers d'un << Jack
the Ripper >> par exemple. Ce type d'exploitation passe forcément par un
accès physique à la machine.

Ahem, j'adore le forcément. C'est bien connu il n'existe aucune remote
vulnerability dans ce beau monde :-/
Là encore comme on ne sait rien de l'architecture autant ne pas étaler sa

science pour l'instant. Il n'y a peut-être aucun Windows du tout et tout ce
beau monde est sur DPS7000. :-)

db
--
email : usenet blas net

Nicob wrote:

On Sat, 15 Jan 2005 14:15:01 +0000, Dominique Blas wrote:

Sur un réseau switché et en l'absence d'accès administratif aux dits
switches le sniffer ne sert pas à grand chose.

Faux ! Pour les TP, voir arp-sk (http://www.arp-sk.org/) Il n'y a que que
dans quelques rares cas très difficiles à maintenir (association en dur)
que les switchs peuvent lutter contre le snif.
Ah oui ? Et les VLAN ? ET le port security ?

db

--
email : usenet blas net

Le Tue, 18 Jan 2005 01:00:37 +0000, Dominique Blas a écrit :

Ben oui mais c'est chiant également de constater que cette rumeur reste
répandue alors qu'il est simple d'y remédier soit avec des switches récents
(et professionnels) soit avec des VLAN ou les 2. :-)

1. Ce n'est pas une rumeur, c'est une réalité.
2. Les protection que tu cites ne sont pas toutes efficaces, et surtout
pas présentes sur tous les commutateurs et en outre désactivées par
défaut

De fait, l'assertion "on peut sniffer sur les switches" est dans la
pratique nettement plus vraie que celle qui dit "on ne peut pas sniffer
sur les switches". En particulier, si je prend un switch out of the box,
n'importe lequel, l'ARP cache poisonning marchera dessus.

Enfin, le VLAN n'est pas particulièrement une protection mais une
méthode de segmentation logique, créée pour pouvoir mutualiser du
matériel pour palier à la multiplication des équipements physiques et
autres interfaces sur des routeurs/firewalls. Donc comme ça oblige de
passer au niveau 3 pour en sortir, de fait, on ne peut pas propager une
attaque de niveau 2 entre deux VLANs.


--

Quant à ma mauvaise quote de mail , désolé, c'est Outlook qui coupe tout
seul à 76. (pour ton répertoire de neuneuX, si tu veux)
(comme les lignes font déjà 76, avec les quotes, forcément, çà dépasse)
-+- C in: Guide du Neuneu d'Usenet - Quand les bornes sont franchies -+-

Dominique Blas wrote:

Eric Razny wrote:

Ah bon, l'ARP spoofing et l'ARP cache poisoning c'est fait pour les
chiens?

Mouais ... c'est vrai. Mais dans ce cas là, sois sympa, va jusqu'au bout de
la démarche : parle également des attaques 802.1q sur l'étiquette, des
attaques d'encapsulation 802.1q ou encore des attaques sur VLAN privé.

Elle existe, mais permet moi de répondre essentiellement à ton post en
ayant le post d'origine en tête et de ce que je peux (peut être à tort)
imaginer de la structure du réseau.

Je me répête :( :

PS : la question semble impliquer la non(mé?)-connaissance de certains
mécanisme et donc l'abscence de protection (arp & co).

Alors s'ils ignorent la base et comment se protéger j'imagine mal une
maitrise quelconque de la mise en place d'un VLAN.

Ensuite il ne faut pas délirer non plus et stopper la destruction de la
moquette : quel besoin de mettre les bidules à la mode de chez Cisco &
co quand les informations qui circulent n'ont pas à être réellement
protégée. Déjà en entreprise où l'équipement se justifie il est parfois
difficile d'obtenir ce qu'il faudrait, alors là...

Je dois justement passer faire en février un "avertissement pédagogique"
(si si :) ) à des élèves d'un BTS info qui commencent à partir en
vrille et demandent à gérer une partie de l'infrastructure. Il me parait
dans ce cadre plus important de leur faire prendre conscience des
risques et de la facilité de mise en oeuvre d'une attaque que de me
battre avec une direction qui de toute façon n'investira pas dans du
matos [1]

Comme pour le posteur original il semble qu'il commence à circuler pas
mal de password en clair sur le reseau vers des services extérieurs[2]...

Pour ce qui est du MAC flooding et également le poisoning il plutôt simple
de mettre en place des VLAN non ?

Simple oui, pour quelqu'un qui sait faire. Mais mettre des VLAN en place
pour le problème présenté c'est aussi prendre un bazoka pour tuer
une mouche... Et le vrai problème est simplement de faire comprendre
qu'on ne se connecte pas en échangeant des infos sensibles sur des
réseaux ou machines non sures, non?

Enfin, comme on ne sait
rien, ce collège utilise tout bêtement des VT320 ou des Questar ou encore
des Infowindow.

Tout à fait. Note cependant que c'est toi qui à introduit le sujet MS
dans ta contribution.

Bref c'est chiant d'entendre sans arrêt la rengaine "pas de sniffing,
mon réseau est switché" :-(

Ben oui mais c'est chiant également de constater que cette rumeur reste
répandue alors qu'il est simple d'y remédier soit avec des switches récents
(et professionnels) soit avec des VLAN ou les 2. :-)

Ce que tu aurais alors du préciser dans ta réponse ;)

Autre chose : c'est bien beau d'avoir le matos mais force est de
constater que la plupart du temps ce genre de structure ne dispose pas
du personnel adéquat pour le gérer (souvent un prof volontaire, avec un
peu de chance passionné).

Donc non, il n'est pas si simple d'y remédier, surtout quand
l'environnement décisionnel ne s'y prête guère. Et si on commence à
mettre des bidules administrables (très bien) on met aussi quelqu'un qui
gère les alertes quand un firmware est buggé (vu la "simplicité" du
bidule ça n'arrive heureusement pas trop souvent) ou qu'on demande un
changement de configuration, même mineur (comment ça vous n'arrivez plus
à vous connecter? Mais elle est neuve, on vient de la changer votre
carte réseau :) ).

Là encore comme on ne sait rien de l'architecture autant ne pas étaler sa
science pour l'instant. Il n'y a peut-être aucun Windows du tout et tout ce
beau monde est sur DPS7000. :-)

Yep, avec les profs formés dessus, je veux voir ça :)

Bref plaisanterie mise à part, je pense qu'il faut savoir reposer les
pieds sur terre même si on connait une solution technique "parfaite"
(ahem!) dans un cadre parfait avec un budget parfait, des admins
parfaits et... bon j'arrête là :)

Eric

[1] avec déjà des compromis délicats, fw+squid sur la même machine, plus
quelques autres services (même si verrouillés sur quelques ip+mac ça
n'ira pas loin comme limite d'accès) :((

[2] je mets semble car je ne peux pas savoir, je ne sais pas me servir
de dsniff & co :)

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

"Dominique Blas" <nospam@spam.int> wrote in message
news:41ec5753$0$1019$626a14ce@news.free.fr

Mouais ... c'est vrai. Mais dans ce cas là, sois sympa, va jusqu'au bout de
la démarche : parle également des attaques 802.1q sur l'étiquette, des
attaques d'encapsulation 802.1q ou encore des attaques sur VLAN privé.

A mon avis, ces attaques ne sont pas du tout au même niveau.
D'une part, le spanning tree n'est pas activé par défaut, et d'autre
part les attques décrites sont nettement plus complexes à mettre en
oeuvre que de l'arp cache poisonning (du moins avec les outils qui
existent)
Sans parler du VLAN hopping.

La probabilité d'occurence n'a rien à voir je pense.


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Le Tue, 18 Jan 2005 09:56:31 +0000, T0t0 a écrit :

Sans parler du VLAN hopping.
La probabilité d'occurence n'a rien à voir je pense.

Pour arriver à passer un saut de VLAN en l'état actuel de nos
connaissances, il faut un alignement de planètes et le passage de deux
comètes...


--
Bonjour, J'ai NUMERIS ITOO depuis Novembre 1998, et une nouvelle
TNRG-P2 depuis début Février 1999. J'ai une carte DJINN ITOO.
-+- JMP In : Guide du Neueu Usenet - Et ton frigo, c'est un quoi ? -+-

Le Tue, 18 Jan 2005 09:54:51 +0000, Benoit Leraillez a écrit :

Ok mais s'il n'est patché qu'en mémoire et non sur disque il faut le
faire à chaque fois que le user se reconnecte et donc pouvoir se
relancer, non ?

tout se base sur le fait que tu vas laisser des processes en exécution.
Effectivement, si tu killes systématiquement tous les processes d'un
utilisateur quand il se délogue, tu rends la tâche plus compliquée. Il
faudrait implémenter un suspend2disk au niveau du process :))))

Mais chez moi si un user est délogué ses process sont terminés
puisque sa mémoire allouée est inexistante. Patcher le browser est
inpossible puisque c'est une appli générique donc modifiable par
l'admin uniquement (sauf appli non corrigée qui ont le droit a des
buffer overflow permettant ce genre d'exploit). Pas trop de fautes ? ;-)

Exécuter du code à travers un browser est possible. Après, il faut
s'adapter au contexte. Il faut reconnaître que ton contexte est
sacrément contraignant pour arriver à faire des trucs efficaces
simplement, en particulier en ne s'appuyant pas sur la persistence d'un
ou plusieurs processes comme le font pas mal de spywares du marché (trois
processes qui se surveillent).


--
Pour le moment, il ne répond pas à mes propositions, je n'en tiens pas
encore rigueur, mais si cette situation dure, je ferai appel à fufa pour
le forcer à tenir compte de mes propositionse.
-+- ST in: Guide du Neuneu d'Usenet - Surtout retiendez moi -+-