Oracle WebLogic Server – JNDI Tree Second-Order Code Injection


Hi Everyone, today i want to share with you a post about a vulnerability i’ve discovered times ago, it was already fixed by the vendor. So before i get started i’ll explain first what is a second-order code injection mostly code injection vulnerabilities.

Code Injection is a type of exploitation caused by processing invalid data input. The concept of injection attacks is to introduce (or “inject”) malicious code into a program so as to change the course of execution. Such an attack may be performed by adding strings of malicious characters into data values in the form or argument values in the URL. Injection attacks generally take advantages of inadequate validation over input/output data, for example:

  • – Lack of defining a class of allowed characters (such as standard regular expressions or custom classes)
  • – Lack of restricting the data format.
  • – Lack of checking the amount of expected data (such as maximum length restriction)
  • – Lack of restricting the data type (such as numerical input only)

In this form of injection attack, the attackers introduce improper scripts into the web browsers. The technique is most often used to inject JavaScript, VBScript, ActiveX, HTML, Flash or any other types of codes that web browsers may execute. Once the injection is successfully performed, hackers can carry out a variety of malicious attacks including account hijacking, changing of user settings, cookie theft, poisoning, Cross-Site Request Forgery or false advertising.

-Second-order code injection :
Second-order code injection is the realisation of malicious code injected into an application by an attacker, but not activated in real-time by the application. In a lot of cases, the victim of the attack may not even be using the same application that the attacker injected their code.

I – Weakness Analysis :

The Code injection vulnerability reside in the Weblogic Server Administration Console (JNDI Tree Structure ). After testing on this platform i realized that i’m able to inject any strings into “server” parameter value. So i injected strings of malicious payloads (javascript/php/Ajax…) into the argument value in the following URI :
-[ /consolejndi.portal?_nfpb=true&_pageLabel=JNDIHomePage&server=(MALICIOUS_CODE) ] and it was a successfull injection, i can execute any code passed to the argument value.

Let’s look more deeper to identify the source of this issue, If we check “tree.js” we find actually that we can ovewrite/corrupt 3 TreeNode() function parameters.
When we take a look at the code *(1-1) we realize that TreeNode function it’s created as a “JSTree” class object, once all arguments are set the JNDI Tree is created by the function createTree(startNode) then we add new nodes in the previous tree with the function addNode(parentNode, recursedNodes) if the “nodeName” is valid. Therefore any attacker can take advantages of this inadequate validation over input/output data. The link above mention the main functions/methods that are processing and building the tree, its content and identifying the vulnerable parameters. (*Check the link )

Difference between the application behaviour in the (1-1) and (1-2) cases :

Actually Dynamic Analysis of data flow and tracking the execution of some functionalities such as ( Tree creation, Add new node, Expand/ collapse operation, Methods used to build JNDI tree,..etc.) helped me to identify the source of this weakness. The following link shows how to recognize the application behaviour in 2 statements, normal and in case of injecting a malicious code :

III – Exploitation :

In order to exploit this vulnerability an attacker can use several ways to inject a payload and execute arbitrary codes. Furthermore there is a possibility to interact with the environment, gain control of JSTree Class objects and the possibility to access an object in a WebLogic Server environment.

  1.  Session Control : Suppose now that we use the void()(returns a null value to the web browser) JavaScript function instead of alert(). We could change the DOM values inside this function and no navigation change state would occur. Oracle Weblogic server use “ADMINCONSOLESESSION” as a session main cookie, so if we start a new navigation to the same website in another browser instance, we’ll get a new “ADMINCONSOLESESSION”; we could change the session IDs in both instances by this payload : javascript: void(document.cookie=”ADMINCONSOLESESSION = <<another session ID>>”);
  2. XSS Shell.
  3. Phishing Attacks :Using Javascript, CSS or HTML an attacker can trick the victim to log in. The basic concept is to override the HTML of the current page to look identical to the login page. Little does the victim know, his credentials are sent to the attacker instead of to the website when trying to log in.  An attack vector for this kind of attack :
  1. Framework-based attacks :-Different attacks/exploitation could be provided with the help of a framework like BeEF, XSSF.


  1. Cross-Site Scripting Worms & Viruses : Using an application to host the malware code, triggers the purpose of second-order code injection issues, XSS worms and viruses take control over a Web browser and propagate by forcing it to copy the malware to other locations on the Web to infect others. XSS malware payloads could force the browser to send email, transfer money, delete/modify data, hack other websites, download illegal content, and many other forms of malicious activity. XSS exploits, typically HTML/JavaScript, use three ways to force browsers to send remote HTTP requests: Embedded HTML Tags, JavaScript DOM Objects, XMLHTTPRequest (XHR).XSS worm functions example :

