Datagram analysis

[justjake]

Good Evening all!!!

I'm looking for a sample datagram that I can perform forensics on. I've done a google query and all I seen to find is TCP/IP packets and IP packets, but what I'm looking for is a packet that has been encapsulated down the protocol suite. I'm curious as to how the data is stored as each layer adds its routing information on to it. I'm a little skeptical on installing a packet sniffer on my machine as I usually don't trust software of that nature, but if anyone knows of a link out there that would have a simple datagram and analysis, I sure would appreciate the link. I'm hitting a wall on reading about header information and TOS and crc and the like. I'd like to see an actual complete datagram, even if the data in it is something as simple as a link to the site that hosts the datagram example.

Jake

[Red Squirrel]

You did say you did not want to install a packet sniffer but I will recomend one anyway. :P

Ethereal

It's free and open source, so you don't have to worry about spyware and such.

You do need to install winpccap which I believe is also open source (it's basically the "engine" behind the GUI).

If you're still not confident you could always do it in VMware. In fact, that's your best bet since you can install a firewall and limit traffic in order to only capture what you want (though ethereal has some filtering for that, as well)

[TheCotMan]

I'm looking for a sample datagram that I can perform forensics on. I've done a google query and all I seen to find is TCP/IP packets and IP packets, but what I'm looking for is a packet that has been encapsulated down the protocol suite. I'm curious as to how the data is stored as each layer adds its routing information on to it. I'm a little skeptical on installing a packet sniffer on my machine as I usually don't trust software of that nature, but if anyone knows of a link out there that would have a simple datagram and analysis, I sure would appreciate the link. I'm hitting a wall on reading about header information and TOS and crc and the like. I'd like to see an actual complete datagram, even if the data in it is something as simple as a link to the site that hosts the datagram example.

First, consider a better google search. Find an application that runs over UDP, and include that application name in your search. Here is an example:
Google: DNS UDP packet

I know there is at least one page out there that takes an entire telnet session from DNS Lookup through to SYN, SYN, ACK, and FIN to decompose and walk through many of the parts to each TCP and UDP packet.

Beyond this, go get yourself a copy of Ethereal, and have it capture while you perform DNS lookups. Ethereal's built-in packet analyzer can help you to see each field, its value, and convert HEX to ASCII as needed for better understanding.

[Added content:]
I see RedSquirrel has suggested Ethereal as well, but beat me to a response. Damn. I am getting slow. ;-)

[skroo]

