Hi list, the box of a friend was hacked: /bin/ps /bin/login /bin/ls were replaced / trojaned. The original files were placed in /bin/bincp (which is not shown by ls, but cd into that dir works fine) Luckyly I found some source within a log of another machine. Comments show that there is an unsigned char shellcode[] = with some rows of "\x ...\x" numbers. I assume that there is the coding of a shell command. Unfortunately I do not know how to "read" the command. Translating the hex numbers into decimal and using an ASCII table does not give a usefull result. Any idea? Tips who to detect which root kit was used are welcome, too. TIA Frank
Frank Derichsweiler wrote:
Luckyly I found some source within a log of another machine. Comments show that there is an unsigned char shellcode[] = with some rows of "\x ...\x" numbers. I assume that there is the coding of a shell command. Unfortunately I do not know how to "read" the command. Translating the hex numbers into decimal and using an ASCII table does not give a usefull result. Any idea? yes, thats assembler! can you write a few lines of c code? then just write the content of "shellcode" into a file and use a disassembler (don't know any for linux - but this shouldn't be too hard to find :) Tips who to detect which root kit was used are welcome, too. sorry, no idea about this ...
greets Markus -- ________________________________________ Markus Gaugusch markus@gaugusch.dhs.org ICQ-ID: 11374583 [www.mirabilis.com]
Hi,
(don't know any for linux - but this shouldn't be too hard to find :)
Try biew or objdump -d... Bye, Thomas -- Thomas Biege, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg E@mail: thomas@suse.de Function: Security Support & Auditing "lynx -source http://www.suse.de/~thomas/thomas.pgp | pgp -fka" Key fingerprint = 09 48 F2 FD 81 F7 E7 98 6D C7 36 F1 96 6A 12 47
On Wed, Mar 22, 2000 at 14:02 +0100, Frank Derichsweiler wrote:
unsigned char shellcode[] =
with some rows of "\x ...\x" numbers. I assume that there is the coding of a shell command. Unfortunately I do not know how to "read" the command.
That's an array (read: data block) containing binary code (obj code in hex notation). You wouldn't like to read this as text just like the processor won't try to do :) Have a look at the toolbox on your computer's disk -- it's plenty of aiding stuff. rpm -ql binutils nm(1) and (more likely) objdump(1) should be your friends. And some literature on the processor's (i386?) internals. Read "man 1 objdump" and look out for the "disass" catch word. Maybe you want to consult somebody with programming skills (C and assembly). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
On 22 Mar 2000, at 21:11, Gerhard Sittig wrote:
That's an array (read: data block) containing binary code (obj code in hex notation). You wouldn't like to read this as text just like the processor won't try to do :) Have a look at the toolbox on your computer's disk -- it's plenty of aiding stuff.
rpm -ql binutils
nm(1) and (more likely) objdump(1) should be your friends. And some literature on the processor's (i386?) internals. Read "man 1 objdump" and look out for the "disass" catch word. Maybe you want to consult somebody with programming skills (C and assembly).
Hi, there is a freeware disassembler around that runs under Dos (freedos should work) to decode the array. One would defenitely need an experienced assembler programmer to understand the disassembled code anyway as the result should look somehow like cld push cx mov cx, 0FFFh mov al, 0 .... so nothing human readable. mike
On Wed, Mar 22, 2000 at 22:13 +0100, Thomas Michael Wanka wrote:
there is a freeware disassembler around that runs under Dos (freedos should work) to decode the array.
Speaking of DOS: Every version I know of (although being only the 4.0 through 6.2 lines of MS and DR's versions) came with a program called debug.exe. If one doesn't mind (e)ntering the data (maybe by means of a clipboard or selection tool when of the lazy kind) one can (u)nassemble any hex dump coming across. But then: debug.exe doesn't know about processors beyond 80286 or doesn't even know this one's features. So chances are you won't see i386 code in any readable form and being "db"ed instead. :( Just FYI if you don't get what you want with objdump(1) -- I don't know well this can cope with formats _not_ being produced by cc(1), ld(1) or ar(1), i.e. not being a supported executable format. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
On Thu, Mar 23, 2000 at 08:27:52PM +0100, Gerhard Sittig wrote:
Just FYI if you don't get what you want with objdump(1) -- I don't know well this can cope with formats _not_ being produced by cc(1), ld(1) or ar(1), i.e. not being a supported executable format.
Hello Gerhard, Hello list, I just would like to confirm the useability of nm and objdump as posted. The shell made the following things: Transform the string /BIN/SH (which is within the code) into /bin/sh, put addresses etc. into the exploited buffer, call execv and perform error checking. Frank
Hello Frank, I think it's not necessary to decode the Assembler-commands, because they do exactly what the name "shellcode" means: Starting a (root-) shell. So the buffer consists of two Linux system calls: (1) execve(/bin/bash) to start the shell (2) exit(0) just in case execve returns with an error So with that source code you found, you can only say which program was used to break into your friends box, e.g. which service had the security hole. To find out what your hacker did after the break-in, you could probably start reading root's cmdline-history /root/.bash_history or /root/.sh-history. For further information on buffer overflows read phrack magazine, issue 49 (www.phrack.com), "Smashing the stack for fun an profit". Greetz, Soeren.
Hi list,
the box of a friend was hacked: /bin/ps /bin/login /bin/ls were replaced / trojaned. The original files were placed in /bin/bincp (which is not shown by ls, but cd into that dir works fine)
Luckyly I found some source within a log of another machine. Comments show that there is an
unsigned char shellcode[] =
with some rows of "\x ...\x" numbers. I assume that there is the coding of a shell command. Unfortunately I do not know how to "read" the command. Translating the hex numbers into decimal and using an ASCII table does not give a usefull result. Any idea? Tips who to detect which root kit was used are welcome, too.
TIA Frank
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On Thu, Mar 23, 2000 at 08:34:40AM +0100, Soeren Eyhusen wrote:
For further information on buffer overflows read phrack magazine, issue 49 (www.phrack.com), "Smashing the stack for fun an profit".
Thanks a lot for that link. Excellent reading. <20000322211105.M24822@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Wed, Mar 22, 2000 at 09:11:05PM +0100 On Wed, Mar 22, 2000 at 09:11:05PM +0100, Gerhard Sittig wrote:
[use nm objdump]
Now I know some tools and have an idea how to try to analyze the whole material from the attacker... BTW: the attacker used pop2, the installed pop2d version was too old Greetings, Frank
On Wed, 22 Mar 2000, Frank Derichsweiler wrote:
the box of a friend was hacked: /bin/ps /bin/login /bin/ls were replaced / trojaned. The original files were placed in /bin/bincp (which is not shown by ls, but cd into that dir works fine)
Tips who to detect which root kit was used are welcome, too.
Hi! We had a breakin not long ago and the part about hidden dirs sounds familiar. The intruder used a kernel-based root kit for 2.2 kernels, Knark v0.50, which would put some info about hidden dirs and some other info into (hidden) /proc/knark dir. Check for it. I could also post the README file from the root kit, maybe that could give you some more clues? Regards, Daniel.
participants (7)
-
Frank Derichsweiler -
Gerhard Sittig -
Markus Gaugusch -
Schoeberle Daniel -
Soeren Eyhusen -
Thomas Biege -
Thomas Michael Wanka