Status report for ithilgore #15 of 16

[ithilgore <ithilgore.ryu.l () gmail com>]

Hello nmap-dev.

As I promised, the first RDP cracking attempt was successful! There are
still some final touches needed, but it is a fact that the RDP module can
now recognize a successful attempt from a failed one, at least against the
latest version of Windows XP (the only box I managed to test as of yet).
I still need to add iteration, which is now pretty easy (the tests were
made using a single pair of username/password each time). Most of the
annoying bugs, that halted further progress, were exterminated after some
thorough debugging took place during the last week.

Now let me give you a brief analysis of the bug squashing that almost
followed the Ninety-ninety rule [1] (a phenomenon which seems to be pretty
frequent in software development):

One of the most frustrating bugs and perhaps the most difficult to spot was
the resetting of our connection by the MS RDP server whenever a certain
flag that concerned bitmap compression (something we don't even care about)
in a certain packet was 0 instead of 1!
The solution was simple (flip that bit) but finding the bug was most of the
work: since no wireshark RDP dissector exists [2] ("The RDP dissector does
not yet exist. The TCP dissector decodes the headers and the rest is just
so much data."), I had to manually check and compare the raw hex data (byte
by byte) of a session of rdesktop with a session of Ncrack and note the
differences. Finally, the culprit bit was found and the problem was solved.

Another problem that needed careful attention and a lot of code rewriting
concerned the proper parsing of the RDP packets. Some background is first
needed: an RDP packet consists of the following layers:

-------TCP data-----
ISO header
MCS header
SEC header
RDP header
RDP sub_packet1
RDP sub_packet2
...
RDP sub_packetN
--------------------

As you can see, there are 4 different headers and an RDP packet may contain
more than 1 RDP sub_packets (which contain the actual RDP data). Apart from
the logic that is essential in looping through the potentially multiple RDP
sub_packets embedded in an RDP packet, there is also another corner-case:
The RDP server can send partial TCP segments (usually because many packets
are of over 4k length) that contain for example one full RDP packet (that
may contain one or more RDP sub_packets) and another which is a partial
one. This means that the TCP data contain more than one RDP packets, but
the last one will not be complete (more TCP segments will need to arrive
from the network to get the rest of the data for it).
The problem is that there is no way to tell Nsock to get an exact amount of
bytes from its buffers (this hasn't been implemented yet although a
proposal has been made for an abstraction layer by Venkat in last year's
GSoC: http://seclists.org/nmap-dev/2009/q3/600 .) This means that whenever
you issue a read call to Nsock, it will usually return the whole TCP data
which Ncrack will then have to manually buffer and parse in a logic that
can separate the RDP packets from each other, the RDP sub_packets from each
other, and leave the partial RDP packets unread until the rest of the TCP
data have arrived. The whole thing is getting even nastier because of
Ncrack's unavoidable event-driven programming (due to the use of Nsock for
socket handling).
Part of the solution was to extend the Buf class (which is based on
OpenSSH's buffer subsystem and which Ncrack uses for internal buffering)
for additional functionality where you can move the internal data pointer
as you move on reading the TCP data from the incoming data buffer, without
necessarily copying them anywhere. Of course, the whole solution was much
more complex but we would have to delve into too many details to document
it here.

Another problem with RDP is that there are no status codes. For example,
there is no 200 OK status code like in HTTP or in FTP, where you can parse
a certain number and then associate it with the equivalent RFC-specified
status. Hence, the only way to know if you have authenticated correctly is
by manually parsing the text messages that the RDP server returns in one of
the countless packets it spews at you after you complete the RDP handshake
phase (which as I have previously mentioned involves the the exchange of a
great *many* packets [3]). Most of the data that the RDP server sends
afterward, inevitably has to do with the graphical interface (polylines,
polygons, rectangles etc) which Ncrack has to ignore but will nevertheless
still have to parse up to a point since the text messages may be part of an
RDP sub_packet (along with all the above GUI-related data). This creates
the necessity for a tiny RDP fingerprinting system which can detect the
different text messages that each Windows version returns upon a successful
or failed authentication attempt. This is the reason why the current
version of the RDP module will only work against Windows XP and Win2.3k (I
haven't fingerprinted Vista or Win7 etc yet).



Accomplishments

* Conducted thorough debugging and fixed many bugs spread all over
  the RDP module code.

* Found and resolved issue where the connection was reset whenever a
  certain bitmpap-caching related flag was off instead of on.

* Solved the problem of parsing multiple RDP sub_packets.

* Resolved the issue of parsing partial RDP packets by
  working around the Nsock inefficiency on buffer abstraction.

* Added fingerprints for Windows XP and Windows 2003 Server.

* Added a lot of code for parsing 'orders' (the GUI-data which are ignored
  and the text messages which need to be checked extensively for
  authentication-related information)

* Added several comments to some important functions. More to be added
  soon.

* Set up some virtual machines with Windows Vista and Windows7 for adding
  more fingerprints.

* Worked on the username gathering project.


Priorities

* RDP code cleanup, final comments, more fingerprints and iteration logic.
* Continue working on username gathering project.


Regards,
ithilgore



[1]. https://secure.wikimedia.org/wikipedia/en/wiki/Ninety-ninety_rule

[2]. http://wiki.wireshark.org/RDP

[3]. http://msdn.microsoft.com/en-us/library/cc240452%28v=PROT.10%29.aspx

-- 
http://sock-raw.org
http://twitter.com/ithilgore
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/