Strange response from network

From: Shashank Rai (shashrai_at_emirates.net.ae)
Date: 09/15/04

  • Next message: Anders Thulin: "Re: Web Application Tester"
    Date: Wed, 15 Sep 2004 14:36:14 +0400
    To: pen-test@securityfocus.com
    
    

    Hi all,

    I observed the following during a pentest i am doing:

    1) A port scan of the TARGET_IP (using nmap 3.7 with -sS, -sV and OS
    identification), shows port 2443 open and remaining ports as "closed".
    2) Nmap fails to identify the OS but identifies the service as
    "Microsoft Distributed Transaction Server".
    3) The interesting (and strange) part comes from here on. A
    tcptraceroute to port 2443 on the TARGET_IP, showed RST/ACK packets
    coming back. To further investigate this, i started sending packets by
    manually increasing the ttl. I obtained the following results:

    SYN packet to port 2443, ttl 7 (last but one hop from target) sends
    RST/ACK....

    hping2 -S -V -n -c 1 -p 2443 -t 7 TARGET_IP
    using eth0, addr: MY_IP, MTU: 1500
    S set, 40 headers + 0 data bytes

    len=46 ip=TARGET_IP ttl=249 id=40109 tos=0 iplen=40
    sport=2443 flags=RA seq=0 win=0 rtt=6.3 ms
    seq=80210401 ack=1098187429 sum=ec0b urp=0

    --- TARGET_IP hping statistic ---
    1 packets tramitted, 1 packets received, 0% packet loss
    round-trip min/avg/max = 6.3/6.3/6.3 ms

    ==========================================================================

    SYN packet to port 2443 ttl 8 (TARGET IP) gives SYN/ACK ..expected
    response.......

    hping2 -S -V -n -c 1 -p 2443 -t 8 TARGET_IP
    using eth0, addr: MY_IP, MTU: 1500
    S set, 40 headers + 0 data bytes
    len=46 ip=TARGET_IP ttl=122 id=16401 tos=0 iplen=44
    sport=2443 flags=SA seq=0 win=16384 rtt=6.1 ms
    seq=416937317 ack=1244107777 sum=61fe urp=0

    --- TARGET_IP hping statistic ---
    1 packets tramitted, 1 packets received, 0% packet loss
    round-trip min/avg/max = 6.1/6.1/6.1 ms

    ===========================================================================

    SYN packet to port 25 (closed port) ttl 7 and there is NO response....

    hping2 -S -V -n -c 1 -p 25 -t 7 TARGET_IP
    using eth0, addr: MY_IP, MTU: 1500
    S set, 40 headers + 0 data bytes

    --- TARGET_IP hping statistic ---
    1 packets tramitted, 0 packets received, 100% packet loss
    round-trip min/avg/max = 0.0/0.0/0.0 ms

    ===========================================================================

    SYN packet to port 25 ttl 8 ... NO RESPONSE.

    hping2 -S -V -n -c 1 -p 25 -t 8 TARGET_IP
    using eth0, addr: MY_IP, MTU: 1500
    S set, 40 headers + 0 data bytes

    --- TARGET_IP hping statistic ---
    1 packets tramitted, 0 packets received, 100% packet loss
    round-trip min/avg/max = 0.0/0.0/0.0 ms

    ===========================================================================

    also note that the packets with ttl 7 still come back with TARGET IP,
    implying that remote system is spoofing the IP. Even the difference in
    ttl and IPID of incoming packets indicates different systems are sending
    the response.

    My questions:
    a) any idea what kind of filtering system can this be
    b) is it possible to determine the IP of the 7th HOP.

    The nature of the service i am testing requires users to connect using a
    client certificate. I connect to port 2443 using stunnel and the client
    certificate supplied to me for the test. Now i send a GET / HTTP/1.0
    request. The response that comes back is HTTP 403 and the server string
    is "Apache-Coyote/1.1" .... in contradiction to what nmap detected as a
    service. Any clues as to what is *Really* running on port 2443. Amap
    returns nothing :(

    TIA

    cheers,

    -- 
    shashank
    <--
    Here is the Packet that was fragmented and has been assembled again.
                                           (with apologies to JRR Tolkien :)
    -->
    ------------------------------------------------------------------------------
    Ethical Hacking at the InfoSec Institute. All of our class sizes are
    guaranteed to be 12 students or less to facilitate one-on-one interaction
    with one of our expert instructors. Check out our Advanced Hacking course,
    learn to write exploits and attack security infrastructure. Attend a course
    taught by an expert instructor with years of in-the-field pen testing
    experience in our state of the art hacking lab. Master the skills of an
    Ethical Hacker to better assess the security of your organization.
    http://www.infosecinstitute.com/courses/ethical_hacking_training.html
    -------------------------------------------------------------------------------
    

  • Next message: Anders Thulin: "Re: Web Application Tester"

    Relevant Pages

    • Re: Logs: Many hits with source port of 80
      ... The hits from source port 80 to dest port 37852 are IMHO almost ... you should probably see a couple other packets - perhaps ... packets if either you send the load balancer a packet, ... >>I have seen similar hits for the past three months. ...
      (Incidents)
    • Re: Error 720 connecting to server via VPN
      ... By default the router's firewall is configured to drop ICMP packets ... Select WAN Setup> Advanced> Respond to Ping on Internet Port. ... server and the Internet allow GRE packets. ... routers on the user's network are also configured to allow GRE packets. ...
      (microsoft.public.windows.server.sbs)
    • tcp oddities.
      ... After syn-scanning an IP block, ... suprise there was an smtp server sitting on port 25. ... 1353 packets received by filter ... Ethical Hacking at the InfoSec Institute. ...
      (Pen-Test)
    • Re: What does a firewall do?
      ... Forward packets not for H, ... > to node Y (from port P to port Q?) and a reject comes back to H, ... >> Firewalls also provide very good logging capabilities these days, ... >> firewalling appliances inside the network stack. ...
      (comp.security.firewalls)
    • RE: Vexing IPF problem
      ... There are a lot of spoof packets using port 80 on the public ... I'm having a problem with IPF blocking packets that appear should be ... pass in log first proto tcp from any to any port = 80 flags S keep ...
      (freebsd-questions)