==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10 |=----=[ Firewall spotting and networks analisys with a broken CRC ]=----=| |=-----------------------------------------------------------------------=| |=-----------------------------=[ Ed3f ]=--------------------------------=| --[ Contents 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 Packet filters firewall are going to be deployed more and more for the sense of security the word "firewall" has got on not-technical people. Available as commercial software, embedded device or inside opensource OS they work at level 3. The support for level 4 isn't complete: they filter ports numbers, TCP flags, seq numbers, defragmentation, but ... What about level 4 checksum? Are they checking for TCP checksum before analyze flags or port numbers? No. Most developers say there would be too overhead and other think that the packet will be simply dropped by destination OS stack. All correct, but how could we take advantage of this "feature"? 1) firewalls reply spotting 2) damn 31337 MiM spotting 3) insert invalid packets inside a network --[ 1 - Something In The Way A complete network stack will drop invalid packets without response. No matter if that port is closed, open or whatever... But Packet Filters aren't so smart and they will reply. If we want to determine if there is a packet filter between us and a target host we must first check if the packet filter is configured to drop the packets or to send back an error. For this we send a valid tcp packet to any port that is supposed to be filtered: # telnet www.oracle.com 31337 Trying 148.87.9.44... telnet: Unable to connect to remote host: Connection refused Good. Either the target host itself or a packet filter sends back a RST. Next step is to check if the RST comes from the target host or from a packet filter: # 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 If we get a reply we know that a packet filter is in place. If we dont get a reply we suspect that the packet arrives unfiltered at the destination host and is dropped by the TCP stack (e.g. no packet filter is in place). Another technique to detect the existence of a packet filter is to compare the TTL of a RST and a SYN (which comes directly from the target host). The TTL-technique fails for all packet filters in bridging mode or filters that do not decrease the TTL and are placed directly in front of the target host (normal DMZ setup). The CRC-technique as described above on the other hand detects a packet filtering device in both cases. Other example, UDP this time: # 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 Having a way to distinguish packets from the host and the firewall, let us use OS identification tools working only with firewall packets without mixing host and firewall replys. Try nmap -O. Interesting ? Well I made a quick patch for Nmap-3.1ALPHA4 that add 2 new type of scan: -sZ BadTCP SYN stealth port scan -sV BadUDP port scan Note that -sZ is derived by a bad drawn -sS and -sV by -sU. BadTCP scan uses FIN scan engine because the default behavior of a host is not to reply. BadUDP scan uses UDP scan engine because the default behavior of a host is not to reply. I hope that Fyodor will think about a from scratch version of Nmap for version 4.00 that could permit to define the real and complete situation of host ports: - closed - opened - filtered (no reply) - firewalled (firewall reply) The patch is below. How does Scanlogd work against this new type scans? Uhm, it still thinks that they are valid packets and it doesn't give the configuration options to alert for valid or invalid SYN packets. --[ 2 - Come As You Are Ok, so packet filters, even the beautiful OpenBSD 3.2 PF, will have to calculate the checksum for every packet? No, to avoid reply spotting they could check the checksum only for packets they want to reply. However it should be introduced an option to spot broken checksum packets and drop them. Some tools that let you alter packets and permit MiM exist, like ettercap, and let your host send packets to the right box and after logging/altering forward them to the real destination. How could we spot the banner trick ? # echo "SSH-1.99" > /tmp/banner # hping -S -c 1 -p 22 -E /tmp/banner -d 9 -b mybox If you receive a SYN+ACK you can start swearing... Note that depends on how the MiM attack is developed. For example DSniff check TCP checksum because it works in proxed mode, while ettercap, that uses a non-proxed method, doesn't. Generally if you don't add such a sanity check in your tool you could be discovered. Is this check always needed? No, it's needed if you want to alter a packet or you want to reply to a received packet. So if your tool simply sniff packets without sending/modifying them you're safe. Ok, but if I want to safely reply-to/modify packets what is the solution? You have 2 solutions: 1) check the checksum for every packet and work only if correct without dropping it in any case; modify/reply-to using a valid checksum. 2) using Incremental Updating of the Internet Checksum [RFC1141] for packets that needs to be modified; checking the checksum for packets you want to reply Note that incremental updating will keep a checksum broken if it was broken and correct if it was correct and it's really faster than calculating it from scratch. Curiosity: TCP checksum of a source route packets is invalid while it's in flight, because it is based on the final destination IP address, which is altered as the source route is followed (at the destination, it will be correct). Most default IDS configurations will alert about bad checksumming traffic but never log those packets, so the admin couldn't check the data part and what was going on. Generally it's possible to create a covert shell with a bad cksum tunnel on a r00t compromised box and connect to it without being detected. Another type of problem could born if the code of a NAT-box/load balancer calculate che checksum from scratch. In this case we could bypass an IDS if it's placed between our box and this dumb device. Check this interesting example: www.oracle.com:80 Evil --[badSYN]--> Router --[badSYN]--> Load_Balancer --[SYN]--> WebServer | | NIDS1 NIDS2 NIDS1 will see a TCP SYN with invalid checksum while NIDS2, if deployed, will see a valid and modifyed SYN. So the webserver will reply to us with a SYN+ACK, letting us talk with it while causing a lot of doubts to NIDS1. What would you think if you were the security manager and you'll find such different results on NIDS1 and NIDS2 ? The solution is always Incremental Updating [RFC1141]. --[ 3 - You Know You're Right awgn (31337 H4X0R) raptor & nobody (LSD project) batmaNAGA & ALORobin (ettercap authors) JWK (OpenBSD addicted) Daniel Hartmeier (Mr.Infinite Patience; OpenBSD PF main coder) antirez (Hping author) Fyodor (Nmap author) 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