You do need to install winpccap which I believe is also open source (it's basically the "engine" behind the GUI).

Ah, close, but not exactly. winpcap is a packet capture library, providing functionality in Windows that's not normally there. The actual filtering and dissection portions are provided by Ethereal directly, but are separate from winpcap. Ethereal's really the engine in this case, since it does the number-crunching; winpcap is more just a generic service.

If you're still not confident you could always do it in VMware. In fact, that's your best bet since you can install a firewall and limit traffic in order to only capture what you want (though ethereal has some filtering for that, as well)

VMware would be overkill in this case since he can do it natively - why boot an emulator to run a secondary OS when you can do it directly under Win32? It's not like he's grabbing executable data that could potentially be run, so there's no serious threat of his machine being overrun by something nasty he sniffed.

[d.fi]

Are you !*%# crazy?

Running Ethereal or tcpdump *is* reasonably dangerous. There are many published vulnerabilities in both Ethereal and tcpdump's protocol decoders. Because of these very issues, the OpenBSD port of tcpdump has gotten a bunch of privilege seperation work done to it, because no security people trust the protocol decoding at all.

Just read Steven's TCP/IP Illustrated Volume 1 book--almost all things TCP/IP will become quite clear

[TheCotMan]

Running Ethereal or tcpdump *is* reasonably dangerous. There are many published vulnerabilities in both Ethereal and tcpdump's protocol decoders. Because of these very issues, the OpenBSD port of tcpdump has gotten a bunch of privilege seperation work done to it, because no security people trust the protocol decoding at all.

Just read Steven's TCP/IP Illustrated Volume 1 book--almost all things TCP/IP will become quite clear

Having an OS that supports MAC and Type Enforcement with strong policies for EtherReal or tcpdump seems to work quite well.

[d.fi]

MAC and TE fall down

MAC and TE don't matter if there are exploitable kernel bug, which there are on all the OS we use Privilege seperation fails for the same reason. Please don't misunderstand me--MAC, TE and privsep are all good concepts (an similar in intent) for reducing the scope of a compromise, but they only *really* work it the underlying kernel is vulnerability free. It is better to not let an attacker get a foot-hold in the first place, which is rather hard to do given the state of software security at this point in time.

[skroo]

Running Ethereal or tcpdump *is* reasonably dangerous. There are many published vulnerabilities in both Ethereal and tcpdump's protocol decoders.

While I ultimately agree with you as far as good practices in handling are concerned, if we're talking about someone fooling around with sniffing the traffic on their home network they should be *reasonably* safe running it natively. From my reading, he didn't initially mention anything about a hostile network, and it seemed as though the VMware suggestion was made more from the standpoint of 'you have to run Ethereal under Linux' - i.e., evangelism complicating the issue. For someone just getting started with it and wanting something to play with, they may as well just run it under whatever platform is native for them.

And hey, if something malicious does bite them on the ass as a result... They've just learned a valuable lesson about acquiring and handling potentially-dangerous traffic.

[Red Squirrel]

So there's actually security issues in packet sniffers? In what sense exactly? Since it does not really open up any ports or anything as far as I know, but I guess I could see a buffer overflow, ex: malicious user sends packet, upon decoding, causes buffer overflow and executes some code. Never heard of it being done though.

I only mentioned VMware as the OP did not want to run it on his machine, but yeah in most cases that could be overkill.

[TheCotMan]

MAC and TE don't matter if there are exploitable kernel bug, which there are on all the OS we use Privilege seperation fails for the same reason.

Yes, but the kernel hole has to be known, and then exploitable from the privs of the user and role of the user using the application, and be able to bypass standard kernel features such as address randomization of functions, emrerging standard techniques of return address encryption, and decryption with eval before return, non-executable stack spaces, and a number of other techniques becoming standard in new kernels and mainstream distros.

Quite a lits of ever-growing (sometimes thinly) layered "armor" to increase the required level of sophistication for an attacker building an exploit and their attack.

Can it be done? There is risk of it. How does the chance of this risk measure against the cost of the data being protected?

That is up to the user.

So there's actually security issues in packet sniffers? In what sense exactly? Since it does not really open up any ports or anything as far as I know, but I guess I could see a buffer overflow, ex: malicious user sends packet, upon decoding, causes buffer overflow and executes some code. Never heard of it being done though.

I only mentioned VMware as the OP did not want to run it on his machine, but yeah in most cases that could be overkill.

Generally speaking, packet sniffers run as "root" in order to set interfaces to promiscuous mode, and/or gain "raw" access to a device. Any unchecked buffers in capture, or analysis can leads to code execution by the owner of the executable, with the privs at the time of the exploit.

However, with kernel enforced Non-executable stack spaces, and address randomization, these risks are minimized. Added to compiler addition of encrypted return addressed checked before return for functions, and randomization of function addresses, on top of TE with MAC, and the risks are minimized (at this time) to be reasonable enough for use on nearly any network.

And if you really want to go further than this, you can go with a RO boot media, for the OS and a noexec mount writable space for file storage.

However, at this point we are well beyond the point of reasonable caution. If there were hackers who could defeat all of the above, they are probably making more money than we might consider possible in tech, or doing things in their garage that should make us all worry.

[skroo]

I guess I could see a buffer overflow, ex: malicious user sends packet, upon decoding, causes buffer overflow and executes some code.

This is more or less how it would work.

Never heard of it being done though.

Check the last few years' worth of Bugtraq / Vulnwatch postings. I seem to remember at least a couple of PoCs making it out along with the advisories. But I also love to smoke crack on my lunch break, so don't take it at face value without research.

[d.fi]

Yes, but the kernel hole has to be known, and then exploitable from the privs of the user and role of the user using the application, and be able to bypass standard kernel features such as address randomization of functions, emrerging standard techniques of return address encryption, and decryption with eval before return, non-executable stack spaces, and a number of other techniques becoming standard in new kernels and mainstream distros.

Saying the kernel vuln has to be known is irrelevant--vulnerabilities exist and we cannot presume the non-existance of that knowledge. The thing about most kernel vulnerabilities is that they are exploitable from any user context, given that in general the exploits are tickled through system calls that do not have restrictions on calling user context (minus ptrace and a few others).

Now for the "standard kernel features," which are not standard in *any* kernel other than OpenBSD's and RedHat's, but rather part of add-on patches like GrSecurity, I agree that they are generally effective at stopping memory manipulation-based attacks. I like them, and everybody else should too.

Quite a lits of ever-growing (sometimes thinly) layered "armor" to increase the required level of sophistication for an attacker building an exploit and their attack.

Can it be done? There is risk of it. How does the chance of this risk measure against the cost of the data being protected?

That is up to the user.

Turns out having access to a whole lot of computers (that were not doing anything worthwhile other than looking at pr0n) allows people to do really bad things, so I don't think the risk equation is just about the value of the data in individual systems. There are meta-threats that we as an industry have to account for.

Generally speaking, packet sniffers run as "root" in order to set interfaces to promiscuous mode, and/or gain "raw" access to a device. Any unchecked buffers in capture, or analysis can leads to code execution by the owner of the executable, with the privs at the time of the exploit.

However, with kernel enforced Non-executable stack spaces, and address randomization, these risks are minimized. Added to compiler addition of encrypted return addressed checked before return for functions, and randomization of function addresses, on top of TE with MAC, and the risks are minimized (at this time) to be reasonable enough for use on nearly any network.

And if you really want to go further than this, you can go with a RO boot media, for the OS and a noexec mount writable space for file storage.

However, at this point we are well beyond the point of reasonable caution. If there were hackers who could defeat all of the above, they are probably making more money than we might consider possible in tech, or doing things in their garage that should make us all worry.

Again, if every computer did indeed have these niffty protections, the world would be a better, safer place. Maybe someday it will apply to the 400,000,000 windows machines out there and not just the people running OpenBSD, RedHat Enterprise Linux v.4, Fedora Core 4, Gentoo with hardened sources and PIE/SSP applied, or one of the fringe hardened Linux distros with GrSecurity applied to it.

Wow, what a digression

[TheCotMan]

Saying the kernel vuln has to be known is irrelevant--vulnerabilities exist and we cannot presume the non-existance of that knowledge. The thing about most kernel vulnerabilities is that they are exploitable from any user context, given that in general the exploits are tickled through system calls that do not have restrictions on calling user context (minus ptrace and a few others).

This is a great point to make, and that is why I'm quoting it.

Now for the "standard kernel features," which are not standard in *any* kernel other than OpenBSD's and RedHat's, but rather part of add-on patches like GrSecurity, I agree that they are generally effective at stopping memory manipulation-based attacks. I like them, and everybody else should too.

One point of refinement on what was meant by "known."

"Known" was meant to mean that at least one person knows about it, vs "published" where the thing is known by many people. The idea of known vs. unknown, means that someone with the skill necessary to search for it, took the time to find it. In this way I was implying that a hole is generally known by someone before being exploited by someone.

Also, I elieve that SE Linux has made its way into debian unstable as a selection for installation. However, after having used it, its support is very poor when compared to RHEL 4 with SE enhancements.

Turns out having access to a whole lot of computers (that were not doing anything worthwhile other than looking at pr0n) allows people to do really bad things, so I don't think the risk equation is just about the value of the data in individual systems. There are meta-threats that we as an industry have to account for.

The scope of risk for the original point of discussion here was personal exposure as a result of and individual running Ethereal or tcpdump. Though it is possible to take a discussion in new directions, altering the scope of discussion changes the point of discussion to something different, and attempts to deflect the original discussion into another new discussion without resolution to the first points.

Again, if every computer did indeed have these niffty protections, the world would be a better, safer place. Maybe someday it will apply to the 400,000,000 windows machines out there and not just the people running OpenBSD, RedHat Enterprise Linux v.4, Fedora Core 4, Gentoo with hardened sources and PIE/SSP applied, or one of the fringe hardened Linux distros with GrSecurity applied to it.

Wow, what a digression

We often do not have many technical discussion here. This is a nice change of pace, I hope to see more of this in the future.

[justjake]

Good Evening all!!!

Thanks for all the suggestions!!! I did install Etheral on my machine. I am using a firewall both on my computer and have tried to the best of my ability to have a secure router. I am on the home network running my tests. I did a nslookup on a site of mine and just tried to gather some general information from it. I am reading TCP/IP Illustrated Volume 1, but at the same time struggling with ADD so I have to wallow through it..sigh... but being able to look at actual packets will make this easier.
Anyway, I am thankful for all those that replied, and I hope to continue to spark more positive threads like this one in my goal of attaining more knowledge and sharing what we have.

and as always... your milage may vary....

Jake

[justjake]

Good Morning all!!!!

So, in looking at dns packets, I'm starting to understand what they mean, but I have a question on why some values aren't being converted. For example,

00 09 43 09 5d 1c is the actual mac address,
but when converted to ascii, the address is
..C.].

So i see that that my 3rd and 5th byte can be converted to its ascii equivilant, but not the other bytes. Even though the 1st and 2nd bytes are different values, they are still represented as the same value of "." so how is there any discrimanation as to what each value means?
I imagine that there is a very simple answer for this such as "it just does, or its discarded, or the actual value in ascii doesn't really matter, as long as you have the actual mac address" which is fine, (and I'm thinking its probably the latter), and if that's the case, then I just move forward and continue the learning of packet analysis.
And on a side note, while talking with Mr. Google on various DNS sample packets, I did see some links pointing to crafting some malformed packets for crashing tcpdump and the like, so I'm glad I'm using a firewall and testing on my home network.

Jake