Dug Song (author of fragroute) was kind enough to send me a better set of parameters for masking IIS Unicode Traversals. According to him, these results will be far more meaningful. After a quick test, this appears to be true. The scenario is the same as yesterday's, but this time there is a sentry in front of both the source and the target networks. The results are quite interesting. The fragroute.conf: tcp_seg 1 tcp_chaff paws order random print <--- again, only as a sanity check This is the same stream of IIS traversal attempts as used yesterday. The results: As seen from in front of attacker: TCP data changed, count 6109 HTTP URL bad hex code, count 6 Telnet abuse, count 4223 As seen from in front of target: TCP data changed, count 6093 HTTP URL bad hex code, count 6 Telnet abuse, count 4122 The results are pretty wild. As we can see, there are no IIS traversal related events. The source-located sentry pulled this out of the "bad hex code" stream: ...a../...q.../..n.t/...t.m....md.exe|...t..b.n/....5.e......e....25.... .52e/..%.e....2./..nnt/.y...m.2......x............H.T./....|..cr........ 2..e.............2e...252e.....2......2e/...n....s.em3...md..x....+d.r.. :| The target-located sentry pulled this out of the bad hex code stream: ./......pc.........c......1.p.../w.n.t.sy.....2...d...e You can *almost* read the IIS traversal inside these events. Obviously, the event itself is a false positive, as we know that's not what we were transmitting. The telnet abuse is kind of surprising. I'm not sure what the sentry was thinking. Telnet abuse is normally generated by any interactive terminal session opened against a port that isn't 23 -- our script has not set this off in the past. So, here's the questions. We've mangled the data to the point where the sentry can't properly parse the data. But is the receiving IP stack reassembling the data better? Would the sent commands activate as intended? The events sent off a slew of red flags in our operations center (that's a lot of TCP data changed), and in a managed client situation would have prompted a response from our staff, but the traversals have been masked to the point where a casual observer might miss what was actually occurring. The response to this really depends on the posture of your (as a security provider) individual operations centers. I'd like to play with this some more, when I can get a more controlled target environment -- I apologize for the haste of this update. Thanks to Dug for the strings -- 1 byte is really small! If anyone gets to experiment with this before I do, please, share your findings. --Chris ******************************************** Chris Deibler, CISSP Senior Security Consultant VigilantMinds Inc. Office 412-661-5700 ext.205 Fax 412-661-5684 www.vigilantminds.com ********************************************
This archive was generated by hypermail 2b30 : Fri Apr 26 2002 - 16:22:55 PDT