91
Unix / Linux Discussion / Re: How to rm yourself
« on: August 14, 2005, 07:11:01 pm »
I'm guessing you also have no way to root me.
News:
Happy New Year! Yes, the current one, not a previous one; this is a new post, we swear!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
92
Unix / Linux Discussion / Re: How to rm yourself
« on: August 14, 2005, 07:07:13 pm »Quote
But at any rate, those aren't 100% reliable. They're mitigating factors, for sure, but they might not save me from a smf sql-injection attack that cleverly evades the IPS, or an Apache format-string vuln that lets me overwrite some key address in Apache, giving me unlimited access or something?
He said apache, not sql. I don't have sql running. The format-string idea sounds interesting, but unlikely. I'm pretty sure you'd need to inject shellcode anyways, because I don't think there's any code in apache that'd do you any good. And on top of that, grsec randomizes all user space memory objects. That would make it difficult to write to key addresses (if they do exist).
Quote
Then you don't use the stack.
grsec has ASLR (full adress space layout randomization). That includes: user space, kernel space, executable image, library images, etc, etc, etc.
Quote
So you see there are always ways around those kernel security modules. Ways around non-exec stacks, and your stack randomization.
What is the way around full address space layout randomization ?
93
Unix / Linux Discussion / Re: How to rm yourself
« on: August 14, 2005, 04:57:51 am »Quote
For instance, if you're running the current version of Apache httpd, you still are not safe from attacks to the Apache httpd, because someone could have found a vuln. And guess what, there isn't a patch out yet. So unfortunately, your only chance would be to plug the 0day vuln holes by coding your own patch.
What if I've got a network IDS running that's filtering for incoming shellcode ? What if I've got something like the grsec patch installed and his shellcode's offsets are fucked up because the stack is randomized ?
94
Unix / Linux Discussion / Using the Environment
« on: July 16, 2005, 05:34:05 am »
I know that bash environment guides and tutorials are a dime a dozen, but I decided to make a to-the-point post about a few tips most of you newer guys should learn from the start, and throw in a few tricks some of you novice guys might not know yet. I'll try to keep this as brief as possible, but it's going to be fairly lengthy.
First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your PS1 (system prompt) env variable:
I wrapped the escape sequences in bold (\u -- username, \w -- working directory), the rest are ANSI escape sequences interpreted as colour codes. For the sake of brevity I'm not going to explain everything here, but here's a guide to the various colour codes here: http://www.linuxgazette.com/issue65/padala.html. Mess around with it to get the colour scheme you want.
Many people know that the PATH env variable stores the various directories to be scanned for scripts/executables to be executed, and MANPATH for man files, etc. Many people, however, overlook the CDPATH env variable. Try:
Now whenever you do a cd <directory> it'll automatically search your home directory, so you don't have to prefix with ~/. Fool around with this a bit. You can add as many directories as you want, just delimit them with :. Note that as root you should be weary of editing your PATH env variable. If you add a directory writable to other users, they can add binaries that will be mistaken by you as typical programs and executed inadvertently as root.
We all know that ~/.bash_history stores everything interpreted by your bash shell. So you need to be careful if you're ever using shells to log into other services. If you enter some sensitive data (password) accidentally on the command line without realizing it before carriage returning it's possible the evil admin (or perhaps some other user!) will stumble upon your precious password when checking out your .bash_history, you'll probably want to erase it. Well, .bash_history is written everytime you log out, so doing rm .bash_history now isn't going to work. What you can do is this:
This will completely clear your .bash_history file, and will write an empty file when you log out. Note: You could have logged out, logged back in, and rm .bash_history, but this trick is more convenient and the other way still leaves an rm command in your .bash_history and you might not want your admin to know you're deleting logs.
A system admin will typically use the w command (or some alternate method) in order to see who is logged into the server. Sometimes people will remotely login, execute a few commands, then just forget about their terminal, leaving it idle. Or perhaps they're using the system to run their irc client. If the person has gone out for the day and their client has terminated for whatever reason their connection will also idle. If you, as the admin, don't like hosting all of these idle users try this:
This will make it so that bash automatically logs out any user who hasn't produced input for 10 minutes. Adjust the time (in seconds) as necessary.
Let's say you're logged into an X session and you want to run a binary with root priviliges that outputs to a GUI. Let's also say it's unsafe to suid the program, and you don't want to add support for sudo on the system for security reasons. Try this series of commands:
Anything that uses xlib to draw to an X session that is executed as root on that command line will be drawn to display :0.0. Note that there are security issues inherent in this as well. xhost is used to control the ACLs that filter access to your X server. If you disable them, anyone able to connect to your X server will be able to output to your display. You may want to research how to limit acess to your X server via xhost.
Typically ps aux is more practical than regular old ps. Or maybe ls -a is preferred to ls. Getting tired of typing ps aux every time ? Set an alias:
Another use of environment variables is storing shellcode. Perhaps you've found a buffer overflow, but there isn't enough room in the buffer for your NOP sled and the lengthy bind shellcode you picked up off of metasploit. Pack a NOP sled and your shellcode into your env variable then use the address of the env variable to overwrite the return address on the stack instead of all of your shellcode:
Here's a quick little program in C that'll output the address of the env variable holding the shellcode:
Find the address of our shellcode and overwrite the stack's return address with our SHELLCODE env variable:
That's enough for now. bash when run as a login shell reads from /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in that order (assuming they exist). For any other kind of shell it reads from ~/.bashrc. So, if you want to make any of these env variables permanent, set them in the appropriate file for your shell.
First of all, if you're operating a terminal as a regular user you might be jealous because root gets fancy colour coded output. This one's a quick and easy fix. All you have to do is edit your PS1 (system prompt) env variable:
Quote
export PS1=`echo -ne "\033[0;34m\u@\h:\033[0;36m\w\033[0;34m\$\033[0;37m "`
I wrapped the escape sequences in bold (\u -- username, \w -- working directory), the rest are ANSI escape sequences interpreted as colour codes. For the sake of brevity I'm not going to explain everything here, but here's a guide to the various colour codes here: http://www.linuxgazette.com/issue65/padala.html. Mess around with it to get the colour scheme you want.
Many people know that the PATH env variable stores the various directories to be scanned for scripts/executables to be executed, and MANPATH for man files, etc. Many people, however, overlook the CDPATH env variable. Try:
Quote
export CDPATH=.:~
Now whenever you do a cd <directory> it'll automatically search your home directory, so you don't have to prefix with ~/. Fool around with this a bit. You can add as many directories as you want, just delimit them with :. Note that as root you should be weary of editing your PATH env variable. If you add a directory writable to other users, they can add binaries that will be mistaken by you as typical programs and executed inadvertently as root.
We all know that ~/.bash_history stores everything interpreted by your bash shell. So you need to be careful if you're ever using shells to log into other services. If you enter some sensitive data (password) accidentally on the command line without realizing it before carriage returning it's possible the evil admin (or perhaps some other user!) will stumble upon your precious password when checking out your .bash_history, you'll probably want to erase it. Well, .bash_history is written everytime you log out, so doing rm .bash_history now isn't going to work. What you can do is this:
Quote
export HISTSIZE=0
This will completely clear your .bash_history file, and will write an empty file when you log out. Note: You could have logged out, logged back in, and rm .bash_history, but this trick is more convenient and the other way still leaves an rm command in your .bash_history and you might not want your admin to know you're deleting logs.
A system admin will typically use the w command (or some alternate method) in order to see who is logged into the server. Sometimes people will remotely login, execute a few commands, then just forget about their terminal, leaving it idle. Or perhaps they're using the system to run their irc client. If the person has gone out for the day and their client has terminated for whatever reason their connection will also idle. If you, as the admin, don't like hosting all of these idle users try this:
Quote
export TMOUT=600
This will make it so that bash automatically logs out any user who hasn't produced input for 10 minutes. Adjust the time (in seconds) as necessary.
Let's say you're logged into an X session and you want to run a binary with root priviliges that outputs to a GUI. Let's also say it's unsafe to suid the program, and you don't want to add support for sudo on the system for security reasons. Try this series of commands:
Quote
sh-3.00$ set | grep DISPLAY
DISPLAY=:0.0
sh-3.00$ xhost +
access control disabled, clients can connect from any host
sh-3.00$ su -
Password:
root@tmp:~# export DISPLAY=:0.0
root@tmp:~# ethereal
Anything that uses xlib to draw to an X session that is executed as root on that command line will be drawn to display :0.0. Note that there are security issues inherent in this as well. xhost is used to control the ACLs that filter access to your X server. If you disable them, anyone able to connect to your X server will be able to output to your display. You may want to research how to limit acess to your X server via xhost.
Typically ps aux is more practical than regular old ps. Or maybe ls -a is preferred to ls. Getting tired of typing ps aux every time ? Set an alias:
Quote
sh-3.00$ cat << EOF > ~/.bashrc
> alias ps='ps aux'
> EOF
sh-3.00$ bash -ic ps | grep xterm
tmp 2659 0.0 0.8 5736 2304 tty1 S Jul15 0:00 xterm -title Terminal
tmp 3909 0.0 1.3 5972 3464 tty1 S 02:22 0:00 xterm -title Terminal
tmp 3978 0.0 0.2 1688 600 pts/3 S+ 02:28 0:00 grep xterm
Another use of environment variables is storing shellcode. Perhaps you've found a buffer overflow, but there isn't enough room in the buffer for your NOP sled and the lengthy bind shellcode you picked up off of metasploit. Pack a NOP sled and your shellcode into your env variable then use the address of the env variable to overwrite the return address on the stack instead of all of your shellcode:
Quote
export SHELLCODE=`perl -e 'print "\x90"x200;'``cat shellcode`
Here's a quick little program in C that'll output the address of the env variable holding the shellcode:
Code: [Select]
#include <stdlib.h>
int main(int argc, char *argv[]) {
char *addr = getenv(argv[1]);
printf("\n%p\n", addr);
return 0;
}
Find the address of our shellcode and overwrite the stack's return address with our SHELLCODE env variable:
Quote
sh-3.00$ getenv SHELLCODE
SHELLCODE is located at 0xbffff892
sh-3.00$ ./vulnprog `perl -e 'print "\x92\xf8\xff\xbf"x10;'`
That's enough for now. bash when run as a login shell reads from /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in that order (assuming they exist). For any other kind of shell it reads from ~/.bashrc. So, if you want to make any of these env variables permanent, set them in the appropriate file for your shell.
95
General Discussion / Re: What are...
« on: July 09, 2005, 03:30:23 pm »
Processor: Intel(R) Celeron(R) CPU 1.70GHz
Ram:256MB SDRam
Harddrive(s):40GB Western Digital Harddrive
Drives: LG 52x CD-R, Floppy disk drive
Video: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]
OS(s): Slackware 10.1.0
Ram:256MB SDRam
Harddrive(s):40GB Western Digital Harddrive
Drives: LG 52x CD-R, Floppy disk drive
Video: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]
OS(s): Slackware 10.1.0
96
Unix / Linux Discussion / Re: Using /proc
« on: June 25, 2005, 02:31:03 am »
When people start building more complex sudo configuration files using things like Runas_Alias and User_Alias I find them giving access to all sorts of things, especially editors. I suppose the thought is it's easier than just creating groups then using chmod on the appropriate configuration files. There are many more security flaws inherent in giving sudo access to text editors, I was just pointing out one relevant to /proc that I figured most users here wouldn't know about.
97
Unix / Linux Discussion / Re: Using /proc
« on: June 24, 2005, 02:34:16 pm »Quote
The thing about finding your root password is that, if a user can access that file, they already have root on your system.
If a user needs higher priviliges it is popular for admins to give them an entry in /etc/sudoers as opposed to giving out the system password. This results in many users having certain escalated priviliges without ever having the system password. Scouring data caches like kcore for sensitive data is one method of circumventing that level of control.
98
Unix / Linux Discussion / Using /proc
« on: June 24, 2005, 03:18:05 am »
For those of you who don't know, /proc is a filesystem that acts as a sort of representation of the kernel's live process table. Many commonly used linux tools are just programs that extract/represent data found in /proc (you can cut out uname -a as a middleman just by doing cat /proc/version). Anyways, I'm going to attempt to show off a few neat things you can do with your own friendly neighbourhood /proc.
In /proc is a directory for every PID you've got running on the system. If you're interested in a particular process, explore the directory corresponding to its PID in /proc. Take init (PID 1) for example:
exe is a symlink pointing to the full path to the binary that was called. cwd points to the current working directory of the process. The cmdline file contains the command line as it was originally called, and environ contains all of the processes environment information. All of this data is delimited by NULL characters, so you'll want to run it through some sort of a filter in order to make it manageable:
This kind of data can be extremely useful when investigating rogue processes.
One interesting aspect of /proc that most users don't utilize is kcore:
From this you can tell that this machine has ~256 MB of RAM installed (279457795/1024/1024). This is the system memory and some interesting data tends to wind up cached here. Try messing around with strings / grep and see what you can come up with. See if you can find your root password in there somewhere. If you can, odds are some miscreant can.
Finally, a little tip for you security buffs. Typically a rootkit will alter your ps command in order to malform its output in an attempt to hide any malicious processes. Well, one quick and easy way around this method is comparing your /proc contents to the output of your ps command:
It is much more difficult (and rare) for a hacker to change the output of /proc, which makes this a very convenient/effective method.
Enjoy ;P
In /proc is a directory for every PID you've got running on the system. If you're interested in a particular process, explore the directory corresponding to its PID in /proc. Take init (PID 1) for example:
Quote
root@tmp:/proc/1# ls -l
total 0
-r--r--r-- 1 root root 0 2005-06-24 00:43 cmdline
lrwxrwxrwx 1 root root 0 2005-06-24 00:43 cwd -> //
-r-------- 1 root root 0 2005-06-24 00:43 environ
lrwxrwxrwx 1 root root 0 2005-06-24 00:43 exe -> /sbin/init*
dr-x------ 2 root root 0 2005-06-24 00:43 fd/
-r--r--r-- 1 root root 0 2005-06-24 00:43 maps
-rw------- 1 root root 0 2005-06-24 00:43 mem
-r--r--r-- 1 root root 0 2005-06-24 00:43 mounts
lrwxrwxrwx 1 root root 0 2005-06-24 00:43 root -> //
-r--r--r-- 1 root root 0 2005-06-24 00:43 stat
-r--r--r-- 1 root root 0 2005-06-24 00:43 statm
-r--r--r-- 1 root root 0 2005-06-24 00:43 status
exe is a symlink pointing to the full path to the binary that was called. cwd points to the current working directory of the process. The cmdline file contains the command line as it was originally called, and environ contains all of the processes environment information. All of this data is delimited by NULL characters, so you'll want to run it through some sort of a filter in order to make it manageable:
Quote
root@tmp:/proc/1# cat environ | tr '\0' '\n'
HOME=/
TERM=linux
BOOT_IMAGE=linux
This kind of data can be extremely useful when investigating rogue processes.
One interesting aspect of /proc that most users don't utilize is kcore:
Quote
root@tmp:/proc# ls -l kcore
-r-------- 1 root root 279457792 2005-06-24 00:33 kcore
From this you can tell that this machine has ~256 MB of RAM installed (279457795/1024/1024). This is the system memory and some interesting data tends to wind up cached here. Try messing around with strings / grep and see what you can come up with. See if you can find your root password in there somewhere. If you can, odds are some miscreant can.
Finally, a little tip for you security buffs. Typically a rootkit will alter your ps command in order to malform its output in an attempt to hide any malicious processes. Well, one quick and easy way around this method is comparing your /proc contents to the output of your ps command:
Quote
root@tmp:/proc/1# ls -d /proc/* | grep [0-9] | wc -l ; ps ax | wc -l
74
74
It is much more difficult (and rare) for a hacker to change the output of /proc, which makes this a very convenient/effective method.
Enjoy ;P
99
Unix / Linux Discussion / Re: Distributions?
« on: June 18, 2005, 02:21:24 am »Quote
So yes it takes awhile to install but I feel its worth it because I can control just about everything that gets installed.
For anyone interested, Slackware:
http://www.slackware.com/book/index.php?source=x4150.html
100
Unix / Linux Discussion / Re: Linux is garbage
« on: June 17, 2005, 03:51:25 pm »
Theo has been discredited before. I used to follow his drawn out debates with the PAX team. He was pretty flustered about grsecurity rolling out a solution to linux's executable stack vulnerabilities.
Anyways, some more of the argument is archived here:
http://www.grsecurity.net/PaX-presentation_files/frame.htm (This link displays better in .pdf format)
On the other hand, if you've looked at any benchmarking comparing OS scalability in a number of categories (http://bulk.fefe.de/scalability/), you'd see that OBSD did quite poorly (finished last out of all of the operating systems, actually), where Linux 2.6 finished FIRST out of all of the operating systems. OBSD of course had an argument for this:
Well... elements of that argument can be applied inversely for Linux in this situation. Linux has different goals than OBSD. If Linux users shouldn't be hounding OBSD developers about their lacking scalability, why do Linux developers catch heat for their rapid development cycle ? Also, If Linux code is so shotty, how is it that the benchmark results for scalability performance for it are significantly better than OBSD (OBSD developers don't deny the results of the benchmark) ? Linux out-performed OBSD in every category. Security is not the only requisite for quality software.
Quote
Claim: OpenBSD cannot protect against attacks using mprotect because it would violate POSIX, and OpenBSD does not violate POSIX.
> > We don't break anything that standards defacto standards require. (Theo de Raadt)
> You do break POSIX as pointed out above. (PaX Team)
> > False. Now go away. (Theo de Raadt)
Anyways, some more of the argument is archived here:
http://www.grsecurity.net/PaX-presentation_files/frame.htm (This link displays better in .pdf format)
On the other hand, if you've looked at any benchmarking comparing OS scalability in a number of categories (http://bulk.fefe.de/scalability/), you'd see that OBSD did quite poorly (finished last out of all of the operating systems, actually), where Linux 2.6 finished FIRST out of all of the operating systems. OBSD of course had an argument for this:
Quote
I was asked by a few OpenBSD people why I'm even comparing them here, since "everyone knows" they don't scale well and their goal is security and not scalability.
Well... elements of that argument can be applied inversely for Linux in this situation. Linux has different goals than OBSD. If Linux users shouldn't be hounding OBSD developers about their lacking scalability, why do Linux developers catch heat for their rapid development cycle ? Also, If Linux code is so shotty, how is it that the benchmark results for scalability performance for it are significantly better than OBSD (OBSD developers don't deny the results of the benchmark) ? Linux out-performed OBSD in every category. Security is not the only requisite for quality software.
101
Unix / Linux Discussion / Re: Text Editors
« on: June 16, 2005, 04:15:20 pm »Quote
Also, to use emacs to its fullest, I'd like to learn how to make extensions for it which are written in Lisp.
Technically they are written in Emacs Lisp, which is different than Common Lisp ;P Emacs Lisp is much simpler than Common Lisp, although standard emacs distributions offer an optional extension file that adds much of Common Lisps functionality to Emacs Lisp.
102
Unix / Linux Discussion / Re: Distributions?
« on: June 15, 2005, 03:17:28 pm »
Joe, why don't you try out Yellow Dog ? I've heard mostly good things about it.
http://www.yellowdoglinux.com/
http://www.yellowdoglinux.com/
103
Unix / Linux Discussion / Re: How should I download KDE?
« on: June 15, 2005, 03:06:04 pm »
Install guide:
http://docs.kde.org/development/en/kdebase/faq/install.html#id2561169
Sounds like you are looking for this:
http://developer.kde.org/build/konstruct/
http://docs.kde.org/development/en/kdebase/faq/install.html#id2561169
Sounds like you are looking for this:
http://developer.kde.org/build/konstruct/
104
Unix / Linux Discussion / Re: Text Editors
« on: June 15, 2005, 02:36:42 am »
emacs during an X session. i'll use vim if i'm going CL mode
105
General Programming / Re: Define a word -- Java
« on: June 14, 2005, 02:47:53 am »
Emacs has an (beautiful if I may say so myself) X version.