========================================================================
| # Title     : limny 2.2 Expression language injection vulnerability
| # Author    : indoushka
| # email     : indoushka4ever@gmail.com
| # Tested on : windows 8.1 FranASSais V.(Pro)
| # Version   : 2.2
| # Vendor    : http://www.limny.org/
| # Dork      : n/a
========================================================================

poc :


PHP code injection :

file : index.php

Line 28 " eval($value.';'); "

http://127.0.0.1//limny-2.2/?q=%24{%40${@system(dir)}}

Expression language injection vulnerability :

Vulnerability description :

This script is possibly vulnerable to Expression Language Injection attacks.

To provide easy ways of outputting data from an object model that more closely resembles pure scripting languages, 
Expression Language (EL) was developed as part of JSTL (Java Server Pages Standard Tag Library). 

JSP EL is a specification (JSR-245 and JSR 252 [2]) and there are many implementations: 
JSP 2.0/2.1: Used by most recently built applications, and delivered as part of the JSTL. 
Jakarta: An older EL implementation built by Apache. 
OGNL: A powerful EL popularized by Struts2/WebWork. 
MVEL: A general purpose EL usable for console applications. 
SPEL: Springs custom EL for scripting (not used in JSPs). 

Expression Language Injection occurs when user input is evaluated by a J2EE servers Expression Language resolvers, 
and a common opportunity for this vulnerability to occur today is with the usage of Spring JSP tags.

Affected items : /limny-2.2/index.php

The impact of this vulnerability :

The impacts of this attack range from a simple HttpOnly bypass to a server-side information leakage technique. 
This information leakage will differ in severity mostly based on what J2EE technologies are in use and what is 
in scope of the vulnerable code. One of the most dangerous abuse scenarios involves an attacker controlled page 
inferring a users session ID on a browser thats currently logged into the vulnerable application.

How to fix this vulnerability :

Perform data validation best practice against untrusted input and to ensure that output encoding 
is applied when data arrives on the EL layer, so that no metacharacter is found by the interpreter 
within the user content before evaluation. The most obvious patterns 
to detect include ${ and #{, but it may be possible to encode or fragment this data.

Attack details :

URL encoded GET input q was set to ${9999840-10937}

Pattern found:
 
9988903

Greetz : aua'>>a'1/2a'1/2a'dega'deg aua'degaua'degau a'>>a'*a'*auaua'>>------au-auau-a'deg a'degaua'degauPSaua'3a'>>au-------- aua'degauau!a'>>auau aua'degauaua'*oauaua'degau ------
                                                                       |
jericho * Larry W. Cashdollar * moncet-1 * achraf.tn                   |
                                                                       |
===================== pa'degaua'1/2a'>>au auauoauau aua'>>auauauauauauC/  =============================