AltSci Blog

by Javantea aka. Joel R. Voss
Sept. 7, 2006
Slideshow format
Botnets Neg9 Hands-On Tutorial

Botnets are groups of computers running malicious software that group together to achieve a common goal. Botnets are possible because of rampant security flaws in commonly used operating systems and programs. While software developers release patches, there isn't a perfect system of updating in place and there is evidence that there never will be. Lack of patching leaves programs open to exploitation. However, many exploits could be prevented by using simple security software (firewall, anti-virus) or by simple design of the operating system (no ports open). Some exploits, however, are in programs that are required for business (eg. web servers). I plan to discuss the methods and motivations for botnets and the methods for discovery and destruction of Botnets. I don't have perfect solutions, but I have some good ideas that can be put into use today to affect the number of botnets.

Botnets are a quite recent addition to security literature. They have appeared mainly as a result of obvious security vulnerabilities. Most botnets are targeted at the Win32 OS because of the number of vulnerabilities [1] and the massive number of unpatched machines available (250,000-1.5M+ Sasser infections, 200M update downloads) [2]. However, botnets have targeted many platforms. The first Linux/Apache worm was quite recent (Dec 20  2004), targetting a vulnerability in phpBB which was caused by PHP. The worm used Perl, Google, and left an obvious trace [3]. Although it did not become a botnet, it easily could have. More recently I have detected a botnet gathering using the AWStats and Mambo vulnerabilities [4]. In response to increased patching and firewalls in remote services of Microsoft Windows, botnets have targetted IE6, which is often unpatched.

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.

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.