Re: Always practice safe software: a lesson from UnrealIRCd

[Ron <ron () skullsecurity net>]

On Sun, 13 Jun 2010 23:01:28 -0700 Fyodor <fyodor () insecure org> wrote:
> On Sun, Jun 13, 2010 at 11:37:02PM -0500, Ron wrote:
> > On Sun, 13 Jun 2010 16:32:24 -0500 Ron <ron () skullsecurity net>
> > wrote:
> >
> > I totally failed to get a Trojanned version of UnrealIRCd running on
> > Windows, and I don't know if any of the Windows binaries were even
> > affected, but the attached version should run on both Windows and
> > Linux.
>
> Hi Ron.  It is great to see you and Kost taking this on!
>
> I have read that the Windows binaries were not affected, but that was
> from a Slashdot comment rather than a known reliable source.  So it
> sounds like this level of testing is good enough for now, unless we
> find evidence that infected Windows Unreal installs are out in the
> wild.
Kost found a quote that it *isn't* vulnerable, but there's always the chance that somebody compiled it for Windows 
specifically with the Trojanned version. Not likely, but having the check doesn't hurt. 

> > It uses delays to check whether or not the command runs, since we
> > have no access to the output. It uses ping -n on Linux and ping -c
> > on Windows.
>
> Your earlier version used "sleep".  Given that you are separating
> suggested using sleep (e.g. "sleep 8") on Linux earlier.  Given that
> you need a different command on Windows anyway, why did you move away
> from using sleep there?
Mostly OCD -- I like the two commands to match. I have no issue going back to sleep() :)

> What is the purpose of:
>
>   local unique = "SOMETHINGUNIQUE"
>
> Maybe it could use a comment explaining it.
Sure, I can explain it better. 

The reason is because the server sends back data asynchronously, even if it hits the sleep or ping I send it. Adding 
SOMETHINGUNIQUE to the command means the server will echo SOMETHINGUNIQUE back and I can check for it. 

I originally considered using an actual random stream, then I realized it wasn't really worthwhile. :)

> > I opted for delaying 8 seconds by default -- Trojanned servers will
> > respond after 8 seconds, and non-Trojanned servers will respond
> > instantly. It's long enough to avoid false positives for slow
> > connections (no response should ever take 8 seconds), but short
> > enough that the user doesn't have to wait a long time.
>
> That sounds like a smart value.
>
> > Question: should I add a script-arg for running an arbitrary command
> > since we're able to? That's more of an attack tool, instead of a
> > scanner, and Metasploit already has that covered, but it'd be a
> > trivial addition.
>
> I think that is a good idea.  And I like the idea of documenting
> Kost's command for killing the server in the nsedoc.
I'll definitely re-introduce Kost's command, and also arbitrary commands. 

> I'm not sure if this script still needs to be "intrusive" or not.
> Clearly that was required when it would kill the server by default.
> But now it uses the least intrusive method we could find to check if
> the server contains the backdoor.  Nothing will happen for the vast
> majority of servers, and at worst we will run a simple sleep or
> localhost ping command if a machine is vulnerable.  And in that rare
> case, it provides extremely valuable information.  I don't think we
> should make this script "default", so someone will only get it if they
> specify it by name or by category anyway.
I don't think it has to be "intrusive", and I even leaned toward making it "default" because, in the vast majority of 
cases it isn't going to run. And the odd time it does run, it'll very likely find nothing and finish instantly. The 
rare time that it finds something, though, it's exceptionally useful. 

I'm ok with safe+vuln, though. 

> Cheers,
> -F
Thanks for the feedback!

-- 
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86

Attachment: _bin
Description:

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