From: sami.ghourabi@icn.com.tn
Date: Fri Jan 19 2007 - 16:52:22 EST
Hi all,
Ron is right, information provided doesn't allow to guess the
internal setup of the Webservers infrastructure.
So here is some other info(all IP are fakes)
the three last hops before servers cannot be seen, perhaps because the first
bloks all outgoing ICMP time exceed packets.
192.168.1.150
******
******
192.168.68.X
Filtering
TCP SYN packets to ports 80 and 443 are the only accepted ones.
TCP ACK fail to go through, this means that there exists a stateful filtering,
probably firewall (do routers have the ability to monitor TCP sessions state ?)
traceroutes(ICMP, UDP and TCP)
TTL
TTLs of packets back from 192.168.68.X are not always the same (for a fixed IP of
course), and the route back from servers is longer than route to the servers.
here is an example:
1 me
2 X.X.X.X
3 X.X.X.X
4 192.168.1.150
5 ****
6 ****
7 192.168.68.227
ping 192.168.68.227
Reply from 192.168.68.227 : octets=32 time=64 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=61 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=72 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=46 ms TTL=122
Reply from 192.168.68.227 : octets=32 time=55 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=42 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=49 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=126 ms TTL=122
Reply from 192.168.68.227 : octets=32 time=50 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=43 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=54 ms TTL=121
Reply from 192.168.68.227 : octets=32 time=101 ms TTL=121
Assuming that initial TTL was 128, if the packet took the same route back,
received TTL should be 124. Notice here that it is 121 or 122.
Another test showed that the difference in route occurs in the area where we can
see IP adresses. We can be sure of this, cause traceroute to the gateway
192.168.1.150 and TTL from ping are in accordance.
So, we can infer that there is more than two routing devices in the black area,
and that there is some dynamic routing (or other technology ?). I hope that one
of you have an idea about this setup.
Another intersting info provided by TTLis that we can see that we receive 3
different type of TTL back from the servers (TTl close to 64, ohers close to 255
and last ones close to 128). For me, this info means that that there is not a
reverse proxy that handles communication for the entire subnet because the
packets are generated by at least three different tcp/ip stacks. Reverse proxies
are generally the termination of all incoming TCP/IP connections (correct me if
I'm wrong), if there was one all recieved TCP/IP packets would look similar.
We will now focus on hosts whose TTL are close to 128, as we can suppose that
they are Windows Boxes.
Among these hosts some of them reply with the messages "No web site is
configured at this address" in english and in french.
This tends to confirm that these IP are coming from Windows boxes that
may run IIS.
Examination of the HTTP headers coming from these IP shows that we are
receiving reply of 6 different type with regard to HTTP header parameter
server:
many IP replied with Server param set to "webserver"
some IP replied with Server param set to "MS-IIS/5.0"
some IP replied with no server param
one with "Apache 1.3.20 / Tomcat 1.0" (this version is known to hold a
serious flaw whose exploit is available)
one with "Apache"
and one with "JRUN"
So there is at least 6 different MS Windows Boxes.
Here I returned back to the network layer to check for TCP Windows size in TCP
SYN ACK replies from servers. I know that Windows 2000 default initial window
size is around 16600,NT is around 8700 (is this correct ?). However I also
recieved packet with window size of around 62535 (what Windows OS version could
it be ?)
Now let's see the application level filtering. Guys that know well IIS,
URLscan, Apache, mod_rewrite, and mod_security config and behavior are
needed here.
thanks to search.live.com (and Olivier who provided the info) we are
able to get a list of website hosted on these IP address.
I tried to request pages using ip address and website name to compare
results.
For the server that doesn't reply with a server param (4 ip), when
requesting with IP we recieve error 400 replies with message "Bad
request (Invalid Host name)".
When requesting with the name of website corresponding to those IPs, the
HTTP response contains server param which indicates that it's a IIS6.0.
How do u interpret this, what are possible configurations to get this
behavior ?
For "webserver" (about 15 ip addresses), when requesting with IP, we
receive 17 error 404 HTTP replies, one error 403, and a webpage
404 replies come with a personalized (or default ?) message. we have
three different messages:
"No web site is configured at this address" (1 time)
"Aucun site web n'est configuré à cette adresse" (14 times, french
translation of the above)
"Le fichier spécifié est introuvable" (2 times, Requested file cannot be
found).
403 reply comes with a message in french
the web page comes with the URL being rewrited or redirected (in my
firefox address bar I always have an IP address)
When searching on windows live, each of the IP addresses hosts one ore
most websites.
How do u interpret all this data, what are possible configurations to get these
behavior ? Any comments about how I proceeded ?
On Tue Jan 16 22:16 , "R. DuFresne" sent:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Fri, 12 Jan 2007, sami ghourabi wrote:
>
>> I'm currently pentesting C class subnet.
>> It seems that it hosts webservers, as a large number of IP @ replied OK to
>> port 80 scan.
>> However I dont think that for each IP adress there is a physical server, but
>> perhaps a multiplexing device that also does application firewalling.
>> According to nmap it may be a Blue Coat SG4.
>> When I browse to the IPs with firefox, I recieve several messages "No web
>> site is configured at this address." for some IP.
>> Does anybody here know if this message is specific to a given reverse
>> proxy/web server product ?
>> Any other experiences similar to this situation are welcome.
>>
>
>
>Actually, it could be just about any firewall/security device in the path
>that has a port 80 opened for some devices behind it and answers up front
>for all devices behind it. I do not think enough info is provided here
>for anyone to make that determination, and it's hard to collect and
>disseminate this is the case without actually being the firewall/network
>admoin for the site in question. There are clues that can lead on to make
>a guess this is the setup you are facing, but not way to fully determine
>this is the case, with a properly configured set of security devices up
>front. Then again, could be someone opening a listener on the other IP's
>in qustion that is not web oriented, your test with firefox is in itself
>insuficcient to flesh that out as well.
>
>Thanks,
>
>Ron DuFresne
>- --
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> admin & senior security consultant: sysinfo.com
> http://sysinfo.com
>Key fingerprint = 9401 4B13 B918 164C 647A E838 B2DF AFCC 94B0 6629
>
>...We waste time looking for the perfect lover
>instead of creating the perfect love.
>
> -Tom Robbins
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.5 (GNU/Linux)
>
>iD8DBQFFrUC7st+vzJSwZikRAuauAKCX9/EKTdjq4IMWQqDR8lItOhMivgCeLV/Q
>xyyy3wZzExc0bQmU9uEFABQ=
>=rJ6C
>-----END PGP SIGNATURE-----
>
>------------------------------------------------------------------------
>This List Sponsored by: Cenzic
>
>Need to secure your web apps?
>Cenzic Hailstorm finds vulnerabilities fast.
>Click the link to buy it, try it or download Hailstorm for FREE.
>
>http://www.cenzic.com/products_services/download_hailstorm.php\?camp=701600000008bOW
>------------------------------------------------------------------------
>
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php?camp=701600000008bOW
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:57:32 EDT