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.


Topics - mynameistmp

Pages: [1] 2
1
Unix / Linux Discussion / Linux Network question
« on: March 23, 2007, 09:27:20 PM »
Evening, gents. I'm installing Slackware 10.2 on a PC and I've run into a strange network problem. I'm wondering if anyone has any ideas.

Some background: It's an ethernet network. When I plug the exact same cable into my Windows computer, it works fine. It's a standard DHCP network with a Linksys router. It's a fresh install of Linux. When I lspci, I can see my ethernet card. The loopback device is setup and I can ping localhost. I have run netconfig, setting the interface as DHCP. I can use ifconfig to bring the interface up.

The problem: I can't seem to get dhcpcd to grab a network address. I cannot ping any other nodes on the network (including the gateway). I have setup dhcpcd to dump output to syslog, and when I inspect my dhcpcd.log there is one message along the lines of: "dhcpcd timed out awaiting response".

Ideas?

Thanks in advance
tmp


2
General Security Information / Book Release
« on: November 06, 2006, 11:40:12 PM »
I'm not sure if you're all aware, but the Authors of the Shellcoders Handbook are releasing a revised edition with some (apparently %40) new material in April, 2007.

"# New material addresses the many new exploitation techniques that have been discovered since the first edition, including attacking "unbreakable" software packages such as McAfee’s Entercept, Mac OS X, XP, Office 2003, and Vista
# Also features the first-ever published information on exploiting Cisco’s IOS, with content that has never before been explored
"

I thought it sounded interesting, anyways.

So yea, I was just thinking I should probably append some sort of a link.

http://www.amazon.com/Shellcoders-Handbook-Discovering-Exploiting-Security/dp/047008023X/sr=8-2/ref=pd_bbs_2/102-1326124-1044129?ie=UTF8&s=books

3
General Discussion / Buying a laptop
« on: October 05, 2006, 05:30:02 AM »
I'm looking at buying a laptop. Any suggestions on good vendors, where to buy, etc ? I know very minimal amounts about laptops. Price isn't my principal concern. I'm willing to pay reasonably more for quality. I plan on running Slackware linux on it. Any input appreciated.

4
General Discussion / Krazed going to jail ??
« on: July 05, 2006, 04:26:50 AM »
Evening gents. Krazed, I haven't talked to you in a while and I saw this the other day and was wondering...

"According to prosecutors, McKeage (AKA Krazed) broke in a computer run by police in Port Orange, Florida and used stolen credentials from this systems to access Accurint, a law enforcement database service, maintained by Seisint, a local subsidiary of LexisNexis." -- the register

Is that you ?? You crazy son of a bitch. Paris is a sweetheart, leave her out of your schemes.

5
General Discussion / Spammer fined $11 billion
« on: January 06, 2006, 02:43:43 AM »
I wonder what you do after you get fined $11 billion dollars. That's got to be a tough one to hide from the wife...

http://www.theinquirer.net/?article=28733

6
General Security Information / Windows outdoes Linux
« on: January 06, 2006, 02:36:23 AM »
According to CERT, Linux/Unix had far more vulnerabilities released last year than Windows did...

http://www.theregister.co.uk/2006/01/05/windows_linux_unix_security_vulnerabilities/

7
General Programming / Anagram solver!
« on: December 05, 2005, 06:58:11 AM »
My Mom always does these anagram puzzles in her morning papers, so I took it upon myself to create a solution finder for her! Now I know that most of you probably aren't interested in what tmps Mother does or solving anagram problems, but you might find the code I made somewhat interesting.

What I am doing is taking a scrambled input string and checking to see if any combination of the string exists in the dictionary file (is it a valid english word or not). Here is what the program looks like in action:

Quote
bash-3.00$ time puzzle.sh adegln
Using anagram: adegln
Sorting adegln alphabetically... adegln
Scanning database...
Found 1 result(s):
angled
Found 2 result(s):
dangle

real    0m0.343s

As you can see, it works pretty quickly ;P The time program tells us less than a second, anyways.

How it works:

