UGN Security Forums UGN Security: Underground General Mixed data in spoofed packets

Say someone was going to use a program like Netwox to spoof a DNS reply packet. Also say that they were going to make it a UDP packet. Now how would one figure out exactly what to put as the mixed data? I understand that, with Netwox, the mixed data is inputted as hex values, but how do you determine what to put?

I don't exactly know what you mean by mixed data, which may be a lack of knowledge on my part, but to easily spoof DNS replies where presented with a MITM situation, you could use Cain .

I downloaded that Cain & Abel, and it would allow me to do what I want, except of course that it would require a MITM situation like you said since it modifies the packets going to the victim. I don't really know a lot about MITM attacks, but from what I have read it seems like it is usually difficult to get into a situation like that what with encryption and key exchanges and crap.

The reason I wanted to generate DNS replies with Netwox is because you don't have to be in a MITM situation since you are creating your own packets. From what I've read, you can easily fool a Windows machine into accepting your DNS reply packets as long as it receives the packet before the actual DNS server's reply comes in, and as long as the destination port number and transaction ID are correct. Therefore you continually send spoofed DNS replies to your victim with incrementing transaction IDs in a reasonable range until you get lucky.

But like I said, Netwox requires you to give it the raw data that the packet should contain in hex format, and I don't know how I'm supposed to determine what to put. Does anyone know another program that creates packets but generates the mixed data itself?

f you want to understand how a protocol works you read the RFC.

http://www.faqs.org/rfcs/rfc1035.html

I beleive section 4 is the information you are after.

Enjoy

A MITM attack can only be achieved with Cain when you are on the same subnet as the victim. The reason being, it uses ARP Poison Routing to achive MITM, and ARP packets can not be sent outside of the current subnet. But if you are on the same subnet as the victim, this would be far easier than any guess work that may be needed with Netwox. Cain does a real good job of doing most of the work for you. All you really need to be able to do is identify your victim and the network gateway, and you're set.

Hmmm... well this says there are 4 sections in the DNS reply: the header, the answer, the authority, and additional information. Then it specifies what each bit is... so do you think the "mixed data" that Netwox requires is the bits in those 4 sections in hexadecimal?

I still don't have a clue about what you mean about mixed data. Where did you read/hear this and can you show me an example?

Here, I uploaded the help file for Netwox's IP4 packet spoofing tool to my Geocities account: http://www.geocities.com/ryoshenron/38.html

If you look at the list of parameters, one of them is --ip4-data which it states is for "mixed data". In this one article about spoofing DNS replies, the following example was shown:

netwox 38 --ip4-src 10.10.10.1 --ip4-dst 192.168.1.1 --ip4-protocol 17
--ip4-data 008904020044000000038580000000010000000020464845504643454c4548464345504646464143 4143414341434143414341424c0000010001000151800004c0a8014d

That's how I know that the mixed data is supposed to be hex numbers.

http://www.freesoft.org/CIE/Course/Section3/7.htm

The only thing I can come up with is it's the padding field.

Or...

It's just the data portion of the packet. If that's the case then you have to construct the DNS portion of the packet you want to send, convert it to hex, and then add that to the command you run.

Heh, have fun with that

The User Datagram Protocol (UDP), defined by IETF RFC768, provides a simple, but unreliable message service for transaction-oriented services. Each UDP header carries both a source port identifier and destination port identifier, allowing high-level protocols to target specific applications and services among hosts.

The UDP header structure is shown as follows
Source port
Source port is an optional field. When used, it indicates the port of the sending process and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted.

Destination port
Destination port has a meaning within the context of a particular Internet destination address.

Length
The length in octets of this user datagram, including this header and the data. The minimum value of the length is eight.

Checksum
The 16-bit one�s complement of the one�s complement sum of a pseudo header of information from the IP header, the UDP header and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets.

Data
UDP data field.

An octet is basicaly a byte.


from RFC
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc768.html
The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.

Destination Port has a meaning within the context of a particular
internet destination address.

Length is the length in octets of this user datagram including this
header and the data. (This means the minimum value of the length is
eight.)

Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data, padded with zero octets at the end (if necessary) to make a
multiple of two octets.

The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.


The UDP module must be able to determine the source and destination
internet addresses and the protocol field from the internet header. One
possible UDP/IP interface would return the whole internet datagram
including all of the internet header in response to a receive operation.
Such an interface would also allow the UDP to pass a full internet
datagram complete with header to the IP to send. The IP would verify
certain fields for consistency and compute the internet header checksum.

Protocol Application
--------------------

The major uses of this protocol is the Internet Name Server [3], and the
Trivial File Transfer [4].


After reading Protocols.com, and both RFC's I am going to make an educated guess and say mixed data is the user data portion of the packet.


For DNS RFC's
RFC1035 http://www.cis.ohio-state.edu/htbin/rfc/rfc1035.html
RFC1706 http://www.cis.ohio-state.edu/htbin/rfc/rfc1706.html


also see
http://protocols.com/pbook/tcpip7.htm#DNS



In the image above, Level1 thru Level7 are in reffence to the OSI Model


You want to look into layer5 Session Layer.
You may find alternatives to what you are trying to do in the TCP/IP protocol stack with protocols using Layer 5 of the OSI model. I used to have a chart of all protocols and what layers they were on.

But from what you are doing, wouldn't it be easier to just poison thier browser so that when they typed in a domain name it went to http://www.your_spoof_site.com?

I think 'mixed' refers to binary and ascii which can both be presented in hex form.
You really can't do a mitm attack unless you are 'in the middle' of the connection some how. Either controlling DNS, which is why I see you want to spoof DNS requests, or on the subnet of one of the targets.
If you really want to try to spoof the DNS payloads to machines and try to get them to connect to yours I would use pacgen on linux to accomplish this.