==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10 |==[Découverte de firewall et analyse des réseaux avec un CRC corrompu]-==| |=-----------------------------=[ Ed3f ]=------------------------------------------------=| |=----------------=[Traduit par Jacob [Degenere-science]=-----------------------=| --[ Table des matières 0 - School 1 - Something In The Way 2 - Come As You Are 3 - You Know You're Right 4 - Drain You 5 - Big Long Now --[ 0 - School Les firewalls de type filtrage de paquets vont êtres de plus en plus déployés, pour l'impression de sécurité que dégage le mot " firewall " à l'égard des personnes non qualifiées techniquement. Disponibles en tant que logiciels commerciaux, matériels dédiés, ou firewalls pré-installés directement à l'intérieur des OS open source, ils travaillent au niveau 3. Le support pour le niveau 4 n'est pas complet : Ils filtrent le numéro de port, les flags TCP, le numéro de séquence, la défragmentation, mais... Que savons-nous pour le checksum de niveau 4 ? Vérifient-ils le checksum TCP avant d'analyser les flags ou les numéros de port ? Non. Beaucoup de développeurs disent qu'il seraient trop surchargés(?), et d'autre pensent que le paquet va simplement être ignoré par la pile de l'OS de destination. Tout semble correct, mais comment pouvons-nous tirer parti de cette " caractéristique " ? 1) Découverte des réponses des firewalls 2) Découverte des fichus MiM 31337 3) Insérer des paquets invalides dans le réseau. --[ 1 - Something In The Way Une pile complète de réseau va ignorer les paquets invalides sans y répondre. Peu importe si le port est fermé, ouvert, ou quoi que ce soit... Mais les filtrages de paquets ne sont pas aussi intelligents et ils vont y répondre. Si nous souhaitons déterminer si il y a un filtrage de paquet entre nous et l'hôte cible, nous devons d'abord vérifier si le filtrage de paquet est configuré pour ignorer les paquets, ou pour renvoyer une erreur. Pour cela, nous envoyons un paquet TCP valide a un port quelconque qui est supposé être filtré : # telnet www.oracle.com 31337 Trying 148.87.9.44... telnet: Unable to connect to remote host: Connection refused Bien. Soit l'hôte cible lui-même, soit un filtrage de paquet renvoie un RST. La prochaine étape est de découvrir si le RST provient de l'hôte cible ou d'un dispositif de filtrage de paquet. # hping -S -c 1 -p 31337 -b www.oracle.com HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms Si nous obtenons une réponse, nous saurons alors qu'un filtrage de paquet est en place. Si nous n'obtenons aucune réponse, nous pouvons supposer que le paquet arrive non filtré jusqu'à l'hôte de destination, et qu'il est ignoré par la pile TCP (c'est a dire qu'aucun filtrage de paquet n'est en place). Une autre technique pour détecter l'existence d'un filtrage de paquet est de comparer le TTL d'un RST et d'un SYN (qui provient directement de l'hôte cible). La méthode TTL ne fonctionne pas pour tout les filtrages de paquets en mode pont ou pour les filtres qui ne diminuentpas le TTL et sont placés directement devant l'hôte cible (installation normale d'une DMZ). La technique CRC comme décrite plus haut détecte un dispositif de filtrage de paquet dans les deux cas. Autre exemple, avec UDP cette fois : # hping -2 -c 1 -p 53 -b www.redhat.com HPING www.redhat.com (rl0 66.187.232.56): udp mode set, 28 headers + 0 data ICMP Packet filtered from ip=63.146.1.74 name=UNKNOWN Nous avons une manière de distinguer les paquets provenants de l'hôte, et ceux provenants du firewall. Pour cela, utilisons les outils d'identification de l'OS fonctionnant seulement avec les paquets du firewall, sans mixer les réponses de l'hôte et du firewall. Essayons nmap -O. Intéressant ? Bien, j'ai fait un petit patch pour Nmap-3.1ALPHA4 qui rajoute deux nouveaux type de scans : -sZ BadTCP SYN stealth port scan -Sv BadUDP port scan Notez que -sZ est dérivé par un mauvais drawn -sS et -sV par -Su. Le scan " Badtcp " utilise le moteur de scan FIN parce que le comportement par défaut d'un hôte est de ne pas répondre. Le scan BadUDP utilise le moteur de scan UDP, parce le comportement par défaut d'un hôte est également de ne pas répondre. J'espère que Fyodor va penser à ajouter le patch pour la toute nouvelle version 4.00 de Nmap, ce qui permettrait de définir la situation complète, et réelle, d'un port : Fermé Ouvert Filtré (pas de réponse) Firewallé (le firewall répond) Le patch est en bas. Comment fonctionne Scanlogd contre ces deux nouveaux type de scan ? Huum…il pense encore que ce sont des paquets valides et il ne donne pas l'option de configuration à l'alerte pour les paquets SYN valides ou invalides --[ 2 - Come As You Are OK, les filtrages de paquets, comme le magnifique OpenBSD 3.2 PF, devraient calculer le checksum pour chaque paquet ? Non, pour éviter la découverte des réponses, ils pourraient vérifier le checksum seulement pour chaque paquet auquel ils veulent répondre. Cependant, il devrait introduire une option pour découvrir les paquets avec checksum corrompus, et les ignorer. Beaucoup d'outils vous laissent changer les paquets et permettre l'existence de MiM, comme ettercap, et laisser votre hôte envoyer des paquets à la bonne box et ensuite les loguer/altérer à la destination réelle. Comment pouvons-nous découvrir l'astuce des bannières? # echo "SSH-1.99" > /tmp/banner # hping -S -c 1 -p 22 -E /tmp/banner -d 9 -b Ma box Si vous recevez un SYN+ACK vous pouvez commencer.. Notez que cela dépend de comment l'attaque MiM est développée. Par exemple, Dsniff vérifie le checksum TCP parce qu'il fonctionne en mode proxed, contrairement à ettercap, qui ne le fait pas. Généralement si vous n'ajoutez pas un tel contrôle dans vos outils, vous pourriez être découvert. Est-ce que l'on a toujours besoin de cette vérification ? Non, c'est nécessaire si vous voulez modifier un paquet ou si vous voulez répondre à un paquet reçu. Si vos outils sniffent simplement les paquets sans les envoyer/modifier vous êtes en sécurité. Ok, mais si je veux, répondre/modifier les paquets en toute sécurité, qu'elle est la solution ? Vous avez deux solutions : 1) Vérifier le checksum pour chaque paquet, et travaillez seulement si c'est correct sans l'ignorer dans tous les cas ; modifier/répondre en utilisant un checksum valide. 2) Utilisez la mise à jour incrémentale du checksum Internet (RFC1141) pour les paquets qui ont besoins d'être modifiés ; vérifiez le checksum pour les paquets auxquels vous voulez répondre. Notez que la mise à jour incrémentale va garder un checksum corrompu si ce dernier était corrompu, et correct si ce dernier était correct et c'est beaucoup plus facile que de le calculer depuis le début. Curiosité : Le checksum TCP des paquets routés par la source est invalide pendant que ceux-ci sont en trajet, parce qu'il est basé sur l’adresse ip de destination finale, qui est changé du fait que la route source est suivie (arrivé à destination il sera correct) Beaucoup de configurations par défaut d'IDS vont alerter lorsqu'il y a un trafique avec checksum corrompus mais jamais loguer ces paquets, ainsi l'administrateur peut vérifier la partie donnée et ce qui est envoyé. Généralement, Il est possible de créer un shell couvert avec un mauvais tunnel checksum sur une box r00t compromise et de se connecter a celle ci sans êtres détecté. Un autre type de problème peut naître si le code d'une box NAT/ répartiteur de charge calcule le checksum du patch. Dans ce cas nous pouvons outrepasser un IDS si celui-ci est placé entre notre box et ce service sourd. Vérifions cet exemple intéressant : Hacker--[Mauvais SYN]--> Routeur --[Mauvais SYN]-->Répart. de charge--[SYN]--> Serv. web | | NIDS1 NIDS2 NIDS1 verra un SYN TCP avec un checksum invalide contrairement a NDIS2, si déployé, qui verra un SYN valide et modifié. Donc le serveur web va nous répondre avec un SYN+ACK, nous laissant ainsi " entrer en communication " avec lui contrairement à NIDS1, a qui nous allons causer beaucoup de doute. Que penseriez-vous, si vous étiez le manager de la sécurité et que vous trouviez des résultats si différent entre NIDS1 et NIDS2 ? La solution, c'est toujours la mise à jour incrémentale [RFC1141] --[ 3 - You Know You're Right awgn (31337 H4X0R) raptor & nobody (projet LSD) batmaNAGA & ALORobin (l'auteur d'ettercap) JWK (un adepte d'OpenBSD) Daniel Hartmeier (Mr.Patience infinie; principal codeur d'OpenBSD PF) antirez (l'auteur de Hping) Fyodor (l'auteur de Nmap) Ed3f (15b27bed5e11fc0550d7923176dbaf81) --[ 4 - Drain You [1] Hping ---> http://www.hping.org [2] Nmap ---> http://www.insecure.org/nmap [3] Scanlogd ---> http://www.openwall.com/scanlogd [4] OpenBSD ---> http://www.openbsd.org [5] OpenBSD PF ---> http://www.benzedrine.cx/pf.html [6] Ettercap ---> http://ettercap.sourceforge.net [7] DSniff ---> http://monkey.org/~dugsong/dsniff [8] RFC1141 ---> http://www.ietf.org/rfc/rfc1141.txt --[ 5 - Big long now begin 600 nmap-fw-detection-patch.diff M9&EF9B`M=7).8B!N;6%P+3,N,3!!3%!(030O3FUA<$]PF5O9BA&24Q%("HI("H@3$]'7U19 M4$53*3L*("`@;FUA<%]S=&1O=70@/2!S=&1O=70["D!`("TQ-38L,3$@*S$U M-RPQ,2!`0`H@?0H@"B!B;V]L($YM87!/<',Z.E1#4%-C86XH*2!["BT@(')E M='5R;B!A8VMS8V%N?&)O=6YC97-C86Y\8V]N;F5C='-C86Y\9FEN&UA7!E('=H:6-H(')E<75I6YS8V%N*W=I;F1O M=W-C86XK>&UA2!O;F4@;V8@+7-!+"`M8BP@+7-4+"`M7,@/B`P("8F M("AB;W5N8V5S8V%N('Q\(&-O;FYE8W1S8V%N*2D@>PH@("`@(&5R7,@87)E(&ER2!W;W)KPHK M("`@(&9A=&%L*")&&UA6YS8V%N?'5D<'-C86Y\8F%D=61P2!A M=F%I;&%B;&4@9F]R(&-O;FYE8W0H*2!S8V%N("@M6]D;W)` M:6YS96-U&UA7!E9&5F(&5N=6T@>R!!0TM?4T-!3BP@4UE.7U-#04XL($9)3E]30T%. M+"!834%37U-#04XL(%5$4%]30T%.+"!#3TY.14-47U-#04XL($Y53$Q?4T-! M3BP@5TE.1$]77U-#04XL(%)00U]30T%.+"!-04E-3TY?4T-!3BP@25!04D]4 M7U-#04XL($)!1%1#4%]30T%.+"!"04151%!?4T-!3B!]('-T>7!E.PH@"B`C M96YD:68@+RI'3$]"04Q?4U1254-455)%4U](("HO"F1I9F8@+75R3F(@;FUA M<"TS+C$P04Q02$$T+VYM87`N8V,@;FUA<"TS+C$P04Q02$$T+6)A9"]N;6%P M+F-C"BTM+2!N;6%P+3,N,3!!3%!(030O;FUA<"YC8PE-;VX@3F]V(#$Q(#$X M.C`S.C4V(#(P,#(**RLK(&YM87`M,RXQ,$%,4$A!-"UB860O;FUA<"YC8PE4 M:'4@1&5C(#$R(#`Y.C`T.C0Y(#(P,#(*0$`@+34Q,RPW("LU,3,L-R!`0`H@ M("`@("`@8G)E86L["B`@("`@8V%S92`G7!E(#T@4$E.1U194$5?3D].13L@8G)E M86L[(`H@"6-A7!E("5C(&YO="!S=7!P;W)T961<;B(L*G`I.R!PPI`0"`M.#$U M+#<@*S@Q-RPW($!`"B`@("`@("!I9B`H8W5R6YS8V%N('Q\(&\N:61L97-C M86X@?'P@;RYF:6YS8V%N('Q\(&\N;6%I;6]N&UAPH@"2`@:68@*&\N4V]U&UA6]U(&%R92!T&UA7!E'!EPH@("!C87-E(%!/4E1?3U!%3CH@PI` M0"`M,C8Q+#$R("LR-C$L,38@0$`*(`H@("!I9B`H<&QI7!E(#T](%A-05-?4T-!3BD@7!E(#T]($9)3E]30T%.*2!S8V%N9FQA9W,@/2!42%]&24X[ M"BL@(&5L7!E(#T]($)!1%1#4%]30T%.*2!S8V%N9FQA M9W,@/2!42%]364X["B`@(&5L7!E(#T]($U!24U/3E]3 M0T%.*2!S8V%N9FQA9W,@/2!42%]&24Y\5$A?04-+.PHM("!E;'-E(&EF("AS M8V%N='EP92`A/2!51%!?4T-!3B`F)B!S8V%N='EP92`A/2!)4%!23U1?4T-! M3BD@>PHK("!E;'-E(&EF("AS8V%N='EP92$]54107U-#04X@)B8@7!E(3U"04151%!?4T-!3BD@>PH@ M("`@(&9A=&%L*")5;FMN;W=N('-C86X@='EP92!F;W(@7!E/3U" M04151%!?4T-!3BD*(`D)("!S96YD7W5D<%]R87=?9&5C;WES*')A=W-D+"!T M87)G970M/G8T:&]S=&EP*"DL(&DL"B`)"0D)("`@("`@8W5R6QO860L(&\N97AT2`F)@HM"0D@("`@*'-C86YT>7!E(#T](%5$4%]30T%.('Q\('-C M86YT>7!E(#T]($E04%)/5%]30T%.*2D**PD)("`@("AS8V%N='EP93T]5410 M7U-#04X@?'P@7!E/3U) M4%!23U1?4T-!3BDI"B`)"2`@=7-L965P*'-E;F1D96QA>2D["B`)("`@("`@ M?0H@"2`@("!]"D!`("TQ-#(P+#<@*S$T,C$L-R!`0`H@"2`@("!G971T:6UE M;V9D87DH)F-U7!E/3U51%!? M4T-!3B!\?"!S8V%N='EP93T]0D%$54107U-#04XI"B`)("`@("`@'1R85]P87EL;V%D7VQE;F=T:"D["B`)("`@(&5L7!E(#T]($E04%)/5%]30T%.*0I`0"`M,30S,"PW("LQ-#,Q+#<@ M0$`*(`D@("`@("!S96YD7W1C<%]R87=?9&5C;WES*')A=W-D+"!T87)G970M M/G8T:&]S=&EP*"DL(&\N;6%G:6-?<&]R="P@"B`)"0D)("!C=7)R96YT+3YP M;W)T;F\L(#`L(#`L('-C86YF;&%G'1R85]P87EL;V%D7VQE;F=T:"D["BT)("`@ M(&EF("@H7!E/3U"04151%!?4T-!3B!\?"!S8V%N='EP93T]25!04D]47U-# M04XI("8F"B`)"7-E;F1D96QA>2D*(`D@("`@("!UPI`0"`M,34S-"PV("LQ-3,X M+#@@0$`*(`D)("!C87-E(#(Z("\J('!R,'0P8S!L('5N7!E/3U"04140U!?4T-! M3BD@>PHK"0D@("`@("`@(&YE=W-T871E(#T@4$]25%]&25)%1#L*(`D)("`@ M('T@96QS90H@"0D@("`@("!N97=S=&%T92`](%!/4E1?1DE215=!3$Q%1#L* M(`D)("`@(&)R96%K.PI`0"`M,34T,2PQ,B`K,34T-RPQ."!`0`H@"0D@(&-A M7!E/3U"04140U!?4T-!3BD@>PHK"0D@("`@("`@(&YE=W-T M871E(#T@4$]25%]&25)%1#L**PD)("`@('T@96QS90HK"0D@("`@("`@(&YE M=W-T871E(#T@4$]25%]&25)%5T%,3$5$.PH@"0D@("`@8G)E86L["B`)"2`@ M"B`)"2`@8V%S92`Y.@H@"0D@(&-A2!P7!E/3U"04151%!?4T-!3B!\?"!S8V%N='EP93T]0D%$5$-0 M7U-#04XI"BL)"2`@("`@(&YE=W-T871E(#T@4$]25%]&25)%1#L**PD)("`@ M(&5LPHK"0EI9B`H*&-UPH@"0D@('1A2D@ M2`J(#(L(#$P,#`P,#`I.PH@"0D@("`@("!I9B`H7!E/3U"04151%!?4T-!3B!\?"!S8V%N M='EP93T]25!04D]47U-#04XI*0H@"0D);6%X7W=I9'1H(#T@34E.*&UA>%]W M:61T:"PR*3L*(`D)("`@("`@9G)E7!E/3U51%!?4T-!3B!\ M?"!S8V%N='EP93T]0D%$54107U-#04X@?'P@'0@/2!C=7)R96YT+3YP7!E/3U"04151%!?4T-!3BD_($E04%)/5$]?5410 M(#H*(`D)"2`@*'-C86YT>7!E(#T]($E04%)/5%]30T%./R!)4%!23U1/7TE0 M.B!)4%!23U1/7U1#4"DL(`H@"0D)3E5,3"P@8W5RPHK("`@(&EF("@H7!E/3U"04151%!?4T-!3BD@)B8@8VAA;F=E9"`F)B`H=')I M97,@*R`Q*2`\(#$P,"D@>PH@("`@("`@:68@*&\N9&5B=6=G:6YG*2!["B`) M;&]G7W=R:71E*$Q/1U]35$1/550L(")3;&5E<&EN9R!F;W(@,2\R('-E8V]N M9"!T;R!O=F5R8V]M92!)0TU0(&5R7!E/3U"04151%!? M4T-!3BD@)B8@=')I97,^/3`I"BL@("`@("!B7!E(#T]($E04%)/5%]30T%.*0H@ M("`@("`@861D<&]R="@F=&%R9V5T+3YP;W)T7!E("$](%5$4%]30T%.*0HK("`@(&5L7!E M(#T]($)!1%1#4%]30T%.*0HK("`@("`@861D<&]R="@F=&%R9V5T+3YP;W)T M7!E(#T]($)!1%5$ M4%]30T%.*0HK("`@("`@861D<&]R="@F=&%R9V5T+3YP;W)T7!E(3U51%!?4T-!3BD*("`@("`@ M(&%D9'!O2!D971E8W1E9"DB*3L**R`@?0HK M("`*("`@+RH@4W5P97(@R`@("`*("`@("!I9B`HPH@ M"6EF("AO+G9E&UAPHK"2`@("`@;RYU M9'!S8V%N('Q\(&\N;W-S8V%N('Q\(&\N=VEN9&]WPH@"2`@&9F9F8I.R`@("`O*B!A9&0@:&EG:"TQ-B!T;R!L;W