Re: Remote Administrator 2.x: highly possible remote hole or back door

[Ari Gordon-Schlosberg <regs () nebcorp com>]

[mgotts () 2roads com]
> LordInfidel () directionweb com wrote on 02/18/2004 10:58:58 AM:
>
> > From reading the thread on famatech's site, this looks more like a weak
> > password issue, which is true of "ANY" piece of software
> > using simple password authentication.
>
> Actually, if you read the thread closely you will see that the attacks are 
> said to comprise a *single* password attempt. On the second connection 
> they were in. Tens of minutes pass between the two attempts. This behavior 
> is observed in more than one of the attacks.
>
> > Strong enough means absolutely nothing in the world of dictionary
> > attacks......
>
> No dictionary attack is being performed. The user claims that his logs 
> show that the server is being sent a single password-attempt string of 
> some kind, and on the next connection the attacker is in. I say 
> "password-attempt string" because it is quite probable that the Radmin 
> client is not being used for the initial. The exploit may be take 
> advantage of a flaw in the authentication system, or make use of a 
> discovered backdoor. Note that those who claim to have been hacked said 
> their logs show an initial attempt (probably automated) and then a single 
> successful login (no dictionary attack) 10-15 minutes later, presumably 
> after the attacker checked his scanner logs and found a vulnerable system.
>
> Additionally, there is a post from an anonymous user who claims to have 
> developed an attack against Radmin's built-in authentication scheme. 
> Although the posting could be complete BS, this person claims that the 
> vulnerability does not exist in Radmin's optional NT authentication 
> scheme. This same poster claims that is going to contact Radmin in a short 
> while with the details. Guess we'll see.

I've seen a similar bug in a product I once worked on:

There was as situation where authentication information was being sent to a
daemon in base64-encoded format.  Under normal operation, the system worked
fine.  The daemon would return 0 for user/pass combos that were valid or 1
for invalid combinations.   This result from the socket was passed through
stdlib's atoi() to convert it to an integer to do a compare.

However, if what you passed the daemon was an improperly-encoded string, it
would throw (and catch) an exception when it was decoding the password.
The exception handler would then spit out a multi-line HTML-formatted error
message to the client's socket.

The client, which was just sending the query and then reading a single line
of response, would read this HTML formatted text and pass it to atoi().
atoi(), not finding any integers in the string would return 0, signalling
to the client that it permission was granted.  This would persist until the
client hed read enough lines to actually be back to a proper failure.  I'm
not sure if would ever actually catch back up. (I just fixed the bug in our
source tree as soon as I found it and then notified the department head
that we had a major problem in our deployed (!) product).

So you'd send an improperly formatted string, which would fail for reasons
which I can no longer remember, but something like the next six requests
would be let through, no matter what they sent.

-- 
Ari Gordon-Schlosberg http://www.nebcorp.com/~regs/pgp for PGP public key