by Javantea aka. Joel R. Voss
Sept 8, 2006
Botnets
Spam Server Analysis
Spam Server Passive/Active Analysis 0.4
[sig]
50 MB of Test Spam
[sig]
At the above Neg9 Seattle meeting (Sept 8, 2006), a group of four Neg9 security researchers gathered to discuss botnets and various other ideas. I, Javantea, led the discussion of botnets, but as expected, the three other participants were far more knowledgeable than I on the topic of botnets. Quite a lot of research, development, and interest is going into botnets currently. This is a very positive note because everyone benefits from better knowledge and control of botnets.
It begs to be said that nothing illegal was done at the Neg9 meeting. Nothing unethical was done at the Neg9 meeting. Polite portscans are legitimate techniques of security researchers and criminals alike. I limited the output of my box to a maximum of 6 packets per second at maximum and 2 packets per second at nominal. Connecting to any machine on the internet is legitimate because open ports are public information. Anyone who disagrees is a complete idiot and should go straight to /dev/null.
Read more »Buffer Overflows
jvoss@altsci.com
jvoss@myuw.net
July 2, 2006
This essay is not finished, but will be in 1 week. Check back Sept 16.
Trivial buffer overflows are easy to exploit with the right tools. Aleph released several buffer overflow tools with his remarkable article "Smashing The Stack For Fun And Profit" in Phrack 49. Recent advances in security technologies have made these more difficult, but junior programmers will continue to make these vulnerabilities far into the future. Interpreted languages promise ensured memory, but programs compiled to bytecode will have these problems. Simple security checking can solve buffer overflows by bounds checking and using functions that take into account the size of the destination buffer. The book, Sockets, Shellcode, Coding, and Porting notes that sadly buffer overflows are history in professional coding (heap overflows have a long ways to go though). That may be true in open source software, but in megacorporations and non-professional coding, bugs will remain. Commonly these program will have networking built-in and will be run as root (or suid).
The trick to understanding what the buffer overflow code is doing is found in a
few small things that you have to try yourself. Break out buffovr1-0.1.tgz for
this. If you don't feel like running buffer overflows on your box, then find
someone else's box.
The most simple that you should know already is that a segfault is when you try
to read memory that your process doesn't have access to. The kernel knows where
you are allowed to read and jump to, so if you get a segfault, you've got some
type of buffer/heap overflow.
The second one equally easy is that variables in a program are pushed onto the
stack. If you're defining variables, you're pushing stuff on the stack.
The third idea is absurdly easy: when you write 200 bytes into a 128 byte
buffer on the stack, it will overwrite variables.
The fourth idea is interesting, but easy to see when you're looking at the
code: One of the variables that you don't push manually is the sfp which is
jumped to by the ret opcode. That way we are able to jump to our shellcode in
the buffer.
The fifth idea is pretty interesting: how do we know where the buffer is? If we
have access to the computer, we can just grab the current stack pointer and add
a few. But if not, we can check a similar computer or guess.
Ident Protocol Scan
jvoss@altsci.com
jvoss@myuw.net
Oct 28, 2005
This program connects to an identd server and asks for the information. This is an unintended consequence of the design of the server.
Identd is an interesting program. It searches /proc/net/tcp for a matching entry. The input is easy enough for a human to input into telnet if they have the localport and the remoteport. We get the localport from getsockname() and the remote port is the port that we are connected to. This will give us the user that is running the command.
Read more »
