I need some help understanding this code...

trist007 · 03-21-2009, 02:50 PM

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
connect=s.connect(('192.168.9.85',21))
s.recv(1024)
s.send('USER ftp\r\n')
s.recv(1024)
s.send('PASS ftp\r\n')
s.recv(1024)
s.send(command+' '+string+'\r\n')
s.recv(1024)
s.send('QUIT) ftp\r\n')
s.close()

I know the first line makes a socket, but what is socket.AF_INET and socket.SOCK_STREAM?

I understand the USER, PASS, and QUIT, but what are s.recv(1024) for?

paulsm4 · 03-21-2009, 03:13 PM

Hi -

Code:

  ' Open a socket 
  ' "SOCK_STREAM" == TCP streams; "SOCK_DGRAM" would be UDP a datagram
  s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
  
  ' Connect to host 192.168.9.85 (this is an internal address; it cannot be accessed from an outside network)
  ' TCP port #21 is FTP (File Transfer Protocol)
  connect=s.connect(('192.168.9.85',21))

  ' Receive upto 1024 bytes of arbitrary data from server
  s.recv(1024)

  ' Send the text string "USER ftp", with a CRLF delimiter, to server, and then try to read up to 1024 bytes back
  s.send('USER ftp\r\n')
  s.recv(1024)

  ' Send "PASS ftp, CRLF" to server, and read another response
  s.send('PASS ftp\r\n')
  s.recv(1024)

  ' Send some string contained in variable "command"
  s.send(command+' '+string+'\r\n')
  s.recv(1024)

  ' Send the string "QUIT) ftp, CRLF"
  s.send('QUIT) ftp\r\n')

  ' Hang up and go home
  s.close()

I'm not sure any of this is "real code", and I'm not it will actually work. But (at least as pseudo-code), the intent is clear.

'Hope that helps .. PSM

Maligree · 03-21-2009, 03:13 PM

socket.SOCK_STREAM makes your socket a TCP socket. The other option is SOCK_DGRAM, for creating UDP sockets - they both have their own uses, but in short, TCP is used when your connection has to be reliable (all data transmission is controlled (Transmission Control Protocol), any packets gone missing are reported and retransmitted. UDP does not do anything like this. To quote some source I cannot remember right now, UDP is fine for "short shouts", while TCP is for longer conversations.

recv(1024) - reads data from socket (in this case as much as 1024 bytes). Normally you'd store the data somewhere (e.g. data=s.recv(1024)) but here it seems the code is just taken from the buffer and discarded (the script continues its sending without looking at what the other side is responding with, not the best way)

AF_INET - I can't really explain this one. It's something I have always considered a brainless constant - I've never used anything other than AF_INET. Perhaps someone else could give some info on this.

The_Kernel · 03-21-2009, 05:10 PM

Quote:

Originally Posted by Maligree

AF_INET - I can't really explain this one. It's something I have always considered a brainless constant - I've never used anything other than AF_INET. Perhaps someone else could give some info on this.

AF_INET is a network socket. There is also AF_UNIX which creates a unix socket. See http://en.wikipedia.org/wiki/Unix_domain_sockets for more info.

paulsm4 · 03-21-2009, 08:48 PM

Hi -

Actually, it says something that things have changed so much that you might think that TCP/IP is only only game in town:

Quote:

AF_INET - I can't really explain this one. It's something I have always considered a brainless constant - I've never used anything other than AF_INET. Perhaps someone else could give some info on this.

When Bill Joy invented sockets (during his student days at UC Berkeley), TCP/IP was still in relative infancy - and it was just one of many (mostly better-known and more widely used) network protocols. "Sockets" were intended to be a programming abstraction on top of *any* network protocol or address family, *including* (but not limited to) TCP/IP addresses.

Today, TCP/IP has pretty much taken over most of the network world, and the "address families" you're most likely to see are:

- "AF_INET" (TCP/IP v4),

- "AF_INET6" (TCP/IP v6), and

- "AF_UNIX" (on many - but certainly not all - platforms).

Here's a link that explains a bit more:
http://publib.boulder.ibm.com/infoce...cpx01/oaws.htm

Just for grins, you might enjoy looking at some of the "address families" listed in MSVC's "winsock.h":

Code:

/*
 * Address families.
 */
#define AF_UNSPEC       0               /* unspecified */
#define AF_UNIX         1               /* local to host (pipes, portals) */
#define AF_INET         2               /* internetwork: UDP, TCP, etc. */
#define AF_IMPLINK      3               /* arpanet imp addresses */
#define AF_PUP          4               /* pup protocols: e.g. BSP */
#define AF_CHAOS        5               /* mit CHAOS protocols */
#define AF_IPX          6               /* IPX and SPX */
#define AF_NS           6               /* XEROX NS protocols */
#define AF_ISO          7               /* ISO protocols */
#define AF_OSI          AF_ISO          /* OSI is ISO */
#define AF_ECMA         8               /* european computer manufacturers */
#define AF_DATAKIT      9               /* datakit protocols */
#define AF_CCITT        10              /* CCITT protocols, X.25 etc */
#define AF_SNA          11              /* IBM SNA */
#define AF_DECnet       12              /* DECnet */
#define AF_DLI          13              /* Direct data link interface */
#define AF_LAT          14              /* LAT */
#define AF_HYLINK       15              /* NSC Hyperchannel */
#define AF_APPLETALK    16              /* AppleTalk */
#define AF_NETBIOS      17              /* NetBios-style addresses */
#define AF_VOICEVIEW    18              /* VoiceView */
#define AF_FIREFOX      19              /* FireFox */
#define AF_UNKNOWN1     20              /* Somebody is using this! */
#define AF_BAN          21              /* Banyan */

PS:
trist007 - is your question answered ;-)?