-Access to local files from browser/ Screen-captures and send data to attacker :

So guys by this we come up to the end of this article,

See you soon, stay tuned 🙂

Best regards.


Follow me on twitter :

JSON Based Attack Techniques (XSS) Part#1

Hi Everyone,

I want to talk about some advanced attacks and potential security flaws especially when using JSON Applications that can lead to Data Injection/Session Hijacking issues.

In this 1st part i’ll talk about a particular kind of vulnerabilities in web applications that are vulnerable more and more to XSS vulnerabilities that are reflected in non HTML responses, For example : JSON. Before I go further, i want to define JSON : JavaScript Object Notation (JSON) is a simple, text-based data transfer format that is used to transmit data between a server and web applications, it’s widely used as a transport mechanism in AJAX applications. I’ll not give some JSON code samples you can find it over the net. In general, every expression that is valid in JavaScript is also valid in JSON.

So in order to apply our tests we have to know that JSON data objects can be evaluated. So, this feature helps to overcome the security restrictions applied by the SOP (same origin policy). However, we can use scripts to communicate and transmit data by the nature of AJAX applications.

Hacking JSON consist on the following typical Fuzzing techniques :

– Array overwrite.

-Large/negative numbers.

-Symbols like <@’_”%/–.

-Additional serialized objects.

As i mentioned before i’ll demonstrate an example of exploiting an XSS vulnerability. But exploiting XSS vectors against Internet Explorer is more than an “alert(‘XSS’)” and as we all know it’s a little bit hard in this situation because browsers pop up the file download instead of rendering the response when the returned content-type is application/json or application/javascript or application/json-rpc.


Thus, the only solution is to bypass JSON parsing mechanism to indirectly exploit this issue, before we move to the trick that will allow us to attack the vulnerable application (IE versions below 10), I want to explain how Microsoft Internet Explorer Filters works. Recently i had a chance to explore how this filters prevent such attacks :

Microsoft Internet Explorer’s XSS Filters :                                                                 ===============================

Filters within Internet Explorer (IE) 8/9 have the capability to deal with and to detect reflected XSS attacks by applying regular expressions to response data. If this data were reflected within the response, IE would handle the payload to prevent it from actually triggering.

The following command show some Filters :
C:\>findstr /C:”sc{r}” \WINDOWS\SYSWOW64\mshtml.dll|find “<                                     C:\>findstr /C:”script” \WINDOWS\SYSWOW64\mshtml.dll|find “{”
Here are a some of the extracted regular expressions including Unicode characters, common URI attributes and event handler names…etc :


After converting the resulting regular expressions, then creating SecRules to prevent XSS attacks against a web application, any
user can apply blacklist-filtering secrules against incoming request data.                                    Some of the converted IE XSS filters:

It was just a quick look into IE Cross-site Scripting filters, Now we pass to the method we’ll use to overcome the problem we encounter previously. This problem is linked to IE content sniffing heuristics, any file can be interpreted as executable Javascript under many circumstances. It’s actually a security weakness even if the data is sent with the appropriate JSON content type and well configured, this concept remains true even if JSON is not embedded in HTML. However this way is based on rendering JSON responses in IE by direct browsing. First we should know how IE defines file types and what content-type will be set for each response :

  1.  IE search for the response data content-type in the windows registry for the specific CLSID key  (know more about CLSID i.e: “CLSID”=6650f4a1-E8B5-A1CF-BB82-012500DDCE0B ), to find the correct handler for that response.
  2. If the content-type is found, IE will consider that to be the valid content-type otherwise IE will attempt to identify the content-type from the file extension or another way.

In our situation the default mime-type list of Internet Explorer does not include any JSON data mime-type. Besides when visiting a link with JSON data included, IE directly prompts the file download dialog because the specific content-type to consider for the requested file is not found when IE attempts to search in the windows registry (HKCR\MIME\Database\Content Type\CLSID).

In order to force IE to recognize JSON responses and render them, the file extension must be considered by IE as text/html (.htm or .html) within the URL. In addition regarding the manner that most web servers use to parse the path, most server side languages (PHP, Python, Perl CGI…) accepts “path-info” parameter that uses the slash sign (/) as delimiter to be passed from the URL  (i.e : HTTP://[domain_name]/[path-info]?[GET params]). Then when an web application is vulnerable to a reflected XSS, the attacker simply adds “.html” as path-info, consequently the server returns a page with XSS content and the same JSON file type and finally IE matches .html path-info to be text/html and directly triggers XSS.

This way we are now able to exploit XSS using a combination of path-info parameter and IE’s content-type designation weakness.

That’s all for this 1st part guys stay in touch … 🙂

You can check my previous research about a kind of JSON attacks :


Follow me on twitter :