[FD] Zenario v7.6 CMS - SQL Injection Web Vulnerability

[Vulnerability Lab]

Document Title:
===
Zenario v7.6 CMS - SQL Injection Web Vulnerability


References (Source):

https://www.vulnerability-lab.com/get_content.php?id=2043


Release Date:
=
2018-01-16


Vulnerability Laboratory ID (VL-ID):

2043


Common Vulnerability Scoring System:

5.7


Vulnerability Class:

SQL Injection


Current Estimated Price:

500€ - 1.000€


Product & Service Introduction:
===
Zenario is a web-based content management system for sites with one or many 
languages. It's designed to grow with 
your site, adding extranet, online database and custom functionality when you 
need it. Zenario 7.2 has a new feature 
to add CSS styles and media queries, thereby allowing you to make 
mobile-friendly "responsive" email newsletters.

(Copy of the Homepage: http://zenar.io/ )


Abstract Advisory Information:
==
The vulnerability laboratory core research team discovered a remote 
sql-injection vulnerability in the official Zenario v7.6 content management 
system.


Vulnerability Disclosure Timeline:
==
2018-01-16: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=
Published


Affected Product(s):

Zenario
Product: Zenario - Content Management System (Web-Application) 7.1

Zenario
Product: Zenario - Content Management System (Web-Application) 7.2

Zenario
Product: Zenario - Content Management System (Web-Application) 7.3

Zenario
Product: Zenario - Content Management System (Web-Application) 7.4

Zenario
Product: Zenario - Content Management System (Web-Application) 7.5

Zenario
Product: Zenario - Content Management System (Web-Application) 7.6


Exploitation Technique:
===
Remote


Severity Level:
===
Medium


Technical Details & Description:

A remote sql-injection web vulnerability has been discovered in the official 
Zenario v7.1 - v7.6 content management system web-application.
The sql-injection web vulnerability allows remote attackers with restricted 
account to execute own malicious sql commands to compromise 
the web-application and database management system.

The sql-injection vulnerability is location in the `Name` input field of the 
`Categories - Edit` module create POST method request.
Remote attackers with restricted privileged accounts are able to execute own 
malicious sql commands to compromise the application.
The attack vector of the vulnerability occurs on the client-side and the 
request method to inject is POST.

The security risk of the sql-injection vulnerability is estimated as medium 
with a common vulnerability scoring system count of 5.7. 
Exploitation of the sql-injection web vulnerability requires a restricted site 
admin user account without user interaction. 
Successful exploitation of the sql-injection vulnerability results in 
web-application or database management system compromise.

Request Method(s):
[+] POST

Vulnerable Module(s):
[+] Categories - Edit

Vulnerable File(s):
[+] organizer.php
[+] admin_boxes.ajax.php

Vulnerable Parameter(s):
[+] Name (current_value)


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

Vulnerable Module: Categories > Edit > Name - Current_Value (Input Field)

--- PoC Session Logs [GET] (restricted_admin) ---
Status: 200[OK]
POST 
http://zenario.localhost:8080/zenario/admin/admin_boxes.ajax.php?path=zenario_categories=4
Mime Type[text/html]
   Request Header:
  Host[zenario.localhost:8080]
  User-Agent[Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 
Firefox/51.0]
  Content-Type[application/x-www-form-urlencoded; charset=UTF-8]
  X-Requested-With[XMLHttpRequest]
  Referer[http://zenario.localhost:8080/zenario/admin/organizer.php?]
  Content-Length[664]
  Cookie[__cfduid=; PHPSESSID=; COOKIE_LAST_ADMIN_USER=restricted_admin; 
cookies_accepted=1]
  Connection[keep-alive]
   POST-Daten:
  _save[true]
  _confirm[]
  
_box[%7B%22key%22%3A%7B%22id%22%3A%224%22%2C%22parent_id%22%3A0%7D%2C%22tabs%22%3A%7B%22details%22%3A%7B%22edit_mode%22%3A%7B%22on%22%3A1%7D%2C%22fields%22%3A%7B%22name%22%3A%7B%22current_value%22%3A%22'[SQL-INJECTION
 

[FD] MagicSpam 2.0.13 - Insecure File Permission Vulnerability

[Vulnerability Lab]

Document Title:
===
MagicSpam 2.0.13 - Insecure File Permission Vulnerability


References (Source):

https://www.vulnerability-lab.com/get_content.php?id=2113


Release Date:
=
2018-01-12


Vulnerability Laboratory ID (VL-ID):

2113


Common Vulnerability Scoring System:

2.8


Vulnerability Class:

Privacy Violation - Information Disclosure


Current Estimated Price:

500€ - 1.000€


Product & Service Introduction:
===
MagicSpam comes fully-integrated with any Plesk 12+ package, blocking spam at 
the edge before it gets a chance to be filtered. 
There’s no need to change DNS or MX records. And your protection comes ready to 
go with complete logging, statistics, and custom controls.

(Copy of the Homepage: https://www.plesk.com/extensions/magicspam/ )


Abstract Advisory Information:
==
An independent vulnerability laboratory researcher discovered a insecure file 
permission vulnerability in the MagicSpam 2.0.13-1 plesk extension.



Vulnerability Disclosure Timeline:
==
2017-01-12: Public Disclosure (Vulnerability Laboratory)


Discovery Status:
=
Published


Affected Product(s):

LinuxMagic
Product: MagicSpam - Plesk Extension 2.0.13-1


Exploitation Technique:
===
Remote


Severity Level:
===
Low


Technical Details & Description:

An insecure file permission access vulnerability has been discovered in the 
MagicSpam 2.0.13-1 plesk extension.
The vulnerability allows an attacker to access sensitive information like 
emails without permission or authentication.


Plesk panel features the freemium extension MagicSpam providing 
industry-leading spam protection technologies.
MagicSpam is keeping a detailed log of all e-mail messages processed under 
directory /var/log/magicspam/ in 
Ubuntu installations. A log file is created with the name mslog, with readable 
permissions for everyone, and rotated daily. 
The file will reveal the full list of mailboxes on the server (provided they 
received or sent at least one message in the past).

The security risk of the permission vulnerability is estimated as low with a 
common vulnerability scoring system count of 2.8. 
Successful exploitation of the file permission security vulnerability results 
in information disclosure of emails.


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

$ id
uid=1002(marco) gid=1011(marco) groups=1011(marco)
$ cd /var/log/magicspam/
$ ls -l
-rw-r--r-- 1 magicspam root 348937 Jan 10 11:50 mslog
$ tail -n1 mslog
2018-01-10 11:51:26 magicspam-daemon[335]: HAM: 
mua=no,ip=[93.94.32.17:mail15.clab99a.contactlab.it],helo=,from=<564020151.35960.1000...@t.contactlab.it>,rcpt=


Solution - Fix & Patch:
===
The security vulnerability can be resolved byan exclude of the emails in the 
list of the affected application log files.
Another solution could be to integration an authentication mechanism  for the 
log file of the magic spam web-application.


Security Risk:
==
The security risk of the insecure file permission vulnerability in the plesk 
extension magic spam is estimated as medium (CVSS 2.8).


Credits & Authors:
==
Marco Marsala [ma...@thenetworksolution.it] - 
https://www.vulnerability-lab.com/show.php?user=Marco+Marsala


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 Labs or its 
suppliers have been advised of the possibility of such damages. Some states do 
not allow the exclusion or limitation of liability mainly for incidental
or consequential damages so the foregoing limitation may not apply. We do not 
approve or encourage anybody to break any licenses, policies, deface 
websites, hack into databases or trade with stolen data. We have no need for 
criminal activities or membership requests. We do not publish advisories 
or vulnerabilities of religious-, militant- and racist- 
hacker/analyst/researcher groups or individuals. We do not publish trade 
researcher mails, 
phone numbers, conversations or anything else to journalists, 

[FD] [RT-SA-2017-013] Truncation of SAML Attributes in Shibboleth 2

[RedTeam Pentesting GmbH]

Advisory: Truncation of SAML Attributes in Shibboleth 2

RedTeam Pentesting discovered that the shibd service of Shibboleth 2
does not extract SAML attribute values in a robust manner. By inserting
XML entities into a SAML response, attackers may truncate attribute
values without breaking the document's signature. This might lead to a
complete bypass of authorisation mechanisms.


Details
===

Product: Shibboleth 2
Affected Versions: before 2.6.1 (with XMLTooling-C prior 1.6.3)
Fixed Versions: 2.6.1
Vulnerability Type: Authorisation Bypass
Security Risk: high
Vendor URL: https://www.shibboleth.net/
Vendor Status: notified
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2017-013
Advisory Status: public
CVE: CVE-2018-0486
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0486


Introduction


"Shibboleth is among the world's most widely deployed federated identity
solutions, connecting users to applications both within and between
organizations. Every software component of the Shibboleth system is free
and open source.

Shibboleth is an open-source project that provides Single Sign-On
capabilities and allows sites to make informed authorization decisions
for individual access of protected online resources in a
privacy-preserving manner."
(from the Shibboleth Consortium's website [1])


More Details


Shibboleth 2 makes use of SAML 2 to communicate assertions between
identity providers and service providers. In some modes of operation,
SAML messages are relayed through a user's browser. Therefore, their
integrity must be protected. SAML accomplishes this by utilizing the XML
signature standard [2] to sign its messages. When employing signatures,
it is important that signed data is interpreted in a consistent manner
by all parties.

RedTeam Pentesting discovered that by inserting XML entities into a SAML
response, the XML signature processor and the Shibboleth application
will interpret the response differently. Parts of the document, for
example values of SAML attributes, can partially be substituted by XML
entities. An inline document type definition at the beginning of the XML
document is inserted to define these entities. During signature
verification, the XML document is canonicalized, which includes
resolution of entities. The definition of all entities is chosen such
that, after their resolution, the original contents of the XML document
appear again. For example, if "RedTeam" was replaced with "Ream", the
entity "x" will be defined as the string "dTe". Consequently, the
signature remains intact as the content of the document was not
changed.

After validating the signature of a SAML response, Shibboleth will
extract various information from the document, such as the values of
SAML attributes. Extracting strings from the XML DOM is implemented
by the function shown below (shortened and re-formatted):


void AbstractXMLObjectUnmarshaller::unmarshallContent(
const DOMElement* domElement)
{
[...]
DOMNode* childNode = domElement->getFirstChild();
[...]
unsigned int position = 0;
while (childNode) {
if (childNode->getNodeType() == DOMNode::ELEMENT_NODE) {
[...]
// Advance the text node position marker.
++position;
}
else if (
childNode->getNodeType() == DOMNode::TEXT_NODE
|| childNode->getNodeType() == DOMNode::CDATA_SECTION_NODE
) {
m_log.debug("processing text content at position (%d)",
position);
setTextContent(childNode->getNodeValue(), position);
}

childNode = childNode->getNextSibling();
}
}


This function fails to take into account the presence of sibling text
and entity nodes in the DOM. The "position" variable is only incremented
if an element node is encountered. If sibling text nodes are
encountered, "setTextContent" will be called multiple times with
"position" set to zero. Consequently, only the contents of the last
sibling text node will be retrieved from the DOM. For example, consider
the following XML snippet:

attackerad...@example.net

When called on "", the "unmarshallContent" function will first
extract "attacker". The "" entity will be ignored. Next,
"ad...@example.net" will be fetched from the DOM. However, as "position"
was never incremented, this latter string overwrites the previously
extracted data.

By exploiting the behaviour of this function, attackers can truncate
SAML attribute values. Arbitrary prefixes and or suffixes may be removed
without breaking the XML signature.


Proof of Concept


Exploitation of this vulnerability is demonstrated using the
dockerized-idp-testbed [3] which implements a minimal Shibboleth
infrastructure using multiple docker containers. It includes a sample
PHP