trist007 · 03-22-2009, 03:31 PM

If I'm pentesting a FTP program, what would be the significance of s.recv(1024)?

here is the whole code.

Code:

#!/usr/bin/env python

import socket

# Buffer array initialization

buffer=["A"]
counter=2
while len(buffer) <=30:
	buffer.append("A"*counter)
	counter=counter+100

commands=["MKD","GET","STOR"]
# needs extending

for command in commands:
	for string in buffer:
		print "Sending the "+command+" command with "+ str(len(string))+" bytes."
		s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
		connect=s.connect(('192.168.9.85',21))
		s.recv(1024)
		s.send('USER ftp\r\n')
		s.recv(1024)
		s.send('PASS ftp\r\n')
		s.recv(1024)
		s.send(command+' '+string+'\r\n')
		s.recv(1024)
		s.send('QUIT) ftp\r\n')
		s.close()

When I execute the program, my FTP program crashes at a certain point. Now, if I comment out the s.recv(1024) lines, I can still crash the program. So why even include s.recv(1024) in the program for the purpose of pentesting?

ta0kira · 03-22-2009, 04:14 PM

Quote:

Originally Posted by paulsm4

- "AF_UNIX" (on many - but certainly not all - platforms).

As far as I know, AF_LOCAL is the POSIX name for this one, but I don't think it really matters.
Kevin Barry

paulsm4 · 03-22-2009, 05:15 PM

Hi, Trist007 -

1. Q: what are s.recv(1024) for?

