From: Eduardo Tongson <propolice@...>
Date: 2007-12-13T21:33:11+09:00
Subject: Re: Emulating Netcat and connecting to bind shells

My exploits are only for 'educational' purposes. I will look into
using raw sockets as you suggested. Thanks Douglas.

On Dec 11, 2007 2:40 AM, Douglas Wells <see@signature.invalid> wrote:
> In article <b18fbe3c0712100152y291f6a49t9f4f4b4434eaef5b@mail.gmail.com>,
>   Eduardo Tongson <propolice@gmail.com> writes:
> > Hello folks,
> >
> > I am creating some exploits written in Ruby.
>
> Hopefully those exploits are for good purposes, not bad.  In any
> case, your issues here are basic socket usage, so we'll address
> them anyways.
>
> >                                              Most of my payloads are
> > TCP bind shells, Netcat works well for connecting to those bind
> > shells. But I thought, why not connect to the shell directly from Ruby
> > immediately after sending the payload. Currently I use this snippet
> > from a Ruby standard library sample I found somewhere:
>
> You haven't given us any indication of what facilities of netcat
> you think are advantageous for your purposes, so I won't comment
> on that.  But, I will note that unless you're doing something much
> more complicated than talking to a shell, simple use of ruby sockets
> should suit your purposes.
>
> > s = TCPsocket.open(host,port)
> > STDOUT.flush
> > while gets(  )
> >   s.write($_)
> >   print(s.readline)
> > end
> > s.close
> >
> > Works, but is very limited compared to Netcat. Return only one line
> > (for example after an "ls"). One strange thing is that it hangs when I
> > send "cd /". No output and subsequent commands are not processed. "/"
> > and "cd" are OK.
>
> I'm not sure why you would only get one line from ls, but maybe
> that's part of your larger problem.  Let's look particularly at
> your complaint about "cd /".  The problem here is almost certainly
> that the prompt ($PS1 in Bourne-derived shells) is *not* sending
> a New-Line, but your use of s.readline requires a New-Line before
> it will return to you.  Thus, you're in deadlock situation.
>
> Fixing this can be done in various ways.
>
> First, you can just asynchronous stream the data in both directions.
> By this, I mean that you can just ignore the data coming from the
> remote shell and just send the data that you (a priori) know needs
> to be sent.
>
> If you do need to act based upon the returned data, you still have
> a couple of alternatives.  For any of this, however, I'd recommend
> that you switch to using the socket primitives directly and avoid
> the higher-level write/readline type of methods.  (See the ruby
> socket documentation on recv and send.)  It's not that you can't
> do the work from IO objects, just that things will be easier to
> understand and have less "magic" going on between you and the
> remote system.
>
> So, you could use a "go-ahead" mechanism.  (See the early telnet
> documents for a full explanation of this, e.g., RFC 854.)  For
> example, you could have the remote shell always send some token,
> say '@', when it's done.  Then you could wait for this before
> sending data.
>
> Beyond that level of solution, you probably need to run multiple
> threads in your client side, in a manner analogous to what you
> would do hen interacting with a local child process via the IO.popen
> method.  In this case you would have one thread examining data
> read from the remote shell and sending state change information
> to another thread, which would be sending the relevant data.  See
> examples for popen -- but remember that most examples of use of
> popen will not be handling the problem with the lack of a New-Line.
> You could also look at user-side telnet implementations, but here
> it will be difficult to see the strategy amongst all the details
> of character set translation and option negotiation.
>
>
> >                  Metasploit has its own library for this kind of
> > stuff. I think it is called Metasploit Rex. Looking at the sources I
> > see some references to Rex::IO::Stream. I find it complex and I would
> > like to avoid something that needs external libraries.
>
> Sorry, never had occasion to look at them.
>
> > Can the above snippet be improved? Is there a better way of emulating
> > Netcat? Is it possible to use Net::Telnet? Thanks everyone.
>
> See above.
>
> >    Eduardo Tongson
>
>  - dmw
>
> --
> .   Douglas Wells             .  Connection Technologies      .
> .   Internet:  -sp9804- -at - contek.com-                     .
>
>