I started off with just a dictionary of all english words (thanks iago). I created script.sh which takes every line in the wordlist and rearranges each character alphabetically, keeping all of the lines in the original order. Now you have two wordlists, both parallel on a line to line basis. Then I created afilter.c. afilter (once compiled) takes data from standard input and rearranges the data alphabetically, then spits out the arrangement, in classical unix fashion ;P. Then I wrote puzzle.sh, a bash script that takes a command line argument (the scrambled word), pipes it to afilter wich outputs an alphabetically arranged version of the anagram. That output is grep'd from the second (alphabetized) wordlist. When a match is found, the line number is extracted via awk and awk is used again to scan the first (original) wordlist for that very line number, which is parallel to the second word list, thus giving you the matching (english) word.

Here is the link to the source (script.sh, afilter.c, puzzle.sh, both wordlists) if anybody is interested:
www.javaop.com/~tmp/puzzle.tar.gz

It is 600k, 95% of which is the dictionary file included.

8
General Programming / Help with C pointers
« on: November 12, 2005, 05:13:58 PM »
I found this brief piece of code that I don't really understand. Obviously there is some major concept that I am missing. I was hoping someone here could explain it a little bit. This guy stores shellcode in a char array then executes the shellcode. If you run the program it works, but I don't understand why. Here is the code:

Code: [Select]
char shellcode[] = "blahblah";

int main()
{
      int *ret;
      ret = (int *)&ret + 2;
      (*ret) = (int)shellcode;
}

I don't really understand how that results in the shellcode being executed. Thanks in advance.


   


9
Unix / Linux Discussion / Who has the most RAM ?
« on: September 27, 2005, 03:02:16 PM »
I'm interested in who has the most RAM in ONE machine. The machine has to be running Linux or you're void from the contest ;P Whoever wins (the winner has to be above 900MB) will get a prize.

10
General Discussion / slackchat has a new home!
« on: September 25, 2005, 10:41:10 PM »
The new home for slackchat is www.javaop.com/~tmp/. Much thanks to iago.

11
Unix / Linux Discussion / TIP: Immutable files
« on: September 19, 2005, 03:20:55 AM »
In the ext2 and ext3 filesystems there are a number of additional file attributes available that are beyond the standard bits accessible by chmod. Here is an example of a neat one:

Quote
sh-3.00$ cat test.txt; ls -l test.txt; id
x86
-rw-r--r--  1 tmp users 4 2005-09-19 00:33 test.txt
uid=1000(tmp) gid=100(users) groups=100(users),11(floppy),17(audio),18(video),19(cdrom)
sh-3.00$ rm -f test.txt
rm: cannot remove `test.txt': Operation not permitted

Seems strange. It's a typical text file. My UID is the owner of this file, but I can't delete it. Alright, let's try with root:

Quote
root@tmp:/home/tmp# id ; rm -f test.txt
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy)
rm: cannot remove `test.txt': Operation not permitted

The problem is that this file is 'immutable'. For those of you who aren't familiar with this you should check out the man page on lsattr and chattr. All we need to do is get rid of the immutable attribute and we're off to the races:

Quote
root@tmp:/home/tmp# lsattr test.txt
----i-------- test.txt
root@tmp:/home/tmp# chattr -i test.txt
root@tmp:/home/tmp# rm test.txt

While this flag is set any attempts to unlink, overwrite, rename, or append to the file will fail.

12
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:

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.





13
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:

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




14
General Discussion / Linus Torvalds interview.
« on: June 09, 2005, 03:41:44 AM »
Linux Magazine did an interview with Linus Torvalds back in January that they now released on their webpage for those of you that didn't pick up the issue.

http://www.linux-mag.com/content/view/59/2201/

One interesting quote I noticed was this one:
Quote
The two will co-exist for a long time, though. I personally also feel that ppc64 is interesting, and that’s actually what I run on my personal desktop( it’s a dual G5 Apple box, although it obviously runs Linux, not OS X).

An Apple box!

15
This one's old, but seeing as NOTHING has been posted here, I might as well make sure you're all informed. This one's dangerous.


Anyways, some guy from chroot.org modified a race condition exploit for the linux kernel to work on SMP kernels. This one works on 2.4 --> 2.4.29-pre3, 2.6 --> 2.6.10

http://www.x0r.ca/uselib24.c

Pages: [1] 2