A: Because the FTP protocol requires that the server send a response to each request the client makes, and the client needs to read that response (even, in this case, if it doesn't actually do anything with it) before the dialog can move on to the next client request.

2. Q: Why does my FTP program crash at a certain point.

A: You already know that it (probably) has nothing to do with the "recv()".

Do you know *where* it's crashing?

If not, have you tried pdb (or some other tool - even "print") to isolate the point where it crashes?

3. Q: What exactly is the "FTP protocol":

A: Here are a few links that explain (probably in more detail than you ever wanted to know), what your Python "send()" and "recv()" lines are actually doing:

http://en.wikipedia.org/wiki/File_Transfer_Protocol
http://www.eventhelix.com/Realtimema...orking/FTP.pdf
http://tools.ietf.org/html/rfc959

'Hope that helps .. PSM

PS:
Here's a newer, Winsock2 version of sockets "address families" (AF_INET6 makes an appearance):

Code:

/*
 * Address families.
 */
#define AF_UNSPEC       0               /* unspecified */
#define AF_UNIX         1               /* local to host (pipes, portals) */
#define AF_INET         2               /* internetwork: UDP, TCP, etc. */
#define AF_IMPLINK      3               /* arpanet imp addresses */
#define AF_PUP          4               /* pup protocols: e.g. BSP */
#define AF_CHAOS        5               /* mit CHAOS protocols */
#define AF_NS           6               /* XEROX NS protocols */
#define AF_IPX          AF_NS           /* IPX protocols: IPX, SPX, etc. */
#define AF_ISO          7               /* ISO protocols */
#define AF_OSI          AF_ISO          /* OSI is ISO */
#define AF_ECMA         8               /* european computer manufacturers */
#define AF_DATAKIT      9               /* datakit protocols */
#define AF_CCITT        10              /* CCITT protocols, X.25 etc */
#define AF_SNA          11              /* IBM SNA */
#define AF_DECnet       12              /* DECnet */
#define AF_DLI          13              /* Direct data link interface */
#define AF_LAT          14              /* LAT */
#define AF_HYLINK       15              /* NSC Hyperchannel */
#define AF_APPLETALK    16              /* AppleTalk */
#define AF_NETBIOS      17              /* NetBios-style addresses */
#define AF_VOICEVIEW    18              /* VoiceView */
#define AF_FIREFOX      19              /* Protocols from Firefox */
#define AF_UNKNOWN1     20              /* Somebody is using this! */
#define AF_BAN          21              /* Banyan */
#define AF_ATM          22              /* Native ATM Services */
#define AF_INET6        23              /* Internetwork Version 6 */
#define AF_CLUSTER      24              /* Microsoft Wolfpack */
#define AF_12844        25              /* IEEE 1284.4 WG AF */
#define AF_IRDA         26              /* IrDA */
#define AF_NETDES       28              /* Network Designers OSI & gateway
                                           enabled protocols */
#define AF_TCNPROCESS   29
#define AF_TCNMESSAGE   30
#define AF_ICLFXBM      31

#define AF_MAX          32

trist007 · 03-22-2009, 08:22 PM

Great stuff, thanks guys.

Biddle · 03-24-2009, 07:54 AM

Quote:

AF_INET - I can't really explain this one. It's something I have always considered a brainless constant - I've never used anything other than AF_INET. Perhaps someone else could give some info on this.

AF_INET is not the correct constant to be using here. The AF stands for address family which you can even see by the source posted by paulsm4. Whilst it will in many many instances give you the correct value, there is the possibility it could be incorrect( I am nit picking). The correct constant to use is PF_INET where PF stands for protocol family.

sundialsvcs · 03-24-2009, 12:41 PM

Documentation files such as man recv can be very informative ... and the command apropos can be helpful to find topics that you didn't know to look for.

Even in higher-level languages, most of these function libraries are just "wrappers" for the underlying C/C++ libraries in which the language has been implemented. Constants, such as AF_INET, are placed into namespaces (such as "socket." in this case) to avoid conflicts. Therefore it is usually a reasonable guess that the Unix man-page documentation will be directly relevant in answering your questions.

ta0kira · 03-24-2009, 06:27 PM

Quote:

Originally Posted by Biddle

AF_INET is not the correct constant to be using here. The AF stands for address family which you can even see by the source posted by paulsm4. Whilst it will in many many instances give you the correct value, there is the possibility it could be incorrect( I am nit picking). The correct constant to use is PF_INET where PF stands for protocol family.

Good catch. I didn't notice that. However, the code doesn't use C directly so the underlying logic (if there is any) might be implemented in a strange way. The value of AF_INET is used to specify what type of address is contained in the struct sockaddr, so whatever gears turn behind that code probably use a switch case statement to create the socket and use the provided AF_* for the connection or binding.
Kevin Barry