A packet forensics challenge - Page 3
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 38

Thread: A packet forensics challenge

  1. #21
    Senior Member
    Join Date
    Jan 2002
    Posts
    458
    Perhaps you need to read the man pages for TCPdump...or better yet, let me post it here for you:

    -----------------------------------------------------
    IP Fragmentation

    Fragmented Internet datagrams are printed as
    (frag id:size@offset+)
    (frag id:size@offset)
    (The first form indicates there are more fragments. The
    second indicates this is the last fragment.)
    -----------------------------------------------

    Nowhere in your trace does this appear. Not to metion the full TCP header would not appear in every datagram if the packet was fragmented. You would see an output like this:

    arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
    arizona > rtsg: (frag 595a:204@328)
    rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

    just because the DF bit is not set doesn't mean that the packet is automatically fragmented. It is just set when the packet is absolutely NOT fragmented.

    Also, since you know alot about TCP/IP, you should know that the SYN bit is also set in the first step of the TCP three-way handshake. Therefore this would be the expected output from a user running a TCP-connect scan. (which happens to be the default for nmap), and again reinforces my position that the attacker was most likely NOT very knowledgeable.

    Also, I am trying to continue to provide informative responses based on the facts at hand. I don't think it is appropriate to attemt to try to degrade me by telling me I know know what I am doing. I have LOTS of experience (none of which I need to get into specifically), you should be able to tell based on my posts. I am not perfect and I will be the first to admit it. The goal here is for everybody to learn and comments like that are very conter-productive. If I do make a mistake, I would appreciate you come forward like a man and tell me I am wrong and why, so I can learn from my mistakes.

    If you find something on this, I would appreciate that you post links or something with factual evidence, instead of telling me to go read a book.

    Enough Said......

  2. #22
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    just because the DF bit is not set doesn't mean that the packet is automatically fragmented. It is just set when the packet is absolutely NOT fragmented.

    Yup, agreed

    Also, since you know alot about TCP/IP, you should know that the SYN bit is also set in the first step of the TCP three-way handshake. Therefore this would be the expected output from a user running a TCP-connect scan. (which happens to be the default for nmap), and again reinforces my position that the attacker was most likely NOT very knowledgeable.

    Here we disagree, do you think it more steatly or productive to run a syn/fin scan, a null scan
    and so on? Each scan performs differing things ie: simple scan, inverse mapping,...
    Does not mean your an amateur for using a syn scan.

    If you find something on this, I would appreciate that you post links or something with factual evidence, instead of telling me to go read a book.

    Well I am sorry you took my post to be offensive or degrading. It was not meant as such.

    -----------------------------------------------------
    IP Fragmentation

    Fragmented Internet datagrams are printed as
    (frag id:size@offset+)
    (frag id:size@offset)
    (The first form indicates there are more fragments. The
    second indicates this is the last fragment.)
    -----------------------------------------------
    You are correct on the above, my mistake. A rather egregious one at that. Oh well I posted too
    quickly. The rest of my post stands for itself though. As for reading a book that was simple advice. As I have been told before one should not be so thin skinned. I have re-read my post
    and saw nothing offensive or degrading in it. If you did however read my comments a para or
    two above.

    02:07:15.196281 xxx.xxx.xxx.xxx.50464 > xxx.xxx.xxx.xxx.929: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20442, len 40)
    0x0000 4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
    0x0010 xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
    0x0020 5002 1000 53d9 0000 0233 3503 3xxx P...S....35.11

    02:07:15.196486 xxx.xxx.xxx xxx.50464 > xxx.xxx.xxx.xxx.829: S [tcp sum ok] 878999699:878999699(0) win 4096 (ttl 41, id 20443, len 40)
    0x0000 4500 0028 4fdb 0000 2906 6ba5 xxxx xxxx E..(O...).k..r@J
    0x0010 xxxx xxxx c520 033d 3464 7893 0000 0000 .......=4dx.....
    0x0020 5002 1000 543d 0000 0233 3503 3xxx P...T=...35.11

    Also check out the above, note the tcp sequence numbers. There are all the same for 10
    packets in a row. Then they change. The time hacks are different as well for each packet
    which again supports my theory of packet fragmentation. As well because each Ip Id number
    differs as well in each packet. Do you see what I mean now. I knew there was a reason why
    I claimed packet fragmentation. Now there you have my reasons why.

  3. #23
    Senior Member
    Join Date
    Jan 2002
    Posts
    458
    I apologize for the misunderstanding of the intention of your post.

    So, lets get back to the fun stuff....

    When I think about this, I don't think it is possible to tell of this is a SYN scan or a full TCP connect scan. A SYN scan would send a SYN packet, and wait for a SYN-ACK from the target host, and the end the session, therefore only completing two of the three steps in the handshake, a tcp-connect obviously completes all three steps. Since the target never replies back with a SYN-ACK, can we really determine conclusively?

    I do understand your point that the sequence number is static for a period of time, but I don't think this means that the packet is fragmented. If it was it would have a frag offset as in the example i posted earlier.

    I will do some more research on this and let you know what I find, please do the same in case you are a better googler than I am

    BTW...I am sure you have already done this, but in case you haven't and for the sake of others who may be interested, check out http://project.honeynet.org/scans and check out the "scan of the month" section.

    I also just bought the book "Honeypots" by Lance Spitzner, so when I get done with it, I will let you know how it is (Unless you already read it)

    Oh yeah, also what do you mean by "time hacks"?

  4. #24
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    I apologize for the misunderstanding of the intention of your post.

    No problemo!

    So, lets get back to the fun stuff....

    Sounds good!

    When I think about this, I don't think it is possible to tell of this is a SYN scan or a full TCP connect scan. A SYN scan would send a SYN packet, and wait for a SYN-ACK from the target host, and the end the session, therefore only completing two of the three steps in the handshake, a tcp-connect obviously completes all three steps. Since the target never replies back with a SYN-ACK, can we really determine conclusively?

    I should of been more verbose in my post. I should of said that this was all the packets exchanged in the trace between the parties involved. What I infer from the lack of syn/ack's
    is that the packets were just dropped by the recieving end.

    I do understand your point that the sequence number is static for a period of time, but I don't think this means that the packet is fragmented. If it was it would have a frag offset as in the example i posted earlier.

    This in my mind implies a tcp sequence number attack or a new? form of fragmentation. It is
    possible I think that it could slip by undetected. Can't say for sure though just a theory. There
    are always new ways to break the stack out there. This may be one of em.

    I will do some more research on this and let you know what I find, please do the same in case you are a better googler than I am

    Roger that

    BTW...I am sure you have already done this, but in case you haven't and for the sake of others who may be interested, check out http://project.honeynet.org/scans and check out the "scan of the month" section.

    Yup been there. Too busy right now though to get into a scan. Too much on my plate. I do
    plan on doing it more religiously though in the upcoming months in preparation for my sans
    track.

    I also just bought the book "Honeypots" by Lance Spitzner, so when I get done with it, I will let you know how it is (Unless you already read it)

    I have not read it, give me your thoughts when done.

    Oh yeah, also what do you mean by "time hacks"?

    My own lingo, I mean that the time is different for each packet. I just call the time itself a time
    hack. That's all.

  5. #25
    Senior Member
    Join Date
    Jan 2002
    Posts
    458
    The time for each packet will be different as a timestamp is appended to each datagram as it is sent. Since they can't all be sent at once, this is normal, or is that what you meant?

  6. #26
    Senior Member
    Join Date
    Dec 2002
    Posts
    110
    That is what I meant.

  7. #27
    Junior Member
    Join Date
    Feb 2003
    Posts
    15
    My 2 cents .....

    My first look at the packet capture doesn't support fragmentation. ( I performed a translation of the hex dump provided)


    First, there is no fragmentation offset in any of the packets displayed. Also the fragmentation ID changes for each packet (Fragments of the same datagram have the same Frag ID to aid in reassembly). The "0" bit that is set in the DF field tells all the network devices that this packet may be fragmented if needed.

    By the way this is a great thread.
    Ferengi Rules of Acquisition:

    Rule 59 Free advice is seldom cheap.

  8. #28
    Member
    Join Date
    Dec 2001
    Posts
    35
    Guys, I apologize for jumping in at the last minute, but this is an awesome post. Im just trying to learn how to get into forensics, and Im learning a great deal. I started by looking at dons post and came up with a port scan but the target is behind a firewall or has iptables set to reject or drop incoming.
    You mentioned using TCPDUMP for hex translation. I know that tcpdump is a *nix based program. I may be mistaken but I thought u said that the computer was a winnt or 2k.
    Obake: how did u do the hex translation?
    thanx guys and I hope to start postin here more often.
    10Ded
    [glowpurple]www.networksynapse.net[/glowpurple]

  9. #29
    Senior Member
    Join Date
    Mar 2002
    Posts
    425
    First things first... Lets take apart a single packet to see what it tells us:

    Code:
    4500 0028 4fda 0000 2906 6ba6 xxxx xxxx E..(O...).k..r@J
    xxxx xxxx c520 03a1 3464 7893 0000 0000 ........4dx.....
    5002 1000 53d9 0000 0233 3503 3xxx      P...S....35.11
    For those who don't know, a byte is represented by two hexadecimal number, so each block of four characters in the packet shown above represents two bytes.

    *** IP HEADER ***
    The very first byte is '45' which means that the packet is IPv4 and the ip headers is 5 32-bit words long (20 bytes long).

    The next byte is the TOS, which is 0. No surprise there. TOS isn't used for much these days.

    The next two bytes '0028' represent the length of the total packet. By doing the hexadecimal math, we see that the entire packet is 40 bytes long. That's pretty standard for a SYN packet.

    The next two bytes '4fda' represent the ID field. This field is most often used to assist in the reconstruction of fragmented packets. Nothing unusual for this one, but we'll take a look later to see if the pattern of ID fields is important.

    Next are the fragmentation flags and offsets '0000'. None of the fragmentation flags are set, so this packet isn't fragmented, nor does the source care whether the packets are fragmented along the way.

    The next byte is '29' which means the packet has a TTL of 41. This may be useful later for OS detection since TTL values vary widely among OS's. 64 is common is used in by linux, BSD, AIX and possibly some others, but it isn't a TTL you usally see from a windows OS.

    The next byte '06' corresponds to protocol 6, which is TCP.

    The next two bytes '6ba6' are the IP checksum. This is calculated by looking at the header as a series of 16-bit chunks. You simply add up all of the 16-bit chunks and then take the one's complement of the number. Since we don't have the IP's, we can't determine if the checksum is correct, so we'll assume that it is.

    The next blocks (xxxx xxxx xxxx xxxx) represent the source and destination IP addresses and then we're done with the IP header. If there had been any IP options, they would have been right after the addresses, but we saw earlier that the IP header was 20 bytes long, so there's no room for IP options.

    By the way don, if you really want to hide the IP addresses, you should have removed the r@J and replaced them with periods before posting them, because we cans still tell what part of the source IP address was.

    *** TCP HEADER ***
    The first two bytes represent the source port (50464) and the next two represent the destination port (929). These are uninteresting from a single packet standpoint.

    Next is the four byte sequence number, which is again, uninteresting from a single packet perspective.

    Next is the four byte acknowledgement number, which is 0 because this is the first packet of the attempted connection and therefore the system doesn't have any previous packets to acknowledge.

    The next four bits '5' represent the length of the TCP header, which like the IP header is 5 32-bit words long, or 20 bytes long.

    The next four bits '0' don't really mean anything since the block of bits is reserved for later use by the creators of the TCP header.

    The next 8 bits represent the congestion flags and the TCP flags. Since the value is '02', it represents no congestion flags set, and only the TCP SYN flag set.

    The next two bytes represent the TCP windows size. The '1000' in this packet represents a window of 4096. This is unusual, since I've never seen a value of 4096 before. I went to check the OS signatures list at the honeynet project and they didn't have any OS's listed with that window size either It's possible that these packets were crafted by a tool instead of being generated by the OS, or it's also possible that someone modified their kernel or edited their registry to change the defaults for this value. At any rate, it's going to make OS detection harder.

    The next two bytes '53d9' are the TCP checksum, which are calculated similarly to the IP checksum above.

    The next two bytes '0000' are the urgent pointer, and since they're set to zero, they're boring.

    *** Extra stuff ***
    The extra bytes '0233 3503 3xxx' on the end of this packet are unusual. They could be related to the recent discovery of ethernet interfaces leaking excess info, or they could be cause by the way that tcpdump stores packet information, or if the packets are indeed crafted, they could be an artifact of poor programming.

    I was also confused about the '3xxx' and the '0xxx' in later packets. Were those an artifact of the way you replaced the Ip addresses? As best I can tell, I think they should have been '3131' and '0131' to correspond to the '11' and '.1' in ascii out to the right.

    *** Patterns ***
    The packets can obviously be grouped into three groupd based on source port. Each group scans 10 tcp ports (929, 829, 368, 1506, 521, 795, 192, 386, 703, 1541) and then moves on.

    The ID field obviously increments by 1 per packet, both within the groups and across groups.

    The sequence number is identical within the group but changes radically between groups, which is another clue that points towards crafted packets.

    I can't find a common link between the ports scanned, but I'll keep looking.

  10. #30
    Junior Member
    Join Date
    Feb 2003
    Posts
    15
    10dedfish

    TCPdump has a brother called Windump which runs on Windows systems or you can simply move the dump to a *nix system. However, I didn't go back thru the tread to check how he got the dump.

    To "translate" a packet you just need the correct RFC ( or any document which shows the packet's layout) a little knowledge of the protocols and how to convert hex into dec. and bin. numbers. I use the rfcs, but you can get a book called TCP/IP illustrated which can help you in learning how to do packet analysis. You might also want to pick up another freebie called Ethereal, which is a GUI network sniffer that runs on Linux and Windows.
    Ferengi Rules of Acquisition:

    Rule 59 Free advice is seldom cheap.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •