RichFaces Framework 3.X Expression Language (EL) Injection (CVE-2018-14667)
Recently, a new vulnerability in the RichFaces framework was discovered and was assigned with CVE-2018-14667. RichFaces is one of the libraries that implement the JavaServer faces (JSF) specification which is the Java standard for building server-side user interfaces. RichFaces provides large amount of advanced Ajax based UI components. In this case the vulnerable feature of RichFaces is the one that allows it to dynamically generate resources such as images or videos based on data received from the user. Each one of those resources are assigned with a unique identifier that is sent to the server via the requested URL alongside with a Java serialized object that is deserialized by the server and supplies it withthe metadata required for generating and rendering the resource. The serialized Java object that is passed to the server is compressed and encoded using the URL safe base64 encoding. Figure 1: RichFaces dynamically generated JPEG file. Figure 2: Example of decompressing and decoding the data sent to the server In past cases it was found that those Java serialized objects helping RichFaces to serve resources could be replaced with malicious ones that may allow attackers to execute arbitrary code on the server running RichFaces, and this case is of no difference. João Matos the researcher who discovered the vulnerability found that another class of resources named “UserResource” by RichFaces receives serialized Java objects as input and therefor prone to similar vulnerability. Mitigating the vulnerability using iRulesLX BIG-IP customers are encouraged to deploy the attached iRule in order to mitigate this vulnerability. The usage of a dedicated iRule is required as the payload exploiting the vulnerability is both encoded and compressed. /Portals/0/Images/userfiles/306666/CVE-2018-14667.zip Additional Reading https://codewhitesec.blogspot.com/2018/05/poor-richfaces.htmlApache Struts 2 Namespace Evaluation Remote Code Execution (CVE-2018-11776 / S2-057)
Today, a new Apache Struts 2 Remote Code Execution vulnerability was announced (S2-057) and CVE-2018-11776 was allocated. At the moment, there is no public Proof of Concept exploit available. for a Struts 2 application to be vulnerable, its configuration should meet 2 conditions: The value of the “struts.mapper.alwaysSelectFullNamespace” should be set to true. This means that Struts will consider the “namespace” to be everything before the last slash of the URI. Action declaration via <action> tag without “namespace” attribute. When the conditions are met, Struts will try to extract the “namespace” from the request URL by following the next logic: Example URL: http://struts2app.test/[Servlet Context]/[Namespace]/[Action].action It was found that if the namespace was extracted from the requested URL, and it contained an Object-Graph Navigation Library (OGNL) expression which is the expression language supported by the Struts framework, in some cases the extracted expression may be evaluated by Struts, which may lead to arbitrary code execution. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Edit:We have released additional, more generic signatures to cover OGNL / JSP expressions injection attempts in the URL: 200004474 -JSP Expression Language Expression Injection (3) (URI) 200004475 - Object Graph Navigation Library Expression Injection (2) (URI Edit:Proof of Concept exploit for this vulnerability is now publicly available. The exploitcan be mitigated by the following signatures: Figure 1: Exploit blocked with attack signature 200004281 Figure 2: Exploit blocked with attack signature 200003439 Figure 3: Exploit blocked with attack signature 200004156 Figure 4: Exploit blocked with attack signature 200004368) Additional Reading https://lgtm.com/blog/apache_struts_CVE-2018-11776 https://semmle.com/news/apache-struts-CVE-2018-11776Remote Code Execution with Spring Data Commons (CVE-2018-1273)
In the recent days another critical vulnerability in Spring Framework was published (CVE-2018-1273). This time the vulnerable component is Spring Data Commons. Spring Data component goal is to provide a common API for accessing NoSQL and relational databases. Spring Data Commons provides basic implementation and interfaces to the other Spring Data projects. It was found that the MapDataBinder class of the Spring Data Commons project was unsafely parsing and evaluating a Spring Expression Language (SpEL) Expression which may be controlled by the user. Because of this unsafe evaluation an attacker can send a string that contains the special T() operator which tells Spring expression parser to treat the string inside it as a class reference and consequently may allow execution of arbitrary code. To mitigate the issue, Spring developers changed the class which they were performing the expression evaluation with from StandardEvaluationContext which allows evaluating Java type references, constructors and bean references to SimpleEvaluationContext which prohibits them and was designed to support only a subset of the Spring Expression Language syntax. Figure 1: Spring Data Commons Github commit showing the change from StandardEvaluationContext to SimpleEvaluationContext Figure 2: CVE-2018-1273 Proof of Concept as it was posted by @shengqi158 (xxlegend) via Twitter Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operating system command execution signatures will detect the attempt to execute operating system commands as the payload for the exploit. Figure 3: Exploit blocked with attack signature 200003437. Figure 4: Exploit blocked with attack signature 200003073 Figure 5: Exploit blocked with attack signature 200002273Remote Code Execution with Spring OAuth Extension (CVE-2018-1260)
Recently, a new Remote Code Execution vulnerability in Spring OAuth extension was published by Pivotal. The OAuth Protocol OAuth is a protocol that supports authorization processes by enabling users to share their data and resources stored on one site with another site. For example, when you use the sign in with Facebook feature available in many modern websites, you utilize the OAuth protocol to allow the 3rd party application to access resources from your Facebook account. This is achieved by authenticating against Facebook’s authorization server and obtaining a token that will be used by the 3rd party application to access the resource servers of Facebook. The supplied token will be validated and if approved the resource servers will send the requested resource. The Vulnerability There are some conditions that must be met for the application that uses the Spring Framework OAuth extension to be vulnerable: It must act in the role of an authorization server. It must not configure any scopes. OAuth scopes provide a way for the authorization server to limit the amount of access that is granted to an access token. For example, scopes can be defined to limit the 3rd party application to read only for certain resources. Because the malicious payload will be sent to the application in the scope parameter if the application will encounter a scope name that doesn’t match the configured ones it will throw an exception and terminate the authorization process. It must use the Whitelabel OAuth approval page. Whitelabel pages in the Spring framework are pages that are present only for demonstration and should be replaced by the application developers. Another example of a Whitelabel page in the Spring framework is the default 404 page, that should be customized by the developer. Figure 1: Spring OAuth Whitelabel approval page The vulnerable code resides in the WhitelabelApprovalEndpoint class which handles the requests sent to the /oauth/authorize endpoint. It holds the template HTML code that will be rendered by the application and shown to the user when he approves the authorization. The template html is saved as a string in a private variable of the class. Figure 2: Spring’s default OAuth approval HTML template. The HTML template contains a few placeholders that will be replaced with the request values once the page is rendered by the application (e.g. %csrf% and %scopes% placeholders). The function that is responsible for replacing those placeholders is the createTemplate function. Figure 3: createTemplate function used by the WhitelabelApprovalEndpoint class to replace the placeholders with the session values The first if statement in the createTemplate function checks if the model object or the request object containing a key or attribute named “scopes”. if it finds such key in the model object or attribute in the request object it will call the createScopes function, which is responsible for building a <ul> (unordered list) HTML element which will hold the scopes available in the model object or the request object. it is important to note that if the model object contains the key “scopes” the value that will be shown to the user in the Spring’s OAuth Whitelabel page will be taken from it and not from the user’s request thus making the application not vulnerable (Condition number 2 mentioned above for the application to be vulnerable). Figure 4: “createScopes” function used to create a <ul> HTML element containing the provided scopes. After replacing the values in the Whitelabel HTML template, Spring returns a “ModelAndView” class instance and instantiates a SpelView class instance which stands for Spring Expression Language View and passes the parsed HTML template string to the constructor of the SpelView class. Figure 5: ModelAndView class instance returned by Spring framework and SpelView is used as the View instance. The SpelView class implements the View Java interface which declares the render method and requires the class that implements it to give its own implementation to it. Another important point to note about the SpelView class is that it holds an instance of the PlaceHolderResolver interface which requires the class that implements it to implement the resolvePlaceholder method. Figure 6: SpelView class declaration and constructor implementation. During it’s render process the SpelView class attempts to extract values that are located inside “${}” template expressions and evaluate them by parsing them as Spring Expression Language (SpEL) expression instance. Figure 7: SpelView render method implementation. Now let’s recap, if the Spring application is being used as the OAuth Authorization Server, and the application didn’t define any OAuth scopes, the user can supply a Spring Expression Language Expression inside a “${}” expression template, that will be stored in the scope parameter and will be parsed by the SpelView class. As we saw in previous vulnerabilities in the Spring framework, evaluation of a user-controlled Spring Expressions by using the “StandardEvaluationContext” class may lead to arbitrary code execution. Figure 8: Malicious user-controlled input parsed as a Spring Expression by the application. Figure 9:The result of parsing the user provided Spring Expression. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operating system command execution signatures will detect the attempt to execute operating system commands as the payload for the exploit. Figure 10: Exploit blocked with attack signature 200003437 Figure 11: Exploit blocked with attack signature 200003073Directory Traversal with Spring MVC on Windows (CVE-2018-1271)
Recently a directory traversal vulnerability in the Spring Framework was published (CVE-2018-1271). The Spring application will only be vulnerable when it is deployed on a Microsoft Windows based operating system and the application developer uses the “file://” scheme as the path of the static resources. Figure 1: Example of a vulnerable resource path configuration The answer for why only applications deployed on servers based on Microsoft Windows operating systems are vulnerable can be found in the Github commit that fixes the vulnerability. We can see that the “isInvalidEncodedPath” function covered only the case of “../” directory traversal attempts, while Windows operating systems supports paths that contains backslashes, and thus “..\” will also lead to directory traversal. Figure 2: Spring Framework’s Github commit fixing the vulnerability Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing evasion techniques in URL, "Directory Traversal” and “IIS Backslashes”. Figure 3: Exploitation attempt blocked by “Directory Traversals” evasion technique. Figure 4: Exploitation attempt blocked by “IIS backslashes” evasion technique.Spring Framework Spring-Messaging Remote Code Execution (CVE-2018-1270 / CVE-2018-1275)
In the recent days a critical vulnerability in Spring framework was published. The vulnerable component is Spring-Messaging which is the Spring implementation of WebSockets, Spring-Messaging uses the STOMP messaging protocol as the subprotocol for WebSockets. The vulnerability allows attackers to run arbitrary code by sending a crafted STOMP WebSocket message. A Proof of Concept code exploiting this vulnerability is already publicly available. Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers with BIG-IP versions greater than 12.1.0 which allows WebSocket inspection are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System. Also, operatingsystem command execution signatures will detect the attempt to execute operatingsystem commands as the payload for the exploit. Figure 1:Exploit blocked with attack signature 200003437. Figure 2:Exploit blocked with attack signature 200003073. Figure 3:Exploit blocked with attack signature 200002273.Security Trends in 2016: Known Vulnerabilities Are Still Dangerous
FINISH HIM! SSHowDowN Wins! The proxy attack Akamai published on last October of 2016 sound like a character from Mortal Kombat. That would be a fun MK character, a little digitized malware-bot killing Sub-Zero or Goro. In reality and actually a real world threat, SSHowDowN's a proxy exploit of OpenSSH daemons running on exposed devices (yes, the same devices that everyone's pwning these days). Where Mirai exploited user failure to change default username/password combos (and disable telnet), SSHowDowN exploited 12 year old vulnerability CVE-2004-1653 which allows OpenSSH to be used a a TCP tunnel for malicious traffic not originating on system. The issues are two-fold, A) we have devices shipping with SSH exposed and tunneling features enabled on public interfaces, and B) it's been out there for 12 years. We have to assume exploits exist we don't know about and enterprise-adopted source code is public; both good and bad users now have chances to pour over decades of material, looking for these hidden gems. 2016 gave us many more exploits of old known bugs so why are old bugs still causing us heartache? What The Experts Say HPE Security Research's 2016 Cyber Risk Report listed 7 major themes for the previous year; them three strike chords related to this article: Theme #5: The industry didn't learn anything about patching in 2015 Theme #6: Attackers have shifted their efforts to directly attack applications Theme #7: The monetization of malware Additionally, patching vulnerabilities involves 4 generalized steps: Researcher uncovers vulnerability; reports to vendor Developers implement a fix Vendor releases a patch End user deploys a software update The first step is usually made through a bug bounty program and here we run into a flaw: White versus Gray versus Black markets have made bugs a very lucrative mini-industry. Monetizing exploits is now big business and creates divergent paths for fixing known vulnerabilities for the various hat-colored people. White Hats make money via bug bounties, Gray Hats make money by selling through private brokers who supposedly resell to ethical and approved sources. And then there's Black Hats and they do what they do best. An Update Is Available... But You Can Keep Your Vulnerabilities April of 2016 saw Oracle publish technical information to the public on the known vulnerabilities of older editions of Java and steps to reduce client risk. This alerted the general public that newer versions of Java installed along side previous versions instead of overwriting the previous install. Some developers do require multiple versions of Java and that's a handy feature. For most people installing Java (read consumers) this was an unknown. This allowed old public vulnerabilities to coexist with their patched counterparts, undermining patching efforts. Oracle did create uninstall procedure instructions and published alerts through various media outlets; because it was required to by the FTC. In this case because known vulnerabilities were listed as fixed in release notes, a malicious user could simply read Oracle's documentation on how to bypass older versions. That Bug Is Old Enough To Drink May of 2016 saw Slackware releasing a patch for a 21-year-old bug which allowed a malicious user to execute remote DoS attacks by exploiting CVE-2016-10087; a null-pointer-deference bug in png_set_text_2 (). The Libpng owners in their own documentation warned of the flaw since July of 2000. Now pause... the CVE is new, the library's been around for a long time, and the flaw was known and documented. This re-raises public discussion on ownership's responsibility of code made popular during the Shellshock and Heartbleed blame games. What CVE-2016-10087 does illustrate is a lot of open source is capable of being investigated and potentially exploited. Mind you this particular CVE is hard to trigger in the wild and would require interactive sessions with the system or through other methods requiring existing elevated privileges. Still... go buy this null-pointer-deference bug a beer. Dirty Cows!!! CVE-2016-5195 leverages an incorrect handling of copy-on-write (COW) feature to write to a read-only memory mapping, and was show to be exploited in wild by October of 2016. How does it relate? 9 years of Linux kernels (2.x through 4.x before 4.8.3) were affected and it was actively being exploited at time of discovery and patching. This was more critical due to it's ability to access sensitive memory, say becoming root in a short amount of time. There was quite a bit of media coverage on this due to the critical nature of the bug and it's reliability of exploitation under normal conditions. I don't need to cover more on this, just search for CVE-2016-5195 and sit down for some nice quiet time reading although most everyone covered the same content. The Average Linux Security Flaw Is In Preschool Keeping Dirty Cows in mind, last October of 2016 codeblog author and Google developer Kees Cook evaluated CVE's between 2011 through 2016 confirming Linux kernel bugs have an average life span of 5 years. Numerical Summary By Severity: Critical: 2 @ 3.3 years High: 34 @ 6.4 years Medium: 334 @ 5.2 years Low: 186 @ 5.0 years Additionally Kees noted for the Linux kernel work, fixing existing bugs tends to create additional bugs. We then have to wait on upstream providers to patch their affected systems. The total lifespan from discover to having your Home DVR fixed could well exceed that 5 year average. Kees also referred to Jon Corbet's analysis in 2010 which came to similar results when comparing Linux kernel 2.6.x open issues. Jon's research identified CVE-2010-1188 which was fixed in 2008 but only identified as a security issue in 2010. This type of delay in realizing kernel bugs would also delay a vendors need to update their distributed kernel. A nefarious user with code level knowledge of kernel development (it is open source after all) would have several years of malicious use to all exposed systems before vendors patched with fixed kernels. Preventative Measures (Stop Airing Your Dirty Device Laundry) Some of these vulnerabilities identified require existing access or require semi-compromised system states to fully realize the exploitive potential. Some are just easy and spooky (Dirty Cow) to exploit. But when we're speaking of nation states, nothing is ever off the table, nor with organized groups of malicious users. Protection comes from limiting exposure to key resources and due diligence for any system requiring internet access. Responsibility isn't just for end users to worry about though; vendors could've prevented SSHowDowN, and Oracle should've default to overwriting Java versions in the installer unless explicitly told not to. For enterprises, the naked exposure of linux-based devices is usually a non-issue but applications moved to the cloud and we have to worry again about what's exposed. Linux kernels may not be exposed but I bet some of you are managing your AWS instance via SSH. What else may be exposed? MongoDB? Apache? Oracle? We've shifted our vulnerabilities to a new world and we're still trying to catch up with the old ones. I don't expect anyone to memorize the current CVE database but admins do have the ability to reduce exposure to the internet. The next Heartbleed or SSHowDown is just around the corner and you may be inadvertently the next target.
