What's new arround internet

Last one

Src Date (GMT) Titre Description Tags Stories Notes
codewhitesec.webp 2023-07-05 10:09:34 Le blog a déménagé sur https://code-white.com/blog
Blog moved to https://code-white.com/blog
(lien direct)
Hé, nous avons déplacé notre blog technologique sur notre propre page d'accueil à https: // code-white.com/blog .À partir de maintenant, tous les nouveaux messages iront là-bas.Nous avons également copié sur tous les anciens articles, vous avez donc gagné rien.Et ne vous inquiétez pas, les publications de blogspot existantes resteront intactes pour que les liens existants fonctionnent.Mais à partir de maintenant, assurez-vous de consulter https://code-white.com/blog et, si vous \\ 'RETTANT, notre tout nouveau Liste des vulnérabilités publiques . Rendez-vous là-bas, L'équipe blanche du code
Hey,we\'ve moved our tech blog to our own homepage at https://code-white.com/blog. From now on, all fresh posts will go up there. We\'ve also copied over all the old articles, so you won\'t miss anything. And don\'t worry, the existing Blogspot posts will remain intact to keep the existing links working. But from now on, make sure to check out https://code-white.com/blog and, if you\'re interested, our all new public vulnerabilities list.See you there,The CODE WHITE Team
★★★
codewhitesec.webp 2023-04-11 15:22:39 Restrictions d'exploitation Java dans les temps JDK modernes
Java Exploitation Restrictions in Modern JDK Times
(lien direct)
Java deserialization gadgets have a long history in context of vulnerability research and at least go back to the year 2015. One of the most popular tools providing a large set of different gadgets is ysoserial by Chris Frohoff. Recently, we observed increasing concerns from the community why several gadgets do not seem to work anymore with more recent versions of JDKs. In this blog post we try to summarize certain facts to reenable some capabilities which seemed to be broken. But our journey did not begin with deserialization in the first place but rather looking for alternative ways of executing Java code in recent JDK versions. In this blost post, we\'ll focus on OpenJDK and Oracle implementations. Defenders should therefore adjust their search patterns to these alternative code execution patterns accordingly.ScriptEngineManager - It\'s GoneInitially, our problems began on another exploitation track not related to deserialization. Often code execution payloads in Java end with a final call to java.lang.Runtime.getRuntime().exec(args), at  least in a proof-of-concept exploitation phase. But as a Red Team, we always try to maintain a low profile and avoid actions that may raise suspicion like spawing new (child) processes. This is a well-known and still hot topic discussed in the context of C2 frameworks today, especially when it comes to AV/EDR evasion techniques. But this can also be applied to Java exploitation. It is a well-known fact that an attacker has the choice between different approaches to stay within the JVM to execute arbitrary Java code, with new javax.script.ScriptEngineManager().getEngineByName(engineName).eval(scriptCode) probably being the most popular one over the last years. The input code used is usually based on JavaScript being executed by the referenced ScriptEngine available, e.g. Nashorn (or Rhino).But since Nashorn was marked as deprecated in Java 11 (JEP 335), and removed entirely in Java 15 (JEP 372), this means that a target using a JDK version >= 15 won\'t process JavaScript payloads anymore by default. Instead of hoping for other manually added JavaScript engines by developers for a specific target, we could make use of a "new" Java code evaluation API: JShell, a read-eval-print loop (REPL) tool that was introduced with Java 9 (JEP 222). Mainly used in combination with a command line interface (CLI) for testing Java code snippets, it allows programmatic access as well (see JShell API). This new evaluation call reads like jdk.jshell.JShell.create().eval(javaCode), executing Java code snippets (not JavaScript!). Further call variants exist, too. We found this being mentioned already in 2019 used in context of a SpEL Injection payload. This all sounded to good to be true but nevertheless some restrictions seemed to apply. "The input should be exactly one complete snippet of source code, that is, one expression, statement, variable declaration, method declaration, class declaration, or import." So, we started to play with some Java code snippets using the JShell API. First, we realized that it is indeed possible to use import statements within such snippets but interestingly the subsequent statements were not executed anymore. This should have been expected by re Tool Vulnerability ★★
codewhitesec.webp 2023-03-20 12:30:04 JMX Exploitation Revisited (lien direct) The Java Management Extensions (JMX) are used by many if not all enterprise level applications in Java for managing and monitoring of application settings and metrics. While exploiting an accessible JMX endpoint is well known and there are several free tools available, this blog post will present new insights and a novel exploitation technique that allows for instant Remote Code Execution with no further requirements, such as outgoing connections or the existence of application specific MBeans. Introduction How to exploit remote JMX services is well known. For instance, Attacking RMI based JMX services by Hans-Martin Münch gives a pretty good introduction to JMX as well as a historical overview of attacks against exposed JMX services. You may want to read it before proceeding so that we're on the same page. And then there are also JMX exploitation tools such as mjet (formerly also known as sjet, also by Hans-Martin Münch) and beanshooter by my colleague Tobias Neitzel, which both can be used to exploit known vulnerabilities and JMX services and MBeans. However, some aspects are either no longer possible in current Java versions (e. g., pre-authenticated arbitrary Java deserialization via RMIServer.newClient(Object)) or they require certain MBeans being present or conditions such as the server being able to connect back to the attacker (e. g., MLet with HTTP URL). In this blog post we will look into two other default MBean classes that can be leveraged for pretty unexpected behavior: remote invocation of arbitrary instance methods on arbitrary serializable objects remote invocation of arbitrary static methods on arbitrary classes Tobias has implemented some of the gained insights into his tool beanshooter. Thanks! Read The Fine Manual By default, MBean classes are required to fulfill one of the following: follow certain design patterns implement certain interfaces For example, the javax.management.loading.MLet class implements the javax.management.loading.MLetMBean, which fulfills the first requirement that it implements an interface whose name of the same name but ends with MBean. The two specific MBean classes we will be looking at fulfill the second requirement: javax.management.StandardMBean javax.management.modelmbean.RequiredModelMBean Both classes provide features that don't seem to have gotten much attention yet, but are pretty powerful and allow interaction with the MBean server and MBeans that may even violate the JMX specification. The Standard MBean Class StandardMBean The StandardMBean was added to JMX 1.2 with the following description: […] the javax.management.StandardMBean class can be used to define standard MBeans with an interface whose name is not necessarily related to the class name of the MBean. – Java™ Management Extensions (JMX™) (Maintenance Release 2) Also: An MBean whose management interface is determined by reflection on a Java interface. –  Tool ★★
codewhitesec.webp 2022-09-06 11:02:07 Attacks on Sysmon Revisited - SysmonEnte (lien direct) In this blogpost we demonstrate an attack on the integrity of Sysmon which generates a minimal amount of observable events making this attack difficult to detect in environments where no additional security products are installed.tl;dr:Suspend all threads of Sysmon.Create a limited handle to Sysmon and elevate it by duplication.Clone the pseudo handle of Sysmon to itself in order to bypass SACL as proposed by James Forshaw.Inject a hook manipulating all events (in particular ProcessAccess events on Sysmon).Resume all threads.We also release a POC called SysmonEnte.BackgroundAt Code White we are used to performing complex attacks against hardened and strictly monitored environments. A reasonable approach to stay under the radar of the blue team is to blend in with false positives by adapting normal process- and user behavior, carefully choosing host processes for injected tools and targeting specific user accounts.However, clients with whom we have been working for a while have reached a high level of maturity. Their security teams strictly follow all the hardening advice we give them and invest a lot of time in collecting and base-lining security related logs while constantly developing and adapting detection rules.We often see clients making heavy use of Sysmon, along with the Windows Event Logs and a traditional AV solution. For them, Sysmon is the root of trust for their security monitoring and its integrity must be ensured. However, an attacker who has successfully and covertly attacked, compromised the integrity of Sysmon and effectively breaks the security model of these clients.In order to undermine the aforementioned security-setup, we aimed at attacking Sysmon to tamper with events in a manner which is difficult to detect using Sysmon itself or the Windows Event Logs.Attacks on Sysmon and DetectionHaving done some Googling on how to blind Sysmon, we realized that all publicly documented ways are detectable via Sysmon itself or the Windows Event Logs (at least those we found) :Unloading Sysmon Driver - Detectable via Sysmon event id 255, Windows Security Event ID 4672.Attacks Via Custom Driver - Detectable via Sysmon event id 6, Driver loaded.Kill the Sysmon Service - Sysmon Event ID 10 (Process Access with at least PROCESS_TERMINATE flag set; The last event forwarded by Sysmon).Manipulating the Rules Registry Key - Event ID 16.Patching Sysmon in Memory - Event ID 10.While we were confident that we can kill Sysmon before throwing Event ID 5 (Process terminated) we thought that a host not sending any events would be suspicious and could be observed in a client's SIEM. Also, loading a signed, whitelisted and exploitable driver to attack from Kernel land was out of scope to maintain stability.Since all of these documented attack vectors are somehow detectable via Sysmon itself, the Windows Event Logs or can cause stability issues we needed a new attack vector with the following capabilities:Not detectable via Sysmon itselfNot detectable via Windows Event LogSysmon must stay aliveAttack from usermodeInjecting and manipulating the control flow of Sysmon seemed the most promising.Attack DescriptionSimilarly to SysmonQuiet or EvtMute, the idea is to inject code into Sysmon which redirects the Tool
codewhitesec.webp 2022-06-28 16:00:56 Bypassing .NET Serialization Binders (lien direct) Serialization binders are often used to validate types specified in the serialized data to prevent the deserialization of dangerous types that can have malicious side effects with the runtime serializers such as the BinaryFormatter. In this blog post we'll have a look into cases where this can fail and consequently may allow to bypass validation. We'll also walk though two real-world examples of insecure serialization binders in the DevExpress framework (CVE-2022-28684) and Microsoft Exchange (CVE-2022-23277), that both allow remote code execution. Introduction Type Names Type names are used to identify .NET types. In the fully qualified form (also known as assembly qualified name, AQN), it also contains the information on the assembly the type should be loaded from. This information comprises of the assembly's name as well as attributes specifying its version, culture, and a token of the public key it was signed with. Here is an (extensive) example of such an assembly qualified name: System.Collections.Concurrent.ConcurrentBag`1+ListOperation[ [System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 This assembly qualified name comprises of two parts with several components: Assembly Qualified Name (AQN) Type Full Name Namespace Type Name Generic Type Parameters Indicator Nested Type Name Generic Type Parameters Embedded Type AQN (EAQN) Assembly Full Name Assembly Name Assembly Attributes You can see that the same breakdown can also be applied to the embedded type's AQN. For simplicity, the type info will be referred to as type name and the assembly info will be referred to as assembly name as these are the general terms used by .NET and thus also within this post. Th
codewhitesec.webp 2022-01-27 16:00:33 .NET Remoting Revisited (lien direct) .NET Remoting is the built-in architecture for remote method invocation in .NET. It is also the origin of the (in-)famous BinaryFormatter and SoapFormatter serializers and not just for that reason a promising target to watch for. This blog post attempts to give insights into its features, security measures, and especially its weaknesses/vulnerabilities that often result in remote code execution. We're also introducing major additions to the ExploitRemotingService tool, a new ObjRef gadget for YSoSerial.Net, and finally a RogueRemotingServer as counterpart to the ObjRef gadget. If you already understand the internal of .NET Remoting, you may skip the introduction and proceed right with Security Features, Pitfalls, and Bypasses. Introduction .NET Remoting is deeply integrated into the .NET Framework and allows invocation of methods across so called remoting boundaries. These can be different app domains within a single process, different processes on the same computer, or different processes on different computers. Supported transports between the client and server are HTTP, IPC (named pipes), and TCP. Here is a simple example for illustration: the server creates and registers a transport server channel and then registers the class as a service with a well-known name at the server's registry: var channel = new TcpServerChannel(12345);ChannelServices.RegisterChannel(channel);RemotingConfiguration.RegisterWellKnownServiceType( typeof(MyRemotingClass), "MyRemotingClass"); Then a client just needs the URL of the registered service to do remoting with the server: var remote = (MyRemotingClass)RemotingServices.Connect( typeof(MyRemotingClass), "tcp://remoting-server:12345/MyRemotingClass"); With this, every invocation of a method or property accessor on remote gets forwarded to the remoting server, executed there, and the result gets returned to the client. This all happens transparently to the developer. And although .NET Remoting has already been deprecated with the release of .NET Framework 3.0 in 2009 and is no longer available on .NET Core and .NET 5+, it is still around, even in contemporary enterprise level software products. Remoting Internals If you are interested in how .NET Remoting works under the hood, here are some insights. In simple terms: when the client connects to the remoting object provided by the server, it creates a RemotingProxy that implements the specified type MyRemotingClass. All method invocations on remote at the client (except for GetType() and GetHashCode()) will get sent to the server as remoting calls. When a method gets invoked on remote, the proxy creates a MethodCall object that holds the information of the method and passed parameters. It is then passed to a chain of sinks that prepare the MethodCall and handle the remoting communication with the server over the given transport. On the server side, the received request is also passed to a chain of sinks that reverses the process, which also includes deserialization of the MethodCall object. It ends in a dispatcher sink, which invokes the actual implementation of the method with the passed parameters. The result of the method invocation is then put in a MethodResponse object and gets returned to the client where the client s Tool
codewhitesec.webp 2021-09-21 10:44:47 RCE in Citrix ShareFile Storage Zones Controller (CVE-2021-22941) – A Walk-Through (lien direct) Citrix ShareFile Storage Zones Controller uses a fork of the third party library NeatUpload. Versions before 5.11.20 are affected by a relative path traversal vulnerability (CTX328123/CVE-2021-22941) when processing upload requests. This can be exploited by unauthenticated users to gain Remote Code Execution. Come and join us on a walk-though of finding and exploiting this vulnerability. Background Part of our activities here at Code White is to monitor what vulnerabilities are published. These are then assessed to determine their criticality and exploitation potential. Depending on that, we inform our clients about affected systems and may also develop exploits for our offensive arsenal. In April, Citrix published an advisory that addresses three vulnerabilities in ShareFile Storage Zones Controller (from here on just "ShareFile"). In contrast to a previous patch in the same product, there were no lightweight patches available, which could have been analysed quickly. Instead, only full installation packages were available. So, we downloaded StorageCenter_5.11.18.msi to have a look at it. The Travelogue A first glance at the files contained in the .msi file revealed the third party library NeatUpload.dll. We knew that the latest version contains a Padding Oracle vulnerability, and since the NeatUpload.dll file had the same .NET file version number as ShareFile (i. e., 5.11.18), chances were that somebody had reported that very vulnerability to Citrix. After installation of version 5.11.18 of ShareFile, attaching to the w3wp.exe process with dnSpy and opening the NeatUpload.dll, we noticed that the handler class Brettle.Web.NeatUpload.UploadStateStoreHandler was missing. So, it must have either been removed by Citrix or they used an older version. Judging by the other classes in the library, the version used by ShareFile appeared to share similarities with NeatUpload 1.2 available on GitHub. So, not a quick win, afterall? As we did not find a previous version of ShareFile such as 5.11.17, that we could use to diff against 5.11.18, we decided to give it a try to look for something in 5.11.18. Finding A Path From Sink To Source Since NeatUpload is a file upload handling library, our first attempts were focused around analysing its file handling. Here FileStream was a good candidate to start with. By analysing where that class got instantiated, the first result already pointed directly to a method in NeatUpload, the Brettle.Web.NeatUpload.UploadContext.WritePersistFile() method. Here a file gets written with something that appears to be some kind of metrics of an upload request: By following the call hierarchy, one eventually ends up in Brettle.Web.NeatUpload.UploadHttpModule.Init(HttpApplication), which is the initialization method for System.Web.IHttpModule: Vulnerability
codewhitesec.webp 2021-06-11 12:05:33 About the Unsuccessful Quest for a Deserialization Gadget (or: How I found CVE-2021-21481) (lien direct) This blog post describes the research on SAP J2EE Engine 7.50 I did between October 2020 and January 2021. The first part describes how I set off to find a pure SAP deserialization gadget, which would allow to leverage SAP's P4 protocol for exploitation, and how that led me, by sheer coincidence, to an entirely unrelated, yet critical vulnerability, which is outlined in part two. The reader is assumed to be familiar with Java Deserialization and should have a basic understanding of Remote Method Invocation (RMI) in Java. PrologueIt was in 2016 when I first started to look into the topic of Java Exploitation, or, more precisely: into exploitation of unsafe deserialization of Java objects. Because of my professional history, it made sense to have a look at an SAP product that was written in Java. Naturally, the P4 protocol of SAP NetWeaver Java caught my attention since it is an RMI-like protocol for remote administration, similar to Oracle WebLogic's T3. In May 2017, I published a blog post about an exploit that was getting RCE by using the Jdk7u21 gadget. At that point, SAP had already provided a fix long ago. Since then, the subject has not left me alone. While there were new deserialization gadgets for Oracle's Java server product almost every month, it surprised me no one ever heard of an SAP deserialization gadget with comparable impact. Even more so, since everybody who knows SAP software knows the vast amount of code they ship with each of their products. It seemed very improbable to me that they would be absolutely immune against the most prominent bug class in the Java world of the past six years. In October 2020 I finally found the time and energy to set off for a new hunt. To my great disappointment, the search was in the end not successful. A gadget that yields RCE similar to the ones from the famous ysoserial project is still not in sight. However in January, I found a completely unprotected RMI call that in the end yielded administrative access to the J2EE Engine. Besides the fact that it can be invoked through P4 it has nothing in common with the deserialization topic. Even though a mere chance find, it is still highly critical and allows to compromise the security of the underlying J2EE server. The bug was filed as CVE-2021-21481. On march 9th 2021, SAP provided a fix. SAP note 3224022 describes the details. P4 and JNDI Listing 1 shows a small program that connects to a SAP J2EE server using P4: The only hint that this code has something to do with a proprietary protocol called P4 is the URL that starts with P4://. Other than that, everything is encapsulated by P4 RMI calls (for those who want to refresh their memory about JNDI). Furthermore, it is not obvious that what is going on behind the scenes has something to do with RMI. However, if you inspect more closely the types of the involved Java objects, you'll find that keysMngr is of type com.sun.proxy.$Proxy (implementing interface KeystoreManagerWrapper) and keysMngr.getKeystore() is a plain vanilla RMI-call. The argument (the name of the keystore to be instantiated) will be serialized and sent to the server which will return a serialized keystore object (in this case it won't because there is no keystore "whatever"). Also not obvious is that the instantiation of the InitialContext requires various RMI calls in the background, for example the instantiation of a RemoteLoginContext object that will allow to process the login with the provided credentials. Each of these RMI calls would in theory be a sink to send a deserialization gadget to. In the exploit I mentioned above, one of the first calls inside new InitialContext() was used to Tool Vulnerability
codewhitesec.webp 2020-07-14 17:17:43 Sophos XG - A Tale of the Unfortunate Re-engineering of an N-Day and the Lucky Find of a 0-Day (lien direct) On April 25, 2020, Sophos published a knowledge base article (KBA) 135412 which warned about a pre-authenticated SQL injection (SQLi) vulnerability, affecting the XG Firewall product line. According to Sophos this issue had been actively exploited at least since April 22, 2020. Shortly after the knowledge base article, a detailed analysis of the so called Asnarök operation was published. Whilst the KBA focused solely on the SQLi, this write up clearly indicated that the attackers had somehow extended this initial vector to achieve remote code execution (RCE). The criticality of the vulnerability prompted us to immediately warn our clients of the issue. As usual we provided lists of exposed and affected systems. Of course we also started an investigation into the technical details of the vulnerability. Due to the nature of the affected devices and the prospect of RCE, this vulnerability sounded like a perfect candidate for a perimeter breach in upcoming red team assessments. However, as we will explain later, this vulnerability will most likely not be as useful for this task as we first assumed. Our analysis not only resulted in a working RCE exploit for the disclosed vulnerability (CVE-2020-12271) but also led to the discovery of another SQLi, which could have been used to gain code execution (CVE-2020-15504). The criticality of this new vulnerability is similar to the one used in the Asnarök campaign: exploitable pre-authentication either via an exposed user or admin portal. Sophos quickly reacted to our bug report, issued hotfixes for the supported firmware versions and released new firmware versions for v17.5 and v18.0 (see also the Sophos Community Advisory). I am Groot The lab environment setup will not be covered in full detail since it is pretty straight forward to deploy a virtual XG firewall. Appropriate firmware ISOs can be obtained from the official download portal. What is notable is the fact that the firmware allows administrators direct root shell access via the serial interface, the TelnetConsole.jsp in the web interface or the SSH server. Thus there was no need to escape from any restricted shells or to evade other protection measures in order to start the analysis. Device Management -> Advanced Shell -> /bin/sh as root. After getting familiar with the filesystem layout, exposed ports and running processes we suddenly noticed a message in the XG control center informing us that a hotfix for the n-day vulnerability, we were investigating, had automatically been applied. Vulnerability Guideline
codewhitesec.webp 2020-03-20 13:49:55 Liferay Portal JSON Web Service RCE Vulnerabilities (lien direct) Code White has found multiple critical rated JSON deserialization vulnerabilities affecting the Liferay Portal versions 6.1, 6.2, 7.0, 7.1, and 7.2. They allow unauthenticated remote code execution via the JSON web services API. Fixed Liferay Portal versions are 6.2 GA6, 7.0 GA7, 7.1 GA4, and 7.2 GA2. The corresponding vulnerabilities are: CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981) The JSONDeserializer of Flexjson allows the instantiation of arbitrary classes and the invocation of arbitrary setter methods. CST-7205: Unauthenticated Remote code execution via JSONWS (LPS-97029/CVE-2020-7961) The JSONWebServiceActionParametersMap of Liferay Portal allows the instantiation of arbitrary classes and invocation of arbitrary setter methods. Both allow the instantiation of an arbitrary class via its parameter-less constructor and the invocation of setter methods similar to the JavaBeans convention. This allows unauthenticated remote code execution via various publicly known gadgets. Liferay released the patched versions 6.2 GA6 (6.2.5), 7.0 GA7 (7.0.6) and 7.1 GA4 (7.1.3) to address the issues; the version 7.2 GA2 (7.2.1) was already released in November 2019. For 6.1, there is only a fixpack available. Introduction Liferay Portal is one of the, if not even the most popular portal implementation as per Java Portlet Specification JSR-168. It provides a comprehensive JSON web service API at '/api/jsonws' with examples for three different ways of invoking the web service method: Via the generic URL /api/jsonws/invoke where the service method and its arguments get transmitted via POST, either as a JSON object or via form-based parameters (the JavaScript Example) Via the service method specific URL like /api/jsonws/service-class-name/service-method-name where the arguments are passed via form-based POST parameters (the curl Example) Via the service method specific URL like /api/jsonws/service-class-name/service-method-name where the arguments are also passed in the URL like /api/jsonws/service-class-name/service-method-name/arg1/val1/arg2/val2/… (the URL Example) Authentication and authorization checks are implemented within the invoked service methods themselves while the processing of the request and thus the JSON deserialization happens before. However, the JSON web service API can also be configured to deny unauthenticated access. First, we will take a quick look at LPS-88051, a vulnerability/insecure feature in the JSON deserializer itself. Then we will walk through LPS-97029 that also utilizes a feature of the JSON deserializer but is a vulnerability in Liferay Portal itself. CST-7111: Flexjson's JSONDeserializer In Liferay Portal 6.1 and 6.2, the Flexjson library is used for seriali Vulnerability
codewhitesec.webp 2020-01-17 10:32:23 CVE-2019-19470: Rumble in the Pipe (lien direct) This blog post describes an interesting privilege escalation from a local user to SYSTEM for a well-known local firewall solution called TinyWall in versions prior to 2.1.13. Besides a .NET deserialization flaw through Named Pipe communication, an authentication bypass is explained as well. Introduction TinyWall is a local firewall written in .NET. It consists of a single executable that runs once as SYSTEM and once in the user context to configure it. The server listens on a Named Pipe for messages that are transmitted in the form of serialized object streams using the well-known and beloved BinaryFormatter. However, there is an additional authentication check that we found interesting to examine and that we want to elaborate here a little more closely as it may also be used by other products to protect themselves from unauthorized access. For the sake of simplicity the remaining article will use the terms Server for the receiving SYSTEM process and Client for the sending process within an authenticated user context, respectively. Keep in mind that the authenticated user does not need any special privileges (e.g. SeDebugPrivilege) to exploit this vulnerability described.Named Pipe Communication Many (security) products use Named Pipes for inter-process communication (e.g. see Anti Virus products). One of the advantages of Named Pipes is that a Server process has access to additional information on the sender like the origin Process ID, Security Context etc. through Windows' Authentication model. Access to Named Pipes from a programmatic perspective is provided through Windows API calls but can also be achieved e.g. via direct filesystem access. The Named Pipe filessystem (NPFS) is accessible via the Named Pipe's name with a prefix \\.\pipe\.The screenshot below confirms that a Named Pipe "TinyWallController" exists and could be accessed and written into by any authenticated user.Talking to SYSTEMFirst of all, let's look how the Named Pipe is created and used. When TinyWall starts, a PipeServerWorker method takes care of a proper Named Pipe setup. For this the Windows API provides System.IO.Pipes.NamedPipeServerStream with one of it's constructors taking a parameter of System.IO.Pipes.PipeSecurity. This allows for fine-grained access control via System.IO.PipeAccessRule objects using SecurityIdentifiers and alike. Well, as one can observe from the first screenshot above, the only restriction seems to be that the Client process has to be executed in an authenticated user context which doesn't seem to be a hard restriction after all.But as it turned out Tool Vulnerability
codewhitesec.webp 2019-08-01 14:54:08 Exploiting H2 Database with native libraries and JNI (lien direct) Techniques to gain code execution in an H2 Database Engine are already well known but require H2 being able to compile Java code on the fly. This blog post will show a previously undisclosed way of exploiting H2 without the need of the Java compiler being available, a way that leads us through the native world just to return into the Java world using Java Native Interface (JNI). Introduction Last week, the blog post Jackson gadgets - Anatomy of a vulnerability by Andrea Brancaleoni of Doyensec was published. It describes how a setter-based vulnerability in the Jackson library can be exploited if the libraries of Logback and H2 Database Engine are available. In short, it exploits the feature of H2 to create user defined functions with Java code that get compiled on the fly using the Java compiler. This is not But what if the Java compiler is not available? This was the exact case in a recent engagement where a H2 Dabatase Engine instance version 1.2.141 on a Windows system was exposing its web console. We want to walk you through the journey of finding a new way to execute arbitrary Java code without the need of a Java compiler on the target server by utilizing native libraries (.dll or .so) and the Java Native Interface (JNI). Assessing the Capabilities of H2 Let's assume the CREATE ALIAS … AS … command cannot be used as the Java compiler is not available. A reason for that may be that it's not a Java Development Kit (JDK) but only a Java Runtime Environment (JRE), which does not come with a compiler. Or the PATH environment variable is not properly set up so that the Java compiler javac cannot be found. However, the CREATE ALIAS … FOR … command can be used: When referencing a method, the class must already be compiled and included in the classpath where the database is running. Only static Java methods are supported; both the class and the method must be public. So every public static method can be used. But in the worst case, only h2-1.2.141.jar and JRE are available. And additionally, only supported data types can be used for nested function calls. So, what is left? While browsing the candidates in the Java runtime library rt.jar, the System.load(String) method stood out. It allows the loading of a native library. That would instantly allow code execution via the library's entry point function. But how can the library be loaded to the H2 server? Although Java on Windows supports UNC paths and fetches the file, it refuses to actually load it. And this also won't work on Linux. So how can one write a file to the H2 server? Writing arbitrary Files with H2 A brief look into the H2 functions reference shows that there is a FILE_WRITE function. Unfortunately, FILE_WRITE was introduced in 1.4.190. So we better only check those functions that are available in 1.2.141. The CSVWRIT Vulnerability Guideline
codewhitesec.webp 2019-07-19 14:03:26 Heap-based AMSI bypass for MS Excel VBA and others (lien direct) This blog post describes how to bypass Microsoft's AMSI (Antimalware Scan Interface) in Excel using VBA (Visual Basic for Applications). In contrast to other bypasses this approach does not use hardcoded offsets or opcodes but identifies crucial data on the heap and modifies it. The idea of an heap-based bypass has been mentioned by other researchers before but at the time of writing this article no public PoC was available. This blog post will provide the reader with some insights into the AMSI implementation and a generic way to bypass it.IntroductionSince Microsoft rolled out their AMSI implementation many writeups about bypassing the implemented mechanism have been released. Code White regularly conducts Red Team scenarios where phishing plays a great role. Phishing is often related to MS Office, in detail to malicious scripts written in VBA. As per Microsoft AMSI also covers VBA code placed into MS Office documents. This fact motivated some research performed earlier this year. It has been evaluated if and how AMSI can be defeated in an MS Office Excel environment.In the past several different approaches have been published to bypass AMSI. The following links contain information which were used as inspiration or reference:https://modexp.wordpress.com/2019/06/03/disable-amsi-wldp-dotnet also lists a lot of other writeups and implements a nice data-based approachhttps://outflank.nl/blog/2019/04/17/bypassing-amsi-for-vba/ AMSI Bypass for VBA The first article from the list above also mentions a heap-based approach. Independent from that writeup, Code White's approach used exactly that idea. During the time of writing this article there was no code publicly available which implements this idea. This was another motivation to write this blog post. Porting the bypass to MS Excel/VBA revealed some nice challenges which were to be solved. The following chapters show the evolution of Code White's implementation in a chronological way:Implementing our own AMSI Client in C to have a debugging platformUnderstanding how the AMSI API worksBypassing AMSI in our own clientPorting this approach to VBAImproving the bypass Improving the bypass - making it production-readyImplementing our own AMSI ClientIn order to ease debugging we will implement our own small AMSI client in C which triggers a scan on the malicious string 'amsiutils'. This string gets flagged as evil since some AMSI Bypasses of Matt Graeber used it. Scanning this simple string depicts a simple way to check if AMSI works at all and to verify if our bypass is functional. A ready-to-use AMSI client can be found on sinn3r's github . This code provided us a good starting point and also contained important hints, e.g. the pre-condition in the Local Group Policies.We will implement our test client using Microsoft Visual Studio Community 2017. In a first step, we end up with two functions, amsiInit() and amsiScan(), not to be confused with functions exported by amsi.dll. Later we will add another function amsiByPass() which does what its name suggests. See this gist for the final code including the bypass. Guideline
codewhitesec.webp 2019-02-07 11:04:37 Telerik Revisited (lien direct) In 2017, several vulnerabilities were discovered in Telerik UI, a popular UI component library for .NET web applications. Although details and working exploits are public, it often proves to be a good idea to take a closer look at it. Because sometimes it allows you to explore new avenues of exploitation. Introduction Telerik UI for ASP.NET is a popular UI component library for ASP.NET web applications. In 2017, several vulnerabilities were discovered, potentially resulting in remote code execution: CVE-2017-9248: Cryptographic Weakness A cryptographic weakness allows the disclosure of the encryption key (Telerik.Web.UI.DialogParametersEncryptionKey and/or the MachineKey) used to protect the DialogParameters via an oracle attack. It can be exploited to forge a functional file manager dialog and upload arbitrary files and/or compromise the ASP.NET ViewState in case of the latter. CVE-2017-11317: Hard-coded default key A hard-coded default key is used to encrypt/decrypt the AsyncUploadConfiguration, which holds the path where uploaded files are stored temporarily. It can be exploited to upload files to arbitrary locations. CVE-2017-11357: Insecure Direct Object Reference The name of the file stored in the location specified in AsyncUploadConfiguration is taken from the request and thus allows the upload of files with arbitrary extension. The vulnerabilities were fixed in R2 2017 SP1 (2017.2.621) and R2 2017 SP2 (2017.2.711), respectively. As for CVE-2017-9248, there is an analysis by PatchAdvisor[1] that gives some insights and exploitation hints. And regarding CVE-2017-11317, the detailed writeup by @straight_blast seems to have been published even half a year before Telerik published an updated version. It describes in detail how the vulnerability was discovered and how it can be exploited to upload an arbitrary file to an arbitrary location. If you're unfamiliar with these vulnerabilities, you may want to read the linked advisories first to get a better understanding. The Catch Although the vulnerabilities sound promising, they all have their catch: exploiting CVE-2017-9248 requires many thousands of requests, which can be pretty noticeable and suspicious. And unless it is actually possible to leak the MachineKey (which would allow an exploitation via deserialization of arbitrary ObjectStateFormatter stream), a file upload to an arbitrary location (i. e., CVE-2017-11317) is still limited to the knowledge of an appropriate location with sufficient write permissions. The problem here is that by default the account that the IIS worker process w3wp.exe runs with is a special account like IIS AppPool\DefaultAppPool. And such an account usually does not have write permissions to the web document root directory like C:\inetpub\wwwroot or similar. Additionally, the web document root of the web application can also be somewhere else and may not be known. So simply writing an ASP.NET web shell probably won't work in many cases. The Dead End This was exactly the case when we faced Managed Workplace RMM by Avast Business in a red team assessment where we didn't want to make too much noise. Additionally, unauthenticated access to all *.aspx pages except for Login.aspx was denied, i. e., the handler Telerik.Web.UI.DialogHandler.aspx for explo Vulnerability
codewhitesec.webp 2018-07-06 14:08:42 LethalHTA - A new lateral movement technique using DCOM and HTA (lien direct) The following blog post introduces a new lateral movement technique that combines the power of DCOM and HTA. The research on this technique is partly an outcome of our recent research efforts on COM Marshalling: Marshalling to SYSTEM - An analysis of CVE-2018-0824. Previous Work Several lateral movement techniques using DCOM were discovered in the past by Matt Nelson, Ryan Hanson, Philip Tsukerman and @bohops. A good overview of all the known techniques can be found in the blog post by Philip Tsukerman. Most of the existing techniques execute commands via ShellExecute(Ex). Some COM objects provided by Microsoft Office allow you to execute script code (e.g VBScript) which makes detection and forensics even harder. LethalHTA LethalHTA is based on a very well-known COM object that was used in all the Office Moniker attacks in the past (see FireEys's blog post): ProgID: "htafile" CLSID : "{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}" AppID : "{40AEEAB6-8FDA-41E3-9A5F-8350D4CFCA91}" Using James Forshaw's OleViewDotNet we get some details on the COM object. The COM object runs as local server. It has an App ID and default launch and access permissions. Only COM objects having an App ID can be used for lateral movement. It also implements various interfaces as we can see from OleViewDotNet. One of the interfaces is IPersistMoniker. This interface is used to save/restore a COM object's state to/from an IMoniker instance. Our initial plan was to create the COM object and restore its state by ca
codewhitesec.webp 2018-06-15 15:19:13 Marshalling to SYSTEM - An analysis of CVE-2018-0624 (lien direct) In May 2018 Microsoft patched an interesting vulnerability which was reported by Nicolas Joly of Microsoft's MSRC: A remote code execution vulnerability exists in "Microsoft COM for Windows" when it fails to properly handle serialized objects. An attacker who successfully exploited the vulnerability could use a specially crafted file or script to perform actions. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) that contains a specially crafted file that is designed to exploit the vulnerability. However, an attacker would have no way to force the user to visit the website. Instead, an attacker would have to convince the user to click a link, typically by way of an enticement in an email or Instant Messenger message, and then convince the user to open the specially crafted file. The security update addresses the vulnerability by correcting how "Microsoft COM for Windows" handles serialized objects. The keywords "COM" and "serialized" pretty much jumped into my face when the advisory came out. Since I had already spent several months of research time on Microsoft COM last year I decided to look into it. Although the vulnerability can result in remote code execution, I'm only interested in the privilege escalation aspects. Before I go into details I want to give you a quick introduction into COM and how deserialization/marshalling works. As I'm far from being an expert on COM, all this information is either based on the great book "Essential COM" by Don Box or the awesome Infiltrate '17 Talk "COM in 60 seconds". I have skipped several details (IDL/MIDL, Apartments, Standard Marshalling, etc.) just to keep the introduction short. Introduction to COM and MarshallingCOM (Component Object Model) is a Windows middleware having reusable code (=component) as a primary goal. In order to develop reusable C++ code, Microsoft engineers designed COM in an object-oriented manner having the following key aspects in mind: Portability Encapsulation Polymorphism Separation of interfaces from implementation Object extensibility Resource Management Language independence COM objects are defined by an interface and implementation class. Both interface and implementation class are identified by a GUID. A COM object can implement several interfaces using inheritance.All COM objects implement the IUnknown interface which looks like the following class definition in C++: The QueryInterface() method is used to cast a COM object to a different interface implemented by the COM object. The AddRef() and Release() methods are used for reference counting. Just to keep it short I rather go on with an existing COM object instead of creating an artificial example COM object.A Control Panel COM object is identified by the GUID {06622D85-6856-4460-8DE1-A81921B41C4B}. To find out more about the COM object we could analyze the registry manually or just use the great tool "OleView .NET".
codewhitesec.webp 2018-05-30 15:00:04 Poor RichFaces (lien direct) RichFaces is one of the most popular component libraries for JavaServer Faces (JSF). In the past, two vulnerabilities (CVE-2013-2165 and CVE-2015-0279) have been found that allow RCE in versions 3.x ≤ 3.3.3 and 4.x ≤ 4.5.3. Code White discovered two new vulnerabilities which bypass the implemented mitigations. Thereby, all RichFaces versions including the latest 3.3.4 and 4.5.17 are vulnerable to RCE. Introduction JavaServer Faces (JSF) is a framework for building user interfaces for web applications. While there are only two major JSF implementations (i. e., Apache MyFaces and Oracle Mojarra), there are several component libraries, which provide additional UI components and features. RichFaces is one of the most popular libraries among these component libraries and since it became part of JBoss (and thereby also part of Red Hat), it is also part of several JBoss/Red Hat products, for example JBoss EAP and JBoss Portal.[1] RichFaces has three major version branches: 3.x, 4.x, and 5.x. However, as 5.x has never left alpha state, it is rather irrelevant. In early 2016, the developers of RichFaces announced the end-of-life of RichFaces in June 2016. The latest releases of the respective branches are 3.3.4 and 4.5.17. The Past In the past, two significant vulnerabilities have been discovered by Takeshi Terada of MBSD, which both affect various RichFaces versions: CVE-2013-2165: Arbitrary Java Deserialization in RichFaces 3.x ≤ 3.3.3 and 4.x ≤ 4.3.2 Deserialization of arbitrary Java serialized object streams in org.ajax4jsf.resource.ResourceBuilderImpl allows remote code execution. CVE-2015-0279: Arbitrary EL Evaluation in RichFaces 4.x ≤ 4.5.3 (RF-13977) Injection of arbitrary EL method expressions in org.richfaces.resource.MediaOutputResource allows remote code execution. Both vulnerabilities rely on the feature to generate images, video, sounds, and other resources on the fly based on data provided in the request. The provided data is either interpreted as a plain array of bytes or as a Java serialized object stream. In RichFaces 3.x, the data gets appended to the URL path preceded by either /DATB/ (byte array) or /DATA/ (Java serialized object stream); in RichFaces 4.x, the data is transmitted in a request parameter named db (byte array) or do (Java serialized object stream). In all cases, the binary data is compressed using DEFLATE and then encoded using a URL-safe Base64 encoding. CVE-2013-2165: Arbitrary Java Deserialization This vulnerability is a straight forward Java deserialization vulnerability. When a RichFaces 3.x resource is requested, it eventually gets processed by ResourceBuilderImpl.getResourceDataForKey(String). If the requested resource key begins with /DATA/, the remaining data gets decoded and decompressed (using ResourceBuilderImpl.decrypt(byte[]), which actually, despite its name, does not incorporate encryption[2]) and finally deserialized without any further validation. In RichFaces 4.x, it is basically the same: the org.richfaces.resource.DefaultCodecResourceRequestData holds
codewhitesec.webp 2018-03-13 15:41:13 Exploiting Adobe ColdFusion before CVE-2017-3066 (lien direct) In a recent penetration test my teammate Thomas came across several servers running Adobe ColdFusion 11 and 12. Some of them were vulnerable to CVE-2017-3066 but no outgoing TCP connections were possible to exploit the vulnerability. He asked me whether I had an idea how he could still get a SYSTEM shell and the outcome of the short research effort is documented here.Introduction Adobe ColdFusion & AMFBefore we go into technical details, I will give you a short intro to Adobe ColdFusion (CF). Adobe ColdFusion is an Application Development Platform like ASP.net, however several years older. Adobe ColdFusion allows a developer to build websites, SOAP and REST web services and interact with Adobe Flash using the Action Message Format (AMF).The AMF protocol is a custom binary serialization protocol. It has two formats, AMF0 and AMF3. An Action Message consists of headers and bodies. Several data types are supported in AMF0 and AMF3. For example the AMF3 format supports the following protocol elements with their type identifier:Details about the binary message formats of AMF0 and AMF3 can be found on Wikipedia (see https://en.wikipedia.org/wiki/Action_Message_Format).There are several implementations for AMF in different languages. For Java we have Adobe BlazeDS (now Apache BlazeDS), which is also used in Adobe ColdFusion.The BlazeDS AMF serializer can serialize complex object graphs. The serializer starts with the root object and serializes its members recursively.Two general serialization techniques are supported by BlazeDS to serialize complex objects:Serialization of Bean Properties (AMF0 and AMF3)Serialization using Java's java.io.Externalizable interface. (AMF3)Serialization of Bean PropertiesThis technique requires the object to be serialized to have a public no-arg constructor and for every member public Getter-and Setter-Methods (JavaBeans convention).In order to collect all member values of an object, the AMF serializer invokes all Getter-methods during serialization. The member names and values are put in the Action message body with the class name of the object.During deserialization, the classname is taken from the Action Message, a new object is constructed and for every member name the corresponding setmethod is called with the value as argument. This all happens either in method readScriptObject() of class flex.messaging.io.amf.Amf3Input or readObjectValue() of class flex.messaging.io.amf.Amf0Input.Serialization using Java's java.io.Externalizable interfaceBlazeDS further supports serialization of complex objects of classes implementing the java.io.Externalizable interface which inherits from java.io.Serializable. Every class implementing this interface needs to provide its own logic to deserialize itself by calling methods on the java.io.ObjectInput-implementation to read serialized primitive types and Strings (e.g. method read(byte[] paramArrayOfByte)).During deserialization of an object (type 0xa) in AMF3, the method readScriptObject()of class flex.messaging.io.amf.Amf3Input gets called. In line #759 the method readExternalizable is invoked which calls the readExternal() method on the object to be deserialized.This should be sufficient to serve as an introduction to Adobe ColdFusion and AMF.Previous workChris Gates (@Carnal0wnage) published the paper Cold
codewhitesec.webp 2018-01-23 10:30:55 Handcrafted Gadgets (lien direct) IntroductionIn Q4 2017 I was pentesting a customer. Shortly before, I had studied json attacks when I stumbled over an internet-facing B2B-portal-type-of-product written in Java they were using (I cannot disclose more details due to responsible disclosure). After a while, I found that one of the server responses sent a serialized Java object, so I downloaded the source code and found a way to make the server deserialize untrusted input. Unfortunately, there was no appropriate gadget available. However, they are using groovy-2.4.5 so when I saw [1] end of december on twitter, I knew I could pwn the target if I succeeded to write a gadget for groovy-2.4.5. This led to this blog post which is based on work by Sam Thomas [2], Wouter Coekaerts [3] and Alvaro Muñoz (pwntester) [4]. Be careful when you fix your readObject() implementation...We'll start by exploring a popular mistake some developers made during the first mitigation attempts, after the first custom gadgets surfaced after the initial discovery of a vulnerability. Let's check out an example, the Jdk7u21 gadget. A brief recap of what it does: It makes use of a hashcode collision that occurs when a specially crafted instance of java.util.LinkedHashSet is deserialized (you need a string with hashcode 0 for this). It uses a java.lang.reflect.Proxy to create a proxied instance of the interface javax.xml.transform.Templates, with sun.reflect.annotation.AnnotationInvocationHandler as InvocationHandler. Ultimately, in an attempt to determine equality of the provided 2 objects the invocation handler calls all argument-less methods of the provided TemplatesImpl class which yields code execution through the malicious byte code inside the TemplatesImpl instance. For further details, check out what the methods AnnotationInvocationHandler.equalsImpl() and TemplatesImpl.newTransletInstance() do (and check out the links related to this gadget). The following diagram, taken from [5], depicts a graphical overview of the architecture of the gadget. So far, so well known. In recent Java runtimes, there are in total 3 fixes inside AnnotationInvocationHandler which break this gadget (see epilogue). But let's start with the first and most obvious bug. The code below is from AnnotationInvocationHandler in Java version 1.7.0_21: There is a try/catch around an attempt to get the proxied annotation type. But the proxied interface javax.xml.transform.Templates is not an annotation. This constitutes a clear case of potentially dangerous input that would need to be dealt with. However, instead of throwing an exception there is only a return statement inside the catch-branch. Fortunately for the attacker, the instance of the class is already fit for purpose and does not need the rest of the readObject() method in order to be able to do its malicious work. So the "return" is problematic and would have to be replaced by a throw new Exception of some sort. Let's check how this method looks like in Java runtime 1.7.0_80: Ok, so problem fixed? Well, yes and no. On the one hand, the use of the exception in the catch-clause will break the gadget which currently ships with ysoserial. On the other hand, this fix is a perfect example of the popular mistake I'm talking about. Wouter Coekaerts (see [3]) came up with an idea how to bypass such "fixes" and Alvaro Muñoz (see [4]) provided a gadget for JRE8u20 which utilizes this technique (in ca
codewhitesec.webp 2017-05-17 16:56:28 SAP Customers: Make sure your SAPJVM is up to date! (lien direct) SummaryCode White have already an impressive publication record on Java Deserialization. This post is dedicated to a vulnerability in SAP NetWeaver Java. We could reach remote code execution through the p4 protocol and the Jdk7u21 gadget with certain engines and certain versions of the SAP JVM.We would like to emphasize the big threat unauthenticated RCE poses to a SAP NetWeaver Java. An attacker with a remote shell can read out the secure storage, access the database, create a local NetWeaver user with administrative privileges, in other words, fully compromise the host. Unfortunately, this list is far from being complete. An SAP landscape is usually a network of tightlyconnected servers and services. It wouldn't be unusual that the database of the server stores technical users with high privileges for other SAP systems, be it NetWeaver ABAP or others. Once the attacker gets hold of credentials for those users she can extend her foothold in the organization and eventually compromise the entire SAP landscape.We tested our exploit successfully on 7.20, 7.30 and 7.40 machines, for detailed version numbers see below. When contacted, SAP Product Security Response told us they published 3 notes (see [7], [8] and [9]) about updates fixing the problems (already in June 2013) with SAP JVM versions 1.5.0_086, 1.6.0_052 and 1.7.0_009 (we tested on earlier versions, see below). In addition SAP have recently adopted JDK JEP 290 (a Java enhancement that allows to filter incoming serialized data). However, neither do these three notes mention Java Deserialization nor is it obvious to the reader they relate to security in any other way.Due to missing access to the SAP Service Marketplace we're unable to make any statement about the aforementioned SAP JVM versions. We could only analyze the latest available SAP JVM from tools.hana.ondemand.com (see [6]) which contained a fix for the problem.DetailsIn his RuhrSec 2016 talk, Code White's former employee Matthias Kaiser already talked about SAP NetWeaver Java being vulnerable [2]. The work described here is completely independent of his research.The natural entry point in this area is the p4 protocol. We found a p4 test client on SAP Collaboration Network and sniffed the traffic. One doesn't need to wait long until a serialized object is sent over the wire:00000000  76 31                                            v100000002  18 23 70 23 34 4e 6f 6e  65 3a 31 32 37 2e 30 2e .#p#4Non e:127.0.00000012  31 2e 31 3a 35 39 32 35  36                      1.1:5925 6    00000000  76 31 19 23 70 23 34 4e  6f 6e 65 3a 31 30 2e 30 v1.#p#4N one:10.0    00000010  2e 31 2e 31 38 34 3a 35  30 30 30 34             .1.184:5 00040000001B  00 00 11 00 00 00 00 00  00 00 ff ff ff ff 00 00 ........ ........0000002B  00 00 00 00 00 00 0a 00  63 00 6f 00 63 00 72    ........ c.o.c.r    0000001C  00 00 75 00 00 00 ff ff  ff ff 9e 06 60 00 00 00 ..u..... ....`...&nbs Guideline
codewhitesec.webp 2017-04-04 16:01:07 AMF – Another Malicious Format (lien direct) AMF is a binary serialization format primarily used by Flash applications. Code White has found that several Java AMF libraries contain vulnerabilities, which result in unauthenticated remote code execution. As AMF is widely used, these vulnerabilities may affect products of numerous vendors, including Adobe, Atlassian, HPE, SonicWall, and VMware. Vulnerability disclosure has been coordinated with US CERT (see US CERT VU#307983). Summary Code White has analyzed the following popular Java AMF implementations:Flex BlazeDS by Adobe (retired, contributed Flex to the Apache Software Foundation in 2011)Flex BlazeDS by ApacheFlamingo AMF Serializer by Exadel (discontinued)GraniteDS (discontinued?)WebORB for Java by Midnight Coders Each of these have been found to be affected by one or more of the following vulnerabilities:XML external entity resolution (XXE)Creation of arbitrary objects and setting of propertiesJava Deserialization via RMI The former two vulnerabilities are not completely new.1 But we found that other implementations are also vulnerable. Finally, a way to turn a design flaw common to all implementations into a Java deserialization vulnerability has been discovered. XXE JavaBeans Setters Deserialization via RMI Adobe Flex BlazeDS 4.6.0.23207 ☒ ☐ ☒ Apache Flex BlazeDS 4.7.2 ☐ ☐ ☒ Flamingo AMF Serializer 2.2.0 ☒ ☒ ☒ GraniteDS 3.1.1.GA ☒ ☒ ☒ WebORB for Java 5.1.0.0 ☒ ☒ ☒ We'll get into details later, except for the XXE. If you're looking for details on that, have a look at our previous blog post CVE-2015-3269: Apache Flex BlazeDS XXE Vulnerabilty. Introduction The Action Message Format version 3 (AMF3) is a binary message format mainly used by Flash applications for communicating with the back end. Like JSON, it supports different kind of basic data types. For backwards compatibility, AMF3 is implemented as an extension of the original AMF (often referred to as AMF0), with AMF3 being a newly introduced AMF0 object type. One of the new features of AMF3 objects is the addition of two certain characteristics, so called traits: […] ActionScript 3.0 introduces two furthe
codewhitesec.webp 2016-05-08 11:15:23 Return of the Rhino: An old gadget revisited (lien direct) [Update 08/05/2015: Added reference to CVE-2012-3213 of James Forshaw. Thanks for the heads up]As already mentioned in our Infiltrate '16 and RuhrSec '16 talks, Code White spent some research time to look for serialization gadgets. Apart from the Javassist/Weld gadget we also found an old but interesting gadget, only using classes from the Java Runtime Environment (so called JRE gadget).We called the gadget Return of the Rhino since the relevant gadget classes are part of the Javascript engine Rhino, bundled with Oracle JRE6 and JRE7.As you may already know, the Rhino Script engine has already been abused in JVM sandbox escapes in the past (e.g. CVE-2011-3544 of Michael Schierl and CVE-2012-3213 of James Forshaw).We stumbled over the gadget just by accident as we realized that there is a huge difference between the official Oracle JRE and the JRE's bundled in common Linux distros.Most may not know that the Rhino Script Engine is actively developed by the Mozilla Project and distributed as a standalone package/jar (packages under org.mozilla.*). Furthermore, Oracle JRE6/7 is bundling an old fork of Rhino (packages under sun.org.mozilla.*).  Surprisingly, Oracle applied some hardening to Rhino core classes with JRE7u1513, not being serializable anymore. The changes were made to fix a sandbox escape (CVE-2012-3213) of James Forshaw (see James' blog post). But those hardening changes were not incorporated into Mozilla's Rhino mainline, which happens once in a while. So the gadget still works if you are using OpenJdk bundled with Ubuntu or Debian.Let's take a look at the static view of some Rhino core classes:In the Rhino Javascript domain almost every Javascript language object is represented as a ScriptableObject in the Java domain.Functions, Types, Regexes and several other Javascript objects are implemented in Java classes, extending ScriptableObject.A ScriptableObject has two interesting members. A reference to its prototype object and an array of Slot objects. The slots store the properties of a Javascript object. The Slot can either be Slot, GetterSlot or RelinkedSlot. For our gadget we only focus on the GetterSlot inner class.Every Slot class has a getValue() method used to retrieve the value of the property. In case of a GetterSlot the value is taken from a call to either a MemberBox or Function instance. And both MemberBox and Function instances do dynamic method calls using Java's Reflection API. That's already the essence of the story :-). But let's go into details.The class NativeError is a successor of IdScriptableObject which inherits from ScriptableObject. ScriptableObject implements the tagging interface Serializable, hence all successors like NativeError are serializable. The class NativeError has an interesting way of how toString() is performed: ★★★
codewhitesec.webp 2016-04-12 16:11:34 Infiltrate 2016 Slidedeck: Java Deserialization Vulnerabilities (lien direct) The outcome of Code White's research efforts into Java deserialization vulnerabilities was presented at Infiltrate 2016 by Matthias Kaiser.The talk gave an introduction into finding and exploiting Java deserialization vulnerabilities. Technical details about the Oracle Weblogic deserialization RCE (CVE-2015-4852) and a SAP Netweaver AS Java 0day were shown.The slidedeck doesn't include the SAP Netweaver AS Java 0day POC and it won't be published until fixed.It  can be found here: http://www.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-classStay tuned!
codewhitesec.webp 2016-02-23 14:50:40 Compromised by Endpoint Protection: Legacy Edition (lien direct) The previous disclosure of the vulnerabilities in Symantec Endpoint Protection (SEP) 12.x showed that a compromise of both the SEP Manager as well as the managed clients is possible and can have a severe impact on a whole corporate environment. Unfortunately, in older versions of SEP, namely the versions 11.x, some of the flawed features of 12.x weren't even implemented, e. g., the password reset feature. However, SEP 11.x has other vulnerabilities that can have in the same impact. Vulnerabilities in Symantec Endpoint Protection 11.x The following vulnerabilities have been discovered in Symantec Endpoint Protection 11.x: SEP Manager SQL Injection Allows the execution of arbitrary SQL on the SQL Server by unauthenticated users. Command Injection Allows the execution of arbitrary commands with 'NT Authority\SYSTEM' privileges by users with write acceess to the database, e. g., via the before-mentioned SQL injection. SEP Client Binary Planting Allows the execution of arbitrary code with 'NT Authority\SYSTEM' privileges on SEP clients running Windows by local users. As SEP 11.x is out of support since early 2015 and Symantec won't provide a patch, you are highly advised to upgrade to 12.1. SEP Manager SQL Injection The AgentRegister operation of the AgentServlet is vulnerable to SQL injections within the HardwareKey attribute: To reach that point, we need to provide a valid DomainID, which can be retrieved from a SEP client installation from the SyLink.xml file located in C:\ProgramData\Symantec\Symantec Endpoint Protection\CurrentVersion\Data\Config. Exploiting this vulnerability is a little more complicated. For example, changing a SEPM administrator user's password requires the manipulation of a configuration stored as an XML document in the database. The administrative users are stored in the SemConfigRoot document in the basic_metadata table with the hard-coded ID B655E64D0A320801000000E164041B79. An administrator entry might look like this: The complicated part is that this configuration document is crucial for the whole SEPM. Any changes resulting in an invalid XML document result in a denial of service. That's why it's important that any change results in a valid document as well. So how can we modify that document to our advantages? The stored PasswordHash is simply the MD5 of the password in hexadecimal representation. So replacing that attribute value with a new one would allow us to login with that password. But we neither know the current PasswordHash value (obviously!) nor any other attribute value that we can use as an anchor point for the string manipulate. However, we know other parts of the SemAdministrator element that we can use. For example, if we replace ' PasswordHash=' by ' PasswordHash="[…]" OldPasswordHash=', we can set our own PasswordHash value while being able to reverse the operation by replacing ' PasswordHash="[…]" OldPasswordHash=' by ' PasswordHash=': Here we first do the reverse operation in line 14 before updating the PasswordHash value with ours in line 15 to avoid accidentally creating an invalid document in the case the update is executed multiple times. There
codewhitesec.webp 2016-02-04 17:03:53 Java and Command Line Injections in Windows (lien direct) Everyone knows that incorporating user provided fragments into a command line is dangerous and may lead to command injection. That's why in Java many suggest using ProcessBuilder instead where the program's arguments are supposed to be passed discretely in separate strings. However, in Windows, processes are created with a single command line string. And since there are different and seemingly confusing parsing rules for different runtime environments, proper quoting seems to be likewise complicated. This makes Java for Windows still vulnerable to injection of additional arguments and even commands into the command line. Windows' CreateProcess Command Lines In Windows, the main function for creating processes is the CreateProcess function. And in contrast to C API functions like execve, arguments are not passed separately as an array of strings but in a single command line. On the other side, the entry point function WinMain expects a single command line argument as well. This circumstance requires the program to parse the command line itself for extracting the arguments. And although Windows provides a CommandLineToArgvW function and supports C and C++ API entry point functions where arguments are already parsed by the runtime and passed in a argc/argv style, the rules for quoting command line arguments with all their quirks can be quite confusing. And there is no definitive guide on how to quote properly, let alone something like a ArgvToCommandLineW function that does it for you. That's why many do it wrong, as “Everyone quotes command line arguments the wrong way” by Daniel Colascione observes. You should definitely read the latter two linked pages first to understand the rest of this blog post. For testing, we'll use the following Java class, which utilizes ProcessBuilder as suggested: The resulting CreateProcess command line can be observed with the Windows Sysinternals' Process Monitor. And for how the command line gets parsed, you can use the following program, which prints the results of both the parsing of C command-line arguments (via the argv function parameter) and of the parsing of C++ command-line arguments (via CommandLineToArgvW function). This already produces different and frankly surprising results in some cases: The last two are remarkable as one additional quotation mark swaps the results of argv and CommandLineToArgvW. Java's Command Line Generation in Windows With the knowledge of how CreateProcess expects the command line arguments to be quoted, let's see how Java builds the command line and quotes the arguments for Windows. If a process is started using ProcessBuilder, the arguments are passed to the static method start of ProcessImpl, which is a platform-dependent class. In the Windows implemen Guideline
codewhitesec.webp 2015-10-01 13:40:39 $@|sh – Or: Getting a shell environment from Runtime.exec (lien direct) If you happen to have command execution via Java's Runtime.exec on a Unix system, you may already have noticed that it doesn't behave like a normal shell. Although simple commands like ls -al, uname -a, or netstat -ant work fine, more complex commands and especially commands with indispensable features like pipes, redirections, quoting, or expansions do not work at all. Well, the reason for that is that the command passed to Runtime.exec is not executed by a shell. Instead, if you dig down though the Java source code, you'll end up in the UNIXProcess class, which reveals that calling Runtime.exec results in a fork and exec call on Unix platforms. Nonetheless, I'll show you a way to still get commands executed in a proper shell. For testing, we'll use this Java example: We call this class as shown below with single quotes around the command line to ensure that our shell passes the command line argument to Java as is: $ java Exec 'command arg1 arg2 ...' Your first thought on a solution to this might be: "Ok, I'll just use sh -c command to execute command in the shell." That is correct, but here is the catch: Since only the first argument following -c is interpreted as shell command, the whole shell command must be passed as a single argument. And if you take a closer look at how the string passed to Runtime.exec is processed, you'll see that Java uses a StringTokenizer that splits the command at any white-space character. If you are thinking of quoting the command parameter string like uname -a as follows: $ java Exec 'sh -c "uname -a"' this won't work. Remember: We're not in a shell yet, and Runtime.exec does only take white-spaces as argument separators into account. So, what is the other option that we have? The key is in the sh -c command, but we won't execute the command directly but build a command that itself spawns another shell that then executes our command. Though it sounds complicated, we'll derive it step by step. How it works The secret key to this is the special parameter @, which expands to the positional parameters when referenced with $@, starting from parameter one: $ java Exec 'sh -c $@' But how do we pass the actual command? Well, if the shell is invoked with -c, any remaining arguments after the command argument are assigned to the positional parameters, starting with $0. So when $@ is expanded by the shell with the following invocation: $ java Exec 'sh -c $@ 0 1 2 3 4 5' It results in 1 2 3 4 5. The 0-th parameter does not appear in the expansion result as it, by convention, should be the file name associated with the file being executed. We can see the result by adding a echo in place of the $1 parameter: $ java Exec 'sh -c $@ 0 echo 1 2 3 4 5' Here the shell first expands $@ to echo 1 2 3 4 5 and then executes it. But this is still not better than the simple sh -c command, as we still have no support of pipes, redirections, quoting or expansion. The reason for this is that the $@ exp
codewhitesec.webp 2015-08-24 13:25:17 CVE-2015-3269: Apache Flex BlazeDS XXE Vulnerabilty (lien direct) In a recent Product Security Review, Code White Researchers discovered a XXE vulnerability in Apache Flex BlazeDS/Adobe (see ASF Advisory). The vulnerable code can be found in the BlazeDS Remoting/AMF protocol implementation. All versions before 4.7.1 are vulnerable. Software products providing BlazeDS Remoting destinations might be also affected by the vulnerability (e.g. Adobe LiveCycle Data Services, see APSB15-20). Vulnerability DetailsAn AMF message has a header and a body. To parse the body, the method readBody() of AmfMessageDeserializer is called. In this method, the targetURI, responseURI and the length of the body are read. Afterwards, the method readObject() is called which eventually calls the method readObject() of an ActionMessageInput instance (either Amf0Input or Amf3Input). In case of an Amf0Input instance, the type of the object is read from the next byte. If type has the value 15, the following bytes of the body are parsed in method readXml() as a UTF string. The xml string gets passed to method stringToDocument of class XMLUtil where the Document is created using the DocumentBuilder. When a DocumentBuilder is created through the DocumentBuilderFactory, external entities are allowed by default. The developer needs to configure the parser to prevent XXE. ExploitationExploitation is easy, just send the XXE vector of your choice.
codewhitesec.webp 2015-08-24 10:29:17 Exploiting the hidden Saxon XSLT Parser in Ektron CMS (lien direct) Another vulnerability I came across was in Ektron CMS. It's a .NET-based Web CMS System. If you want to find running instances try "inurl:/workarea filetype:asmx" at Google. The interesting thing about is that Microsoft already reported the initial vulnerability as MSVR12-016 (CVE-2012-5357), but I found a different vector to exploit it. Summary From US CERT VU#110652: Ektron Content Management System version 8.5, 8.7, and 9.0 contain a resource injection vulnerability by using an improperly configured XML parser. By default, Ektron utilizes the Microsoft XML parser to parse XSLT documents, which is not vulnerable. If an attacker specifies use of the Saxon XSLT parser instead, and sends it a specially crafted XSLT document, the attacker may be able to run arbitrary code at the privilege level of the application. Vulnerability Details During information gathering, I found several Web services exposed on the Ektron CMS system. One of them was http://[host]/Workarea/ServerControlWS.asmx Looking at the WSDL, there was the SOAP method ContentBlockEx, having a parameter that nearly jumped into my face: xslt. If you can get your data parsed by a XSLT parser, that's almost like hitting the jackpot. The problem was that Ektron already patched the vulnerability by hardening the MSXML parser. Nevertheless, XXE was still possible - but I couldn't get any helpful information out of the system. There was also another vulnerability that allowed me to list directories. Finally, I found the directory with all .net DLL's. After browsing through the directory, I finally found something interesting. There were several saxon9*.dlls. From my former times, I could remember that Saxon allows me to parse XSLT. So I had a look at the documentation at Saxon Function Library.Looking at the different namespaces, I found several interesting functions working with files, etc. After browsing through the Saxon documentation, I finally found an interesting paragraph Saxon Calling Static Methods in a .NET ClassFrom this, it seemed like I could call static functions of .net CRL classes from Saxon :-) So I created the following XSLT template: Putting it all together, the final SOAP request looks like this: Vendor ResponseI wasn't involved, although CERT tried to contact them with no luck. The fixEktron released a Security Update 2 (Releases 8.02 SP5 to 9.10 SP1). To my amazement, Ektron told CERT the following: This was patched via a cumulative security patcher that was made available Oct 9, 2013 that would apply the updates to versions 8.0.2 to 9.0. The current version of the patcher is available at: https://portal.ektron.com/News/Security/Security_Notice_-_11-25-14/ 8.7sp2 (released 8/16/2013), 9.0sp1 (relea
codewhitesec.webp 2015-08-24 10:29:17 How I could (i)pass your client security (lien direct) Half a year ago I stumbled over a software called iPass Open Mobile during a Windows Client security review. iPass Open Mobile helps you in getting network connectivity over Wifi-Hotspots, modem, DSL, etc. It's widely deployed on Windows Clients in large corporations. SummaryFrom US CERT VU#110652: The iPass Open Mobile Windows Client versions 2.4.4 and earlier allows Remote Code Execution as SYSTEM. It utilizes named pipes for interprocess communication. One of the subprocesses spawned by the client runs with SYSTEM privileges. An authenticated user can register arbitrary DLL files, including ones located at UNC paths, by sending a specially-crafted unicode string to this subprocess to one of the named pipes. The DllMain function in the specified DLL file will then execute with SYSTEM privileges. Vulnerability DetailsThis software attracted my attention due to several processes that were running in the background, one of it being as NT-Authority/SYSTEM. The CLR binary iPlatformService.exe is running as a service, but starts two processes of iPlatformHost.exe, one as SYSTEM and another one as your user. The Main method of class iPass.iPlatformHost.Program eventually creates an iPass.Bus.Bus instance. In the constructor of iPass.Bus.Bus two iPass.Bus.BusEngine objects are instantiated. The iPass.Bus.BusEngine will create a NamedPipeServerStream, accepting commands from CommandPipeAccessPrivillage.Everyone. So what does CommandPipeAccessPrivillage.Everyone mean? Does it grant access to everyone? The method iPass.Bus.EPHelperCommandPipeServer.ServerThreadFunction() answers the question. Access is granted to the current user and to BUILTIN\Users which includes the Domain Users group of a windows domain! Commands are processed by plugins registered at the iPass.Bus.Bus. In case of CVE-2015-0925 I focused on the plugin "iPass Software Update Assistant Plugin". It can be found in the default installation under C:\Program Files (x86)\iPass\Open Mobile\omsi\Plug-ins\iPass.SoftwareUpdateAssistant and has the plugin-id iPass.SWUpdateAssist. Looking at the config file plugin.xml the command "RegisterCOM" caught my eye, as it was defined to be running in System context.
codewhitesec.webp 2015-08-04 07:59:03 Compromised by Endpoint Protection (lien direct) In a recent research project, Markus Wulftange of Code White discovered several critical vulnerabilities in the Symantec Endpoint Protection (SEP) suite 12.1, affecting versions prior to 12.1 RU6 MP1 (see SYM15-007). As with any centralized enterprise management solution, compromising a management server is quite attractive for an attacker, as it generally allows some kind of control over its managed clients. Taking control of the manager can yield a takeover of the whole enterprise network. In this post, we will take a closer look at some of the discovered vulnerabilities in detail and demonstrate their exploitation. In combination, they effectively allow an unauthenticated attacker the execution of arbitrary commands with 'NT Authority\SYSTEM' privileges on both the SEP Manager (SEPM) server, as well as on SEP clients running Windows. That can result in the full compromise of a whole corporate network. Vulnerabilities in Symantec Endpoint Protection 12.1 Code White discovered the following vulnerabilities in Symantec Endpoint Protection 12.1: SEP Manager Authentication Bypass (CVE-2015-1486) Allows unauthenticated attackers access to SEPM Mulitple Path Traversals (CVE-2015-1487, CVE-2015-1488, CVE-2015-1490) Allows reading and writing arbitrary files, resulting in the execution of arbitrary commands with 'NT Service\semsrv' privileges Privilege Escalation (CVE-2015-1489) Allows the execution of arbitrary OS commands with 'NT Authority\SYSTEM' privileges Multiple SQL Injections (CVE-2015-1491) Allows the execution of arbitrary SQL SEP Clients Binary Planting (CVE-2015-1492) Allows the execution of arbitrary code with 'NT Authority\SYSTEM' privileges on SEP clients running Windows The objective of our research was to find a direct way to take over a whole Windows domain and thus aimed at a full compromise of the SEPM server and the SEP clients running on Windows. Executing post exploitation techniques, like lateral movement, would be the next step if the domain controller hasn't already been compromised by this. Therefore, we focused on SEPM's Remote Java or Web Console, which is probably the most exposed interface (accessible via TCP ports 8443 and 9090) and offers most of the functionalities of SEPM's remote interfaces. There are further entry points, which may also be vulnerable and exploitable to gain access to SEPM, its server, or the SEP clients. For example, SEP clients for Mac and Linux may also be vulnerable to Binary Planting. Attack Vector and Exploitation A full compromise of the SEPM server and SEP clients running Windows was possible through the following steps: Gaining administrative access to the SEP Manager (CVE-2015-1486) Full compromise of SEP Manager server (CVE-2015-1487 and CVE-2015-1489) Full compromise of SEP clients running Windows (CVE-2015-1492) CVE-2015-1486: SEPM Authentication Bypass SEPM uses sessions after the initial authentication. User information is stored in a AdminCredential object, which is
codewhitesec.webp 2015-06-09 15:20:19 Reading/Writing files with MSSQL\'s OPENROWSET (lien direct) Unfortunately, Microsoft SQL Server's SQL dialect Transact-SQL does not support reading and writing files in an easy way as opposed to MySQL's LOAD_FILE() function and INTO OUTFILE clause. Of course, with xp_cmdshell being enabled, you can read and write files using OS commands. However, one is not always blessed with the CONTROL SERVER permission, which is generally only granted with the sysadmin role. But if you happen to have the ADMINISTER BULK OPERATIONS permission (implied by the bulkadmin role), then OPENROWSET is a viable option for both reading and writing files. Granted, using OPENROWSET for reading and writing files is nothing new. However, all examples for writing files that I have seen so far require the access to remote OLE DB providers being enabled, which is controlled by the ad hoc distributed queries configuration option, which is disabled by default. And changing and reconfiguring any configuration option requires ALTER SETTINGS permissions (implied by the sysadmin and serveradmin roles), which are not always available. And, well, in case of the sysadmin role, you could just as well use xp_cmdshell. So the technique for writing files demonstrated here is a little different as it exploits a side-effect of OPENROWSET, which just requires ADMINISTER BULK OPERATIONS permission. It also does not require any temporary table or whatsoever; everything can be performed in a sub-query. Checking Prerequisites For looking up whether the current user has ADMINISTER BULK OPERATIONS permissions, you can use the HAS_PERMS_BY_NAME() function: The the result should be 1. Reading Files Reading a file is pretty straight forward. When OPENROWSET is referenced in the FROM clause, it allows reading from the given file through a built-in BULK provider and returns it as a rowset. The following SELECT reads the C:\Windows\win.ini file and returns a rowset of one single character LOB: This, of course, can also be used to leak hashes for pass-the-hash. Writing Files Writing to a file is a little more difficult. The common approach with OPENROWSET only is calling an external OLE DB provider. But this generally requires ad hoc distributed queries being enabled and has certain caveats like restriction to certain output formats depending on the selected OLE DB provider (e. g., CSV), previous existence of the output file, registration of linked servers, etc. However, there is a way of writing arbitrary data to an arbitrary file without any of these restrictions or prerequisites by exploiting a side-effect of OPENROWSET. The feature that is being exploited is the error reporting feature. The reference states the purpose of the ERRORFILE argument as follows: ERRORFILE = 'file_name' Specifies the file used to collect rows that have formatting errors and cannot be converted to an OLE DB rowset. These rows are copied into this error
codewhitesec.webp 2015-05-20 15:03:17 CVE-2015-2079: Arbitrary Command Execution in Usermin (lien direct) While performing a penetration test for a customer, I stumbled across a command execution vulnerability in Usermin that is pretty trivial to identify and to exploit. The interesting part is that this vulnerability survived for almost 13 years. Introduction According to the Usermin Homepage: Usermin is a web-based interface for webmail, password changing, mail filters, fetchmail and much more. It is designed for use by regular non-root users on a Unix system, and limits them to tasks that they would be able to perform if logged in via SSH or at the console. Therefore, Usermin can be seen as a web alternative for interactive machine access as a specific system user. But often times in real environments, Usermin is used to limit the user's rights to perform specific actions via the web, for example as a webmailer only. In this case, arbitrary command execution is definitely not a desired feature. Nonetheless, enter CVE-2015-2079, which affects Usermin versions 0.980 (dating back to 2002-12-16) until 1.650 (latest unpatched version of 2015-02-16) by exploiting a specific behavior of Perl's open() function. Summary An authenticated user of Usermin can specify the path to an arbitrary file on the server that should be attached to any new email as a signature via the Signature file configuration in the Other file option. This is due to the function get_signature in usermin/mailbox/mailbox-lib.pl, which calls open() without any prior validation: For what it's worth, that alone poses a vulnerability. But according to an old bug report dating back to 2005, this is not a bug but a feature: This is not really a bug, as normal Unix file permissions still apply, so really critical files like /etc/shadow cannot be used as a signature. Also, the feature for attaching server-side files could be used in the same way Besides that, due to some specific behavior of the Perl function used to open the user specified file, it is possible to provide and execute shell commands. Vulnerability Details Perl's open() function can not just open regular files. If it gets called with just two arguments (i. e., open FILEHANDLE,EXPR), the second argument allows to specify additional behavior via prefixes and suffixes. For example, the open mode can be specified with the prefix for writing to, or >> for appending to the file. And with the prefix or suffix | it is possible to start interprocess communication: Perl's basic open() statement can also be used for unidirectional interprocess communication by either appending or prepending a pipe symbol to the second argument to open(). Since Usermin's call to open() uses the two arguments form, we can provide a shell command enclosed in pipes as the Signature file to execute the provided command whenever the user composes a new email and output is shown within the message text window or when the user edits the signature. Example request as proof-of-concept with a sig_file_free parameter of value |uname -a| which gets sent to /uconfig_save.cgi by a POST request to usermin like this:
codewhitesec.webp 2015-05-08 20:48:26 CVE-2015-0935: PHP Object Injection in Bomgar Remote Support Portal (lien direct) Serialization is often used to convert objects into a string representation for communication or to save them for later use. However, deserialization in PHP has certain side-effects, which can be exploited by an attacker who is able to provide the data to be deserialized. This post will give you an insight on the deserialization of untrusted data vulnerability in the Bomgar Remote Support Portal 14.3.1 (US CERT VU#978652, CVE-2015-0935), which is part of Bomgar's appliance-based remote support software. It covers details on the weakness of Deserializion of Untrusted Data (CWE-502) in PHP applications in general, as well as specific details on the vulnerability and its exploitation in the Bomgar Remote Support Portal 14.3.1. Note that this post is not about the various bugs in the implementation of the unserialize function itself (see for example Sec Bug #67492, Sec Bug #68594, Sec Bug #68710, and Sec Bug #68942), but about the exploitation on the application level. Summary Description from US CERT VU#978652: Bomgar Remote Support Portal version 14.3.1 and possibly earlier versions deserialize untrusted data without sufficiently verifying the validity of the resulting data. An unauthenticated attacker can inject arbitrary input to at least one vulnerable PHP file, and authenticated attackers can inject arbitrary input to multiple vulnerable PHP files. When malicious data is deserialized, arbitrary PHP code may be executed in the context of the PHP server process. Vulnerability Details The PHP function unserialize allows the creation of arbitrary object constructs of any class with arbitrary attributes of almost arbitrary types without any validation. During the deserialization, the lifetime of an object, and the interaction with the object, several methods, including so called magic methods, may get called using these arbitrarily definable attributes. An attacker may be able to utilize the functionality provided within these called methods to his benefit. For more information on deserialization in PHP, have a look at Serialization in the PHP Internals Book and Writing Exploits For Exotic Bug Classes: unserialize() by Stephen Coty of Alert Logic. In Bomgar Remote Support Portal 14.3.1, unserialize is called several times with user provided data, among them there is one which can be called by an unauthenticated user. Exploitation The most challenging part of exploiting such a vulnerability is finding appropriate classes with effects beneficial for an attacker. Therefore, it solely depends on the available classes. If there are no classes with beneficial effects available, it is not exploitable. Fortunately, there is at least one in Bomgar Remote Support Portal 14.3.1! One way to exploit this vulnerability is by utilizing the Tracer class. It is used to write stack trace information to a log using a Logger instance, which wraps an instance of PEAR's Log class. By using a Log_file instance as an instance of Lo ★★★★
Last update at: 2024-03-28 13:09:45
See our sources.
My email:

To see everything: Our RSS (filtrered) Twitter